Thanks David will look into this later this night :) regards, Achim
2011/4/20 David Jencks <[email protected]>: > Achim sent me his framework directory privately at which point I discovered > that git had not checked in the bin directories in framework and full. I > found that my local copies still had .svn files in them... does that confuse > git into thinking the directories don't exist? Even after I removed the .svn > files git didn't notice them.... > > I added the files by hand to my svn checkout and checked them in so they > should be available now. When I tried git svn rebase it finally noticed the > files and said > > error: The following untracked working tree files would be overwritten by > checkout: > <the files it didn't notice previously or indeed after the rebase attempt> > > I guess git is not entirely bug free. > > Anyway maybe others will be able to build new-style server assemblies now. > > thanks > david jencks > > On Apr 19, 2011, at 12:36 PM, David Jencks wrote: > >> Hi Achim, >> >> I looked over the kar archiving code and didn't see anything mac or osx >> specific so I think I'm going to need some help investigating what's going >> on on other systems. Maybe if you or someone could zip up the target folder >> of the framework kar and send it to me I could try and think of a clue of >> what is going wrong.... >> >> thanks >> david jencks >> >> On Apr 19, 2011, at 11:53 AM, Achim Nierbeck wrote: >> >>> Hi David, >>> >>> thanks for fixing :) >>> >>> I'm partially trying to get 2.2.1 going, that's probably why 3.0 >>> doesn't get a good testing :) >>> By the way of testing, last time I looked into the kar produced >>> artifacts, the bin folder wasn't still included. >>> >>> regards, Achim >>> >>> 2011/4/19 David Jencks <[email protected]>: >>>> I looked into this more and found that I'd made the default start value >>>> false rather than true in the jaxb model. I added some comments to the >>>> schema copes and fixed this, now features appear to start automatically >>>> when installed. >>>> >>>> This problem didn't have anything to do with boot features.... which >>>> indicates to me that trunk is not getting any significant testing..... not >>>> a good sign if we want to release it soon. >>>> >>>> thanks >>>> david jencks >>>> >>>> On Apr 19, 2011, at 4:32 AM, Christian Schneider wrote: >>>> >>>>> +1 >>>>> For auto starting features by default >>>>> >>>>> Christian >>>>> >>>>> >>>>> Am 19.04.2011 09:05, schrieb Achim Nierbeck: >>>>>> hm, >>>>>> >>>>>> I only have one open question, the other "standard" features like war >>>>>> and webconsole, when I install those features the bundles stay in >>>>>> installed state, and some >>>>>> of those bundles are supposed to be system bundles, e.g. the web >>>>>> console bundle. I kind of miss the standard behaviour of installing a >>>>>> feature and all bundles are up and running. How do we get around that? >>>>>> And actually the current behavior of installing a feature and those >>>>>> features are right available is one of the best things about the >>>>>> features. I'd rather like to see it the other way round. >>>>>> >>>>>> Default behavior should be the same as before, if a feature is >>>>>> installed all bundles are started right away, if I don't want it that >>>>>> way I need to add a special flag like --nostart or something. >>>>>> >>>>>> regards, Achim >>>>>> >>>>>> 2011/4/19 David Jencks<[email protected]>: >>>>>>> In r1094800 I adopted these ideas. The biggest change to review is >>>>>>> adding a "forceStart" option to the FeaturesService options. This is >>>>>>> so we can assure that all bundles in boot features get started. I >>>>>>> thought I remembered a -s features:install option that would start all >>>>>>> the bundles, but it doesn't seem to be there today. If no one objects >>>>>>> to this enum option I think we should add the command option. >>>>>>> >>>>>>> In addition I made a new feature called "standard" in the standard >>>>>>> features which contains the stuff from framework that can easily be >>>>>>> installed as a boot feature. I also made the full kar's feature >>>>>>> installed as a boot feature. >>>>>>> >>>>>>> The servers (old and new) seem to start OK for me and have the expected >>>>>>> content. Please check for problems. >>>>>>> >>>>>>> thanks >>>>>>> david jencks >>>>>>> >>>>>>> On Apr 18, 2011, at 12:15 AM, David Jencks wrote: >>>>>>> >>>>>>>> I think there's a problem with boot features, and I think we don't see >>>>>>>> it with the old style assemblies because the bundles are in fact all >>>>>>>> listed in the startup.properties as well as as boot features. >>>>>>>> >>>>>>>> There are 3 bundles in other parts of the startup.properties that >>>>>>>> depend on Apache Karaf :: Management (3.0.0.SNAPSHOT): >>>>>>>> >>>>>>>> [ 14] [Installed ] [ ] [ 30] Apache Karaf :: Diagnostic >>>>>>>> :: Management (3.0.0.SNAPSHOT) >>>>>>>> [ 16] [Installed ] [ ] [ 30] Apache Karaf :: Features >>>>>>>> :: Management (3.0.0.SNAPSHOT) >>>>>>>> [ 19] [Installed ] [ ] [ 30] Apache Karaf :: Admin :: >>>>>>>> Management (3.0.0.SNAPSHOT) >>>>>>>> >>>>>>>> Even if I put the feature core bundle at start level 25 it installs >>>>>>>> the boot feature asynchronously so the management bundle isn't >>>>>>>> installed by the time these 3 bundles need it. >>>>>>>> I'm not 100% sure but I think this problem still occurs if I make the >>>>>>>> feature service install the boot features synchronously. I'm >>>>>>>> surprised but can't debug through it tonight. >>>>>>>> >>>>>>>> One possible fix might be to move more of this into boot features so >>>>>>>> there are no dependencies from startup.properties-started-bundles on >>>>>>>> boot feature bundles. This is a pretty big change to the structure of >>>>>>>> the minimal server. >>>>>>>> >>>>>>>> Also the boot features don't appear to be started by default unless I >>>>>>>> put start='true' into each bundle. >>>>>>>> >>>>>>>> Any suggestions? >>>>>>>> >>>>>>>> thanks >>>>>>>> david jencks >>>>>>>> >>>>>>>> >>>>>>>> On Apr 17, 2011, at 12:23 PM, David Jencks wrote: >>>>>>>> >>>>>>>>> Hi Guillaume, >>>>>>>>> >>>>>>>>> I think you are suggesting: >>>>>>>>> >>>>>>>>> 1. combine local-repo and system under a suitable name such as system >>>>>>>>> or repository. I'll use system for now. >>>>>>>>> >>>>>>>>> 2. have as little as possible in startup.properties. For instance >>>>>>>>> the startup.properties for minimal and full servers should be the same >>>>>>>>> >>>>>>>>> 3. everything else in the basic minimal and full servers should be >>>>>>>>> started through bootFeatures. We want to ensure that all the >>>>>>>>> required bundles are in the (single) repo. >>>>>>>>> >>>>>>>>> 4. generally to create a custom server you'll add (or maybe also >>>>>>>>> remove) more bootFeatures and make sure the bundles are installed >>>>>>>>> into the repo. >>>>>>>>> >>>>>>>>> This seems entirely reasonable to me. The only quibble I can think >>>>>>>>> of at the moment is that if everything is in startup.properties you >>>>>>>>> can look at one file and see everything that will be started in one >>>>>>>>> place. >>>>>>>>> >>>>>>>>> I'm not sure how it works right now, but with this approach I think >>>>>>>>> we'll want to make sure that when the features service starts it >>>>>>>>> installs all the boot feature bundles immediately so the framework >>>>>>>>> can use the start level specified in the features and the order >>>>>>>>> listed in bootFeatures won't matter. >>>>>>>>> >>>>>>>>> One situation this approach won't work for is if you need some >>>>>>>>> bundles started before the feature service itself. For instance if >>>>>>>>> you want jaxb 2.2 used everywhere you'd need to install the jaxb 2.2 >>>>>>>>> system with a lower start level than the feature service. So some >>>>>>>>> custom servers may need to alter the startup.properties compared to >>>>>>>>> the minimal server. While in this case I expect the jaxb 2.2 feature >>>>>>>>> I'll need will be in its own feature repo so it can be handled by >>>>>>>>> just listing it as a compile scope dependency, so its bundles will >>>>>>>>> get added to startup.properties, this kind of situation indicates to >>>>>>>>> me that startupFeatures can still be useful. >>>>>>>>> >>>>>>>>> I'll see if I run into any problems switching the new-style >>>>>>>>> assemblies to this approach. >>>>>>>>> >>>>>>>>> thanks! >>>>>>>>> david jencks >>>>>>>>> >>>>>>>>> >>>>>>>>> On Apr 17, 2011, at 12:00 PM, Guillaume Nodet wrote: >>>>>>>>> >>>>>>>>>> Note that I've recently enhanced the startup mecahnism to not >>>>>>>>>> *always* >>>>>>>>>> try to install the bundles listed in the startup.properties. >>>>>>>>>> Previously, they were always reinstalled at startup time. >>>>>>>>>> >>>>>>>>>> First, I don't really see the need for local-repo and system. I >>>>>>>>>> think we should just merge them. >>>>>>>>>> >>>>>>>>>> There's really no need for bootFeatures + startupFeatures. I think >>>>>>>>>> we >>>>>>>>>> should only have one mechanism. The original idea was that the >>>>>>>>>> core >>>>>>>>>> bundles are started with the startup.properties and everthing else >>>>>>>>>> installed using features, mostly through bootFeatures. Now that we >>>>>>>>>> have a better maven plugin, the plugin is able to do both, but this >>>>>>>>>> is >>>>>>>>>> a bit confusing. Note that there is some differences though: >>>>>>>>>> * bundles listed startup.properties have to be in the system repo as >>>>>>>>>> the real mvn url handlers can't be used >>>>>>>>>> * manually editing the statup.properties is much more tedious than >>>>>>>>>> changing the bootFeatures imho >>>>>>>>>> * you can't put bundles using wrap url handler in the >>>>>>>>>> startup.properties >>>>>>>>>> The third point is specially problematic I think. One possible use >>>>>>>>>> case that isn't really addressed yet is the ability to create a >>>>>>>>>> configuration where some features depend on url handlers that are >>>>>>>>>> provisioned by other features. Or, said another way, a feature can >>>>>>>>>> only be *installed* if a dependent feature is *started*. I think >>>>>>>>>> moving things back in the startup.properties will make such >>>>>>>>>> dependencies even harder to manage. >>>>>>>>>> >>>>>>>>>> I think I would have rathe gone the opposite direction and remove as >>>>>>>>>> much as possible from the startup.properties to use the bootfeatures >>>>>>>>>> instead, but it may be just me. >>>>>>>>>> >>>>>>>>>> Just to understand the goal, what kind of benefit do you see by >>>>>>>>>> listing all bundles in the startup.properties ? I suppose we could >>>>>>>>>> get rid of the features service at runtime then, but apart from that, >>>>>>>>>> I'm not sure to see. >>>>>>>>>> >>>>>>>>>> On Sun, Apr 17, 2011 at 09:41, David Jencks<[email protected]> >>>>>>>>>> wrote: >>>>>>>>>>> Well, I think it may promote confusion, but there are now 3 options >>>>>>>>>>> for features in features repositories of maven runtime scope: >>>>>>>>>>> >>>>>>>>>>> startupFeatures. The bundles in these features will get installed >>>>>>>>>>> into system and listed in startup.properties >>>>>>>>>>> >>>>>>>>>>> bootFeatures: The bundles in these features will get installed into >>>>>>>>>>> local-repo and the feature names added to bootFeatures in the >>>>>>>>>>> features cfg file >>>>>>>>>>> >>>>>>>>>>> installedFeatures: The bundles in these features will get installed >>>>>>>>>>> into local-repo. >>>>>>>>>>> >>>>>>>>>>> For instance, >>>>>>>>>>> >>>>>>>>>>> <configuration> >>>>>>>>>>> <startupFeatures> >>>>>>>>>>> <feature>ssh</feature> >>>>>>>>>>> <feature>config</feature> >>>>>>>>>>> <feature>management</feature> >>>>>>>>>>> </startupFeatures> >>>>>>>>>>> </configuration> >>>>>>>>>>> >>>>>>>>>>> Note that except for startupFeatures the bundles are installed into >>>>>>>>>>> local-repo. I think system should only have bundles started from >>>>>>>>>>> startup.properties in it. >>>>>>>>>>> >>>>>>>>>>> thoughts? >>>>>>>>>>> >>>>>>>>>>> thanks >>>>>>>>>>> david jencks >>>>>>>>>>> >>>>>>>>>>> On Apr 16, 2011, at 12:50 PM, Johan Edstrom wrote: >>>>>>>>>>> >>>>>>>>>>>> For me it'd be the same logic as not "starting" everything from >>>>>>>>>>>> tomcats endorsed lib and >>>>>>>>>>>> just deploying WAR file, perhaps a little convoluted comparison, >>>>>>>>>>>> but the features additions, adding >>>>>>>>>>>> things and keeping "application" vs. features does make it simpler >>>>>>>>>>>> to manage as your features and deployments grow. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Apr 16, 2011, at 1:05 PM, David Jencks wrote: >>>>>>>>>>>> >>>>>>>>>>>>> If the same bundles all get started when you start the server, >>>>>>>>>>>>> what is the difference? I think you've "designed" the server you >>>>>>>>>>>>> want by including the bundles and indicating that you want them >>>>>>>>>>>>> started at server startup. How is it different whether the >>>>>>>>>>>>> bundles are started from startup.properties or the feature >>>>>>>>>>>>> service looking at boot features? >>>>>>>>>>>>> >>>>>>>>>>>>> thanks >>>>>>>>>>>>> david jencks >>>>>>>>>>>>> >>>>>>>>>>>>> On Apr 16, 2011, at 11:48 AM, Johan Edstrom wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> I really think that the startup.properties is for >>>>>>>>>>>>>> infrastructure, bluperint etc. >>>>>>>>>>>>>> the startup features allows you do "design" your own distro. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Apr 16, 2011, at 12:42 PM, David Jencks wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi JB, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks for the explanation, I think I've looked at things from >>>>>>>>>>>>>>> only the karaf-assembly point of view too long to see anything >>>>>>>>>>>>>>> else :-) The way karaf-assembly works now, all the bundles in >>>>>>>>>>>>>>> system will be listed in startup.properties and will start >>>>>>>>>>>>>>> automatically. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think you are saying: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- if you include a feature in the boot feature list, you >>>>>>>>>>>>>>> should make sure all the bundles needed are in the server >>>>>>>>>>>>>>> already. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> and, looking more closely at the add-features-to-repo mojo I >>>>>>>>>>>>>>> see there's a<features> configuration element that lets you >>>>>>>>>>>>>>> specify features to install the bundles for. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm going to add that capability to the karaf-assembly >>>>>>>>>>>>>>> packaging. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There's another difference of style to resolve. I've set up >>>>>>>>>>>>>>> the karaf-assembly packaging so that whenever it installs a >>>>>>>>>>>>>>> featue, it adds the feature's bundles to startup.properties at >>>>>>>>>>>>>>> the appropriate start level. For "boot" features this means >>>>>>>>>>>>>>> that you don't need to list them in the features service >>>>>>>>>>>>>>> configuration "boot features" since they will be started via >>>>>>>>>>>>>>> the startup.properties. On the other hand you can't uninstall >>>>>>>>>>>>>>> this feature so easily. Is this an important difference? Do I >>>>>>>>>>>>>>> need to make a way to install a feature's bundles but not add >>>>>>>>>>>>>>> the bundles to startup.properties? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> many thanks >>>>>>>>>>>>>>> david jencks >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Apr 16, 2011, at 12:12 AM, Jean-Baptiste Onofré wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm not sure to follow you. bootFeatures property defines >>>>>>>>>>>>>>>> which features are started at Karaf bootstrap time. It allows >>>>>>>>>>>>>>>> user to start a fresh Karaf instance with a set of Karaf >>>>>>>>>>>>>>>> features loaded and installed. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> For instance, in ServiceMix, we have: >>>>>>>>>>>>>>>> - nmr feature as boot feature and we ship all required jar >>>>>>>>>>>>>>>> (using features-add-to-repo goal) in the system OBR >>>>>>>>>>>>>>>> - camel-nmr, cxf-nmr, etc are part of the NMR features but not >>>>>>>>>>>>>>>> in the boot features set. As we consider this kind of features >>>>>>>>>>>>>>>> as optional, we don't ship the features jar in the system OBR >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>>> JB >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 04/16/2011 08:32 AM, David Jencks wrote: >>>>>>>>>>>>>>>>> I am wondering why we have boot features in trunk. In >>>>>>>>>>>>>>>>> particular I think there is an inconsistency around the >>>>>>>>>>>>>>>>> management feature which is in the minimal boot feature list >>>>>>>>>>>>>>>>> and whose jars are in the minimal server assembly. On the >>>>>>>>>>>>>>>>> other hand the ssh full boot feature doesn't have all its >>>>>>>>>>>>>>>>> jars in the full server. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If a boot feature doesn't already have all its jars in the >>>>>>>>>>>>>>>>> server, won't this require internet access on initial startup? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If all the jars for a boot feature are already installed in >>>>>>>>>>>>>>>>> the server, why call it a boot feature, why not just start it >>>>>>>>>>>>>>>>> with the rest of the jars? For this question I may be biased >>>>>>>>>>>>>>>>> by looking at the packaging based assemblies where the >>>>>>>>>>>>>>>>> startup.properties is constructed from the features that are >>>>>>>>>>>>>>>>> installed into the server, so it is at least as east to >>>>>>>>>>>>>>>>> configure the assembly to just include the jars as to >>>>>>>>>>>>>>>>> configure a boot feature. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Am I missing something? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> thanks >>>>>>>>>>>>>>>>> david jencks >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Cheers, >>>>>>>>>> Guillaume Nodet >>>>>>>>>> ------------------------ >>>>>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>>>>> ------------------------ >>>>>>>>>> Open Source SOA >>>>>>>>>> http://fusesource.com >>>>>>>>>> >>>>>>>>>> Connect at CamelOne May 24-26 >>>>>>>>>> The Open Source Integration Conference >>>>>>>>>> http://camelone.com/ >>>>>>> >>>>> >>>>> -- >>>>> Christian Schneider >>>>> CXF and Camel Architect >>>>> SOPERA - The Application Integration Division of Talend >>>>> http://www.talend.com >>>>> >>>> >>>> >> > >
