Re: Cactus Eclipse Plugin page on website

2009-08-03 Thread Martin Cooper
But it *is* available. At least, I managed to find it in a couple of
minutes. The source code is here:

http://svn.apache.org/repos/asf/jakarta/cactus/trunk/integration/eclipse/

and there are binaries available in the Maven central repo.

I don't doubt that it is not actively developed, though, and I can't say
which versions of Eclipse the binaries were built for. Since the source is
available, though, you should be able to easily build it yourself if need
be.

--
Martin Cooper

(Disclaimer - I have no affiliation with Cactus in any shape or form.)


On Wed, Jul 29, 2009 at 5:38 PM, Clifford Alan Jones cajone...@gmail.comwrote:

 Apparently the Cactus Eclipse Plugin is not in development and is
 unavailable.  Unfortunately, I could not tell that from browsing the Cactus
 website.  Removing the a link to download the now unavailable plugin,
 causing people to search the page and the website in vain, is not sufficient
 .

 It's confusing and wastes peoples time.

 Somewhere on the page for the Eclipse Cactus Plugin, it should say clearly,
 boldly and obviously near the top of the page that the plugin in not
 available and not being actively developed.  Perhaps there could even be a
 plea for interested volunteers to take up the task.

 I don't know if this mailing list is the appropriate forum, but could
 someone please update the Eclipse Cactus Plugin page.  Countless hours of
 people's time is being wasted.

 thanks

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




Re: Suggestion to use OpenGrok to index all Jakarta source code

2007-09-03 Thread Martin Cooper
On 9/3/07, Henri Yandell [EMAIL PROTECTED] wrote:

 Personally I'd ask the reverse question of the Fisheye users. Can
 OpenGrok serve the same purpose?

 If so, then we should stop using the commercial app and move to the open
 app.


Other things being equal, I would probably agree with you. However, with
FishEye, Cenqua (now Atlassian) takes care of hardware, installation,
upgrades, maintenance, etc. so that we don't have to. The proposal in this
thread is that the ASF take all of this on in order to run OpenGrok as part
of the ASF infrastructure. I'm much more inclined to leave things as they
are, with Cenqua doing the work, than I am to have us take on all the work
just because we'd prefer the open source project.

--
Martin Cooper


On 9/3/07, Ted Husted [EMAIL PROTECTED] wrote:
  Would FishEye serve the same purpose?
 
   * http://fisheye6.cenqua.com/
 
  There is already a procedure for using FishEye with an ASF project.
  First, ask on infra@ for permission to have cenqua.com setup a FishEye
  instance for your project. Then, contact  [EMAIL PROTECTED]
  and ask them to add your project, and include a copy of the post from
  [EMAIL PROTECTED]
 
  ATM, the only concern seems to be that the initial indexing occur over
  the weekend. The administration is handled on the cenqua.com side, and
  so our group is not directly involved.
 
  Meanwhile, Atlassian has acquired Cenqua Products, and we're told that
  Atlassian is  working on integration components with JIRA and other
  Atlassian products. The integration products are expected to be open
  source, and so we will be able to use them here as soon as they are
  available.
 
  -Ted.
 
  On 9/1/07, Alf H√łgemark [EMAIL PROTECTED] wrote:
   I have a number of times missed an an easy to use web interface for
   searching through all Jakarta source code and subversion change logs,
   and to also being
   able to see line number and subversion change log history for a
   particular file.
  
   The OpenGrok tool ( http://www.opensolaris.org/os/project/opengrok/ )
   seems to me to be very useful in that respect.
   So I would like to suggest that OpenGrok is set up to search and index
   the Subversion repository at http://svn.apache.org/repos/asf/
   OpenGrok seems to be a lot more useful than what is currently
 available
   using a web browser to point to http://svn.apache.org/repos/asf/
 
  -
  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]




Moderators needed

2007-04-08 Thread Martin Cooper
I need to step down from being a moderator of some of the Jakarta mailing 
lists. Before I do, though, I want to make sure that we have adequate 
coverage, which in my mind means at least two moderators for each list.


With myself excluded, here's what we would have for the lists for which I 
am currently a moderator:


announcements - craigmcc bayard mvdb
taglibs-dev   - husted
taglibs-user  - husted

The announcements list looks fine, but we'd want to have at least one more 
moderator for each of the taglibs lists.


Any volunteers? I believe any committer can be a moderator of these lists.

--
Martin Cooper

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



Re: [VOTE] Release Regexp 1.5

2007-03-19 Thread Martin Cooper

On 3/19/07, Vadim Gritsenko [EMAIL PROTECTED] wrote:


Martin Cooper wrote:
 Those sites provide infrastructure, but absolutely no legal protection.

Who says there is no way to combine legal protection and non-absurd
procedures?



Not me. We don't have absurd procedures, so we're already there.

For example: community votes for a release, RM tags a release (and prepares

files), pmc rubber-stamps it with 'ACK' within 72 hours (a-la PMC
composition
change process), done.



PMCs are not about rubber-stamping anything. They are about project
oversight and responsibility.

And the big one. The main goal ASF exists for is fostering software

development
communities. With second goal being software released in the process. And
the
legal part here is an *evil necessity*, it is *not* a goal.



Interesting perspective. But my reading of the first couple of sentences of
this page suggests otherwise:

http://www.apache.org/foundation/

--
Martin Cooper


Vadim


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




Re: [VOTE] Release Regexp 1.5

2007-03-19 Thread Martin Cooper

On 3/19/07, Vadim Gritsenko [EMAIL PROTECTED] wrote:


Martin Cooper wrote:
 On 3/19/07, Vadim Gritsenko [EMAIL PROTECTED] wrote:
 Martin Cooper wrote:
  Those sites provide infrastructure, but absolutely no legal
protection.

 Who says there is no way to combine legal protection and non-absurd
 procedures?

 Not me. We don't have absurd procedures, so we're already there.

I consider tag before vote as absurd.



Yeah, well I consider voting on something that doesn't exist yet to be
absurd. So there we are.

By the way, if you really want to change any of this, burying the discussion
in a vote thread on this list isn't the best way to go about it.

--
Martin Cooper



For example: community votes for a release, RM tags a release (and

prepares
 files), pmc rubber-stamps it with 'ACK' within 72 hours (a-la PMC
 composition change process), done.

 PMCs are not about rubber-stamping anything. They are about project
 oversight and responsibility.

Oversight and responsibility is happening before you tag. They are part of
day
to day work. Mechanical checks for NOTICE and LICENSE files preceding
approval
for distribution stamp happen after.


 And the big one. The main goal ASF exists for is fostering software
 development
 communities. With second goal being software released in the process.
And
 the legal part here is an *evil necessity*, it is *not* a goal.

 Interesting perspective.

Thanks.

Vadim

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




Re: bugzilla administration

2007-03-10 Thread Martin Cooper

I've taken care of this.

--
Martin Cooper


On 3/10/07, Torsten Curdt [EMAIL PROTECTED] wrote:


http://issues.apache.org/bugzilla/show_bug.cgi?id=40577

How can I add new version to bugzilla? Who has admin rights on bugzilla?

cheers
--
Torsten

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




Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should not-yet-commons-ssl go?

2007-02-24 Thread Martin Cooper

On 2/24/07, Martin van den Bemt [EMAIL PROTECTED] wrote:



 Let's keep this statement your personal opinion on the fact that it is
 not
 relevant. I still like to
 know the opinion of others.


 If you want opinions, don't use a vote to collect them. This is a vote
 thread, not an opinion thread. Votes within the ASF are for decision
 making,
 not opinion polls. Jakarta is well known, in a negative way, for being
 overly vote-happy, so we should be doing our best to confine our use of
 voting to things that really need to be voted on. That includes neither
 opinion polls or consensus building.

 My statement was that the final destination of a project is not relevant
 for
 a vote on whether or not it should be accepted into the incubator. I
 consider that to be a simple fact about the way the incubator works, not
an
 opinion.


The difference of opinion here is that you see this as a vote about
incubating ssl, which is simply
not our call.



Not true. There are two basic requirements for entry into incubation: a
Champion and a Sponsor. Once both are found, the project is accepted. That's
it. So by stepping up and being a Sponsor, the Jakarta PMC could play a
pivotal role in the incubation of this SSL project, because without a
Sponsor, incubation is not going to happen, and once it has one, and a
Champion, entry into incubation is a done deal.

We can vote however on accepting ssl into Jakarta, which has the consequence

that
Jakarta is going to be actively involved as a champion / sponsor role to
have the Incubator accept
ssl.



Those things are not quite as connected as you make them out to be. Yes, we
could decide that Jakarta would be happy to have the SSL project land here
after incubation. But that does not imply any particular involvement in the
incubation process, and in the absence of a decision to be the project's
Sponsor, it is meaningless.

So the real decision to be made is whether or not the Jakarta PMC is willing
to step up and be the Sponsor for the SSL project. That basically means two
things:

1) Do we believe that this project would make a worthy addition to the ASF?
This is regardless of where it might land after incubation.
2) Would we be willing to accept the project as part of Jakarta once
incubation is completed successfully?

Note that #2 says that we are _willing_ to accept it, and makes no statement
about whether the project will, in fact, end up as part of Jakarta, or go
somewhere else.

So let's restart the vote (again - sorry) and make it very clear that we are
voting to be the Sponsor of the SSL project, and thus voting on whether it
should enter into incubation or not.

Say if the target is commons, we probably should have commons-ssl end up in

the website of
commons, have Julius participate on the commons website, instead of having
separate lists, separate
website and a separate PPMC and learning the commons way is pretty hard
when you are actually not
integrated into the commons community to begin with.
We are talking about around 20 classes here and 1 new committer (afaik).
What makes this case
special compared to eg webwork (came across this while wading through the
incubator archives to find
similar scenario's) ?

Maybe it's just a different definition of the meaning of full incubation.
Things I want see solved during incubation here is (assuming commons is
the target) :

- IP clearance (paperwork is done by the way)
- It contains crypto, so we probably need some legal advice on this
(currently a discussion on legal
btw)
- Making sure Julius is here to stay (so preventing a new dead commons
project)
- Getting enough support in commons, so it's not a one man project



Commons is not the issue here. Building a community around the code, within
the ASF, is the issue. Without that, incubation will fail. This is, IMHO,
the single most important criterion for any ASF project.

- Everything takes place on the commons mailinglists (user and dev)

- Release votes needs to be the same as any other commons component, with
the addition of an extra
incubator vote.
- Reuse of commons infrastructure, probably with the exception of svn (eg
incubator svn and have
separate permissions, with the whole of jakarta being able to work there)



Agreed on these last three, with the proviso that they apply to whatever
environment the project might land in after successful incubation, be it
Jakarta or elsewhere.

--
Martin Cooper


Thoughts welcome...


Mvgr,
Martin

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




Re: [Vote] Where should not-yet-commons-ssl go?

2007-02-23 Thread Martin Cooper

On 2/23/07, Julius Davies [EMAIL PROTECTED] wrote:


Hi, Jakarta-General,

Let's vote on where to put this code!  Here's the code right now:

http://juliusdavies.ca/commons-ssl/

Forgive my newbieness; I hope these are the right options:

[] Sub-module in Httpcomponents.



IMO it would have to pass through incubation before this could happen
anyway.

[] Sandbox.


The sandbox is open only to ASF committers. IIRC, you're not (yet) a
committer.

[+1] Full Incubator.


+1. IMO this is the correct and appropriate path.

--
Martin Cooper


[-1] not-yet-commons-ssl is not a good project for Apache because...


I'm fine with majority rules, assuming there are no -1 votes.

Some background:

http://wiki.apache.org/jakarta/JakartaBoardReport-February2007

The code grant for the not yet commons SSL (formerly named
commons-ssl), has been completed, so we can progress to having a vote
where SSL should end up on general and based on that result take the
correct incubator path (legal / full incubation).

Let's just get this vote out of the way, and then we can move on to
other issues in the appropriate venue (HttpComponents, or Sandbox, or
Incubator).

My original proposal to jakarta-general about the project is here:
http://www.mail-archive.com/general@jakarta.apache.org/msg12790.html

Yesterday I released not-yet-commons-ssl-0.3.7.  Changes described
at the bottom of this email.  My intention is for 0.3.7 to be the last
release outside of Apache.


By the way, there's one undocumented feature of common-ssl that's been
quite fun:


http://juliusdavies.ca/commons-ssl/javadocs/org/apache/commons/ssl/OpenSSL.html

:-)


yours,

Julius

ps.  My vote is:

[+0] - Abstaining because I'm too much of a newb to really understand
what I'm voting for.



Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should not-yet-commons-ssl go?

2007-02-23 Thread Martin Cooper

On 2/23/07, Martin van den Bemt [EMAIL PROTECTED] wrote:


I prefer this vote to see where it should end up in Jakarta and based on
that result the path full
incubation / legal incubation is decided.

So in my view the vote should be :

[ ] Jakarta should sponsor (which effectively states we like to see the
code end up here)



+1

[ ] Jakarta shouldn't sponsor (which effectively means it will end up TLP)


No, it means that it still needs to find a Sponsor before it can be accepted
into incubation. It says nothing about where it will end up after incubation
or even if it will start incubation.

if accepted in Jakarta, it should end up in :


This is not relevant. The final location of a project is not decided until
it is ready to _exit_ incubation, so it's more than a little premature to be
discussing this here.

[ ] commons as a component

[ ] httpcomponents as a component
[ ] subproject directly under Jakarta
[ ] integrate / merge code into project xxx (please replace x) (so not a
subcomponent of a project!)

And

[ ] I am willing to mentor (you need to be on the Incubator PMC / Member
of the ASF)
[ ] I want to get involved in coding
[X] No interest in getting involved.



--
Martin Cooper


Reasoning :


1) the first decides if Jakarta wants to sponsor this



2) we need to know the place it should end up in Jakarta (at least have some

kind of direction)
3) if no one is interested in getting involved or being a mentor
(preferably 3 mentors!), we can
easily see if option 1 and 2 are viable at all.

The problem with the current vote is that I have to start yet another vote
to let us sponsor and
where it should end up, best to do it in one go in my opninion...

So Martin and Ortwin could you please revote  ? (Sorry for the
inconvenience)

Mvgr,
Martin



Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should not-yet-commons-ssl go?

2007-02-23 Thread Martin Cooper

On 2/23/07, Martin van den Bemt [EMAIL PROTECTED] wrote:




Martin Cooper wrote:
 On 2/23/07, Martin van den Bemt [EMAIL PROTECTED] wrote:

 I prefer this vote to see where it should end up in Jakarta and based
on
 that result the path full
 incubation / legal incubation is decided.

 So in my view the vote should be :

 [ ] Jakarta should sponsor (which effectively states we like to see the
 code end up here)


 +1

 [ ] Jakarta shouldn't sponsor (which effectively means it will end up
TLP)


 No, it means that it still needs to find a Sponsor before it can be
 accepted
 into incubation. It says nothing about where it will end up after
 incubation
 or even if it will start incubation.

 if accepted in Jakarta, it should end up in :


 This is not relevant. The final location of a project is not decided
until
 it is ready to _exit_ incubation, so it's more than a little premature
 to be discussing this here.

Let's keep this statement your personal opinion on the fact that it is not
relevant. I still like to
know the opinion of others.



If you want opinions, don't use a vote to collect them. This is a vote
thread, not an opinion thread. Votes within the ASF are for decision making,
not opinion polls. Jakarta is well known, in a negative way, for being
overly vote-happy, so we should be doing our best to confine our use of
voting to things that really need to be voted on. That includes neither
opinion polls or consensus building.

My statement was that the final destination of a project is not relevant for
a vote on whether or not it should be accepted into the incubator. I
consider that to be a simple fact about the way the incubator works, not an
opinion.

--
Martin Cooper


Main reason : it is very interesting to see to figure out what the exit

criteria should be for a small component like ssl (besides the IP stuff).
Would be nice to get Robert's view on this (I will start a discussion
after the vote, so the vote
doesn't get too polluted). Could be that I am the only one seeing the
difference during incubation
depending on the target within Jakarta, so if that's the case it's
probably best for SSL that other
people step up as mentors and champions.

Mvgr,
Martin

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




Re: List moderator cleanup..

2007-02-18 Thread Martin Cooper

On 2/18/07, Henri Yandell [EMAIL PROTECTED] wrote:


Heh. Whereas I go through the spam every now and then and delete the
spam and reply with -allow to the good ones (except for announce@
where I always do -accept) and while I reply to -owner I can't do much
for people as a moderator any more because gmail.com doesn't seem to
work with the list moderation commands.



Check out the thread with subject List Moderator Help please on infra@
from late January - sebb found ways to do this.

--
Martin Cooper
*
*

Hen


On 2/18/07, Andrew C. Oliver [EMAIL PROTECTED] wrote:
 I think people have a different way to moderate them.  I lack
 time/motivation to explicitly read
 every spam that comes through as a moderation request and only respond
 directly to -owner requests (provided the request is reasonable and
 stated politely)

 -andy

 Martin van den Bemt wrote:
  Hi everyone,
 
  Since I had reason to believe that not all lists are moderated (some
mails are just not coming
  through), I thought I do an audit on what lists are moderated by
who.
  I will mail all the moderators individually to ask if they are still
active, in the mean while I
  asked to be added as a moderator for the jcs lists, which don't seem
to be covered atm (there is a
  moderator, but unlikely to be active).
 
  Mvgr,
  Martin
 


 -
 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: commons-ssl - commons-sslutils?

2006-12-01 Thread Martin Cooper

On 12/1/06, Oleg Kalnichevski [EMAIL PROTECTED] wrote:


On Fri, 2006-12-01 at 15:20 -0500, Vadim Gritsenko wrote:
 Julius Davies wrote:
 ...
  I had to explain that Commons-SSL just sits on top of the JSSE and JCE
  to try and make working with SSL and Java easier.  Your point about
  the name is a good one.

 The counterpoint to name argument. Just single example, I'm sure there
are many
 more: commons-logging sits on top of log4j/java logger/logkit/... and
tries to
 make working with all them seamless.

 commons-ssl may be not the best name but it isn't terribly bad either.

 Vadim


Folks,

What about Commons-SSLUtils? This name seems consistent with already
existent Commons projects (DBUtils)



Calling it Commons-anything presupposes where it would land up after
incubation. That's not something that we should be doing, as the final
resting place of an incubated project is not determined until incubation has
successfully completed.

On the other hand, I think SSLUtils would be a fine name to run with.

--
Martin Cooper


Julius,


Since what-some-day-might-become-commons-ssl is partially based on
some little bits of code I wrote, you can safely add me to the initial
list of committers. I will not be able to do a lot in terms of coding,
given my HttpComponents commitments, but I could help by doing some code
reviews once in a while and participating in design decisions.

Cheers,

Oleg


 ...

  On 12/1/06, Roland Weber [EMAIL PROTECTED] wrote:
 
  The working title Commons-SSL does not really reflect this. Do you
  plan to implement the SSL protocol as part of the project? Probably
  not, so the title is misleading. An all-encompassing name might also
  be offensive to people working on other SSL-related projects. I think
  you should spend the time and define not only a motto, but a very
clear
  scope of the project. Both in terms of what's in scope as well as
what's
  out of scope. From there on, we can work on finding a name and home.
 
  Please do not underestimate the importance of this step. Finding a
  name may seem like a minor detail, but the problem of defining the
  scope is very real. Only a few months ago, there was a long
discussion
  on this list about a proposal for testing.apache.org. I haven't
read
  anything about it anymore after the supporters realized that a scope
of
  everything that has to do with testing was overly broad. We don't
  want to see that happen to your proposal.


 -
 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: commons-fileupload: Streaming mode

2006-11-02 Thread Martin Cooper

On 11/2/06, Dain Sundstrom [EMAIL PROTECTED] wrote:


