Gemeinschaft
Participate
Working Groups
This somehow duplicates bug #277394 , but it targets Luna JEE version, which contains and shows PDE extensions. A "standard" Java EE developer doesn't need PDE in his IDE, and most likely the standard Java EE developer doesn't even know and care about what is PDE. So PDE should be removed from the JEE package. The datatools oda.designer feature seems to reference PDE to develop extensions for new datasource to the ODA designer. This seems to be an advanced use-case which is out of the scope of the JEE package.
As pointed out in bug 277394 comment 9, there is a role for OSGi bundles in modern web apps ... and the solution there was to turn off the "capability" (activity) by default. It appears in current versions, there are no more "capabilities" ... is that something we lost in Eclipse 4.x? Or were they literally removed from JEE? I still see some of them at http://git.eclipse.org/c/epp/org.eclipse.epp.packages.git/tree/packages/org.eclipse.epp.package.jee.feature/feature.xml#n117 Adding Paul to CC ... Paul, may we assume "capabilities" (activities) are never coming back?
(In reply to David Williams from comment #1) > As pointed out in bug 277394 comment 9, there is a role for OSGi bundles in > modern web apps ... and the solution there was to turn off the "capability" > (activity) by default. There is indeed a role, but it doesn't seem to be something that is so much used that is should be packaged by default. Unfortunately, I don't have statistics to support this assumption... IMO, capability aren't that much a nice solution: Are end-users really aware/using the capabilites mechanism? I'm doubtful... People who want PDE in their app would more easily think about installing PDE in their IDE than look into their preferences whether the capability is enabled.
(In reply to Mickael Istria from comment #2) > (In reply to David Williams from comment #1) > > As pointed out in bug 277394 comment 9, there is a role for OSGi bundles in > > modern web apps ... and the solution there was to turn off the "capability" > > (activity) by default. > > There is indeed a role, but it doesn't seem to be something that is so much > used that is should be packaged by default. Unfortunately, I don't have > statistics to support this assumption... > IMO, capability aren't that much a nice solution: Are end-users really > aware/using the capabilites mechanism? I'm doubtful... People who want PDE > in their app would more easily think about installing PDE in their IDE than > look into their preferences whether the capability is enabled. I just hate taking it out unless "substantial reason to", and guess doesn't seem substantial, to me. (Such as, not huge, doesn't interfere with other function, etc.). Part of the "mission" of WTP (and by extension JEE Package) is to promote JEE standards and technologies, so I think have ability to create bundles for web-apps IS important and should be promoted ... not "made harder". The more complicated question about "capabilities" ... Yes, many people may not "be used to them" ... but those should be promoted too :) I'm not sure why the dialog doesn't show up in JEE package now. Chuck, Markus, was it intentionally removed? It does show up in plan eclipse SDK package and (previously) I just copied what ever they had into our JEE definition. Apparently there are still e4 issues with capabilities ... supports "old style" contributions, but not "pure e4" contributions (is what I've been told) and was pointed to bug 359778 for work that remains to be done. In other words, they are not "gone forever", so ... as a user of JEE Package ... not maintainer ... I'd like to see PDE stay and UI clutter managed with capabilities, if at all possible. But ... up to Chuck.
> I just hate taking it out unless "substantial reason to", and guess doesn't > seem substantial, to me. (Such as, not huge, doesn't interfere with other > function, etc.). Adding irrelevant UI entries in many places is IMO an intereference with other functions. > Part of the "mission" of WTP (and by extension JEE Package) is to promote > JEE standards and technologies, so I think have ability to create bundles > for web-apps IS important and should be promoted ... not "made harder". I'd be fine with with a "OSGi Bundle for webapp" under the JEE category in wizards, but the whole thing of having entries related to PDE in a JEE IDE seems to be that same as having entries for CDT in a JEE package. They don't make sense there. The issue is actually more on OSGi tools at Eclipse: there is only PDE, and PDE comes with all its UI entries, no way to kick them out. Maybe PDE should be split in several parts: an OSGi-related one, that could be re-used by WTP, and a pure Plugin Development one. But that's another story...
(In reply to David Williams from comment #1) > > Adding Paul to CC ... Paul, may we assume "capabilities" (activities) are > never coming back? Some of the activities are already back in Kepler, with some more work to be done. PW
For the average JBoss stack user, having PDE in Java EE package has a negative impact on the perceived quality: it's something they will never use, so it makes UI more complex. So it seems like our users (who are typically using Eclipse JEE + JBoss Tools) would see the removal of PDE from the JEE package as an improvement. Apparently, this is a use-case that according to David should be promoted. @David, are you telling that more or less in the name of WebSphere users? Do you know what share of WebSphere users use this package and use PDE? Is this share big enough to add useless UI to the other people doing plain JEE ? @Konstantin: what's your opinion on that, from the Oracle/Glassfish/Weblogic POV? Do your user use this package? Do they use OSGi much? Are you in favour for keeping PDE in it or do you think it'd better be removed?
-1 on removing PDE from the Eclipse IDE for Java EE Developers distros The EE sphere is very wide and OSGi use is not that rare. We include PDE in Oracle distros. <soap-box>It's easy to forget for those of us who develop Eclipse plugins, but an average Eclipse user still struggles to find plugins corresponding to a feature that they read about and then struggles figuring out how to install it. Eclipse Marketplace has improved the situation somewhat, but it still has fundamental flaws that impact UX and the project is barely seeing any activity. To make matters worse, many projects don't even bother publishing to the marketplace. As an acknowledgement of the current situation, which hasn't seen much improvement in many years, we should be moving to fewer more full-featured distros rather than in the other direction.</soap-box>
(In reply to Mickael Istria from comment #6) > Apparently, this is a use-case that according to David should be promoted. > @David, are you telling that more or less in the name of WebSphere users? Do > you know what share of WebSphere users use this package and use PDE? Is this > share big enough to add useless UI to the other people doing plain JEE ? > Yes, I meant "WDT" specifically (available from market place). I'd have no way to know "number of users" ... but see no reason to remove it. As far as know, you can (still) turn off some of the UI via the "capabilities" preferences, but I've not been involved in quite a while, so the current maintainer would be a better spokes-person.
Well, although I still believe a vast majority of JEE developers are not interesting in seeing "New Plugin Project" nor "Run As Eclipse application" nor others, it seems like it's something that has value for other providers of JEE stacks. So marking it as WONTFIX. The perspective is probably efficient enough to avoid not-contextual actions.
(In reply to Konstantin Komissarchik from comment #7) > we should be > moving to fewer more full-featured distros rather than in the other > direction.</soap-box> I don't fully agree with that. The most frequent criticism I hear about Eclipse is "Eclipse is just a mess", people have difficulties to find what to install, and then when they have too much stuff installed, they complain that their UI is crowded by many things they don't like. So it's not about going fully in a direction or the other (with minimal or maximal packages), but finding the balance between both.
