Finding Eclipse on UNIX, Ubuntu default installation path
5,567 views
Skip to first unread message
Kennet
Nov 9, 2009, 7:42:59 AM11/9/09
to Project Lombok
EclipseFinder class method for reading Linux path:
<pre>
static List<String> findEclipseOnUnix(){
List<String> eclipses = new ArrayList<String>();
for(File dir: new File("/usr/bin/").listFiles()){ //this path is the
default path on Ubuntu
if (dir.getName().equals("eclipse")) {
eclipses.add(dir.toString());
}
}
if(eclipses.size() > 0){
return eclipses;
}
return null;
}
</pre>
should be added in findEclipses method
static List<String> findEclipses() {
...
case UNIX:
return findEclipseOnUnix();
}
}
<pre>
static List<String> findEclipseOnUnix(){
List<String> eclipses = new ArrayList<String>();
for(File dir: new File("/usr/bin/").listFiles()){ //this path is the
default path on Ubuntu
if (dir.getName().equals("eclipse")) {
eclipses.add(dir.toString());
}
}
if(eclipses.size() > 0){
return eclipses;
}
return null;
}
</pre>
should be added in findEclipses method
static List<String> findEclipses() {
...
case UNIX:
return findEclipseOnUnix();
}
}
Reinier Zwitserloot
Nov 9, 2009, 8:50:14 AM11/9/09
to Project Lombok
Hey Kennet,
According to this:
http://packages.debian.org/lenny/i386/eclipse/filelist
/usr/bin/eclipse is an executable and not a directory, and there's
also no eclipse.ini whatsoever, which is problematic, because that's
the one that the lombok installer needs to find. Presumably some post
install script creates it, or possibly eclipse can run without an ini
file. The lombok installer will need to know where to find (or,
perhaps, create) eclipse.ini.
According to this:
http://packages.debian.org/lenny/i386/eclipse/filelist
/usr/bin/eclipse is an executable and not a directory, and there's
also no eclipse.ini whatsoever, which is problematic, because that's
the one that the lombok installer needs to find. Presumably some post
install script creates it, or possibly eclipse can run without an ini
file. The lombok installer will need to know where to find (or,
perhaps, create) eclipse.ini.
Kennet
Nov 9, 2009, 9:16:09 AM11/9/09
to Project Lombok
Hi,
I've also seen my mistake. Seems like the eclipse.ini is located in
the /usr/lib/eclipse directory.
I'll have a look at it again to see if I can figure out a solution for
Ubuntu user using apt installation.
/Kennet
I've also seen my mistake. Seems like the eclipse.ini is located in
the /usr/lib/eclipse directory.
I'll have a look at it again to see if I can figure out a solution for
Ubuntu user using apt installation.
/Kennet
Kennet
Nov 9, 2009, 9:29:57 AM11/9/09
to Project Lombok
Ho about changing the default path in the suggested method
findEclipseOnUnix to /usr/lib/eclipse
findEclipseOnUnix to /usr/lib/eclipse
Reinier Zwitserloot
Nov 9, 2009, 9:33:39 AM11/9/09
to Project Lombok
well, at the very least we can have a quick look in /usr/lib/eclipse
and see if there's an eclipse.ini there, and use it.
The much bigger concern is how the LSB view (of splitting files for a
given app across a bunch of directories, such as in this case, across /
usr/bin, and /usr/lib) is totally different from how the downloadable
eclipse package (from eclipse.org) works, which bundles all files into
a single directory.
The installer needs to do this:
1. It needs to find eclipse.ini, and edit references to lombok.jar
into it.
2. It needs to put lombok.jar in a suitable place.
3. It needs to hide these details from the end user, who probably
doesn't even know there's such a thing as eclipse.ini, and that it
might be hidden somewhere in the insides of the eclipse install.
Right now, the installer accomplishes these goals by looking for the
eclipse executable, knowing that it can go from there to eclipse.ini
easily: It's either right there in the same dir, or it's in
Eclipse.app/MacOS/Resources relative to the directory that the
executable is in. It then drops lombok.jar in the same directory as
eclipse.ini and makes the edit. Furthermore, to fully hide this
process, whenever the user tries to add an eclipse by hand using the
'add eclipse...' button, the user is supposed to navigate to either
the executable or a directory containing the executable. The installer
then translates the path to the executable to a path to the ini, which
is what the installer actually works with.
This entire process is just going to fail on an apt-getted eclipse,
because eclipse.ini isn't anywhere near eclipse the executable. Also,
the act of pointing the installer at a custom eclipse is going to be
similarly complex. Fortunately, the text in the "what do I do?" link
in the installer should be obvious enough to a seasoned linux user,
but this is clearly not an optimum solution for installing lombok on
apt-getted eclipse installs.
I'm a bit stuck about how to figure out a better way. How's this:
1. We accept that this unclustered installation process is unique to
package managers, which will ALWAYS stick both the eclipse executable
and the eclipse.ini file in a single, unchanging location. Therefore,
either (A) the installer knows how to handle this situation and can
thus detect these files and pre-populate the eclipse installations
list with them, or (B) it doesn't know how to install there at all, so
trying to point it out by hand with the 'add eclipse...' button is
never going to work right.
Conclusion: The 'add eclipse...' button will never have to deal with
this situation. I could, for completeness' sake, let the add eclipse
feature be compatible with pointing at your actual eclipse.ini file
(or, in fact, at any file named 'eclipse.ini'). The installer doesn't
actually need to know or care about the executable, as it doesn't
modify that.
2. We hardcode the notion that if /usr/bin/eclipse is a lone
executable that ISNT a softlink, then eclipse.ini needs to be at /usr/
lib/eclipse/eclipse.ini, and if it isn't there, /usr/bin/eclipse can
be discarded as a fixable eclipse. If it IS a softlink, we follow the
softlink and continue as if that's a non-aptget style eclipse install
(with all files bundled into one dir instead of smeared across the LSB
dirs).
In order to make this scheme sufficiently robust, we'll have to check
the exact installation directories of every major linux distro around.
Presumably all debianesque distros will all be using the debian
package, and thus will put the executable in /usr/bin, and the ini
file in /usr/lib/eclipse, but then we still have to check yum-based
distros (redhat, CentOS, Fedora, Mandriva?, olpc [though I doubt
eclipse runs on an XO-1!]), YaST/Zypper (SUSE), whatever slackware
does, and whatever Gentoo does.
For a standards project, the LSB sure is a pain in my ass that I wish
would just go away or actually, you know, standardize on something.
Could be I don't get it, but the only proper LSB distribution model
for eclipse that I can see is to dump the entire eclipse install into /
usr/share/eclipse, then softlink /usr/share/eclipse/eclipse into /usr/
bin, and that's that.
I've got various debian variants to test out at home, but I don't have
any other distro, so it's going to take quite a bit of trouble
collating all this data. Ugh.
and see if there's an eclipse.ini there, and use it.
The much bigger concern is how the LSB view (of splitting files for a
given app across a bunch of directories, such as in this case, across /
usr/bin, and /usr/lib) is totally different from how the downloadable
eclipse package (from eclipse.org) works, which bundles all files into
a single directory.
The installer needs to do this:
1. It needs to find eclipse.ini, and edit references to lombok.jar
into it.
2. It needs to put lombok.jar in a suitable place.
3. It needs to hide these details from the end user, who probably
doesn't even know there's such a thing as eclipse.ini, and that it
might be hidden somewhere in the insides of the eclipse install.
Right now, the installer accomplishes these goals by looking for the
eclipse executable, knowing that it can go from there to eclipse.ini
easily: It's either right there in the same dir, or it's in
Eclipse.app/MacOS/Resources relative to the directory that the
executable is in. It then drops lombok.jar in the same directory as
eclipse.ini and makes the edit. Furthermore, to fully hide this
process, whenever the user tries to add an eclipse by hand using the
'add eclipse...' button, the user is supposed to navigate to either
the executable or a directory containing the executable. The installer
then translates the path to the executable to a path to the ini, which
is what the installer actually works with.
This entire process is just going to fail on an apt-getted eclipse,
because eclipse.ini isn't anywhere near eclipse the executable. Also,
the act of pointing the installer at a custom eclipse is going to be
similarly complex. Fortunately, the text in the "what do I do?" link
in the installer should be obvious enough to a seasoned linux user,
but this is clearly not an optimum solution for installing lombok on
apt-getted eclipse installs.
I'm a bit stuck about how to figure out a better way. How's this:
1. We accept that this unclustered installation process is unique to
package managers, which will ALWAYS stick both the eclipse executable
and the eclipse.ini file in a single, unchanging location. Therefore,
either (A) the installer knows how to handle this situation and can
thus detect these files and pre-populate the eclipse installations
list with them, or (B) it doesn't know how to install there at all, so
trying to point it out by hand with the 'add eclipse...' button is
never going to work right.
Conclusion: The 'add eclipse...' button will never have to deal with
this situation. I could, for completeness' sake, let the add eclipse
feature be compatible with pointing at your actual eclipse.ini file
(or, in fact, at any file named 'eclipse.ini'). The installer doesn't
actually need to know or care about the executable, as it doesn't
modify that.
2. We hardcode the notion that if /usr/bin/eclipse is a lone
executable that ISNT a softlink, then eclipse.ini needs to be at /usr/
lib/eclipse/eclipse.ini, and if it isn't there, /usr/bin/eclipse can
be discarded as a fixable eclipse. If it IS a softlink, we follow the
softlink and continue as if that's a non-aptget style eclipse install
(with all files bundled into one dir instead of smeared across the LSB
dirs).
In order to make this scheme sufficiently robust, we'll have to check
the exact installation directories of every major linux distro around.
Presumably all debianesque distros will all be using the debian
package, and thus will put the executable in /usr/bin, and the ini
file in /usr/lib/eclipse, but then we still have to check yum-based
distros (redhat, CentOS, Fedora, Mandriva?, olpc [though I doubt
eclipse runs on an XO-1!]), YaST/Zypper (SUSE), whatever slackware
does, and whatever Gentoo does.
For a standards project, the LSB sure is a pain in my ass that I wish
would just go away or actually, you know, standardize on something.
Could be I don't get it, but the only proper LSB distribution model
for eclipse that I can see is to dump the entire eclipse install into /
usr/share/eclipse, then softlink /usr/share/eclipse/eclipse into /usr/
bin, and that's that.
I've got various debian variants to test out at home, but I don't have
any other distro, so it's going to take quite a bit of trouble
collating all this data. Ugh.
David Goodenough
Nov 9, 2009, 9:51:01 AM11/9/09
to Project Lombok
Well the only problem with that is that on Debian the latest version
(in unstable) is 3.4.1, which is a bit elderly. Personally I download
direct from Eclipse.org and I install in /usr/local/share/<eclipse-
release>. However whichever way you do it I think I am right in
saying that eclipse.ini is always in the directory that is the eclipse
root and also contains an (not necessarily the) eclipse binary. So
looking in /usr for all eclipse.ini files will take a while, but
should find what you want. Although I seem to recall that on rpm
based systems the default location is /opt (but it is while since I
used Eclipse in one of those). But at least on my machine searching /
opt as well would not a negligable overhead as it is does not exist.
On the other hand I realise that hand installing means its up to me,
and I have no problems with the current version.
David
(in unstable) is 3.4.1, which is a bit elderly. Personally I download
direct from Eclipse.org and I install in /usr/local/share/<eclipse-
release>. However whichever way you do it I think I am right in
saying that eclipse.ini is always in the directory that is the eclipse
root and also contains an (not necessarily the) eclipse binary. So
looking in /usr for all eclipse.ini files will take a while, but
should find what you want. Although I seem to recall that on rpm
based systems the default location is /opt (but it is while since I
used Eclipse in one of those). But at least on my machine searching /
opt as well would not a negligable overhead as it is does not exist.
On the other hand I realise that hand installing means its up to me,
and I have no problems with the current version.
David
Kennet Svanberg
Nov 9, 2009, 9:58:16 AM11/9/09
to project...@googlegroups.com
And I thought it was such a quick fix. I guess that to be able to copy files you need to run the installer as root if the files are located in this (/usr/lib/eclipse) path.
The reason why I started to look at it is/was? a bug in gtk that also affected Lombok. https://bugs.launchpad.net/gtk/+bug/442078 which appeared after installing regular updates in Ubuntu.
When running eclipse, the dialog buttons "didn't work". A workaround was to manually set a variable at the terminal:
export GDK_NATIVE_WINDOWS=1
I did that and eclipse did work allright, but the JFileChooser dialog in lombok messed up the whole screen making it impossible to install Lombok. I started looking at it to see if I could run it from the command prompt (without gui). After a while I copied the lombok related lines from an old eclipse.ini file to the new and copied the jars manually.
Now after installing eclipse using apt, eclipse works again and the lombok-installer also works. So I don't really know anymore what was the cause.
Kennet Svanberg
----- Ursprungligt meddelande ----
Från: Reinier Zwitserloot <rein...@gmail.com>
Till: Project Lombok <project...@googlegroups.com>
Skickat: måndag 9 november 2009 15:33:39
Ämne: [project lombok] Re: Finding Eclipse on UNIX, Ubuntu default installation path
__________________________________________________________
Låna pengar utan säkerhet. Jämför vilkor online hos Kelkoo.
http://www.kelkoo.se/c-100390123-lan-utan-sakerhet.html?partnerId=96915014
The reason why I started to look at it is/was? a bug in gtk that also affected Lombok. https://bugs.launchpad.net/gtk/+bug/442078 which appeared after installing regular updates in Ubuntu.
When running eclipse, the dialog buttons "didn't work". A workaround was to manually set a variable at the terminal:
export GDK_NATIVE_WINDOWS=1
I did that and eclipse did work allright, but the JFileChooser dialog in lombok messed up the whole screen making it impossible to install Lombok. I started looking at it to see if I could run it from the command prompt (without gui). After a while I copied the lombok related lines from an old eclipse.ini file to the new and copied the jars manually.
Now after installing eclipse using apt, eclipse works again and the lombok-installer also works. So I don't really know anymore what was the cause.
Kennet Svanberg
----- Ursprungligt meddelande ----
Från: Reinier Zwitserloot <rein...@gmail.com>
Till: Project Lombok <project...@googlegroups.com>
Skickat: måndag 9 november 2009 15:33:39
Ämne: [project lombok] Re: Finding Eclipse on UNIX, Ubuntu default installation path
Låna pengar utan säkerhet. Jämför vilkor online hos Kelkoo.
http://www.kelkoo.se/c-100390123-lan-utan-sakerhet.html?partnerId=96915014
Reinier Zwitserloot
Nov 9, 2009, 5:14:29 PM11/9/09
to Project Lombok
Allright, turns out some smart programming has made the installer
quite robust, or, at least, I think so.
v0.9.1 is out, which pretty much only features updates to the
installer. It should install on linux, pretty much no matter how you
installed your eclipse.
Give it a try!
On Nov 9, 3:58 pm, Kennet Svanberg <k_svanb...@yahoo.se> wrote:
> And I thought it was such a quick fix. I guess that to be able to copy files you need to run the installer as root if the files are located in this (/usr/lib/eclipse) path.
>
> The reason why I started to look at it is/was? a bug in gtk that also affected Lombok.https://bugs.launchpad.net/gtk/+bug/442078which appeared after installing regular updates in Ubuntu.
> Låna pengar utan säkerhet. Jämför vilkor online hos Kelkoo.http://www.kelkoo.se/c-100390123-lan-utan-sakerhet.html?partnerId=969...
quite robust, or, at least, I think so.
v0.9.1 is out, which pretty much only features updates to the
installer. It should install on linux, pretty much no matter how you
installed your eclipse.
Give it a try!
On Nov 9, 3:58 pm, Kennet Svanberg <k_svanb...@yahoo.se> wrote:
> And I thought it was such a quick fix. I guess that to be able to copy files you need to run the installer as root if the files are located in this (/usr/lib/eclipse) path.
>
>
> When running eclipse, the dialog buttons "didn't work". A workaround was to manually set a variable at the terminal:
>
> export GDK_NATIVE_WINDOWS=1
>
> I did that and eclipse did work allright, but the JFileChooser dialog in lombok messed up the whole screen making it impossible to install Lombok. I started looking at it to see if I could run it from the command prompt (without gui). After a while I copied the lombok related lines from an old eclipse.ini file to the new and copied the jars manually.
>
> Now after installing eclipse using apt, eclipse works again and the lombok-installer also works. So I don't really know anymore what was the cause.
>
> Kennet Svanberg
>
> ----- Ursprungligt meddelande ----
> Från: Reinier Zwitserloot <reini...@gmail.com>
> When running eclipse, the dialog buttons "didn't work". A workaround was to manually set a variable at the terminal:
>
> export GDK_NATIVE_WINDOWS=1
>
> I did that and eclipse did work allright, but the JFileChooser dialog in lombok messed up the whole screen making it impossible to install Lombok. I started looking at it to see if I could run it from the command prompt (without gui). After a while I copied the lombok related lines from an old eclipse.ini file to the new and copied the jars manually.
>
> Now after installing eclipse using apt, eclipse works again and the lombok-installer also works. So I don't really know anymore what was the cause.
>
> Kennet Svanberg
>
> ----- Ursprungligt meddelande ----
Kennet Svanberg
Nov 10, 2009, 3:05:07 AM11/10/09
to project...@googlegroups.com
Brilliant, works perfectly!
Thanks a lot!
Kennet
----- Ursprungligt meddelande ----
Från: Reinier Zwitserloot <rein...@gmail.com>
Till: Project Lombok <project...@googlegroups.com>
Skickat: måndag 9 november 2009 23:14:29
http://www.kelkoo.se/c-100390123-lan-utan-sakerhet.html?partnerId=96915014
Thanks a lot!
Kennet
----- Ursprungligt meddelande ----
Från: Reinier Zwitserloot <rein...@gmail.com>
Till: Project Lombok <project...@googlegroups.com>
Skickat: måndag 9 november 2009 23:14:29
Reply all
Reply to author
Forward
0 new messages