maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Migrating to Maven
Date Thu, 07 Apr 2005 20:53:56 GMT
just one persons opinions...
On Apr 7, 2005, at 11:33 AM, Anil Arora wrote:

> I'm currently doing a small evaluation of maven for our build
> environment.  However, I'm having some issues with mapping how we
> currently doing things to how maven does things.  So I'm hoping that
> someone out there may have some good ideas on how we could migrate to
> maven without completely changing what we do.
>
>
>
> One of the main goals of our build environment is that the developer
> should only have to do minimal work to get up and running.  Meaning
> after syncing the source tree, he/she should be able to build quickly
> and simply just run our application.  Another goal is that the same
> buildsystem should be used for the release builds which occur every
> night and the continuous builds that happen every 10 minutes.
>
>
>
> Our current build environment is built using ANT.  So, this is the
> current view on how things are currently laid out.
>
>
>
> /
>
> +-- base/util
>
>     +-- src
>
>     +-- src_generated
>
>     +-- test
>
>     +-- resource
>
>     +-- classes
>
>     +-- test-classes
>
> +-- base/main
>
>     +-- src
>
>     +-- test
>
>     +-- resource
>
> +-- site1
>
>     +-- src
>
>     +-- test
>
>     +-- resource
>
> +-- site2
>
>     +-- src
>
>     +-- test
>
>     +-- resource
>
> +-- install
>
>     +-- bin
>
>     +-- lib
>
>     +-- internal
>
>         +-- bin
>
>         +-- lib
>
> +-- build
>
>
>
>
>
> Each component looks pretty much the same (which is why maven is so
> attractive to use).
>
> src is the main source directory, test is the test source directory.
> Resource contains other artifacts that are placed in the resulting
> image.  Src_generated is where generated files (antlr, castor, etc.) 
> are
> placed.  Classes and test-classes are where the classes files are
> generated.
>
> Install is the image directory which contains the entire application
> after a build.  Build contain any temporary build files.  Under 
> install,
> we have an internal directory which is used for image files that are 
> not
> necessarily meant for production, but for testing, etc.  The idea of 
> the
> image directory is a self contained application which can be zipped up,
> sent to a machine or QA user, unzipped, and tests run.
>
>
>
> In my above example, I have site1 and site2.  The developer has a
> setting somewhere where it tells the build only build one of these, not
> both.  In our nightly builds, we'll build the application for
> site1...and then we'll build the application for site2.  We have
> separate images for them.
>
>
>
> So, after playing with maven last night, I've generated a nice long 
> list
> of questions, many I couldn't find answers for.
>
>
>
> First, I would like to see what people's first impressions are.  Have
> other people tried to adopt maven in a similar way and 
> succeeded/failed?

I converted a project sort of like this, it went ok.  I strongly 
recommend moving your source to conform to maven standards.  You may 
object now but it will save lots of hassles later.
>
>
>
> I'm guessing I need some sort of master project file that will drive 
> the
> sub projects.  I was looking at the multiproject plug-in.  This seemed
> to be something that I needed to use.  But it seems like I need finer
> grain control on what order the projects are compiled in.
>
>
Use dependencies to control the order in which subprojects are built.
>
> If I encounter a case where there is a third party jar file is not in
> ibiblio or an online repository, what is the recommended procedure?
>
create your own company-wide repository.  After some experience with 
ibiblio you may want to do this anyway for all the external 
dependencies you use.
>
>
> How can I build a jar without the version number?  I don't really care
> about the version number.  The entire image is versioned.  Actually, 
> how
> do I strip out the version numbers from the third-party jar files.  We
> don't care for this and it actually makes our lives harder when we do
> patching.  We'd have to remove the old jar files and add the new ones.
> In our current environment, we just simply overlay the jar file and
> restart the application.
>
How do you know what versions of what are being used in a particular 
installation?
The best way IMO is to change your thinking and use version numbers for 
everything.  If there's something that needs a list of jars in it such 
as a manifest class path, construct it with symbol replacement from a 
properties file that contains the current version numbers.
>
>
> How do I tell maven to place all of the jar files under the image
> instead of some unknown location?
>
not quite sure what you mean here... its pretty easy to add jelly code 
to maven.xml to e.g. copy marked dependencies into a specific location 
in a target directory.
>
>
> How do I handle third party components that contain other artifacts?
> For example, we use the tomcat embed component.  This is not only the
> jar files, but contains configuration information as well.
>
>
If it comes as a zip file you can list the zip as a dependency and 
unpack it into an appropriate location.
>
> Documentation is a bit tricky.  Remember I was talking about how some
> subprojects are selectively built (site1, site2, etc.)?  For the
> internal site documentation, I want all generated.  For external
> documentation, only the site that is being built should be created.   I
> want to place all of the javadoc in the image as part of our
> documentation set.
>
> I don't want documentation to be generated in the developer's
> environment.  It adds too much time to the build.
>

I don't know much about doc generation- I never generate it.
>
>
> At the end of the nightly build, we need to zip up everything and put 
> it
> on the repository.
>
I think there's a dist plugin, although I've used jelly + ant jar for 
similar purposes.
>
>
> I'm hoping that maven provides something useful for us and doesn't turn
> out just to be a theoretical exercise.  Right now, it feels like maven
> doesn't have exactly what I need.  I'm hoping that someone could prove
> me wrong.
>
IMO, the more you adopt the recommended maven practices the more 
benefit you will get from maven.

hope this helps
david jencks

>
>
> Thanks,
>
> Anil
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message