You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jorg Heymans <jh...@domek.be> on 2006/03/18 11:50:37 UTC
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
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release
plan)
Posted by Jorg Heymans <jh...@domek.be>.
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 reopsitory@a.o 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)
Posted by Ralph Goers <Ra...@dslextreme.com>.
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)
Posted by Niclas Hedhman <ni...@hedhman.org>.
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 reopsitory@a.o 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)
Posted by Jorg Heymans <jh...@domek.be>.
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)
Posted by Antonio Gallardo <ag...@agssa.net>.
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)
Posted by Niclas Hedhman <ni...@hedhman.org>.
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)
Posted by Jorg Heymans <jh...@domek.be>.
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.excalibur.components.xmlutil:excalibur-xmlutil:jar:2.1
1) icu4j:icu4j:jar:3.0
Path to dependency:
1) org.apache.cocoon:cocoon-forms-impl:jar:1.0-SNAPSHOT
2) icu4j:icu4j:jar:3.0
2) xreporter:xreporter-expression:jar:20040701
Path to dependency:
1) org.apache.cocoon:cocoon-forms-impl:jar:1.0-SNAPSHOT
2) xreporter:xreporter-expression:jar:20040701
3) daisy:daisy-util:jar:1.4.1
Path to dependency:
1) org.apache.cocoon:cocoon-forms-impl:jar:1.0-SNAPSHOT
2) daisy:daisy-util:jar:1.4.1
4) daisy:daisy-htmlcleaner:jar:1.4.1
Path to dependency:
1) org.apache.cocoon:cocoon-forms-impl:jar:1.0-SNAPSHOT
2) daisy:daisy-htmlcleaner:jar:1.4.1
1) wsrp4j:wsrp4j-consumer:jar:0.3-dev
Path to dependency:
1) org.apache.cocoon:cocoon-portal-impl:jar:1.0-SNAPSHOT
2) wsrp4j:wsrp4j-consumer:jar:0.3-dev
2) wsrp4j:wsrp4j-shared:jar:0.3-dev
Path to dependency:
1) org.apache.cocoon:cocoon-portal-impl:jar:1.0-SNAPSHOT
2) wsrp4j:wsrp4j-shared:jar:0.3-dev
3) nekohtml:nekodtd:jar:0.1.11
Path to dependency:
1) org.apache.cocoon:cocoon-portal-impl:jar:1.0-SNAPSHOT
2) nekohtml:nekodtd:jar:0.1.11
Regards
Jorg
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release
plan)
Posted by Andrew Savory <an...@luminas.co.uk>.
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)
Posted by Antonio Gallardo <ag...@agssa.net>.
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)
Posted by Jorg Heymans <jh...@domek.be>.
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)
Posted by Pier Fumagalli <pi...@betaversion.org>.
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
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release
plan)
Posted by Andrew Savory <an...@luminas.co.uk>.
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/