-1 I'm with JB here, I didn't realize that those "half" empty jars are supposed to be the replacements
2011/4/11 Jean-Baptiste Onofré <[email protected]>: > 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 >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >> >> > >> >> >> >> > > >
