Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 339958

Summary:	Eliminate extra startup arguments required by p2 for Mac OS X
Product:	[Eclipse Project] Equinox	Reporter:	Patrick Paulin <patrick>
Component:	p2	Assignee:	P2 Inbox <equinox.p2-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	aniefer, jeffmcaffer, pascal, t-oberlies
Version:	unspecified
Target Milestone:	---
Hardware:	Macintosh
OS:	Mac OS X - Carbon (unsup.)
Whiteboard:

Description Patrick Paulin

2011-03-14 19:41:25 EDT

Build Identifier: 

An issue with p2 requires the addition of extra program arguments when running an RCP application as an OS X app bundle. The additional arguments are generated correctly by PDE. Something like:

-startup
../../../plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar
--launcher.library
../../../plugins/org.eclipse.equinox.launcher.cocoa.macosx_1.1.2.R36x_v20101019_1345

This solution is very brittle because of the hard-coded version numbers. It's also not currently supported by Maven Tycho. I asked for the addition of these arguments in Tycho:

https://issues.sonatype.org/browse/TYCHO-595

But the response is that these arguments shouldn't be required, and I agree. I don't know the internals of what's going on, but Pascal has referred to this in the past:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=275679#c4

It would be great if p2 could be modified so that these program arguments could be removed.



Reproducible: Always

Comment 1 DJ Houghton

2011-03-15 11:56:56 EDT

Pascal, is this related to bug 57349? Is the proposal to remove these arguments altogether? Will the executable function without them?

Comment 2 Jeff McAffer

2011-03-15 13:45:10 EDT

These are settings created and managed by p2 so the brittleness is not a factor.  If a new version of the launcher is installed, the values will be updated.  Take a look at the bundles.info file.  It is chalk full of version numbers.

Tycho's lack of support is a different topic.  Personally I think the response there was incorrect.

As DJ points out, This is largely an executable problem.  If we don't point to the jars then the C code has to hunt them down.  Since there is no control over what it might find you would then not be able to update/rollback with any control.

Comment 3 Andrew Niefer

2011-03-15 16:10:32 EDT

From the launcher's perspective, these arguments are only required if the launcher jar and fragment are in a non-standard location, or you want to use a version other than the highest version found on disk.

So, they are required when using a bundle pool that is not the install folder.  They are required when there are multiple versions available and we want to use the one that isn't the highest version.

From p2's perspective, I would say these arguments should always be specified to ensure you are running what the profile says you should be.

Comment 4 Patrick Paulin

2011-03-15 16:25:10 EDT

Is it possible to move these settings into the generated config.ini? This seems like low-level config info and it would be nice to keep the INI file as clean as possible for developers to use.

In any case, if we need these arguments perhaps someone more knowledgable than I could relay that to the Tycho team by commenting on the bug entry:

https://issues.sonatype.org/browse/TYCHO-595

Comment 5 Jeff McAffer

2011-03-15 17:13:26 EDT

the args need to be in the eclipse.ini so the executable can find them.  AFAIK the executable does not know anything about the config.ini.

I'm puzzled somewhat by the idea that these .ini files are developer resources.  The tooling takes great pains to hide this stuff.  The editors allow you to enter various values (program args, vm args, config settings) in a reasonable way and then renders those as config.ini and eclipse.ini entries.

As for Tycho, I suspect this is more an issue with the product publishing.  The work to make a p2 product publisher that can be used by Tycho is well underway in bug 331974.  Tobias is on the Tycho bug and working the product publishing bug.  The simple statement that these arguments are not optional (for the general case) should be enough.

So can this bug be closed?

Comment 6 Patrick Paulin

2011-03-15 18:07:02 EDT

Thanks for pointing me at bug 331974. If these arguments are getting added as part of that work, then of course there's no need for this defect. Marking as closed.

Comment 7 Jeff McAffer

2011-03-15 21:27:22 EDT

just to be clear, I don't know that the problems will be fixed by bug 331974.  Since one of the goals of that bug is to enable systems like tycho to build/publish correct product sturctures, I *suspect* that the problem will be addressed.

Comment 8 Patrick Paulin

2011-03-15 21:42:06 EDT

Understood. I've asked Tobias for confirmation over on the Tycho entry. We can always reopen this if we need to.

Comment 9 Tobias Oberlies

2011-03-17 05:30:18 EDT

(In reply to comment #3)
> From the launcher's perspective, these arguments are only required if the
> launcher jar and fragment are in a non-standard location, or you want to use a
> version other than the highest version found on disk.

(In reply to comment #2)
> These are settings created and managed by p2...

I think this is where the confusion comes from: for the launcher, the parameters are optional (in certain cases), but for p2 they have to be set or otherwise certain operations will fail.

I don't dispute that p2 should _write_ these parameters (and therefore also every build system that builds p2-enabled products), but I doubt that p2 should _read_ these parameters and fail if they are wrong/missing.

What is the p2 team's opinion on this?

Comment 10 Andrew Niefer

2011-03-17 11:19:17 EDT

(In reply to comment #9)
> I don't dispute that p2 should _write_ these parameters (and therefore also
> every build system that builds p2-enabled products), but I doubt that p2 should
> _read_ these parameters and fail if they are wrong/missing.
> 
> What is the p2 team's opinion on this?

In the launcher.jar Main class, if -configuration is not specified (and also perhaps -install), then the default config location is determined relative to the launcher.jar.

So -startup affects the location of the config folder.  p2 will need to read the -startup to find the config folder, if it is missing then the configuration location should be found relative to the executable.  If it is just wrong, then there will be problems in non-standard install shapes.