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 >>>> >>> >>> >
