Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 317392

Summary: UDC Feature incorrectly includes Orbit bundles
Product: [Technology] EPP Reporter: David Williams <david_williams>
Component: Usage Data CollectorAssignee: Wayne Beaton <wayne.beaton>
Status: RESOLVED WONTFIX QA Contact:
Severity: major    
Priority: P1 CC: b.muskalla, christian, jonah, mknauer, steffen.pingel
Version: 1.3.0   
Target Milestone: 1.3.1   
Hardware: PC   
OS: Windows 7   
Whiteboard:
Bug Depends on: 334258    
Bug Blocks:    

Description David Williams CLA 2010-06-20 21:26:46 EDT
This isn't the packagers fault, per se, but it is a problem for packages, if they end up packaging extra bundles. I noticed in both the javascript and Java EE package, the following bundle pairs. 

This implies some "feature" being installed is using an old version of Orbit to construct itself, so some features end up saying they need (include) exactly the old versions. Since they are not singletons, there is no compliant during install/resolution ... but in the best case, it is "extra" bytes. I am assuming that at runtime, only the latest one is used ... but that is an assumption and in the general case, having multiple versions could cause runtime problems. 

My guess is it is the market place client, or data collector that is using old version of Orbit ... just guessing, since most the other features I'm pretty familiar with and know it doesn't come from them.  

org.apache.commons.codec_1.3.0.v20100106-1700.jar
org.apache.commons.codec_1.3.0.v20100518-1140.jar

org.apache.commons.httpclient_3.1.0.v20080605-1935.jar
org.apache.commons.httpclient_3.1.0.v201005080502.jar

org.apache.commons.logging_1.0.4.v200904062259.jar
org.apache.commons.logging_1.0.4.v201005080501.jar

Once tracked down, we can move this bug to appropriate place ... just wanted to get it entered, now.
Comment 1 Markus Knauer CLA 2010-06-21 02:51:39 EDT
I checked this and it is not the MPC.

Moving to UDC / 1.3.1 since this is definitely one place where these bundles are pulled in. Unfortunately they are not defined as external 'dependencies', they are defined as part of the UDC feature which is even worse.

We need to fix this in SR1 and make sure that nobody else is pulling in those plugins.
Comment 2 Markus Knauer CLA 2010-06-22 01:21:37 EDT
*** Bug 317523 has been marked as a duplicate of this bug. ***
Comment 3 Steffen Pingel CLA 2011-01-12 19:10:31 EST
This is causing severe problems with the same class being loaded from different bundles. Wayne, let me know if I can do anything to get this fixed for SR2.
Comment 4 Steffen Pingel CLA 2011-01-12 19:11:18 EST
*** Bug 334180 has been marked as a duplicate of this bug. ***
Comment 5 Wayne Beaton CLA 2011-01-13 13:14:34 EST
(In reply to comment #3)
> This is causing severe problems with the same class being loaded from different
> bundles. Wayne, let me know if I can do anything to get this fixed for SR2.

I've got a build working with Tycho committed in HEAD (Bug334258). It excludes the bundles.

How do I ensure that the bundles I require actually make it into the aggregate repository? Does the aggregator automatically pull them out of Orbit for me?

I need to figure out how to get this build into Hudson; I have no experience with this, so it will take me a bit (unless somebody wants to help :-))
Comment 6 Markus Knauer CLA 2011-01-14 08:54:44 EST
(In reply to comment #5)
> I need to figure out how to get this build into Hudson; I have no experience
> with this, so it will take me a bit (unless somebody wants to help :-))

In any case (Hudson or not) 

* the result of the build (signed and compressed p2 repository) needs to be copied to ~/downloads/technology/epp/updates/1.3/1.3.1.Rxyz/... (with xyz as timestamp)

* the Indigo and Helios builds need updates in
** /org.eclipse.indigo.build/epp-udc.b3aggrcon and in
** /org.eclipse.helios.build/epp-udc.b3aggrcon

* at Helios SR2 release date compositeArtifact.jar and compositeContent.jar in ~/downloads/technology/epp/updates/1.3 need an update
Comment 7 Steffen Pingel CLA 2011-02-02 03:22:34 EST
Do you think we can make this happen for RC2 on Thursday?
Comment 8 Wayne Beaton CLA 2011-02-02 10:26:47 EST
(In reply to comment #7)
> Do you think we can make this happen for RC2 on Thursday?

I have a new Tycho-based build with packing and signing that seems to be working. I'll test it a little more today before I push the bits out.
Comment 9 Wayne Beaton CLA 2011-02-03 14:54:58 EST
(In reply to comment #6)
> (In reply to comment #5)
> > I need to figure out how to get this build into Hudson; I have no experience
> > with this, so it will take me a bit (unless somebody wants to help :-))

I can't quite seem to sort out how to get the Maven-based build to succuessfully sign. It looks signed, but Eclipse is reporting back that it's not when I attempt to install it (very frustrating). I picked up the most recent old-school PDE build results (which benefited from the changes I made to exclude the Orbit JARs) and am using those for the time-being.

> In any case (Hudson or not)
> 
> * the result of the build (signed and compressed p2 repository) needs to be
> copied to ~/downloads/technology/epp/updates/1.3/1.3.1.Rxyz/... (with xyz as
> timestamp)

Done. Directory name is 1.3.1.R201102031410

> * the Indigo and Helios builds need updates in
> ** /org.eclipse.indigo.build/epp-udc.b3aggrcon and in
> ** /org.eclipse.helios.build/epp-udc.b3aggrcon

Done and done.

> 
> * at Helios SR2 release date compositeArtifact.jar and compositeContent.jar in
> ~/downloads/technology/epp/updates/1.3 need an update

Not sure what needs to be done here. Is there a pointer?
Comment 10 Markus Knauer CLA 2011-05-20 04:58:48 EDT
While going through the list of open bugs, I found this one.

(In reply to comment #9)
> > * at Helios SR2 release date compositeArtifact.jar and compositeContent.jar in
> > ~/downloads/technology/epp/updates/1.3 need an update
> 
> Not sure what needs to be done here. Is there a pointer?

I updated all composite repository definitions (compositeArtifacts.jar  compositeArtifacts.xml  compositeContent.jar  compositeContent.xml) in the directory mentioned above with the URL that is used in our Indigo contribution (1.3.1.R201102081640). I think we are good now. Can you close the bug then?
Comment 11 Jonah Graham CLA 2021-05-07 10:23:37 EDT
The Usage Data Collector was decommissioned a long time ago. Therefore any
remaining bugs are now being closed as WONTFIX. If this bug is still relevant,
please make a comment and we'll move it to the correct project/component for
further investigation.

This change was made as part of a bulk change.