Home » Archived » Buckminster » Buckminster, feature and p2 update-site
| Buckminster, feature and p2 update-site [message #1072963] |
Tue, 23 July 2013 21:04  |
 Matthieu Ouellette-Vachon
Messages: 3
Registered: July 2013 |
Junior Member |
|
|
Hi,
I would like to have some insights about the best way (if it's even possible) to do the following thing.
I would like to create a p2 site from an eclipse feature. I already achieved that from the IDE and headlessly. Now, what I would like is to reduce our maintenance burden by not specifying every plugins that should go in the repository in the feature.
What I would love is to specify, in the feature Plug-ins tab, only the top level plugins that is needed by the feature and then, Buckminster would auto magically add all (non-eclipse) dependencies into the generated p2 site. Eclipse ones would be fetched from the target-platform currently activated in my workspace while other ones are all projects already checked-out in my workspace.
I would like to do that because the top-level plugins transitively need a lot of other plugins and currently, we often make mistakes when it comes the time to specify them because the transitive dependencies are so low in the graph.
Currently, putting only the top-level plugins in a feature generates a p2 site with only those top-level plugins. We miss all other ones to have a functional self-contains p2 site (again, expect those provided in the Eclipse platform).
Regards,
Matt
|
|
|
| Re: Buckminster, feature and p2 update-site [message #1073098 is a reply to message #1072963] |
Wed, 24 July 2013 06:14  |
|
On 2013-07-24 01:18, Matthieu Ouellette-Vachon wrote:
> Hi,
>
> I would like to have some insights about the best way (if it's even possible) to do the following thing.
>
> I would like to create a p2 site from an eclipse feature. I already achieved that from the IDE and headlessly. Now, what
> I would like is to reduce our maintenance burden by not specifying every plugins that should go in the repository in the
> feature.
> What I would love is to specify, in the feature Plug-ins tab, only the top level plugins that is needed by the feature
> and then, Buckminster would auto magically add all (non-eclipse) dependencies into the generated p2 site. Eclipse ones
> would be fetched from the target-platform currently activated in my workspace while other ones are all projects already
> checked-out in my workspace.
>
> I would like to do that because the top-level plugins transitively need a lot of other plugins and currently, we often
> make mistakes when it comes the time to specify them because the transitive dependencies are so low in the graph.
>
> Currently, putting only the top-level plugins in a feature generates a p2 site with only those top-level plugins. We
> miss all other ones to have a functional self-contains p2 site (again, expect those provided in the Eclipse platform).
>
Buckminster is able to resolve the plug-in hierarchy transitively if you are using 'Require-Bundle' in your manifests
but if you are using 'Import-Package', then it has no way of computing what bundles that provides those packages. I
don't recommend using 'Require-Bundle' though, since it's less fine-grained and makes it harder to co-exist with other
bundles in a complex environment.
When using 'Import-Package' you can add a buckminster.cspex to each bundle where the intended bundle dependencies are
described.
- thomas
|
|
|
| Re: Buckminster, feature and p2 update-site [message #1073318 is a reply to message #1073098] |
Wed, 24 July 2013 14:11 |
Matthieu Ouellette-Vachon
Messages: 3
Registered: July 2013 |
Junior Member |
|
|
Yes, I noticed that Buckminster is able to do it transitively, because as you say we use Require-Bundle already. I can see them when checking with the Open Dependency Graph context menu entry on a feature project in the IDE.
Now, my ultimate wet dream is to leverage this information and Buckminster to create a site.p2 containing all those dependencies, but filter out Eclipse ones. This would results in a p2 repository where our end-users can install our plugins and all its dependencies from a single repository.
Currently, what I tried is to create a feature with only the required top-level plugins added in the Plug-ins tab. But when doing so, The final p2 repository created via Invoke action -> site.p2 only contains the top-level plugins. For our use case, we need also all the other plug-ins dependencies in the generated site.p2 (all of them are projects in our workspace).
How could I achieve that? I played a bit with cquery, cspec and rmap files but did not add great success so far. I'm open to all workflow suggestion.
At the very least, if my use-case is not feasible automatically, what I would like is to extract the transitive dependencies list generated by Buckminster. With this list, I could then edit manually the `feature.xml` file with information generated by Buckminster. This would at least reduce our maintenance burden when releasing our plugins.
Thanks you for your time thomas.
Regards,
Matt
|
|
|
| Re: Buckminster, feature and p2 update-site [message #1073471 is a reply to message #1073318] |
Wed, 24 July 2013 21:41 |
|
Your site feature is not supposed to 'require' those bundles. It's supposed to 'include' them.
- thomas
On 2013-07-24 16:11, Matthieu Ouellette-Vachon wrote:
> Yes, I noticed that Buckminster is able to do it transitively, because as you say we use Require-Bundle already. I can
> see them when checking with the Open Dependency Graph context menu entry on a feature project in the IDE.
>
> Now, my ultimate wet dream is to leverage this information and Buckminster to create a site.p2 containing all those
> dependencies, but filter out Eclipse ones. This would results in a p2 repository where our end-users can install our
> plugins and all its dependencies from a single repository.
>
> Currently, what I tried is to create a feature with only the required top-level plugins added in the Plug-ins tab. But
> when doing so, The final p2 repository created via Invoke action -> site.p2 only contains the top-level plugins. For our
> use case, we need also all the other plug-ins dependencies in the generated site.p2 (all of them are projects in our
> workspace).
>
> How could I achieve that? I played a bit with cquery, cspec and rmap files but did not add great success so far. I'm
> open to all workflow suggestion.
>
> At the very least, if my use-case is not feasible automatically, what I would like is to extract the transitive
> dependencies list generated by Buckminster. With this list, I could then edit manually the `feature.xml` file with
> information generated by Buckminster. This would at least reduce our maintenance burden when releasing our plugins.
>
> Thanks you for your time thomas.
>
> Regards,
> Matt
|
|
|
| Re: Buckminster, feature and p2 update-site [message #1073517 is a reply to message #1073471] |
Thu, 25 July 2013 00:54 |
Matthieu Ouellette-Vachon
Messages: 3
Registered: July 2013 |
Junior Member |
|
|
It's already the case, my `feature.xml` include the plug-ins I need, it does not 'require' them, sorry for the confusion. In fact, it includes all of them, for example, my feature named `com.example.feature` includes:
com.example.plugin-a
com.example.framework-a
com.example.framework-b
org.apache.xerces
org.mozilla.rhino
This will then create a nice p2 repository with all the plugins listed above. From the listing, `org.mozilla.rhino` is included in the p2 repository because it's a dependency of `com.example.framework-b`.
Now, what I would like is to avoid to edit manually all the included plugins of feature `com.example.feature`. Instead, it would be preferable to only list the top-level ones:
com.example.plugin-a
And let Buckminster find all the dependencies by itself and create a p2 repository containing the listed plugins + all the transitive dependencies.
Is it possible to achieve this using Buckminster? Either by using a `feature.xml` and some Buckminster incantations or via maybe a cspec + rmap or by other means?
Regards,
Matt
|
|
|
Goto Forum:
Current Time: Thu Apr 18 17:42:05 GMT 2024
Powered by FUDForum. Page generated in 0.02271 seconds |
] 
Search
Help
Register
Login
Home
