Upgrade to Eclipse 3.5.0

Why can't we get it into Fiesty? The way I see it, Eclipse is a completely "external" package, not affecting the distro in any way. People want to get the latest version of Eclipse without having to upgrade to a new distribution. It is very important for developers. Eclipse releases are backwards compatible, so it isn't like you have to go get all new plugins.

Hi Dan, new package needs to be included in current Ubuntu development version first before it can be considered for a stable release.
Then then the package go though SRU or backport process.

I hope this helps.

https://wiki.ubuntu.com/MOTU/Packages/New
https://wiki.ubuntu.com/UbuntuDevelopment
https://wiki.ubuntu.com/BackportRequestProcess
https://wiki.ubuntu.com/MOTU/SRU

What mlind said. A backport would probably be entirely reasonable once it's in gutsy.

I'd just like to voice my support for Eclipse 3.3 as well. I've been trying to find a source package for Europa so that I can build proper packages on Feisty, but so far I haven't been able to. I don't like to install software manually that isn't in a deb package, but so far I have to for this.

I will also voice my support fro Eclipse 3.3. I am trying to add the PHP addin for Eclipse, but it does not support the 3.2 version that comes with Feisty. So I really hope that the Ubuntu community makes an upgrade available. Europa is now in stable distribution as far as I can understand on their website.

best regards

Definitely it would be great to have Eclipse 3.3 "apt'able" in Gutsy, yet nothing prevents you from running a generic package from eclipse.org.

Thanks for all commentaries. I am working on it right now.

William, thanks for the good job. I really think that Eclipse must have to be updated to 3.3.

We are now almost a month past the Upstream Version Freeze for Gutsy. Eclipse is a very complex package and so a UVF exception is very unlikely.

Will Eclipse be upgraded to 3.3 in time for Gutsy?

yet another same question:

will be eclipse upgrade to 3.3 in stable-gutsy or not? real problem is many plugins doesn't run with eclipse < 3.3

Yeah, I hope eclipse 3.3 is added to gutsy soon.

Please read comment 9 and https://wiki.ubuntu.com/FreezeExceptionProcess#head-1d28045481b8803d4815989e93edc4206f4848c4

Adobe's new flex for linux requires Eclipse 3.3 and sun jdk 1.5.
Please provide such packages for Ubuntu so its easy for us Linux Newbies.
thanks

I want 3.3 in gutsy as much as the rest of you.. but it really looks like it's pretty much impossible at this point, it's way too late. Sort of annoying considering that 3.3 came out long before the deadline for merging new versions.

But all is not lost, luckily eclipse happens to be extremely easy to install without an ubuntu package. If you download the precompiled version from eclipse.org, you only have to extract it into a directory and run it. I've been using it for a long time now this way.

What chance of it appearing in gutsy-backports after (or even at) release?

On 12/10/2007, Shane O'Connell <email address hidden> wrote:
> I want 3.3 in gutsy as much as the rest of you.. but it really looks
> like it's pretty much impossible at this point, it's way too late. Sort
> of annoying considering that 3.3 came out long before the deadline for
> merging new versions.
>
> But all is not lost, luckily eclipse happens to be extremely easy to
> install without an ubuntu package. If you download the precompiled
> version from eclipse.org, you only have to extract it into a directory
> and run it. I've been using it for a long time now this way.
>
> --
> Upgrade to Eclipse 3.3
> https://bugs.launchpad.net/bugs/123064
> You received this bug notification because you are a direct subscriber
> of the bug.
>

This is pretty trivial, but in my pursuit of desktop perfection, I'm a bit annoyed by the eclipse icon (icon.xpm file) that comes bundled in the precompiled version of Eclipse from Eclipse.org. Namely, it has a purple background around the Eclipse sphere instead of transparency. I recall getting an icon with a transparent background when I installed Eclipse 3.2 from the repository, and that's definitely the icon you get if you download the 3.3 Windows or Mac versions. What's extra strange is that I had Eclipse 3.3 running when I tried out the AWN dock recently, and the nicer icon magically appeared in the dock! Where did it come from, and why doesn't it look that way when I create a custom launcher for Eclipse with icon.xpm as the icon?

On Fri, 2007-10-12 at 05:59 +0000, Ashton Batty wrote:
> What chance of it appearing in gutsy-backports after (or even at)
> release?
>

I would say that it is odd that development-packages is
distribution-dependent. Any version of Eclipse should be updated /
installed on any distro-version you are using.
In other words: Distribution independent.

And it should be easy to install so you don't have to spend hours and
hours and ... to get your development-tool up and running.

Trond

Sorry about delay, since I'm too busy. Two weeks and all OK.

any idea when it will be available? thanks.

Ok, first let's get it packaged and built in Hardy, then I'd be more than happy to look at backporting it.

Someone nominated it to Gutsy.. John, are you able to decline that? I'm pretty close to finish it.

Oh, and yes, i'm packaging to Hardy :)

thanks! when will it be ready for gutsy and will it include php & svn plugins?

This bug was nominated for Gutsy but does currently not qualify for a 7.10 stable release update (SRU) and the nomination is therefore declined.
According the the SRU policy, the fix should already be deployed and tested in the current development version before an update to the stable releases will be considered. With 7.10 now released, that policy applies to this bug. See: https://wiki.ubuntu.com/StableReleaseUpdates .
The bug is not being closed as work will continue on fixing it for the next release, Hardy Heron (8.04). If the state of this bug should change such that it qualifies for the SRU process, please contact the person who originally declined it and ask them to re-evaluate it. To help improve the state of this bug see: https://wiki.ubuntu.com/Bugs/HowToTriage .

I am also looking forward to Eclipse 3.3 in Ubuntu.

So, is it confirmed that it will be in Hardy as default, with all the CDT, PHP plugins, etc?

No, it's currently not confirmed. If anyone is contributing to this task, they should join forces with Debian Java maintainers.

> What chance of it appearing in gutsy-backports after (or even at) release?

Probably slim. Eclipse churns out SWT and other development packages, libraries, etc that other software in the repositories depend on and it all depends on whether or not introducing these newer versions are going to be backwards-compatible.

Eclipse isn't just an IDE, it's also a platform and library.

I'm also looking forward to Eclipse 3.3 in Hardy so that Azureus 3.x can go in, and thank in advance the volunteers that will take this job forward :)

Yet a note showing my interest in getting Eclipse 3.3 in Gutsy and/or Hardy.

+1
simple downloading and unpacking don't work for me :(
There is exception:

JVM terminated. Exit code=13
/usr/bin/java
-Dosgi.requiredJavaVersion=1.5
-Xms40m
-Xmx512m
-jar /home/seth/Програмування/eclipse/plugins/org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar
-os linux
-ws gtk
-arch x86
-showsplash
-launcher /home/seth/Програмування/eclipse/eclipse
-name Eclipse
--launcher.library /home/seth/Програмування/eclipse/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_1.0.2.R331_v20071019/eclipse_1021.so
-startup /home/seth/Програмування/eclipse/plugins/org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar
-exitdata 1e10018
-vm /usr/bin/java
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xms40m
-Xmx512m
-jar /home/seth/Програмування/eclipse/plugins/org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar

"If anyone is contributing to this task, they should join forces with Debian Java maintainers."

So, since the Debian import freeze came and went a long time ago and feature freeze is just two weeks away... no 3.3 in Hardy then... most likely. :(

And downloading and running from the website doesn't work (I've forgotten what the error was for me in Hardy and I'm back in Gutsy now). Oh well.

(Just felt like complaining a little. ;)

So, since we're complaining... ;-)
Do the ubuntu devs want developers to use another distro, or why is only a 1+ year old version of eclipse available? 3.4 will go final shortly after hardy is released and yet not even 3.3 is in hardy. This is so absurd I find it difficult to believe.

I dont think it will be so bad if 3.3 is not included in Hardy because if u are a java developer, it would be able to intall Eclipse it own on Ubuntu there would be no prolbem, of course it would be nicer if we could say apt-get install eclipse but if not, no problem to i think..

The more we can apt-get the better. Then we know that the software is
being installed the correct way. We also know that it is being removed
from the system when we uninstall it as well.

-t-

On Thu, 2008-02-21 at 06:32 +0000, farkarich wrote:
> I dont think it will be so bad if 3.3 is not included in Hardy because
> if u are a java developer, it would be able to intall Eclipse it own on
> Ubuntu there would be no prolbem, of course it would be nicer if we
> could say apt-get install eclipse but if not, no problem to i think..
>

I think it is probably a bit late to get a release out and tested
enough before Hardy. I am a bit surprised nothing at all has been
released yet... there have been a handful of people who have claimed
to be working on it since before Gutsy.

On Thu, Feb 21, 2008 at 6:46 PM, Trond Husoe <email address hidden> wrote:
> The more we can apt-get the better. Then we know that the software is
> being installed the correct way. We also know that it is being removed
> from the system when we uninstall it as well.
>
> -t-
>
>
>
> On Thu, 2008-02-21 at 06:32 +0000, farkarich wrote:
> > I dont think it will be so bad if 3.3 is not included in Hardy because
> > if u are a java developer, it would be able to intall Eclipse it own on
> > Ubuntu there would be no prolbem, of course it would be nicer if we
> > could say apt-get install eclipse but if not, no problem to i think..
> >
>
> --
> Upgrade to Eclipse 3.3
> https://bugs.launchpad.net/bugs/123064
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Cmon, they don't give a $heet bout java developers which is inherited from the fact that Debian guys have exactly the same attitude. Extremely dumb in the first case (given the fact that Ubuntu is desktop-oriented) and just fine in the second (as Debian is more server-side).
Besides Eclipse, how long would it take for Tomcat 6 to get into repos? It went stable almost a year ago.

 HI!

Don't take tomcat as example, because @ tomcat you dont have troubles with the SWT Libs! It would be even easier to take the Jboss Application Server in the repos than it is with eclipse!

GSMD wrote:
> Cmon, they don't give a $heet bout java developers which is inherited from the fact that Debian guys have exactly the same attitude.
Hold on a sec, this is a bug report, not a forum for your rants about
Ubuntu developer priorities. The beauty of an open community effort is
that it inherits the priorities of everyone who participates. You are
welcome to step up and help to get the work done that you think is most
important, subject to the overall guidance of the technical board.

In the case of Java:

 - our primary constraint has been that upstream Java could not go into
main because of licensing concerns
 - we aim to get java into main as soon as it is possible to do so
 - we are currently post feature freeze, and so it will be difficult to
change Hardy

We are working with Sun on OpenJDK, but it's not yet clear what can be
achieved by Hardy without putting other pieces of the distribution, like
OpenOffice, at risk. One of our requirements in working with Sun is that
Eclipse work well. I fully support the idea of being able to apt-get the
latest stable Eclipse, and am pretty offended by your sweeping statement
to the contrary.

Mark

Eclipse 3.3.1 (From Eclipse site) works quite well using the beta version of icedtea and jdk7 (from the repositories)
I've used it to create some c++ code using cdt, seems to work with problems.
(the memory usage is also a lot better)
it needed some manual editing of the java virtual machine configuration.

Mark Shuttleworth wrote:
> Hold on a sec, this is a bug report, not a forum for your rants about Ubuntu developer priorities
Sorry for that and sorry for this post as well.
> our primary constraint has been that upstream Java could not go into main because of licensing concerns
Still, eclipse 3.2 and tomcat 5.5 are in the repos in spite of any java licensing concerns. Would updating the packages to current versions rise any licensing issues? Don't think so.
> we aim to get java into main as soon as it is possible to do so
Most people don't care whether it's in main or multiverse.
> we are currently post feature freeze
This issue has been reported long ago. Do you mean that Ubuntu team encountered the issue only now?

Don't get me wrong, I adore Ubuntu and respect all the effort you put into it. It's only that sometimes some things seem WAY too lame.

Everyone who cares about this bug should up-vote the "Make Eclipse a priority" idea on Ubuntu Brainstorm:

  http://brainstorm.ubuntu.com/idea/1265/

Hi,

could we get updated on the status please :)

