Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] conflicting dependencies to Orbit

You say "the bundles in the CDO update site depend on a [Orbit] bundle with a specific version". Wouldn't that happen through a Manifest.MF?

I don't understand the exact mechanism, but as I said, p2 seems to tighten dependency ranges.

In the CDO update site, I can see this (in downloads/modeling/emf/cdo/updates/4.0/4.0-M4-S201012140905/content.jar) :
<unit id='org.eclipse.net4j.db.derby.feature.group' version='4.0.0.v20101112-1636' singleton='false'>
    ....
    <required namespace='org.eclipse.equinox.p2.iu' name='org.apache.derby' range='[10.5.1.1_201010140907,10.5.1.1_201010140907]'/>

The strict dependency was not specified in the Manifest.MF, but it was added by p2.


On Fri, Dec 17, 2010 at 10:01 AM, Eike Stepper <stepper@xxxxxxxxxx> wrote:
Am 17.12.2010 09:30, schrieb Nicolas Bros:

Hello Eike,

Actually, I think the problem is not with the dependency in the Manifest.MF.
It is with the p2 update site. I have noticed that when p2 builds an update site, it restricts the dependencies to the versions of the bundles that were used for the build that produced this update site.
So, I believe in this case the CDO build for M4 was referencing the Orbit update site from M3.
Then, when I'm trying to build MoDisco with only the M4 Orbit update site referenced, it fails because the latest versions of the bundles in the CDO update site depend on a bundle with a specific version only found in the M3 Orbit update site.
You say "the bundles in the CDO update site depend on a [Orbit] bundle with a specific version". Wouldn't that happen through a Manifest.MF?

But in fact I can find a feature.xml in our M4 build with a build-generated version for Derby:

<plugin
        id="org.apache.derby"
        version="10.5.1.1_201010140907"
        unpack="false"/>




In order to make MoDisco build successfully without removing the dependency to CDO, I had to provide both the M3 and M4 Orbit update sites to the build.
This shouldn't cause any problems as long as the Orbit bundles from M3 and M4 are binary compatible.
But I would prefer to be able to provide a single update site, in order to be certain that MoDisco works with the latest version of Indigo that is being built.
Understandeable. I wonder why Orbit doesn't provide a single composite repository (like other good projects) so that we don't have to tackle with repo locations in addition to version ranges all the time?

On Thu, Dec 16, 2010 at 9:37 PM, Eike Stepper <stepper@xxxxxxxxxx <mailto:stepper@xxxxxxxxxx>> wrote:

   Hi Nicolas,

   I checked our (CDO's) manifests and wherever we depend on Derby, we do it by:

      org.apache.derby.jdbc;version="[10.0.0,11.0.0)"

   Cheers
   /Eike

   ----
   http://www.esc-net.de
   http://thegordian.blogspot.com
   http://twitter.com/eikestepper


   Am 14.12.2010 17:01, schrieb Nicolas Bros:

       Hi,

       While trying to build MoDisco for Indigo M4, I found that org.eclipse.net4j.db.derby.feature.group on the CDO update site referenced by the Indigo build model depends on org.apache.derby[10.5.1.1_201010140907,10.5.1.1_201010140907], which is in Orbit S20101014084557 <http://download.eclipse.org/tools/orbit/downloads/drops/S20101014084557/>.
       But other features, such as org.eclipse.birt.chart, depend on features in Orbit S20101204061544 <http://download.eclipse.org/tools/orbit/downloads/drops/S20101204061544/>, which is the latest version, and the one that should be used I believe.

       Due to the strict dependency range, both dependencies can't be satisfied at the same time.

       --         Nicolas Bros
       R&D
       tel: 06 75 09 19 88
       nbros@xxxxxxxxxxxxxxxx <mailto:nbros@xxxxxxxxxxxxxxxx> <mailto:nbros@xxxxxxxxxxxxxxxx <mailto:nbros@xxxxxxxxxxxxxxxx>>
       nbros.mia@xxxxxxxxx <mailto:nbros.mia@xxxxxxxxx> <mailto:nbros.mia@xxxxxxxxx <mailto:nbros.mia@xxxxxxxxx>>


       Mia-Software, 410 clos de la Courtine
       93160 Noisy-le-Grand
       http://www.mia-software.com
       .: model driven agility :.


       _______________________________________________
       cross-project-issues-dev mailing list
       cross-project-issues-dev@xxxxxxxxxxx <mailto:cross-project-issues-dev@xxxxxxxxxxx>

       https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


   _______________________________________________
   cross-project-issues-dev mailing list
   cross-project-issues-dev@xxxxxxxxxxx <mailto:cross-project-issues-dev@xxxxxxxxxxx>

   https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev




--
Nicolas Bros
R&D
tel: 06 75 09 19 88
nbros@xxxxxxxxxxxxxxxx <mailto:nbros@xxxxxxxxxxxxxxxx>
nbros.mia@xxxxxxxxx <mailto:nbros.mia@xxxxxxxxx>
Mia-Software, 410 clos de la Courtine
93160 Noisy-le-Grand
http://www.mia-software.com
.: model driven agility :.


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



--
Nicolas Bros
R&D
tel: 06 75 09 19 88
nbros@xxxxxxxxxxxxxxxx
nbros.mia@xxxxxxxxx
Mia-Software, 410 clos de la Courtine
93160 Noisy-le-Grand
http://www.mia-software.com
.: model driven agility :.

Back to the top