Re: [VOTE] Merge dev lists

[Stephen Colebourne]

Rahul Akolkar wrote:

This is a vote to consolidate the development lists at Jakarta into
one development and one notifications list. For background including
timing, anticipated benefits and some discussion, see proposal [1]
thread.


+1
Subject to encouraging a Commons style prefixing system for emails, eg 
[jmeter] or [oro].


Stephen


-
To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
For additional commands, e-mail: general-h...@jakarta.apache.org

Re: What about HttpClient?

[Stephen Colebourne]

Oleg Kalnichevski wrote:
The question is really whether the Commons TLP owns the HttpClient 
codebase.

Based on the project's charter approved by the Jakarta PMC on Oct 31st,
2005 the HttpComponents project is meant to have the ownership of the
Commons HttpClient codebase

Thats great! Thanks for the link.



My preference is to not not move stuff around (option 1).


But option 1 does move stuff around. It moves it to commons.apache.org 
which is misleading to both the commons and jakarta groups. And is why I 
suggested option 3, where HttpClient retains the same URL as now.


Stephen

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

Re: What about HttpClient?

[Stephen Colebourne]

Roland Weber wrote:

1. Keep the httpclient site with the rest of commons
and move it to the new TLP domain. We'll have to update
the httpclient build with the new location and redeploy.
(Anything I've forgotten?)

2. Move the httpclient site to httpcomponents. Since
httpcomponents is unlikely to remain in Jakarta
indefinitely, that means the site would move again
later this year. Two moves within a few months is a
bit too disruptive to users for my liking.

3. Keep the httpclient site at it's current location
in Jakarta when the rest of the commons site moves.
Move it only once to httpcomponents when those leave
Jakarta.


The question is really whether the Commons TLP owns the HttpClient 
codebase. I don't believe its terribly sensible for it to do so. All 
active committers and knowledge are focussed in the HttpComonents group.


Thus I would suggest #3 as the best option, followed by #2.

Stephen

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

Re: [VOTE] Commons moving to TLP

[Stephen Colebourne]

- Original Message 
From: Dion Gillard <[EMAIL PROTECTED]>
> Using CLI as an example, I'm not sure that there is a shared sense of
> responsibility for it.
> 
> CLI 1.x has had an issue open against it since 2006-03 with only
> recent activity on it, and Henri's comment in that issue from 2007-03
> ("CLI is still pretty much a dead commons component. No one's actively
> working on it.")  is damning evidence.

IMO Henri was being a little harsh here, as I don't think we always distinguish 
between the stability of code and the activity of the community.

I do feel, and this is the important point, that if a commons committer chose 
to work on CLI, and want to release it then they would get support for doing 
the release (we're not perfect, but we're pretty good at making up the quorum 
and doing the quality checking). Would it be as easy to get Jakarta PMC members 
to step up for a JMeter release?

Stephen





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

Re: [VOTE] Commons moving to TLP

[Stephen Colebourne]

- Original Message 
From: sebb <[EMAIL PROTECTED]>
> Do all the Commons sub-projects have sufficient numbers ot committers
> to justify them remaining in Commons? For example CLI has not even had
> a formal release yet and has been far less active than JMeter, but is
> still protected by being in Commons.

Commons components are not the equivalent of Jakarta sub-projects.

That is a key factor as to why commons can continue to function, when Jakarta 
has died.

The difference is that everyone is responsible for everything in Commons, 
whereas in Jakarta people only take responsibility for their own area. Now, 
thats not to say that every Commons developer cares equally about every Commons 
component, but there is a strong sense of shared responsibility. Anyone can 
review/support/oppose a commit/idea/release.

Thus, your original question re CLI doesn't really apply in the same way.

Stephen





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

Re: [VOTE] Commons moving to TLP

[Stephen Colebourne]

This seems a little overplanned in my mind ;) Allow a little more evolution.

- Commons goes TLP.
- Rules for Commons TLP become clear (one mailing list, one PMC, anyone commits 
in any component, anyone votes/reviews any release, comfortable social group)
- Then invite communities from Jakarta to join if they wish (once the rules and 
expectations are clear)

Simple. And community-up not top-down.

Stephen

- Original Message 
From: Henri Yandell <[EMAIL PROTECTED]>
To: Jakarta General List 
Sent: Wednesday, 23 May, 2007 6:00:05 AM
Subject: Re: [VOTE] Commons moving to TLP

On 5/22/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
>
> Quick summary of this thread 28 Votes for (23 binding), 4 against (3
> binding). Seems to me that those objecting don't seem to have
> pursuaded people to change their vote. At what point do we decide on a
> result?

I think you just did :) Definitely a consensus in favour of the resolution.

The negative opinions in the thread then started moving in the
direction of other ideas. My preference is for a single-community
Jakarta, I think the time has come to finish the job - however if that
looks like it's never going to come then I think the best thing is for
Commons to go TLP.

Here's what I think could happen:

If willing, ECS, ORO, Regexp moving into Commons. Probably move ECS
into maintenance immediatley but that's a different story. Both dev
and user mailing lists to merge in.

I think JCS, BCEL and BSF should also all move into Commons if
willing; with the intention of moving them to TLP if they grow. I
think BSF is a good TLP on paper, but some more time 'incubating' will
be valuable and that'll be better in the relatively small move to
Jakarta-Commons. Dev lists should merge in, user lists could stay
outside I think (assuming some level of activity currently).

Taglibs is currently discussing a good chunk of internal clean-up.
We'll retire most of the taglibs and focus on three. Much like BSF, I
think the future for Taglibs could easily be folding into Commons or
going TLP if it more activity. Again, fold dev into commons, keep user
separate. The devs there already have high overlap with Commons.

--- up til this point was the easy bit :)

Http Components is much the same as Taglibs/BSF, but less overlap and
less interested in returning to Commons. I think it would do well to
follow the same course (merge dev list, different user list, keeping
an eye on TLP in the future if growth).

* Slide. There's some sign of activity here. Not enough yet.

* Cactus. Tiny bit of activity, again not enough for a TLP.

* JMeter. Lots of commits from Sebb, but not a big community.

For all three of these the best solution I can think of is to move
them to the Incubator. Keep the lists where they are, move the svn,
move the websites. They need to be thinking TLP, they need to get
community.

--

If that, or something like it, sounds like a good consensus plan, then
I'm definitely more in favour of that than Commons going to TLP. There
are really only four steps:

Step 0: Consensus.
Step 1: Move 3 projects to the Incubator.
Step 2: Move other projects into Commons.
Step 3: Re-establish Jakarta PMC - we'd use pretty much the same
resolution we just voted on here.

So the question is; is the above direction worth discussing, or should
we just go with the Commons TLP.

Hen

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





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

Re: [PROPOSAL] The future of Jakarta

[Stephen Colebourne]

- Original Message 
From: Ted Husted <[EMAIL PROTECTED]>
> On 5/22/07, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> > In summary:
> > a) I believe the status quo is not viable
> > b) I believe that merging commons into Jakarta merges two mismatched groups
> 
> My suggestion was to merge the Jakarta subprojects into the Commons,
> not the other way around.

Yes, Jakarta subprojects should be invited to join Commons. I'll happily 
welcome them to the Commons fold.

But *invited* is the key word. They must not be forced - isn't the ASF about 
'community'? For me that means not pushing groups to go where they don't want 
to go.

> * The remaining subprojects all seem to be "reusable components"
> within the scope of the Commons charter.

Mostly, but that doesn't mean that they don't have their own communities (even 
a community of one). They mustn't be forced to do anything. Encouraged perhaps, 
not forced.

> * If the remaining subprojects join the Jakarta Commons, then we could
> then ask the board to re-establish the Jakarta PMC, using the list
> suggested in the draft resolution as the initial PMC.
> 
> * The extended Commons group then becomes the new Jakarta PMC.

This seems complicated, political, and unecessary. We have a vibrant community 
in Commons, and for some half-arsed reason we seem to be trying to abuse it's 
strength to save long-dead Jakarta.

I know some people here have long attachments to 'Jakarta', and the perceived 
'brand'. I don't. (At one time I did want to save Jakarta, but then I saw how 
much of a disfunctional beast it had become). Jakarta is like a family, where 
the children have left home and have their own lives now.

Commons has its own life too. Its own community. And that's independent of 
Jakarta. There is no need to have a Jakarta PMC overseeing Commons. In fact, I 
object to the fact the it seems to be so difficult to escape Jakarta.

To those trying to preserve Jakarta I say 'let go of Commons'. Don't abuse 
Commons to try and save Jakarta. If the Jakarta name is worth saving, people 
and community will form to save it. If not, then it will die. Thats normal and 
natural.

> In the alternative, without an anchor subproject, or a ready
> initiative to promote Java at Apache, realistically, Jakarta whithers away.

I'd encourage people to step back for a moment and look at what Jakarta 
actually is today. Its a very disparate group of voices pulling in different 
directions. This is a natural result of the true meaning of Jakarta - the 
community around the code - leaving. There is no longer any focus within 
Jakarta. Nor has there been for a *very* long time.

Whatever Jakarta becomes once Commons leaves is up to Jakarta, and those who 
feel it should exist. Just don't abuse Commons to try and save Jakarta.

Stephen





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

Re: [PROPOSAL] The future of Jakarta

[Stephen Colebourne]

- Original Message 
From: Ted Husted <[EMAIL PROTECTED]>
On 5/22/07, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> > PS:  Yes, of course, there are passionate believers in the development
> > of particular libraries.  Are there enough to make a viable community
> > for *any* of the libraries on their own?  Or enough that care about
> > the Commons ecosystem as a whole to satisfy Apache's notions of
> > "community"?  It is not clear to me (any longer) that a "commons" type
> > environment fits Apache culture (as it is currently being discussed)
> > at all.
> 
> You're right, it probably doesn't. Towards that end, we should encourage
> Commons components with robust communities to apply for top-level
> status, so that they can report directly to the Board and have their
> own mailing lists. The "one list" rule is a great equalizer and should
> help keep the Commons from becoming another Jakarta.

Huh? Commons has one mailing list. Each of its components are not isolated 
islands suitable for TLP, but part of the shared commons identity. They are not 
Jakarta style subprojects.

Note that there are cliques within commons, some people care about one set of 
components, other people care about another set of components. Thats OK. We can 
all commit, we can all vote, we can all comment on the mailing list.

This approach of commons is different to the rest of the ASF, but it does work 
(and is probably the only way to support small codebases within the ASF. I also 
believe it is sufficiently different to how the other projects in Jakarta have 
been run to make merging not necessarily smooth.

In summary:
a) I believe the status quo is not viable
b) I believe that merging commons into Jakarta merges two mismatched groups
c) I believe that commons is big enough and strong enough to be a TLP

So, I support Apache Commons TLP - Just as Tomcat grew up and left the Jakarta 
brand name, so should Commons. But we should assert our right for that to be 
Java only - we really did get the name first, and the commons community 
(one-list, one-pmc) is fundamentally tied to Java. 

