Re: new Standard/JSTL subproject? [WAS Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin]

2005-07-05 Thread Felipe Leme



Henri Yandell wrote:

are there any committers involved with JSTL around?


Sorry, I raised the question then entered in JavaOne-sleep-mode :(


if not, would anyone like to volunteer to sound them out about a move to
subproject status?


I vote for Standard being a separate Jakarta sub-project.


I've mentioned the idea on the taglibs-dev mailing list, no reply as yet.


There hasn't being too many messages by the committers lately, specially 
on votes. So, tomorrow (I'm too tired now :-) I will send a big message 
summarizing all of these pending votes and hopefully we will get enough 
committer answers now...


-- Felipe





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



new Standard/JSTL subproject? [WAS Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin]

2005-06-26 Thread robert burrell donkin
On Thu, 2005-06-23 at 20:14 -0400, Henri Yandell wrote:
 On Thu, 23 Jun 2005, robert burrell donkin wrote:
 
  On Thu, 2005-06-23 at 00:49 -0300, Felipe Leme wrote:
  Apache Wiki wrote:
 
  Please do not edit comments into this text: please use the 
  CharterForWebCommonsRequestForComments
   or post to  [http://jakarta.apache.org/site/mail.html General At
  Jakarta].
 
  OK, here I am posting :-)
 
  3.What about the Standard Taglibs? Should it be part of this new project
  or should it be a separate project. The reasoning here is that, because
  that sub-project provide the codebase for JSTL's implementation (and
  maybe other JSR taglibs in the future as well, such as the Web Services
  taglib), its development activities/cycles might be different from the
  non-standard ones (we could even try to apply the TCK on such projects
  in the future, for instance).
 
  if the new subproject is anything like the commons then each component
  will have it's own development rhythm.
 
  it might be easier to raise extra hands when needed for these efforts if
  these share the same infrastructure (mailing lists, subproject
  organization and so on).
 
  opinions?
 
 My vote is for the active Taglibs to roll into the web component 
 subproject, but for the Standard/JSTL taglib to move to Jakarta subproject 
 status.
 
 Taglibs-user is dominated by JSTL questions and the JSTL committers don't 
 have any obvious overlap with the other taglib committers (that I've 
 noticed). Also in terms of codebase, Standard is the relative behemoth.
 
 Lastly it has a much higher profile than other parts of 
 web-component-subproject will have and as a spec implementation it has a 
 different set of issues to deal with.

+1

are there any committers involved with JSTL around?

if not, would anyone like to volunteer to sound them out about a move to
subproject status? 

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: new Standard/JSTL subproject? [WAS Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin]

2005-06-26 Thread Henri Yandell
On 6/26/05, robert burrell donkin [EMAIL PROTECTED] wrote:
 
 are there any committers involved with JSTL around?
 
 if not, would anyone like to volunteer to sound them out about a move to
 subproject status?

I've mentioned the idea on the taglibs-dev mailing list, no reply as yet.

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin

2005-06-23 Thread robert burrell donkin
On Thu, 2005-06-23 at 00:49 -0300, Felipe Leme wrote:
 Apache Wiki wrote:
  
  Please do not edit comments into this text: please use the 
  CharterForWebCommonsRequestForComments 
   or post to  [http://jakarta.apache.org/site/mail.html General At 
 Jakarta].
 
 OK, here I am posting :-)
 
 I'd like to suggest 2 things:
 
 1.We prefereably use Maven for the builds, as it helps a lot handling 
 the dependencies (if we stick to Ant, we should at least use Ivy or M2 
 Ant stuff for dependency management). For instance, I haven't applied 
 some patches to the Jakarta Taglibs because my computers are not set for 
 building them anymore (and I don't have the time/patience to fix it).

jakarta commons is agnostic (but uses maven for the website). i'd
recommend official agnosticism with unofficial encouragement to maven.
it is a good idea to provide ant scripts generated by maven in SVN. 

 2.Regarding the Jakarta Taglibs, we should create the new taglibs from 
 scratch. I mean, of course we should reuse the code, but we better do 
 some refactoring first (for instance, eliminating redundant taglibs, 
 defining a role for TLD names, etc...) - the current Jakarta Taglibs 
 would then be frozen in time.

IMHO it would probably be more convenient to maintain these frozen
taglibs (from an official perspective) within the new subproject. with
subversion, it's really nice and easy to have cool directory
structures...

 3.What about the Standard Taglibs? Should it be part of this new project 
 or should it be a separate project. The reasoning here is that, because 
 that sub-project provide the codebase for JSTL's implementation (and 
 maybe other JSR taglibs in the future as well, such as the Web Services 
 taglib), its development activities/cycles might be different from the 
 non-standard ones (we could even try to apply the TCK on such projects 
 in the future, for instance).

if the new subproject is anything like the commons then each component
will have it's own development rhythm.

it might be easier to raise extra hands when needed for these efforts if
these share the same infrastructure (mailing lists, subproject
organization and so on). 

opinions?

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin

