You are viewing a plain text version of this content. The canonical link for it is here.
Posted to -deprecated@jakarta.apache.org by Ted Husted <ne...@husted.com> on 2001/02/17 13:24:24 UTC
[POLL] - General Consensus, Round 1
Now that we have a proposed set of committers and codebases, I believe
the next step is to agree upon a working infrastructure. We could then
draw up a proposal, and maybe a prototype Web site.
Going over the past posts, I believe we have a consensus on these
points:
-----
* Each component must be something that can be used by one or more ASF
products.
* Each component must have a clearly defined purpose, scope, and API.
(Do one thing well, and keep your contracts!)
* Each component should clearly specify any external API dependencies,
including JDK version required.
* External dependencies on optional and third-party APIs should be
minimized.
* The components should provide Ant build files as part of the standard
distribution.
* The components should use XML format files for configuration options.
* When applicable, optional JavaBean wrappers around a component are
encouraged.
* Each component will be featured on its own page on the subproject Web
site, which may then be indexed in a master catalog.
* The subproject may also host a top-level "general" and "announcement"
mailing list.
* The subproject may also provide a single JAR of all stable component
releases. (Perhaps with a subset of JDK 1.1 compatible releases.)
-----
Of course, if you disagree with any of these points, please say so now
(see below). Only committers' votes count, but every committer's vote
counts!
Following are some additional questions where I was less certain of how
people feel. Of course, if anyone has similar questions of their own,
please post them or start a discussion leading to a poll.
Please respond to one alternative in each block (or suggest another
alternative):
(0)
Do you agree with the "consensus points" above?
(1)
Should the the components be created and maintained as individual
subproducts by a set of "component committers"?
OR,
Should the component be created and maintained by the union of all
interested committers from the Jakarta products that are using the
component?
(2)
Who will approve adding new codebases to the project:
All the Committers?
OR,
A group of "core" Committers?
OR,
Any Jakarta committer can add a codebase, SourceForge style.
(2)
Is overlap between components acceptable? Is it OK for two components to
solve the same problem differently?
(3)
Do we need a set of super-committers (e.g. PMC members) who can step-up
when a codebase loses a sole Committer.
(4)
Can the unit of reuse and release be the package?
OR,
Will we need a larger or smaller "granule" for each codebase?
(5)
Should we encourage giving components boring, functional names, to
emphasize their utilitarian nature?
(6)
Do we want to propose this as a Jakarta subproject?
OR,
Do we want to propose a new PMC that would focus on Java development
tools
(Ant and a package/component library -- maybe BSF too)?
OR,
Start with a pilot Jakarta subproject, and then consider proposing a new
ASF Project if it works.
-----
I will also soon move < http://husted.com/jakarta/library.html > to the
Jakarta Web site. (But, hey, its the weekend, the kids are all slept
over at friends ;-).
-T.
Re: [POLL] - General Consensus, Round 1
Posted by Ted Husted <ne...@husted.com>.
> Do you agree with the "consensus points" above?
+1
> (1)
> Should the the components be created and maintained as individual
> subproducts by a set of "component committers"?
+1
> (2)
> Who will approve adding new codebases to the project:
> All the Committers?
+1
By super-majority (3/4's vote)
> (3)
> Is overlap between components acceptable? Is it OK for two components to
> solve the same problem differently?
+1
> (4)
> Do we need a set of super-committers (e.g. PMC members) who can step-up
> when a codebase loses a sole Committer.
+1
I suggest a team of 3 core committers who will take responsibility for
seeing that things like this don't fall through the cracks.
> (5)
> Can the unit of reuse and release be the package?
+1
> (6)
> Should we encourage giving components boring, functional names, to
> emphasize their utilitarian nature?
+1
> (7)
> Start with a pilot Jakarta subproject, and then consider proposing a new
> ASF Project if it works.
+1
-Ted.
Re: [POLL] - General Consensus, Round 1
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
"Geir Magnusson Jr." wrote:
> > (6)
> >
> > Do we want to propose this as a Jakarta subproject?
>
> not enough experience to make a judgement
>
> > OR,
> >
> > Do we want to propose a new PMC that would focus on Java development
> > tools
> > (Ant and a package/component library -- maybe BSF too)?
>
> not enough experience to make a judgement
>
> > OR,
> >
> > Start with a pilot Jakarta subproject, and then consider proposing a new
> > ASF Project if it works.
>
> Seems the best :)
I thought about this a bit more, and want to change to
Do we want to propose this as a Jakarta subproject?
+1
And when thinking about it - aren't Ant and log4j ideal candidates for a
tool library?
--
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] - General Consensus, Round 1
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
"Geir Magnusson Jr." wrote:
> > (6)
> >
> > Do we want to propose this as a Jakarta subproject?
>
> not enough experience to make a judgement
>
> > OR,
> >
> > Do we want to propose a new PMC that would focus on Java development
> > tools
> > (Ant and a package/component library -- maybe BSF too)?
>
> not enough experience to make a judgement
>
> > OR,
> >
> > Start with a pilot Jakarta subproject, and then consider proposing a new
> > ASF Project if it works.
>
> Seems the best :)
I thought about this a bit more, and want to change to
Do we want to propose this as a Jakarta subproject?
+1
And when thinking about it - aren't Ant and log4j ideal candidates for a
tool library?
--
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] - General Consensus, Round 1
Posted by Ted Husted <ne...@husted.com>.
Peter Donald wrote:
> Very grand idea - though a lot of work ;)
Here's a real test of whether Apache is a community or not ;-)
SourceForge is PHP open source.
PHP is Apache.
-T.
Re: [POLL] - General Consensus, Round 1
Posted by Ted Husted <ne...@husted.com>.
Peter Donald wrote:
> Very grand idea - though a lot of work ;)
Here's a real test of whether Apache is a community or not ;-)
SourceForge is PHP open source.
PHP is Apache.
-T.
Re: [POLL] - General Consensus, Round 1
Posted by Peter Donald <do...@apache.org>.
At 08:21 18/2/01 -0500, Ted Husted wrote:
>"Geir Magnusson Jr." wrote:
>> A 'ToolForge' might be a nice 'project' under the mini-Jakarta - with
>> the understanding that anything that gets real traction be made a
>> project in it's own right?
>
>Why not go the whole nine yards and develop a secure, back-end
>administration tool for managing the nuts-and-bolts of Jakarta (like
>SourceForge), that can also generate a friendly public interface for
>product distribution (like CPAN).
That is a really kewl idea! It could vastly simplify management for people
like Brian who must get bomarded with requests every now and again.
A few issues I can see that would need to be addressed.
1. I want to have a better quality management and in a way I still want the
PMC to oversee the progress of projects/miniprojects/whatever through the
stages.
2. It would require a LOT of work which I can't commit to at this time. To
get this going would require a very strong community or a very focused
individual ;)
3. It could put a drain on our computer resources. It looks like that each
sourceforge page could have as many as 10 reads from a DB which may put
undue strain on our host machines
4. It could get more complex for developer
For 1 I think it would be solvable if output from gump, output from
sourcewars (CVS statistics) and adequete documentation of project and
communication with PMC could do it.
If 3 became an issue I would be happy to put in a bit to get another
machine and possibly we could could garner some cash from the ApacheCon
events or whatever.
4 would only be possible if we made the web interface optional and still
made it possible to vote/discuss/get web reports from mailing lists etc.
....
However think of the benefits. We could have a central interface that gave
us access to scarab/bugzilla/mailing list archives/feature requests/todo
etc. With adequete standardisation we could have one click to get nightly
builds/distributions/whatever.
It would also be great for certain management functions like voting so that
votes are recorded and peoples reasons for votes ar erecorded so they could
be easily revued in future. Of course all this would be mirrored onto
mailing list so you don't *need* the web interface.
It would be nice - it would be broadly applicable across many of the apache
projects and possibly could incorporate things from tigris.org etc.
Very grand idea - though a lot of 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: [POLL] - General Consensus, Round 1
Posted by Peter Donald <do...@apache.org>.
At 08:21 18/2/01 -0500, Ted Husted wrote:
>"Geir Magnusson Jr." wrote:
>> A 'ToolForge' might be a nice 'project' under the mini-Jakarta - with
>> the understanding that anything that gets real traction be made a
>> project in it's own right?
>
>Why not go the whole nine yards and develop a secure, back-end
>administration tool for managing the nuts-and-bolts of Jakarta (like
>SourceForge), that can also generate a friendly public interface for
>product distribution (like CPAN).
That is a really kewl idea! It could vastly simplify management for people
like Brian who must get bomarded with requests every now and again.
A few issues I can see that would need to be addressed.
1. I want to have a better quality management and in a way I still want the
PMC to oversee the progress of projects/miniprojects/whatever through the
stages.
2. It would require a LOT of work which I can't commit to at this time. To
get this going would require a very strong community or a very focused
individual ;)
3. It could put a drain on our computer resources. It looks like that each
sourceforge page could have as many as 10 reads from a DB which may put
undue strain on our host machines
4. It could get more complex for developer
For 1 I think it would be solvable if output from gump, output from
sourcewars (CVS statistics) and adequete documentation of project and
communication with PMC could do it.
If 3 became an issue I would be happy to put in a bit to get another
machine and possibly we could could garner some cash from the ApacheCon
events or whatever.
4 would only be possible if we made the web interface optional and still
made it possible to vote/discuss/get web reports from mailing lists etc.
....
However think of the benefits. We could have a central interface that gave
us access to scarab/bugzilla/mailing list archives/feature requests/todo
etc. With adequete standardisation we could have one click to get nightly
builds/distributions/whatever.
It would also be great for certain management functions like voting so that
votes are recorded and peoples reasons for votes ar erecorded so they could
be easily revued in future. Of course all this would be mirrored onto
mailing list so you don't *need* the web interface.
It would be nice - it would be broadly applicable across many of the apache
projects and possibly could incorporate things from tigris.org etc.
Very grand idea - though a lot of 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: [POLL] - General Consensus, Round 1
Posted by Ted Husted <ne...@husted.com>.
"Geir Magnusson Jr." wrote:
> A 'ToolForge' might be a nice 'project' under the mini-Jakarta - with
> the understanding that anything that gets real traction be made a
> project in it's own right?
Why not go the whole nine yards and develop a secure, back-end
administration tool for managing the nuts-and-bolts of Jakarta (like
SourceForge), that can also generate a friendly public interface for
product distribution (like CPAN).
It's possible that this could be mainly an implementation of existing
Jakarta technologies, like Alexandria, Jyve, WebDAV, and Avalon --
much like what was done with Jetspeed. It would also be interesting to
try and adopt the Jetspeed portlet into another product, since I
believe this was meant to be a standalone API.
With a proper tool, it would be much easier to allow Committers to
create experimental subprojects, whether they are meant as tools or
products. These could then be exposed to the public in stages
(internal-only (experimental), incubator, catalog, showcase) until they
hit the top-level showcase category (where all the products are today).
This would also make it easier to manage the "driftwood". If an
experimental or incubator project hasn't had a CVS update in six
months, it could be automatically archived and marked inactive. Of
course, once a project made it to the catalog, it would become a
permanent fixture.
The voting (aka peer review) would then not be about creating
subprojects, but whether to expose them to the public. This follows the
same Rules for Revolutionaries we adopted for CVS branches,
< http://www.x180.net/Mutterings/Apache/rules.html >
but expands it to include the infrastucture you need to make a
revolution work.
We might also be able to automate some of the management features, like
voting, the infamous Status file, the whoWeAre pages, to make these
easier to keep up-to-date, and to weave Meritocracy into the base
infrastructure.
It would then be a small step for another organization with a broader
scope to use the same product to launch a CJAN.
And, if the infrastructure is designed to encourage open source
development by Meritocracy, this would also serve the another goal of
the ASF -- to provide an alternative model to "development by Benevolent
Dictatorship".
< http://java.apache.org/main/constitution.html >
-Ted.
Re: [POLL] - General Consensus, Round 1
Posted by Ted Husted <ne...@husted.com>.
"Geir Magnusson Jr." wrote:
> A 'ToolForge' might be a nice 'project' under the mini-Jakarta - with
> the understanding that anything that gets real traction be made a
> project in it's own right?
Why not go the whole nine yards and develop a secure, back-end
administration tool for managing the nuts-and-bolts of Jakarta (like
SourceForge), that can also generate a friendly public interface for
product distribution (like CPAN).
It's possible that this could be mainly an implementation of existing
Jakarta technologies, like Alexandria, Jyve, WebDAV, and Avalon --
much like what was done with Jetspeed. It would also be interesting to
try and adopt the Jetspeed portlet into another product, since I
believe this was meant to be a standalone API.
With a proper tool, it would be much easier to allow Committers to
create experimental subprojects, whether they are meant as tools or
products. These could then be exposed to the public in stages
(internal-only (experimental), incubator, catalog, showcase) until they
hit the top-level showcase category (where all the products are today).
This would also make it easier to manage the "driftwood". If an
experimental or incubator project hasn't had a CVS update in six
months, it could be automatically archived and marked inactive. Of
course, once a project made it to the catalog, it would become a
permanent fixture.
The voting (aka peer review) would then not be about creating
subprojects, but whether to expose them to the public. This follows the
same Rules for Revolutionaries we adopted for CVS branches,
< http://www.x180.net/Mutterings/Apache/rules.html >
but expands it to include the infrastucture you need to make a
revolution work.
We might also be able to automate some of the management features, like
voting, the infamous Status file, the whoWeAre pages, to make these
easier to keep up-to-date, and to weave Meritocracy into the base
infrastructure.
It would then be a small step for another organization with a broader
scope to use the same product to launch a CJAN.
And, if the infrastructure is designed to encourage open source
development by Meritocracy, this would also serve the another goal of
the ASF -- to provide an alternative model to "development by Benevolent
Dictatorship".
< http://java.apache.org/main/constitution.html >
-Ted.
Re: [POLL] - General Consensus, Round 1
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ted Husted wrote:
>
> "Geir Magnusson Jr." wrote:
> > That sounds like something to fix then. If not the Jakarta web site,
> > where actually does one find the Jakarta charter?
>
> <
> http://apache.org/foundation/records/minutes/1999/board_minutes_1999_09_16.txt
> >
>
> Agenda item D.
Thank you. Good read...
> The list of other Apache projects is at
> < http://apache.org/foundation/projects.html >
>
> > Couldn't you leave the option to 'add everyone automatically' up to the
> > subproject? Taglibs seems to work along these lines?
>
> Costin recently proposed that every Jakarta committer be automatically
> added to the Jakarta Tools subproject. The hope would be that this would
> lead to a model where any committer with a tool itch could offer up a
> component. There wasn't any response to that proposal. I'm told the
> tools area is also very underutilized right now. Personally, I don't
> even know where it is.
I didn't know there was one..
> It seems possible that the tools area could be invigorated, but the
> comments on the general list seemed to be running toward a mini-Jakarta,
> rather than a ToolForge -- where any committer could setup shop at their
> own discretion.
A 'ToolForge' might be a nice 'project' under the mini-Jakarta - with
the understanding that anything that gets real traction be made a
project in it's own right?
> Given a decent infrastructure, it is an interesting idea. If we wanted
> to pursue this, my suggestion would be to actually provide a
> SourceForge-like interface, placed on a secure area of the site that
> would require a Jakarta committer login for access. They could then
> register their component, and have the mailing list, home page, and CVS
> repository all setup automatically. To merge the two models together, we
> could offer an option of whether committers must be added individually,
> or whether all Jakarta committers should be added automatically (today
> and in the future).
>
> -Ted.
--
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] - General Consensus, Round 1
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ted Husted wrote:
>
> "Geir Magnusson Jr." wrote:
> > That sounds like something to fix then. If not the Jakarta web site,
> > where actually does one find the Jakarta charter?
>
> <
> http://apache.org/foundation/records/minutes/1999/board_minutes_1999_09_16.txt
> >
>
> Agenda item D.
Thank you. Good read...
> The list of other Apache projects is at
> < http://apache.org/foundation/projects.html >
>
> > Couldn't you leave the option to 'add everyone automatically' up to the
> > subproject? Taglibs seems to work along these lines?
>
> Costin recently proposed that every Jakarta committer be automatically
> added to the Jakarta Tools subproject. The hope would be that this would
> lead to a model where any committer with a tool itch could offer up a
> component. There wasn't any response to that proposal. I'm told the
> tools area is also very underutilized right now. Personally, I don't
> even know where it is.
I didn't know there was one..
> It seems possible that the tools area could be invigorated, but the
> comments on the general list seemed to be running toward a mini-Jakarta,
> rather than a ToolForge -- where any committer could setup shop at their
> own discretion.
A 'ToolForge' might be a nice 'project' under the mini-Jakarta - with
the understanding that anything that gets real traction be made a
project in it's own right?
> Given a decent infrastructure, it is an interesting idea. If we wanted
> to pursue this, my suggestion would be to actually provide a
> SourceForge-like interface, placed on a secure area of the site that
> would require a Jakarta committer login for access. They could then
> register their component, and have the mailing list, home page, and CVS
> repository all setup automatically. To merge the two models together, we
> could offer an option of whether committers must be added individually,
> or whether all Jakarta committers should be added automatically (today
> and in the future).
>
> -Ted.
--
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] - General Consensus, Round 1
Posted by Ted Husted <ne...@husted.com>.
"Geir Magnusson Jr." wrote:
> That sounds like something to fix then. If not the Jakarta web site,
> where actually does one find the Jakarta charter?
<
http://apache.org/foundation/records/minutes/1999/board_minutes_1999_09_16.txt
>
Agenda item D.
The list of other Apache projects is at
< http://apache.org/foundation/projects.html >
> Couldn't you leave the option to 'add everyone automatically' up to the
> subproject? Taglibs seems to work along these lines?
Costin recently proposed that every Jakarta committer be automatically
added to the Jakarta Tools subproject. The hope would be that this would
lead to a model where any committer with a tool itch could offer up a
component. There wasn't any response to that proposal. I'm told the
tools area is also very underutilized right now. Personally, I don't
even know where it is.
It seems possible that the tools area could be invigorated, but the
comments on the general list seemed to be running toward a mini-Jakarta,
rather than a ToolForge -- where any committer could setup shop at their
own discretion.
Given a decent infrastructure, it is an interesting idea. If we wanted
to pursue this, my suggestion would be to actually provide a
SourceForge-like interface, placed on a secure area of the site that
would require a Jakarta committer login for access. They could then
register their component, and have the mailing list, home page, and CVS
repository all setup automatically. To merge the two models together, we
could offer an option of whether committers must be added individually,
or whether all Jakarta committers should be added automatically (today
and in the future).
-Ted.
Re: [POLL] - General Consensus, Round 1
Posted by Ted Husted <ne...@husted.com>.
"Geir Magnusson Jr." wrote:
> That sounds like something to fix then. If not the Jakarta web site,
> where actually does one find the Jakarta charter?
<
http://apache.org/foundation/records/minutes/1999/board_minutes_1999_09_16.txt
>
Agenda item D.
The list of other Apache projects is at
< http://apache.org/foundation/projects.html >
> Couldn't you leave the option to 'add everyone automatically' up to the
> subproject? Taglibs seems to work along these lines?
Costin recently proposed that every Jakarta committer be automatically
added to the Jakarta Tools subproject. The hope would be that this would
lead to a model where any committer with a tool itch could offer up a
component. There wasn't any response to that proposal. I'm told the
tools area is also very underutilized right now. Personally, I don't
even know where it is.
It seems possible that the tools area could be invigorated, but the
comments on the general list seemed to be running toward a mini-Jakarta,
rather than a ToolForge -- where any committer could setup shop at their
own discretion.
Given a decent infrastructure, it is an interesting idea. If we wanted
to pursue this, my suggestion would be to actually provide a
SourceForge-like interface, placed on a secure area of the site that
would require a Jakarta committer login for access. They could then
register their component, and have the mailing list, home page, and CVS
repository all setup automatically. To merge the two models together, we
could offer an option of whether committers must be added individually,
or whether all Jakarta committers should be added automatically (today
and in the future).
-Ted.
Re: [POLL] - General Consensus, Round 1
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ted Husted wrote:
>
> "Geir Magnusson Jr." wrote:
> > Suppose I wanted to include a nice little XML browser, a little visual
> > program that lets me see a document as a tree, edit attributes, etc.
> > with the XML subproject. Could I not because it by nature cannot be
> > used in another Jakarta product?
>
> I would -1 that myself, but that doesn't mean I wouldn't be out-voted
> ;-).
I would too once I thought about it. :p
My point is that why would having to be used in another Jakarta project
be a requirement? I can understand keeping things in scope, but there
must be examples of things that adequately support the Jakarta mission
w/o necessarily being used w/in an existing project.
> > 1) shared software to be used by many projects in Jakarta (because that
> > is there the nucleus of these projects is going to come from anyway...)
> >
> > AND
> >
> > 2) 'products' in their own right, such as DB Connection pool, that are
> > useful *outside* of Jakarta projects.
>
> +1. But both (1) and (2) would be components targeted for use by another
> Jakarta product, even if also useful to some other product.
Should have said 'and/or'. If we leave it as 'targeted for use', that
would be fine, as it doesn't require *actual* use. We can't force a
project to use something...
> It's also important to remember that none of this is written in stone.
> We just need to find a do-able starting point to keep things from going
> random too early.
I am not trying to be combative - I simply see this restriction as
unnecessary. As I understood it, everything we are going to seed the
projects with will come from an existing project anyway, supported by
existing committers who have been throughly vetted and converted to the
Jakarta Way(tm)(c)(R). A logical interpretation would mean that you
couldn't write new code for the library unless you had some sort of
'sponsoring project', which I don't like.
> > The Jakarta mission is "Provide commercial-quality server solutions
> > based on the Java Platform that are developed in an open and cooperative
> > fashion." Well, the 'problem space' is growing - there is nothing I see
>
> The Web site says that, but the ASF which owns the Web site, and the
> license to all the Apache code (including Velocity), disagrees.
> Jakarta's charter is to "create and maintain Java servlet-related
> software." Period. This could change any day now, but at this instant,
> the Web site's mission statement is out of scope.
That sounds like something to fix then. If not the Jakarta web site,
where actually does one find the Jakarta charter?
>
> > It's becoming clearer that I have a different idea on what this should
> > be : I imagine productizing some of the stuff embedded and duplicated in
> > possibly multiple projects, and another possibility is a 'communal
> > software depot'.
>
> Costin and Ignacio do have a "dissenting opinion" (Costin's phrase).
And it's a valid one, so lets figure this out. It's an important
distinction. We don't have to choose one way over the other. Both is
fine with me as long as the subprojects of the library have their own
control. I can have my DBConnectionPool 'product' with standard Jakarta
committer conventions (I hope I will be allowed to participate :), and
there can be other models of projects that act as incubators, or related
collections (like Taglibs) or whatever someone comes up with.
> And that's to be expected in any group, especially in a group of
> strong-willed self-starters, like this one. So, we post the
> alternatives, take a vote, and move on. When the first poll is complete
> we'll have a better idea of what * this * proposal will be about. (Which
> isn't to say there couldn't be another.)
>
> At this point it's unlikely that anyone is going to change anyone's mind
> here. We all have our own reasons for wanting to do this one way or the
> other, and I'm sure they all are equally valid, only from different
> viewpoints. But sometimes approaches conflict, and it's necessary to
> choose one or the other to survive.
I am in favor of doing *both* ways. I agree to the need for both, and I
think a structure can be made to accomodate both.
I just read it as there being more a push towards the open 'code depot'
model, and I wanted to push back.
> Personally, I think a Jakarta free-for-all library can be done through
> the tools subproject, and doesn't need to be proposed separately. If
> someone wants to try that, they can just go ahead and run with it. The
> vote to add everyone automatically was a non-starter. So, the next step
> here might be to find some other like-minded committers, and nominate
> each one, until you have a quorum.
Couldn't you leave the option to 'add everyone automatically' up to the
subproject? Taglibs seems to work along these lines?
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] - General Consensus, Round 1
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ted Husted wrote:
>
> "Geir Magnusson Jr." wrote:
> > Suppose I wanted to include a nice little XML browser, a little visual
> > program that lets me see a document as a tree, edit attributes, etc.
> > with the XML subproject. Could I not because it by nature cannot be
> > used in another Jakarta product?
>
> I would -1 that myself, but that doesn't mean I wouldn't be out-voted
> ;-).
I would too once I thought about it. :p
My point is that why would having to be used in another Jakarta project
be a requirement? I can understand keeping things in scope, but there
must be examples of things that adequately support the Jakarta mission
w/o necessarily being used w/in an existing project.
> > 1) shared software to be used by many projects in Jakarta (because that
> > is there the nucleus of these projects is going to come from anyway...)
> >
> > AND
> >
> > 2) 'products' in their own right, such as DB Connection pool, that are
> > useful *outside* of Jakarta projects.
>
> +1. But both (1) and (2) would be components targeted for use by another
> Jakarta product, even if also useful to some other product.
Should have said 'and/or'. If we leave it as 'targeted for use', that
would be fine, as it doesn't require *actual* use. We can't force a
project to use something...
> It's also important to remember that none of this is written in stone.
> We just need to find a do-able starting point to keep things from going
> random too early.
I am not trying to be combative - I simply see this restriction as
unnecessary. As I understood it, everything we are going to seed the
projects with will come from an existing project anyway, supported by
existing committers who have been throughly vetted and converted to the
Jakarta Way(tm)(c)(R). A logical interpretation would mean that you
couldn't write new code for the library unless you had some sort of
'sponsoring project', which I don't like.
> > The Jakarta mission is "Provide commercial-quality server solutions
> > based on the Java Platform that are developed in an open and cooperative
> > fashion." Well, the 'problem space' is growing - there is nothing I see
>
> The Web site says that, but the ASF which owns the Web site, and the
> license to all the Apache code (including Velocity), disagrees.
> Jakarta's charter is to "create and maintain Java servlet-related
> software." Period. This could change any day now, but at this instant,
> the Web site's mission statement is out of scope.
That sounds like something to fix then. If not the Jakarta web site,
where actually does one find the Jakarta charter?
>
> > It's becoming clearer that I have a different idea on what this should
> > be : I imagine productizing some of the stuff embedded and duplicated in
> > possibly multiple projects, and another possibility is a 'communal
> > software depot'.
>
> Costin and Ignacio do have a "dissenting opinion" (Costin's phrase).
And it's a valid one, so lets figure this out. It's an important
distinction. We don't have to choose one way over the other. Both is
fine with me as long as the subprojects of the library have their own
control. I can have my DBConnectionPool 'product' with standard Jakarta
committer conventions (I hope I will be allowed to participate :), and
there can be other models of projects that act as incubators, or related
collections (like Taglibs) or whatever someone comes up with.
> And that's to be expected in any group, especially in a group of
> strong-willed self-starters, like this one. So, we post the
> alternatives, take a vote, and move on. When the first poll is complete
> we'll have a better idea of what * this * proposal will be about. (Which
> isn't to say there couldn't be another.)
>
> At this point it's unlikely that anyone is going to change anyone's mind
> here. We all have our own reasons for wanting to do this one way or the
> other, and I'm sure they all are equally valid, only from different
> viewpoints. But sometimes approaches conflict, and it's necessary to
> choose one or the other to survive.
I am in favor of doing *both* ways. I agree to the need for both, and I
think a structure can be made to accomodate both.
I just read it as there being more a push towards the open 'code depot'
model, and I wanted to push back.
> Personally, I think a Jakarta free-for-all library can be done through
> the tools subproject, and doesn't need to be proposed separately. If
> someone wants to try that, they can just go ahead and run with it. The
> vote to add everyone automatically was a non-starter. So, the next step
> here might be to find some other like-minded committers, and nominate
> each one, until you have a quorum.
Couldn't you leave the option to 'add everyone automatically' up to the
subproject? Taglibs seems to work along these lines?
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] - General Consensus, Round 1
Posted by Ted Husted <ne...@husted.com>.
"Geir Magnusson Jr." wrote:
> Suppose I wanted to include a nice little XML browser, a little visual
> program that lets me see a document as a tree, edit attributes, etc.
> with the XML subproject. Could I not because it by nature cannot be
> used in another Jakarta product?
I would -1 that myself, but that doesn't mean I wouldn't be out-voted
;-).
> 1) shared software to be used by many projects in Jakarta (because that
> is there the nucleus of these projects is going to come from anyway...)
>
> AND
>
> 2) 'products' in their own right, such as DB Connection pool, that are
> useful *outside* of Jakarta projects.
+1. But both (1) and (2) would be components targeted for use by another
Jakarta product, even if also useful to some other product.
It's also important to remember that none of this is written in stone.
We just need to find a do-able starting point to keep things from going
random too early.
> The Jakarta mission is "Provide commercial-quality server solutions
> based on the Java Platform that are developed in an open and cooperative
> fashion." Well, the 'problem space' is growing - there is nothing I see
The Web site says that, but the ASF which owns the Web site, and the
license to all the Apache code (including Velocity), disagrees.
Jakarta's charter is to "create and maintain Java servlet-related
software." Period. This could change any day now, but at this instant,
the Web site's mission statement is out of scope.
> It's becoming clearer that I have a different idea on what this should
> be : I imagine productizing some of the stuff embedded and duplicated in
> possibly multiple projects, and another possibility is a 'communal
> software depot'.
Costin and Ignacio do have a "dissenting opinion" (Costin's phrase).
And that's to be expected in any group, especially in a group of
strong-willed self-starters, like this one. So, we post the
alternatives, take a vote, and move on. When the first poll is complete
we'll have a better idea of what * this * proposal will be about. (Which
isn't to say there couldn't be another.)
At this point it's unlikely that anyone is going to change anyone's mind
here. We all have our own reasons for wanting to do this one way or the
other, and I'm sure they all are equally valid, only from different
viewpoints. But sometimes approaches conflict, and it's necessary to
choose one or the other to survive.
Personally, I think a Jakarta free-for-all library can be done through
the tools subproject, and doesn't need to be proposed separately. If
someone wants to try that, they can just go ahead and run with it. The
vote to add everyone automatically was a non-starter. So, the next step
here might be to find some other like-minded committers, and nominate
each one, until you have a quorum.
-Ted.
Re: [POLL] - General Consensus, Round 1
Posted by Ted Husted <ne...@husted.com>.
"Geir Magnusson Jr." wrote:
> Suppose I wanted to include a nice little XML browser, a little visual
> program that lets me see a document as a tree, edit attributes, etc.
> with the XML subproject. Could I not because it by nature cannot be
> used in another Jakarta product?
I would -1 that myself, but that doesn't mean I wouldn't be out-voted
;-).
> 1) shared software to be used by many projects in Jakarta (because that
> is there the nucleus of these projects is going to come from anyway...)
>
> AND
>
> 2) 'products' in their own right, such as DB Connection pool, that are
> useful *outside* of Jakarta projects.
+1. But both (1) and (2) would be components targeted for use by another
Jakarta product, even if also useful to some other product.
It's also important to remember that none of this is written in stone.
We just need to find a do-able starting point to keep things from going
random too early.
> The Jakarta mission is "Provide commercial-quality server solutions
> based on the Java Platform that are developed in an open and cooperative
> fashion." Well, the 'problem space' is growing - there is nothing I see
The Web site says that, but the ASF which owns the Web site, and the
license to all the Apache code (including Velocity), disagrees.
Jakarta's charter is to "create and maintain Java servlet-related
software." Period. This could change any day now, but at this instant,
the Web site's mission statement is out of scope.
> It's becoming clearer that I have a different idea on what this should
> be : I imagine productizing some of the stuff embedded and duplicated in
> possibly multiple projects, and another possibility is a 'communal
> software depot'.
Costin and Ignacio do have a "dissenting opinion" (Costin's phrase).
And that's to be expected in any group, especially in a group of
strong-willed self-starters, like this one. So, we post the
alternatives, take a vote, and move on. When the first poll is complete
we'll have a better idea of what * this * proposal will be about. (Which
isn't to say there couldn't be another.)
At this point it's unlikely that anyone is going to change anyone's mind
here. We all have our own reasons for wanting to do this one way or the
other, and I'm sure they all are equally valid, only from different
viewpoints. But sometimes approaches conflict, and it's necessary to
choose one or the other to survive.
Personally, I think a Jakarta free-for-all library can be done through
the tools subproject, and doesn't need to be proposed separately. If
someone wants to try that, they can just go ahead and run with it. The
vote to add everyone automatically was a non-starter. So, the next step
here might be to find some other like-minded committers, and nominate
each one, until you have a quorum.
-Ted.
Re: [POLL] - General Consensus, Round 1
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ted Husted wrote:
>
> "Geir Magnusson Jr." wrote:
>
> > What does that mean, exactly? If its written in Java?
>
> Jakarta is already in serious trouble regarding the scope of its
> projects. The ASF takes charters seriously, and we are doing a lot more
> than creating and maintaining Servlet-related software right now. So its
> important that we declare the scope of this subproject - that the
> components are expressly intended for use in another Jakarta product.
I don't agree at all. Maybe it's me misinterpreting what we are doing
here (and it's really embarassing for me if I still have it wrong this
late in the game...), but my intent was to try and 'liberate' some
common, useful tools / utilities / components that are found in Jakarta
projects, and turn them into
1) shared software to be used by many projects in Jakarta (because that
is there the nucleus of these projects is going to come from anyway...)
AND
2) 'products' in their own right, such as DB Connection pool, that are
useful *outside* of Jakarta projects. I mean, you might use a DBCP
*with* Tomcat, but Tomcat isn't actually using it, in that case.
The Jakarta mission is "Provide commercial-quality server solutions
based on the Java Platform that are developed in an open and cooperative
fashion." Well, the 'problem space' is growing - there is nothing I see
there that prevents components and tools that directly support that
mission from being included.
Suppose I wanted to include a nice little XML browser, a little visual
program that lets me see a document as a tree, edit attributes, etc.
with the XML subproject. Could I not because it by nature cannot be
used in another Jakarta product?
>
> > And when thinking about it - aren't Ant and log4j ideal candidates for a
> > tool library?
>
> In the greater scheme of things, there would be a good argument for
> another ASF PMC for Java development tools. Jakarta is not the only ASF
> project that uses Java. XML for example.
I see. Sure. But Jakarta already 'owns' those two. I am simply
suggesting these are two great 'parts' that could help bootstrap a
Jakarta toolset.
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] - General Consensus, Round 1
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ted Husted wrote:
>
> "Geir Magnusson Jr." wrote:
>
> > What does that mean, exactly? If its written in Java?
>
> Jakarta is already in serious trouble regarding the scope of its
> projects. The ASF takes charters seriously, and we are doing a lot more
> than creating and maintaining Servlet-related software right now. So its
> important that we declare the scope of this subproject - that the
> components are expressly intended for use in another Jakarta product.
I don't agree at all. Maybe it's me misinterpreting what we are doing
here (and it's really embarassing for me if I still have it wrong this
late in the game...), but my intent was to try and 'liberate' some
common, useful tools / utilities / components that are found in Jakarta
projects, and turn them into
1) shared software to be used by many projects in Jakarta (because that
is there the nucleus of these projects is going to come from anyway...)
AND
2) 'products' in their own right, such as DB Connection pool, that are
useful *outside* of Jakarta projects. I mean, you might use a DBCP
*with* Tomcat, but Tomcat isn't actually using it, in that case.
The Jakarta mission is "Provide commercial-quality server solutions
based on the Java Platform that are developed in an open and cooperative
fashion." Well, the 'problem space' is growing - there is nothing I see
there that prevents components and tools that directly support that
mission from being included.
Suppose I wanted to include a nice little XML browser, a little visual
program that lets me see a document as a tree, edit attributes, etc.
with the XML subproject. Could I not because it by nature cannot be
used in another Jakarta product?
>
> > And when thinking about it - aren't Ant and log4j ideal candidates for a
> > tool library?
>
> In the greater scheme of things, there would be a good argument for
> another ASF PMC for Java development tools. Jakarta is not the only ASF
> project that uses Java. XML for example.
I see. Sure. But Jakarta already 'owns' those two. I am simply
suggesting these are two great 'parts' that could help bootstrap a
Jakarta toolset.
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] - General Consensus, Round 1
Posted by Ted Husted <ne...@husted.com>.
"Geir Magnusson Jr." wrote:
> What does that mean, exactly? If its written in Java?
Jakarta is already in serious trouble regarding the scope of its
projects. The ASF takes charters seriously, and we are doing a lot more
than creating and maintaining Servlet-related software right now. So its
important that we declare the scope of this subproject - that the
components are expressly intended for use in another Jakarta product.
Once this starts, we may get inquiries from people who are not Jakarta
committers, so we have to think about that.
> +1 for 'may', but since optional, why specify?
> again, why specify if optional?
So that we don't have to answer the question again later.
> And when thinking about it - aren't Ant and log4j ideal candidates for a
> tool library?
In the greater scheme of things, there would be a good argument for
another ASF PMC for Java development tools. Jakarta is not the only ASF
project that uses Java. XML for example.
The project page is updated with the story so far.
< http://husted.com/about/jakarta/library.html >
-Ted.
Re: [POLL] - General Consensus, Round 1
Posted by Ted Husted <ne...@husted.com>.
"Geir Magnusson Jr." wrote:
> What does that mean, exactly? If its written in Java?
Jakarta is already in serious trouble regarding the scope of its
projects. The ASF takes charters seriously, and we are doing a lot more
than creating and maintaining Servlet-related software right now. So its
important that we declare the scope of this subproject - that the
components are expressly intended for use in another Jakarta product.
Once this starts, we may get inquiries from people who are not Jakarta
committers, so we have to think about that.
> +1 for 'may', but since optional, why specify?
> again, why specify if optional?
So that we don't have to answer the question again later.
> And when thinking about it - aren't Ant and log4j ideal candidates for a
> tool library?
In the greater scheme of things, there would be a good argument for
another ASF PMC for Java development tools. Jakarta is not the only ASF
project that uses Java. XML for example.
The project page is updated with the story so far.
< http://husted.com/about/jakarta/library.html >
-Ted.
Re: [POLL] - General Consensus, Round 1
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
>
> > > Should the component be created and maintained by the union of all
> > > interested committers from the Jakarta products that are using the
> > > component?
> >
> > -1 : how do guage 'interested' and why 'using the component'.
>
> "interested" is simple to guage - if project is using a Foo component and
> a project commiter wants to vote or make a proposal for the Foo component
> - he's vote should be binding ( i.e. as if it is a commiter for that
> component ).
It's becoming clearer that I have a different idea on what this should
be : I imagine productizing some of the stuff embedded and duplicated in
possibly multiple projects, and another possibility is a 'communal
software depot'.
I will go re-read what is on Ted's site to see if I can clarify my
thinking. If not, I will post something outside of this thread.
I will participate in a 'software depot' as well, but I think it's
important to go after a more productization strategy for some of this
stuff.
>
> > On the other hand, why modify the usual Jakarta committer rules?
>
> Because that will improve "sharing" and "cooperation" among jakarta
> tribes, instead of creating yet another set of.
Why is it assumed this will create another set? I figure that the
interested parties from each project that has code that is moved to or
replaced by library code would be involved anyway as committers.
It seems to me you are thowing away the working mechanism of the Jakarta
committer system.
Could it be that because of the success of the Jakarta project, and the
broad scope of the projects therein, it's not really possible to return
to the community in the days of yore? (I have no idea what that was
like, btw...)
> > > Any Jakarta committer can add a codebase, SourceForge style.
> >
> > No matter what the structure, -1. SourceForge should remain 'special'
> > :)
>
> What about "any jakarta _project_ " can share a codebase, "Apache" style ?
> ( like APR was spawned from httpd )
>
> > > (2)
> > >
> > > Is overlap between components acceptable? Is it OK for two components to
> > > solve the same problem differently?
> >
> > -1
>
> Then there is no point in creating the library - and you should provide a
> way to decide what component is the "right" one.
Again, I think I am confused on what we are trying to do.
> > Would Jakarta let me start another template engine project that was just
> > like Velocity, didn't do anything differently, or solve a different
> > problem? I hope not.
>
> There are quite a few template engines in jakarta - and that's not bad,
> as new ideas are developed. On the other side - the users decide which is
> the best way to solve the problem ( in our case, other jakarta projects -
> for now, and general users when we get things going )
Which ones? Velocity is the only one I understand to be a template
engine. JSP isn't as much of a template engine as 'the standard' the
template engines are an alternative to. ECS isn't a template engine.
What other template engines?
> > I guess this comes down to the fundamental question of : Is this going
> > to be a library of stuff, or is it 'productizing' some of the utilities
> > and components buried within existing projects?
>
> We have enough "products", the problem we want to solve is "sharing" and
> "cooperationg" , not creating more products.
I disagree - that may be the problem you want to solve, and I don't
disagree with that as a goal, but I got motivated because of the several
connection pools in use in Jakarta (and Java-Apache) products, not one
is cleanly separated and available for general use.
Maybe we should figure this out.
> "Open" development will probably lead to product-quality components, but
> we first need to get the "open/shared/common" development in place.
Again, we need to figure this out.
>
> Costin
--
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] - General Consensus, Round 1
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
>
> > > Should the component be created and maintained by the union of all
> > > interested committers from the Jakarta products that are using the
> > > component?
> >
> > -1 : how do guage 'interested' and why 'using the component'.
>
> "interested" is simple to guage - if project is using a Foo component and
> a project commiter wants to vote or make a proposal for the Foo component
> - he's vote should be binding ( i.e. as if it is a commiter for that
> component ).
It's becoming clearer that I have a different idea on what this should
be : I imagine productizing some of the stuff embedded and duplicated in
possibly multiple projects, and another possibility is a 'communal
software depot'.
I will go re-read what is on Ted's site to see if I can clarify my
thinking. If not, I will post something outside of this thread.
I will participate in a 'software depot' as well, but I think it's
important to go after a more productization strategy for some of this
stuff.
>
> > On the other hand, why modify the usual Jakarta committer rules?
>
> Because that will improve "sharing" and "cooperation" among jakarta
> tribes, instead of creating yet another set of.
Why is it assumed this will create another set? I figure that the
interested parties from each project that has code that is moved to or
replaced by library code would be involved anyway as committers.
It seems to me you are thowing away the working mechanism of the Jakarta
committer system.
Could it be that because of the success of the Jakarta project, and the
broad scope of the projects therein, it's not really possible to return
to the community in the days of yore? (I have no idea what that was
like, btw...)
> > > Any Jakarta committer can add a codebase, SourceForge style.
> >
> > No matter what the structure, -1. SourceForge should remain 'special'
> > :)
>
> What about "any jakarta _project_ " can share a codebase, "Apache" style ?
> ( like APR was spawned from httpd )
>
> > > (2)
> > >
> > > Is overlap between components acceptable? Is it OK for two components to
> > > solve the same problem differently?
> >
> > -1
>
> Then there is no point in creating the library - and you should provide a
> way to decide what component is the "right" one.
Again, I think I am confused on what we are trying to do.
> > Would Jakarta let me start another template engine project that was just
> > like Velocity, didn't do anything differently, or solve a different
> > problem? I hope not.
>
> There are quite a few template engines in jakarta - and that's not bad,
> as new ideas are developed. On the other side - the users decide which is
> the best way to solve the problem ( in our case, other jakarta projects -
> for now, and general users when we get things going )
Which ones? Velocity is the only one I understand to be a template
engine. JSP isn't as much of a template engine as 'the standard' the
template engines are an alternative to. ECS isn't a template engine.
What other template engines?
> > I guess this comes down to the fundamental question of : Is this going
> > to be a library of stuff, or is it 'productizing' some of the utilities
> > and components buried within existing projects?
>
> We have enough "products", the problem we want to solve is "sharing" and
> "cooperationg" , not creating more products.
I disagree - that may be the problem you want to solve, and I don't
disagree with that as a goal, but I got motivated because of the several
connection pools in use in Jakarta (and Java-Apache) products, not one
is cleanly separated and available for general use.
Maybe we should figure this out.
> "Open" development will probably lead to product-quality components, but
> we first need to get the "open/shared/common" development in place.
Again, we need to figure this out.
>
> Costin
--
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] - General Consensus, Round 1
Posted by cm...@yahoo.com.
> > Should the component be created and maintained by the union of all
> > interested committers from the Jakarta products that are using the
> > component?
>
> -1 : how do guage 'interested' and why 'using the component'.
"interested" is simple to guage - if project is using a Foo component and
a project commiter wants to vote or make a proposal for the Foo component
- he's vote should be binding ( i.e. as if it is a commiter for that
component ).
> On the other hand, why modify the usual Jakarta committer rules?
Because that will improve "sharing" and "cooperation" among jakarta
tribes, instead of creating yet another set of.
> > Any Jakarta committer can add a codebase, SourceForge style.
>
> No matter what the structure, -1. SourceForge should remain 'special'
> :)
What about "any jakarta _project_ " can share a codebase, "Apache" style ?
( like APR was spawned from httpd )
> > (2)
> >
> > Is overlap between components acceptable? Is it OK for two components to
> > solve the same problem differently?
>
> -1
Then there is no point in creating the library - and you should provide a
way to decide what component is the "right" one.
> Would Jakarta let me start another template engine project that was just
> like Velocity, didn't do anything differently, or solve a different
> problem? I hope not.
There are quite a few template engines in jakarta - and that's not bad,
as new ideas are developed. On the other side - the users decide which is
the best way to solve the problem ( in our case, other jakarta projects -
for now, and general users when we get things going )
> I guess this comes down to the fundamental question of : Is this going
> to be a library of stuff, or is it 'productizing' some of the utilities
> and components buried within existing projects?
We have enough "products", the problem we want to solve is "sharing" and
"cooperationg" , not creating more products.
"Open" development will probably lead to product-quality components, but
we first need to get the "open/shared/common" development in place.
Costin
Re: [POLL] - General Consensus, Round 1
Posted by Peter Donald <do...@apache.org>.
At 10:28 17/2/01 -0500, Geir Magnusson Jr. wrote:
>Peter Donald wrote:
>>
>> If you are -1 for this then I don't see a point of a separate library
>> project as it would be 100% overlap with Avalon.
>
>Why is Avalon located under Java-Apache yet has the Jakarta look to the
>site? Is it a Jakarta project or not? I don't get it...
It is to be a jakarta project as soon as we decide how it should be
segregated. Currently it has multiple internal products. We have to resolve
how multiple products are organized within a single project (ie is it
possible/desirable) or else ask for split to another project.
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: [POLL] - General Consensus, Round 1
Posted by Peter Donald <do...@apache.org>.
At 10:28 17/2/01 -0500, Geir Magnusson Jr. wrote:
>Peter Donald wrote:
>>
>> If you are -1 for this then I don't see a point of a separate library
>> project as it would be 100% overlap with Avalon.
>
>Why is Avalon located under Java-Apache yet has the Jakarta look to the
>site? Is it a Jakarta project or not? I don't get it...
It is to be a jakarta project as soon as we decide how it should be
segregated. Currently it has multiple internal products. We have to resolve
how multiple products are organized within a single project (ie is it
possible/desirable) or else ask for split to another project.
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: [POLL] - General Consensus, Round 1
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Peter Donald wrote:
>
> If you are -1 for this then I don't see a point of a separate library
> project as it would be 100% overlap with Avalon.
Why is Avalon located under Java-Apache yet has the Jakarta look to the
site? Is it a Jakarta project or not? I don't get it...
--
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] - General Consensus, Round 1
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Peter Donald wrote:
>
> If you are -1 for this then I don't see a point of a separate library
> project as it would be 100% overlap with Avalon.
Why is Avalon located under Java-Apache yet has the Jakarta look to the
site? Is it a Jakarta project or not? I don't get it...
--
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] - General Consensus, Round 1
Posted by Peter Donald <do...@apache.org>.
At 10:27 17/2/01 -0500, Geir Magnusson Jr. wrote:
>Here we go again with this 'secret charter' business. I just *have* to
>figure out where the real charter's are kept.. :)
hasn't been officialized or anything - I guess it would become "official"
if we split the project but until then it is just in mindscope ;)
>When I see the word 'framework', I tend not to think of 'repository' or
>'general utilities'. I tend to think of a set of inter-related pieces
>that may work wonderfully together, but in practice don't come apart
>that easily.
perhaps - though that description is about 2 years old - I am surprised
that it is still as relevent as it is ;)
>What if I don't want to use your common platform?
most parts can be pulled out - everything but the kernel/core-services but
they are not what we are talking about here ;)
>I looked, but I just can't find a DB Connection Pool. I took a look at
>the FAQ, the Javadocs, nothing jumped out at me. Under 'History', I saw
>a hint that 'avalon-independant code was moved to util package'. This
>gives me hope that I will find what I want, but futher cements the idea
>of Avalon-as-Framework with the notion of 'avalon-independant code'.
docs are out of date. The DB pool was the one in Cocoon2 and only got added
in since last release of Avalon (which the docs refer to).
>I am not criticizing Avalon here - I really know nothing about it, other
>than it doesn't appear to be what I looking to help create and support :
>namely a way to take some of the rich but repeated codebase we have here
>in Jakarta and make it available for use for the general server /
>servlet developer as well as shared throughout the Jakarta project set.
>I don't think those two notions are exclusive.
Actually that is exactly what it is about ;)
>> If you are -1 for this then I don't see a point of a separate library
>> project as it would be 100% overlap with Avalon.
>
>I guess I misunderstood Avalon then. Where can I find a list of the
>utilities available?
In CVS ;)
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: [POLL] - General Consensus, Round 1
Posted by Peter Donald <do...@apache.org>.
At 10:27 17/2/01 -0500, Geir Magnusson Jr. wrote:
>Here we go again with this 'secret charter' business. I just *have* to
>figure out where the real charter's are kept.. :)
hasn't been officialized or anything - I guess it would become "official"
if we split the project but until then it is just in mindscope ;)
>When I see the word 'framework', I tend not to think of 'repository' or
>'general utilities'. I tend to think of a set of inter-related pieces
>that may work wonderfully together, but in practice don't come apart
>that easily.
perhaps - though that description is about 2 years old - I am surprised
that it is still as relevent as it is ;)
>What if I don't want to use your common platform?
most parts can be pulled out - everything but the kernel/core-services but
they are not what we are talking about here ;)
>I looked, but I just can't find a DB Connection Pool. I took a look at
>the FAQ, the Javadocs, nothing jumped out at me. Under 'History', I saw
>a hint that 'avalon-independant code was moved to util package'. This
>gives me hope that I will find what I want, but futher cements the idea
>of Avalon-as-Framework with the notion of 'avalon-independant code'.
docs are out of date. The DB pool was the one in Cocoon2 and only got added
in since last release of Avalon (which the docs refer to).
>I am not criticizing Avalon here - I really know nothing about it, other
>than it doesn't appear to be what I looking to help create and support :
>namely a way to take some of the rich but repeated codebase we have here
>in Jakarta and make it available for use for the general server /
>servlet developer as well as shared throughout the Jakarta project set.
>I don't think those two notions are exclusive.
Actually that is exactly what it is about ;)
>> If you are -1 for this then I don't see a point of a separate library
>> project as it would be 100% overlap with Avalon.
>
>I guess I misunderstood Avalon then. Where can I find a list of the
>utilities available?
In CVS ;)
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: [POLL] - General Consensus, Round 1
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Peter Donald wrote:
>
> At 12:10 17/2/01 -0500, Geir Magnusson Jr. wrote:
> >> (2)
> >>
> >> Is overlap between components acceptable? Is it OK for two components to
> >> solve the same problem differently?
> >
> >-1
> >
> >Would Jakarta let me start another template engine project that was just
> >like Velocity, didn't do anything differently, or solve a different
> >problem? I hope not.
> >
> >I think it should be required that if it is similar, that it solves a
> >different or alternate problem and that it's reasonably clear that
> >modifying the existing one isn't practical.
> >
> >I guess this comes down to the fundamental question of : Is this going
> >to be a library of stuff, or is it 'productizing' some of the utilities
> >and components buried within existing projects?
>
> I am curious why you sought this path. If you wanted developers vetting a
> library project - then we already have one of those projects at Apache
> (namely Avalon). Avalons charter is to act as a repository of well designed
> general utilities for server products. (its scope widened to any component
> based products later).
Here we go again with this 'secret charter' business. I just *have* to
figure out where the real charter's are kept.. :)
Re: [POLL] - General Consensus, Round 1
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Peter Donald wrote:
>
> At 12:10 17/2/01 -0500, Geir Magnusson Jr. wrote:
> >> (2)
> >>
> >> Is overlap between components acceptable? Is it OK for two components to
> >> solve the same problem differently?
> >
> >-1
> >
> >Would Jakarta let me start another template engine project that was just
> >like Velocity, didn't do anything differently, or solve a different
> >problem? I hope not.
> >
> >I think it should be required that if it is similar, that it solves a
> >different or alternate problem and that it's reasonably clear that
> >modifying the existing one isn't practical.
> >
> >I guess this comes down to the fundamental question of : Is this going
> >to be a library of stuff, or is it 'productizing' some of the utilities
> >and components buried within existing projects?
>
> I am curious why you sought this path. If you wanted developers vetting a
> library project - then we already have one of those projects at Apache
> (namely Avalon). Avalons charter is to act as a repository of well designed
> general utilities for server products. (its scope widened to any component
> based products later).
Here we go again with this 'secret charter' business. I just *have* to
figure out where the real charter's are kept.. :)
Re: [POLL] - General Consensus, Round 1
Posted by Peter Donald <do...@apache.org>.
At 12:10 17/2/01 -0500, Geir Magnusson Jr. wrote:
>> (2)
>>
>> Is overlap between components acceptable? Is it OK for two components to
>> solve the same problem differently?
>
>-1
>
>Would Jakarta let me start another template engine project that was just
>like Velocity, didn't do anything differently, or solve a different
>problem? I hope not.
>
>I think it should be required that if it is similar, that it solves a
>different or alternate problem and that it's reasonably clear that
>modifying the existing one isn't practical.
>
>I guess this comes down to the fundamental question of : Is this going
>to be a library of stuff, or is it 'productizing' some of the utilities
>and components buried within existing projects?
I am curious why you sought this path. If you wanted developers vetting a
library project - then we already have one of those projects at Apache
(namely Avalon). Avalons charter is to act as a repository of well designed
general utilities for server products. (its scope widened to any component
based products later).
If you are -1 for this then I don't see a point of a separate library
project as it would be 100% overlap with Avalon.
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: [POLL] - General Consensus, Round 1
Posted by Peter Donald <do...@apache.org>.
At 12:10 17/2/01 -0500, Geir Magnusson Jr. wrote:
>> (2)
>>
>> Is overlap between components acceptable? Is it OK for two components to
>> solve the same problem differently?
>
>-1
>
>Would Jakarta let me start another template engine project that was just
>like Velocity, didn't do anything differently, or solve a different
>problem? I hope not.
>
>I think it should be required that if it is similar, that it solves a
>different or alternate problem and that it's reasonably clear that
>modifying the existing one isn't practical.
>
>I guess this comes down to the fundamental question of : Is this going
>to be a library of stuff, or is it 'productizing' some of the utilities
>and components buried within existing projects?
I am curious why you sought this path. If you wanted developers vetting a
library project - then we already have one of those projects at Apache
(namely Avalon). Avalons charter is to act as a repository of well designed
general utilities for server products. (its scope widened to any component
based products later).
If you are -1 for this then I don't see a point of a separate library
project as it would be 100% overlap with Avalon.
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: [POLL] - General Consensus, Round 1
Posted by cm...@yahoo.com.
> > Should the component be created and maintained by the union of all
> > interested committers from the Jakarta products that are using the
> > component?
>
> -1 : how do guage 'interested' and why 'using the component'.
"interested" is simple to guage - if project is using a Foo component and
a project commiter wants to vote or make a proposal for the Foo component
- he's vote should be binding ( i.e. as if it is a commiter for that
component ).
> On the other hand, why modify the usual Jakarta committer rules?
Because that will improve "sharing" and "cooperation" among jakarta
tribes, instead of creating yet another set of.
> > Any Jakarta committer can add a codebase, SourceForge style.
>
> No matter what the structure, -1. SourceForge should remain 'special'
> :)
What about "any jakarta _project_ " can share a codebase, "Apache" style ?
( like APR was spawned from httpd )
> > (2)
> >
> > Is overlap between components acceptable? Is it OK for two components to
> > solve the same problem differently?
>
> -1
Then there is no point in creating the library - and you should provide a
way to decide what component is the "right" one.
> Would Jakarta let me start another template engine project that was just
> like Velocity, didn't do anything differently, or solve a different
> problem? I hope not.
There are quite a few template engines in jakarta - and that's not bad,
as new ideas are developed. On the other side - the users decide which is
the best way to solve the problem ( in our case, other jakarta projects -
for now, and general users when we get things going )
> I guess this comes down to the fundamental question of : Is this going
> to be a library of stuff, or is it 'productizing' some of the utilities
> and components buried within existing projects?
We have enough "products", the problem we want to solve is "sharing" and
"cooperationg" , not creating more products.
"Open" development will probably lead to product-quality components, but
we first need to get the "open/shared/common" development in place.
Costin
Re: [POLL] - General Consensus, Round 1
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ted Husted wrote:
>
> Now that we have a proposed set of committers and codebases, I believe
> the next step is to agree upon a working infrastructure. We could then
> draw up a proposal, and maybe a prototype Web site.
>
> Going over the past posts, I believe we have a consensus on these
> points:
>
> -----
>
> * Each component must be something that can be used by one or more ASF
> products.
What does that mean, exactly? If its written in Java?
>
> * Each component must have a clearly defined purpose, scope, and API.
> (Do one thing well, and keep your contracts!)
+1
> * Each component should clearly specify any external API dependencies,
> including JDK version required.
+1
> * External dependencies on optional and third-party APIs should be
> minimized.
Do we care about, and if so can we clarify licensing restrictions
imposed by those 3rd party APIs?
> * The components should provide Ant build files as part of the standard
> distribution.
+1
> * The components should use XML format files for configuration options.
+1
> * When applicable, optional JavaBean wrappers around a component are
> encouraged.
0 - I don't know why this matters here - that would certainly be a
'product issue'.
> * Each component will be featured on its own page on the subproject Web
> site, which may then be indexed in a master catalog.
+1
> * The subproject may also host a top-level "general" and "announcement"
> mailing list.
+1 for 'may', but since optional, why specify?
> * The subproject may also provide a single JAR of all stable component
> releases. (Perhaps with a subset of JDK 1.1 compatible releases.)
again, why specify if optional?
> -----
>
> Of course, if you disagree with any of these points, please say so now
> (see below). Only committers' votes count, but every committer's vote
> counts!
>
> Following are some additional questions where I was less certain of how
> people feel. Of course, if anyone has similar questions of their own,
> please post them or start a discussion leading to a poll.
>
> Please respond to one alternative in each block (or suggest another
> alternative):
>
> (0)
>
> Do you agree with the "consensus points" above?
See above.
> (1)
>
> Should the the components be created and maintained as individual
> subproducts by a set of "component committers"?
+1
> OR,
>
> Should the component be created and maintained by the union of all
> interested committers from the Jakarta products that are using the
> component?
-1 : how do guage 'interested' and why 'using the component'.
I don't see these as exclusive.
The caveat here is that involvement of interested committers from the
Jakarta projects using the component seems to me to be a critical issue,
and certainly reflects on the 'bootstrap' problem of how to get things
started in the case of components that are clearly duplicated around the
various Jakarta projects.
On the other hand, why modify the usual Jakarta committer rules?
> (2)
>
> Who will approve adding new codebases to the project:
I think this depends upon the final decided structure. If the 'project'
consists of 'subprojects' that each manage a set of 'products' :
POOL :
- object pool
- connection pool
XML :
- blargh
- woobie
Naming :
- gloop
- dwop
Then if you mean adding a new 'category' or realigning category, I have
no clue, other than all or an uber committee.. The committers
associated with a subproject (say 'POOL') sounds like the best group to
decide how 'POOL' is organized.
Starting to look like Jakarta on a smaller length scale...
> All the Committers?
>
> OR,
>
> A group of "core" Committers?
>
> OR,
>
> Any Jakarta committer can add a codebase, SourceForge style.
No matter what the structure, -1. SourceForge should remain 'special'
:)
> (2)
>
> Is overlap between components acceptable? Is it OK for two components to
> solve the same problem differently?
-1
Would Jakarta let me start another template engine project that was just
like Velocity, didn't do anything differently, or solve a different
problem? I hope not.
I think it should be required that if it is similar, that it solves a
different or alternate problem and that it's reasonably clear that
modifying the existing one isn't practical.
I guess this comes down to the fundamental question of : Is this going
to be a library of stuff, or is it 'productizing' some of the utilities
and components buried within existing projects?
> (3)
>
> Do we need a set of super-committers (e.g. PMC members) who can step-up
> when a codebase loses a sole Committer.
+1 or something like that.
> (4)
>
> Can the unit of reuse and release be the package?
>
> OR,
>
> Will we need a larger or smaller "granule" for each codebase?
I think that may depend upon the needs of the subcategory.
> (5)
>
> Should we encourage giving components boring, functional names, to
> emphasize their utilitarian nature?
+1 Yes, please.
> (6)
>
> Do we want to propose this as a Jakarta subproject?
not enough experience to make a judgement
> OR,
>
> Do we want to propose a new PMC that would focus on Java development
> tools
> (Ant and a package/component library -- maybe BSF too)?
not enough experience to make a judgement
> OR,
>
> Start with a pilot Jakarta subproject, and then consider proposing a new
> ASF Project if it works.
Seems the best :)
> -----
>
> I will also soon move < http://husted.com/jakarta/library.html > to the
> Jakarta Web site. (But, hey, its the weekend, the kids are all slept
> over at friends ;-).
>
> -T.
--
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] - General Consensus, Round 1
Posted by Ted Husted <ne...@husted.com>.
> Do you agree with the "consensus points" above?
+1
> (1)
> Should the the components be created and maintained as individual
> subproducts by a set of "component committers"?
+1
> (2)
> Who will approve adding new codebases to the project:
> All the Committers?
+1
By super-majority (3/4's vote)
> (3)
> Is overlap between components acceptable? Is it OK for two components to
> solve the same problem differently?
+1
> (4)
> Do we need a set of super-committers (e.g. PMC members) who can step-up
> when a codebase loses a sole Committer.
+1
I suggest a team of 3 core committers who will take responsibility for
seeing that things like this don't fall through the cracks.
> (5)
> Can the unit of reuse and release be the package?
+1
> (6)
> Should we encourage giving components boring, functional names, to
> emphasize their utilitarian nature?
+1
> (7)
> Start with a pilot Jakarta subproject, and then consider proposing a new
> ASF Project if it works.
+1
-Ted.
Re: [POLL] - General Consensus, Round 1
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Ted Husted wrote:
>
> Now that we have a proposed set of committers and codebases, I believe
> the next step is to agree upon a working infrastructure. We could then
> draw up a proposal, and maybe a prototype Web site.
>
> Going over the past posts, I believe we have a consensus on these
> points:
>
> -----
>
> * Each component must be something that can be used by one or more ASF
> products.
What does that mean, exactly? If its written in Java?
>
> * Each component must have a clearly defined purpose, scope, and API.
> (Do one thing well, and keep your contracts!)
+1
> * Each component should clearly specify any external API dependencies,
> including JDK version required.
+1
> * External dependencies on optional and third-party APIs should be
> minimized.
Do we care about, and if so can we clarify licensing restrictions
imposed by those 3rd party APIs?
> * The components should provide Ant build files as part of the standard
> distribution.
+1
> * The components should use XML format files for configuration options.
+1
> * When applicable, optional JavaBean wrappers around a component are
> encouraged.
0 - I don't know why this matters here - that would certainly be a
'product issue'.
> * Each component will be featured on its own page on the subproject Web
> site, which may then be indexed in a master catalog.
+1
> * The subproject may also host a top-level "general" and "announcement"
> mailing list.
+1 for 'may', but since optional, why specify?
> * The subproject may also provide a single JAR of all stable component
> releases. (Perhaps with a subset of JDK 1.1 compatible releases.)
again, why specify if optional?
> -----
>
> Of course, if you disagree with any of these points, please say so now
> (see below). Only committers' votes count, but every committer's vote
> counts!
>
> Following are some additional questions where I was less certain of how
> people feel. Of course, if anyone has similar questions of their own,
> please post them or start a discussion leading to a poll.
>
> Please respond to one alternative in each block (or suggest another
> alternative):
>
> (0)
>
> Do you agree with the "consensus points" above?
See above.
> (1)
>
> Should the the components be created and maintained as individual
> subproducts by a set of "component committers"?
+1
> OR,
>
> Should the component be created and maintained by the union of all
> interested committers from the Jakarta products that are using the
> component?
-1 : how do guage 'interested' and why 'using the component'.
I don't see these as exclusive.
The caveat here is that involvement of interested committers from the
Jakarta projects using the component seems to me to be a critical issue,
and certainly reflects on the 'bootstrap' problem of how to get things
started in the case of components that are clearly duplicated around the
various Jakarta projects.
On the other hand, why modify the usual Jakarta committer rules?
> (2)
>
> Who will approve adding new codebases to the project:
I think this depends upon the final decided structure. If the 'project'
consists of 'subprojects' that each manage a set of 'products' :
POOL :
- object pool
- connection pool
XML :
- blargh
- woobie
Naming :
- gloop
- dwop
Then if you mean adding a new 'category' or realigning category, I have
no clue, other than all or an uber committee.. The committers
associated with a subproject (say 'POOL') sounds like the best group to
decide how 'POOL' is organized.
Starting to look like Jakarta on a smaller length scale...
> All the Committers?
>
> OR,
>
> A group of "core" Committers?
>
> OR,
>
> Any Jakarta committer can add a codebase, SourceForge style.
No matter what the structure, -1. SourceForge should remain 'special'
:)
> (2)
>
> Is overlap between components acceptable? Is it OK for two components to
> solve the same problem differently?
-1
Would Jakarta let me start another template engine project that was just
like Velocity, didn't do anything differently, or solve a different
problem? I hope not.
I think it should be required that if it is similar, that it solves a
different or alternate problem and that it's reasonably clear that
modifying the existing one isn't practical.
I guess this comes down to the fundamental question of : Is this going
to be a library of stuff, or is it 'productizing' some of the utilities
and components buried within existing projects?
> (3)
>
> Do we need a set of super-committers (e.g. PMC members) who can step-up
> when a codebase loses a sole Committer.
+1 or something like that.
> (4)
>
> Can the unit of reuse and release be the package?
>
> OR,
>
> Will we need a larger or smaller "granule" for each codebase?
I think that may depend upon the needs of the subcategory.
> (5)
>
> Should we encourage giving components boring, functional names, to
> emphasize their utilitarian nature?
+1 Yes, please.
> (6)
>
> Do we want to propose this as a Jakarta subproject?
not enough experience to make a judgement
> OR,
>
> Do we want to propose a new PMC that would focus on Java development
> tools
> (Ant and a package/component library -- maybe BSF too)?
not enough experience to make a judgement
> OR,
>
> Start with a pilot Jakarta subproject, and then consider proposing a new
> ASF Project if it works.
Seems the best :)
> -----
>
> I will also soon move < http://husted.com/jakarta/library.html > to the
> Jakarta Web site. (But, hey, its the weekend, the kids are all slept
> over at friends ;-).
>
> -T.
--
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] - General Consensus, Round 1
Posted by David Weinrich <dw...@home.com>.
On Sat, 17 Feb 2001, Ted Husted wrote:
> Now that we have a proposed set of committers and codebases, I believe
> the next step is to agree upon a working infrastructure. We could then
> draw up a proposal, and maybe a prototype Web site.
>
> Going over the past posts, I believe we have a consensus on these
> points:
>
> -----
>
> * Each component must be something that can be used by one or more ASF
> products.
+0.5 I think this could also be worded as 'be used by or with one or more
ASF products'. Something that isn't a standard part of another product may
be commonly used with that product...
>
> * Each component must have a clearly defined purpose, scope, and API.
> (Do one thing well, and keep your contracts!)
+1
>
> * Each component should clearly specify any external API dependencies,
> including JDK version required.
+1
>
> * External dependencies on optional and third-party APIs should be
> minimized.
+1 I would even go further and say 'discouraged'
>
> * The components should provide Ant build files as part of the standard
> distribution.
+1
>
> * The components should use XML format files for configuration options.
+0, +1 if this isn't implying that this would be the *only* way to
configure the components. I think someone else mentioned having get/set
methods for configuration as a standard goal.
>
> * When applicable, optional JavaBean wrappers around a component are
> encouraged.
+0 see below, I think there may be legitimate cases where different
components solving the same problem in a different way would be a *good*
thing. But I guess the word 'encouraged' kinda covers that.
>
> * Each component will be featured on its own page on the subproject Web
> site, which may then be indexed in a master catalog.
+1 I would even go so far as to state a minimum level of documentation (
FAQ or a simple usage demonstration at the very least ) that would be
encouraged as part of the webpage.
>
> * The subproject may also host a top-level "general" and "announcement"
> mailing list.
+1
>
> * The subproject may also provide a single JAR of all stable component
> releases. (Perhaps with a subset of JDK 1.1 compatible releases.)
>
+1 As long as this doesn't create some pressure to keep diverse components
in a release 'lockstep'. This should be a convenience target and not a
hard and fast rule.
> -----
>
> Of course, if you disagree with any of these points, please say so now
> (see below). Only committers' votes count, but every committer's vote
> counts!
>
> Following are some additional questions where I was less certain of how
> people feel. Of course, if anyone has similar questions of their own,
> please post them or start a discussion leading to a poll.
>
> Please respond to one alternative in each block (or suggest another
> alternative):
>
> (0)
>
> Do you agree with the "consensus points" above?
+1 Absolutely ;) There may be a few rounds of clarifications and
rewording but it looks great.
>
> (1)
>
> Should the the components be created and maintained as individual
> subproducts by a set of "component committers"?
>
> OR,
>
> Should the component be created and maintained by the union of all
> interested committers from the Jakarta products that are using the
> component?
>
'Yes' I don't think these need to be mutually exclusive. In fact I have a
feeling both will happen fairly naturally. To me each of the components
has something of a 'water cooler' effect. The end users ( I probably fit
into this category the best ), the people with expertise on a particular
component and how it can be implemented, and the projects within jakarta
that would like to include a particular functionality ( and don't want or
need to recreate this from scratch ) will cluster together. As far as I
understand the jakarta project in general ( I am fairly new at this and in
this community so not quite so well yet ) this will be something like a
smaller scale view of jakarta in general.
> (2)
>
> Who will approve adding new codebases to the project:
>
> All the Committers?
>
> OR,
>
> A group of "core" Committers?
>
> OR,
>
> Any Jakarta committer can add a codebase, SourceForge style.
Again 'Yes'. I think someone else already made the reference to 'evolution
vs. revolution', and I think this fits here again. I personally would like
to see designs discussed and apis discussed before a codebase gets added,
but that could be me being naive/inexperienced/stupid. But there is
something to be said for different routes of getting a component started.
What is likely to happen is that this list could be used for proposals and
discussions of that nature.
>
> (2)
>
> Is overlap between components acceptable? Is it OK for two components to
> solve the same problem differently?
>
+1 Absolutely. Diversity is a good thing. In fact I see it as a strength
of jakarta as a whole. Having different components with different goals
and designs/solutions for related problems is a good thing, as long as it
isn't motivated or driven by non-functional reasons :). I would hope the
natural pressure that one would receive from proposing a straight
duplication on this mailing list and/or general would tend to discourage
that from happening.
> (3)
>
> Do we need a set of super-committers (e.g. PMC members) who can step-up
> when a codebase loses a sole Committer.
+1 if it is actually needed. Hopefully it would become clear fairly quick
when a component has withered, dropped off the tree, and lost most of its
users.
>
> (4)
>
> Can the unit of reuse and release be the package?
>
> OR,
>
> Will we need a larger or smaller "granule" for each codebase?
>
+0 on either. I think there may be cases where the most useful unit of
reuse may vary.
> (5)
>
> Should we encourage giving components boring, functional names, to
> emphasize their utilitarian nature?
>
+1 hell yes
> (6)
>
> Do we want to propose this as a Jakarta subproject?
>
+0 I think the time when this would be appropriate will make itself
apparent. This particular moment seems too soon ;)
I have a couple other suggestions or recommendations:
* I think the end users and even possibly the developers could benefit
from having development projects or versions clearly delineated from
stable/release versions. The freebsd method ( current/stable/release ) of
doing this, or the even/odd linux thing seem to be good models of this.
* I think the issues of bug tracking and testing also have a place in this
discussion. Being that both of these are over my head/experience level I
will defer starting a discussion directly ;)
> OR,
>
> Do we want to propose a new PMC that would focus on Java development
> tools
> (Ant and a package/component library -- maybe BSF too)?
>
> OR,
>
> Start with a pilot Jakarta subproject, and then consider proposing a new
> ASF Project if it works.
>
> -----
>
> I will also soon move < http://husted.com/jakarta/library.html > to the
> Jakarta Web site. (But, hey, its the weekend, the kids are all slept
> over at friends ;-).
>
Yeehaa!
> -T.
>
Re: [POLL] - General Consensus, Round 1
Posted by cm...@yahoo.com.
> * Each component must be something that can be used by one or more ASF
> products.
+1
Components not used by one or more ASF products could still be hosted, as
revolution/experiments, but not considered "prime-time" and shouldn't be
released. Each component should list the projects that use it.
> * Each component must have a clearly defined purpose, scope, and API.
> (Do one thing well, and keep your contracts!)
+1
> * Each component should clearly specify any external API dependencies,
> including JDK version required.
+1. No restriction on JDK1.1 - I would rather see 2 implementations ( or
components doing the same thing), one specialized in 1.1 for projects
who need 1.1 compat ( maybe the 2 implementation could share
code/config/ideas ).
> * External dependencies on optional and third-party APIs should be
> minimized.
+1
I would rather see - discouraged ( or not permitted ).
> * The components should provide Ant build files as part of the standard
> distribution.
+1
> * The components should use XML format files for configuration options.
-1
I would rather see: components should provide bean style setter if
possible, and avoid defining/using a configuration system.
It should be simple to integrate the components in different projects
using different config styles ( using the setFoo() style ).
( Reason: those components will be used in systems using different styles,
etc - like storing options in a database or jndi, etc.!)
> * When applicable, optional JavaBean wrappers around a component are
> encouraged.
Required ?
What about: components should provide a JavaBean-like API, if possible,
with set/get patterns for configurable properties, etc.
> * Each component will be featured on its own page on the subproject Web
> site, which may then be indexed in a master catalog.
+1
> * The subproject may also host a top-level "general" and "announcement"
> mailing list.
+0
> * The subproject may also provide a single JAR of all stable component
> releases. (Perhaps with a subset of JDK 1.1 compatible releases.)
+0
> (0)
>
> Do you agree with the "consensus points" above?
+0.5
> (1)
>
> Should the the components be created and maintained as individual
> subproducts by a set of "component committers"?
-1. The scope is not to create components per se, but to promote sharing
and colaboration among jakarta projects. Most of the code will come from
existing jakarta projects - and it would be wrong if the original authors
will not share the ownership of the component with other projects.
I don't believe the current "sharing" problems are caused by the code, we
all know code is easy to write/refactor, I think the real problem is
related with the community organization in "tribes".
>
> OR,
>
> Should the component be created and maintained by the union of all
> interested committers from the Jakarta products that are using the
> component?
+10
With emphasis on "interested" - the best way to insure the quality of a
bean and its APIs is to have enough diversifity in the "eyeballs" and have
each project that is using the component represented ( so it can protect
its interests ). Given the fact that it be used in common, it is very
important that the component is of high quality.
That doesn't mean a component used by many projects will have too many
commiters - I don't expect all commiters of every project to manifest
interest and vote on each component. But if a change or the difection of
the component is affecting somebody's work on a project, he should have an
official -1.
It is clear that sometimes different projects will have divergent opinions
- in which case the best solution is to create specialized version (
preferably using the same base, or using a separate component )
> (2)
>
> Who will approve adding new codebases to the project:
>
> All the Committers?
>
> OR,
>
> A group of "core" Committers?
>
> OR,
>
> Any Jakarta committer can add a codebase, SourceForge style.
OR:
Any jakarta project can decide to share a piece of code that is use ( by
refactoring it and sharing control ). Or any jakarta project may decide
that a certain functionality it needs is of general intereset and not
specific to it's core goal, and start a new codebase in the library.
+1 for that. ( which doesn't mean "any jakarta commiter, SourceForge
style)
> (2)
>
> Is overlap between components acceptable? Is it OK for two components to
> solve the same problem differently?
+1 The only way to decide which idea is better is to have them both
implemented side-by-side and see what people choose. ( with the hope that
code, ideas and patterns will be shared by multiple implementations )
This also solves the "specialization" problem - different implementations
may cover different niches ( JDK1.1, footprint, speed, etc) .
> (3)
>
> Do we need a set of super-committers (e.g. PMC members) who can step-up
> when a codebase loses a sole Committer.
I would say it is ok for a codebase to lose a sole commiter - it means the
component is stable, tested, does it's job well, no open bugs - that's the
perfect component IMHO.
The problem is when a codebase loses a sole project that was using it.
Each component can have a "status" - I don't think code should be thrown
away, but a component that is not used should be considered
"experimental" or "revolution".
In other words - new components will be in "revolution" state until at
least a project is using it, or after no project is using it.
> (4)
>
> Can the unit of reuse and release be the package?
+1/2
> OR,
>
> Will we need a larger or smaller "granule" for each codebase?
+1/2
Both are good, for most components it would be better to just use packages
( i.e. jakrata-library/packages/org/apache/library/foo ).
> (5)
>
> Should we encourage giving components boring, functional names, to
> emphasize their utilitarian nature?
+1
> (6)
>
> Do we want to propose this as a Jakarta subproject?
>
> OR,
>
> Do we want to propose a new PMC that would focus on Java development
> tools
> (Ant and a package/component library -- maybe BSF too)?
>
> OR,
>
> Start with a pilot Jakarta subproject, and then consider proposing a new
> ASF Project if it works.
OR,
Try to use one of the existing projects ( jakarta-tools doesn't want it,
maybe jakarta-alexandria ? ) that are already suppoesd to be shared among
projects ?
Costin
Re: [POLL] - General Consensus, Round 1
Posted by David Weinrich <dw...@home.com>.
On Sat, 17 Feb 2001, Ted Husted wrote:
> Now that we have a proposed set of committers and codebases, I believe
> the next step is to agree upon a working infrastructure. We could then
> draw up a proposal, and maybe a prototype Web site.
>
> Going over the past posts, I believe we have a consensus on these
> points:
>
> -----
>
> * Each component must be something that can be used by one or more ASF
> products.
+0.5 I think this could also be worded as 'be used by or with one or more
ASF products'. Something that isn't a standard part of another product may
be commonly used with that product...
>
> * Each component must have a clearly defined purpose, scope, and API.
> (Do one thing well, and keep your contracts!)
+1
>
> * Each component should clearly specify any external API dependencies,
> including JDK version required.
+1
>
> * External dependencies on optional and third-party APIs should be
> minimized.
+1 I would even go further and say 'discouraged'
>
> * The components should provide Ant build files as part of the standard
> distribution.
+1
>
> * The components should use XML format files for configuration options.
+0, +1 if this isn't implying that this would be the *only* way to
configure the components. I think someone else mentioned having get/set
methods for configuration as a standard goal.
>
> * When applicable, optional JavaBean wrappers around a component are
> encouraged.
+0 see below, I think there may be legitimate cases where different
components solving the same problem in a different way would be a *good*
thing. But I guess the word 'encouraged' kinda covers that.
>
> * Each component will be featured on its own page on the subproject Web
> site, which may then be indexed in a master catalog.
+1 I would even go so far as to state a minimum level of documentation (
FAQ or a simple usage demonstration at the very least ) that would be
encouraged as part of the webpage.
>
> * The subproject may also host a top-level "general" and "announcement"
> mailing list.
+1
>
> * The subproject may also provide a single JAR of all stable component
> releases. (Perhaps with a subset of JDK 1.1 compatible releases.)
>
+1 As long as this doesn't create some pressure to keep diverse components
in a release 'lockstep'. This should be a convenience target and not a
hard and fast rule.
> -----
>
> Of course, if you disagree with any of these points, please say so now
> (see below). Only committers' votes count, but every committer's vote
> counts!
>
> Following are some additional questions where I was less certain of how
> people feel. Of course, if anyone has similar questions of their own,
> please post them or start a discussion leading to a poll.
>
> Please respond to one alternative in each block (or suggest another
> alternative):
>
> (0)
>
> Do you agree with the "consensus points" above?
+1 Absolutely ;) There may be a few rounds of clarifications and
rewording but it looks great.
>
> (1)
>
> Should the the components be created and maintained as individual
> subproducts by a set of "component committers"?
>
> OR,
>
> Should the component be created and maintained by the union of all
> interested committers from the Jakarta products that are using the
> component?
>
'Yes' I don't think these need to be mutually exclusive. In fact I have a
feeling both will happen fairly naturally. To me each of the components
has something of a 'water cooler' effect. The end users ( I probably fit
into this category the best ), the people with expertise on a particular
component and how it can be implemented, and the projects within jakarta
that would like to include a particular functionality ( and don't want or
need to recreate this from scratch ) will cluster together. As far as I
understand the jakarta project in general ( I am fairly new at this and in
this community so not quite so well yet ) this will be something like a
smaller scale view of jakarta in general.
> (2)
>
> Who will approve adding new codebases to the project:
>
> All the Committers?
>
> OR,
>
> A group of "core" Committers?
>
> OR,
>
> Any Jakarta committer can add a codebase, SourceForge style.
Again 'Yes'. I think someone else already made the reference to 'evolution
vs. revolution', and I think this fits here again. I personally would like
to see designs discussed and apis discussed before a codebase gets added,
but that could be me being naive/inexperienced/stupid. But there is
something to be said for different routes of getting a component started.
What is likely to happen is that this list could be used for proposals and
discussions of that nature.
>
> (2)
>
> Is overlap between components acceptable? Is it OK for two components to
> solve the same problem differently?
>
+1 Absolutely. Diversity is a good thing. In fact I see it as a strength
of jakarta as a whole. Having different components with different goals
and designs/solutions for related problems is a good thing, as long as it
isn't motivated or driven by non-functional reasons :). I would hope the
natural pressure that one would receive from proposing a straight
duplication on this mailing list and/or general would tend to discourage
that from happening.
> (3)
>
> Do we need a set of super-committers (e.g. PMC members) who can step-up
> when a codebase loses a sole Committer.
+1 if it is actually needed. Hopefully it would become clear fairly quick
when a component has withered, dropped off the tree, and lost most of its
users.
>
> (4)
>
> Can the unit of reuse and release be the package?
>
> OR,
>
> Will we need a larger or smaller "granule" for each codebase?
>
+0 on either. I think there may be cases where the most useful unit of
reuse may vary.
> (5)
>
> Should we encourage giving components boring, functional names, to
> emphasize their utilitarian nature?
>
+1 hell yes
> (6)
>
> Do we want to propose this as a Jakarta subproject?
>
+0 I think the time when this would be appropriate will make itself
apparent. This particular moment seems too soon ;)
I have a couple other suggestions or recommendations:
* I think the end users and even possibly the developers could benefit
from having development projects or versions clearly delineated from
stable/release versions. The freebsd method ( current/stable/release ) of
doing this, or the even/odd linux thing seem to be good models of this.
* I think the issues of bug tracking and testing also have a place in this
discussion. Being that both of these are over my head/experience level I
will defer starting a discussion directly ;)
> OR,
>
> Do we want to propose a new PMC that would focus on Java development
> tools
> (Ant and a package/component library -- maybe BSF too)?
>
> OR,
>
> Start with a pilot Jakarta subproject, and then consider proposing a new
> ASF Project if it works.
>
> -----
>
> I will also soon move < http://husted.com/jakarta/library.html > to the
> Jakarta Web site. (But, hey, its the weekend, the kids are all slept
> over at friends ;-).
>
Yeehaa!
> -T.
>
Re: [POLL] - General Consensus, Round 1
Posted by Peter Donald <do...@apache.org>.
At 07:47 17/2/01 -0500, Ted Husted wrote:
>Peter Donald wrote:
>> * A standard build process (ie template of ant file that also does unit
testing etc)
>> * A standard directory layout
>> * A standard method of handling auxilliary jars
>> * A standard schema/dtd for describing each package
>> * A standard release naming/versioning method
>> * A standard gump installing/notifying thing etc ;)
>> * A standard way to direct bug reports to correct place
>> * A semi standard distribution mechanism (precurson to cjan ???)
>
>I'd say a standards document with examples of these would be generally
>useful to new projects as well.
>
>Is this a prioritized list? If not, is there a optimal order for
>addressing these issues?
Well I guess there is two main concerns;
1. concerns for developers of library
2. concerns for users of library.
We should address (1) first and (2) can come later.
for (1) there is two issues of importance from which other issues stem
a. - easy process for building
b. - communication about product
from [a] stems (in order of importance that I see)
- A standard build process - including standard ant targets etc
- A standard directory layout
- A standard method of handling auxilliary jars
- A standard release naming/versioning method
and [b] stems (in order of importance that I see)
- A standard gump installing/notifying thing etc ;)
- A standard way to direct bug reports to correct place
For (2) we have (in my order of importance)
a. - A semi standard distribution mechanism (precurson to cjan ???)
b. - A standard schema/dtd for describing each package
>Is there an existing subproject that does these things particularly
>well, that we could use as a skeleton?
Well I am biased but I would say for 1a there is the Avalon build process.
It went through three revisions grabbing the best bits from all the
projects on jakarta. It is mainly turbine build process with cocoon style
building added in.
As for the rest I think we have to invent it as we go along as it doesn't
exist within apache (though it does in other projects).
>What will be the best way to work toward resolving these issues?
propose, vote, revise, vote again and repeat ;)
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: [POLL] - General Consensus, Round 1
Posted by Peter Donald <do...@apache.org>.
At 07:47 17/2/01 -0500, Ted Husted wrote:
>Peter Donald wrote:
>> * A standard build process (ie template of ant file that also does unit
testing etc)
>> * A standard directory layout
>> * A standard method of handling auxilliary jars
>> * A standard schema/dtd for describing each package
>> * A standard release naming/versioning method
>> * A standard gump installing/notifying thing etc ;)
>> * A standard way to direct bug reports to correct place
>> * A semi standard distribution mechanism (precurson to cjan ???)
>
>I'd say a standards document with examples of these would be generally
>useful to new projects as well.
>
>Is this a prioritized list? If not, is there a optimal order for
>addressing these issues?
Well I guess there is two main concerns;
1. concerns for developers of library
2. concerns for users of library.
We should address (1) first and (2) can come later.
for (1) there is two issues of importance from which other issues stem
a. - easy process for building
b. - communication about product
from [a] stems (in order of importance that I see)
- A standard build process - including standard ant targets etc
- A standard directory layout
- A standard method of handling auxilliary jars
- A standard release naming/versioning method
and [b] stems (in order of importance that I see)
- A standard gump installing/notifying thing etc ;)
- A standard way to direct bug reports to correct place
For (2) we have (in my order of importance)
a. - A semi standard distribution mechanism (precurson to cjan ???)
b. - A standard schema/dtd for describing each package
>Is there an existing subproject that does these things particularly
>well, that we could use as a skeleton?
Well I am biased but I would say for 1a there is the Avalon build process.
It went through three revisions grabbing the best bits from all the
projects on jakarta. It is mainly turbine build process with cocoon style
building added in.
As for the rest I think we have to invent it as we go along as it doesn't
exist within apache (though it does in other projects).
>What will be the best way to work toward resolving these issues?
propose, vote, revise, vote again and repeat ;)
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: [POLL] - General Consensus, Round 1
Posted by Ted Husted <ne...@husted.com>.
Peter Donald wrote:
> * A standard build process (ie template of ant file that also does unit testing etc)
> * A standard directory layout
> * A standard method of handling auxilliary jars
> * A standard schema/dtd for describing each package
> * A standard release naming/versioning method
> * A standard gump installing/notifying thing etc ;)
> * A standard way to direct bug reports to correct place
> * A semi standard distribution mechanism (precurson to cjan ???)
I'd say a standards document with examples of these would be generally
useful to new projects as well.
Is this a prioritized list? If not, is there a optimal order for
addressing these issues?
Is there an existing subproject that does these things particularly
well, that we could use as a skeleton?
What will be the best way to work toward resolving these issues?
-Ted.
Re: [POLL] - General Consensus, Round 1
Posted by Ted Husted <ne...@husted.com>.
Peter Donald wrote:
> * A standard build process (ie template of ant file that also does unit testing etc)
> * A standard directory layout
> * A standard method of handling auxilliary jars
> * A standard schema/dtd for describing each package
> * A standard release naming/versioning method
> * A standard gump installing/notifying thing etc ;)
> * A standard way to direct bug reports to correct place
> * A semi standard distribution mechanism (precurson to cjan ???)
I'd say a standards document with examples of these would be generally
useful to new projects as well.
Is this a prioritized list? If not, is there a optimal order for
addressing these issues?
Is there an existing subproject that does these things particularly
well, that we could use as a skeleton?
What will be the best way to work toward resolving these issues?
-Ted.
Re: [POLL] - General Consensus, Round 1
Posted by Peter Donald <do...@apache.org>.
At 10:39 17/2/01 -0500, Ted Husted wrote:
>"* Components are encouraged to use XML format files for configuration
>options."
>
>This and your other comments have been noted on the working project
>page.
It's a nice idea - but the problem arises - whos config system do we use ;)
I prefer XML configs at all costs but I am just concerned about the
practicalities ...
>> before we do this we need to have more infrastructure in place. I think
>> seeing gump more integrated etc will greatly help this as will a
>> standadised build/test process acorss products. Unsexy yes but without it
>> we will just end up with a bunch of code in repository.
>
>Could you be more specific? Exactly what infrastructure do we need? What
>flavor of grit did you have in mind?
* A standard build process (ie template of ant file that also does unit
testing etc)
* A standard directory layout
* A standard method of handling auxilliary jars
* A standard schema/dtd for describing each package
* A standard release naming/versioning method
* A standard gump installing/notifying thing etc ;)
* A standard way to direct bug reports to correct place
* A semi standard distribution mechanism (precurson to cjan ???)
etc
These may all sound like boring things but it is just too much of a PITA to
work without them. When each component has different build process it is
near impossible to actually get cross pollination and users will walk away.
I have seen people walk away from a projects because their build process is
not logical per-se or different from their experience. The same should not
happen in here.
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: [POLL] - General Consensus, Round 1
Posted by Peter Donald <do...@apache.org>.
At 10:39 17/2/01 -0500, Ted Husted wrote:
>"* Components are encouraged to use XML format files for configuration
>options."
>
>This and your other comments have been noted on the working project
>page.
It's a nice idea - but the problem arises - whos config system do we use ;)
I prefer XML configs at all costs but I am just concerned about the
practicalities ...
>> before we do this we need to have more infrastructure in place. I think
>> seeing gump more integrated etc will greatly help this as will a
>> standadised build/test process acorss products. Unsexy yes but without it
>> we will just end up with a bunch of code in repository.
>
>Could you be more specific? Exactly what infrastructure do we need? What
>flavor of grit did you have in mind?
* A standard build process (ie template of ant file that also does unit
testing etc)
* A standard directory layout
* A standard method of handling auxilliary jars
* A standard schema/dtd for describing each package
* A standard release naming/versioning method
* A standard gump installing/notifying thing etc ;)
* A standard way to direct bug reports to correct place
* A semi standard distribution mechanism (precurson to cjan ???)
etc
These may all sound like boring things but it is just too much of a PITA to
work without them. When each component has different build process it is
near impossible to actually get cross pollination and users will walk away.
I have seen people walk away from a projects because their build process is
not logical per-se or different from their experience. The same should not
happen in here.
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: [POLL] - General Consensus, Round 1
Posted by Ted Husted <ne...@husted.com>.
Peter Donald wrote:
> >* The components should use XML format files for configuration options.
>
> Not sure there is consensus on this as a number of different config
> patterns are used and a number of different representations - from SAX to
> JDOM to Properties to jserv1 Configuration to jserv2/avalon Configuration
> to Parameters etc
How about
"* Components are encouraged to use XML format files for configuration
options."
This and your other comments have been noted on the working project
page.
< http://www.husted.com/about/jakarta/library.html >
Thanks for the quick reply!
> before we do this we need to have more infrastructure in place. I think
> seeing gump more integrated etc will greatly help this as will a
> standadised build/test process acorss products. Unsexy yes but without it
> we will just end up with a bunch of code in repository.
Could you be more specific? Exactly what infrastructure do we need? What
flavor of grit did you have in mind?
-- 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/jakarta/library.html
Re: [POLL] - General Consensus, Round 1
Posted by Ted Husted <ne...@husted.com>.
Peter Donald wrote:
> >* The components should use XML format files for configuration options.
>
> Not sure there is consensus on this as a number of different config
> patterns are used and a number of different representations - from SAX to
> JDOM to Properties to jserv1 Configuration to jserv2/avalon Configuration
> to Parameters etc
How about
"* Components are encouraged to use XML format files for configuration
options."
This and your other comments have been noted on the working project
page.
< http://www.husted.com/about/jakarta/library.html >
Thanks for the quick reply!
> before we do this we need to have more infrastructure in place. I think
> seeing gump more integrated etc will greatly help this as will a
> standadised build/test process acorss products. Unsexy yes but without it
> we will just end up with a bunch of code in repository.
Could you be more specific? Exactly what infrastructure do we need? What
flavor of grit did you have in mind?
-- 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/jakarta/library.html
Re: [POLL] - General Consensus, Round 1
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
> "Interested"!!! If 100 people will be interested in a simple DBPool -
> well, it's unlikely, but it will not be bad - I'm sure the result will be
> the best pool ever :-)
Why do you think this? Every person I know developing with servlets and
a database eventually runs into the need for a db pool! Every single
person. This is a basic component used in 'server-side solutions for
the Java platform', and Jakarta doesn't offer on.
Sure, you can dig one out of Struts, or you can dig one out of Turbine
(but that isn't here in Jakarta... lets keep this to Jakarta), or you
can get one out of Cocoon (that isn't Jakarta), or you can dig one...
Why do people have to dig?
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] - General Consensus, Round 1
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
cmanolache@yahoo.com wrote:
> "Interested"!!! If 100 people will be interested in a simple DBPool -
> well, it's unlikely, but it will not be bad - I'm sure the result will be
> the best pool ever :-)
Why do you think this? Every person I know developing with servlets and
a database eventually runs into the need for a db pool! Every single
person. This is a basic component used in 'server-side solutions for
the Java platform', and Jakarta doesn't offer on.
Sure, you can dig one out of Struts, or you can dig one out of Turbine
(but that isn't here in Jakarta... lets keep this to Jakarta), or you
can get one out of Cocoon (that isn't Jakarta), or you can dig one...
Why do people have to dig?
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] - General Consensus, Round 1
Posted by cm...@yahoo.com.
> >Should the the components be created and maintained as individual
> >subproducts by a set of "component committers"?
>
> I think whoever (individual or group) adds it in initially should take
> "ownership" of it and help maintain it and hopefully it should be passed on
> to other individuals/groups.
Then where is the "sharing" ? If a project decides a component it develops
is to be "shared", it shouldn't mean just placing it in a common
repository - it should mean allow other projects to paticipate with equal
rights.
> >Should the component be created and maintained by the union of all
> >interested committers from the Jakarta products that are using the
> >component?
>
> impossible to do - the cost of communication becomes higher than cost of
> reimplementing it by yourself.
"Interested"!!! If 100 people will be interested in a simple DBPool -
well, it's unlikely, but it will not be bad - I'm sure the result will be
the best pool ever :-)
Costin
Re: [POLL] - General Consensus, Round 1
Posted by cm...@yahoo.com.
> >Should the the components be created and maintained as individual
> >subproducts by a set of "component committers"?
>
> I think whoever (individual or group) adds it in initially should take
> "ownership" of it and help maintain it and hopefully it should be passed on
> to other individuals/groups.
Then where is the "sharing" ? If a project decides a component it develops
is to be "shared", it shouldn't mean just placing it in a common
repository - it should mean allow other projects to paticipate with equal
rights.
> >Should the component be created and maintained by the union of all
> >interested committers from the Jakarta products that are using the
> >component?
>
> impossible to do - the cost of communication becomes higher than cost of
> reimplementing it by yourself.
"Interested"!!! If 100 people will be interested in a simple DBPool -
well, it's unlikely, but it will not be bad - I'm sure the result will be
the best pool ever :-)
Costin
Re: [POLL] - General Consensus, Round 1
Posted by Peter Donald <do...@apache.org>.
At 07:24 17/2/01 -0500, Ted Husted wrote:
>* The components should use XML format files for configuration options.
Not sure there is consensus on this as a number of different config
patterns are used and a number of different representations - from SAX to
JDOM to Properties to jserv1 Configuration to jserv2/avalon Configuration
to Parameters etc
>* When applicable, optional JavaBean wrappers around a component are
>encouraged.
I think it should be other way around. If at all possible the core should
be a javabean while the scaffolding around it can be framework specific (ie
turbine/struts/avalon/whatever).
>(1)
>
>Should the the components be created and maintained as individual
>subproducts by a set of "component committers"?
I think whoever (individual or group) adds it in initially should take
"ownership" of it and help maintain it and hopefully it should be passed on
to other individuals/groups.
>Should the component be created and maintained by the union of all
>interested committers from the Jakarta products that are using the
>component?
impossible to do - the cost of communication becomes higher than cost of
reimplementing it by yourself.
>(2)
>
>Is overlap between components acceptable? Is it OK for two components to
>solve the same problem differently?
yep. Otherwise innovation is styfled.
>(3)
>
>Do we need a set of super-committers (e.g. PMC members) who can step-up
>when a codebase loses a sole Committer.
>Can the unit of reuse and release be the package?
should be ;)
>Should we encourage giving components boring, functional names, to
>emphasize their utilitarian nature?
+1
>Do we want to propose this as a Jakarta subproject?
before we do this we need to have more infrastructure in place. I think
seeing gump more integrated etc will greatly help this as will a
standadised build/test process acorss products. Unsexy yes but without it
we will just end up with a bunch of code in repository.
>Do we want to propose a new PMC that would focus on Java development
>tools
>(Ant and a package/component library -- maybe BSF too)?
not something we can consider now. Lets get some grit down before making
too grander plans or else we may putt putt out of steam ;)
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: [POLL] - General Consensus, Round 1
Posted by Peter Donald <do...@apache.org>.
At 07:24 17/2/01 -0500, Ted Husted wrote:
>* The components should use XML format files for configuration options.
Not sure there is consensus on this as a number of different config
patterns are used and a number of different representations - from SAX to
JDOM to Properties to jserv1 Configuration to jserv2/avalon Configuration
to Parameters etc
>* When applicable, optional JavaBean wrappers around a component are
>encouraged.
I think it should be other way around. If at all possible the core should
be a javabean while the scaffolding around it can be framework specific (ie
turbine/struts/avalon/whatever).
>(1)
>
>Should the the components be created and maintained as individual
>subproducts by a set of "component committers"?
I think whoever (individual or group) adds it in initially should take
"ownership" of it and help maintain it and hopefully it should be passed on
to other individuals/groups.
>Should the component be created and maintained by the union of all
>interested committers from the Jakarta products that are using the
>component?
impossible to do - the cost of communication becomes higher than cost of
reimplementing it by yourself.
>(2)
>
>Is overlap between components acceptable? Is it OK for two components to
>solve the same problem differently?
yep. Otherwise innovation is styfled.
>(3)
>
>Do we need a set of super-committers (e.g. PMC members) who can step-up
>when a codebase loses a sole Committer.
>Can the unit of reuse and release be the package?
should be ;)
>Should we encourage giving components boring, functional names, to
>emphasize their utilitarian nature?
+1
>Do we want to propose this as a Jakarta subproject?
before we do this we need to have more infrastructure in place. I think
seeing gump more integrated etc will greatly help this as will a
standadised build/test process acorss products. Unsexy yes but without it
we will just end up with a bunch of code in repository.
>Do we want to propose a new PMC that would focus on Java development
>tools
>(Ant and a package/component library -- maybe BSF too)?
not something we can consider now. Lets get some grit down before making
too grander plans or else we may putt putt out of steam ;)
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: [POLL] - General Consensus, Round 1
Posted by cm...@yahoo.com.
> * Each component must be something that can be used by one or more ASF
> products.
+1
Components not used by one or more ASF products could still be hosted, as
revolution/experiments, but not considered "prime-time" and shouldn't be
released. Each component should list the projects that use it.
> * Each component must have a clearly defined purpose, scope, and API.
> (Do one thing well, and keep your contracts!)
+1
> * Each component should clearly specify any external API dependencies,
> including JDK version required.
+1. No restriction on JDK1.1 - I would rather see 2 implementations ( or
components doing the same thing), one specialized in 1.1 for projects
who need 1.1 compat ( maybe the 2 implementation could share
code/config/ideas ).
> * External dependencies on optional and third-party APIs should be
> minimized.
+1
I would rather see - discouraged ( or not permitted ).
> * The components should provide Ant build files as part of the standard
> distribution.
+1
> * The components should use XML format files for configuration options.
-1
I would rather see: components should provide bean style setter if
possible, and avoid defining/using a configuration system.
It should be simple to integrate the components in different projects
using different config styles ( using the setFoo() style ).
( Reason: those components will be used in systems using different styles,
etc - like storing options in a database or jndi, etc.!)
> * When applicable, optional JavaBean wrappers around a component are
> encouraged.
Required ?
What about: components should provide a JavaBean-like API, if possible,
with set/get patterns for configurable properties, etc.
> * Each component will be featured on its own page on the subproject Web
> site, which may then be indexed in a master catalog.
+1
> * The subproject may also host a top-level "general" and "announcement"
> mailing list.
+0
> * The subproject may also provide a single JAR of all stable component
> releases. (Perhaps with a subset of JDK 1.1 compatible releases.)
+0
> (0)
>
> Do you agree with the "consensus points" above?
+0.5
> (1)
>
> Should the the components be created and maintained as individual
> subproducts by a set of "component committers"?
-1. The scope is not to create components per se, but to promote sharing
and colaboration among jakarta projects. Most of the code will come from
existing jakarta projects - and it would be wrong if the original authors
will not share the ownership of the component with other projects.
I don't believe the current "sharing" problems are caused by the code, we
all know code is easy to write/refactor, I think the real problem is
related with the community organization in "tribes".
>
> OR,
>
> Should the component be created and maintained by the union of all
> interested committers from the Jakarta products that are using the
> component?
+10
With emphasis on "interested" - the best way to insure the quality of a
bean and its APIs is to have enough diversifity in the "eyeballs" and have
each project that is using the component represented ( so it can protect
its interests ). Given the fact that it be used in common, it is very
important that the component is of high quality.
That doesn't mean a component used by many projects will have too many
commiters - I don't expect all commiters of every project to manifest
interest and vote on each component. But if a change or the difection of
the component is affecting somebody's work on a project, he should have an
official -1.
It is clear that sometimes different projects will have divergent opinions
- in which case the best solution is to create specialized version (
preferably using the same base, or using a separate component )
> (2)
>
> Who will approve adding new codebases to the project:
>
> All the Committers?
>
> OR,
>
> A group of "core" Committers?
>
> OR,
>
> Any Jakarta committer can add a codebase, SourceForge style.
OR:
Any jakarta project can decide to share a piece of code that is use ( by
refactoring it and sharing control ). Or any jakarta project may decide
that a certain functionality it needs is of general intereset and not
specific to it's core goal, and start a new codebase in the library.
+1 for that. ( which doesn't mean "any jakarta commiter, SourceForge
style)
> (2)
>
> Is overlap between components acceptable? Is it OK for two components to
> solve the same problem differently?
+1 The only way to decide which idea is better is to have them both
implemented side-by-side and see what people choose. ( with the hope that
code, ideas and patterns will be shared by multiple implementations )
This also solves the "specialization" problem - different implementations
may cover different niches ( JDK1.1, footprint, speed, etc) .
> (3)
>
> Do we need a set of super-committers (e.g. PMC members) who can step-up
> when a codebase loses a sole Committer.
I would say it is ok for a codebase to lose a sole commiter - it means the
component is stable, tested, does it's job well, no open bugs - that's the
perfect component IMHO.
The problem is when a codebase loses a sole project that was using it.
Each component can have a "status" - I don't think code should be thrown
away, but a component that is not used should be considered
"experimental" or "revolution".
In other words - new components will be in "revolution" state until at
least a project is using it, or after no project is using it.
> (4)
>
> Can the unit of reuse and release be the package?
+1/2
> OR,
>
> Will we need a larger or smaller "granule" for each codebase?
+1/2
Both are good, for most components it would be better to just use packages
( i.e. jakrata-library/packages/org/apache/library/foo ).
> (5)
>
> Should we encourage giving components boring, functional names, to
> emphasize their utilitarian nature?
+1
> (6)
>
> Do we want to propose this as a Jakarta subproject?
>
> OR,
>
> Do we want to propose a new PMC that would focus on Java development
> tools
> (Ant and a package/component library -- maybe BSF too)?
>
> OR,
>
> Start with a pilot Jakarta subproject, and then consider proposing a new
> ASF Project if it works.
OR,
Try to use one of the existing projects ( jakarta-tools doesn't want it,
maybe jakarta-alexandria ? ) that are already suppoesd to be shared among
projects ?
Costin