Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
Niclas Hedhman wrote: > You said; "libraries that are currently hosted on cvs.a.o", meaning they > exist > on cvs.a.o, and can't you just tell Maven in your pom to use that repository > as well?? > I meant : "libraries that are currently hosted on cvs.a.o AND that are not hosted on ibiblio AND that we are dependent on" > Join the [EMAIL PROTECTED] mailing for discussion and more info. IIUIC, the > http://cvs.apache.org/maven-snapshot-repository is meant for making snapshots > available cross-ASF projects. I'm already on it, i'll continue argueing my case over there :) Jorg
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
Niclas Hedhman wrote: You said; "libraries that are currently hosted on cvs.a.o", meaning they exist on cvs.a.o, and can't you just tell Maven in your pom to use that repository as well?? From what I can see the build is set up to do that. The builds fail because apparently that repository can't handle the load. That is why we need a mirrored server. Cheers Niclas
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
On Wednesday 22 March 2006 01:00, Jorg Heymans wrote: > Niclas Hedhman wrote: > >> What is being suggested is not that we mirror the whole of ibiblio, we > >> would only mirror the libraries that are currently hosted on cvs.a.o. > > > > ... You can point your pom to use the cvs.a.o directly. > > What do you mean here? You said; "libraries that are currently hosted on cvs.a.o", meaning they exist on cvs.a.o, and can't you just tell Maven in your pom to use that repository as well?? Join the [EMAIL PROTECTED] mailing for discussion and more info. IIUIC, the http://cvs.apache.org/maven-snapshot-repository is meant for making snapshots available cross-ASF projects. I still maintain that checking in the libs to SVN are much more comfortable than a dependency on a temporary server. Cheers Niclas
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
Niclas Hedhman wrote: If SNAPSHOTs are totally unavoidable, consider putting these in the Svn alongside the source code. Inability to build from today's source in the future is a serious flaw in chosen strategy. This is exactly what we do internally. ;-) Best Regards, Antonio Gallardo. Cheers Niclas
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
Pier Fumagalli wrote: On 20 Mar 2006, at 09:19, Andrew Savory wrote: Hi, Jorg Heymans wrote: If someone can offer the bandwidth and server, i'm willing to migrate us away from cvs.a.o. and setup a decent m2 repo where only *we* control the poms. Any offers? I've got some time to kill this weekend ;) We (Luminas/SourceSense) are offering. Do you know what sort of requirements in terms of bandwidth and server space? We have capacity to spare, and are happy to donate it. Excuse me, but can someone refresh my memory on why we went down the Maven way? I thought it was to get rid of maintaining all those "lib" in our SVN, and now someone is telling me that we actually should maintain a full maven mirror, but tweaked because we don't like theirs? Pier http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110571714621160 Is something better now? I guess not. :-( /me looking for xerces-2.8.0 commons-io 1.2, et al in the maven2 repos. Best Regards, Antonio Gallardo.
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
Niclas Hedhman wrote: >> What is being suggested is not that we mirror the whole of ibiblio, we >> would only mirror the libraries that are currently hosted on cvs.a.o. > > ... You can point your pom to use the cvs.a.o directly. What do you mean here? >> - the dependency is not available on the central m2 repo (the number of >> these libs is slowly declining due to better m2 acceptance) > > If it is not on the central repo, it is a non-released version and > questionable that anyone should depend on it. best practice #1 >> - the dependency is available, but has a dodgy pom making it difficult >> to benefit from m2 features (eg transitive dependencies). > > Since you will need to manually clean this up here, perhaps sending the file > over to the Maven peeps is collectively a better idea. best practice #2, we will do this ofcourse. >> - we're using a snapshot dependency that is not hosted anywhere else >> (remember the central repo only allows _released_ versions) > > IMHO, a questionable practice. (see below) indeed it is. >> Remember that this mirror would become only a *temporary* solution for >> any dependend library that has not fully mavenized yet. > > Now think again; After you have done this, and decommissioned the temporary > solution, you are in a position of a non-working slot in time for that > source. This goes both for SNAPSHOTs (which are actively being removed from > their temporary storage spaces) and temporary artifact hosts. I'll classify this as a "worry about it later". We haven't even released anything so this is no time to worry about 100% reproducible builds. I just want to make the maven build to reliably work using the quickest way possible. Anything that involves "send something to someone else and wait until..." is just not working for us at the moment. Regards Jorg
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
On Tuesday 21 March 2006 02:32, Jorg Heymans wrote: > What is being suggested is not that we mirror the whole of ibiblio, we > would only mirror the libraries that are currently hosted on cvs.a.o. This sounds like a really odd idea. You can point your pom to use the cvs.a.o directly. > - the dependency is not available on the central m2 repo (the number of > these libs is slowly declining due to better m2 acceptance) If it is not on the central repo, it is a non-released version and questionable that anyone should depend on it. > - the dependency is available, but has a dodgy pom making it difficult > to benefit from m2 features (eg transitive dependencies). Since you will need to manually clean this up here, perhaps sending the file over to the Maven peeps is collectively a better idea. > - we're using a snapshot dependency that is not hosted anywhere else > (remember the central repo only allows _released_ versions) IMHO, a questionable practice. (see below) > Remember that this mirror would become only a *temporary* solution for > any dependend library that has not fully mavenized yet. Now think again; After you have done this, and decommissioned the temporary solution, you are in a position of a non-working slot in time for that source. This goes both for SNAPSHOTs (which are actively being removed from their temporary storage spaces) and temporary artifact hosts. If SNAPSHOTs are totally unavoidable, consider putting these in the Svn alongside the source code. Inability to build from today's source in the future is a serious flaw in chosen strategy. Cheers Niclas
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
Andrew Savory wrote: > infrastructure problems are resolved. Actually, in hindsight, it makes > more sense to see what can be done to fix maven's repo infrastructure - > but I know nothing about ibiblio etc. and don't have time to investigate This is being worked on by maven and infra, but it's a slooow process. > right now, so it's easier for me to simply say "here's a machine with a > ton of bandwidth, let's use that for now". Yes that's the easiest and most rewarding way to go for now. Here is a list of dependencies that are currently pulled from cvs.a.o/repository or cvs.a.o/maven-snapshot-repository. I didn't have time to lookup and add sizes together but it doesn't look like more than 30-40MB .. (ignore the numbers, they're from subsequent maven runs) 1) jakarta-bcel:jakarta-bcel:jar:20040329 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) jakarta-bcel:jakarta-bcel:jar:20040329 2) org.apache.excalibur.components.store:excalibur-store:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.components.store:excalibur-store:jar:2.1 3) org.apache.avalon.framework:avalon-framework-impl:jar:4.3 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.avalon.framework:avalon-framework-impl:jar:4.3 4) org.apache.excalibur.components.sourceresolve:excalibur-sourceresolve:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.components.sourceresolve:excalibur-sourceresolve:jar:2.1 5) org.apache.excalibur.containerkit.logger:excalibur-logger:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.containerkit.logger:excalibur-logger:jar:2.1 6) org.apache.excalibur.components.pool:excalibur-pool-impl:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.components.pool:excalibur-pool-impl:jar:2.1 7) commons-jci:commons-jci:jar:r306555 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) commons-jci:commons-jci:jar:r306555 8) commons-javaflow:commons-javaflow:jar:r306555 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) commons-javaflow:commons-javaflow:jar:r306555 9) org.apache.excalibur.components.xmlutil:excalibur-xmlutil:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.components.xmlutil:excalibur-xmlutil:jar:2.1 10) org.apache.excalibur.containerkit.instrument:excalibur-instrument-api:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.containerkit.instrument:excalibur-instrument-api:jar:2.1 11) org.apache.excalibur.components.pool:excalibur-pool-instrumented:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.components.pool:excalibur-pool-instrumented:jar:2.1 1) org.apache.excalibur.components.sourceresolve:excalibur-sourceresolve:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.components.sourceresolve:excalibur-sourceresolve:jar:2.1 2) org.apache.excalibur.components.store:excalibur-store:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.components.store:excalibur-store:jar:2.1 3) org.apache.excalibur.containerkit.logger:excalibur-logger:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.containerkit.logger:excalibur-logger:jar:2.1 4) org.apache.avalon.framework:avalon-framework-impl:jar:4.3 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.avalon.framework:avalon-framework-impl:jar:4.3 5) org.apache.excalibur.components.pool:excalibur-pool-instrumented:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.components.pool:excalibur-pool-instrumented:jar:2.1 6) org.apache.excalibur.components.pool:excalibur-pool-impl:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.components.pool:excalibur-pool-impl:jar:2.1 7) org.apache.excalibur.containerkit.instrument:excalibur-instrument-api:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.containerkit.instrument:excalibur-instrument-api:jar:2.1 8) org.apache.excalibur.components.xmlutil:excalibur-xmlutil:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalib
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
Andrew Savory wrote: >> We (Luminas/SourceSense) are offering. Do you know what sort of >> requirements in terms of bandwidth and server space? We have capacity >> to spare, and are happy to donate it. Thanks, see below. Pier Fumagalli wrote: > Excuse me, but can someone refresh my memory on why we went down the > Maven way? I thought it was to get rid of maintaining all those "lib" in > our SVN, and now someone is telling me that we actually should maintain > a full maven mirror, but tweaked because we don't like theirs? My mistake, i should've explained things a bit more. What is being suggested is not that we mirror the whole of ibiblio, we would only mirror the libraries that are currently hosted on cvs.a.o. There are various reasons why we decided to host some of our dependencies there: - the dependency is not available on the central m2 repo (the number of these libs is slowly declining due to better m2 acceptance) - the dependency is available, but has a dodgy pom making it difficult to benefit from m2 features (eg transitive dependencies). - we're using a snapshot dependency that is not hosted anywhere else (remember the central repo only allows _released_ versions) Remember that this mirror would become only a *temporary* solution for any dependend library that has not fully mavenized yet. We should still practice maven evangelism and encourage the library owners to mavenize and release code to the central repo. I'll compile a report of what we're currently pulling from cvs.a.o., this should make it easier to estimate required bandwidth. In any case I will speak to Brett or Jason to see how they feel about this. Hope this clears things up a bit, Jorg
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
Hi, Pier Fumagalli wrote: Excuse me, but can someone refresh my memory on why we went down the Maven way? I thought it was to get rid of maintaining all those "lib" in our SVN, and now someone is telling me that we actually should maintain a full maven mirror, but tweaked because we don't like theirs? Heh. Yes, the idea is that by going the maven route we can more easily use external libs without having to keep them all within Cocoon itself. Unfortunately, there's some scaling issues, so this has backfired on us: it's not that we don't like the existing maven repos, but that they have capacity issues right now which reflects badly on Cocoon. To people new to maven, it looks like "Cocoon doesn't build" even though it's maven unable to fetch from the repositories. So my suggestion was, since we have bandwidth to spare, we could provide a Cocoon-specific mirror as a short-term fix whilst the more general infrastructure problems are resolved. Actually, in hindsight, it makes more sense to see what can be done to fix maven's repo infrastructure - but I know nothing about ibiblio etc. and don't have time to investigate right now, so it's easier for me to simply say "here's a machine with a ton of bandwidth, let's use that for now". If anyone knows how to do this in a more integrated way, please shout! Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
On 20 Mar 2006, at 09:19, Andrew Savory wrote: Hi, Jorg Heymans wrote: If someone can offer the bandwidth and server, i'm willing to migrate us away from cvs.a.o. and setup a decent m2 repo where only *we* control the poms. Any offers? I've got some time to kill this weekend ;) We (Luminas/SourceSense) are offering. Do you know what sort of requirements in terms of bandwidth and server space? We have capacity to spare, and are happy to donate it. Excuse me, but can someone refresh my memory on why we went down the Maven way? I thought it was to get rid of maintaining all those "lib" in our SVN, and now someone is telling me that we actually should maintain a full maven mirror, but tweaked because we don't like theirs? Pier smime.p7s Description: S/MIME cryptographic signature
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
Hi, Jorg Heymans wrote: If someone can offer the bandwidth and server, i'm willing to migrate us away from cvs.a.o. and setup a decent m2 repo where only *we* control the poms. Any offers? I've got some time to kill this weekend ;) We (Luminas/SourceSense) are offering. Do you know what sort of requirements in terms of bandwidth and server space? We have capacity to spare, and are happy to donate it. Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
Andrew Savory wrote: > Is there any way we can set up a Cocoon mirror for the time being, until > the repository problems are resolved? I'm sure several of us here can > set up a repo, and it could be the default used by Cocoon. If someone can offer the bandwidth and server, i'm willing to migrate us away from cvs.a.o. and setup a decent m2 repo where only *we* control the poms. Any offers? I've got some time to kill this weekend ;) Regards Jorg