The packages in util are all API, which is why they need to be exported. Given that PropertyPlaceholder is exported so other people can extend it I would argue that also makes it API, although I would prefer to be able to hide the implementation details of blueprint.
Alasdair On 7 February 2011 19:20, Guillaume Nodet <[email protected]> wrote: > 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 > -- Alasdair Nottingham [email protected]
