www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: maven2 based releases for the james project and ASF policy
Date Sun, 17 Sep 2006 12:28:18 GMT
Hi dims,

thank you for this suggestion! I never used a file url in the repository 
definition and it sounds interesting..

The main problem I can see with this solution is that people have to do 
a manual step (download third-party-m1 to a specific folder) before 
being able to build.

As an example people that will download the src package will find a 
pom.xml but running "mvn" on it won't work because they won't have this 
third-party-m1 repository in their system, and we have to make them 
manually do this step.

As another example when I'll put my pom url into continuum it will not 
be able to build it because it does not have the third-party-m1 jars and 
I can't see a simple solution if not add a cron or a manual script to 
keep them synchronized.

I'm just thinking at a solution (less than optimal because of jars 
duplication, but maybe better overall) where each project has its own 
repos/third-party-m1 folder in the source tree: we have no restricted 
jars in our dependencies now that Sun released activation/javamail under 
the CDDL.

So one of my projects (jspf) would have this repository definition:
----
<repository>
   <id>local-jspf-3rd-party-m1</id>
   <name>Local jSPF third party repository</name>
   <url>file://${basedir}/repos/third-party-m1</url>
   <layout>legacy</layout>
   <releases>
     <enabled>true</enabled>
     <checksumPolicy>ignore</checksumPolicy>
   </releases>
   <snapshots>
     <enabled>true</enabled>
     <checksumPolicy>ignore</checksumPolicy>
   </snapshots>
</repository>
-----
Then I would have to change the assembly.xml in order to put the repos 
folder in our src distribution: does this make sense?

I just made a proof and it seems to work for a single project: now I'm 
going to test this in a multiproject environment. I guess I will have 
problems with transitive dependencies, but I have to do some test to 
understand this.

Anyone else ever tested a similar solution?

Stefano

Davanum Srinivas wrote:
> Stefano,
> 
> I was thinking about the same thing for the last few days :) Here's
> something that will work. It's a variant on your steps.
> 
> Start with your #1, #2, but skip #3 and in #4 instead of a http url
> specify the directory on the hard disk where the svn checkout of the
> third-party-m1 directory is present.
> 
>         <repository>
>             <id>james-private-repo</id>
>             <name>James Private Repository</name>
>             <url>file:${basedir}/../../third-party-m1</url>
>             <releases>
>                 <enabled>true</enabled>
>             </releases>
>             <snapshots>
>                 <enabled>true</enabled>
>             </snapshots>
>         </repository>
> 
> What does this buy us?
> - We don't need to overload infra or worry about mirrors.
> - No need to worry about the web site.
> - Complete control over the jars
> - No network traffic as the jars are on the hard disk.
> - When we make a release the source zip is self-contained (no network
> access needed, no need to worry about jars disappearing from remote
> maven repos)
> 
> What do you think?
> 
> -- dims



Mime
View raw message