Community
Participate
Working Groups
This afternoon I'll be rolling out the new Eclipse Packaging site. It will be found at http://phoenix.eclipse.org/packages during its beta phase. The idea behind the packaging site is to make a portal where you can come to find all of the packages being produced and built by the EPP team. Currently this site is hosting Ganymede M5 content and packages. The site will be linked by the Ganymede M5 links on the download page to get some initial users to see and use it. If you notice any bugs with the site or have some feedback / suggestions please leave them in this bug.
Looks very nice Nathan. Thanks. Here's few quick impressions and thoughts. "Number of Bugs" ... not sure how useful this will be to users, especially on first page, since, I'm assuming, it's happens to be once slice of bugs reported that I would think would be hard to interpret. If anything, maybe it could go on the "more info" page, next to the line that says "enter a bug on this package" (Which, I'm assuming is where the count comes from?). The "feature list" may be too long (and too meaningless) in it's raw form ... perhaps there could be some hierarchy, where the top level is hand created with drill downs to raw features? Most of all ... very nice. Seems like a compact (uncluttered) representation of all the data and links that users would want. Thanks, again.
Thanks, Nathan. Now we have something to discuss! But first of all... * I changed *all* existing references on the EPP webpages to point to the new page * As promised, http://www.eclipse.org/epp/ganymede.php is now a redirect to the new page This should help us to get more feedback during the next weeks. One important thing to change: We need to add something like 'Ganymede *Milestone* Packages' to the page and highlight that it is really *beta* content. Otherwise we will see many confused people out there.
Hello together, please add all Windows x64 versions to this download page, too. The x64 Versions are a "little bit" hidden: You need to click downloads by project and eclipse platform, at the moment. For example this URL: http://download.eclipse.org/eclipse/downloads/drops/S-3.4M5-200802071530/index.php Thank you Andreas Salzborn, STZ object-IT
(In reply to comment #3) > Hello together, > > please add all Windows x64 versions to this download page, too. > The x64 Versions are a "little bit" hidden: You need to click downloads by > project and eclipse platform, at the moment. > > For example this URL: > > http://download.eclipse.org/eclipse/downloads/drops/S-3.4M5-200802071530/index.php > > Thank you > > > Andreas Salzborn, STZ object-IT > The file you've linked is the Eclipse SDK. Its not a package. This site is meant to display packages built by the EPP project.
> The file you've linked is the Eclipse SDK. Its not a package. This site is > meant to display packages built by the EPP project. The general population doesn't know the difference from the SDK and a 'package'. In fact, the SDK is Platform+PDT+PDE+sources in one package.
(In reply to comment #5) > > The file you've linked is the Eclipse SDK. Its not a package. This site is > > meant to display packages built by the EPP project. > > The general population doesn't know the difference from the SDK and a > 'package'. In fact, the SDK is Platform+PDT+PDE+sources in one package. > The site simply isn't designed to show things that aren't part of the EPP Packaging Build process. That's not to say that it can't support it but currently its not within the scope of the task at hand. The point of this site is NOT a replacement for www.eclipse.org/downloads. With more packages being created and released we needed a place to put the other packages without putting 6 or 10 or 20 packages all on the front of the download page. This site is designed to showcase packages. Adding the SDK to it sends the wrong message to the general population about what a package is. The whole idea is that committers from different projects will be maintaining and testing their packages for consumption. These pages are designed to show activity around these packages to provide the user an accurate barometer of bugs / testing / maintenance that is done on these packages. Perhaps some effort is required in informing the community more about what a 'package' is.
I think this raises a point about how the download site and the packaging site are related. I don't think the end user is going to care much about the differences nor about what a package is. All they will care about it is how to get the correct download for their profile.
Cosmetic: * the "Find out More..." should be "more..." and be right justified under the paragraph in order to avoid visual clutter. * the (for me) "- Windows (156 MB)" is just visual clutter and not useful information. In fact, it took me a while to figure out that that is the download os and size rather than part of the descriptive paragraph. * if you got rid of the right column text and moved it below the left menu (lots of white space there), then you could make the table wider and more readable. * clicking on the icon takes me a different place than clicking on the title - that seems confusing * how about a "download" button under the icon with a left margin of 20 or 30 to make it very very visually obvious how to download that package? * similarly, the list of operating systems is interesting, but there's no explanation of what the list is for - perhaps a "download for..." title above the list? * also that list should be left justified
(In reply to comment #8) > Cosmetic: > * the (for me) "- Windows (156 MB)" is just visual clutter and not useful > information. In fact, it took me a while to figure out that that is the > download os and size rather than part of the descriptive paragraph. I agree that the OS is redundant. Perhaps a "packages for <insert OS>" somewhere at the top to avoid repetition. I think the file size will well serve the large numbers of visitors who don't have broadband. > * clicking on the icon takes me a different place than clicking on the title - > that seems confusing meetoo I think we should put all the OS icons in a zip file and file it as a CQ. It would be really nice to represent the OSses visually.
Can you please provide access to the version information of each feature in the build and of the platform it is based on? For example, the link below includes a lot of features from the Eclipse MDT project. However, I have no idea which versions of the MDT-related features and plugins are in the packaged build. http://phoenix.eclipse.org/packages/eclipse-ide-software-architects-and-modeling If we have Ganymede M6 package builds, surely some folks will want to find out what's different between M5 and M6 before downloading.
(In reply to comment #10) > Can you please provide access to the version information of each feature in the > build and of the platform it is based on? > > For example, the link below includes a lot of features from the Eclipse MDT > project. However, I have no idea which versions of the MDT-related features and > plugins are in the packaged build. > > http://phoenix.eclipse.org/packages/eclipse-ide-software-architects-and-modeling > > If we have Ganymede M6 package builds, surely some folks will want to find out > what's different between M5 and M6 before downloading. > I really can't offer you that type of information, the files that i'm parsing simply list <feature id="org.eclipse.platform" version="latest"> I'm not sure what benefit there is the user to see Latest for each feature. Perhaps Markus can expand on this.
(In reply to comment #11) > (In reply to comment #10) > Perhaps Markus can expand on this. Yepp, I can. I think the feature version is not too important for most users. But when I read this quite a while ago I thought that it might be helpful if we add a link to the EPP build logfile. That would resolve the problem because in most cases you have the version information only in this logfile. And a user who is really interested in the exact version number (before downloading a package) could look into that file.
Two more things: [1] We are listing the currently open bugs for a certain package. I think this is a very good idea because it gives additional feedback to a user who wants to download a package. But what I would add as another feature is a direct link that lists exactly these open bugs in the browser. [2] That's really a new feature request but sooner or later we need a solution for this usecase: History and multiple versions. Until the Ganymede release in June we will update the packages with milestone releases (yes, milestones!), then the content will change to released package. Later this year, we will add the Ganymede Fall release to it and maybe other milestones. I would like to make it as easy as possible for users to choose between a) release versions (plus maybe old releases) and b) milestone versions. What are your opinions?
From bug#220272: it can be useful to know which versions of each feature are included in the package.
The Checksum links, after expanding the checksum section on the more details pages, show up very small and are practically unreadable.
Also, when clicking on a download link I get a new page (new tab in firefox) and when clicking on a checksum download link, it redirect my current page. It would be nice of both sets of links behaved the same.
This is not really related to the new site, but instead with the current package naming scheme, but since you're redesigning the whole thing... Why not use version numbers instead of 'winter', 'summer' etc? IMHO "eclipse-java-europa-3.3.2-tar.gz" makes much more sense than "eclipse-java-europa-winter-tar.gz".
Is this page eventually intended for general use, after 3.4 is released? If so, 1) cannot find a Compare Eclipse Packages page (equivalent to http://www.eclipse.org/downloads/moreinfo/compare.php). From a more casual user's point of view, that page is very helpful - far more than the feature list. 2) the Eclipse for RCP/Plug-in Developers feature list does not include the JDT, which is bound to cause confusion.
(In reply to comment #15) > The Checksum links, after expanding the checksum section on the more details > pages, show up very small and are practically unreadable. I already added this as separate bug 226804 The other issue with the checksum files is mentioned in the same bug: The download link should point to download.eclipse.org and *not* to a download mirror location.
(In reply to comment #17) > This is not really related to the new site, but instead with the current > package naming scheme, but since you're redesigning the whole thing... Why not > use version numbers instead of 'winter', 'summer' etc? IMHO > "eclipse-java-europa-3.3.2-tar.gz" makes much more sense than > "eclipse-java-europa-winter-tar.gz". We already had several discussions about the package naming (e.g. in bug 191449). The idea is to use the release train name and not the version number of the included Eclipse Platform and IMHO this makes sense. But if you come up with better ideas, please open another bug against EPP for further discussion.
Created attachment 96441 [details] Modeling package icon Can you please use the attached image as the Modeling package icon? It's the same image we use in the About dialog, and a miniature of our logo.
(In reply to comment #21) Thanks to Markus for making me aware of the obvious... the image is gotten from our package config file. I've updated it and added the image to the modeling website http://www.eclipse.org/modeling/images/modeling_about.png
(In reply to comment #20) > (In reply to comment #17) > > This is not really related to the new site, but instead with the current > > package naming scheme, but since you're redesigning the whole thing... Why not > > use version numbers instead of 'winter', 'summer' etc? IMHO > > "eclipse-java-europa-3.3.2-tar.gz" makes much more sense than > > "eclipse-java-europa-winter-tar.gz". > > We already had several discussions about the package naming (e.g. in bug > 191449). The idea is to use the release train name and not the version number > of the included Eclipse Platform and IMHO this makes sense. > > But if you come up with better ideas, please open another bug against EPP for > further discussion. > Hi Markus, using the release train name isn't the problem -- in fact I think it's a plus. My only gripe is the use of season names, IMHO it's a poor way of positioning the release in time (eg. since I live in the Southern hemisphere, "winter" means Jun-Sep to me, which is obviously not what it means for you guys). Using month names would be much more useful.
(In reply to comment #23) > Using month names would be much more useful. FWIW, I've always been uncomfortable with using Fall and Winter due to the reasons you mentioned. I do like the suggestion of using months.
+1 for NOT using summer, winter, etc. This is not intuitive for us living on southern hemisphere.
I've opened bug 227767 to continue the seasonal discussion.
Another side issue, sort of. If I enter only http://phoenix.eclipse.org/ I get a 404, not found error. I suggest there be _something_ put there, even if merely an automatic re-direct to http://phoenix.eclipse.org/packages/ (I'll admit, I just have a poor memory and have tried typing in only "phoenix.eclipse.org" a few times before I thought to bookmark it. :)
(In reply to comment #27) > Another side issue, sort of. > > If I enter only > http://phoenix.eclipse.org/ > I get a 404, not found error. Webmasters, please correct me but AFAIK * phoenix.eclipse.org is the test environment for the webmasters and used for the beta release and early feedback of the packaging site * in the end it will be something like eclipse.org/packages
(In reply to comment #28) > (In reply to comment #27) > > Another side issue, sort of. > > > > If I enter only > > http://phoenix.eclipse.org/ > > I get a 404, not found error. > > Webmasters, please correct me but AFAIK > > * phoenix.eclipse.org is the test environment for the webmasters and used for > the beta release and early feedback of the packaging site > * in the end it will be something like eclipse.org/packages > Right you are Markus. Phoenix.eclipse.org uses that exact same config as the live site but with PHP errors / warning displayed. Once the packaging site becomes final it will be moved to www.eclipse.org/packages
Just a note that the packaging site URL is now http://www.eclipse.org/downloads/packages/
I would like to see a reference to the "New and Noteworthy" for the milestone build somewhere on this page.
Since I am not an expert at all of the Eclipse names and numbers, I could not use this site for my purpose: I need a version of eclipse that includes "WTP 3.0". As far as I could see the site does not include this information, which I think is important.
I've pushed some visual changes through on friday. Cleaner look for the packages list, different font, column headings etc. On the Packages More Info page ive added some a dialogish look and changed the layout some. Feedback appreciated. Also (In reply to comment #31) > I would like to see a reference to the "New and Noteworthy" for the milestone > build somewhere on this page. > I'll look into seeing if/how we can add this. (In reply to comment #32) > Since I am not an expert at all of the Eclipse names and numbers, I could not > use this site for my purpose: I need a version of eclipse that includes "WTP > 3.0". As far as I could see the site does not include this information, which I > think is important. > I've covered this previously in the bug, currently the data that i consume doesn't know its own version. Just "latest". However i do see the value in adding this field.
(In reply to comment #6) > (In reply to comment #5) > > > The file you've linked is the Eclipse SDK. Its not a package. This site is > > > meant to display packages built by the EPP project. > > > > The general population doesn't know the difference from the SDK and a > > 'package'. In fact, the SDK is Platform+PDT+PDE+sources in one package. > > > > The site simply isn't designed to show things that aren't part of the EPP > Packaging Build process. That's not to say that it can't support it but > currently its not within the scope of the task at hand. (I really wish eclipse would quit using "SDK" in an ambiguous way, I can never decide what is meant: a kit to develop software or the platform for developing eclipse). Ganymede is in large part a short list of common configurations that will be soon shipped as a unit to users. As such it represents a excellent target for plugin developers: a known test point and simple way to specify prerequisites. For this reason, knowing exactly what versions are included in the package is important AND knowing the exact URL for the source of the components of the package would be extremely valuable. This information would greatly reduce errors and confusion but plugin developers outside of the eclipse homeland. I hope you will consider including the URLs for the source on the page.
When will the M7 packages be available?
I beleive they come out on next Tuesday. You can check http://wiki.eclipse.org/Ganymede for more info on Ganymede Builds.
(In reply to comment #36) > I beleive they come out on next Tuesday. You can check > http://wiki.eclipse.org/Ganymede for more info on Ganymede Builds. It's Tuesday, and the server freeze ended last night. Will they be up today, or did the GMF/UML2 Tools problems delay things?
Yes there is a delay, expect the m7 packages to hit the site sometime today once more mirrors have picked up the files.
I've turned on the M7 Bits for the packaging site. If you encounter any problems downloading files its probably due to the slow start the mirrors got on these files. On a side note. With this release i've introduced the concept of having past / present and future versions of packages. You'll notice on the left nav theres a link to M6 and M7 packages. by adding /release/ganymede/m6 to the url you'll see the listing of packages for that milestone. Also you'll notice that more info pages for each package urls have changed to have a /ganymedem6 or /ganymedem7 at the end of the URL. This lets you know which milestone your looking at. I'll be adding more to the theme to make it easier to distinguish which milestone your on. If you notice any bugs please post them!
I posted Bug 232269 against p2 as the JEE package, at least on Mac, does not actually have all the additional features and plugins installed. Even tho they are in the correct locations. I figured I'd mention it here since I suppose it could also be some misconfiguration of the package?
Eclipse uses the Directory name as project name (project explorer) When you import a project "production-appli" into eclipse, that has the path "<some path>/production/appli" then eclipse names this project only "appli" instead of "production-appli" as named in the .project file. --> you cannot import two project of two different workingsets that are in directories like: "<some path>/production/appli" <name>production-appli</name> "<some path>/unstable/appli" <name>unstable-appli</name> Thanks, Roland
I'd like a "Get Everything" download option. I've tried getting JEE and then adding CDT, and TPTP using the update site mechanism but it takes a lot longer than it used to and there seem to be a number of incompatibilities.
+1 on an package that is an everything package, I need J2ee, Modeling, Plugin development and may need CDT in future. would like to basically have an option to get it all.
Windows XP SP2 x32, JDK 1.6.0_03 I tried eclipse-reporting-ganymede-M7-win32 and then eclipse-jee-ganymede-M7-win32 packages and if I start the eclipse there isn't any JEE or Birt plugins. It is not even possible to create a Java Project, only a standard project can be created.
(In reply to comment #44) > Windows XP SP2 x32, JDK 1.6.0_03 > > I tried eclipse-reporting-ganymede-M7-win32 and then > eclipse-jee-ganymede-M7-win32 packages and if I start the eclipse there isn't > any JEE or Birt plugins. > It is not even possible to create a Java Project, only a standard project can > be created. Sounds like bug 231178 (or my own bug 232269, that should likely have been marked a duplicate by now). Did you rename the eclipse folder?
This bug is intended to get feedback and suggestions about the new packaging website. Please report bugs in the packages as separate bugs. (Reporting bugs against a specific package is easy: Go back to the packaging website (http://www.eclipse.org/downloads/packages/), click at 'More...' and find the 'File a Bug on this Package' link on the package details page.)
(In reply to comment #45) > (In reply to comment #44) > > Windows XP SP2 x32, JDK 1.6.0_03 > > > > I tried eclipse-reporting-ganymede-M7-win32 and then > > eclipse-jee-ganymede-M7-win32 packages and if I start the eclipse there isn't > > any JEE or Birt plugins. > > It is not even possible to create a Java Project, only a standard project can > > be created. > > Sounds like bug 231178 (or my own bug 232269, that should likely have been > marked a duplicate by now). Did you rename the eclipse folder? > Yes, I did. I renamed it and it is Ok now. Thanks!
(In reply to comment #46) > This bug is intended to get feedback and suggestions about the new packaging > website. Please report bugs in the packages as separate bugs. > > > > (Reporting bugs against a specific package is easy: Go back to the packaging > website (http://www.eclipse.org/downloads/packages/), click at 'More...' and > find the 'File a Bug on this Package' link on the package details page.) > Ok, It would be good to have an everything package and AJDT.
In the list of Europa packages, there was an "Eclipse Classic" package. It looks as if this package is missing from the Ganymede package site.
Ganymede RC1 Packages are now live on the packaging site. I've added the Eclipse Classic Download to the site. We've got some versioning info for features into the config files, expect to see something this week on that front. As usual please report any problems with the website here.
The "Eclipse Classic Download" is the only download that works for me. The other packages give this error: > Eclipse downloads - file unavailable > > The selected file is invalid, or it is no longer available for download. > > This happens when the file is part of a nightly or development build. If so, > please return to the project's home page and download a newer version. > > Go back. M7 and M6 packages are also giving this error.
Andrew, I'm seeing the same problem as well, but found a workaround: http://ftp.osuosl.org/pub/eclipse/technology/epp/downloads/release/ganymede/ This will drop you into the OSU FTP mirror server and then you can choose the RC1 directory and then the package you'd like to download. Hope that helps!
Thanks for reporting the error, looks like a '/' was missing from the path. Should be fixed.
I can confirm that it seems to be fixed for all packages and versions. Thanks!
(In reply to comment #32) > Since I am not an expert at all of the Eclipse names and numbers, I could not > use this site for my purpose: I need a version of eclipse that includes "WTP > 3.0". As far as I could see the site does not include this information, which I > think is important. > Over the weekend I went back into the auto-updater code for the site and added some parsing ability to read out the version for each feature. This information is now available in the collapsible feature list.
In the package details page (from "more..." link) the collapsible feature list should order plugins alphabetically. It is hard to see the plugins you are looking for.
What about the performance of that site? I think this is something to keep in mind, because in the background we do a lot of XML-parsing, Bugzilla querying, etc. and I am not sure what happens when we release Ganymede. Are we prepared for that? AFAIK, the XML files and the file sizes are parsed/checked only once and an update happens if and only if the last modified date of the file has changed. Is this correct? If so then the XML files shouldn't be an issue. What about the Bugzilla queries? Other dynamic elements of the site?
(In reply to comment #56) > In the package details page (from "more..." link) the collapsible feature list > should order plugins alphabetically. It is hard to see the plugins you are > looking for. Fixed. I've change the sort back to the feature name. (In reply to comment #57) > What about the performance of that site? > > I think this is something to keep in mind, because in the background we do a > lot of XML-parsing, Bugzilla querying, etc. and I am not sure what happens when > we release Ganymede. Are we prepared for that? > > AFAIK, the XML files and the file sizes are parsed/checked only once and an > update happens if and only if the last modified date of the file has changed. > Is this correct? If so then the XML files shouldn't be an issue. Every 15 minutes the site checks to see if there is an update. If the timestamps on the config files have changed then the contents of that package are updated. > What about the Bugzilla queries? Other dynamic elements of the site? Bugzilla Queryies are generated on pageview. This is a very low cost query as i'm pinging the databases directly. In terms of the actual Ganymede release date, the download page will soon start displaying a cached version of the drupal data and that should hopefully drive the majority of the traffic.
(In reply to comment #57) > What about the performance of that site? I sent more simultaneous traffic to the packaging pages than what Ganymede ever will, and I didn't see any noticeable resource hog. Nathan, can you confirm which DB connection object you're using for Bugzilla? If you're using bugs-ro then the queries will be cached anyway.
I'm not using a DB object to connect but i am using bugs_ro to connect
I think these packages are great for general use. There are a few more things that would be useful in them for me personally, but I don't think that they are used broadly. For example: the delta pack, subversive, jira support for mylyn. I think it would be great if I could get these via the update sites that are installed when the package is delivered. With respect to the delta pack, I'm not sure if an update site even exists that has it, so I guess I will have to stick to downloading it and unzipping it over my install. On subversive, I found part of it on the ganymede update site: http://download.eclipse.org/releases/ganymede. This site is already included in the package that I downloaded (modeling) However, it isn't in the default list of sites checked for "Available Software". I had to add it myself by going to "Manage Sites" and then checking the box adjacent to that site. It seems to me that the ganymede site should be in the default list. The part of subversive that is included corresponds to the update site: http://download.eclipse.org/technology/subversive/0.7/update-site/ There are two more parts of subversive that are not included, one of which is required, and corresponds to the update site: http://www.polarion.org/projects/subversive/download/eclipse/2.0/update-site/ I'm guessing that perhaps it isn't included because it points to a third party site? I would feel that is okay although the update site list also includes the third party site at www.topcased.org already. With respect to the JIRA support for Mylyn, I was able to get this via the http://download.eclipse.org/tools/mylyn/update/extras site, which was one of the non-default update sites. I'm not really sure if this support should be available through the ganymede site, or if the update site should be in the default list. I'm inclined to say that the way it works now is fine. To summarize, I am hoping for three things: 1. The default list of update sites in the packages should be reasonable. * include sites of broad applicability such as the Ganymede site. (http://download.eclipse.org/releases/ganymede) 2. The non-default list of update sites in the package should be as comprehensive as possible. * include as many update sites from eclipse.org as possible (I'm sorry that I don't have any good suggestion on how to gather them) 3. All the provided update sites should be useful * don't include sites that don't work "No repository found at http://download.eclipse.org/modeling/m2m/updates/" * don't include sites that won't have any applicable features such as the mylyn eclipse 3.3 site. (http://download.eclipse.org/tools/mylyn/update/e3.3)
(In reply to comment #61) > With respect to the JIRA support for Mylyn, I was able to get this via the > http://download.eclipse.org/tools/mylyn/update/extras site, which was one of the > non-default update sites. I'm not really sure if this support should be > available through the ganymede site, or if the update site should be in the > default list. I'm inclined to say that the way it works now is fine. Good to hear. The update site split has always been a challenge. We currently make the split along the lines of support level and maturity. For the latest on this split, check out bug 214182 comment#7. The only appreciable difference for Ganymede will be that the Trac will not be on the Ganymede update site, but not that it was already excluded from EPP distros. In addition, one thing we are doing to reduce clicks for those wanting Extras is to add that update site to the "Sites to visit" part of the feature, which causes the Extras site to be available in P2 and the Update Manager.
(In reply to comment #61) > 2. The non-default list of update sites in the package should be as > comprehensive as possible. > * include as many update sites from eclipse.org as possible (I'm sorry that > I don't have any good suggestion on how to gather them) That is not going to happen, sorry. The Eclipse IP Policy is very clear and quite strict about what each package can and cannot include. Other sites with uncleared IP is definitely on the "not allowed" column.
(In reply to comment #61) > I would feel that is okay although the update site list also includes > the third party site at www.topcased.org already. Which package did you download and find topcased.org in?
(In reply to comment #63) > (In reply to comment #61) > > 2. The non-default list of update sites in the package should be as > > comprehensive as possible. > > * include as many update sites from eclipse.org as possible (I'm sorry that > > I don't have any good suggestion on how to gather them) > > That is not going to happen, sorry. The Eclipse IP Policy is very clear and > quite strict about what each package can and cannot include. Other sites with > uncleared IP is definitely on the "not allowed" column. > I guess I expected that update sites hosted by eclipse.org would already be cleared through Eclipse IP. An example of a site that I would think should be okay and in the non-default list could be: http://download.eclipse.org/tools/pdt/updates/site.xml On the side of "How to do it", maybe one could start with searching for site.xml anywhere in "download.eclipse.org". This could conceivably generate a lot of outdated sites, I suppose.
(In reply to comment #64) > (In reply to comment #61) > > I would feel that is okay although the update site list also includes > > the third party site at www.topcased.org already. > > Which package did you download and find topcased.org in? > Ganymede RC2 for Modeling. http://www.eclipse.org/downloads/packages/eclipse-modeling-tools/ganymederc2 The topcased.org doesn't seem to indicate a real update either. (trying to update from it generates an error)
(In reply to comment #66) I'm sorry Andrew, I didn't read carefully enough. I thought you said: "include as many non-eclipse.org update sites as possible" when in fact you said the opposite. My apologies.
(In reply to comment #66) > > Which package did you download and find topcased.org in? > > Ganymede RC2 for Modeling. I opened bug 235582 to take care of the topcased.org discovery elements contributed by EMFT Search.
(In reply to comment #33) [...] > (In reply to comment #31) > > I would like to see a reference to the "New and Noteworthy" for the milestone > > build somewhere on this page. > > > > I'll look into seeing if/how we can add this. Any news on this? I just downloaded RC2 and it would be really nice if there was a clear reference to its "New and Noteworthy" info somewhere on the downloads page...
Much, much better that the previous one. Thanks for the hard work.
(In reply to comment #61) > 2. The non-default list of update sites in the package should be as > comprehensive as possible. > * include as many update sites from eclipse.org as possible (I'm sorry that > I don't have any good suggestion on how to gather them) +1 Should a separate bug against EPP be opened up for this?
The new site looks really, really nice! I particularly like the layout, the usability, and enjoy having bug count and download statistics right on the page. Just one observation: The download stats are wrong. How are they computed? I was surprised that Eclipse Classic 3.4RC2 had only 389 downloads, and checked current stats from the Committer Tools (via portal): 4289. That's quite a difference! I did a copy&paste of the URL from the EPP Download, got rid of the prefix, and then pasted the relative path into the committer tools download stats page: /eclipse/downloads/drops/S-3.4RC2-200805230100/eclipse-SDK-3.4RC2-win32.zip Should I file a separate defect for this, or is it just a misunderstanding, or is it already known?
(In reply to comment #72) > The new site looks really, really nice! I particularly like the layout, the > usability, and enjoy having bug count and download statistics right on the > page. > Thanks I'm glad you like it! > Just one observation: The download stats are wrong. How are they computed? I > was surprised that Eclipse Classic 3.4RC2 had only 389 downloads, and checked > current stats from the Committer Tools (via portal): 4289. That's quite a > difference! > > I did a copy&paste of the URL from the EPP Download, got rid of the prefix, and > then pasted the relative path into the committer tools download stats page: > /eclipse/downloads/drops/S-3.4RC2-200805230100/eclipse-SDK-3.4RC2-win32.zip > > Should I file a separate defect for this, or is it just a misunderstanding, or > is it already known? > The only clicks that are calculated in this count are ones that are performed from the packaging site. I'm sure that the platform team has links out there to the "Classic Download" in other places.
(In reply to comment #73) > The only clicks that are calculated in this count are ones that are performed > from the packaging site. Ah, I see. Just out of curiosity, can you explain more clearly on what page(s) exactly the clicks are counted, and if/how the counters are reset when a new milestone is promoted to the main page (and the old milestone archived)? I just checked JEE and got a total of 988 downloads versus 1226 advertised on your site. Could that be because the "Committertools stats" will update again only at midnight today, so yours include today's downloads up-to-the-minute? /technology/epp/downloads/release/ganymede/RC2/eclipse-jee-ganymede-RC2-linux-gtk.tar.gz 2008-06-04 95 2008-06-03 40 2 records found. 135 /technology/epp/downloads/release/ganymede/RC2/eclipse-jee-ganymede-RC2-win32.zip 2008-06-04 416 2008-06-03 291 2 records found. 707 /technology/epp/downloads/release/ganymede/RC2/eclipse-jee-ganymede-RC2-linux-gtk-x86_64.tar.gz 2008-06-04 42 2008-06-03 13 2 records found. 55 /technology/epp/downloads/release/ganymede/RC2/eclipse-jee-ganymede-RC2-macosx-carbon.tar.gz 2008-06-04 58 2008-06-03 33 2 records found. 91
(In reply to comment #74) > (In reply to comment #73) > > The only clicks that are calculated in this count are ones that are performed > > from the packaging site. > > Ah, I see. Just out of curiosity, can you explain more clearly on what page(s) > exactly the clicks are counted, and if/how the counters are reset when a new > milestone is promoted to the main page (and the old milestone archived)? > When you click any of the download links (Windows, Linux 32bit, Linux 64Bit, Mac OSx) links you can see there is an onClick action. This performs an ajax call to the site to increase the click count. Counters are reset when a new RC / Milestone is made. This is because i am creating a new node in the drupal site to keep track of each release. I suppose some logic could be added to find like packages and offer a total count but this is something that is going to change once this site begins in what i would refer to as a normal release cycle. Currently each package node has a past / present / or future status. Currently we are using Present for the RC / milestone builds. where as next year these would be referred to as future builds. And Ganymede releases would be either Past / Present builds. Once the final Ganymede bits are on the server these nodes will have a longer lifetime and the download stats will have more relevance. Hope this explains what your looking for.
Absolutely! Thanks. Those Ajax calls for counter updating sound interesting. Seems like lower overhead than the "download.sh" script that's used for mirroring/counting. I've been thinking how download stats could be computed for updates being pulled with P2, do you think that the very same Ajax calls could be executed from P2/update manager?
Not sure if this is the right bug...but I think it would be great if there for each Package also were the corresponding SDK bundle with sources etc.
It would be great to have an "All in one" package.
(In reply to comment #78) > It would be great to have an "All in one" package. > There has been an number of requests for an 'All in one' package. However, if you really want everything, wouldn't using the update manager be easier. I worry that the all in one would be a huge download in terms of size.
Unfortunately, it's not that easy. When using the update sites, you keep getting messages about dependencies that can't be fulfilled. You also run into problems where the plugin provider doesn't include all of the dependencies in one URL (the Subversive plugin, and Mylyn plugins are good examples of that). Subversive provides a core plugin, but the connectors that actually do the work are only available through a separate update site. At least if we had a single download we'd be reasonably certain that all dependencies had been satisfied. It would also address a basic usability issue with Eclipse. There are a number of users who don't want to install a bunch of plugins (or spend their time trying to figure out which plugins to download) in order to get started on a project. (In reply to comment #79) > (In reply to comment #78) > > It would be great to have an "All in one" package. > > > > There has been an number of requests for an 'All in one' package. However, if > you really want everything, wouldn't using the update manager be easier. I > worry that the all in one would be a huge download in terms of size. >
We need to remove the login button at the bottom of the page. I realize this is just for adminstrators, so we need to have an admin page.
(In reply to comment #80) > Unfortunately, it's not that easy. When using the update sites, you keep > getting messages about dependencies that can't be fulfilled. You also run into > problems where the plugin provider doesn't include all of the dependencies in > one URL (the Subversive plugin, and Mylyn plugins are good examples of that). > Subversive provides a core plugin, but the connectors that actually do the work > are only available through a separate update site. Those third party connectors can't be provided at Eclipse due to license issues. If you're looking for an all-in-one single-source download including content NOT hosted at Eclipse, look to something like http://www.yoxos.com/ondemand/ > At least if we had a single download we'd be reasonably certain that all > dependencies had been satisfied. It would also address a basic usability issue > with Eclipse. There are a number of users who don't want to install a bunch of > plugins (or spend their time trying to figure out which plugins to download) in > order to get started on a project. The difference between "all of ganymede in a single zip" and "all of ganymede on an update site" is relatively trivial*. If you don't want to pick and choose plugins, just select the entire site and install the whole shebang. The added benefit is that p2 will allow you to do multi-threaded multi-mirror downloads, so the performance is actually more like downloading an "everything in Ganymede zip" via a grid. * - The update site is packed for size, digested for performance, and contains all the requisite p2 metadata. The zip omits all this and is therefore actually bigger to install and arguably would take longer to start up (because of the lacking metadata, unless I'm mistaken, p2 has to generate all that stuff on the first start).
> However, if you really want everything, wouldn't using the update manager be easier. When using the update manager we should download all plugins multiple times (once for each workplace or after each OS reinstall). With 'All in one' package this task would be much easier. And I don't expect the third-party plugins from eclipse.org packages. > I worry that the all in one would be a huge download in terms of size. It should be bigger than the biggest one (Eclipse Modeling Tools for now) but not impossibly huge and definitely the time saver for multiple multipurpose workplace installations.
Talking about rolling out a cusomized version of Eclipse to multiple workplaces, wouldn't you just make one local master installation, and then clone that one to your other workplaces? I cannot quite see how a giant ganymede-all-in-one package download could help here. What might make sense, though, is an "Archived update site" of Ganymede, in order to simplify local mirrors of the Ganymede site or install custom stuff from it. Such an archived site would be considerably smaller than a giant downloadable package, since it could hold packed jars. I've been making such an archived update site for all of Ganymede M5, and it had been 291MB large at that time.
> Talking about rolling out a cusomized version of Eclipse to multiple workplaces, wouldn't you just make one local master installation, and then clone that one to your other workplaces? So how should I make this one local master installation? Should I download five huge packages with some similar features? Or use update manager instead of my favorite download manager for multimegabyte downloads? Or download features from many project download pages? And then somehow "clone" that all. I think that this is the packages is standing for. > I cannot quite see how a giant ganymede-all-in-one package download could help here. The same way the ganymede-modeling could help modeling-only users or the ganymede-cpp could help c++-only users. I want to use not only enterprise java, not only modeling, not only c++ and not only reporting but all of this in one eclipse installation. When the new version of netbeans IDE appears, I download all-in-one package just for looking at all that new features. That's great that I can do this in one simple step. I think that many novice eclipse users could find the 'all-in-one' package helpful for starting the exploration of our favorite IDE. > What might make sense, though, is an "Archived update site" of Ganymede, in order to simplify local mirrors of the Ganymede site or install custom stuff from it. It would be helpful. But I think that 'all-in-one' package is much more simple way from user's point of view.
(In reply to comment #85) > So how should I make this one local master installation? Get any package you like, and then pick what you need from the Ganymede site. The Ganymede site provides categorized listing of features, automatic dependency checking and resolving, automatic mirror selection and packed Jars. So, in terms of download speed I'm pretty sure that you'll get the most efficient download you can have from the Ganymede site, along with the most versatile selection of items. This is very similar to other software distributions who provide a "Web Installer" download first, and allow you to pick components afterwards. Just look at the Sun JDK's who recently provide an "online installation", or all the Microsoft products. > And then somehow "clone" that all. Clone is super-simple: Pick your installation, right-click > Add to ZIP. Extract on any other computer. > When the new version of netbeans IDE appears, I download all-in-one package > just for looking at all that new features. That's great that I can do this in > one simple step. I think that many novice eclipse users could find the > 'all-in-one' package helpful for starting the exploration of our favorite IDE. That's a very good argument, and I don't know how big the Netbeans all-in-one package is... but are you aware of the sheer size of Eclipse Ganymede? I just checked, and with Ganymede M5 an all-in-one package ZIP would be 519 MBytes. Which has VERY likely even grown larger as of Ganymede final release. Would you really want to download that as one package? Just compare to the 291 MBytes that an archived update site takes. If yes, then it's probably time to start a new packaging discussion in the EPP project. As far as I'm aware, this requires filing a Bug in Bugzilla asking for that new package kind, and then naming some people who'd be responsible for trying out that package and testing it. Maybe, in terms of the size, what we eventually want is an "All-in-one" DOWNLOAD which holds the packed jars (and is thus as large as the archived site), integrated with a P2 installer exe that allows installing a selection of stuff. I think we have all the technology that's required for such a thing, we'd just need to have somebody take the time and do it (not me) :-)
(In reply to comment #86) > Get any package you like, and then pick what you need from the Ganymede site. So I should download almost the same things just with more manual steps instead of one. > This is very similar to other software > distributions who provide a "Web Installer" download first, and allow you to > pick components afterwards. Just look at the Sun JDK's who recently provide an > "online installation", or all the Microsoft products. I'm trying to avoid "web installers" because of multiple installation issue. I prefer to download once and install anytime i need and use almost instantly. > That's a very good argument, and I don't know how big the Netbeans all-in-one > package is... 156M > but are you aware of the sheer size of Eclipse Ganymede? I just > checked, and with Ganymede M5 an all-in-one package ZIP would be 519 MBytes. Huge indeed, but I think it's reasonable value (less than double of ganymede-modeling size). And one could use update manager option anytime if prefer. > Maybe, in terms of the size, what we eventually want is an "All-in-one" > DOWNLOAD which holds the packed jars (and is thus as large as the archived > site), integrated with a P2 installer exe that allows installing a selection of > stuff. Looks promising. Thanks for enlightening comments!
(In reply to comment #87) > (In reply to comment #86) > > Get any package you like, and then pick what you need from the Ganymede site. > > So I should download almost the same things just with more manual steps instead > of one. I also vote for an all in one package. I need them for two reasons: a) When packaging for a Linux distribution I maintain a fat package, but full would be better preferable. b) On our campus we maintain a site installation and of course the parts not in the SDK (or RCP) will get installed in the students home dirs multiple times. Really i don't see what is so special about 500MB vs. 100MB, we have GBit Ethernet and Terabyte RAIDS ;) I also bet /home/*/*/.eclipse .eclipse is far bigger on the campus (with subdirs for beginning letter of student userid in case you wonder).
I has a look at http://www.eclipse.org/downloads/packages/ today and noticed two issues. 1. The list should be sorted alphabetically. Having "Eclipse IDE for Java ..." at the top then something in between and then back at the bottom doesn't make sense. If the current sort order is popularity then it should be indicated somewhere and an option to switch to alphabetically. Note, popularity == random for a lot new visitors and random is bad usability. 2. "Windows" needs an architecture indicator as well. There are 32bit and 64 bit Windows downloads. To avoid adding yet another line an option might be to format it in the following way. Windows (_32bit_, _64bit_) OS X (Carbon) Linux (_32bit_, _64bit_)
(In reply to comment #89) > 2. "Windows" needs an architecture indicator as well. There are 32bit and 64 > bit Windows downloads. To avoid adding yet another line an option might be to > format it in the following way. There are 64bit Windows versions available from the Eclipse Platform, but there is *no* 64bit Windows EPP package. We are not providing packages for several platforms, such as Solaris, AIX, ...because the user demand is quite low and we cannot test them. If there were volunteers (you?) we could think about adding a Win64 build.
(In reply to comment #89) > 1. The list should be sorted alphabetically. Having "Eclipse IDE for Java ..." > at the top then something in between and then back at the bottom doesn't make > sense. If the current sort order is popularity then it should be indicated > somewhere and an option to switch to alphabetically. Note, popularity == random > for a lot new visitors and random is bad usability. I disagree. Every Item in the list starts with Eclipse so sorting it alphabetically will not seem that much different then sorting by popularity. I also don't think that popularity == random. While this may lead to some inflation of the packages at the top since they are already at the top, i think its an acceptable compromise. That's not to say that I won't add a sorting feature in the future, i just don't see the benefit at this point.
(In reply to comment #91) > Every Item in the list starts with Eclipse so sorting it > alphabetically will not seem that much different then sorting by popularity. If everything starts with "Eclipse" that begs the question: "why not just remove all those extra 'Eclipse' words and make the list easier to read?" Plus, a sorted list, even by the second word: A A A B A C A D A E is easier to read than an unsorted list: A D A A A C A E A B Maybe I'm missing the point, but isn't this page supposed to be making it _easier_ for consumers to find the package they are looking for?
I agree with Bjorn. With seven packages in the list, we're treading into the "I need to think" territory, so we need to remove the fluff and put the Most Significant Bits to the left Now: Eclipse IDE for Java EE Developers (161 MB) Eclipse Classic (149 MB) Eclipse for RCP/Plug-in Developers (173 MB) Eclipse Modeling Tools (290 MB) Eclipse IDE for C/C++ Developers (68 MB) Eclipse IDE for Java Developers (84 MB) Eclipse IDE for Java and Report Developers (186 MB) I suggest: C/C++ IDE (68 MB) Eclipse Classic (149 MB) Eclipse for RCP/Plug-in Developers (173 MB) Java and Reporting IDE (186 MB) Java EE IDE (161 MB) Java IDE (84 MB) Modeling Tools (290 MB)
(In reply to comment #92) > > If everything starts with "Eclipse" that begs the question: "why not just > remove all those extra 'Eclipse' words and make the list easier to read?" > If we remove the word Eclipse and sort it alphabetically then the list would look like this. Classic IDE for C/C++ Developers IDE for Java and Report Developers IDE for Java Developers IDE for Java EE Developers Modeling Tools RCP/Plugin Developers I personally don't see how this makes it any easier to read. I suppose we could get rid of the "IDE for" as well, but then when you drill down into those packages more info page the title will simply be "C/C++ Developers" which i think is much more confusing. Keep in mind that we want to keep the words Eclipse (IDE) so that search engines can find the packages. I know that if i were searching for a C/C++ IDE I probably wouldn't find it if the title of the package was just C/C++ Developers. > Maybe I'm missing the point, but isn't this page supposed to be making it > _easier_ for consumers to find the package they are looking for? Maybe my brain is wired differently but I don't see how changing the order of sorting of the packages makes that harder. We only have 7 packages currently it shouldn't take you more then 20 seconds to read all their titles and decide which one is currently the best for your needs. Once we reach 20+ packages I think the point your bringing up has more validity. Like i said above, I'm not ruling out adding something that lets you sort the page differently, but at this stage i don't think its necessary.
(In reply to comment #92) I am against removing 'Eclipse' from the packages. In the end it is the decision of the package maintainers how to name their packages, and IMHO having 'Eclipse' as branding in the name makes it very clear that it is an Eclipse package (and not a Linux package, etc. package).
> Classic > IDE for C/C++ Developers > IDE for Java and Report Developers > IDE for Java Developers > IDE for Java EE Developers > Modeling Tools > RCP/Plugin Developers +1 for removing "Eclipse", "IDE", and "Developers". Obviously all the packages include Eclipse, are an IDE, and are for development. Let's strip the fluff and focus on the differences. But how about these names: For C/C++ For Java For Java EE, JSF and Web For Java EE, JSF, Web and Reporting For Java and Modeling For Java, RCP, and Plugins (Classic) For Java, RCP, Plugins, and Communication +1 too for removing the sort by # downloads, unless you also provide a link to sort by alpha as well. As an aside, I notice the RCP/Plugin bundle doesn't include the PDE or p2 features [1]. That seems ... odd, to say the least. [1]http://www.eclipse.org/downloads/packages/eclipse-rcpplug-developers/ganymederc3 Also, though GEF is in about half of the packages, it's never mentioned in the names or descriptions. Should it?
(In reply to comment #96) > Let's strip the fluff and > focus on the differences. +1
(In reply to comment #96) > +1 for removing "Eclipse", "IDE", and "Developers". Obviously all the packages > include Eclipse, are an IDE, and are for development. Let's strip the fluff and > focus on the differences. > > But how about these names: > > For C/C++ > For Java > For Java EE, JSF and Web > For Java EE, JSF, Web and Reporting > For Java and Modeling > For Java, RCP, and Plugins (Classic) > For Java, RCP, Plugins, and Communication > -1 for me, Removing these words does not help to make things simple, I think that it only makes things more difficult to understand. While it may make sense to call it "For Java and Modeling" on the main packages page [1]. It wouldn't make sense for it to be called that on the package details page [2]. I think your assuming the only way someone can get to that page is by the main page [1]. Direct Links, Search Engines all bring visitors directly to the pages in question. If I were to show up on a page titled "For Java and Modeling" as a new user I would more then likely have no idea what the page is about. "Eclipse Modeling Tools" or "Eclipse IDE for Java Developers" tells me EXACTLY what this page / package is for. Just because we understand what these packages are because we are in the community doesn't mean that we should lose that context. > +1 too for removing the sort by # downloads, unless you also provide a link to > sort by alpha as well. > I still don't understand the desire to sort these alphabetically by default. Could someone who wants this +1'd give me a better explanation of why this is better? [1] http://www.eclipse.org/downloads/packages/ [2] http://www.eclipse.org/downloads/packages/eclipse-modeling-tools/ganymederc3
(In reply to comment #97) > (In reply to comment #96) > > Let's strip the fluff and > > focus on the differences. > > +1 > Coming soon : http://phoenix.eclipse.org/packages/compare-packages Feel free to comment on this page as well.
Hmmm. With EMF you can regenerate a complete RCP application based on your model, so I think the package has all you need for RCP/Plugins too...
-1 for sorting alphabetically (see below) -1 for multiple sortings unless the list gets a lot longer +1 for sorting by a measure of relevance (given what Mylyn is all about I suppose it's unsurprising that I say that ;) The more packages we have the more confusing the download page gets. There is now a sufficient number of packages that if we don't sort by relevance, we will frustrate users who know what they are after, but who are now now forced to read through multiple entries to find their download. The icons help, but with the exception of the JEE one I don't think that they will be obvious enough for a typical user. In my opinion the best measure of relevance we have is the number of release downloads (either from previous month or previous release). This puts any new entries on the page at a disadvantage when they are first released, but that's typical of user-generated ranking systems, and they will be able to climb the ranks quickly if we base it on the past month's downloads.
> > Coming soon : http://phoenix.eclipse.org/packages/compare-packages > > Feel free to comment on this page as well. > I missed the comparison before and I think that is an important item for helping people understand which package they want. Thanks!
I believe we need to keep this list sorted by popularity. Sorting alphabetically makes no sense to me and would just create confusion. Over time it would be nice to have the ability to sort the list by different ways but we are not there yet. As for the names, I don't see any big advantage of removing them. I do think we need to be consistent but I do think it is the decision of the package maintainers and so far I have not heard them complain.
I agree with sorting by downloads, it just naturally propagates the mostly likely to be selected thing to the top...
(In reply to comment #103) > Sorting alphabetically makes no sense to me and would just create confusion. I'm sorry, I just have to disagree. It may not make sense to you, but it obviously makes sense to others (such as myself) or we wouldn't have brought it up as an issue. I, personally, think that as a new user coming to the site the pseudo-random sorting provided by popularity of downloads creates more confusion. But, like I said, that's just my opinion and the opinion of some other commenters. > As for the names, I don't see any big advantage of removing them. I do think > we need to be consistent but I do think it is the decision of the package > maintainers and so far I have not heard them complain. Since this page is aimed at users, I think we need to think about what the right names are. We have project naming guidelines (not always followed) - I don't see why we wouldn't do the same here with packages. I suspect that most/all package owners would be happy to follow guidelines and, in fact, I suspect that most packages are named the way they are today because some original package was named that way and then everybody copied it.
(In reply to comment #105) > I > suspect that most packages are named the way they are today because some > original package was named that way and then everybody copied it. > Actually the packages we named last year were done by the initial EPP maintainers (Markus, Wayne and myself). We solicited feedback from the EPP newsgroups and then I ensured that legally we were okay with the names. For instance including Java in a product name needs to conform to the naming guidelines of Sun.
Here is the very simply use case for why it should be sorted alphabetically. I visited the site yesterday for the first time. I saw the packages and the thing that immediately hurt my eyes was ... uh, ugly, why is it random? After a while I figured that there _might_ be a reason by the order ... but what reason? Do _they_ want to promote the JavaEE stuff? Is it intentional that C/C++ guys has to scroll for there stuff and the RCP guys not? Why is Classic second if it's useful only for committers? If the sort order is popularity then there *has* to be a popularity indicator. I also don't think that number of downloads is the best popularity indicator ... shit that thing crashed .... maybe my download is broken ... let me download again. It's ok to not sort if there are <= 3 items. But a page with seven items? I'm sorry but I honestly think that visitors should also understand the sort order without visiting a course in "promoting items on your website" or "understanding focused user interfaces using Mylyn". (I apologize if that was harsh for somebody.)
(In reply to comment #106) > We solicited feedback from the EPP newsgroups Just as an FYI: the reason we have the "notifying membership" guidelines for new components (http://www.eclipse.org/projects/dev_process/notifying-membership.php) is because the larger community told me that they were unable to monitor all the newsgroups and that they wanted a single place/feed to learn about all the major initiatives that are being started at Eclipse. Thus I suggest that using the EPP newsgroups for this issue did not provide the 'opinion of the community' that you were looking for. Thus, perhaps, the "we did it this way before" argument is not as strong as it might be. On the other hand, most of the complaints I heard about last year's packages page (the download page itself) were (a) it was hard to find "the SDK" and (b) it wasn't clear what was in each package. We might assume that these were indirect complaints about the package names (on the theory that if the names were better, people would have been able to find what they were looking for), but then I might just be reading more into the data than really exists. I still think that Nick (comment #96) had the cleanest set of names so far: minimalist yet informative.
> I still think that Nick (comment #96) had the cleanest set of names so far: > minimalist yet informative. > Just so everyone know, it is against Sun Java trademark guidelines to include Java or Java EE in a product name without a descriptor following Java; this is why we say 'Java Developers'. You might like Nick's names but unfortunately our lawyers and Sun won't.
(In reply to comment #109) > > I still think that Nick (comment #96) had the cleanest set of names so far: > > minimalist yet informative. > Just so everyone know, it is against Sun Java trademark guidelines to include > Java or Java EE in a product name without a descriptor following Java; this is > why we say 'Java Developers'. You might like Nick's names but unfortunately > our lawyers and Sun won't. I didn't realize that EPP bundles were "products," but hey. Can you point to such a document? All I could find are these, which aren't the most explicit: http://java.sun.com/developer/technicalArticles/JavaOne2005/java_naming_aag.pdf http://java.sun.com/logos/pdfs/477765_Java_Brand_Guide_1pg_FINAL.pdf http://www.sun.com/policies/trademarks/ So, though IANAL, let me try again: (1) For C/C++ Development For Java Development For Java EE, JSF and Web Development For Java EE, JSF, Web Development and Reporting For Java Development and Modeling For Java, RCP, and Plugin Development (Classic) For Java, RCP, Plugin, and Communication Development (if it's okay to use Java in a compound noun or list of nouns) Otherwise... (2) For C/C++ Dev For Java Dev For JSF, Web and Java EE Dev For JSF, Web, Reporting and Java EE Dev For Modeling and Java Dev For RCP, and Plugins and Java Dev (Classic) For RCP, Plugins, Communication and Java Dev Alternatively, we could go the "Bundle" or "Package" route: (3) C/C++ Bundle Java Bundle Java EE, JSF and Web Bundle Java EE, JSF, Web and Reporting Bundle Java and Modeling Bundle Java, RCP, and Plugins Bundle (Classic) Java, RCP, Plugins, and Communication Bundle Or... (4) C/C++ Package Java Package Java EE, JSF and Web Package Java EE, JSF, Web and Reporting Package Java and Modeling Package Java, RCP, and Plugins Package (Classic) Java, RCP, Plugins, and Communication Package Again, if Java can't be part of a noun list, then these last two will need to be reordered a la (2) vs. (1). --- Oh, and as to the issue of sort by alpha vs. sort by rank... really, how hard is it to provide a couple links? Default to the IMHO more obvious "sort by alpha" so people can see similar packages grouped side by side (eg., RCP/Plugins vs. RCP/Plugins+Communications or JSF/Web vs. JSF/Web + Reporting) and let people see the popularity order as an optional link on the right-hand nav. Point me at the code in CVS and I'll write you a patch. You're never going to get consensus on which way is "better" because clearly we all think differently. So provide choice -- isn't that what OSS is all about? :) Oh, and if you want to be fancy, you can cookie the user's selection so their preference persists.
(In reply to comment #96) > As an aside, I notice the RCP/Plugin bundle doesn't include the PDE or p2 > features [1]. That seems ... odd, to say the least. > > [1]http://www.eclipse.org/downloads/packages/eclipse-rcpplug-developers/ganymederc3 Huh, when I read comments like this I get really nervous... :) *If* this were true then it would be a major bug, but I checked it again this morning and couldn't find any missing features in the RCP package. Maybe it is confusing that it includes the org.platform.sdk feature only?
(In reply to comment #110) > I didn't realize that EPP bundles were "products," but hey. We are talking about names for 'something' so I don't think it matters if we debate if they are product or not. > > Can you point to such a document? All I could find are these, which aren't the > most explicit: > > http://www.sun.com/policies/trademarks/ This is the document. > > So, though IANAL, let me try again: Yup, and IANAL either, so anything we do would need to be reviewed. From my experience in these issues, this are closer but I can see some that would have to be tweaked. Regardless of the IANAL discussion, I really have not problems with the current names. The naming policy we use at Eclipse is to prefix projects with 'Eclipse' and so I think it is appropriate to have the packages prefixed with 'Eclipse'. I realize some people don't share this opinion but unfortunately naming is generally a matter of opinion. IMHO, the current names are descriptive, identify the role of the potential user and reinforces the Eclipse brand. This is why I vote +1 for keeping the existing names. > > Oh, and as to the issue of sort by alpha vs. sort by rank... really, how hard It is not hard and it would be great to have your help. However, we are less than two weeks away from launch and I don't think it is a good idea of introducing new 'features' to this site. It would be great if you provided the patch and then I think once things settle from Ganymede in July we can consider applying it.
(In reply to comment #110) > Oh, and as to the issue of sort by alpha vs. sort by rank... really, how hard > is it to provide a couple links? Default to the IMHO more obvious "sort by > alpha" so people can see similar packages grouped side by side (eg., > RCP/Plugins vs. RCP/Plugins+Communications or JSF/Web vs. JSF/Web + Reporting) > and let people see the popularity order as an optional link on the right-hand > nav. Point me at the code in CVS and I'll write you a patch. > > You're never going to get consensus on which way is "better" because clearly we > all think differently. So provide choice -- isn't that what OSS is all about? > :) > FYI - The Packaging Site is NOT in CVS as it runs on Drupal which is GPL licensed. It is also not part of any project at Eclipse.
(In reply to comment #113) > FYI - The Packaging Site is NOT in CVS as it runs on Drupal which is GPL > licensed. It is also not part of any project at Eclipse. http://www.eclipse.org/downloads/packages/ runs on Drupal now?
(In reply to comment #114) > (In reply to comment #113) > > FYI - The Packaging Site is NOT in CVS as it runs on Drupal which is GPL > > licensed. It is also not part of any project at Eclipse. > > http://www.eclipse.org/downloads/packages/ runs on Drupal now? > That specific url and anything below it is yes.
(In reply to comment #112) > However, we are less > than two weeks away from launch and I don't think it is a good idea of > introducing new 'features' to this site. [snip] > Yup, and IANAL either, so anything we do would need to be reviewed. In that case, perhaps we should remove the request for feedback notice and call this iteration final, so that Nick et al. can open a bugs and request improvements.
(In reply to comment #115) > That specific url and anything below it is yes. OK, thanks for clarifying. Can you please commit that code to some place like Google Code or SourceForge which allows GPL? IMHO it's not acceptable for us to create stuff and then don't publish the source. That's not the Eclipse Way.
(In reply to comment #117) > (In reply to comment #115) > > That specific url and anything below it is yes. > > OK, thanks for clarifying. Can you please commit that code to some place like > Google Code or SourceForge which allows GPL? IMHO it's not acceptable for us to > create stuff and then don't publish the source. That's not the Eclipse Way. > Wiki, Bugzilla, EclipseLive, EPIC, Portal, even PlanetEclipse (to some extent) aren't in CVS for all to consume. I don't see how this is any different. (I'm not saying that the Packaging Site shouldn't be in some sort of publicly available for people to consume but this is not a new precedent that I'm setting.
(In reply to comment #117) > IMHO it's not acceptable for us to > create stuff and then don't publish the source. That's not the Eclipse Way. Gunnar, We are very careful to distinguish between the Eclipse open source projects and the Eclipse Foundation's internal systems. For example, we create financial things (budgets, contracts, employee paychecks, etc) but we do not publish those (most corporations do not). Some of the Foundation's system are open source projects (e.g., Babel, the commits explorer dashboard, and the new EclipseCon submission system) and some are not (CVS server, Bugzilla server, EPIC, etc).
I can not install any plug-in manually (copy the plug-in into plugins directory, and then add -clean parameter) on Ganymede RC2, RC3. I don't know why, because these plugins can be installed on Ganymede M6. I think this is a P1 bug.
Pan, Try running with -clean -debug to provide details. With P2, there's a dropins folder; try copying them there.
(In reply to comment #119) > [...] Some of the Foundation's system are open > source projects (e.g., Babel, the commits explorer dashboard, and the new > EclipseCon submission system) and some are not (CVS server, Bugzilla server, > EPIC, etc). Bjorn and Nathan, I appreciate your feedback. I moved the discussion over to phoenix-dev mailing list as it was getting off-topic here. http://dev.eclipse.org/mhonarc/lists/phoenix-dev/msg00998.html -Gunnar
Marking this bug as FIXED / CLOSED. Initial Development of this subsite is now complete. Please create a new bug for issues on the Packaging Site.
Marking as Closed
Ed， FYI, I put the plugins into dropins directory, then restart Eclipse, the plugin have been installed successfully. Thanks!