Stephen





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

Re: [VOTE] Commons moving to TLP

[Stephen Colebourne]

Travelling ATM, limited internet

My preference is for a java-only commons.apache.org. I don't see that as scary 
or unreasonable. My +1 is based on that assumption.

Also, from a practical matter, our projects already use org.apache.commons, so 
this is already recognised in the ASF.

Stephen


From: Martin van den Bemt <[EMAIL PROTECTED]>

If moving commons TLP is just a "twisted" (maybe a bad choice of a word) way to 
come back to
jakarta.apache.org in the end, I am -1 on the TLP move..

We currently have 2 projects moving TLP (Turbine and POI) and after that we 
need to start thinking
about every other project at Jakarta.

So if the goals is to make commons Jakarta, we should aim for that, instead of 
artificially trying
to accomplish that.

If I am not mistaken the real goals/questions are :

- Fix oversight issues
- Be more transparent for the board
- Move towards a community with the same focus (= eg reusable java components)
- Be able to say in one sentence what Jakarta is about (is consequence of above)
- See where we can fit project that are in maintenance mode or not actively 
supported anymore.
- How to handle projects that don't fit well within the new focus, but work 
pretty well as part of
Jakarta (are people waiting for being on eg 15 PMC's to be able to support 
these projects)
- And Apache wide : is there only a place for projects that have a "healthy" 
community ?

Mvgr,
Martin

Danny Angus wrote:
> On 5/14/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
>> As my random suggestion that Ted quoted points out, you can have a PMC
>> without their having to be TLP. Least I was told that a couple of
>> years ago either on board@ or face to face, so we could do the
>> following:
>>
>> * Create the Jakarta Commons PMC, without changing the website (or
>> even the svn maybe).
>> * Continue to encourage Jakarta subprojects to move to TLP, go into
>> maintenance or move over to other PMCs.
>> * Reach a point at which we can end the Jakarta PMC, or federate or
>> whatever.
> 
> Do you mean that the resources can then be handed over to the
> Jakarta-commons (or whatever) PMC?
> I'm in favour of that idea, jakarta==jakarta-commons is the option
> which I think makes most sense of all for the future of Jakarta.
> 
> 1/ it preserves a valuable brand
> 2/ commons embodies the original ethos of Jakarta
> 3/ commons (as we've seen hints of) still actively depends (c.f
> passively benefiting) upon the Jakarta brand.
> 
> To close down the project and hand the "brand" to another PMC would
> also meet all but the most draconian interpretation of what the reorg@
> discussions suggested needed to be done about the problem of Jakarta.
> 
> d.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

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

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

Re: [VOTE] Commons moving to TLP

[Stephen Colebourne]

[X] +1 I support the proposal
[ ] +0 I don't care
[ ] -1  I'm opposed to the proposal because...

Stephen




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

Re: POI TLP -- constructively

[Stephen Colebourne]

Thank you Andy for the detailed and constructive response. I didn't and 
won't participate in the previous thread because there were too many 
negatives there.


I like the proposals below, so long as the X months is not too large. I 
believe a 3-4 months target is appropriate for a POI TLP.


That said, Jakarta (and its Chair in particular) is still responsible 
for POI in the intermediate time. Legally, we have to monitor your 
releases (as I understand it). I just want that to be 'light touch' 
until a TLP is possible.


And can we please go to sleep for Christmas now!

Stephen


Andrew C. Oliver wrote:
I really liked hearing Avik speak up because he's been hurting for 
awhile and not spoken up.  It was Nick's first release, cut him some 
slack.  POI has been around since 2001, in Apache since 2002.  It is 
nearly 2007.  Talks of mentoring us or incubating us are a little 
patronizing and insulting (multiple of us our even members of the 
foundation though I forget who).  Much of the thread is about bashing us 
and bashing me in particular which I stupidly reacted to partly out of 
fatigue.  I appologize for that, I've been very busy launching 
http://buni.org and planning our corporate structure.


It is fair to say that not many POI people participate in Jakarta.  
However, to add perspective we never joined the "Jakarta as it is" -- we 
joined Jakarta as it was...and one day this formed around us.  It is 
fair to criticize our build...it is pretty rusty and yucky.  I do 
however thing focusing too much on it is a bit well...mean.  Nick has 
been doing a great job and a lot of work.  (I on the other hand will 
have to merge my patches into SVN before I can even commit them since 
they're off of CVS :-P ).  However it was his first release.  Moreover, 
Apache's "release policies" have evolved considerably since the last 
official release and none of us have a valid signed key...that needs to 
be rectified (laziness, don't like conventions where all the cool key 
signing parties).  We're not the only one's guilty of kinds of neglect.  
Our own Marc Johnson (who cofounded the project) has been extremely 
frustrated at the lack of responsiveness in getting his access/etc in 
order and no one at POI seems to be able to jerk the right chain in 
Apache to make that happen (and I think he requested from this PMC with 
no effect).  So much that he's given up!


In any case, legal issues aside (which have to a good degree abated, but 
take yourself back 5 years) I really don't want POI to really merge into 
Jakarta (which is really now the successor to Jakarta Commons) and I 
don't think the majority of the committers do either.  On the other 
hand, I really don't think POI by itself can be a TLP as its scope is 
too narrow (historically this was deliberate).  I also don't think that 
parts of POI have much of a future as we're moving to an XML formats 
era, but other parts certainly do.  Partly because of projects like POI, 
Microsoft is even moving.  Once the default is to save in an XML format 
then will anyone really care about POI "as it is" as more than a 
migration tool.


That being said, there is considerable interest in unified APIs for each 
of these verticals (spreadsheets, documents, etc) and considerable life 
in POI with a very active userbase.  Many people dealing with data 
formats have asked for common APIs for the various verticals that output 
to the various formats.  Moreover, many of us are no longer as single 
minded with regards to Java as we once were (POI ruby for example).  And 
achieving API compatibility across these could be interesting.


I therefore propose this:

* Jakarta PMC has the responsibility to not call more votes on 
restructuring POI during the next X months.  (Access or otherwise)


* POI committers have responsibility for achieving the proper oversight 
procedures and putting out a new release in the next X months


* POI committers have responsibility for putting together a TLP proposal 
and working out a consensus.


(BTW that pretty much is batting 1000 on this: 
http://wiki.apache.org/jakarta/JakartaPMCRequestTLPBenchmark)


Full disclosure:

I've also submitted a counter proposal to the committers as an 
alternative to leave apache entirely.  However thus far most folks seem 
to value POIs association with Apache and the opportunities afforded 
them, even if they find it "difficult to work with" as one person stated 
in response.  I suspect TLP status would alleviate some of the mutual 
snags between apache and POI (for one we could get poor Marc his access 
back despite him having sent in his CLA now like 3 times including when 
the project moved to Apache and for two we'd be sending our reports in 
ourselves and thus have to do more proper oversight).
However, PLLEEAASS let's press the PAUSE button 
until January 3rd so that we can all get very drunk and open presents 
rather than jerk each other's chains in front of a computer on a mai

Re: Tracking Jakarta Software Dependencies

[Stephen Colebourne]

Daniel F. Savarese wrote:

In message <[EMAIL PROTECTED]>, =?ISO-8859-1?Q?Ortwin_Gl=FCck?= writes:


JDK version: what a mess. IMHO this is THE information that is missing
on almost ANY project page out there.


I think everyone's responses have brought this topic to closure.
Library dependencies are already available from most subprojects, but
JDK requirements aren't obvious.  Conclusion: let's try to make the JDK
requirements for our projects more obvious for Jakarta users.


Perhaps, this could be achieved by enhancing maven to allow the minimum 
JDK level to be specified in the POM, and thus on the dependencies page?


Stephen

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

Re: Opening up the PMC

[Stephen Colebourne]

Henri Yandell wrote:

What do people think to the following:

1) Every existing committer not on the pmc receives an email asking if 
they would like to join the pmc. Once that email is sent they are marked 
in a file as having had the email sent and we can wash our hands until a 
reply comes in.


2) Every new committer automatically gets added to the pmc.


-1
Becoming a committer is an essential first step. It allows everyone, 
committer included, to figure out if the committer is really able to 
spend the time and energy on the project they thought they would.


What is needed is an easier way of judging who should be PMC and isn't. 
Something like a monthly script of non-pmc committers and their number 
of commits and mail messages.


Stephen

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

Re: svn commit: r406115 - /jakarta/site/docs/style/jakarta-maven.css

[Stephen Colebourne]

Rahul Akolkar wrote:

On 5/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


Author: scolebourne
Fix IE menu problem




Thanks for looking into this!


Yeh, it was an IE bug where one background colour messed up another. I 
used the old trick of removing everything and then gradually adding 
stuff back in again to find it ;-)


Stephen

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

Re: [VOTE] Move Jakarta Cactus/JMeter to new Testing TLP

[Stephen Colebourne]

[ ] +1 I am favorable to the move and would like to contribute to the new TLP
[X] +1 I am favorable to the move but would not be participating in the new TLP
[ ] +0 it does not matter to me
[ ] -1 I am against it because 


Stephen

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

Re: Jakarta Scope

[Stephen Colebourne]

--- Henri Yandell <[EMAIL PROTECTED]> wrote:
> I think our scope is:
***
> Components that are,
> 
> a) written in and/or for the Java environment
> b) too small in the long-term to be their own
> independent communities
>
***

This is what I put on the wiki a while back (framed in
website-friendly language not scope-friendly
language):

Jakarta provides a diverse set of Java-based
components which aim to make day-to-day development
easier. The focus is on reusable, small-scale,
single-purpose libraries that can be used directly by
your application or by larger frameworks.

The key points were:
- Java-based
- reusable
- small-scale
- single-purpose
- libraries

Stephen


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

Re: [VOTE] Remove SVN restrictions

[Stephen Colebourne]

[X] +1
[ ] -1


Stephen

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

Re: Managing communities and emails (was Re: [PROPOSAL] Jakarta Language Components)

[Stephen Colebourne]

Henri Yandell wrote:

A joke turns into something serious ...but I am all with you guys.
As I said: the more I think about it - the more I like the idea!


You've got my +1 :)


But is that what you mean? (+1 is active not passive)

This all sounds like a nice idea, and could potentially solve the 
difficult issues and choices which we seem to be trying to make.


But is it practical? Is there a tool out there that does this? Are there 
one or more people willing to drive this through and make it happen in 
the next three months?


If its possible and is going to happen then we shouldn't do Jakarta 
Language Components. But if this idea isn't going to happen then JLC 
should be created. How will we make the decision?


Stephen

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

Re: [Jakarta Wiki] Update of "OneCommunityProposals" by StephenColebourne

[Stephen Colebourne]

For the record, I wrote this to try to sum up where discussions have got 
to and to provide some vision as to where the end result might be.


Checking mailing lists tonight indicates that POI has quite a healthy 
set of messages as is. I didn't see much development discussion (an 
indicator of community) but I could be mistaken.