thanks

HARDY, latest beta:

1) Having Eclipse 3.3 in the repos would be "nice", but I think unpacking it myself is "acceptable" (but not so nice...).

2) For me, this doesn't work. I (probably) have the same problem as Ілля Романенко above (https://bugs.launchpad.net/ubuntu/+source/eclipse/+bug/123064/comments/31)
JVM terminated. Exit code=13
...
In the log file, I saw something about swt-libs... (can't find the log at the moment, sorry... Maybe I deleted it in my uninstall-reinstall-reinstall-uninstall-delete-reinstall procedure...)

3) Eclipse 3.3 being "comptatible" with Hardy is an absolute must and a show-stopper for me and probably other people as well. If I cannot install Eclipse 3.3, I cannot use Hardy. I currently cannot use Gutsy because of another nasty bug (sound suddenly stopped working). This is really a pity, I really want to use Ubuntu, but every version has a different problem :-(. Well, it's not too late for Hardy, that's why I installed the beta... I *really* hope this problem can be fixed, it's a "real bug" (imho).

If you need first class Eclipse support/integration, use Fedora; They
have really put a lot of effort into Eclipse support.
I prefer Ubuntu over Fedora, and I am just going to stick with Eclipse
3.2 for another half year. I assume (hope) Ubuntu 8.10 will include
Eclipse 3.4

On Sat, Mar 29, 2008 at 11:46 PM, Finch <email address hidden> wrote:
> HARDY, latest beta:
>
> 1) Having Eclipse 3.3 in the repos would be "nice", but I think
> unpacking it myself is "acceptable" (but not so nice...).
>
> 2) For me, this doesn't work. I (probably) have the same problem as Ілля Романенко above (https://bugs.launchpad.net/ubuntu/+source/eclipse/+bug/123064/comments/31)
>
> JVM terminated. Exit code=13
> ...
> In the log file, I saw something about swt-libs... (can't find the log at the moment, sorry... Maybe I deleted it in my uninstall-reinstall-reinstall-uninstall-delete-reinstall procedure...)
>
> 3) Eclipse 3.3 being "comptatible" with Hardy is an absolute must and a
> show-stopper for me and probably other people as well. If I cannot
> install Eclipse 3.3, I cannot use Hardy. I currently cannot use Gutsy
> because of another nasty bug (sound suddenly stopped working). This is
> really a pity, I really want to use Ubuntu, but every version has a
> different problem :-(. Well, it's not too late for Hardy, that's why I
> installed the beta... I *really* hope this problem can be fixed, it's a
> "real bug" (imho).
>
>
>
> --
> Upgrade to Eclipse 3.3
> https://bugs.launchpad.net/bugs/123064
> You received this bug notification because you are a direct subscriber
> of the bug.
>

> I assume (hope) Ubuntu 8.10 will include Eclipse 3.4

Will it? Has a team formed for Eclipse? If so, that would be great. If not, I would like to know how you can be so sure. :)

well, eclipse 3.3.*+myeclipse 6.* work fine for me in Kubuntu 7.10 x64 since new year

as far I remember I was applying some howto from Ubuntu forums -- can't remember what...

@Ashton: "If you need ... Eclipse, use Fedora":

Well, thanks for the hint, but *you can't be serious*! As far as I'm concerned, Fedora is a completely different OS than Ubuntu and (for me at least) just as much of a difference as, let's say, MacOS would be... Having to switch the OS to make something work that worked fine in the previous version is just the reason BUG #1 will be open for much much longer...

@Andriy:

Yes, I know. It works fine in 7.10 x64 for me as well, but does *not* currently work in 8.04.

I *really* hope this will be fixed (and that's the reason I'm testing 8.04 and posting here), but it's really frustrating to see new things break in every new release.

I've tried 4 releases of Ubuntu now and at the beginning I was really impressed / enthusiastic and thought "wow, things are really moving forward rapidly and I can switch in a year or so". In every subsequent release, a lot of things got better but new things broke that had worked before. I'm now officially frustrated... how can I (ever) use a system like that if I can't be sure that things will even "keep working"? I'm sorry, we were told this is not a forum for rants... it's just that I'm frustrated at the moment... and unfortunately, I do not have enough Linux knowledge (yet) to solve this problem myself or help others solve it...

Well, maybe I can help a little by posting the log-file:
==================
!SESSION 2008-03-31 20:08:11.055 -----------------------------------------------
eclipse.buildId=M20080221-1800
java.version=1.6.0_05
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US
Command-line arguments: -os linux -ws gtk -arch x86

!ENTRY org.eclipse.osgi 4 0 2008-03-31 20:08:12.558
!MESSAGE Application error
!STACK 1
java.lang.UnsatisfiedLinkError: no swt-gtk-3349 or swt-gtk in swt.library.path, java.library.path or the jar file
 at org.eclipse.swt.internal.Library.loadLibrary(Library.java:219)
 at org.eclipse.swt.internal.Library.loadLibrary(Library.java:151)
 at org.eclipse.swt.internal.C.<clinit>(C.java:21)
 at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:63)
 at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:54)
 at org.eclipse.swt.widgets.Display.<clinit>(Display.java:128)
 at org.eclipse.ui.internal.Workbench.createDisplay(Workbench.java:482)
...
==================
I do have packages called "libswt3.2-gtk-java" and "libswt3.2-gtk-jni" installed, but Eclipse 3.3 doesn't seem to like them...

Hope somebody can solve this for Hardy final...

Weird, I'm using eclipse 3.3.2 in ubuntu 8.04 right now, it seems to work fine. All I had to do was install sun-java6-bin/sun-java6-jre/sun-java6-plugin, extract the eclipse .tar.gz into a directory in my home directory and run it.

Also, I don't actually have libswt3.2-gtk-java nor libswt3.2-gtk-jni installed. I think eclipse includes all the necessary files it needs to run.

I downloaded the C++ development version of eclipse from

http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/europa/winter/eclipse-cpp-europa-winter-linux-gtk.tar.gz

What did you download? I'd imagine the one for java development should work the same.

Problem (crash) still exists in latest Release Candidate *** 64 BIT ***

Yes, maybe that's the news here. I just tested Eclipse 3.3 (and even 3.4 M6) in a Virtual Machine (32 bit) and it worked fine. That had me hoping...
I then tested my "real machine" (64 bit) again and there is no change - Eclipse 3.3 still crashes with the same symptoms...

As I said above: This is a real showstopper for me and probably other people. Having to install it manually is acceptable, but atm, I really don't see a way to get it working and that means I cannot use Hardy and that means I cannot use Ubuntu.
:-(

Finch,
I'm running Eclipse Europa x86_64
(eclipse-java-europa-winter-linux-gtk-x86_64.tar.gz) on current Kubuntu
8.04 without a problem. My Java is:
$ java -version
java version "1.6.0"
OpenJDK Runtime Environment (build 1.6.0-b09)
OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode)

+1, eclipse 3.3 .deb version

it would be time for eclipse-3.4 and skip 3.3 ....

Yes, 3.4rc1 is a week away, and the final is not much more than a month away, so yes, there's not much point in going for 3.3 anymore. Should this bug be renamed to "Upgrade to Eclipse 3.4", or should a new one be created?

i am realy pissed off by this whole discussion about updating...

but i dont want to talk to much about this thing, i changed to fedora because the eclipse thing in ubuntu is realy poor poor work...

Hold on. The way it goes, this should be named Upgrade to 'Eclipse 3.5' along with 'Upgrade to Tomcat 7' somewhere nearby. Anyways, eclipse 3.3 and tomcat 6.0 is not in LTS which is sorta sad.

it works as is, downloaded from eclipse.org website
Kubuntu 8.04 x64

if it fails, try changing default jvm between openjdk6, sun-java-6, sun-java-5

I'm highly disgusted by how long this bug has been left unopened. It has already moved me to leave Ubuntu to seek fresher pastures, and I believe others will do so too. Now, users of Hardy will be left, what, the entire length of an LTS without an upgrade to Eclipse?

Shame.

Hi,

first off all, I'd like to say that I'm sorry that we haven't been able to provide an updated version of eclipse yet. The reason for this is quite trivial: Neither Debian (where we take most of the universe packages from) hasn't provided an updated version yet, and also we (i.e. the MOTU team consisting entirely of volunteers) don't have people which are very experienced with java packages.

Hence replies how bad you think Ubuntu is in regards java/eclipse packaging won't help us solve this bug. The only answers which do bring us further are in the form of: "Hey, I've got a source package ready, can you review it?". Are you up for it?

Cheers,
   Stefan.

