Re: Generating Config Files for multi-module project

Mon, 28 Mar 2011 05:56:27 -0700 

This is a good way to structure the project.
Using profiles to select files and modify configuration properties is not a good idea and it seems that most of the time it causes a great deal of frustration and lost time before they are abandoned. 


You may find it easier to have a project for each configuration and just 
have a batch script that builds all of the configurations once you have 
the core tested.



Profiles seem to be very single-minded and do not take well to bending, 
folding or other forms of mutilation that people try to do to put 
environment specific stuff into deliverables.
Don't spend a lot of time tweaking profiles and trying to make them work 
before asking questions.
I lot of people spend days screwing about before giving up because 
profiles can not be bent to their purpose.



Sometimes the old fashioned approach that seems inelegant is better that 
the latest technology misapplied to the problem.

Maven does work from the command line.

Ron


On 28/03/2011 12:57 AM, Lee Meador wrote:

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







---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org























					Reply via email to