IMO, a *forced* merger of POI with another group would have very 
negative consequences, both for POI and the other group. Sorry I wasn't 
clear on that.


At the moment, I see this debate as not affecting POI. (It also probably 
excludes Hivemind and possibly some other subprojects). IMHO, this 
debate is about commons and the inactive/mature Jakarta subprojects.


Andrew C. Oliver wrote:
A lot of this sounds like Commons trying to remake Jakarta in its image. 
 As an alternative why can't commons be top level?  The namespace is now 
free (http://commons.apache.org/).
or why not http://poi.apache.org/ ;-) Then you don't have to listen to 
our debates.


Stephen

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

Re: Other Jakarta Components

[Stephen Colebourne]

DbUtils and DBCP to db.apache.org sounds like a win to me; DBCP would
point back to Jakarta for a dependency on [pool], but that helps to

foster intra-project involvement.


Betwixt, Digester and JXPath strike me as a bit more to swallow and XML
might not want to taking such bites. You want to go ahead and ask them?


Martin Cooper wrote:

I think this whole thing is putting the cart before the horse. You're in the
process of destroying Commons, not just dismantling it, and for no good
reason that I can see. The people involved with Digester should be the ones
to initiate a discussion about whether or not they want to take Digester
elsewhere. As it is, this is coming across more like "why don't you guys go
away, somewhere far away, 'cos we think that's a good idea".
+1. I believe there is the potential to group Jakarta around perhaps 4 
or 5 mailing lists groupings instead of 15+ now. But it cannot be forced.


Just because db-commons and xml-commons exist doesn't mean that we 
should 'outsource' to them. OSS isn't like that.


As I've said before, its in our nature as programmers to look for 
abstractions and hierarchies - to look for order. Community isn't that 
convenient.


Stephen

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

Other Jakarta Components

[Stephen Colebourne]

Thomas Dudziak wrote:

Could you elaborate a bit on what the physical / visual-to-users
differences to the current commons, well, Jakarta sub-project will be
? Will this be a new Jakarta sub-project (and the other commons
components will remain in the current commons one) ?


I've been trying to dodge this question. Why? Because I want to 
encourage other groupings (especially from commons) to self-select. If I 
make a proposal, then it will be an imposition.


My hope is that in a few months we will have a mentality of working on 
*Jakarta* components, not working on commons (or any other) components. 
To achieve this will require other groupings.


Note: I suspect that some Jakarta sub-projects, perhaps POI, Turbine and 
Velocity, may have real issues with this whole grouping philosophy. My 
answer is to *not* force communities that are truly content with the 
status quo to change.


Each grouping will have:
- a bland name (Jakarta Xxx Components)
- an identity (how and why does the group exist)
- sufficient size (to be active not inactive)
- mailing lists (one ML for all Jakarta doesn't work)
- SHARE COMMON ISSUES on a shared ML, [EMAIL PROTECTED]

What I will say is that its too early to worry about website issues. For 
now, all we need to know is that there will be a link somewhere to each 
component, and probably a single page describing each group. Pages such 
as release procedures etc are Jakarta-scoped and discussed on [EMAIL PROTECTED]


Stephen

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

Re: [PROPOSAL] Jakarta Language Components

[Stephen Colebourne]

Andrew C. Oliver wrote:
I will vote -1 based soley on item 1 of the list for the reasons I've 
already explained.  I think that having ANOTHER jak-commons is a 
fundementally bad idea.  If these are truly enahancements to JavaSE, 
they are one community, and share a mailinglist...then make them one 
distribution and version them together.


An interesting perspective. Firstly, this isn't another commons, but a 
breakout from the existing commons using the existing code in the 
existing packages.


Secondly, jar hell is real and painful. We know that and strive for 
backwards compatibility. My hope is that this group will be able to 
create a single jar file in addition to the component jar files. Why? 
Because our users seem to want both.


Thirdly, because it moves one step forward towards a world where Jakarta 
consists of lots of small components, each at the same level, grouped 
for communication, development and practicality.


Stephen

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

Re: [PROPOSAL] Jakarta Language Components

[Stephen Colebourne]

Roland Weber wrote:

Hello,


other 1-word suggestions would be great.


since they're language components, you can call them "Syllables" :-)


I understand the desire for 'fancy' names, but it misses the point 
unfortunately. This is merely a grouping a several *Jakarta* components.


A fancy name should be thought of as implying TLP status.

Stephen

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

[PROPOSAL] Jakarta Language Components

[Stephen Colebourne]

Reposted (edited) from original commons proposal.
Currently this proposal has general, though not unanimous, support.
A vote thread may follow this thread if the mood remains positive.


I hereby propose the creation of a new Jakarta entity named 'Jakarta 
Language Components'.


This will be formed from the following codebases:
[lang]
[io]
[collections] - expected to divide
[primitives]
[codec]
[id] - on exit from sandbox
[beanutils] - logging to be removed

The following are invited to join if their communities desire:
[oro]
[regexp]
[cli]

Jakarta Language Components mission:
'Enhancing Java SE'

Jakarta Language Components will:
- develop multiple independent components
- each component will have no dependencies
- each component will have no configuration
- each component provides an extension to the JavaSE
- code judged by would it be out of place in the JavaSE
- a component typically has a broad API (many callable methods)
- each method typically does relatively little processing
- have mailing lists (language-user/language-dev)
- not have a sandbox
- use [EMAIL PROTECTED] ML (new) for cross group issues

Stephen

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

One community or many

[Stephen Colebourne]

Henri Yandell wrote:
> I'm not tied to any of the things I'm suggesting - except the strong
> belief that Jakarta as a community of communities cannot work. So I'm
> definitely in favour of more shared site and less individual site - I'm
> in favour of a flat Jakarta, both in terms of SVN acces and not allowing
> subprojects of subprojects (ie: Jakarta Velocity-DVSL, not Jakarta
> Velocity DVSL); I'm in favour of sharing the decisions - rather than
> having a slice of the PMC informing the main PMC of their decision.

It just seem to me to be impossible to imagine a commons-betwixt 
developer caring about velocity-tools, or a taglibs-foo developer caring 
about bcel. There is no community in common.


In commons we care about a broad range of different projects. But the 
degree to which we care about components other than our own has reduced 
over time (roughly inverse proportional to the number of components).


So yes, in the past I was gung-ho about commons taking over the whole of 
Jakarta. Now I recognise commons can barely manage itself, let alone any 
more projects. Size matters.


(In fact, commons often behaves as multiple communities already. Its 
natural and organic. I'm embracing it by proposing Jakarta Language 
Components.)


At some point a recognition needs to occur that hierarchy is not evil. 
We are all developers. We group things into hierarchies naturally. If 
you flattened all the turbine components on the home page of jakarta all 
you'd be doing is forcing the reader to group them. The turbine 
components will always 'belong to' Turbine.



In summary, I believe we are many communities, not one. What unites us 
is our size, in that each individual community is too small to stand 
alone as a TLP. There is the *potential* to build a cross-Jakarta 
community in *addition* to our smaller communities, but it requires care 
and nurturing. Perhaps a single jakarta-user ML, or a forum are the 
places to start.


Stephen

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

Re: [PROPOSAL] Two community proposals

[Stephen Colebourne]

Henri Yandell wrote:
Given that we are one project and that we should be acting as one 
community

I both agree and disagree with the premise.

Jakarta is one community from an ASF point of view (not that important).
Jakarta is many communities in reality (really important).

Reality and practicality should drive our thoughts, not the ASF board.

1) Remove SVN restrictions, all Jakarta committers can commit anywhere 
in Jakarta, with the exception of the Commons-Sandbox as it allows 
Apache committers in general to commit.
+0. I don't see any real downsides to this, as social factors will act 
as a suitable control. However, it doesn't strike me as a big issue.



2) All vote threads to occur on the general@ mailing list; or the pmc@ 
mailing list if deemed private.
-1. This splits votes from code and community. Its just a bad idea. 
Instead we should say that votes *may* occur on jakarta-general if desired.


Stephen

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

Re: Notice of intent.... #2

[Stephen Colebourne]

Tim OBrien wrote:

--- Stephen Colebourne <[EMAIL PROTECTED]>

For example:
- HttpComponents
- WebComponents
- LibraryComponents  (narrowAPI-deep)
- BaseComponents  (broadAPI-shallow)


Explain that narrowAPI-deep, braodAPI-shallow
business.  


BroadAPI-Shallow
The principal API of the component is broad. That is, it consists of 
lots of methods.
Each of those methods is Shallow. That is, each method does relatively 
little processing.

Typically, these will not have config files.
Typically, these wil not have dependencies.
For example, a static Utils class.
For example, commons-lang, commons-io.

NarrowAPI-Deep
The principal API of the component is narrow. That is, there are 
relatively few methods in the whole javadoc that most users should call.
Each of those 'external' methods is Deep. That is, each external method 
performs a lot of internal work to achieve its goal.

Typically, these will have config files.
Typically, these wil have dependencies.
For example, commons-jxpath, oro.

I sugest these as groupings as I believe there is a difference in skills 
in creating these two types of libraries. With NarrowDeep its all about 
the making that narrow API as simple to understand, yet powerful, as 
possible. With BroadShallow, there is a lot of work defining the method 
exactly and in naming. (Plus lots of overap in skills too...)


Stephen

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

Re: Notice of intent.... #2

[Stephen Colebourne]

Phil Steitz wrote:
Hopefully we can keep it at a point where the groups are really just 
there to refine the flow of mail, not to separate it. HttpComponents 
is an example of this (though not a good one as most of its components 
came from HttpClient). WebComponents (formerly hoped to be known as 
Silk) is another example.


Commons would be groupalized out. 


Not sure I understand exactly what you mean here, but if it means 
breaking commons up - even the list - I think we should think very 
carefully about that.  From what may be a selfish perspective - and 
which I will back off from if the rest of the community feels otherwise 
- I think getting feedback from the full group of commons committers and 
voluneers *really* helps those of us who work on commons components.  I 
am afraid that if we break up the dev list and we don't all just agree 
to subscribe to all of the sublists (really defeating the purpose), we 
will both have a harder time building community around components and we 
will lose some valuable feedback.  We will also have less collective 
energy to apply to things like the site, how we think about versioning 
and releases, etc.  We are developing a pretty good body of collective 
experience developing small java components and I think that if we 
"split up" now we may be losing something.


I believe that this plan only works if we are prepared to have multiple 
mailing lists. Try merging velocity, httpclient, taglibs,... all into 
the commons list and its just ridiculous.


The question is how to break down the groupings. And how big should they 
be. One rule would be that a component is only in one grouping.


For example:
- HttpComponents
- WebComponents
- LibraryComponents  (narrowAPI-deep)
- BaseComponents  (broadAPI-shallow)

site and build discussions can occur on a shared list.

Stephen

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

Re: News updates to jakarta.apache.org

[Stephen Colebourne]

