You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Danny MacMillan <fl...@nekulturny.org> on 2007/04/13 23:41:42 UTC
Newbie Question: How do I represent my current Ant builds with Maven?
Hi,
I've looked at Maven, read quite a bit of the documentation, and I can't
figure out quite how to represent my current typical Ant build with
Maven. Hopefully someone here can help me.
I write a lot of console utilities in Java. These are comprised of the
original code for the utility, that goes in a jar, 3rd-party libraries
the utility uses, and ancillary files. Today, my typical folder
structure for one of these projects looks like this:
trunk (contains IDE project files, build.xml, build.properties)
trunk/dist (contains content to be deployed 'as is')
trunk/dist/doc (contains product documentation)
trunk/dist/etc (configuration files read at runtime)
trunk/dist/lib (holds 3rd-party jars)
trunk/dist/...
trunk/java (main source code)
trunk/test (test source code)
I have a 'deploy' target in my ant build that
1. copies the contents of 'dist' to a staging area for deployment
2. then compiles the java source into a jar
3. copies the jar to the staging area dist/lib directory
4. zips up the staging area
The product is a zip file I can take to a client's site and deploy by
unzipping and editing a few configuration files (which exist in their
unedited state in trunk/dist/etc) and possibly batch files (which exist
in their unedited state in trunk/dist).
Everything I read about Maven suggests that there should be one build
product per Maven project. Okay, I can see creating a project just for
the jar holding the compiled Java code, but I can't quite wrap my head
around what I'm 'supposed' to do here for the non-Java source files (the
batch files, the configuration files, etc.) Switching to Maven becomes
a non-starter because at a minimum I need to duplicate the functionality
that is currently present in my ant builds.
I would appreciate any guidance or advice you can offer.
--
Danny MacMillan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Newbie Question: How do I represent my current Ant builds with
Maven?
Posted by Danny MacMillan <fl...@nekulturny.org>.
Lacoste, Dana wrote:
> Once again, I'm far from the right person to provide "should" answers to
> this, but as I understand it, maven really wants
> one-pom:one-target:one-build-result-file ratios. As in a single directory
> should build exactly one thing.
>
> BUT
>
> I do this kind of thing in several areas: build a .jar and a .zip that
> packages everything up in the same directory.
>
> So it _can_ be done, but as I understand it, it's not "best practice".
>
> ...
Dana,
Thanks for both of your replies. You've really helped me see that
switching to Maven is an attainable goal, so I've decided to jump in
with both feet. Well, with one foot ... I'm using it on my next project.
I'm going to proceed with the plan to have one Maven project whose build
product is a zip file that contains my jar containing original code,
required 3rd party jars, and ancillary files. It might not be perfect
but I don't currently see any flaws, and the only thing that will let me
see any flaws is experience, and the only way to get experience is to
get started.
--
Danny MacMillan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Newbie Question: How do I represent my current Ant builds with Maven?
Posted by "Lacoste, Dana" <da...@hp.com>.
(extra info deleted to save space)
Once again, I'm far from the right person to provide "should" answers to
this,
but as I understand it, maven really wants
one-pom:one-target:one-build-result-file
ratios. As in a single directory should build exactly one thing.
BUT
I do this kind of thing in several areas: build a .jar and a .zip that
packages
everything up in the same directory.
So it _can_ be done, but as I understand it, it's not "best practice".
The only catch (that I can see) is that the various published elements
have to have
different extensions (or different "<classifier>" tags) so that there's
no naming
conflict.
So it should definitely be possible to do what you want: make your pom
build the .jar,
then add the assembly code and package that up as a .zip and you'd have
both published
to your repository. It will work fine and reliable. But it's not "the
way you're
supposed to do it" if that makes sense....
Dana Lacoste
-----Original Message-----
From: Danny MacMillan
[mailto:flowers~maven.apache.org~users@nekulturny.org]
Sent: Friday, April 13, 2007 3:43 PM
To: Maven Users List
Subject: Re: Newbie Question: How do I represent my current Ant builds
with Maven?
> Something like:
>
> Parent\pom.xml <- placeholder, effectively
> jar1\pom.xml <- generates your .jar
> war1\pom.xml <- generates your .war
> dist1\pom.xml <- generates an assembly putting all the pieces
> together
> dist1\dist.xml <- descriptor
> (http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html)
> dist1\resources <- "flat" files needed in your assembly,
> referred to in the pom
>
Would it be 'wrong' to merge the jar1 and dist1 folders (in your
example) and their corresponding poms together? The rationale for this
question is that the jar being produced is nothing on its own. It's not
a library or a shared component of any kind. Its reason for being is to
provide an executable, which by its nature requires the contents of the
resources directory. My prejudicial response to what you outline is
that it seems kind of complicated, but I'm open minded and happy to
revise my opinion if I understand the value in the split.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Newbie Question: How do I represent my current Ant builds with
Maven?
Posted by Danny MacMillan <fl...@nekulturny.org>.
Lacoste, Dana wrote:
> I'm far from the expert in dealing with this, but Maven's "assembly"
> plugin will do what you need: make your staging area, populate it,
> and zip it up in the end.
>
> We do something similar: I need to produce an "autorun" CD image:
> we build, with each jar having its own directory and maven pom,
> and then a "packaging" pom that just generates .war files, and
> then another "packaging" pom that generates a .zip of the CD image.
>
> (It's much more complex than that in sheer number of components,
> so I can't give you a sample directory structure easily, but
> I'm sure someone else will speak up :)
>
> Something like:
>
> Parent\pom.xml <- placeholder, effectively
> jar1\pom.xml <- generates your .jar
> war1\pom.xml <- generates your .war
> dist1\pom.xml <- generates an assembly putting all the pieces
> together
> dist1\dist.xml <- descriptor
> (http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html)
> dist1\resources <- "flat" files needed in your assembly, referred
> to in the pom
>
> Does that help?
>
> Dana Lacoste
Yes, thanks.
The assembly.html page you reference has certainly changed since the
last time I looked at it. Last time I read it it seemed to suggest
assemblies were for creating different 'views' of the same information
(e.g. a source distribution, a binary distribution, etc.) Now it pretty
plainly says it is the mechanism for doing exactly what I want :) The
documentation on the page looks a lot more complete, too. I had
considered the assembly plugin the last time I looked at this but I
thought it would be counter to the design. It's good to have
confirmation that this is indeed what others are using to achieve this goal.
Would it be 'wrong' to merge the jar1 and dist1 folders (in your
example) and their corresponding poms together? The rationale for this
question is that the jar being produced is nothing on its own. It's not
a library or a shared component of any kind. Its reason for being is to
provide an executable, which by its nature requires the contents of the
resources directory. My prejudicial response to what you outline is
that it seems kind of complicated, but I'm open minded and happy to
revise my opinion if I understand the value in the split.
Thanks for your (astonishingly prompt) answer.
--
Danny MacMillan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Newbie Question: How do I represent my current Ant builds with Maven?
Posted by "Lacoste, Dana" <da...@hp.com>.
I'm far from the expert in dealing with this, but Maven's "assembly"
plugin will do what you need: make your staging area, populate it,
and zip it up in the end.
We do something similar: I need to produce an "autorun" CD image:
we build, with each jar having its own directory and maven pom,
and then a "packaging" pom that just generates .war files, and
then another "packaging" pom that generates a .zip of the CD image.
(It's much more complex than that in sheer number of components,
so I can't give you a sample directory structure easily, but
I'm sure someone else will speak up :)
Something like:
Parent\pom.xml <- placeholder, effectively
jar1\pom.xml <- generates your .jar
war1\pom.xml <- generates your .war
dist1\pom.xml <- generates an assembly putting all the pieces
together
dist1\dist.xml <- descriptor
(http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html)
dist1\resources <- "flat" files needed in your assembly, referred
to in the pom
Does that help?
Dana Lacoste
-----Original Message-----
From: Danny MacMillan
[mailto:flowers~maven.apache.org~users@nekulturny.org]
Sent: Friday, April 13, 2007 2:42 PM
To: users@maven.apache.org
Subject: Newbie Question: How do I represent my current Ant builds with
Maven?
Hi,
I've looked at Maven, read quite a bit of the documentation, and I can't
figure out quite how to represent my current typical Ant build with
Maven. Hopefully someone here can help me.
I write a lot of console utilities in Java. These are comprised of the
original code for the utility, that goes in a jar, 3rd-party libraries
the utility uses, and ancillary files. Today, my typical folder
structure for one of these projects looks like this:
trunk (contains IDE project files, build.xml, build.properties)
trunk/dist (contains content to be deployed 'as is') trunk/dist/doc
(contains product documentation) trunk/dist/etc (configuration files
read at runtime) trunk/dist/lib (holds 3rd-party jars) trunk/dist/...
trunk/java (main source code)
trunk/test (test source code)
I have a 'deploy' target in my ant build that
1. copies the contents of 'dist' to a staging area for deployment
2. then compiles the java source into a jar
3. copies the jar to the staging area dist/lib directory
4. zips up the staging area
The product is a zip file I can take to a client's site and deploy by
unzipping and editing a few configuration files (which exist in their
unedited state in trunk/dist/etc) and possibly batch files (which exist
in their unedited state in trunk/dist).
Everything I read about Maven suggests that there should be one build
product per Maven project. Okay, I can see creating a project just for
the jar holding the compiled Java code, but I can't quite wrap my head
around what I'm 'supposed' to do here for the non-Java source files (the
batch files, the configuration files, etc.) Switching to Maven becomes
a non-starter because at a minimum I need to duplicate the functionality
that is currently present in my ant builds.
I would appreciate any guidance or advice you can offer.
--
Danny MacMillan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org