Re: [cross-project-issues-dev] error with org.apache.derby jar.pack.gz expected by CDO
do you literally mean "repack"? or pack?
I'm not sure about the terminology, but CDO at least "packs" the jars (since they are not originally packed on Orbit).
But, yes, projects are expected to pack (pack200) files they get and redistribute from Orbit.
Then it means CDO is not to blame. But there is still a problem, and I have trouble putting my finger on it : does the problem lie with Buckminster, p2, MoDisco, 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).
MoDisco only needs the jar in its target platform for building because of the dependency to CDO.
What I am doing currently is getting all the Orbit jars from the Orbit update site (when populating the target platform for building) :
This is easy to specify with Buckminster. As a last case in my rmap, I have:
<rm:locator searchPathRef="orbit" failOnError="true" />
This means that everything that couldn't be found anywhere else will be fetched from Orbit.
Now if I need to get all the required Orbit jars from the multitude of projects MoDisco depends on, it means I must keep track of all these requirements, and add a line in my Buckminster rmap for each jar to specify where it should be fetched from. That sounds like a lot of work. I feel like the Buckminster map system is not made to handle well this kind of situation.
So, I'm wondering, is getting the Orbit jars from each project (instead of from the Orbit update site) to build the target platform really mandatory?
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