Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] error with org.apache.derby jar.pack.gz expected by CDO


I consulted the powers that be (Janet/Wayne/Mike) and asked this question:

Suppose that project Y depends on project X and both have a p2 repository for their build results and project Y's repository composes X's repository (in the virtual sense of how p2 supports it via a link), is project Y redistributing project X and all project X's dependencies?  Does project Y therefore have to track all CQs filed by project X?  (Of course Y might depend on only a subset of X's features and that subset might not depend on the CQ's aspects.)

I got

1.       Yes
2.       No

You need a CQ if you make direct use of a library. An import statement in Java source, or a bundle reference or package reference in a manifest file are examples of a direct reference. Indirect references through another project's code do not require a CQ.

And finally

I agree.   While there’s a benefit to increased tracking, I’d be concerned that extending it beyond what we contemplate today would be an unreasonable burden on the Projects.

So unless MoDisco directly depends on these Orbit bundles (as outlined in the second answer), it doesn't require a CQ for everything for which CDO required a CQ.


On Thu, Sep 8, 2011 at 5:52 AM, David M Williams <david_williams@xxxxxxxxxx> wrote:
I'm not sure I understand all the issues ... but, will answer best as I can ... then maybe you could ask more questions.

> ... Should CDO avoid repacking the jars from Orbit?

do you literally mean "repack"? or pack? In generally, it is best (maybe essential) to avoid "repacking" (conditioning) jars, if they already have been, especially if already signed.
But, yes, projects are expected to pack (pack200) files they get and redistribute from Orbit.

> Should MoDisco build using the Orbit jars from the CDO update site?

Yes, if MoDisco needs it (and has a CQ for it :). If you need it independently of CDO then you should likely get, package, and distribute it yourself. If you need it just because CDO does (and you need CDO), then it is fine to get from CDOs distribution. (You still need a CQ, in both cases, if you distribute it).  

> What about when the same Orbit jar is required by several different projects?

This is pretty common ... contents should be exactly the same.

It almost sounds like your metadata is being "blended" so that what is a packed jar on CDOs site is expected to be a packed jar everywhere, but I do no think you can make assumptions like that ... it would vary repo by repo.

So, hope these answers give some ideas of what to look at, or what to ask next. Apologies if I am missing your point.

From:        Nicolas Bros <nbros@xxxxxxxxxxxxxxxx>
To:        cross-project-issues-dev <cross-project-issues-dev@xxxxxxxxxxx>
Date:        09/08/2011 04:53 AM
Subject:        [cross-project-issues-dev] error with org.apache.derby jar.pack.gz        expected by CDO
Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx


The MoDisco build for Indigo SR1 RC3 is suddenly getting an error when materializing the target platform with Buckminster:

Indeed, there is no ".jar.pack.gz" in Orbit. There are only simple ".jar" there. But p2 is supposed to fallback to the jar when there is no jar.pack.gz.

But MoDisco depends on CDO which depends on org.apache.derby, and in the CDO update site that is referenced by our build, in <downloads>/modeling/emf/cdo/drops/S20110907-0210/artifacts.jar, I found :

    <artifact classifier='osgi.bundle' id='org.apache.derby' version=''>
      <processing size='1'>
        <step id='org.eclipse.equinox.p2.processing.Pack200Unpacker' required='true'/>
      <properties size='3'>
        <property name='artifact.size' value='4839649'/>
        <property name='download.size' value='1879328'/>
        <property name='format' value='packed'/>

I interpret this as meaning that org.apache.derby is expected to be packed. So I believe this is the cause for the error.

Apparently CDO packs the jar from Orbit in its own update site : <downloads>/modeling/emf/cdo/drops/S20110907-0210/plugins/org.apache.derby_10.5.1.1_201105231903.jar.pack.gz

I'm not sure what is the right way to fix this. Should CDO avoid repacking the jars from Orbit? Should MoDisco build using the Orbit jars from the CDO update site? What about when the same Orbit jar is required by several different projects?

Nicolas Bros
tel: 06 75 09 19 88

Mia-Software, 410 clos de la Courtine
93160 Noisy-le-Grand
.: model driven agility :.
cross-project-issues-dev mailing list

cross-project-issues-dev mailing list

Back to the top