jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From orhan alkan <orhan.al...@sun.com>
Subject Re: Accepting new projects [was: LDAP taglib proposal]
Date Mon, 30 Sep 2002 09:11:31 GMT
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.
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).
>> 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: 
> <mailto:taglibs-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:taglibs-dev-help@jakarta.apache.org>

To unsubscribe, e-mail:   <mailto:taglibs-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:taglibs-dev-help@jakarta.apache.org>

View raw message