In blueprint-cm, we have org.apache.aries.blueprint.compendium.cm.CmPropertyPlaceholder inheriting org.apache.aries.blueprint.ext.PropertyPlaceholder. That's the first reason i've seen, there may be others. Aries-utils is also full of packages with code (well, it's purpose is to share code, so that's kinda expected).
On Mon, Feb 7, 2011 at 20:12, Alasdair Nottingham <[email protected]> wrote: > If they aren't API then why are we exporting them? > > On 7 February 2011 16:53, Guillaume Nodet <[email protected]> wrote: >> On Mon, Feb 7, 2011 at 17:26, Timothy Ward <[email protected]> wrote: >>> >>> >>> >>>> >>>> Before we go in any particular direction we must agree, that's true. >>>> >>>> Is >>>> >>>> it >>>> >>>> possible to agree with these goals now: >>>> >>>> >>>> >>>> 1) As an OSGi project we must demonstrate best practice in our use of >>>> >>>> semantic versioning at bundle and package level >>>> >>> >>>> >>> Agreed, though I don't think there's much semantic implied at the >>>> >>> bundle >>>> >>> level. >>>> >>> >>>> >>>> 2) A build and release process which allows us to do >>>> >>>> (a) A release of everything in one go with associated samples which >>>> >>>> are >>>> >>>> therefore guaranteed to work together >>>> >>>> (b) Release by module - with the correctly versioned bundles of >>>> >>>> sub-modules >>>> >>>> (c) To avoid having to do release by sub-module (eg not having to >>>> >>>> do >>>> >>>> 17 >>>> >>>> separate release steps for blueprint) >>>> >>> >>>> >>> Well, those are side issues imho and I think they conflict with the >>>> >>> requirements I propose below. >>>> >>> >>>> >>> I'd rather have the following requirements: >>>> >>> 1. correct osgi semantic versioning >>>> >>> 2. a release must have a buildable source distribution (that's >>>> >>> really an asf requirement, as the source distribution *is* really the >>>> >>> release from an asf pov) >>>> >>> 3. a release should have some release notes listing the changes in >>>> >>> that release >>>> >>> 4. a release must be publicly announced >>>> >>> 5. users should have an easy way to download the bundles needed for >>>> >>> a given component (blueprint, etc...) >>>> >>> 6. easy tagging / branching mechanism >>>> >>> >>>> >> I'd also like to add those requirements: >>>> >> 7. a way to provide bug fix releases >>>> >> 8. a way to ensure that a given component does not have conflicting >>>> >> dependencies >>>> >> >>>> >> #7 is really important in my opinion, even more than #5 and #6. I >>>> >> can't even imagine how I would tell my customers I can't even do a bug >>>> >> fix release. >>>> >> >>>> >> #8 is about mitigating the dependency hell so that we actaully have >>>> >> the ability to deploy a component which does not require two >>>> >> dependencies with an incompatible version (i.e. for aries blueprint >>>> >> x.y we don't end up with requiring both aries-utils 1.x and >>>> >> aries-utils 2.x). This requirement is definitely not a must-have, but >>>> >> a nice to have, as it's really for ease of use and consumption of our >>>> >> components. >>>> >> >>>> >> I haven't heard any feedback so far, but I think starting from what we >>>> >> want is a better idea than investigating a technical solution now. At >>>> >> least discussing those requirements may end up to doing some >>>> >> compromise over others if they are somewhat incompatible (i..e we >>>> >> don't find a technical solution to solve all those requirements). >>>> > >>>> > I didn't reply earlier because: >>>> > >>>> > (a) I'm not sure what in your requirements conflicts exactly with my >>>> > original suggestions? In any case I'm quite happy to abandon my >>>> > suggestions >>>> > in favour of yours. >>>> > (b) I'm still trying to understand how we satisfy requirement "1. Correct >>>> > osgi semantic versioning" >>>> > >>>> > Requirement 2, 3, 4 are relatively easy to satisfy. >>>> > Requirements 5, 6, 7 are tied up in the semantic versioning discussion >>>> > and I >>>> > believe that if we choose to implement semantic versioning there are at >>>> > least some implications for the way in which we meet requirements 5, 6, >>>> > and >>>> > 7. Not sure about 8. >>>> > >>>> > So, as a list of requirements I don't think there is too much >>>> > disagreement, >>>> > although perhaps other people would like chip in with their views. >>>> > As I said, the reason for experimenting is about how to satisfy >>>> > requirement >>>> > 1 with the others. I feel that it's rather poor form that we (as an OSGi >>>> > project) don't meet requirement 1 at the moment :-) >>>> > >>>> >>>> Well, given I still haven't understood how we're going to release >>>> things (per bundle or per component, as it seems a single whole >>>> release hasn't really received much support), I think our current >>>> layout conflict with #6 and we still haven't found a clear way to >>>> align #1 with #7 afaik. >>> >>> #1 and #7 are compatible as long as you don't change your API in an >>> incompatible way (for anyone). This should be a requirement of an "in >>> service" fix anyway so it isn't restrictive. Subsequent releases can export >>> at the same version (assuming it contains the fix) or increment the micro >>> version again if needs be. If you've written your bundles well the fix is >>> very unlikely to affect a package version anyway, requiring only a micro >>> increment to the bundle version. This doesn't seem incompatible with #7 at >>> all. >> >> That's would only work if we have package versions on pure API >> packages only. We have several bundles that export packages that are >> not real API and which contain code. We're not talking about an ideal >> world here, but about real code. >> >>> >>> Tim >>> >>>> >>>> > Zoe >>>> >> >>>> >> >>>> >> >>>> > >>>> > >>>> >>>> >>>> >>>> -- >>>> Cheers, >>>> Guillaume Nodet >>>> ------------------------ >>>> Blog: http://gnodet.blogspot.com/ >>>> ------------------------ >>>> Open Source SOA >>>> http://fusesource.com >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> > > > > -- > Alasdair Nottingham > [email protected] > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
