Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Meeting this Wednesday


As asked by Wayne, I updated the wiki page [1] with a recap about the Neon.3 problems. You can also read this recap following in this mail. If I missed something or if you have any comments, do not hesitate to answer to this mail and I will update the wiki before the meeting.

The Neon.3 update problems

The first symptom seen was that the Marketplace was not showing anymore in the Help menu in Neon.3. This seems to be due to a broken Orbit bundle that got into the Neon.3 release train repository: org.apache.httpcomponents.httpclient 4.5.2 which does not include the fluent API among others. This was introduced in Neon.3 by the Linux Tools project while upgrading the level of docker-client referenced the Oxygen M4 Orbit repo to get the httpclient.

This leads to two different points:
1. How to resolve right now the problem for Neon.3 ? What should we do to not anymore include the broken httpclient version in Neon.3? 2. What we should do to prevent this in our future releases: How Orbit dependencies should be managed?

== 1. How to resolve the problem for Neon.3 ? ==	

Several options for resolution were proposed on the mailing lists: 	

A. Respin against Oxygen Mx Orbit:
Jeff Jonhson proposed to respin Linux Tools based on the Oxygen M5 Orbit. This means distributing an unreleased version of a bundle.

B. Respin with the old version of httpclient:
Needs a Neon.3 Orbit Service Release containing only the 4.3.6 version of httpclient.
Needs a respin of Linux Tools to downgrade the version
But the other depending projects will not be updated and so the MPC will still not work for end user after the update.

C. Respin with the two versions	of httpclient:
Needs a Neon.3 Orbit Service Release containing the old 4.3.6 version and the fixed 4.5.2 version of httpclient. In theory the two httpclient bundles should be able to work side-by-side but we've seen a lot of wiring issues in Oxygen due to the mix.

D. Respin with only the new fixed version of httpclient:
Needs a Neon.3 Orbit Service Release containing only the 4.5.2 version of httpclient. Needs a respin of all the depending projects (Marketplace?) to update their ranges to the new 4.5.2 version minimum and force the update.

Service release builds for Orbit ?
One point was also about that service release builds for Orbit could be dropped in the future [2]. David Williams confirmed that in the past, there was always a maintenance build in Orbit when it was required.

== 2. How Orbit dependencies should be managed? ==

The fact is that many integration problems occurred during these last months in the SimRel.
Today we rely on the manual labor of our package maintainers.
From the Neon.3 problems, another discussion was initiated, I tried here to list the different proposed solutions:

A. Be sure of the Orbit milestones:
Roland Grunberg proposed to make sure that the Orbit milestones aren't harmful to begin with. For future release they would use separate branches. For Neon.3, they had no initial plan to release Orbit builds at the beginning which contribute to the previous exposed problem.

B. Check that 3rd party libs for SimRel come from Orbit

C. A tool to check consistency a kind of “SimRel consistency check”.

D. The individual projects should not be allowed to contribute Orbit bundles to SimRel: SimRel aggregator should pull in the required Orbit bundles alone.

E. Don't include Orbit bundles in project's features:
It is not necessary to include deps in features as p2 will install them. David Williams answered that this could make builds and installs non-deterministic especially with third party jars. This means that tests should be done based on the "project's repository" and others from the "Sim. Release repository".

F. Communication/synchronization effort is necessary to harmonize versions across feature.xml of all participating projects.

G. Have an integration test suite that SimRel projects can contribute their own test bundles to and that runs against the finished packages. These integration tests should cover basic user stories.

H. Requiring projects on the train to have proper package uses constraints for all their bundles.

Mélanie Bats
Eclipse Modeling Consultant
+33 5 34  57 16 29

25 Boulevard Victor Hugo - Colomiers - France


Back to the top