In the mean time, can you publish a SNAPSHOT?  Also, is anyone
looking at releasing this stuff?  Am I on the wrong mailing list (I
couldn't find one for commons-fileupload)?



The mailing lists for FileUpload are the usual Commons ones, viz
[EMAIL PROTECTED] and [EMAIL PROTECTED]

--
Martin Cooper


Thanks,


-dain

On Nov 2, 2006, at 12:38 AM, Henri Yandell wrote:

 Our (Commons) nightly build machine (vmbuild.apache.org) was on a
 vmware zone that hasn't come back after the machine migration. It took
 care of both the nightly dist build and the m1 snapshot repo
 deployments.

 I'll pester for info again on it tomorrow; last I heard was that we
 don't have vmware expertise and so it's a case of finding nudging
 those who were involved with infra back when it was down to look into
 it.

 It's all in SVN, so if nothing's forthcoming I'll look into setting
 something up (unless someone else volunteers - always appreciated :)
 ).

 Sad that we pestered Craig to get it off of his workstation, and we've
 not managed to achieve his quality of service.

 Hen

 On 10/29/06, Dain Sundstrom [EMAIL PROTECTED] wrote:
 Has this code been Released yet?  The latest version I see is 1.1.1
 and it doesn't seem to contain the FileItemIterator class.  Also
 there don't seem to be any nightly snapshots available.

 In the mean time I can build this by hand, but I'd prefer a Release
 or SNAPSHOT in a maven repo.

 Thanks for any help,

 -dain

 On May 23, 2006, at 5:10 PM, Dain Sundstrom wrote:

  Wow.
 
  I can't wait to get my hands on this code.
 
  -dain
 
  On May 23, 2006, at 4:24 AM, Yoav Shapira wrote:
 
  Hola,
  +1 to you getting commons-fileupload karma and doing it
 yourself ;)
 
  Yoav
 
  On 5/23/06, Jochen Wiedmann [EMAIL PROTECTED] wrote:
 
  Hi,
 
  I have developed a modified version of the commons-fileupload,
 which
  allow a true streaming mode. In other words, there's no need for
  internal byte arrays or temporary disk files, you simply iterate
  through
  the items, get an InputStream on the items, read and process the
  InputStream (for example, run an XML parser on it) and that's it.
  The
  API remains unchanged and the modifications are strictly
 internally.
 
  For obvious reasons, the patches are non-trivial. So far I have
  splitted
  some changes into three patches, which I have posted in Jira
 issues.
  However, to get this patches in, one after the other, I see as my
  only
  chances, if an existing developer would express interest on the
  changes,
  review and guide my work and accept patches step by step. Is
 there
  anyone who volunteers doing the job? Perhaps, being an active ws
  committer, I might after some time as well receive Karma for
  commons-fileupload and finish the work, if I have earned some
 trust.
 
  Regards,
 
  Jochen
 
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
  --
  Yoav Shapira
  Nimalex LLC
  1 Mifflin Place, Suite 310
  Cambridge, MA, USA
  [EMAIL PROTECTED] / www.yoavshapira.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]


 -
 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: [RESULT] Move Velocity to TLP

2006-09-23 Thread Martin Cooper

On 9/23/06, Henning Schmiedehausen [EMAIL PROTECTED] wrote:


Hi,

I'm completely with Nathan here. A Velocity TLP will not be another
Jakarta (though I do fail to see why everyone seems to believe that
Jakata is always considered a bad example).

On the opposite. The Velocity TLP is intended to help reducing the
number of projects that Jakarta has. Which is a push that was started by
Henri last year. The fact that Velocity already has a number of projects
(VelocityTools, which doesn't make any sense without Velocity and same
goes for DVSL; two projects that are heavily entwined with Velocity)
will not go away whether it is located under Jakarta or its own TLP.

I know that we will be reluctant in accepting new projects into Velocity
and I hope that you will be one of the watchguards of that policy on the
new Velocity PMC. But personally, I consider Clustering a good thing.

Having a small group of related projects available through a single
point of access (like e.g. the Lucene related stuff) is a good thing.



I tend to agree with you. Unfortunately, I don't think Lucene is the best
example to point to, though, since it demonstrates how projects can drift.
What I mean is that something like Hadoop should not be part of Lucene, just
as MINA should not be part of Directory. (I think) I understand how both of
these happened, but still, it's something that a Velocity TLP would do well
to bear in mind.

--
Martin Cooper


Just pushing everything top-level IMHO is not. Especially if projects

are too small to go TLP. And putting e.g. VelocityTools under Jakarta
would IMHO not be correct because it would be somehow lost there. A
project like that would always look towards Velocity even if it is
located somewhere else.

For upcoming stuff: there currently is talk with Click (click.sf.net),
and the relation of Click to Velocity is similar (IMHO) the the relation
of Velocity to VelocityTools. They will have to go through incubation
(surely) if they decide to join, but the communities of Velocity and
Click seem to be an even match.

So, in a nutshell: Don't worry. Velocity will not become another
Jakarta. It might become another Lucene or MyFaces with a small number
of clearly defined, Velocity related projects, though. Which is a good
thing IMHO.

Best regards
Henning


On Fri, 2006-09-22 at 21:18 -0700, Nathan Bubna wrote:
 On 9/22/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
  This vote closed sooner than expected.  I was traveling and there was
no
  stated deadline.

 Aw, c'mon.  It's been in discussion on velocity-dev for over a month,
 and i gave the vote a full week!

 Still, further votes and discussion are fine with me... :)

  I'm +1 and -1.
 
  I'm +1 as I do think that Velocity as a TLP is not unreasonable.  Not
  necessary, but not unreasonable.
 
  I'm -1 because I'm worried that this is a new kind of umbrella that's
  planned. Making it a catchall for things that are and use Velocity is
  going the wrong direction.

 Nothing new about it.  Velocity became just such an umbrella under
 your leading, or am i mistaken about your part in forming DVSL and
 VelocityTools?  :)

 And the idea is not that all Velocity using projects are welcome, but
 that we are free to invite projects that are explicitly built upon or
 for Velocity.  There are big differences between being free to invite
 projects and being a catchall and between being a project that uses
 or supports Velocity and one that is explicitly built for or upon
 Velocity.

  If there are projects that aren't template engines that want to come
to
  Apache, the door is open and they are welcome.

 And template engines are welcome too, right?  The question is whether
 being here would be just about them having the foundation and
 infrastructure support or if there is a community aspect too.  If
 community matters, then it matters where they fit in Apache
 organizationally.  So rather than a blanket statement that any
 Velocity-related projects are welcome or not welcome, i prefer having
 the freedom to individually vet the merits and fit of project
 interested in joining the Velocity TLP.  And you, as a Velocity PMC
 member, would be very, very welcome to join in those discussions and
 decisions.

  But putting anything that uses Velocity into a TLP is like using
things
  that use log4j into the same TLP (which would re-create Jakarta... :)

 Yep, good thing that's not the plan! :)

  geir
 
 
  Nathan Bubna wrote:
   Looks like the Velocity community is ready to head out on its own...
  
   +1 votes:
Nathan Bubna
Martin van den Bemt
James Mitchell
Henri Yandell
Jorg Schaible
Henning P. Schmiedehausen
Will Glass-Husain
Torsten Curdt
Rony G. Flatscher
Jesse Kuhnert
Dion Gillard
Daniel Rall
Matthijs Lambooy
Niall Pemberton
Claude Brisson
Malcolm Edgar
Christoph Reck
  
   +0 votes:
   -none-
  
   -1 votes:
   -none-
  
   I'm not sure who's on the PMC

Re: [PATCH]: site/vendors.xml/html

2006-09-06 Thread Martin Cooper

Hmm, are we OK with having companies naming themselves after ASF projects?

--
Martin Cooper


On 9/6/06, Otis Gospodnetic [EMAIL PROTECTED] wrote:


Hello,

Would it be possible to add Lucene Consulting to the Specialized Solution
providers section on http://jakarta.apache.org/site/vendors.html ?

The patch is attached.
If the attachment doesn't make it through the ML, it is also here:
http://lucene-consulting.com/vendors.patch
And here is the info inlined:

Lucene Consulting / http://www.lucene-consulting.com/
- We provide services around Lucene, Solr, and Nutch. Our services include
providing
  best practices, code reviews, scaling, performance tuning, etc. advice,
as well as
  custom development.  Our experience includes working with Java web apps
  (Jetty, Resin, and Tomcat, Struts), PostgreSQL, MySQL, Oracle, and
Hibernate,
  document indexing/searching (e.g. PDF, RTF, XML, HTML...), web crawling,
etc.
- USA and Croatia
- info at lucene-consulting dot com

Thanks,
Otis





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




Re: Opening up the PMC

2006-08-19 Thread Martin Cooper

On 8/8/06, Jesse Kuhnert [EMAIL PROTECTED] wrote:


+1

If they are good enough to change/commit code then they should be able to
vote. Isn't code the core of what the foundation provides anyways? (er
something like that...)



Actually, the community is the core. The code flows from the community.

--
Martin Cooper


On 8/8/06, Henri Yandell [EMAIL PROTECTED] wrote:



 Being on a PMC means two actionable things. Firstly, you get a binding
 vote; and secondly, you can subscribe to [EMAIL PROTECTED] - a list which
 should be pretty quiet (mostly it's just vote results now - would be
nice
 to move those to this list).

 The purpose of the binding vote is that that allows you to perform
 oversight on behalf of the foundation - it's not me making a release,
it's
 the foundation.

 That's all there is. It's nothing special, just that we can yay or nay
 something. There's not even any paperwork beyond the board ack email.
 Given that - why do we have committers and pmc members? Why do we have
 people in our community who have been accepted as committers and are
 happily churning code, but are not allowed a binding vote? It's
definitely
 not because we have an enormously low bar of entry to being a committer.

 My view is that we shouldn't keep wasting our time on such a separation.
 There is no danger at all (given our size) to having a new committer
 immediately join the PMC, and there are notable benefits in that we
don't
 have to keep remembering to add people to the pmc (which we really suck
at
 doing) and we'll have a more open environment (which we all like
right?).
 Also we won't have second class citizens who have to yet again sit and
 wait while their elders remember to nominate them as an elder.

 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.

 ---

 I bring it up because the concept has cropped up elsewhere at the ASF
and
 given our large non-pmc to pmc ratio I think we'll have a lot of strong
 views on the subject.

 Hen

 (Yeah, I recognize that the above is flamebait if we have any strong
 opinions out there. Hopefully it'll stay constructive :) )

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




--
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.




Re: unable to subsribe to [EMAIL PROTECTED]

2006-06-09 Thread Martin Cooper

On 6/9/06, Ido M. Tamir [EMAIL PROTECTED] wrote:


Hi,
since 24hrs I was not able to subscribe with the
link given here:
http://jakarta.apache.org/site/mail2.html#Tapestry

This is what I get:

Hi. This is the qmail-send program at apache.org.
I'm afraid I wasn't able to deliver your message to the following
addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

[EMAIL PROTECTED]:



If you check out the link here:

http://tapestry.apache.org/mail-lists.html

you will see that (a) it's 'users' rather than 'user', and (b) it's
tapestry.apache.org instead of 'jakarta.apache.org' now.

--
Martin Cooper


Sorry, no mailbox here by that name. (#5.1.1)


--- Below this line is a copy of the message.

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




Re: Jakarta Commit access

2006-06-06 Thread Martin Cooper

On 6/6/06, Thomas Vandahl [EMAIL PROTECTED] wrote:


Hi folks,

how is the common svn commit access supposed to work? I was  trying to
commit something to Fulcrum but got 403 Forbidden. I have commit
access to Torque, however. Any hint is welcome.



Torque is part of the Apache DB project. Fulcrum is part of the Apache
Jakarta project. They are entirely separate, with entirely separate SVN
access control. From what I can see, you are a committer to the Torque
sub-project, but you are not a Jakarta committer.

--
Martin Cooper


Bye, Thomas.


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




Re: [site] Copyright dates

2006-06-01 Thread Martin Cooper

On 6/1/06, Henri Yandell [EMAIL PROTECTED] wrote:




On Thu, 1 Jun 2006, sebb wrote:

 At present, all the pages contain the footer:

 Copyright (c) 1999-2005, The Apache Software Foundation. _Legal
information_

 where _Legal information_ is a link to the legal page (which
 definitely needs updating to 2006!)

 IIUC, the new footer would just be:

 _Legal information_

 Is that correct?

 Or would it be better to have:

 Copyright (c) The Apache Software Foundation. _Legal information_

 i.e. remove just the dates from all footers.

That sounds good - I'm pretty sure it's not going to be bad to do that and
change it later. Not having the first part will seem quite out of context.



I think it would be worth asking whether or not a copyright notice without
specified years is actually meaningful. My expectation is that it would not
- i.e. that it would not imbue the pages with copyright protection at all.

I guess the first question is: Do we care about our pages being copyrighted?
I would expect that we do, in which case I believe we should make people
aware of that. If we take the attitude that the copyright applies to the
site and not to the individual pages, then I guess we could go back to what
sebb was talking about in the first place, and use a boilerplate copyright
on each page.

--
Martin Cooper


Once it's changed, I'll ping Cliff for confirmation.


Hen

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




Re: [Taglibs] svn messages not sent to taglibs-dev

2006-05-22 Thread Martin Cooper

On 5/21/06, Kris Schneider [EMAIL PROTECTED] wrote:


I made a few commits to the Cache taglib last week but never saw the
resulting email notifications on taglibs-dev. Are those going to a
different list or is something just not configured properly? Thanks for
any
insight...



I've been tied up with conferences, and backed up on my moderation duties. I
just went through the taglibs queue, and moderated through the only commit I
saw from you. Not sure what happened to any other ones.

--
Martin Cooper


--

Kris Schneider mailto:[EMAIL PROTECTED]
D.O.Tech   http://www.dotech.com/

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




Re: [PROPOSAL] Tiles as the seed for Jakarta Web Components

2006-04-25 Thread Martin Cooper
On 4/25/06, Andrew C. Oliver [EMAIL PROTECTED] wrote:

 I'd be against another commons style sub-community.  Unless you can show
 me
 a defined scope, web components means nothing, then expect my objection.


Understood. A formal scope does need to be written down and agreed upon.
However, I believe that concensus on the gist of such a scope has already
happened, between the lines, in the numerous previous threads on JWC on
various lists.

--
Martin Cooper


-Andy

 James Mitchell wrote:
  I believe that this would be a great way to bootstrap this new
 community.
 
  If this were a formal vote, then I, as both a Struts PMC and a Jakarta
  PMC member, would throw a binding +1 your way.
 
  --
  James Mitchell
 
 
 
 
  On Apr 24, 2006, at 11:56 PM, Martin Cooper wrote:
 
  There has been considerable discussion, on this list and others, about
  the
  creation of a Jakarta Web Components sub-project (also previously
  known as
  Jakarta Silk). I believe the concensus has been in favour of creating
 it.
  However, we seemed to get bogged down, several times, in discussions
  of the
  name, or of exactly which pieces of Jakarta Commons, Jakarta Taglibs,
  etc.,
  should move to the new sub-project.
 
  Meanwhile, over at Struts, we have had a number of discussions about
 the
  future of Tiles[1], currently a Struts sub-project. We have been
 working
  hard to make Tiles independent of Struts, and are close to achieving
 that
  goal. With Tiles no longer depending on Struts, it makes little sense
  for it
  to remain a part of the Struts project. In fact, it is much more
  likely to
  flourish outside of Struts.
 
  The proposal, then, is to create the Jakarta Web Components
  sub-project, and
  make Tiles the first citizen of that sub-project. This simultaneously
  achieves several objectives:
 
  1) We actually get started with the Jakarta Web Components sub-project.
  2) We can defer discussion of which other parts of Jakarta move there.
  3) We create a logical home for the now-Struts-independent Tiles.
 
  While Tiles is a powerful templating framework, it is actually a fairly
  small code base, making it a good candidate for an independent web
  component. It is still being developed, so we would not be seeding
  Jakarta
  Web Components with a dormant component. Several of the Struts
 committers
  (many of whom are already Jakarta committers) would come here to
 continue
  working on Tiles, and to help build the Jakarta Web Components
  sub-project.
 
  Once Jakarta Web Components is up and running, it would, of course, be
  up to
  the various communities surrounding Commons and Taglibs components, and
  potentially other Jakarta sub-projects, as to whether or not they
  choose to
  join the new sub-project. The goal of this proposal is simply to seed
 the
  sub-project and get the ball rolling.
 
  Comments?
 
 
  -
  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] Tiles as the seed for Jakarta Web Components

2006-04-25 Thread Martin Cooper
On 4/25/06, Nathan Bubna [EMAIL PROTECTED] wrote:

 This sounds great, Martin.   But if i may be forgiven a little
 semantic nitpicking, my understanding of previous discussions is that
 JWC would be a grouping rather than a sub-project.  So Tiles would
 be directly a Jakarta sub-project, rather than a sub-sub-project (i.e.
 becoming Jakarta Tiles, not Jakarta Web Components Tiles).


Yes, you are correct, Tiles would be a Jakarta sub-project within the JWC
grouping. I guess I was trying to simplify the proposal for those who
haven't paid as much attention to the whole grouping thing, but in
retrospect, that probably wasn't such a great idea. ;-)

I do also like Andrew's term sub-community as that describes the
 true intent of having these groupings.

 As far as a formal scope to be attached to the Jakarta Web Components
 group goes, i would propose that members of the JWC should be java
 components developed primarily for use in the development of web
 applications.


That's a good start. I'm not sure it's enough, but we could start from
there.

--
Martin Cooper


On 4/24/06, Martin Cooper [EMAIL PROTECTED] wrote:
  There has been considerable discussion, on this list and others, about
 the
  creation of a Jakarta Web Components sub-project (also previously known
 as
  Jakarta Silk). I believe the concensus has been in favour of creating
 it.
  However, we seemed to get bogged down, several times, in discussions of
 the
  name, or of exactly which pieces of Jakarta Commons, Jakarta Taglibs,
 etc.,
  should move to the new sub-project.
 
  Meanwhile, over at Struts, we have had a number of discussions about the
  future of Tiles[1], currently a Struts sub-project. We have been working
  hard to make Tiles independent of Struts, and are close to achieving
 that
  goal. With Tiles no longer depending on Struts, it makes little sense
 for it
  to remain a part of the Struts project. In fact, it is much more likely
 to
  flourish outside of Struts.
 
  The proposal, then, is to create the Jakarta Web Components sub-project,
 and
  make Tiles the first citizen of that sub-project. This simultaneously
  achieves several objectives:
 
  1) We actually get started with the Jakarta Web Components sub-project.
  2) We can defer discussion of which other parts of Jakarta move there.
  3) We create a logical home for the now-Struts-independent Tiles.
 
  While Tiles is a powerful templating framework, it is actually a fairly
  small code base, making it a good candidate for an independent web
  component. It is still being developed, so we would not be seeding
 Jakarta
  Web Components with a dormant component. Several of the Struts
 committers
  (many of whom are already Jakarta committers) would come here to
 continue
  working on Tiles, and to help build the Jakarta Web Components
 sub-project.
 
  Once Jakarta Web Components is up and running, it would, of course, be
 up to
  the various communities surrounding Commons and Taglibs components, and
  potentially other Jakarta sub-projects, as to whether or not they choose
 to
  join the new sub-project. The goal of this proposal is simply to seed
 the
  sub-project and get the ball rolling.
 
  Comments?
 
  --
  Martin Cooper
 
  [1] http://struts.apache.org/struts-action/struts-tiles/
 
 

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




[PROPOSAL] Tiles as the seed for Jakarta Web Components

2006-04-24 Thread Martin Cooper
There has been considerable discussion, on this list and others, about the
creation of a Jakarta Web Components sub-project (also previously known as
Jakarta Silk). I believe the concensus has been in favour of creating it.
However, we seemed to get bogged down, several times, in discussions of the
name, or of exactly which pieces of Jakarta Commons, Jakarta Taglibs, etc.,
should move to the new sub-project.

Meanwhile, over at Struts, we have had a number of discussions about the
future of Tiles[1], currently a Struts sub-project. We have been working
hard to make Tiles independent of Struts, and are close to achieving that
goal. With Tiles no longer depending on Struts, it makes little sense for it
to remain a part of the Struts project. In fact, it is much more likely to
flourish outside of Struts.

The proposal, then, is to create the Jakarta Web Components sub-project, and
make Tiles the first citizen of that sub-project. This simultaneously
achieves several objectives:

1) We actually get started with the Jakarta Web Components sub-project.
2) We can defer discussion of which other parts of Jakarta move there.
3) We create a logical home for the now-Struts-independent Tiles.

While Tiles is a powerful templating framework, it is actually a fairly
small code base, making it a good candidate for an independent web
component. It is still being developed, so we would not be seeding Jakarta
Web Components with a dormant component. Several of the Struts committers
(many of whom are already Jakarta committers) would come here to continue
working on Tiles, and to help build the Jakarta Web Components sub-project.

Once Jakarta Web Components is up and running, it would, of course, be up to
the various communities surrounding Commons and Taglibs components, and
potentially other Jakarta sub-projects, as to whether or not they choose to
join the new sub-project. The goal of this proposal is simply to seed the
sub-project and get the ball rolling.

Comments?

--
Martin Cooper

[1] http://struts.apache.org/struts-action/struts-tiles/


Re: [VOTE] Jakarta Sandbox

