Comment 1 Remy Suen 2009-06-25 09:44:26 EDT

For whatever reasons, I can't vote (it's not in the "Related actions" box), I will give my verbal +1.

Comment 2 wayne townsend-merino 2009-06-25 11:40:35 EDT

Hmmm.  I'm logged in but don't see a vote option - but please add cocoa 64 bit.

Comment 3 Ian Skerrett 2009-06-25 14:11:46 EDT

Markus, is it possible to create the 64 bit Cocoa packages?  

Kevin and other Mac users, we need testers?  Very few people around the EPP project are Mac users, so if you guys want good Mac support we need more involvement from the Mac community.

Comment 4 Kevin Barnes 2009-06-25 14:17:33 EDT

"If you build it, they will come."

In the RC candidates we consistently found that 64-bit Cocoa downloads out numbered 32-bit. I'll test what I can.

Sorry about the terrible quote.

Comment 5 Charles Rivet 2009-06-25 14:52:09 EDT

I'll volunteer to do a bit of testing...

Comment 6 Markus Franz 2009-06-26 02:48:26 EDT

I's also like to add my "verbal +1".

Comment 7 John Hawksley 2009-06-26 03:21:32 EDT

+1 from me too; I can check out the J2EE EPP package at least.

Comment 8 Markus Knauer 2009-06-26 05:53:46 EDT

(In reply to comment #1)
> For whatever reasons, I can't vote (it's not in the "Related actions" box), I
> will give my verbal +1.

Voting was disabled (the default) - I changed this now.

Comment 9 Remy Suen 2009-06-26 05:57:22 EDT

(In reply to comment #8)
> Voting was disabled (the default) - I changed this now.

Thanks Markus. Oddly enough, I can specify the number of votes (instead of it being a checkbox). What's the deal with that?

Comment 10 John Hawksley 2009-06-26 06:01:45 EDT

According to the Vote page, we have a certain number of votes per product.  Since this is the only bug I want fixed in EPP, I put my full 5 in there ;-)  I would guess different grades of user might get a lesser or greater quantity of votes.

Comment 11 Markus Knauer 2009-06-26 06:19:45 EDT

