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

Bug 348604

Summary: Re-spin to pick up RC4 EclipseLink bundles for Dali
Product: [WebTools] WTP Releng Reporter: Neil Hauge <neil.hauge>
Component: relengAssignee: Tran Le <tranle1>
Status: RESOLVED WONTFIX QA Contact: David Williams <david_williams>
Severity: normal    
Priority: P3 Flags: david_williams: pmc_approved+
Version: 3.10   
Target Milestone: 3.10.0   
Hardware: PC   
OS: Windows 7   
Whiteboard:

Description Neil Hauge CLA 2011-06-07 11:57:49 EDT 
Tracking bug to update EL bundle dependencies.

There are some WTP dependencies that are packaged into WTP in a similar fashion to the Orbit bundles.  Several EclispeLink bundles are an example of this packaging, and as a result, a respin is required to pick up the latest RC4 bundles so that what is eventually shipped with WTP 3.3 will match what is installable from the Indigo repository.
Comment 1 Tran Le CLA 2011-06-07 12:08:41 EDT 
The JPT map is updated, and the build is re-started
Comment 2 David Williams CLA 2011-06-07 23:49:20 EDT 
marking as PMC approved to document that we discussed this as PMC meeting.
Comment 3 David Williams CLA 2011-06-08 13:51:37 EDT 
Do we need to do this again? So we match new org.eclipse.persistence.jpa.jpql bundle, as a result of bug 348670? 

And, guess we should _not_ be signing the javax.persistence bundle we get from EclispeLink? 

Please confirm ... propose a plan.
Comment 4 Neil Hauge CLA 2011-06-08 14:13:48 EDT 
(In reply to comment #3)
> Do we need to do this again? So we match new org.eclipse.persistence.jpa.jpql
> bundle, as a result of bug 348670? 

It would seem so, if we are to retain an exact plugin match with what EclipseLink ships with Indigo, which I think we have agreed is desirable.  If we would rather avoid the rebuild, from a functional standpoint I don't believe there would be any ill effects.

> 
> And, guess we should _not_ be signing the javax.persistence bundle we get from
> EclispeLink? 

I'm not sure.  The javax.persistence bundle that we package would only be for use within the IDE, so it seems reasonable that we could sign it as we are packaging it.  I'm not sure if there is a particular code of conduct when it comes to signing (in this case signing another project's jar), but if not then seems it might be reasonable to do in this case.  There is of course the issue of our packaging being different than what might be obtained in the Indigo repository, so there would be that issue.  And that is probably the more important issue, since that is where this would most matter (when a user is installing via Update versus epp package, where they would not know if content was signed or not.

For this issue, it would seem that leaving things as they are has the benefit of less churn, no late delivery, etc.  Making the change would give us parity with the Indigo repository, but no other benefits.  I suppose if we are going to respin to pick up the new jpa.jpql bundle, we might as well make the changes to not sign javax.persistence bundle.

> 
> Please confirm ... propose a plan.
Comment 5 David Williams CLA 2011-06-21 15:34:49 EDT 
I think most accurate to mark this as "won't fix" and deal with the longer term issues in other bugzilla entries.