2006-04-10 Thread Martin Cooper
On 4/10/06, robert burrell donkin [EMAIL PROTECTED]
wrote:

 On Sun, 2006-04-09 at 22:31 -0400, Andrew C. Oliver wrote:
  Yes.  A lot of things predate the incubator.  I'm not opposed to say an
  HTTPD-sandbox for experimental HTTPD related stuff.
  I'm not opposed to a POI-sandbox (indeed we have one but call it
  scratchpad) for POI-related stuff.  However Jakarta-sandbox is
  SCOPELESS.  Go have a scopeless sandbox on sourceforge IMO.  If you want
  to start a whole NEW project then do that in the incubator IMO.

 the sandbox already exists. the management and supervision were
 entrusted to the commons sub-project. sub-projects have no formal
 existence. the scope of the sandbox is the same as the scope for
 jakarta.

 anything that is in scope for jakarta is in scope for sub-projects. code
 in other languages is pretty much out but nearly any subject is in
 scope. the only limits are imposed by the community itself.


When something graduates from this Jakarta Sandbox, where does it go?
Being a _Jakarta_ sandbox, one might assume that it becomes a Jakarta
subproject. But Hen has claimed to want to morph Jakarta into a
non-umbrella, and graduating to a new Jakarta subproject would be counter to
that goal. On the other hand, if it graduates to somewhere outside of
Jakarta, why is the sandbox inside of Jakarta?

--
Martin Cooper


jakarta's scope is the problem but it's hard to fix for both historic
 and community reasons

 - robert



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




Re: [VOTE] Jakarta Sandbox

2006-04-10 Thread Martin Cooper
On 4/10/06, Henri Yandell [EMAIL PROTECTED] wrote:



 On Mon, 10 Apr 2006, Martin Cooper wrote:

  On 4/10/06, robert burrell donkin [EMAIL PROTECTED]
  wrote:
 
  On Sun, 2006-04-09 at 22:31 -0400, Andrew C. Oliver wrote:
  Yes.  A lot of things predate the incubator.  I'm not opposed to say
 an
  HTTPD-sandbox for experimental HTTPD related stuff.
  I'm not opposed to a POI-sandbox (indeed we have one but call it
  scratchpad) for POI-related stuff.  However Jakarta-sandbox is
  SCOPELESS.  Go have a scopeless sandbox on sourceforge IMO.  If you
 want
  to start a whole NEW project then do that in the incubator IMO.
 
  the sandbox already exists. the management and supervision were
  entrusted to the commons sub-project. sub-projects have no formal
  existence. the scope of the sandbox is the same as the scope for
  jakarta.
 
  anything that is in scope for jakarta is in scope for sub-projects.
 code
  in other languages is pretty much out but nearly any subject is in
  scope. the only limits are imposed by the community itself.
 
 
  When something graduates from this Jakarta Sandbox, where does it go?
  Being a _Jakarta_ sandbox, one might assume that it becomes a Jakarta
  subproject. But Hen has claimed to want to morph Jakarta into a
  non-umbrella, and graduating to a new Jakarta subproject would be
 counter to
  that goal. On the other hand, if it graduates to somewhere outside of
  Jakarta, why is the sandbox inside of Jakarta?

 In my incoherent mind it's:

 Jakarta is
 Components
 Sandbox

 Things move from sandbox to components. Once there, they are arranged into
 groupings to smooth communication.


That would be fine if there was a well-defined scope for the sandbox. As
Andy and others have pointed out, there is no scope right now. That means
that someone could start, say, a new servlet container, or an OSGi
framework, or whatever, that would have no reasonable place as a Jakarta
Component.

--
Martin Cooper


Hen

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




Re: [VOTE] Jakarta Sandbox

2006-04-07 Thread Martin Cooper
On 4/7/06, Henri Yandell [EMAIL PROTECTED] wrote:


 Calling a vote to create a Jakarta Sandbox; which entails:

   * Move Jakarta Commons Sandbox to Jakarta Sandbox
   * Migrate Jakarta Taglibs Sandbox into Jakarta Sandbox
   * Create development mailing list ([EMAIL PROTECTED])
   * Create wiki (and migrate wiki bits from j-c-s/j-t-s)
   * Jakarta Sandbox to initially use the Commons sandbox processes.


What would be the constraints on what could go in there? Anything, as long
as it's written in or for Java?

[ ] +1
 [X] -1


This just seems like too big of a can of worms to me.

--
Martin Cooper


Vote to last no shorter than a week.

 Hen

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




Re: party@ for users?

2006-03-28 Thread Martin Cooper
On 3/28/06, Mario Ivankovits [EMAIL PROTECTED] wrote:

 Hi!

 I would like to know if it is allowed for users to subscribe to
 [EMAIL PROTECTED]


AFAIK that list is open to ASF committers only.

--
Martin Cooper


(So that I can stop from posting to the user lists ;-) )

 Ciao,
 Mario


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




Re: OneCommunityProposals - thoughts?

2006-03-22 Thread Martin Cooper
On 3/22/06, Yoav Shapira [EMAIL PROTECTED] wrote:

 Hola,

  So anymore thoughts? Shall we vote on the wiki page as a whole, rather
  than individual items?

 Definitely individual items: Stefano (Mazzocchi) had a really nice
 message once on another list about pursuing a policy of small
 reversible steps instead of huge ones.  So ours (something becoming a
 TLP) may not be easily reversible, but I'd like to keep them small and
 gradual where possible, especially given no additional benefit from
 doing things at once.


+1. I read Stefano's post too, and agree wholeheartedly.

--
Martin Cooper


 Shall we refine it the wiki page?

 Yeah, let's keep refining it until some date by which we want it to be
 done.  Your call on the date...

 Yoav

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




Re: [PROPOSAL] Cleanup pmc members

2006-03-16 Thread Martin Cooper
On 3/16/06, Henri Yandell [EMAIL PROTECTED] wrote:


 Previously I'd suggested that we should be cleaning up inactive committers
 and inactive PMC members - because I'm a bit of a tidy-addict sometimes
 and I enjoy deleting :)

 A thread on [EMAIL PROTECTED] convinced me that this was half wrong though
 - we shouldn't be worrying about cleaning up the large list of inactive
 committers, they might come back and that would be great.

 However I do still think we should be cleaning up the inactive PMC
 members. The PMC represents the active committers entrusted with oversight
 - so to have inactive committers on there is a detriment to its ability to
 get the job done.


I think I know what you mean, but if I'm right, you didn't say what you
mean. ;-)

The PMC represents those people entrusted with oversight of the project. The
manner in which we elect PMC members means that those people are committers.
A PMC member may be active or inactive with respect to committership, and
may be active or inactive with respect to oversight of the project. Those
two are not necessarily tied at any given time. For example, someone might
be actively working to ensure oversight of the project, but may not have
committed anything for a long time.

All that is a long-winded way of saying that it's not inactive committers
that are the concern, but rather inactive overseers. Those people are harder
to identify. Your SVN file proposal might help, although it's not a complete
solution. (I'm not sure that there is one, though.)

--
Martin Cooper


My proposal is that we create a file in SVN in which PMC members can list
 themselves as being active. After 1 month, failure to appear in that list
 will result in removal from the PMC. If it goes well we could consider
 doing it periodically, or just when it feels like the numbers are getting
 out of sync again.

 Thoughts?

 Hen

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




Re: [PROPOSAL] Cleanup pmc members

2006-03-16 Thread Martin Cooper
On 3/16/06, Henri Yandell [EMAIL PROTECTED] wrote:



 On Thu, 16 Mar 2006, Roland Weber wrote:

  Hi Hen,
 
  My proposal is that we create a file in SVN in which PMC members can
  list themselves as being active. After 1 month, failure to appear in
  that list will result in removal from the PMC. If it goes well we could
  consider doing it periodically, or just when it feels like the numbers
  are getting out of sync again.
 
  Thoughts?
 
  Make sure there is an easy way for the removed people to get back
  on the list. Somebody might just be taking a longer vacation, or
  have a big backlog of things to do after a shorter vacation.

 3 +1s from PMC members would be the most that would be needed - though I
 think we could also do it without even needing that vote. Someone just
 asks to be back on the PMC and after 72 hours they'd get added back on.


The catch with this, though, is that someone coming back from a long
vacation loses their binding vote on any vote that closes within that 72
hour period.

--
Martin Cooper


Hen

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




Re: adding a link from commons.apache.org to Jakarta Commons?

2006-03-14 Thread Martin Cooper
On 3/13/06, Sandy McArthur [EMAIL PROTECTED] wrote:

 I know Jakarta Commons isn't a TLP but considering the
 commons.apache.org space is vacant how about addins a blurb about the
 Jakarta Commons.


You'd have to sell this idea across the ASF, not just at Jakarta, and you'll
likely get more than a little push back. That space was also the realm of
Apache Commons when it existed.

--
Martin Cooper


It's the convention that you use your domain as your package. The
 Jakarta Commons code is in the package org.apache.commons, not
 org.apache.jakarta.commons. Also a number of times I've seen s stack
 trace and simply reveresed the package name parts and pasted it into a
 browser in an attempt to find out more about the code.

 I'm thinking a blurb at the bottom to the effect of:

 hr/
 If you came here looking for Java code in the org.apache.commons
 packages then go see the a
 href=http://jakarta.apache.org/commons/;Apache Jakarta Commons/a
 page.

 --
 Sandy McArthur

 He who dares not offend cannot be honest.
 - Thomas Paine

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




Re: Other Jakarta Components

2006-03-12 Thread Martin Cooper
On 3/7/06, Henri Yandell [EMAIL PROTECTED] wrote:



 On Tue, 7 Mar 2006, Thomas Dudziak wrote:

  On 3/7/06, Henri Yandell [EMAIL PROTECTED] wrote:
 
  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?
 
  Well, yes, JXPath migh be a bit much, but Digester and Betwixt IMO
  would fit nicely.
  And obviously the component developers should agree first whether they
  think this is a good idea. And if they are interested, I can ask the
  DB PMC if they agree, as well.

 I don't think there is any active maintenance for DbUtils, and I suspect
 not for DBCP either. I've been meaning to do some work on DbUtils - but I
 have a long list of those.

  However, I have no direct connections to XML PMC, and since I'm not an
  comitter on Digester/Betwixt/JXPath, it would feel a bit strange to me
  (though I would if you want me to).

 Go ahead and propose each one (db and xml) separately on commons-dev. See
 if anyone speaks up against it - I suspect you'll find that for
 betwixt/jxpath/dbutils/dbcp there won't be a huge amount of talk, though
 Struts uses digester (I think) and they might have an opinion (they're
 well represented on commons-dev).


Yes, Struts uses Digester. It also uses BeanUtils, Chain, FileUpload, IO,
Logging and Validator.

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.

Stephen's proposal for Jakarta Language Components came from inside that
grouping. So should any other proposals for groupings or departures.

With respect to departures in particular, there is a serious potential for
losing community. For example, I keep tabs on a bunch of different Commons
components, primarily because all of the discussions happen on communal
lists. If Digester and DbUtils, for example, go to some other community
where they also share lists, I am very unlikely to sign up for those lists
just to keep tabs on those components. Maybe the developers will move, but
how much of the community will go with them?

--
Martin Cooper


We're only going to end up with a Jakarta XML Components at this rate;
 which would suck. The DB ones would either be in a Jakarta SQL Components
 (suck) or a Jakarta Enterprise Components. The latter isn't so bad, but as
 Geronimo shows - there's a lot in J2EE and I suspect that grouping would
 balloon.

 Hen

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




Re: Other Jakarta Components

2006-03-12 Thread Martin Cooper
On 3/12/06, Henri Yandell [EMAIL PROTECTED] wrote:



 On Sun, 12 Mar 2006, Stephen Colebourne wrote:

  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.

 Right. My first response was that we needed to be sure community would go
 with them. My gut instinct is that the DB ones would go - there's somewhat
 of an overlap between db.apache and commons, but I'm not convinced the XML
 ones would.

 Asking the question on commons-dev should initiate discussion with those
 who care about Digester - ideally asking it here would too but they might
 not be paying attention I guess. Waiting for every individual codebase to
 individually decide to get active and discuss non-code issues is a
 non-starter from the beginning.


Why?

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

 That's no reason to ignore the idea though. OSS is sometimes 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.

 This still comes down to the basic issue :) I believe that as Thomas is a
 Jakarta committer it is not an idea being forced from the outside, but
 something from the inside. As he's a DB PMC member, then at least half is
 very much from the inside - and I think he was involved in the Commons SQL
 - DdlUtils move.

 Even in the model where we only look to those with substantial commits to
 a codebase - some of the inactive ones are going to be left behind and
 will need someone to be suggesting a direction for them.


Why?

--
Martin Cooper


Hen

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




Re: Jakarta Web Components

2006-03-06 Thread Martin Cooper
On 3/6/06, Rahul Akolkar [EMAIL PROTECTED] wrote:

 On 3/6/06, Henri Yandell [EMAIL PROTECTED] wrote:
 
  (feel free to keep discussing names etc, but for the moment I'm going to
  go ahead with the one above)
 
 snip/

 But do it within a reasonable time frame (atleast post any objections
 to JWC in a week -- I think thats reasonable, unless anyone wants more
 time?). I have been meaning to add some initial components to JWC and
 begin work there, and while I agree that the name is important, this
 name game is now getting old ;-)

 Recap - We had 3 votes for JWC in the initial vote thread, and there
 seems to have been more added informally on parallel conversations on
 commons-dev. Seems the J*C trend is catching on (see Stephen talk
 about JLC in another thread).


  Would anyone like to start putting together a list of constituent parts
  for JWC? Please include a proposal for what will happen to any
 subprojects
  left dead by the creation of JWC (ie: Taglibs).
 
 snap/

 Allow me to informally assemble the beginnings of a roster, hopefully
 others can add/remove.

 From Commons:

 * EL (dormant?)

 * FileUpload (active, martinc should confirm interest in moving to JWC)


I'm not so sure about this. FileUpload has already cloned some code from
HttpClient, and could undoubtedly make use of more. Its purpose is to parse
HTTP requests. So I'm actually more inclined to move this to Jakarta HTTP
Components, assuming that HttpClient eventually morphs into that. (I thought
it had already, but I can't seem to find a JHC anywhere.)

* Latka (dormant)

 * FeedParser (possibly? dormant)

 From Taglibs:

 * Reusable Dialog Components (RDC) (JSP 2.0, active)

 * Others per interest (I have little interest in JSP 1.1/1.2 taglibs,
 been on 2.0 for a while now)


I used to work on the Mailer taglib, but abandoned it when someone else
decided to reinvent that as a Mailer2 taglib. That now appears to have been
abandoned as well, and never made it out of the Taglibs sandbox. So I'm not
sure which, if either, would go to JWC.

--
Martin Cooper


Then there is the question of sandbox. There has been talk about a
 Jakarta sandbox, that probably deserves its own thread.

 -Rahul


  Hen
 

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




Re: Subproject Charters

2006-03-05 Thread Martin Cooper
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote:


 I notice that Commons and HTTP Components both have charters. Other
 subprojects may have them and I've just missed in my very quick look.

 Do these serve any purpose? Are they a legacy of the days when we tried to
 create an ASF-like structure within Jakarta to organize things?


They were originally created to define the (sub)projects we were creating,
and they still serve that purpose. If you get rid of the charter, where
would you propose that we define the purpose and scope of these projects?
And what would you call that if it isn't a charter?

Any reason not to go ahead and kill these subproject charters?


 Yes. See above. There needs to be some place where we state the official
purpose and scope, and that isn't just some words that someone happened to
use as a description on some page that's part of the site.

Say some Prolog constraint framework decided it wanted to be part of
Commons. Where would you point them to explain that that's not what Commons
is about?

--
Martin Cooper


Hen

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




Re: [PROPOSAL] Two community proposals

2006-03-05 Thread Martin Cooper
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote:


 I started to write a long email on the problems in Jakarta, on umbrellas,
 on the lack of a Jakarta community and existence only of subcommunities
 and on how it should be there is no Jakarta Xxxx, you are members of
 Jakarta - not a subproject; but you've heard it all before.

 So, proposal:

 -
 Given that we are one project and that we should be acting as one
 community - I propose that we:

 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.


What problem is this solving? I just don't see the need.

2) All vote threads to occur on the general@ mailing list; or the pmc@
 mailing list if deemed private.


I agree with Sandy on this one. The votes should stay on the relevant
developer list.

--
Martin Cooper


-

 Comments?

 The only negative I have for 1) is that I like to use the commit lists to
 see who is on which subproject (for 3 PMC member oversight checking), but
 that is a flawed idea anyway. The real way is to see who is voting on
 issues (especially releases) for that project. If it's an inactive
 project, the real way is to ask the -dev mailing list for 3 PMC replies
 else the subproject gets mothballed.

 Hen

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




Re: Representing project inactivity on the site

2006-03-05 Thread Martin Cooper
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote:


 I really shouldn't be sending multiple emails at the same time - you'll
 all jsut end up replying to one of them. However, itching while the itch
 is present.

 Alexandria is dead. We need to represent it as so on the site.


Why? You're trying to save one mouse click? It's clear as day that it's dead
as soon as you click on the link.

ECS, ORO, Regexp are inactive development-wise - represent - site.
 Slide, POI, Turbine, JCS seem pretty inactive - should we represent such?


Why do we need to do this on the front page? Each site can say whatever it
needs to, since, as you indicated in a subsequent message, there are many
different flavours of done-ness. I think about the only person that needs
such a summary on one page is you, Hen. ;-) And it's just one more thing to
maintain that means updating the Jakarta site instead of the subproject
site, which is backwards to me.

--
Martin Cooper


What labels should we use?

 I suggest:

 * Delete Alexandria. It's at the same level as the java-* CVS stuff,
 ancient history to be forgotten.

 * ECS, ORO, Regexp to be moved to a label of Inactive.

 * Others to be raised as questions separately and voted on.

 Hen

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




Re: Subproject Charters

2006-03-05 Thread Martin Cooper
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote:



 On Sun, 5 Mar 2006, Martin Cooper wrote:

  On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote:
 
 
  I notice that Commons and HTTP Components both have charters. Other
  subprojects may have them and I've just missed in my very quick look.
 
  Do these serve any purpose? Are they a legacy of the days when we tried
 to
  create an ASF-like structure within Jakarta to organize things?
 
 
  They were originally created to define the (sub)projects we were
 creating,
  and they still serve that purpose. If you get rid of the charter, where
  would you propose that we define the purpose and scope of these
 projects?
  And what would you call that if it isn't a charter?
 
  Any reason not to go ahead and kill these subproject charters?
 
 
  Yes. See above. There needs to be some place where we state the
 official
  purpose and scope, and that isn't just some words that someone happened
 to
  use as a description on some page that's part of the site.

 Why restrict a project?


One of your big things right now - order and organisation. ;-)

I missed the alternative on this email (it spun out of a Commons email)
 which is why don't we require these of all subprojects?


I can't answer the question, but that would be fine with me.

 Say some Prolog constraint framework decided it wanted to be part of
  Commons. Where would you point them to explain that that's not what
 Commons
  is about?

 The Jakarta charter where it says Java (which in fact it doesn't say -
 might be a bit of an ommission).


OK, then what about a Java constraint framework?

Here's the Commons Charter:

 ***
 0) rationale

 history, then:
 A Jakarta subproject to solely create and maintain
 independent packages is proposed to accelerate and guide this process.

 (1) scope of the subproject

 The subproject shall create and maintain packages written in the Java
 language, intended for use in server-related development, and designed to
 be used independently of any larger product or framework. Each package
 will be managed in the same manner as a larger Jakarta product.

 bit about sandbox

 (2) identify the initial set of committers

 historical list
 **

 If anything, that's a better Jakarta charter than the Jakarta charter and
 should be merged in - but there's very little to restrict the scope of
 Commons.


Well, I see:

* Written in Java.
* Independent packages.
* Intended for server-side.
* Not frameworks.

Those don't all apply to Jakarta as a whole, but they do all apply to
Commons, and I, for one, do not want to lose those statements of scope and
purpose. It's a charter, whether or not you want to call it one.

--
Martin Cooper


Hen

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




Re: [PROPOSAL] Two community proposals

2006-03-05 Thread Martin Cooper
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote:



 On Sun, 5 Mar 2006, Will Glass-Husain wrote:

  I'm mildly positive on all votes on general.  A corollary of this
 would be
  to encourage everyone to sign up for general. Maybe put this in big
 letters
  on the Jakarta home page.  It seems a good way to try out the one
  community idea, see if it fits.

 To stir things a bit more :)

 We could go further and say that all non-technical discussions are on
 [EMAIL PROTECTED] All navel-gazing, all infrastructure style, all license
 questions etc. -dev lists would remain to discuss the actual code,
 bugfixes etc and would promote non-code issues up to the general mailing
 list.


Great idea! Then I can unsub from general@ and avoid all the navel-gazing!
:-)

--
Martin Cooper


