Maybe it could work this way: The parent project has the normal "modules" section saying to build all the jars, the war, the config files the installer results and several others for each Zip file created.
I'm going to assume you want to create a zip file with the war, the installer and the config files in it. Make that zip file's project depend on the war project, the installer project and a "config" project. The parent pom will use profiles to set values for properties that are used in the "config" project to filter and/or transform to create the right versions of the config files. The config project will hold the template xml files used to create the config files. I think it will be a pom artifact. It will use a bit of ant (or some other plugin) to do the xslt part. The result files can be filtered by the assembly plugin if you like. The resulting artifacts can go independently in the same spot in the local repo if you use the plugin that allows setting multiple result artifacts (like a single pom cat send a jar, test-jar, javadocs and source jars all in one install. Then the zip file project will use the assembly plugin to collect the war file, the installer file and the already created config files and zip them up. I'm not sure how you tell it to collect all those files from the local repo. If all else fails you can put them all as compile dependencies and use the property maven creates with the names of all the dependencies in it. That's sort of a unnatural act though, so be careful. Of course, it could be I'm misunderstanding your question. I understand it to say that you build a set of artifacts (zip files, war files, install files, etc) that correspond to one scenario when you run mvn one time. That means that some properties can be set inside profiles in the parent pom as the build starts and those properties can be used during the build to control which optional stuff happens. -- Lee On Sun, Mar 27, 2011 at 10:02 AM, Adam Retter <adam.ret...@googlemail.com>wrote: > Is there a way to do this without using settings.xml, I really want to > make this as easy as possible for our other developers i.e. have > everything in the pom.xml or project files. > > On 27 March 2011 16:33, Martin Gainty <mgai...@hotmail.com> wrote: > > > > the output of the xslt transform will generate filter.properties which > identifyies the transformed files to be read in by each child module > > then setup peofiles in each child (module) pom react to profiles to set > the exact location_of_filter parameter > > > > %USER_HOME%/.m2/settings.xml > > <settings> > > ... > > <profiles> > > <profile> > > <id>location_of_filter1</id> > > <properties> > > > <location_of_filter>/src/assemble/filter.properties</location_of_filter> > > </properties> > > </profile> > > <profile> > > <id>location_of_filter2</id> > > <properties> > > > <location_of_filter>/src/assemble/filter2.properties</location_of_filter> > > </properties> > > </profile> > > <profile> > > </profiles> > > > > <activeProfiles> > > <activeProfile>location_of_filter1</activeProfile> > > </activeProfiles> > > ... > > </settings> > > > http://maven.apache.org/guides/introduction/introduction-to-profiles.html > > <!-- then your local pom.xml will have profiles which will detect the > location_of_filter property --> > > > > <profiles> > > <profile> > > <id>location_of_filter1</id> > > <build> > > <plugins> <plugin> > > <artifactId>maven-assembly-plugin</artifactId> > > <version>2.2.1</version> > > <executions> > > <execution> > > <phase>package</phase> > > <goals> > > <goal>run</goal> > > </goals> > > <configuration> > > <filters> > > <filter>${location_of_filter}/filter.properties</filter> > > </filters> > > <configuration> > > </configuration> > > </plugin> > > </plugins> > > </profile> > > <profile> > > ................ > > </profile> > > </profiles> > > > > > > > http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/filtering-some-distribution-files.html > > Martin > > ______________________________________________ > > Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité > > > > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene > Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte > Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht > dient lediglich dem Austausch von Informationen und entfaltet keine > rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von > E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. > > Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas > le destinataire prévu, nous te demandons avec bonté que pour satisfaire > informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie > de ceci est interdite. Ce message sert à l'information seulement et n'aura > pas n'importe quel effet légalement obligatoire. Étant donné que les email > peuvent facilement être sujets à la manipulation, nous ne pouvons accepter > aucune responsabilité pour le contenu fourni. > > > > > > > > > >> Subject: Re: Generating Config Files for multi-module project > >> From: topp...@codehaus.org > >> Date: Sat, 26 Mar 2011 15:05:08 -0400 > >> To: users@maven.apache.org > >> > >> It sounds like you are mostly stuck on the config files issue so I'll > focus on that. Ron already answered this, but I had this typed and didn't > send it for some reason. I'm basically repeating what he's already said. > >> > >> I would organize the config files into a separate top-level project, > then have these other projects depend on it. The output of this project > will be your config files as a jar, but I would suggest not worrying about > that in the config file build. The m2 repo needs to have a single artifact > per build, and it does not make sense to have one build per config file, if > you see what I mean. > >> > >> So what you would do here is use the assembly plugin to extract the > config files you need from the config file artifact jar for each specific > product scenario. If there are separate POMs for each product scenario, you > could copy the plugin to each module with a separate <configuration> element > for the file selection used by that specific product. > >> > >> Or you could put the assembly plugin in a parent build one time, but > have it rely on <properties> elements in the child build. In this manner, > product scenarios share a common POM with the single assembly plugin, but > each child POM has the specific config files listed. > >> > >> There's probably other ways to accomplish this, but that's the path I > would go if I were doing it. > >> > >> Brian > >> > >> On Mar 26, 2011, at 12:15 PM, Adam Retter wrote: > >> > >> > Hi there, > >> > > >> > I am trying to migrate a complex Ant setup to Maven and need some help > >> > about how we can share our config files. > >> > > >> > I have a series of Maven project modules that make up the Jar files > >> > for my project. I also need to produce several end product scenarios - > >> > > >> > 1) A WAR file for users to deploy in Tomcat etc. > >> > 2) A IzPack installer distribution (I have seen the IzPack plugin). > >> > 3) Several Zip file distributions, various combinations of the output > >> > of my maven modules. > >> > > >> > I understand that I can create a Maven module to produce each of > >> > these, and that is indeed my intention. > >> > > >> > However, I have some common config files etc that I need to > >> > incorporate into each of these final product scenarios. > >> > So my question is, where can I keep these config files??? > >> > > >> > I would like to have one atomic version of them, that can be reused by > >> > each scenario, some sort of dependency. To complicate things - > >> > 1) These config files typically are generated from template XML files > >> > using XSLT, with some parameters injected into the XSLT depending on > >> > the scenario. > >> > 2) These config files need to be easily modified by our end-users, who > >> > use our product scenarios, so packaging them into Jar files is a not a > >> > good idea. > >> > > >> > Thanks Adam. > >> > > >> > > >> > > >> > -- > >> > Adam Retter > >> > > >> > skype: adam.retter > >> > tweet: adamretter > >> > http://www.adamretter.org.uk > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> > For additional commands, e-mail: users-h...@maven.apache.org > >> > > >> > > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > > > > > > -- > Adam Retter > > skype: adam.retter > tweet: adamretter > http://www.adamretter.org.uk > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- -- Lee Meador Sent from gmail. My real email address is lee AT leemeador.com
