I think this is a good idea but we'd need to be able to guarantee
that this is always enabled when -Pbree-libs is disabled.
The reason is there's a few profiles that can be passed such as -Pupdate-branding-plugins,
-Peclipse-sign, -Peclipse-pack etc...
Also passing -Dnative=gtk.linux.x86 for exampled would also
activate another profile for building natives, would this action
deactivate the no-bree-libs profile?
Thanh
On 12/14/2012 04:49 AM, Sievers, Jan wrote:
another simplification proposal:
get rid of "-Pno-bree-libs" in the build instructions. It seems this is only used in
./rt.equinox.bundles/bundles/org.eclipse.equinox.io/pom.xml: <id>no-bree-libs</id>
./rt.equinox.bundles/bundles/org.eclipse.equinox.util/pom.xml: <id>no-bree-libs</id>
for compiling with jsr14 target level (which I think should be removed as well [1] but maybe that's another story).
Instead, we could make these two profiles active by default [2]
<activation>
<activeByDefault>true</activeByDefault>
</activation>
In particular, this means that if another profile is explicitly activated on CLI (such as -Pbree-libs), the no-bree-libs profile is deactivated.
Wdyt?
Jan
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=369145
[2] http://maven.apache.org/guides/introduction/introduction-to-profiles.html
From: cbi-dev-bounces@xxxxxxxxxxx [mailto:cbi-dev-bounces@xxxxxxxxxxx] On Behalf Of Andrew Ross
Sent: Mittwoch, 28. November 2012 17:45
To: Common-build Developers discussion
Subject: [cbi-dev] Proposal to tweak the platform build instructions
Hi Everyone,
This may be a quick thing.
Jan suggests we drop -Dmaven.repo.local=$LOCAL_REPO in our Eclipse platform build instructions.
I agree with this suggestion so it has my +1. My thinking is that anyone who really cares deeply will not be blocked from specifying where their output goes. Casual builders and newcomers don't need to care.
If you would, please let me know where you stand by +1 or -1. If we make it to +4 with no strong objections, I'll make the change.
Thanks,
Andrew
_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cbi-dev
|