Re: Missing javax.servlet:jstl:1.2
The old jstl 1.2 in central was wrong, so I deleted it and get help from Oracle to deploy a correct version. more info here: https://issues.sonatype.org/browse/MVNCENTRAL-71 On Tue, Jun 21, 2011 at 1:42 AM, Mark Struberg strub...@yahoo.de wrote: actually I think javax.jstl NEVER have been on maven.central. It originally was hosted on java.net, but they killed parts of their maven repo while migrating from sun to oracle. There is of course an ALv2 version of jstl: http://repo1.maven.org/maven2/org/apache/geronimo/bundles/jstl/1.2_1/ LieGrue, strub --- On Mon, 6/20/11, Anders Hammar and...@hammar.net wrote: From: Anders Hammar and...@hammar.net Subject: Re: Missing javax.servlet:jstl:1.2 To: Maven Developers List dev@maven.apache.org Date: Monday, June 20, 2011, 5:26 PM I though artifacts were supposed to never change at central... This could break people's builds. /Anders On Mon, Jun 20, 2011 at 19:00, Paul Gier pg...@redhat.com wrote: It seems that the artifacts were moved to a different location: https://issues.sonatype.org/browse/MVNCENTRAL-71 On 06/20/2011 10:41 AM, Paul Gier wrote: The artifacts for javax.servlet:jstl:1.2 seem to have disappeared from central [1]. They still appear in the Sonatype search [2]. Does anyone know what happened to these files? Were they removed because of a bad license or something? [1]http://repo1.maven.org/maven2/javax/servlet/jstl/ [2] http://search.maven.org/#search|gav|1|g%3A%22javax.servlet%22%20AND%20a%3A%22jstl%22 http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22javax.servlet%22%20AND%20a%3A%22jstl%22 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Recommended procedure for fixing hash file syntax
I think people can create tasks here: http://jira.codehaus.org/browse/MAVENUPLOAD or at Sonatype: https://issues.sonatype.org/browse/OSSRH On Thu, Apr 29, 2010 at 4:12 PM, sebb seb...@gmail.com wrote: OK thanks very much. If this problem recurs with other projects, is there a formal means of reporting it? e.g. via an issue tracker? On 29/04/2010, Juven Xu ju...@sonatype.com wrote: checksums on pgp signautes are deleted. On Wed, Apr 28, 2010 at 11:34 PM, sebb seb...@gmail.com wrote: On 28/04/2010, Juven Xu ju...@sonatype.com wrote: On Wed, Apr 28, 2010 at 11:05 PM, sebb seb...@gmail.com wrote: On 28/04/2010, Juven Xu ju...@sonatype.com wrote: you can use these shell scripts: find . -type f | xargs -i sh -c 'sha1sum {} | cut -d -f1 {}.sha1' find . -type f | xargs -i sh -c 'md5sum {} | cut -d -f1 {}.md5' Thanks, I have already created the fixed hashes. [BTW, the find command above needs to be changed, otherwise it will create md5 hashes for the sha1 hashes it has just created. Also, not all versions of xargs support the -i flag. Nor are sha1sum and md5sum universally available.] yes, assume xargs -i , sha1sum, md5sum is supported: find . -type f | grep -e 'md5$' -e 'sha1$' -v | xargs -i sh -c 'sha1sum {} | cut -d -f1 {}.sha1' Which will still create hashes for .asc files... release artifacts and their hashes in central will never be updated unless manual fix is needed. So how does the Nexus solution work if manual intervention is required? It's central, has nothing to do with Nexus, currently I will fix any central artifacts problem if your artifacts' hashes in central are incorrect, tell me what are them so I can fix. The problem is with commons-compress-1.0: http://repo1.maven.org/maven2/org/apache/commons/commons-compress/1.0/ e.g. commons-compress-1.0-bin.tar.gz.md5: commons-compress-1.0-bin.tar.gz: F8 F0 2E 1E AC 08 37 7D 75 14 CB 94 87 AF E2 C9 All the other hashes have the wrong syntax too. fixed Thanks, but you have also created unnecessary hashes for the .asc files. Please can those be deleted? On Wed, Apr 28, 2010 at 10:12 PM, sebb seb...@gmail.com wrote: On 26/04/2010, sebb seb...@gmail.com wrote: What is the recommended procedure for fixing hash files in a Maven repo that have the wrong syntax? I have seen the reply about using Nexus, but if the project does not use Nexus, what is the procedure? If I update the hashes in the release repo will these be propagated to the central repo? And is that procedure permitted by the central repo rules? For example: file.tar.gz.sha1: file.tar.gz: B886 07FA D17D 06C2 7D67 01D6 E7E6 56BB 52F3 3B4C The hash is correct, but not all tools can process the hash when it is split over two lines and has spaces in the hex string. Any advice on how best to fix this? Can I just replace the hash files in the Apache release repository with the fixed versions? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- - juven - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- - juven - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- - juven - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- - juven
Re: Recommended procedure for fixing hash file syntax
you can use these shell scripts: find . -type f | xargs -i sh -c 'sha1sum {} | cut -d -f1 {}.sha1' find . -type f | xargs -i sh -c 'md5sum {} | cut -d -f1 {}.md5' release artifacts and their hashes in central will never be updated unless manual fix is needed if your artifacts' hashes in central are incorrect, tell me what are them so I can fix. On Wed, Apr 28, 2010 at 10:12 PM, sebb seb...@gmail.com wrote: On 26/04/2010, sebb seb...@gmail.com wrote: What is the recommended procedure for fixing hash files in a Maven repo that have the wrong syntax? I have seen the reply about using Nexus, but if the project does not use Nexus, what is the procedure? If I update the hashes in the release repo will these be propagated to the central repo? And is that procedure permitted by the central repo rules? For example: file.tar.gz.sha1: file.tar.gz: B886 07FA D17D 06C2 7D67 01D6 E7E6 56BB 52F3 3B4C The hash is correct, but not all tools can process the hash when it is split over two lines and has spaces in the hex string. Any advice on how best to fix this? Can I just replace the hash files in the Apache release repository with the fixed versions? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- - juven
Re: Recommended procedure for fixing hash file syntax
On Wed, Apr 28, 2010 at 11:05 PM, sebb seb...@gmail.com wrote: On 28/04/2010, Juven Xu ju...@sonatype.com wrote: you can use these shell scripts: find . -type f | xargs -i sh -c 'sha1sum {} | cut -d -f1 {}.sha1' find . -type f | xargs -i sh -c 'md5sum {} | cut -d -f1 {}.md5' Thanks, I have already created the fixed hashes. [BTW, the find command above needs to be changed, otherwise it will create md5 hashes for the sha1 hashes it has just created. Also, not all versions of xargs support the -i flag. Nor are sha1sum and md5sum universally available.] yes, assume xargs -i , sha1sum, md5sum is supported: find . -type f | grep -e 'md5$' -e 'sha1$' -v | xargs -i sh -c 'sha1sum {} | cut -d -f1 {}.sha1' release artifacts and their hashes in central will never be updated unless manual fix is needed. So how does the Nexus solution work if manual intervention is required? It's central, has nothing to do with Nexus, currently I will fix any central artifacts problem if your artifacts' hashes in central are incorrect, tell me what are them so I can fix. The problem is with commons-compress-1.0: http://repo1.maven.org/maven2/org/apache/commons/commons-compress/1.0/ e.g. commons-compress-1.0-bin.tar.gz.md5: commons-compress-1.0-bin.tar.gz: F8 F0 2E 1E AC 08 37 7D 75 14 CB 94 87 AF E2 C9 All the other hashes have the wrong syntax too. fixed On Wed, Apr 28, 2010 at 10:12 PM, sebb seb...@gmail.com wrote: On 26/04/2010, sebb seb...@gmail.com wrote: What is the recommended procedure for fixing hash files in a Maven repo that have the wrong syntax? I have seen the reply about using Nexus, but if the project does not use Nexus, what is the procedure? If I update the hashes in the release repo will these be propagated to the central repo? And is that procedure permitted by the central repo rules? For example: file.tar.gz.sha1: file.tar.gz: B886 07FA D17D 06C2 7D67 01D6 E7E6 56BB 52F3 3B4C The hash is correct, but not all tools can process the hash when it is split over two lines and has spaces in the hex string. Any advice on how best to fix this? Can I just replace the hash files in the Apache release repository with the fixed versions? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- - juven - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- - juven
Re: Recommended procedure for fixing hash file syntax
checksums on pgp signautes are deleted. On Wed, Apr 28, 2010 at 11:34 PM, sebb seb...@gmail.com wrote: On 28/04/2010, Juven Xu ju...@sonatype.com wrote: On Wed, Apr 28, 2010 at 11:05 PM, sebb seb...@gmail.com wrote: On 28/04/2010, Juven Xu ju...@sonatype.com wrote: you can use these shell scripts: find . -type f | xargs -i sh -c 'sha1sum {} | cut -d -f1 {}.sha1' find . -type f | xargs -i sh -c 'md5sum {} | cut -d -f1 {}.md5' Thanks, I have already created the fixed hashes. [BTW, the find command above needs to be changed, otherwise it will create md5 hashes for the sha1 hashes it has just created. Also, not all versions of xargs support the -i flag. Nor are sha1sum and md5sum universally available.] yes, assume xargs -i , sha1sum, md5sum is supported: find . -type f | grep -e 'md5$' -e 'sha1$' -v | xargs -i sh -c 'sha1sum {} | cut -d -f1 {}.sha1' Which will still create hashes for .asc files... release artifacts and their hashes in central will never be updated unless manual fix is needed. So how does the Nexus solution work if manual intervention is required? It's central, has nothing to do with Nexus, currently I will fix any central artifacts problem if your artifacts' hashes in central are incorrect, tell me what are them so I can fix. The problem is with commons-compress-1.0: http://repo1.maven.org/maven2/org/apache/commons/commons-compress/1.0/ e.g. commons-compress-1.0-bin.tar.gz.md5: commons-compress-1.0-bin.tar.gz: F8 F0 2E 1E AC 08 37 7D 75 14 CB 94 87 AF E2 C9 All the other hashes have the wrong syntax too. fixed Thanks, but you have also created unnecessary hashes for the .asc files. Please can those be deleted? On Wed, Apr 28, 2010 at 10:12 PM, sebb seb...@gmail.com wrote: On 26/04/2010, sebb seb...@gmail.com wrote: What is the recommended procedure for fixing hash files in a Maven repo that have the wrong syntax? I have seen the reply about using Nexus, but if the project does not use Nexus, what is the procedure? If I update the hashes in the release repo will these be propagated to the central repo? And is that procedure permitted by the central repo rules? For example: file.tar.gz.sha1: file.tar.gz: B886 07FA D17D 06C2 7D67 01D6 E7E6 56BB 52F3 3B4C The hash is correct, but not all tools can process the hash when it is split over two lines and has spaces in the hex string. Any advice on how best to fix this? Can I just replace the hash files in the Apache release repository with the fixed versions? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- - juven - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- - juven - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- - juven
Re: maven-archetype-plugin 2.0-beta-5 and Central
I just created a cli tool using code from nexus-archetype-plugin, and updated the central archetype catalog with latest central index The nexus-archetype-plugin is open sourced: http://scm.sonatype.org/repobrowser.svn?path=/trunk/revision=HEADname=Nexus-plugins I will clean up the cli code and publish it. On Mon, Mar 29, 2010 at 12:28 AM, Jason van Zyl ja...@sonatype.com wrote: We already have all the code because this is what we integrated into the Maven Shell. I'll find all the pointers and send them to you. On Mar 28, 2010, at 9:00 AM, Hervé BOUTEMY wrote: Le dimanche 28 mars 2010, Jason van Zyl a écrit : Question: how to update it? Run crawl Mojo against Central once a day, for example? No, there will be no scanning of Maven Central. The best thing is to use the Nexus index like we do in M2Eclipse. Everything required is in the index and you can just make a Nexus index source which is far more efficient. Scanning just kills the performance of the machine and there aren't many windows of time anymore where Central isn't heavily used. Scanning simply isn't required anyway with the index. yes, far better approach for Central. I found Nexus Archetype Plugin code [1], with everything needed, thank you for the tip. Now the question is: where to add code, and how to add catalog generation after central index creation? Is there an extension point in repository-tools? Regards, Hervé [1] http://svn.sonatype.org/nexus-plugins/trunk/nexus-archetype- plugin/src/main/java/org/sonatype/nexus/plugins/mac/DefaultMacPlugin.java [2] http://svn.apache.org/viewvc/maven/repository-tools/trunk/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- -- - juven
Re: repository.apache.org, gpg signatures and site:attach-descriptor
What I saw is some of those staged artifacts were missing signatures. Nexus works correctly, it only complained the missing ones, not all. On Wed, Jan 13, 2010 at 2:32 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: 2010/1/13 Brian Fox bri...@infinity.nu: We should definitely fix this, both in the GPG and in Nexus. Currently it expects all files to be signed and this is the first one we've come across that wasn't signed. I'll disable the rule now until it's sorted out and close the repo for you. Stephen, what ended up being the fix for the rest of the sigs? This morning it was complaining about all the sigs. I'm not sure, you'd need to ask Juven. On Tue, Jan 12, 2010 at 5:53 PM, Wendy Smoak wsm...@gmail.com wrote: On Tue, Jan 12, 2010 at 9:43 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: For some reason the site descriptor does not get a signature generated by the gpg plugin. As r.a.o now requires all artifacts to be signed, it would appear to be impossible to close a staged repository. If it's going in the repo, I'd like to see it signed... but this hasn't been happening up to now, so it probably shouldn't block this release. The archetype catalog is another file that may be a problem, I noticed it wasn't signed in a recent Struts release. Is the list of files that require a signature configurable? -- Wendy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- - juven