On Mon, Feb 4, 2013 at 10:46 AM, Gert Vanthienen <[email protected]> wrote: > Guillaume, > > > Bundles and specs are usually released separately these days and they have > a completely different release cycle than the container, so I would keep > those as they are today. > > I was mainly thinking about Features itself and the things we usually > release together with that (Utils, Components, NMR, Archetypes). If we > could strip that down to a single maven build for the container itself and > drop the JBI/NMR bits, we should be able to do those container builds more > quickly and easily, making it easier to stay up-to-date with all other > dependency versions (Karaf, Camel, CXF, ...) > > > Regards, > > Gert Vanthienen >
+1 Sounds good if it becomes easier to cut new SMX releases (as well patch releases). > > On Mon, Feb 4, 2013 at 9:16 AM, Guillaume Nodet <[email protected]> wrote: > >> Are you also talking about moving back everything in a single subproject ? >> So that the release would only consist in a single maven release ? >> If so, I'm not sure we can easily do that for bundles (which are used by >> downstream projects), and also the specs (which are used by Karaf). >> >> >> On Sun, Feb 3, 2013 at 9:54 PM, Gert Vanthienen >> <[email protected]>wrote: >> >> > L.S., >> > >> > >> > About a year and a half ago, we had some discussions on the mailing list >> > about a plan for Apache ServiceMix 5.0 and had some initial commits to >> > build the additional services and functionality. Since then however, >> none >> > of us have actually had the time to work on that code or move things >> > forward. >> > >> > In the meanwhile, we are also struggling constantly to get our releases >> > done in timely fashion. The latest 4.5.0 release took almost 9 months >> > since the first mention of it on the dev@ list. Doing a ServiceMix >> > release >> > now is quite a task: it usually involves doing releases in 5 or 6 >> > subprojects. >> > >> > I would like to propose a new plan for Apache ServiceMix 5.0. Instead of >> > doing a lot of new development, how about we start with the current 4.x >> > features codebase and remove everything that's related to JBI and the >> NMR. >> > That will give us a nice and simple integration container build (based >> on >> > Karaf, Camel, CXF, ActiveMQ, ...) and everything is living in a single >> > project that's quick and easy to release. >> > >> > If we start doing this now, we could get a build out with Karaf 2.3.0, >> > ActiveMQ 5.8.0, Camel 2.11.0 (which will bring in Scala 2.10 and opens up >> > the possibility to include the Akka OSGi examples I built a few months >> ago) >> > pretty soon after those versions are available. With only one project >> to >> > maintain the versions of all those dependencies, we should be able to >> > follow up more regularly as our sibling projects do (new) fix releases as >> > well. >> > >> > We don't have to throw away the existing ServiceMix 5.0 code by the way, >> we >> > can always move that into a separate branch and then cherry-pick the >> useful >> > bits afterwards, but I think our first goal now should be to get >> ourselves >> > in a position that we can actually build and release stuff more easily >> > again. >> > >> > >> > Wdyt? >> > >> > Gert Vanthienen >> > >> >> >> >> -- >> ------------------------ >> Guillaume Nodet >> ------------------------ >> Red Hat, Open Source Integration >> >> Email: [email protected] >> Web: http://fusesource.com >> Blog: http://gnodet.blogspot.com/ >> -- Claus Ibsen ----------------- Red Hat, Inc. FuseSource is now part of Red Hat Email: [email protected] Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
