#1136 Missing JSR305 source-code artifact

open
William Pugh
None
5
2014-03-06
2012-11-21
Gili Tzabari
No

Hi,

Someone published JSR305 to Maven incorrectly. Version 2.0.1 consists of a JAR file containing both class files and source files. The problem with this approach is that IDEs won't detect the source-code files or Javadoc, making it harder to use the library.

Expected behavior:
jsr305-2.0.1jar should only contain the class files
jsr305-2.0.1-sources.jar should only contain the source files

Discussion

  • William Pugh
    William Pugh
    2012-11-25

    For the IDE's I use, they will detect source files contained in the jar file. Which IDE doesn't?

    Would there be a problem if the source were contained in both jsr305-2.0.1.jar and jsr305-2.0.1-sources.jar?

     
  • William Pugh
    William Pugh
    2012-11-25

    • assigned_to: nobody --> wpugh
    • status: open --> pending
     
  • Gili Tzabari
    Gili Tzabari
    2012-11-26

    • status: pending --> open
     
  • Gili Tzabari
    Gili Tzabari
    2012-11-26

    My mistake. The IDE *does* pick up the sources. You should still split the classes and sources into separate artifacts so users only end up deploying what they need.

     
  • William Pugh
    William Pugh
    2012-11-26

    Given that the jar file is tiny, I don't understand the advantage of separating them out. The source files are about 15K, and the classfiles are about 17K. Does it really matter to someone if they save 15K?

     
  • Gili Tzabari
    Gili Tzabari
    2012-11-26

    Practically speaking, probably not. Theoretically speaking, Maven conventions dictate the two should remain separate. Since my IDE is picking up sources just fine I'll leave it up to you to decide which way you want to go.

     
  • D Miles
    D Miles
    2012-12-07

    It is a convention that is useful as it clearly makes the redistribution of the data clear. It is not possible to tell if the contents of the regular *.jar files are needed by the runtime *.class files and those files end up on the class path.

    Where as when they are in another file people don't deploy the extra data in production, they don't download them if they don't need them, the various facets of 1 project (runtime library, javadoc and sources) is nicely encapsulated in an understandable way what due to convention leads itself to allowing automated tooling to work within each realm.

    Just because this one project (and its maintainer) doesn't see the point in the convention because the data is so small doesn't mean the larger Java ecosystem doesn't appreciate when an individual project has considered the bigger picture.