I don't think realistically maven is ever likely to make a plugin built (for the first time) in a build usable in that build as an extension. So we can either use profiles and do some kind of preliminary build to make maven know about the next-version plugin before a release or figure out how to release the maven plugin independently of the rest of karaf. Since the plugin uses some karaf classes such as the feature service the second is not trivial. Unless someone has an idea how to do this I suggest we use the profile approach.
I have both been waiting for some feedback on what I've done so far and pulled off into some client work. I can spend a little more time in the next few days and see if I can more closely approximate the old assemblies with the new approach. I used features/assembles for the framework because it was already there. I don't think it's a very good idea to have feature or kar projects in the top level assemblies directory since they don't produce server images. features (top level) is already used. Some maven subprojects are going to produce features.xml and some kar files so "kar" doesn't seem ideal either. subsystems might conflict with a future osgi spec implementation(?) subassemblies might be plausible. Other than not producing exactly the same contents as the existing assemblies, what keeps the new stuff from being usable? thanks david jencks On Feb 3, 2011, at 2:45 PM, Guillaume Nodet wrote: > So where are we at with the assemblies ? > We currently have: > trunk/assembly (the still in use assemblies) > trunk/features/assembly/enteprise (contains a feature descriptor) > trunk/features/assembly/standard (contains a feature descriptor) > trunk/features/assembly/framework (supposed to be the minimal assembly?) > trunk/assemblies/apache-karaf (supposed to be the main distribution?) > > In all cases, I'm not really happy about having assemblies in > trunk/features and I'd like them moved to trunk/assemblies if > possible. > Second, this is not really usable yet, so do we plan to finish that > for 2.2 or postpone for 3.0 ? > Last, I'm still worried of having to split our release cycle in two > because of the maven plugin, so I'm not sure how we should deal with > that. > > THoughts? > > On Tue, Feb 1, 2011 at 10:23, Andreas Pieber <[email protected]> wrote: >> Ok, from my point of view we can move everything but the following issues >> >> 254, 338, 334 (optionally), 424 (including 401). >> >> kind regards, >> andreas >> >> On Mon, Jan 31, 2011 at 11:47:33AM -0330, Jamie G. wrote: >>> Hi All, >>> >>> We're rapidly approaching being able to cut a release candidate for >>> Apache Karaf 2.2.0. At this time I'd like to encourage everyone to >>> quickly review open issues in Jira for the 2.2.0 branch, and to test >>> their local snapshot builds and report any issues you encounter >>> (especially platform specific issues - i.e. IBM Java or WIndows). >>> >>> Apache Karaf 2.2.0 issue tracker (see issues tab for complete list of >>> open 2.2.0 issues): >>> https://issues.apache.org/jira/browse/KARAF/fixforversion/12315328 >>> >>> Cheers, >>> Jamie >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com
