[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] Equinox Launchers in 3.3 M5.
|
Well, it's not as bad as you'd think.
If you're launching Eclipse from a shell script, you can just find the
equinox jar and use that instead of startup.jar.
cp=$(find $eclipseinstallDir -name "org.eclipse.equinox_*.jar" | sort
| tail -1);
/opt/java50/bin/java -cp $cp org.eclipse.equinox.launcher.Main ...
If you're launching Eclipse from an ant script, you can use a mapper
or simple copy/move to find the equinox jar and rename it so it's more
accessible.
<copy tofile="${install}/eclipse/plugins/org.eclipse.equinox.launcher.jar">
<fileset dir="${install}/eclipse/plugins"
includes="**/org.eclipse.equinox.launcher_*.jar"/>
</copy>
<java classpath="${install}/eclipse/plugins/org.eclipse.equinox.launcher.jar"
.../>
If you're launching Eclipse from a cmd or bat script on Windows...
well, you're on your own there. ;-)
Personally, I agree with you - a simple startup.jar that is nothing
more than an org.eclipse.core.launcher.Main that calls into the right
equinox jar and starts up org.eclipse.equinox.launcher.Main would make
the transition much easier for existing users and embedded clients.
Actually, if you look in /cvsroot/eclipse/equinox-incubator/ you'll
see that there's already a core.launcher.Main that does that, but it
seems it hasn't escaped incubation and made it into production code.
Yet?
If migrating to the new method is too onerous, I'd suggest opening a
bug and asking the Equinox team to comment on the feasibility of what
you and I've outlined. I'm not on that team so I'm not at liberty to
give them work, nor am I on the platform releng team so I don't know
what's involved in adding a startup.jar back into the root, or
ensuring it can find the latest equinox jar, regardless of its plugin
version / name. My job is just to make sure the 13+ builds I'm
responsible for will run with whatever Eclipse can dish out, so I
don't mind revising scripts every year around this time to support the
latest and greatest. That said, if enough people agree, this issue
could be this year's M5a. ;-)
Cheers,
--
Nick Boldt :: Release Engineer, IBM Toronto Lab
Eclipse Modeling :: http://www.eclipse.org/modeling
http://wiki.eclipse.org/index.php/User:Nickb
On 2/10/07, Thomas Hallgren <thomas@xxxxxxx> wrote:
Hi Nick,
and thanks. To be honest, this looks horrible. Would it be possible for
the equinox team to provide a unified way of launching using pure Java?
I.e. reinstate the startup.jar as a very thin wrapper who's
responsibility is to find the real launcher jar. Perhaps name it
'eclipse.jar'? In any case, put it in the root. Not everyone loves an
executable and shared libraries.
Or perhaps I'm missing something. Is there some other unified way of
booting the OSGi framework that doesn't involve finding a jar with some
specific version and copy that to the root?
Kind Regards,
Thomas Hallgren
Nick Boldt wrote:
> Thomas:
>
> On behalf of the equinox guys, let me give you my "end-user" experience.
>
>> * Is it still possible to run pure java when running headless? We
>> really want to avoid using shared libraries.
>
> See bugs https://bugs.eclipse.org/bugs/show_bug.cgi?id=170831 and
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=171756#c13 for some
> progress made along these lines. The short answer for running headless
> w/ <java jar="..." .../> instead of <exec
> executable="${eclipse-home}/eclipse" .../> is that it's possible, as
> discussed here:
>
> http://wiki.eclipse.org/index.php/PDE_JUnit_Testing
>
>> * Is the new java launcher transparent to options? I.e. does it
>> forward everything that it doesn't recognize? Does it propagate
>> options that it does recognize and act on or are they swallowed?
>
> I saw at least one example where an old commandline flag, "-noupdate",
> is no longer supported and causes problems when running with the new
> launcher jar. Links regarding what's supported and what's not are in
> the wiki and bug 170831.
>
> Hope that helps!
