You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Ted Husted <ne...@husted.com> on 2001/02/12 13:26:19 UTC
[POLL] Re: Code Sharing Concepts
On 2/9/2001 at 8:12 AM Sam Ruby wrote:
>I would suggest that you start with a proposed code base.
Going back over the posts, there seem to be at least five clear areas of
overlap:
* DataSource/Database Pool
* XML Configuration
* Message Resources / i18n
* JNDI / Naming
* Testing Suites
If you are * actually * interested in working on a Jakarta library
product, and a library implementation of one of these subproducts is an
itch you are ready to scratch, please indicate your commitment with a
+1.
Again, a +1 response indicates that you are actually committing to
working on the given library subproduct in the immediate future. In
order to make a proposal, we need to indicate both the codebases and the
initial Committers, which is the purpose of this vote.
If there is sufficient response to this, we could tally the vote, and
proceed toward a formal proposal. The persons committing to one or more
library products would then work out the other details. (To the
committers go the spoils!) Of course, if no one tenders a (+1) for a
suggested library subproduct, then it would not be part of the initial
proposal.
---
Suggested subproducts and existing Jakarta codebases
DATASOURCE/DATABASE POOL
[Avalon/Cocoon2] DataSource Connection pool
[Struts] DataSource Connection pool
[Turbine] - Database Connection Pool
XML CONFIGURATION
[Avalon/Cocoon2] Configuration (XML based config classes - like a read
only JDOM tree)
[Struts] Digester package - fires events during SAX processing of an XML
document, similar to Tomcat's XmlMapper used to configure itself.
MESSAGE RESOURCES / INTERNATIONALIZATION
[Ant] i18n tools
[Avalon/Cocoon2] XMLResourceBundle/ResourceGroup (ie equivelent)
[Struts] Message Resources - utility classes for packaging resources
(similar to ResourceBundles but Serializable) that include messages for
the same keys in multiple locales.
JNDI
[Avalon] ComponentManager - a component based directory (A
simplification of JNDI and more advanced/generic form of Turbines
Service API).
[Tomcat 4] Naming - Robust implementation of JNDI Context and DirContext
APIs for in-memory resource collections to be accessed via JNDI (with
extensions for things like WAR files that are Tomcat-specific, and
therefore would probably remain in Tomcat).
TESTING SUITES
[Ant] testlet framework (basically similar to early versions of JUnit)
[Tomcat/Watchdog/Slide/Ant] HTTP test clients for unit tests.
[Xalan] Testing infrastructure proposal
< http://marc.theaimsgroup.com/?l=xerces-j-dev&m=98183907325686&w=2 >
SUBPROJECT INFRASTRUCTURE
[*] - Subproject infrastructure: website, documentation, sample
applications, test suites, quality assurance.
[Tinderbox] ?
[GUMP] ?
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/about/struts/
Re: [POLL] Re: Code Sharing Concepts
Posted by Federico Barbieri <sc...@betaversion.org>.
Ted Husted wrote:
>
> On 2/9/2001 at 8:12 AM Sam Ruby wrote:
> >I would suggest that you start with a proposed code base.
>
> Going back over the posts, there seem to be at least five clear areas of
> overlap:
>
> * XML Configuration
+1
> * JNDI / Naming
+1
> TESTING SUITES
>
> [Ant] testlet framework (basically similar to early versions of JUnit)
>
> [Tomcat/Watchdog/Slide/Ant] HTTP test clients for unit tests.
>
> [Xalan] Testing infrastructure proposal
> < http://marc.theaimsgroup.com/?l=xerces-j-dev&m=98183907325686&w=2 >
There may be something interesting in the avalon project too under
org.apache.testlet.
Fede
Re: [POLL] Re: Code Sharing Concepts
Posted by sa...@totalsync.com.
> TESTING SUITES
+1
> SUBPROJECT INFRASTRUCTURE
Specifically Tinderbox/Gump
+1
Scott Sanders
Re: [POLL] Re: Code Sharing Concepts
Posted by Ted Husted <ne...@husted.com>.
Ted Husted wrote:
> TESTING SUITES
+1
> SUBPROJECT INFRASTRUCTURE
[*] - Subproject infrastructure: website, documentation, sample
applications, test suites, quality assurance.
+1
For a running tally, see < http://husted.com/about/jakarta/library.html
>.
Re: [POLL] Re: Code Sharing Concepts
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ted Husted wrote:
>
> On 2/9/2001 at 8:12 AM Sam Ruby wrote:
> >I would suggest that you start with a proposed code base.
>
> Going back over the posts, there seem to be at least five clear areas of
> overlap:
>
> * DataSource/Database Pool
+1
> * XML Configuration
+1
geir
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
Re: [POLL] Re: Code Sharing Concepts
Posted by cm...@yahoo.com.
>
> * DataSource/Database Pool
> * XML Configuration
+1
> * Message Resources / i18n
+1
> * JNDI / Naming
> * Testing Suites
+1
Costin
Re: [POLL] Re: Code Sharing Concepts
Posted by Ted Husted <ne...@husted.com>.
David Weinrich wrote:
> Ok, sorry I was a bit late on the draw here
Glad to have you aboard, David, especially since as near as I can
figure, you're the one that started this thread!
< http://www.mail-archive.com/general@jakarta.apache.org/msg00018.html >
(This time, at least ;-)
-Ted.
Re: [POLL] Re: Code Sharing Concepts
Posted by David Weinrich <dw...@home.com>.
Ok, sorry I was a bit late on the draw here, while I doubt my
programming skills are up to snuff, I would love to help out
with the following in any way I can:
>
> DATASOURCE/DATABASE POOL
>
+1 I can test the heck out of these and perhaps help with a bit of the
documentation...
>
>
> SUBPROJECT INFRASTRUCTURE
>
> [*] - Subproject infrastructure: website, documentation, sample
> applications, test suites, quality assurance.
>
> [Tinderbox] ?
> [GUMP] ?
>
+1 Just let me know what needs to be done...
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 425-0252; Fax 716 223-2506.
> -- http://www.husted.com/about/struts/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
Re: [POLL] Re: Code Sharing Concepts
Posted by Ted Husted <ne...@husted.com>.
"Geir Magnusson Jr." wrote:
> You might think then that each partition could manage it's own issues,
> like the projects do.
So given
< http://www.mail-archive.com/general@jakarta.apache.org/msg00154.html >
are we on the same page, Geir?
Basically, I just want to nest everything we do for Jakarta subprojects
into Library subproducts. (But then I may have spent too many years
wired to a Pascal compiler ;-)
> I don't know what kind of process management
> rules one could have to ensure API stability other than responsibility
> to the users. I mean, with Tomcat 4, nothing really guarantees that you
> won't abandon Servlet 2.3 for the Wiggly Green Spec from Planet Mongo,
> but I trust that you will stick to your 'mission'... :)
The idea is that when a subproject is proposed, it will also define it's
scope, or charter. The scope of the Tomcat subproject is to provide a
reference implementation for the Sun Servlet and JSP specifications. If
the committers did go insane and adopt another API, the subproject could
be cancelled.
And the ASF Chairman has alluded to doing just that with Ant. But that's
another problem.
I would imagine that we would do the same with our library subproducts.
If the datasource team started building JDBC drivers, we'd have to ask
if they were still within scope, or whether we needed another subproduct
for that codebase.
-Ted.
Re: [POLL] Re: Code Sharing Concepts
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
"Craig R. McClanahan" wrote:
>
> As I stated in words rather than votes, and on this code base or any of the others in
> the polll that came from my original list:
>
> Before process management issues are worked out: -0
>
> After process management issues are worked out: +1
>
> I don't have any time to waste on anarchy-based shared code repositories. I have
> lots of time to spend, and useful code to contribute, to a shared repository that I
> know I can confidently use in my projects, based on process management rules that
> include protection from arbitrary API changes.
Agreed 100% with the sentiment, but I maybe I need something cleared up
for me. I keep thinking/hoping/wishing/deaming about this as not a
'code repository' but as another Jakarta project - like Ant, Struts,
Tomcat, Turbine ( ok, it isn't actually Jakarta... who cares...) Call
it 'Rupert'.
The only issue I can think of offhand that makes this a problem is that
partitioning into subsections is likely - DBConnPooling, XML Config,
etc. I would think that the notion of responsible committers used in the
current Jakarta projects would scale down to the subsection level,
partitioning the committers among the subprojects of 'Rupert', just like
Jakarta committers are partitoned among Jakarta's projects.
You might think then that each partition could manage it's own issues,
like the projects do. I don't know what kind of process management
rules one could have to ensure API stability other than responsibility
to the users. I mean, with Tomcat 4, nothing really guarantees that you
won't abandon Servlet 2.3 for the Wiggly Green Spec from Planet Mongo,
but I trust that you will stick to your 'mission'... :)
I would assume that if there was a DBConnection Pool project (my
favorite example), that the 'mission' might be something along the lines
of something compliant with JDBC's Driver, DataSource and Connection
interfaces...
geir
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
Re: [POLL] Re: Code Sharing Concepts
Posted by James Duncan Davidson <du...@x180.net>.
on 2/15/01 11:56 AM, Craig R. McClanahan at Craig.McClanahan@eng.sun.com
wrote:
> I don't have any time to waste on anarchy-based shared code repositories. I
> have lots of time to spend, and useful code to contribute, to a shared
> repository that I know I can confidently use in my projects, based on process
> management rules that include protection from arbitrary API changes.
I agree wholeheartedly with this statement.
--
James Duncan Davidson
http://x180.net/ !try; do();
Re: [POLL] Re: Code Sharing Concepts
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Ted Husted wrote:
> There are many packages which would make good candidates for the
> library. To find a starting set, I simply looked for packages where
> there was already overlap. But, if no one disagrees, let's hereby amend
> the POLL to include
>
> --
>
> [Struts] Bean Introspection support - BeanUtils, PropertyUtils, and
> ConvertUtils classes have generic support for managing JavaBean property
> setting and getting through the use of the Java Reflection APIs,
> including support for nested and indexed property expressions.
>
> --
>
> If you or Pete or anyone else would like to commit to this proposed
> codebase, please reply with your +1.
>
As I stated in words rather than votes, and on this code base or any of the others in
the polll that came from my original list:
Before process management issues are worked out: -0
After process management issues are worked out: +1
I don't have any time to waste on anarchy-based shared code repositories. I have
lots of time to spend, and useful code to contribute, to a shared repository that I
know I can confidently use in my projects, based on process management rules that
include protection from arbitrary API changes.
>
> -Ted.
>
Craig
Re: [POLL] Re: Code Sharing Concepts
Posted by Ted Husted <ne...@husted.com>.
"Craig R. McClanahan" wrote:
> I haven't voted yet in this thread because I haven't seen anyone else say
> "let's figure out the process issues first." I guess it's not as interesting
> as writing code :-), but it is very much as important to a shared resource like
> this.
My thinking on the next step would be to draft a formal proposal for
consideration by the proposed committers, for comments, discussions,
revisions, and eventually a vote in the usual way. Also in the usual
way, these discussions could take place on an interim list (off Jakarta)
to which the proposed committers, and other interested parties, can
subscribe. Of course, when it comes to a vote, only those of the
proposed committers would be binding, again in the usual way.
There are many packages which would make good candidates for the
library. To find a starting set, I simply looked for packages where
there was already overlap. But, if no one disagrees, let's hereby amend
the POLL to include
--
[Struts] Bean Introspection support - BeanUtils, PropertyUtils, and
ConvertUtils classes have generic support for managing JavaBean property
setting and getting through the use of the Java Reflection APIs,
including support for nested and indexed property expressions.
--
If you or Pete or anyone else would like to commit to this proposed
codebase, please reply with your +1.
I think this subproject has tremendous potential, but like all Apache
subprojects, the decision-making has to be pushed down to the people who
are willing to do the work. So before we can make any decisions, we need
to find out who will do the work, and let them decide. I know you are
one of those people, Craig, and I think you know I won't let the process
issues slide.
-Ted.
Re: [POLL] Re: Code Sharing Concepts
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Peter Donald wrote:
>
> I would also like to hear from the struts bean utils. I haven't looked at
> them but I presume they would be general enough (or could be made so) so
> Ant2.x could use it (ie remove converter/introspector elemenets from Ant2.0
> codebase).
>
They are -- and they have dependencies only on JDK classes for the following
org.apache.struts.util classes: BeanUtils, ConvertUtils, and PropertyUtils.
Javadocs are online at
http://jakarta.apache.org/struts/api/index.html
I haven't voted yet in this thread because I haven't seen anyone else say
"let's figure out the process issues first." I guess it's not as interesting
as writing code :-), but it is very much as important to a shared resource like
this.
I will coordinate contributing any or all of the code listed at the bottom of
my "Code Sharing Concepts" message, but I'm definitely not interested in making
any project I'm a part of dependent on an ad hoc collection of code with no
rules about who can change what. I've been bitten way too many times in that
scenario.
>
> Cheers,
>
> Pete
>
Craig
Re: [POLL] Re: Code Sharing Concepts
Posted by Peter Donald <do...@apache.org>.
At 07:26 12/2/01 -0500, Ted Husted wrote:
>On 2/9/2001 at 8:12 AM Sam Ruby wrote:
>>I would suggest that you start with a proposed code base.
>
>Going back over the posts, there seem to be at least five clear areas of
>overlap:
>
>* DataSource/Database Pool
>* XML Configuration
+1
>* Message Resources / i18n
+1
>* JNDI / Naming
+1
>* Testing Suites
+1 if that means suites for products I indicated above, +1 also if it means
integrating all the test frameworks into one.
I would also like to hear from the struts bean utils. I haven't looked at
them but I presume they would be general enough (or could be made so) so
Ant2.x could use it (ie remove converter/introspector elemenets from Ant2.0
codebase).
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 |
*-----------------------------------------------------*