Hen

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




Re: Representing project inactivity on the site

2006-03-05 Thread Martin Cooper
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote:


 On Sun, 5 Mar 2006, Martin Cooper wrote:

  On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote:
 
 
  I really shouldn't be sending multiple emails at the same time - you'll
  all jsut end up replying to one of them. However, itching while the
 itch
  is present.
 
  Alexandria is dead. We need to represent it as so on the site.
 
 
  Why? You're trying to save one mouse click? It's clear as day that it's
 dead
  as soon as you click on the link.
 
  ECS, ORO, Regexp are inactive development-wise - represent - site.
  Slide, POI, Turbine, JCS seem pretty inactive - should we represent
 such?
 
 
  Why do we need to do this on the front page? Each site can say whatever
 it
  needs to, since, as you indicated in a subsequent message, there are
 many
  different flavours of done-ness. I think about the only person that
 needs
  such a summary on one page is you, Hen. ;-) And it's just one more thing
 to
  maintain that means updating the Jakarta site instead of the subproject
  site, which is backwards to me.

 I'm suggesting:

 Active Subprojects

  * Alexandria
  * BCEL
  * BSF
  * Commons
  * HiveMind
  * JMeter
  * Tapestry
  * Velocity

 Inactive Subprojects

  * Cactus
  * ECS
  * JCS
  * ORO
  * POI
  * Regexp
  * Slide
  * Taglibs
  * Turbine


But why? If I'm a user looking for something to help me out in my
development, I don't really care that much if it's active or not. What I
care about is if it does the job. If there are problems with it, then I
might care about whether it's active or not - or maybe I don't, since it's
open source and I could fix the problems myself, if I chose to.

The people who care about active versus inactive are those on the PMC, and
those are not the people we should be designing the Jakarta front page for.

Though it's also obvious that I want all of the Commons components,
 Turbine components, Velocity components, Taglibs components and any other
 hidden away sub-sub-projects to be at the same level. Alexandria itself
 would just go into a trash-can - same place JServ went.

 --

 All (90%?) of the navel gazing comes down to one binary question. Should
 Jakarta be a community, or a community of communities. Are we Jakarta
 committers, or ORO committers.


It should be what it is. As I just wrote in another message (on commons-dev,
I think), you can't make a community into something other than what it has
grown into organically.

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.

 Agreed - most/all of this will seem backwards if someone takes the view of
 community of communities as opposed to single community.


And there you have the nub of my objections to all this manipulation of
communities.

--
Martin Cooper


Hen

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




Re: Subproject Charters

2006-03-05 Thread Martin Cooper
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote:



 On Sun, 5 Mar 2006, Martin Cooper wrote:

  On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote:
 
  Why restrict a project?
 
 
  One of your big things right now - order and organisation. ;-)

 Guess I don't see this as one that needs constraining - how a
 component/subproject does something - sure. What it's allowed to do -
 nope. Not as long as it falls within the larger Jakarta charter.


It's not so much what it's allowed to do, as much as to define its
purpose. Perhaps you see Velocity as a viable Commons component, but I
don't. Nor do I think it would make sense for Digester to be part of Cactus,
or Taglibs to be part of Slide. A well-defined scope is a good thing, and
helps people understand what they're looking at.

 I missed the alternative on this email (it spun out of a Commons email)
  which is why don't we require these of all subprojects?
 
 
  I can't answer the question, but that would be fine with me.

 Seems like unnecessary bureaucracy.


It's not bureaucracy. See above.

 Say some Prolog constraint framework decided it wanted to be part of
  Commons. Where would you point them to explain that that's not what
  Commons
  is about?
 
  The Jakarta charter where it says Java (which in fact it doesn't say -
  might be a bit of an ommission).
 
 
  OK, then what about a Java constraint framework?

 If it's large: -1 to Commons, -1 to Jakarta. If it's tiny +0 to Commons,
 +1 to Jakarta, but they're converging to both be a +1 if not too framework
 like.


I specifically chose a framework for my example because we have long stated
that frameworks should not live in Commons, and that is stated in our
charter. Are you saying you want to change that now, to allow frameworks as
Commons components? I so, -1 from me.

--
Martin Cooper


 Here's the Commons Charter:
 
  ***
  0) rationale
 
  history, then:
  A Jakarta subproject to solely create and maintain
  independent packages is proposed to accelerate and guide this process.
 
  (1) scope of the subproject
 
  The subproject shall create and maintain packages written in the Java
  language, intended for use in server-related development, and designed
 to
  be used independently of any larger product or framework. Each package
  will be managed in the same manner as a larger Jakarta product.
 
  bit about sandbox
 
  (2) identify the initial set of committers
 
  historical list
  **
 
  If anything, that's a better Jakarta charter than the Jakarta charter
 and
  should be merged in - but there's very little to restrict the scope of
  Commons.
 
 
  Well, I see:
 
  * Written in Java.

 +1 to this in the Jakarta charter - though I'd probably say 'Written for
 Java'. Commons Daemon has C parts, but exists for the purposes of Java.

  * Independent packages.

 Common sense - assuming it means other people wouldn't use their packages,
 but fine to add to the Jakarta charter. If it means no dependencies, well
 we break this one a lot.

  * Intended for server-side.

 +1 to this in the Jakarta charter. We've always had this as a loose
 constraint. We don't interpret this as server-side though, rather we
 interpret it as not client-side.

  * Not frameworks.

 +1 to this in the Jakarta charter - we're heading that way.

  Those don't all apply to Jakarta as a whole, but they do all apply to
  Commons, and I, for one, do not want to lose those statements of scope
 and
  purpose. It's a charter, whether or not you want to call it one.

 So my disagreement is that I think it should apply to Jakarta as a whole -
 and is pretty close to doing so.

 Hen

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




Re: Representing project inactivity on the site

2006-03-05 Thread Martin Cooper
On 3/5/06, Yoav Shapira [EMAIL PROTECTED] wrote:

 Hola,
 Martin, I agree with almost everything you've said, except this:

  But why? If I'm a user looking for something to help me out in my
  development, I don't really care that much if it's active or not. What I

 I do care, a lot, as a user.  Active means bugs are getting fixed, the
 mailing lists are a reasonable source for help, and if new standards
 become relevant or new features are requested by numerous, there's a
 good chance the product will evolve to comply with them.  As a user
 who doesn't have Apache commit privilges and who doesn't want to fork
 a product just to use it, activity versus dormancy is a HUGE factor in
 choosing a product.


You snipped out the part that explains what you quoted. ;-)

What I care about is if it does the job. If there are problems with it,
then I might care about whether it's active or not

If you are saying that you wouldn't even try out a component that's marked
as 'inactive', to see if it does what you need, then I think it would be a
*huge* disservice to flag components as inactive right on the front page,
because then people might not even look at them, even if they're done and
would completely fit their needs. Marking a component as 'inactive' would
then be the final nail in its coffin.

--
Martin Cooper


Yoav

 --
 Yoav Shapira
 Senior Architect
 Nimalex LLC
 1 Mifflin Place, Suite 310
 Cambridge, MA, USA
 [EMAIL PROTECTED] / www.yoavshapira.com

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




Re: Representing project inactivity on the site

2006-03-05 Thread Martin Cooper
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote:



 On Sun, 5 Mar 2006, Martin Cooper wrote:

  On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote:
 
  All (90%?) of the navel gazing comes down to one binary question.
 Should
  Jakarta be a community, or a community of communities. Are we Jakarta
  committers, or ORO committers.
 
 
  It should be what it is. As I just wrote in another message (on
 commons-dev,
  I think), you can't make a community into something other than what it
 has
  grown into organically.

 Agreed - that's why I'm not JFDI as one piece of advice I've received
 suggests. I'm also trying to avoid it being manipulation - I could have
 pushed each item one at a time in most-likely-to-be-accepted order. That
 would have been a lot easier, but too machiavellian.

 Least I'm trying to not be doing that :) Thus emails about long term ideas
 etc. More confusing to the community, but less manipulative.

  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.
 
  Agreed - most/all of this will seem backwards if someone takes the view
 of
  community of communities as opposed to single community.
 
 
  And there you have the nub of my objections to all this manipulation of
  communities.

 Stepping further back than the community question - do you think the
 current Jakarta community of communities is healthy?


Not completely, no. I don't follow all the pieces as closely as I believe
you do, but gangrene has definitely set in in places. Taglibs is the example
I'm most familiar with, but I believe that can be resolved by amputating the
truly dead limbs and revitalising the remainder as part of the (eventually,
I hope) forthcoming Jakarta Web Components subproject. (On the other hand, I
suspect that part of the reason for the demise of Taglibs is because a lot
fewer people are using JSP tags these days, having moved on to AJAX or JSF.)

With many Jakarta subprojects having been around for some time, some of them
are just more or less done, which leads to quiet spots in the community. I
think that's fine - we need to recognise that most software projects don't
go on forever (even if it can seem otherwise, sometimes ;), and most
developers don't work on the same projects all of their lives. When the
conversation slows or comes to an end on subproject X, we shouldn't assume
the community is then unhealthy. Maybe it's just done, or people have
moved on to a different technology, or whatever. Putting an old race horse
out to pasture is a lot different than killing it. ;-)

Do you think there
 are ways that an umbrella (in the negative sense of the word) can continue
 to grow (in health rather than size) within the ASF?


In health, yes, and I think we're on that path. Shrinking in size and
bringing the scale of subprojects closer together both help, and much of
that has happened, with the big subprojects moving out to TLPs. Getting Web
Components off the ground will also help. And in that same vein of
collecting like components into Commons-ish sets, I believe that Stephen
Colebourne's proposal for Jakarta Language Components would also help.
Despite some pitfalls along the way, I believe the Commons model has worked
well, and seeing that spread into Web Components and Language Components is
great.

--
Martin Cooper


It's possible it's just me wanting to make the chair role a non-fulltime
 job.

 Hen

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




Re: One community or many

2006-03-05 Thread Martin Cooper
On 3/5/06, Stephen Colebourne [EMAIL PROTECTED] wrote:

 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.


Yes, it does, and I think it's really important that we recognise that.
Those of us who've been around since the inception of Commons, in
particular, will hear the ring of truth in Stephen's words. Jakarta Commons
was a much more cohesive and vibrant community in the early days, and there
were indeed more committers per component, on average, than we have today.

Now, while Commons has been growing like topsy, Jakarta as a whole has been
shrinking, with several subprojects graduating into their own TLPs. That has
been good for Jakarta, and for those subprojects. There's not much left that
could logically go TLP, so we need to deal with what's left.

I agree with Stephen's comments above that forcing everything that's left
into a single group doesn't make sense. They really are different, and we
should recognise that.

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


And I believe that is the way forward, especially for Commons. HttpClient
blazed a path, and now we have Jakarta HTTP Components. We're about to
create Jakarta Web Components, which will acquire pieces from Commons and
Taglibs. So it makes perfect sense to take the group of components related
to extending the Java language and form Jakarta Language Components out of
that.

The end result will be smaller, more cohesive, more vibrant communities than
we have today. It's hard to imagine why that would be a bad thing!

--
Martin Cooper


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: jakarta struts binary

2006-02-08 Thread Martin Cooper
On 2/8/06, John Armstrong [EMAIL PROTECTED] wrote:


 I'm trying to learn java struts and an old Jakarta Struts book is telling
 me to go to jakarta.apache.org for the jakarta struts binary.  When I go
 there there's no mention of such under downloads. There's just Struts
 under Ex-Jakarta, and when I go there, there's numerous downloads besides
 Jakarta Struts Binary.

 How can I get the Jakarta Struts binary for Windows?


Struts is no longer part of Jakarta, so it's now Apache Struts. If you're
just starting to learn Struts, you'll probably want to start with our most
recent GA release, which is Struts 1.2.8. You can find that on the Struts
downloads page, here:

http://struts.apache.org/downloads.html

For documentation, you'll want the corresponding release web site, here:

http://struts.apache.org//struts-doc-1.2.8/index.html

Hope that helps.

--
Martin Cooper


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




Re: Jakarta stats

2006-01-12 Thread Martin Cooper
On 1/12/06, Henri Yandell [EMAIL PROTECTED] wrote:



 On Thu, 12 Jan 2006, Danny Angus wrote:

 
 
  I'm one of the 1) Inactive PMC members  :  39
 
  For historical reasons I made it onto this PMC just as the project I was
  really involved with (James) got promoted to TLP.
  I hung around to try to help make sure that Jakarta didn't die as a
 result
  of all the reorganisation, and wasn't killed off because we failed to
  provide adequate oversight while we carried out the controlled expansion
 of
  the PMC.
  On the one hand I think it may be time for me to move on, on the other
 hand
  I think that Jakarta PMC might benefit from the continuity provided by
  letting the interest of me and the others like me fade away as Jakarta
  continues to evolve.
 
  Whatever I think, I would happily relinquish my PMC vote if the active
 PMC
  members think it would help in any way.

 Personally, I think that as long as we don't have to have any form of
 quorom, and as long as the inactive PMC member is on the mailing list
 (which really means they're not completely inactive), then it's not a
 problem.

 We do need quorom on one issue: The Chairman or any member may be removed
 from the PMC by a 3/4 vote of the PMC.

 Of course, we only have 60% active right now, so presuming only committers
 to the current Jakarta voted, that line of the charter would be
 impossible.


What, you think we're going to let you off the hook as PMC Chair any time
soon? Ha ha ha!

;-)

--
Martin Cooper


Not a biggy I think, I think the chair can sidestep the charter if the
 community allowed it and removing the chair is more about the PMC sending
 a vote of no confidence to the board regardless of %, the board's
 interpretation of that vote would be subjective.

 ie) I doubt a chair could be removed for doing what the board said had to
 be done. 75% or no 75%. :)

 It's one of the places where Jakarta modelled itself on the ASF, but isn't
 the same as the ASF.

 -=-=-=-=

 Mostly I'm worried about:

 PMC members who are not on pmc@ (there's a handful)
 PMC members who are not on general@ (never looked. I will soon)
 Inactive committers who are not on the PMC (200+)

 Hen


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




Re: Notice of intent.... #2

2006-01-10 Thread Martin Cooper
On 1/10/06, Henri Yandell [EMAIL PROTECTED] wrote:


 As a second email in the Notice of intent series; here's what I think
 being a Jakarta component will be like in the future.

 * Jakarta is a collection of components. Hopefully all sitting at the same
 level. ie) a big bag of things.

 * Groups exist. These are categorically not subprojects, but a way to
 allow for slicing of the website etc. Some groups may have their own mail
 list; thus the importance of making sure they don't become subprojects. An
 important rule will probably be that they must do votes on the main list.


I prefer the term groupings (which, interestingly, you switch to below ;)
over groups. I also think we should allow the component:grouping
relationship to be 1:N, since not all components will fit tidily into a
single grouping. As a corollary, I don't believe groupings should have their
own mailing lists.

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. Hopefully. Groupings are not vague names
 - HttpComponents good, Silk bad. CoreComponents good, Turbine bad. The
 idea with that being that boring grouping names are intentionally dull, no
 subcommunity identification.

 * No svn authentication beyond being in the jakarta group. Velocity coders
 have rw access to POI.

 * Improved Committer-PMC process. Chair's responsibility (I've failed at
 this so far) is to turn around the new committer process. A new committer
 of 6 months is effectively voted against going to the PMC, not for. Might
 not be able to make it exactly that way, but the idea being that joining
 the PMC is the exception, not the norm. Personally I'd like to see
 committership be removed if people repeatedly are not allowed onto the
 PMC.


Well, except that the process is that the PMC has to vote in a new committer
to the PMC and then notify the board of that vote. I'm definitely not in
favour of magic notifications to the board when the six months are up,
without an associated vote.

* Application of Commons thinking. Not entirely sure on this one as I
 think we've overcomplicated things in Commons a bit; but things like a
 common build system, common site system etc.

 * Sandbox becomes a Jakarta resource, not a Commons resource. Much of the
 same rules as it has currently. Probably a separate mailing list.


A separate mailing list for the sandbox would be a double-edged sword.Yes,
it would keep the noise out of other mailing lists, but it also, at least,
partially condemns sandbox components to death, by limiting their exposure
much more than now. And if everyone has to subscribe to the sandbox list
anyway, to know what's happening, then a separate list is of limited
utility.

--
Martin Cooper


-

 Shout, scream, yell :)

 Hen

 On Mon, 12 Dec 2005, Henri Yandell wrote:

  dum de dum de dum.
 
  Just to be public so that it doesn't look like I'm sneaking around
  trying to manipulate things.
 
  --
 
  I'm starting to open the question of TLP on many of the Jakarta dev
  mailing lists. It's with a general plan where we would see another
  half a dozen subprojects move to TLP and then really leave Commons as
  the main entity inside Jakarta along with some commons-like components
  that are currently subprojects.
 
  I've been talking unofficially with lots of people at ApacheCon, so
  I've had a fair bit of feedback on various bits. The important part is
  that the loose plan above finds a way to coalesce the Jakarta
  community into a much tighter, more TLP e like project.
 
  I've talked with a couple of board members to feel out things would
  be. One question being, is it a problem if we're pushing a TLP with
  just a few committers. The answer I had was that Excalibur is the
  example TLP, it's rather dormant and it's not a problem.
 
  I was also advised to be a bit more active in pushing forward. I think
  this makes sense, a lot of our cross-community activity is gone
  because people with high activity tend to move to TLP, so we need a
  bit more drive to get things done. Thus the change of tack that I'll
  be trying to pull off without getting hung :)
 
  Please discuss, argue, wibble; but what I'm looking for are active
  ways forward instead of maintaining the status quo. I don't think the
  status quo is good for Jakarta as an entity, it puts strain on our
  oversight because the number of subprojects stretches the chair's and
  community in general's ability to keeps things covered.
 
  *denies the blindfold and stands against the wall waiting*
 
  Hen
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED

Re: multipart/form-java

2005-12-27 Thread Martin Cooper
I would recommend that you use something like Commons HttpClient to
construct and make the request, instead of trying to do so manually, as you
are now. See:

http://jakarta.apache.org/commons/httpclient/

You might also want to use Commons FileUpload to parse the request, instead
of the O'Reilly package, so that you don't get tangled up in the strange
licensing conditions of the O'Reilly package. See:

http://jakarta.apache.org/commons/fileupload/

--
Martin Cooper


On 12/27/05, Lamberto Altieri [EMAIL PROTECTED] wrote:

 Hi there,
 I have a problem!
 I must send a post multipart/form-data message from an applet to a
 servlet,
 I wrote this piece of code:

 try{
// Create a socket to the host
String hostname=localhost;
int port=8080;
InetAddress addr=InetAddress.getByName(hostname);
Socket socket=new Socket(hostname,port);
// Construct data
String dataA=--AaB03x\r\n,
   dataB=Content-Disposition: form-data; name=\submitter\\r\n,
   dataC=\r\n,
   dataD=Larry\r\n,
   dataE=--AaB03x\r\n,
   dataF=Content-Disposition: form-data; name=\files\;
 filename=\file1.txt\\r\n,
   dataG=Content-Type: text/plain\r\n,
   dataH=\r\n,
   dataI=... contents of file1.txt ...\r\n,
   dataL=--AaB03x--\r\n;
int len=dataA.length()+
dataB.length()+
dataC.length()+
dataD.length()+
dataE.length()+
dataF.length()+
dataG.length()+
dataH.length()+
dataI.length()+
dataL.length();

// Send header
String path=/upload/requestupload;
BufferedWriter wr=new BufferedWriter(new OutputStreamWriter(
 socket.getOutputStream()));
wr.write(POST +path+ HTTP/1.0\r\n);
wr.write(Content-Length: +len+\r\n);
wr.write(Content-Type: multipart/form-data;
 boundary=--AaB03x\r\n);
wr.write(\r\n);
// Send data
wr.write(dataA);
wr.write(dataB);
wr.write(dataC);
wr.write(dataD);
wr.write(dataE);
wr.write(dataF);
wr.write(dataG);
wr.write(dataH);
wr.write(dataI);
wr.write(dataL);
wr.flush();

// Get response
BufferedReader rd=new BufferedReader(new InputStreamReader(
 socket.getInputStream()));
String line;
while((line=rd.readLine())!=null)
System.out.println(line);
wr.close();
rd.close();
socket.close();
 }
 catch(Exception e) {e.printStackTrace();}

 but this kind of error is thrown by tomcat 5.5:

 24-dic-2005 1.45.27 org.apache.catalina.core.ApplicationContext log
 GRAVE: error reading or saving file
 java.io.IOException: Corrupt form data: premature ending
 at com.oreilly.servlet.multipart.MultipartParser.init(
 MultipartParser.java:205)
 at com.oreilly.servlet.MultipartRequest.init(MultipartRequest.java
 :222)
 at DemoRequestUploadServlet.doPost(DemoRequestUploadServlet.java:80)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
 ApplicationFilterChain.java:252)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(
 ApplicationFilterChain.java:173)
 at org.apache.catalina.core.StandardWrapperValve.invoke(
 StandardWrapperValve.java:213)
 at org.apache.catalina.core.StandardContextValve.invoke(
 StandardContextValve.java:178)
 at org.apache.catalina.core.StandardHostValve.invoke(
 StandardHostValve.java:126)
 at org.apache.catalina.valves.ErrorReportValve.invoke(
 ErrorReportValve.java:105)
 at org.apache.catalina.core.StandardEngineValve.invoke(
 StandardEngineValve.java:107)
 at org.apache.catalina.connector.CoyoteAdapter.service(
 CoyoteAdapter.java:148)
 at org.apache.coyote.http11.Http11Processor.process(
 Http11Processor.java:856)
 at
 org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection
 (Http11Protocol.java:744)
 at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(
 PoolTcpEndpoint.java:527)
 at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(
 LeaderFollowerWorkerThread.java:80)
 at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
 ThreadPool.java:684)
 at java.lang.Thread.run(Unknown Source)


 I use cos.jar crated by o'reilly for reading the multipart/form-data
 message.
 Is this an encoding problem? Can you help me?
 If you need further info.

 Thanks
 Yours,
 Lamberto Altieri