(side note: I've declined the hardy task, as hardy is released already. Only way for hardy is via backports, but that means that we need a new version in intrepid first.)

If I knew how to generate a package for eclipse, I'd definitely do it. If I hadn't the exams coming up next week, I'd be learning how to do it right now :(
Could you post a few pointers as to how to generate ubuntu packages, and what eclipse should rely on/what relies on eclipse, etc?

Thanks!

On Thu, 2008-05-22 at 09:16 +0000, Jean Azzopardi wrote:
> If I knew how to generate a package for eclipse, I'd definitely do it. If I hadn't the exams coming up next week, I'd be learning how to do it right now :(
> Could you post a few pointers as to how to generate ubuntu packages, and what eclipse should rely on/what relies on eclipse, etc?

Since this bug has been filed for some time, I think that a week or more is not the matter. I wouldn't mind trying to help out either.

-trond-

Hi,

Ok, here some pointers:

Generating packages:
https://wiki.ubuntu.com/PackagingGuide (should also contain links to other useful documentation).

Java packages:
http://www.debian.org/doc/packaging-manuals/java-policy/
(not too sure how complete this is nowadays)

From the current eclipse source package, e.g. libswt3.2-gtk-java gets built. So you can find out what packages are affected by dependencies with:

apt-cache rdepends libswt3.2-gtk-java

(same works for other binary packages, which come from eclipse source package as well).

This test doesn't necessariliy cover build-dependencies yet. To find out, if there are packages build-depending (but not depending, not sure if this is the case for a package) on a binary package from eclipse, you'll need to look through the packages files in /var/lib/apt/lists. A tool to help doing this is grep-dctrl (package dctrl-tools), but I've forgotten the syntax right now.

Finally, you can always ask any packaging questions on the channel #ubuntu-motu on freenode, or on the motu mailing list <email address hidden>

Cheers, and thank you very much for offering help,
    Stefan.

3.4 is now out.

Lets get this going again shall we?

I require Eclipse for work and as been mentioned many times, most plugins need at least 3.3.

And 3.4 provides a lot of web development support, which I, and many others, have been screaming about for some time!

Is there something we as complainers can do to make this build under
Ubuntu 7.10->
Instead of continuing to complain, maybe we should take action. I
totally agree that 3.3-> should be an option in Gutsy/Hardy.

best
trond

I've used 3.3 in both Gutsy and Hardy. There is some conflicting
package(s) you need to remove first, though I don't remember which.

On Thu, Jun 26, 2008 at 10:09 PM, Trond Husoe <email address hidden> wrote:
> Is there something we as complainers can do to make this build under
> Ubuntu 7.10->
> Instead of continuing to complain, maybe we should take action. I
> totally agree that 3.3-> should be an option in Gutsy/Hardy.
>
> best
> trond
>
> --
> Upgrade to Eclipse 3.4
> https://bugs.launchpad.net/bugs/123064
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Eclipse 3.4 installed from source works well in Hardy.
http://jhcore.com/2008/06/26/eclipse-34-ganymede-on-ubuntu/

How can we then turn it into a package for Hardy?

-t-

On Thu, 2008-06-26 at 21:05 +0000, John Paulett wrote:
> Eclipse 3.4 installed from source works well in Hardy.
> http://jhcore.com/2008/06/26/eclipse-34-ganymede-on-ubuntu/
>

+1 for upgrading to Eclipse 3.4. I'd be happy to help with testing. I'd also be happy to attempt packaging and upload to a PPA if someone could offer guidance.

One question -- should we be looking to get this addressed at the Debian level rather than doing it locally and duplicating the effort?

it works from www.eclipse.org just fine.
IMHO eclipse should be removed from repository and instead put some script that would download it from www.eclipse.org (automatix4eclipse :)

No, no, no! The automatix crap is NOT the way to go with a deb-based distro! That would just open the door for serious problems when those root-privileged scripts malfunction (which they eventually will do, e.g. when they aren't updated fast enough when the packages at www.eclipse.org are updated).

I believe the problem is that currently there are several jvms, if
openjdk were the only one, wouldn't it make java packaging simpler?

On Fri, Jun 27, 2008 at 1:19 PM, Marcus Sundman <email address hidden> wrote:
> No, no, no! The automatix crap is NOT the way to go with a deb-based
> distro! That would just open the door for serious problems when those
> root-privileged scripts malfunction (which they eventually will do, e.g.
> when they aren't updated fast enough when the packages at
> www.eclipse.org are updated).
>
> --
> Upgrade to Eclipse 3.4
> https://bugs.launchpad.net/bugs/123064
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Yes, it probably would, though I don't think that is a major issue.
I think it is people taking it on, without realising how much work is
really required. Especially with the new P2 plugins system, simply
updating the old packages isn't enough.
My thoughts, if anyone wants to package Eclipse, start with just the
Eclipse Platform and JDT, release as early and frequently as possible,
and add plugin packages one at a time. Target only openjdk 6. And if
you change your mind, please let others know. There have been a
handful of people say they will start adopt Eclipse, and then are
never heard from again.

On Sat, Jun 28, 2008 at 1:26 PM, Don Smith <email address hidden> wrote:
> I believe the problem is that currently there are several jvms, if
> openjdk were the only one, wouldn't it make java packaging simpler?
>
> On Fri, Jun 27, 2008 at 1:19 PM, Marcus Sundman <email address hidden> wrote:
>> No, no, no! The automatix crap is NOT the way to go with a deb-based
>> distro! That would just open the door for serious problems when those
>> root-privileged scripts malfunction (which they eventually will do, e.g.
>> when they aren't updated fast enough when the packages at
>> www.eclipse.org are updated).
>>
>> --
>> Upgrade to Eclipse 3.4
>> https://bugs.launchpad.net/bugs/123064
>> You received this bug notification because you are a direct subscriber
>> of the bug.
>>
>
> --
> Upgrade to Eclipse 3.4
> https://bugs.launchpad.net/bugs/123064
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I would try to create an ubuntu compatable source package but I can´t even get ganymede to compile correctly with openjdk-6-jdk and ant 1.7.0-3. According to http://download.eclipse.org/eclipse/downloads/drops/R-3.4-200806172000/srcIncludedBuildInstructions.html, we only need ant (>= 1.6.1) ).

If anyone can get it to compile from source, then that would greatly increase the chances of it being packaged.

Debian is already packaging it and is needing some help :
http://lists.debian.org/debian-java/2008/06/msg00036.html

AFAIK, Eclipse doesn't support Java 6:

http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_4.html#TargetOperatingEnvironments
https://bugs.eclipse.org/bugs/show_bug.cgi?id=214110

From: http://download.eclipse.org/eclipse/downloads/drops/R-3.4-200806172000/srcIncludedBuildInstructions.html

Under "Initial Setup", it says, "Install Ant and a JDK as per each program's instructions. Minimally you will need the following environment variables set. ... 2. Set the JAVA_HOME environment variable to the root of your 1.6 JDK installation..."

On that page, "1.6 JDK" is in bold.

I wonder if it's a typo?

Michael wrote:
> I wonder if it's a typo?

And I wonder if you've read the page you posted? :-D
Just kidding.
No, not kidding... It says the *build* requires 1.4, 1.5 AND 1.6. I don't know why, but that's what it says.
Further down ("known limitations"), it says: "For the platforms were JDK 1.6 support is not yet available e.g ..... the Eclipse SDK can be built with JDK 1.5 in place JDK 1.6. To do that, please follow the following steps: ...replace this with that, remove ... following ... packages that require JDK 1.6... "

So I don't think it's a typo.

I've been working on a package for 3.4 since RC1. I just uploaded a source package to my [[https://launchpad.net/~rock-gimp/+archive ppa]]. It is based off of the never-released packaging for 3.3 in debian's pkg-java svn. There are a few major issues:

 * Help indexing causes memory corruption, which leads to a crash. This seems to be a gcj-4.2 issue; other jvms don't seem to have this problem. Unfortunately, the source package is set up to build with gcj, so some of the help file packages never get built. Furthermore, if you try to search help files installed using the update manager while running under gcj, eclipse crashes.

 * The Eclipse source build lost the ability to compile the SWT native libraries sometime between RC1 and the final release. This package uses the .so files that come in the upstream tarball.

 * There are several jars that were replaced with symlinks to jars in /usr/share/java. Since the 3.4 versions have had osgi properties added to their manifests, this isn't a safe transformation anymore, so those files aren't replaced with symlinks anymore.

 * P2 doesn't work. If you enable classic update, you can still use it to install new plugins from update sites.

Despite all that, I've found it to be reasonably stable and much more useful to me than the 3.2 packages in Hardy.

On Tue, 2008-07-01 at 06:14 +0000, Rockwalrus wrote:
> I've been working on a package for 3.4 since RC1. I just uploaded a
> source package to my [[https://launchpad.net/~rock-gimp/+archive ppa]].
> It is based off of the never-released packaging for 3.3 in debian's pkg-
> java svn. There are a few major issues:
>
> * Help indexing causes memory corruption, which leads to a crash. This
> seems to be a gcj-4.2 issue; other jvms don't seem to have this problem.
> Unfortunately, the source package is set up to build with gcj, so some
> of the help file packages never get built. Furthermore, if you try to
> search help files installed using the update manager while running under
> gcj, eclipse crashes.
>
> * The Eclipse source build lost the ability to compile the SWT native
> libraries sometime between RC1 and the final release. This package uses
> the .so files that come in the upstream tarball.
>
> * There are several jars that were replaced with symlinks to jars in
> /usr/share/java. Since the 3.4 versions have had osgi properties added
> to their manifests, this isn't a safe transformation anymore, so those
> files aren't replaced with symlinks anymore.
>
> * P2 doesn't work. If you enable classic update, you can still use it
> to install new plugins from update sites.
>
> Despite all that, I've found it to be reasonably stable and much more
> useful to me than the 3.2 packages in Hardy.
>
It seems to me that a good idea would be to help out Rockwalrus with
the building.

I've uploaded the most recent package to https://launchpad.net/~eclipse-team/+archive . The team membership is set to open so anyone who wants to can make a fix to the package and upload it there.

Will this work on feisty ?

I use hardy, so I can't say for sure. I've queued a build for Fiesty on my ppa (which has been moved to https://launchpad.net/~rockwalrus/+archive). It will probably take about three hours to know for sure.

I too can't wait for this. I have setup eclipse 3.2 using the apt-get manager, but the latest version is only 3.2. This is a major problem because Eclipse 3.2 doesnt work behind an authenticated proxy, you can configure a proxy in 3.2, but not configure authentication for it. So it pretty much means you cant use eclipse on Ubuntu because its 3.2. Any later version would be great.

My vote ++;

Please don't post "+1" comments to this bug anymore. The large number of subscribers is of course well aware of the issue; you're generating a big amount of mail for nothing -- just complaining won't help to get this fixed. Moreover, comments that could help to get this done are interleaved with the other posts.
Just quietly subscribe and wait.

If you indeed *can't* wait, please help Rockwalrus with packaging (see https://launchpad.net/~eclipse-team/+archive) or else make up your own package and put it in a PPA.

I continue working on the package when I have free time

I'm not familiar with PPAs etc, but it looks like the build is failing because the process hangs up. What can I be doing to assist here, if anything? I've installed several packages from the PPA and at first blush they appear to be functional, but I haven't yet used them in anger. What I have is:

ii eclipse 3.4.0-0ubuntu1~ppa6 Extensible Tool Platform and Java IDE
pn eclipse-base <none> (no description available)
ii eclipse-cdt 3.1.2-1 C/C++ Development Tools for Eclipse
ii eclipse-cvs 3.4.0-0ubuntu1~ppa6 cvs integration for Eclipse
un eclipse-cvs-gcj <none> (no description available)
un eclipse-ecj <none> (no description available)
un eclipse-ecj-gcj <none> (no description available)
ii eclipse-gcj 3.4.0-0ubuntu1~ppa6 Native Eclipse run with GCJ
ii eclipse-jdt 3.4.0-0ubuntu1~ppa6 Java Development Tools plug-ins for Eclipse
pn eclipse-jdt-common <none> (no description available)
ii eclipse-jdt-gcj 3.4.0-0ubuntu1~ppa6 Java Development Tools plug-ins for Eclipse (GCJ version)
pn eclipse-nls-sdk <none> (no description available)
ii eclipse-pde 3.4.0-0ubuntu1~ppa6 Plug-in Development Environment to develop Eclipse plug-ins
pn eclipse-pde-common <none> (no description available)
ii eclipse-pde-gcj 3.4.0-0ubuntu1~ppa6 Plug-in Development Environment to develop Eclipse plug-ins (GCJ version)
ii eclipse-platform 3.4.0-0ubuntu1~ppa6 Eclipse platform without plug-ins to develop any language
pn eclipse-platform-common <none> (no description available)
ii eclipse-platform-gcj 3.4.0-0ubuntu1~ppa6 Eclipse platform without plug-ins to develop any language (GCJ version)
ii eclipse-pydev 1.2.5-2 Python development plug-in for Eclipse
un eclipse-pydev-gcj <none> (no description available)
ii eclipse-rcp 3.4.0-0ubuntu1~ppa6 Eclipse rich client platform
pn eclipse-rcp-common <none> ...

It would be really useful to have an Ubuntu .deb package of Eclipse 3.4 backported to 8.04. At the moment I can't use the Flexbuilder 3 plugin or the Github plugin, because they both support 3.3 or later, and Aptana is sure to transition to 3.4 in the future.

I'm currently using the PPA from the eclipse-team, and I'm having some problems:

First off, the eclipse-subversive package is missing SVN Connectors. This makes the package useless. I have even tried installing the libsvn-java package. Here's the error:

Selected SVN connector library is not available or cannot be loaded.
If you selected native JavaHL connector, please check if binaries are available or install and select pure Java Subversion connector from the plug-in connectors update site.
If connectors already installed then you can change the selected one at: Window->Preferences->Team->SVN->SVN Client.

Second, on my x86_64 box I'm having major issues getting plugins installed from remote update sites. Here's a sample error I get:

 The current configuration contains errors and this operation can have unpredictable results.
 Resulting configuration does not contain the platform.
 Mylyn Bridge: Plug-in Development (3.0.1.v20080721-2100-e3x) requires feature "org.eclipse.pde (3.4.0)", or compatible.
 Mylyn Bridge: Eclipse IDE (3.0.1.v20080721-2100-e3x) requires feature "org.eclipse.cvs (1.1.0)", or compatible.
 Mylyn Task List (Required) (3.0.1.v20080721-2100-e3x) requires feature "org.eclipse.rcp (3.4.0)", or compatible.
 Mylyn Bridge: Java Development (3.0.1.v20080721-2100-e3x) requires feature "org.eclipse.jdt (3.4.0)", or compatible.

I have all of the required packages installed, but it continues to throw an error. On my x86 box, it seems to work without any problems.

Also, is someone looking into packaging CDT 5.0? Eclipse in the PPA is up to 3.4, but the current version of CDT in the repositories is ancient (3.1).

Sorry for may be drifting off the topic a bit here. I tried the PPA from https://launchpad.net/~eclipse-team/+archive. It installs nice but after launch I can not access the Help -> Software Updates . I only get the message "Cannot launch the update UI. This installation has not been configured properly for software updates." I searched a while but did get any solution in what to do to activate the Software Updates again. Was it perhaps deactivated in the build on purpose?

The new p2 update manager does not work in the PPA version. The classic update manager can be enabled in Preferences under General/Capacities.

I'm getting a related error with the classic update manager:

Error creating feature "file:/usr/lib/eclipse/features/org.eclipse.cvs_1.1.0.v20080603-7C79E8M9EI99m9c9S/". [/usr/lib/eclipse/features/org.eclipse.cvs_1.1.0.v20080603-7C79E8M9EI99m9c9S/feature.xml (No existe el fichero ó directorio)]
/usr/lib/eclipse/features/org.eclipse.cvs_1.1.0.v20080603-7C79E8M9EI99m9c9S/feature.xml (No existe el fichero ó directorio)

Using intrepid here, don't know if it's supposed to work (apt-getted fine so dependencies are satisfied...)

+1 for upgrading to Eclipse 3.4.

+1 for upgrading

Please do not keep posting +1 comments, it only creates extra bugmail and does not have any constructive purpose. If you wish to monitor the progress of this bug then the best action is to subscribe. This bug is already confirmed, it just needs someone to package the new version, either here or in debian so we can sync it. Please feel free to help out with this process. https://wiki.ubuntu.com/MOTU/Contributing

Jisakiel:

I was having the same issue. Ensure that eclipse-cvs is installed. Perhaps the control file should be modified so that eclipse depends on eclipse-cvs...

Hi Everybody,

i just installed ubuntu 8.10 in hope to get some newer repositories with eclipse 3.4

The whole thing is still on 3.2 and it prevents me from installing CDT 5.0.1

can anybody help and provide a package? for both? for the ones of us who are not masters on doing it all from source.
or can somebody please update the community repository.

im not sure what the issue is that this thing hasnt been updated for 2 years!

kind regards
Tibor

On Tue, Nov 4, 2008 at 11:47 AM, ghostwriter78 <email address hidden> wrote:
> can anybody help and provide a package? for both? for the ones of us who are not masters on doing it all from source.
> or can somebody please update the community repository.

There is no need to compile anything, just go to eclipse.org and
follow the appropriate download links (selecting Linux, naturally).
Extract the archive and run the eclipse binary in it.

He means, of course, for those who aren't masters of ubuntu package creation.

Yes, we can use the official release from eclipse.org - but then why use a package manager.
We all know the advantages of package managers in terms of security, integration with rest of system, file organisation, access for all users and whatnot.

In my opinion, the version of eclipse that is currently being released with Ubuntu is so old that including it in the repository is misleading and harmful to users.

It should be removed as unmaintained.

In practical terms, the packaging work for Eclipse 3.4 takes place at the Debian project and at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432350

Ask politely the previous Debian developer on this, or use your contacts with other Debian developers to get it done.

For now, Eclipse 3.4 requires manual installation, which is a medium skill task.

I agree that it should be removed, as it is basically useless since most of the new plugins dont support it anymore.

The manual installation might be a medium skill task, but it costs a lot of time to find the right steps to do it.

I just installed ubuntu 8.10 and forgot what had to be done for eclipse. it cost me time for searching on the internet, just to find out that the recent CDT plugin cant use the old eclipse version 3.2

Its simply a shame, and becomes a reason for people not to use ubuntu.

The report on the debian.org bugreports has been done. Perhaps there is someone out here who could still help with it.

@Simos Xenitellis: pointing fingers at another group is corporate and not as helpful as real action. Please, at the very least, admit that Eclipse is unmaintained (and nobody is willing to fix it), and remove it from the list of packages.

Thanks!

who should remove this?

On Wed, Nov 5, 2008 at 12:09 PM, Victor Costan <email address hidden> wrote:

> @Simos Xenitellis: pointing fingers at another group is corporate and
> not as helpful as real action. Please, at the very least, admit that
> Eclipse is unmaintained (and nobody is willing to fix it), and remove it
> from the list of packages.
>
> Thanks!
>
> --
> Upgrade to Eclipse 3.4.1
> https://bugs.launchpad.net/bugs/123064
> You received this bug notification because you are a direct subscriber
> of the bug.
>

@Victor Costan: 'eclipse' 3.2 is part of Debian's universe repository.
This means that there is not much that Ubuntu can do to remove from the list,
because that list is Debian's. You may contact Debian for this issue.

Being practical, my view is that what's missing is helping hands in packaging
the new version of Eclipse. The packaging would take place at Debian, or someone
could package and put on their personal archive (launchpad.net offers space for this).

Trying to encourage someone to spend time in packaging Eclipse 3.4+ is what we need to do.

>
> @Victor Costan: 'eclipse' 3.2 is part of Debian's universe repository.

s/universe/main
There is no universe repo in Debian, just main, non-free, and contrib.

I don't think it is good idea of packaging Eclipse as Ubuntu packages at all. Base Eclipse platform is relatively easy to install - just unpack it's archive to a directory. There is huge amount of plugins available but Eclipse provides it's own plugin management system with dependency resolving, posiibility of install from different repositories over Internet connection, from disk after downloading and so on. Packaging this as .deb packages would be complex, tedious and what is most important doubling of Eclipse and plugin developers work.

Instead of packaging Eclipse providing comprehensive documentation how to integrate Eclipse with Ubuntu should be enough. Maybe some configuration or launcher scripts for Eclipse could be worth of packaging as a .deb package.

Sure, don't package plugins - I agree that Eclipse's plugin manager can handle that itself. BUT - the convenience of a .deb package, which handles JDK and JRT dependencies, puts a launcher in the menu, picks a default directory, and so forth, is something I've gotten used to with Ubuntu. I think that this .deb should just install the base (perhaps the Java Development version, as that seems to be the most used) with select plugin repositories pre-selected and let the user install further plugins with Eclipse's internal plugin manager.

And what when a third-party plugin wants to upgrade the JDT? or a similar core plugin that an Eclipse package would need to provide in order to make Eclipse usable out of the box?

Eclipse's plugin manager can only "handle itself" correctly on a single-user system, unless you start making system directories world-writable...

Perhaps the answer is to modify /usr/bin/eclipse so that it copies a skeleton of all the packaged plugins into the user's home directory the first time it is run, and always use those instead. This way the problems of file permissions and plugins affecting other user's accounts are avoided.

@Rockwalrus:
Are you still actively working on the Eclipse package in the PPA? I'd be happy to try this theory out, if it is worthwhile?

Actually, when using the dropins directory to install plug-ins manually in a system-wide installation (let's say, you have Eclipse 3.4.1 installed in /usr/lib/eclipse with root permissions, and install jdt and pde in the dropins dir also with root permissions) then afaik those plug-ins installed there can co-exist peacefully with upgrade versions of plug-ins that are installed in .eclipse through the P2 Update Manager.

So, if you'd have eclipse-platform, jdt en pde installed from the repo, suposing jdt and pde are installed as dropins, then you can update those plugins through the Update Manager without any problem. The updated .jars are just placed in .eclipse. So no problems there.

In the interest of having this out quicker, I'd like to highlight that JDT is very easy to install using P2 (Eclipse's new package manager.) So I think the only component that needs to be included in the .deb is the platform, and the nice .xpm icon. As far as I know, the platform isn't update-able via P2 (i.e. can't update from Eclipse 3.2 to Eclipse 3.4 without reinstalling.)

Thanks to anyone and everyone who's working on this bug!

Let's avoid going in circles here:

"Rockwalrus wrote on 2008-09-17:

The new p2 update manager does not work in the PPA version. The classic update manager can be enabled in Preferences under General/Capacities."

My suggestion would allow the classic update manager to be used instead of the broken P2 one. It is a work-around as opposed to a long-term solution, but it is a work-around that could be done *now*.

The package should be made for at least one reason, there are dependencies (like java in ubuntu) which are not noted on the eclipse installations page, but required for it to run properly.

Also users who are not experts with ubuntu (like me), are glad to have a easy to use package manager.

I was asking already in Intrepid if it could be packaged as there were difficulties to get eclipse 3.4 running. So please backport it for us who are not able to update ubuntu to newer versions (Jaunty).

regards and big thanks
Tibor

On 24.11.2008 20:11, Victor Costan wrote:
> In the interest of having this out quicker, I'd like to highlight that
> JDT is very easy to install using P2 (Eclipse's new package manager.) So
> I think the only component that needs to be included in the .deb is the
> platform, and the nice .xpm icon. As far as I know, the platform isn't
> update-able via P2 (i.e. can't update from Eclipse 3.2 to Eclipse 3.4
> without reinstalling.)
looking at how the Fedora Project[1] packaged Eclipse 3.4, we could just
keep on packaging Eclipse Core and the most popular plugins.

But basically the Eclipse Update manager needs fixing in order to be
able to install the plug-ins in the user directory instead of its own.

Just like Firefox does it.

[1] http://fedoraproject.org/wiki/Eclipse

The classic update manager can't be used to update a plugin installed in a global read-only location. It tries to install it to your user plugin location, but when you restart, the global directory overrides the user-specific one. But you can use the update manager to install new plugins.

Probably in a perfect world it'd be possible to override the default update manager behaviour to ask it to create a .deb for each plugin to install... would it be feasible to do that? Just an idea, though.

It seems to me the .deb should include no plugins, or as close that as
possable. and have a plugin manager that hooks into eclipse's plugin manager
and causes, perhaps upon first use (ie if no .eclipse dir exists), the main
plugins to be installed for that user. This would be able to remain
consistent on a multi user system where one user wishes not to ever update
anything, and the other user wishes to keep everything current.

On Tue, Nov 25, 2008 at 11:47 AM, Matteo Settenvini <
<email address hidden>> wrote:

> Probably in a perfect world it'd be possible to override the default
> update manager behaviour to ask it to create a .deb for each plugin to
> install... would it be feasible to do that? Just an idea, though.
>
> --
> Upgrade to Eclipse 3.4.1
> https://bugs.launchpad.net/bugs/123064
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Guys, I don't see what the problem is.
Just provide the basic Java version (http://www.eclipse.org/downloads/packages/eclipse-ide-java-developers/ganymedesr1) and make sure there won't be permission problem when installing plugins via eclipse plugin manager itself. This is it. You don't need to provide -cdt, -jee and myriads of other versions at all.

@Rockwalrus: thanks for the insight!
So, suppose the .deb only includes the minimum necessary to install plug-ins (I think that would be the platform install; a bit more than RCP). This base wouldn't be update-able -- updates would install, but wouldn't be picked up by Eclipse. I think that's ok, because I usually have to re-install when switching the platform version (3.4 to 3.4.1)
On the other hand, I would have to use some Update Manager (ideally P2, it's slightly fewer clicks; classic is also pretty much OK) for anything outside this.
This would give me most of the value of the .deb (automatic JVM installation, the directory setup, the icon in the Start Menu.) Would this be feasible?

@GSMD: Some people use Eclipse for developing in other languages. For example, I don't use the JDT at all (I do ruby, python, sometime C, sometime Latex). Plus, if JDT is installed via Update Manager, it can be updated. So I believe it's better to keep JDT out of the .deb. Side-perk: it's easier to get the package done.

For those of you who say "Why does this need to be packaged? Just unzip and run!", I think you're forgetting about package management.

To upgrade Eclipse to 3.4.1 would be a nightmare without package management across a school board or business.

> Some people use Eclipse for developing in other languages.

completely agree with that! I don't need everything related to java development, since i'm using http://www.epic-ide.org/ only.

How about adding in Applications/Programming two entries for Eclipse

1. Eclipse
2. Eclipse as root (or something like that).

The second option would then run "gksudo eclipse", and be able to install updates in /usr/lib/eclipse/

I am not sure how the current discussion is related to this bug report.

In my humble opinion it would be better if we continue discussions which are not directly related to a bug report on http://ubuntuforums.org/ or http://brainstorm.ubuntu.com/

I support Simos' suggestion. I would not normally agree with a workaround like this but since it is a developer package it would be tolerable.

I also think current eclipse users would find it pretty intuitive. In the past (when eclipse was part of ubuntu) I always started eclipse as root when I wanted to install a plugin.

That would be a great first step without having to heavily hack eclipse itself.

Implementation suggestion: Since menu item comments show in tooltips, I would suggest pointing out that when as root you can/should install plugins.

Olivier Bilodeau wrote:
> Implementation suggestion: Since menu item comments show in tooltips, I
> would suggest pointing out that when as root you can/should install
> plugins.

You should never start Eclipse as root.

Rockwalrus' comment about not being to update plugins using the package manager is incorrect (at least for the latest Eclipse release).

I was able to download Ganymede SR1, install it into /opt, run it as a normal user, and update plugins (but not the core Platform). The plugins went into my ~/.eclipse directory and were used instead of the global ones.

This means we could package a core Platform-only version, or a version with a core set of plugins, and the user could update everything other than the Platform themselves, without needing root access.

On Wed, Nov 26, 2008 at 7:23 AM, Emilio Pozuelo Monfort <email address hidden>wrote:

> Olivier Bilodeau wrote:
> > Implementation suggestion: Since menu item comments show in tooltips, I
> > would suggest pointing out that when as root you can/should install
> > plugins.
>
> You should never start Eclipse as root.

Emilio, such a terse statement does not help much.

Are you a newbie that just reiterates the issue of not running things as
root, although package managers, network diagnostics, etc actually require
and run as root.

Reading the discussion so far, we are in a stalemate. Having an initial
package of Eclipse 3.4, from a PPA repository, that allows to get Eclipse
installed and then configured in GUI all the way, is a positive thing to do.
This might lead to a proper solution in the near future.

Simos, you are not helping much either. Running applications as root is a no-go, no need to call a man a newbie. Just imaging every user of a thin client doing this -- sudo rights for everyone? No way! There should be a sane solution.

Eclipse should fix two things: installing updates to user directories and update manager preferring user directory to the system one. After that, every user can install and update his Eclipse as much as he wants, while the admin will install stable and proven updates.Then there should be some notifying the user about old plugins and offering to remove them from his user profile -- this would be enough for most cases. Still, these problems are in Eclipse and need to be addressed by upstream.

I sent this by E-Mail, but it didn't show up, so here it is:

Olivier Bilodeau wrote:
> > I support Simos' suggestion. I would not normally agree with a
> > workaround like this but since it is a developer package it would be
> > tolerable.
> >
> > I also think current eclipse users would find it pretty intuitive. In
> > the past (when eclipse was part of ubuntu) I always started eclipse as
> > root when I wanted to install a plugin.
> >
> > That would be a great first step without having to heavily hack eclipse
> > itself.
> >
> > Implementation suggestion: Since menu item comments show in tooltips, I
> > would suggest pointing out that when as root you can/should install
> > plugins.
> >
> >
I actually install eclipse in /opt and own the directory. I realize
owning the dir wouldn't work for a debian package, but what about having the
install script add a developer group and ask which users should be added
to the group. Then the folders for eclipse can have group r+w permissions. This
solves the problem of running it as root. What do others think?

Thanks,
Micah

Nikolai,

I'm not understanding. Eclipse (Ganymede) *already* installs updates to user directories (all except for Platform) and prefers those updates to the system ones. There's nothing to be done here, it already works as it should.

@Micah: bad idea, sorry. It is perfectly possible that there is some kind of configuration which is "agreed on" (this is installed by the admin) and then there might be some differences between developers, i.e. someone wants to have a python plugin, which only s/he needs, someone else prefers a slightly more instable version of mylyn connector etc. What happens if two developers start an upgrade at the same time? What if Eclipse needs to be restarted? Personal plugin repository is better in this case.

BTW. a bigger problem with Eclipse 3.4 PPA packages is right now that P2 is completely disabled, not that it can't write to certain locations...

@Joel: if this is the case, then there is a lot less to talk about. I'm sorry, I only had packages from PPA to play with, which, as I remember now, do not have Software Updates (not even classic) enabled. Maybe we should re-iterate which plugin installation problems we still have? I've only seen two, the ones I've described, if they work as described, there is actually no issue?

This bug report is an upgrade request for the Ubuntu repositories. Discussion about alternative methods of upgrade/installation and the workings of eclipse should be taken elsewhere. This is a large bug, and each comment is generating a large amount of bugmail.

The upgrade request is already with Debian, so unless Ubuntu plans to release its own package, there is no need for any further comments here.

Simos Xenitellis wrote:
> On Wed, Nov 26, 2008 at 7:23 AM, Emilio Pozuelo Monfort
>> You should never start Eclipse as root.
> Emilio, such a terse statement does not help much.

People may read this bug report and then start Eclipse as root because someone
pointed it out. So this *does* help them :-)

And no, an IDE is not a package manager

I 'd like to invite all subscribers to this bug to <email address hidden>

We are trying to start an effort to get eclipse-3.4 and its ilk in shape for debian. From there merging it to ubuntu will be much easier.

The big problem is we don't have anyone working full time on this, but I think we can still make it happen if a large number of people accept to contribute a small piece of the puzzle each.

Fact: The number of subscribers is well more than 100, if even half of us contributed a small, trivial task we 'd all enjoy recent eclipse packages for a long time now, with room to spare for helping overholt, akurtakov and the other fedora guys upstream. in the linux-distros project.

Being a newbie is *not* an excuse for not helping. We have lots of small, "low hanging fruit" tasks for people with skills in unix, branding stuff (drawing logos etc), packaging, Java, ant, eclipse, XML, project management etc.

If on the other hand you believe you have no skills whatsoever (and no will to learn) one would wonder why do
you care for an IDE anyway :-)

So, if you are still interested, please come to the above mailing list and/or in #debian-java in OFTC, introduce yourself and present your skills and time constraints. Our team is mostly comprised of concerned users like you, we have at least one debian developer to help with uploading and such, but no "gurus" and no interest in flaming people (so no reason to be scared, honestly :-)

Or, you could continue waiting patiently and (judging from history so far) maybe by 2012, eclipse packages will be in ubuntu Vintage Vinegar or something ;-)

Cheers,
Pantelis

On 12/16/08, pkt <email address hidden> wrote:
> I 'd like to invite all subscribers to this bug to <pkg-java-
> <email address hidden>>
>
> We are trying to start an effort to get eclipse-3.4 and its ilk in shape
> for debian. From there merging it to ubuntu will be much easier.
>
> The big problem is we don't have anyone working full time on this, but I
> think we can still make it happen if a large number of people accept to
> contribute a small piece of the puzzle each.
>
> Fact: The number of subscribers is well more than 100, if even half of
> us contributed a small, trivial task we 'd all enjoy recent eclipse
> packages for a long time now, with room to spare for helping overholt,
> akurtakov and the other fedora guys upstream. in the linux-distros
> project.
>
> Being a newbie is *not* an excuse for not helping. We have lots of
> small, "low hanging fruit" tasks for people with skills in unix,
> branding stuff (drawing logos etc), packaging, Java, ant, eclipse, XML,
> project management etc.
>
> If on the other hand you believe you have no skills whatsoever (and no will
> to learn) one would wonder why do
> you care for an IDE anyway :-)
>
> So, if you are still interested, please come to the above mailing list
> and/or in #debian-java in OFTC, introduce yourself and present your
> skills and time constraints. Our team is mostly comprised of concerned
> users like you, we have at least one debian developer to help with
> uploading and such, but no "gurus" and no interest in flaming people (so
> no reason to be scared, honestly :-)
>
> Or, you could continue waiting patiently and (judging from history so far)
> maybe by 2012, eclipse packages will be in ubuntu Vintage Vinegar or
> something ;-)
>
> Cheers,
> Pantelis
>
> --
> Upgrade to Eclipse 3.4.1
> https://bugs.launchpad.net/bugs/123064
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in "eclipse" source package in Ubuntu: Confirmed
> Status in "eclipse" source package in Debian: New
>
> Bug description:
> Binary package hint: eclipse
>
> Eclipse 3.4.1 is now out - maybe we could see this in Jaunty?
>
> [was: Eclipse 3.3/3.4 is out, maybe we could see this in Gutsy/Intrepid?]
>

In 2012, one can expect Ubuntu Porky Piglet (LTS release) and Queer
Quacker (normal release), following the naming policy. It's not quite
time for a Vintage Vinegar release yet, though that name could be used
as a general health indicator.
:)

--
Victor Bielawski

>> Or, you could continue waiting patiently and (judging from history so far)
>> maybe by 2012, eclipse packages will be in ubuntu Vintage Vinegar or
>> something ;-)
>>
>
> In 2012, one can expect Ubuntu Porky Piglet (LTS release) and Queer
> Quacker (normal release), following the naming policy. It's not quite
> time for a Vintage Vinegar release yet, though that name could be used
> as a general health indicator.
> :)

