Hi guys, just to make this clear, I'm not against the changes David made, I also do think this could be a nice way of a reassembling karaf to the needs. On the other hand I'm also not against the assembly approach we have right now, and I'm pretty sure people using Karaf are using it to make it fit their needs, at least I used to do it that way.
To get the KAR reassembly approach flying we need to make sure 1) The assemblied Karaf behaves the same as before 2) All needed cfg/bat/ what ever files are included 3) We need a migration guide for people using the assembly aproach 4) is it still possible to use the "old" assembly approach, I think yes it still is therefore we need to make sure this still works 5) add a real good documentation to the manual why this way is so cool and how KAR files do help everybody using it :) Just my 2 cents, Achim 2011/4/12 Andreas Pieber <[email protected]>: > Hey, > > TBH i'm much in favor of David's approach. The entire kar thing is > something really cool allowing client projects to build their parts > (kars) and then simply assembly them together to one big part. There > might be some part's which are not perfect right now (and which will > need some more time to get rock-solid) but though I'm convinced that > this is the way to go... > > Kind regards, > Andreas > > 2011/4/12 Łukasz Dywicki <[email protected]>: >> >> Hi guys, >> At the start I wish notice that I am not enemy of David's changes. >> >> I just wish notice that assembly can be more modular than it is now. Maven >> assembly supports components which may be included to assemblies. Example of >> this you may find in my gist. [1] Why we just don't extract common things >> like fileSets and core dependencySets from assemblies to component >> descriptor and simply reuse it? We should allow other projects reuse these >> component descritors to make easier creating own assemblies with maven >> assembly plugin or karaf-assembly/distro packaging. Introducing new >> assemblies now conflicts with DRY, every new assembly contains same >> dependency sets. I did some prototype of re-structure of assembly >> descriptors for Karaf 2.2.x and I might port these changes to trunk to leave >> 2.2.x branch stable before release. >> >> Best regards, >> Lukasz >> >> [1] https://gist.github.com/915214 >> >> >> >>> Hi David, >>> >>> will do tonight, but isn't the zip the proper artefact which contains >>> the runtime? >>> >>> regards, Achim >>> >>> 2011/4/12 David Jencks <[email protected]>: >>>> can you look in karaf-framework-3.0.0-SNAPSHOT.kar ? >>>> >>>> jar tf >>>> assemblies/features/framework/target/karaf-framework-3.0.0-SNAPSHOT.kar >>>> |grep bin >>>> resources/bin/compon >>>> resources/lib/bin/ >>>> resources/bin/admin >>>> resources/bin/admin.bat >>>> resources/bin/client >>>> resources/bin/client.bat >>>> resources/bin/karaf >>>> resources/bin/karaf.bat >>>> resources/bin/shell >>>> resources/bin/shell.bat >>>> resources/bin/start >>>> resources/bin/start.bat >>>> resources/bin/stop >>>> resources/bin/stop.bat >>>> resources/lib/bin/karaf-client.jar >>>> >>>> thanks >>>> david jencks >>>> >>>> >>>> On Apr 11, 2011, at 3:00 PM, Achim Nierbeck wrote: >>>> >>>>> Hi, >>>>> >>>>> just did an update to the latest version in svn. >>>>> Build with clean install, but I still don't see any bin folder >>>>> >>>>> <moz-screenshot-5.png> >>>>> >>>>> >>>>> building on windows. >>>>> >>>>> regards, Achim >>>>> >>>>>> Hi, >>>>>> >>>>>> Looking back at my original message I might not have said quite what I >>>>>> thought I said... I know there are some gaps between new and old >>>>>> assemblies, and I was trying to start a discussion about them rather >>>>>> than suggest replacing the old with the current state of the new. >>>>>> >>>>>> I know the legal files and release notes are missing and need to be >>>>>> there, and hope to have a flexible solution soon. >>>>>> >>>>>> I'm wondering if I misunderstand you or if we are getting different >>>>>> build results. The bin directories are in all the new assemblies I >>>>>> build, with all the scripts (unix and windows) in both zip and tar.gz. >>>>>> The unix scripts in tar.gz have executable permissions and I can at >>>>>> least run bin/karaf. I have no way to test the windows scripts. e.g. >>>>>> >>>>>> jar tf target/apache-karaf-full-3.0.0-SNAPSHOT-bin.zip |grep bin >>>>>> apache-karaf-full-3.0.0-SNAPSHOT/bin/ >>>>>> apache-karaf-full-3.0.0-SNAPSHOT/lib/bin/ >>>>>> apache-karaf-full-3.0.0-SNAPSHOT/bin/admin >>>>>> apache-karaf-full-3.0.0-SNAPSHOT/bin/admin.bat >>>>>> apache-karaf-full-3.0.0-SNAPSHOT/bin/client >>>>>> apache-karaf-full-3.0.0-SNAPSHOT/bin/client.bat >>>>>> apache-karaf-full-3.0.0-SNAPSHOT/bin/karaf >>>>>> apache-karaf-full-3.0.0-SNAPSHOT/bin/karaf.bat >>>>>> apache-karaf-full-3.0.0-SNAPSHOT/bin/shell >>>>>> apache-karaf-full-3.0.0-SNAPSHOT/bin/shell.bat >>>>>> apache-karaf-full-3.0.0-SNAPSHOT/bin/start >>>>>> apache-karaf-full-3.0.0-SNAPSHOT/bin/start.bat >>>>>> apache-karaf-full-3.0.0-SNAPSHOT/bin/stop >>>>>> apache-karaf-full-3.0.0-SNAPSHOT/bin/stop.bat >>>>>> apache-karaf-full-3.0.0-SNAPSHOT/lib/bin/karaf-client.jar >>>>>> >>>>>> If this is not what you get.... what maven version are you using? I >>>>>> thought I set the minimum to 3.0.3 >>>>>> >>>>>> I agree that it would be better to name apache-karaf-full apache-karaf >>>>>> but don't think we can until we remove the old assembly. >>>>>> >>>>>> I believe these features files are in the old assemblies at these same >>>>>> locations: >>>>>> ./org/apache/karaf/assemblies/features/enterprise/3.0.0-SNAPSHOT/enterprise-3.0.0-SNAPSHOT-features.xml >>>>>> ./org/apache/karaf/assemblies/features/standard/3.0.0-SNAPSHOT/standard-3.0.0-SNAPSHOT-features.xml >>>>>> and are needed so the features in these feature repos are available. >>>>>> >>>>>> The other two are artifacts of assembling the server from the kar files >>>>>> that include the features files. If you think it's important I can make >>>>>> it so they aren't included but so far I've found them useful to check on >>>>>> the source of the entries in the generated startup.properties file. >>>>>> >>>>>> >>>>>> Hopefully we can figure out what's going on with the bin folder >>>>>> quickly... >>>>>> >>>>>> thanks >>>>>> david jencks >>>>>> >>>>>> On Apr 11, 2011, at 12:53 AM, Jean-Baptiste Onofré wrote: >>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>> I take a quick look on apache karaf (minimal and full) assemblies >>>>>>> generated with >>>>>>> the new MOJOs. >>>>>>> >>>>>>> I see the following issues: >>>>>>> - no information files are presents in the assemblies: README, NOTICE, >>>>>>> LICENSE, >>>>>>> RELEASE-NOTES >>>>>>> - no bin folder containing the startup scripts >>>>>>> - I think that the apache-karaf-full should be named apache-karaf, I'm >>>>>>> afraid to >>>>>>> loose the users the the full suffix. >>>>>>> - could you explain the function of all features files in system repo ? >>>>>>> system$ find . -name "*.xml" >>>>>>> ./org/apache/karaf/assemblies/features/enterprise/3.0.0-SNAPSHOT/enterprise-3.0.0-SNAPSHOT-features.xml >>>>>>> ./org/apache/karaf/assemblies/features/standard/3.0.0-SNAPSHOT/standard-3.0.0-SNAPSHOT-features.xml >>>>>>> ./org/apache/karaf/assemblies/features/karaf-full/3.0.0-SNAPSHOT/karaf-full-3.0.0-SNAPSHOT-features.xml >>>>>>> ./org/apache/karaf/assemblies/features/karaf-framework/3.0.0-SNAPSHOT/karaf-framework-3.0.0-SNAPSHOT-features.xml >>>>>>> >>>>>>> So in the current state, the new assemblies can not replace the "old" >>>>>>> one. >>>>>>> >>>>>>> The bin folder is a must have, also the README, NOTICE, etc. >>>>>>> >>>>>>> To summarize, here's my -1 to remove the "old" assembly for now. >>>>>>> >>>>>>> Regards >>>>>>> JB >>>>>>> >>>>>>> On Mon 11/04/11 07:42, "David Jencks" [email protected] wrote: >>>>>>>> I also added a simple karaf-feature-archetype. >>>>>>>> >>>>>>>> david jencks >>>>>>>> >>>>>>>> On Apr 10, 2011, at 2:38 PM, David Jencks wrote: >>>>>>>> >>>>>>>>> I didn't see where a smx assembly was being built so >>>>>>>> I spent a few minutes on plugin documentation. I think running mvn >>>>>>>> site in >>>>>>>> tooling/karaf-maven-plugin produces a reasonably informative >>>>>>>> result. >>>>>>>> >>>>>>>>> Are we publishing maven generated sites anywhere? >>>>>>>> I'm not always sure about regular projects' maven sites but the >>>>>>>> generated >>>>>>>> plugin documentation is usually pretty useful and I think that people >>>>>>>> expect to find it. >>>>>>>> >>>>>>>>> thanks >>>>>>>>> david jencks >>>>>>>>> >>>>>>>>> On Apr 9, 2011, at 1:47 PM, Achim Nierbeck >>>>>>>> wrote: >>>>>>>> >>>>>>>>>> my comments in-line :) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 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. >>>>>>>>>> the way I used to do it was to configure a maven >>>>>>>> project for assembly >>>>>>>>> and I configured all my extra bundles as >>>>>>>> dependency in this >>>>>>>>> project, using the assembly plug-in for maven. >>>>>>>> First step was to extract >>>>>>>>> the standard distro of Karaf, add some extra >>>>>>>> bundles >>>>>>>>> add some extra config files, changed some config >>>>>>>> files skipped some >>>>>>>>> config files of the original >>>>>>>> assembly. >>>>>>>>>>> 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. >>>>>>>>>> This is a nice idea, and this way I probably >>>>>>>> don't need to edit the >>>>>>>>> startup.properties anymore. I kind of like >>>>>>>> that. >>>>>>>>> As I already stated we need some very good >>>>>>>> documentation to get our >>>>>>>>> users into this boat :) >>>>>>>>>>> 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? >>>>>>>>>> For this you have to ask JB, he did the last >>>>>>>> release for ServiceMix. >>>>>>>>>>> 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-di >>>>>>>> stribution.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 >>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >> >> >
