Bug 334519

Comment 1 Shenol Yousouf 2011-01-17 11:25:59 EST

As we would want to deliver a patch, let's first discuss how to make the product publisher application read the profile file from an external location. Passing it as a configuration parameter (just like the way the product file is passed with "-productFile", etc.) seems to be the most natural approach to me.

Then, the patch will follow the usual pattern for customizing the publishing process with new advice and advice file types for the JRE actions.

Comment 2 Jeff McAffer 2011-01-17 14:45:12 EST

For the package versions being ignored the fix seems pretty straightforward.  For some reason the JREAction is creating capabilities with null versions where the version should come from the profile being used.

For identifying the JRE profile, ideally the JREAction would not be parsing these files at all but rather would take some JRE "advice" that would figure out what packages etc the JRE provides.  Then the JREAction would know simply how to create the various IUs and artifacts.

Some things to note.  JREAction currently has two constructors, one that points to an actual JRE and another that points to a profile. These are quite different things.  If you use the first, the JRE is expected to have a profile file co-located with the JRE.  Also, if this option is used, the JRE itself is packaged up and published. Also, as pointed out, if the profile is identified, only one of the profiles from the publisher itself can be used.

I propose that both of these constructors be removed/deprecated and the required information be captured in a IJREAdvice that would answer questions like 
- getName()
- getSystemPackages()
- getVersion()
- getLocation()
- ...

The JREAction should process all available instances of IJREAdvice and publish a separate JRE IU set for each.

Then publishing applications that want to have JREs can add the required advice objects prior to running the publisher.  how they do that could be using -jre or some such.  The JREAdvice creation workflow should be simple enough that it is easily incorporated into various applications without too much duplicate/complicated code.

Note also that the profile to use and the JRE location should not be mutually exclusive.  The current code simply finds the first .profile file in the JRE location and uses that.  Clearly that has significant limitations.  So one should be able to publish a particular JRE using a particular profile.  This may mean that the applications have to have two arguments, one for the location and one for the profile to use.

Comment 3 Tobias Oberlies 2011-02-13 07:17:50 EST

Assuming that this issue is fixed, where would you know the package versions from? Is this specified anywhere?

Plain Java has a mechanism for documenting package version (http://download.oracle.com/javase/1.4.2/docs/api/java/lang/Package.html), but as far I know, the Oracle JDK doesn't use it...

Comment 4 Shenol Yousouf 2011-02-14 07:16:20 EST

I am not aware of any automated procedure for extracting/calculating the package versions and building the respective .profile files. OSGi bundle and publisher bundle seem to include them statically in their build. The same approach is valid for other products too such as the Virgo application server, for example.

Comment 5 Pascal Rapicault 2011-05-17 19:51:50 EDT

*** Bug 311861 has been marked as a duplicate of this bug. ***

Comment 6 Shenol Yousouf 2011-12-18 08:01:38 EST

The recent discussions around bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=346174 have rebooted the topic how to improve the process of JRE publishing, done during product publishing.

The purpose of this comment is to elicit some feedback on the proposals for the patch, laid out below, before starting the actual implementation, hopefully, in a short period of time.

To summarize once again, the JREAction in product publisher offers two options to specify the external input, on which the JRE IU content is based:
- the name of a java profile file, packaged in the o.e.e.p2.publisher bundle;
- a file location to a real JRE folder, containing a java profile file.
In the latter case, the JRE folder is zipped and uploaded as a binary artifact into the p2 repository of the product.

Product publisher utilizes none of these options which leads to the awkward situation that one and the same JRE unit, based on one of the profiles (JavaSE-1.6), included in the bundle, is created. The goal of the current bug report is to expose some means in the product publisher application to create JRE units from user-specified files.

My proposal is to introduce a new parameter for the product publisher application, pointing to an actual JRE location. Given the current implementation, the fix should be straightforward and link the product publishing flow with the JREAction by initializing it with the provided location.

I would even go one step further to suggest that the JRE location parameter will allow not only values that are a JRE folder but also a simple java profile file. The two cases can be easily distinguished in the code and the case of an external profile file should replace the use of the fixed profile files inside the publisher bundle.

For now, I wouldn't touch the current logic of picking up a bundled profile if the new parameter is not specified during publishing, mainly for backward compatibility reasons. If there is a demand, we can later think about another patch which gives the users choice which bundled profile to use directly from the publisher application's options.

Of course, these proposals do not solve the more general problem how to ensure that the published JRE unit will comply with the actual environment, in which the product is installed. This is the focus of the referred bug 346174. However, I tend to believe that giving the users an external control over the creation of the JRE unit through the publisher application parameters would be a substantial improvement, compared to the current situation. This is even more true in the context that the users will be able to publish and ship a real JRE along with their product, thus making the installation of the product complete with the java runtime environment, in which it has been validated to run (although I admit that this does not ensure that the JRE itself will be capable to run on the provisioned system, but the product vendors can find a way to work around it by, for example, offering different distributions for different systems and so on :)).

Comment 7 Pascal Rapicault 2011-12-19 23:26:49 EST

I agree with the directions being proposed here.

Comment 8 Shenol Yousouf 2012-01-07 08:53:24 EST

Created attachment 209166 [details]
Patch for product publisher + tests

Close to the anniversary from reporting this bug, here is the proposed patch, according to the agreement above. The changes are as follows:
-	Added a new “jreLocation” parameter for product publisher application, the value of which is a file path:
o	If the path points to a local file, it is assumed to be a java profile and is loaded as such. Note that the recent fix for bug 364221 causes the publishing to be successful even if the file is not a valid properties file because it allows to publish a JRE unit without exported java packages.
o	If the path points to a folder, it is assumed to be a folder of a JRE. It is searched for a java profile to load and the folder is zipped and published as a binary artifact into the p2 repository. This is an old behavior of JREAction for JRE folders; now it is simply exposed in the publisher application.
o	If the path points to a non-existing location, an IllegalArgumentException is thrown.
-	The versions of packages, described in the java profile, now are also published (previously, they were just ignored and replaced with 0.0.0).
-	New test cases for ProductAction and JREAction, corresponding to the changes.

Comment 9 Tobias Oberlies 2012-02-21 03:44:45 EST

Thanks for the good patch; submitted as b6e3036.

I did a very small change to the JREActionTest, but this was only due to a matter of personal taste: rather than asserting somewhere hidden in a helper method, I prefer having the assertions better visible in the actual test method. I hope you don't mind that modification to your change.

Comment 10 Mickael Istria 2018-02-21 06:41:31 EST

*** Bug 267445 has been marked as a duplicate of this bug. ***