Community
Participate
Working Groups
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.
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.
*** Bug 317523 has been marked as a duplicate of this bug. ***
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.
*** Bug 334180 has been marked as a duplicate of this bug. ***
(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 :-))
(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
Do you think we can make this happen for RC2 on Thursday?
(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.
(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?
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?
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.
