Hi Tim, Thanks for the comments. I think I understand the scenario you're trying to support better. I've trimmed context and added further comments inline ...
> Our maven build very deliberately always depends on 'minimum required' > > released versions, unless there's a functional requirement for a snapshot > > dependency. > > This is true. > > > So if we want to release util, and util depends on testsupport, > > my understanding is that the new Java-7 compatible util will have a > > dependency on the old non-Java-7-compatible testsupport. > > I believe that this is the currently open question. We could do it this > way, but it prevents you being able to do an end to end source build with > JDK 7. > I think this is only slightly true. :) We probably want to clarify what our goal is, and what we mean by end to end builds for a heavily modularised project. At the moment, I'd argue you can't really do an end to end source build of Aries full stop, no matter what JDK you're using. Obviously, at the moment, you can check trunk out, and build it, and that will work (as long as you're not using Java 7). If we switch to using the java-7-compatible-java5-parent, you'll be able to check trunk out, build it using either Java 6 or Java 7, and have everything work. So what's missing? Well, in both scenarios, you didn't build all of the bundles you're using from source. All of the bundles you built have snapshot versions. Many of these snapshot bundles depend on released bundles, and you haven't built these bundles - maven just automagically pulled them into the maven repo for you. So in your local repo, for most bundles, you'll have a version you built, and another version that you're actually using. So what if you want to build them yourself? No problem, you can go find the source associated with the level maven pulled down, build it locally, and then the version in your maven repo will have been built locally by you. The limitation we currently have is that you can't rebuild these already-released bundles using Java 7. I think this is a reasonable limitation. After all, these bundles may also fail to build with Java 8 or Java 9 - they're historical artefacts and they have limitations because of the context in which they were originally created. What I think you're proposing, Tim, is to re-release things so that the conscientious would have the capability to rebuild dependencies from source, for the currently released levels. Since this wouldn't fix the historical releases, I do think the use case for it is small; consumers like Karaf would most likely still be using the older releases, so we wouldn't be helping them rebuild from source on Java 7. I also suspect the cross-over between people who're obsessive enough to rebuild released artefacts from source and people who need to be able to build using Java 7 is small. :) (On the other hand, maybe generating Java-7-built artefacts is one of the main use cases for rebuilding released artefacts from source??) I guess the other scenario for rebuilding everything from source with Java 7 is to verify that Java7-built-bundles do actually work, but I think this use case is covered by the snapshot-dependencies build. > > > If we wanted to > > build the old Java-7-incompatible testsupport from source, rather than > just > > pulling the released version into our local Maven repo, we could still do > > that. We'd download the old testsupport source, and build it, and it > would > > build ok, because the old testsupport would depend on the the old > > java5-parent. > > This would not work with JDK 7 because it uses the old java5-parent. This > is why I'm saying that it wouldn't be possible to do an end-to-end source > build using JDK7 unless we re-release dependencies with this update. > You're right, we'd have to build it with Java 6, but I think this is a reasonable limitation for a historical artefact, given that we can never actually *fix* the old artefacts, only supercede them. > > > So in the scenario where you started with a clean maven repo > > and built the 'current' util release and its dependencies, from source, > > your maven repo at the end would contain a new and and an old version of > > java5-parent, but everything you tried to build would have built > > successfully. (I think!) > > > As I say above, this is only possible if you don't use JDK7 for at least > some part of the build. > > > > > If we want to check everything works end to end with the current > versions, > > we'd use the build-with-snapshot-dependencies build. This build verifies > > that the 'current' util builds and runs fine with the 'current' > > testsupport. (This happens automatically in the nightly build.) > > > > I actually think I'm very lost about what we're trying to achieve. If we > > did release both util and testsupport (say), what minimum version of > > testsupport would new util depend on? My assumption is that 'new' until > > would 'depend' on and require new testsupport, even though new > testsupport > > is actually binary-compatible with old testsupport? (Otherwise we > wouldn't > > bother re-releasing new testsupport, if it wasn't actually required.) But > > if the built archives of new testsupport are binary-compatible with the > old > > testsupport, it seems semantically wrong to me that we'd prevent the new > > util bundle from resolving against the old testsupport bundle. > > > I see what you're getting at, but I think that you're conflating the > versions of the maven artifacts with the versions of the packages that end > up in the manifests. Changes in You're right, I am. :) > versions of the released modules don't necessarily imply that the versions > of any packages have changed. If we look, for example, at proxy-api, the > new maven module will have exactly the same exported packages at exactly > the same versions. > So for the example you have given, the new util bundle would resolve with > either the new or old test support. The same is true of everything I have > found so far (e.g blueprint's dependency on proxy-api). We can safely > ignore micro version number changes because we configure the maven bundle > plugin (in default-parent) not to use them when generating imports. > My assumption was that there were probably at least a few places where we'd updated a package version without bumping the maven dependency level of all consumers. If there any of those places, we'd be incorrectly increasing the minimum package import. However, I didn't actually check that, and I guess it hasn't been that long since we moved to 1.0.0, so maybe none of the API packages have had 'stealth' version changes. If so, you're right that nothing would change semantically. In this case my point about effort still stands, but not my point about any semantic incorrectness. I'm also not sure that supporting the use case where people pull down the source for every bundle and build it for the current release (but not any earlier releases) on Java 7 is worth the disruption to the build that a mass non-incremental release would cause. I think people building from trunk is probably the more common scenario to support, even if the disruption is only for a few weeks. Others may have different views! > > > > > Because the maven dependencies directly impact the minimum OSGi import > > ranges, doing a mass-adjustment of the dependency levels and a > mass-release > > could actually be semantically incorrect and counter-productive, rather > > than just time-consuming. > > I would prefer not to have to do a mass release too, and I agree that we > need to be careful, but so far I've found nothing that would create a > different manifest (other than a bump to the micro version of the bundle). > Do you have an example of something that would be changed? > No, so I suspect you're right that my concern may have been theoretical rather than something we'd actually see. Holly > > > > What I'd prefer to see is an update of all the 'current' snapshot POMs to > > depend on the freshly released java5-parent, but no mass adjustment of > our > > carefully crafted minimum dependency levels. However, I assume I'm > missing > > something! Does the java7 compatibility affect the binary compatibility > of > > the built archives? > > > We could do this, but it will mean that you can't build all Aries modules > completely from source using JDK7. If we're happy to tell people that they > have to use JDK6 for parts of the dependency tree then this would be an > option. > > > > > > > Holly > > > > > > > > On Tue, May 7, 2013 at 11:07 AM, Timothy Ward <[email protected] > >wrote: > > > > > Hi Jeremy, > > > Changing the version of the maven-compiler plugin really needs to be > done > > > in default-parent (which is where we define most of the top-level > compiler > > > config). This new version of default-parent then needs to be the > parent of > > > new versions of java5-parent and java6-parent. > > > Assuming we want people to be able to do end-to-end source builds using > > > JDK7 then we need to update each Aries module to use these new parent > poms, > > > but importantly we also need to update the aries internal dependencies > to > > > be ones that can be built using JDK7. > > > Take util as an example. > > > util depends on java5-parent (as its parent pom), and on > > > org.apache.aries.testsupport.unit. It also depends on osgi core and > > > compendium. > > > In order to do a full source build for util you need to: > > > a) build osgi core and compendium from source and install them into > your > > > maven repob) build java5-parentc) build aries test supportd) build util > > > If we were only to release things on an as/when basis (e.g. we have > some > > > util fixes we need to push out), then we would release the new > > > java5-parent, update util to use the new parent, and release it. This > would > > > work, but it wouldn't be possible to use JDK7 for a full source build > of > > > util (the current testsupport dependency doesn't build using JDK7). > > > In order to flush through all of these dependencies we need to > re-release > > > everything and update dependency versions as we go. For me it's quite > > > important that you can do a full rebuild from source, hence I feel we > need > > > to do the leg-work and fix the JDK7 build issue properly, rather than > > > outputting releases that can only partially be built using JDK7. > > > I realise that this probably isn't the way most people think about > > > releases, but I believe it is the way Apache thinks about them. That's > why > > > the release votes are primarily about verifying what's in the source > zips. > > > Tim Ward > > > ------------------- > > > Apache Aries PMC member & Enterprise OSGi advocate > > > Enterprise OSGi in Action (http://www.manning.com/cummins) > > > ------------------- > > > > > > > > > > From: [email protected] > > > > Date: Tue, 7 May 2013 09:19:35 +0100 > > > > Subject: Re: [CANCELLED] [VOTE] Apache Aries release parent-1.1.0 > > > > To: [email protected] > > > > > > > > Hi Tim, > > > > > > > > On 6 May 2013 20:42, Timothy Ward <[email protected]> wrote: > > > > > General consensus is that we should upgrade the > maven-compiler-plugin > > > to 3.1. > > > > > I will start to ripple changes through trunk so that it is > possible to > > > build everything from source using JDK 7. This will mean that > *everything* > > > has to be re-released (much like when we did 1.0.0). > > > > > > > > You might be right but can you explain why? Can't we change the > > > > version of the referenced parent pom as necessary. Is using v3.1 of > > > > the maven-compiler-plugin an all or nothing situation for the whole > of > > > > trunk? > > > > > > > > > I'm volunteering to do changes and releases for most of the "base" > > > modules, namely: > > > > > parent > > > > > testsupportutilproxyjndiblueprint > > > > > As I'm doing this in my spare time I may need somebody to take over > > > for a while after that. > > > > > I know that it will be a bit disruptive to trunk, but the release > > > cycle will be much faster if we do projects in batches. This will mean > that > > > some projects won't build when checked out from trunk for the duration > of > > > the release vote (only the ones in that release that depend on other > things > > > being released at the same time). > > > > > I know that releasing from branches is another possibility, but > we've > > > been asked not to do that again because of the problems we caused in > the > > > git mirroring. > > > > > Are people prepared to put up with some disruption to save several > > > weeks of release voting? > > > > > > > > > > Tim Ward > > > > > ------------------- > > > > > Apache Aries PMC member & Enterprise OSGi advocate > > > > > Enterprise OSGi in Action (http://www.manning.com/cummins) > > > > > ------------------- > > > > > > > > > > > > > > >> From: [email protected] > > > > >> Date: Mon, 6 May 2013 15:51:22 +0100 > > > > >> Subject: Re: [VOTE] Apache Aries release parent-1.1.0 > > > > >> To: [email protected] > > > > >> > > > > >> +1 from me too. > > > > >> > > > > >> David > > > > >> > > > > >> > > > > >> On 4 May 2013 05:29, Tang Yong <[email protected]> wrote: > > > > >> > > > > >> > forgot to say about vote, > > > > >> > > > > > >> > +1(updating maven-compiler-plugin to 3.1) > > > > >> > > > > > >> > Thanks > > > > >> > --Tang > > > > >> > > > > > >> > Tang Yong wrote: > > > > >> > >> 2) updating org.osgi.core to 4.3.1 because of an issue using > jdk7 > > > > >> > > about the point, if updating org.osgi.core to 5.0.0, building > is > > > also OK. > > > > >> > > > > > > >> > > Thanks > > > > >> > > --Tang > > > > >> > > > > > > >> > > Tang Yong wrote: > > > > >> > >> Tim,John, > > > > >> > >> > > > > >> > >>> I will try to build the whole aries project and see what > will > > > happen. > > > > >> > >> I have commented on ARIES-1006, and finally, I built the > whole > > > project > > > > >> > >> successfully using jdk7. > > > > >> > >> > > > > >> > >> In summary, in order to build using jdk7, > > > > >> > >> > > > > >> > >> 1) updating maven-compiler-plugin to 3.1 > > > > >> > >> 2) updating org.osgi.core to 4.3.1 because of an issue using > jdk7 > > > > >> > >> pl. seeing > > > > >> > http://blog.osgi.org/2012/10/43-companion-code-for-java-7.html > > > > >> > >> > > > > >> > >> 3) Since jdk7, some java core classes added some new apis, > > > > >> > >> eg.javax.sql.CommonDataSource, this has effect on aries jpa > > > module. > > > > >> > >> So, needing to implement these new apis by simply > implementing > > > these > > > > >> > >> apis if having not more complex logic. > > > > >> > >> > > > > >> > >> Thanks > > > > >> > >> --Tang > > > > >> > >> > > > > >> > >> Tang Yong wrote: > > > > >> > >>> John, Tim, > > > > >> > >>> > > > > >> > >>> I made a confirmation by specifying version 3.1 (latest > > > release) of the > > > > >> > >>> maven-compiler-plugin in parent/default-parent/pom.xml, and > both > > > > >> > >>> subsystem-core and util are built successfully. > > > > >> > >>> > > > > >> > >>> John, whether you have modified util/util/pom.xml liking > > > following, > > > > >> > >>> > > > > >> > >>> <parent> > > > > >> > >>> <groupId>org.apache.aries</groupId> > > > > >> > >>> <artifactId>java5-parent</artifactId> > > > > >> > >>> <version>1.1.1-SNAPSHOT</version> > > > > >> > >>> <relativePath /> > > > > >> > >>> </parent> > > > > >> > >>> > > > > >> > >>> BTW: I suggest util/util and util/util-r42's parent pom is > set > > > as > > > > >> > >>> util/pom rather than java5-parent. > > > > >> > >>> > > > > >> > >>> I will try to build the whole aries project and see what > will > > > happen. > > > > >> > >>> > > > > >> > >>> Thanks > > > > >> > >>> --Tang > > > > >> > >>> > > > > >> > >>> John W Ross wrote: > > > > >> > >>>> Specifying version 3.1 (latest release) of the > > > maven-compiler-plugin > > > > >> > in > > > > >> > >>>> parent/default-parent/pom.xml fixes the subsystem-core > build > > > issue on > > > > >> > java > > > > >> > >>>> 7 (jdk1.7.0_21). I suspect it will also fix the same > issue, and > > > > >> > perhaps > > > > >> > >>>> others, for other projects. > > > > >> > >>>> > > > > >> > >>>> Unfortunately, this does not fix the issue in util. An > > > explicit cast > > > > >> > to > > > > >> > >>>> BundleWiring is still needed in the R43Worker class. The > > > 3.2-SNAPSHOT > > > > >> > >>>> version of maven-compiler-plugin has the same issue. So it > > > looks like > > > > >> > >>>> proceeding with this vote may be the only option for util. > > > > >> > >>>> > > > > >> > >>>> John > > > > >> > >>>> > > > > >> > >>>>> RE: [VOTE] Apache Aries release parent-1.1.0 > > > > >> > >>>>> > > > > >> > >>>>> +1 for upgrading the maven-compiler-plugin > > > > >> > >>>>> > > > > >> > >>>>> I've been trying to build using maven-compiler-plugin 3.1 > as > > > an > > > > >> > exercise > > > > >> > >>>>> for the past hour but can't figure out how to get it to > stop > > > using > > > > >> > 2.0.2. > > > > >> > >>>>> > > > > >> > >>>>> John > > > > >> > >>>>> > > > > >> > >>>>>> RE: [VOTE] Apache Aries release parent-1.1.0 > > > > >> > >>>>>> > > > > >> > >>>>>> After doing some further digging I've found we're using a > > > very old > > > > >> > >>>>>> (2.0.2) version of the maven-compiler-plugin. This is > over 6 > > > years > > > > >> > >>>>>> old and predates Java 7. Apparently nobody (including me) > > > thought to > > > > >> > >>>>>> try upgrading it. > > > > >> > >>>>>> The release we have here does work, in that it prevents a > > > compiler > > > > >> > >>>>>> warning that was being interpreted as an error. On the > other > > > hand > > > > >> > >>>>>> there are still other warnings that break the build. I'm > > > happy do do > > > > >> > >>>>>> some rework/respin upgrading the maven-compiler plugin, > or > > > to go > > > > >> > >>>>>> with the solution we have. > > > > >> > >>>>>> Tim Ward > > > > >> > >>>>>> ------------------- > > > > >> > >>>>>> Apache Aries PMC member & Enterprise OSGi advocate > > > > >> > >>>>>> Enterprise OSGi in Action ( > http://www.manning.com/cummins) > > > > >> > >>>>>> ------------------- > > > > >> > >>>>>> > > > > >> > >>>>>> > > > > >> > >>>>>>> Date: Fri, 3 May 2013 23:44:55 +0900 > > > > >> > >>>>>>> From: [email protected] > > > > >> > >>>>>>> To: [email protected] > > > > >> > >>>>>>> Subject: Re: [VOTE] Apache Aries release parent-1.1.0 > > > > >> > >>>>>>> > > > > >> > >>>>>>> after confirming poms, +1 > > > > >> > >>>>>>> > > > > >> > >>>>>>> Timothy Ward wrote: > > > > >> > >>>>>>>> This is a vote for the release of the aries parent > poms at > > > > >> > >>>>>> version 1.1.0. This is a significant fix, and is the > first > > > step in > > > > >> > >>>>>> getting Aries building properly with JDK 7. Individual > > > projects will > > > > >> > >>>>>> need to be updated to use these poms before they can be > > > successfully > > > > >> > >>>>>> built using Java 7. > > > > >> > >>>>>>>> The staging area is available here: https:// > > > > >> > >>>>>> > > > repository.apache.org/content/repositories/orgapachearies-167/ > > > > >> > >>>>>>>> Tags: > > > https://svn.apache.org/repos/asf/aries/tags/parent-1.1.0 > > > > >> > >>>>>>>> > > > > >> > >>>>>>>> > > > > >> > >>>>>>>> Note that this project only contains poms. Please > verify > > > the > > > > >> > >>>>>> source release for parent and the pom files for > > > default-parent, > > > > >> > >>>>>> java5-parent and java6-parent > > > > >> > >>>>>>>> This vote will remain open for at least 72 hours. > > > > >> > >>>>>>>> > > > > >> > >>>>>>>> > > > > >> > >>>>>>>> Tim Ward > > > > >> > >>>>>>>> ------------------- > > > > >> > >>>>>>>> Apache Aries PMC member & Enterprise OSGi advocate > > > > >> > >>>>>>>> Enterprise OSGi in Action ( > http://www.manning.com/cummins) > > > > >> > >>>>>>>> ------------------- > > > > >> > >>>>>>>> > > > > >> > >>>>>>> -- > > > > >> > >>>>>>> －－－－－－－－－－－－－－－－－－－－－－ > > > > >> > >>>>>>> Tang Yong > > > > >> > >>>>>>> Senior Engineer > > > > >> > >>>>>>> Glassfish Team Developer(OSGi&OSGi-JavaEE) > > > > >> > >>>>>>> OSGi Alliance Supporter > > > > >> > >>>>>>> Blog: http://osgizone.typepad.com/tangyong/ > > > > >> > >>>>>>> > > > > >> > >>>>>>> Nanjing Fujitsu NanDa Software Tec CO.,LTD > > > > >> > >>>>>>> http://www.fujitsu.com/cn/fnst > > > > >> > >>>>>>> Tel: +86-25-86630566-8310 > > > > >> > >>>>>>> Fax: +86-25-83317685 > > > > >> > >>>>>>> －－－－－－－－－－－－－－－－－－－－－－ > > > > >> > >>>>>>> > > > > >> > > > > > > >> > > > > > >> > -- > > > > >> > －－－－－－－－－－－－－－－－－－－－－－ > > > > >> > Tang Yong > > > > >> > Senior Engineer > > > > >> > Glassfish Team Developer(OSGi&OSGi-JavaEE) > > > > >> > OSGi Alliance Supporter > > > > >> > Blog: http://osgizone.typepad.com/tangyong/ > > > > >> > > > > > >> > Nanjing Fujitsu NanDa Software Tec CO.,LTD > > > > >> > http://www.fujitsu.com/cn/fnst > > > > >> > Tel: +86-25-86630566-8310 > > > > >> > Fax: +86-25-83317685 > > > > >> > －－－－－－－－－－－－－－－－－－－－－－ > > > > >> > > > > > >> > > > > > > > > > > > > > >
