You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Stephen McConnell <mc...@apache.org> on 2003/01/22 17:23:40 UTC
[PROPOSAL] avalon housekeeping
I would like to propose that we put some priorities in place.
On our release agenda is Avalon framework 4.1.4, logkit 1.2,
excalibur packages: thread 1.1; sourceresolve 1.0;
configuration 1.0; xmlutil 1.0; store 1.0, cornerstone
packages: threads 1.0; connection 1.0; datasources 1.0;
masterstore 1.0; scheduler 1.0; sockets 1.0 threads 1.0.
If we throw into the equation the potential release of
Fortress we also need to address release of the avalon-sandbox
lifecycle package and the instrument package. Phoenix release
is already out but used non-released code - excalibur
configuration, loader and extension.
Throw into this equation the fact that our current Cornerstone
repository (used by James and Cocoon) has changed at interface and
implementation levels and that every indication from Gump tells us
we have a broken product. Also keep in mind that Cocoon is using the
source, component, xml, store, datasource, pool, testcase, util,
instrument, collections (and possibly other packages) some of which
we have never release.
My proposal is this:
No new release proposals until the current Avalon in-use
excalibur and cornerstone products are finalized,
validated, properly released, and synchronized with
Cocoon and James.
A.K.A - Lets put our priority towards getting Avalon in shape for
our users based on what they are doing today. From that platform
we can move ahead.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] avalon housekeeping
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>>
>> Carsten Ziegeler wrote:
>>
>>> As soon as they are integrated we can make a release of
>>> sourceresolve but not any sooner because than we would have
>>> to deal with incompatible interface changes.
>>>
>>>
>>
>> Quick glance at the dependency graph:
>>
>> sourceresolve dependes on framework 4.1.3 and pool 1.1
>> pool 1.1 depends on framework 4.X and excalibur collections 1.0
>> excalibur collections is depricated if favout of commons collections
>>
>> It would seem to make sense that we update pool to use common
>> collections, bump pool to 1.2, and validate sourceresolve against
>> pool 1.2.
>
>
> +1
Have just updated excalibur-pool to use commons-collections-2.0. I've
bumped the version from 1.1 to 1.2 and updated all of the excalibur
dependent projects. Before committing I verifed against the pool test
case and all pssed ok.
Please let me know if you experience any problems.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] avalon housekeeping
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>
> Carsten Ziegeler wrote:
>
>> As soon as they are integrated we can make a release of
>> sourceresolve but not any sooner because than we would have
>> to deal with incompatible interface changes.
>>
>>
>
> Quick glance at the dependency graph:
>
> sourceresolve dependes on framework 4.1.3 and pool 1.1
> pool 1.1 depends on framework 4.X and excalibur collections 1.0
> excalibur collections is depricated if favout of commons collections
>
> It would seem to make sense that we update pool to use common
> collections, bump pool to 1.2, and validate sourceresolve against
> pool 1.2.
+1
> A less quick glance at the documentation:
>
> Tracking down examples of sourcerolve usage is a PITA. The
> current documetation basically points you to Cocoon. If you
> look around you can find usage in Fortress - but even then,
> its somewhat obscure. I think it would much better if the
> documentation included some code examples - setting up a
> source resolver, adding protocol support, resolving urls,
> etc. (including this in the package documentation would be
> terrific).
+1
> A quick glance at the javadoc:
>
> Running checkstyle on the code as it would generate lots of
> messages about missing @param, @return and @exception
> declarations. Are you planning on getting these in?
We should strive to have good JavaDocs.
> A quick glance at the testcases:
>
> Any plans to get something in place here?
Again, we need something that works.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] avalon housekeeping
Posted by Berin Loritsch <bl...@apache.org>.
Sylvain Wallez wrote:
> Stephen McConnell wrote:
>
> Let me give some details, since I'm currently working on sourceresolve
> after some discussion with Carsten. We want to reach API stability on
> this, because it's used in many places in Cocoon and a such is required
> if we want to start releasing Cocoon 2.1 (we're not even alpha yet).
>
> To answer your questions, the plan is to start by refining and
> stabilizing the API and document it, and test into Cocoon 2.1. There's
> no problem if we start by testing with Cocoon before writing automated
> unit tests because of the unreleased nature of the 2.1 branch.
>
> Detailed docs and automated unit tests will be written in a second
> phase, and any help in this area is more than welcome !
>
> Also, I don't see a dependency of sourceresolve on pool. Where did you
> find it (I'm not fully "fluent" with Avalon build system) ?
The only reason I could think of is for testing purposes. SourceResolve
currently defers to component handlers....
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] avalon housekeeping
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stephen McConnell wrote:
> Sylvain Wallez wrote:
>
>> Stephen McConnell wrote:
>>
>> Let me give some details, since I'm currently working on
>> sourceresolve after some discussion with Carsten. We want to reach
>> API stability on this, because it's used in many places in Cocoon and
>> a such is required if we want to start releasing Cocoon 2.1 (we're
>> not even alpha yet).
>
> Agreed.
>
>> To answer your questions, the plan is to start by refining and
>> stabilizing the API and document it, and test into Cocoon 2.1.
>> There's no problem if we start by testing with Cocoon before writing
>> automated unit tests because of the unreleased nature of the 2.1 branch.
>>
>> Detailed docs and automated unit tests will be written in a second
>> phase, and any help in this area is more than welcome !
>
> Setting up a simple tesdt case should not be difficult.
> I can help to put in place some very basic - but I'll need assistance
> when it comes down to using the package because I don't know anything
> about it (but I'm interested all the same).
OK. We'll talk about this after the first phase. I'm also interested in
setting up those tests, as I never used the ExcaliburTestCase up to now
and want to get up to speed with it, as it is _the_ key to write
component test cases.
>> Also, I don't see a dependency of sourceresolve on pool. Where did
>> you find it (I'm not fully "fluent" with Avalon build system) ?
>
> There were references to excalibur-pool-1.1 in the properties and
> build file. I checked the sources and you correct - the dependency
> isn't real. I've already updated and committed the respective files
> so your now only dependent on framework 4.1.3.
Cool. Thanks.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] avalon housekeeping
Posted by Stephen McConnell <mc...@apache.org>.
Sylvain Wallez wrote:
> Stephen McConnell wrote:
>
> Let me give some details, since I'm currently working on sourceresolve
> after some discussion with Carsten. We want to reach API stability on
> this, because it's used in many places in Cocoon and a such is
> required if we want to start releasing Cocoon 2.1 (we're not even
> alpha yet).
Agreed.
>
> To answer your questions, the plan is to start by refining and
> stabilizing the API and document it, and test into Cocoon 2.1. There's
> no problem if we start by testing with Cocoon before writing automated
> unit tests because of the unreleased nature of the 2.1 branch.
>
> Detailed docs and automated unit tests will be written in a second
> phase, and any help in this area is more than welcome !
Setting up a simple tesdt case should not be difficult.
I can help to put in place some very basic - but I'll need assistance
when it comes down to using the package because I don't know anything
about it (but I'm interested all the same).
>
> Also, I don't see a dependency of sourceresolve on pool. Where did you
> find it (I'm not fully "fluent" with Avalon build system) ?
There were references to excalibur-pool-1.1 in the properties and build
file. I checked the sources and you correct - the dependency isn't
real. I've already updated and committed the respective files so your
now only dependent on framework 4.1.3.
Cheers, Steve.
>
> Sylvain
>
>
>> Carsten Ziegeler wrote:
>>
>>> Stephen McConnell wrote:
>>>
>>>
>>>> I would like to propose that we put some priorities in place.
>>>>
>>>> On our release agenda is Avalon framework 4.1.4, logkit 1.2,
>>>> excalibur packages: thread 1.1; sourceresolve 1.0;
>>>> configuration 1.0; xmlutil 1.0; store 1.0, cornerstone
>>>> packages: threads 1.0; connection 1.0; datasources 1.0;
>>>> masterstore 1.0; scheduler 1.0; sockets 1.0 threads 1.0.
>>>> If we throw into the equation the potential release of
>>>> Fortress we also need to address release of the avalon-sandbox
>>>> lifecycle package and the instrument package. Phoenix release
>>>> is already out but used non-released code - excalibur
>>>> configuration, loader and extension.
>>>>
>>>
>>>
>>> As I mentioned last week, there will be some changes in the
>>> excalibur sourceresolve package. This includes some minor
>>> interface changes and some more additions.
>>>
>>> As soon as they are integrated we can make a release of
>>> sourceresolve but not any sooner because than we would have
>>> to deal with incompatible interface changes.
>>>
>>
>>
>>
>> Quick glance at the dependency graph:
>>
>> sourceresolve dependes on framework 4.1.3 and pool 1.1
>> pool 1.1 depends on framework 4.X and excalibur collections 1.0
>> excalibur collections is depricated if favout of commons collections
>>
>> It would seem to make sense that we update pool to use common
>> collections, bump pool to 1.2, and validate sourceresolve against
>> pool 1.2.
>
>
>> A less quick glance at the documentation:
>>
>> Tracking down examples of sourcerolve usage is a PITA. The current
>> documetation basically points you to Cocoon. If you look around you
>> can find usage in Fortress - but even then, its somewhat obscure. I
>> think it would much better if the documentation included some code
>> examples - setting up a source resolver, adding protocol support,
>> resolving urls, etc. (including this in the package documentation
>> would be terrific).
>>
>> A quick glance at the javadoc:
>>
>> Running checkstyle on the code as it would generate lots of
>> messages about missing @param, @return and @exception declarations.
>> Are you planning on getting these in?
>>
>> A quick glance at the testcases:
>>
>> Any plans to get something in place here?
>>
>> Cheers, Steve.
>
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] avalon housekeeping
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stephen McConnell wrote:
Let me give some details, since I'm currently working on sourceresolve
after some discussion with Carsten. We want to reach API stability on
this, because it's used in many places in Cocoon and a such is required
if we want to start releasing Cocoon 2.1 (we're not even alpha yet).
To answer your questions, the plan is to start by refining and
stabilizing the API and document it, and test into Cocoon 2.1. There's
no problem if we start by testing with Cocoon before writing automated
unit tests because of the unreleased nature of the 2.1 branch.
Detailed docs and automated unit tests will be written in a second
phase, and any help in this area is more than welcome !
Also, I don't see a dependency of sourceresolve on pool. Where did you
find it (I'm not fully "fluent" with Avalon build system) ?
Sylvain
> Carsten Ziegeler wrote:
>
>> Stephen McConnell wrote:
>>
>>
>>> I would like to propose that we put some priorities in place.
>>>
>>> On our release agenda is Avalon framework 4.1.4, logkit 1.2,
>>> excalibur packages: thread 1.1; sourceresolve 1.0;
>>> configuration 1.0; xmlutil 1.0; store 1.0, cornerstone
>>> packages: threads 1.0; connection 1.0; datasources 1.0;
>>> masterstore 1.0; scheduler 1.0; sockets 1.0 threads 1.0.
>>> If we throw into the equation the potential release of
>>> Fortress we also need to address release of the avalon-sandbox
>>> lifecycle package and the instrument package. Phoenix release
>>> is already out but used non-released code - excalibur
>>> configuration, loader and extension.
>>>
>>
>> As I mentioned last week, there will be some changes in the
>> excalibur sourceresolve package. This includes some minor
>> interface changes and some more additions.
>>
>> As soon as they are integrated we can make a release of
>> sourceresolve but not any sooner because than we would have
>> to deal with incompatible interface changes.
>>
>
>
> Quick glance at the dependency graph:
>
> sourceresolve dependes on framework 4.1.3 and pool 1.1
> pool 1.1 depends on framework 4.X and excalibur collections 1.0
> excalibur collections is depricated if favout of commons collections
>
> It would seem to make sense that we update pool to use common
> collections, bump pool to 1.2, and validate sourceresolve against
> pool 1.2.
> A less quick glance at the documentation:
>
> Tracking down examples of sourcerolve usage is a PITA. The current
> documetation basically points you to Cocoon. If you look around you
> can find usage in Fortress - but even then, its somewhat obscure. I
> think it would much better if the documentation included some code
> examples - setting up a source resolver, adding protocol support,
> resolving urls, etc. (including this in the package documentation
> would be terrific).
>
> A quick glance at the javadoc:
>
> Running checkstyle on the code as it would generate lots of messages
> about missing @param, @return and @exception declarations. Are you
> planning on getting these in?
>
> A quick glance at the testcases:
>
> Any plans to get something in place here?
>
> Cheers, Steve.
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PROPOSAL] avalon housekeeping
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stephen McConnell wrote:
>
>
> Quick glance at the dependency graph:
>
> sourceresolve dependes on framework 4.1.3 and pool 1.1
> pool 1.1 depends on framework 4.X and excalibur collections 1.0
> excalibur collections is depricated if favout of commons collections
>
> It would seem to make sense that we update pool to use common
> collections, bump pool to 1.2, and validate sourceresolve against
> pool 1.2.
>
Ok.
> A less quick glance at the documentation:
>
> Tracking down examples of sourcerolve usage is a PITA. The
> current documetation basically points you to Cocoon. If you
> look around you can find usage in Fortress - but even then,
> its somewhat obscure. I think it would much better if the
> documentation included some code examples - setting up a
> source resolver, adding protocol support, resolving urls,
> etc. (including this in the package documentation would be
> terrific).
>
I never got time for this, but I planned it - if someone else wants
to do it, fine.
> A quick glance at the javadoc:
>
> Running checkstyle on the code as it would generate lots of
> messages about missing @param, @return and @exception
> declarations. Are you planning on getting these in?
>
These will be updated, yes.
> A quick glance at the testcases:
>
> Any plans to get something in place here?
>
No, not yet. So if anyone wants to do so, he/she is welcome.
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] avalon housekeeping
Posted by Stephen McConnell <mc...@apache.org>.
Carsten Ziegeler wrote:
>Stephen McConnell wrote:
>
>
>>I would like to propose that we put some priorities in place.
>>
>> On our release agenda is Avalon framework 4.1.4, logkit 1.2,
>> excalibur packages: thread 1.1; sourceresolve 1.0;
>> configuration 1.0; xmlutil 1.0; store 1.0, cornerstone
>> packages: threads 1.0; connection 1.0; datasources 1.0;
>> masterstore 1.0; scheduler 1.0; sockets 1.0 threads 1.0.
>> If we throw into the equation the potential release of
>> Fortress we also need to address release of the avalon-sandbox
>> lifecycle package and the instrument package. Phoenix release
>> is already out but used non-released code - excalibur
>> configuration, loader and extension.
>>
>>
>>
>As I mentioned last week, there will be some changes in the
>excalibur sourceresolve package. This includes some minor
>interface changes and some more additions.
>
>As soon as they are integrated we can make a release of
>sourceresolve but not any sooner because than we would have
>to deal with incompatible interface changes.
>
>
Quick glance at the dependency graph:
sourceresolve dependes on framework 4.1.3 and pool 1.1
pool 1.1 depends on framework 4.X and excalibur collections 1.0
excalibur collections is depricated if favout of commons collections
It would seem to make sense that we update pool to use common
collections, bump pool to 1.2, and validate sourceresolve against
pool 1.2.
A less quick glance at the documentation:
Tracking down examples of sourcerolve usage is a PITA. The
current documetation basically points you to Cocoon. If you
look around you can find usage in Fortress - but even then,
its somewhat obscure. I think it would much better if the
documentation included some code examples - setting up a
source resolver, adding protocol support, resolving urls,
etc. (including this in the package documentation would be
terrific).
A quick glance at the javadoc:
Running checkstyle on the code as it would generate lots of
messages about missing @param, @return and @exception
declarations. Are you planning on getting these in?
A quick glance at the testcases:
Any plans to get something in place here?
Cheers, Steve.
>Carsten
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PROPOSAL] avalon housekeeping
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stephen McConnell wrote:
>
> I would like to propose that we put some priorities in place.
>
> On our release agenda is Avalon framework 4.1.4, logkit 1.2,
> excalibur packages: thread 1.1; sourceresolve 1.0;
> configuration 1.0; xmlutil 1.0; store 1.0, cornerstone
> packages: threads 1.0; connection 1.0; datasources 1.0;
> masterstore 1.0; scheduler 1.0; sockets 1.0 threads 1.0.
> If we throw into the equation the potential release of
> Fortress we also need to address release of the avalon-sandbox
> lifecycle package and the instrument package. Phoenix release
> is already out but used non-released code - excalibur
> configuration, loader and extension.
>
As I mentioned last week, there will be some changes in the
excalibur sourceresolve package. This includes some minor
interface changes and some more additions.
As soon as they are integrated we can make a release of
sourceresolve but not any sooner because than we would have
to deal with incompatible interface changes.
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>