Please don't get me wrong, I'm not criticizing your work and I want to thank you for what you did. I'm just trying to bring karaf into a state where we can release 2.2. See comments inline.
On Fri, Feb 4, 2011 at 00:20, David Jencks <[email protected]> wrote: > 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 know it would be better for various reasons, but given we don't really produce dozens of different assemblies, do we really have to eat our own dog food ? Can we just keep the current distributions (minimal and default) and have the plugin create custom distribution on top of the minimal one ? That would allow us to keep a straightforward release process while still delivering a usable plugin to our downstream users I think. Another option would be to reuse the goals of the features maven plugin without reusing the packaging. Does that seem possible ? I'll try to investigate that. > 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. I do get that point. The location in the svn tree is just a minor problem, but I'd rather move everything into trunk/assemblies somehow and keep the trunk/features folder for the implementation of features, not features definition or usage. So what about: moving trunk/assembly to trunk/assemblies/ moving trunk/features/assembly/* into trunk/assemblies Then, depending on what we decide with the first point, we can work on making the trunk/assemblies better. > Other than not producing exactly the same contents as the existing > assemblies, what keeps the new stuff from being usable? It's only based on the fact that assemblies/apache-karaf doesn't build for me, but i haven't investigated the issue yet. > 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 > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