This seems like a good idea, however I believe some data has got lost in 
the conversion. Commons-IO was released on October 10/11th, but (unless 
I'm blind) has managed to disappear.


Also, could we move the RSS icon next to the 'News' hyperlink on the 
homepage? Would seem to make more sense there.


Stephen


Howard Lewis Ship wrote:

I adapted some build files and style sheets from my personal web site
for Jakarta this morning, while posting the Tapestry 4.0-beta-11
release notes.

Having posted a lot (!) of releases, I've grown very frustrated with
the very manual, tedious process.

There is now a general news files, news.xml, in the jakarta-site2 directory.

This file contains all new news.

The build process uses this file to generate an RSS feed, and to
generate XML content files in the site/news folder (which are then
converted to HTML).

The master index (at jakarta.apache.org/index.html) is generated from
this file as well (it is limited to the most recent 20 entries).

The format should be easy to grasp.  A root  element contains
 elements.  Each  has an @id and a @title and will be
used to generate a single news file in the site/news folder. 
Currently, a "group" is a calendar quarter, but this can change in the

future if things really heat up (i.e., monthly news pages rather than
quarterly).

 contains  and .  Both of these contain an @id
attribute (consisting of "MMDD.x", i.e., a date stamp and index
within a day), and a @date attribute (a formatted date, such as "17
October 2005").  I suspect some clever juggling could programatically
generate the date from the id, but oh well.

 contains @product which is the product that was released
(i.e., "Tapestry 4.0-beta-11").

 contains @title which is simply the title of the news entry
(i.e., "Right Commons-Cli 1.0 Jar Now In Java Repository").

 and  contains a body of markup, the details about that
product release or general news entry.

I also update the site.xml navigation, to add a link to the RSS feed.

I'm quite happy with how it came out.  An RSS feed makes the site feel
a bit more modern and cared for.

I suspect at some point we'll need to find a way to split this one
news file into several files, but beyond that, this seems like an
approach we can all live with.

--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

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




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

Re: GMANE

[Stephen Colebourne]

Martin Cooper wrote:

On Thu, 1 Sep 2005, David Smiley wrote:

Hello all.  I love using GMANE ( http://www.gmane.org ) to access 
mailing lists because:

1. one stop mailing-list shopping -- a consistent experience
2. NNTP access
3. easiest path to posting a question to a list that you're not a 
member of, examining the responses, and then leaving.


IMHO, this is actually a reason to *not* provide a link to Gmane on our 
site, since it's anti-community, and community is what we are about.


I think anti-community is not a good term to use here. IMHO, any user 
taking an interest in our libraries is A Good Thing, no matter how they 
interact. For many, gmane will be a good choice. We certainly should not 
give the impression of being insular and only accepting access by 
mailing list.


One other point to bear in mind is that Gmane isn't the only service of 
its kind. I believe Roomity aspires to be another Gmane, and there are 
probably others. I'm not sure we want to be keeping pointers to all of 
them, and we shouldn't be picking favourites. ;-)


This is probably a good reason not to have the link though.

Stephen


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

Re: [VOTE] Naming for new Jakarta subproject

[Stephen Colebourne]

> [+1]Apache Silk 
> [-1]Apache Web Bricks
> [-1]Apache Web Commons
> [ 0]Apache Web Components
> [-1]Apache Web Parts

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

Name for commons-like area for web

[Stephen Colebourne]

There doesn't seem to be a thread for this

The current suggestions are:

 Commons Web
 Jakarta Web Parts for Java (JWP4J)
 Web App Commons
 Web App Components
 Web App Modules
 Web Bricks
 Web Commons
 Web Components
 Web Libs
 Web Parts
 Web Tools
 Weblets

Of these, WebParts has issues with Microsoft, so I would suggest we 
avoid it. Weblets was also used by IBM back in 2000, so could have issues.


The most obvious would be CommonsWeb or WebCommons, as the general user 
community could link the concept to commons easily enough. However, 
there is a danger that it could be confusing precisely because of that.


Thus, my current top three are:
- WebLibs
- WebCommons
- WebBricks
but I can still be persuaded.


We do need to decide this though. Only then can mailing list discussion 
move off jakarta general and coding get started.


Stephen

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

Re: configuration files [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]

[Stephen Colebourne]

robert burrell donkin wrote:

On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:

9 or somewhere else should speak to J2EE or other external config 
requirments, which should be fine, even encouraged in some cases



is 9 needed? are any configuration guidelines needed?

if they are then i agree that they should encourage specification
compliance. would a general statement about specification compliance be
better? 


Its not needed. The charter should be as simple as possible.

Stephen

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

Re: [POLL] drop point 12 [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]

[Stephen Colebourne]

robert burrell donkin wrote:

this has proved impractical in the jakarta commons. i propose we drop
point 12.


"12. The subproject will also provide a single JAR of all stable package 
releases. It may also provide a second JAR with a subset of only JDK 1.1 
compatible releases. A gump of nightly builds will also be provided."




--8<---
[X] +1 Get rid!
[ ] -1 Keep it (please give a reason...)
--


One jar didn't work for commons, no reason to expect it will here.

Stephen

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

Re: sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]

[Stephen Colebourne]

Rahul Akolkar wrote:

is boils down to the question: does this subproject need it's own
sandbox or will neophyte components start in the jakarta commons
sandbox?


+1 for sandbox (non-binding)

Its slightly hard to imagine anything otherwise, but maybe I'm just
used to seeing how commons and taglibs work. If Taglibs join, we have
a bunch of Taglibs in sandbox, they will need to be housed somewhere,
and I don't see them migrating to commons sandbox ;-) Right?


Yes, +1 to a sandbox. Although it can create issues, I think has more 
benefits than downsides.


Stephen

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

Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications

[Stephen Colebourne]

robert burrell donkin wrote:

there have been a number of long running threads in the commons
discussing the possibility of commons components for use in web
applications. the consensus emerged that it would be best if a new
subproject with a structure similar to the commons was created for
components intended for use in web applications.

opinions, please!


I am in favour of this, although whether I would be able to spare much 
time is debatable.


In particular, I think that a browser recognition component would be an 
example of something that would fit well in this location.


Perhaps named webparts?

Stephen

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

Re: VOTE: Tomcat -> TLP

[Stephen Colebourne]

   [X] +1 Vote in support
scolebourne, Jakarta PMC member
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jakarta Apache Tomcat as a TLP ?

[Stephen Colebourne]

From: "Henri Gomez" <[EMAIL PROTECTED]>
Well I'd like to know the pros and cons of Tomcat being TLP.
As I said in tomcat-dev, it was proposed when ant became TLP and at
this time the consensus was to stay under jakarta umbrella.
What motivate the move to TLP now.
Currently, Tomcat developers are having to take time away from their main 
task (coding) to answer management issues raised by Jakarta. This raises the 
question of whether Tomcat is big enough and mature enough to manage these 
issues itself, without the involvement of Jakarta.

For example, in this case, if Tomcat were a TLP, it seems likely (based on 
emails to the thread from Tomcat committers) that this PR release would have 
been a non-issue.

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

Re: [draft-2] SD Magazine: request for change

[Stephen Colebourne]

While not directly involved with Tomcat, some code I have written via 
commons probably is included in Tomcat distros.

My comment is simply that I found the pdf description rather distasteful and 
definitely worthy of gentle correction.

We all have lines that we don't want to see crossed, and each person has a 
line in a different place. Simply put, this crossed my line.

+1 to sending the mail
Stephen
- Original Message - 
From: "Henri Yandell" <[EMAIL PROTECTED]>
Added thanks for the award.
Removed the text about companies not being contributors as it is 
nitpicking.

Added note about Apache Tomcat, though I left it open to their discretion 
to avoid detracting from the main issue, that of the concept of a leading 
contributor.

Hen
===
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Tomcat 5.0 error in JOLT announcement
Hi Kate,
I'd like to thank SD/Jolt on behalf of the Jakarta community for the JOLT 
"Productivity Winner" award for Tomcat 5.0. Media recognition of the work 
the Tomcat community puts in is always very welcome.

I'm also writing to let you know about a serious error on your JOLT 
product excellence awards press release because I am concerned it might be 
reproduced in your forthcoming June 2005 issue:

http://www.sdmagazine.com/pressroom/jolt_winners_2005.pdf
The release incorrectly attributes Apache's Tomcat 5.0 product to "The 
Apache Jakarta Project and leading Tomcat contributor JBoss".

There is one big problem with this attribution for us, Apache does not 
have a concept of leading contributors. It is completely out of sync with 
the very philosophies that lie at the heart of the Apache Software 
Foundation (ASF), as there are 70 committers to the Tomcat codebase, many 
of whom are employed by other companies or contribute individually.

We would like to request that this be changed to:
"Tomcat 5.0 (The Apache Software Foundation)"
in both the press release (pdf url above) and the forthcoming June 2005 
issue.

Officially the name of the product is "Apache Tomcat 5.0" and not just 
"Tomcat 5.0", but I will leave it to your discretion as to whether you'd 
like to prefix Tomcat with Apache or not, as the subsequent mention of the 
ASF is fine.

Many thanks,
Henri Yandell
V.P., Apache Jakarta
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

Re: Jakarta jars binaries for JDK 1.3

[Stephen Colebourne]

The problem occurs when a new method is added to a common class
StringBuffer.append(Object)  was in early JDKs
StringBuffer.append (StringBuffer) was added later
If you compile under the later JDKs it uses the second method. Run that 
bytecode on an earlier JDK and it fails. Thats why I always build the 
commons/joda jars that I release under JDK1.3, and try to ensure that that 
jar file is included in the binary, source and ibiblio didstributions (ie. 
don't use maven to create upload bundles to the ibiblio repository)

Stephen
- Original Message - 
From: "Henning Schmiedehausen" <[EMAIL PROTECTED]>
On Wed, 2005-02-16 at 12:43 -0500, Henri Yandell wrote:
Ditto for Commons. I'm pretty sure most of them are outputting
1.2-compatible code from a 1.4 compiler. I'll also happily believe that
that's not a perfect system :)
I'm very sure that there are incompatibilities with bytecode outputted
by the 1.4 compile which makes problems running it on 1.3. Because of
that, at one point I built a Turbine release (2.3) with both 1.3 and 1.4
jars.
The problem is documented in the Java bug database, but I'm not able to
find a reference to it. There should be something about it on the
turbine-dev archive around the time of the 2.3 release, but I don't know
whether the archives work again.
I've pointed to this problem a long time ago but it got largely ignored,
mainly because everyone here seems to compile their jars themselves. But
I did have the problem with maven (when I was still using 1.3 as my main
platform) binary relases, which were built with JDK 1.4 (1.4.1 IIRC) and
did not run on the Sun 1.3.1 JRE.
IMHO this will get worse with 1.5.
Regards
Henning

The only place I could imagine would have the 1.3 jars is either the
nightly build (only Commons, and it doesn't afaik) or gump (does 1.4 and
1.5). I don't think Gump want to be responsible for released jars either,
so currently I'd suspect it'll need a fair bit of effort/movement to get
1.3 jars created.
Sorry,
Hen
On Wed, 16 Feb 2005, Jose Alberto Rodriguez Ruiz wrote:
> Hello Will, and thank you very much for your time.
>
> Indeed no, it seems that there are some incompatibilities at the JVM 
> level
> which means that not all 1.4 bytecode runs in 1.3 JVM. I have had to
> recompile turbine source and commons-configuration source only to be 
> able to
> make my webapp run.
>
> As errors appears only during runtime, I wonder whether I could find
> jakarta's binaries compiled 1.3 for the 
> more-or-less-fifty-libraries-I-use
> in order for not to recompile all of them.
>
> However it is true, no need to touch velocity; it works "as it".
>
> Thanks,
>
> José
>
> -Message d'origine-
> De : Will Glass-Husain [mailto:[EMAIL PROTECTED]
> Envoyé : mercredi 16 février 2005 17:56
> À : Jakarta General List
> Objet : Re: Jakarta jars binaries for JDK 1.3
>
> The byte code should be the same -- as long as the library doesn't use 
> any
> JDK 1.4 specific libraries, it should work fine under 1.3.  I can vouch 
> this
>
> is fine for Velocity.
>
> WILL
>
> - Original Message -
> From: "Jose Alberto Rodriguez Ruiz" <[EMAIL PROTECTED]>
> To: 
> Sent: Wednesday, February 16, 2005 2:04 AM
> Subject: Jakarta jars binaries for JDK 1.3
>
>
> Hello,
>
> I have a J2EE application built around Hibernate, Turbine, and
> Velocity, which I need to recompile to be able to run into a JDK1.3
> environment. This implies recompiling several common libraries, as well 
> as
> Turbine itself and other components. I have sear the mirrors but it 
> seems
> that all the available apache jars are now compiled with JDK 1.4
>
> My question is, is there any place to get ("old") jars compiled with
> JDK1.3? Any help will be much appreciated.
>
> Thank you very much,
>
> José Alberto Rodriguez Ruiz
>
> P.D.: If this is not the right list to ask this question, sorry in 
> advance.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen  INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0   http://www.intermeta.de/
 RedHat Certified Engineer -- Jakarta Turbine Development
  Linux, Java, perl, Solaris -- Consulting, Training, Engineering
"Now you can start with implementation and integration and do the
requirements later".  -- Prof. Dr. Dr. h.c. Manfred Broy about the new
german federal software development

Re: [VOTE] [site] New download pages

[Stephen Colebourne]

[X] +1
[ ] -1
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [site] Label for promoted Jakarta project

[Stephen Colebourne]

I am with this view. Its time to remove other TLP projects from Jakarta, 
whether or not they once had some link to Jakarta.

Stephen
- Original Message - 
Do most visitors care about whether a project is "graduated" or "related"?
If a new user comes from an up-to-date link (or book/article), they won't 
even be looking here.  If they see an out-of-date reference in to the 
jakarta site, usually it'll be to a direct URL (e.g. 
http://jakarta.apache.org/ant) which should just forward to the new URL. 
I suspect only a few people will be searching on the Jakarta home page for 
ant, etc.  So why not just a simple prominent sentence "Can't find what 
you're looking for?  Check the list of related projects at 
http://www.apache.org";.

Cheers, WILL
- Original Message - 
From: "robert burrell donkin" <[EMAIL PROTECTED]>
To: "Jakarta General List" 
Sent: Wednesday, January 12, 2005 12:54 PM
Subject: Re: [site] Label for promoted Jakarta project


i'm not really sure there's any good solution to this one. the downside 
of ex-jakarta is that it's inaccurate: logging isn't really ex-jakarta 
since it contains more than log4j.

i wonder whether we could fit in every apache project and just label it 
Apache Projects...

- robert
On 9 Jan 2005, at 00:42, Henri Yandell wrote:
At the bottom of the left hand navbar is a section of projects that used 
to be a part of Jakarta. It used to be Related and is currently 
Graduated, but neither name has won fans.

Martin has suggested 'Ex-Jakarta'. A problem with Graduated is that it 
involves explaining, and also that it is a poor label as it is not a 
noun. Ex-Jakarta wins on both of these.

Ex-Jakarta has another advantage that I see, which is that things don't 
have to goto an Apache TLP to be Ex-Jakarta. OJB for example, in 
db.apache.org, or even to somewhere like Sourceforge.

So, any opinions?
Barring any -1's to Ex-Jakarta, I'll make the change on Wednesday night.
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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

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


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

Re: [site] Removing things

[Stephen Colebourne]

#8 (langauages) is a pity. Are we planning on trying to fomalize the 
relationship? To cut them off seems a bit of a disservice after a lot of 
effort, although equally inaccurate info can be damaging.

Also, I'd like to see a section on the left for dormant projects. That 
doesn't have to be done tomorrow, but it would clarify the main list.

Stephen
- Original Message - 
From: "Henri Yandell" <[EMAIL PROTECTED]>
Still planning to do all of the below on Tuesday night except for 4), the 
removal of the Graduated section.

Hen
On Fri, 7 Jan 2005, Henri Yandell wrote:
Next up is to clean up various bits on the large front page. Here's the 
list of changes. For each one, if I don't hear a -1 by Tuesday I'll go 
ahead and make the change.

1) Rewrite of the welcome message to the welcome message at 
http://www.apache.org/~bayard/mock-jakarta-frontpage.html. Including 
additions to the products table as shown in the mock.

2) Removal of the elsewhere news section. Point redirects to 
news/index.html.

3) Remove License renewal and news blog from Headlines section. Rename 
Headlines to News.

