Bugzilla – Full Text Bug Listing
| Summary: | Need to fix build scripts, so we do not sign javax.persistence | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP Releng | Reporter: | David Williams <david_williams> | ||||
| Component: | releng | Assignee: | webtools.releng <webtools.releng-inbox> | ||||
| Status: | NEW --- | QA Contact: | Carl Anderson <ccc> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | neil.hauge, tranle1 | ||||
| Version: | 3.10 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
David Williams
This will be a little more complicated to do than I first thought. We create the pack.properties file in one of our build tools, UpdatePackPropertiesFile.java which is in the org.eclipse.wtp.releng.tools module. So, to fix, we have to fix that utility, rebuild it, then update our "builder" to use a new version of the build utility. All pretty simple and safe ... but ... not as risk free as simply updating a properties file. I was just thinking that javax.persistence is only a compile time dependency for Dali. Is there a non-hack way that we can reference this bundle, compile against it, but not package it? I can't think of any examples of this kind of setup in WTP. But perhaps I am just not aware? One way to do this (although a hack) would be to put the javax.persistence.jar into a lib folder of the Dali plugin that depends on it and then compile the plugin with this jar on its classpath. We still end up shipping it, but it is embedded in a Dali bundle. Is this the only way? (In reply to comment #2) I'd have to think ... seems others have done this, but don't recall how/when, right off ... so was/is probably hacky itself. :) A slightly less hacky way is to 1) remove it from your org.eclipse.jpt.jpa.eclipselink.feature but put it in your assembly feature. (probably first, in that assembly feature.xml, though not sure it matters). I think this would still pull it into the build, but would not put it in our "distribution". Feel free to try ... it'd take a few hours to make sure it worked. (We'd probably still end up signing it, but since never distributed, wouldn't matter ... for now). Oh, and not sure of effect on unit tests. I know you already load some special "runtimes" to test against, so hopefully they already have what you need? But would no longer be "installed" as part of your feature, for the tests. Oh, and if you do respin to fix javax.persistence issue, don't forget to udpate dependency on org.eclipse.persistence.jpa.jpql to get the "released" version :) Created attachment 197644 [details]
Proposed patch
Patch to move javax.persistence dependency to assembly feature.xml
(In reply to comment #3) > (In reply to comment #2) > > I'd have to think ... seems others have done this, but don't recall how/when, > right off ... so was/is probably hacky itself. :) > > A slightly less hacky way is to 1) remove it from your > org.eclipse.jpt.jpa.eclipselink.feature > > but put it in your assembly feature. (probably first, in that assembly > feature.xml, though not sure it matters). > > I think this would still pull it into the build, but would not put it in our > "distribution". > > Feel free to try ... it'd take a few hours to make sure it worked. > > (We'd probably still end up signing it, but since never distributed, wouldn't > matter ... for now). That sounds like a good plan. Not sure which of the unsigned bundle issues is really driving us at this point (o.e.persistence.jpa.jpql or javax.persistence). It seems like we can probably knock out both issues in one re-spin this afternoon (assuming EL gets their new build published). I'm not sure if either one alone is really a showstopper for WTP, but perhaps both added together amount to passing the threshold for a re-spin? In any case, we have a patch to do this assembly based fixed. We will get a build started after we can update the other EL dependency. (In reply to comment #4) > Oh, and not sure of effect on unit tests. I know you already load some special > "runtimes" to test against, so hopefully they already have what you need? But > would no longer be "installed" as part of your feature, for the tests. This won't affect unit tests. We have another solution in place there. (In reply to comment #5) > Oh, and if you do respin to fix javax.persistence issue, don't forget to udpate > dependency on org.eclipse.persistence.jpa.jpql to get the "released" version :) Yep...will do. Patch applied and released. According to Eric the jpql release version has not change, so I haven't modify the map file. I have not restarted the build yet. (In reply to comment #8) > Patch applied and released. > According to Eric the jpql release version has not change, so I haven't modify > the map file. > I have not restarted the build yet. The build started automatically, I've killed it and disabled our I-builds. From all the discussion in bug 348670, sounds like there would be no harm, leaving things as they are, for Indigo release, so I do not think it is worth any churn simply to "be correct". If we do not need to distribute the javax.persistence bundle, (only need at compile time), then I do still think we should not include it in distribution, so I think the change to the feature is still ok ... still ok to do for maintenance release, that is. I'm fairly sure that would not cause "udpate" issues. But ... can you revert the changes, in maps and (up to you) your code ... I want to make sure when we tag maps for "R3_3_0" ... or ?"R2_3_0"? for your case? ... that we tag what was actually delivered. I'll probably tag next week, during "quiet week". Sorry for all the churn and concern. (In reply to comment #9) David, I have reverted the patch and map files. I guess that the build auto-start is deactivated. |