I still think adding a new namespace only for such simple calculation is too heavy and not consumalbe for users..
Anyway, could anybody help with the release of * org.apache.aries.application/0.2.2-SNAPSHOT* *and org.apache.aries.util/0.2.1-SNAPSHOT* first? or chould anyone help check why I can not deploy artifacts to apache.snapshot? Maybe I can try release the 2 components. Geronimo does not have much time targeting the 3.0-beta release. thanks, -Rex 2011/9/7 Alasdair Nottingham <[email protected]> > If we release blueprint as is we will never be able to make the change as > we > would cause a major breaking change. I think we need to get this right > before a release is done. > > On 6 September 2011 04:37, Rex Wang <[email protected]> wrote: > > > 2011/9/6 Alasdair Nottingham <[email protected]> > > > > > On 1 September 2011 07:41, Valentin Mahrwald <[email protected] > > > >wrote: > > > > > > > Comments inline :) > > > > > > > > Kind regards, > > > > > > > > Valentin > > > > > > > > On 31 Aug 2011, at 20:02, Alasdair Nottingham wrote: > > > > > > > > > I'm sorry for being slow I'm on holiday with limited access to > email. > > > > > > > > > > The goal (I thought) was to ensure that the support for ${a+b} > would > > be > > > > > optional. When we make it optional we have two problems: > > > > > > > > > > 1. How do we make it optional (usually gate any call with a > > > > > Class.forName check to ensures we can load a class. > > > > > 2. How do we fail when the support isn't there and someone is > using > > > it. > > > > > > > > > > The first problem is trivial to fix, the latter is harder to > define. > > It > > > > > isn't until you build the bean that you find the ${a+b} doesn't > work > > > and > > > > > with lazy activation that could take a while. I would suggest that > if > > > we > > > > > have ${a+b} in use, and the apache-jexl bundle is not present, then > > the > > > > bean > > > > > creation would most likely fail (or you would get the wrong > > behaviour). > > > > This > > > > > is obviously not desirable. > > > > > > > > > > An alternative would be to make use of the default behaviour of > > > blueprint > > > > > for namespace extensions. By using a separate namespace to indicate > > the > > > > > desire to use this behaviour blueprint will delay initialisation of > a > > > > > bundle's blueprint container until the namespace is available. The > > > result > > > > > would be if apache-jexl is not present the namespace handler would > > not > > > be > > > > > registered and the blueprint container would not be configured. In > > > > addition > > > > > you can now register the namesake when apache-jexl becomes > available > > > > > allowing it to be brought up later. > > > > > > > > I think that this definitely the right way to go. In practical terms > > > though > > > > it might be quite a bit tricky to implement. > > > > In particular I am wondering how to link the usage of the extended > > > property > > > > replacement syntax to a namespace reference. I can think of > > > > the following ways to do this: > > > > > > > > a) Have two different property placeholder brackets like ${...} for > > the > > > > non-arithmetic one and $[...] for the one doing arithmetic. The > second > > > > one is defined via a tag from the new namespace. > > > > b) Support property placeholders only if we can support the whole > > shebang > > > > (which is kind of step back?) > > > > c) Have a kind of unrelated namespace import which we check for when > we > > > > decide whether to do arithmetic (that could be quite non-obvious to > the > > > > user). > > > > > > > > > > > The blueprint specification says any non-standard extensions to > blueprint > > > must be enabled via namespace handlers. I don't like the ext of cm > > > namespaces to require apache-jexl since it means more dependencies are > > > pulled in when they may never be used. > > > > > Hi Alasdair, > > Since the current code does not hard depend on the commons-jexl, and I > > think > > the only difference from your desire is adding a new namespace which can > > delay the blueprint container initialization if the commons-jexl is not > > present, > > I consider this as an improvement to the current solution. And I think it > > would be better to let user hold the option that if he would use the new > > namespace, and if he don't use it, the ${a+b} can still work. Hope the > > current solution meets the criteria to start release.. > > > > BTW, seems Aries community is not that active in last two month. Is there > > still a release manager help the release works? > > > > -Rex > > > > > > > > > > > > Looking at your options a) doesn't work because it isn't using > namespace > > > handlers, b) sucks big time and would mean to meat the spec we would > > need > > > apache-jexl and the whole point is to allow the spec to be implemented > > > without apache-jexl being required. So I think something like option c > > > should be gone for. For instance you could add an attribute in a > > > non-standard namespace that says to enable this capability. > > > > > > > > > > Is any of that what you were thinking of? > > > > > > > > > Does that make any sense? > > > > > > > > > > Alasdair > > > > > > > > > > On 30 August 2011 07:36, Rex Wang <[email protected]> wrote: > > > > > > > > > >> Sorry, I will add the corresponding tests. But I am not quite > > > > understanding > > > > >> your suggestion in Aries-727 of "use a different namespace to the > > ext > > > > >> one". The current implement add the ability to blueprint-ext and > > also > > > > >> blueprint-cm, because the CmPropertyPlaceholder is the subclass of > > the > > > > >> PropertyPlaceholder. Could a different namespace handle this? > > > > >> After the change is final, will definitely port it to the trunk. > > > > >> > > > > >> thanks, > > > > >> -Rex > > > > >> > > > > >> 2011/8/30 Alasdair Nottingham <[email protected]> > > > > >> > > > > >>> Hi, > > > > >>> > > > > >>> I'm not happy with the current fix for ARIES-727. There are no > > tests > > > > and > > > > >> as > > > > >>> I commented on the bug the dependency on jexl is not optional > when > > it > > > > >> should > > > > >>> be. It also doesn't exist in trunk which is dangerous. This > affects > > > the > > > > >>> programming model so it needs to be right. > > > > >>> > > > > >>> Alasdair Nottingham > > > > >>> > > > > >>> On 29 Aug 2011, at 23:17, Rex Wang <[email protected]> wrote: > > > > >>> > > > > >>>> Hi Devs, > > > > >>>> > > > > >>>> Geronimo 3.0-beta has passed the Java EE 6 full profile tck, and > > is > > > > >>> going > > > > >>>> to release soon. But some dependencies are from Aries project, > so > > we > > > > >> are > > > > >>>> requesting your supports to release the following 3 components > > with > > > > the > > > > >>>> important fixes to our users. Could anybody please help? > > > > >>>> > > > > >>>> *1. **org.apache.aries.application/0.2.2-SNAPSHOT* > > > > >>>> ARIES-521: handles zip files without directory entries > > > > >>>> ARIES-635: Move the resource bundle to the right directory > > > > >>>> ARIES-638: Logging improvements for AriesApplicationManagerImpl > > > > >>>> ARIES-667: OBRAriesResolver can return bundle information for > > > bundles > > > > >>> with > > > > >>>> higher version than expected > > > > >>>> ARIES-689: Application OBR resolution fails for optional imports > > > > >>>> ARIES-734: Back port improvements made to resolution error > > messages > > > in > > > > >>> OBR > > > > >>>> application resolver > > > > >>>> > > > > >>>> *2. org.apache.aries.util/0.2.1-SNAPSHOT* > > > > >>>> ARIES-667: OBRAriesResolver can return bundle information for > > > bundles > > > > >>> with > > > > >>>> higher version than expected > > > > >>>> > > > > >>>> *3. org.apache.aries.blueprint/0.3.2-SNAPSHOT* > > > > >>>> ARIES-727 support syntax : ${a+b} in blueprint-ext > > > > >>>> > > > > >>>> regards, > > > > >>>> -- > > > > >>>> Lei Wang (Rex) > > > > >>>> rwonly AT apache.org > > > > >>> > > > > >> > > > > >> > > > > >> > > > > >> -- > > > > >> Lei Wang (Rex) > > > > >> rwonly AT apache.org > > > > >> > > > > > > > > > > > > > > > > > > > > -- > > > > > Alasdair Nottingham > > > > > [email protected] > > > > > > > > > > > > > > > > > -- > > > Alasdair Nottingham > > > [email protected] > > > > > > > > > > > -- > > Lei Wang (Rex) > > rwonly AT apache.org > > > > > > -- > Alasdair Nottingham > [email protected] > -- Lei Wang (Rex) rwonly AT apache.org