4) Removal of Graduated from the left navbar.
5) Removal of Related table at the bottom of the index.
6) Move Legal link to the bottom of the page (with the copyright), as 
shown in mock.

7) Removal of Our Mission. Redirect to front page.
8) Removal of links to Japanese/Korean translations.
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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


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

Re: 3-column jakarta.apache.org?

[Stephen Colebourne]

What I was thinking of for projects is something like:
++
|=Projects===|
+--Subprojects---+
| * Alexandia|
| * etc...   |
+--Graduated-+
| * Ant  |
| * etc...   |
++
I have two concerns with this: It takes up more space and nothing else
uses subheadings. It does put Graduated into context with a noun,
though.
My concern is that most users don't care about TLP vs Jakarta owned. So, 
does the terminology 'graduated' help? Why does the user care that some 
projects started at Jakarta, while other Java projects didn't?

Unless and until Jakarta can become a Java portal @ Apache we have to deal 
with this though. It would seem to me that 'Related' was a looser word for 
these projects, and allows us to include other projects that didn't start at 
Jakarta.

Also, I don't see any need to use a noun/subheadings here. For me, 'Related' 
on its own would be a sufficient defintion.

Stephen

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

RE: Deciding on Java futures?

[Stephen Colebourne]

I can't quite see us managing this by tomorrow <:-)

Actually my concern is that we may add stuff to Java
that harms rather than helps (Java isn't C or C++).
So, my question remains whether we have any
opportunity to vote against bad ideas.

Anyway, its good to have some interaction with Sun ;-)

Stephen

 --- "Noel J. Bergman" <[EMAIL PROTECTED]> wrote: 
> First, the ideas can be discussed on the mailing
> list, but we should collect
> them on the Wiki.  Second, we should try to
> prioritize them.  Third, I have
> some feedback already on the good stuff posted, and
> have been asked if we
> can provide some use cases, e.g., for continuations.
>  Not that the ideas
> aren't good, but the use cases will bolster the
> arguments internally at Sun
> for why a given feature is important.
> 
> FWIW, I'm told that some of the ideas are already
> planned, so that should
> make folks happy.  I'm hoping that we'll get some
> direct feedback on the
> Wiki page from Sun.
> 
>   --- Noel
> 
> -Original Message-
> From: Stephen Colebourne
> [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 27, 2004 19:54
> To: Jakarta General List
> Subject: Deciding on Java futures?
> 
> 
> How are we deciding on the Java Futures? Are we
> voting? Just talking?
> 
> There are wide ranging views here, from add no more
> (JDK1.5 was bad enough)
> to add everything but the kitchen sink.
> 
> The wiki has some simpler ideas which haven't been
> shouted down yet, like
> jar in jar and access to the Class from a static
> context. I also think we
> could leverage Jakarta Commons to get small useful
> methods added in a review
> and tidy up of the core libraries (which is
> desparately needed). Perhaps we
> could agree on these?
> 
> Could I suggest on language features, that our best
> approach would be to ask
> Sun to allow us to discuss (in private if necessary)
> their proposed
> additions in the next few months. That way we can
> feedback early our
> experiences and maybe avoid adding unecessary or
> innappropriate 'features'.
> (Personally I am on the side of most of the JDK1.5
> additions being poor
> choices that harm Java)
> 
> Stephen
> 
> 
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
>  

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

Re: Deciding on Java futures?

[Stephen Colebourne]

http://wiki.apache.org/general/JavaFutures

Stephen

 --- Dakota Jack <[EMAIL PROTECTED]> wrote: 
> What wiki, where?  Thanx,
> 
> Jack
> 
> 
> On Wed, 27 Oct 2004 20:08:36 -0400, Noel J. Bergman
> <[EMAIL PROTECTED]> wrote:
> > 
> >
> > First, the ideas can be discussed on the mailing
> list, but we should collect
> > them on the Wiki.  Second, we should try to
> prioritize them.  Third, I have
> > some feedback already on the good stuff posted,
> and have been asked if we
> >I'm hoping that we'll get some direct feedback on
> the
> > Wiki page from Sun.
> > 
> > --- Noel
> > 
> 
> -- 
> "You can't wake a person who is pretending to be
> asleep."
> 
> ~Native Proverb~
> 
> "Each man is good in His sight. It is not necessary
> for eagles to be crows."
> 
> ~Hunkesni (Sitting Bull), Hunkpapa Sioux~
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
>  

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

Deciding on Java futures?

[Stephen Colebourne]

How are we deciding on the Java Futures? Are we voting? Just talking?

There are wide ranging views here, from add no more (JDK1.5 was bad enough)
to add everything but the kitchen sink.

The wiki has some simpler ideas which haven't been shouted down yet, like
jar in jar and access to the Class from a static context. I also think we
could leverage Jakarta Commons to get small useful methods added in a review
and tidy up of the core libraries (which is desparately needed). Perhaps we
could agree on these?

Could I suggest on language features, that our best approach would be to ask
Sun to allow us to discuss (in private if necessary) their proposed
additions in the next few months. That way we can feedback early our
experiences and maybe avoid adding unecessary or innappropriate 'features'.
(Personally I am on the side of most of the JDK1.5 additions being poor
choices that harm Java)

Stephen



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

Port commons-collections to generics under 1.5

[Stephen Colebourne]

Fowarding to jakarta general list from commons.

Are there any apache committers willing to help out on porting
commons-collections to JDK1.5?? I'm overloaded ATM, so can't really help.
Whats needed is an existing committer willing to make commits and work on
this.

Stephen

- Original Message -
From: "Chris Lambrou" <[EMAIL PROTECTED]>
> I thought I'd make a start on converting commons-collections to use
> generics under the JDK 1.5.  Before I go too far, I'd like to hear
> peoples comments on the subject.  In particular, I'd like to know what
> people have to say about the following issues.
>
>
> Project
>
>  From previous discussions on this subject, the general concensus seems
> to be that we should start a new project, [collections15], rather than
> trying to shoehorn generics into [collections], which is required to
> maintain backwards compatibility with older versions of the JDK.  It is
> clear, however, that there would be great similarities between the
> codebases of [collections] and [collections15]. Should we aim to
> ultimately develop the two in parallel, just try to keep the public APIs
> similar (they can't be kept identical - see MultiMap below) or allow the
> two projects to drift off in different directions over time?
> Furthermore, if the codebases do remain very similar, what's the best
> way to handle the tracking of bugs which affect both projects?
>
>
> MultiMap
>
> Most of the interfaces defined in [collections] can be trivially adapted
> to generics. The only exception is MultiMap.  MultiMap violates the Map
> interface, as after calling put(key, value) on a map, get(key) doesn't
> return value, but a Collection containing the value.  This works fine
> for the current Map interface, since Object get(Object key) can
> legitimately return a Collection instance rather than the original
> Object. It's not possible to continue with the current behaviour with
> generics. The map interface's get method now has the signature V get(K
> key), and so we simply cannot return a collection of type
> Collection.  It seems to me that we'll have to settle for a
> Collection getValues(K key) method, but the question is, what happens
> to V get(K key)?  I can think of three obvious behaviours:
>
> 1. V get(K key) should throw an UnsupportedOperationException.
>
> 2. V get(K key) returns one of the values that is mapped to the
> specified key. The choice of exactly which value is left to the
> implementation.
>
> 3. V get(K key) should return the latest value to be mapped against the
> specified key.
>
> I'm not keen on either of the first two options, as they both violate
> the Map interface. The first because Map doesn't specify that V get(K
> key) is an optional operation, and the second because it doesn't
> guarantee that get(key) will return value after put(key, value) has been
> called.  The third option looks good to me, but it would pretty much
> require that the values for each key must be stored in a list, so that V
> get(K key) always returns the latest value mapped, even taking into
> account any calls to V remove(K key, Object item).
>
>
> Also, on a more practical level, since I'm new to the Apache development
> scene, I obviously can't setup a project or commit any code. What's the
> best way to get things started?
>
> Chris
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


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

Re: [VOTE] Updating PMC bylaws

[Stephen Colebourne]

> ===
> [X] +1 - let's do it
> [ ] -1 - not good
> ===



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

Re: [PROPOSAL][site] create separate page for commons downloads

[Stephen Colebourne]

Sorry if I messed this up for you.

FYI, collections is using the subpage named anchor tags to get the user to
the right part of the page.

Stephen

- Original Message -
From: "robert burrell donkin" <[EMAIL PROTECTED]>
> look like we've missed the chance for this :(
>
> this change needed infrastructure to update a list of paths to make the
> cgi script work with the new url. unfortunately, it took a few days to
> get this processed. in the mean time, commons collections was released.
>
> it's a bit of a pity since i've spent this evening working on new
> download pages but i'm rolling back these changes and asking
> infrastructure to remove the url from the list. we'll probably need
> more coordination (and probably a pmc sanctioned release freeze) to
> make changes to the download pages. so, since henri has plans for a
> rethink, we might as well wait and move to the new system directly.
>
> oh well: win some, lose some. that's just the way it is...
>
> - robert
>
> On 20 Jun 2004, at 22:45, Henri Yandell wrote:
> > On Sun, 20 Jun 2004, Stephen Colebourne wrote:
> >
> >>> PROPOSAL
> >>> 
> >>> i'd like to shift all jakarta commons component downloads onto
> >>> separate
> >>> pages which are linked from the main ones. i think that this will
> >>> prolong the useful life of the original page without really effecting
> >>> it's utility.
> >> +1
> >
> > +1.
> >
> > I'd had some complaints from users about the difficulty of downloading
> > (too many click's). I like the dynamic closer.cgi page that the maven
> > download is using. We should just have a single download page with all
> > the
> > commons components on, and it should not mention mirrors at all.
> >
> > All links for downloads should then be aimed at the cgi, which will
> > have
> > all the mirror info for each file.
> >
> > Hen
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


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

Re: [PROPOSAL][site] create separate page for commons downloads

[Stephen Colebourne]

> PROPOSAL
> 
> i'd like to shift all jakarta commons component downloads onto separate 
> pages which are linked from the main ones. i think that this will 
> prolong the useful life of the original page without really effecting 
> it's utility.
+1


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

Re: [VOTE] HiveMind as a Jakarta sub-project

[Stephen Colebourne]

> [X] +1  I support this proposal (PMC)
> [ ] -1  I don't support this proposal
> [ ]  0  I abstain from voting for or against this
> proposal


Stephen

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

Re: EU analogy [PROPOSAL] Proactively encourage TLP status

[Stephen Colebourne]

> >> you haven't seen what the EU has been up to :)  Talk about
> >> over-regulation...
> >
> > LOL  :-)  OK, so it is a bad analogy.  I don't believe that either
> > Costin or
> > I live in the EU.
>
> I don't either.  I live in Connecticut, USA.
>
> I was always suspicious that something was amiss trying to integrate
> proud countries with long individual histories, but it was confirmed
> the first time I had to schelp from Terminal 4 to Terminal 3 at
> Heathrow just so I could pick up the bus to Reading, which used to stop
> at all 4 terminals, but stopped going to terminal 4 because EU regs
> said the total trip was too long.  The whole thing is something like an
> hour. :/

I live in the UK, so can comment ;-) The thing that I spot about the EU is
that is is often used as a scapegoat. When individual countries (or often
the media) wants to shift blame it is convenient. This comes about because
citizens of each country identify more with their own country than with the
EU. (Note: I believe that the EU does a lot of good, but it'll never be my
country)

Perhaps the parallel is that a Struts 'citizen' identifies more with the
Struts 'country' than the Jakarta 'union'. Of course one key difference is
that we don't have the individual governments at the country/Struts level.

Stephen


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

Re: [PROPOSAL] Proactively encourage TLP status

[Stephen Colebourne]

From: "Geir Magnusson Jr." <[EMAIL PROTECTED]>
> We need to get that view corrected, because there is *nothing* that
> states that every member of the PMC is *directly* responsible for ever
> part of every code, doc, mail list and CVS usage in Jakarta, the key
> word is "directly".
As a PMC member, I should care whether there is a new Tapestry release, or a
new Lucene committer. These are PMC votes (or should be). But I don't care
(especially ;-). Thus there is a tension between my mandated responsibility
and my actual interests.

This aspect of 'do I care' is key. I read every vote on J-C, I may not
choose to vote (since adding lots of +0's wastes space), but I care about
the release or new committer. But I don't care about Lucene. Not one jot.
Yet I have equal responsibility for it. This just isn't right.

All I have heard from the original ASF projects indicate to me that the PMC
should represent one codebase and one tight community. Anything else leads
to a layer of management separate from the codebase (aka Jakarta PMC). All
the current debates exist because we have a layer of management which we do
not need.

These debates waste vast amounts of time and energy. Thus PMC members are
given the choice:
- debate/manage continuously and don't code,  or
- code and ignore the PMC
I'm unusual in that I'm bothering putting any effort at all into the former.
It won't be long before I'll give up and do the latter. Your POV will win on
the PMC because everyone else has better things to do than argue incesantly.


> Therefore I would think that given we have coverage of more than one
> committer per sub-project on the PMC, and those committers understand
> the oversight role and are actively performing that role, then the
> Jakarta PMC is compliant with the requirements of the ASF, is scalable,
> and puts minimal additional responsibility on those on the PMC.
>
> Isn't that reasonable?
No. What you are arguing for is just not human nature. As long as there is a
PMC away from the dev list, with other people from the dev list, with other
responsibilities and issues, people will not associate with it. People look
after what they own, and don't care about what they don't own. They may be
on the PMC in name, but that simply isn't enough. It really isn't.


> The fact that participants from multiple sub-projects were the force
> behind J-C (and not the PMC or the board) to me validates my assertion
> that Jakarta as a whole is also a community.
The question that we cannot know the answer to (without a time machine) is
whether the same result would have occurred if Jakarta had not existed. ie.
Is J-C a product of Jakarta, or a product of the need for shared Java code.
You believe its the former, I wasn't around so can't really comment, however
I see no great reason why exactly the same J-C couldn't have occurred
without Jakarta.

Stephen



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

Re: [PROPOSAL] Proactively encourage TLP status

[Stephen Colebourne]

From: "Geir Magnusson Jr." <[EMAIL PROTECTED]>
> I think a lot of what you say presupposed some sort of onerous
> additional work that comes from being a part of the Jakarta PMC.  I
> would argue that it's no different - if you are providing oversight
> independently of Jakarta or part of Jakarta, it's the same amount of
> work.
Well this is a key point. I believe that now I am a Jakarta PMC member I
have direct responsibility for ALL subprojects. Given the breadth of Jakarta
this is a ridiculous position. So, it is more work. Much more work. For
example, I have spent much less time coding in the last 4 weeks. And thats
just plain wrong.

If I'm not careful, I'll go crazy like Robert. So I may choose to leave the
PMC. Others will too, either actually resign, or just ignore it. Oversight
is NOT increased - the basic approach of sign 'em up is flawed.

> The question is how much value you place on Jakarta as a community
> versus Jakarta as a website.
The communities are the subprojects.

> Again, I'll suggest that Jakarta Commons and Apache Commons might
> illustrate a bit about what I keep [unsuccessfully] trying to say.
Sorry, but I don't get you. A-C was a board invention. If it didn't exist
then J-C would be able to TLP cleanly. Perhaps you need to explain more. In
fact, perhaps you should set out in a separate thread as to where you see
Jakarta in 3-6 months time.

Stephen


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

Re: [PROPOSAL] Proactively encourage TLP status

[Stephen Colebourne]

Firstly, having details collected together in one place for 'how to become a
TLP' is a good thing IMHO. I doubt you are asking us to deny information to
subprojects, are you?

Secondly, I am acting because I have been the responsibility to act. As a
Jakarta PMC member I have direct responsibility for ALL Jakarta subprojects.
I am trying to discharge that responsibilty as best I can. If I were
unwilling to to this then I should resign, which I don't feel like doing
quite yet.

Thirdly, this was marked as a proposal, and was asking for views to
determine whether a consensus or vote should be held. I believe I do have
the right to start a proposal thread. I was also concerned that those
members of this list who support a sticking plaster approach were becoming
the only voices heard.

Finally, the time to vote on Jakarta-Commons is not now, because, as has
been pointed out, of the holidays. I would also suggest that J-C contains
many of the people talking on this list, so debating here is not without
merit. (ie. J-C is unique amongst all dev lists in participation from other
Jakarta subprojects - it might also naturally inherit the Jakarta name if
all other subprojects left, which complicates the vote)

Stephen

From: "Costin Manolache" <[EMAIL PROTECTED]>
> Ted, Stephen - you are free to propose or encourage any subproject to do
> whatever you want - but please make clear that this is your personal
> opinion or proposal ( unless jakarta PMC or the board votes on this ).
> But please start with the projects you are dirrectly involved with :-) -
> I don't think it's a good practice to act as a parent for childs you
> don't know very well.
>
>
> Costin
>
>
>
> Geir Magnusson Jr. wrote:
> >
> > On Dec 28, 2003, at 10:25 AM, Ted Husted wrote:
> >
> >> +1
> >>
> >> I agree that interested volunteers should:
> >>
> >> * setup a Wiki area describing the TLP process and rationales , AND
> >
> >
> > Do you think we all should setup our own individual Wiki page, or work
> > together?  I'm getting the feeling you don't want to work together on
> > this.
> >
> >>
> >> * give notice to each and every Jakarta DEV list that the area exists.
> >>
> >> My main beef is that we have not done due diligence in alerting ALL
> >> of  the subprojects of the latest developments.
> >
> >
> > What 'developments'?  We are discussing things here on general@, and as
> > far as I can see, we have no developments yet.  Ted, you seem to be in
> > a terrible hurry to push this through.  Can you wait until people come
> > back from the holiday break and read and catch up?  the point of doing
> > things here is to *increase* participation, not reduce it by rushing
> > something through during a generally world-wide western holiday.
> >
> >>
> >> I've outlined a wiki page as described by this proposal
> >> <http://nagoya.apache.org/wiki/apachewiki.cgi?
> >> JakartaPMCTopLevelProjectApplication>, and setup a draft TLP
resolution.
> >>
> >> I would also volunteer to subscribe to each of the DEV lists and post
> >> a message pointing them to the archive of this thread. (Unless
> >> another  volunteer already has an account setup to do such things. )
> >
> >
> > Instead of doing it yourself, why not try to work w/in the PMC
> > structure and get a message that we all agree on, and have one person
> > from each project on the PMC send to their community.  It would be a
> > good step in the direction you just were espousing in a different
> > thread, namely increased participation.
> >
> >>
> >> Whether a subproject follows through or not can be totally up to each
> >> subproject. The important thing is that we do the due diligence in
> >> making sure *everyone* concerned has been apprised.
> >
> >
> > LOL. There is no legal requirement that any arbitrary idea that a
> > person has *must* be propagated directly to the dev list of each
> > sub-project.  Let others join in this...
> >
> >>
> >> -Ted.
> >>
> >>
> >> - Original message >
> >> From: Stephen Colebourne <[EMAIL PROTECTED]>
> >> To: Jakarta General List <[EMAIL PROTECTED]>
> >> Received: Sun, 28 Dec 2003 14:39:30 +
> >> Subject: [PROPOSAL] Proactively encourage TLP status
> >>
> >>> There has been considerable emphasis on this list over recent weeks
> >>> for t

Re: [PROPOSAL] Proactively encourage TLP status

[Stephen Colebourne]

From: "Geir Magnusson Jr." <[EMAIL PROTECTED]>
> What really saddens me is the idea of chasing them out the door.
To use an analogy, its like being the parents of a family, where the
children, aged from 4 to 40, are all living at home. It strikes me that it
isn't healthy for that 40 year old to be living at home, expecting his
parents to do the washing, feed him and make his bed. Instead, the good
parent should be gently enabling the child to set out on their own in the
next phase of their life.

Sometimes letting go is the hardest part of being a parent.

Stephen


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

Re: [PROPOSAL] Proactively encourage TLP status

[Stephen Colebourne]

I have added to the wiki
 a section on board meeting dates (Jan 21st according to the
archives). (If anyone knows a better source, or more dates, please update
the wiki).

Any suggestions of someone who could comment on the TLP promotion
experience. Perhaps Ant or Logging?

I suggest we wait before contacting the dev lists until the wiki is more
complete.
Stephen

From: "Ted Husted" <[EMAIL PROTECTED]>
I agree that interested volunteers should:
* setup a Wiki area describing the TLP process and rationales , AND
* give notice to each and every Jakarta DEV list that the area exists.



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

[PROPOSAL] Proactively encourage TLP status

[Stephen Colebourne]

There has been considerable emphasis on this list over recent weeks for the
sticking plaster approach. That is to make small minor changes to Jakarta in
the hope the board will stop hassling us. This could be because this is the
consensus view and I'm an odd one out. Or it could be that those in favour
of multiple TLPs just can't be bothered with the arguing. So I thought I'd
place the alternative proposal on the table. If you like it, +1 it.

Background info:
http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges

Stephen

PROPOSAL
The Jakarta PMC shall proactively encourage subprojects to reach Top Level
Project (TLP) status.

It shall do this by
- drawing up a list of advantages that TLP status brings
- explaining the effect of the ASF only recognizing Jakarta on a
subproject's rights
- documenting the process, by receiving advice from recent new TLPs
- produce a draft template board resolution for creating a TLP
- clearly identifying board meeting dates for TLP creation
- proactively encouraging proposal then vote on developer lists
- setting a timefame of 3 months for the votes

In order to respect current reality, voters on each dev list shall be those
of committer and PMC member status who have made recent contributions, with
the exact list to be determined by the dev list.



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

Re: [PROPOSAL] As it ever were (draft 2)

[Stephen Colebourne]

> -PROPOSITION (1)-
>
> * Require all Jakarta products (or subprojects) to file regular reports
> with the PMC.
You mean 'make each subproject work like a TLP' don't you?

> Since the PMC cannot delegate its responsibilities, the report would
> have to be prepared by a PMC member, ideally one directly involved with
> subproject. (A likely suspect being the DEV list moderator.)
Er, doesn't this just emphasise how broken this process is?

> -PROPOSITION (2)-
> [snip]
> Work regarding a specific subproject can continue to occur on that
> subproject's DEV list. PMC members (aka committers) following that list
> can vote on its releases and other day-to-day affairs. So long as the
> minimum quorum is met, the vote is legal and binding.
So, we are trying to delegate power to subprojects? Er, but we can't now can
we.

So who can vote? 'Following the list' is a very vague term. Presumably I can
simply subscribe to struts-dev and then vote, never having even used struts?
It also seems highly dubious to say that a vote is legal and binding if most
of the PMC never knew the vote occurred.

> Under proposition (1), the significant events occurring for each
> subproject would be reported to the PMC list, for the review of the PMC
> at-large.
So the PMC is reviewing events already happened, not actively managing. Er,
sounds like the relationship between the board and a PMC to me.

> PMC membership is voluntary. Anyone can resign from the PMC at any
> time. If a volunteer would like to be a committer, but not a PMC member,
> then each subproject can then decide whether to support separate
> committer and PMC member roles or not.

--
I would suggest that there is nothing in this proposal that will cause the
board members to have any more faith in Jakarta than they do now. And thats
because it changes nothing of significance.

Stephen








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

I thought I'd ask some users

[Stephen Colebourne]

As an experiment, I tried asking some non-Jakarta people about some of the
issues we face:
http://www.javalobby.org/thread.jspa?forumID=61&threadID=10427

Some comments that made me smile were:
"Honestly, Jakarta doesn't mean much to me at all, other than some arbitrary
grouping under Apache. I respect the Apache brand, not Jakarta, and it seems
quite random to me how some java products are under jakarta, some under xml,
and some elsewhere. "

"I tend to see Jakarta simply as the Java arm of the Apache organisation. If
I'm looking for Java components from Apache I know to go to
jakarta.apache.org
I don't really see why any of the projects have moved outside of the Jakarta
project - to me it just fragments things and weakens the brand. Can't those
projects be brought back onboard?"

"As regards to what project should be where, frankly, I think Ant and Tomcat
have been the Flagship projects for Jakarta and they are probably best in
the market. In fact I wonder why they don't have a tomcat.apache.org as it's
so popular. "

"IMHO I think Apache is too hierarchy that a project only belong to one
group (just my opinion). My suggestion is a project can have more than one
group where it related for example batik can belong to XML & Java group. It
will be more like a network structure rather than bottom up tree structure."

Stephen


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

Re: Jakarta: Confederation or Single Project?

[Stephen Colebourne]

Not really (my POV)

As people we naturally think in terms of the hierarchy
  ASF to Jakarta to MySubProject.
But the middle layer is artificial. It could just as well be XML or DB or
WebApps or Java or C or 'Projects starting with S' or 'Projects where Joe
Bloggs works'. There simply is no one way of categorizing, hence there
actually is no one community either. (ie. 'the jakarta community' simply
does not exist in my eyes)

The alternative is a one layer structure
   ASF to MyProject
which gives full oversight, management and confidence both to the ASF and
the ASF. Separately, there is a search website that allows searches by all
the different ways that you might want to look things up.

After all, the one layer (TLP) structure didn't harm Ant or James, and
almost certainly benefitted Maven, Avalon and from the looks of it Log4J. In
the end, actions will speak louder than words.

Stephen


- Original Message -
From: "Harish Krishnaswamy" <[EMAIL PROTECTED]>
> That's true, so back to Jakarta = "Server side web development"! But is it
restricted only to Java
> web development or just plain web development?
>
> -Harish
>
> Henri Yandell wrote:
>
> > Because it's wrong.
> >
> > XML has lots of Java bits, and Maven, Ant, Cocoon, Avalon, James are all
> > Java Development and not in Jakarta.
> >
> > If we go with this approach, we end up with the continuation of: "should
> > digester be in jakarta or xml" etc. Does XML take precedence over the
fact
> > it's in Java, or does it just depend on which community creates or
invites
> > the codebase. As they have to go through the Incubator now [or be
> > fast-tracked with the board's new scheme Greg mentioned], is the
community
> > inviting them in as important as it used to be.
> >
> > I'd much rather find a real subtitle for Jakarta that fits well [Cocoon
is
> > Java web development, but only indirectly I think, ditto for Avalon].
> >
> > Hen
> >
> > On Thu, 18 Dec 2003, Harish Krishnaswamy wrote:
> >
> >
> >>How about Jakarta = "Java Development"? Then, they all seem in place,
no?
> >>
> >>-Harish
> >>
> >>Henri Yandell wrote:
> >>
> >>
> >>>On Thu, 18 Dec 2003, Costin Manolache wrote:
> >>>
> >>>
> >>>
> >>>
> IMO it would be sad if projects like struts or tapestry leave
jakarta -
> since they are closely related to web development and "server side"
java
> ( compared with log4j or regexp for example ).
> >>>
> >>>
> >>>So, Jakarta = "Server side web development" is the subtitle.
> >>>
> >>>Log4J, POI, ORO, Regexp, all of Commons except HttpClient, Latka and
> >>>FileUpload, Gump, BSF, BCEL are the ones that seem most out of place in
> >>>that they don't focus on that subtitle.
> >>>
> >>>Slide would be if a WebDAV TLP were to arrive.
> >>>
> >>>Just as a flamebait suggestion :)
> >>>
> >>>Hen
> >>>
> >>>
> >>>-
> >>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>For additional commands, e-mail: [EMAIL PROTECTED]
> >>>
> >>>
> >>
> >>
> >>-
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


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

