On Fri, Feb 4, 2011 at 10:54, David Jencks <[email protected]> wrote: > > On Feb 3, 2011, at 10:21 PM, Guillaume Nodet wrote: > >> 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. > > Releasing 2.2 with the old assembly structure seems like a really good idea > to me. I don't think this will cause any problems for geronimo.
Ok, so I'll remove the assemblies from the branch I've just created. >> >> 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. > > I wonder how this would work. I need something that will produce a packaged > karaf server from a maven build that's really easy to set up. What I've > proposed is one really simple solution since it involves installing one kind > of artifact (kar files) and then packaging the result. If you start from > some kind of minimal server, you need to unpack it somehow before starting to > add more things to it. This seems possible but more complicated to me. > Maybe someone else sees a good way to do this that is not more complicated > than the all-kar approach. > >> >> 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'll be impressed if you can get this to work. It should be fairly easy to > run the appropriate mojos at the appropriate stages, but preventing the mojos > for any of the normal maven lifecycles from running could be more > challenging. Maybe enough of them have a "skip" parameter so that this will > work. > > I wonder if its possible to stabilize the karaf interfaces the maven plugin > uses (I think its now just the features service) so that we can release it > independently of the rest of karaf and put in the appropriate version of the > karaf feature jar etc in the plugin config as a dependency. Or maybe we could > copy the interface right into the plugin itself and include the karaf bundles > as dependencies in the configuration. > > This would still require two releases but at least they wouldn't be > interleaved so much. Possibly the maven plugin would be sufficiently stable > that it wouldn't need frequent releases. > >> >>> 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. > > Ok, but how about > > trunk/assemblies for actual assemblies > trunk/assemblies/features for feature and kar projects? > >> >>> 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. > > For me it looks like the first build attempt sometimes fails with a missing > felix fileinstall class but trying again succeeds. What do you see? > > thanks > david jencks > >> >>> 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 > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
