Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

The best way to break a fundamental principle of Maven

 
Leroy J Brown
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm going to be taking over the development architecture of a large enterprise java application and would like to migrate this application to Maven asap as dependency management is currently very complex. This will be my first real project with Maven, though I have a little bit of experience using it to build instructional applications from books on Spring etc.

Our application currently builds using a large set of Ant scripts via CruiseControl and there are two different outputs:

1) The WARs, EARs etc which are deployed automatically on build to our development environment

2) Deployment packages (tarred deployable assets and deployment scripts) which are stored as artifacts and handed off to our middleware team for deployment to our upper environments

In this scenario it would seem reasonable to me to have one project with two outputs but I'm not sure if "one project one output" is a maven best practice or something you cannot avoid in maven. I wouldn't want to make the entire rest of the lifecycle run just to create a deployment package (especially since I would like to use a previously generated artifact in the deployment package, not a newly created one.)

Any suggestions on how to structure something like this in Maven2?

Thanks.
 
Chris Hurd
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I suggest not trying to redo what your ant script already does in maven if it currently works, just so you can add dependency management. Take a look at http://ant.apache.org/ivy/ it provides the dependency management of maven but integrates nicely with ant.

Chris Hurd
 
Leroy J Brown
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I appreciate the advice. Actually dependency management is not the only issue I'm attempting to address with Maven. I also think it likely quite a bit of the existing ant tasks for very specialized behavior (including building the deployment packages) will still be used, bound to project's goals, but I'd like to use Maven for the overall framework.

Is it possible to specify a goal in a custom build life cycle outside of the standard one (which I would plan to use for #1 above), so that a project would have multiple life cycles, or is there another way to accomplish what I'm attempting to here?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic