If the general consensus is that we don't need to worry about having release dependencies buildable using JDK7 then I'm happy to just do releases for parent, util, blueprint-core and blueprint bundle (being the things we actually want to release right now). It's definitely a lot less work.
Tim Ward ------------------- Apache Aries PMC member & Enterprise OSGi advocate Enterprise OSGi in Action (http://www.manning.com/cummins) ------------------- > Date: Tue, 7 May 2013 16:33:49 +0100 > Subject: Re: [CANCELLED] [VOTE] Apache Aries release parent-1.1.0 > From: holly.k.cumm...@googlemail.com > To: dev@aries.apache.org > > 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 <timothyjw...@apache.org > > >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: jpjhug...@gmail.com > > > > > Date: Tue, 7 May 2013 09:19:35 +0100 > > > > > Subject: Re: [CANCELLED] [VOTE] Apache Aries release parent-1.1.0 > > > > > To: dev@aries.apache.org > > > > > > > > > > Hi Tim, > > > > > > > > > > On 6 May 2013 20:42, Timothy Ward <timothyjw...@apache.org> 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: david.bosscha...@gmail.com > > > > > >> Date: Mon, 6 May 2013 15:51:22 +0100 > > > > > >> Subject: Re: [VOTE] Apache Aries release parent-1.1.0 > > > > > >> To: dev@aries.apache.org > > > > > >> > > > > > >> +1 from me too. > > > > > >> > > > > > >> David > > > > > >> > > > > > >> > > > > > >> On 4 May 2013 05:29, Tang Yong <tangy...@cn.fujitsu.com> 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: tangy...@cn.fujitsu.com > > > > > >> > >>>>>>> To: dev@aries.apache.org > > > > > >> > >>>>>>> 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 > > > > > >> > −−−−−−−−−−−−−−−−−−−−−− > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > > > > >
