Re: [epp-dev] [cross-project-issues-dev] EPP packages and shared install

[Markus Knauer <mknauer@xxxxxxxxxxxxxxxxx>]

What I did so far...

* I upgraded the p2 director application that is used to build the packages from the p2 meta data to the Eclipse SDK build M20100902-1717. I assume this build is correct and includes the fixes for the underlying p2 problem.

* I added a dependency to the bundle "org.slf4j.api" in the common EPP feature that is included in *all* EPP packages. Or do we need to add more bundles - the bug reports weren't really clear to me. Are we sure, or better: how can we be sure/verify that this is the only dependency that needs to be added?
In any case it should be enough to add this bundle to the central EPP common feature and leave the package features as they are.

* I copied a p2 repository that includes the new dependencies to http://download.eclipse.org/technology/epp/packages/helios/SR1.227 - I will do some testing with this repo tomorrow but that shouldn't prevent you from testing the upgrade from the released Helios packages to the latest build. If you start with a Helios EPP package, add the above p2 repo and the repo URL of the /releases/maintenance you should be able to upgrade it to the latest SR1 bits.

* A new EPP package build is running with the above p2 repository as input (+ the /releases/maintenance repo). The output will be available at http://build.eclipse.org/technology/epp/epp_build/36/download/20100907-1829/ later today. How can we confirm that this build with an updated p2 director doesn't contain the configuration problem any more?

Here is a reference to the bug that describes all required changes and includes pointers to bugs and mailing list postings:

[Bug 322929] EPP configuration problem prevents shared installs from working

David had some really important points in his first mail. I tend to agree that we should leave this dependency in there for Helios SR2. I am sure there are users out there who are updating from Helios R to SR2 but in the end we can discuss this in January next year again because we should be able to see how many users downloaded the Helios R packages and how many of them updated to SR1 in the meantime.
For the Indigo release I think we should start with a clean version, that means I would prefer to remove those unnecessary dependencies.

Regards, Markus

On 7 September 2010 19:26, Steffen Pingel <steffen.pingel@xxxxxxxxxxx> wrote:

On Mon, Sep 6, 2010 at 5:19 PM, Pascal Rapicault <pascal@xxxxxxxxxxxx> wrote:

Sounds like adding the bundle to epp feature is best solution. But just to be explicit, here's a few more questions ...

Are you sure (I'd assume so) that it _has_ to be added to _each_ EPP package? For example, JEE EPP has org.apache.commons.logging in it already, and I seem to recall something about "one logger" had to be present? (But I've only skimmed the technical discussions ... and not sure exactly what bugs/issues are involved).

Despite the presence of the commons.logging in the packages, it should still be added. The bug has nothing to do with the loggers themselves but with the unexpected presence of those slf4j bundles that were being brought in by the resolver.

+1 for the adding the bundles. It would be good to build package with this change soon to leave sufficient time for testing. The slf4j bundles have caused breakage in Mylyn in the past. I believe this has been resolved by a change to the bundles but I would like to be sure that there are no unexpected side effects. 

Steffen

--
Steffen Pingel
Committer, http://eclipse.org/mylyn
Senior Developer, http://tasktop.com

_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epp-dev