Community
Participate
Working Groups
For instance, the core bundle depends on the ASM bundle. Because it lists the same version that it itself uses, the core bundle can never be updated in issolation - the matching ASM bundle must also be obtained. The ASM bundle rarely changes so this particular dependency restriction is unneccessary and should be fixed so that they only need to be changed when something required has changed. This is required for patching since currently a patch that only touches a single class must replace the majority of bundles.
removing the qualifier opens the bundles to use older builds of dependant bundles (which is the point), but it also opens us up to allowing non-compatible versions due to our current versioning scheme - all bundles match the release version. This is especially an issue, with ASM (the newly internalized ASM is based upon 3.3.1, which is not compatible with the previous version, but the bundle is still versioned 2.3.0.<qualifier>). I can remove the qualifier for all dependencies except ASM, and hardcode ASM's to the yesterday's qualifier, which would force the dependency to that build or newer. Thus allowing other bundles to be used with a patched core, and avoid backward compatability issues with the previous ASM milestones. This is non-standard and prone to inadvertant 'fixing'. Ideally, we should move to separate versioning for each bundle, and as Chris has pointed out it should somhow be centrally located for ease of development (version property for each bundle?). If so a larger question is what should the initial bundle versions be? They cannot be lower than the current build, so should at a minimum be 2.3.0. But this is a larger Project issue and should be discussed.
I'm upping the priority because this should at least be discussed before the release of 2.3.0
Another question that will need resolution is how we reconcile the multiple branch strategy with the eclipse strategy of OSGi versioning: - how do we maintain room for bugfixes on a branch, yet maintain a coherent versioning strategy for the bundles? For example, say we start with 2.3, and all bundles begin with version 2.3.0, as released they either remain 2.3.0, or are bumped to 2.3.1 for fixes, now we add a 2.3 branch and move trunk to 2.4.0, new bug fixes are added, the bundles should remain 2.3.x unless API changes are made, yet if a fix is added is it now 2.3.2? Maintenance will become a nightmare. Unless we can guarantee new features (backward compatible API changes for each release thus allowing the trunk to bump all bundles to 2.4.x. - we could split all the bundles into separate projects (no branching) and simply include an appropriate bundle version for each Release (which does branch), but that would mean more projects to maintain, and potential difficulties for developers. It also means that a "patched" bundle could/would contain other fixes. Unless branching was done by version similar to, but unrelated to the "marketing release" (branch at 2.3, but 2.3 is unrelated to the 2.3 release, rather it means that new functionality was added to the bundle (beyond bug fixes).)
I've spoken with Tom, and he feels we actually should tighten our required-bundle and import version dependencies where EclipseLink bits are concerned. This would mean changing from something like "version=2.3.0.v20110405-r8888" to "version=[2.3.0.v20110405-r8888,2.4)" this is counter to the bug. It may be possible, that both are possible if different import version standards are applied to the individual bundles (tighten core, loosen others). I've setup a meeting with the team leads to discuss how we want to move forward.
Meeting to discuss this bug concluded the following: - we make no statements about compatability of development releases. This includes milestones. So there is no reall concern about the changes in version of ASM/ANTLR during the development cycle. That said, it was agreed that those bundles should move to a static version, though it cannot be done this late in the development of 2.3.0. - maintaining fully qualified exports (V.v.v.qqualifier) and only three part imports and required-bundle directives is moving ahead. Work to complete the transistion is going to be completed and reviewed today for 2.3.0, and then will be followed up on prior branches asap.
Created attachment 196142 [details] loosen import and require-bundle directives there are also some other changes... some bundles weren't exporting versioned packages at all. I changed that. There is a question of whether I should loosen the fragment-host directive for fragments. It makes sense to me to do so, so I have. In cases where we didn't specify versions for import I didn't change that (core requires ams and antlr, the require-bundle directive specifies a version, the import package doesn't - and I left it alone)
patch reviewed by Tom. merged in revision 9426 to trunk. Marking assigned. Need to test the results to trunk. If good, will merge updated manifests in trunk, and make similar changes in the other branches.
works fine in 2.3.x. need to backport to 2.2 and 2.1?
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
