Community
Participate
Working Groups
When starting, the EPP package has 'Java EE IDE Package' in the application name at the top, which is most confusing to users. This should be just Eclipse.
Created attachment 135299 [details] Screenshot showing application name where Eclipse usually exists
Note that if I comment out the 'eclipse.product' back, we get somewhat normality: #eclipse.product=org.eclipse.epp.package.jee.product although the name now becomes named for the executable (eclipse) instead of the actual app name (Eclipse) - though this might be related to the packaging issue. I believe this is a regression against Eclipse 3.4, because the Eclipse 3.4 EPP Java EE package has: eclipse.product=org.eclipse.platform.ide which also gives the Eclipse name. All Mac apps have the same name in the Application as in the executable. The P2 allows this to be configured based on product (for people wanting to ship different names) but the EPP should not be changing the name for the sake of it. Here's where the Bad Thing Happens: <property name="appName" value="Java EE IDE Package"> </property> <property name="aboutText" value="The Eclipse Java EE IDE."> </property> org.eclipse.epp.package.jee_1.0.0.200905081735/plugin.xml
To be clear, are you saying another solution would be to change the name of the executable to "Java EE IDE Package"? That is, you are just saying they should be the same? CC'ing Markus as he was saying something about this the other day ... and I didn't really understand it then either ... but sounds related.
No, it would be wrong to change the name of the executable to match this identifier - the users are downloading Eclipse and expect to see Eclipse.app. Not only that, but there are a number of other implications of doing this (such as breaking the release build) which would be bad. We need to change the XML definition of the name so that appName reads "Eclipse": org.eclipse.epp.package.jee_1.0.0.200905081735/plugin.xml <property name="appName" value="Java EE IDE Package"> <!-- Change this to Eclipse --> </property> <property name="aboutText" value="The Eclipse Java EE IDE."> </property> Alex
I think this could be additional input for the discussion on the mailing list: http://dev.eclipse.org/mhonarc/lists/epp-dev/msg00566.html
I do not, btw, disagree with changing this to 'Eclipse', now that we know. I do wonder if we _always_ want the executable name to be 'Eclipse', but no need to rock the boat now. I just say this, Alex, since even though you say "the users are downloading Eclipse" but some of us think of "downloading Eclipse" as _just_ the platform eclipse, but, like I said, no reason to change now.
I know there's a disconnect between 'eclipse' the platform and 'eclipse' the application, but users consider all the EPP packages to be 'eclipse' with different flavours. It wouldn't make sense to (say) have one user download CDT and then add the Java EE stuff to see 'CDT Package' in the title, in just the same way that someone who downloads Java EE and then adds CDT wouldn't make sense to have 'Java EE IDE' in the title. In both cases, the platform is still the same (and net result is same installed applications) but the product branding is different. For good or for bad, users will think Eclipse, especially if it's called Eclipse.app (and the internal executable name of 'eclipse'). So having something different show up in the titlebar is unexpected at best. Really, the 'initial feature set' shouldn't define the product. A product should define the product, and the product to most end users is Eclipse (and I say this with fully knowing the problems of eclipse-the-ide vs eclipse-the-patform vs eclipse-the-foundation). Having a dependency on the 'ide' would work - it would give the harmonised name across all packages - but so would renaming the name in the product itself. The advantage of the IDE approach is that you don't have to worry/change all of the other EPP builds to make sure they too have Eclipse in the title (since I'll bet there's the same problem with naming there too).
(In reply to comment #6) > I do not, btw, disagree with changing this to 'Eclipse', now that we know. > > I do wonder if we _always_ want the executable name to be 'Eclipse', but no > need to rock the boat now. > > I just say this, Alex, since even though you say "the users are downloading > Eclipse" but some of us think of "downloading Eclipse" as _just_ the platform > eclipse, but, like I said, no reason to change now. > I agree the status quo is a good solution in this situation. I've learnt that when you say _always_ it typically means you are wrong. :-) +1 for keeping Eclipse as the name.
Fixed in RC1 (I'm fairly sure ... please confirm)
No, not fixed.
Created attachment 136771 [details] change appName to Eclipse
Markus, can you please apply patch to change appName back to "Eclipse" ... for RC2 please?
whoops, I meant RC1 ... is there time/ability to do this on Friday?
The patch looks like it'll work - however, does the same change need to be done to the other EPP packages?
Yepp, I think that was not the best idea to introduce different names for each package. I am going to rename the application name of every package to the 'Eclipse' standard.
FYI the Eclipse CDT package still calls itself "EPP CPP Package" which is odd, because (a) it's CDT, not CPP and (b) it should be Eclipse ;-) This was from the EPP RC1 package
I'm beginning to have doubts about this change to merely "Eclipse". It seems now (in JEE RC2 nightly) that the "about" menu says "About Eclipse" and the about dialog says only "Eclipse". I'm pretty sure most who install Java EE IDE would be confused if About said only "Eclipse". Is the "About" name derived from something else? If "appName" controls all these different things, I'd prefer to go back to a more descriptive name. I also think it's make bug reports clearer ... people more likely to report what they have installed, instead of always just saying they had "Eclipse" installed.
I'm going to punt this up to Major. This is really a breaker of a problem for the Mac application. It's difficult to convey exactly how bad this is ... it's somewhat like forcing a Windows application into c:\lotus because it can't handle a space in the name, or a Linux app being forced to install into /matlab instead of /usr/bin. There are many places which represent an application name on Mac, and they all should be consistent: * The name of the .app * The text in the Info.plist * The name of the .icns file (referenced from Info.plist) * The name in the top-left of the screen * The name after the 'About' text * The name that shows up on the dock when you mouse-over * The name that is shown when you Alt+Tab between applications Setting the 'appName' in the package changes the name at the top-left and about text, as well as the Alt+Tab. I'm not sure if the Dock gets it from the Info.plist. But having an .app name that is different from the text in the top-left is 100% against the Mac app ethos. There doesn't appear to be a significant/compelling reason for this change other than an undisclosed personal opinion. Furthermore, the bugs that people will raise will be about CDT, Mylyn, JDT, PDE, EMF ... it's very likely that most bugs will be unrelated to the initial packaging. In fact, the bug wizard will take the user through the components and get them to choose one. Somehow suggesting that the text in the 'About' will lead them to the correct component is seriously unlikely; and even if led to the appropriate EPP package, chances are the bug will need to be punted elsewhere anyway. The other aspect is that the text in the About box is pretty minimal. In Eclipse 3.4, the About text says 'About Eclipse Platform' and the content is: --- Eclipse Platform Version: 3.4.2 Build id: M20090211-1700 (c) Copyright Eclipse contributors and others 2000, 2009. All rights reserved. Visit http://www.eclipse.org/platform This product includes software developed by the Apache Software Foundation http://www.apache.org/ --- Compare this to (say) EPP CPP About Dialog contents: --- This is the EPP CPP About Dialog. --- To be honest, you're probably better off just shipping the EPP packages with the platform feature product across all EPP installs rather than trying to come up with your own. It gives a much more professional and Mac-compliant view than a collection of arbitrary 'package' names when they're nothing that the end user will associate with Eclipse. Having used Macs since the 10.0 days (and been an ex-NeXT-ie in the pre-Java days), not to mention testing on the early Mac ports of Eclipse in the 2.1 days, I can't stress how important it is that the app has 'Eclipse' at the top left of the screen. > I'm pretty sure most who install Java EE IDE would be confused if About said > only "Eclipse". Is the "About" name derived from something else? No - it's completely the other way around. You will absolutely confuse people who install Eclipse and then it claims to be something else. The app is still Eclipse.app, they're installing a bundle from Eclipse.org (which has always shipped Eclipse.app, even in the last round of EPP packages were called Eclipse). I've never thought, when downloading Eclipse EPP packages, that I'm downloading anything other than a pre-verified collection of plugins that make up Eclipse. In fact, I don't see the difference between downloading Eclipse JDT and then installing CDT onto the top vs Eclipse CDT and then installing JDT on the top. Either way, you end up with the same Eclipse + JDT + CDT combo installed.
It is good to be consistent, within an application (how it refers to itself, etc.) and to be consistent with the rules and conventions of the Operating System. But, Alex, I think you see the purpose of these "packages" much differently than some of the rest of us. They really are supposed to be more than just installing Eclipse and then some collection of features. The fact that you haven't seen that simply reflects just how badly we've been accomplishing our goal ... but I still think it worth pursuing. It is sort of like if someone wanted to call "Lotus Notes" just "Eclipse" just because "Lotus Notes" happened be be built on the Eclipse Platform. If you really want "Eclipse" and then a bunch of features, I suggest you install the Eclipse Platform, and then use the Galileo Discover site to install other features you want. It might be helpful to Eclipse as a whole if you describe why that doesn't work for you? I will admit, an oddity in our naming might have been making it seem worse ... but, still won't make you happy, I know, Alex ... but instead of something like "Java EE IDE" we should always lead with 'Eclipse ...', such as "Eclipse IDE for Java EE" or Eclipse Jave EE IDE". I really appreciate your feedback, advice and suggestions, Alex. Now that I've explained it really is supposed to be different than just Eclipse-plus-a-collection-of-features, could you give any other specific advice? Thanks again,
(In reply to comment #19) > It is good to be consistent, within an application (how it refers to itself, > etc.) and to be consistent with the rules and conventions of the Operating > System. Right, that's the main complaint of this bug. > But, Alex, I think you see the purpose of these "packages" much differently > than some of the rest of us. > > They really are supposed to be more than just installing Eclipse and then some > collection of features. The fact that you haven't seen that simply reflects > just how badly we've been accomplishing our goal ... but I still think it worth > pursuing. That's pretty much always what I've thought; and others whom I've spoken with have seen it as a way to 'Get Eclipse' with a collection of features already installed. > It is sort of like if someone wanted to call "Lotus Notes" just "Eclipse" just > because "Lotus Notes" happened be be built on the Eclipse Platform. Right, there are products that do this. WebSphere, Rational, even Apache Directory Studio are built upon Eclipse and do a good job of showing a brand name as part of it. But in each case, the branding is complete, consistent, and it's clear that they're delivering something over-and-above what you can get from Eclipse.org. In those cases, the renaming is justified; but I don't see the value in 'productising' Eclipse features and calling them by a different name. > If you really want "Eclipse" and then a bunch of features, I suggest you > install the Eclipse Platform, and then use the Galileo Discover site to install > other features you want. It might be helpful to Eclipse as a whole if you > describe why that doesn't work for you? That's a two-step operation. Downloading a customised package is a one-step operation, and a one-step is always going to be preferred over a two-step. But I don't see myself ending up with different resulting products at the end of the day; I've got the same things under the hood, after all. (Well, there are P2 problems - aren't there always - with the EPP packages since they don't base themselves off the platform feature; and that in itself is part of the problem.) > I will admit, an oddity in our naming might have been making it seem worse ... > but, still won't make you happy, I know, Alex ... but instead of something like > "Java EE IDE" we should always lead with 'Eclipse ...', such as "Eclipse IDE > for Java EE" or Eclipse Jave EE IDE". This is about consistency. If you're going to do that, then you need to rename it Eclipse IDE for Java EE.app, and support the other items I've enumerated above. And frankly, that's just going to make it worse. Like I said, no-one actually thinks of these EPP packages as being different products; that might have been the intent behind doing this, but it's not been well delivered and the consistency is awful. If you're going to do the EPP as a re-branding exercise, then you need to do it all the way through and not just on one place. > I really appreciate your feedback, advice and suggestions, Alex. Now that I've > explained it really is supposed to be different than just > Eclipse-plus-a-collection-of-features, could you give any other specific > advice? This appears to be a divergence of the EPP packages from last year, which didn't have these names. The problem that the EPP project has is that you're trying to distinguish between Eclipse-the-Java-IDE and Eclipse-the-base-set-of-tooling, but you still want to keep Eclipse in the title. That's one of the key problems that will always suggest to people that it's Eclipse+Stuff, and not DifferentProduct. For example, Eclipse CDT Package is always going to suggest a package of Eclipse and CDT to me. However, call it something like Wascana (or Excelsior, or ...) and make the whole thing consistent with the name of the executable, the install location etc., and you start to really make a distinction between Eclipse+Stuff and Product. Perhaps I missed out on the EPP for this year, but it seems that they've only really been firing up towards the end of the release train. I'm concerned that there isn't enough time to iron out these sorts of problems before the gold; and I'm doubly concerned that the inconsistency is going to damage the EPP's reputation more than it's going to gain by trying to distinguish between the two things. And the problem seems to be that it'll just push people away from using EPP and, as you say, download the Platform and do update in the future.
(In reply to comment #20) > (In reply to comment #19) > > Perhaps I missed out on the EPP for this year, but it seems that they've only > really been firing up towards the end of the release train. I'm concerned that > there isn't enough time to iron out these sorts of problems before the gold; > and I'm doubly concerned that the inconsistency is going to damage the EPP's > reputation more than it's going to gain by trying to distinguish between the > two things. And the problem seems to be that it'll just push people away from > using EPP and, as you say, download the Platform and do update in the future. > You raise many good points, Alex. And I certainly don't want to impose my single point of view on the solution here. I'm getting the impression that I see "Eclipse" as one thing, but maybe the rest of the world thinks of "Eclipse" as something else. Namely, I see 'Eclipse' as the Eclipse Platform/base ... sounds like others see it as "Anything from 'eclipse.org'". I'm willing to leave it up to Markus to find the best, easiest, most consistent way to do this for all EPP Packages ... and next year, let's start earlier! :)
(In reply to comment #21) > You raise many good points, Alex. And I certainly don't want to impose my > single point of view on the solution here. I'm getting the impression that I > see "Eclipse" as one thing, but maybe the rest of the world thinks of "Eclipse" > as something else. Namely, I see 'Eclipse' as the Eclipse Platform/base ... > sounds like others see it as "Anything from 'eclipse.org'". But then, what is Eclipse Platform/base? Isn't that RCP? Or is it a subset, like Equinox runtime? Or is it the workbench/IDE (org.eclipse.platform.ide)? Or maybe the granddaddy of them all, JDT? The thing is, Eclipse - even in its most minimalistic form - has several variations of what that mimimalistic form is. I think the de facto assumption is Eclipse = Eclipse JDT, at least outside the Eclipse community. You hear announcements about "The Eclipse IDE" when what the news is, at least, just the JDT parts. This is from a recent post of Cafe au Lait: http://www.cafeaulait.org/oldnews/news2009May19.html "The Eclipse Project has posted the first release candidate of Eclipse 3.5 Galileo, their open integrated development environment for Java. New features include Solaris support, toString() generation, and more." But that, on the other hand, is equivalent to your 'Eclipse for Java Developers' EPP package. Fighting the name association with Eclipse =/= Eclipse JDT is an uphill battle generally. But without some common agreement of what 'Eclipse' means in the first place is the key ...
I've been following the discussion and thought I would shoot in my comments and thoughts on this matter. For me, downloading and installing "Eclipse" has always meant getting it down the simplest way I can by choosing the package that best describes what I will use it for. As a Web Application developer the Java EE package is "the" package for me. Big was my surprise then that the familiar name "eclipse" was gone from the title when I started the application. The webpage is eclipse.org, the page clearly says: "download eclipse" and finally the download link says "Eclipse IDE for Java EE". At the very least, the title bar for the application itself should be "Eclipse IDE for Java EE" if not simply Eclipse. I understand the need to separate the platform and the package, but I don't think I'm alone when I claim that for most of the normal visitors of eclipse.org they expect to get Eclipse when they go to download any of the packages off that site. For another reference, think about how Visual Studio brands their Express editions: They all have branded icons (C#,C++,Visual Basic) and names begining with Microsoft Visual .... Express Edition as the title, while the full Visual Studio package does not reflect in the title what features are set up and available in the current install. What I'm trying to get across here is that unless the Java EE package tries to be something so different that users KNOW that this is something different than the "classic" package, it should keep the name Eclipse. (Although I cant seem to see it mentioned anywhere, I expect that the Classic is as close to "Eclipse Platform" as you can get).
We discussed this in our conference call yesterday because it affects *all* packages, not only the Java EE IDE Package. We agreed to use 'Eclipse' as application name for every package and I am convinced that this is the best possible solution we have. Regarding the special Mac OSX issues: While I changed the appNames of all packages to 'Eclipse' I am not yet sure that it solves each and every problem with the naming on this particular platform. Maybe we have to re-iterate and adjust things next week.
I think the main complaint here has been fixed. We are still not perfectly consistent with the items listed in comment #18, and not sure if we can be, or what it would take, but suggest a separate bug be open if there are remaining issues.
