Thanks, Anthony. This was very helpful. I've started a prototype of a maven build environment on top of our existing one. My goal is to not change anything, with the exception of a few minor tweaks. Moving src files around is not much of an option right now.
I also did a bit of searching to look for an example of an application built using maven, versus a library. The only one I have looked at is cruisecontrol itself, since I had that handy. I would be curious to see if someone used maven to build tomcat because that's a complicated application with a lot of artifacts, distribution, etc. I'm actually quite disappointed with the artifact management stuff. Yes, the whole downloadable thing is nice. But projects always contain more than one artifact. Ant itself contains multiple jar files. It seems like a pain for me to have to create a dependency for each jar file for a dependent application. And with multiproject, the dependency version should be centralized. I guess the only way to do this is to use the jar override mechanism. Also, I cannot figure out how to correctly get the dependencies between projects to work. It's says it cannot download the jar file. I don't want this to sound like I'm criticizing Maven too much, because I believe that the intentions are good. Just needs a bit more work. I really like the multiproject site generation. Actually, that's the main reason for me looking at Maven at this point. I'll have to figure out how to combine all of the javadocs together for distribution (internal/external). Anil -----Original Message----- From: Roy, Anthony [mailto:[EMAIL PROTECTED] Sent: Friday, April 08, 2005 1:51 AM To: Maven Users List Subject: RE: Migrating to Maven > 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? We have been using Maven now for around 5 months. It was easy to get started with, and requires a lot less work to set up than an Ant project (we had our own Ant build system with lots of default targets for common tasks, almost all of which have been made redundant with the switch to Maven. The dependency resolution, while not perfect, was a HUGE incentive for us - it makes starting new projects so much easier, as well as updating libraries in existing projects, and managing inter-project dependencies. > 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. The muli-project plugin looks through the list of dependencies in each project, and makes sure that projects get built in the correct order (i.e. a project will be built after its dependencies). If you *do* need finer control than that, you can create a new goal in your maven.xml, perhaps using the reactor jelly tag to get whatever control you need. It is considered best practice though to get your projects using as little customisation as possible in the maven.xml, since it reduces maintenance cost. > 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? Copy the jar into an appropriate directory structure in your global repository (or local repo if you haven't got a global one set up). For example we have the javamail jar in the javamail/jars/ directory of the repo, with the filename javamail-1.3.2.jar. This is then referenced by the dependency <dependency> <groupId>javamail</groupId> <artifactId>javamail</artifactId> <version>1.3.2</version> </dependency> > 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. Set up a post-goal to jar:jar in the maven.xml to rename the jar: <postGoal name="jar:jar"> <move file="${maven.build.dir}/${maven.final.name}.jar" tofile="${maven.build.dir}/${name}.jar"/> </postGoal> Do something similar for the third party jars assuming you have some sort of pack goal set up (we actually have a maven plugin set up that we use to build all distributions - the best approach if you are going to be using the same custom goals for different projects). > How do I tell maven to place all of the jar files under the > image instead of some unknown location? We found that the smoothest way to use Maven was to use the standard setup, which is not very much different from the setup you already have. For example: +- base/util +- src +- java +- test +- config +- target +- xdocs The source along with any specified config files get comiled and placed in the target dir, as do any jars created. If you wanted to move all files to your image directory, then a custom goal in a plugin would probably be the best approach (see the example above.) > 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. ? > 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. All docs are currently built into the maven format in the target directory. You could move the ones you want to your target using a custom goal. Build internal docs using the multi-goal project. Build external docs using just site:deploy on the project in question. > I don't want documentation to be generated in the developer's > environment. It adds too much time to the build. When you are developing in maven, you only need to call the goals you need at the time. So don't call site:generate. > At the end of the nightly build, we need to zip up everything > and put it on the repository. > > > > 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. It looks like maven has just what you want in terms of automated build, but with some gaps. This is normal - it would be weird indeed if everyone had exactly the same requirements when building a project! All you need is the addition of a custom plugin (which is only a matter of writing a simple jelly script called plugin.jelly in the same style as the maven.xml file - basically an Ant script but using goal instead of target!) containing a handful of simple goals, it would do everything your Ant based environment can do but with less effort. Always remember that Maven can utilise Ant scripts in its plugin.jelly or maven.xml files - hence it can do everything that Ant can do, with the added bonus of managing dependencies for you. It may be possible to modify the way you're current build system works (i.e. directory structure) to reduce the amount of customisation necessary, but from what I can see your custom goals in the plugin are going to be pretty simple <copy> and <move> Ant tasks, and perhaps the use of the reactor. An example from out build system, when only a subset of the subprojects need to be built: <maven:reactor basedir="${basedir}" includes="**/project.xml" excludes="project.xml,order/project.xml,wxl/arp/project.xml,wsdl/project .xml" goals="clean:clean,jar:install" banner="Building" ignoreFailures="false"/> Hope this was useful to you. -- Anthony Roy. The British Library ************************************************************************ ** Experience the British Library online at www.bl.uk Help the British Library conserve the world's knowledge. Adopt a Book. www.bl.uk/adoptabook ************************************************************************ * The information contained in this e-mail is confidential and may be legally privileged. It is intended for the addressee(s) only. If you are not the intended recipient, please delete this e-mail and notify the [EMAIL PROTECTED] : The contents of this e-mail must not be disclosed or copied without the sender's consent. The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the British Library. The British Library does not take any responsibility for the views of the author. ************************************************************************ * --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
