#1136 Missing JSR305 source-code artifact



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


  • 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.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks