Community
Participate
Working Groups
As discussed on the e4-dev mailing list it would be nice to add a category holding the following bundles: * javax.annotation * javax.inject * org.apache.batik.css * org.apache.batik.util * org.apache.batik.util.gui * org.eclipse.e4.core.contexts * org.eclipse.e4.core.di * org.eclipse.e4.core.di.extensions * org.eclipse.e4.core.services * org.eclipse.e4.tools.compat * org.eclipse.e4.tools.services * org.eclipse.e4.ui.css.core * org.eclipse.e4.ui.css.swt * org.eclipse.e4.ui.css.swt.theme * org.eclipse.e4.ui.di * org.eclipse.e4.ui.services * org.eclipse.e4.ui.widgets (see 337262 to probably remove) * org.eclipse.emf.common (see 337256 to probably remove) * org.w3c.css.sac * org.w3c.dom.smil * org.w3c.dom.svg
I agree. It would be really nice when in order to use (for example) e4 - DI in 3.x all i have to do is add 1 feature to my target platform.
After more consideration a feature probably would be a better option. PW
If all of these bundles are intended to all be installed together instead of users picking and choosing which ones they want, then a feature is the way to do this.
ok. what would be a good name for the feature? org.eclipse.e4.ui.forwardcompat?
>org.eclipse.e4.ui.forwardcompat? Sorry, I don't get what the 'ui' stands for here.
(In reply to comment #5) > >org.eclipse.e4.ui.forwardcompat? > Sorry, I don't get what the 'ui' stands for here. Sorry, I mean I know what "UI" stands for in general :) But for example the core application services are also referred, so is it not best to exclude the UI segment from the package? Regards, Dimitar
Well the ui is in because the 3.x compat layer parts have a dependency on org.eclipse.ui but naturally the core part of the feature can be used in none UI scenarios.
I think the name of the feature should reflect the use of that feature. If this forward compatibility layer is meant to be used only in a UI context, then i think the "ui" is appropriate, otherwise it is not.
I've committed the new feature to the CVS. It is found in e4/org.eclipse.e4.tools/features/org.eclipse.e4.tools.e3x.bridge.feature. I hope i added the correct source informations. Can we get the feature into the build and try a test build?
I've added the e3x.bridge feature to the master and updated the map files. e4-releng/org.eclipse.e4.ui.releng/maps/ui.map is the map file containing org.eclipse.e4.tools.e3x.bridge.feature. A test build seems to be good, a p2 repo can be downloaded from http://build.eclipse.org/eclipse/e4/build/e4/downloads/drops/4.0.0/I20110302-1530/I20110302-1530/eclipse-e4-repo-incubation-I20110302-1530.zip
Ok. I've tested it and the feature installs fine on 3.7 but there are 2 observations: a) It looks like the feature is not part of a group (maybe the best matching one is tools) b) It looks like there's not source feature to install
reopen for category & source feature
Created attachment 190209 [details] patch This is my changes for adding a source feature and doing the category, they are still untested so I haven't released it.
Andrew, did you release those changes?
(In reply to comment #14) > Andrew, did you release those changes? If not it would be good if we could get this one and bug 339301 into the build
Yes these changes were released. I just found a mistake which caused the source feature to be missing from the category, I've fixed this and everything should be good now.
