Hi All, The package org.karaf.feature.core.internal.model might be generated and don't need to be stored in svn. This package will double changes related with XML Schema - we'll have to maintain classes and XML schema, with generated code we must maintain only schema.
Best regards, Lukasz -----Original Message----- From: Achim Nierbeck [mailto:[email protected]] Sent: Wednesday, March 09, 2011 10:17 AM To: [email protected] Cc: Andreas Pieber; Jean-Baptiste Onofré Subject: Re: Moving features jaxb tree to features core Also +1 for two interfaces 2011/3/9 Andreas Pieber <[email protected]>: > Also +1 for the two interfaces > > On Wed, Mar 9, 2011 at 8:17 AM, Jean-Baptiste Onofré <[email protected]> wrote: >> Agree for the two interfaces. >> >> Regards >> JB >> >> On 03/09/2011 08:08 AM, Guillaume Nodet wrote: >>> >>> I think for #4 it would make sense to use two interfaces. >>> >>> On Wed, Mar 9, 2011 at 01:58, David Jencks<[email protected]> wrote: >>>> >>>> I went ahead and committed this, let me know if there are any problems. >>>> It works fine for me so far.... >>>> >>>> I found the answer to (1) and (2) (feature event exports them) I >>>> think.... haven't had time to update for (3) and I'm still wondering about >>>> (4). >>>> >>>> thanks >>>> david jencks >>>> >>>> On Mar 4, 2011, at 5:02 PM, David Jencks wrote: >>>> >>>>> I spent a little time moving the jaxb tree for features.xml into >>>>> features core and getting it to work with features core. (and then a lot of >>>>> time trying to figure out how to get it onto my github branch. I think it's >>>>> on the "master" branch at https://github.com/djencks/karaf/branches) >>>>> >>>>> I have a few questions. >>>>> >>>>> 1. Why are the feature structure interfaces (Feature, BundleInfo, etc) >>>>> exported from feature core at all? >>>>> >>>>> 2. If they really need to be exported, is there a good reason to use >>>>> interfaces rather than the jaxb classes? >>>>> >>>>> 3. The schema allows 0..unbounded details elements since its an optional >>>>> member of a choice group. The original classes only allow one detail. I >>>>> guess we want to only allow one detail element? >>>>> >>>>> 4. There's only one Feature interface for both a complete feature (top >>>>> level in features element ) and a dependency feature inside a feature >>>>> element. The second one is more of a feature-ref since it doesn't have any >>>>> actual contents for the feature. I think it might be reasonable to have two >>>>> interfaces so as to distinguish these more easily. >>>>> >>>>> Does anyone want to review this or should I just go ahead and commit it? >>>>> >>>>> thanks >>>>> david jencks >>>>> >>>> >>>> >>> >>> >>> >> >
