You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Ole Ersoy <ol...@yahoo.com> on 2006/08/29 03:12:08 UTC
Maven Builds
Guys,
These build issues are really of our own "Choosing".
When a project is started, we can point maven to
repositories of our choice, or download all the
dependencies manually, build a maven repository
ourself, and then manage the updates of that
repository, so that we know of every change made to
it.
The reason the maven repository is so useful is
because it communicates to anyone who wants to build
the project what the dependencies are and where they
can get them.
So if we want control we can have it, for both plugin
repositories and source repositories, right at the
start of the project and thereafter.
If were using Ant - we'd have to tell everyone wanting
to do a build where to find the dependencies...
setup the class path, etc. etc. etc. and we could even
have the ant script download and setup a custom
repository and classpath, but then we all of a sudden
have Maven.
If Maven had the checksum validation Emmanuel
mentioned when we listed ways to lock down the build
process, that's as good as it gets as far as
validating and using dependencies and plugins goes.
If only we had a plugin that read the parent pom and
all the module poms, analyze them, and tell us where
we used the same dependency, but different version,
alerted us whenenver a plugin/dependencies checksum
changed without a version change, and created a report
detailing all of the automatically updated plugins /
dependencies - Bravo! We would be in primo condition
because the build be intelligent, and tell us when
something unexpected were about to happen, or when
something could go awry due to the configuration of
maven.
So theres obviously some room for improvement, but
Maven is a brilliant piece of work, and those
improvements are easy to do with Maven. We just need
some "Summer of Code" guys. Anyone got connections?
OK OK OK - I'll shatt up now and get to work on
analyzing where to apply our currently known
solutions.
Cheers,
- Ole
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Maven Builds
Posted by 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
Posted by 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
Re: Maven Builds
Posted by 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
Posted by Ole Ersoy <ol...@yahoo.com>.
One additional note per the previous:
Scenario:
Suppose we start from scratch with Maven,
and point it to our repository mirror / our
own repository.
Now Maven goes ahead and initializes itself.
However our repository is down, so Maven ends up going
to Ibiblio anyways.
Possible Solution:
rsync our repository into
the m2 directory on our machines,
and then set maven to work offline.
--- Ole Ersoy <ol...@yahoo.com> wrote:
> 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):
>
>
--------------------------------------------------------------------------------------
>
> Build Process
>
>
--------------------------------------------------------------------------------------
>
> Maven Repository Setup
>
> Per the Maven
>
http://maven.apache.org/guides/introduction/introduction-to-repositories.html
> documentation setting up a repository is just a
> matter of mirroring the type of file
> structure used on for example ibiblio.
>
> Then add a repositories element to the pom like
> this:
>
-------------------------------------------------------------------------------------
> <project>
> ...
> <repositories>
> <repository>
> <id>adsr</id>
> <name>Apache Directory Repository</name>
> <url>http://m2.safehouse.org</url>
> <layout>default</layout>
> <repository>
> </repositories>
> ...
> </project>
>
-------------------------------------------------------------------------------------
>
> Now - in our case we probably want to turn off
> Ibiblio as well. I asked how to
> do that on the users group, and Wayne Fay said
> to
> just setup a mirror of
> central like this in settings.xml:
>
>
-------------------------------------------------------------------------------------
>
> <mirrors>
> <mirror>
> <mirrorOf>
> central
> </mirrorOf>
> <name>Apache Directory Repository</name>
> <url>http://m2.safehouse.org</url>
> <id>adsr</id>
> </mirror>
> </mirrors>
>
>
-------------------------------------------------------------------------------------
>
>
>
> Going Offline
>
> To run Maven offline add this to settings.xml
>
-------------------------------------------------------------------------------------
> <settings>
> <offline>true</offline>
> </settings>
>
-------------------------------------------------------------------------------------
>
> Checksum Automation
>
> If a newer version of a dependency we are using
>
> with the same version number is available, do
> we
> want to
> download it?
>
> Does Maven do a timestamp check on dependencies
> with the
> same version number that we already have, and
> if
> available download it?
>
> I have to test it to see whether it does.
>
> If we have our own repository mirror, then
> Maven
> should always go there
> and ibiblio will not be consulted.
>
> However if our mirror is down, then it might go
> to ibiblio.
>
> So the concern can be restated like this:
>
> "If our mirror is down, and Maven sees
> dependencies or plugins with
> a more recent timestamp, but same version as
> we
> are currently using
> in the build, will it download and replace our
> current files with
> the more recent files"?
>
> Or in other words does Maven treat versioned
> dependencies and plugins
> like SNAPSHOTS?
>
> If the answer to this ends up being no, then
> we
> are safe, because
> we will be initializing our maven installation
> from the mirror repository.
>
> Plugin Version Management
>
>
-------------------------------------------------------------------------------------
>
> Specify Plugin Versions in the POM
>
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-compiler-plugin</artifactId>
> <version>Set the Version of the Plugin
> Here</version>
> </plugin>
> </plugins>
> </build>
>
>
-------------------------------------------------------------------------------------
>
> As an alternative we can use the
> plugin-registry.xml File to Manage Plugin Versions
>
>
> Dependency Version Management
>
> All dependencies should have the associated
> version set.
>
>
-------------------------------------------------------------------------------------
>
> <dependencies>
> <dependency>
> <version>
> Set the version here
> </version>
> </dependency>
>
-------------------------------------------------------------------------------------
>
>
> Remember that if the dependency is a SNAPSHOT,
> then this tells maven to get the latest file.
>
>
>
>
>
>
> --- Brett Porter <br...@gmail.com> wrote:
>
> > Here is an explanation of the problem and how to
> > make your build more
> > predictable:
> >
>
http://mail-archives.apache.org/mod_mbox/maven-users/200608.mbox/%3C9e3862d80608281316t3e9c388ep60216c8a80d588aa@mail.gmail.com%3E
> >
> > Basically it comes down to only using snapshot
> > plugins when you really
> > really have to. Currently, too many projects are
> > setting their default
> > builds to grab all the unstable plugins, which is
> > obviously a receipe
> > for disaster.
> >
> > We're certainly working to improve that story for
> > future Maven releases.
> >
> > I have now turned off
> snapshots.maven.codehaus.org,
> > so the errors
> > should be a whole lot less subtle if it is still
> in
> > use anywhere else
> > :)
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Maven Builds
Posted by Ole Ersoy <ol...@yahoo.com>.
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):
--------------------------------------------------------------------------------------
Build Process
--------------------------------------------------------------------------------------
Maven Repository Setup
Per the Maven
http://maven.apache.org/guides/introduction/introduction-to-repositories.html
documentation setting up a repository is just a
matter of mirroring the type of file
structure used on for example ibiblio.
Then add a repositories element to the pom like
this:
-------------------------------------------------------------------------------------
<project>
...
<repositories>
<repository>
<id>adsr</id>
<name>Apache Directory Repository</name>
<url>http://m2.safehouse.org</url>
<layout>default</layout>
<repository>
</repositories>
...
</project>
-------------------------------------------------------------------------------------
Now - in our case we probably want to turn off
Ibiblio as well. I asked how to
do that on the users group, and Wayne Fay said to
just setup a mirror of
central like this in settings.xml:
-------------------------------------------------------------------------------------
<mirrors>
<mirror>
<mirrorOf>
central
</mirrorOf>
<name>Apache Directory Repository</name>
<url>http://m2.safehouse.org</url>
<id>adsr</id>
</mirror>
</mirrors>
-------------------------------------------------------------------------------------
Going Offline
To run Maven offline add this to settings.xml
-------------------------------------------------------------------------------------
<settings>
<offline>true</offline>
</settings>
-------------------------------------------------------------------------------------
Checksum Automation
If a newer version of a dependency we are using
with the same version number is available, do we
want to
download it?
Does Maven do a timestamp check on dependencies
with the
same version number that we already have, and if
available download it?
I have to test it to see whether it does.
If we have our own repository mirror, then Maven
should always go there
and ibiblio will not be consulted.
However if our mirror is down, then it might go
to ibiblio.
So the concern can be restated like this:
"If our mirror is down, and Maven sees
dependencies or plugins with
a more recent timestamp, but same version as we
are currently using
in the build, will it download and replace our
current files with
the more recent files"?
Or in other words does Maven treat versioned
dependencies and plugins
like SNAPSHOTS?
If the answer to this ends up being no, then we
are safe, because
we will be initializing our maven installation
from the mirror repository.
Plugin Version Management
-------------------------------------------------------------------------------------
Specify Plugin Versions in the POM
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>Set the Version of the Plugin
Here</version>
</plugin>
</plugins>
</build>
-------------------------------------------------------------------------------------
As an alternative we can use the
plugin-registry.xml File to Manage Plugin Versions
Dependency Version Management
All dependencies should have the associated
version set.
-------------------------------------------------------------------------------------
<dependencies>
<dependency>
<version>
Set the version here
</version>
</dependency>
-------------------------------------------------------------------------------------
Remember that if the dependency is a SNAPSHOT,
then this tells maven to get the latest file.
--- Brett Porter <br...@gmail.com> wrote:
> Here is an explanation of the problem and how to
> make your build more
> predictable:
>
http://mail-archives.apache.org/mod_mbox/maven-users/200608.mbox/%3C9e3862d80608281316t3e9c388ep60216c8a80d588aa@mail.gmail.com%3E
>
> Basically it comes down to only using snapshot
> plugins when you really
> really have to. Currently, too many projects are
> setting their default
> builds to grab all the unstable plugins, which is
> obviously a receipe
> for disaster.
>
> We're certainly working to improve that story for
> future Maven releases.
>
> I have now turned off snapshots.maven.codehaus.org,
> so the errors
> should be a whole lot less subtle if it is still in
> use anywhere else
> :)
>
> - Brett
>
> On 29/08/06, Emmanuel Lecharny <el...@gmail.com>
> wrote:
> > Ole Ersoy a écrit :
> >
> > >Guys,
> > >
> > >These build issues are really of our own
> "Choosing".
> > >
> > >
> > Well, yes. I have to agree. But the point is that
> Maven development have
> > been so intense those last two years (the switch
> from maven1 to maven 2
> > brought so tremendous improvment that I really
> can't understand how we
> > were able to live we m1 :) that we were left (and
> still are) without
> > any decent documentation.
> >
> > Right now, M2 is usable, but really, some tricky
> problem need to be
> > fixed and be set as default. "Coosing" mean you
> know that you can
> > choose, and sorry, but the "documentation" is
> really the biggest problem
> > atm.
> >
> > >When a project is started, we can point maven to
> > >repositories of our choice, or download all the
> > >dependencies manually, build a maven repository
> > >ourself, and then manage the updates of that
> > >repository, so that we know of every change made
> to
> > >it.
> > >
> > >
> > Let's do that. I have sent a mail 2 months ago
> suggesting that we have
> > to do exactly that.
> >
> > >The reason the maven repository is so useful is
> > >because it communicates to anyone who wants to
> build
> > >the project what the dependencies are and where
> they
> > >can get them.
> > >
> > >
> > They are usefull - really - because you can grab
> the last one and bring
> > all the information regarding transitive
> dependencies. But this is
> > usefull only once : when you start using a
> version. However, the version
> > checking done by maven is *not* the best. It
> assumes that everybody use
> > the same notation. For instance, acme-20020825.jar
> is seens as newer
> > than acme-3.0.jar (let say that acme-3.0 was out
> last month). I'm ok
> > with that, but then you must have a way to get the
> control of the whole
> > process.
> >
> > >So if we want control we can have it, for both
> plugin
> > >repositories and source repositories, right at
> the
> > >start of the project and thereafter.
> > >
> > >
> > yeahhhhh !
> >
> > >If were using Ant - we'd have to tell everyone
> wanting
> > >to do a build where to find the dependencies...
> > >setup the class path, etc. etc. etc. and we could
> even
> > >have the ant script download and setup a custom
> > >repository and classpath, but then we all of a
> sudden
> > >have Maven.
> > >
> > >
> > No. That's a misconception of what should be a
> build. When you are
> > building a product wich has versions, then whenyou
> do a checkout, you
> > *must* (I insist) download all the files,
> including all the jars, to be
> > able to build the exact version you want to build.
> So it's not a
> > question of using ant or maven, it's a question of
> being able to build a
> > version X reliably. That means versionning ALL the
> files. acme-3.0.jar
> > should be versionned and tagged with version 1.0
> if it is used to build
> > version 1.0. If you build version 2.0, which use
> acme-4.0.jar, then this
> > jar has to be tagged as a member of this build.
> Maven bring *nothing* to
> > solve this issue. Maven bring a better structure
> and transitive
> > dependencies handling (and these are good thing),
> that's it. It's not a
> > way to solve configuration managment which is not
> handled.
> >
> > >If Maven had the checksum validation Emmanuel
> > >mentioned when we listed ways to lock down the
> build
> > >process, that's as good as it gets as far as
> > >validating and using dependencies and plugins
> goes.
> > >
> > >
> > Yeah, I agree. But checksum validation is only
> good for people managing
> > maven repos. We are not managing them, we are
> using them. And in my
> > mind, we should only use them once, when we grab
> our initial jars.
> >
> > >If only we had a plugin that read the parent pom
> and
> > >all the module poms, analyze them, and tell us
> where
> > >we used the same dependency, but different
> version,
> > >alerted us whenenver a plugin/dependencies
> checksum
> > >changed without a version change, and created a
> report
> > >detailing all of the automatically updated
> plugins /
> > >dependencies - Bravo! We would be in primo
> condition
> > >because the build be intelligent, and tell us
> when
> > >something unexpected were about to happen, or
> when
> > >something could go awry due to the configuration
> of
> > >maven.
> > >
> > >
> > You had a dream :)
> >
> > >So theres obviously some room for improvement,
> but
> > >Maven is a brilliant piece of work, and those
> > >improvements are easy to do with Maven. We just
> need
> > >some "Summer of Code" guys. Anyone got
> connections?
> > >
> > >
> > Maven may be a brilliant piece of software, but,
> sorry about that, I'm
> > not intelligent enough to just guess what it does
> when it goes wild.
> > Sorry to insist : we have lost 2 hours yesturday
> with ersin to just
> > understand what could be the problem with the
> build when it suddenly
> > broke because somebody modified a jar somewhere in
> one unknown repos. At
> > least, Stefano and other maven guru's helped us to
> find out a solution.
> > But I really see it dangerous when a tool need
> guru's to be used. We are
> > locked down. I never felt that with ant, and trust
> me, I'm not a Ant
> > guru (the less I have to deal with build system,
> the more happy I'm).
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Maven Builds
Posted by Brett Porter <br...@gmail.com>.
Here is an explanation of the problem and how to make your build more
predictable:
http://mail-archives.apache.org/mod_mbox/maven-users/200608.mbox/%3C9e3862d80608281316t3e9c388ep60216c8a80d588aa@mail.gmail.com%3E
Basically it comes down to only using snapshot plugins when you really
really have to. Currently, too many projects are setting their default
builds to grab all the unstable plugins, which is obviously a receipe
for disaster.
We're certainly working to improve that story for future Maven releases.
I have now turned off snapshots.maven.codehaus.org, so the errors
should be a whole lot less subtle if it is still in use anywhere else
:)
- Brett
On 29/08/06, Emmanuel Lecharny <el...@gmail.com> wrote:
> Ole Ersoy a écrit :
>
> >Guys,
> >
> >These build issues are really of our own "Choosing".
> >
> >
> Well, yes. I have to agree. But the point is that Maven development have
> been so intense those last two years (the switch from maven1 to maven 2
> brought so tremendous improvment that I really can't understand how we
> were able to live we m1 :) that we were left (and still are) without
> any decent documentation.
>
> Right now, M2 is usable, but really, some tricky problem need to be
> fixed and be set as default. "Coosing" mean you know that you can
> choose, and sorry, but the "documentation" is really the biggest problem
> atm.
>
> >When a project is started, we can point maven to
> >repositories of our choice, or download all the
> >dependencies manually, build a maven repository
> >ourself, and then manage the updates of that
> >repository, so that we know of every change made to
> >it.
> >
> >
> Let's do that. I have sent a mail 2 months ago suggesting that we have
> to do exactly that.
>
> >The reason the maven repository is so useful is
> >because it communicates to anyone who wants to build
> >the project what the dependencies are and where they
> >can get them.
> >
> >
> They are usefull - really - because you can grab the last one and bring
> all the information regarding transitive dependencies. But this is
> usefull only once : when you start using a version. However, the version
> checking done by maven is *not* the best. It assumes that everybody use
> the same notation. For instance, acme-20020825.jar is seens as newer
> than acme-3.0.jar (let say that acme-3.0 was out last month). I'm ok
> with that, but then you must have a way to get the control of the whole
> process.
>
> >So if we want control we can have it, for both plugin
> >repositories and source repositories, right at the
> >start of the project and thereafter.
> >
> >
> yeahhhhh !
>
> >If were using Ant - we'd have to tell everyone wanting
> >to do a build where to find the dependencies...
> >setup the class path, etc. etc. etc. and we could even
> >have the ant script download and setup a custom
> >repository and classpath, but then we all of a sudden
> >have Maven.
> >
> >
> No. That's a misconception of what should be a build. When you are
> building a product wich has versions, then whenyou do a checkout, you
> *must* (I insist) download all the files, including all the jars, to be
> able to build the exact version you want to build. So it's not a
> question of using ant or maven, it's a question of being able to build a
> version X reliably. That means versionning ALL the files. acme-3.0.jar
> should be versionned and tagged with version 1.0 if it is used to build
> version 1.0. If you build version 2.0, which use acme-4.0.jar, then this
> jar has to be tagged as a member of this build. Maven bring *nothing* to
> solve this issue. Maven bring a better structure and transitive
> dependencies handling (and these are good thing), that's it. It's not a
> way to solve configuration managment which is not handled.
>
> >If Maven had the checksum validation Emmanuel
> >mentioned when we listed ways to lock down the build
> >process, that's as good as it gets as far as
> >validating and using dependencies and plugins goes.
> >
> >
> Yeah, I agree. But checksum validation is only good for people managing
> maven repos. We are not managing them, we are using them. And in my
> mind, we should only use them once, when we grab our initial jars.
>
> >If only we had a plugin that read the parent pom and
> >all the module poms, analyze them, and tell us where
> >we used the same dependency, but different version,
> >alerted us whenenver a plugin/dependencies checksum
> >changed without a version change, and created a report
> >detailing all of the automatically updated plugins /
> >dependencies - Bravo! We would be in primo condition
> >because the build be intelligent, and tell us when
> >something unexpected were about to happen, or when
> >something could go awry due to the configuration of
> >maven.
> >
> >
> You had a dream :)
>
> >So theres obviously some room for improvement, but
> >Maven is a brilliant piece of work, and those
> >improvements are easy to do with Maven. We just need
> >some "Summer of Code" guys. Anyone got connections?
> >
> >
> Maven may be a brilliant piece of software, but, sorry about that, I'm
> not intelligent enough to just guess what it does when it goes wild.
> Sorry to insist : we have lost 2 hours yesturday with ersin to just
> understand what could be the problem with the build when it suddenly
> broke because somebody modified a jar somewhere in one unknown repos. At
> least, Stefano and other maven guru's helped us to find out a solution.
> But I really see it dangerous when a tool need guru's to be used. We are
> locked down. I never felt that with ant, and trust me, I'm not a Ant
> guru (the less I have to deal with build system, the more happy I'm).
> And please don't tell me that ant can't handle big builds, because I
> just used it successfully to build a broject with 300 modules, 250
> developpers, and the ant scripts were built in 2 weeks, and was handling
> transitive dependencies, without the help of ivy. Here, the question is
> not if we want to switch to ant, it's "how for christ sake can we have a
> *RELIABLE* build with maven.
>
> So let's find solution, because discussion about maven, ant, ivy,
> ./configure advantages are better in a bar with a lot of beers, and the
> place to have them is Austin, october 9-13. Now we just want to have the
> best possible maven build for ADS ;)
>
> >OK OK OK - I'll shatt up now and get to work on
> >analyzing where to apply our currently known
> >solutions.
> >
> >
> Really kool!!!
>
> >Cheers,
> >- Ole
> >
> >
>
> Thanks Ole :)
>
> Emmanuel
>
--
Apache Maven - http://maven.apache.org
"Better Builds with Maven" book - http://library.mergere.com/
Re: Maven Builds
Posted by Ole Ersoy <ol...@yahoo.com>.
--- Emmanuel Lecharny <el...@gmail.com> wrote:
> Ole Ersoy a écrit :
>
> >Guys,
> >
> >These build issues are really of our own
> "Choosing".
> >
> >
> Well, yes. I have to agree. But the point is that
> Maven development have
> been so intense those last two years (the switch
> from maven1 to maven 2
> brought so tremendous improvment that I really can't
> understand how we
> were able to live we m1 :) that we were left (and
> still are) without
> any decent documentation.
>
> Right now, M2 is usable, but really, some tricky
> problem need to be
> fixed and be set as default. "Coosing" mean you know
> that you can
> choose, and sorry, but the "documentation" is really
> the biggest problem
> atm.
>
> >When a project is started, we can point maven to
> >repositories of our choice, or download all the
> >dependencies manually, build a maven repository
> >ourself, and then manage the updates of that
> >repository, so that we know of every change made to
> >it.
> >
> >
> Let's do that. I have sent a mail 2 months ago
> suggesting that we have
> to do exactly that.
>
> >The reason the maven repository is so useful is
> >because it communicates to anyone who wants to
> build
> >the project what the dependencies are and where
> they
> >can get them.
> >
> >
> They are usefull - really - because you can grab the
> last one and bring
> all the information regarding transitive
> dependencies. But this is
> usefull only once : when you start using a version.
> However, the version
> checking done by maven is *not* the best. It assumes
> that everybody use
> the same notation. For instance, acme-20020825.jar
> is seens as newer
> than acme-3.0.jar (let say that acme-3.0 was out
> last month). I'm ok
> with that, but then you must have a way to get the
> control of the whole
> process.
>
> >So if we want control we can have it, for both
> plugin
> >repositories and source repositories, right at the
> >start of the project and thereafter.
> >
> >
> yeahhhhh !
>
> >If were using Ant - we'd have to tell everyone
> wanting
> >to do a build where to find the dependencies...
> >setup the class path, etc. etc. etc. and we could
> even
> >have the ant script download and setup a custom
> >repository and classpath, but then we all of a
> sudden
> >have Maven.
> >
> >
> No. That's a misconception of what should be a
> build. When you are
> building a product wich has versions, then whenyou
> do a checkout, you
> *must* (I insist) download all the files, including
> all the jars, to be
> able to build the exact version you want to build.
> So it's not a
> question of using ant or maven, it's a question of
> being able to build a
> version X reliably. That means versionning ALL the
> files. acme-3.0.jar
> should be versionned and tagged with version 1.0 if
> it is used to build
> version 1.0. If you build version 2.0, which use
> acme-4.0.jar, then this
> jar has to be tagged as a member of this build.
> Maven bring *nothing* to
> solve this issue. Maven bring a better structure and
> transitive
> dependencies handling (and these are good thing),
> that's it. It's not a
> way to solve configuration managment which is not
> handled.
Time out. OK - Suppose I create a project:
<artifactId>OleProject</artifactId>
<version>1.0</version>
And now version 1.0 of OleProject dependes on
<dependency>SomeJar</dependency>
<version>1.0</dependency>
And Later I Upgrade OleProject to version 2.0,
<artifactId>OleProject</artifactId>
<version>2.0</version>
And this is built with version 3.0 of SomeJar
<dependency>SomeJar</dependency>
<version>3.0</dependency>
So now the build automatically uses version 3.0 of
some jar.
That's configuration management / dependency
management right?
So if I control the repository that that has version
1.0 of SomeJar and 3.0 of SomeJar, I control
everything.
>
> >If Maven had the checksum validation Emmanuel
> >mentioned when we listed ways to lock down the
> build
> >process, that's as good as it gets as far as
> >validating and using dependencies and plugins goes.
> >
> >
> Yeah, I agree. But checksum validation is only good
> for people managing
> maven repos. We are not managing them, we are using
> them. And in my
> mind, we should only use them once, when we grab our
> initial jars.
Indeed.
>
> >If only we had a plugin that read the parent pom
> and
> >all the module poms, analyze them, and tell us
> where
> >we used the same dependency, but different version,
> >alerted us whenenver a plugin/dependencies checksum
> >changed without a version change, and created a
> report
> >detailing all of the automatically updated plugins
> /
> >dependencies - Bravo! We would be in primo
> condition
> >because the build be intelligent, and tell us when
> >something unexpected were about to happen, or when
> >something could go awry due to the configuration of
> >maven.
> >
> >
> You had a dream :)
That some Day all repositories will be Equal!!
>
> >So theres obviously some room for improvement, but
> >Maven is a brilliant piece of work, and those
> >improvements are easy to do with Maven. We just
> need
> >some "Summer of Code" guys. Anyone got
> connections?
> >
> >
> Maven may be a brilliant piece of software, but,
> sorry about that, I'm
> not intelligent enough to just guess what it does
> when it goes wild.
> Sorry to insist : we have lost 2 hours yesturday
> with ersin to just
> understand what could be the problem with the build
> when it suddenly
> broke because somebody modified a jar somewhere in
> one unknown repos. At
> least, Stefano and other maven guru's helped us to
> find out a solution.
> But I really see it dangerous when a tool need
> guru's to be used. We are
> locked down. I never felt that with ant, and trust
> me, I'm not a Ant
> guru (the less I have to deal with build system, the
> more happy I'm).
> And please don't tell me that ant can't handle big
> builds, because I
> just used it successfully to build a broject with
> 300 modules, 250
Ant Goodddd!!!
> developpers, and the ant scripts were built in 2
> weeks, and was handling
> transitive dependencies, without the help of ivy.
> Here, the question is
> not if we want to switch to ant, it's "how for
> christ sake can we have a
> *RELIABLE* build with maven.
>
> So let's find solution, because discussion about
> maven, ant, ivy,
> ./configure advantages are better in a bar with a
> lot of beers, and the
Beer Gooddd!!
> place to have them is Austin, october 9-13. Now we
> just want to have the
> best possible maven build for ADS ;)
>
> >OK OK OK - I'll shatt up now and get to work on
> >analyzing where to apply our currently known
> >solutions.
> >
> >
> Really kool!!!
>
> >Cheers,
> >- Ole
> >
> >
>
> Thanks Ole :)
>
> Emmanuel
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Maven Builds
Posted by Emmanuel Lecharny <el...@gmail.com>.
Ole Ersoy a écrit :
>I forgot to mention there's a free Book offered by
>Mergere
>
>http://maven.apache.org/articles.html
>
>and I find the guides to be concise, brief, and
>reasonably exhaustive, to the point where I can
>usually find an answer within a few minutes.
>
>There's also lots of good articles.
>
>
>
Yes, I printed it two monts ago.
It's really a good introduction to maven. But it's not enough...
Good start, however !
I hope we have the same for ADS :)
Emmanuel
Re: Maven Builds
Posted by Ole Ersoy <ol...@yahoo.com>.
I forgot to mention there's a free Book offered by
Mergere
http://maven.apache.org/articles.html
and I find the guides to be concise, brief, and
reasonably exhaustive, to the point where I can
usually find an answer within a few minutes.
There's also lots of good articles.
--- Emmanuel Lecharny <el...@gmail.com> wrote:
> Ole Ersoy a écrit :
>
> >Guys,
> >
> >These build issues are really of our own
> "Choosing".
> >
> >
> Well, yes. I have to agree. But the point is that
> Maven development have
> been so intense those last two years (the switch
> from maven1 to maven 2
> brought so tremendous improvment that I really can't
> understand how we
> were able to live we m1 :) that we were left (and
> still are) without
> any decent documentation.
>
> Right now, M2 is usable, but really, some tricky
> problem need to be
> fixed and be set as default. "Coosing" mean you know
> that you can
> choose, and sorry, but the "documentation" is really
> the biggest problem
> atm.
>
> >When a project is started, we can point maven to
> >repositories of our choice, or download all the
> >dependencies manually, build a maven repository
> >ourself, and then manage the updates of that
> >repository, so that we know of every change made to
> >it.
> >
> >
> Let's do that. I have sent a mail 2 months ago
> suggesting that we have
> to do exactly that.
>
> >The reason the maven repository is so useful is
> >because it communicates to anyone who wants to
> build
> >the project what the dependencies are and where
> they
> >can get them.
> >
> >
> They are usefull - really - because you can grab the
> last one and bring
> all the information regarding transitive
> dependencies. But this is
> usefull only once : when you start using a version.
> However, the version
> checking done by maven is *not* the best. It assumes
> that everybody use
> the same notation. For instance, acme-20020825.jar
> is seens as newer
> than acme-3.0.jar (let say that acme-3.0 was out
> last month). I'm ok
> with that, but then you must have a way to get the
> control of the whole
> process.
>
> >So if we want control we can have it, for both
> plugin
> >repositories and source repositories, right at the
> >start of the project and thereafter.
> >
> >
> yeahhhhh !
>
> >If were using Ant - we'd have to tell everyone
> wanting
> >to do a build where to find the dependencies...
> >setup the class path, etc. etc. etc. and we could
> even
> >have the ant script download and setup a custom
> >repository and classpath, but then we all of a
> sudden
> >have Maven.
> >
> >
> No. That's a misconception of what should be a
> build. When you are
> building a product wich has versions, then whenyou
> do a checkout, you
> *must* (I insist) download all the files, including
> all the jars, to be
> able to build the exact version you want to build.
> So it's not a
> question of using ant or maven, it's a question of
> being able to build a
> version X reliably. That means versionning ALL the
> files. acme-3.0.jar
> should be versionned and tagged with version 1.0 if
> it is used to build
> version 1.0. If you build version 2.0, which use
> acme-4.0.jar, then this
> jar has to be tagged as a member of this build.
> Maven bring *nothing* to
> solve this issue. Maven bring a better structure and
> transitive
> dependencies handling (and these are good thing),
> that's it. It's not a
> way to solve configuration managment which is not
> handled.
>
> >If Maven had the checksum validation Emmanuel
> >mentioned when we listed ways to lock down the
> build
> >process, that's as good as it gets as far as
> >validating and using dependencies and plugins goes.
> >
> >
> Yeah, I agree. But checksum validation is only good
> for people managing
> maven repos. We are not managing them, we are using
> them. And in my
> mind, we should only use them once, when we grab our
> initial jars.
>
> >If only we had a plugin that read the parent pom
> and
> >all the module poms, analyze them, and tell us
> where
> >we used the same dependency, but different version,
> >alerted us whenenver a plugin/dependencies checksum
> >changed without a version change, and created a
> report
> >detailing all of the automatically updated plugins
> /
> >dependencies - Bravo! We would be in primo
> condition
> >because the build be intelligent, and tell us when
> >something unexpected were about to happen, or when
> >something could go awry due to the configuration of
> >maven.
> >
> >
> You had a dream :)
>
> >So theres obviously some room for improvement, but
> >Maven is a brilliant piece of work, and those
> >improvements are easy to do with Maven. We just
> need
> >some "Summer of Code" guys. Anyone got
> connections?
> >
> >
> Maven may be a brilliant piece of software, but,
> sorry about that, I'm
> not intelligent enough to just guess what it does
> when it goes wild.
> Sorry to insist : we have lost 2 hours yesturday
> with ersin to just
> understand what could be the problem with the build
> when it suddenly
> broke because somebody modified a jar somewhere in
> one unknown repos. At
> least, Stefano and other maven guru's helped us to
> find out a solution.
> But I really see it dangerous when a tool need
> guru's to be used. We are
> locked down. I never felt that with ant, and trust
> me, I'm not a Ant
> guru (the less I have to deal with build system, the
> more happy I'm).
> And please don't tell me that ant can't handle big
> builds, because I
> just used it successfully to build a broject with
> 300 modules, 250
> developpers, and the ant scripts were built in 2
> weeks, and was handling
> transitive dependencies, without the help of ivy.
> Here, the question is
> not if we want to switch to ant, it's "how for
> christ sake can we have a
> *RELIABLE* build with maven.
>
> So let's find solution, because discussion about
> maven, ant, ivy,
> ./configure advantages are better in a bar with a
> lot of beers, and the
> place to have them is Austin, october 9-13. Now we
> just want to have the
> best possible maven build for ADS ;)
>
> >OK OK OK - I'll shatt up now and get to work on
> >analyzing where to apply our currently known
> >solutions.
> >
> >
> Really kool!!!
>
> >Cheers,
> >- Ole
> >
> >
>
> Thanks Ole :)
>
> Emmanuel
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Maven Builds
Posted by Emmanuel Lecharny <el...@gmail.com>.
Ole Ersoy a écrit :
>Guys,
>
>These build issues are really of our own "Choosing".
>
>
Well, yes. I have to agree. But the point is that Maven development have
been so intense those last two years (the switch from maven1 to maven 2
brought so tremendous improvment that I really can't understand how we
were able to live we m1 :) that we were left (and still are) without
any decent documentation.
Right now, M2 is usable, but really, some tricky problem need to be
fixed and be set as default. "Coosing" mean you know that you can
choose, and sorry, but the "documentation" is really the biggest problem
atm.
>When a project is started, we can point maven to
>repositories of our choice, or download all the
>dependencies manually, build a maven repository
>ourself, and then manage the updates of that
>repository, so that we know of every change made to
>it.
>
>
Let's do that. I have sent a mail 2 months ago suggesting that we have
to do exactly that.
>The reason the maven repository is so useful is
>because it communicates to anyone who wants to build
>the project what the dependencies are and where they
>can get them.
>
>
They are usefull - really - because you can grab the last one and bring
all the information regarding transitive dependencies. But this is
usefull only once : when you start using a version. However, the version
checking done by maven is *not* the best. It assumes that everybody use
the same notation. For instance, acme-20020825.jar is seens as newer
than acme-3.0.jar (let say that acme-3.0 was out last month). I'm ok
with that, but then you must have a way to get the control of the whole
process.
>So if we want control we can have it, for both plugin
>repositories and source repositories, right at the
>start of the project and thereafter.
>
>
yeahhhhh !
>If were using Ant - we'd have to tell everyone wanting
>to do a build where to find the dependencies...
>setup the class path, etc. etc. etc. and we could even
>have the ant script download and setup a custom
>repository and classpath, but then we all of a sudden
>have Maven.
>
>
No. That's a misconception of what should be a build. When you are
building a product wich has versions, then whenyou do a checkout, you
*must* (I insist) download all the files, including all the jars, to be
able to build the exact version you want to build. So it's not a
question of using ant or maven, it's a question of being able to build a
version X reliably. That means versionning ALL the files. acme-3.0.jar
should be versionned and tagged with version 1.0 if it is used to build
version 1.0. If you build version 2.0, which use acme-4.0.jar, then this
jar has to be tagged as a member of this build. Maven bring *nothing* to
solve this issue. Maven bring a better structure and transitive
dependencies handling (and these are good thing), that's it. It's not a
way to solve configuration managment which is not handled.
>If Maven had the checksum validation Emmanuel
>mentioned when we listed ways to lock down the build
>process, that's as good as it gets as far as
>validating and using dependencies and plugins goes.
>
>
Yeah, I agree. But checksum validation is only good for people managing
maven repos. We are not managing them, we are using them. And in my
mind, we should only use them once, when we grab our initial jars.
>If only we had a plugin that read the parent pom and
>all the module poms, analyze them, and tell us where
>we used the same dependency, but different version,
>alerted us whenenver a plugin/dependencies checksum
>changed without a version change, and created a report
>detailing all of the automatically updated plugins /
>dependencies - Bravo! We would be in primo condition
>because the build be intelligent, and tell us when
>something unexpected were about to happen, or when
>something could go awry due to the configuration of
>maven.
>
>
You had a dream :)
>So theres obviously some room for improvement, but
>Maven is a brilliant piece of work, and those
>improvements are easy to do with Maven. We just need
>some "Summer of Code" guys. Anyone got connections?
>
>
Maven may be a brilliant piece of software, but, sorry about that, I'm
not intelligent enough to just guess what it does when it goes wild.
Sorry to insist : we have lost 2 hours yesturday with ersin to just
understand what could be the problem with the build when it suddenly
broke because somebody modified a jar somewhere in one unknown repos. At
least, Stefano and other maven guru's helped us to find out a solution.
But I really see it dangerous when a tool need guru's to be used. We are
locked down. I never felt that with ant, and trust me, I'm not a Ant
guru (the less I have to deal with build system, the more happy I'm).
And please don't tell me that ant can't handle big builds, because I
just used it successfully to build a broject with 300 modules, 250
developpers, and the ant scripts were built in 2 weeks, and was handling
transitive dependencies, without the help of ivy. Here, the question is
not if we want to switch to ant, it's "how for christ sake can we have a
*RELIABLE* build with maven.
So let's find solution, because discussion about maven, ant, ivy,
./configure advantages are better in a bar with a lot of beers, and the
place to have them is Austin, october 9-13. Now we just want to have the
best possible maven build for ADS ;)
>OK OK OK - I'll shatt up now and get to work on
>analyzing where to apply our currently known
>solutions.
>
>
Really kool!!!
>Cheers,
>- Ole
>
>
Thanks Ole :)
Emmanuel