I also hope that latest Findbugs will be deployed onto Maven central.
And I guess that you can use following commands to deploy jar files. See Sonatype wiki for detail.
I'm getting the following error: [dhcp322:~/Documents/findbugs-git] pugh% mvn release:prepare [INFO] Scanning for projects... [ERROR] The build could not read 1 project -> [Help 1] [ERROR] [ERROR] The project com.google.code.findbugs:findbugs-project:2.0.3-SNAPSHOT (/Users/pugh/Documents/findbugs-git/pom.xml) has 1 error [ERROR] Child module /Users/pugh/Documents/findbugs-git/findbugs-package of /Users/pugh/Documents/findbugs-git/pom.xml does not exist [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR][Help 1]http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oh, it looks pom.xml is invalid at this commit. Sorry I didn't check it.
And I found a test failure in my PC. I think maven-release-plugin is not good way to deploy.
java.lang.IllegalStateException: Invalid method signature: '(!*)V' : !*)V
at edu.umd.cs.findbugs.ba.generic.GenericSignatureParser$ParameterSignatureIterator.next(GenericSignatureParser.java:115)
at edu.umd.cs.findbugs.ba.generic.GenericSignatureParser$ParameterSignatureIterator.next(GenericSignatureParser.java:45)
at edu.umd.cs.findbugs.ba.generic.GenericUtilities.getTypeParameters(GenericUtilities.java:401)
At least Garvin LeClaire can deploy them, because he has permission to deploy.
You and I are also possible but we need to get permission from Sonatype. I will try to get.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
as you release your software outside the maven cycle, release:prepare and release:perform require additional steps to work. Easiest would be to use direct artifact deployment using the maven deploy plugin, because you already have generated the artifacts.
A few notes:
to upload to oss.sonatype.org, you need to have an account there and the permission to push to that upload group. Once you have the necessary credentials, everything that was uploaded there will be mirrored to central automatically. See https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide for details on how to do that. In your case, they need to create a com.google.code.findbugs group and add you to it.
Yes, you can go ahead and deploy 2.0.3. I think I've getting the hang of it, but I think you have more experience with it and it is more likely to go correctly if you do it.
Do I need to deploy other artifacts under com.google.code.findbugs groupId? I mean that do bcel, jsr305, findbugs-ant, annotations and jformatString have version 2.0.3?
In pom.xml, findbugs depends on 2.0.1 of bcel, jsr305 and jformatString. So I guess that only findbugs-ant and annotations has version 2.0.3.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If JSR 305 and bcel are unchanged, can we deploy the same versions as 2.0.3? The problem is that a lot of code uses a ${dep.findbugs.version} property in their poms to refer to the various pieces of findbugs and now updating that version to 2.0.3 will break because e.g. jsr305 does not exist in that version.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If JSR 305 and bcel are unchanged, can we deploy the same versions as 2.0.3? The problem is that a lot of code uses a ${dep.findbugs.version} property in their poms to refer to the various pieces of findbugs and now updating that version to 2.0.3 will break because e.g. jsr305 does not exist in that version.
Hello Findbugs contributors,
I also hope that latest Findbugs will be deployed onto Maven central.
And I guess that you can use following commands to deploy jar files. See Sonatype wiki for detail.
Note that you need to generate a PGP signature to deploy jar files onto Sonatype repository.
If you have a release tag, you do not need to do a release:prepare or
perform. All you need to do is a "mvn deploy".
On Mon, Dec 9, 2013 at 6:34 AM, eller86 eller86@users.sf.net wrote:
Thanks for your help.
I'm getting the following error:
[dhcp322:~/Documents/findbugs-git] pugh% mvn release:prepare
[INFO] Scanning for projects...
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR] The project com.google.code.findbugs:findbugs-project:2.0.3-SNAPSHOT (/Users/pugh/Documents/findbugs-git/pom.xml) has 1 error
[ERROR] Child module /Users/pugh/Documents/findbugs-git/findbugs-package of /Users/pugh/Documents/findbugs-git/pom.xml does not exist
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
OK, I fixed this problem by doing it from within the findbugs subdirectory.
Now I'm having a problem with building the javadoc via maven.
I get this both when I run mvn release:prepare or mvn javadoc:javadoc
I've pushed release-2.0.3 to the repository if you want to try to examine the problem I'm getting.
Oh, it looks pom.xml is invalid at this commit. Sorry I didn't check it.
And I found a test failure in my PC. I think maven-release-plugin is not good way to deploy.
So it is better to try to deploy existed artifacts by maven-gpg-plugin including pom, jar, sources-jar and javadoc-jar.
At least Garvin LeClaire can deploy them, because he has permission to deploy.
You and I are also possible but we need to get permission from Sonatype. I will try to get.
Can you give me the corrected pom.xml file?
Hi William,
as you release your software outside the maven cycle, release:prepare and release:perform require additional steps to work. Easiest would be to use direct artifact deployment using the maven deploy plugin, because you already have generated the artifacts.
A few notes:
to upload to oss.sonatype.org, you need to have an account there and the permission to push to that upload group. Once you have the necessary credentials, everything that was uploaded there will be mirrored to central automatically. See https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide for details on how to do that. In your case, they need to create a com.google.code.findbugs group and add you to it.
for oss (and central), a gpg signature is required. There are instructions at https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven on how to do that.
Hi William,
I think pom.xml in master is OK because we fixed at #1229 and other commits, We can try release plugin from next release.
BTW, I got permission to deploy onto SonaType repo. Can I deploy 2.0.3?
Or you can try by yourself, I think hgschmie's guide is quite good and kind.
Yes, you can go ahead and deploy 2.0.3. I think I've getting the hang of it, but I think you have more experience with it and it is more likely to go correctly if you do it.
Bill
On Dec 14, 2013, at 1:58 AM, eller86 eller86@users.sf.net wrote:
Related
Bugs:
#1227I got, I will do it.
Do I need to deploy other artifacts under com.google.code.findbugs groupId? I mean that do
bcel,jsr305,findbugs-ant,annotationsandjformatStringhave version 2.0.3?In pom.xml, findbugs depends on 2.0.1 of
bcel,jsr305andjformatString. So I guess that onlyfindbugs-antandannotationshas version 2.0.3.please, please, please do not rip apart the versions for findbugs, findbugs-annotations and findbugs-jsr305. For all of the jars, there should be a 2.0.3 release on central. See http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22com.google.code.findbugs%22
I think we've managed to get 2.0.3 successfully deployed to maven. Thanks eller86. Do people concur that this item can be closed?
If JSR 305 and bcel are unchanged, can we deploy the same versions as 2.0.3? The problem is that a lot of code uses a ${dep.findbugs.version} property in their poms to refer to the various pieces of findbugs and now updating that version to 2.0.3 will break because e.g. jsr305 does not exist in that version.
jsr305 and bcel are unchanged.
I've reopened the ticket.
Bill
On Dec 16, 2013, at 12:56 PM, hgschmie hgschmie@users.sf.net wrote:
How do I reopen this ticket? I do not think that it is fixed yet.
findbugs:2.0.3 is now on central, but others are not yet. I will restart this task next week.
Hello ALL,
could you tell me where is source code of each library? They are necessary to deploy libraries to Maven Central via Sonatype repository. Current my understanding is below:
findbugs/src/antTaskdirectory in the same repositoryfindbugs/src/java/edu/umd/cs/findbugs/annotationsdirectory in the same repositoryThanks in advance,
Kengo
Looks like 2.0.3 is there:
http://mvnrepository.com/artifact/com.google.code.findbugs/findbugs/2.0.3