You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <fl...@gmail.com> on 2007/02/07 02:07:22 UTC
[all] Status of components
I made a stab of defining the current status for Commons for the
Jakarta board report:
http://wiki.apache.org/jakarta/JakartaBoardReport-current
Here's the summary. Any thoughts on the ?? marks and the dormancy
candidates? Feel free to add things to the wiki page. I've not added
all of this yet.
Attributes - Needs a new release, after that a dormancy candidate.
BeanUtils - Inactive. 1.8.0 slowly being worked on.
Betwixt - Just released.
Chain - ??
CLI - Inactive. Dormancy candidate?
Codec - Inactive.
Collections - Inactive - new releases discussed but not much movement.
Configuration - Active.
Daemon - ?? Dormancy candidate?
DBCP - 1.2.2 release in the works.
DbUtils - 1.1 release made. No plans for 1.2.
Digester - ??
Discovery - 0.4 release made, nothing new planned. Dormancy candidate.
EL - ?? Dormancy candidate?
Email - Maybe a 1.1 release in the works. Not much activity yet.
FileUpload - 1.2 release in the works.
IO - 1.3 just released.
Jelly - ?? Dormancy candidate?
Jexl - ?? Dormancy candidate?
JXPath - ?? Dormancy candidate?
Lang - 2.3 release in the works.
Launcher - Inactive. Dormancy candidate.
Logging - Needs a 1.1.1 release, no plans beyond that.
Math - Slow activity.
Modeler - Inactive - dormancy?
Net - New JDK 1.5 version in the works.
Pool - New version in the works.
Primitives - Inactive. Dormancy candidate?
SCXML - Active, just released.
Transaction - Release being discussed.
Validator - Active.
VFS - Active and releasing.
Dormant - Nothing likely to leave dormancy.
Sandbox - Nothing that looks like moving to proper anytime soon. Some
for dormancy (finder, id).
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Status of components
Posted by Henri Yandell <fl...@gmail.com>.
On 2/8/07, sebb <se...@gmail.com> wrote:
> On 07/02/07, Henri Yandell <fl...@gmail.com> wrote:
> > I made a stab of defining the current status for Commons for the
> > Jakarta board report:
> >
> > http://wiki.apache.org/jakarta/JakartaBoardReport-current
> >
> > Here's the summary. Any thoughts on the ?? marks and the dormancy
> > candidates? Feel free to add things to the wiki page. I've not added
> > all of this yet.
> >
> > Attributes - Needs a new release, after that a dormancy candidate.
> > BeanUtils - Inactive. 1.8.0 slowly being worked on.
> > Betwixt - Just released.
> > Chain - ??
> > CLI - Inactive. Dormancy candidate?
>
> JMeter is currently using the same code as the Avalon CLI - which is
> mixed up in the rest of CLI2. There have been no reported problems
> for the CLI in JMeter for a long time now.
>
> It is not the same animal as CLI and CLI2, so perhaps it should be
> moved somewhere else? Can it be made a separate mini project in
> Commons?
>
> Seems a shame that the only use of the code is in JMeter at present.
>
> Once it has been released, it can remain happily in maintenance mode...
>
> I'm happy to do the work.
Split off from CLI2 a while ago :)
http://svn.apache.org/repos/asf/jakarta/commons/proper/cli/branches/avalon-implementation/
> > Jexl - ?? Dormancy candidate?
>
> We're using it in JMeter.
I think a lot of people are. Maybe we need a better name than
Dormancy, it seems to imply dead to people when in fact the idea is
that things wake up from dormancy if someone wants to be active on it.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Status of components
Posted by sebb <se...@gmail.com>.
On 07/02/07, Henri Yandell <fl...@gmail.com> wrote:
> I made a stab of defining the current status for Commons for the
> Jakarta board report:
>
> http://wiki.apache.org/jakarta/JakartaBoardReport-current
>
> Here's the summary. Any thoughts on the ?? marks and the dormancy
> candidates? Feel free to add things to the wiki page. I've not added
> all of this yet.
>
> Attributes - Needs a new release, after that a dormancy candidate.
> BeanUtils - Inactive. 1.8.0 slowly being worked on.
> Betwixt - Just released.
> Chain - ??
> CLI - Inactive. Dormancy candidate?
JMeter is currently using the same code as the Avalon CLI - which is
mixed up in the rest of CLI2. There have been no reported problems
for the CLI in JMeter for a long time now.
It is not the same animal as CLI and CLI2, so perhaps it should be
moved somewhere else? Can it be made a separate mini project in
Commons?
Seems a shame that the only use of the code is in JMeter at present.
Once it has been released, it can remain happily in maintenance mode...
I'm happy to do the work.
> Codec - Inactive.
> Collections - Inactive - new releases discussed but not much movement.
> Configuration - Active.
> Daemon - ?? Dormancy candidate?
> DBCP - 1.2.2 release in the works.
> DbUtils - 1.1 release made. No plans for 1.2.
> Digester - ??
> Discovery - 0.4 release made, nothing new planned. Dormancy candidate.
> EL - ?? Dormancy candidate?
> Email - Maybe a 1.1 release in the works. Not much activity yet.
> FileUpload - 1.2 release in the works.
> IO - 1.3 just released.
> Jelly - ?? Dormancy candidate?
> Jexl - ?? Dormancy candidate?
We're using it in JMeter.
> JXPath - ?? Dormancy candidate?
> Lang - 2.3 release in the works.
> Launcher - Inactive. Dormancy candidate.
> Logging - Needs a 1.1.1 release, no plans beyond that.
> Math - Slow activity.
> Modeler - Inactive - dormancy?
> Net - New JDK 1.5 version in the works.
> Pool - New version in the works.
> Primitives - Inactive. Dormancy candidate?
> SCXML - Active, just released.
> Transaction - Release being discussed.
> Validator - Active.
> VFS - Active and releasing.
>
> Dormant - Nothing likely to leave dormancy.
>
> Sandbox - Nothing that looks like moving to proper anytime soon. Some
> for dormancy (finder, id).
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Status of components
Posted by Henri Yandell <fl...@gmail.com>.
On 2/6/07, Craig McClanahan <cr...@apache.org> wrote:
> Couple of thoughts intermixed. A key one is whether "inactive" and "heading
> for dormancy" should mean the same thing. A stable library used by other
> projects, with no significant bugs, seems to fit the former descriptor,
> while a project nobody uses or cares about would certainly fit the latter.
> That kind of distinction is not clear in your first crack at ranking these
> things.
Definitely different things. Inactive means there's not much work
going on it, it's the opposite of active. It's a symptom.
Dormancy is a plan. Maintenance would be another. Release planned
would be another. I think the key difference between dormancy and
maintenance is that in the latter case there is someone who is
monitoring it. DbUtils is definitely in Maintenance - I've no plans to
work on a new release and don't know of anyone who is, but if the
issues show up then I'll be aiming to get involved and get a release
out.
> On 2/6/07, Henri Yandell <fl...@gmail.com> wrote:
> The specific EL version this implemented was before the separation of the
> JSP 2.1 / JSF 1.2 expression language APIs into their own spec. Ideally,
> this library would become an implementation of that API ... otherwise
> dormancy seems reasonable.
I don't think Tomcat uses it anymore, so I think it's dormant time.
> > Jelly - ?? Dormancy candidate?
>
>
> Maven1 users don't count as a pretty large audience?
I sometimes suspect we are the major Maven1 users :)
> > Modeler - Inactive - dormancy?
>
> Better ask the Tomcat folks, since they use (used?) it.
Daemon too. Dims did a release of Modeler recently, so someone else uses it too.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Status of components
Posted by Niall Pemberton <ni...@gmail.com>.
On 2/9/07, Niall Pemberton <ni...@gmail.com> wrote:
> On 2/8/07, Craig McClanahan <cr...@apache.org> wrote:
> > On 2/8/07, Niall Pemberton <ni...@gmail.com> wrote:
> > >
> > > On 2/7/07, Craig McClanahan <cr...@apache.org> wrote:
> > > > On 2/7/07, Niall Pemberton <ni...@gmail.com> wrote:
> > > > >
> > > > > On 2/7/07, Craig McClanahan <cr...@apache.org> wrote:
> > > > > > > Digester - ??
> > > > > >
> > > > > >
> > > > > > Recently had a 1.8 release to clean up memory leaks and a few other
> > > > > bugs.
> > > > > > For a 1.x release it seems like you could call it stable. But the
> > > > > > architectural approach (including its dependence on the six year old
> > > > > > BeanUtils architecture) could certainly use a remodel.
> > > > >
> > > > > Do you have a suggestion/idea on what you would replace BeanUtils
> > > with?
> > > >
> > > >
> > > > I'm biased by my own experience, of course :-), but any implementation
> > > of an
> > > > expression language has to solve the same set of problems that BeanUtils
> > > > solves, plus a whole lot more. Coupled with the fact that the JSP/JSF
> > > > expression language APIs are being split out into a separate spec so you
> > > > could have implementations of it that have nothing to do with the web
> > > tier,
> > > > if I were building Digester today I would likely think about mapping the
> > > > property setter type rules to EL evaluations.
> > >
> > > I went "looking for el" today - had to first work out what spec
> > > versions were related.
> > >
> > > So Commons EL is used in Tomcat 5.x which is Servlet 2.4 / JSP 2.0.
> > > The independant EL Craig's talking about relates to Servlet 2.5 / JSP
> > > 2.1 and will feature in Tomcat 6 (currently beta).
> > >
> > > Unfortunately it seems that the Tomcat project has developed the
> > > independant EL for Tomcat 6 "in house" as part of their project -
> > > rather than building a new version of Commons EL here. This seems a
> > > shame - both from a Commons EL PoV since its now a legacy/dormant
> > > component and for the type of thing Craig is suggesting - using EL
> > > independantly of a servlet environment.
> > >
> > > I wonder if we could entice the Tomcat folks to do the development of
> > > EL here rather than in their repo - if they haven't already got commit
> > > access here (which I'm sure at least some have) - I'd be happy for
> > > them to have it. Anyone else think this has merit or should we just
> > > let EL lapse?
> >
> >
> > I think it would indeed be useful ... but as usual in life there will be
> > complications.
> >
> > The EL spec itself defines basic APIs like ELContext and ELResolver, plus
> > some factory and configuration methods to glue them together and get
> > instances. On top of that, JSF and JSP provide a whole pile of resolvers
> > that provide the default functionality you need in that environment (for
> > example, the gadget that makes managed bean creation happen) on top of it.
> > From the viewpoint of the Tomcat folks, this might indeed be reasonable to
> > keep in their own repository ... while perhaps moving the generic part here.
>
> I posted a message to the Tomcat Dev list[1] about this - so have to
> see what (if any) interest there is from their side.
>
> [1] http://tinyurl.com/2hozrg
Just as a follow up to this - Tomcat is now publishing the EL jars in
the main maven repo - from my PoV the main thing is having access to
an ASF compatible EL implementation and the location isn't that
relevant.
Niall
> > In addition to Tomcat, I know that Facelets and MyFaces both have some stuff
> > in this area, and Geronimo will eventually have to do something (although
> > they'll probably start by inheriting from whatever JSF and JSP
> > implementations they choose).
> >
> > Come to think of it, Shale's test framework has started implementing mocks
> > for these classes so you can unit test JSF 1.2 based apps. But you have to
> > build so much of the infrastructure to make this actually work that it's
> > pretty close to implementing the generic part of the EL APIs. It'd be
> > interesting to think about moving that part over so it can be shared.
> >
> > Niall
> >
> >
> > Craig
> >
> >
> > > (Of course, because we're dealing with XML directly here, XPath
> > > expressions
> > > > might be another choice ... but they will be less familiar to Java
> > > > developers.)
> > > >
> > > > Craig
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Status of components
Posted by Niall Pemberton <ni...@gmail.com>.
On 2/8/07, Craig McClanahan <cr...@apache.org> wrote:
> On 2/8/07, Niall Pemberton <ni...@gmail.com> wrote:
> >
> > On 2/7/07, Craig McClanahan <cr...@apache.org> wrote:
> > > On 2/7/07, Niall Pemberton <ni...@gmail.com> wrote:
> > > >
> > > > On 2/7/07, Craig McClanahan <cr...@apache.org> wrote:
> > > > > > Digester - ??
> > > > >
> > > > >
> > > > > Recently had a 1.8 release to clean up memory leaks and a few other
> > > > bugs.
> > > > > For a 1.x release it seems like you could call it stable. But the
> > > > > architectural approach (including its dependence on the six year old
> > > > > BeanUtils architecture) could certainly use a remodel.
> > > >
> > > > Do you have a suggestion/idea on what you would replace BeanUtils
> > with?
> > >
> > >
> > > I'm biased by my own experience, of course :-), but any implementation
> > of an
> > > expression language has to solve the same set of problems that BeanUtils
> > > solves, plus a whole lot more. Coupled with the fact that the JSP/JSF
> > > expression language APIs are being split out into a separate spec so you
> > > could have implementations of it that have nothing to do with the web
> > tier,
> > > if I were building Digester today I would likely think about mapping the
> > > property setter type rules to EL evaluations.
> >
> > I went "looking for el" today - had to first work out what spec
> > versions were related.
> >
> > So Commons EL is used in Tomcat 5.x which is Servlet 2.4 / JSP 2.0.
> > The independant EL Craig's talking about relates to Servlet 2.5 / JSP
> > 2.1 and will feature in Tomcat 6 (currently beta).
> >
> > Unfortunately it seems that the Tomcat project has developed the
> > independant EL for Tomcat 6 "in house" as part of their project -
> > rather than building a new version of Commons EL here. This seems a
> > shame - both from a Commons EL PoV since its now a legacy/dormant
> > component and for the type of thing Craig is suggesting - using EL
> > independantly of a servlet environment.
> >
> > I wonder if we could entice the Tomcat folks to do the development of
> > EL here rather than in their repo - if they haven't already got commit
> > access here (which I'm sure at least some have) - I'd be happy for
> > them to have it. Anyone else think this has merit or should we just
> > let EL lapse?
>
>
> I think it would indeed be useful ... but as usual in life there will be
> complications.
>
> The EL spec itself defines basic APIs like ELContext and ELResolver, plus
> some factory and configuration methods to glue them together and get
> instances. On top of that, JSF and JSP provide a whole pile of resolvers
> that provide the default functionality you need in that environment (for
> example, the gadget that makes managed bean creation happen) on top of it.
> From the viewpoint of the Tomcat folks, this might indeed be reasonable to
> keep in their own repository ... while perhaps moving the generic part here.
I posted a message to the Tomcat Dev list[1] about this - so have to
see what (if any) interest there is from their side.
[1] http://tinyurl.com/2hozrg
> In addition to Tomcat, I know that Facelets and MyFaces both have some stuff
> in this area, and Geronimo will eventually have to do something (although
> they'll probably start by inheriting from whatever JSF and JSP
> implementations they choose).
>
> Come to think of it, Shale's test framework has started implementing mocks
> for these classes so you can unit test JSF 1.2 based apps. But you have to
> build so much of the infrastructure to make this actually work that it's
> pretty close to implementing the generic part of the EL APIs. It'd be
> interesting to think about moving that part over so it can be shared.
>
> Niall
>
>
> Craig
>
>
> > (Of course, because we're dealing with XML directly here, XPath
> > expressions
> > > might be another choice ... but they will be less familiar to Java
> > > developers.)
> > >
> > > Craig
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Status of components
Posted by Craig McClanahan <cr...@apache.org>.
On 2/8/07, Niall Pemberton <ni...@gmail.com> wrote:
>
> On 2/7/07, Craig McClanahan <cr...@apache.org> wrote:
> > On 2/7/07, Niall Pemberton <ni...@gmail.com> wrote:
> > >
> > > On 2/7/07, Craig McClanahan <cr...@apache.org> wrote:
> > > > > Digester - ??
> > > >
> > > >
> > > > Recently had a 1.8 release to clean up memory leaks and a few other
> > > bugs.
> > > > For a 1.x release it seems like you could call it stable. But the
> > > > architectural approach (including its dependence on the six year old
> > > > BeanUtils architecture) could certainly use a remodel.
> > >
> > > Do you have a suggestion/idea on what you would replace BeanUtils
> with?
> >
> >
> > I'm biased by my own experience, of course :-), but any implementation
> of an
> > expression language has to solve the same set of problems that BeanUtils
> > solves, plus a whole lot more. Coupled with the fact that the JSP/JSF
> > expression language APIs are being split out into a separate spec so you
> > could have implementations of it that have nothing to do with the web
> tier,
> > if I were building Digester today I would likely think about mapping the
> > property setter type rules to EL evaluations.
>
> I went "looking for el" today - had to first work out what spec
> versions were related.
>
> So Commons EL is used in Tomcat 5.x which is Servlet 2.4 / JSP 2.0.
> The independant EL Craig's talking about relates to Servlet 2.5 / JSP
> 2.1 and will feature in Tomcat 6 (currently beta).
>
> Unfortunately it seems that the Tomcat project has developed the
> independant EL for Tomcat 6 "in house" as part of their project -
> rather than building a new version of Commons EL here. This seems a
> shame - both from a Commons EL PoV since its now a legacy/dormant
> component and for the type of thing Craig is suggesting - using EL
> independantly of a servlet environment.
>
> I wonder if we could entice the Tomcat folks to do the development of
> EL here rather than in their repo - if they haven't already got commit
> access here (which I'm sure at least some have) - I'd be happy for
> them to have it. Anyone else think this has merit or should we just
> let EL lapse?
I think it would indeed be useful ... but as usual in life there will be
complications.
The EL spec itself defines basic APIs like ELContext and ELResolver, plus
some factory and configuration methods to glue them together and get
instances. On top of that, JSF and JSP provide a whole pile of resolvers
that provide the default functionality you need in that environment (for
example, the gadget that makes managed bean creation happen) on top of it.
>From the viewpoint of the Tomcat folks, this might indeed be reasonable to
keep in their own repository ... while perhaps moving the generic part here.
In addition to Tomcat, I know that Facelets and MyFaces both have some stuff
in this area, and Geronimo will eventually have to do something (although
they'll probably start by inheriting from whatever JSF and JSP
implementations they choose).
Come to think of it, Shale's test framework has started implementing mocks
for these classes so you can unit test JSF 1.2 based apps. But you have to
build so much of the infrastructure to make this actually work that it's
pretty close to implementing the generic part of the EL APIs. It'd be
interesting to think about moving that part over so it can be shared.
Niall
Craig
> (Of course, because we're dealing with XML directly here, XPath
> expressions
> > might be another choice ... but they will be less familiar to Java
> > developers.)
> >
> > Craig
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [all] Status of components
Posted by Niall Pemberton <ni...@gmail.com>.
On 2/7/07, Craig McClanahan <cr...@apache.org> wrote:
> On 2/7/07, Niall Pemberton <ni...@gmail.com> wrote:
> >
> > On 2/7/07, Craig McClanahan <cr...@apache.org> wrote:
> > > > Digester - ??
> > >
> > >
> > > Recently had a 1.8 release to clean up memory leaks and a few other
> > bugs.
> > > For a 1.x release it seems like you could call it stable. But the
> > > architectural approach (including its dependence on the six year old
> > > BeanUtils architecture) could certainly use a remodel.
> >
> > Do you have a suggestion/idea on what you would replace BeanUtils with?
>
>
> I'm biased by my own experience, of course :-), but any implementation of an
> expression language has to solve the same set of problems that BeanUtils
> solves, plus a whole lot more. Coupled with the fact that the JSP/JSF
> expression language APIs are being split out into a separate spec so you
> could have implementations of it that have nothing to do with the web tier,
> if I were building Digester today I would likely think about mapping the
> property setter type rules to EL evaluations.
I went "looking for el" today - had to first work out what spec
versions were related.
So Commons EL is used in Tomcat 5.x which is Servlet 2.4 / JSP 2.0.
The independant EL Craig's talking about relates to Servlet 2.5 / JSP
2.1 and will feature in Tomcat 6 (currently beta).
Unfortunately it seems that the Tomcat project has developed the
independant EL for Tomcat 6 "in house" as part of their project -
rather than building a new version of Commons EL here. This seems a
shame - both from a Commons EL PoV since its now a legacy/dormant
component and for the type of thing Craig is suggesting - using EL
independantly of a servlet environment.
I wonder if we could entice the Tomcat folks to do the development of
EL here rather than in their repo - if they haven't already got commit
access here (which I'm sure at least some have) - I'd be happy for
them to have it. Anyone else think this has merit or should we just
let EL lapse?
Niall
> (Of course, because we're dealing with XML directly here, XPath expressions
> might be another choice ... but they will be less familiar to Java
> developers.)
>
> Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Status of components
Posted by Craig McClanahan <cr...@apache.org>.
On 2/7/07, Niall Pemberton <ni...@gmail.com> wrote:
>
> On 2/7/07, Craig McClanahan <cr...@apache.org> wrote:
> > > Digester - ??
> >
> >
> > Recently had a 1.8 release to clean up memory leaks and a few other
> bugs.
> > For a 1.x release it seems like you could call it stable. But the
> > architectural approach (including its dependence on the six year old
> > BeanUtils architecture) could certainly use a remodel.
>
> Do you have a suggestion/idea on what you would replace BeanUtils with?
I'm biased by my own experience, of course :-), but any implementation of an
expression language has to solve the same set of problems that BeanUtils
solves, plus a whole lot more. Coupled with the fact that the JSP/JSF
expression language APIs are being split out into a separate spec so you
could have implementations of it that have nothing to do with the web tier,
if I were building Digester today I would likely think about mapping the
property setter type rules to EL evaluations.
(Of course, because we're dealing with XML directly here, XPath expressions
might be another choice ... but they will be less familiar to Java
developers.)
Craig
Re: [all] Status of components
Posted by Henri Yandell <fl...@gmail.com>.
On 2/7/07, Niall Pemberton <ni...@gmail.com> wrote:
> Rather than inactive or dormant I think a label like "maintenance
> mode" is better for something like this - someone prepared to maintain
> it (e.g. me) but no ongoing development, inactive/dormant implies
> abandonned in my mind.
Should have said this rather than my reply to Craig - +1 to this definition :)
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Status of components
Posted by Niall Pemberton <ni...@gmail.com>.
On 2/7/07, Craig McClanahan <cr...@apache.org> wrote:
> Couple of thoughts intermixed. A key one is whether "inactive" and "heading
> for dormancy" should mean the same thing. A stable library used by other
> projects, with no significant bugs, seems to fit the former descriptor,
> while a project nobody uses or cares about would certainly fit the latter.
> That kind of distinction is not clear in your first crack at ranking these
> things.
>
> On 2/6/07, Henri Yandell <fl...@gmail.com> wrote:
> >
> > I made a stab of defining the current status for Commons for the
> > Jakarta board report:
> >
> > http://wiki.apache.org/jakarta/JakartaBoardReport-current
> >
> > Here's the summary. Any thoughts on the ?? marks and the dormancy
> > candidates? Feel free to add things to the wiki page. I've not added
> > all of this yet.
> >
> > Attributes - Needs a new release, after that a dormancy candidate.
> > BeanUtils - Inactive. 1.8.0 slowly being worked on.
> > Betwixt - Just released.
> > Chain - ??
>
> Inactive but stable. Used by a few projects (including Shale) and
> libraries, but not widespread. Limited in scope due to awkard support for
> conditional processing, so not likely to be aggressively enhanced (at least
> by me ... others may disagree :-).
+1 - from memory could do with a release just to improve the pom
(provided scope) and make life easier for m2 users - also I think
theres a couple of tickets I didn't have time to look at (catalog
support on features I don't use) for the last release. I'll probably
look at doing this once another component(s) has taken the m2 plunge
with a release.
Rather than inactive or dormant I think a label like "maintenance
mode" is better for something like this - someone prepared to maintain
it (e.g. me) but no ongoing development, inactive/dormant implies
abandonned in my mind.
> CLI - Inactive. Dormancy candidate?
> > Codec - Inactive.
> > Collections - Inactive - new releases discussed but not much movement.
Some work started on a JDK 1.5 version in the sandbox a few months back.
> > Configuration - Active.
> > Daemon - ?? Dormancy candidate?
> > DBCP - 1.2.2 release in the works.
> > DbUtils - 1.1 release made. No plans for 1.2.
> > Digester - ??
>
>
> Recently had a 1.8 release to clean up memory leaks and a few other bugs.
> For a 1.x release it seems like you could call it stable. But the
> architectural approach (including its dependence on the six year old
> BeanUtils architecture) could certainly use a remodel.
Do you have a suggestion/idea on what you would replace BeanUtils with?
> Discovery - 0.4 release made, nothing new planned. Dormancy candidate.
> > EL - ?? Dormancy candidate?
>
>
> The specific EL version this implemented was before the separation of the
> JSP 2.1 / JSF 1.2 expression language APIs into their own spec. Ideally,
> this library would become an implementation of that API ... otherwise
> dormancy seems reasonable.
>
> Email - Maybe a 1.1 release in the works. Not much activity yet.
> > FileUpload - 1.2 release in the works.
> > IO - 1.3 just released.
> > Jelly - ?? Dormancy candidate?
>
>
> Maven1 users don't count as a pretty large audience?
>
> Jexl - ?? Dormancy candidate?
> > JXPath - ?? Dormancy candidate?
> > Lang - 2.3 release in the works.
> > Launcher - Inactive. Dormancy candidate.
> > Logging - Needs a 1.1.1 release, no plans beyond that.
> > Math - Slow activity.
> > Modeler - Inactive - dormancy?
>
> Better ask the Tomcat folks, since they use (used?) it.
>
> Net - New JDK 1.5 version in the works.
> > Pool - New version in the works.
> > Primitives - Inactive. Dormancy candidate?
> > SCXML - Active, just released.
> > Transaction - Release being discussed.
> > Validator - Active.
> > VFS - Active and releasing.
> >
> > Dormant - Nothing likely to leave dormancy.
> >
> > Sandbox - Nothing that looks like moving to proper anytime soon. Some
> > for dormancy (finder, id).
>
>
> Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Status of components
Posted by Craig McClanahan <cr...@apache.org>.
Couple of thoughts intermixed. A key one is whether "inactive" and "heading
for dormancy" should mean the same thing. A stable library used by other
projects, with no significant bugs, seems to fit the former descriptor,
while a project nobody uses or cares about would certainly fit the latter.
That kind of distinction is not clear in your first crack at ranking these
things.
On 2/6/07, Henri Yandell <fl...@gmail.com> wrote:
>
> I made a stab of defining the current status for Commons for the
> Jakarta board report:
>
> http://wiki.apache.org/jakarta/JakartaBoardReport-current
>
> Here's the summary. Any thoughts on the ?? marks and the dormancy
> candidates? Feel free to add things to the wiki page. I've not added
> all of this yet.
>
> Attributes - Needs a new release, after that a dormancy candidate.
> BeanUtils - Inactive. 1.8.0 slowly being worked on.
> Betwixt - Just released.
> Chain - ??
Inactive but stable. Used by a few projects (including Shale) and
libraries, but not widespread. Limited in scope due to awkard support for
conditional processing, so not likely to be aggressively enhanced (at least
by me ... others may disagree :-).
CLI - Inactive. Dormancy candidate?
> Codec - Inactive.
> Collections - Inactive - new releases discussed but not much movement.
> Configuration - Active.
> Daemon - ?? Dormancy candidate?
> DBCP - 1.2.2 release in the works.
> DbUtils - 1.1 release made. No plans for 1.2.
> Digester - ??
Recently had a 1.8 release to clean up memory leaks and a few other bugs.
For a 1.x release it seems like you could call it stable. But the
architectural approach (including its dependence on the six year old
BeanUtils architecture) could certainly use a remodel.
Discovery - 0.4 release made, nothing new planned. Dormancy candidate.
> EL - ?? Dormancy candidate?
The specific EL version this implemented was before the separation of the
JSP 2.1 / JSF 1.2 expression language APIs into their own spec. Ideally,
this library would become an implementation of that API ... otherwise
dormancy seems reasonable.
Email - Maybe a 1.1 release in the works. Not much activity yet.
> FileUpload - 1.2 release in the works.
> IO - 1.3 just released.
> Jelly - ?? Dormancy candidate?
Maven1 users don't count as a pretty large audience?
Jexl - ?? Dormancy candidate?
> JXPath - ?? Dormancy candidate?
> Lang - 2.3 release in the works.
> Launcher - Inactive. Dormancy candidate.
> Logging - Needs a 1.1.1 release, no plans beyond that.
> Math - Slow activity.
> Modeler - Inactive - dormancy?
Better ask the Tomcat folks, since they use (used?) it.
Net - New JDK 1.5 version in the works.
> Pool - New version in the works.
> Primitives - Inactive. Dormancy candidate?
> SCXML - Active, just released.
> Transaction - Release being discussed.
> Validator - Active.
> VFS - Active and releasing.
>
> Dormant - Nothing likely to leave dormancy.
>
> Sandbox - Nothing that looks like moving to proper anytime soon. Some
> for dormancy (finder, id).
Craig
Re: [jxpath] was: [all] Status of components
Posted by Dmitri Plotnikov <dm...@apache.org>.
Matt,
I fully agree.
As you can see from the thread on JXPATH-61, the discussion was quite
heated, so in the end I decided to just let it simmer and neither release
nor revert the changes for a while. It's years and no new arguments have
been added to the discussion. The prevailing opinion appears to be to keep
things as they were in 1.2. Thus we should revert the changes (which are
not too extensive anyway).
Thank you,
- Dmitri
----- Original Message -----
From: "Matt Benson" <gu...@yahoo.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Monday, February 19, 2007 2:25 PM
Subject: Re: [jxpath] was: [all] Status of components
> Hi Dmitri... glad to see you got your apache.org mail
> back working again (saw it on infra@). ;) If you're
> in the "neighborhood" for the moment, I'd like to
> gauge your opinion RE
> https://issues.apache.org/jira/browse/JXPATH-61 . The
> final consensus seems to have been that the entire
> thing should be forgotten, as Elliotte Rusty H so
> vehemently pushed for, but your final changes were
> never reverted. Based on my very limited
> understanding of the issue my personal inclination
> would have been to take ERH at his word, given the
> rather large collection of XML-related books he has to
> his name (I'll acknowledge that's perhaps a lazy
> attitude, but I have lots of other projects to look at
> too). Since it has been awhile, I'd like your current
> thoughts on whether this change should indeed appear
> in the 1.3 release. :)
>
> Thanks,
> Matt
>
> --- Dmitri Plotnikov <dm...@apache.org> wrote:
>
>> Hi,
>>
>> I just wanted to express my immense gratitude to
>> Matt Benson for stepping in
>> as the new curator of JXPath. I am happy that it
>> will be in such capable
>> hands.
>>
>> BTW, JXPath does not really have to be dormant. If
>> somebody were interested
>> in taking it further, there are several things that
>> could still be done,
>> e.g. XPath 2.0 conformance, some level of
>> integration with java.xml.xpath,
>> also perhaps some new SPI, which would allow an
>> alternate engine to step in
>> and provide an optimized implementation for some
>> object model (think Jaxen
>> for DOM). Of course, I wanted to do all those
>> things myself, but I have
>> been very busy on other projects lately.
>>
>> Best regards,
>>
>> - Dmitri Plotnikov
>>
>>
>> ----- Original Message -----
>> From: "Dion Gillard" <di...@gmail.com>
>> To: "Jakarta Commons Developers List"
>> <co...@jakarta.apache.org>
>> Sent: Friday, February 09, 2007 12:53 AM
>> Subject: Re: [all] Status of components
>>
>>
>> > On 2/7/07, Henri Yandell <fl...@gmail.com>
>> wrote:
>> >> I made a stab of defining the current status for
>> Commons for the
>> >> Jakarta board report:
>> >>
>> >>
>>
> http://wiki.apache.org/jakarta/JakartaBoardReport-current
>> >>
>> >> Here's the summary. Any thoughts on the ?? marks
>> and the dormancy
>> >> candidates? Feel free to add things to the wiki
>> page. I've not added
>> >> all of this yet.
>> >>
>> >> Attributes - Needs a new release, after that a
>> dormancy candidate.
>> >> BeanUtils - Inactive. 1.8.0 slowly being worked
>> on.
>> >> Betwixt - Just released.
>> >> Chain - ??
>> >> CLI - Inactive. Dormancy candidate?
>> >> Codec - Inactive.
>> >> Collections - Inactive - new releases discussed
>> but not much movement.
>> >> Configuration - Active.
>> >> Daemon - ?? Dormancy candidate?
>> >> DBCP - 1.2.2 release in the works.
>> >> DbUtils - 1.1 release made. No plans for 1.2.
>> >> Digester - ??
>> >> Discovery - 0.4 release made, nothing new
>> planned. Dormancy candidate.
>> >> EL - ?? Dormancy candidate?
>> >> Email - Maybe a 1.1 release in the works. Not
>> much activity yet.
>> >> FileUpload - 1.2 release in the works.
>> >> IO - 1.3 just released.
>> >> Jelly - ?? Dormancy candidate?
>> >
>> > Again, little ongoing hard core development, but a
>> little fix work and
>> > experimentation happens.
>> >
>> >> Jexl - ?? Dormancy candidate?
>> >
>> > Jexl gets a little bit of development here and
>> there and has been
>> > reasonably stable recently. We keep threatening to
>> start Jexl 2.
>> >
>> >> JXPath - ?? Dormancy candidate?
>> >> Lang - 2.3 release in the works.
>> >> Launcher - Inactive. Dormancy candidate.
>> >> Logging - Needs a 1.1.1 release, no plans beyond
>> that.
>> >> Math - Slow activity.
>> >> Modeler - Inactive - dormancy?
>> >> Net - New JDK 1.5 version in the works.
>> >> Pool - New version in the works.
>> >> Primitives - Inactive. Dormancy candidate?
>> >> SCXML - Active, just released.
>> >> Transaction - Release being discussed.
>> >> Validator - Active.
>> >> VFS - Active and releasing.
>> >>
>> >> Dormant - Nothing likely to leave dormancy.
>> >>
>> >> Sandbox - Nothing that looks like moving to
>> proper anytime soon. Some
>> >> for dormancy (finder, id).
>> >>
>> >>
>>
> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail:
>> commons-dev-unsubscribe@jakarta.apache.org
>> >> For additional commands, e-mail:
>> commons-dev-help@jakarta.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > http://www.multitask.com.au/people/dion/
>> > Rule of Acquisition #91: Hear all, trust nothing.
>> >
>> >
>>
> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail:
>> commons-dev-unsubscribe@jakarta.apache.org
>> > For additional commands, e-mail:
>> commons-dev-help@jakarta.apache.org
>> >
>> >
>>
>>
>>
> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> commons-dev-help@jakarta.apache.org
>>
>>
>
>
>
>
> ____________________________________________________________________________________
> Sucker-punch spam with award-winning protection.
> Try the free Yahoo! Mail Beta.
> http://advision.webevents.yahoo.com/mailbeta/features_spam.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jxpath] was: [all] Status of components
Posted by Matt Benson <gu...@yahoo.com>.
Hi Dmitri... glad to see you got your apache.org mail
back working again (saw it on infra@). ;) If you're
in the "neighborhood" for the moment, I'd like to
gauge your opinion RE
https://issues.apache.org/jira/browse/JXPATH-61 . The
final consensus seems to have been that the entire
thing should be forgotten, as Elliotte Rusty H so
vehemently pushed for, but your final changes were
never reverted. Based on my very limited
understanding of the issue my personal inclination
would have been to take ERH at his word, given the
rather large collection of XML-related books he has to
his name (I'll acknowledge that's perhaps a lazy
attitude, but I have lots of other projects to look at
too). Since it has been awhile, I'd like your current
thoughts on whether this change should indeed appear
in the 1.3 release. :)
Thanks,
Matt
--- Dmitri Plotnikov <dm...@apache.org> wrote:
> Hi,
>
> I just wanted to express my immense gratitude to
> Matt Benson for stepping in
> as the new curator of JXPath. I am happy that it
> will be in such capable
> hands.
>
> BTW, JXPath does not really have to be dormant. If
> somebody were interested
> in taking it further, there are several things that
> could still be done,
> e.g. XPath 2.0 conformance, some level of
> integration with java.xml.xpath,
> also perhaps some new SPI, which would allow an
> alternate engine to step in
> and provide an optimized implementation for some
> object model (think Jaxen
> for DOM). Of course, I wanted to do all those
> things myself, but I have
> been very busy on other projects lately.
>
> Best regards,
>
> - Dmitri Plotnikov
>
>
> ----- Original Message -----
> From: "Dion Gillard" <di...@gmail.com>
> To: "Jakarta Commons Developers List"
> <co...@jakarta.apache.org>
> Sent: Friday, February 09, 2007 12:53 AM
> Subject: Re: [all] Status of components
>
>
> > On 2/7/07, Henri Yandell <fl...@gmail.com>
> wrote:
> >> I made a stab of defining the current status for
> Commons for the
> >> Jakarta board report:
> >>
> >>
>
http://wiki.apache.org/jakarta/JakartaBoardReport-current
> >>
> >> Here's the summary. Any thoughts on the ?? marks
> and the dormancy
> >> candidates? Feel free to add things to the wiki
> page. I've not added
> >> all of this yet.
> >>
> >> Attributes - Needs a new release, after that a
> dormancy candidate.
> >> BeanUtils - Inactive. 1.8.0 slowly being worked
> on.
> >> Betwixt - Just released.
> >> Chain - ??
> >> CLI - Inactive. Dormancy candidate?
> >> Codec - Inactive.
> >> Collections - Inactive - new releases discussed
> but not much movement.
> >> Configuration - Active.
> >> Daemon - ?? Dormancy candidate?
> >> DBCP - 1.2.2 release in the works.
> >> DbUtils - 1.1 release made. No plans for 1.2.
> >> Digester - ??
> >> Discovery - 0.4 release made, nothing new
> planned. Dormancy candidate.
> >> EL - ?? Dormancy candidate?
> >> Email - Maybe a 1.1 release in the works. Not
> much activity yet.
> >> FileUpload - 1.2 release in the works.
> >> IO - 1.3 just released.
> >> Jelly - ?? Dormancy candidate?
> >
> > Again, little ongoing hard core development, but a
> little fix work and
> > experimentation happens.
> >
> >> Jexl - ?? Dormancy candidate?
> >
> > Jexl gets a little bit of development here and
> there and has been
> > reasonably stable recently. We keep threatening to
> start Jexl 2.
> >
> >> JXPath - ?? Dormancy candidate?
> >> Lang - 2.3 release in the works.
> >> Launcher - Inactive. Dormancy candidate.
> >> Logging - Needs a 1.1.1 release, no plans beyond
> that.
> >> Math - Slow activity.
> >> Modeler - Inactive - dormancy?
> >> Net - New JDK 1.5 version in the works.
> >> Pool - New version in the works.
> >> Primitives - Inactive. Dormancy candidate?
> >> SCXML - Active, just released.
> >> Transaction - Release being discussed.
> >> Validator - Active.
> >> VFS - Active and releasing.
> >>
> >> Dormant - Nothing likely to leave dormancy.
> >>
> >> Sandbox - Nothing that looks like moving to
> proper anytime soon. Some
> >> for dormancy (finder, id).
> >>
> >>
>
---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> > --
> > http://www.multitask.com.au/people/dion/
> > Rule of Acquisition #91: Hear all, trust nothing.
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> >
> >
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
>
>
____________________________________________________________________________________
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jxpath] was: [all] Status of components
Posted by Dmitri Plotnikov <dm...@apache.org>.
Hi,
I just wanted to express my immense gratitude to Matt Benson for stepping in
as the new curator of JXPath. I am happy that it will be in such capable
hands.
BTW, JXPath does not really have to be dormant. If somebody were interested
in taking it further, there are several things that could still be done,
e.g. XPath 2.0 conformance, some level of integration with java.xml.xpath,
also perhaps some new SPI, which would allow an alternate engine to step in
and provide an optimized implementation for some object model (think Jaxen
for DOM). Of course, I wanted to do all those things myself, but I have
been very busy on other projects lately.
Best regards,
- Dmitri Plotnikov
----- Original Message -----
From: "Dion Gillard" <di...@gmail.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Friday, February 09, 2007 12:53 AM
Subject: Re: [all] Status of components
> On 2/7/07, Henri Yandell <fl...@gmail.com> wrote:
>> I made a stab of defining the current status for Commons for the
>> Jakarta board report:
>>
>> http://wiki.apache.org/jakarta/JakartaBoardReport-current
>>
>> Here's the summary. Any thoughts on the ?? marks and the dormancy
>> candidates? Feel free to add things to the wiki page. I've not added
>> all of this yet.
>>
>> Attributes - Needs a new release, after that a dormancy candidate.
>> BeanUtils - Inactive. 1.8.0 slowly being worked on.
>> Betwixt - Just released.
>> Chain - ??
>> CLI - Inactive. Dormancy candidate?
>> Codec - Inactive.
>> Collections - Inactive - new releases discussed but not much movement.
>> Configuration - Active.
>> Daemon - ?? Dormancy candidate?
>> DBCP - 1.2.2 release in the works.
>> DbUtils - 1.1 release made. No plans for 1.2.
>> Digester - ??
>> Discovery - 0.4 release made, nothing new planned. Dormancy candidate.
>> EL - ?? Dormancy candidate?
>> Email - Maybe a 1.1 release in the works. Not much activity yet.
>> FileUpload - 1.2 release in the works.
>> IO - 1.3 just released.
>> Jelly - ?? Dormancy candidate?
>
> Again, little ongoing hard core development, but a little fix work and
> experimentation happens.
>
>> Jexl - ?? Dormancy candidate?
>
> Jexl gets a little bit of development here and there and has been
> reasonably stable recently. We keep threatening to start Jexl 2.
>
>> JXPath - ?? Dormancy candidate?
>> Lang - 2.3 release in the works.
>> Launcher - Inactive. Dormancy candidate.
>> Logging - Needs a 1.1.1 release, no plans beyond that.
>> Math - Slow activity.
>> Modeler - Inactive - dormancy?
>> Net - New JDK 1.5 version in the works.
>> Pool - New version in the works.
>> Primitives - Inactive. Dormancy candidate?
>> SCXML - Active, just released.
>> Transaction - Release being discussed.
>> Validator - Active.
>> VFS - Active and releasing.
>>
>> Dormant - Nothing likely to leave dormancy.
>>
>> Sandbox - Nothing that looks like moving to proper anytime soon. Some
>> for dormancy (finder, id).
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
>
> --
> http://www.multitask.com.au/people/dion/
> Rule of Acquisition #91: Hear all, trust nothing.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Status of components
Posted by Dion Gillard <di...@gmail.com>.
On 2/7/07, Henri Yandell <fl...@gmail.com> wrote:
> I made a stab of defining the current status for Commons for the
> Jakarta board report:
>
> http://wiki.apache.org/jakarta/JakartaBoardReport-current
>
> Here's the summary. Any thoughts on the ?? marks and the dormancy
> candidates? Feel free to add things to the wiki page. I've not added
> all of this yet.
>
> Attributes - Needs a new release, after that a dormancy candidate.
> BeanUtils - Inactive. 1.8.0 slowly being worked on.
> Betwixt - Just released.
> Chain - ??
> CLI - Inactive. Dormancy candidate?
> Codec - Inactive.
> Collections - Inactive - new releases discussed but not much movement.
> Configuration - Active.
> Daemon - ?? Dormancy candidate?
> DBCP - 1.2.2 release in the works.
> DbUtils - 1.1 release made. No plans for 1.2.
> Digester - ??
> Discovery - 0.4 release made, nothing new planned. Dormancy candidate.
> EL - ?? Dormancy candidate?
> Email - Maybe a 1.1 release in the works. Not much activity yet.
> FileUpload - 1.2 release in the works.
> IO - 1.3 just released.
> Jelly - ?? Dormancy candidate?
Again, little ongoing hard core development, but a little fix work and
experimentation happens.
> Jexl - ?? Dormancy candidate?
Jexl gets a little bit of development here and there and has been
reasonably stable recently. We keep threatening to start Jexl 2.
> JXPath - ?? Dormancy candidate?
> Lang - 2.3 release in the works.
> Launcher - Inactive. Dormancy candidate.
> Logging - Needs a 1.1.1 release, no plans beyond that.
> Math - Slow activity.
> Modeler - Inactive - dormancy?
> Net - New JDK 1.5 version in the works.
> Pool - New version in the works.
> Primitives - Inactive. Dormancy candidate?
> SCXML - Active, just released.
> Transaction - Release being discussed.
> Validator - Active.
> VFS - Active and releasing.
>
> Dormant - Nothing likely to leave dormancy.
>
> Sandbox - Nothing that looks like moving to proper anytime soon. Some
> for dormancy (finder, id).
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
http://www.multitask.com.au/people/dion/
Rule of Acquisition #91: Hear all, trust nothing.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Status of components
Posted by Martin van den Bemt <ml...@mvdb.net>.
If you could add that to the board report, me will be very happy ;)
Mvgr,
Martin
Matt Benson wrote:
> --- Henri Yandell <fl...@gmail.com> wrote:
>
>> I made a stab of defining the current status for
>> Commons for the
>> Jakarta board report:
>>
>>
> http://wiki.apache.org/jakarta/JakartaBoardReport-current
> [SNIP]
>
> JXPath seems to have been effectively abandoned, but
> is overall quite stable. It is, IMHO, very close to
> being ready for a 1.3 release (a couple of JIRA issues
> still need attention). After 1.3 is released it can
> likely languish in the "maintenance mode" that IIRC
> was proposed by Niall on this thread. My intent is to
> act as curator for this project. However all that
> condenses into a summary status. ;)
>
> -Matt
>
>
>
>
> ____________________________________________________________________________________
> Bored stiff? Loosen up...
> Download and play hundreds of games for free on Yahoo! Games.
> http://games.yahoo.com/games/front
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Status of components
Posted by Matt Benson <gu...@yahoo.com>.
--- Henri Yandell <fl...@gmail.com> wrote:
> I made a stab of defining the current status for
> Commons for the
> Jakarta board report:
>
>
http://wiki.apache.org/jakarta/JakartaBoardReport-current
[SNIP]
JXPath seems to have been effectively abandoned, but
is overall quite stable. It is, IMHO, very close to
being ready for a 1.3 release (a couple of JIRA issues
still need attention). After 1.3 is released it can
likely languish in the "maintenance mode" that IIRC
was proposed by Niall on this thread. My intent is to
act as curator for this project. However all that
condenses into a summary status. ;)
-Matt
____________________________________________________________________________________
Bored stiff? Loosen up...
Download and play hundreds of games for free on Yahoo! Games.
http://games.yahoo.com/games/front
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org