OK, so I checked out the sources and re-read your mails a couple of times. My
first suggestion still sounds the most workable solution to your problem,
although I do want to stress that having the parent-POM variable is very
unstable and error-prone.
To be able to activate more profiles, you probably want to configure the POMs
a little different from my example. Let me give it a try (using your example
from the first mail):
Base-POM:
<project>
....
<!-- These modules should ALWAYS build -->
<modules>
<module>api</module>
</modules>
<profiles>
<profile>
<id>basic-impl</id>
<activation>
<property>
<name>impl</name>
<value>basic</value>
</property>
</activation>
<!-- These modules are ADDED to the active module-list
when profile is active -->
<modules>
<module>impl</module>
</modules>
</profile>
<profile>
<id>alternate-impl</id>
<activation>
<property>
<name>impl</name>
<value>alternate</value>
</property>
</activation>
<!-- These modules are ADDED to the active module-list
when profile is active -->
<modules>
<module>alternate-impl</module>
</modules>
</profile>
<profile>
<id>tool</id>
<activation>
<property>
<name>tool</name>
</property>
</activation>
<!-- These modules are ADDED to the active module-list
when profile is active -->
<modules>
<module>tool</module>
</modules>
</profile>
<profile>
<id>test</id>
<activation>
<property>
<name>test</name>
</property>
</activation>
<!-- These modules are ADDED to the active module-list
when profile is active -->
<modules>
<module>test</module>
</modules>
</profile>
</profiles>
....
</project>
Now, you can have parent-POMs that activate none, one or more of these
profiles, eg:
Parent-POM that activates tests on alternate-impl:
<project>
....
<properties>
<impl>alternate</impl>
<!-- The value for test is irrelevant, the property just needs to
exist -->
<test />
</properties>
....
</project>
Parent-POM that activates the tool:
<project>
....
<properties>
<!-- The value for tool is irrelevant, the property just needs to
exist -->
<tool />
</properties>
....
</project>
So, I hope this sorts your problem... You can still combine this with profiles
in the parent-POM, which means you can have a parent-POM that triggers
profile 'alternate-impl' and 'test' when started in parent-profile 'p1'
and 'basic-impl' and 'tool' when started in parent-profile 'p2'.
As I said before I haven't actually tried this sort of activation myself, but
theoretically it should work. Good luck and feel free to contact me (and the
mailing-list) if you need some more help.
On Friday 09 November 2007 11:35, Aaron Zeckoski wrote:
> I think the one thing that would help me to work around the build
> problems we are having would be to simply be able to cause a profile
> to be activated (which is not the default profile) without requiring
> the user who is building it to put in a command line parameter of
> -PprofileId. In fact, even more ideal would be the ability to activate
> multiple profiles at once (again without having to type
> "-Pprofile1,profile2,profile3"
>
> Our current experimental way to get this working using profiles in the
> base POM of one of the many many projects (that all rely on a parent
> POM) is here:
> https://source.sakaiproject.org/svn/content/branches/SAK-12105/pom.xml
>
> -AZ
>
> On Nov 8, 2007 7:52 PM, Roland Asmann <[EMAIL PROTECTED]> wrote:
> > I'm not really sure if I completely understand what you want. I'll check
> > your project out tomorrow at work (have no SVN here) and try and see if I
> > can figure out what you exactly want and how best to solve this.
> >
> > > On Nov 8, 2007 12:43 PM, Roland Asmann <[EMAIL PROTECTED]> wrote:
> > >> Correct me if I'm wrong, but you are changing the parent-pom in you
> > >> projects??
> > >> Doesn't sound like very stable development to me...
> > >
> > > That is correct and you are right, it is not very stable. This is why
> > > I am looking for a better option.
> > >
> > > I think the ideal situation would be if I could have the effect of
> > > typing "mvn -Pmything" without having to put in the -P option. To
> > > instead have the parent POM able to activate a profile. Does anyone
> > > know if that is possible?
> > >
> > > I will try out what you suggested to see what happens.
> > > -AZ
> > >
> > >> Anyway, there is a way to activate profiles based on parent-POMs, it's
> > >> just
> > >> not a very obvious one...
> > >> If you set your profiles to be activated when a specific property is
> > >> set to a
> > >> specific value, you can configure all your profiles as you want and
> > >> set these
> > >> properties with the correct values in the parent-POM.
> > >>
> > >> Example:
> > >>
> > >> <profiles>
> > >> <profile>
> > >> <activation>
> > >> <property>
> > >> <name>parentPom</name>
> > >> <value>firstParent</value>
> > >> </property>
> > >> </activation>
> > >> <modules>
> > >> <module>module1</module>
> > >> </module>
> > >> </profile>
> > >> <profile>
> > >> <activation>
> > >> <property>
> > >> <name>parentPom</name>
> > >> <value>secondParent</value>
> > >> </property>
> > >> </activation>
> > >> <modules>
> > >> <module>module2</module>
> > >> <module>module3</module>
> > >> </module>
> > >> </profile>
> > >> </profiles>
> > >>
> > >> And then in the first parent-POM you define something like:
> > >>
> > >> <properties>
> > >> <parentPom>firstParent</parentPom>
> > >> </properties>
> > >>
> > >> And in the second:
> > >>
> > >> <properties>
> > >> <parentPom>secondParent</parentPom>
> > >> </properties>
> > >>
> > >> Mind you that I haven't tested this, but from normal logic I think
> > >> this should
> > >> work. At least it's worth a try, 'cause you don't need to trigger the
> > >> profiles from the commandline this way.
> > >>
> > >> Oh, and in case I misunderstood your problem and therefore this is not
> > >> a solution to it, please feel free to post again and help me
> > >> understand better. ;-)
> > >>
> > >> On Thursday 08 November 2007 11:59, Aaron Zeckoski wrote:
> > >> > I am trying to build a limited set of modules based on the parent
> > >> > pom file being used. I tried using profiles but there does not seem
> > >> > to be a way to trigger a profile based on the parent POM. Here is
> > >> > the scenario I am trying to figure out. I have a project base POM
> > >> > which has a number of modules. I want to build various subsets of
> > >> > those modules depending on a setting in the parent POM for this base
> > >> > POM.
> > >> >
> > >> > Here is a sample base POM:
> > >> > <modules>
> > >> > <module>api</module>
> > >> > <module>impl</module>
> > >> > <module>tests</module>
> > >> > <module>alternate-impl</module>
> > >> > <module>tool</module>
> > >> > </modules>
> > >> >
> > >> > I would like to build just the api and impl modules in circumstance
> > >> > one (services only).
> > >> > <modules>
> > >> > <module>api</module>
> > >> > <module>impl</module>
> > >> > </modules>
> > >> >
> > >> > I would like to optionally add in the tests module and/or the tool
> > >> > module to include the tests or the webapp.
> > >> > <modules>
> > >> > <module>api</module>
> > >> > <module>impl</module>
> > >> > <module>tool</module>
> > >> > </modules>
> > >> >
> > >> > I would also like to be able to specify that I need to use an
> > >> > alternate implementation of the service in place of the current impl
> > >> > when the service is built.
> > >> > <modules>
> > >> > <module>api</module>
> > >> > <module>alternate-impl</module>
> > >> > <module>tests</module>
> > >> > </modules>
> > >> >
> > >> > The final key here is that the parent POM for this project base POM
> > >> > will change depending on which set of source code is checked out.
> > >> > Currently we have one parent POM which includes all the base POMs
> > >> > for all central services and then one which includes modules for all
> > >> > the optional services. This has a huge limitation in that we have
> > >> > redefine base poms for all the core services to exclude the
> > >> > accompanying webapps and tests. I would ideally like to automate
> > >> > this since currently we have to maintain huge lists of modules in
> > >> > both (soon to be three) the parent POMs.
> > >> >
> > >> > It looks like I can accomplish this via profiles, except that those
> > >> > require lots of command line parameters. Is there a way to do this
> > >> > where the user would not have put a huge number of command line
> > >> > paramters down or am I stuck maintaining multiple parent POMs with
> > >> > huge lists of modules and multiple base POMs for each project?
> > >> >
> > >> > Open to suggestions about restructuring the project layout as well.
> > >> > Here is an example of one version of parent POM and a set of base
> > >>
> > >> POMs:
> > >> > https://source.sakaiproject.org/svn/cafe/trunk/
> > >> >
> > >> > -AZ
> > >>
> > >> --
> > >> Roland Asmann
> > >>
> > >> CFC Informationssysteme Entwicklungsgesellschaft m.b.H
> > >> Bäckerstrasse 1/2/7
> > >> A-1010 Wien
> > >> FN 266155f, Handelsgericht Wien
> > >>
> > >> Tel.: +43/1/513 88 77 - 27
> > >> Fax.: +43/1/513 88 62
> > >> Email: [EMAIL PROTECTED]
> > >> Web: www.cfc.at
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >> For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > > --
> > > Aaron Zeckoski ([EMAIL PROTECTED])
> > > Senior Research Engineer - CARET - Cambridge University
> > > [http://bugs.sakaiproject.org/confluence/display/~aaronz/]
> > > Sakai Fellow - [http://aaronz-sakai.blogspot.com/]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
--
Roland Asmann
CFC Informationssysteme Entwicklungsgesellschaft m.b.H
Bäckerstrasse 1/2/7
A-1010 Wien
FN 266155f, Handelsgericht Wien
Tel.: +43/1/513 88 77 - 27
Fax.: +43/1/513 88 62
Email: [EMAIL PROTECTED]
Web: www.cfc.at
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