Interesting observation :)

Cheers,
Pantelis

No, in 2012 our world-domination plan will be more or less accomplished, thus we will have the Ultimate Ubuntu. Howver, due to releases introduced during the beta upgrades, it will be followed by the Very-last Version, and finally, to fix bug #1, there will be the Wedding with Windows. Then, there will be no further version for obvious reasons¹, even if it would have an X in the name :)

¹ Microsoft will claim their patent on boot processes and gain an exclusive right to produce such software.

s/releases/bugs/ ... I am not even able to add some ironic garbage to a bug report it seems ...

As a christmas present, a pre-pre-pre-alpha version of an eclipse 3.4.1 package is now available in my
PPA;

http://launchpad.net/~pktoss/+archive

Details are available in this email to <email address hidden>:

http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/2008-December/018863.html

I will quite likely not put any more development time on eclipse 3.4.x since 3.5Mx seems to be getting
a better/easier build system, but I will most likely be available for questions/patch review should
anyone decide to help with the fixes needed to get the package in shape for debian/ubuntu.

So it 's mostly up to you from now on :-)

Thanks. Build seems to work nicely.
Had to do a complete uninstall of current eclipse first, in order to get it to install.
Could have been the couple of addons I'd installed system wide (had to manually remove those anyway).

Apart from that, works great. Oh, apart from eclipse w/ full ganymede needing more than 1024 files open so I had to crank up /etc/security/limits.conf

