Community
Participate
Working Groups
I've noticed these two EclipseLink bundles are unsigned, in staging repo. org.eclipse.persistence.jpa.jpql_1.0.0.v20110604-r9504.jar org.eclipse.persistence.jpa.jpql.source_1.0.0.v20110604-r9504.jar Not sure if that's your final contribution or not, but this effects us in WTP, since these are some we in WTP pickup, and redistribute, for use in some IDE function. I noticed this by accident when doing some testing with our final WTP "RC4b" build, which we did specifically to pick up your final bundles, and I noticed that, when staging was on the list of available software sites, doing an install of WTP would pop up a dialog about "you are installing unsigned software ...". After some panic, discovered that _our_ version in WTP is signed (by our build process) but guess yours in staging is not? And, not sure how to solve this. Not really sure "where" the unsigned versions came from ... but either we in WTP do not have the latest? or there's two versions of these bundles floating around? That is, same version/qualifier, different contents. If they bundles have the same version/qualifier, one signed, one not, then there will always be some amount of confusion over which a user will get. Not sure, even, which the final repo will get ... which the aggregator (p2) ends up pulling will be kind of indeterminate, as far as I know. Is this a known issue? Am I seeing things right?
I've confirmed by looking directly in ~/downloads/rt/eclipselink/milestone-updates/2.3.0.v20110604-r9504_RC4 that the following four bundles are not signed. The other 37 of them there are. javax.persistence_2.0.3.v201010191057.jar javax.persistence.source_2.0.3.v201010191057.jar org.eclipse.persistence.jpa.jpql_1.0.0.v20110604-r9504.jar org.eclipse.persistence.jpa.jpql.source_1.0.0.v20110604-r9504.jar Well, the other 37 of them except commonj.sdo_2.1.1.v200905221342.jar, which is the one and only "known exception".
I found the issue. It was quite subtle, but amounted to the o.e.p.jpa.jpql bundle being excluded from the signing zip. I'm in the process of fixing and testing. Should be able to replace the p2 repo, and bundle.zip with a fixed one by end-of-day. Will keep you posted... would have been nice to find this before we published RC4... ;)
The jpql bundles need to be signed. However, as outlined in https://bugs.eclipse.org/bugs/show_bug.cgi?id=315644 the unsigned version of javax.persistence is required. The two exceptions required by eclipselink are the javax.persistence and sdo jars.
fix tested. I need to go to an appt now, but will check-in and regenerate the milestone P2, and upload the updated bundle.zip when I return.
(In reply to comment #3) > The jpql bundles need to be signed. > > However, as outlined in https://bugs.eclipse.org/bugs/show_bug.cgi?id=315644 > the unsigned version of javax.persistence is required. The two exceptions > required by eclipselink are the javax.persistence and sdo jars. would have been nice to find this before we published RC4... (just kidding) But what I mean is we in WTP are signing this jar, since we now "pick it up". And us mistakenly signing it has not been noticed until now. :( I suggest if you never want it signed, it should have an eclipse.inf file in its META-INF directory to specify "don't sign". See http://wiki.eclipse.org/JarProcessor_Options Is that feasible/desired, now? We in WTP could hard code our scripts not to sign it ... but, seems it'd be better to have it "spec'd" in the bundle itself not to sign it. I'm not crazy about us in WTP then having an unsigned bundle in our "stack". But, that's a longer term discussion ... Neil. Thanks for the reminder and pointer to the old discussion.
David, I think you misread Peter (he was referring to javax.persistence and commonj.sdo as unsign-able, and e.o.p.jpa.jpql bundles as "should be signed"), or I am misunderstanding you (and you are also shipping javax.persistence). My understanding is that you are signing the o.e.p.jpa.jpql bundles in WTP, and you shouldn't. They should be signed by eclipselink (hence this bug), and WTP should get them from the repository. Thinking through your suggestion of adding an eclipse.inf into e.o.p.jpa.jpql for "no sign", I cannot see how that would work, since we need to sign it. Then again, I'm not certain you can simply pull in bundles from the Aggregator repo - my understanding is that p2 is feature based (but I may be wrong). We'll look into adding "no sign" to commonj.sdo and javax.persistence but, unless I am misunderstanding something, I don't think it is worth the churn at this pint to do it for Indigo.
(In reply to comment #6) > I think you misread Peter (he was referring to javax.persistence and > commonj.sdo as unsign-able, and e.o.p.jpa.jpql bundles as "should be signed"), > or I am misunderstanding you (and you are also shipping javax.persistence). Yes, we also ship javax.persistence, as part of a Dali feature. If we have to respin anyway, to pick up new, matching version of released version of e.o.p.jpa.jpql, we can tweak our scripts to not sign javax.persistence. And you can "improve" eclipse.inf files later. (We redistribute javax.persistence 2.0.3. While looking into this, I noticed there is a javax.persisence 1.0.0 in Orbit. And it is signed. Is it supposed to be signed? Or, is it just doing no harm, because no one uses it? )
I've discovered, see bug 348790, that its not as easy to "not sign" this bundle, as I thought. Not hard. Just not as easy as I thought. So, wanted to discuss the risk of having two versions of "javax.persistence" out there in the wild, same version/qualifier, one signed, one not signed. I know not great, and needs to be fixed, but wondering if it is "blocking" for Indigo? For example, in the runtimes where your need it unsigned, are those 'pre-packaged" deployed runtimes, where you can control which javax.persistence is installed? Or, are those runtimes created with p2 installers ... in which case, you'd not have complete control, and I think it'd be a blocking problem? Just wanted to be explicit. Apologies for the late-breaking problems.
I believe the signed javax.persistence 1.0 jar is there for use with earlier versions of EclipseLink - someone can correct me if I am wrong. When using PDE or OSGi, EclipseLink will be happy with either a signed or unsigned version of javax.persistence. Our bundles have no issue with using the signed bundle. The reason we need an unsigned version is for our non-OSGi support. (e.g. on a traditional Java EE application server). This type of install uses a larger eclipselink.jar rather than our bundles. We create our own zip of this type of install and I think it is unlikely this would be something anyone would ever get from P2. I am not sure which jars you are referring to when you say, "two versions of "javax.persistence" out there in the wild, same version/qualifier, one signed, one not signed". It appears to me as if the javax.persistence 1.0 and 2.0 jars have different versions and qualifiers.
(In reply to comment #4) > fix tested. I need to go to an appt now, but will check-in and regenerate the > milestone P2, and upload the updated bundle.zip when I return. Any updates on the regen and uploading? From looking at the download page, it would appear that this has not happened yet.
> > I am not sure which jars you are referring to when you say, "two versions of > "javax.persistence" > out there in the wild, same version/qualifier, one signed, one not signed". > > It appears to me as if the javax.persistence 1.0 and 2.0 jars have different > versions and qualifiers. Oh, I meant the one in your repo, unsigned, and the one in our WTP repo (and apparently common repo), signed. But, must admit ... sounds like you could/should provide a signed OSGi version, and handle your non-OSGi "internal jar" separately, as part of your releng process. Granted ... more releng work for you ... but ... you are the one with non-OSGi need :) [That is, we'd never make progress if we all said "we can't improve things because we need to support legacy apps" :) ... and, honest, I'm more sympathetic than I sound in bug reports and notes :) ] So, the main problem, for now, with javax.persistence is there are two "official" versions of javax.persistence_2.0.3.v201010191057.jar, one signed, one not. It appears, if we in WTP can respin, we can avoid our accidental "contribution" of this signed version to the common repo.
I just completed the regen, and am in the process of verifying. was going to send out email to cross-platform mailing list when verified. Re: comment 7-9 I don't think it will be an issue for you to sign the javax.persistence_2.0.3 jar. It'd even be nice if we could somehow guarantee the signed version in the Indigo P2. Tom's explanation of why we cannot ship (in archive) a signed javax.persistence_2.0.3 is quite accurate. The reason we cannot generate a P2 with it signed is due to our process. We generate our p2 repos from zip archives (to guarantee consistency) which are also downloadable. If some of the javax.persistence_2.0.3 jars were signed in archive while others weren't it creates a trouble-shooting issue in cases where a user decides to use an unexpected combination of jars from different downloadable archives. However, if we are shipping (in archive) unsigned versions, and Indigo ships with a signed version, as Tom says there should be no issue. Any process changes to generate our P2 with a signed javax.persistence_2.0.3, yet maintain unsigned versions in the downloadable archives is far too risky at this point to undertake.
Verified the P2 repository. Should be ready for a re-spin.
Eric, can you send out the address.
it (they are the same)... P2: '/home/data/httpd/download.eclipse.org/rt/eclipselink/milestone-updates' latest should get you what you need from the composite, or you could go directly to '/home/data/httpd/download.eclipse.org/rt/eclipselink/milestone-updates/2.3.0.v20110604-r9504-RC4' Downloadable Bundle Archive: http://download.eclipse.org/rt/eclipselink/milestones/2.3.0/RC4/eclipselink-plugins-2.3.0.v20110604-r9504.zip (direct, without mirror support)
(In reply to comment #15) > it (they are the same)... > '/home/data/httpd/download.eclipse.org/rt/eclipselink/milestone-updates/2.3.0.v20110604-r9504-RC4' I'm still seeing the one there, on file system, unsigned. But, agree, the one in the zip file is signed. But, you are going to leave the jar file name/version the same? Just sign it and update metadata (so checksums, etc., match). Normally that's not a good practice, but this part of our WTP build is not cached, but freshly re-fetched each time, so not sure we in WTP would have to respin if you are going to leave the name the same. We already have a signed one, with same name (that we in WTP signed) ... but ... during our Indigo aggregation, it's a "roll of the dice" which the aggregator will get ... your (currently) unsigned version, or our wtp signed version. If I'm seeing things correctly.
(In reply to comment #16) > > '/home/data/httpd/download.eclipse.org/rt/eclipselink/milestone-updates/2.3.0.v20110604-r9504-RC4' > I'm still seeing the one there, on file system, unsigned. But, agree, the one > in the zip file is signed. I was stumped, since I verified the signing.. seems my update script had a tiny bug... it generated with a "-RC4" rather than a "_RC4" so both existed in the composite repository, the above should have had a signed version of jpql, where _RC4 didn't. (I missed the difference for about 15 minutes of hair-pulling trying to figure out how to get rid of one of the two "duplicate directories" - so I figure you must have inadvertantly looked in the old one). I removed the old repos (_RC4) and renamed -RC4 to _RC4 and have regenerated the composite parent. If you really need different qualifiers, I'm going to have to do a full rebuild based upon the same revision, then promote as RC4a. I'd rather avoid it if possible (and that won't even fix javax.persistence_2.0.3), but if it is necessary let me know.
> > If you really need different qualifiers, I'm going to have to do a full rebuild > based upon the same revision, then promote as RC4a. I'd rather avoid it if > possible (and that won't even fix javax.persistence_2.0.3), but if it is > necessary let me know. Its up to you. I'm just trying to be helpful. :) As long as the currently running aggregator run snagged the sign version, I don't know of any user-impacting problem, so would say its time to stop. I did confirm its signed in the underscore directory now. (If current run happened to snag unsigned version, then sounds like it'll pick up signed version next run ... we do not "cache" anything while creating staging ... just for reasons like this :( Thanks for attending to this issue. I'll open new bugs for a couple of the other issues we discussed here.
I think we can mark this as fixed. I opened following two bugs for your future consideration. Thanks everyone. bug 348828 best if intentionally unsigned bundles say so, in eclipse.inf bug 348829 javax.persistence should be signed for OSGi consumers
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
