You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by Pierre Delisle <pi...@sun.com> on 2002/09/27 22:39:08 UTC
Accepting new projects [was: LDAP taglib proposal]
I have not received any comments on my proposal for
opening up the way we accept new proposals for
jakarta-taglibs.
I'd eventually like to call for a vote on that topic,
but before I do so, let me expand a little bit more
on how I'd see it happen for two cases we currently have pending:
the JNDI/LDAP taglib (Orhan, Mark, Mike), as well
as the PDF taglib (Roberto).
Essentially, I think we could run the design/development of
these new taglibs a bit like the JSR-52 expert group has functioned
for the design/development of JSTL 1.0.
We have experts on specific topics that have the interest as well as
commitment to assume the responsibility to successfully design and
develop new libraries. What they need is a stimulating environment to
bring their project to fruition. jakarta-taglibs should be the right
place to do so if we have the proper process in place.
So, leveraging the experience of the JSTL expert group, as well
as our current "new project submission" rules, how about something
like this:
---
1. Motivation
First of all, the motivation for a new project should be clear.
There is a multitude of topics that custom taglibs can address.
I don't think we should accept any project for which the value
proposition is not clear.
So, if someone is interested in submitting a new project
to jakarta-taglibs, it should start with a document that
describes the motivation for the new taglib.
This document clearly explains why this taglib is important/useful.
It tells what kind of problems it solves.
It provides as many concrete use cases as possible
to support the fact that this will be a good addition to
a page author's toolbox.
For example:
It would be very important to learn at this
stage why people want to do JNDI/LDAP in JSP and not in the
business logic. Orhan seems to already have many customers
for his taglib; it would be great to hear why they find
it so useful in their development environment. Same with
Mark and Mike.
As for Roberto's PDF taglib, I must admit I know nothing
about FO, but would very much like to understand why
I should care, and why people would be interested in
his taglib. How do they do it right now without the taglib?
What benefit will they gain with the taglib?
It is the responsibility of the submitter(s) to generate
interest for the taglib. Show to everyone that it is worth
for jakarta-taglibs to pay attention to your proposal.
---
2. Comparative Analysis
If applicable, a comparative analysis should accompany
the motivation document (or follow shortly afterwards).
It should answer the following questions:
- Other taglibs out there that do something similar?
- What are their strenghts/weaknesses
- Why should we have one at jakarta-taglibs?
- What will be the key design issues?
---
3. Vote
The intent of (1) and (2) is to make sure that a submitter
does his/her homework properly to motivate the need
for that new taglib. A vote should not be called
until that homework has been successfully completed.
Details to be nailed down, but we probably need
binding votes where whoever votes +1 will be committed
in helping this project be successful (the submitter
will need help to get the project started in the
sandbox)
Once the vote is positive, the project enters the sandbox,
and design discussions can start on the list.
---
4. Design / Development
A design document for the taglib is a requirement.
I'd suggest using the same format as the one used
for the JSTL spec (e.g. see chapter 9 for the SQL actions).
[I believe that format is clear, provide enough
information to get someone up and running easily with the taglib, and leaves
plenty of room for book/article authors to write more about them...]
The process is iterative. First draft of spec; get comments,
adjust spec, more comments, some implementation; second
draft of the spec, more comments, more implementation, etc...
The project is hosted in the sandbox, and eventually moves
to the official repository once it is ready for prime time.
[And by doing a great job at designing the best possible taglig
for that specific topic, the taglib is eventually considered
within the Java Community Process for standardization :-)]
---
Call for Action
Here are some things we need to do to help us move forward:
- All: Is this the right direction?
We still need to refine the proposal made above, but how
does it sound in general? Is that the direction we should take to
be more flexible in handling new project submissions?
[the main difference with the current rules is that we would not
mandate a project to be fully cooked before being accepted;
we would simply require it to have clear motivation for its importance,
clear commitment from the submitters, and clear interest from the community).
- JNDI/LDAP
Orhan, Mark, Mike: Would this process work for all of you interested in a newly
designed JNDI/LDAP taglib? If yes, then I'd propose that you guys decide among
yourself how to get the motivation/comparative analysis documents ready for
consideration by the list.
- PDF
Roberto: Same question to you. Would this process work for you?
If yes, then please get us clear motivation / comparative analysis
documents...
Sorry for another long email...
-- Pierre
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Accepting new projects [was: LDAP taglib proposal]
Posted by Pierre Delisle <pi...@sun.com>.
Hi Mark,
> >- All: Is this the right direction?
> I think the sandbox is important place for projects to start out because
> otherwise they endup like the current JNDI Taglib, stale and without
> developers. I think it should be a requirement that a taglib gets a
> certain following (both in terms of # users and developer support)
> before it can graduate from the sandbox. With this in mind, having a
> number of individuals interested in getting together to work on a
> project in the sandbox should be grounds enough to get a branch started.
OK, we're in agreement.
> But,...
>
> there should be a definite passage through your development process
> before files start showing up. We need to isolate that we all want to
> see the same results from the project. (ie right now some want a LDAP
> library while others want a JNDI library, while similar in architecture,
> they encompass different scopes of application). Making sure that the
> design fits cleanly at both scopes is important.
Totally agree (as I pointed out in previous replies). This should
all be cleared up when the projects is first discussed before being
approved.
...
> I have a couple of questions:
>
> 1.) As we all have interest in the design of the library as well as its
> development, shouldn't this process be exposed to the community
> (jakarata-taglib's) as well via jakarta-taglib developers list?
Definitely, as I replied to Orhan.
> 2.) As you've somewhat decided that a broader scope JNDI taglib is
> favored over a narrower scope LDAP taglib, what are we going to gain
> from a comparitive aalysis?
Personally, I think it would be very useful to know how different
projects have tackled the same problem. We always learn a lot from
these competitive analysis (both what's good and what's bad).
> 3.) As a JNDI taglib is basically wrapping the behavior of an already
> *well* designed package, shouldn't design of the taglib mirror that
> package? The strategy I had used originally in my project involved
> creating simple wrapper tags that simply called these methods in the
> javax.naming,Context/directory.DirContext stored in a scope of the
> servlet engine.
The key thing here is to clearly define what the purpose of the taglib
is. That's why use cases are so important.
Is this for a developer who simply does not want to do that stuff in the
backend (because it's easier in the JSP page)? Or is this for a page
author that does not know much about JNDI but will gain from this
set of tags? All important things to discuss before accepting
a taglib in the sandbox... (or maybe we don't know, and just want to
experiment... which is also OK as long as we all know that's what
we're after...)
-- Pierre
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Accepting new projects [was: LDAP taglib proposal]
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Pierre Delisle wrote:
>---
>Call for Action
>
>Here are some things we need to do to help us move forward:
>
>- All: Is this the right direction?
>
> We still need to refine the proposal made above, but how
> does it sound in general? Is that the direction we should take to
> be more flexible in handling new project submissions?
> [the main difference with the current rules is that we would not
> mandate a project to be fully cooked before being accepted;
> we would simply require it to have clear motivation for its importance,
> clear commitment from the submitters, and clear interest from the community).
>
I think the sandbox is important place for projects to start out because
otherwise they endup like the current JNDI Taglib, stale and without
developers. I think it should be a requirement that a taglib gets a
certain following (both in terms of # users and developer support)
before it can graduate from the sandbox. With this in mind, having a
number of individuals interested in getting together to work on a
project in the sandbox should be grounds enough to get a branch started.
But,...
there should be a definite passage through your development process
before files start showing up. We need to isolate that we all want to
see the same results from the project. (ie right now some want a LDAP
library while others want a JNDI library, while similar in architecture,
they encompass different scopes of application). Making sure that the
design fits cleanly at both scopes is important.
>- JNDI/LDAP
>
> Orhan, Mark, Mike: Would this process work for all of you interested in a newly
> designed JNDI/LDAP taglib? If yes, then I'd propose that you guys decide among
> yourself how to get the motivation/comparative analysis documents ready for
> consideration by the list.
>
------------------ Orhans response
> Hi Pierre,
> I agree with Glenn in some points. However, your proposal is
> acceptable for us. Here is my plan;
> - Me, Ayhan Alkan and Murat Go"rgu"ner are going to contribute to
> JNDI/LDAP taglib design and development. We'll be glad if Mike and
> Mark join us. This would be our team for the project.
> - We can prepare motivation, comparative analysis and high-level
> taglib design in 2-3 weeks.
>
> I'm looking for your comments.
> Regards
> Orhan Alkan
I have a couple of questions:
1.) As we all have interest in the design of the library as well as its
development, shouldn't this process be exposed to the community
(jakarata-taglib's) as well via jakarta-taglib developers list?
2.) As you've somewhat decided that a broader scope JNDI taglib is
favored over a narrower scope LDAP taglib, what are we going to gain
from a comparitive aalysis?
3.) As a JNDI taglib is basically wrapping the behavior of an already
*well* designed package, shouldn't design of the taglib mirror that
package? The strategy I had used originally in my project involved
creating simple wrapper tags that simply called these methods in the
javax.naming,Context/directory.DirContext stored in a scope of the
servlet engine.
i.e.
org.apache.jakarta.taglib.naming.ContextTag
org.apache.jakarta.taglib.naming.method.CreateSubContextTag
org.apache.jakarta.taglib.naming.method.DestroySubContextTag
org.apache.jakarta.taglib.naming.method.LookupTag
org.apache.jakarta.taglib.naming.method.BindTag
org.apache.jakarta.taglib.naming.method.UnbindTag
org.apache.jakarta.taglib.naming.method.ListTag
...
org.apache.jakarta.taglib.naming.directory.DirContextTag extends
org.apache.jakarta.taglib.naming.ContextTag
org.apache.jakarta.taglib.naming.directory.method.GetAttributes
org.apache.jakarta.taglib.naming.directory.method.ModifyAttributes
org.apache.jakarta.taglib.naming.directory.method.Search
...
org.apache.jakarta.taglib.ldap.LdapContextTag extends
org.apache.jakarta.taglib.naming.directory.DirContextTag
org.apache.jakarta.taglib.ldap.method.ExtendedOperation
org.apache.jakarta.taglib.ldap.method.GetRequestControls
...
I know the details of what will be implemented out of these would need
to be worked out, but the basic concept is that <jndi:ldap-context>
would instantiate/use a jndi context. and that the method tags in
directory and naming could act on that context as well (casted into one
of its ancestors.).
<!--good jsp page example (calling direcotry/ldap method tags on a
LdapContext) -->
<jndi:ldap-context ... />
<jndi:lookup..../>
<jndi:modify-attributes.../>
<jndi:extended-operation .../>
....
<!--bad jsp page example (calling direcotry/ldap method tags on a
Context) -->
<jndi:context ... />
<jndi:modify-attributes.../>
<jndi:extended-operation .../>
....
-My 2 Cents,
Mark
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Accepting new projects [was: LDAP taglib proposal]
Posted by Pierre Delisle <pi...@sun.com>.
Hi Glenn,
Good to hear from you!
...
> > 1. Motivation
> > 2. Comparative Analysis
...
> Issues 1 & 2 are important but we also don't want to raise
> the barrier to high. The documentation for what to submit
> to meet 1 & 2 should be general in nature. The vote is
> the final arbiter.
OK, makes sense. We'll simply offer guidelines to submitters
to help them come up with successful proposals.
> > 3. Vote
> Here is a sample ballot:
>
> [ ] +1 Add taglib to sandbox and I will help
> [ ] +0 Add taglib but I can't help
> [ ] -1 Don't add taglib, please explain why
>
> For the taglib to be added it woulr require a majority vote
> where there is at least 1 +1, and the combination of +1 and +0
> is greater than the -1's.
Sounds good. This accounts to a minor variation of
"majority approval" (described at
http://jakarta.apache.org/site/decisions.html) which makes
sense in our context.
> > 4. Design / Development
> I wouldn't get into much detail here. It might just be enough
> to state that the design, including that of each individual tag,
> has to be completed (but not fully implemented) before it
> can become an official jakarta taglib. This is open source,
> lets allow those working in the sandbox to self organize
> their development in ways that work best for them.
>
> I would like to strongly urge new taglibs in the sandbox to
> use as much of the standardized build system as they can.
> This is documented in addtaglib.html.
OK.
> > The project is hosted in the sandbox, and eventually moves
> > to the official repository once it is ready for prime time.
>
> Once the taglib is no longer experimental it can become official when
> the following three requirements are met:
>
> - It has well defined design goals for the tags
> - it is ready for its first milestone release
> - the jakarta-taglib committers conduct a vote where the majority approve
OK.
Thanks Glenn,
-- Pierre
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Accepting new projects [was: LDAP taglib proposal]
Posted by Pierre Delisle <pi...@sun.com>.
Hi Orhan,
> I agree with Glenn in some points. However, your proposal is acceptable
> for us. Here is my plan;
> - Me, Ayhan Alkan and Murat Go"rgu"ner are going to contribute to
> JNDI/LDAP taglib design and development. We'll be glad if Mike and Mark
> join us. This would be our team for the project.
> - We can prepare motivation, comparative analysis and high-level taglib
> design in 2-3 weeks.
Glad to see you guys are interested to contribute. However, I'd suggest,
as pointed out by Mark,
Mark wrote:
1.) As we all have interest in the design of the library as well as its
development, shouldn't this process be exposed to the community
(jakarata-taglib's) as well via jakarta-taglib developers list?
to keep the process fully open to the community.
Given the different views that seem to exist regarding this taglib,
I suggest you guys start open discussions on this list on the
very basic assumptions for that taglib. For example, should it be
LDAP, or JNDI? I'm sure lots of good input will come (some
has already been given and it would be good to have a summary
of it), and this will be critical to come up with the proper
motivation for the taglib.
-- Pierre
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Accepting new projects [was: LDAP taglib proposal]
Posted by orhan alkan <or...@sun.com>.
Hi Pierre,
I agree with Glenn in some points. However, your proposal is acceptable
for us. Here is my plan;
- Me, Ayhan Alkan and Murat Go"rgu"ner are going to contribute to
JNDI/LDAP taglib design and development. We'll be glad if Mike and Mark
join us. This would be our team for the project.
- We can prepare motivation, comparative analysis and high-level taglib
design in 2-3 weeks.
I'm looking for your comments.
Regards
Orhan Alkan
Glenn Nielsen wrote:
> Hi Pierre!
>
> My comments are intermixed below.
>
> Pierre Delisle wrote:
>
>> I have not received any comments on my proposal for opening up the
>> way we accept new proposals for
>> jakarta-taglibs.
>> I'd eventually like to call for a vote on that topic, but before I do
>> so, let me expand a little bit more on how I'd see it happen for two
>> cases we currently have pending:
>> the JNDI/LDAP taglib (Orhan, Mark, Mike), as well
>> as the PDF taglib (Roberto).
>>
>> Essentially, I think we could run the design/development of
>> these new taglibs a bit like the JSR-52 expert group has functioned
>> for the design/development of JSTL 1.0.
>>
>
> See my comments nested in step 4.
>
>> We have experts on specific topics that have the interest as well as
>> commitment to assume the responsibility to successfully design and
>> develop new libraries. What they need is a stimulating environment to
>> bring their project to fruition. jakarta-taglibs should be the right
>> place to do so if we have the proper process in place.
>>
>> So, leveraging the experience of the JSTL expert group, as well
>> as our current "new project submission" rules, how about something
>> like this:
>>
>> ---
>> 1. Motivation
>>
>> First of all, the motivation for a new project should be clear.
>> There is a multitude of topics that custom taglibs can address.
>> I don't think we should accept any project for which the value
>> proposition is not clear.
>>
>> So, if someone is interested in submitting a new project
>> to jakarta-taglibs, it should start with a document that
>> describes the motivation for the new taglib.
>>
>> This document clearly explains why this taglib is important/useful.
>> It tells what kind of problems it solves.
>> It provides as many concrete use cases as possible to support the
>> fact that this will be a good addition to
>> a page author's toolbox.
>>
>> For example:
>>
>> It would be very important to learn at this
>> stage why people want to do JNDI/LDAP in JSP and not in the
>> business logic. Orhan seems to already have many customers
>> for his taglib; it would be great to hear why they find
>> it so useful in their development environment. Same with
>> Mark and Mike.
>>
>> As for Roberto's PDF taglib, I must admit I know nothing
>> about FO, but would very much like to understand why
>> I should care, and why people would be interested in his taglib. How
>> do they do it right now without the taglib?
>> What benefit will they gain with the taglib?
>>
>> It is the responsibility of the submitter(s) to generate
>> interest for the taglib. Show to everyone that it is worth
>> for jakarta-taglibs to pay attention to your proposal.
>>
>> ---
>> 2. Comparative Analysis
>>
>> If applicable, a comparative analysis should accompany
>> the motivation document (or follow shortly afterwards).
>>
>> It should answer the following questions:
>>
>> - Other taglibs out there that do something similar?
>> - What are their strenghts/weaknesses
>> - Why should we have one at jakarta-taglibs?
>> - What will be the key design issues?
>>
>
> Issues 1 & 2 are important but we also don't want to raise
> the barrier to high. The documentation for what to submit
> to meet 1 & 2 should be general in nature. The vote is
> the final arbiter.
>
>> ---
>> 3. Vote
>> The intent of (1) and (2) is to make sure that a submitter
>> does his/her homework properly to motivate the need
>> for that new taglib. A vote should not be called
>> until that homework has been successfully completed.
>>
>> Details to be nailed down, but we probably need
>> binding votes where whoever votes +1 will be committed
>> in helping this project be successful (the submitter
>> will need help to get the project started in the
>> sandbox)
>>
>> Once the vote is positive, the project enters the sandbox,
>> and design discussions can start on the list.
>>
>
> Here is a sample ballot:
>
> [ ] +1 Add taglib to sandbox and I will help
> [ ] +0 Add taglib but I can't help
> [ ] -1 Don't add taglib, please explain why
>
> For the taglib to be added it woulr require a majority vote
> where there is at least 1 +1, and the combination of +1 and +0
> is greater than the -1's.
>
>> ---
>> 4. Design / Development
>>
>> A design document for the taglib is a requirement. I'd suggest using
>> the same format as the one used for the JSTL spec (e.g. see chapter 9
>> for the SQL actions).
>> [I believe that format is clear, provide enough
>> information to get someone up and running easily with the taglib, and
>> leaves
>> plenty of room for book/article authors to write more about them...]
>>
>> The process is iterative. First draft of spec; get comments,
>> adjust spec, more comments, some implementation; second
>> draft of the spec, more comments, more implementation, etc...
>>
>
> I wouldn't get into much detail here. It might just be enough
> to state that the design, including that of each individual tag,
> has to be completed (but not fully implemented) before it
> can become an official jakarta taglib. This is open source,
> lets allow those working in the sandbox to self organize
> their development in ways that work best for them.
>
> I would like to strongly urge new taglibs in the sandbox to
> use as much of the standardized build system as they can.
> This is documented in addtaglib.html.
>
>> The project is hosted in the sandbox, and eventually moves
>> to the official repository once it is ready for prime time.
>
>
> Once the taglib is no longer experimental it can become official when
> the following three requirements are met:
>
> - It has well defined design goals for the tags
> - it is ready for its first milestone release
> - the jakarta-taglib committers conduct a vote where the majority approve
>
>>
>> [And by doing a great job at designing the best possible taglig
>> for that specific topic, the taglib is eventually considered
>> within the Java Community Process for standardization :-)]
>>
>> ---
>> Call for Action
>>
>> Here are some things we need to do to help us move forward:
>>
>> - All: Is this the right direction?
>> We still need to refine the proposal made above, but how
>> does it sound in general? Is that the direction we should take to
>> be more flexible in handling new project submissions?
>> [the main difference with the current rules is that we would not
>> mandate a project to be fully cooked before being accepted;
>> we would simply require it to have clear motivation for its
>> importance, clear commitment from the submitters, and clear interest
>> from the community).
>>
>> - JNDI/LDAP
>>
>> Orhan, Mark, Mike: Would this process work for all of you interested
>> in a newly
>> designed JNDI/LDAP taglib? If yes, then I'd propose that you guys
>> decide among
>> yourself how to get the motivation/comparative analysis documents
>> ready for consideration by the list.
>>
>> - PDF
>>
>> Roberto: Same question to you. Would this process work for you?
>> If yes, then please get us clear motivation / comparative analysis
>> documents...
>>
>> Sorry for another long email...
>
>
> Thats ok. Things like this require it.
>
> Thanks Pierre!
>
> Glenn
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Accepting new projects [was: LDAP taglib proposal]
Posted by Glenn Nielsen <gl...@mail.more.net>.
Hi Pierre!
My comments are intermixed below.
Pierre Delisle wrote:
> I have not received any comments on my proposal for
> opening up the way we accept new proposals for
> jakarta-taglibs.
>
> I'd eventually like to call for a vote on that topic,
> but before I do so, let me expand a little bit more
> on how I'd see it happen for two cases we currently have pending:
> the JNDI/LDAP taglib (Orhan, Mark, Mike), as well
> as the PDF taglib (Roberto).
>
> Essentially, I think we could run the design/development of
> these new taglibs a bit like the JSR-52 expert group has functioned
> for the design/development of JSTL 1.0.
>
See my comments nested in step 4.
> We have experts on specific topics that have the interest as well as
> commitment to assume the responsibility to successfully design and
> develop new libraries. What they need is a stimulating environment to
> bring their project to fruition. jakarta-taglibs should be the right
> place to do so if we have the proper process in place.
>
> So, leveraging the experience of the JSTL expert group, as well
> as our current "new project submission" rules, how about something
> like this:
>
> ---
> 1. Motivation
>
> First of all, the motivation for a new project should be clear.
> There is a multitude of topics that custom taglibs can address.
> I don't think we should accept any project for which the value
> proposition is not clear.
>
> So, if someone is interested in submitting a new project
> to jakarta-taglibs, it should start with a document that
> describes the motivation for the new taglib.
>
> This document clearly explains why this taglib is important/useful.
> It tells what kind of problems it solves.
> It provides as many concrete use cases as possible
> to support the fact that this will be a good addition to
> a page author's toolbox.
>
> For example:
>
> It would be very important to learn at this
> stage why people want to do JNDI/LDAP in JSP and not in the
> business logic. Orhan seems to already have many customers
> for his taglib; it would be great to hear why they find
> it so useful in their development environment. Same with
> Mark and Mike.
>
> As for Roberto's PDF taglib, I must admit I know nothing
> about FO, but would very much like to understand why
> I should care, and why people would be interested in
> his taglib. How do they do it right now without the taglib?
> What benefit will they gain with the taglib?
>
> It is the responsibility of the submitter(s) to generate
> interest for the taglib. Show to everyone that it is worth
> for jakarta-taglibs to pay attention to your proposal.
>
> ---
> 2. Comparative Analysis
>
> If applicable, a comparative analysis should accompany
> the motivation document (or follow shortly afterwards).
>
> It should answer the following questions:
>
> - Other taglibs out there that do something similar?
> - What are their strenghts/weaknesses
> - Why should we have one at jakarta-taglibs?
> - What will be the key design issues?
>
Issues 1 & 2 are important but we also don't want to raise
the barrier to high. The documentation for what to submit
to meet 1 & 2 should be general in nature. The vote is
the final arbiter.
> ---
> 3. Vote
>
> The intent of (1) and (2) is to make sure that a submitter
> does his/her homework properly to motivate the need
> for that new taglib. A vote should not be called
> until that homework has been successfully completed.
>
> Details to be nailed down, but we probably need
> binding votes where whoever votes +1 will be committed
> in helping this project be successful (the submitter
> will need help to get the project started in the
> sandbox)
>
> Once the vote is positive, the project enters the sandbox,
> and design discussions can start on the list.
>
Here is a sample ballot:
[ ] +1 Add taglib to sandbox and I will help
[ ] +0 Add taglib but I can't help
[ ] -1 Don't add taglib, please explain why
For the taglib to be added it woulr require a majority vote
where there is at least 1 +1, and the combination of +1 and +0
is greater than the -1's.
> ---
> 4. Design / Development
>
> A design document for the taglib is a requirement.
> I'd suggest using the same format as the one used
> for the JSTL spec (e.g. see chapter 9 for the SQL actions).
> [I believe that format is clear, provide enough
> information to get someone up and running easily with the taglib, and leaves
> plenty of room for book/article authors to write more about them...]
>
> The process is iterative. First draft of spec; get comments,
> adjust spec, more comments, some implementation; second
> draft of the spec, more comments, more implementation, etc...
>
I wouldn't get into much detail here. It might just be enough
to state that the design, including that of each individual tag,
has to be completed (but not fully implemented) before it
can become an official jakarta taglib. This is open source,
lets allow those working in the sandbox to self organize
their development in ways that work best for them.
I would like to strongly urge new taglibs in the sandbox to
use as much of the standardized build system as they can.
This is documented in addtaglib.html.
> The project is hosted in the sandbox, and eventually moves
> to the official repository once it is ready for prime time.
Once the taglib is no longer experimental it can become official when
the following three requirements are met:
- It has well defined design goals for the tags
- it is ready for its first milestone release
- the jakarta-taglib committers conduct a vote where the majority approve
>
> [And by doing a great job at designing the best possible taglig
> for that specific topic, the taglib is eventually considered
> within the Java Community Process for standardization :-)]
>
> ---
> Call for Action
>
> Here are some things we need to do to help us move forward:
>
> - All: Is this the right direction?
>
> We still need to refine the proposal made above, but how
> does it sound in general? Is that the direction we should take to
> be more flexible in handling new project submissions?
> [the main difference with the current rules is that we would not
> mandate a project to be fully cooked before being accepted;
> we would simply require it to have clear motivation for its importance,
> clear commitment from the submitters, and clear interest from the community).
>
> - JNDI/LDAP
>
> Orhan, Mark, Mike: Would this process work for all of you interested in a newly
> designed JNDI/LDAP taglib? If yes, then I'd propose that you guys decide among
> yourself how to get the motivation/comparative analysis documents ready for
> consideration by the list.
>
> - PDF
>
> Roberto: Same question to you. Would this process work for you?
> If yes, then please get us clear motivation / comparative analysis
> documents...
>
> Sorry for another long email...
>
Thats ok. Things like this require it.
Thanks Pierre!
Glenn
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Accepting new projects [was: LDAP taglib proposal]
Posted by Pierre Delisle <pi...@sun.com>.
Thanks for the insight Craig.
More comments below...
> ...
> It is trivial (from a technical perspective) to allow commit privileges to
> the jakarta-taglibs-sandbox repository only, if that is appropriate.
>
> As for process, you might look at the jakarta-commons project for an
> example charter that includes the concept of the Commons Sandbox:
>
> http://jakarta.apache.org/commons/charter.html
>
> What it boils down to is that the Commons Sandbox was designed to support
> experimentation and proposals, primarily from existing Jakarta committers
> (on any existing Jakarta project). Therefore, the acceptance bar was set
> very low for such existing committers -- no permission at all is required
> to create a sandbox package, but a vote (by all commons-dev committers in
> that case) is needed to promote a package into Commons Proper. [NOTE -
> you'll need to send a note to TAGLIBS-DEV to get appropriate karma on the
> jakarta-taglibs-sandbox repository, but I can turn that around quickly]
>
> So what about non-Jakarta committers? In practice, this hasn't come up
> very often, but informally Commons has set the bar progressively higher,
> in the two most common scenarios:
>
> * One or more existing Jakarta committers want to start a
> sandbox package, along with one or more non-Jakarta committers.
>
> * One or more non-Jakarta committers want to start a sandbox package,
> but no existing Jakarta committers are involved.
>
> For Taglibs, the details of what you want to do are pretty much up to the
> community, but I'd suggest that the bar be pretty low in the first
> scenario (we want to encourage innovation and code sharing from existing
> Jakarta projects that might be generally useful) -- but the usual vote to
> accept a new committer would still be required.
We currently allow anyone who is a committer at
jakarta-tablibs to start a new project in the sandbox
(assuming a proper email for the new project submission is sent to the
list). It is therefore very easy in that case. Agree it should also be
made easy for your first scenario.
> For the second scenario, I would recommend that the bar be somewhat higher
> -- basically along the lines of the standards for accepting a new package
> directly into Jakarta (existing codebase, existing developer community, at
> least advice from an existing Jakarta committer to teach the rules of the
> road, and so on). Why? Because Jakarta is not SourceForge -- we care as
> much (or even more) about the community and the development style as we do
> about the code. Establishing a Jakarta sandbox project, simply for the
> purpose of *building* the development community, isn't really the right
> answer -- it's really better that the community exist already. It's also
> much better, IMHO, that you have the active participation of at least one
> existing Jakarta committer on any sandbox project (which effectively turns
> the second scenario into the first one).
>
> As I said, the details of how TAGLIBS-DEV wants to do this is pretty much
> up to your community (the PMC is more about making sure that code is
> licensed correctly, that committers are properly voted on, than they are
> about the details). But my recommendations are included in the above
> paragraphs.
Keypoint here is that a project should not be created to build
a community. Rather a community should already exist around the project
to ensure its success at jakarta.
Fair enough. Given Craig's achievements and many successes in the
Open Source community, I think this is probably the best path to follow.
Other opinions?
In the meantime, do we have enough of a community around the JNDI/LDAP
project to allow it to enter the sandbox? We've seen so far quite a few
people that voiced interest in working on that project. What seems to be missing
however is a committer willing to give it a +1...
Unless someone else wants to step up, I might be willing to cast that
+1... but I'd like some of my questions to be clearly answered.
More in my next email.
-- Pierre
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Accepting new projects [was: LDAP taglib proposal]
Posted by "Craig R. McClanahan" <cr...@apache.org>.
See below for a few comments on process and procedure.
On Wed, 2 Oct 2002, Pierre Delisle wrote:
> Date: Wed, 02 Oct 2002 13:11:39 -0700
> From: Pierre Delisle <pi...@sun.com>
> Reply-To: Tag Libraries Developers List <ta...@jakarta.apache.org>
> To: Tag Libraries Developers List <ta...@jakarta.apache.org>
> Subject: Re: Accepting new projects [was: LDAP taglib proposal]
>
> Hi Hen,
>
> > > Here are some things we need to do to help us move forward:
> > >
> > > - All: Is this the right direction?
> >
> > It slows things done a chunk, but as we're hardly a racing fast
> > environment it seems more important to try and keep things moving with
> > focus, which I think your suggestion will do.
>
> Exactly. In a subsequent email, Mark seemed to also be in agreement:
>
> Mark wrote
> > ...
> > there should be a definite passage through your development process
> > before files start showing up. We need to isolate that we all want to
> > see the same results from the project. (ie right now some want a LDAP
> > library while others want a JNDI library, while similar in architecture,
> > they encompass different scopes of application). Making sure that the
> > design fits cleanly at both scopes is important.
>
>
> > > We still need to refine the proposal made above, but how
> > > does it sound in general? Is that the direction we should take to
> > > be more flexible in handling new project submissions?
> > > [the main difference with the current rules is that we would not
> > > mandate a project to be fully cooked before being accepted;
> > > we would simply require it to have clear motivation for its importance,
> > > clear commitment from the submitters, and clear interest from the
> > > community).
> >
> > Definitely +1. Allowing taglis to grow in the sandbox cannot be a bad
> > thing.
>
> Great!
>
> > This does mean often handing out Jakarta committerness to people
> > for sandbox work, is this an issue with the PMC/Rules?
>
> Will check with our local PMC representative (Craig McClanahan)...
>
> > Maybe Jakarta need to define a 'sandbox-committer' type of person.
>
> Yes, or a variation could be that we have taglibs-sandbox commit
> privileges limited to our sandbox. Will see what Craig has to say
> about it.
>
> Thanks for commenting,
>
It is trivial (from a technical perspective) to allow commit privileges to
the jakarta-taglibs-sandbox repository only, if that is appropriate.
As for process, you might look at the jakarta-commons project for an
example charter that includes the concept of the Commons Sandbox:
http://jakarta.apache.org/commons/charter.html
What it boils down to is that the Commons Sandbox was designed to support
experimentation and proposals, primarily from existing Jakarta committers
(on any existing Jakarta project). Therefore, the acceptance bar was set
very low for such existing committers -- no permission at all is required
to create a sandbox package, but a vote (by all commons-dev committers in
that case) is needed to promote a package into Commons Proper. [NOTE -
you'll need to send a note to TAGLIBS-DEV to get appropriate karma on the
jakarta-taglibs-sandbox repository, but I can turn that around quickly]
So what about non-Jakarta committers? In practice, this hasn't come up
very often, but informally Commons has set the bar progressively higher,
in the two most common scenarios:
* One or more existing Jakarta committers want to start a
sandbox package, along with one or more non-Jakarta committers.
* One or more non-Jakarta committers want to start a sandbox package,
but no existing Jakarta committers are involved.
For Taglibs, the details of what you want to do are pretty much up to the
community, but I'd suggest that the bar be pretty low in the first
scenario (we want to encourage innovation and code sharing from existing
Jakarta projects that might be generally useful) -- but the usual vote to
accept a new committer would still be required.
For the second scenario, I would recommend that the bar be somewhat higher
-- basically along the lines of the standards for accepting a new package
directly into Jakarta (existing codebase, existing developer community, at
least advice from an existing Jakarta committer to teach the rules of the
road, and so on). Why? Because Jakarta is not SourceForge -- we care as
much (or even more) about the community and the development style as we do
about the code. Establishing a Jakarta sandbox project, simply for the
purpose of *building* the development community, isn't really the right
answer -- it's really better that the community exist already. It's also
much better, IMHO, that you have the active participation of at least one
existing Jakarta committer on any sandbox project (which effectively turns
the second scenario into the first one).
As I said, the details of how TAGLIBS-DEV wants to do this is pretty much
up to your community (the PMC is more about making sure that code is
licensed correctly, that committers are properly voted on, than they are
about the details). But my recommendations are included in the above
paragraphs.
> -- Pierre
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Accepting new projects [was: LDAP taglib proposal]
Posted by Pierre Delisle <pi...@sun.com>.
Hi Hen,
> > Here are some things we need to do to help us move forward:
> >
> > - All: Is this the right direction?
>
> It slows things done a chunk, but as we're hardly a racing fast
> environment it seems more important to try and keep things moving with
> focus, which I think your suggestion will do.
Exactly. In a subsequent email, Mark seemed to also be in agreement:
Mark wrote
> ...
> there should be a definite passage through your development process
> before files start showing up. We need to isolate that we all want to
> see the same results from the project. (ie right now some want a LDAP
> library while others want a JNDI library, while similar in architecture,
> they encompass different scopes of application). Making sure that the
> design fits cleanly at both scopes is important.
> > We still need to refine the proposal made above, but how
> > does it sound in general? Is that the direction we should take to
> > be more flexible in handling new project submissions?
> > [the main difference with the current rules is that we would not
> > mandate a project to be fully cooked before being accepted;
> > we would simply require it to have clear motivation for its importance,
> > clear commitment from the submitters, and clear interest from the
> > community).
>
> Definitely +1. Allowing taglis to grow in the sandbox cannot be a bad
> thing.
Great!
> This does mean often handing out Jakarta committerness to people
> for sandbox work, is this an issue with the PMC/Rules?
Will check with our local PMC representative (Craig McClanahan)...
> Maybe Jakarta need to define a 'sandbox-committer' type of person.
Yes, or a variation could be that we have taglibs-sandbox commit
privileges limited to our sandbox. Will see what Craig has to say
about it.
Thanks for commenting,
-- Pierre
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Accepting new projects [was: LDAP taglib proposal]
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 27 Sep 2002, Pierre Delisle wrote:
> I have not received any comments on my proposal for
> opening up the way we accept new proposals for
> jakarta-taglibs.
Sorry.
> ---
> Call for Action
>
> Here are some things we need to do to help us move forward:
>
> - All: Is this the right direction?
It slows things done a chunk, but as we're hardly a racing fast
environment it seems more important to try and keep things moving with
focus, which I think your suggestion will do.
> We still need to refine the proposal made above, but how
> does it sound in general? Is that the direction we should take to
> be more flexible in handling new project submissions?
> [the main difference with the current rules is that we would not
> mandate a project to be fully cooked before being accepted;
> we would simply require it to have clear motivation for its importance,
> clear commitment from the submitters, and clear interest from the
> community).
Definitely +1. Allowing taglis to grow in the sandbox cannot be a bad
thing. This does mean often handing out Jakarta committerness to people
for sandbox work, is this an issue with the PMC/Rules?
Maybe Jakarta need to define a 'sandbox-committer' type of person.
> - PDF
>
> Roberto: Same question to you. Would this process work for you?
> If yes, then please get us clear motivation / comparative analysis
> documents...
Will repeat this if I see more about the PDF one. Like, why not a taglib
for JasperReports [typo?] instead of FOP....
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>