fwiw, in my PPA I have packages for Eclipse and a bunch of plugins that I built using the release binaries from Eclipse.org:
https://launchpad.net/~yogarine/+archive

Obviously these packages aren't suitable for inclusion in the Ubuntu repos, but they are stable and usable for everyone that just wants something that gets the job done in the meantime.

Also, afaik the plugins in my ppa (like eclipse-pdt, etc) should all play nicely with pkt's packages. Haven't tested this though, but they use the dropins folder in /usr/lib/eclipse/dropins.

I just noticed the Assignee changed to the Medibuntu Packaging team... Does that mean Eclipse 3.4.1 is going to be included in Medibuntu?

I assigned it to Medibuntu Packaging to see if they would include it - up to them to review

You should ask a person / team before assigning bugs to them. A good general rule is not to assign bugs to anyone but yourself.

The Ubuntu Eclipse upgrade has nothing to do with Medibuntu, so I have removed the assign.

Bloody hell, even my university has Ganymede on the Fedora 7 image.

I found this page about people working to create Ubuntu packages for the current version of eclipse:

https://launchpad.net/~eclipsers

"A collaboration to try to provide an up-to-date eclipse package for Ubuntu (and possibly Debian in general)."

We're quickly approaching two years since this bug was launched, many people have said things but nothing has come from it to get a proper package-build-process started. Considering how many developers use Eclipse (for so many different things), I would have put money on this being fixed 18 months ago... And I would have lost.

