You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2002/08/16 12:09:52 UTC
Releasing excalibur subprojects
Hi,
can someone give me a hint on what's the procedure to release a
subproject? Is a vote necessary?
I want to release the store, the xmlutil and the sourceresolve
subprojects. Anyone against it?
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Releasing excalibur subprojects
Posted by Gerhard Froehlich <g-...@gmx.de>.
Carsten Ziegeler wrote:
> Hi,
>
> can someone give me a hint on what's the procedure to release a
> subproject? Is a vote necessary?
>
> I want to release the store, the xmlutil and the sourceresolve
> subprojects. Anyone against it?
Store. I started to move the Jisp based FS Store to Avalon with the new
Jisp 2.0 API. I hope I can finish this at the weekend.
Greets
Gerhard
--
"Three o'clock is always too late or too early for
anything you want to do.
(Jean-Paul Sartre)"
Weblogging at: http://radio.weblogs.com/0107791/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Releasing excalibur subprojects
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
>
> On Fri, 16 Aug 2002 20:41, Gerhard Froehlich wrote:
> > I'm not involved in Simplestore, anymore. But it's a OR mapping API (JDO
> > and stuff). IMHO that's not needed in Cocoon and Co. The Store
> > components in Avalon are simple Data stores (NO DBs). There is a Jisp
> > (http://www.coyotegulch.com/algorithm/jisp/index.html) based Store in
> > Cocoon. I plan to move it to Excalibur-store to have all Cocoon Store
> > components in this subproject. That would be less confusing and more
> > continuous.
> >
> > What do you think?
>
> sounds good to me ;)
>
+1
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Releasing excalibur subprojects
Posted by Peter Donald <pe...@apache.org>.
On Fri, 16 Aug 2002 20:41, Gerhard Froehlich wrote:
> I'm not involved in Simplestore, anymore. But it's a OR mapping API (JDO
> and stuff). IMHO that's not needed in Cocoon and Co. The Store
> components in Avalon are simple Data stores (NO DBs). There is a Jisp
> (http://www.coyotegulch.com/algorithm/jisp/index.html) based Store in
> Cocoon. I plan to move it to Excalibur-store to have all Cocoon Store
> components in this subproject. That would be less confusing and more
> continuous.
>
> What do you think?
sounds good to me ;)
--
Cheers,
Peter Donald
"All my life I wanted to be someone; I guess I should have been more
specific."
-- Jane Wagner
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Releasing excalibur subprojects
Posted by Gerhard Froehlich <g-...@gmx.de>.
Nicola Ken Barozzi wrote:
>
> Carsten Ziegeler wrote:
>
>> Hi,
>>
>> can someone give me a hint on what's the procedure to release a
>> subproject? Is a vote necessary?
>
>
> For releases, always, as said in our Project Guidelines.
>
> "
> Release Plan
>
> A release plan is used to keep all volunteers aware of when a release is
> desired, who will be the release manager, when the repository will be
> frozen to create a release, and other assorted information to keep
> volunteers from tripping over each other. Lazy majority decides each
> issue in a release plan.
>
> Release Testing
>
> After a new release is built, it must be tested before being released to
> the public. Majority approval is required before the release can be made.
> "
>
>
>> I want to release the store, the xmlutil and the sourceresolve
>> subprojects. Anyone against it?
>
>
> Before releasing excalibur components, I prefer to check if we can move
> the stuff elswhere, before creating a legacy here.
>
> So -1 till anyone wanting to release excalibur stuff explains why these
> have to be released here versus be in some kind of Commons.
>
> Now more specific points:
> - xmlutil -1: seems like a package for xml-commons, no Avalon dependency
>
> - sourceresolve +1: seems like a non-commons-convertible Avalon
> component to me
>
> - store -0: it *is* an Avalon Component, but there is a cool simplestore
> package in Jakarta-commons-sandbox, written by Gerhard Froehlich
> (g-froehlich@gmx.de) Juozas Baliuka (baliuka@mwm.lt).
> Gerhard, what's the status? Can't we make our store use simplestore as
> an impl?
I'm not involved in Simplestore, anymore. But it's a OR mapping API (JDO
and stuff). IMHO that's not needed in Cocoon and Co. The Store
components in Avalon are simple Data stores (NO DBs). There is a Jisp
(http://www.coyotegulch.com/algorithm/jisp/index.html) based Store in
Cocoon. I plan to move it to Excalibur-store to have all Cocoon Store
components in this subproject. That would be less confusing and more
continuous.
What do you think?
Greets
Gerhard
--
"Three o'clock is always too late or too early for
anything you want to do.
(Jean-Paul Sartre)"
Weblogging at: http://radio.weblogs.com/0107791/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Releasing excalibur subprojects
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi wrote:
>
> Carsten Ziegeler wrote:
> >
> >
> > Ah, the good old discussion about commons vs. avalon. Great!
>
> It's not a discussion, it's a simple fact.
> If a component has no needed dependencies to Avalon Framework, it should
> go in Commons.
>
Agreed.
> >>Now more specific points:
> >>- xmlutil -1: seems like a package for xml-commons, no Avalon dependency
> >>
> >
> > Hmm, xmlutil provides Avalon components. I'm fine with moving them if
> > xml-commons wants to have a dependency on avalon.
>
> Sorry, I somehow looked at another xmlutil package I had on my hd, in
> fact yes, they are Avalon xml components.
>
> +1
>
Ah, this saves my day!
> BTW, I would /personally/ not call them xmlutil, but simply xml, as
> javax.xml...
> Usually *util is used for helper classes and static methods, which is
> not the case here.
>
I think it was called xml but renamed later - or do I suffer from a
weak memory?
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Releasing excalibur subprojects
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
>
>>-----Original Message-----
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>
>>Carsten Ziegeler wrote:
>>
>>>Hi,
>>>
>>>can someone give me a hint on what's the procedure to release a
>>>subproject? Is a vote necessary?
>>
>>For releases, always, as said in our Project Guidelines.
>>
>>"
>>Release Plan
>>
>>A release plan is used to keep all volunteers aware of when a release is
>>desired, who will be the release manager, when the repository will be
>>frozen to create a release, and other assorted information to keep
>>volunteers from tripping over each other. Lazy majority decides each
>>issue in a release plan.
>>
>>Release Testing
>>
>>After a new release is built, it must be tested before being released to
>>the public. Majority approval is required before the release can be made.
>>"
>>
> In our case the components are tested very well in Cocoon.
Yes. Now the majority vote :-)
>>>I want to release the store, the xmlutil and the sourceresolve
>>>subprojects. Anyone against it?
>>
>>Before releasing excalibur components, I prefer to check if we can move
>>the stuff elswhere, before creating a legacy here.
>>
>>So -1 till anyone wanting to release excalibur stuff explains why these
>>have to be released here versus be in some kind of Commons.
>>
>
> Ah, the good old discussion about commons vs. avalon. Great!
It's not a discussion, it's a simple fact.
If a component has no needed dependencies to Avalon Framework, it should
go in Commons.
>>Now more specific points:
>>- xmlutil -1: seems like a package for xml-commons, no Avalon dependency
>>
>
> Hmm, xmlutil provides Avalon components. I'm fine with moving them if
> xml-commons wants to have a dependency on avalon.
Sorry, I somehow looked at another xmlutil package I had on my hd, in
fact yes, they are Avalon xml components.
+1
BTW, I would /personally/ not call them xmlutil, but simply xml, as
javax.xml...
Usually *util is used for helper classes and static methods, which is
not the case here.
>>- sourceresolve +1: seems like a non-commons-convertible Avalon
>>component to me
>>
>>- store -0: it *is* an Avalon Component, but there is a cool simplestore
>>package in Jakarta-commons-sandbox, written by Gerhard Froehlich
>>(g-froehlich@gmx.de) Juozas Baliuka (baliuka@mwm.lt).
>>Gerhard, what's the status? Can't we make our store use simplestore as
>>an impl?
>>
>
> Again, this project defines components (with an implementation). It is
> of course possible to add an implementation which uses a commons-sandbox
> implementation - but that's optional in my eyes.
After the mail of Gerhard, +1.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Releasing excalibur subprojects
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> Carsten Ziegeler wrote:
> > Hi,
> >
> > can someone give me a hint on what's the procedure to release a
> > subproject? Is a vote necessary?
>
> For releases, always, as said in our Project Guidelines.
>
> "
> Release Plan
>
> A release plan is used to keep all volunteers aware of when a release is
> desired, who will be the release manager, when the repository will be
> frozen to create a release, and other assorted information to keep
> volunteers from tripping over each other. Lazy majority decides each
> issue in a release plan.
>
> Release Testing
>
> After a new release is built, it must be tested before being released to
> the public. Majority approval is required before the release can be made.
> "
>
In our case the components are tested very well in Cocoon.
> > I want to release the store, the xmlutil and the sourceresolve
> > subprojects. Anyone against it?
>
> Before releasing excalibur components, I prefer to check if we can move
> the stuff elswhere, before creating a legacy here.
>
> So -1 till anyone wanting to release excalibur stuff explains why these
> have to be released here versus be in some kind of Commons.
>
Ah, the good old discussion about commons vs. avalon. Great!
> Now more specific points:
> - xmlutil -1: seems like a package for xml-commons, no Avalon dependency
>
Hmm, xmlutil provides Avalon components. I'm fine with moving them if
xml-commons wants to have a dependency on avalon.
> - sourceresolve +1: seems like a non-commons-convertible Avalon
> component to me
>
> - store -0: it *is* an Avalon Component, but there is a cool simplestore
> package in Jakarta-commons-sandbox, written by Gerhard Froehlich
> (g-froehlich@gmx.de) Juozas Baliuka (baliuka@mwm.lt).
> Gerhard, what's the status? Can't we make our store use simplestore as
> an impl?
>
Again, this project defines components (with an implementation). It is
of course possible to add an implementation which uses a commons-sandbox
implementation - but that's optional in my eyes.
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Releasing excalibur subprojects
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
> Hi,
>
> can someone give me a hint on what's the procedure to release a
> subproject? Is a vote necessary?
For releases, always, as said in our Project Guidelines.
"
Release Plan
A release plan is used to keep all volunteers aware of when a release is
desired, who will be the release manager, when the repository will be
frozen to create a release, and other assorted information to keep
volunteers from tripping over each other. Lazy majority decides each
issue in a release plan.
Release Testing
After a new release is built, it must be tested before being released to
the public. Majority approval is required before the release can be made.
"
> I want to release the store, the xmlutil and the sourceresolve
> subprojects. Anyone against it?
Before releasing excalibur components, I prefer to check if we can move
the stuff elswhere, before creating a legacy here.
So -1 till anyone wanting to release excalibur stuff explains why these
have to be released here versus be in some kind of Commons.
Now more specific points:
- xmlutil -1: seems like a package for xml-commons, no Avalon dependency
- sourceresolve +1: seems like a non-commons-convertible Avalon
component to me
- store -0: it *is* an Avalon Component, but there is a cool simplestore
package in Jakarta-commons-sandbox, written by Gerhard Froehlich
(g-froehlich@gmx.de) Juozas Baliuka (baliuka@mwm.lt).
Gerhard, what's the status? Can't we make our store use simplestore as
an impl?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Releasing excalibur subprojects
Posted by Peter Donald <pe...@apache.org>.
On Fri, 16 Aug 2002 20:17, Gerhard Froehlich wrote:
> Peter Donald wrote:
> > (don't use store)
>
> Where is the problem? Sry didn't follow up the lists the last weeks...
Sorry. I am saying that I don't use store so I don't have an opinion about it
;)
--
Cheers,
Peter Donald
--------------------------------------------------
Logic: The art of being wrong with confidence...
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Releasing excalibur subprojects
Posted by Gerhard Froehlich <g-...@gmx.de>.
Peter Donald wrote:
> (don't use store)
Where is the problem? Sry didn't follow up the lists the last weeks...
Greets
Gerhard
--
"Three o'clock is always too late or too early for
anything you want to do.
(Jean-Paul Sartre)"
Weblogging at: http://radio.weblogs.com/0107791/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Releasing excalibur subprojects
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Fri, 16 Aug 2002 20:26, Carsten Ziegeler wrote:
>
>
>>Peter Donald wrote:
>>
>>
>>>On Fri, 16 Aug 2002 20:09, Carsten Ziegeler wrote:
>>>
>>>
>>>>can someone give me a hint on what's the procedure to release a
>>>>subproject? Is a vote necessary?
>>>>
>>>>
>>>There is no real formal process for release. Usually it is lazy
>>>consensus for
>>>components that are already released so just state intentions and unless
>>>anyone objects go for it.
>>>
>>>
>>Ok, but what does 'go for it' mean? Where do I put the dists, do we
>>have bin and src dists etc. Or is this a matter of the subproject as well?
>>
>>
>
>oh that.
>
>* Update jakarta-avalon-site CVS with new docs.
>* create distribution (I usually create a single distribution for excalibur
>components and include src in src.zip inside a "binary distribution).
>
>Ideally a distribution would look like
>
>foo-1.0/README.txt
>foo-1.0/LICENSE.txt
>foo-1.0/docs/**
>foo-1.0/src.zip (the source for foo)
>foo-1.0/foo-1.0.jar
>foo-1.0/foo-all-1.0.jar (contains foo and its dependencies)
>foo-1.0/lib/baz-2.3.jar (contains jars foo is dependent upon)
>
>(The last two jars may be optional depending on personal preference).
>
>
>
>>>One thing
>>>I would like
>>>to see is for sourceresolve to be upgraded so that components do not
>>>implement Component interface however that requires changes to cocoon
>>>presumably ...
>>>
>>>
>>Hmm, the only problem is the release() method of the component manager,
>>were we would have to cast to Component for these components - this
>>would not be an incompatible change as we did not release Cocoon
>>with the sourceresolve package, but it's inconsistent - there are
>>components were you have to cast and 95% you don't have to.
>>What do others thing on this?
>>
>>
>
>No I mean the whole package should not be using Component - instead Cocoon
>should upgrade to Serviceable in all places possible ;)
>
-1 on removal of Component from implements clause
Project that are already currently using ComponentManager and have not
yet moved to ServiceManager will break if you remove the Component
interface. It seems a lot more friendly to our users (Cocoon, James,
etc.) to leave in place the "implements Component".
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Releasing excalibur subprojects
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Peter Donald wrote:
>
> On Fri, 16 Aug 2002 20:26, Carsten Ziegeler wrote:
> > Peter Donald wrote:
> > > On Fri, 16 Aug 2002 20:09, Carsten Ziegeler wrote:
> > > > can someone give me a hint on what's the procedure to release a
> > > > subproject? Is a vote necessary?
> > >
> > > There is no real formal process for release. Usually it is lazy
> > > consensus for
> > > components that are already released so just state intentions
> and unless
> > > anyone objects go for it.
> >
> > Ok, but what does 'go for it' mean? Where do I put the dists, do we
> > have bin and src dists etc. Or is this a matter of the
> subproject as well?
>
> oh that.
>
> * Update jakarta-avalon-site CVS with new docs.
> * create distribution (I usually create a single distribution for
> excalibur
> components and include src in src.zip inside a "binary distribution).
>
> Ideally a distribution would look like
>
> foo-1.0/README.txt
> foo-1.0/LICENSE.txt
> foo-1.0/docs/**
> foo-1.0/src.zip (the source for foo)
> foo-1.0/foo-1.0.jar
> foo-1.0/foo-all-1.0.jar (contains foo and its dependencies)
> foo-1.0/lib/baz-2.3.jar (contains jars foo is dependent upon)
>
> (The last two jars may be optional depending on personal preference).
>
Ok, many thanks - that sounds easy :)
> >
> > Hmm, the only problem is the release() method of the component manager,
> > were we would have to cast to Component for these components - this
> > would not be an incompatible change as we did not release Cocoon
> > with the sourceresolve package, but it's inconsistent - there are
> > components were you have to cast and 95% you don't have to.
> > What do others thing on this?
>
> No I mean the whole package should not be using Component -
> instead Cocoon
> should upgrade to Serviceable in all places possible ;)
>
Ah, sorry, I didn't express myself proper - yes, I know that
you mean the whole package. But Cocoon itself uses much more
components than from the sourceresolve package, these are the 95%
I'm refering to.
Serviceable in all places...sounds great!
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Releasing excalibur subprojects
Posted by Peter Donald <pe...@apache.org>.
On Fri, 16 Aug 2002 20:26, Carsten Ziegeler wrote:
> Peter Donald wrote:
> > On Fri, 16 Aug 2002 20:09, Carsten Ziegeler wrote:
> > > can someone give me a hint on what's the procedure to release a
> > > subproject? Is a vote necessary?
> >
> > There is no real formal process for release. Usually it is lazy
> > consensus for
> > components that are already released so just state intentions and unless
> > anyone objects go for it.
>
> Ok, but what does 'go for it' mean? Where do I put the dists, do we
> have bin and src dists etc. Or is this a matter of the subproject as well?
oh that.
* Update jakarta-avalon-site CVS with new docs.
* create distribution (I usually create a single distribution for excalibur
components and include src in src.zip inside a "binary distribution).
Ideally a distribution would look like
foo-1.0/README.txt
foo-1.0/LICENSE.txt
foo-1.0/docs/**
foo-1.0/src.zip (the source for foo)
foo-1.0/foo-1.0.jar
foo-1.0/foo-all-1.0.jar (contains foo and its dependencies)
foo-1.0/lib/baz-2.3.jar (contains jars foo is dependent upon)
(The last two jars may be optional depending on personal preference).
> > One thing
> > I would like
> > to see is for sourceresolve to be upgraded so that components do not
> > implement Component interface however that requires changes to cocoon
> > presumably ...
>
> Hmm, the only problem is the release() method of the component manager,
> were we would have to cast to Component for these components - this
> would not be an incompatible change as we did not release Cocoon
> with the sourceresolve package, but it's inconsistent - there are
> components were you have to cast and 95% you don't have to.
> What do others thing on this?
No I mean the whole package should not be using Component - instead Cocoon
should upgrade to Serviceable in all places possible ;)
--
Cheers,
Peter Donald
--------------------------------------------------
The fact that nobody understands you doesn't
mean you're an artist.
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Releasing excalibur subprojects
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Peter Donald wrote:
>
> On Fri, 16 Aug 2002 20:09, Carsten Ziegeler wrote:
> > can someone give me a hint on what's the procedure to release a
> > subproject? Is a vote necessary?
>
> There is no real formal process for release. Usually it is lazy
> consensus for
> components that are already released so just state intentions and unless
> anyone objects go for it.
>
Ok, but what does 'go for it' mean? Where do I put the dists, do we
have bin and src dists etc. Or is this a matter of the subproject as well?
> However we require a vote to go for a component to move from
> alpha to released
> which I believe those components are doing? ANyways I would be +1 for
> promoting xmlutil and sourceresolve (don't use store).
Ok, yes, that's right. I will start a vote then.
> One thing
> I would like
> to see is for sourceresolve to be upgraded so that components do not
> implement Component interface however that requires changes to cocoon
> presumably ...
>
Hmm, the only problem is the release() method of the component manager,
were we would have to cast to Component for these components - this
would not be an incompatible change as we did not release Cocoon
with the sourceresolve package, but it's inconsistent - there are
components were you have to cast and 95% you don't have to.
What do others thing on this?
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Releasing excalibur subprojects
Posted by Peter Donald <pe...@apache.org>.
On Fri, 16 Aug 2002 20:09, Carsten Ziegeler wrote:
> can someone give me a hint on what's the procedure to release a
> subproject? Is a vote necessary?
There is no real formal process for release. Usually it is lazy consensus for
components that are already released so just state intentions and unless
anyone objects go for it.
However we require a vote to go for a component to move from alpha to released
which I believe those components are doing? ANyways I would be +1 for
promoting xmlutil and sourceresolve (don't use store). One thing I would like
to see is for sourceresolve to be upgraded so that components do not
implement Component interface however that requires changes to cocoon
presumably ...
--
Cheers,
Peter Donald
----------------------------------------------
Money is how people with no talent keep score.
----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>