Community
Participate
Working Groups
As discussed on http://blog.deepakazad.com/2011/12/annotation-based-null-analysis-with-jdt.html it would be great if the tiny new annotation bundle org.eclipse.jdt.annotation would be available from maven repos. The said bundle has no dependencies on anything beside a JRE >= 1.5. It has an OSGi manifest so it should be a one click action to deploy using tycho for those you are sufficiently familiar with Maven/Tycho, which I'm not. Of course, if generally publishing Eclipse SDK bundles as maven artifacts is making progress this might actually be a no-op, since the bundle is already available from the I-Build p2 site and soon from the Milestones p2 site. BTW: My attempts to comment on the blog forced me into creating a new blog account which I certainly don't want, so I moved to a medium I have access to :) @Deepak, maybe you can link from your blog to this bug?
(In reply to comment #0) > Of course, if generally publishing Eclipse SDK bundles as maven artifacts is > making progress this might actually be a no-op, since the bundle is already > available from the I-Build p2 site and soon from the Milestones p2 site. I also thought that the jar is available as part of Eclipse SDK and that should be enough, hence kept quiet so far. > BTW: My attempts to comment on the blog forced me into creating a new blog > account which I certainly don't want, so I moved to a medium I have access to > :) All you need is a Google account (or an OpenID), don't you have one? > @Deepak, maybe you can link from your blog to this bug? Sure, I will do this.
(In reply to comment #1) > I also thought that the jar is available as part of Eclipse SDK and that should > be enough, hence kept quiet so far. Sure, ideally everything inside the Eclipse SDK should automatically be available via Maven, too. I must admit I simply lost track of where we are in this regard. I'm sure one of Aaron, Alex, David will enlighten us :)
(In reply to comment #2) > Sure, ideally everything inside the Eclipse SDK should automatically be > available via Maven, too. I must admit I simply lost track of where we > are in this regard. > > I'm sure one of Aaron, Alex, David will enlighten us :) I'm tracking this in bug Bug 367126 - [maven.eclipse.org] Define process how to deploy official Eclipse releases
(In reply to comment #3) > I'm tracking this in bug Bug 367126 - [maven.eclipse.org] Define process how to > deploy official Eclipse releases Thanks, Aaron, for looking into this!
While the general solution seems to be hard(er than expected), would it be possible to just get the Juno version of the tiny org.eclipse.jdt.annotation bundle into maven.eclipse.org? I'm sure once Juno is released many folks wanting to use null annotations will ask for this! References: source: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/tree/org.eclipse.jdt.annotation binary: http://download.eclipse.org/eclipse/updates/4.2milestones/S-4.2RC4-201206081400/plugins/org.eclipse.jdt.annotation_1.0.0.v20120522-1651.jar (temporary link before the Juno release).
I'd like to "me too" on this one. I'm very interested in adding these annotations, but I'm not keen on building my own Maven artifact just for this. The whole Java world uses headless Maven builds, so I think it's really important that you have a small jar with just these compile-time libraries in the central repo if you want to encourage adoption. (I do think small is important here. A lot of us a large companies need to get approvals for every library, and there's no need to add a zillion new classes just so these annotations don't break our build.)
(In reply to comment #6) > (I do think small is important here. A lot of us a large companies need to get > approvals for every library, and there's no need to add a zillion new classes > just so these annotations don't break our build.) No need to worry about size: the bundle in its current shape (OSGi consumable jar) has a size of 14 kbyte incl. sources.
Count me in! There will be no widespread acceptance without supporting maven.
(In reply to comment #3) > I'm tracking this in bug Bug 367126 - [maven.eclipse.org] Define process how > to deploy official Eclipse releases Aaron, do you see a chance of a break-through in bug 367126 any time soon? Otherwise I'd ask for a one time exception for the tiny bundle org.eclipse.jdt.annotation. Perhaps Juno SR1 will be a good time for this (we made a small doc-fix in this bundle after Juno GA).
We should be able to do this. Can you generate a Maven POM which contains information about the build? This should include e.g. any viewvcs urls and the developer connection, as well as any dependencies listed. If you're not familiar with a POM then there is a reference here: http://maven.apache.org/pom.html
Created attachment 219706 [details] Converted bundle Here is the bundle converted with mt4e 0.14-SNAPSHOT (16.05.2012). Please have a look and let me know if it's OK (I don't know how to test it).
(In reply to comment #11) > Created attachment 219706 [details] > Converted bundle > > Here is the bundle converted with mt4e 0.14-SNAPSHOT (16.05.2012). Please > have a look and let me know if it's OK (I don't know how to test it). Great, works OK. I'll attach a test project FYI. It looks like you built the jar using the Juno release, right? The version from http://download.eclipse.org/eclipse/updates/4.2-M-builds/M20120809-1200/plugins/org.eclipse.jdt.annotation_1.0.0.v20120728-095341.jar has a small doc-fix and should be JDT's contribution to Juno SR1. So, if you could pick up that version, we'll be good and up-to-date until Kepler. (In reply to comment #10) > ... This should include e.g. any viewvcs urls and > the developer connection, as well as any dependencies listed. Dependencies: *NONE* :) viewvcs urls: can you derive the necessary declaration from http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/tree/org.eclipse.jdt.annotation ?
Created attachment 219748 [details] test project This project can be used to test the converted maven artifact. Essential effect: - Source code can reference org.eclipse.jdt.annotation.NonNull et al. Works OK. Ideally clients should express a compile-time-only dependency on org.eclipse.jdt.annotation (which only contains annotations with retention CLASS). I'm not sure if/how this can be achieved in a pom, any hints? Desired effect: - builds should signal two errors like this: Potential null pointer access: The variable dontcare may be null at this location Test.java /null.test/src/main/java/p line 7 Java Problem Null type mismatch: required '@NonNull String' but the provided value is null Test.java /null.test/src/main/java/p line 12 Java Problem Works OK in the IDE (where I'm using m2e and "M2E connector for the Eclipse JDT Compiler" provided by jboss). Ideally this should also be signalled during maven builds, but I haven't yet found a way to use the compiler settings from .settings/org.eclipse.jdt.core.prefs also during maven build. Does anyone happen to know if/how this is possible with the tycho-compiler-jdt plugin? So, the test project shows that the org.eclipse.jdt.annotation is good. The above questions are off-topic in this bug as they concern how this artifact can be consumed, not how it is provided.
(In reply to comment #13) > Ideally this should also be signalled during maven builds, but I haven't yet > found a way to use the compiler settings from > .settings/org.eclipse.jdt.core.prefs also during maven build. Does anyone > happen to know if/how this is possible with the tycho-compiler-jdt plugin? Answering my own question: the compiler plugin configuration should contain a compilerArgument like so: <plugin> <!-- Use compiler plugin with tycho as the adapter to the JDT compiler. --> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.6</source> <target>1.6</target> <compilerId>jdt</compilerId> <compilerArgument>-err:nullAnnot,null</compilerArgument> </configuration> ... </plugin> Now both compiler errors are correctly reported also during maven builds. Remains only this one: > Ideally clients should express a compile-time-only dependency on > org.eclipse.jdt.annotation (which only contains annotations with retention > CLASS). I'm not sure if/how this can be achieved in a pom, any hints?
(In reply to comment #11) > Created attachment 219706 [details] > Converted bundle > > Here is the bundle converted with mt4e 0.14-SNAPSHOT (16.05.2012). Please > have a look and let me know if it's OK (I don't know how to test it). As mentioned the converted bundle from comment 11 works fine. See comment 13 for a test project. The latest version is 1.0.0.v20120728-095341 (Juno SR1 RC1) which is currently available from http://download.eclipse.org/eclipse/updates/4.2-M-builds/M20120815-1200/plugins/org.eclipse.jdt.annotation_1.0.0.v20120728-095341.jar Since no more changes are planned in the Juno stream, I suggest you convert just once more using the above version and upload to maven.eclipse.org. TIA
Is this going to be fixed at any time in the near future? It's hard to tell. I'm trying to get my company to take up nullity analysis and the ability to use @NonNullByDefault would be very handy. I suppose that we could package the jar separately in our own repo...
Updated URL for the latest release (same file as mentioned in comment 15) is: http://download.eclipse.org/eclipse/updates/4.2/R-4.2.1-201209141800/plugins/org.eclipse.jdt.annotation_1.0.0.v20120728-095341.jar Using this for conversion and upload to maven.eclipse.org would be a real treat.
Created attachment 226069 [details] updated artifact matching Juno SR2 Am I riding a dead horse here? At comment 11 I thought the solution exists and just needs to be put in action. This is the smallest possible bundle. OK, for the upcoming Juno SR2 release I repackaged the annotation bundle using Aaron's version from comment 11 as a template, updating to 1.0.1 (we did have comment changes since Juno GA after all) and adding the copyright notice. I tested this artifact and all looks good to me. If s.o. else wants to give it a try, please find it in a temporary repo at http://build.eclipse.org/tools/objectteams/m2test Can we please just have this artifact on maven.eclipse.org? Thanks!
Created attachment 226070 [details] minimal test project And here's the minimal test project. 1. unzip 2. change into null.test/ 3. mvn clean compile Expected: ... Downloading: http://build.eclipse.org/tools/objectteams/m2test/org/eclipse/jdt/org.eclipse.jdt.annotation/1.0.1/org.eclipse.jdt.annotation-1.0.1.pom ... [ERROR] /tmp/test2/null.test/src/main/java/p/Test.java:[7,0] System.out.println(dontcare.toString()); ^^^^^^^^ Potential null pointer access: The variable dontcare may be null at this location [ERROR] /tmp/test2/null.test/src/main/java/p/Test.java:[12,0] String s = greet(null, null).toUpperCase(); ^^^^ Null type mismatch: required '@NonNull String' but the provided value is null ...
OK, I was obviously waiting for a dead horse, so let's try moving this old bug to a more lively space :)
Meanwhile the original project is of course fully set up with poms for CBI.
Ping, is anybody reading this?
David, I'm not sure this is the right place for this bug. Would it be better if it was moved to JDT? As far as I know it should be up to them if they want to publish this bundle onto repo.eclipse.org.
Yes, should be moved to JDT and be up to them. Though I'm sure they (and I :) would need your help to figure out "how to do it" (in the easiest possible way).
Moved to JDT inbox.
(In reply to David Williams from comment #24) > Yes, should be moved to JDT and be up to them. Though I'm sure they (and I > :) would need your help to figure out "how to do it" (in the easiest > possible way). I can certainly help with "how to do it" once we what specifically and where it should go is decided.
I would have published this bundle two years ago if I had access to any official Maven repo of Eclipse. So, what do you need in order to help us? In this context it would be interesting also to learn the process by which tycho plublishes the JDT compiler for its use.
The other obvious question, after all the changes in this area since the bug was initially filed: does it still make sense for JDT to publish one or two individual bundles, or is the Eclipse project about to publish all of the SDK into repo.eclipse.org any time soon? BTW, this seems to be the first bug which I filed against another component (because I'm unable [1] to fix it myself) and which returned to me saying, "just do it yourself". Let's see what other records this bug is able to set :) [1] unable in terms of: I don't have the permission to upload to the server and in terms of: I'm not authorized to decide the necessary naming conventions etc.
(In reply to Stephan Herrmann from comment #28) > The other obvious question, after all the changes in this area since the bug > was initially filed: does it still make sense for JDT to publish one or two > individual bundles, or is the Eclipse project about to publish all of the > SDK into repo.eclipse.org any time soon? > > > BTW, this seems to be the first bug which I filed against another component > (because I'm unable [1] to fix it myself) and which returned to me saying, > "just do it yourself". Let's see what other records this bug is able to set > :) > > > [1] unable in terms of: I don't have the permission to upload to the server > and in terms of: I'm not authorized to decide the necessary naming > conventions etc. Hi Stephan, sorry I had not realized you were from the JDT team. There is instructions on how a project could publish artifacts to repo.eclipse.org on the wiki here [1]. You should already have access to deploy, but you will need a Hudson job defined somewhere in order to proceed. In the wiki I've documented 2 methods of deploying artifacts to Hudson. 1. Deploying all artifacts as part of a build. 2. Deploying a single jar using a hudson job. The path is tied to your artifact's pom's GAV (Group, Artifact, Version) entries. So all the poms in JDT already have this detail, unless you want to change it of course. As for where it should be deployed, the platform project has 3 repos to choose from. eclipse-releases eclipse-staging eclipse-snapshots Unfortunately the way that Eclipse defines pom files everything artifact in the platform project today is a -SNAPSHOT version so by default all your artifacts would be deployed to the eclipse-snapshots repo. We'd have to discuss what the right thing to do is in this case. The Maven way is to make them releases by removing the -SNAPSHOT from the pom version field but I believe that doesn't apply here. If I recall I think for the JDT Compiler we've been forcing a version and pushing it to eclipse-staging repo. [1] http://wiki.eclipse.org/Services/Nexus
(In reply to Thanh Ha from comment #29) > (In reply to Stephan Herrmann from comment #28) > > If I recall I think for the JDT Compiler we've been forcing a version and > pushing it to eclipse-staging repo. > > [1] http://wiki.eclipse.org/Services/Nexus Yes, the compiler case is described (a little more) on this wiki page: http://wiki.eclipse.org/Platform-releng/Automated_Platform_Build#JDT_Compiler But it is "special" repo that we update every milestone, but then eventually delete old ones from ... we have yet to work out where to put "released" versions, if we ever do.
(In reply to Stephan Herrmann from comment #28) > ... or is the Eclipse project about to publish all of the > SDK into repo.eclipse.org any time soon? > This seems pretty unlikely. We have very few bundles that are (or could be) "pure maven" bundles. At least, that's what I read from the hundreds of warnings we get in the log: [WARNING] Dependency from /opt/public/eclipse/builds/4I/gitCache/eclipse.platform.releng.aggregator/eclipse.jdt/org.eclipse.jdt to nested classpath entry /opt/public/eclipse/builds/4I/gitCache/eclipse.platform.releng.aggregator/eclipse.platform.ui/bundles/org.eclipse.ui.workbench/e4-workbench.jar can not be represented in Maven model and will not be visible to non-OSGi aware Maven plugins But, suspect others know more on this topic than I do. But its not something "we" have planned for.
(In reply to David Williams from comment #30) > (In reply to Thanh Ha from comment #29) > > (In reply to Stephan Herrmann from comment #28) > > Yes, the compiler case is described (a little more) on this wiki page: > http://wiki.eclipse.org/Platform-releng/Automated_Platform_Build#JDT_Compiler > > But it is "special" repo that we update every milestone, but then eventually > delete old ones from ... we have yet to work out where to put "released" > versions, if we ever do. To be more explicit ... I'd be happy to include "your?" annotation bundle along with the compiler, but get the impression you are more interested in publishing the "released" version ... and "eclipse-staging" isn't the place for that.
Thanks to both for your explanations. Unfortunately the wiki currently answers: > The wiki is down for an upgrade, please check back later When it will be back, I'll be gone for vacations :) But I think when I'm back I can take it one or two steps further, since luckily the annotation bundle has *no* dependencies beyond the jre :) I suspect that other projects pushing artifacts to the repo would like to see platform bundles in the same repo, at least things like equinox, runtime, resources. Xtext is a likely example for pulling eclipse bundles into non-osgi products. That's why I thought I could maybe just piggyback on s.t. bigger :) So for this bug the only open question would be: how can we publish into "releases"? (yes, releases is what I would like to target).
(In reply to Stephan Herrmann from comment #33) > So for this bug the only open question would be: how can we publish into > "releases"? (yes, releases is what I would like to target). To release into "releases" it must be a non-snapshot build, but unfortunately as designed with the platform poms. All artifacts are SNAPSHOT builds. I think what you would have to do in this case is take one of the already built jars (the one you want to deploy), and make a custom job deploying via the single jar upload method. With this method you could create a custom pom.xml for deploying the jar which makes it a specific release without the -SNAPSHOT suffix.
During ECE 2013, I ran into some users interested in trying out null annotations, but were citing this as the impediment.
> some users interested in trying out null annotations, but were citing this as the impediment. That would have been me ;) - nice talking to you on the train back from ECE.
Stephan, I think we discussed at EclipseCon regarding this bug. Which version of org.eclipse.jdt.annotation would you like released into repo.eclipse.org? I'll try to find some time to look into a way for you to do this easily.
Hi Thanh, thanks for your offer and sorry I got diverted by ongoing bug-chase :) The following version is released and ready to go into maven as a release: org.eclipse.jdt.annotation_1.1.0.v20140129-1625 (corresponds to Kepler SR2) During ECNA we worked on the 2.0 stream (which needs BREE 1.8). While I don't expect any changes between now and Luna GA, it might be best to - practice snapshot releases now (to check the 1.8 issues) - wait until Luna GA before doing a maven release also here Note that we have split versions into different projects in git: 1.1.x is in http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/tree/org.eclipse.jdt.annotation_v1 2.0.x is in http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/tree/org.eclipse.jdt.annotation
(In reply to Stephan Herrmann from comment #38) Hi Stephan, I pushed the bundle org.eclipse.jdt.annotation_1.1.0.v20140129-1625 to repo.eclipse.org and created a job here: https://hudson.eclipse.org/platform/job/deploy-jdt-annotation/ So far I've only released it to the eclipse-staging URL so we can test it. Once a final release is done and everyone is happy we should release it to eclipse-releases URL instead. The build is parameterized so it will ask you for the required parameters it needs when you try to run it manually. The only steps you need to do prior to running the job is copy the jar you would like to release to /shared/eclipse/jdtstaging/annotation and modify the pom.xml file in that directory to update the version you would like to release.
(In reply to Thanh Ha from comment #39) Thanks Thanh, looks smooth and easy ... > The only steps you need to do prior to running the job is copy the jar you > would like to release to /shared/eclipse/jdtstaging/annotation and modify > the pom.xml file in that directory to update the version you would like to > release. Could you please make that directory writable for a group that I'm member of? $ groups common signers callisto-dev tools.objectteams eclipse.jdt.core eclipsecla So, eclipse.jdt.core would be the canonical choice, I guess :) Also I don't yet have an account on that Hudson instance. Can you make me one?
(In reply to Stephan Herrmann from comment #40) > (In reply to Thanh Ha from comment #39) > > The only steps you need to do prior to running the job is copy the jar you > > would like to release to /shared/eclipse/jdtstaging/annotation and modify > > the pom.xml file in that directory to update the version you would like to > > release. > > Could you please make that directory writable for a group that I'm member of? > Fixed. > Also I don't yet have an account on that Hudson instance. Can you make me > one? You do have an account actually, however you need to login using your _email_ address though and your Eclipse.org password.
Thanks Thanh! I have uploaded also the 2.0.0 version to eclipse-staging, and sanity-checked both versions. From my p.o.v. all looks great. For posterity I will attach the two test projects that I used (variants of attachment 226070 [details]) The two jars are bitwise identical with the content of 4.4 RC4 and these two files will surely not change between now and 4.4 GA. Thanh, any objections to uploading to eclipse-releases at this point?
Created attachment 244253 [details] Test project for annotation_1.1.0 This prj tests o.e.j.annotation_1.1.0 with compliance 1.6 Running $ mvn clean verify should produce these two compile errors: [ERROR] /home/stephan/jdt/m2/null.test/src/main/java/p/Test.java:[7] System.out.println(dontcare.toString()); ^^^^^^^^ Potential null pointer access: The variable dontcare may be null at this location [ERROR] /home/stephan/jdt/m2/null.test/src/main/java/p/Test.java:[12] String s = greet(null, null).toUpperCase(); ^^^^ Null type mismatch: required '@NonNull String' but the provided value is null 2 problems (2 errors) These errors signal that null checking successfully used the annotations.
Created attachment 244254 [details] Test project for annotation_2.0.0 This prj tests o.e.j.annotation_2.0.0 with compliance 1.8 Running $ mvn clean verify should produce these two compile errors: [ERROR] /home/stephan/jdt/m2/null.test.1.8/src/main/java/p/Test.java:[8] System.out.println(dontcare.get(0).toString()); ^^^^^^^^^^^^^^^ Potential null pointer access: The method get(int) may return null [ERROR] /home/stephan/jdt/m2/null.test.1.8/src/main/java/p/Test.java:[9] other(dontcare); ^^^^^^^^ Null type mismatch (type annotations): required 'List<@NonNull Object>' but this expression has type 'List<@Nullable Object>' 2 problems (2 errors) These errors signal that null checking successfully used the type annotations. (pom requires tycho 0.21.0-SNAPSHOT for compiling Java 8, hence I had to specify the repo where this version of tycho can be obtained).
Please don't forget about this bug. I can't really make a stable release of my project unless it builds out-of-the-box for people with Maven, and since my code is using the 2.0 annotations, this will eventually become a blocker for me :( Will the annotations bundle make it into the Maven Central repo, or will I have to add <repository><id>repo.eclipse.org</id><name>Project Repository - Releases</name><url>https://repo.eclipse.org/content/repositories/project-releases/</url></repository> to my POM? If everyone in the world using these annotations adds the Eclipse repo to their POM, won't it then get checked for all kinds of other artifacts referenced by people's builds as well?
(In reply to Chris Hubick from comment #45) > Will the annotations bundle make it into the Maven Central repo Actually, can you please ensure it does make it in to Central. As per http://maven.apache.org/guides/mini/guide-central-repository-upload.html > Only releases can be uploaded to the central repository, > that means files that won't change and that only depend > on other files already released and available in the repository. So, unless these annotations get into Central, I think that means that no project using them can make it into Central, which might be a deal-breaker for a lot of people :(
Sorry, the final upload got forgotten between the release craze and vacations... Today I have uploaded both release versions (1.1.0 & 2.0.0) of the annotation bundle to https://repo.eclipse.org/content/repositories/eclipse-releases/ I also filed bug 440501 for removal of the previous upload to eclipse-staging. This is all I can do -> closing. PS: I think for consumption of eclipse artifacts it's fair to add a repository section pointing to eclipse-releases (what else would be the purpose of this repo?). Maven Central is beyond my reach and if folks believe that eclipse artifacts should be uploaded there rather than to repo.eclipse.org this should definitely happen in an organized fashion ...
PPS: I just noticed that eclipse-releases is also accessible as https://repo.eclipse.org/content/repositories/eclipse I assume this shorter form is the recommended URL, right?
I believe when ever any of bundles end up in maven central, it is always "someone else" that does it ... not Eclipse committers nor the Eclipse Foundation ... using what ever process they use at Maven Central. [I'm guessing you are right about the URL, Stephan, but the short form might give you "staged" versions too? (that is, not released ones? ... if there ever is one) ... but Thanh can answer that better than I].
Ideally, a big organization like Eclipse would use the Nexus Smart Proxy component of Nexus pro to sync their repo to Central: http://central.sonatype.org/pages/producers.html http://central.sonatype.org/pages/central-sync-with-nexus-smart-proxy.html I could find Bug 365798 with some talk about that kind of thing, but no outcome. Forgetting that, there are instructions for uploading a one-off artifact bundle at https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+The+Central+Repository but those state that the requirements outlined in https://docs.sonatype.org/display/Repository/Central+Sync+Requirements must be met. In that direction, would it be possible to get annotation -source.jar and -javadoc.jar artifacts published as part of this bug as well? There are also a number of elements a project POM should have, but the annotation POM being published is empty aside from the minimal auto-generated fields :( And I'm not really sure about Central's .asc signing requirement versus the .md5 and .sha1 files being provided here? If those issues can be addressed, then perhaps a bundle could be created to file in the OSS Nexus JIRA for them to upload to the Central repo.
1. I've prepared and successfully uploaded annotation v1 to Maven Central. V2 is uploaded and pending. Hopefully, will be in Maven Central soon! 2. I had to turn Java8 javadoc's lint off, due to a javadoc error in DefaultLocation.java - it's not well formed. It would be nice if it could be fixed. This is not strictly required - the lint-off switch is in the pom, so it'll compile okay if someone wanted to deal with the source. Ideally, Eclipse guys could just use my pom and re-sign it with their PGP signature. And here is the link for v1 on Maven Central: http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22org.eclipse.jdt.annotation%22 Cheers, David PS: I gave all proper attributions in these artifacts to Eclipse, based on what I could find in the original manifest and copyright.
(In reply to David Tesler from comment #51) > 1. I've prepared and successfully uploaded annotation v1 to Maven Central. Thanks! From scanning pom and jar: the original jar has source and target set to 1.5, the upload to central uses 1.6. Was this done on purpose? Users wishing to use the annotations in a 1.5 project (if any) will not be able to use the version from Maven central. The tag/commit referenced in the pom don't exactly match the released version in repo.eclipse.org, but there are no changes in that range which affect the annotation bundle, so this should not cause any trouble. In fact, I couldn't easily see how the qualifier in our released versions were generated, but the preferred way of referencing the sources would be to use the release tags like R4_3_2 and R4_4. Other than that the upload looks good.
(In reply to David Tesler from comment #51) > 2. I had to turn Java8 javadoc's lint off, due to a javadoc error in > DefaultLocation.java - it's not well formed. It would be nice if it could be > fixed. This is not strictly required - the lint-off switch is in the pom, so > it'll compile okay if someone wanted to deal with the source. You should open a new/separate bug on the JavaDoc error you were seeing, with complete details (including a patch on how you fixed ... in general it is bad form for us to "take a fix" we get from anywhere other than bugzilla ... you know, just for traceability, and I'm sure other legal reasons).
(In reply to David Tesler from comment #51) > 2. I had to turn Java8 javadoc's lint off, due to a javadoc error in > DefaultLocation.java - it's not well formed. It would be nice if it could be > fixed. This is not strictly required - the lint-off switch is in the pom, so > it'll compile okay if someone wanted to deal with the source. fixed via http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=ce0574029788b33026db9472a710468c9674b11f
(In reply to Stephan Herrmann from comment #52) > (In reply to David Tesler from comment #51) > > 1. I've prepared and successfully uploaded annotation v1 to Maven Central. > > Thanks! > > From scanning pom and jar: the original jar has source and target set to > 1.5, the upload to central uses 1.6. Was this done on purpose? > Users wishing to use the annotations in a 1.5 project (if any) will not be > able to use the version from Maven central. > > The tag/commit referenced in the pom don't exactly match the released > version in repo.eclipse.org, but there are no changes in that range which > affect the annotation bundle, so this should not cause any trouble. > In fact, I couldn't easily see how the qualifier in our released versions > were generated, but the preferred way of referencing the sources would be to > use the release tags like R4_3_2 and R4_4. > > Other than that the upload looks good. Stephan, I've downloaded the original bundle/jar from eclipse-releases repo, copied sources , looked at manifest, and repackaged this stuff into a proper Maven pom project; then issued mvn install command to make it into signed Maven artifact in my local Maven repo; then took all the files there, created a jar, and uploaded it as a third-party bundle to Sonatype Snapshots, which later had been promoted to the Maven Central itself. The scm info taken as-is from the original bundle manifest. I thought the Java 5 is not supported anymore; in addition, Java 5 would create package-info.class, contrary to the Java 6 and later behavior (it's not compiled if there are no runtime annotations in the java source). Also, any change in Maven Central will require to incrementing the artifact version, e.g. from 1.1.0 to 1.1.1, and as I am a third party in this, this would only be possible, if you were incrementing the original version this way. BTW, the version part in the original after 1.1.0 is used in OSGI bundle, but not in Maven, and not valid in Maven Central, so I had to discard it. As you see, the situation is not ideal to have a third-party uploading your stuff to Maven Central, I've done this out of desperation and frustration - this is a very important Eclipse technology, made totally useless for Eclipse Maven users by the lack of these annotations in Maven Central. So I am joining the other customers of yours and beg you to reconsider and take ownership of this project in regards to Maven Central availability. 2. The fix in v2 will have to have an incremented version, 2.0.1, in order for me to upload it to Central, as in for v1.
David, Please don't take my nitpicking as criticism of your efforts, your help is much appreciated! I'm implementing annotation based null analysis in my spare time because I feel here I have the required skills for contributing s.t. of value to the community. I don't have good skills in anything Maven, or, rather: I have good skills of breaking each and every Maven plugin in totally erratic ways and wasting entire days on achieving trivial results. This is decidedly not the way to make proper use of my spare time. I've been suggesting that the Eclipse project as such takes more responsibility towards coordinated publishing of maven artefacts, but according to bug 441530 comment 16 this is not the direction taken by the Eclipse PMC (not even for repo.eclipse.org). That's why people like you, who have the skills for this, are important as to step in and fill the gaps. Thanks! Back to bugfixing...
(In reply to David Tesler from comment #51) > 1. I've prepared and successfully uploaded annotation v1 to Maven Central. > V2 is uploaded and pending. Hopefully, will be in Maven Central soon! It's in: http://search.maven.org/#artifactdetails|org.eclipse.jdt|org.eclipse.jdt.annotation|2.0.0|jar Much Thanks David! :)
For posterity: since bug 484004 we are now publishing directly to maven central, so nothing of what was done in this bug should be needed any more, and I will suggest deleting the corresponding hudson job "deploy-jdt-annotation".
