Hey guys.. Over the past few days I've been playing with the build system trying to understand exactly how and what Eclipse bundles with a feature when it's being built.. I think I have a pretty clear understanding of what's going on now. I have implemented an ant task that can automate some of the places where pde build drops off, but I wanted to start a discussion about how things should work WRT our new distribution idea.. Things PDE build does/doesn't do: 1) If a plugin is listed as a <plugin> in your feature.xml, it will get bundled in the final ZIP file automatically (we were including 3rd party plugins to let eclipse do a lot of the bundling for us) 2) If a plugin is listed as an <import> in your feature.xml, no bundling will occur 3) If another feature is listed as an <include> in your feature.xml, no bundling will occur of that feature or it's plugins Things the old ant task did: 1) Took a list of plugins and added them to an arbitrary zip file. The old ant task was pretty annoying as you all probably know it required a list of plugins in a property file, which had to be synchronized every time one of our dependencies changed or one of our plugins changed it's needs. I have replaced the old task with a java-based task that recursively pulls requirements from your feature's feature.xml and corresponding plugin manifests. Things the new ant task current does: 1) Takes a name of a feature, and sets a property to a list of plugins that are not in the standard SDK that that feature depends on. This list is pulled from the <import> and <include> tags. With the new ant task we will be able now to automate bundling by just keeping our feature.xml's up to date. I am also thinking about making the new ant task make the "dependencies" it generates be not just plugins, but features also. That way our bundle contains not just plugins but features (which it probably should have all along). So, in short.. with the new ant task.. this will be the "new" behavior provided from our build system: 1) If a plugin is listed as a <plugin>, it gets auto-bundled just like in standard PDE build (no change). Anything here will be seen in both "bundle" and "nodeps" downloads. 2) If a plugin is listed as an <import>, that plugin and all of it's recursive dependencies will be auto-bundled (only for "bundle" downloads) 3) If a feature is listed as an <include>, that feature and all of it's plugins (and recursive dependencies) will be auto-bundled (again only in "bundle" downloads) Basically, I just want you guys to chime in if this is or isn't the expected behavior you think we should have for bundling... -- Marshall Culpepper marshall.culpepper(a)jboss.com JBoss Eclipse IDE Lead JBoss, a division of Red Hat _______________________________________________ jbosside-dev mailing list jbosside-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosside-dev

ok, so just so i understand "make the dependencies it generates...be features" means that you copy an existing complete feature as-is, instead of taking individual parts or create a new feature, correct?

1) If a plugin is listed as a <plugin>, it gets auto-bundled just like in > standard PDE build (no change). Anything here will be seen in both > "bundle" and "nodeps" downloads. +1 (if "bundle" means the type of downloads we provide now for each plugin? not bundle as in full eclipse SDK + deps + our plugin)

plugin.xml/feature.xml and look for "evil" plugin references.

> Would be cool if one could automatically run through >> plugin.xml/feature.xml and look for "evil" plugin references. > > I have absolutely no idea what you mean by "evil" ... care to expand a > bit more? (I'm guessing you mean org.eclipse.emf.*? =) I mean any <plugin ...> that: references eclipse core plugins or something that is in a feature

> I'm still a little confused by your description, but I have a hunch > you're > talking about plugins that are already a part of the standard SDK > download? > My ant task already filters out those plugins/features.... and it should then complain loudly if it is a <plugin> reference sine it is wrong. the other part is just a sugarcoating thing, that if i refer to a plugin, e.g. some WTP XML plugin and that plugin is part of a feature then the feature.xml should import the feature...right ? /max > On 9/5/06, Max Rydahl Andersen <max.andersen(a)jboss.com&gt; wrote: >> >> >> > Would be cool if one could automatically run through >> >> plugin.xml/feature.xml and look for "evil" plugin references. >> > >> > I have absolutely no idea what you mean by "evil" ... care to expand a >> > bit more? (I'm guessing you mean org.eclipse.emf.*? =) >> >> I mean any <plugin ...> that: >> >> references eclipse core plugins >> or >> something that is in a feature >> > -- -- 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