| Re: [m2e-dev] M2e profile activation and system properties |
My suggestion, fork m2e, make it work for your project(s), then lets
talk about what you've learnt.
My primary concern, but I don't really know, is that it will be very
difficult to manage those properties. Developers will forget to set
them. New developers will now know about them. These properties will
grow into a ritual most will follow blindly without really understanding
what this does and how it works.
Btw, I think it is possible to use setting.xml properties to activate
profiles. I am pretty sure this works for source projects, but if this
works for dependencies, then I think you don't need to change anything
in m2e, just tell your devs to add the properties in their settings.xml.
--
Regards,
Igor
On 2014-09-18, 18:30, Anton Tanasenko wrote:
______________________________________________________________________________________________Hi,
A bit of background.
Maven allows control over which profiles are activated either explicitly
by using -Pprofile1,!profile2, or specifying certain activation
conditions, usually by system properties.
However, there is a subtle difference in how -P and -D profile
activation happens.
-P will only activate profiles on the projects that are being built,
while -D (or any other activation mechanism) will also activate profiles
in dependencies.
Consider an example of three projects A, B and C. A has a profile which
specifies B as a dependency. B has a similar profile with the same id
which adds C as a dependency. Both profiles are also activated by the
same property.
Trimmed output of dep:tree commands:
$ mvn dependency:tree
[INFO] test:a:jar:1.0
$ mvn dependency:tree -Palt
[INFO] test:a:jar:1.0
[INFO] \- test:b:jar:1.0:compile
$ mvn dependency:tree -Dalt
[INFO] test:a:jar:1.0
[INFO] \- test:b:jar:1.0:compile
[INFO] \- test:c:jar:1.0:compile
We have a setup where activating a certain profile results in an
'alternative' build with a different dependency tree.
This is needed for allowing a third party to access a limited set of
codebase. Some artifacts are effectively removed by specifying a dummy
version (empty jar) and some are added.
Now, in M2E explicit profile activation (analogous to -P) works the same
way as in cli, except that you can be more detailed in which profiles
are active for each project.
But the only way I have found to specify profile activation properties
is putting them into eclipse.ini, which is not that easy to force people
to do.
So my question is: what if there was some ui element in m2e preferences
that would allow setting what would be considered
system properties by underlying maven runtime?
Do you know of any potential problems with such a solution?
I do understand that these properties are global, they affect the whole
workspace and changes should trigger full rebuild of all the projects.
--
Regards,
Anton.
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/m2e-dev
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/m2e-dev