You are viewing a plain text version of this content. The canonical link for it is here.
Posted to -deprecated@jakarta.apache.org by Peter Donald <do...@apache.org> on 2001/02/21 03:31:35 UTC
Stymied?
Hi,
As the process seems to have slowed and every one seems to be talking about
different approach maybe we should look at exactly what we want. There is
three different things that people are talking about
1. component repository (ie ToolForge+CJAN)
2. vetted/tested/approved components (ie Avalon+CJAN)
3. base util (Something similar to AUT - Apache Utility Toolkit).
I am happy to work on (3) and are familiar enough with both Turbine and
Avalon bases that I could help extract the code from them that was
necessary. I already work on (2) ;)
So if there is enough supporters from other projects do you think it would
be useful to start AUT now using the standard apache model? For (1) I think
there needs to be a few issues resolved. Thoughts?
Another model no one has mentioned is the "gatherer" style. ie Code remains
in whatever CVS it is in now but there is another process to gather
components from all the different places and publishes them?
So you would have an XML descriptor for each project that lists all
sub-products. So if you wanted digester from struts, the connection pool
from turbine and the feedReader from jetspeed you just write your own
script. This script would indicate your dependencies. During build these
dependencies are sucked from CJAN/whatever and placed in lib directory. In
many ways this can draw on and complement gump. Thoughts?
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Stymied?
Posted by Peter Donald <do...@apache.org>.
At 08:51 21/2/01 -0500, Geir Magnusson Jr. wrote:
>Peter Donald wrote:
>>
>> Hi,
>>
>> As the process seems to have slowed and every one seems to be talking about
>> different approach maybe we should look at exactly what we want. There is
>> three different things that people are talking about
>>
>> 1. component repository (ie ToolForge+CJAN)
>> 2. vetted/tested/approved components (ie Avalon+CJAN)
>> 3. base util (Something similar to AUT - Apache Utility Toolkit).
>
>I have a little trouble seeing the distinction between 2 and 3.
well the size/applicability I guess is where the difference is.
3 would contain elements such as
* CascadingThrowable/Exception support that every project has
* IOUtil that almost every project has
* FileUtil
* Exception util
* Stack introspector stuff
* Command line parameter parser
etc
ie All the basic stuff that any large project aquires overtime and are
relatively stable.
(2) would contain stuff like a DB pool/connection manager/action
router/action interface/etc
>> I am happy to work on (3) and are familiar enough with both Turbine and
>> Avalon bases that I could help extract the code from them that was
>> necessary. I already work on (2) ;)
>
>That would be avalon? :)
yaah ;)
>I am happy to join in on Avalon, as long as I was sure that that the
>charter allowed for the things I want to do. Specifically, I am looking
>to make mini-projects out of common software elements (like a conneciton
>pool, XML config utilities, etc) that aren't required to live in a
>framework (but can easily be used by any framework), is identifiable and
>buildable as a separate unit (like being able to build/download a
>Jakarta DBConn Pool w/o dragging endless amounts of unrelated stuff
>with it), etc. Given the recent changes I saw regarding the maillists
>and all the sublists, my understanding of Avalon is still a bit vague.
>I am following it trying to figure it out, though :)
You may want to hold off till end of week as we are still in progress with
the move ;)
>> So if there is enough supporters from other projects do you think it would
>> be useful to start AUT now using the standard apache model? For (1) I think
>> there needs to be a few issues resolved. Thoughts?
>
>What would 'AUT' be?
Apache Utility Toolkit
>
>>
>> Another model no one has mentioned is the "gatherer" style. ie Code remains
>> in whatever CVS it is in now but there is another process to gather
>> components from all the different places and publishes them?
>>
>> So you would have an XML descriptor for each project that lists all
>> sub-products. So if you wanted digester from struts, the connection pool
>> from turbine and the feedReader from jetspeed you just write your own
>> script. This script would indicate your dependencies. During build these
>> dependencies are sucked from CJAN/whatever and placed in lib directory. In
>> many ways this can draw on and complement gump. Thoughts?
>
>This sounds like a great thing for use within Jakarta projects, but I
>still don't think it solves the problem of making things easily
>available, identifiable, documented, etc to outside users, like all
>other jakarta projects have a deliverable available for outside users.
true - that would require a bit more work ;)
>The other issue is that it wouldn't be unexpected if those sub-products
>you mentioned changed over time as the needs of the owning project
>changed, greatly screwing up life for anyone that use it. The only way
>to avoid that is for the project to 'declare' as sub-projects parts of
>the project code it is willing to support as such, and maintain on an
>ongoing basis.
right. And declare specific versions as well - so you can retrieve version
3.2.1 or 1.2.3 or perhaps 2.1.2 etc.
>That would work if you could get projects to do it, but given that we
>have duplicated functionality among the Jakarta projects, I think it
>might be better if we consolodated some of that code, giving each
>project the freedom to use it. (If projects don't use it, we screwed
>up...)
right - the consolidation etc is what Avalon tried to do but it requires
supporters within each project to work.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Stymied?
Posted by Peter Donald <do...@apache.org>.
At 10:06 21/2/01 -0500, Geir Magnusson Jr. wrote:
>The way I hope, it is *used* by a framework, not *part of* a framework.
>
>Hopefully, down at the bottom, there is still a useful DBCP that stands
>on it's own. I know there is no standard interface for a DBCP except
>that they seem best when you don't know they are there : they look like
>a Driver.
good - the answer I was hoping for. The only issue remaining is that that
is going to require a LOT of work - to keep from people taking short cuts
and integrating it with a config/services/environment framework we are
going to need some very tuff thought police ;) The reason being that it is
damn hard to do that and as yet I have only seen one set of components that
could do that ;)
>Maybe what this does is have the DBCP provide hooks to work with larger
>scale entities. I dunno. I can't see that far. This sounds like stuff
>someone already knows, or we will find out through doing. I would
>prefer to see this shot down if 'someone knows'.
Theres a few ways of doing it - most of them are covered in standard texts
ala Design Patterns by GoF. I have been working on components of these
types for a whiel so we should be able to kick the tyres and light the
fires ;)
>> We need to define clearly wear the difference between this project is and
>> where Avalon is.
>
>Sure. But it seems to me we just went full circle and are back to
>considering Avalon as a framework again. Ohh, head hurts, head hurts :)
Ahh but the mystery of Avalon is that it is about 5 different things and
one name may refer to different bits of it - depending on the use ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Stymied?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Peter Donald wrote:
>
> Considering the DBPool issue kickstarted this whole thing it may be
> possible to start with that ?
> Cheers,
This probably won't come as a surprise : +1
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Stymied?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Peter Donald wrote:
>
> Considering the DBPool issue kickstarted this whole thing it may be
> possible to start with that ?
> Cheers,
This probably won't come as a surprise : +1
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Stymied?
Posted by Peter Donald <do...@apache.org>.
At 09:11 21/2/01 -0500, Ted Husted wrote:
>What do you suggest then, Pete?
well - both implementations serve a different need so keep them both and
let the users pick which one they want to use ;) Personally I intend to use
both ... at different places in the same app ;)
>The Struts Digester is a pretty cool tool on its own,
agreed.
>and would take very little to have it running as a utility. (Some people
>all already using it in their own non-Struts projects.) But, it is
>important that we start with something that two or more products can use
>right away.
Considering the DBPool issue kickstarted this whole thing it may be
possible to start with that ?
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Stymied?
Posted by Peter Donald <do...@apache.org>.
At 09:11 21/2/01 -0500, Ted Husted wrote:
>What do you suggest then, Pete?
well - both implementations serve a different need so keep them both and
let the users pick which one they want to use ;) Personally I intend to use
both ... at different places in the same app ;)
>The Struts Digester is a pretty cool tool on its own,
agreed.
>and would take very little to have it running as a utility. (Some people
>all already using it in their own non-Struts projects.) But, it is
>important that we start with something that two or more products can use
>right away.
Considering the DBPool issue kickstarted this whole thing it may be
possible to start with that ?
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Stymied?
Posted by Ted Husted <ne...@husted.com>.
Peter Donald wrote:
> >> Merging the Avalon and Struts
> >> components seems manageable, and may provide a lot of
> >> utility to other products.
>
> I doubt it will ever happen. Both config frameworks are good but they serve
> different purposes much like SAX and DOM are different models. They really
> belong side-by-side. Neither project would get any advantage from integration.
What do you suggest then, Pete?
The idea of merging the two came from
< http://www.mail-archive.com/general@jakarta.apache.org/msg00194.html >
but I must have misread what you were suggesting.
The Struts Digester is a pretty cool tool on its own,
<
http://jakarta.apache.org/struts/api/org/apache/struts/digester/package-summary.html#package_description
>
and would take very little to have it running as a utility. (Some people
all already using it in their own non-Struts projects.) But, it is
important that we start with something that two or more products can use
right away.
-T.
Re: Stymied?
Posted by Ted Husted <ne...@husted.com>.
Peter Donald wrote:
> >> Merging the Avalon and Struts
> >> components seems manageable, and may provide a lot of
> >> utility to other products.
>
> I doubt it will ever happen. Both config frameworks are good but they serve
> different purposes much like SAX and DOM are different models. They really
> belong side-by-side. Neither project would get any advantage from integration.
What do you suggest then, Pete?
The idea of merging the two came from
< http://www.mail-archive.com/general@jakarta.apache.org/msg00194.html >
but I must have misread what you were suggesting.
The Struts Digester is a pretty cool tool on its own,
<
http://jakarta.apache.org/struts/api/org/apache/struts/digester/package-summary.html#package_description
>
and would take very little to have it running as a utility. (Some people
all already using it in their own non-Struts projects.) But, it is
important that we start with something that two or more products can use
right away.
-T.
Re: Stymied?
Posted by Peter Donald <do...@apache.org>.
At 10:06 21/2/01 -0500, Geir Magnusson Jr. wrote:
>The way I hope, it is *used* by a framework, not *part of* a framework.
>
>Hopefully, down at the bottom, there is still a useful DBCP that stands
>on it's own. I know there is no standard interface for a DBCP except
>that they seem best when you don't know they are there : they look like
>a Driver.
good - the answer I was hoping for. The only issue remaining is that that
is going to require a LOT of work - to keep from people taking short cuts
and integrating it with a config/services/environment framework we are
going to need some very tuff thought police ;) The reason being that it is
damn hard to do that and as yet I have only seen one set of components that
could do that ;)
>Maybe what this does is have the DBCP provide hooks to work with larger
>scale entities. I dunno. I can't see that far. This sounds like stuff
>someone already knows, or we will find out through doing. I would
>prefer to see this shot down if 'someone knows'.
Theres a few ways of doing it - most of them are covered in standard texts
ala Design Patterns by GoF. I have been working on components of these
types for a whiel so we should be able to kick the tyres and light the
fires ;)
>> We need to define clearly wear the difference between this project is and
>> where Avalon is.
>
>Sure. But it seems to me we just went full circle and are back to
>considering Avalon as a framework again. Ohh, head hurts, head hurts :)
Ahh but the mystery of Avalon is that it is about 5 different things and
one name may refer to different bits of it - depending on the use ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Stymied?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Peter Donald wrote:
>
> >> My actual suggestion would be to start with the XML Configuration
> >> component, along with the Testing Suite, supported by a site
> >> infrastructure designed to scale to multiple components.
> >
> >And to test that scalabilty, lets do DBConnection Pool as well :)
>
> I have a few concerns about this plan of attack. When we are building these
> components how will this evolve. I expect at the start that they will
> largely be independent. Then someone will need configuration data for DB
> pool and thus they will use the XML Config component to get it. This is
> integrated on top of that.
Sure. 'On top of' being the key phrase there. Hopefully the DBCP is
untouched, or at least the standard interfaces are untouched.
>
> Now a bit down the line it is decided that there needs to be a way to share
> connections and share components between DBPools and a native system (ie
> may need to do transaction monitoring etc) so someone decides to integrate
> DBPool into a service directory.
Ok. So I interpret this as they are *using* the DBCP still.
> Now this DBPool is part of a framework rather than an API - and depending
> on framework parts chosen (ie whos configuration component and whos service
> directory - turbine, avalon or struts) we have just built yet another
> framework.
The way I hope, it is *used* by a framework, not *part of* a framework.
Hopefully, down at the bottom, there is still a useful DBCP that stands
on it's own. I know there is no standard interface for a DBCP except
that they seem best when you don't know they are there : they look like
a Driver.
Maybe what this does is have the DBCP provide hooks to work with larger
scale entities. I dunno. I can't see that far. This sounds like stuff
someone already knows, or we will find out through doing. I would
prefer to see this shot down if 'someone knows'.
> We need to define clearly wear the difference between this project is and
> where Avalon is.
Sure. But it seems to me we just went full circle and are back to
considering Avalon as a framework again. Ohh, head hurts, head hurts :)
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Stymied?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Peter Donald wrote:
>
> >> My actual suggestion would be to start with the XML Configuration
> >> component, along with the Testing Suite, supported by a site
> >> infrastructure designed to scale to multiple components.
> >
> >And to test that scalabilty, lets do DBConnection Pool as well :)
>
> I have a few concerns about this plan of attack. When we are building these
> components how will this evolve. I expect at the start that they will
> largely be independent. Then someone will need configuration data for DB
> pool and thus they will use the XML Config component to get it. This is
> integrated on top of that.
Sure. 'On top of' being the key phrase there. Hopefully the DBCP is
untouched, or at least the standard interfaces are untouched.
>
> Now a bit down the line it is decided that there needs to be a way to share
> connections and share components between DBPools and a native system (ie
> may need to do transaction monitoring etc) so someone decides to integrate
> DBPool into a service directory.
Ok. So I interpret this as they are *using* the DBCP still.
> Now this DBPool is part of a framework rather than an API - and depending
> on framework parts chosen (ie whos configuration component and whos service
> directory - turbine, avalon or struts) we have just built yet another
> framework.
The way I hope, it is *used* by a framework, not *part of* a framework.
Hopefully, down at the bottom, there is still a useful DBCP that stands
on it's own. I know there is no standard interface for a DBCP except
that they seem best when you don't know they are there : they look like
a Driver.
Maybe what this does is have the DBCP provide hooks to work with larger
scale entities. I dunno. I can't see that far. This sounds like stuff
someone already knows, or we will find out through doing. I would
prefer to see this shot down if 'someone knows'.
> We need to define clearly wear the difference between this project is and
> where Avalon is.
Sure. But it seems to me we just went full circle and are back to
considering Avalon as a framework again. Ohh, head hurts, head hurts :)
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Stymied?
Posted by Peter Donald <do...@apache.org>.
>> My actual suggestion would be to start with the XML Configuration
>> component, along with the Testing Suite, supported by a site
>> infrastructure designed to scale to multiple components.
>
>And to test that scalabilty, lets do DBConnection Pool as well :)
I have a few concerns about this plan of attack. When we are building these
components how will this evolve. I expect at the start that they will
largely be independent. Then someone will need configuration data for DB
pool and thus they will use the XML Config component to get it. This is
integrated on top of that.
Now a bit down the line it is decided that there needs to be a way to share
connections and share components between DBPools and a native system (ie
may need to do transaction monitoring etc) so someone decides to integrate
DBPool into a service directory.
Now this DBPool is part of a framework rather than an API - and depending
on framework parts chosen (ie whos configuration component and whos service
directory - turbine, avalon or struts) we have just built yet another
framework.
We need to define clearly wear the difference between this project is and
where Avalon is.
>> Testing seems to be a hot button right now all over Jakarta. But we
>> would also need something to test. The XML Configuration component
>> saw the largest number of votes. Merging the Avalon and Struts
>> components seems manageable, and may provide a lot of
>> utility to other products.
I doubt it will ever happen. Both config frameworks are good but they serve
different purposes much like SAX and DOM are different models. They really
belong side-by-side. Neither project would get any advantage from integration.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Stymied?
Posted by cm...@yahoo.com.
> Does this mean that we have a project with an XMLConfig component that
> will be used by Avalon and Struts, or will there now be three? :)
And of course, there is the XML config tool from tomcat3.x and the xml
config from ant. Both of them have minimal dependencies on the rest of the
project ( none for tomcat, log/getProperty for ant - but easy to remove ).
So at least 4 to choose from.
How do you choose ? Majority ? But an un-informed majority can't make the
right decision - and few people have used more than one.
That's why I think it is essential to:
1. Allow multiple implementations. Nobody can make the right decision
without all the information - and in some cases different solutions may
have different use cases.
What is important is to have the general-purpose code clearly identified
and in a common place ( because that's the only way we can make sure it
doesn't have hidden dependencies and is indeed reusable ). And it's
important to let time and users to select - instead of making arbitrary
decisions.
2. Each component should have as commiters the union of (interested
!) commiters from the projects that are using it. It's about having -1
control over incompatible changes and having a way to influence the
evolution of the component - each project has specific needs, and the only
way to get a component that can be shared is to make sure that all parties
are represented.
That's why I think having a group of commiters for each component (
selected with any other mechanism ) is bad - the goal is to share
components, and that can't be done if we don't share control.
I don't think the goal is to develop components - we already do that.
The problem that started all this was that components are not shared (
by projects that develop them ) and are not reused ( by projects that
choose to replicate ).
Maybe we should first agree on the goals, before choosing the methods.
Costin
Re: Stymied?
Posted by Peter Donald <do...@apache.org>.
>> My actual suggestion would be to start with the XML Configuration
>> component, along with the Testing Suite, supported by a site
>> infrastructure designed to scale to multiple components.
>
>And to test that scalabilty, lets do DBConnection Pool as well :)
I have a few concerns about this plan of attack. When we are building these
components how will this evolve. I expect at the start that they will
largely be independent. Then someone will need configuration data for DB
pool and thus they will use the XML Config component to get it. This is
integrated on top of that.
Now a bit down the line it is decided that there needs to be a way to share
connections and share components between DBPools and a native system (ie
may need to do transaction monitoring etc) so someone decides to integrate
DBPool into a service directory.
Now this DBPool is part of a framework rather than an API - and depending
on framework parts chosen (ie whos configuration component and whos service
directory - turbine, avalon or struts) we have just built yet another
framework.
We need to define clearly wear the difference between this project is and
where Avalon is.
>> Testing seems to be a hot button right now all over Jakarta. But we
>> would also need something to test. The XML Configuration component
>> saw the largest number of votes. Merging the Avalon and Struts
>> components seems manageable, and may provide a lot of
>> utility to other products.
I doubt it will ever happen. Both config frameworks are good but they serve
different purposes much like SAX and DOM are different models. They really
belong side-by-side. Neither project would get any advantage from integration.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Stymied?
Posted by cm...@yahoo.com.
> Does this mean that we have a project with an XMLConfig component that
> will be used by Avalon and Struts, or will there now be three? :)
And of course, there is the XML config tool from tomcat3.x and the xml
config from ant. Both of them have minimal dependencies on the rest of the
project ( none for tomcat, log/getProperty for ant - but easy to remove ).
So at least 4 to choose from.
How do you choose ? Majority ? But an un-informed majority can't make the
right decision - and few people have used more than one.
That's why I think it is essential to:
1. Allow multiple implementations. Nobody can make the right decision
without all the information - and in some cases different solutions may
have different use cases.
What is important is to have the general-purpose code clearly identified
and in a common place ( because that's the only way we can make sure it
doesn't have hidden dependencies and is indeed reusable ). And it's
important to let time and users to select - instead of making arbitrary
decisions.
2. Each component should have as commiters the union of (interested
!) commiters from the projects that are using it. It's about having -1
control over incompatible changes and having a way to influence the
evolution of the component - each project has specific needs, and the only
way to get a component that can be shared is to make sure that all parties
are represented.
That's why I think having a group of commiters for each component (
selected with any other mechanism ) is bad - the goal is to share
components, and that can't be done if we don't share control.
I don't think the goal is to develop components - we already do that.
The problem that started all this was that components are not shared (
by projects that develop them ) and are not reused ( by projects that
choose to replicate ).
Maybe we should first agree on the goals, before choosing the methods.
Costin
Re: Stymied?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ted Husted wrote:
>
> My feeling is that we need to do (3) to energize (1) and (2) (or (4) -
> The
> Gathering). I also feel we need to something both useful and manageable
> for (3) that can serve as a baseline example for future work.
>
> My actual suggestion would be to start with the XML Configuration
> component, along with the Testing Suite, supported by a site
> infrastructure designed to scale to multiple components.
And to test that scalabilty, lets do DBConnection Pool as well :)
> Testing seems to be a hot button right now all over Jakarta. But we
> would also need something to test. The XML Configuration component
> saw the largest number of votes. Merging the Avalon and Struts
> components seems manageable, and may provide a lot of
> utility to other products.
Does this mean that we have a project with an XMLConfig component that
will be used by Avalon and Struts, or will there now be three? :)
I think it's important :
* When we are done, we haven't increased the number of XML config tools
in Jakarta.
* The XML Config tool has standalone documentation and build
instructions.
* It is usable by and visible to an external developer that comes to
Jakarta 'shopping'
Ideally :
* The project includes committers from Avalon and Struts because
* Avalon uses it
* Struts uses it.
However, if it works out that we can't find a solution acceptable to
both Avalon and Struts, then we focus on making something suitable for
one of them, to keep the total # of like utilities in Jakarta constant
or smaller. But lets work hard to do something both are satisfied with.
This might be a good way to make all sides happy, as we can see how it
works out wrt committers from all interested parties.
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Stymied?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ted Husted wrote:
>
> My feeling is that we need to do (3) to energize (1) and (2) (or (4) -
> The
> Gathering). I also feel we need to something both useful and manageable
> for (3) that can serve as a baseline example for future work.
>
> My actual suggestion would be to start with the XML Configuration
> component, along with the Testing Suite, supported by a site
> infrastructure designed to scale to multiple components.
And to test that scalabilty, lets do DBConnection Pool as well :)
> Testing seems to be a hot button right now all over Jakarta. But we
> would also need something to test. The XML Configuration component
> saw the largest number of votes. Merging the Avalon and Struts
> components seems manageable, and may provide a lot of
> utility to other products.
Does this mean that we have a project with an XMLConfig component that
will be used by Avalon and Struts, or will there now be three? :)
I think it's important :
* When we are done, we haven't increased the number of XML config tools
in Jakarta.
* The XML Config tool has standalone documentation and build
instructions.
* It is usable by and visible to an external developer that comes to
Jakarta 'shopping'
Ideally :
* The project includes committers from Avalon and Struts because
* Avalon uses it
* Struts uses it.
However, if it works out that we can't find a solution acceptable to
both Avalon and Struts, then we focus on making something suitable for
one of them, to keep the total # of like utilities in Jakarta constant
or smaller. But lets work hard to do something both are satisfied with.
This might be a good way to make all sides happy, as we can see how it
works out wrt committers from all interested parties.
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Stymied?
Posted by Ted Husted <ne...@husted.com>.
My feeling is that we need to do (3) to energize (1) and (2) (or (4) -
The
Gathering). I also feel we need to something both useful and manageable
for (3) that can serve as a baseline example for future work.
My actual suggestion would be to start with the XML Configuration
component, along with the Testing Suite, supported by a site
infrastructure designed to scale to multiple components.
Testing seems to be a hot button right now all over Jakarta. But we
would also need something to test. The XML Configuration component
saw the largest number of votes. Merging the Avalon and Struts
components seems manageable, and may provide a lot of
utility to other products.
Peter Donald wrote:
>
> Hi,
>
> As the process seems to have slowed and every one seems to be talking about
> different approach maybe we should look at exactly what we want. There is
> three different things that people are talking about
>
> 1. component repository (ie ToolForge+CJAN)
> 2. vetted/tested/approved components (ie Avalon+CJAN)
> 3. base util (Something similar to AUT - Apache Utility Toolkit).
>
> I am happy to work on (3) and are familiar enough with both Turbine and
> Avalon bases that I could help extract the code from them that was
> necessary. I already work on (2) ;)
>
> So if there is enough supporters from other projects do you think it would
> be useful to start AUT now using the standard apache model? For (1) I think
> there needs to be a few issues resolved. Thoughts?
>
> Another model no one has mentioned is the "gatherer" style. ie Code remains
> in whatever CVS it is in now but there is another process to gather
> components from all the different places and publishes them?
>
> So you would have an XML descriptor for each project that lists all
> sub-products. So if you wanted digester from struts, the connection pool
> from turbine and the feedReader from jetspeed you just write your own
> script. This script would indicate your dependencies. During build these
> dependencies are sucked from CJAN/whatever and placed in lib directory. In
> many ways this can draw on and complement gump. Thoughts?
>
> Cheers,
>
> Pete
>
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof." |
> | - John Kenneth Galbraith |
> *-----------------------------------------------------*
Re: Stymied?
Posted by Peter Donald <do...@apache.org>.
At 08:51 21/2/01 -0500, Geir Magnusson Jr. wrote:
>Peter Donald wrote:
>>
>> Hi,
>>
>> As the process seems to have slowed and every one seems to be talking about
>> different approach maybe we should look at exactly what we want. There is
>> three different things that people are talking about
>>
>> 1. component repository (ie ToolForge+CJAN)
>> 2. vetted/tested/approved components (ie Avalon+CJAN)
>> 3. base util (Something similar to AUT - Apache Utility Toolkit).
>
>I have a little trouble seeing the distinction between 2 and 3.
well the size/applicability I guess is where the difference is.
3 would contain elements such as
* CascadingThrowable/Exception support that every project has
* IOUtil that almost every project has
* FileUtil
* Exception util
* Stack introspector stuff
* Command line parameter parser
etc
ie All the basic stuff that any large project aquires overtime and are
relatively stable.
(2) would contain stuff like a DB pool/connection manager/action
router/action interface/etc
>> I am happy to work on (3) and are familiar enough with both Turbine and
>> Avalon bases that I could help extract the code from them that was
>> necessary. I already work on (2) ;)
>
>That would be avalon? :)
yaah ;)
>I am happy to join in on Avalon, as long as I was sure that that the
>charter allowed for the things I want to do. Specifically, I am looking
>to make mini-projects out of common software elements (like a conneciton
>pool, XML config utilities, etc) that aren't required to live in a
>framework (but can easily be used by any framework), is identifiable and
>buildable as a separate unit (like being able to build/download a
>Jakarta DBConn Pool w/o dragging endless amounts of unrelated stuff
>with it), etc. Given the recent changes I saw regarding the maillists
>and all the sublists, my understanding of Avalon is still a bit vague.
>I am following it trying to figure it out, though :)
You may want to hold off till end of week as we are still in progress with
the move ;)
>> So if there is enough supporters from other projects do you think it would
>> be useful to start AUT now using the standard apache model? For (1) I think
>> there needs to be a few issues resolved. Thoughts?
>
>What would 'AUT' be?
Apache Utility Toolkit
>
>>
>> Another model no one has mentioned is the "gatherer" style. ie Code remains
>> in whatever CVS it is in now but there is another process to gather
>> components from all the different places and publishes them?
>>
>> So you would have an XML descriptor for each project that lists all
>> sub-products. So if you wanted digester from struts, the connection pool
>> from turbine and the feedReader from jetspeed you just write your own
>> script. This script would indicate your dependencies. During build these
>> dependencies are sucked from CJAN/whatever and placed in lib directory. In
>> many ways this can draw on and complement gump. Thoughts?
>
>This sounds like a great thing for use within Jakarta projects, but I
>still don't think it solves the problem of making things easily
>available, identifiable, documented, etc to outside users, like all
>other jakarta projects have a deliverable available for outside users.
true - that would require a bit more work ;)
>The other issue is that it wouldn't be unexpected if those sub-products
>you mentioned changed over time as the needs of the owning project
>changed, greatly screwing up life for anyone that use it. The only way
>to avoid that is for the project to 'declare' as sub-projects parts of
>the project code it is willing to support as such, and maintain on an
>ongoing basis.
right. And declare specific versions as well - so you can retrieve version
3.2.1 or 1.2.3 or perhaps 2.1.2 etc.
>That would work if you could get projects to do it, but given that we
>have duplicated functionality among the Jakarta projects, I think it
>might be better if we consolodated some of that code, giving each
>project the freedom to use it. (If projects don't use it, we screwed
>up...)
right - the consolidation etc is what Avalon tried to do but it requires
supporters within each project to work.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Stymied?
Posted by Ted Husted <ne...@husted.com>.
My feeling is that we need to do (3) to energize (1) and (2) (or (4) -
The
Gathering). I also feel we need to something both useful and manageable
for (3) that can serve as a baseline example for future work.
My actual suggestion would be to start with the XML Configuration
component, along with the Testing Suite, supported by a site
infrastructure designed to scale to multiple components.
Testing seems to be a hot button right now all over Jakarta. But we
would also need something to test. The XML Configuration component
saw the largest number of votes. Merging the Avalon and Struts
components seems manageable, and may provide a lot of
utility to other products.
Peter Donald wrote:
>
> Hi,
>
> As the process seems to have slowed and every one seems to be talking about
> different approach maybe we should look at exactly what we want. There is
> three different things that people are talking about
>
> 1. component repository (ie ToolForge+CJAN)
> 2. vetted/tested/approved components (ie Avalon+CJAN)
> 3. base util (Something similar to AUT - Apache Utility Toolkit).
>
> I am happy to work on (3) and are familiar enough with both Turbine and
> Avalon bases that I could help extract the code from them that was
> necessary. I already work on (2) ;)
>
> So if there is enough supporters from other projects do you think it would
> be useful to start AUT now using the standard apache model? For (1) I think
> there needs to be a few issues resolved. Thoughts?
>
> Another model no one has mentioned is the "gatherer" style. ie Code remains
> in whatever CVS it is in now but there is another process to gather
> components from all the different places and publishes them?
>
> So you would have an XML descriptor for each project that lists all
> sub-products. So if you wanted digester from struts, the connection pool
> from turbine and the feedReader from jetspeed you just write your own
> script. This script would indicate your dependencies. During build these
> dependencies are sucked from CJAN/whatever and placed in lib directory. In
> many ways this can draw on and complement gump. Thoughts?
>
> Cheers,
>
> Pete
>
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof." |
> | - John Kenneth Galbraith |
> *-----------------------------------------------------*
Re: Stymied?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Peter Donald wrote:
>
> Hi,
>
> As the process seems to have slowed and every one seems to be talking about
> different approach maybe we should look at exactly what we want. There is
> three different things that people are talking about
>
> 1. component repository (ie ToolForge+CJAN)
> 2. vetted/tested/approved components (ie Avalon+CJAN)
> 3. base util (Something similar to AUT - Apache Utility Toolkit).
I have a little trouble seeing the distinction between 2 and 3. I would
assume that whatever is in 3 has been vetted, tested and approved, and I
thought 2 was supposed to be base utility elements for server
development.
> I am happy to work on (3) and are familiar enough with both Turbine and
> Avalon bases that I could help extract the code from them that was
> necessary. I already work on (2) ;)
That would be avalon? :)
I am happy to join in on Avalon, as long as I was sure that that the
charter allowed for the things I want to do. Specifically, I am looking
to make mini-projects out of common software elements (like a conneciton
pool, XML config utilities, etc) that aren't required to live in a
framework (but can easily be used by any framework), is identifiable and
buildable as a separate unit (like being able to build/download a
Jakarta DBConn Pool w/o dragging endless amounts of unrelated stuff
with it), etc. Given the recent changes I saw regarding the maillists
and all the sublists, my understanding of Avalon is still a bit vague.
I am following it trying to figure it out, though :)
> So if there is enough supporters from other projects do you think it would
> be useful to start AUT now using the standard apache model? For (1) I think
> there needs to be a few issues resolved. Thoughts?
What would 'AUT' be?
>
> Another model no one has mentioned is the "gatherer" style. ie Code remains
> in whatever CVS it is in now but there is another process to gather
> components from all the different places and publishes them?
>
> So you would have an XML descriptor for each project that lists all
> sub-products. So if you wanted digester from struts, the connection pool
> from turbine and the feedReader from jetspeed you just write your own
> script. This script would indicate your dependencies. During build these
> dependencies are sucked from CJAN/whatever and placed in lib directory. In
> many ways this can draw on and complement gump. Thoughts?
This sounds like a great thing for use within Jakarta projects, but I
still don't think it solves the problem of making things easily
available, identifiable, documented, etc to outside users, like all
other jakarta projects have a deliverable available for outside users.
The other issue is that it wouldn't be unexpected if those sub-products
you mentioned changed over time as the needs of the owning project
changed, greatly screwing up life for anyone that use it. The only way
to avoid that is for the project to 'declare' as sub-projects parts of
the project code it is willing to support as such, and maintain on an
ongoing basis.
That would work if you could get projects to do it, but given that we
have duplicated functionality among the Jakarta projects, I think it
might be better if we consolodated some of that code, giving each
project the freedom to use it. (If projects don't use it, we screwed
up...)
Which brings us back to last week... :)
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Stymied?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Peter Donald wrote:
>
> Hi,
>
> As the process seems to have slowed and every one seems to be talking about
> different approach maybe we should look at exactly what we want. There is
> three different things that people are talking about
>
> 1. component repository (ie ToolForge+CJAN)
> 2. vetted/tested/approved components (ie Avalon+CJAN)
> 3. base util (Something similar to AUT - Apache Utility Toolkit).
I have a little trouble seeing the distinction between 2 and 3. I would
assume that whatever is in 3 has been vetted, tested and approved, and I
thought 2 was supposed to be base utility elements for server
development.
> I am happy to work on (3) and are familiar enough with both Turbine and
> Avalon bases that I could help extract the code from them that was
> necessary. I already work on (2) ;)
That would be avalon? :)
I am happy to join in on Avalon, as long as I was sure that that the
charter allowed for the things I want to do. Specifically, I am looking
to make mini-projects out of common software elements (like a conneciton
pool, XML config utilities, etc) that aren't required to live in a
framework (but can easily be used by any framework), is identifiable and
buildable as a separate unit (like being able to build/download a
Jakarta DBConn Pool w/o dragging endless amounts of unrelated stuff
with it), etc. Given the recent changes I saw regarding the maillists
and all the sublists, my understanding of Avalon is still a bit vague.
I am following it trying to figure it out, though :)
> So if there is enough supporters from other projects do you think it would
> be useful to start AUT now using the standard apache model? For (1) I think
> there needs to be a few issues resolved. Thoughts?
What would 'AUT' be?
>
> Another model no one has mentioned is the "gatherer" style. ie Code remains
> in whatever CVS it is in now but there is another process to gather
> components from all the different places and publishes them?
>
> So you would have an XML descriptor for each project that lists all
> sub-products. So if you wanted digester from struts, the connection pool
> from turbine and the feedReader from jetspeed you just write your own
> script. This script would indicate your dependencies. During build these
> dependencies are sucked from CJAN/whatever and placed in lib directory. In
> many ways this can draw on and complement gump. Thoughts?
This sounds like a great thing for use within Jakarta projects, but I
still don't think it solves the problem of making things easily
available, identifiable, documented, etc to outside users, like all
other jakarta projects have a deliverable available for outside users.
The other issue is that it wouldn't be unexpected if those sub-products
you mentioned changed over time as the needs of the owning project
changed, greatly screwing up life for anyone that use it. The only way
to avoid that is for the project to 'declare' as sub-projects parts of
the project code it is willing to support as such, and maintain on an
ongoing basis.
That would work if you could get projects to do it, but given that we
have duplicated functionality among the Jakarta projects, I think it
might be better if we consolodated some of that code, giving each
project the freedom to use it. (If projects don't use it, we screwed
up...)
Which brings us back to last week... :)
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/