2005-06-23 Thread robert burrell donkin
On Thu, 2005-06-23 at 00:52 -0300, Felipe Leme wrote:
 Felipe Leme wrote:
  
  I'd like to suggest 2 things:
  ...
  3
 
 Damn, beaten by the ENTER key again :-(

shades of monty python's flying circus ;)

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin

2005-06-23 Thread Frank W. Zammetti

robert burrell donkin wrote:

if the new subproject is anything like the commons then each component
will have it's own development rhythm.


I think this is a cogent point... if the idea is that this is like a 
Commons project, than I have to ask the question: why not just have a 
few new Commons projects, as was my original proposal?


I originally started by suggesting a Commons Filters, because I had some 
filters I wanted to contribute.  So far I think we've brainstormed 
something like 4-6 sort of sub-packages of this... If they are going 
to develop to their own rhythm as you say, then why not make each a 
Commons project, where there already largely is the infrastructure (in 
the larger sense) build up?  That would seem to me the path of least (or 
at least lower) resistance, and maybe even a more appropriate fit.


It's a question of what the vision is of course... if everyone is 
thinking along the commons lines anyway, why not just do it in Commons?


Frank


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin

2005-06-23 Thread Simon Kitching
On Thu, 2005-06-23 at 17:55 -0400, Frank W. Zammetti wrote:
 robert burrell donkin wrote:
  if the new subproject is anything like the commons then each component
  will have it's own development rhythm.
 
 I think this is a cogent point... if the idea is that this is like a 
 Commons project, than I have to ask the question: why not just have a 
 few new Commons projects, as was my original proposal?

The relevant questions are:
 * what percentage of the existing commons developers are
   interested in working on web components
 * what percentage of the prospective web developers are
   interested in participating in other commons projects
 * what percentage of users and interested in both web and
   normal commons projects.

If the answer to any of these is high then the benefits of a combined
community outweigh the nuisance of excessive emails, overly-large
subproject lists and general distraction.

I would guess the critical threshold to be about 25% - but I don't think
that will be reached, ie I believe that less than 25% of existing
commons committers would be interested in web commons components of the
sort proposed. Therefore having such components in the existing commons
will just annoy people without having any significant benefits (other
than allowing this startup hassle for web commons to be skipped).

Already we have people (both developers and users) agitating for
separate per-component mail lists due to the volume of emails in
commons. Some people have stated that they refuse to subscribe or be
part of the community while there is a shared list. I would hate to see
separate lists, but they have a point - there is an upper limit to the
amount of mail people can handle (esp. people on dial-up connections;
filtering by mail subject doesn't reduce the bandwidth needed to
download all the mails).

There is also the issue of community size. Commons has a couple of dozen
regular committers, which means we all recognise each other's names.
That's quite important I think, and brings some sense of team
membership. Diluting this with another dozen developers (I hope web
commons will grow to that size!) may change that sense of community
(esp. if we don't have many interests in common). And likewise for new
web commons committers - I think the sense of a team will be stronger
with a separate project/mail-list etc.

I admit it's all guesswork and a little crystal-ball-gazing. If
web-commons is a failure, ie only a couple of projects get off the
ground, then the existing commons would be a better home. But I hope
that's not the case - there does seem to be a reasonable number of ideas
and people willing to push them forward.

Regards,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin

2005-06-23 Thread Henri Yandell


On Thu, 23 Jun 2005, robert burrell donkin wrote:


On Thu, 2005-06-23 at 00:49 -0300, Felipe Leme wrote:

Apache Wiki wrote:


Please do not edit comments into this text: please use the 
CharterForWebCommonsRequestForComments

 or post to  [http://jakarta.apache.org/site/mail.html General At
Jakarta].

OK, here I am posting :-)

3.What about the Standard Taglibs? Should it be part of this new project
or should it be a separate project. The reasoning here is that, because
that sub-project provide the codebase for JSTL's implementation (and
maybe other JSR taglibs in the future as well, such as the Web Services
taglib), its development activities/cycles might be different from the
non-standard ones (we could even try to apply the TCK on such projects
in the future, for instance).


if the new subproject is anything like the commons then each component
will have it's own development rhythm.

it might be easier to raise extra hands when needed for these efforts if
these share the same infrastructure (mailing lists, subproject
organization and so on).

opinions?


My vote is for the active Taglibs to roll into the web component 
subproject, but for the Standard/JSTL taglib to move to Jakarta subproject 
status.


Taglibs-user is dominated by JSTL questions and the JSTL committers don't 
have any obvious overlap with the other taglib committers (that I've 
noticed). Also in terms of codebase, Standard is the relative behemoth.


Lastly it has a much higher profile than other parts of 
web-component-subproject will have and as a spec implementation it has a 
different set of issues to deal with.


Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin

2005-06-22 Thread Felipe Leme

Apache Wiki wrote:


Please do not edit comments into this text: please use the CharterForWebCommonsRequestForComments 
 or post to  [http://jakarta.apache.org/site/mail.html General At 
Jakarta].


OK, here I am posting :-)

I'd like to suggest 2 things:

1.We prefereably use Maven for the builds, as it helps a lot handling 
the dependencies (if we stick to Ant, we should at least use Ivy or M2 
Ant stuff for dependency management). For instance, I haven't applied 
some patches to the Jakarta Taglibs because my computers are not set for 
building them anymore (and I don't have the time/patience to fix it).


2.Regarding the Jakarta Taglibs, we should create the new taglibs from 
scratch. I mean, of course we should reuse the code, but we better do 
some refactoring first (for instance, eliminating redundant taglibs, 
defining a role for TLD names, etc...) - the current Jakarta Taglibs 
would then be frozen in time.


3.What about the Standard Taglibs? Should it be part of this new project 
or should it be a separate project. The reasoning here is that, because 
that sub-project provide the codebase for JSTL's implementation (and 
maybe other JSR taglibs in the future as well, such as the Web Services 
taglib), its development activities/cycles might be different from the 
non-standard ones (we could even try to apply the TCK on such projects 
in the future, for instance).



-- Felipe

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin

2005-06-22 Thread Felipe Leme

Felipe Leme wrote:


I'd like to suggest 2 things:
...
3


Damn, beaten by the ENTER key again :-(

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]