I think I left out a step :-) and I'm not sure how people are currently packaging the extra files needed for a custom server.
I'm thinking that you would set up a kar project with all the extra files, configuration, etc as well as listing or including the bundles, so you can install e.g. servicemix on any karaf instance as a kar, and then also set up a karaf-assembly project that produces a custom distribution based on that kar as well as everything else you want in the server. The framework and full kars I added to assemblies/features combined with the new assemblies are one example of this technique, but maybe I should try it out on e.g. servicemix also as an example. Is it clear where the servicemix assembly is? thanks david jencks On Apr 9, 2011, at 11:41 AM, Achim Nierbeck wrote: > Hi David, > > >> I assume you are talking about the instructions for custom distributions >> here: >> >> http://karaf.apache.org/manual/2.2.0/developers-guide/custom-distribution.html >> > > yes, exactly > >> The process described here is hideously complex compared to what I'm >> proposing. To keep it available we need to keep the add-features-to-repo >> mojo. If, after comparing equivalent old and new style karaf assembly >> projects, someone wants to keep it, fine. > > well, it might be complex but most persons I know a very aware of how to > use the assembly plugin of maven on building a > nice little distribution :) > >> Conceptually the main difference I see between old and new styles is that >> the old style relies on unpacking an existing distro whereas the new style >> currently asks you to copy the list of features and kars that were assembled >> into the existing distro. I think I can set up an "uber feature" for each >> distro so there's only one feature going in, so in either style there would >> be exactly one artifact involved, but it might be a good idea to add an >> "unpack existing distro" mojo so the karaf-assembly packaging can also >> unpack something for you. In this case I think the new style would be >> equivalent to the old style except you'd list the features to add as maven >> dependencies instead of configuring them in the k-m-p plugin configuration, >> and you' leave out 99% of the configuration. >> >> Have you tried setting up a project to do a new-style assembly? > > No I didn't yet, but will give it a try. I just realized this big change. > > > regards, Achim > >> thanks >> david jencks >> >> >> On Apr 9, 2011, at 10:03 AM, Achim Nierbeck wrote: >> >>> Hi all my comments in-line >>> >>> regards, Achim >>> >>>> Karaf is complete atomic and standalone OSGi container. >>>> >>>> It should run by itself (and it's still the case). >>>> >>> full ack, for just using camel you don't need anything else. This just >>> as a quick description on how I am using Karaf very often. >>> >>> >>>> I think it's more logic for the projects to be build on top. Anyway, >>>> I'm not against this new change as it could get life easy in the project. >>>> David, did you launch a thread in the past on this mailing list, or >>>> updated a wiki page describing this new philosophy ? Sorry if the >>>> question is stupid, maybe I missed some messages, but I don't remember >>>> lot of discussion on these changes. >>>> >>> I did see some mail-threads touching parts of this, but somehow I was >>> missing the big picture beforehand. >>> IMHO for me this move was quite fast and a better discussion could have >>> been helpful. >>> >>> >>>> Let me make some try to have a better understanding. Anyway, I didn't >>>> see any change on the manual around the "Karaf Custom Distribution" >>>> section. It should be introduce and described in the manual. >>>> >>> We surely need some very good documentation on this move, because we >>> already have a description for how to build a custom distributions and >>> people are already using it to make their own custom distribution. I >>> used to do this at my former company >>> and I'm sure the guys doing it now will get kind of upset if they have >>> to change a lot on how to make a custom distribution. >>> Just my 2 cent. >>> >>>> I will do that regarding my tests on ServiceMix. >>>> >>>> Thanks >>>> Regards >>>> JB >>>> >>>> On 04/08/2011 09:15 PM, David Jencks wrote: >>>>> I'd like to suggest that it would be more appropriate for other >>>>> projects such as servicemix to have one or more karaf-assembly >>>>> packaging projects similar to the apache-karaf-framework or >>>>> apache-karaf-full assemblies but including exactly the content >>>>> wanted, rather than starting with a distributed karaf server and >>>>> modifying it. That was more or less the point of introcuding the >>>>> karaf-assembly packaging. >>>>> >>>>> This is a pretty dramatic change in philosophy of what karaf is and >>>>> how to use it, but I think it is easier to use and a lot more >>>>> flexible. I think of karaf more as a way to construct servers rather >>>>> than as a particular set of content in a server. >>>>> >>>>> thanks >>>>> david jencks >>>>> >>>>> On Apr 8, 2011, at 10:55 AM, Jean-Baptiste Onofré wrote: >>>>> >>>>>> Before, I will check the impact on some other projects, especially >>>>>> around the groupId/artifactId used. >>>>>> >>>>>> We made a mistake by changing the groupId/artifactId of features, I >>>>>> don't wanna to have the same issue with the distribution assemblies. >>>>>> Projects like ServiceMix use the Karaf distribution in their own >>>>>> assembly. At least, we need to document the new Mojo, the new >>>>>> distro, etc. >>>>>> >>>>>> I'm gonna make some tests with ServiceMix and I will keep you posted. >>>>>> >>>>>> Regards >>>>>> JB >>>>>> >>>>>> On 04/08/2011 07:45 PM, David Jencks wrote: >>>>>>> I'd like to suggest that we remove the old assemblies/apache-karaf >>>>>>> and use instead the assemblies/apache-karaf-minimal and >>>>>>> apache-karaf-full assemblies constructed using the new mojos. I >>>>>>> think we can also remove a lot of mojos from the karaf-maven-plugin. >>>>>>> >>>>>>> With the exception of some configuration files, legal files, the >>>>>>> demo files, and the inclusion of o.a.k.shell.ssh in the old minimal >>>>>>> assembly by error, the contents of the corresponding new and old >>>>>>> assemblies are the same. A few more bundles start in the newer >>>>>>> servers but I think these are errors similar to the inclusion of >>>>>>> ssh in the minimal assemblies. It would be great if someone more >>>>>>> familiar with karaf history than I would investigate the >>>>>>> differences and advise about what to do. Basically I assume that >>>>>>> all the bundles in system should be started, so the choices are to >>>>>>> remove the extra bundles from system or to decide that indeed their >>>>>>> presence is correct. >>>>>>> >>>>>>> I'm not sure what to do with the demos. It's easy enough to write >>>>>>> a kar file that will unpack the demo content so it will look just >>>>>>> as it does today, but what's there strikes me as sort of horrible. >>>>>>> I don't really expect a server image to include maven projects that >>>>>>> I can build to add functionality. I think that it would be a lot >>>>>>> more appropriate to have a customization maven archetype that will >>>>>>> generate a full-featured customization project, and one or two demo >>>>>>> features that can install prebuilt demo applications. >>>>>>> >>>>>>> I'm thinking about how best to install legal files into assemblies >>>>>>> and hope to have a suggestion in the next few days. >>>>>>> >>>>>>> The current apache-karaf builds some kind of source distribution. >>>>>>> I haven't looked into exactly what it is but suggest that the >>>>>>> source distros produced by the apache release profile are sufficient. >>>>>>> >>>>>>> Related to this suggestion I think it would be great if some of the >>>>>>> other projects that use karaf such as servicemix, activemq, >>>>>>> directory (?) tried out the new packagings to build custom server >>>>>>> assemblies. I will try to write up some documentation and maven >>>>>>> archetypes for this in the next few days. >>>>>>> >>>>>>> thoughts? >>>>>>> >>>>>>> thanks >>>>>>> david jencks >>>>>>> >>>>>>> >>>>>>> >
