directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole_er...@yahoo.com>
Subject Re: Maven Builds
Date Thu, 31 Aug 2006 15:09:46 GMT
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 <brett.porter@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 <elecharny@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 

Mime
View raw message