Community
Participate
Working Groups
As discussed in bug 348670, javax.persistence is currently not signed, by EclipseLink project, for delivery to the release train, but there is no technical reason it can not be, for OSGi consumers. It is not signed, by EclipseLink, so they can use it "internally" in a runtime jar, provided for non-OSGi consumers. Seems to me, it would be feasible to deliver a signed version for main release, so that OSGi oriented runtime can be assured they are running with signed jars from Eclipse, while for the "internally" packaged jars could be unsigned ... slightly renamed, or something to avoid confusion, all by releng tasks. From looking at the zip file of bundles provided in bug 348670 comment #15, I've noticed EclipseLink has a number of other "unsigned internal jars": eclipselink-jpa-modelgen_2.3.0.v20110604-r9504.jar javax.jms_1.1.0.jar javax.persistence.source_2.0.3.v201010191057.jar javax.persistence_2.0.3.v201010191057.jar javax.resource_1.5.0.jar javax.transaction_1.1.0.v201002051055.jar javax.xml.soap_1.3.0.jar At least one of these, is similar to what is provided in Orbit in a signed form (javax.transaction_1.1.1.v201105210645.jar) . So that makes me think something similar could be done for javax.persistence.
We should probably just upgrade our javax.transaction bundle to the one in orbit. There is some suggestion in the earlier bug that our unsigned javax.persistence case is "legacy". (although it may not ultimately make a difference in what we do in the end) I want to ensure it is understood that this is not the Legacy case. This is, by far, the most common case. With Java EE just starting to be adopted as part of the OSGi spec, JPA in OSGi is still one of our least common deployment scenarios. It remains to be seen if this will ever become a common usecase.
> > There is some suggestion in the earlier bug that our unsigned > javax.persistence > case is "legacy". ... > I want to ensure it is understood that this is not the Legacy > case. Yes, apologies. I was just trying to make a joke, that anything non-OSGi was legacy. I didn't mean anything by it. Thanks for clarifying and keeping the record (and me) straight.
BTW: I believe that the majority of the other jars (other than javax.persistence) in the list above are unsigned because we only use them in testing. We may want to consider simply signing them.
Found this bug instead of creating a new one to address the issues in bug 460094. We need a signed javax.persistence jar for Eclipse IDE usage, as the unsigned jar is causing issues when users are adding Eclipse features, such as Dali Java Persistence tools. More importantly, this is a blocker for Dali being delivered in the upcoming Mars release.
Lukas, Martin...Wanted to let you know that our window on addressing this issue is closing fairly quickly. We need to have some sort of solution in place by May 28th, with a drop dead date of June 4th. Please let us know if this won't be possible so we can take necessary actions to get a signed bundle in place some other way.
looking into this...
There appears to be a problem with the proposed repo: http://download.eclipse.org/rt/eclipselink/updates/2.6.0.1 It doesn't appear to contain all necessary bits.
starting with 2.6.1 RC1 http://download.eclipse.org/rt/eclipselink/milestone-updates/ should contain signed javax.persistence bits. Would it be possible to check it and let us know whether this can be considered fixed or if there is still something wrong, please?
Yes...not sure exactly when that will be, but at the very latest we can try pulling it into the early Neon builds in early July.
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
