[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- From: Markus Alexander Kuppe <ecf-dev_eclipse.org@xxxxxxxxxxx>
- Date: Sat, 02 Oct 2010 08:56:12 +0200
- Delivered-to: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:18.104.22.168) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8
On 10/02/2010 01:02 AM, Scott Lewis wrote:
> Yes, I understand that this the typical case (requires in features being
> same as target platform)...but you are also right that they are distinct
> things...that is, the required plugins in feature.xml end up being in
> the p2 metadata...and that's why I don't really want to have the
> requires be used to set the target platform for compile/build. An
> example of why this doesn't work very well for edge cases is optional
> bundle dependencies...they shouldn't be in requires (for target
> platform), but they *do* need to be present for the compiler.
That's why optional bundles go into the buckminster.cspex of the feature
and not into requires. But org.eclipse.ecf.remoteservices is not an
optional dependency for jms.
> And...I think that the depending upon requires info in features to
> create the target platform makes for an undesirably brittle
> build...because bundles that are statically in the target platform (e.g.
> ECF sdk, or ECF remote services) may be easily and/or appropriately
> *not* in the feature.xml.
I do not agree that this creates a brittle build. The metadata has to be
somewhere, either in a TP or in the feature metadata. And especially a
hard compile dependency should IMO in the same metadata that is also
used by p2.
So again, the answer is buckminster.cpsex and not TPs.
> So in any event...I just would like to have the target platform (for
> build) be defined separately than via contents of feature.xml requires.
1) Check in your TP
2) Clone the logic from the Hudson Template-Build into the JMS build
3) Explicitly set your TP in the build step that also activates the baseline