|
| Re: Builds vs. Repository Creation [message #664232 is a reply to message #664224] |
Thu, 07 April 2011 23:02   |
 Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Even if you produce a p2 repository containing everything for the
purpose of creating the product zips, it does not mean that this have to
be the repository you have to expose to the world as the update site.
The update site could be a composite pointing to eclipse (+ various
other sites) and a site with only your bundles/features.
You can mirror/filter and compose p2 sites using Eclipse b3 aggregator.
This way you can slice and dice the composition of the repositories
independently from the build.
You can naturally also create a feature that represents your update site
(all your things) - when running site.p2 on this feature the result is a
repository with what the feature includes (excluding the site feature).
At some point you have to declare everything that is supposed to be there.
Alternatively, you have many such site contributions (compare to
Eclipse), and the final repository is an aggregation of all of them
(this is what Eclipse uses the b3 aggregator for when putting a release
together).
Does that help?
- henrik
On 4/8/11 12:02 AM, Trip Gilman wrote:
> For my current project, I have two main uses for buckminster: building
> the product from source and the generation of p2 repositories for
> publishing/shipment. I'm having a difficult time figuring out the best
> way to manage the differences between these two tasks.
>
> For the build, the component features I'm using must include all know
> bundles/features in the plugins or included features sections so that
> materialization and resolution is successful.
>
> On the other hand, I only want to include my local bundles in the
> resulting p2 repository. All external bundles should come from the
> various repositories provided by their authors/vendors.
>
> I could maintain two parallel sets of features, one with all bundles
> included for building and one with external bundles moved to the
> dependencies section, but this seems like a lot of additional work. Has
> anyone else run into this sort of situation before? Is there a better
> way to do this sort of thing?
>
> I will say that the system being built consists of roughly 200-300
> bundles and is broken into various components, each of which may or may
> not be installed and subsequently is managed by its own set of features.
> Having to double the feature projects could be pretty time consuming.
|
|
|
| Re: Builds vs. Repository Creation [message #664401 is a reply to message #664224] |
Fri, 08 April 2011 16:09 |
Carsten Reckord
Messages: 139
Registered: July 2009 |
Senior Member |
|
|
Hi Trip,
On 08.04.2011 00:02, Trip Gilman wrote:
> I could maintain two parallel sets of features, one with all bundles included for building and one with external bundles moved to the dependencies section, but this seems like a lot of additional work. Has anyone else run into this sort of situation before? Is there a better way to do this sort of thing?
I do something similar, just with a single root feature. Everything that is
part of my product is (directly or indirectly) contained through plugins and
included features. All third-party stuff is listed as dependency.
I don't think it's that much work and it makes the boundaries between your
stufff and the rest of the world very clear and explicit, which I think is a
huge benefit.
The only somewhat ugly thing here is that in order to get Buckminster to
still resolve those dependencies, you have to add them a second time in a
Cspex, because Bucky doesn't follow non-greedy feature dependendencies :(
cheers,
Carsten
|
|
|
| Re: Builds vs. Repository Creation [message #664418 is a reply to message #664401] |
Fri, 08 April 2011 18:06 |
Terran Gilman
Messages: 67
Registered: July 2009 |
Member |
|
|
You know, I was just going down that same path of research. What I've come up with so far is declaring a CSPEX for each bundle that has build requirements that aren't supposed to be included in the p2 repository.
The bundles that are for build only are placed in the dependencies section of the feature.xml. These same bundles are then added to the CSPEX alterDependencies section. Will this result in the bundles being resolved and materialized during build but missed in the p2 repository creation? It looks like the feature.bundles group is used for the repository listing but the dependencies attributes are used for building.
Edit:
After trying a few things out, it appears that the approach above doesn't work. The autogenerated cspec file references the same group (bundle.jars) for both the manifest action and the site generation action. Adding the items to the dependencies element does allow them to show up when using the resolve to wizard option from the cquery, but the actual manifesting of the artifacts doesn't occur.
Being able to maintain a cspex in addition to the standard feature.xml would be a great solution to this. The feature.xml would follow the general rule that items in the plugins and included features section are delivered as part of the feature. Items in the dependencies section are considered to be pre-requisites and are delivered through some other feature and/or repository.
This would leave the building requirements for materializing and such controlled by the cspex supplied with the feature. The external bundles being listed in the dependencies section or some other part so that they are included in the materialization group but not in the p2 site group.
Would changing the auto cspec generation to use two separate groups for these actions cause problems else where? Is this something that might be possible to do?
[Updated on: Fri, 08 April 2011 18:57] Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.03207 seconds
] 
Search
Help
Register
Login
Home
