Either I am really thick here, or we talk about different things.
I don't want to use the Apache SVN server as MVN repository.
I propose to commit again all JARs into, say, cocoon/trunk/m2repo
and then tell Maven at build time to use that directory in the
checkout area as first repository server in the search list.
cocoon/trunk/pom.xml:
<repositories>
<repository>
<id>cocoon-private</id>
<name>Cocoon private Maven repository</name>
<url>file:/my/path/to/m2repo</url>
</repository>
<repository>
<id>central</id>
<name>Maven central repository</name>
<url>http://ibiblio.org/maven2</url>
</repository>
...
</repositories>
I am a Maven newbie that I don't know whether file: repositories
are actually supported. A relative locator would even be nicer.
The Internet repositories can still be used for thoses JARs for
which the are legal reasons not to store them on ASF servers.
I don't see, how storing some 100 jarfiles totaling 100 MB like
it is now for 2.1 should endanger the SVN infrastructure, if it
is used on the SVN checkouts and commits.
The drawback is of course that one has to checkout the whole thing
even for building a mini-subset of Cocoon blocks. But that is
something to worry about when the blocks a-la-carte actually works.
Until then a reliable build system is much more important.
Cheers, Alfred.
-----Original Message-----
From: Simone Gianni [mailto:[EMAIL PROTECTED]
Sent: Montag, 3. Juli 2006 11:27
To: dev@cocoon.apache.org
Subject: Re: [RANT] This Maven thing is killing us....
Hi Alfred,
see the previous mail by Upayavira :
"A good idea, but I can't see any way in which infrastructure would
allow this.That is because it would prevent any useful partitioning of
resources.
Maven is likely to become a resource hog, and could easily bring SVN
down to its knees. Much better that it only be the MVN repo that goes
down at such a time, and not our SVN repo too."
Simone
Nathaniel Alfred wrote:
>Why not keep the MVN repo in the Cocoon SVN repository like we used to
>do with the lib directory? That would allow close control of updates
>only by committers, and with a MVN file repo pointing to the user's
>Cocoon checkout, builds remain stable between SVN updates.
>
>Sure that requires again 100+ MB downloads from SVN. But that seems
>more stable than downloading 20 MB from SVN only and then 80+ MB from
>shakey MVN servers.
>
>Cheers, Alfred.
>
>-----Original Message-----
>From: Upayavira [mailto:[EMAIL PROTECTED]
>Sent: Montag, 3. Juli 2006 10:42
>To: dev@cocoon.apache.org
>Subject: Re: [RANT] This Maven thing is killing us....
>
>Simone Gianni wrote:
>
>
>>Niclas Hedhman wrote:
>>
>>
>>
>>>What happens *if* Mergere runs out of juice and flip the switch off?
>>>
>>>
>>>
>>>
>>IIUC, maven repos are nothing more than HTTP servers, and SVN is
>>accessible thru HTTP, so we can create a folder named "repository" in
>>our svn repo, copy the folders of artifacts we need from ibiblio, and
>>have complete control over it. This is technically possible (and would
>>also solve maaaaaaaany other problems), but does not solve the legal
>>stuff maven repos solve about redistributing others work.
>>
>>
>
>A good idea, but I can't see any way in which infrastructure would
allow
>this.
>
>That is because it would prevent any useful partitioning of resources.
>Maven is likely to become a resource hog, and could easily bring SVN
>down to its knees. Much better that it only be the MVN repo that goes
>down at such a time, and not our SVN repo too.
>
>Upayavira
>
>
>This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please notify the sender urgently
and then immediately delete the message and any copies of it from your
system. Please also immediately destroy any hardcopies of the message.
You must not, directly or indirectly, use, disclose, distribute, print,
or copy any part of this message if you are not the intended recipient.
The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this
message are those of the individual sender, except where the message
states otherwise and the sender is authorised to state them to be the
views of the sender's company.
>
>
--
Simone Gianni
