Re: Newbie Question: How do I represent my current Ant builds with Maven?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Newbie Question: How do I represent my current Ant builds with Maven?
(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 "" 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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Newbie Question: How do I represent my current Ant builds with Maven?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Newbie Question: How do I represent my current Ant builds with Maven?
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:[EMAIL PROTECTED] Sent: Friday, April 13, 2007 2:42 PM To: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]