Re: [Request for Comment] Http Components proposal

2005-09-24 Thread Martin Cooper
On 9/24/05, Henri Yandell [EMAIL PROTECTED] wrote:


 Prior to calling a PMC vote here in a week or two, I'd like to ask if
 anybody has any comments on the following proposal for Commons
 HttpClient to become a Jakarta subproject focusing on Http components.

 Hen

 *

 (The following charter for Jakarta Http Components project is pending
 approval of the Jakarta Project Management Committee (PMC). )

 Rationale:
 =

 The original Jakarta Commons HttpClient API has a number limitations that
 cannot be resolved without a significant architectural redesign. Moreover,
 Jakarta Commons HttpClient has been increasingly used in applications and
 environments it has not been specifically designed for. The existing
 monolithic design no longer adequately reflects the use patterns of
 HttpClient.

 HttpClient needs to be refactored into a toolset of simple, low level HTTP
 components suitable for building more specialized HTTP services.

 Project scope:
 =

 * Jakarta Http Components develops a toolset of low level components
 focused exclusively at the transport aspects of HTTP protocol.

 * Jakarta Http Components MUST be content agnostic. The project DOES NOT
 develop components intended to produce or consume content of HTTP
 messages.


While I understand what you're trying to say here, this wording appears to
preclude some of what is in HttpClient today, namely multipart content
handling.

* Jakarta Http Components continues the development of Jakarta
 HttpClient (formerly Jakarta Commons HttpClient) based on the toolset of
 HTTP components. This tool focuses strictly on the client side of HTTP.

 * Jakarta Http Components MAY develop non-client components (such as an
 HTTP connector, a lightweight server component, proxy components) as
 reference material to demonstrate the capabilities of the toolset. The
 said artifacts ARE NOT meant for production use and are not released as
 official Apache Jakarta products.

 * Jakarta Http Components collaborates with other projects to develop
 specialized HTTP services for production use based on the toolset of HTTP
 components.

 * Jakarta Http Components DOES NOT define a server side API on top of the
 low level transport API.


Again, I understand what you want to say. However, I think it would be
better said in terms that make it clear that it is intended for use on the
client side _of the protocol_, since many people are using HttpClient on the
server side today, but as a client to other servers.

--
Martin Cooper


Targeted specifications and standards:
 =
 * RFC1945 Hypertext Transfer Protocol -- HTTP/1.0
 * RFC2616 Hypertext Transfer Protocol -- HTTP/1.1
 * RFC2617 HTTP Authentication: Basic and Digest Access Authentication
 * RFC2109 HTTP State Management Mechanism -- Cookies
 * RFC2965 HTTP State Management Mechanism -- Cookie2
 * A standard for robot exclusion - robots.txt parser (contribution
 requiring Software Grant - http://www.osjava.org/norbert/)

 Initial set of committers:
 ==
 Project Lead
 Michael Becke

 Project Committers
 Adrian Sutton
 Ortwin Glueck
 Oleg Kalnichevski
 Henri Yandell


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




Re: GMANE

2005-09-01 Thread Martin Cooper



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.


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. ;-)


--
Martin Cooper


4. emails for lists don't go into my mailbox; I don't want them there (I 
prefer NNTP)


I think a mention of GMANE on Jakarta would be helpful for the community. 
This page could use it:

http://jakarta.apache.org/site/mail.html   (by the Archives section)
And perhaps elsewhere; I don't know.

Thanks for listening.

~ David Smiley


-
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: Web Components/Common project

2005-08-09 Thread Martin Cooper
On 8/9/05, Rahul Akolkar [EMAIL PROTECTED] wrote:
 On 8/8/05, Rahul Akolkar [EMAIL PROTECTED] wrote:
  On 8/8/05, robert burrell donkin [EMAIL PROTECTED] wrote:
  snip/
   IMO the proposal can be finished off pretty quickly but i'm unsure about
   the best way to handle the name issue. didn't seem to be any sort of a
   consensus. opinions?
  snap/
 
 Is there any interest in resolving the name issue as mentioned below?
 I think everyone's perception of the methodology used is key to a
 swift resolution, so it'd be nice to flesh out what the method should
 be.

Yes. We need to pick a name ASAP so that we can get the new subproject
off the ground with its own mailing lists, SVN repo, etc.

The problem is that the list of candidate names, as it is now, is
rather long, which could make for a somewhat messy vote. Therefore,
I'd like to propose removing some of those candidate names prior to a
vote:

* Remove anything that has potential conflict. Let's just not go there.
* Remove League, Confederation and Bloc. I honestly don't think those
are serious names.
* I would also recommend removing Weblets, since this suggests a
uniformity of structure that simply won't be there.

That would still leave us with quite a few options to choose among.

--
Martin Cooper


 -Rahul
 
  While it
  would be nice, I doubt this is going to be unanimous. Unless there are
  other suggestions, or someone else beats me to it, I will call a vote
  in 24 hours. I plan to keep it simple, mark X before the name that
  appeals most to you.
 snip/
 
 -
 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: Tracking commons component liveliness

2005-07-27 Thread Martin Cooper



On Wed, 27 Jul 2005, Simon Kitching wrote:


Hi All,

There have recently been some discussions about handling dormant/dead
commons projects. And I've been wondering about the activity levels of
some projects recently (whether they are dead or not).

It's hard to track activity by email volumes, and subversion commit
counts can be misleading for two reasons:
* some commits are done to fix widespread issues such as copyright
 dates, while not actually indicating activity on a project
* some projects are perfectly stable, and so have low activity counts
 though they are by no means dead and still have maintainers around.

I've got a suggestion to make about tracking this.

We could put up a page on the wiki (or maybe directly on the
jakarta-commons main page) listing all the projects (main and sandbox).
Next to each project would be listed the currently active developers and
a date.


I have a big problem with putting people's names beside projects and 
components on a public web page. Besides being yet another thing that 
needs to be kept up to date, it will only encourage people to contact the 
developers directly, instead of using the mailing lists. From my own 
perspective, this is a huge problem already, and I'd be -1 to anything 
that's going to further exacerbate it.


--
Martin Cooper



People would be expected to regularly (as often as they like but at
least every 3 months) go to the page and update the date next to their
name for projects they still are actively involved in, and remove their
name against any projects they no longer do anything on. By actively
involved I mean that they respond to bug reports or patches submitted
for the project, not just that they are currently coding on it.

Periodically (eg before the board report is due) the Jakarta PMC chair
can post a few mails reminding people to update their details. And then
names where the dates get too old can be removed as they clearly aren't
responding to those prompter emails.


A quick look at this page by users or apache people would show the
stability of projects: zero, one or multiple maintainers.

It doesn't seem an unfair burden; I'm happy to update 3 or 4 lines on a
wiki page once every 3 months.

Anyway, it's just a thought for the PMC, Henri, etc. to follow up on if
you think it's worth doing for us or the users.

Regards,

Simon


-
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: [RESULT] Brian Stansberry as jakarta-commons-logging committer

2005-07-26 Thread Martin Cooper



On Wed, 27 Jul 2005, Simon Kitching wrote:


Hi,

Any sign of Brian's CLA having been received??


Nope, not yet. Jim added in a bunch of received iCLAs on 7/14, and Brian's 
was not amongst them. You might want to ask him to fax it again, in case 
it got lost somehow.


--
Martin Cooper



Thanks,

Simon

On Mon, 2005-07-11 at 16:50 +1200, Simon Kitching wrote:

Hi,

Brian sent his CLA in by post about 12 days ago. How can I check whether
it has been received/processed?

Thanks,

Simon


On Sat, 2005-06-25 at 22:50 +1200, Simon Kitching wrote:

The votes to elect Brian Stansberry as a committer for
jakarta-commons-logging are as follows:

+1 Dion Gillard
+1 Phil Steitz
+1 Robert Donkin
+1 Yoav Shapira
+1 Emmanuel Bourg
+1 Henri Yandell
+1 Simon Kitching

Brian is therefore elected (Brian has indicated privately that he is
willing to accept).


Brian, the first thing you need to do is complete a Contributor License
Agreement and send it in by mail or fax. Details are here:
  http://www.apache.org/dev/new-committers-guide.html

Once this is completed we can create a user account for you and arrange
the necessary access rights. Note that processing of CLAs can sometimes
take a week or two.

Your contributions to jakarta commons so far are very appreciated and we
all hope you'll enjoy being part of the commons community.

Regards,

Simon


-
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: [RESULT] Brian Stansberry as jakarta-commons-logging committer

2005-07-26 Thread Martin Cooper



On Wed, 27 Jul 2005, Simon Kitching wrote:


On Tue, 2005-07-26 at 19:49 -0700, Martin Cooper wrote:


On Wed, 27 Jul 2005, Simon Kitching wrote:


Hi,

Any sign of Brian's CLA having been received??


Nope, not yet. Jim added in a bunch of received iCLAs on 7/14, and Brian's
was not amongst them. You might want to ask him to fax it again, in case
it got lost somehow.


It was posted, rather than faxed. I don't believe the US post is that
slow is it??


Not usually. ;-) You might want to e-mail Jim. All I can tell you is that 
Brian's name isn't in the iCLAs file, and it didn't get added and then 
accidentally removed. Beyond that, I have no clue. For all I know, Jim 
might not have picked up from the PO box for a while, the CLA could be 
lying on his desk, or it could have fallen into a black hole. Sorry.


--
Martin Cooper





On Mon, 2005-07-11 at 16:50 +1200, Simon Kitching wrote:

Hi,

Brian sent his CLA in by post about 12 days ago. How can I check whether
it has been received/processed?

Thanks,

Simon


On Sat, 2005-06-25 at 22:50 +1200, Simon Kitching wrote:

The votes to elect Brian Stansberry as a committer for
jakarta-commons-logging are as follows:

+1 Dion Gillard
+1 Phil Steitz
+1 Robert Donkin
+1 Yoav Shapira
+1 Emmanuel Bourg
+1 Henri Yandell
+1 Simon Kitching

Brian is therefore elected (Brian has indicated privately that he is
willing to accept).


Brian, the first thing you need to do is complete a Contributor License
Agreement and send it in by mail or fax. Details are here:
  http://www.apache.org/dev/new-committers-guide.html

Once this is completed we can create a user account for you and arrange
the necessary access rights. Note that processing of CLAs can sometimes
take a week or two.

Your contributions to jakarta commons so far are very appreciated and we
all hope you'll enjoy being part of the commons community.

Regards,

Simon




-
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: [RESULT] Brian Stansberry as jakarta-commons-logging committer

2005-07-10 Thread Martin Cooper



On Mon, 11 Jul 2005, Simon Kitching wrote:


Hi,

Brian sent his CLA in by post about 12 days ago. How can I check whether
it has been received/processed?


I just checked, and it has not yet been recorded. I'll keep an eye out for 
it, though.


--
Martin Cooper



Thanks,

Simon


On Sat, 2005-06-25 at 22:50 +1200, Simon Kitching wrote:

The votes to elect Brian Stansberry as a committer for
jakarta-commons-logging are as follows:

+1 Dion Gillard
+1 Phil Steitz
+1 Robert Donkin
+1 Yoav Shapira
+1 Emmanuel Bourg
+1 Henri Yandell
+1 Simon Kitching

Brian is therefore elected (Brian has indicated privately that he is
willing to accept).


Brian, the first thing you need to do is complete a Contributor License
Agreement and send it in by mail or fax. Details are here:
  http://www.apache.org/dev/new-committers-guide.html

Once this is completed we can create a user account for you and arrange
the necessary access rights. Note that processing of CLAs can sometimes
take a week or two.

Your contributions to jakarta commons so far are very appreciated and we
all hope you'll enjoy being part of the commons community.

Regards,

Simon


-
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: [POLL] drop 8

2005-07-03 Thread Martin Cooper
+1

--
Martin Cooper


On 7/3/05, Phil Steitz [EMAIL PROTECTED] wrote:
 +1 to drop this
 
 Phil
 
 robert burrell donkin wrote:
 8. Packages are encouraged to either use JavaBeans as core objects, a
 JavaBean-style API, or to provide an optional JavaBean wrapper.
 
 
  doesn't seem very relevant. i think that it'd be simpler just to drop
  it.
 
  here's my +1
 
  - robert
 
  --8---
  [ ] +1 Get rid!
  [ ] -1 Keep it (please give a reason...)
  --
 
 
 
  -
  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: sandbox [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]

2005-07-02 Thread Martin Cooper
On 6/25/05, Stephen Colebourne [EMAIL PROTECTED] wrote:
 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.

+1

--
Martin Cooper


 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]



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

2005-07-02 Thread Martin Cooper
On 6/25/05, Stephen Colebourne [EMAIL PROTECTED] wrote:
 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.

+1. Let's ditch it.

--
Martin Cooper


 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]



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

2005-07-02 Thread Martin Cooper
On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote:
 On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
 
  4.1 in the guidelines repeats the error that I thought was fixed in the
  j-c guidelines saying that each package has its own mailing list.  If
  that is intentional, I think that is a *bad* idea, especially to start.
 
 it was intentional in as much as it was a copy of the jakarta commons
 charter :)
 
  Don't like the many little lists implied by 11 -- dev + user works fine
  in j-c (I know some disagree, but I personally view this as the key to
  the health of j-c)
 
 i agree. just dev and user lists.
 
 in jakarta commons, the common mailing lists hold together the single
 community. i'd like to see just one mailing list with components using
 prefixing (as per jakarta commons). i'd like to see changes to the draft
 so that it's clear that this will be the arrangement.
 
 opinions?

+1 to just one dev and one user list, shared for all components, a la
Jakarta Commons.

--
Martin Cooper


 - robert
 
 
 -
 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: new components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]

2005-07-02 Thread Martin Cooper
On 6/23/05, robert burrell donkin [EMAIL PROTECTED] wrote:
 On Wed, 2005-06-22 at 14:40 -0700, Phil Steitz wrote:
 
 snip
 
  Interpreted literally, 17 goes against standard practice in jakarta (or
  apache, to my knowledge, other than in the incubator).  I would
  recommend that new packages require existing committers to support them.
  I would at least recommend changing Anyone to Any apache committer.
   If an individual has already contributed enough to be voted in as a
  committer, then that should be done in a separate VOTE.
 
 this certainly doesn't reflect the current practise in the jakarta
 commons. though anyone can propose a new component, they really won't
 have any chance of winning a VOTE unless they have the support of
 existing committers.
 
 there is also the issue of the incubator: any new component bringing
 code from outside apache would need to be incubated.

We have a few different scenarios here, I believe.

1) A new component is proposed, with no existing code to back it up.
I'm not sure that this has ever happened in Jakarta Commons, or is
likely to happen in the new subproject, so frankly I don't much care
about how that would work. ;-)

2) A new component is proposed by an existing Apache committer. This
will almost certainly be backed up by code in the sandbox.
Historically, in Jakarta Commons, there hasn't so much been a
proposal, but rather a new project materialises in the sandbox. This
has, in part, been responsible for dregs that lie around forever. This
could be handled through the after 6 months vote that has been
mentioned in another thread.

3) A new component is proposed by a non-committer. Code to back up
such a proposal would necessarily be coming from somewhere else. This
is a situation in which the component should, I believe, come in
through the incubator. The incubation process would resolve the
questions of committers, etc., before the component lands in the new
subproject. (I want to emphasise here, for the folks that might be
concerned about this, that incubation need not be an onerous process,
and can happen rather quickly, if conditions are right.)

I would suggest that we come up with wording in the charter to reflect
these scenarios, rather than trying to crib from the Jakarta Commons
charter in this instance.

 is 19 needed in addition to 15?

This seems to be a different topic entirely, but my vote would be yes,
because 15 relates only to the proposal, while 19 relates to the
component as it exists, and is developed, within the subproject.

--
Martin Cooper


 - robert
 
 
 -
 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] subproject that's a home for bricks reusable in java web applications

2005-06-22 Thread Martin Cooper

Can we please separate the two different topics being discussed here?

The original purpose of this discussion was to see if there is general 
concensus that a Webapp Commons (or whatever name we end up with) is a 
good idea. If we think it is, then we need to develop a charter, come up 
with a name, and officially make the proposal to the PMC. We also need to 
discuss other aspects, such as whether or not we want to follow the 
Jakarta Commons model, with separate Proper and Sandbox components.


Once we've got to that point, we can have discussions about the various 
sources from which code might be contributed. Some of those will be from 
inside of Jakarta, or other ASF projects, and some might be from external 
sources. IMHO, the discussion of potential external sources and potential 
new ASF committers is premature at this point. I think we need to get off 
the ground first.


Finally, I'll point out that any substantive contributions would need to 
come in through the incubator. That being the case, we're not in any 
position to make judgements or promises, here and now, about what can be 
brought in and / or who may or may not become committers on the new 
subproject.


(Frank, I am *not* trying to shut you out. I'm simply trying to get the 
new subproject off the ground without complicating things by discussing 
external elements prematurely.)


--
Martin Cooper


On Wed, 22 Jun 2005, Frank W. Zammetti wrote:


robert burrell donkin wrote:

that's understandable but is likely to cause wrinkles in the approval
process. a subproject needs a name and a charter before it can be
approved. no guarantees could be offered since accepting new committers
is something that sould be delegated to the new community. 


I definitely see the conundrum.

You touched on something too that I hadn't even brought up directly... If I'm 
going to give up the name, and end my project and contribute all the code 
I've written, I don't think it is unreasonable to ask to be a committer on 
the new Jakarta project.


I may be mistaken, but I thought part of the approval process is a list of 
initial committers?  I thought I had seen that at one point on the new 
project proposal paperwork.  If so, I'd say that could take care of this part 
of things because I could be named a committer initially, then everything 
else as far as names and initial code goes falls in to place pretty easily.



anyone have any opinions about this?


If the above isn't true, one possible suggestion is to proceed with a 
contingent name... The contingency being the community accepting me as a 
committer.  There would still be a name in reserve if that should not happen.


I hope I'm not coming across like an a**hole here trying to worm my way in... 
I believe what I'm saying is reasonable, if anyone disagrees please feel free 
to tell me so.



if you could leave it a little while before changing the name of your
project to WP4J, that might give us some time to prepare the documents
in...


I actually didn't mean I would change my project name... In my mind, there 
are three possible paths here...


One is that the Jakarta project takes my name, and my projects ends and all 
the code is contributed.  Two is that the Jakarta project takes a completely 
different name and I still end my project and contribute all the code.  Third 
is that my project continues as-is and the Jakarta project takes a completely 
different name.


There is the fourth option of me changing my proejects' name and keeping in 
separate, but that presents problems for me at this point so I wouldn't be 
especially inclined to do that.  I suppose I wouldn't rule it completely out, 
but it would definitely be last on my list.


Frank


-
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: [ANNOUNCEMENT] Proposal For Jakarta Sub Project For Web Application Components

2005-06-22 Thread Martin Cooper



On Wed, 22 Jun 2005, robert burrell donkin wrote:


i considered posting this to one or more of the announcement lists in an
attempt to widen the audience but i didn't feel confident that it would
be appropriate or wise.

opinions?


IMO, it doesn't need to go to announcements lists at this point. People 
who are only on those lists are likely interested only in things that have 
become real. When (if) the subproject is created, it might be more 
appropriate, but I don't feel a proposal is right for [EMAIL PROTECTED]


