On Thu, 28 Sep 2006 10:30:36 +0200, Koen Aers <koen.aers(a)jboss.com&gt; wrote: > But I *am* building a completely separate thing along with the JBoss IDE > distribution. Our jBPM Starter's Kit contains the jBPM GPD feature > without all the other JBoss IDE stuff. And this is exactly what I am > worried about and why I am looking at this with so much suspicion... > > I am distributing the jBPM GPD feature as a standalone feature and I > certainly do not want to import the complete WTP feature only because I > am using the XML editor. So I repackage the plugins from the WTP feature > and I provide or distribute them in my own feature. Ok, we are apparently not going anywhere with this ;) We are not saying you need to depend on the complete WTP feature. HibernateTools doesn't need that either. The thing is though (which I also just realized lately) is that the WTP consists of multiple features AND one of those are the xml editor and is not really that bigger. So if you used that feature as an dependency instead of your own extraction of plugins things would be easier. that being said, you can still use <import> specifically to just refer to individual plugins - I don't think that gives problems (besides your plugin is actually not stating its true/general dependency) Would you be ok maintaining two feature/plugin.xml files so we could have one that package things up like you want and another that works like intended in the eclipse 'eco-system' kind of way so we can get an IDE build going ? (this were mean as half-for-fun and half-for-real..;) > Besides, your statement does not hold. The Eclipse RCP feature is > packaged in the Eclipse core distribution and 'provides' some of the > plugins that happen also to be in the Equinox project and thus in the > Equinox feature. This is exactly the same situation as what I am doing > with WTP... The bottom line is that the feature is a way of packaging > and of distributing plugins. Yes and I can see the usefullnes of this if you wanted to provide a custom build/bundling of eclipse as a standalone program...that is not what you want, right ? You don't distribute a linux/windows/mac edition of your plugins, right ? I don't get why WTP and eclipse core, jdt etc. is getting different treatment then ? Why don't you refer to the core eclipse plugin the same way so they also get packaged with your jBPM GPD feature ? /max > > Regards, > Koen > >> -----Original Message----- >> From: Max Andersen >> Sent: donderdag 28 september 2006 6:20 >> To: Koen Aers; Marshall Culpepper; jbosside-dev(a)lists.jboss.org >> Cc: Tom Baeyens >> Subject: Re: About feature.xml and bundling plugins (WAS: >> jBPM Designer feature.xml needs to be updated) >> >> >> I just got to look at the two feature.xml you are attaching >> and these are core features.xml - meaning this is what they >> do...define a feature.xml to represent equinox and rcp. >> >> If we were building a complete separate thing, e.g. something >> that does not need to run in other peoples Eclipse IDE 3.2 >> then sure we could just redefine the features.xml and >> plugin.xml as something completely seperate ...but that is >> not what we are doing, right ? >> >> Similar if we were building equinox and rcp based apps I >> would have a feature.xml that referred to those two (via >> import not plugin) >> >> We are an *IDE* building on top of the eclipse ide core >> features and those we refer/link to those core >> features/plugin instead of saying that our feature actually >> provides them. Our features *only* provides the >> org.jboss.*/org.hibrnate.*/org.jbpm.*/etc plugins it does not >> provide org.eclipse.* stuff. >> >> Not I'm writing "Our *feature* provides" not "Our >> *distribution* provides" >> two *different* things. >> >> /max >> >> >> >> >> There are two very different things: >> >> >> >> One is what goes into feature.xml that states what your feature >> >> actually >> >> *need* and then there is your distribution. >> >> ... >> >> The other is distribution which is your feature + what is a good >> >> default packaging. >> >> >> >> Of course we want the last ... >> > >> > >> > In fact this is not true. Eclipse features *are* a >> packaging mechanism. >> > A feature does not *need* anything by itself. Only the >> plugins in the >> > feature have dependencies on other plugins. See : >> > >> http://dev.eclipse.org/viewcvs/index.cgi/*checkout*/platform-core-home >> > /d >> > ocuments/plugin-versioning.html?rev=1.2 for a document >> stating this. >> > The fact that you will not find any Eclipse project that references >> > plugins in the feature.xml is due to the fact that they are at the >> > source and perfectly capable of defining their own >> packaging units in >> > which no feature contains plugins that appear also >> somewhere else in >> > other features. >> > As a matter of fact after exploring the different Eclipse >> projects a >> > bit I have found evidence that what you say is not true. >> Have a look >> > at the attached feature.xml files for the rcp feature and for the >> > equinox feature and see that they are exactly using the >> 'evil' way of >> > doing things. And I am sure that if I look a bit around I >> will be able >> > to find plugin providers (that are not part of the Eclipse overall >> > project) that have also feature.xml files containing references to >> > third party plugins in the <plugin> tags. >> > >> >> This thing we are doing here (with using <plugin> instead of >> >> <import>) is actually in the same ballpark since it breaks >> >> updatemanagers and depedency checking. >> > >> > Again, I have completely no evidence that this is >> happening. In fact, >> > the JIRA issue you mention is happening because the update >> manager is >> > looking for particular versions of the plugins stated in the >> > feature.xml. But you don't have to state these versions in your >> > feature.xml explicitly. If you do not state them explicitly any >> > version that is available on the update site will satisfy >> the requirements. >> > >> > Regards, >> > Koen >> >> >> >> -- >> -- >> Max Rydahl Andersen >> callto://max.rydahl.andersen >> >> Hibernate >> max(a)hibernate.org >> http://hibernate.org >> >> JBoss a division of Red Hat >> max.andersen(a)jboss.com >>