I am running into an issue. The default profile seems to run even though the property is specified to cause it not to. On the other hand, if I run the command like this then everything works fine: mvn clean install -Pkernel
Unfortunately, this does not meet the needs of the users which will be building this (they need to be able to simply run normal "mvn clean install". You can see the parent pom and there lots of project poms in the directories here: https://source.sakaiproject.org/contrib/caret/kernel/ Help? -AZ On Nov 9, 2007 11:53 AM, Roland Asmann <[EMAIL PROTECTED]> wrote: > 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] > > -- Aaron Zeckoski ([EMAIL PROTECTED]) Senior Research Engineer - CARET - Cambridge University [http://bugs.sakaiproject.org/confluence/display/~aaronz/] Sakai Fellow - [http://aaronz-sakai.blogspot.com/]