(In reply to comment #4)
> In the RC candidates we consistently found that 64-bit Cocoa downloads out
> numbered 32-bit. I'll test what I can.

EPP never built any 64-bit Cocoa packages. 
Are you talking about Eclipse Platform or SDK?

Comment 12 Kevin Barnes 2009-06-26 07:07:57 EDT

I was referring to SDK downloads.

Comment 13 Markus Knauer 2009-06-26 07:17:38 EDT

(In reply to comment #10)
> According to the Vote page, we have a certain number of votes per product. 
> Since this is the only bug I want fixed in EPP, I put my full 5 in there ;-)  I
> would guess different grades of user might get a lesser or greater quantity of
> votes.

No, we are all equal - at least in this context here.

Comment 14 Ian Skerrett 2009-06-26 08:15:31 EDT

I'd be interested in hearing comments about this blog post that recommends using 32 bit Cocoa.  http://blog.zvikico.com/2009/06/eclipse-galileo-for-mac-cocoa-or-carbon.html

Comment 15 Markus Knauer 2009-06-26 08:17:17 EDT

(In reply to comment #3)
> Markus, is it possible to create the 64 bit Cocoa packages?  

It took a while to test if it is possible and I didn't want to promise anything before checking it. Yes, it is possible.

> Kevin and other Mac users, we need testers?  Very few people around the EPP
> project are Mac users, so if you guys want good Mac support we need more
> involvement from the Mac community.

We need more than just testers:

- Every package maintainer *must* agree to a new build. And I want to note here that it *is* possible to run the available 32-bit Cocoa packages with a Java 1.5 JVM.

- If we are going to provide 64-bit Cocoa versions, we need to drop one of the other Mac builds, IMHO. Why? Build time, disk space, user experience... so I expect Mac users to tell me which version can be removed. And as far as I know you can run a 32-bit Cocoa package on 64-bit, but not a 64-bit package on 32-bit.

- If we are going to provide 64-bit Cocoa versions, *when* do we start? Immediately? With Galileo SR1? With Helios? So far I am not yet convinced to do it *now*. The earliest possibility seems to me SR1.

- If... where do we stop? The next request will be this and that Windows 64-bit version, maybe other flavors of windowing systems, etc. - my standard answer here is: Use the EPP p2 repository and the p2 director in order to build your own package.

- The packages need testing, testing, ... :)

Comment 16 Kevin Barnes 2009-06-26 08:31:23 EDT

32-bit cocoa is fine until you want to use Java6. Since this limitation was the main reason that we started the cocoa port, I think it makes sense to package the 64-bit version the same way we package the 32-bit version.

I filed this bug because users were contacting me to find out where the 64-bit packages are. IMO, if you're going to make packages available, you should do so for all of the supported platforms.

Comment 17 Markus Franz 2009-06-26 08:42:09 EDT

(In reply to comment #15)
> - Every package maintainer *must* agree to a new build. And I want to note here
> that it *is* possible to run the available 32-bit Cocoa packages with a Java
> 1.5 JVM.

I do not think that that was doubted by anyone voting for this bug. 

> - If we are going to provide 64-bit Cocoa versions, we need to drop one of the
> other Mac builds, IMHO. Why? Build time, disk space, user experience... so I
> expect Mac users to tell me which version can be removed. And as far as I know
> you can run a 32-bit Cocoa package on 64-bit, but not a 64-bit package on
> 32-bit.

I agree that it is a tough decision to drop one of the three packages, but if a package is to be dropped, it should be the Carbon package, imho. Iirc the Carbon API was declared deprecated by Apple with the release of Mac OS X 10.4 and the encouraged API is Cocoa. Thus, as you stated, the 32-bit developers may well use the 32-bit Cocoa port instead of Carbon.

And indeed there is a pressing matter to make the 64-bit Cocoa Version an EPP provided version: Java 6. There simply is NO official 32-Bit JDK for the version 6. Thus, if a developer (such as me) has to use Java 6 because of cross-platform development involving co-workers not readily willing to backport their Windows Java 6 development, one either has to develop on a 32-Bit Java 5 Eclipse Platform (and thus not being able to properly eat one's dogfood) using (as i do) the Delta Pack in their target platorm (RCP development) or to use a (painfully) self-made development platform using p2.

> 
> - If we are going to provide 64-bit Cocoa versions, *when* do we start?
> Immediately? With Galileo SR1? With Helios? So far I am not yet convinced to do
> it *now*. The earliest possibility seems to me SR1.
> 

I agree that there might be a problem regarding resources to do this, yet in my opinion, it should be done asap because of the JDK problem.


> - If... where do we stop? The next request will be this and that Windows 64-bit
> version, maybe other flavors of windowing systems, etc. - 

I do not agree that this is really a valid argument, because as far as i know there is only a problem on Mac OS X to use Java 6. 

Comment 18 Kevin Barnes 2009-06-26 08:53:29 EDT

Carbon is still a supported platform and some eclipse products have not ported to cocoa yet. See bug 277580 and bug 277287.

Comment 19 Ian Skerrett 2009-06-26 09:02:15 EDT

(In reply to comment #16)
> I filed this bug because users were contacting me to find out where the 64-bit
> packages are. IMO, if you're going to make packages available, you should do so
> for all of the supported platforms.

Unfortunately the EPP project has limited resources so the strategy is to only build for the most popular platforms.  As you can appreciate, anything that is built also needs to be tested.


(In reply to comment #17)
> I agree that it is a tough decision to drop one of the three packages, but if a
> package is to be dropped, it should be the Carbon package, imho. Iirc the
> Carbon API was declared deprecated by Apple with the release of Mac OS X 10.4
> and the encouraged API is Cocoa. Thus, as you stated, the 32-bit developers may
> well use the 32-bit Cocoa port instead of Carbon.

Unfortunately dropping Carbon support would then provide no transition for Carbon users from Ganymede to Galileo.   Something already pointed out to us.  This is a scenerio that I just don't think is acceptable.  We can't just drop support for something we have provided in the past.

Comment 20 ekkehard gentz 2009-06-26 09:29:57 EDT

+1 for EPP cocoa

I'm telling all people to try out and use cocoa32 or cocoa64 -
and the EPP packages are great for users not exactly knowing which plug-ins they need
or to test out some projects

ekke

Comment 21 Ian Skerrett 2009-06-26 09:30:26 EDT

(In reply to comment #15)
> - If we are going to provide 64-bit Cocoa versions, we need to drop one of the
> other Mac builds, IMHO. Why? Build time, disk space, user experience... so I
> expect Mac users to tell me which version can be removed. And as far as I know
> you can run a 32-bit Cocoa package on 64-bit, but not a 64-bit package on
> 32-bit.

I don't see disk space being an issue.  Denis assures me we have lots.  Can you elaborate more on build time?   For user experience, we will need a way to show them on the download page and Nathan can look at this.  
> 
> - If we are going to provide 64-bit Cocoa versions, *when* do we start?
> Immediately? With Galileo SR1? With Helios? So far I am not yet convinced to do
> it *now*. The earliest possibility seems to me SR1.

I have seen a lot of people say this is an issue, so I would not like to wait until SR1.  Meaning if we can get help, we do it immediately.

> 
> - If... where do we stop? The next request will be this and that Windows 64-bit
> version, maybe other flavors of windowing systems, etc. - my standard answer
> here is: Use the EPP p2 repository and the p2 director in order to build your
> own package.

As with everything it is a fine balance.  I just know lots of people are complaining about 64 bit Cocoa support so we should attempt to find a solution.  It certainly appears this is the future platform going forward for Mac people.


> - The packages need testing, testing, ... :)

+1.  I will say it again, the people that want Mac support need to start participating in EPP.  We went through the entire release cycle and this issue was not raised as urgent.  In fact the lack of Carbon support was the only issue raised.  I think this points to we just don't have Mac people involved in EPP, so if this is going to solved we need to get them on board.  I just don't know any other way to solve it.

Comment 22 Eric Rizzo 2009-06-26 09:57:51 EDT

(In reply to comment #21)
> (In reply to comment #15)

> > - The packages need testing, testing, ... :)
> 
> +1.  I will say it again, the people that want Mac support need to start
> participating in EPP.  We went through the entire release cycle and this issue
> was not raised as urgent.  In fact the lack of Carbon support was the only
> issue raised.  I think this points to we just don't have Mac people involved in
> EPP, so if this is going to solved we need to get them on board.  I just don't
> know any other way to solve it.
> 

Ian,
Actually, I did raise the question on epp-dev when I noticed it at RC3. Markus offered a seemingly reasonable explanation, and I was too busy at the time to fully understand the Java 6 implication.
I am a full-time OS X 64-bit user now, so I will be happy to help test. For others who are volunteering to test, please join the epp-dev mailing list to get involved: https://dev.eclipse.org/mailman/listinfo/epp-dev

Comment 23 Markus Knauer 2009-06-26 10:00:10 EDT

(In reply to comment #17)
> And indeed there is a pressing matter to make the 64-bit Cocoa Version an EPP
> provided version: Java 6. There simply is NO official 32-Bit JDK for the
> version 6. Thus, if a developer (such as me) has to use Java 6 because of
> cross-platform development involving co-workers not readily willing to backport
> their Windows Java 6 development, one either has to develop on a 32-Bit Java 5
> Eclipse Platform (and thus not being able to properly eat one's dogfood) using
> (as i do) the Delta Pack in their target platform (RCP development) or to use a
> (painfully) self-made development platform using p2.

I would like to understand this better, because I always thought that it doesn't matter what you are running as development environment as long as you are free to define your own development target. E.g. it is possible to run a 32-bit Eclipse and use a 64-bit target and JVM.

Either I am not completely understanding your scenario, or I am right and the pressure is not that high as many people think.

And if someone is really interested in building his/her own platform specific package, you only have to run the p2 director against the EPP repository. It's easy and not painful at all if you are using consistent repositories. Just use this description (http://wiki.eclipse.org/EPP/Galileo_Packages#Using_the_eclipse.org_repositories) or a command such as:

eclipse -nosplash -consoleLog \
  -application org.eclipse.equinox.p2.director \
  -m http://download.eclipse.org/releases/galileo/,http://download.eclipse.org/technology/epp/packages/galileo/ \
  -a http://download.eclipse.org/releases/galileo/,http://download.eclipse.org/technology/epp/packages/galileo/ \
  -installIU epp.package.rcp \
  -destination /tmp/epp/eclipse \
  -profile epp.package.rcp \
  -flavor tooling \
  -profileProperties org.eclipse.update.install.features=true \
  -bundlepool /tmp/epp/eclipse \
  -p2.os macosx -p2.ws cocoa -p2.arch x86_64 \
  -roaming -vmargs -Declipse.p2.mirrors=false -Declipse.p2.data.area=/tmp/epp/eclipse/p2

Comment 24 Markus Franz 2009-06-26 10:14:59 EDT

(In reply to comment #23)> 
> I would like to understand this better, because I always thought that it
> doesn't matter what you are running as development environment as long as you
> are free to define your own development target. E.g. it is possible to run a
> 32-bit Eclipse and use a 64-bit target and JVM.

Yes this is the case. Yet SWT and RCP developers wanting to use Java 6 must have the 64-Bit Cocoa port of all relevant Eclipse plugins at hand (either in their installed Eclipse and thus the standard target platform or as i did add the delta pack containing the fragments to a manually set up target platform). 

> 
> Either I am not completely understanding your scenario, or I am right and the
> pressure is not that high as many people think.
> 

For developers not too familiar with the whole RCP platform / target platform stuff this is a major problem as the resulting error message (something like "Cannot load 32-bit SWT libraries on 64-bit JVM") will most likely seem strange to anyone not involved with the whole Java6/Cocoa/Carbon/64-32-bit business on Mac, most possible driving many possible SWT developers away as they can not readily use Java 6 and SWT without doing a ot of reading and digging.

> And if someone is really interested in building his/her own platform specific
> package, you only have to run the p2 director against the EPP repository. It's
> easy and not painful at all if you are using consistent repositories. Just use
> this description
> (http://wiki.eclipse.org/EPP/Galileo_Packages#Using_the_eclipse.org_repositories)
> or a command such as:
> 
> eclipse -nosplash -consoleLog \
>   -application org.eclipse.equinox.p2.director \
>   -m
> http://download.eclipse.org/releases/galileo/,http://download.eclipse.org/technology/epp/packages/galileo/
> \
>   -a
> http://download.eclipse.org/releases/galileo/,http://download.eclipse.org/technology/epp/packages/galileo/
> \
>   -installIU epp.package.rcp \
>   -destination /tmp/epp/eclipse \
>   -profile epp.package.rcp \
>   -flavor tooling \
>   -profileProperties org.eclipse.update.install.features=true \
>   -bundlepool /tmp/epp/eclipse \
>   -p2.os macosx -p2.ws cocoa -p2.arch x86_64 \
>   -roaming -vmargs -Declipse.p2.mirrors=false
> -Declipse.p2.data.area=/tmp/epp/eclipse/p2
> 

For the meantime, i propose to at least give some kind of explanation on this issue (Java 6 and SWT on Mac) on the main download page for all packages or only to users downloading the 32-bit Cocoa port.

Comment 25 Zviki Cohen 2009-06-26 10:21:24 EDT

A couple of things: 
* People are confused about whether to go for Carbon or Mac. Don't forget that there's a broad population using Eclipse, not all are tech savvy. The proof - I wrote an article in my blog regarding this and people are pouring in by searching "Eclipse Mac Cocoa or Carbon".
* A third option will make this decision more difficult.
* No real justification for using 64-bit, unless you need to run specific plugins written for Java 6. I'm not familiar with any. 
* You cannot drop Carbon for now, I agree. There are still many "legacy" plugins out there.

I say - for the minority who do need to run Java 6 plugins - it's not worth troubling the general population at the moment. This should be reconsidered for Helios.

BTW, here's a crazy thought - how about a mixed distribution which includes both SWT version and two APP packages one with 32 bit definitions and the other with 64 bit. Will it work?  I don't see why not.

Comment 26 Eric Rizzo 2009-06-26 10:30:06 EDT

 One of the justifactions for using the Java 6 JVM to run Eclipse is because, as of 3.4, I was told that JDT's compiler can take advantage of multi-threading capabilities introduced in Java 6 and actually do some builds in parallel. Needless to say, that can have a big impact on building large workspaces. But because Java 6 on OS X requires 64-bit, MAc EPP users can't take advantage of that.
Another possible justification is that when you install Java 6, I think it becomes the default for the system and a lot of users aren't going to know how to change that (or even that they can). Can anyone confirm this?

I'm sure the talented Nathan can come up with a good UI for presenting the multiple Mac options; I don't think that should be an issue in this discussion. Nor do I see how build time is an issue. I do, however, agree that the testing need is important, but balanced by the note from Kevin about how the 64-bit builds were consistently out-downloaded for the SDK RCs.

Comment 27 Kevin Barnes 2009-06-26 10:57:31 EDT

I should correct myself, 64 and 32 bit downloads were comparable, but not consistent. These are the download stats for the cocoa RC builds of the SDK according to the committer tools.

RC4 32bit - 726
    64bit - 690	

RC3 32bit - 501
    64bit - 550

RC2 32bit - 357
    64bit - 272

RC1 32bit - 621
    64bit - 464

Comment 28 Zviki Cohen 2009-06-26 11:09:36 EDT

(In reply to comment #26)
> Another possible justification is that when you install Java 6, I think it
> becomes the default for the system and a lot of users aren't going to know how
> to change that (or even that they can). Can anyone confirm this?

No, it does not. Leopard users get Java 1.6 automatically, but you have to switch manually using the "Java Preferences" application.

> I'm sure the talented Nathan can come up with a good UI for presenting the
> multiple Mac options;

It's not about presenting the options. More options == more confusion, no matter how well you put it. 

> how the 64-bit builds were consistently out-downloaded for the SDK RCs.

That's hardly an indication for anything. The population downloading the RCs is very tech savvy. People, myself included, wanted to check it out and see how it works. It means nothing. BTW, if you include it in the EPP packages there's still a chance this will become the most popular download because 64 bit sounds "more". 

Comment 29 Ian Skerrett 2009-06-26 11:29:45 EDT

As a suggestion, would it make sense to start by providing the Classic package on 64 bit Cocoa?  This would help for the immediate requests and we can look to resolved the bigger issue for SR1?

Comment 30 Remy Suen 2009-06-26 11:32:57 EDT

(In reply to comment #29)
> As a suggestion, would it make sense to start by providing the Classic package
> on 64 bit Cocoa?

To make sure we're all on the same page, you mean by modifying the main downloads page to expose the package without additional mouse clicks, correct?

Comment 31 Ian Skerrett 2009-06-26 12:07:30 EDT

(In reply to comment #30)
> (In reply to comment #29)
> > As a suggestion, would it make sense to start by providing the Classic package
> > on 64 bit Cocoa?
> 
> To make sure we're all on the same page, you mean by modifying the main
> downloads page to expose the package without additional mouse clicks, correct?
> 

Markus or Nathan can confirm but I believe EPP actually needs to build a 'package' for Classic.

btw, I am leaving for 1 week vacation, so any delay in responding is due to the fact I am enjoying some time off.  I do hope we can find some type of solution.  :-)

Comment 32 wayne townsend-merino 2009-06-26 12:09:17 EDT

I tried to build my own but it only starts up the eclipse GUI:

./eclipse -nosplash -consoleLog \
 -application org.eclipse.equinox.p2.director \
 -m http://download.eclipse.org/releases/galileo/,http://download.eclipse.org/technology/epp/packages/galileo/ \
 -a http://download.eclipse.org/releases/galileo/,http://download.eclipse.org/technology/epp/packages/galileo/ \
 -installIU epp.package.jee \
 -destination /tmp/epp/eclipse \
 -profile epp.package.jee \
 -flavor tooling \
 -profileProperties org.eclipse.update.install.features=true \
 -bundlepool /tmp/epp/eclipse \
 -p2.os macosx -p2.ws cocoa -p2.arch x86_64 \
 -roaming -vmargs -Declipse.p2.mirrors=false -Declipse.p2.data.area=/tmp/epp/eclipse/p2

Comment 33 David Williams 2009-06-27 01:25:55 EDT

I agree with the comment #15 that the earliest possible time to actually provide anything new is SR1. There are reasons why we plan; effort goes up and down and plans made for other things, and to start "reacting" outside that cycle is asking for trouble (increases risk), and is harder on developers who (as has been pointed out several times) are already overloaded (so, it increases stress; which increases risk).

Plus, it sounds like there's still some issues that might need some thought and discussion and decisions made.  

Plus, this is basically an enhancement request ... a request to make things easier for a certain group of users ... and as important as that is, it is not the same as some data-damaging bug which might deserve an off-cycle fix. 

Plus, there is a work-around; start with the cocoa 64 bit Eclipse SDK and then install what's desired from the Galileo discovery site. It would be great if  someone would "writeup" a blog entry or wiki page that detailed (screen shots and all) exactly what to select in the discovery site to "duplicate" some package functionality -- the required features are listed in the corresponding package feature and we can help with that if needed. Now, I'm not saying this is nice, nor easy, nor the same things that's being requested; but it is doable, so no one should be "blocked" from getting their work done. 

Thus, for SR1 (due 9/25) I suspect we'll begin work on it in earnest around first of August (though, I've not talked about any specific schedule with "the simultaneous team" so I'm just estimating). 

Comment 34 Remy Suen 2009-06-27 09:10:54 EDT

(In reply to comment #33)
> It would be great if 
> someone would "writeup" a blog entry or wiki page that detailed (screen shots
> and all) exactly what to select in the discovery site to "duplicate" some
> package functionality -- the required features are listed in the corresponding
> package feature and we can help with that if needed.

This would be very helpful and was mentioned in bug 277580 comment 0 in passing. It also comes up as a question on IRC once in a while.

Comment 35 Eric Rizzo 2009-06-27 09:32:59 EDT

I don't really agree with the "risk" argument, since this is something that has literally zero impact on anything else and there have been multiple offers to help test.
But in any case, I'll work on some blogs next week on how to "build your own package" using update manager. I doubt I have the stamina to do all of the packages, but at least I can give a try at Java, JEE, Modeling, and (hopefully) RCP/Plug-in Developer.

Comment 36 Eric Rizzo 2009-06-30 00:40:42 EDT

So I started to do a blog entry with step-by-step instructions and screenshots (and even planned a short video), but as soon as I got to the part about actually selecting the features to install, I realized this is NOT a viable option for most users. I was doing the JEE package first, since it is the most popular package, and what I discovered is a two-fold problem with this approach:
1) the list of features in the JEE package is much too long to allow this to be  a palatable task for anyone.
2) The user has to map from feature IDs (listed on the More... page for each package) to an actual selection in the Install New Software wizard GUI, which lists features by category and/or name. Because the GUI does not (seem to) provide a way to search or filter by feature ID, that mapping is practically impossible - you just don't know what to select based on the list of feature IDs that a package includes.
3) I haven't even gotten to the point where I can test if p2 has actually improved things enough that there aren't likely to be indecipherable error messages spewed at me as it tries to install, as it did in 3.4.

Unless someone has some suggestions for making this process a LOT easier (easy enough to explain in a reasonable blog entry and for the average, NON-ECLIPSE-DEVELOPER, user to understand and execute), then I'd say the alternative of documenting the process is a dead end. We really need a build for 64-bit/Java 6 users, guys.

Comment 37 Markus Franz 2009-06-30 04:58:48 EDT

(In reply to comment #36)

> Unless someone has some suggestions for making this process a LOT easier (easy
> enough to explain in a reasonable blog entry and for the average,
> NON-ECLIPSE-DEVELOPER, user to understand and execute), then I'd say the
> alternative of documenting the process is a dead end. We really need a build
> for 64-bit/Java 6 users, guys.
> 

May i suggest a (blogged) tutorial describing in detail how to use the 32-Bit Cocoa Version for Java 6/64-bit development via a 64-bit cocoa target platform. This is a quicker/easier approach, yet not very well documented (especially for non-RCP developers). I myself unfortunately lack the resources to do so...

Comment 38 ekkehard gentz 2009-06-30 05:05:25 EDT

I'm planning to blog about this in detail,
but it'll take some days .... I'm just blogging about target platforms, pde, galileo ....
and I want to have some special scenarios described like
... 32-bit / 64-bit IDE vs TP

but this wont help the 'normal' eclipse user to start with cocoa-64-EPP packages

I tried to use the sdk-cocoa-64bit and then use a 32-bit-cocoa-epp installation as source,
but it doesnt work

so we really need an easy way to get a cocoa-64-EPP

Comment 39 Markus Knauer 2009-06-30 07:36:29 EDT

(In reply to comment #36)
> ...but as soon as I got to the part about
> actually selecting the features to install, I realized this is NOT a viable
> option for most users.

I think it is easier than you think. If it is only about installing a set of features you can get the list from the EPP packages p2 repository.

Add

 http://download.eclipse.org/technology/epp/packages/galileo/

as a new p2 repository and select the top-level feature that you would like to install. What you don't get by installing a package this way is the branding of the package, e.g. JVM parameters.

Comment 40 ekkehard gentz 2009-06-30 08:13:04 EDT

Markus, this works great :-)

http://ekkescorner.wordpress.com/2009/06/30/galileo-epp-for-cocoa-64-bit/

ekke

Comment 41 Eric Rizzo 2009-06-30 10:15:15 EDT

(In reply to comment #39)
> I think it is easier than you think. If it is only about installing a set of
> features you can get the list from the EPP packages p2 repository.
> 
> Add
> 
>  http://download.eclipse.org/technology/epp/packages/galileo/
> 
> as a new p2 repository and select the top-level feature that you would like to
> install. What you don't get by installing a package this way is the branding of
> the package, e.g. JVM parameters.
> 

Holy cow, that DOES make a big difference. Tell the truth, Markus: you just now created that site, didn't you? :-)
OK, now I see it buried in the package command example above.
Anyway, I see that ekke beat me to the punch on a blog explanation. I think I'll augment his with a screencast video, just to make sure there is no excuse for a newbie to say "Eclipse doesn't support 64-bit OS X!"

Thanks, Markus, for the pointer.

Comment 42 ekkehard gentz 2009-06-30 10:29:54 EDT

Eric,
I already tried it yesterday using my EPP-cocoa-32-bit installation and failed.
after getting the info from Markus about the Update Site it was not much work :-)

a screencast is always great - I'll link yours to my blog if published.

ekke

Comment 43 wayne townsend-merino 2009-06-30 19:34:20 EDT

Works great - I am happy

(In reply to comment #42)
> Eric,
> I already tried it yesterday using my EPP-cocoa-32-bit installation and failed.
> after getting the info from Markus about the Update Site it was not much work
> :-)
> 
> a screencast is always great - I'll link yours to my blog if published.
> 
> ekke
> 

Comment 44 Eric Rizzo 2009-07-01 18:31:13 EDT

I posted a screencast video of the process: http://bewarethepenguin.blogspot.com/2009/07/screencast-creating-eclipse-download.html

Comment 45 Robert Oschwald 2009-07-19 06:21:26 EDT

It would help users like me if you state "cocoa 32bit" on the download page for the currently available version and provide a link to an info page, like Eric's excellent screencast.

Comment 46 Eric Rizzo 2009-07-20 12:30:45 EDT

(In reply to comment #45)
> It would help users like me if you state "cocoa 32bit" on the download page for
> the currently available version

I like this idea a lot. Do we need to CC webmaster to make that happen? Perhaps it would be best to open another bug against the website with that small request.

Comment 47 Ethan Tira-Thompson 2009-07-20 22:21:31 EDT

Just my 2¢, this release was really shortsighted not to include the 64 bit version for OS X.  My coworkers are developing an app in Java 1.6 building on Eclipse in Windows, and I was looking forward to running on the Mac with the 3.5 release... only to discover no 64 bit / Java 1.6 builds are available! :-P  I would think the SWT guys must be pissed since a main motivation of the cocoa SWT port was to provide 64 bit support, and then this was completely ignored at the release.

My first impression is to suggest you drop the 32 bit cocoa, and provide 64 bit cocoa instead.  32 bit carbon provides backwards compatibility; 64 bit cocoa is the future.  32 bit cocoa is an evolutionary dead end, I don't see the point of going that route.  This is assuming you can't provide a cocoa "fat binary" version, which is obviously the best option to cover the bases with minimal confusion.

Comment 48 Ian Skerrett 2009-07-21 12:52:41 EDT

(In reply to comment #46)
> (In reply to comment #45)
> > It would help users like me if you state "cocoa 32bit" on the download page for
> > the currently available version
> 
> I like this idea a lot. Do we need to CC webmaster to make that happen? Perhaps
> it would be best to open another bug against the website with that small
> request.
> 

Yup I agree good idea.  Nathan is going to work on adding this to the download page.   

Comment 49 Ian Skerrett 2009-07-21 13:07:46 EDT

(In reply to comment #31)
> (In reply to comment #30)
> > (In reply to comment #29)
> > > As a suggestion, would it make sense to start by providing the Classic package
> > > on 64 bit Cocoa?
> > 
> > To make sure we're all on the same page, you mean by modifying the main
> > downloads page to expose the package without additional mouse clicks, correct?
> > 
> 
> Markus or Nathan can confirm but I believe EPP actually needs to build a
> 'package' for Classic.
> 
> btw, I am leaving for 1 week vacation, so any delay in responding is due to the
> fact I am enjoying some time off.  I do hope we can find some type of solution.
>  :-)
> 

I am back from vacation. 

Nathan is going to start working on adding 64 bit Cocoa support as a option for the Classic Package.  This is essentially a link to the the Eclipse Project SDK so it has been well tested.

I know this is a partial solution but hopefully it will help address some of the issues.

Comment 50 Ian Skerrett 2009-07-21 14:40:36 EDT

Nathan was able to get this done a lot faster than I expected.  Check out the download page now and specifically the Eclipse Classic package.  Hopefully this starts to address the issues raised here in the bug.

Comment 51 ekkehard gentz 2009-07-21 14:51:30 EDT

looks good :-)

now everyone can see that most EPP packages are only cocoa 32bit and the sdk 32bit and 64bit.

now it would be great at the other packages also to add a cocoa 64bit link - pointing to a wiki page where the user gets informations how to do this using sdk 64bit (as described in eric's screencast or my blog)

ekke

Comment 52 Ian Skerrett 2009-07-21 14:52:36 EDT

Nathan was able to get this done a lot faster than I expected.  Check out the download page now and specifically the Eclipse Classic package.  Hopefully this starts to address the issues raised here in the bug.

Comment 53 Ethan Tira-Thompson 2009-07-21 15:03:08 EDT

Just for reference, I was able to get my 64 bit cocoa build done via following the screencast provided by Eric (http://bewarethepenguin.blogspot.com/2009/07/screencast-creating-eclipse-download.html)

I had to futz a bit with the built product to put the plugins inside the application bundle, but it's up and running now:
http://tekkotsu.no-ip.org/code/Tekkotsu_Storyboard_2.0.0-macosx.dmg

So that's a successful data point in terms of testing.  If this process was advertised a little so it was easier to find the instructions that would be helpful.

In particular, I've always be a little wary of what is different between the different eclipse download packages (what if I want to do both C++ development and also produce RCP packages for different projects... do I need two Eclipse installations?)  Now that I see how to access the EPP packages, this makes it clear what's going on and how to customize eclipse installations better.  So for relative newbies, the top of the Eclipse download page could give a link to a page with instructions.  (e.g. beside the "Looking for older versions or source code?", could add a "or how to make a custom configuration" with link to instructions)

Thanks

Comment 54 Eric Rizzo 2009-07-21 15:14:16 EDT

(In reply to comment #50)
> Nathan was able to get this done a lot faster than I expected.  Check out the
> download page now and specifically the Eclipse Classic package.  Hopefully this
> starts to address the issues raised here in the bug.
> 

Yes, I like it.
Crap, now I need to re-do my screencast because the new Classic links eliminate a couple of the steps that I demonstrated! Gee, thanks Nathan ;-)

Let's not lose sight of the need for 64-bit builds of all packages when it comes time for 3.5.1, however.

Comment 55 Kevin Barnes 2009-07-21 15:22:44 EDT

Makes me happy. 
Of course someone is probably going to want a 64 bit windows link on that page now. :-)

Comment 56 Ian Skerrett 2009-07-21 15:54:41 EDT

(In reply to comment #55)
> Makes me happy. 
> Of course someone is probably going to want a 64 bit windows link on that page
> now. :-)
> 

And here I thought from the comments in this bug everyone had moved to the Mac.  What is this Windows thingy?  :-)

Comment 57 Eddie Galvez 2009-07-29 12:55:30 EDT

+1

Our commercial product requires Java 1.6, and our Mac support is only via update-site plug-ins (we don't build a complete install). Thus we would like to be able to say "download the cocoa 64bit rcp package" and not "follow the blogs that tell you how to get this" (a link posted in these comments was perfect).

Hope we see this in 3.5 SR1.

Comment 58 Eric Rizzo 2009-08-10 12:20:27 EDT

(In reply to comment #33)
> Thus, for SR1 (due 9/25) I suspect we'll begin work on it in earnest around
> first of August (though, I've not talked about any specific schedule with "the
> simultaneous team" so I'm just estimating). 

So SR1 is about 6 weeks away; what needs to be done to make this happen? I haven't seen any traffic on epp-dev, should I ask over there instead?

Comment 59 Zviki Cohen 2009-08-26 09:02:42 EDT

I'm not sure if there were any developments, but let's add another interesting parameter to the mix. 

Snow Leopard will be out in a couple of days. From what I've seen, it comes with Java 6 only, 32-bit and 64-bit, where the 64 bit is the default. So, the good news is that Java 6 will support 32-bit after all. The bad news: 64-bit is the default. While not really bad news, this means many unsuspecting users will get frustrated without really understanding why.

Keep in mind not all Eclipse developers are experts. Some don't even know what's the different between Java 5 and 6. We are talking about a mixed audience which also includes PHP developers, BIRT users and more. I have a post on my blog explaining which version to pick (Cocoa or Carbon) and I'm getting about 100 hits per day from people searching for "eclipse galileo cocoao vs carbon" (or something similar). 

This becomes a very pressing reason to promote the 64 bit EPP package. There should be a very clear guide for selecting the right version right there on the download page, because it is becoming very confusing.

Comment 60 Simon Pope 2009-08-30 05:13:41 EDT

Re: Snow Leopard.

Yup. I got done. Took me a whole day to realize there was a Java Preferences to set the default JVM to 32-bit.

I agree with Zviki. A *lot* of developers will not realize why their apps are broken. We can go some way to helping them by providing the 64-bit Cocoa as a default, (or better still, bundle 32-bit and 64-bit packages together for a single install).

Comment 61 David Alves 2009-09-07 06:23:50 EDT

Stumbled upon this thread.

Just to notfy that I'm running Snow Leopard on 64 bit mode (which as you may know is not the default) and Eclipse is working fine.

Its running on 32 bit mode even if the default JDK is now 64 bit.

Comment 62 Eric Rizzo 2009-09-08 09:26:35 EDT

According to http://wiki.eclipse.org/Galileo#SR1 SR1 should already be at the RC2 stage, with RC3 this week, but there's been no comment on this issue from the EPP team for quite a while.
What is the status of this for SR1? What needs to get done?

Comment 63 Kevin Barnes 2009-09-18 11:08:34 EDT

64-bit builds available here: http://www.eclipse.org/epp/download.php
Please test them!

Comment 64 Markus Knauer 2009-09-25 10:52:56 EDT

Comment #64 (this one) will mark this 64-bit bug as "resolved" and "fixed". ;-)