I did, however, forward the message to taglibs-dev and taglibs-user, since 
they may end up with a vested interest in this.


--
Martin Cooper



- robert

On Wed, 2005-06-22 at 22:48 +0100, robert burrell donkin wrote:

There has been considerable interest over the last few weeks and months
concerning the possibility of a new Jakarta sub project similar to the
Jakarta Commons but aimed at independent reusable web application
components.

There are a number of matters which need to be discussed and ideas
developed. Anyone who is interested is invited to subscribe to the
general list at Jakarta (http://jakarta.apache.org/site/mail.html).

A start has been made at documenting some of these:
http://wiki.apache.org/jakarta/CreatingCommonsForWebComponents.

- robert


-
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: [Jakarta Wiki] Update of InterWiki by ManikSurtani

2005-03-30 Thread Martin Cooper
What's happened is that the wiki change notifications seem to be sent
to a separate list now ([EMAIL PROTECTED]) instead of where they were sent
before ([EMAIL PROTECTED]). This has also happened for some (all?) of the
other wikis. I'm assuming this change happened as part of the upgrade
to the newer wiki version. I've already put in a request to the
infrastructure folks to change this back to the way it was.

--
Martin Cooper


On Wed, 30 Mar 2005 23:48:13 +0100, Kevin Jones [EMAIL PROTECTED] wrote:
 I hate to do this as I know this is not an admin list but in the last few
 days I've started receiving these notifications that the wiki has changed. I
 haven't subscribed to this list so I'm assuming I was added 'accidentally',
 how do I get off the list?
 
 Kevin Jones
 http://public.xdi.org/=kevin.jones
 skype (www.skype.com): kevinrjones
 
  -Original Message-
  From: Apache Wiki [mailto:[EMAIL PROTECTED]
  Sent: 30 March 2005 23:32
  To: Apache Wiki
  Subject: [Jakarta Wiki] Update of InterWiki by ManikSurtani
 
  Dear Wiki user,
 
  You have subscribed to a wiki page or wiki category on
  Jakarta Wiki for change notification.
 
  The following page has been changed by ManikSurtani:
  http://wiki.apache.org/jakarta/InterWiki
 
  --
  
List of valid InterWiki names this wiki knows of:
  [[InterWiki]]
 
  - Subprojects under Jakarta that have wiki pages:
  + Subprojects under Jakarta that do not have wiki sites of
  their own (under http://wiki.apache.org) but have a few wiki
  pages under this wiki:
   JakartaRegexp
 
MoinMoin marks the InterWiki links in a way that works for
  the MeatBall:ColourBlind and also is MeatBall:LynxFriendly by
  using a little icon with an ALT attribute. If you hover above
  the icon in a graphical browser, you'll see to which Wiki it
  refers. If the icon has a border, that indicates that you
  used an illegal or unknown BadBadBad:InterWiki name (see the
  list above for valid ones). BTW, the reasoning behind the
  icon used is based on the idea that a Wiki:WikiWikiWeb is
  created by a team effort of several people.
 
 
 -
 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: future for maven generated websites?

2005-03-27 Thread Martin Cooper
I believe you're really talking about deployment, rather than
generation. I doubt that any changes will be needed in generation
itself. The current hand-wavy answer on updating web sites when shell
accounts go away is WebDAV. I'm not sure if anyone has thought this
through yet, though - when I asked for more detail, the answer was
essentially dunno yet. So I guess we'll have to wait and see,
although if you have suggestions / want to keep up to date,
infrastructure@ is the place to be.

--
Martin Cooper


On Sun, 27 Mar 2005 11:29:28 +0100, robert burrell donkin
[EMAIL PROTECTED] wrote:
 does anyone have a plan to cope with rebuilding maven based websites
 when shell access is switched off to the machine serving the website?
 
 will we be able to run regular maven site regeneration on a
 jakarta.apache.org partition?
 
 - robert
 
 -
 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] build.xml includes force=true

2005-03-24 Thread Martin Cooper
On Thu, 24 Mar 2005 17:19:49 +, sebb [EMAIL PROTECTED] wrote:
 On Thu, 24 Mar 2005 09:06:33 -0500 (EST), Henri Yandell
 [EMAIL PROTECTED] wrote:
 
  Sorry, meant to replyt on this stuff last night but it turned into a
  mildly late one at work, followed by the usual household chores.
 
 No problem.
 
  I think the problem was that it was not noticing when the navigation was
  being changed, so somebody added a force.
 
 OK, I see.
 
  Although it causes it to build everything, SVN's seems to handle it and
  notices the 1 or 2 files that have actually changed. Under 1.5 it builds
  so quickly (10-ish seconds on my P3 1Ghz) that it's not seemed a big deal.
 
 Yes, it builds quickly enough.
 
 I must admit I did not dare try committing all the files to SVN, as I
 did not want to generate huge diff listings...
 
 Ideally the files would not be recreated, as there must be quite a bit
 of overhead in sending the files back to SVN for it to ignore them,
 but unless the overlooked dependency can be fixed, I guess it all
 needs to be rebuilt.

Actually, I would not expect those files to be sent to the SVN server
at all, since diff is a local operation. (One of the big advantages of
SVN. ;)

--
Martin Cooper


  Hen
 
  On Thu, 24 Mar 2005, sebb wrote:
 
   build.xml was updated in r128387 to add force=true to all the 
   transformations.
  
   Is this needed?
   [The log does not say why it was added].
  
   It causes files to be always out of date with respect to the SVN copies.
  
   Seems to me it should either be removed - or at least be made a property?
  
   S.
  
   -
   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: Javadoc management

2005-03-15 Thread Martin Cooper
On Wed, 16 Mar 2005 00:49:08 -0500 (EST), Henri Yandell
[EMAIL PROTECTED] wrote:
 
 Interested in finding out if anyone else thinks this would be a good idea.
 
 Rather than have each subproject managing their release javadocs
 separately, I think it would be good if we treated the javadoc more like
 the releases. Located in a central location, perhaps mirrored, all
 versions available and perhaps with additional tools like ashkelon or
 multidoc to bring them together.

Sounds good to me (assuming you mean all *released* versions
available). On download pages, we could have binaries, sources and
javadocs, with options for javadocs being download or view online (a
bit like Sun's download pages). We might not need to mirror right away
- we could wait to see how much this gets used.

I'm not familiar with ashkelon or multidoc. What would they bring to the party?

--
Martin Cooper


 Subprojects would still be hosting their latest cvs head javadocs
 internally, but they would deploy a versioned javadoc as a part of
 releasing, and we wouldn't end up with the issue where users cannot view
 the latest released javadoc due to a site rebuild etc.
 
 Javadoc seems less important for some projects, Taglibs and Tomcat leap to
 mind, so it may not apply for all (though seeing a tag doc in javadoc
 style would rock).
 
 Anyway. Looking for community interest. If there, I'd make it my 2005 Q2
 task, probably along with trying to hassle on LGPL stuff again.
 
 As it's my current weapon of choice, I'd probably end up with an xml/xslt
 solution much like the download stuff, so feel free to point out that that
 wasy crap.
 
 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: Problems under 1.5 Was: [site] New Jakarta download pages

2005-02-22 Thread Martin Cooper
On Tue, 22 Feb 2005 14:09:48 -0500, Howard Lewis Ship [EMAIL PROTECTED] wrote:
 I think we should not be checking in derived files.

One of the reasons for that is so that anyone on the infrastructure
team can quickly replace the site if it is corrupted or vandalised
somehow. They should not have to go through a build process before
they can do that.

--
Martin Cooper


 I think the process should be:
 1) Build and test locally
 2) SVN checkin
 3) Log into jakarta
 4) SVN checkout
 5) Build to staging area; test stage
 6) Build to production; test production
 
 The build.xml needs to have targets:
 build -- local build (to target/site)
 build-stage -- to /www/jakarta-stage.apache.org ?
 build-prod - to /www/jakarta.apache.org
 
 The build scripts can be smart about setting file permissions  etc.
 
 On Tue, 22 Feb 2005 12:42:45 -0500 (EST), Henri Yandell
 [EMAIL PROTECTED] wrote:
 
 
  On Tue, 22 Feb 2005, Stefan Bodewig wrote:
 
   While it was using XSLTC, which is the TraX processor shipping with
   JDK 1.5.  We now switched to Xalan-J's CVS HEAD.
 
  I give up :)
 
  How would I force it to be dependent on a particular version of Xalan?
 
  Along with the problems with .cgi files and xhtml, xsltc appears to sort
  the attributes of a html tag differently so if we have 1 person using 1.4
  and 1 using 1.5, our diffs are going to be spammed by attributes rotating
  back and forth.
 
  Throw in possible worries that the http:// url was causing problems under
  1.4 and it seems to not be worth the trouble.
 
  Hen
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 --
 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: [site] bug update

2005-02-22 Thread Martin Cooper
On Wed, 23 Feb 2005 00:41:38 -0500 (EST), Henri Yandell
[EMAIL PROTECTED] wrote:
 
 After grumbling out loud, my wife pointed out I was being an idiot. So a
 quick bit of scripting hackery and a very one-off link checker is off and
 running.
 
 Jakarta downloads at about 560Meg by the way :)
 
 A bunch more fixes made. From svn:
 
 Configuration had a typo 'commons-commons'. Daemon doesn't have commons-
 at the front. DBCP had typo of version number, I did 2.1.1 instead of
 1.2.1. JEXL doesn't have binaries/source directories. Modeler doesn't have
 commons- at front. Transaction uses .tgz. ECS had -src in wrong place.
 JMeter uses _src. Lucene had -src in wrong place. ORO doesn't have a -src
 at all in its src download. Slide had duplicated extra bad lines and the
 jca link was typo'd.
 
 md5/pgp turned off for cli. md5 turned off for jexl. nightly link fixed
 for transaction. md5 turned off for tomcat 3. Fix to turbine nightly
 build.
 
 Known problems:
 
 * Chain, IO, Transaction, Validator use .MD5 instead of .md5

I think this is an Ant vs. Maven issue, although I don't recall which
way around.

 * ORO uses .sig instead of .asc

This might be a PGP vs. GPG issue. I use PGP, but rename the generated
files from .sig to .asc.

--
Martin Cooper


 * JEXL has no KEYS file
 * Turbine is quite fubar'd (was in binindex too). Out of date. Missing
lots of entries.
 * ECS .asc files are fubar'd, they appear to be binary.
 
 Hen
 
 On Tue, 22 Feb 2005, Henri Yandell wrote:
 
 
  While I futz my way along fixing things, thought I'd disclose which bugs 
  have
  existed today.
 
  Couple of hours between 7 and 9am EST we had problems due to JDK 1.5 and
  unpredictability of building on other people's environments. Solution will 
  be
  to hardwire a Xalan dependency.
 
  All Commons -src downloads were screwed. I c+p'd the -src into the wrong
  place in the filename.
 
  Bug in group of group md5/pgp's meant those links failed for 5 download
  pages. HttpClient, Collections, Tomcat 5, Hivemind and Tomcat-Connectors 
  were
  affected.
 
  Wrong information on the original binindex page for mod jk 1.2. Fixed now.
 
  HttpClient binary download was broken due to difference in url from other
  Commons projects (binary rather than binaries).
 
  -
 
  I'm slowly checking all the links to make sure they're ok.
 
  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: FW: PMC contact for Wiki Admin

2005-02-17 Thread Martin Cooper
On Thu, 17 Feb 2005 14:35:59 -0800, Tim Colson (tcolson)
[EMAIL PROTECTED] wrote:
 Hello Most Reverent and Kind Jakarta Gentlefolk :-)
 
 I have a suggestion/request and it seems this might (or might not) be
 the place to suggest/request it. :-)
 
 As per below... I'd like to request the MoinMoin wiki be upgraded to
 1.3.x.

You'd need to take this up with the infrastructure team
([EMAIL PROTECTED]). There has been some discussion of upgrading
MoinMoin, and the most likely target at this point seems to be 1.2.4.
IIRC, there was some resistance to go to 1.3.x, I think because there
were bigger implications. But infrastructure@ is the place to get the
real scoop.

--
Martin Cooper

 
 Personally I'd love to see Confluence replace the Python Moin Moin,
 since Confluence is written in Java, shows off Jakarta through the use
 of many Jakarta packages, and shows support open source projects by
 being FREE for them.
 
 But barring that... I'd really like to see the upgrade to MoinMoin
 happen because the wiki is becoming a huge benefit for collaboration on
 the Velocity and Velocity Tools projects.
 
 I realize Apache is a volunteer org and we all know this is stuff we all
 do in our not so copious free time -- but I'd really like to know
 how/where/who admins the MoinMoin install and offer to help in any way I
 can.
 
 Cheers,
 Tim Colson, Geek
 
 P.S. If you suggest something it is a suggestion, but if you request
 something, why isn't it a requestion? grin
 
  -Original Message-
  From: Will Glass-Husain [mailto:[EMAIL PROTECTED]
  Sent: Thursday, February 17, 2005 10:43 AM
  To: Velocity Developers List
  Subject: Re: PMC  contact for Wiki Admin
 
  Velocity doesn't have a PMC since it's not a top level
  project.   Our PMC is
  the Jakarta PMC.  Many of the committers (but not me) are
  members of the
  PMC.
 
  I can't seem to find the address for the pmc mailing list.
  You might use
  general@jakarta.apache.org as a substitute (although it's a
  public list).
  That might be a good place to advocate for this anyway.
 
  WILL
 
  - Original Message -
  From: Tim Colson (tcolson) [EMAIL PROTECTED]
  To: Velocity Developers List velocity-dev@jakarta.apache.org
  Sent: Thursday, February 17, 2005 9:28 AM
  Subject: PMC  contact for Wiki Admin
 
 
  So I'm not in the Know on this one... i.e. WHO is the admin for the
  MoinMoin stuff?
 
  I searched to try and figure it out, also tried to figur out
  how to make
  requests for MoinMoin other than create a new site...
 
  Seems the only way will be to send an email to the
  infrastructure alias
  at apache ...and cc the PMC (who IS that for Velocity these
  days? Will?)
 
  http://wiki.apache.org/general/HowToMakeWikiAdminRequests
 
  What I want to request: upgrade MoinMoin to 1.3.x ...while
  not as spiffy
  as Confluence, at least it's a HELLUVALOT better than the current
  version 1.1.x.
 
  Lots of detailed observations on what's improved here:
  http://confluence.atlassian.com/display/DISC/Comparison+Matrix
 
  Cheers,
  Timo
 
  -
  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: [VOTE] [site] New download pages

2005-02-17 Thread Martin Cooper
Looks good to me, apart from the not-working-ness. ;-)

+1

--
Martin Cooper


On Thu, 17 Feb 2005 19:47:37 -0500 (EST), Henri Yandell
[EMAIL PROTECTED] wrote:
 
 I'd like to go ahead and move to my suggested new download pages:
 
 http://jakarta.apache.org/~bayard/jakarta/site/downloads/downloads.html
 
 [ ] +1
 [ ] -1
 
 or alternatively:
 
 [ ] +1, but fix this first: [ ]
 
 Currently the filenames match the names on the binindex.cgi page, I'm
 trying to stay as close as possible to the current site before making any
 other changes. It's easy enough to then do things like change 1.0.zip to
 hivemind-1.0.zip as Howard suggested.
 
 Post change, I'll focus on improving the Taglibs page to match the Commons
 one in style.
 
 72 hour consensus vote. ie) a single -1 is a veto.
 
 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: [site] Odd Ant question

2005-02-13 Thread Martin Cooper
I haven't tried it, but how about this:

* Use subant with 'genericantfile' (referencing the same build file)
and a dirset for the directories you want.

* In the target invoked by subant, use available to determine
whether or not the HTML file exists, and invoke another target that
only runs 'if' the property is set. That second target would do the
copy.

* Use pathconvert to generate the name of the CGI file based on the
name of the HTML file.

--
Martin Cooper


On Sun, 13 Feb 2005 21:38:32 -0500, Henri Yandell [EMAIL PROTECTED] wrote:
 Before I lug myself off to the Ant lists, thought I'd ask here.
 
 I'm trying to come up with a way to make the cgi work for the
 downloads pages. One way would be to rewrite the cgi, have it take
 arguments and be more dynamic. Another easier way would be to simply
 copy the cgi file lots of times (as it's already been copied many
 times already).
 
 To do this copying, I basically want to do the equivalent of:
 
 ---
 For each downloads_*.html file
   copy downloads.cgi downloads_*.cgi
 
 
 Any idea how I do that in Ant? Mappers seem like they'd want to be
 copying the html file to the cgi file; ie) wildcard in to and from.
 There's no for loop, so not sure how I'd do such a thing.
 
 Maybe one way would be to call a target on each file in a list of files.
 
 Any ideas?
 
 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: [site] Removing things

2005-01-08 Thread Martin Cooper
On Fri, 7 Jan 2005 20:50:28 -0500 (EST), Henri Yandell
[EMAIL PROTECTED] 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.

I haven't kept up with all of the discussion in the last few days -
why are we removing this? IMHO, it's still valuable for the less
frequent visitor to our site.

 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.

This seems to me like an important thing to have stated up front. If
what we have now isn't what we think we're about, we should fix it
rather than removing it. If we don't think we can fix it, then we have
a serious problem. ;-)

--
Martin Cooper


 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]



Re: [site] Removing things

2005-01-08 Thread Martin Cooper
On Sat, 8 Jan 2005 17:28:34 -0500 (EST), Henri Yandell
[EMAIL PROTECTED] wrote:
 
 
 On Sat, 8 Jan 2005, Martin Cooper wrote:
 
  On Fri, 7 Jan 2005 20:50:28 -0500 (EST), Henri Yandell
  [EMAIL PROTECTED] 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.
 
  4) Removal of Graduated from the left navbar.
 
  I haven't kept up with all of the discussion in the last few days -
  why are we removing this? IMHO, it's still valuable for the less
  frequent visitor to our site.
 
 Graduated is a confusing concept that we then have to somehow explain.

Then let's just call it Ex-Jakarta.

 Additionally, how long would we maintain links to said projects etc?

6 months to a year.

Let me ask the reverse question: How long would you keep the link to a
subproject once it leaves? Would you remove it as soon as the project
leaves, or keep it around for a while? If the latter, why wouldn't you
move it to an Ex-Jakarta section instead?

 I think Graduated is best replaced by:
 
 News item on graduation that stays prominent for a few months. Some kind
 of larger [EMAIL PROTECTED] page.

It's not clear to me that people will go and read the News section if
they can't find the link to the subproject. After all, if there's no
link, then it can't be a Jakarta subproject, so why would there be
Jakarta news about it?

--
Martin Cooper


  7) Removal of Our Mission. Redirect to front page.
 
  This seems to me like an important thing to have stated up front. If
  what we have now isn't what we think we're about, we should fix it
  rather than removing it. If we don't think we can fix it, then we have
  a serious problem. ;-)
 
 It's a pointless page. The Welcome + Navbars contains all the information
 it has, so it just adds to the general clutter.
 
 Hen


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



Re: [site] Removing things

2005-01-08 Thread Martin Cooper
On Sat, 8 Jan 2005 19:38:17 -0500 (EST), Henri Yandell
[EMAIL PROTECTED] wrote:
 
 
 On Sat, 8 Jan 2005, Martin Cooper wrote:
 
  On Sat, 8 Jan 2005 17:28:34 -0500 (EST), Henri Yandell
  [EMAIL PROTECTED] wrote:
 
 
  On Sat, 8 Jan 2005, Martin Cooper wrote:
 
  On Fri, 7 Jan 2005 20:50:28 -0500 (EST), Henri Yandell
  [EMAIL PROTECTED] 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.
 
  4) Removal of Graduated from the left navbar.
 
  I haven't kept up with all of the discussion in the last few days -
  why are we removing this? IMHO, it's still valuable for the less
  frequent visitor to our site.
 
  Graduated is a confusing concept that we then have to somehow explain.
 
  Then let's just call it Ex-Jakarta.
 
 Seems okay :) I'll promote this suggestion to a new thread, see if anyone
 disagrees.
 
  Additionally, how long would we maintain links to said projects etc?
 
  6 months to a year.
 
  Let me ask the reverse question: How long would you keep the link to a
  subproject once it leaves? Would you remove it as soon as the project
  leaves, or keep it around for a while? If the latter, why wouldn't you
  move it to an Ex-Jakarta section instead?
 
 Spent an hour pondering it, and I'm swayed by your arguments.
 
 I'm happy too keep the links to old Jakarta sites. The only real problem
 it causes us is when things get closed (Avalon), but those projects should
 have sites kept up anyway.

