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 <ba...@generationjava.com> on 2004/02/28 06:48:08 UTC
[sandbox] report
I've asf 2.0'd the sandbox. All modules that are mavenised either build,
or if they don't, they didn't before.
I've moved all mavenised projects over to the sandbox-build structure but
not run the maven->build.xml yet, so might see some gumps if any of these
are in gump.
Also prepared a report on sandbox in general:
DEAD
====
altrmi
util
joran
pattern
primitives
SANDBOX-PLAY
============
cli ??
lang
TO-DELETE
=========
jexl
el
MAVENISED+BUILD
===============
attributes
cache
compress
convert
email
events
functor
grant
graph2
jrcs
jux
mapper
messenger
reflect
resources
sql
threadpool
workflow
xo
MAVENISED+FAILING
=================
chain - needs portlet api/jsf
clazz - tests fail
codec-multipart - has bad codec dependency
id - test fails [sys clock]
jjar - lacks ant-tools
periodicity - bad maven deps
scaffold - does not compile - missing class
vfs - bad maven deps
NOT-MAVENISED
=============
feedparser
filters
http
jpath
servlet
rupert
services
simplestore
tbm
threading
xmlunit
SPECIAL
=======
hivemind - ignoring as it is leaving commons
jex - legacy maven issues, needs figuring out
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [sandbox] report
Posted by Rob Oxspring <ro...@imapmail.org>.
The sandbox cli project should be safe to remove now, it was being used
for some experimentation prior to v2 but all work has been moved to a
branch on cli proper which has been 2.0'd already (HEAD hasn't but no
release is expected there)
Rob
Henri Yandell wrote:
>SANDBOX-PLAY
>============
>cli ??
>lang
>
>TO-DELETE
>=========
>jexl
>el
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [releases] lacking releases for .... Was: [sandbox] report
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 1 Mar 2004, at 13:39, Henri Yandell wrote:
> On Mon, 1 Mar 2004, Geir Magnusson Jr wrote:
>
>> On Feb 29, 2004, at 11:26 AM, Henri Yandell wrote:
>>
>>> Does anyone have estimated release dates for these? and who is
>>> release
>>> manager for each one? [something we should probably make a clause of
>>> sandbox->proper promotion]. If the release manager then vanishes, we
>>> should demote if no one else volunteers.
>>
>> Subtle point - should there be a required release to get to commons
>> out
>> of sandbox? One issue we're discussing is that code shouldn't depend
>> on sandbox code, as it's supposed to be just a 'play area'. That
>> said,
>> having users is a great way to clean, refactor and evolve code, so if
>> you can only get to commons from sandbox w/ a release, then we are
>> imposing a bit of a chicken-egg problem, or just releasing for the
>> sake
>> of release, which I think is pointless.
>
> I think this is pretty much the current situation. For most components,
> they move from sandbox to commons with the intention of a release. A
> few
> have just got hung up at the last hurdle :)
i've now had a bit of experience (from various perspectives) with this
and i now think that the best practice is to insist on a speedy base
line release when the component graduates - but this may be a 0.1 (or a
0.5 etc) release rather than a full 1.0 release.
being able to release is an important step between experimental code
and graduating to a fully supported component. some users require
official releases and it's better for other projects to be able to rely
on releases (rather than snapshots) but often components have stumbled
when it comes to fixing the interfaces (which is probably required for
a 1.0 release). a good 1.0 is often a goal which may take months (or
years) to achieve.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [releases] lacking releases for .... Was: [sandbox] report
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 1 Mar 2004, Geir Magnusson Jr wrote:
>
> On Feb 29, 2004, at 11:26 AM, Henri Yandell wrote:
>
> > Does anyone have estimated release dates for these? and who is release
> > manager for each one? [something we should probably make a clause of
> > sandbox->proper promotion]. If the release manager then vanishes, we
> > should demote if no one else volunteers.
>
> Subtle point - should there be a required release to get to commons out
> of sandbox? One issue we're discussing is that code shouldn't depend
> on sandbox code, as it's supposed to be just a 'play area'. That said,
> having users is a great way to clean, refactor and evolve code, so if
> you can only get to commons from sandbox w/ a release, then we are
> imposing a bit of a chicken-egg problem, or just releasing for the sake
> of release, which I think is pointless.
I think this is pretty much the current situation. For most components,
they move from sandbox to commons with the intention of a release. A few
have just got hung up at the last hurdle :)
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [releases] lacking releases for .... Was: [sandbox] report
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Feb 29, 2004, at 11:26 AM, Henri Yandell wrote:
>
> In addition, we have commons-proper projects without a release:
>
> IO
> Jelly
> Jexl
> Launcher
> Math
>
> Does anyone have estimated release dates for these? and who is release
> manager for each one? [something we should probably make a clause of
> sandbox->proper promotion]. If the release manager then vanishes, we
> should demote if no one else volunteers.
Subtle point - should there be a required release to get to commons out
of sandbox? One issue we're discussing is that code shouldn't depend
on sandbox code, as it's supposed to be just a 'play area'. That said,
having users is a great way to clean, refactor and evolve code, so if
you can only get to commons from sandbox w/ a release, then we are
imposing a bit of a chicken-egg problem, or just releasing for the sake
of release, which I think is pointless.
>
> ***
>
> To get started, I'm currently viewing myself as IO release manager and
> have been slowly moving along. All code is now javadoc'd as much as
> needs
> be and classes that will not go in 1.0 have been identified. 3 Unit
> tests
> remain to be finished.
I'll do jexl...
geir
>
> Hen
>
> On Sat, 28 Feb 2004, Henri Yandell wrote:
>
>>
>> I've asf 2.0'd the sandbox. All modules that are mavenised either
>> build,
>> or if they don't, they didn't before.
>>
>> I've moved all mavenised projects over to the sandbox-build structure
>> but
>> not run the maven->build.xml yet, so might see some gumps if any of
>> these
>> are in gump.
>>
>> Also prepared a report on sandbox in general:
>>
>> DEAD
>> ====
>> altrmi
>> util
>> joran
>> pattern
>> primitives
>>
>> SANDBOX-PLAY
>> ============
>> cli ??
>> lang
>>
>> TO-DELETE
>> =========
>> jexl
>> el
>>
>> MAVENISED+BUILD
>> ===============
>> attributes
>> cache
>> compress
>> convert
>> email
>> events
>> functor
>> grant
>> graph2
>> jrcs
>> jux
>> mapper
>> messenger
>> reflect
>> resources
>> sql
>> threadpool
>> workflow
>> xo
>>
>> MAVENISED+FAILING
>> =================
>> chain - needs portlet api/jsf
>> clazz - tests fail
>> codec-multipart - has bad codec dependency
>> id - test fails [sys clock]
>> jjar - lacks ant-tools
>> periodicity - bad maven deps
>> scaffold - does not compile - missing class
>> vfs - bad maven deps
>>
>> NOT-MAVENISED
>> =============
>> feedparser
>> filters
>> http
>> jpath
>> servlet
>> rupert
>> services
>> simplestore
>> tbm
>> threading
>> xmlunit
>>
>> SPECIAL
>> =======
>> hivemind - ignoring as it is leaving commons
>> jex - legacy maven issues, needs figuring out
>>
>>
>> Hen
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math]Re: [releases] lacking releases for .... Was: [sandbox]
report
Posted by Christopher Schuck <cs...@stny.rr.com>.
Phil,
Thank you for the info, I'll start with the code review and javadoc. It
sounds like you need help there, and it'll give me a chance to learn the
codebase, so it's a good place to start. Later this week
(Thursday/Friday) I'll look at the other items to see what I can best
contribute on there. I'll try to keep the dumb newbie questions to a
minimum. :)
Chris
Phil Steitz wrote:
> Chris,
>
> The TODO list and "Straw Man Release Plan" here:
> http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=107547484612802&w=2
> provide a decent summary of what we need to do to get a 1.0 release out the
> door. Right now, we are pretty much focussed on cleaning up what we have
> so that we can make an intitial release and then get on to some new stuff.
> Depending on your interest / background / tolerance for things like
> documentation, testing, etc., I would suggest that you start on one or more
> of the following. All have essentially equal priority, since all must be
> done prior to release.
>
> 1. Code and javadoc review -- there are lots of errors and broken links in
> the javadoc and we need to get through all of this. Pick any package and
> start reviewing / submitting patches / fixing broken links. We need to get
> everything up to the standard specified in the "Documentation" section
> here: http://jakarta.apache.org/commons/math/developers.html
> If you look at, for example, the random or distribution packages, the
> javadoc is not in bad shape; but other packages need significant work.
> Obviously, a key part of this task is verifying that the code and tests
> match the javadoc.
>
> 2. User Guide contributions. If you know basic stat, filling in the
> missing sections on Bivariate Regression and/or Statistical Tests in
> stat.xml would be great. The Utilities section also needs to be written.
> Let me know if you are going to work on anything in the User Guide so that
> we don't step on each other.
>
> 3. Test path and boundary value coverage improvements. If you have access
> to R or S, for example, or have a numerics background, it would be very
> helpful to do more validation testing using extreme values, badly
> conditioned problems, etc. Here again, let us know what you are working on
> if you decide to take some of this on.
>
> 4. Do the research, evaluate the patch here:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25278
> and either submit a patch or recommend closing the spline implementation
> issue as WONTFIX. Test cases and good references describing the proposed
> algorithms will be necessary to close this.
>
> 5. RealMatrix Solve issue. What is going on here is that the solve() method
> of the RealMatrix interface enables you to solve a linear system whose
> coefficient matrix is the RealMatrix instance. The current implementation
> uses LU decomposition, which is a good general method, but when you get
> down to it the best solution method depends on the system, so it would be
> good to make the solution method pluggable. That is the problem statement.
> If you dig into the code, you will see that the LU decomposition is cached
> and used for multiple things (e.g. determinant computation, singularity
> testing) and there are some efficiencies that result from this. I would
> not want to lose these efficiencies by fully separating the decomposition.
>
> 6. Critical assessment of the APIs from a usability and extensibility
> standpoint. I would really like to hold onto the 1.0 target, which means
> that the APIs need to be stable and easily extensible without breaking
> backward compatability.
>
> If you have any problems getting set up, submitting patches, figuring out
> maven, etc., don't hesitate to ask for help. Thanks in advance.
>
> Phil
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - More reliable, more storage, less spam
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
Christopher Schuck
"If you have no voice, SCREAM; if you have no legs, RUN; if you have no
hope, INVENT" - Alegria
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math]Re: [releases] lacking releases for .... Was: [sandbox] report
Posted by Phil Steitz <st...@yahoo.com>.
--- Christopher Schuck <cs...@stny.rr.com> wrote:
>
> Phil, I am new to the Commons, but would like to help out the math
> project if I could. In brief I am a mathematician turned developer
> (principally Java), and would like to do something mathematical again.
> What is your highest priority now? I saw the TODO list, but I imagine
> there are some things more urgent than others. One item I didn't
> understand was the refactoring of the solve method for the RealMatrix
> class (I didn't follow what was meant by making it more pluggable), but
> if that isn't what you need the most, I'd rather help out where you need
> the help.
>
> Chris
>
Chris,
The TODO list and "Straw Man Release Plan" here:
http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=107547484612802&w=2
provide a decent summary of what we need to do to get a 1.0 release out the
door. Right now, we are pretty much focussed on cleaning up what we have
so that we can make an intitial release and then get on to some new stuff.
Depending on your interest / background / tolerance for things like
documentation, testing, etc., I would suggest that you start on one or more
of the following. All have essentially equal priority, since all must be
done prior to release.
1. Code and javadoc review -- there are lots of errors and broken links in
the javadoc and we need to get through all of this. Pick any package and
start reviewing / submitting patches / fixing broken links. We need to get
everything up to the standard specified in the "Documentation" section
here: http://jakarta.apache.org/commons/math/developers.html
If you look at, for example, the random or distribution packages, the
javadoc is not in bad shape; but other packages need significant work.
Obviously, a key part of this task is verifying that the code and tests
match the javadoc.
2. User Guide contributions. If you know basic stat, filling in the
missing sections on Bivariate Regression and/or Statistical Tests in
stat.xml would be great. The Utilities section also needs to be written.
Let me know if you are going to work on anything in the User Guide so that
we don't step on each other.
3. Test path and boundary value coverage improvements. If you have access
to R or S, for example, or have a numerics background, it would be very
helpful to do more validation testing using extreme values, badly
conditioned problems, etc. Here again, let us know what you are working on
if you decide to take some of this on.
4. Do the research, evaluate the patch here:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25278
and either submit a patch or recommend closing the spline implementation
issue as WONTFIX. Test cases and good references describing the proposed
algorithms will be necessary to close this.
5. RealMatrix Solve issue. What is going on here is that the solve() method
of the RealMatrix interface enables you to solve a linear system whose
coefficient matrix is the RealMatrix instance. The current implementation
uses LU decomposition, which is a good general method, but when you get
down to it the best solution method depends on the system, so it would be
good to make the solution method pluggable. That is the problem statement.
If you dig into the code, you will see that the LU decomposition is cached
and used for multiple things (e.g. determinant computation, singularity
testing) and there are some efficiencies that result from this. I would
not want to lose these efficiencies by fully separating the decomposition.
6. Critical assessment of the APIs from a usability and extensibility
standpoint. I would really like to hold onto the 1.0 target, which means
that the APIs need to be stable and easily extensible without breaking
backward compatability.
If you have any problems getting set up, submitting patches, figuring out
maven, etc., don't hesitate to ask for help. Thanks in advance.
Phil
__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math]Re: [releases] lacking releases for .... Was: [sandbox]
report
Posted by Christopher Schuck <cs...@stny.rr.com>.
Phil Steitz wrote:
> Eric,
>
> Any help with the validation would be *much* appreciated.
>
> -Phil
Phil, I am new to the Commons, but would like to help out the math
project if I could. In brief I am a mathematician turned developer
(principally Java), and would like to do something mathematical again.
What is your highest priority now? I saw the TODO list, but I imagine
there are some things more urgent than others. One item I didn't
understand was the refactoring of the solve method for the RealMatrix
class (I didn't follow what was meant by making it more pluggable), but
if that isn't what you need the most, I'd rather help out where you need
the help.
Chris
--
Christopher Schuck
"If you have no voice, SCREAM; if you have no legs, RUN; if you have no hope, INVENT" - Alegria
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math]Re: [releases] lacking releases for .... Was: [sandbox]
report
Posted by Eric MacAdie <EK...@MacAdie.net>.
Phil Steitz wrote:
> Eric MacAdie wrote:
>
>> I am starting to look at R for validating the stats functions. I also
>> found a site with some data sets, but I have not looked at them yet.
>>
>
> Eric,
>
> Any help with the validation would be *much* appreciated.
>
> -Phil
>
>
I *finally* have some results. I ran a couple of small data sets through
org.apache.commons.math.stat.univariate.DescriptiveStatisticsImpl and a
couple of R and Octave scripts to
compare answers.
A few of the functions I have not been able to figure out in Octave yet,
like getMax(), getMin(), getSum() and getSumsq().
For the most part, I got the same answers, except for kurtosis and skewness.
I hope this is helpful.
EKMacAdie
*
*
Re: [math]Re: [releases] lacking releases for .... Was: [sandbox]
report
Posted by Phil Steitz <ph...@steitz.com>.
Eric MacAdie wrote:
> I am starting to look at R for validating the stats functions. I also
> found a site with some data sets, but I have not looked at them yet.
>
Eric,
Any help with the validation would be *much* appreciated.
-Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math]Re: [releases] lacking releases for .... Was: [sandbox]
report
Posted by Eric MacAdie <EK...@MacAdie.net>.
I am starting to look at R for validating the stats functions. I also
found a site with some data sets, but I have not looked at them yet.
I took a few weeks to read some books from the library about the kinds
of jobs that math majors can get. It was very interesting reading. I
wish there were more books like that when I was in high school.
EKMacAdie
Phil Steitz wrote:
> The following coding/doco items are all still open:
>
> a. Finish the User Guide
> b. Finalize and execute RealMatrix solve() strategy
> c. Finalize and execute spline changes
> d. Extend certified data tests with tests against R or other sources
> (need to finalize what is included here)
> e. Review API and fix broken links and other errors in javadoc
> f. Improve path and boundary value test coverage
> g. Finalize and implement "BeanList" stats
>
> I have been making slow progress on a, d, e, and f. Javadoc review
> has raised a few additional API issues (e.g. RealSolver refactoring)
> and I am sure that more will surface as I make my way through all of
> the code. I have been extremely time constrained recently, but
> hopefully this will improve "soon." Volunteer help on any of the
> items above -- especially code/API review -- would be much appreciated.
>
> Phil
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[math]Re: [releases] lacking releases for .... Was: [sandbox] report
Posted by Phil Steitz <ph...@steitz.com>.
Mark R. Diggory wrote:
> In Math we have Phil and myself working on various aspects of the
> release process. My efforts have primarily been in automation of the
> release process and site generation (thus benefiting the whole commons
> as well) while Phil has been focused on task management to get the
> sourcecode upto release stage.
>
> -Mark
>
The following coding/doco items are all still open:
a. Finish the User Guide
b. Finalize and execute RealMatrix solve() strategy
c. Finalize and execute spline changes
d. Extend certified data tests with tests against R or other sources (need
to finalize what is included here)
e. Review API and fix broken links and other errors in javadoc
f. Improve path and boundary value test coverage
g. Finalize and implement "BeanList" stats
I have been making slow progress on a, d, e, and f. Javadoc review has
raised a few additional API issues (e.g. RealSolver refactoring) and I am
sure that more will surface as I make my way through all of the code. I
have been extremely time constrained recently, but hopefully this will
improve "soon." Volunteer help on any of the items above -- especially
code/API review -- would be much appreciated.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [releases] lacking releases for .... Was: [sandbox] report
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
In Math we have Phil and myself working on various aspects of the
release process. My efforts have primarily been in automation of the
release process and site generation (thus benefiting the whole commons
as well) while Phil has been focused on task management to get the
sourcecode upto release stage.
-Mark
Henri Yandell wrote:
> In addition, we have commons-proper projects without a release:
>
> IO
> Jelly
> Jexl
> Launcher
> Math
>
> Does anyone have estimated release dates for these? and who is release
> manager for each one? [something we should probably make a clause of
> sandbox->proper promotion]. If the release manager then vanishes, we
> should demote if no one else volunteers.
>
> ***
>
> To get started, I'm currently viewing myself as IO release manager and
> have been slowly moving along. All code is now javadoc'd as much as needs
> be and classes that will not go in 1.0 have been identified. 3 Unit tests
> remain to be finished.
>
> Hen
>
> On Sat, 28 Feb 2004, Henri Yandell wrote:
>
>
>>I've asf 2.0'd the sandbox. All modules that are mavenised either build,
>>or if they don't, they didn't before.
>>
>>I've moved all mavenised projects over to the sandbox-build structure but
>>not run the maven->build.xml yet, so might see some gumps if any of these
>>are in gump.
>>
>>Also prepared a report on sandbox in general:
>>
>>DEAD
>>====
>>altrmi
>>util
>>joran
>>pattern
>>primitives
>>
>>SANDBOX-PLAY
>>============
>>cli ??
>>lang
>>
>>TO-DELETE
>>=========
>>jexl
>>el
>>
>>MAVENISED+BUILD
>>===============
>>attributes
>>cache
>>compress
>>convert
>>email
>>events
>>functor
>>grant
>>graph2
>>jrcs
>>jux
>>mapper
>>messenger
>>reflect
>>resources
>>sql
>>threadpool
>>workflow
>>xo
>>
>>MAVENISED+FAILING
>>=================
>>chain - needs portlet api/jsf
>>clazz - tests fail
>>codec-multipart - has bad codec dependency
>>id - test fails [sys clock]
>>jjar - lacks ant-tools
>>periodicity - bad maven deps
>>scaffold - does not compile - missing class
>>vfs - bad maven deps
>>
>>NOT-MAVENISED
>>=============
>>feedparser
>>filters
>>http
>>jpath
>>servlet
>>rupert
>>services
>>simplestore
>>tbm
>>threading
>>xmlunit
>>
>>SPECIAL
>>=======
>>hivemind - ignoring as it is leaving commons
>>jex - legacy maven issues, needs figuring out
>>
>>
>>Hen
>>
>>
>>---------------------------------------------------------------------
>>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
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [releases] lacking releases for .... Was: [sandbox] report
Posted by di...@multitask.com.au.
Henri Yandell <ba...@generationjava.com> wrote on 01/03/2004 03:26:28 AM:
> In addition, we have commons-proper projects without a release:
>
> IO
> Jelly
> Jexl
> Launcher
> Math
>
> Does anyone have estimated release dates for these? and who is release
> manager for each one? [something we should probably make a clause of
> sandbox->proper promotion]. If the release manager then vanishes, we
> should demote if no one else volunteers.
I'm working on Jelly at the moment to get to ASL v2 compliance. As far as
a release goes, the next release is scheduled as a beta when the existing
bugs and enhancements are finished :-)
--
dIon Gillard, Multitask Consulting
[releases] lacking releases for .... Was: [sandbox] report
Posted by Henri Yandell <ba...@generationjava.com>.
In addition, we have commons-proper projects without a release:
IO
Jelly
Jexl
Launcher
Math
Does anyone have estimated release dates for these? and who is release
manager for each one? [something we should probably make a clause of
sandbox->proper promotion]. If the release manager then vanishes, we
should demote if no one else volunteers.
***
To get started, I'm currently viewing myself as IO release manager and
have been slowly moving along. All code is now javadoc'd as much as needs
be and classes that will not go in 1.0 have been identified. 3 Unit tests
remain to be finished.
Hen
On Sat, 28 Feb 2004, Henri Yandell wrote:
>
> I've asf 2.0'd the sandbox. All modules that are mavenised either build,
> or if they don't, they didn't before.
>
> I've moved all mavenised projects over to the sandbox-build structure but
> not run the maven->build.xml yet, so might see some gumps if any of these
> are in gump.
>
> Also prepared a report on sandbox in general:
>
> DEAD
> ====
> altrmi
> util
> joran
> pattern
> primitives
>
> SANDBOX-PLAY
> ============
> cli ??
> lang
>
> TO-DELETE
> =========
> jexl
> el
>
> MAVENISED+BUILD
> ===============
> attributes
> cache
> compress
> convert
> email
> events
> functor
> grant
> graph2
> jrcs
> jux
> mapper
> messenger
> reflect
> resources
> sql
> threadpool
> workflow
> xo
>
> MAVENISED+FAILING
> =================
> chain - needs portlet api/jsf
> clazz - tests fail
> codec-multipart - has bad codec dependency
> id - test fails [sys clock]
> jjar - lacks ant-tools
> periodicity - bad maven deps
> scaffold - does not compile - missing class
> vfs - bad maven deps
>
> NOT-MAVENISED
> =============
> feedparser
> filters
> http
> jpath
> servlet
> rupert
> services
> simplestore
> tbm
> threading
> xmlunit
>
> SPECIAL
> =======
> hivemind - ignoring as it is leaving commons
> jex - legacy maven issues, needs figuring out
>
>
> Hen
>
>
> ---------------------------------------------------------------------
> 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