So apart from people randomly assigning this to random groups (Medibuntu? wtf?!), what's going on? People appear to be taking this on, finding it doesn't build and eventually giving up. Is there any way we can elevate this from a community bug to a proper Canonical "we can't release Karmic with E3.2" bug?

Because shipping Eclipse 3.2 in Intrepid and Jaunty is a complete joke. Shipping it in Karmic is just lazy. If we can't do it as a community, lets get Canonical and Sun talking to resolve this issue before we start getting laughed at.

Oli, I think the reason this will never be done is really simple: not having elcipse package is not a problem.

At all.

It's really easy to install eclipse manually, It have it's own internal update, plugins installation and dependency resolving system. Same time, any "external" update and plugins installation are complex, unreliable and... just never worse the time spent on them vs. simplicity of eclipse manual installation and self-update.

Who want to kill days or even weeks on the problem that can be solved in other way in 5 minutes?

Just forget about the eclipse package. Anyone who need it will be able to install manually.

Well... IMHO, the "own internal update, plugin installation and dependency resolving system" is not that reliable. I cannot count the number of problems and workarounds I had trying to install several plugins with different (and incompatible) dependencies. It's so painful that most plugin editors also release a version of their plugin bundled with eclipse, to avoid its integration if you want to give it a try.

Also, I think that when you are a part-time developper, being able to install your workspace from clean distribution package, if you want, is a real advantage since you can focus on your job, and not on system administration/maintainance tasks.

What's the status of other major distribution ? Most of them ship Ganymede (3.4)... so it seems to be feasible... or maybe I missed something ?

Somebody's working on it: https://launchpad.net/~eclipse-team/+archive/ppa
One could say that it isn't difficult to install eclipse manually, but imho
it's bad
school of thought: one could say that about 70% of software.

On Fri, Apr 17, 2009 at 3:29 PM, Oli <email address hidden> wrote:

> We're quickly approaching two years since this bug was launched, many
> people have said things but nothing has come from it to get a proper
> package-build-process started. Considering how many developers use
> Eclipse (for so many different things), I would have put money on this
> being fixed 18 months ago... And I would have lost.
>
> So apart from people randomly assigning this to random groups
> (Medibuntu? wtf?!), what's going on? People appear to be taking this on,
> finding it doesn't build and eventually giving up. Is there any way we
> can elevate this from a community bug to a proper Canonical "we can't
> release Karmic with E3.2" bug?
>
> Because shipping Eclipse 3.2 in Intrepid and Jaunty is a complete joke.
> Shipping it in Karmic is just lazy. If we can't do it as a community,
> lets get Canonical and Sun talking to resolve this issue before we start
> getting laughed at.
>
> --
> Upgrade to Eclipse 3.4.2
> https://bugs.launchpad.net/bugs/123064
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “eclipse” source package in Ubuntu: Confirmed
> Status in “eclipse” source package in Baltix: New
> Status in “eclipse” source package in Debian: New
>
> Bug description:
> Binary package hint: eclipse
>
> Eclipse 3.4.2 is now out - maybe we could see this in Jaunty?
>
> [was: Eclipse 3.3/3.4/3.4.1 is out, maybe we could see this in
> Gutsy/Intrepid?]
>

--
M. Modrzejewski

Caesar, that's really dangerous thinking there. Those same arguments could
be levelled against lots of other mature apps that have their own
ecosystems... Surely you wouldn't suggest not packaging (for example)
Firefox?

We use packages for a good reason: it keeps things sturdy and constant
between similar machines and results in a standardised install process you
can script for any machine. It also, psychologically speaking, instils an
ethos of installing things from a trusted source. Downloading things from
all-over the internet is one reason why the security landscape is so mired
on Windows.

You might try and say that Eclipse appeals to a different audience but
looking at Add/Remove, it's is one of the most popular packages in the
package popularity contest for the Programming section, only beaten outright
by Python (for obvious reasons). People want it and they want to get it from
Ubuntu's repositories.

I don't deny that downloading and untarring Eclipse from eclipse.org works
but that's not the point. Eclipse is major software that thousands (if not
millions) of people use. "It's a waste of time" doesn't seem like a valid
argument.

On Fri, Apr 17, 2009 at 2:51 PM, Caesar <email address hidden> wrote:

> Oli, I think the reason this will never be done is really simple: not
> having elcipse package is not a problem.
>
> At all.
>
> It's really easy to install eclipse manually, It have it's own internal
> update, plugins installation and dependency resolving system. Same time,
> any "external" update and plugins installation are complex, unreliable
> and... just never worse the time spent on them vs. simplicity of eclipse
> manual installation and self-update.
>
> Who want to kill days or even weeks on the problem that can be solved in
> other way in 5 minutes?
>
> Just forget about the eclipse package. Anyone who need it will be able
> to install manually.
>
> --
> Upgrade to Eclipse 3.4.2
> https://bugs.launchpad.net/bugs/123064
> You received this bug notification because you are a direct subscriber
> of the bug.
>

do you expect apt to be more reliable in installing eclipse and its numerous plugins than eclipse itself?

When I need my workspace on the clean machine I simply unpack my eclipse installation with all its plugins. It is easier than installing everything with apt and it is easier than fresh eclipse install and then plugins install with internal installer.

And I don't need to configure tons of tiny things for every plugin.

Apt and eclipse can live together only when all plugins will have their's own debs maintained by plugin's developers. In any other case you'll have eventually install something through eclipse's internal installer which is bad. Not because it's just bad but because you will have two managers - apt and eclipse messing with the same software. You will never be sure which way to use next time because one will work better for one set of lugins and other will work for some other set, and you will never know who's responsible of the failure - plugin creator, eclipse, or repo package maintainer.

I made my own packages of Eclipse and a bunch of plugins using the
release tarballs from eclipse.org:
https://edge.launchpad.net/~yogarine/+archive/ppa

I did this because from my experience installing Eclipse and then
installing all the plugins you want is always a big hassle that can
take up a whole hour. Why go to all that trouble if you can just type:

sudo apt-get install eclipse-pdt

Just give my ppa a try and I'm sure you'll like the idea.

On Fri, Apr 17, 2009 at 4:36 PM, Oli <email address hidden> wrote:
> Caesar, that's really dangerous thinking there. Those same arguments could
> be levelled against lots of other mature apps that have their own
> ecosystems... Surely you wouldn't suggest not packaging (for example)
> Firefox?
>
> We use packages for a good reason: it keeps things sturdy and constant
> between similar machines and results in a standardised install process you
> can script for any machine. It also, psychologically speaking, instils an
> ethos of installing things from a trusted source. Downloading things from
> all-over the internet is one reason why the security landscape is so mired
> on Windows.
>
> You might try and say that Eclipse appeals to a different audience but
> looking at Add/Remove, it's is one of the most popular packages in the
> package popularity contest for the Programming section, only beaten outright
> by Python (for obvious reasons). People want it and they want to get it from
> Ubuntu's repositories.
>
> I don't deny that downloading and untarring Eclipse from eclipse.org works
> but that's not the point. Eclipse is major software that thousands (if not
> millions) of people use. "It's a waste of time" doesn't seem like a valid
> argument.
>
> On Fri, Apr 17, 2009 at 2:51 PM, Caesar <email address hidden> wrote:
>
>> Oli, I think the reason this will never be done is really simple: not
>> having elcipse package is not a problem.
>>
>> At all.
>>
>> It's really easy to install eclipse manually, It have it's own internal
>> update, plugins installation and dependency resolving system. Same time,
>> any "external" update and plugins installation are complex, unreliable
>> and... just never worse the time spent on them vs. simplicity of eclipse
>> manual installation and self-update.
>>
>> Who want to kill days or even weeks on the problem that can be solved in
>> other way in 5 minutes?
>>
>> Just forget about the eclipse package. Anyone who need it will be able
>> to install manually.
>>
>> --
>> Upgrade to Eclipse 3.4.2
>> https://bugs.launchpad.net/bugs/123064
>> You received this bug notification because you are a direct subscriber
>> of the bug.
>>
>
> --
> Upgrade to Eclipse 3.4.2
> https://bugs.launchpad.net/bugs/123064
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Alwin Garside
Email: <email address hidden>
Blog: http://www.yogarine.net
Twitter: http://twitter.com/yogarine
MSN: <email address hidden>
Skype: yogarine
Phone: +31 (0)23 8442699
Mobile: +31 (0)6 49 748 424

are there some technical issues that doesn't allow to install core of eclipse via apt (and keep it updated when new releases of eclipse occurs) and let the end user to install plugins via eclipse's build-in mechanisms? I don't understand why you are packaging let's say perl + tons of modules (the same I can say regarding php/python/ruby, etc) when it has own module manager called "cpan". If someone need to update module (installed via apt) or install new module (not packages as .deb) he is able to do that via "cpan" and everything works fine, because such modules installs to "/usr/local/lib" and they have higher priority. Why you can't do the same with eclipse?

Fwiw:

1) The statement that eclipse doesn't need packaging and it is trivial
to install standalone is imho *a joke*.
The fact is, eclipse *does* have dependencies on other stuff that is
installed via the package system
(by far the most painful of which is, of course, mozilla/xulrunner).

Packaging eclipse hopefully makes packagers responsible for making
sure the installed versions of these
dependencies are appropriate and won't cause problems (e.g., see the
current bugs in fedora/debian
where eclipse doesn't even start because the mozilla guys decided to
change their API once more.
Those are the kinds of problems that packaging is supposed to fix).

