Hi Holly, responses inline
Tim Ward ------------------- Apache Aries PMC member & Enterprise OSGi advocate Enterprise OSGi in Action (http://www.manning.com/cummins) ------------------- > Date: Tue, 7 May 2013 12:18:43 +0100 > Subject: Re: [CANCELLED] [VOTE] Apache Aries release parent-1.1.0 > From: holly.k.cumm...@googlemail.com > To: dev@aries.apache.org > > I'm afraid I still don't understand the requirement to release everything, > even after your detailed explanation, Tim. (Sorry!) > > 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. > 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. > 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 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. > > 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? > > 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 > > > >> > −−−−−−−−−−−−−−−−−−−−−− > > > >> > > > > >> > > > > > > > > >
