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. >> >> 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.
I'm just thinking about not using the packaging inside the karaf build, but actually producing the same artifacts using the goals directly. The problem here is really about using the packaging inside the same build, reusing the goals should produce the same output without those problems, no ? Geronimo and other downstream users would definitely use kars and the new packaging. > >> >> 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
