I agree, I think the best option for 2.0.x is to keep the current profile
behaviour, with the working profile deactivation.
I like the idea of being able to use "+myProfile" to add a profile without
deactivating the deafault profiles. But for 2.0.x I think we should just leave
the current behaviour because:
1. The change would require some changes to the ProfileManager interface and
more changes to the DefaultProfileManager should probably wait until 2.1.
2. I see the "+" option as low priority because there is an easy workaround of
just specifying all the profiles that you want active.
For 2.1 maybe we can add an optional groupId to the profile config like you
suggested.
As far as reducing the overall need for profiles maybe being able to more easily
control the build lifecycle would help. For example, if there was an easy way
to tell the build to skip a certain phase or skip certain plugins or executions,
that might cover some profile use cases.
Brian E. Fox wrote:
I think we should maintain the current functionality of a default deactivating
when another profile in the pom is activated until there is a syntax to perform
the same. I have often in the past done things like: (pseudo pom code)
<profile>
<id>all</id>
<activeByDefault>true</activeByDefault>
<modules>
<module>a</module>
<module>b</module>
<module>c</module>
...
<profile>
<id>a</id>
<modules>
<module>a</module>
Etc and the activation would be mvn xxx -Pa and the expectation is you only build a...retraining everyone to say -Pa,!all is a bit much.
To accomplish this correctly, you would need to add a profile group id and if
nothing is there, then the explicitly share the same group, thus preserving
backwards compat while giving a bit more flexibility.
I do share Jesse's sentiment about maybe we are missing something else. If
there's anything in the pom that reduces clarity, it is definitely profiles.
--Brian
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jesse McConnell
Sent: Thursday, May 15, 2008 11:37 AM
To: Maven Developers List; [EMAIL PROTECTED]
Subject: Re: Profile activation/deactivation
No one can dispute the nice things that profiles let us accomplish in
terms of toggling on functionalities...
But I wonder much this will impact build reproducibility....especially
given the existence of profiles in the settings.xml file. It is
already a source of minor pain where people need to pass around
fragments of profiles to get their builds (or releases) working. I
wonder how much making it easier to toggle on and off profiles will
impact the future of these sorts of practices.
I already have to edit my settings.xml file and comment in and out a
certain profile if I want to deploy something from one place or
another. I could override on the cli but thats a big pita as well.
John and I talked ages ago about how profiles were basically a hack
and black magic in what they allowed people to do with any given
build. Seeing all of these +/-/D:/E:/! goop floating around seems to
be increasing the black magic. I am torn though, profiles have helped
me immeasurably in the past...even if they made me feel a touch dirty
in the process.
Are we missing a chance to codify some other sort of functionality
that keeps build reproducibility at the forefront? And by build
reproducibility I mean out of the box, not after cut and pasting magic
chunks of stuff around behind the scenes.
anywho, figured I would throw that out.
jesse
On Thu, May 15, 2008 at 10:16 AM, Ralph Goers
<[EMAIL PROTECTED]> wrote:
+1. My first reaction though was the thought, what should -P-profile do? Is
it confusing not to have it if + is supported? Would it be the same as
-P!profile?
Bernhard David wrote:
would it be possible to have "-Pprofile" work as usual (activate
profile, deactivate defaults) but "-P+profile" add profile to the
existing ones, without deactivating defaults? Or if "+" is taken we
could use some other character.
In any case it would be really useful to add profiles like this, for
instance to support "mvn install -P+optionalTests" without having to
figure out what other profiles you need manually.
Greetings,
David Bernhard
---------------------------------------------------------------------
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]
