Hi Alfred, ok, now "and with a MVN file repo pointing to the user's Cocoon checkout" is clear to me, sorry my mistake :)
We evaluated this opportunity while thinking how to package Dojo. One of the solutions was exactly making a local repo, and putting there this dependency (and eventually the others) that cannot be found on public repositories. Main disadvantages regarding non mavenized libraries are : 1) We still need to "mavenize" them. 2) We will then publish artifacts which are not usable if not doing a complete checkout of the project. Anyway a local maven repo that resides in SVN with only needed dependencies, already mavenized and taken from ibiblio, is an option (or the default option?). It's not just a question of having a reliable build system, simply in many companies they have a lifecycle for their applications that steps thru test, integration etc.. and quite often this servers are not connected to internet, so building cocoon on those machines would be simply impossibile. With the local checkedout repo solution it's like having a lib dir, just a matter of checking out cocoon, moving it to the target server, and then build with maven as usual. Also, this would not interfere with artifacts published on ibiblio, since they will still have a dependency to the X artifact, and the local repo wouls be only configured in the main cocoon pom.xml, so used only when a complete checkout has been made. Simone Nathaniel Alfred wrote: >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