And hopefully what happened with Avalon won't happen very often...

 By News section, I'd meant the front page. Given the tighter mock, an item
 in the news section of the front page is pretty prominent, but it's
 probably more valueable spacewise than the bottom left of the navbar, so
 maintaining links to ex-jakarta is much better.
 
  7) Removal of Our Mission. Redirect to front page.
 
  This seems to me like an important thing to have stated up front. If
  what we have now isn't what we think we're about, we should fix it
  rather than removing it. If we don't think we can fix it, then we have
  a serious problem. ;-)
 
  It's a pointless page. The Welcome + Navbars contains all the information
  it has, so it just adds to the general clutter.
 
 Any comment on this? Can 'Our Mission' go?

I guess so. It just feels like something we should have, but, as you
mentioned, we don't really have much of anything to say at the moment.

--
Martin Cooper

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



Re: [site] clean up

2005-01-06 Thread Martin Cooper
On Thu, 6 Jan 2005 17:57:38 +, robert burrell donkin
[EMAIL PROTECTED] wrote:
 On 6 Jan 2005, at 09:09, Danny Angus wrote:
 
  Robert,
 
  and is any planning needed so that no toes are stepped on?
 
  An advance heads-up would warn other projects which might link to those
  pages. Though as a redirect wouldn't break the links I guess its not
  that
  important, James has been bitten by Jakarta changes before, though I
  hasten
  to add it is James' own fault for not moving quick enough, and anyway I
  don't think this would affect James.
 
 it's hard to know which projects links to jakarta and where would be
 the right place to post any advance warning. so, though i definitely
 take your point, i'm not sure that there's much that can be done.

I wonder if there's a link checker doodad that we could run on *.a.o,
perhaps as a cron job, and have it send out Gump-like nag messages
when something breaks?

--
Martin Cooper


 i do try to ensure that any changes i make do not break links. the
 redirects should ensure that this doesn't happen.
 
 what i will try to do is to collect and collate the changes (once
 there's a reasonable number) and post an email to community detailing
 the new pages and together with the redirected pages from jakarta. this
 should allow projects which may be linking to redirects to update their
 links.
 
 - robert
 
 
 -
 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: Last call for comments Was: [site] next step - 3-tier + welcome

2005-01-05 Thread Martin Cooper
On Thu, 6 Jan 2005 00:19:37 -0500 (EST), Henri Yandell
[EMAIL PROTECTED] wrote:
 
 http://www.apache.org/~bayard/jakarta-3tier.html
 
 Rolled back to remove the table-div header change for the moment. I'd
 like to go ahead and make the change to a 3 column on Friday.

Looks OK to me. I'd say go for it.

There are a couple of tweaky things - like the font seems a little
bigger than it needs to be, and the section headers are different from
the main ASF site - but they really are tweaky things that we can talk
about and fiddle with later.

--
Martin Cooper


 Any nay-sayers before then, let me know.
 
 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: jakarta-site2 now live on xslt

2005-01-03 Thread Martin Cooper
On Mon, 3 Jan 2005 09:02:23 -0500 (EST), Henri Yandell
[EMAIL PROTECTED] wrote:
 
 
 On Mon, 3 Jan 2005, sebb wrote:
 
  On Sun, 2 Jan 2005 19:15:59 -0500 (EST), Henri Yandell
  [EMAIL PROTECTED] wrote:
 
 
  On Sun, 2 Jan 2005, sebb wrote:
 
  Looks like a *lot* of other projects use the Anakia jars and/or
  stylesheets from jakarta-site2 - not just jakarta-tomcat-site...so
  perhaps those need to be restored.
 
  Sites with the older lf:
 
  Taglibs, Velocity, BSF, ECS, JMeter, Lucene, ORO, Regexp, Slide, Tomcat,
  Watchdog.
 
  However, the following all appear to be self contained/non-users:
 
  Taglibs, Velocity, BSF, Watchdog, Slide.
 
  Sorry, should have remembered that, as it used to apply to jmeter...
 
  + JMeter.
 
  So the broken ones look like they are Tomcat, Regexp, ORO, Lucene, ECS.
 
 
  I did a search for the string jakarta-site2 in the build.xml,v files
  in CVS, and that produced quite a lot of hits (see
  http://www.apache.org/~sebb/js2.txt - note that the matched text is
  *followed* by the file name).
 
  Some of the matches relate to history items, but some are in the HEAD
  versions of the files, for example:
 
  http://cvs.apache.org/viewcvs.cgi/ant/proposal/ant-site/anakia/build.xml?only_with_tag=HEADview=markup
 
  http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/build.xml?only_with_tag=HEADview=markup
 
  Of course we don't know if the build targets are actually still used,
  but it suggests that these files are rather more generally used.
 
 Both HttpClient and Ant appear to use Maven or Forrest for their sites
 though, so I'd think it's a pretty low chance that they still use things.
 
 I think all of Commons is Mavenised, and I checked all of Jakarta in this
 way to find old style lf and then examined those by hand. Looking at the
 graduated projects, Struts and James still look old style; so they've got
 a good chance of still using site2.
 
 Looking at them, both Struts and James appear to be on XSLT variants, but
 no use of the site2 jars or stylesheets.

WRT Struts, it does not depend on site2. Its site generation is self-contained.

--
Martin Cooper


 Still, not to say that others in your list don't use it, such as jyve or
 various proposals in James etc, just nothing 'big' I think.
 
 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: 3-column jakarta.apache.org?

2004-12-30 Thread Martin Cooper
On Fri, 31 Dec 2004 00:26:15 -, Stephen Colebourne
[EMAIL PROTECTED] wrote:
  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?

Because resource information for projects that have moved away are no
longer found on the Jakarta site. For example, going to the Jakarta
mailing lists page is not going to help you find information on the
Struts mailing lists. I believe the distinction is important to
helping users find what they're looking for.

 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.

We (meaning Hen ;) just got done cleaning up a bunch of related
links that didn't seem particularly coherent, so I'd be against
putting it right back again. ;-)

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

I suggested Alumni but I don't think I got any takers. It seemed
like the logical noun to replace Graduated to me. IMO, Related is
too broad, and it was being misused before.

--
Martin Cooper


 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]



Re: 3-column jakarta.apache.org?

2004-12-29 Thread Martin Cooper
On Wed, 29 Dec 2004 14:01:27 -0500 (EST), Henri Yandell
[EMAIL PROTECTED] wrote:
 
 Here's my mockup proposal:
 
 http://www.apache.org/~bayard/mock-jakarta-frontpage.html
 
 Changes:
   3 column
   Strikethrough of links/pages I'd like to kill.
   Less news.
   Removal of Related section (aim is to make this a new page).
   Rewrite of the welcome message to hopefully say the same main thing,
but use a lot less space.

This looks OK. The one thing I would change, though, is to get rid of
the indentation under the headings (which would probably necessitate a
slightly larger gap between the columns). As it is now, with the
indent, the center text - and especially the table - becomes a rather
tall, skinny column in a default-sized browser window.

 The aim would also be to switch entirely over to the XSL build version
 which seems to work fine and dump Anakia creation.

+1

--
Martin Cooper


 Hen
 
 On Wed, 29 Dec 2004, Henri Yandell wrote:
 
 
  I'm a fan of the www.apache.org look and how it gives us a lot more 
  usability
  in terms of available column space. I'd like to change Jakarta to the
  3-columns (though not the lf or anything).
 
  Switching to 3-columns means less space in the center for content, however I
  also want to simplify the content so I think it will look fine.
 
  Any views?
 
  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: Mess in jakarta.apache.org/

2004-12-29 Thread Martin Cooper
I zapped the 'userGuide' file.

I don't see any point in keeping old sites that are being redirected
away from anyway. Unless I'm mistaken, nobody will ever see them.
However, it would be good to check with the projects that have moved
away from Jakarta, to make sure, since they may not be monitoring this
list, and they just might care. ;-)

Anything obviously broken or dead should go. Not sure what's left after that.

--
Martin Cooper


On Wed, 29 Dec 2004 00:52:45 -0500 (EST), Henri Yandell
[EMAIL PROTECTED] wrote:
 
 Worringly, this is just the flotsam lying around at the top level :)
 
 What on this list cannot be rm -r'd? There's usually one or two important
 ones in the pile of junk, so I'll be relatively careful.
 
 BUGS/
Copy of a CVS/. Odd.
 bcel.org/
Old copy of BCEL site.
 broken/
A maven repo by the looks of it.
 builds/
Old build system. Seems somewhat empty and broken. How long to maintain?
 buildsite.sh
Something to do with TAC. Dead way to build site.
 cjan/
Dead java-repo for pre-cursor to Maven.
 commons-mavenized/
Old test Commons site.
 cvsweb/
Broken symlink.
 gump/
Entire site, though htaccess is redirecting. How long to maintain this?
 index-new.html
Dead copy of index.html
 jakarta-gnats.tar.gz
Dead bug tracking system.
 jjar/
Dead java-repo for pre-cursor to Maven.
 jmeter201/
Copy of JMeter site. Bizarrely seems to be kept up to date.
 log4j/
Entire site, though htaccess is redirecting. How long to maintain this?
 main.template
Old dead file.
 ojb/
A simple redirect. How long to maintain this?
 oldsite.tar.gz
Dead old file.
 pluto/
Entire site, though htaccess is redirecting. How long to maintain this?
 phoenix/
Broken symlink.
 resources
A struts file. Odd.
 struts/
Entire site. Redirecting so not viewable. How long to maintain this?
 tac.jar
Something to do with TAC. Dead way to build site.
 tomcat-4.0/
Bizarre. An installation of Tomcat 4.
 tomcat-old/
Old copy of Tomcat site.
 turbine.old/
Old copy of Turbine site.
 userGuide
A struts file. Odd.
 
 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: 3-column jakarta.apache.org?

2004-12-29 Thread Martin Cooper
On Wed, 29 Dec 2004 21:41:00 -0500 (EST), Henri Yandell
[EMAIL PROTECTED] wrote:
 
 
 On Wed, 29 Dec 2004, James Mason wrote:
 
  Henri,
 
  Looks good. Big improvement, I think :). I especially like how the third
  column brings more information above the status bar. A few comments:
 
 Thanks :)
 
  1) The first paragraph sounds more like it's describing the ASF than
  describing Jakarta. A suggestion:
 
  -
  The Jakarta Project offers a diverse set of open source Java solutions
  and is a part of [The Apache Software Foundation] (ASF). Like all ASF
  [projects] Jakarta encourages a collaborative, consensus-based
  development process under an [open software license].
  -
 
 It actually is meant to be describing the ASF :) To cut down on text, I
 threw away 'jakarta, like all ASF, encourages...' to the simpler 'ASF
 encourages'. It's just as true and uses less space. I'd like to dump 'for
 all its projects' to be honest, but didn't want to lose the link to the
 ASF Project page.
 
 It's tempting to chop the last 4 words and add a ASF link on the right,
 together with the other ASF ones, under a new heading of About Apache or
 something.
 
  2) The first sentence of the second paragraph seems awkward to me. It's
  not immediately apparent why that information is useful. If I don't know
  what a TLP is it doesn't really help me, and if I'm looking for a TLP
  that used to be part of Jakarta it doesn't tell me how to find it.
  Unfortunately I haven't been able to come up with a better wording.
  Hopefully someone else is feeling inspired :).
 
 Two big parts I'm looking for in this paragraph.
 
 1) Jakarta = umbrella project. I don't want to say umbrella as that's an
 odd metaphor to the uninitiated.
 
 2) Definition of graduating, attempt at an explanation of why projects are
 no longer to be found in Jakarta (a common user confusion I think). The
 TLP acronym isn't highly important (at first I thought it was good to get
 it accross, but it's too much info). Linking to the bit above, I could
 dump the TLP acronym and make this the link to the ASF project page.
 
  3) Graduated on the left needs to be in the context of a noun. Maybe
  swapping the left and right columns (leaving About on the left) and
  making the right column Projects with subheadings of Subprojects and
  Graduated? That might take up too much space, though.
 
 Gah! Much as I want to scoff at the suggestion for the pain it causes, I
 think you're right, to be correct it should be a noun.
 
 Putting the projects on the right was an option, but I think that
 consumers will mostly want to click through to a subproject, rather than
 any other link there and the LHS is the prime navigation spot.
 
 It also matches the www.apache.org approach, which is nice for the
 symmetry of a user clicking through and not having to adjust their
 navigation flow.
 
 Possibly I could change Graduated to Graduated Subprojects? Seems a bit
 long. 'Graduates' seems wrong. Looking for a good label here :)

Alumni?

--
Martin Cooper


  4) Removing the margin from the ul that makes up the news would help
  spread that section out a bit.
 
 Yep. I'm going to hassle a few web designers I know on spacing issues once
 I've updated the XSL build to output this site. All their suggestions will
 involve CSS, so I'll need to have a CSS sheet by then I suspect.
 
 Thoughts?
 
 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: Cleaning up Site2

2004-12-28 Thread Martin Cooper
On Tue, 28 Dec 2004 00:35:08 -0500 (EST), Henri Yandell
[EMAIL PROTECTED] wrote:
 
 The jakarta-site2 module is horrendously old, overpowered and creaky.
 There's support in there for using xml/xsl-html instead of anakia, and
 support for printable pages.
 
 I'm not sure the use of Anakia is even justified given the limited amount
 that is being done.
 
 In increasing order of effort level:
 
 1) Running ant doc_print, I can't say I'm too excited by the printable
 page version. I'd like to scrap it.

Fine with me. I had no idea it was there. ;-)

 2) There's an XSL variant of the site generation which may be used instead
 of Anakia. It's not used afaik and I think it should be ditched; except
 that:
 
 3) Are we really using Anakia enough to make it worth it? It seems to me
 that it could easily be replaced with CSS and a single Java class to kick
 off a simple XML/XSL conversion of each xdoc to a doc. Even that might be
 overkill as I suspect we could just have regexp search and replace to
 achieve the same goal.

I would be +0 for just using Ant's xslt (a.k.a. style) to kick off
a simple XSLT conversion along with a CSS stylesheet. (I would be +1
if I was more practised in the use of these myself.) This is how we
generate the Struts documentation, and it's worked well for us. Also,
I suspect that using XSLT instead of Anakia would open up the
possibility of more contributors, and using CSS would allow for some
folks to come up with a much snazzier site much more easily.

 4) What should the min JDK be for building the Jakarta site? Is there any
 reason why it can't be 1.3/1.4 (whichever one gets sane XML-wise). ie) The
 lib/ directory should not be needed.

I'd say just require JDK 1.4 and a recent version of Ant, and you're
all done. The lib directory can go.

 5) Really contraversial: Killing dead pages. idiot.html, jars.html,
 ide*.html, os.html, and of course jon.html. Probably other pages too.

No opinion on this one.

 6) Less contraversial (as no mention of Jon or idiots): Kill vendors page?
 How about legal and acknowledgements? Should these be under the ASF
 umbrella level now and not Jakarta specific.

If there's stuff that makes sense to move to the main ASF site, then
we should do that. Other stuff, like perhaps the vendors page, might
make more sense on the wiki. I'd be leery of moving too much out,
though, since I suspect a lot of people don't think to look outside
the Jakarta site for help.

 7) Needs moving Geir: 'Apache on the JSPA'; jspa-position.html.
 
 8) Faqs is something I would merge in with my 'one page index' idea with
 cvs/svn, javadoc, jars, source, binary, issue-tracking, mailing lists,
 wiki. I admit I may not get it all on one page :) The challenge is how to
 make a 50 x 10 table look good.

The FAQs page is pretty big all by itself. Not sure how you're going
to manage incorporating that into a 'one page index', but I'll look
forward to seeing what you come up with. ;-)

--
Martin Cooper


 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: Jakarta download pages Was: download pages in j.a.o.

2004-12-28 Thread Martin Cooper
On Mon, 27 Dec 2004 23:27:51 -0500 (EST), Henri Yandell
[EMAIL PROTECTED] wrote:
 
 I spent a fair while walking circles in the basement (carrying the unhappy
 baby) and thinking on the download pages.
 
 My first thoughts were on what they exist for. From an info-arch point of
 view, they are a search system in addition to the project pages
 themselves. The fact that the project pages link back to them is a mistake
 on the usability side (though does make our lives fractionally easier).
 
 My next thought is, why are there separate pages for mailing lists, source
 code, cvs repositories, binaries? A lot of information is repeated in
 attempting to provide navigation to get to the part desired. One reason
 for the separate pages is so that separate information may be obtained,
 but I believe there is a different solution to that one.
 
 So as a general direction, I think we should have a single project summary
 page that provides the links to all the relevant resources. This does give
 us a problem with how to handle the context sensitive message of how to
 use the resource. I think that closer.cgi has the solution there:
 
 For example:
 
 http://www.apache.org/dyn/closer.cgi/maven/binaries/maven-1.0.2.exe
 
 It has problems. Mainly in that it doesn't really provide much a context
 sensitive message. It should be mentioning signatures, keys, md5s etc. It
 also loses the navigation of the project it's on and dumps you into a
 global Apache navigation. However, I think it's the right solution
 architectually. A dynamic page that contains a standard message and is
 filled with dynamic info.

I actually think that page is horrible. Almost the entire page is
filled with stuff the user doesn't care a whit about - a big list of
mirror sites. The vast majority of users don't care about mirror
sites, they just want to download what they want. The list of mirror
sites should be stashed away in a drop-down list, as we have it now.

I think, if we had a standard template for download pages, each
subproject could have its own download page, something like we have
for Struts:

http://struts.apache.org/download.cgi

this would be a more workable approach. I don't see a need to have one
page with all of the available downloads (with the possible exception
of Commons, but I'm not sure we need that either).

 So I see the same thing existing for cvs/svn (context message is how to
 use cvs/svn etc), mail lists (usual message about politeness etc),
 downloads, jars (ibiblio links?), javadocs etc.
 
 Now, circling the basement is not conducive to coherence, or correct
 spelling I suspect, so I'm going to ramble a bit here in vague
 justification. Jakarta is different to other TLP's in that it's an
 umbrella. One of the reasons I like the approach above is that it is
 playing to Jakarta's role as an umbrella. Each project will link directly
 to the dynamic resource page, ie) closer.cgi for downloads. Jakarta then
 provides an umbrella navigation system for when people want to see all
 this information from a single location and not click on each sub-project.
 
 ---
 
 Baby's feed is near an end I suspect, so I need to wrap things up a bit.
 Direct comments on the current binindex page (with srcindex inheriting
 most of these flaws):
 
 1) Demo Builds, Milestone Builds: Do we even use these terms regularly? We
 have 1 demo build, and I thought we did RC's rather than Milestones. I'm
 not sure we even need to push the nightlies at this level; the project
 pages themselves should be fine as anyone looking for a nightly is
 probably deeply involved with that project as a user.

I'd be fine with getting rid of separate sections for these, and
simply putting RCs in the main section, but that presupposes that we
want to mirror RCs...

 2) I'm not sure we need to advertise the Apache blog or Jakarta news here.
 It's on the front page, why use up valuable space.

Yep.

 3) Why advertise related projects? They're in the navbar about an inch
 away.

I think the original purpose of this section was to provide links to
projects that had moved out of Jakarta to TLPs. It would help people
who were not yet aware that a project had gone TLP. Now, however,
that section seems to have a lot more in it, making it somewhat less
meaningful. It might make sense to reinstate the original purpose,
listing only graduated projects and renaming the section to reflect
that.

 4) Same complaint as Martin has. Why have the download information if we
 let people click right past it. The table at the top is a noble effort,
 but I think we need a lot more to solve the problem.

Yep.

 5) Agreed, Commons needs some kind of grouping to bring it together.

I think Commons needs its own page to sort out all of the components,
instead of trying to deal with a large number of artifacts of one
subproject on the same page as all the other subprojects.

--
Martin Cooper


 That's it. Hopefully much food for thought.
 
 Hen
 
 On Mon, 27 Dec 2004, Martin Cooper wrote

Re: Jakarta download pages Was: download pages in j.a.o.

2004-12-28 Thread Martin Cooper
On Tue, 28 Dec 2004 18:23:37 -0500 (EST), Henri Yandell
[EMAIL PROTECTED] wrote:
 
 
 On Tue, 28 Dec 2004, Martin Cooper wrote:
 
  On Mon, 27 Dec 2004 23:27:51 -0500 (EST), Henri Yandell
  [EMAIL PROTECTED] wrote:
 
  1) Demo Builds, Milestone Builds: Do we even use these terms regularly? We
  have 1 demo build, and I thought we did RC's rather than Milestones. I'm
  not sure we even need to push the nightlies at this level; the project
  pages themselves should be fine as anyone looking for a nightly is
  probably deeply involved with that project as a user.
 
  I'd be fine with getting rid of separate sections for these, and
  simply putting RCs in the main section, but that presupposes that we
  want to mirror RCs...
 
 Should RC's even be on this page? The reality is that currently we list
 about 3% of all the RC's made.