2) The hardest technical issue for packaging, is by far the eclipse
build system. My package released
in christmas (based on the fedora package) proved that it is indeed
possible to get something that works
(even with eclipse's new update/provisioning system, P2) but the size
of packaging scripts and the number
of patches that had to be applied to get things to work *almost*
reasonably, shows this path is unfortunately
unmaintainable in the long run. Even the Fedora/Redhat guys seem to be
concerned with that issue.

The linuxdistros eclipse project is working on a saner build system
for eclipse (called eclipse-build)
and rockwalrus has worked on a slightly different build system too
(that I like a bit better). If you are
really interested in seeing recent eclipse in shape for debian/ubuntu
and are reasonably well versed
in java/ant, you should really consider helping those efforts.

There are also policy issues imho: E.g., should the osgi framework
(equinox) be provided separately?
(it is already used standalone by a few people). What should we do
with the shared libraries?

Other issues are simple but tedious stuff like packaging and pushing
all the dependencies
in a form that are usable by eclipse (at least an OSGified Manifest.MF).

I have filed bugs for lots of the subtasks I could think of in
https://bugs.launchpad.net/eclipse-debian
My source has also been public from the beginning and is in a
gitorious repository (eclipse-debian)*
rockwalrus also has the eclipse-ubuntu effort.

So, currently it seems nobody has the needed free time (I know I
don't) to finish the job. But if everyone
contributing complaints to this bug had invested a few hours to solve
one of the documented subproblems,
eclipse would be pretty ok by now ;)

*git://gitorious.org/eclipse-debian/mainline.git

Caesar wrote:
> do you expect apt to be more reliable in installing eclipse and its
> numerous plugins than eclipse itself?
>
> When I need my workspace on the clean machine I simply unpack my eclipse
> installation with all its plugins. It is easier than installing
> everything with apt and it is easier than fresh eclipse install and then
> plugins install with internal installer.
>
> And I don't need to configure tons of tiny things for every plugin.
>
> Apt and eclipse can live together only when all plugins will have
> their's own debs maintained by plugin's developers. In any other case
> you'll have eventually install something through eclipse's internal
> installer which is bad. Not because it's just bad but because you will
> have two managers - apt and eclipse messing with the same software. You
> will never be sure which way to use next time because one will work
> better for one set of lugins and other will work for some other set, and
> you will never know who's responsible of the failure - plugin creator,
> eclipse, or repo package maintainer.
>
>
You could make this same argument for Firefox with the myriad plugins,
but it's still packaged. Some plugins with .deb packages and some as .xpi

There is a difference between the two in that the .deb packages are
systemwide whereas the .xpi are for the user only. This was one of the
main issues brought up earlier in this thread. A mutli-user system
needs at least the base eclipse installation if not all the necessary
plugins to be global so only one copy is needed on the system.

@Sergiy Zuban:
No there are no technical limitations to having mixed system-wide eclipse updated through apt and local plugins installed through Eclipse's Update Manager.

I have done lots of test with the packages in my PPA and in all cases things just work perfectly. The approach I took was to use Eclipse 3.4's dropins folder to install eclipse plugins system-wide in .debs.

Glad to see this is being proposed as blueprint foundations-karmic-eclipse-update for karmic

https://blueprints.launchpad.net/ubuntu/+spec/foundations-karmic-eclipse-update

I actually really like the example packages in the PPA from ~yogarine, quite an interesting idea to package in this way

Well, why not aim for 3.5 instead? It is not like the work required
to get 3.4.x in shape is any less, or that it would
be finished before 3.5 is out anyway. (Of course that is just imho).

I'm be willing to do testing, but I know nothing about Java or packaging.

I'd like too! Ready to learn!

On Tue, May 19, 2009 at 6:58 PM, Luca Saba <email address hidden> wrote:
> I'd like too! Ready to learn!

Testing is great but what is missing right now is someone with enough free time
to do the actual work. I 'll hopefully have some free time in the beginnings of
July but not before.

I would like to help.

Status know, package isn't maintained in Debian anymore. Updating to a new package version requires some effort. If somebody does want to start this, please get in contact on the ubuntu-devel ML.

The current packaging in the PPA isn't suited for upload to karmic/universe.

As long as the package is available in Debian, it should not be removed in Ubuntu. Blacklisting for syncs doesn't seem to be appropriate.

Matthias: can you work on fixing bug 312824 (i.e., sponsoring the move of jetty from contrib to main) so that someone can actually get started on decent eclipse packaging?

Hello, seems like Mandriva ships the latest version of eclipse.

http://qense.nl/eclipse-34-on-ubuntu-is-tricky-but-possible/comment-page-1#comment-6291

Being Mandriva based on Ubuntu couldn't Debian/Ubuntu grab the package from them or join forces ?

Mandriva isn't based on Ubuntu at all (Mandriva is a new name for Mandrake, which in turn is based on Red Hat, and both are older than Ubuntu).

Mandriva also uses RPMs whereas Ubuntu uses deb packages, and packaging guidelines are quite different, so one of Debian or Ubuntu will have to package Eclipse by themselves (thanks to some volunteers, of course).

i use the latest version of eclipse in Ubuntu 8.04 http://ubuntuforums.org/showthread.php?t=941461&highlight=eclipse

Thanks for the information Karl, but this bug report is about packaging the
latest stable version of Eclipse.

On Mon, Jun 8, 2009 at 6:10 PM, karl michael <email address hidden>wrote:

> i use the latest version of eclipse in Ubuntu 8.04
> http://ubuntuforums.org/showthread.php?t=941461&highlight=eclipse
>
> --
> Upgrade to Eclipse 3.4.2
> https://bugs.launchpad.net/bugs/123064
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “eclipse” source package in Ubuntu: Confirmed
> Status in “eclipse” source package in Baltix: New
> Status in “eclipse” source package in Debian: New
>
> Bug description:
> Binary package hint: eclipse
>
> Eclipse 3.4.2 is now out
>

Fedora 11 uses 3.4.2.

http://docs.fedoraproject.org/release-notes/f11/en-US/sect-Release_Notes-Eclipse.html

Please change the targeted upgrade to Eclipse 3.5.0.

Very inconvenient. I really hope that Karmic Koala includes Eclipse 3.5.

While the Eclipse Team PPA doesn't currently provide Jaunty amd64 packages, I was able to install the Intrepid packages successfully. Here's my /etc/apt/sources.list.d/eclipse.sources.list:

#deb http://ppa.launchpad.net/eclipse-team/ppa/ubuntu jaunty main
#deb-src http://ppa.launchpad.net/eclipse-team/ppa/ubuntu jaunty main
# The above is commented out because the official Jaunty PPA below apparently
# doesn't contain amd64 builds.
# c.f. http://qense.nl/eclipse-34-on-ubuntu-is-tricky-but-possible
# Using the previous (Intrepid) Ubuntu version.
deb http://ppa.launchpad.net/eclipse-team/ppa/ubuntu intrepid main
deb-src http://ppa.launchpad.net/eclipse-team/ppa/ubuntu intrepid main

I'm a frequent visitor of #eclipse on freenode irc and there is at least one perso each day, who has a problem related to eclipse 3.2 on ubuntu.

Eclipse 3.5 will be released this week and this issue will celebrate it's third birthday soon. Any chance that it will be adressed for the next ubuntu release?

If packaging 3.5 is too much work, could you please consider removing 3.2 from the repository or notify the user that it is outdated?
This would help to prevent a bad user experience (install 3.2 via repo, use it, find out its 3 years old, migrate to 3.5 manually).

Is there anything eclipse could do to make packaging easier?

2 eclipse projects that may be of interest:
linux tools project: http://wiki.eclipse.org/Linux_Distributions_Project
eclipse packaging project: http://www.eclipse.org/epp/

+1 to previous comment. If this is not going to be fixed for karmic, please remove completely in karmic. The argument appears to be about whether to package eclipse, or to use the official eclipse installer. In either case, leaving 3.2 is a bad idea.

There are many thing eclipse could do to make packaging easier:

* Provide a source package (preferred as tar.gz) which does not contain any compiled file (like .jar).
* One command (like running ant) to build all binary files from scratch.
* One command to cleanup the directory (delete all generated files).
* Work with OpenJDK 6.
* Maybe one command to install the generated files (should pay attention to the DESTDIR variable).
* A license file which lists all relevant information.
* The plug-in system should allow users to install plug-ins into their home directories.
* The plug-in system should allow plug-ins to be installed system wide (only) by Debian packages.
* The possibility to disable the update system (the Debian package system provides updates).

Maybe some points on the list are already resolved. The last time I tried to work on the eclipse package, I failed on configuring/compiling eclipse (and of course understanding the build process). If someone wants to help me understanding/compiling eclipse please feel free to contact me directly (e.g. by IRC or mail).

At the earliest in August/September I have time to work on the package. I will then have a look at the Linux Tools Project. I think it is at most possible to provide an up-to-date package for karmic/jaunty in a PPA and pushing this version then in karmic+1. It's on my todo list, but I cannot promise anything (because I like working on smaller/easier packages).

I think the request to remove eclipse from ubuntu is extremely smart. If eclipse will want to be in ubuntu they'll need to cooperate themselves, as ubuntu clearly does not have enough man power. On the other hand, keeping ecliplse 3.2 gives a bad reputation to ubuntu.

And if there is no such package, it's not too bad, since eclipse must be kept up-to date, and people using eclipse is typically used to get it from the web site.

+1, please remove eclipse from ubuntu. How does one file such a request if there is a more proper way?

On Tue, Jun 23, 2009 at 4:50 PM, Vincenzo Ciancia<email address hidden> wrote:
> I think the request to remove eclipse from ubuntu is extremely smart. If
> eclipse will want to be in ubuntu they'll need to cooperate themselves,
> as ubuntu clearly does not have enough man power. On the other hand,
> keeping ecliplse 3.2 gives a bad reputation to ubuntu.
>
> And if there is no such package, it's not too bad, since eclipse must be
> kept up-to date, and people using eclipse is typically used to get it
> from the web site.
>
> +1, please remove eclipse from ubuntu. How does one file such a request
> if there is a more proper way?

Eclipse is now officially orphaned in upstream debian so it will probably
be removed from ubuntu if nobody picks it up. I think the proper way
to request a feature in ubuntu is via a blueprint in launchpad but I 'm not
so sure.

https://blueprints.launchpad.net/ubuntu/+spec/eclipse

There's a Linux Distros project at Eclipse that aims to make Eclipse easier to use on Linux.

Maybe some people from the Ubuntu team should consider joining?

Red Hat is an active participant and they have done some recent work to help things.

http://dev.eclipse.org/mhonarc/lists/linuxtools-dev/msg00130.html

Or maybe talking to the Eclipse team would help?

The problem is that, for the most part, there is no debian/ubuntu eclipse team.

There is mostly just individuals right now, many with almost no free time
(e.g., I don't even use eclipse nowadays).

Removing the ancient 3.2 version might help bring a few more interested
developers to assist towards packaging 3.5.

Btw, some things the eclipse team could do to make packagers' lives easier
and increase the chances for an eclipse version that meets debian's high
freedom/quality standards:

* Test your code with openjdk.
* Assist with building eclipse in a headless manner from the command-line.
(this practically means test your code with eclipse-build and help fix the bugs)
2-3 redhat people trying to fix bugs in the ant scripts of more than 50 people
doesn't really scale, especially if said 50 people continuously add new bugs :)

There are other issues like proper policy for eclipse and plugins (placement
within FHS) etc but debian people can deal with those and the build issue
is currently the thorniest

It appears that Doko (Matthias Klose) has uploaded a 3.4 package to Karmic.

why not 3.5?

Why not be thankful?

On 6/29/09, karl michael <email address hidden> wrote:
> why not 3.5?
>
> --
> Upgrade to Eclipse 3.5.0
> https://bugs.launchpad.net/bugs/123064
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “eclipse” package in Ubuntu: Confirmed
> Status in “eclipse” package in Baltix: New
> Status in “eclipse” package in Debian: New
>
> Bug description:
> Binary package hint: eclipse
>
> Eclipse 3.5.0 will soon be out.
>

--
Victor Bielawski

v4sw5CJUhw4ln4pr7OPck2/3ma4u7Lw3+2TVXm5l6DFRUi2Ce2t2b7AHIMTen5a16s4r2p-1/-1g1

If it is any help: I think on Gentoo it is possible to compile eclipse with openjdk (at least 3.4, did not test with 3.5, yet).

Where is the packege? I mean it's not here:

http://packages.ubuntu.com/search?keywords=eclipse&searchon=names&suite=karmic&section=all

I think that if 3.4 was uploaded then the path is clean to have eclipse 3.5 or 3.5+1 in karmic+1 isn't it?

BTW I am thankful :)

On Tue, Jun 30, 2009 at 2:11 PM, Vincenzo Ciancia<email address hidden> wrote:
> Where is the packege? I mean it's not here:
>
> http://packages.ubuntu.com/search?keywords=eclipse&searchon=names&suite=karmic&section=all
>
> I think that if 3.4 was uploaded then the path is clean to have eclipse
> 3.5 or 3.5+1 in karmic+1 isn't it?
>
> BTW I am thankful :)
>
> --
> Upgrade to Eclipse 3.5.0
> https://bugs.launchpad.net/bugs/123064
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Hey, it is here:
https://launchpad.net/ubuntu/karmic/+source/eclipse

