Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Plugin Development Environment (PDE) » How to include binary bundles from "pluginPath" in feature output?
How to include binary bundles from "pluginPath" in feature output? [message #41664] Thu, 22 January 2009 21:05 Go to next message
Eclipse UserFriend
Originally posted by: mark_melvin.amis.com

Hi,

I have a continuous integration server building all of my plugins
separately, and I am now using those plugins to build the features. I
supply all dependencies in binary form and point to them using the
"pluginPath" attribute of the eclipse.buildScript Ant target. This all
works great and my feature is built with all of the appropriate version
numbers substituted. However, I can see of no way to easily package up
the features and plugins that were dependencies of the feature I just
built. I am trying to make an update site zip of all features and plugins
included in the feature I am building and it looks impossible without
ripping apart the feature.xml myself to find everything (and doing this
recursively to find dependencies of nested features).

Am I missing something here? Is there a magical flag I can pass
eclipse.buildScript that will include all children - even if they were
pre-build binaries on the pluginPath?

While I'm on the topic - what the heck is "filteredDependencyCheck"
supposed to achieve? I have tried setting this property both ways and it
appears to do nothing in my situation. The docs mention that it is
"optional, constraint the set of plug-ins and features to be considered
during the build to those reachable from the features" - but I still have
yet to figure out what that means.

Thanks,
Mark.
Re: How to include binary bundles from "pluginPath" in feature output? [message #42125 is a reply to message #41664] Fri, 23 January 2009 16:05 Go to previous messageGo to next message
Andrew Niefer is currently offline Andrew NieferFriend
Messages: 990
Registered: July 2009
Senior Member
Mark,
Where the features are coming from (pluginPath, buildDirectory,
baseLocation) has no affect on whether they show up in the results. The
key here will be the different between source and binary.

Creation of the final archives happens in 2 parts, "assemble" and
"package". The assemble phase gathers all the features and plugins that
were built from source, the package phase gathers all the ones that were
binary to start with. The package phase only runs if your builder
defines the property "runPackager=true". I expect you are missing this
property.

As for the filteredDependencyCheck, by default PDE/Build will consider
all features and plugins it can find in the pluginPath, buildDirectory
and baseLocation, (and potentially even link files, platform.xml,
bundles.info and dropins from the baseLocation). You can imagine
perhaps having one target that is used to build several different
versions of a product. So there could be multiple versions of some
singleton bundle in that target. Of course only one of those versions
can be resolved.

"filteredDependencyCheck" filters the set of plugins to include only
those in the transitive closure of includes and requires from the top
level feature being built. This way, different versions of a product
could filter out different versions of singleton bundles from the state.
This is just one example of reasons why you may want to filter the state.

Note however that this feature is not commonly used and there are a few
bugs here that were found and fixed in 3.5 (247027, 247007, 260763)

-Andrew

Mark Melvin wrote:
> Hi,
>
> I have a continuous integration server building all of my plugins
> separately, and I am now using those plugins to build the features. I
> supply all dependencies in binary form and point to them using the
> "pluginPath" attribute of the eclipse.buildScript Ant target. This all
> works great and my feature is built with all of the appropriate version
> numbers substituted. However, I can see of no way to easily package up
> the features and plugins that were dependencies of the feature I just
> built. I am trying to make an update site zip of all features and
> plugins included in the feature I am building and it looks impossible
> without ripping apart the feature.xml myself to find everything (and
> doing this recursively to find dependencies of nested features).
>
> Am I missing something here? Is there a magical flag I can pass
> eclipse.buildScript that will include all children - even if they were
> pre-build binaries on the pluginPath?
>
> While I'm on the topic - what the heck is "filteredDependencyCheck"
> supposed to achieve? I have tried setting this property both ways and
> it appears to do nothing in my situation. The docs mention that it is
> "optional, constraint the set of plug-ins and features to be considered
> during the build to those reachable from the features" - but I still
> have yet to figure out what that means.
>
> Thanks,
> Mark.
>
Re: How to include binary bundles from "pluginPath" in feature output? [message #42240 is a reply to message #42125] Fri, 23 January 2009 19:05 Go to previous message
Mark Melvin is currently offline Mark MelvinFriend
Messages: 118
Registered: July 2009
Senior Member
Hi Andrew,

Thanks for the valuable response. You are correct - I am not running the
packager. I actually am executing targets from the generated build.xml
and not really using the full PDE at all. I tried calling bits from the
generated assemble and package scripts but they seem to depend too much on
being run in the context of a full PDE build and I currently don't run
things that way (and to be honest, I don't really intend to either...;).
What I have now pretty much works and requires much less configuring. I
just need to do a little more packaging on my end. At any rate - I think
I can use the dependency management I have configured in my build system
to achieve what I need here, with some Ant scripting.

The stuff on filteredDependencyCheck is useful to know. That's kind of
how I thought it worked, but I thought that setting it avoided the
"transitive" part of the dependency check for some reason, and testing
(along with your response!) tells me that it doesn't. I understand what
it is for now.

Thanks very much,
Mark.

On Fri, 23 Jan 2009 11:05:33 -0500, Andrew Niefer <aniefer@ca.ibm.com>
wrote:

> Mark,
> Where the features are coming from (pluginPath, buildDirectory,
> baseLocation) has no affect on whether they show up in the results. The
> key here will be the different between source and binary.
>
> Creation of the final archives happens in 2 parts, "assemble" and
> "package". The assemble phase gathers all the features and plugins that
> were built from source, the package phase gathers all the ones that were
> binary to start with. The package phase only runs if your builder
> defines the property "runPackager=true". I expect you are missing this
> property.
>
> As for the filteredDependencyCheck, by default PDE/Build will consider
> all features and plugins it can find in the pluginPath, buildDirectory
> and baseLocation, (and potentially even link files, platform.xml,
> bundles.info and dropins from the baseLocation). You can imagine
> perhaps having one target that is used to build several different
> versions of a product. So there could be multiple versions of some
> singleton bundle in that target. Of course only one of those versions
> can be resolved.
>
> "filteredDependencyCheck" filters the set of plugins to include only
> those in the transitive closure of includes and requires from the top
> level feature being built. This way, different versions of a product
> could filter out different versions of singleton bundles from the state.
> This is just one example of reasons why you may want to filter the
> state.
>
> Note however that this feature is not commonly used and there are a few
> bugs here that were found and fixed in 3.5 (247027, 247007, 260763)
>
> -Andrew
>
> Mark Melvin wrote:
>> Hi,
>> I have a continuous integration server building all of my plugins
>> separately, and I am now using those plugins to build the features. I
>> supply all dependencies in binary form and point to them using the
>> "pluginPath" attribute of the eclipse.buildScript Ant target. This all
>> works great and my feature is built with all of the appropriate version
>> numbers substituted. However, I can see of no way to easily package up
>> the features and plugins that were dependencies of the feature I just
>> built. I am trying to make an update site zip of all features and
>> plugins included in the feature I am building and it looks impossible
>> without ripping apart the feature.xml myself to find everything (and
>> doing this recursively to find dependencies of nested features).
>> Am I missing something here? Is there a magical flag I can pass
>> eclipse.buildScript that will include all children - even if they were
>> pre-build binaries on the pluginPath?
>> While I'm on the topic - what the heck is "filteredDependencyCheck"
>> supposed to achieve? I have tried setting this property both ways and
>> it appears to do nothing in my situation. The docs mention that it is
>> "optional, constraint the set of plug-ins and features to be considered
>> during the build to those reachable from the features" - but I still
>> have yet to figure out what that means.
>> Thanks,
>> Mark.
>>
Re: How to include binary bundles from "pluginPath" in feature output? [message #590373 is a reply to message #41664] Fri, 23 January 2009 16:05 Go to previous message
Andrew Niefer is currently offline Andrew NieferFriend
Messages: 990
Registered: July 2009
Senior Member
Mark,
Where the features are coming from (pluginPath, buildDirectory,
baseLocation) has no affect on whether they show up in the results. The
key here will be the different between source and binary.

Creation of the final archives happens in 2 parts, "assemble" and
"package". The assemble phase gathers all the features and plugins that
were built from source, the package phase gathers all the ones that were
binary to start with. The package phase only runs if your builder
defines the property "runPackager=true". I expect you are missing this
property.

As for the filteredDependencyCheck, by default PDE/Build will consider
all features and plugins it can find in the pluginPath, buildDirectory
and baseLocation, (and potentially even link files, platform.xml,
bundles.info and dropins from the baseLocation). You can imagine
perhaps having one target that is used to build several different
versions of a product. So there could be multiple versions of some
singleton bundle in that target. Of course only one of those versions
can be resolved.

"filteredDependencyCheck" filters the set of plugins to include only
those in the transitive closure of includes and requires from the top
level feature being built. This way, different versions of a product
could filter out different versions of singleton bundles from the state.
This is just one example of reasons why you may want to filter the state.

Note however that this feature is not commonly used and there are a few
bugs here that were found and fixed in 3.5 (247027, 247007, 260763)

-Andrew

Mark Melvin wrote:
> Hi,
>
> I have a continuous integration server building all of my plugins
> separately, and I am now using those plugins to build the features. I
> supply all dependencies in binary form and point to them using the
> "pluginPath" attribute of the eclipse.buildScript Ant target. This all
> works great and my feature is built with all of the appropriate version
> numbers substituted. However, I can see of no way to easily package up
> the features and plugins that were dependencies of the feature I just
> built. I am trying to make an update site zip of all features and
> plugins included in the feature I am building and it looks impossible
> without ripping apart the feature.xml myself to find everything (and
> doing this recursively to find dependencies of nested features).
>
> Am I missing something here? Is there a magical flag I can pass
> eclipse.buildScript that will include all children - even if they were
> pre-build binaries on the pluginPath?
>
> While I'm on the topic - what the heck is "filteredDependencyCheck"
> supposed to achieve? I have tried setting this property both ways and
> it appears to do nothing in my situation. The docs mention that it is
> "optional, constraint the set of plug-ins and features to be considered
> during the build to those reachable from the features" - but I still
> have yet to figure out what that means.
>
> Thanks,
> Mark.
>
Re: How to include binary bundles from "pluginPath" in feature output? [message #590411 is a reply to message #42125] Fri, 23 January 2009 19:05 Go to previous message
Mark Melvin is currently offline Mark MelvinFriend
Messages: 118
Registered: July 2009
Senior Member
Hi Andrew,

Thanks for the valuable response. You are correct - I am not running the
packager. I actually am executing targets from the generated build.xml
and not really using the full PDE at all. I tried calling bits from the
generated assemble and package scripts but they seem to depend too much on
being run in the context of a full PDE build and I currently don't run
things that way (and to be honest, I don't really intend to either...;).
What I have now pretty much works and requires much less configuring. I
just need to do a little more packaging on my end. At any rate - I think
I can use the dependency management I have configured in my build system
to achieve what I need here, with some Ant scripting.

The stuff on filteredDependencyCheck is useful to know. That's kind of
how I thought it worked, but I thought that setting it avoided the
"transitive" part of the dependency check for some reason, and testing
(along with your response!) tells me that it doesn't. I understand what
it is for now.

Thanks very much,
Mark.

On Fri, 23 Jan 2009 11:05:33 -0500, Andrew Niefer <aniefer@ca.ibm.com>
wrote:

> Mark,
> Where the features are coming from (pluginPath, buildDirectory,
> baseLocation) has no affect on whether they show up in the results. The
> key here will be the different between source and binary.
>
> Creation of the final archives happens in 2 parts, "assemble" and
> "package". The assemble phase gathers all the features and plugins that
> were built from source, the package phase gathers all the ones that were
> binary to start with. The package phase only runs if your builder
> defines the property "runPackager=true". I expect you are missing this
> property.
>
> As for the filteredDependencyCheck, by default PDE/Build will consider
> all features and plugins it can find in the pluginPath, buildDirectory
> and baseLocation, (and potentially even link files, platform.xml,
> bundles.info and dropins from the baseLocation). You can imagine
> perhaps having one target that is used to build several different
> versions of a product. So there could be multiple versions of some
> singleton bundle in that target. Of course only one of those versions
> can be resolved.
>
> "filteredDependencyCheck" filters the set of plugins to include only
> those in the transitive closure of includes and requires from the top
> level feature being built. This way, different versions of a product
> could filter out different versions of singleton bundles from the state.
> This is just one example of reasons why you may want to filter the
> state.
>
> Note however that this feature is not commonly used and there are a few
> bugs here that were found and fixed in 3.5 (247027, 247007, 260763)
>
> -Andrew
>
> Mark Melvin wrote:
>> Hi,
>> I have a continuous integration server building all of my plugins
>> separately, and I am now using those plugins to build the features. I
>> supply all dependencies in binary form and point to them using the
>> "pluginPath" attribute of the eclipse.buildScript Ant target. This all
>> works great and my feature is built with all of the appropriate version
>> numbers substituted. However, I can see of no way to easily package up
>> the features and plugins that were dependencies of the feature I just
>> built. I am trying to make an update site zip of all features and
>> plugins included in the feature I am building and it looks impossible
>> without ripping apart the feature.xml myself to find everything (and
>> doing this recursively to find dependencies of nested features).
>> Am I missing something here? Is there a magical flag I can pass
>> eclipse.buildScript that will include all children - even if they were
>> pre-build binaries on the pluginPath?
>> While I'm on the topic - what the heck is "filteredDependencyCheck"
>> supposed to achieve? I have tried setting this property both ways and
>> it appears to do nothing in my situation. The docs mention that it is
>> "optional, constraint the set of plug-ins and features to be considered
>> during the build to those reachable from the features" - but I still
>> have yet to figure out what that means.
>> Thanks,
>> Mark.
>>
Previous Topic:Headless build an update site with multiple features
Next Topic:[newbie] Accessing selected file
Goto Forum:
  


Current Time: Thu Mar 28 17:14:08 GMT 2024

Powered by FUDForum. Page generated in 0.04685 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top