Confused with PMCs, TLPs, ASF and Power?

[Stephen Colebourne]

Then try this:

http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges

It aims to be a starter course on why discssions about PMCs, TLPs, Jakarta
and the ASF appear, and possibly how they affect you. Be aware of the
disclaimer at the top, however trying to distill any controversial topic to
one page always ends up annoying someone.

Stephen



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

Choosing against Jakarta

[Stephen Colebourne]

As some of you may know, I look after my own date and time code in Java at
www.joda.org. I had been hoping to bring this code to Apache, as I believe
it to be a very good fit with developments within Jakarta/Jakarta-commons.

Today I decided not to pursue this option for the time being, until the
situation with Jakarta's future is resolved. Instead I applied for a new
sourceforge project to house it more cleanly.

Why post this here? Because I believe that others may also be questioning
the value of Jakarta. I confess that I have no idea what, or if, Jakarta
will look like in 6 months time. Certainly it made no sense to me to attempt
to get a new project adopted by Jakarta at the moment.

Stephen


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

Re: Promotion of sub projects

[Stephen Colebourne]

The list of TLP sugestions outlined below is a good starting point. I'll
suggest some applicability:

The question is whether some projects are willing to make the step to TLP.
These seem like possible candidates:
Tomcat, Lucene, Struts, Velocity

Some others don't strike me as moving out:
BCEL, BSF, ECS, ORO, Regexp, Taglibs

In fact, IMHO what is left in Jakarta is Jakarta-Commons plus other
utility-like projects that might on a different day have been created in
commons.

(I still think there are some tricky cases - POI, Log4J, Tapestry )

I am hoping that developers in some of the larger jakarta products push for
promotion sooner rather than later.

Stephen

- Original Message -
From: "Danny Angus" <[EMAIL PROTECTED]>
> In the light of a request to the PMC by a Jakarta sub-project to have its
> own "top-level" wiki I thought of this...
>
> Jakarta is attempting to put our house in order wrt oversight, this is
> manifesting itself as incresed centralisation of oversight, and reduced
> autonomy for sub-projects.
>
> An issue we've discussed before is promotion to TLP of existing mature
> sub-projects. This started off with an assertion that no-one from Ant
would
> be in favour, and ended up with Ant, Avalon, James and Maven all taking
the
> plunge.
>
> One of the most obvious benefits of TLP to promoted sub-projects is their
> own top-level infrastructure. Providing access to this from within Jakarta
> seems wrong, it breaks the seperation of concerns, would provide
ammunition
> to the argument that this PMC doesn't have full oversight and blurs the
> line between project and sub-project. If a project wants this it should
> consider promotion as the route to achieve it.
>
> I would like to propose (but this is not a proposal, just provoking
> discussion) that we draw up some benchmarks for promotion, which could
give
> some indication that a sub-project is ready to *consider* promotion, and
> probably should do so seriously.
>
> These could be similar to the guidelines for adoption as a sub-project
> (http://jakarta.apache.org/site/newproject.html).
> some ideas are noted below (a little tongue-in-cheek in the style of a
> lifestyle magazine).
>
> Such checks need not compel a sub-project to apply for promotion, but I
> would certainly like sub-projects to consider it as they grow in size,
> maturity or scope, and perhaps an official checklist will remind people
and
> give them the confidence to raise the subject, and perhaps a target to aim
> for.
>
> 1/ Community dynamic,
> a) Is your community self sustaining and largely independant of other
parts
> of Jakarta?
> Not the individuals, the community. Is it, for instance, so heavily
> influenced by the direction of some other sub-project that membership of
> both is virtually a pre-requisite for understanding.
> b) Are many of your commiters also commiters of some other sub-project for
> this, or similar, reasons?
>
> 2/ Project Management,
> a) Does your sub-project need or get much direction from the Jakarta PMC
> (or is it mostly handled by the comitters with lip service paid to the
> PMC)?
>
> 3/ Community health,
> a) Is your community highly dependant on one or two key people, or is
> there a real mix of talent working as a team?
> b) Is there generally an amicable, if hotly debated, concensus?
>
> 4/ Infrastructure resources,
> a) Does your sub-project have aspirations to own its own top-level
> resources (cvs, mailing lists, wiki, web-site)?
>
> 5/ Product seperation,
> a) Is your product tightly bound to other Jakarta sub-projects (excluding
> commons) or does it only supply a need or consume deliverables in the
usual
> way?
> b) Does your sub-project contribute a lot of code to another, or receive a
> lot of contributions from another Jakarta sub-project?
>
> 6/ Scope,
> a) Has your sub-project outgrown it's original scope?
> b) Does your sub-project have a need or desire to maintain it's own
> sub-projects, incubate new ideas, or accept incubated projects from the
> incubator?
>
> 7/
> a) Are there any compeling arguments which can be raised to support
> remaining within Jakarta?
>
> Score 1 for each of the following answers:
> 1a yes
> 1b no
> 2a not much
> 3a real mix
> 3b generally amicable
> 4a yes
> 5a normal supply/consume relationship
> 5b not much direct contribution to or by other sub-projects
> 6a yes
> 6b yes
> 7a not really
>
> Total 1-3 You probably belong here, consider staying.
> Total 4-6 You might need to address some issues before you go.
> Total 7-9 Promotion could be your path to further growth and maturity.
> Total 10-11 You treat this place like a hotel, its time to think about
what
> you really want.
>
>
> d.
>
>
>
>
***
> The information in this e-mail is confidential and for use by the
addressee(s) only. If you are not the intended recipient (or responsible for
delivery of the message to the intended recipient) please notify us
immediat

Re: [i18n] Internationalization subproject sponsor?

[Stephen Colebourne]

For those of you interested in localizing dates and times, take a look at
http://joda.sourceforge.net where I run a project to replace java dates and
times. Contact me directly if you are interested in helping out with testing
the localized dates we produce, or adding calendar systems such as Jewish,
Japanese or Islamic.

If there is sufficient interest, Joda-Time might be persueded to move to
Jakarta-Commons.

Stephen

NB. Joda-Time tackles time issues differently from ICU-time. Joda is a
ground up rewrite. ICU tries to be compatable with the flawed Java classes.
(OK I'm biased...)

NB2. My view on the [i18n] project is to tackle the coding side as small
projects in Jakarta-Commons, such as [time], [money], [text]


- Original Message -
From: "J.Pietschmann" <[EMAIL PROTECTED]>
To: "Jakarta General List" <[EMAIL PROTECTED]>
Sent: Wednesday, July 09, 2003 8:00 PM
Subject: Re: [i18n] Internationalization subproject sponsor?


> Stephen Colebourne wrote:
> > Once you start getting into a list like this you must consider the IBM
ICU
> > project, which tackles these kind of issues. (note, I haven't used ICU).
>
> ICU tackles a lot of important functionality, mainly related to
> extended Unicode support (compared to the Java RT). Most notably
> it provides character normalization, as well as localized
> collation, generalized number parsing and formatting, script
> dependent glyph shaping and some other character/script/text
> related stuff.
>
> It also has all kind of calendars, localized date and time parsing
> and formatting, extensions for dealing with holidays (very useful),
> and a somewhat extended support for currencies (also compared to
> Java RT).
>
> Some of the functionality, in particular BIDI support, was adopted by
> Java 1.4.
>
> A look at the ICU4J jar size should make clear that proper i18n is
> no small undertaking.
>
> There's still more to i18n, especially for interactive programs
> which get significant text input from the user. This requires
> internationalized input methods, something which is rather
> nontrivial to get right. There's also hyphenation, word inflection,
> spell check, punctuation and a few other text/script specific stuff.
>
> Other, hardly explored i18n features are writing modes and dialog
> component arrangement (imagine a drop down box in a lr-tb writing
> mode), cultural dependent use of colors, patterns and pictograms,
> and the gadzillion of small differences in national standards and
> customs for expressing measurements, city names, legalese,
> lies+threats, formulas and whatnot.
>
> Regards
> J.Pietschmann
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


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

Re: [i18n] Internationalization subproject sponsor?

[Stephen Colebourne]

Once you start getting into a list like this you must consider the IBM ICU
project, which tackles these kind of issues. (note, I haven't used ICU).
Stephen

- Original Message -
From: "J.Pietschmann" <[EMAIL PROTECTED]>
To: "Jakarta General List" <[EMAIL PROTECTED]>
Sent: Tuesday, July 08, 2003 9:32 PM
Subject: Re: [i18n] Internationalization subproject sponsor?


> Tetsuya Kitahata wrote:
> > many hardships which people in multi-byte area *must* undergo.
>
> *bg*
>   http://www.pms.informatik.uni-muenchen.de/lehre/seminar/
>internationalisation/02ss/reports-slides/topicK/all.htm
> (URL broken across line)
> gives an impression. Besides the more obvious:
>  * Unicode Support
>  * Collation
>  * Number Formatting
>  * Currency
>  * Date and Time
>  * BIDI and general writing mode support
>  * Input Method Engines
> They even have
>  * Measurement Scales
>  * Paper Sizes
>  * Color: Red
> + U.S. Meaning: Danger
> + Asian Countries: Happiness & Good Luck
> Who'd think about that?
>
> Happy lobbying!
>
> J.Pietschmann
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


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

PMC Nomination

[Stephen Colebourne]

Yesterday I received the Jakarta Monthly Newsletter. Interesting as always,
until I got to the section on PMC nominations. There, I suddenly found my
name listed as elected to the Jakarta PMC. This came as a complete surprise
and shock to me.

When I followed the relevant link, I discovered that a discussion had taken
place on this list, but I was not subscribed to general@jakarta (unless I'm
mistaken, I'm not required to subscribe). At no point was a personal email
sent to myself (or I guess the others nominated). I feel as though I have
been pressganged.

Unless I am mistaken, being a PMC member implies an overseing role for the
whole of jakarta, a requirement to follow PMC issues and votes and to be a
manager. Whilst the concept of being able to push forward jakarta, JSRs,
make decisions etc is appealing, I do not believe that I have the time
available to do the job. Hell, I already lack the time to fully oversee the
commons-lang, commons-collections and commons-clazz projects that I am
involved with as I would like :-)

So, unless someone magically wants to convince me otherwise, I must
respectfully decline the pressgang.

Stephen


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