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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to