Re: Maven Builds

[Emmanuel Lecharny <el...@gmail.com>]

Ole Ersoy a écrit :

>Brett,
>
>Thanks for the info.
>
>I put together some additional notes that I think are
>inline with our current goals for the build process. 
>I still have to validate that this will all work as
>expected, but I figured I would get the notes out here
>in case anyone wants to get started (These are in APT
>format, so if you want just cut and paste into the apt
>directory of a mvn project and run site to get the
>html version):
>
>  
>
Thanks Ole (and Brett), very interesting information.

I'm playing with Maven an try to set my dream environment :
- I want two repos : one for jars, one for plugins : is it possible ?
- I want those repos be at the same level than the top level pom.xml : 
jars and plugins respectively :

.
..
/jars
/plugins
/project1
/project2
pom.xml

and my pom.xml will contain :
  <repositories>
    <repository>
     <id>ads-jars</id>
     <name>Apache Directory Repository for Jars</name>
     <url>jars</url>
     <layout>default</layout>
    <repository>
    <repository>
     <id>ads-plugins</id>
     <name>Apache Directory Repository for Plugins</name>
     <url>plugins</url>
     <layout>default</layout>
    <repository>
  </repositories>

Is it correct ?
- Now, I don't want Maven to look after jars or plugins in the outer 
world. Modifying settings.xml does not fit me, because that means other 
users have to set it on their computer, and tis is a global element. I 
want to disable external repos from the rop level pom.xml. Is it possible ?

Lot of questions, I know, and RTFM, I know too... Lack of time, too :)

If you have any clue, it will be my pleasure !

btw, you can look at 
http://svn.apache.org/rpos/asf/directory/apacheds/sandbox/akarasulu/apacheds-2.0, 
this is where I'm playing.

Emmanuel

Re: Maven Builds

[Ole Ersoy <ol...@yahoo.com>]

Emmanuel,

Looks like your cool running - you know everything I
know now, and by the looks of it you will soon be De
Masta.

I'm still experimenting as well, so I'll let you know
results as I complete tests.

Cheers,
- Ole

--- Emmanuel Lecharny <el...@gmail.com> wrote:

> I gonna auto-answer some of my questions, but it
> induces more other 
> questions :)
> 
> > I'm playing with Maven an try to set my dream
> environment :
> 
> > - I want two repos : one for jars, one for plugins
> : is it possible ?
> 
> Definitively. There is a <repositories>  element and
> a 
> <pluginRepositories> one. Great !
> 
> > - I want those repos be at the same level than the
> top level pom.xml : 
> > jars and plugins respectively :
> >
> > .
> > ..
> > /jars
> > /plugins
> > /project1
> > /project2
> > pom.xml
> >
> > and my pom.xml will contain :
> 
> <snip/>
> 
> >
> > Is it correct ?
> 
> Part of my new pom.xml :
>   <repositories>
>     <repository>
>      <id>central</id>
>      <name>Apache Directory Repository</name>
>      <url>jars</url>
>      <layout>default</layout>
>     </repository>
>   </repositories>
> 
> Well, now have a problem : how do I set up the url
> to point on jars. If 
> I go up to a subproject (like project1), then I
> can't build my project, 
> because there is no 'jars' directory in it. So the
> url should be 
> something like $basedir/jars, where $basedir is the
> pom.xml path where 
> $basedir is declared. is it possible?
> 
> > - Now, I don't want Maven to look after jars or
> plugins in the outer 
> > world. Modifying settings.xml does not fit me,
> because that means 
> > other users have to set it on their computer, and
> tis is a global 
> > element. I want to disable external repos from the
> top level pom.xml. 
> > Is it possible ?
> 
> Don't know yet. My RTFM session was not completely
> satisfying : the 
> "better build with maven" is a great doco, but very
> general. And 
> browsing the web site lead me to something I
> strongly desagree with :
> "It is not recommended that you store your JARs in
> CVS. ... With Maven 
> these standard utilities can be stored in your local
> repository and 
> shared by any number of builds.
> 
> This has the following advantages:
> *1) It uses less storage"
> *Who cares ??? For less than 200$, I can buy 300Go
> disks. ApacheDS 
> repository is only 55 Mb big. This is NOTHING.
> *2) It makes checking out a project quicker
> *Who cares? I do check out ADS completely very often
> (around once a 
> week), and I really think I'm very untypical. You
> generally checkout a 
> project a few times in its whole life, and even if
> it takes 10 minutes, 
> big deal.
> *3) No need for versioning
> *This is all but an advantage. This is the way to
> break a configuration 
> managment. As you don't version, you have no way to
> guarantee that a jar 
> you are downloading is the one which has been use
> for the current 
> version of the product you are building. It is said
> on Maven web site 
> that you don't need to store in CVS immutable files,
> because if the file 
> change, its name change accordingly (junit-3.8.1.jar
> -> junit-4.1.0.jar, 
> for instance). Badly wrong. Not that far away, many
> jar's name weren't 
> changed. You had to look at the manifest to know
> which version it was, 
> if the developper has put this number in it :(. IBM
> Websphere is still 
> using this naming scheme (poor poor deployers ...).
> And I have seen sooo 
> many times a developper modifying a jar to add the
> last forgotten patch 
> without modifying the jar's name (and of course,
> this patch break 
> something in your code, and of course he was subtle
> enough to 
> re-generate the sha1 files so that its last minute
> and at nigth 
> modification went through all the Q&A processes ...)
> 
> Ok, ok, personnal opinion expressed...
> 
> More RTFM to come ! I may finally adopt maven and
> use it frantically :)
> 
> > Emmanuel
> 
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Maven Builds

