Community
Participate
Working Groups
Both of these features are listed in our "master feature", and defined in our "releng" project. But, I'm not sure what they are, or why we need them. If so, fine, but, since they in the "pde" namespace, thought I'd open the bug here in PDE. <includes id="org.eclipse.pde.junit.runtime.addon" version="0.0.0"/> <includes id="org.eclipse.pde.junit.runtime.standalone" version="0.0.0"/> These came to my attention because they explicitly state they require "org.junit" version 4.10.x ... but, everything else had "moved up" to version 4.11. Via bug 402707 I can change these to "0.0.0" now, as far as I know, so the extra org.junit won't be pulled in, but .... seeing these with this "odd" requirement made me wonder if they were needed at all? Anyone recall their history?
Does that mean that they are available in the repo or on the project download site? org.eclipse.pde.junit.runtime allows the junit launches to hook into the Platform UI.
These two features are available from repo only. The bundle org.eclipse.pde.junit.runtime is (also) included in the org.eclipse.pde feature and that is the one that is available in the SDK and download page separate PDE downloads. (A different topic, but, about those separate PDE downloads, see also bug 403811 -- I question whether they are really useful or not?). So, the question remains ... what are these 'addon' and 'standalone' features used for? (That is, what's the use-case that someone might need them?)
To add a little more certainty that they were 'not used', I checked the Kepler common repo for M6, and nothing "pulls them in" there ... which mean no other Eclipse project makes use of them.
So, if there's no objection, I'd like to move this back to "releng", and remove them. Seems like the time to clean out old stuff that's not used. It'll make build improvements easier. [I should note: if another non-eclipse product uses these, or something, then it should be that product that "slices and dices" our plugins in what ever combination they like, not us, since we could not possibly meet all needs]. But, if you can think of some use-case where committers use them, or something, feel free to say they are needed.
Go ahead with the removal.
http://git.eclipse.org/c/platform/eclipse.platform.releng.git/commit/?id=1cff42313571fed8da4dff5611a5521706526966 We'll see what blows up. :)
*** Bug 407375 has been marked as a duplicate of this bug. ***
Please add the add-on feature back. I need it in our headless target platforms in order to execute headless PDE JUnit Plugin tests (from within Eclipse).
(In reply to comment #8) > Please add the add-on feature back. I need it in our headless target > platforms in order to execute headless PDE JUnit Plugin tests (from within > Eclipse). So it isn't possible to just include PDE because of the UI requirements?
You've done me enough favors, Gunnar that I don't mind adding 'addons' back for Kepler, if you _really_ need it. But, I'd look to remove in Luna. And, honestly, from what I see, all this feature contains is following ... and "meant to be installed in target, not IDE" ... and it used to be part of Jetty project, or something? - <requires> - <import plugin="org.eclipse.core.runtime" version="3.6.0"/> - </requires> - <plugin id="org.eclipse.jdt.junit.runtime" version="0.0.0" unpack="false"/> - <plugin id="org.eclipse.pde.junit.runtime" version="0.0.0" unpack="false"/> - <plugin id="org.hamcrest.core" version="0.0.0" unpack="false"/> - <plugin id="org.junit" version="0.0.0" unpack="true"/> So, my point is, if you are only one using this ... you could easily "roll your own", right? But again ... I know it was M7 when we removed, and while this whole cycle has skewed to the right, I would add back the one feature in RC1 for Kepler if you needed it to stay on track. (But you'll need to adjust in future ... this doesn't look like something that belongs in "platform releng"). So, please state again if you really need it, or willing to look at other arrangements. Thanks.
(In reply to comment #9) > So it isn't possible to just include PDE because of the UI requirements? Yes, I just need the headless parts. (In reply to comment #10) > So, my point is, if you are only one using this ... you could easily "roll > your own", right? I know how to modify the target xml manually in order to just consume the bundles. However, please bear in mind that the PDE target editor does not allow to do this. It only knows about features/categories but not about bundles. Thus, a lot of users might not know how to roll their own. Anyway, I have no idea how widely it is used out there. It may be just me and now that I know the intention and the workaround I'm happy to roll my own.
Ok, thanks Gunnar. If you have any troubles, let me know. Or, if we hear of other complaints, we'll reconsider. Otherwise, moving back to "fixed" status.
mass change to 'verified', as these bugs are either routine or obviously fixed build breaks.
Just found this and wanted to add myself to the list of those who were using it. I also can roll my own, if needed, but here's the use case: When setting up a new RCP project, I usually create a new target definition that references the "Eclipse RCP SDK" feature. This includes everything I need to develop RCP applications *except* JUnit. So in the past I have always added the "add-on" JUnit feature (standalone contains too much) to the target so that JUnit tests can be run in the IDE and during Tycho builds. My questions is should I be doing this some other way? How are other RCP developers running JUnit tests without the "add-on" feature in their target? If there's no better way, then I might open up another Bugzilla entry to discuss how to approach this.
(In reply to comment #14) > Just found this and wanted to add myself to the list of those who were using > it. I also can roll my own, if needed, but here's the use case: > > When setting up a new RCP project, I usually create a new target definition > that references the "Eclipse RCP SDK" feature. This includes everything I > need to develop RCP applications *except* JUnit. > > So in the past I have always added the "add-on" JUnit feature (standalone > contains too much) to the target so that JUnit tests can be run in the IDE > and during Tycho builds. > > My questions is should I be doing this some other way? How are other RCP > developers running JUnit tests without the "add-on" feature in their target? > > If there's no better way, then I might open up another Bugzilla entry to > discuss how to approach this. Well, it is gone, now (from the Kepler release) so if you needed anything soon, I'd suggest you "roll your own" ... again ... its only 4 bundles .... so should be relatively easy to add just those to target? As for how most people test RCP apps with Tycho, my guess is most of them use a maven or Tycho plugin to do that ... but, I am not personally knowledgeable about that ... or if can be used "from IDE" or only during "batch builds". You might ask on "CBI list" (cbi-dev).
Hm, it is a pity these features got removed, and I'm quite sure most developers have not noticed this yet because they still build against Eclipse Indigo or Juno. Anyway, here is my use case and a bit of history. When I started developing Eclipse plug-ins, our customer was using Eclipse Galileo 3.5.2. In order to make sure I don't introduce unnecessary dependencies and to speed things up, I've setup a PDE target platform. This platform included only the minimally necessary set of features: org.eclipse.platform and org.eclipse.cdt. However, as soon as I set this platform and tried running JUnit tests, an error message notified me that JUnit Runtime is missing from it. So, I had to install the whole org.eclipse.jdt in order to get it. When our customer moved up to Eclipse Helios 3.6.2, and I was about to create a new target platform, I noticed that the Helios Release Site contains "PDE JUnit Runner Support - Add-on" feature. So, the new target platform included org.eclipse.platform, org.eclipse.cdt and org.eclipse.pde.junit.runtime.addon features, and contained twice as few plug-ins because all the unnecessary JDT stuff was not included. Cool! Since then our customer moved up to Eclipse Indigo 3.7.2 and is planning to upgrade to Eclipse Juno 3.8.1 quite soon. We've also moved to Tycho-based build and started running unit tests from Tycho, which in contrast to PDE somehow manages without the org.eclipse.pde.junit.runtime.addon feature. Still, this feature is a part of our target platform because it is needed to run JUnit tests from PDE. Given that org.eclipse.pde.junit.runtime.addon.feature.group is not a part of Kepler Release Site, in couple years we'll have to come up with another solution to this problem. David, do you suggest that one should clone the Platform git repo and build this two features manually? Or do you think that one should download PDE (or just JDT), copy-paste the bundles into a new directory, run FeaturesAndBundles p2 publisher, and add a newly created repo to the target platform? Both methods are of course viable alternatives, but I would rather consume them directly. The promised history of org.eclipse.pde.junit.runtime.addon feature can be found here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=313202
Oh, and the history of moving org.eclipse.pde.junit.runtime.addon and org.eclipse.pde.junit.runtime.standalone from Jetty repo to Helios repo is given here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=323062 Finally, just to make things clear, I use the o.e.pde.junit.runtime.addon feature and have no idea if o.e.pde.junit.runtime.standalone feature is really needed. Judging by comment 5 in bug 313202, it may well be unnecessary nowadays.
(In reply to Mikhail Kalkov from comment #16) > ... > > Since then our customer moved up to Eclipse Indigo 3.7.2 and is planning to > upgrade to Eclipse Juno 3.8.1 quite soon. We've also moved to Tycho-based > build and started running unit tests from Tycho, which in contrast to PDE > somehow manages without the org.eclipse.pde.junit.runtime.addon feature. > Still, this feature is a part of our target platform because it is needed to > run JUnit tests from PDE. > > Given that org.eclipse.pde.junit.runtime.addon.feature.group is not a part > of Kepler Release Site, in couple years we'll have to come up with another > solution to this problem. David, do you suggest that one should clone the > Platform git repo and build this two features manually? Or do you think that > one should download PDE (or just JDT), copy-paste the bundles into a new > directory, run FeaturesAndBundles p2 publisher, and add a newly created repo > to the target platform? Both methods are of course viable alternatives, but > I would rather consume them directly. > I'm not sure I'm the best one to give advice here, but I'd lean toward the former. You shouldn't have to rebuild the bundles from Git, but just "build" your own "minimum test requirements feature" (with your own namespace) and "include" the bundles from Kepler repo. Or ... maybe better is to convince Gunnar to describe how to "manually" edit the .target file, to add bundles. :) Sorry to have "broken" you ... but in general, this is one reason why we don't like to include features "we" don't really use ... we never know who is doing what with some particular "slice" of bundles.