It would make sense for subprojects whose RCs would cause significant
bandwidth consumption. However, I think the only subproject that would
likely cause such volumes today is Tomcat, but they don't have RCs.
(Struts used to put RCs on this page when we were in Jakarta, to take
the load off the ASF servers.) So you may be right - maybe this
section should go.

 
 I'm going to kill the Demo Build section as the only link (Velocity demo)
 fails.
 
  3) Why advertise related projects? They're in the navbar about an inch
  away.
 
  I think the original purpose of this section was to provide links to
  projects that had moved out of Jakarta to TLPs. It would help people
  who were not yet aware that a project had gone TLP. Now, however,
  that section seems to have a lot more in it, making it somewhat less
  meaningful. It might make sense to reinstate the original purpose,
  listing only graduated projects and renaming the section to reflect
  that.
 
 Switching to Graduated.
 
 I've removed DB, Geronimo, Gump, HTTP Server, Incubator, Web Services and
 XML as ones I don't think came from Jakarta. Hard to say with Gump, DB,
 Web Services. I'm not sure if bits didn't exist in Jakarta.

Gump originated at Jakarta, certainly.

--
Martin Cooper


 (at least, I'm doing this. Should be live relatively soon)
 
 Hen


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



Re: download pages in j.a.o.

2004-12-27 Thread Martin Cooper

On Tue, 28 Dec 2004, Tetsuya Kitahata wrote:
Just I've tried to improve the usability of Download Pages
in jakarta.a.o. (by Adding Table Of Contents in Release Source Drops
section)
The problem I have with this change is that it pretty much guarantees that 
people will completely skip reading anything about the fact that they are 
downloading from a mirror site, and especially the fact that they need to 
verify the signature of what they download. If we could put that info 
before the links, I would be much happier. ;-)

--
Martin Cooper

http://jakarta.apache.org/site/binindex.cgi
http://jakarta.apache.org/site/sourceindex.cgi
The migration of CVS repository (jakarta-site2)
into SVN had slipped my mind -- very sorry.
--
BTW:
Perhaps, commons-*** lines can be separated, by creating
/commons/binindex.cgi plus commons/sourceindex.cgi
and by adding these lines below to .htaccess in jakarta-site2
module (migrated into SVN?).
| RedirectMatch ^/site/binindex.cgi#commons-(.*)  
http://jakarta.apache.org/commons/binindex.cgi#$1
| RedirectMatch ^/site/sourceindex.cgi#commons-(.*)  
http://jakarta.apache.org/commons/sourceindex.cgi#$1
(... not sure. I am not familiar with RedirectMatch.)
Sincerely,
-
Tetsuya Kitahata --  Terra-International, Inc.
E-mail: [EMAIL PROTECTED]  http://www.terra-intl.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: Jakarta CVS modules

2004-12-26 Thread Martin Cooper
On Sun, 26 Dec 2004 12:11:36 -0500 (EST), Henri Yandell
[EMAIL PROTECTED] wrote:
 
 Partly to do with CVS-SVN and partly to do with figuring out just what
 we're sitting on top of, here's a review of our CVS structure. The phrase
 'needs migration' may just mean that it's already been migrated and needs
 deletion.
 
 jakarta-*
 =
 
 jakarta-jetspeed + jakarta-jetspeed-2 need migration to portals.
 jakarta-log4j + jakarta-log4j-sandbox need migration to logging.
 jakarta-ecs2 looks dead.
 jakarta-ojb needs migration to db.
 jakarta-pluto needs migration to portals.
 jakarta-site is dead.
 jakarta-tools looks dead.

Wow, I'd never even heard of -tools before. The only reference I can
find to it (or at least to moo) is from watchdog, so we should be able
to archive it along with that. Note that Gump is still building this,
so we'll need to remove those references first.

 Additionally, we know we need to archive:
 
 jakarta-watchdog
 jakarta-watchdog-4
 jakarta-alexandria
 
 On our CVS page, we claim to be looking after the following java-*
 repositories, but they are no longer in the main cvs.apache.org location:
 
 * java-framework
 * java-icalendar
 * java-jserv
 * java-jukebox
 * java-jyve (dead)
 * java-jyve2 (dead)
 * java-mod_java
 * java-picoserver
 * java-site
 * java-spfc
 * java-ssi
 * java-utils
 * java-whiteboard

Where did these all go? Have they all been archived already? We should
definitely remove all the broken links.

--
Martin Cooper


 Ideally they would be in our archive too.
 
 Comments?
 
 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: new sandbox projects

2004-12-19 Thread Martin Cooper
On Tue, 14 Dec 2004 21:52:57 -0500 (EST), Henri Yandell
[EMAIL PROTECTED] wrote:
 
 
 On Tue, 14 Dec 2004, Martin Cooper wrote:
 
 
  On Wed, 15 Dec 2004, Torsten Curdt wrote:
 
  Over at cocoon we have some code that might be worth
  sharing on jakarta commons. So I was wondering
  if the sandbox is open to any committer or only to
  jakarta committers? (which I am not) I heard
  different stories...
 
  Any Apache committer can have sandbox karma just for the asking.
 
 The only complication is that the committer will need to get the jakarta
 unix group, so it'll take us a little bit longer to add karma.

Torsten (tcurdt) is now in the 'jakarta' Unix group. Can someone with
karma karma please give him access to the Commons Sandbox? Thanks!

--
Martin Cooper


 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: Converting Jakarta site and site2 to SVN

2004-12-18 Thread Martin Cooper
+1 to all of the proposals below.

--
Martin Cooper


On Sat, 18 Dec 2004 13:41:59 -0500, Tim O'Brien [EMAIL PROTECTED] wrote:
 I'm looking for comments on the following proposal to move jakarta's
 site module to Subversion.
 
 jakarta-site2 CVS
 
 will be moved to
 
 /jakarta/
  /site/  (jakarta-site2 HEAD)
 
 I don't think we need trunk, tags, and branches for this module.
 Anyone disagree?
 
 Also, does anyone have any objections to not migrating the jakarta-site
 module?  I believe this module has been unused for 3 years.
 
 -
 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] moving jakarta-site2 to subversion

2004-12-18 Thread Martin Cooper
On Sat, 18 Dec 2004 22:39:24 -0500, Tim O'Brien [EMAIL PROTECTED] wrote:
 This is the simplest SVN migration in Jakarta.  The migration
 instructions follow for review:
 
 http://wiki.apache.org/jakarta/Site2_20Conversion_20Instructions
 
 72 hours for this vote - classify this as a public release vote requires
 majority (at least 3 +1s and more +1s than -1s )
 
 [X] +1, migrate jakarta-site2 CVS to /jakarta/site SVN
 [ ] +0
 [ ] -0
 [ ] -1, No

--
Martin Cooper


 -
 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: new sandbox projects

2004-12-15 Thread Martin Cooper

On Wed, 15 Dec 2004, Torsten Curdt wrote:
Any Apache committer can have sandbox karma just for the asking.

The only complication is that the committer will need to get the jakarta 
unix group, so it'll take us a little bit longer to add karma.
Any voting needed for the sandbox components?
To get in to the Sanbox, no. To get out again, to Commons Proper, yes. ;-)
Otherwise it would be great if I could get
access to the sandbox so I can move the stuff
over.
I'll make a request to have you added to the jakarta group.
--
Martin Cooper

cheers
--
Torsten
-
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: new sandbox projects

2004-12-14 Thread Martin Cooper

On Wed, 15 Dec 2004, Torsten Curdt wrote:
Hey, folks!
Hey Torsten,
Over at cocoon we have some code that might be worth
sharing on jakarta commons. So I was wondering
if the sandbox is open to any committer or only to
jakarta committers? (which I am not) I heard
different stories...
Any Apache committer can have sandbox karma just for the asking.
I factored out our javaflow (java continuations)
implementation and a java compiler interface (jci)
featuring a compiling classloader.
Any opinions on hosting that at jakarta commons?
Or should we keep that stuff under our umbrella?
These sound good to me. I would be +1 for having these in the Commons 
sandbox.

--
Martin Cooper

cheers
--
Torsten
-
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: Mail list page

2004-12-01 Thread Martin Cooper
On Wed, 1 Dec 2004 10:05:11 -0500 (EST), Henri Yandell
[EMAIL PROTECTED] wrote:
 
 Couple of questions
 
 When are we going to remove projects which have been promoted from
 Jakarta, from the mail list page? Anyone mind if I do it now?

Feel free to remove Struts.

--
Martin Cooper


 The watchdog-dev mail list appears to be gone (which makes sense). Is
 there a list left for Watchdog, should its entry direct people to
 [EMAIL PROTECTED]
 
 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: Axion / Derby status?

2004-09-29 Thread Martin Cooper
You'd likely get better answers on these if you ask the folks in the
incubator, since that is the path into the ASF for both of the
projects you're asking about. See:

http://incubator.apache.org/

My understanding is that the Axion folks wanted to wait until they're
done with their 1.0 release at Tigris before moving the code over. I
don't know about Derby.

--
Martin Cooper


On Thu, 30 Sep 2004 13:11:48 +1000, Mark Livingstone
[EMAIL PROTECTED] wrote:
 Hi Guys,
 
 Could someone in the know :-) please tell me what the hold up seems to
 be with Axion moving into the incubator from it's current Tigris site?
 From an outsiders perspective nothing seems to be happening.
 
 Likewise (as appropriate) for Derby?
 
 TIA
 
 MarkL
 
 -
 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: CVS-SVN Was: SVN of ECS

2004-09-28 Thread Martin Cooper
On Tue, 28 Sep 2004 10:32:06 -0400 (EDT), Henri Yandell
[EMAIL PROTECTED] wrote:
 
 
 On Tue, 28 Sep 2004, Henning Schmiedehausen wrote:
 
  Hi,
 
  ok. So this means, once we get e.g. /jakarta/turbine, we could
  set the repository structure below it just as we see it fit?
 
  We (Turbine) currently have (for history reasons) a lot of CVS
  repositories and consolidating them is a real pet peeve for me. ;-)
 
 Yep. My suggestion would be to go with a:
 
 /jakarta/turbine/component/tags|branches|trunk|site
 
 but that may not fit every subproject. I have a definite Commons view of
 the world where every component is equal. I'm not sure how commons-sandbox
 should be handled though.

We've been discussing the same subject over at Struts, and one
excellent point that Craig brought up is consideration of ease of
refactoring / moving code across units of source control. I think this
might be an important consideration for Commons as well, in
determining whether separation occurs above or below the 'trunk' point
in the tree.

--
Martin Cooper


 
 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: Can I use Hibernate in an Apache project without compromising the Apache License?

2004-09-27 Thread Martin Cooper
On Mon, 27 Sep 2004 18:06:09 +0200, Oliver Zeigermann
[EMAIL PROTECTED] wrote:
 OK, I understand I can not check in the jar. But what about having it
 included in a Maven like build with dynamically downloading it.

Theoretically, I suspect you could write such a build target, but you
would not be able to distribute the results of such a build.

--
Martin Cooper


 I was
 wondering if the dynamic linking thing hasn't be explitictely clarified
 in this:
 
 http://www.hibernate.org/196.html
 
 Or is the above still not satisfying?
 
 Just wondering...
 
 Oliver
 
 
 
 Henri Yandell wrote:
 
 
  Correct. We can't check in LGPL, and I don't believe you can check in
  code that depends on LGPL. The reason for this is that their
  interpretation of dynamic linking is debatable and the ASF takes the
  other side in that debate.
 
  The options appear to be to either have a plugin module which depends on
  the LGPL library and is a java.net or SF project etc, or to find a BSD
  dependency.
 
  Hen
 
  On Mon, 27 Sep 2004, Tim O'Brien wrote:
 
  AFAIK IANAL, no.  Checking in LGPL binaries is not something we can do
  here.
 
  Tim
 
 
 
 
  -Original Message-
  From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
  Sent: Monday, September 27, 2004 2:38 AM
  To: Jakarta General List
  Subject: Can I use Hibernate in an Apache project without
  compromising the Apache License?
 
  Folks,
 
  I was considering to use Hibernate for persistence in the
  Slide project.
  Now, Hibernate is LGPL, but in
  http://www.hibernate.org/196.html the authors explain their
  idea of dynamic linking as mentioned in the LGPL text. This
  looks just fine to me. Additionally, I understand I can even
  put the jars into the Slide CVS if I include a reference to
  the license, right?
 
  Thanks for any comments in advance,
 
  Oliver
 
  -
  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]



Re: CVS-SVN Was: SVN of ECS

2004-09-25 Thread Martin Cooper
On Sat, 25 Sep 2004 21:25:37 +0100, robert burrell donkin
[EMAIL PROTECTED] wrote:
 On 24 Sep 2004, at 19:55, Henri Yandell wrote:
 
  Sounds good to me. ORO's the first to goto SVN then.
 
 cool
 
  Noel (or any other local to Jakarta infra people), before I go ahead
  and just make a request, is there a particular process you'd like us
  to adhere to?
 
 given jakarta's large and diverse, i'd say that we need some kind of
 documented procedure. otherwise, it could get really messy and create a
 lot of trouble for infrastructure.

There is this to start with:

http://www.apache.org/dev/cvs2svn.html

--
Martin Cooper


 
 - robert
 
 
 
 
 -
 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: FYI: Author tags

2004-09-13 Thread Martin Cooper

On Mon, 13 Sep 2004, Henri Yandell wrote:
Many will remember the discussion on whether the ASF should discourage, ban 
or allow @author tags. I'm not sure that the end result was reported out to 
the whole community, so going ahead and doing so now. Apologies if a repeat.

The boards statement (via Sam) is that:
 Sam: The choice of @authors or not is a PMC level decision. 
For the benefit of those who were not around at the time, I think it's 
only fair to include the following official statement that was made by the 
board:

 - author tags are officially discouraged. these create difficulties
   in establishing the proper ownership and the protection of our
   committers. there are other social issues dealing with
   collaborative development, but the Board is concerned about the
   legal ramifications around the use of author tags
--
Martin Cooper

Many do think that @author tags are not useful, but we're free to do what we 
want.

My opinion:
 If we ever get subprojects where things are getting childish over @author 
tags and recognition for fixing newlines or removing unused imports (made up 
examples), then we should just take the easy way out on that subproject and 
remove the @author tags. Otherwise, we continue as normal.

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: md5 checksum formats on BSD

2004-08-11 Thread Martin Cooper
Do you happen to know which flavour Ant creates? For Struts releases,
the Ant build file generates the MD5 files using the checksum task.
That seems like a pretty obvious way to generate them for any project
that uses Ant, but the task doesn't appear to have any switch for
determining flavour (and the docs don't appear to say anything about
different flavours of MD5).

--
Martin Cooper


On Wed, 11 Aug 2004 13:06:00 -0400, Mark R. Diggory
[EMAIL PROTECTED] wrote:
 A subject came up on the Tomcat developers list which we thought should
 be shared with the whole community.
 
 Specifically, it was found that BSD's default md5 format is not parsable
 by some external programs that clients are using to verify the integrity
 of our downloads.
 
 While we thought this not mission critical, we did think it wise that
 we should begin making the following recommendation when creating md5
 signatures for files.
 
 We discovered there is a -r option which makes BSD md5 generate md5
 signature format that is the same as that of GNU's md5sum, a more
 prevalent tool for generating checksums of files.
 
 We also found that on BSD, cksum is comparable to to GNU's md5sum
 --check functionality and that it works on both the BSD and GNU file
 format.
 
 Our recommendation is that Apache should be signing with the more
 prevalent GNU formated output so that other file integrity software
 available on platforms other than BSD can verify the file integrity more
 easily. This is simply accomplished by adding the -r option
 
 For Example:
 %md5 -r foo.bar  foo.bar.md5
 
 We should remember that md5 signatures are for the public to verify the
 integrity of our software package distributions. Making sure that
 everyone can verify our file integrity is probably more important than
 maintaining a platform specific format because it is the default for the
 OS these were generated on.
 
 -Mark Diggory
 
 Mark R. Diggory wrote:
  For example here are the outputs of the various signing tools we use at
  this time:
 
  BSD md5:
 
md5 commons-collections-3.1.jar
  MD5 (commons-collections-3.1.jar) = d1dcb0fbee884bb855bb327b8190af36
 
  while the GNU md5 script generates the following:
 
  [EMAIL PROTECTED] jars]$ md5sum commons-collections-3.1.jar
  d1dcb0fbee884bb855bb327b8190af36  commons-collections-3.1.jar
 
  And maven just generates and uses:
  d1dcb0fbee884bb855bb327b8190af36
 
  Yes, the nice thing about BSD md5 is that the -r can be used to make it
  look like the GNU md5sum output, it would probably be good if we started
  to use this as it will be more prevalent and possibly is the closest one
  can get to a standard:
 
md5 -r commons-collections-3.1.jar
  d1dcb0fbee884bb855bb327b8190af36 commons-collections-3.1.jar
 
 
  Mark R. Diggory wrote:
 
  This is the md5 output generated by BSD md5 and not necessarily a
  standard, GNU md5sum generates a different format that is not
  standard as well. For maven, just the checksum portion of the
  content is stored in the file.
 
  It would be nice if there was a standard in this area, but I have yet
  to see one in the internet community. We have the same problem with
  generating md5 checksums for the maven repository at the moment.
 
  -Mark
 
  Shapira, Yoav wrote:
 
  Hi,
  The format I use for MD5 sums is the standard one.  Every other project
  I know uses this format, so I think if anything this user needs to
  adjust his preferences ;)  However, if there's a standard or spec
  somewhere that mandates we use md5 -r (reverse output format), then
  sure, someone point me to it and I'll follow that spec when signing
  releases.
 
  Yoav Shapira
  Millennium Research Informatics
 
 
 
  -Original Message-
  From: jean-frederic clere [mailto:[EMAIL PROTECTED]
  Sent: Tuesday, August 10, 2004 5:26 AM
  To: Tomcat Developers List
  Subject: Re: Fwd: md5 sums for jakarta downloads
 
  Pier Fumagalli wrote:
 
 
  Begin forwarded message:
 
 
  From: Andy Mudrak [EMAIL PROTECTED]
  Date: 10 August 2004 00:57:44 BST
  To: [EMAIL PROTECTED]
  Subject: md5 sums for jakarta downloads
 
  Hi,
 
 
 
  I noticed that your MD5 sums on your website are not all formatted
  correctly.  I specifically downloaded the Tomcat 5.0.27 MD5 file,
 
 
 
  and
 
  found this out.  Not that it's a big deal or anything like that, but
  it'd be good to have the MD5 properly formatted, that is the MD5 sum
  and then the file name...
 
 
 
  I am not sure that is a good idea:
  +++
  -bash-2.05b$ openssl md5  toto
  MD5(toto)= efd6b079984c77cd80254ff266e9ab43
  +++
 
  And looking in the Jakarta Binary downloads I have found that a lot
 
 
 
  of
 
  other
  MD5 file are using the Tomcat format.
 
 
 
 
  Thanks,
 
 
 
  Andy Mudrak
 
  [EMAIL PROTECTED]
 
 
 
 
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED

Re: Adding project version to bugzilla

2004-07-22 Thread Martin Cooper

On Wed, 21 Jul 2004, Shapira, Yoav wrote:
Hi,
Please remind me what I need to do / whom I need to ask that a new
version (e.g. 5.0.26 and 5.0.27 for tomcat) be added to the list in
Bugzilla's Version field?
Asking here is fine. I've added 5.0.26 and 5.0.27 for Tomcat 5.
--
Martin Cooper

Thanks,
Yoav Shapira
Millennium Research Informatics

-
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: Adding project version to bugzilla

2004-07-22 Thread Martin Cooper


 -Original Message-
 From: Henri Yandell [mailto:[EMAIL PROTECTED]
 Sent: Thursday, July 22, 2004 6:00 AM
 To: Jakarta General List
 Subject: Re: Adding project version to bugzilla



 Any idea who the people with access to do this are Martin? Within Jakarta
 anyway?

Apart from the folks who've chimed in, the only other person I know for sure
has the right perms is Craig.

--
Martin Cooper



 Hen

 On Wed, 21 Jul 2004, Martin Cooper wrote:

 
 
  On Wed, 21 Jul 2004, Shapira, Yoav wrote:
 
   Hi,
   Please remind me what I need to do / whom I need to ask that a new
   version (e.g. 5.0.26 and 5.0.27 for tomcat) be added to the list in
   Bugzilla's Version field?
 
  Asking here is fine. I've added 5.0.26 and 5.0.27 for Tomcat 5.
 
  --
  Martin Cooper
 
 
   Thanks,
  
   Yoav Shapira
   Millennium Research Informatics
  
  
  
   -
   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]



  1   2   >