That package contains eclipse 3.4.1

Matthias Klose was active here on 2009-05-26: https://bugs.launchpad.net/ubuntu/+source/eclipse/+bug/123064/comments/169

At that date the description here was already asking for 3.4.2 and got changed to 3.5.0 on 2009-06-16.

Eclipse releases at a very accurate schedule (a major release at the last week of june for 6 years in a row with service releases in fall and winter), so i wonder why 3.4.1 was used instead of 3.5 (or at least 3.4.2).
And while 3.4.1 is better than 3.2, it's still outdated (major and minor). So including this would be an improvement but no solution. In my opinion removing the eclipse package altogether would be better than including 3.4.1.

Remove eclipse totally is better than have a completely and totally obsolete version. It's better both for Ubuntu project, at least they can pretend it's a choice, and more important here for eclipse. Eclipse 3.2 is soooooo old that it's completely ridiculous. Eclipse project SHOULD forbid any distribution as old as this one. It changed so much since that it's just a bad publicity for them.

At least the binary installation provide by eclipse project is working fine and it's easy to install. Naturally for any large deployement in a compagny that can be a problem but they will other distributions that's it and naturally canonical will lost contract because of this...

In a previous comment (https://bugs.launchpad.net/ubuntu/+source/eclipse/+bug/123064/comments/184), I mentioned the Ubuntu team talking to the Eclipse linux community for help.

I've seen nothing yet.

If RedHat can do it... so can Ubuntu
     http://fedoraproject.org/wiki/Eclipse

How about getting some collaboration going? We don't bite.

Yeah, Eclipse 3.4.1 finally arrived in Karmic! Thanks to anyone who made this possible!

Yes thanks very much for eclipse 3.4 in karmic.

I have to ask, why does the "eclipse-platform" package depend on the "firefox" package?

Shouldn't it just depend on the "www-browser" virtual package or is there something in firefox that it needs? If it's the latter, then the firefox-3.5 package should probably have "Provides: firefox" or eclipse-platform should depend on "firefox | firefox-3.5" or something.

For a few people at my work, the "firefox-3.5" package is already installed in karmic and apt is trying to install firefox 3.0 too when we run "apt-get install eclipse"

thanks again,

On Fri, Jul 17, 2009 at 9:57 PM, aporter<email address hidden> wrote:
> Yes thanks very much for eclipse 3.4 in karmic.
>
> I have to ask, why does the "eclipse-platform" package depend on the
> "firefox" package?

Eclipse uses a particular version of xulrunner for various functions
e.g., to display the welcome page.

Shouldn't it depend directly on xulrunner, then? Or does it require something from the firefox package?

A quick comment from doko after he uploaded:
<doko> I'm filing a bug report to remove this package again, because it does include a handful or more third party libs inside the eclipse package. if you want to keep eclipse, please fix these bugs, hint, hint ;)

Basically, where possible, it's preferred to tear out libraries Ubuntu already ships.

As the description states 3.5.0 is out and SHOULD be tested in karmic to make it run great in the next LTS release. Ubuntu already is the distro of choice for most developers. It is sad that they have to get Eclipse from somewhere else than the Ubuntu repos. So I vote for exchanging 3.4 with 3.5 in karmic.

The Eclipse linuxtools project has just released version 0.3.0, which includes an eclipse-builder component that standardises Eclipse builds across Linux distros. This currently works with 3.5.x, I don't know about 3.4.x, but it might be a way to get to 3.5.x quickly. From the announcement:

The Eclipse Linux Tools team is pleased to announce our 0.3.0 release! This
release is compatible with the Galileo releases of the Eclipse SDK (version
3.5) and CDT (version 6.0). It is available now from our update site:

http://download.eclipse.org/technology/linuxtools/update
(yes, that will give a 404 in the browser; just use it in the update manager)

Should you prefer a zip of the release, it is available at our downloads page:

http://www.eclipse.org/linuxtools/downloads.php

Installation instructions are available:

http://wiki.eclipse.org/Linux_Tools_Project/PluginInstallHelp

113 bugs [1] were closed as part of this release including bug fixes and new
features. Highlights include:

* integration of the SystemTapGUI project including editing and graphing capabilities
* a Valgrind suppressions editor
* importing/exporting of SRPMs/RPMs
* Eclipse Help documentation for some of our plugins
* manual control of the OProfile daemon
* the first coordinated release of eclipse-build, our scripts to ease the
  building of the Eclipse SDK for Linux distributions (tested so far on Fedora
  and Debian). See: http://wiki.eclipse.org/Linux_Tools_Project/Eclipse_Build
* C++ hover help for the libstdc++ library

The full list of highlights can be see on our new and noteworthy page:

http://eclipse.org/linuxtools/new

Since some days we (Niels Thykier, Adrian Perez, and I) work on getting an eclipse 3.5 build for Debian/Ubuntu based on the Linux Tools. You can grab the current status from the git repository [1]. Helping hands are welcome (especially ant hackers and FHS experts). You can find us in the #eclipse-linux channel on Freenode and in #debian-java on OFTC.

[1] http://git.debian.org/?p=pkg-java/eclipse.git;a=summary

So, I had been using the 3.4 ppa build mentioned in this bug in Jaunty with some success.

I decided to give Karmic a shot, and after some entertainment with the Karmic eclipse not picking up all its dependancies (had to manually add them a few at a time, working my way down), eclipse was installed and running.

However, on starting eclipse I get:
"This Eclipse build doesn't have support for the integrated browser"

None of my oh-so-crucial plugins like subclipse appear to be there, and if I go to software updates I get:
"Cannot launch the Update UI. This installation has not been configured properly for Software Updates."

I suppose I can go back to the ppa build which did indeed work quite nicely and also uninstalled quite nicely too, but I'm wondering if anyone here has had better luck.

Enabling classic update seems to work.
Not sure exactly what happened to my existing plugins, but, hey. looks hopeful.

Fail. Seems to want to install in /usr/lib, and running as root (hey, whatever, I'll install the packages globally if it wants - I'd rather it was ubuntu packaged subclipse anyway) simply aborts with various errors like:
!MESSAGE Missing required bundle org.eclipse.wst.common.environment_[1.0.100,1.1.0).

Guess I'm going back to:
https://launchpad.net/~yogarine/+archive/eclipse

Which I think was what I was using before.
Oh well. I'll stop spamming the bug now and go back to lurking.

Oh. One more bit of bugspam. I'm not sure exactly what is going on w/ Yogarine's - it is definitely not the one I was using before.

eclipse depends on eclipse-platform and eclipse-jdt, but eclipse-jdt depends on eclipse-platform-sdk which conflicts with eclipse-platform.

plus circular deps between various other packages.
after 30m of mucking about in dpkg -i I think I'm going to look for some alternative packaging.

... one more. Sorry. Just didn't want to muck people up with prior comments.
 I shouldn't have tried installing the .deb files myself it seems.
Appears that adding yogarine as a repo works just fine. However, the subclipse package only has SVNkit which doesn't play so well with svn 1.6 (errors on lack of format file). On the other hand, software update appears to work normally, so I guess I'll just install that by hand and not use the package.

Well, my packages are only tested on Jaunty. And it makes sense Subclipse breaks on Karmik since Jaunty still uses Subversion 1.5. ;-)

Also you shouldn't mix the different eclipse repo's out there. (Like eclipse-teams repo.) Eclipse's dependencies are pretty complicated, so it can easily go wrong. ;-) Anyway, eclipse-jdt depends on eclipse-platform OR eclipse-platform-sdk, so if it gives a conflict saying eclipse-platform-sdk can't be installed, it's probably because you have an old version of eclipse-platform installed. (I'll try to improve the dependencies in future packages...)

And when Karmik beta comes out I'll package Eclipse for Karmik as well...

Either way, thanks for trying out my packages. :-)

This bug was fixed in the package eclipse - 3.5.1-0~ubuntu1

---------------
eclipse (3.5.1-0~ubuntu1) karmic; urgency=low

  * Fix build failure on lpia.
  * For anything else kudos to the eclipse-team.

eclipse (3.5.1-0~ppa1) karmic; urgency=low

  * New upstream release. (LP: #123064)
    - Supports xulrunner-1.9.1 (Closes: #538871, #507536)
  * Converted build system to use eclipse-build. (Closes: #501533)
  * Removed obsolete linda overrides.
  * New maintainers. (Closes: #526489)
  * Added kdebase-bin as alternative to zenity (Closes: #537605)
  * Added missing "apt" plug-in for eclipse-jdt.
    (Closes: #403655, LP: #120610)
  * Added conflicts on the old eclipse-*-nls packages.
    (Closes: #538869)
  * Removed "builtin browser not supported"-warning; it did not
    work. (Closes: #403675, #402340)
  * Removed dependency on libtomcat5.5-java and liblucene-javadoc.
    (Closes: #530722, #537605)

 -- Matthias Klose <email address hidden> Tue, 06 Oct 2009 14:22:24 +0200

Sorry, but Eclipse CDT is at version 3.1

That's very old. It also should be upgraded, because it doesn't work with the newest platform.

gerstrong, eclipse-cdt is a separate package, there's bug 163739 for tracking its upgrade.

This will probably cause me to be scorned by the developers, though I honestly think they're doing really great job, well, for the most part, but my humble opinion is that being unable to provide an upgraded version of Eclipse with each new Eclipse release (and with that for each flavor - plug-in if you may), is at the very least sad.

Sure, a user can simply download the Eclipse environment from the website and use it as is (no installation needed), but it would be much more convenient and aligned with Ubuntu's motto of "it just works" (or is that no longer true?) if the user would have been able to install the package system wide using the package manager.

-- Liad W.

@Liad:
Packaging eclipse (or a plugin like eclipse-cdt) is not easy and consumes much time. We lack of time / manpower / skills / motivation to update eclipse-cdt, but we do not scorn our users. Updating the eclipse-cdt package is on our todo list, but we cannot promise, that it will be in karmic.

I am willing to review and upload a eclipse-cdt package if someone provides one.

I agree that it's a disappointing, but rather than play a blame game between volunteers within Ubuntu, Debian and Eclipse upstream, I'd rather see how we can address the problem of keeping eclipse closer in sync with upstream.

For starters, can anyone locate an eclipse roadmap for 3.6?