[Emmanuel Lecharny <el...@gmail.com>]

I gonna auto-answer some of my questions, but it induces more other 
questions :)

> I'm playing with Maven an try to set my dream environment :

> - I want two repos : one for jars, one for plugins : is it possible ?

Definitively. There is a <repositories>  element and a 
<pluginRepositories> one. Great !

> - I want those repos be at the same level than the top level pom.xml : 
> jars and plugins respectively :
>
> .
> ..
> /jars
> /plugins
> /project1
> /project2
> pom.xml
>
> and my pom.xml will contain :

<snip/>

>
> Is it correct ?

Part of my new pom.xml :
  <repositories>
    <repository>
     <id>central</id>
     <name>Apache Directory Repository</name>
     <url>jars</url>
     <layout>default</layout>
    </repository>
  </repositories>

Well, now have a problem : how do I set up the url to point on jars. If 
I go up to a subproject (like project1), then I can't build my project, 
because there is no 'jars' directory in it. So the url should be 
something like $basedir/jars, where $basedir is the pom.xml path where 
$basedir is declared. is it possible?

> - Now, I don't want Maven to look after jars or plugins in the outer 
> world. Modifying settings.xml does not fit me, because that means 
> other users have to set it on their computer, and tis is a global 
> element. I want to disable external repos from the top level pom.xml. 
> Is it possible ?

Don't know yet. My RTFM session was not completely satisfying : the 
"better build with maven" is a great doco, but very general. And 
browsing the web site lead me to something I strongly desagree with :
"It is not recommended that you store your JARs in CVS. ... With Maven 
these standard utilities can be stored in your local repository and 
shared by any number of builds.

This has the following advantages:
*1) It uses less storage"
*Who cares ??? For less than 200$, I can buy 300Go disks. ApacheDS 
repository is only 55 Mb big. This is NOTHING.
*2) It makes checking out a project quicker
*Who cares? I do check out ADS completely very often (around once a 
week), and I really think I'm very untypical. You generally checkout a 
project a few times in its whole life, and even if it takes 10 minutes, 
big deal.
*3) No need for versioning
*This is all but an advantage. This is the way to break a configuration 
managment. As you don't version, you have no way to guarantee that a jar 
you are downloading is the one which has been use for the current 
version of the product you are building. It is said on Maven web site 
that you don't need to store in CVS immutable files, because if the file 
change, its name change accordingly (junit-3.8.1.jar -> junit-4.1.0.jar, 
for instance). Badly wrong. Not that far away, many jar's name weren't 
changed. You had to look at the manifest to know which version it was, 
if the developper has put this number in it :(. IBM Websphere is still 
using this naming scheme (poor poor deployers ...). And I have seen sooo 
many times a developper modifying a jar to add the last forgotten patch 
without modifying the jar's name (and of course, this patch break 
something in your code, and of course he was subtle enough to 
re-generate the sha1 files so that its last minute and at nigth 
modification went through all the Q&A processes ...)

Ok, ok, personnal opinion expressed...

More RTFM to come ! I may finally adopt maven and use it frantically :)

> Emmanuel