Re: [jbosstools-dev] JBoss Tools 3.2 on Eclipse Marketplace

I propose that we create a plugin/feature that would install different JBT artifacts (plugins/features and runtimes) using P2 provisioning. We could also create a leigthweigth RCP aplication that would include that plugin/feature and that could install different JBT plugins with requirements as well as our runtimes: Seam, JBoss AS, EAP, EPP, SOA-P, Portletbridge, etc. We could create catalogs (Web, SOA, ...) of features/plugins. The user could install some or all of the features. Eclipse plugins would be in the standard P2 repositories and our provisioning aplication could install the standard Eclipse plugins/features, JBoss Runtimes and catalogs. We would create catalogs (for instance, Web Tools, SOA Tools, Seam Tools, etc) that would include Eclipse plugins/features and JBoss Runtimes. A catalog would be an xml file that would describe a feature in the way project-examples.xml describes project examples. We would need to know the URL of a JBoss Runtime we would like to download. It is also possible to create a JBoss Runtime as an Eclipse bundle (XULRunner is bundled this way) which would make easier to handle bundle/runtime dependencies. When a new version of some artifact (a plugin/feature or a runtime) is released, we would add a new entry to the catalog. Since the p2 API is a public API, we could use it to create our specific functionalities and user interface.

Snjeza Max Rydahl Andersen wrote: > I discovered last week that Eclipse Marketplace (available via Help > Eclipse Marketplace) is *super easy* to submit thus I submitted JBoss Tools 3.2.x (marked as beta) to it: > > http://marketplace.eclipse.org/content/jboss-tools-1 > > On that submission we have to give at least one feature to install to make it easy to install from a "plain" eclipse. > > This again give us a problem since including *everything* from jboss tools will for a JEE user grab a non-significant > set of dependencies (i.e. Teeid's UML, Maven tooling m2eclipse and TPTP requires tptp etc.) > > Thus for this "first time" I only included the features I know should be able to install on Eclipse JEE and just get > dependencies from our site and I added a comment in the description that to get the "extras" use the updatesite directly. > > Suggestion on how we handle this problem of "large bundles" welcome. > > Should we simply create a "Web" and "SOA" bundling feature which might have overlap ? (i.e. both will need our AS integration) > > And if users insttall such - will they be able to install both without conflicts ? > > /max > > >