On 6/25/07, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>From: "Craig McClanahan" <[EMAIL PROTECTED]>
>
> Sorry for the late response ... still catching up from a backlog due
> to being on the road for most of May. Comments below.
>
> On 6/22/07, Rahul Akolkar wrote:
> > On 6/22/07, Gary VanMatre wrote:
> > > >From: "Greg Reddin"
> > > >
> > > > On 6/22/07, Rahul Akolkar wrote:
> > > > >
> > > > > On 6/22/07, Matthias Wessendorf wrote:
> > > > > > hi,
> > > > > >
> > > > > > are there any plans for 1.1.0 release ?
> > > > > >
> > > > >
> > > > > As an aside, IMO its worthwhile to have a v1.0.5 as well so we can
> > > > > attempt to go GA in the 1.0.x line. Opinions?
> > > >
> > >
> > > For the most part, the trunk and 1_0_x branch are the same. I can only
> think of one commit that was not made to the both. I'd like to see us move the
> trunk to JSF 1.2 and then we could mix in the annotations as part of the base
> libraries.
> > >
> >
> >
> > shale-dialog has considerable deltas (the helper class, some new
> > listener methods etc. -- many @since 1.1.0 tags if you dig into the
> > code). This was under the understanding that no new features went into
> > the 1.0.x line after v1.0.4.
> >
> > If we want to move trunk to JSF 1.2, that should either happen at
> > v1.1.0 or should wait for the next line of development (v1.2.0) IMO.
> > Depending on JSF versions and when currently unreleased new features
> > frum trunk get released, here are the potential release scenarios:
> >
> > SCENARIO A:
> >
> > 1.0.x --> JSF 1.1, no new features beyond v1.0.4
> > 1.1.x --> JSF 1.1, seeded from current trunk
> > 1.2.x --> JSF 1.2
> >
> > SCENARIO B:
> >
> > 1.0.x --> JSF 1.1, no new features beyond v1.0.4
> > 1.1.x --> JSF 1.2, seeded from current trunk
> >
> > SCENARIO C:
> >
> > 1.0.x --> JSF 1.1, merge current deltas (mostly dialog new features) from
> > trunk in 1.0.x line
> > 1.1.x --> JSF 1.2, seeded from current trunk
> >
> > Preferences?
> >
>
> My personal preference would be for scenario A over scenario B or C,
> but with a twist ... target the JSF 1.2 based stuff for a 2.x release
> series, rather than 1.1 or 1.2. Why? Because a redesign of the
> existing APIs to take JSF 1.2 into account (and therefore also become
> dependent on Java SE 5) is very likely to require some significant
> changes (just as one example, much of "tiger" basically goes away and
> becomes part of the core functionality in "view" and other places), so
> upping the major version number would be more appropriate.
>
I'd like also like to see the annotation processor moved to the core with
a pluggable way to register handlers. It seems silly to scan the classpath
multiple times for each library that might have future annotations. Maybe
a commons chain would be a good way to register annotation handlers?
Silly it may be, the alternative seems to be everyone agreeing to use
a common "low level" library to abstract away the very real
differences between what kinds of annotations different projects would
look for. That should work about as successfully as Commons Logging
has :-).
More seriously:
* What is really important is a way to scan for runtime
annotations that does not require loading all the classes
in a way that runs all the static initializers.
* It turns out that there is such a scheme to look at ...
the Class.forName() variant of class loading (at least;
hopefully there are others as well so you can do the discovery
from a parent class loader) that does exactly this. Thanks to
Bob Lee of Google for a pointer to look at this (which is the
mechanism Google Guice uses).
Craig
