[RESULT] Move Jakarta to the Attic; close down Jakarta PMC

[Henri Yandell]

Declaring a result on this one. 13 +1s.

Jakarta's off to the Attic.

Hen

On Thu, Nov 10, 2011 at 10:01 AM, Henri Yandell  wrote:
> A joint vote to retire Jakarta into the Attic and to ask the board to
> close down the PMC.
>
>  [ ] +1
>  [ ] -1, because
>
> Hen

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

Re: Moving release archives for BSF, BCEL, JCS from Jakarta to Commons

[Henri Yandell]

Looks good, though I'm not sure the redirect on the mirror adds you
much value. I'd do it if it's standard practice, otherwise skip.

Hen

On Fri, Nov 11, 2011 at 4:08 PM, sebb  wrote:
> At present, BSF, BCEL and JCS downloads still use /dist/jakarta/.
>
> I've just started the process of moving JMeter files to the new JMeter
> TLP, so I thought I might as well do the same for the remaining
> Jakarta downloads.
>
> This is what I propose for the Commons moves:
>
> - copy (cp -p) archives, sigs, hashes from /dist/jakarta/ to
> /dist/commons/
> - add redirect for /dist/jakarta/ to
> http://ww.apache.org/dist/commons/
> (this only affects www.apache.org, not the 3rd party mirrors)
>
> Wait a day or two to allow the mirrors to catch up.
>
> Next stages are:
>
> - update  download page to use /dist/commons/
> - delete /dist/jakarta/
>
> At some later point the archives need to be tackled, but that might
> involve infra.
>
> I think that's it; if anyone can spot any errors in the process please advise!
>
> -
> To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: general-h...@jakarta.apache.org
>
>

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

Re: [VOTE] Move Jakarta to the Attic; close down Jakarta PMC

[Henri Yandell]

Jakarta contains retired projects that we would need to transfer over.
Also a general check that everyone left correctly. Probably kill the
current page and write something historical.

Hen

On Thu, Nov 10, 2011 at 10:52 AM, Phil Steitz  wrote:
> Is there anything left actually to put in the attic?  Maybe just disband the 
> PMC?
>
> Phil
>
>
>
> On Nov 10, 2011, at 10:01 AM, Henri Yandell  wrote:
>
>> A joint vote to retire Jakarta into the Attic and to ask the board to
>> close down the PMC.
>>
>>  [ ] +1
>>  [ ] -1, because
>>
>> Hen
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: general-h...@jakarta.apache.org
>>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: general-h...@jakarta.apache.org
>
>

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

[VOTE] Move Jakarta to the Attic; close down Jakarta PMC

[Henri Yandell]

A joint vote to retire Jakarta into the Attic and to ask the board to
close down the PMC.

  [ ] +1
  [ ] -1, because

Hen

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

Re: Top Level Jakarta Website

[Henri Yandell]

The last project just moved out of Jakarta, so what you're seeing is a very
realistic view of things :)

We'll be closing down Jakarta soon. Waiting on JMeter to be fully 'out',
and then need to go through the non-profit motions to close the committee
down.

Hen

On Tue, Nov 8, 2011 at 9:48 AM, Geiglein, Gary wrote:

> In general I like the Apache Websites, and we use a lot of Apache
> technologies in our development efforts. With that said, the Jakarta site
> has one problem. It is not easy for a new Jakarta user to find the current
> Jakarta projects.
>
> ** **
>
> I would think that the current projects would be more important to
> spotlight than either Ex-Jakarta or Retired Projects. But the list is not
> found on any of the entry level pages.
>
> ** **
>
> John Gary Geiglein
>
> ** **
>
> John Gary Geiglein
>
> Project Manager
>
> [image: acentia2]
>
>   (Formerly IT Solutions LLC)
>
> ** **
>
> 6116 Executive Blvd.
>
> Suite 701-A
>
> Rockville, MD 20852
>
> 301-451-6544 (office)
>
> 443-538-3620 (cell)
>
> gary.geigl...@acentia.com
>
> www.acentia.com
>
> ** **
>
> *Acentia* is a family of companies that include ITS Holding Company LLC,
> Interactive Technology Solutions LLC, ITEQ Integrated Technologies Inc.,
> Codin Solutions Inc., ITS Net Inc., ITS Net Government Services, Inc., ITS
> Net Government Solutions Inc., Optimus Corporation, and Peace Technology.*
> ***
>
>  
>
> The information in this electronic mail message is confidential and may be
> legally privileged. It is intended solely for the addressee. Access to this
> Internet electronic mail message by anyone else is unauthorized. If you are
> not the intended recipient, any disclosure, copying, distribution or any
> action taken or omitted to be taken in reliance on it is prohibited and may
> be unlawful.
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>

Re: October board report input needed

[Henri Yandell]

JMeter->jmeter.apache.org was approved by the board. I'm eager to see
the change happen so the 'Close Jakarta' thread can start :)

On Fri, Oct 21, 2011 at 8:08 AM, Rahul Akolkar  wrote:
> Please provide any input for our October board report by editing the
> wiki, I'll be sending the report Sunday. I've added the draft for
> October to the wiki here:
>
>  http://wiki.apache.org/jakarta/JakartaBoardReport-October2011
>
> -Rahul
>

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

Re: JMeter TLP - draft resolution and first chair

[Henri Yandell]

On Thu, Sep 22, 2011 at 2:31 AM, sebb  wrote:
> On 22 September 2011 01:15, Rahul Akolkar  wrote:
>> On Wed, Sep 21, 2011 at 7:33 PM, Henri Yandell
>>  wrote:
>>> On Thu, Sep 22, 2011 at 1:30 AM, Rahul Akolkar  
>>> wrote:
>>>> On Tue, Sep 20, 2011 at 3:15 AM, Henri Yandell
>>>>  wrote:
>>>>> Happy to be on the PMC :) I'm not sure I'll be that active, but
>>>>> hopefully can help with any setup items.
>>>>>
>>>>> +1 for Sebb as Chair.
>>>>>
>>>>
>>>> I've updated the resolution to reflect the nomination.
>>>>
>>>> If there are no further changes to the proposal in a couple of days,
>>>> I'll start the TLP vote.
>>>
>>> We shouldn't vote until Sebb, or someone else, is signed up to be the chair.
>>>
>> 
>>
>> Thats reasonable too :-) Sebb?
>
> I would have preferred to see JMeter as part of HC, but perhaps it
> would be better as a TLP.
> However I think we need some more PMC members first.
>
> I can think of some Jakarta PMC members who have been involved with
> JMeter recently, and I think some of the Tomcat PMC use JMeter.
>
> Is it OK just to add them, or should they be asked first?

Ask - though any Jakarta PMC member who doesn't want to be a JMeter
PMC member is implicitly saying they're not a Jakarta PMC member now
that Jakarta = { JMeter }.

Hen

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

Re: JMeter TLP - draft resolution and first chair

[Henri Yandell]

On Thu, Sep 22, 2011 at 1:30 AM, Rahul Akolkar  wrote:
> On Tue, Sep 20, 2011 at 3:15 AM, Henri Yandell
>  wrote:
>> Happy to be on the PMC :) I'm not sure I'll be that active, but
>> hopefully can help with any setup items.
>>
>> +1 for Sebb as Chair.
>>
> 
>
> I've updated the resolution to reflect the nomination.
>
> If there are no further changes to the proposal in a couple of days,
> I'll start the TLP vote.

We shouldn't vote until Sebb, or someone else, is signed up to be the chair.

Hen

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

Re: JMeter TLP - draft resolution and first chair

[Henri Yandell]

Happy to be on the PMC :) I'm not sure I'll be that active, but
hopefully can help with any setup items.

+1 for Sebb as Chair.

Hen

On Mon, Sep 19, 2011 at 1:59 AM, Rahul Akolkar  wrote:
> I've created a draft TLP resolution for JMeter here, intent being to
> submit in time for the October board meeting:
>
>  http://wiki.apache.org/jakarta/TLPJMeter
>
> Folks on initial PMC include those who voted on latest release (some
> arbitrary metric to get started) plus those involved in recent
> discussions on topic, such as Hen and me. Please feel free to edit the
> above page directly to add/remove entries.
>
> Pending question - who to list as Chair?
>
> sebb - Given your sustained work on JMeter, I think you should do it.
> Its not much overhead, take the plunge, rest of us will write the
> reports if needed :-)
>
> -Rahul
>
> -
> To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: general-h...@jakarta.apache.org
>
>

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

Re: Ad BSF 2.x (Re: Activity of Jakarta subprojects

[Henri Yandell]

On Tue, Aug 30, 2011 at 4:36 AM, Rony G. Flatscher
 wrote:
> ... cut ...
>> Well, I would like to incorporate the changes in August such that an
>> updated (bug-fixed, and the enhancements incorportated) BSF 2.x can then
>> be put into the attic.
>
> ... cut ...
>
> Another project (a language binding for D-Bus) took too much time, such
> that I was not able to turn to BSF 2.4 this month. As I will be off for
> ten days I just wanted to assert that I will turn to BSF 2.4 upon return
> and work steadily in smaller units to incorporate the changes throughout
> September (the committing in commons works, I changed the version number
> to BSF 2.5 yesterday to indicate that there is activity :) ).
>
> ---rony
>
> P.S.: Was not sure where to post this, so I turned to this list. What
> would be the correct list for BSF related mails in the future?

Sorry, missed this.

Mailing lists for BSF are now:

d...@commons.apache.org
u...@commons.apache.org

See the following page on Lang:

http://commons.apache.org/lang/mail-lists.html

Hen

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

BSF SVN moved

[Henri Yandell]

Post the successful vote to move BSF over to Commons, I've moved the
svn into the Commons tree.

New svn url:

  https://svn.apache.org/repos/asf/commons/proper/bsf/trunk

Or you can check out all of Commons at:

  https://svn.apache.org/repos/asf/commons/trunks-proper

I've updated the Jakarta site to point BSF SVN to this location. There
didn't seem to be a BSF svn url within the BSF site. I'll also fix the
doap file and update the category in JIRA.

Hen

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

Fwd: [VOTE][RESULT] Accept BSF as a Commons component

[Henri Yandell]

FYI. Vote passes for BSF to move over to Commons.

Hen

-- Forwarded message --
From: sebb 
Date: Tue, Aug 16, 2011 at 4:26 PM
Subject: [VOTE][RESULT] Accept BSF as a Commons component
To: Commons Developers List 


The 72 hours has elapsed.

Voting was as follows:

+1, PMC member (all both sub-votes)
=
Matt Benson
Henri Yandell
Stefan Bodewig
Luc Maisonobe
Christian Grobmeier
Simone Tripodi
Gary Gregory
Oliver Heger
James Carman
Daniel F. Savarese
Sebastian Bazley

There were no other votes, so the vote duly passes.

Thanks to all who voted.

On 17 August 2011 00:20, sebb  wrote:
> On 13 August 2011 01:13, sebb  wrote:
>> BSF [1] needs to move out of Jakarta.
>>
>> It's not really big enough to warrant its own TLP.
>>
>> IMO Commons would be a good alternative home for BSF.
>>
>> Can we please vote to:
>>
>> 1. Accept BSF as a Commons Component
>>
>> 2. Offer Commons karma to BSF developers.
>>
>> The ones who made commits since the start of 2008 and are not already
>> in Commons are:
>>
>> 2a) Rony G. Flatscher (rony)
>> 2b) Ant Elder (antelder)
>>
>> [I'm another such developer and so is Rahul]
>>
>> -
>> [X] +1 to all above
>> [  ] +/- 0
>> [  ] -1, which ones and why ...
>> --
>>
>> You may of course vote on each separately if necessary.
>>
>> Vote will minimally stay open for 72 hours. Thanks.
>>
>> [1] http://jakarta.apache.org/bsf/
>>
>

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

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

Re: Ad BSF 2.x (Re: Activity of Jakarta subprojects

[Henri Yandell]

On Sat, Aug 6, 2011 at 1:58 PM, Rony G. Flatscher
 wrote:
>
>
> On 06.08.2011 18:41, sebb wrote:
>> On 6 August 2011 08:40, Henri Yandell  wrote:
>>
>>> On Mon, Jul 25, 2011 at 1:14 AM, Rony G. Flatscher
>>>  wrote:
>>>
>>>> On 24.07.2011 19:08, Henri Yandell wrote:
>>>>
>>>>> On Sun, Jul 24, 2011 at 5:08 AM, Rony G. Flatscher
>>>>>  wrote:
>>>>>
>>>>>
>>>>>> On 23.07.2011 20:47, sebb wrote:
>>>>>>
>>>>>>
>>>>>>>> * BSF: Slow activity; only coder in last two years is Sebb.
>>>>>>>>
>>>>>>>> A difficult one to decide on. I think we should challenge on it going
>>>>>>>> to the Attic, and if not send it to Commons where it will have more
>>>>>>>> chance of activity.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Now that JSR-223 is part of Java 1.6 there is less need for BSF.
>>>>>>> There are no bugs oustanding against BSF 3.x.
>>>>>>> Not sure it is worth fixing any of the 2.x bugs.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Please wait a little bit. It has been a long time intent to fix the few
>>>>>> bugs in 2.x and add the enhancements in JIRA to it. Maybe also creating
>>>>>> a JSR-223 bridge to allow BSF 2.x engines to be used in JSR-223
>>>>>> environments (not sure whether this is worthwhile, but it may be the
>>>>>> case that there are 2.x engines for which no JSR-223 engines
>>>>>> exist).(Just have not been able to push this more to the front of my
>>>>>> table; have a 2.x engine in use that has the bugfixes incorporated and I
>>>>>> would like to apply them to the official 2.x.
>>>>>>
>>>>>>
>>>>> Fair enough request.
>>>>>
>>>>> Still leaves the question of what to do with BSF. Do we:
>>>>>
>>>>> * Leave all of Jakarta open just for BSF.
>>>>> * Move BSF elsewhere. Where? Commons?
>>>>> * Move to the Attic.
>>>>>
>>>>> ---
>>>>>
>>>>> How realistic are we talking on the changes? Your last BSF code commit
>>>>> was in 2007. I know I'm being pushy - but I also know how hard it is
>>>>> to say "Game Over". If we move it to the Attic, it can always move out
>>>>> with the only pain being that you have to do the work locally at
>>>>> first, or fork into a Lab/Commons Sandbox/Incubator project.
>>>>>
>>>>>
>>>> Well, I would like to incorporate the changes in August such that an
>>>> updated (bug-fixed, and the enhancements incorportated) BSF 2.x can then
>>>> be put into the attic. Ideally a POM for it would be great, however I
>>>> can not promise as I have no working knowledge of defining Maven POMs
>>>> (however I can read them ;) ). This way older scripting engines for
>>>> which no JSR-223 bindings exist can still be deployed by Java
>>>> applications. It would be important to make the attic version easily
>>>> findable and downloadable.
>>>>
>>>> ---
>>>>
>>>> Also, I would like to stress the following point, which may be easily
>>>> overseen: BSF 3.x needs to stay alive as it implements the JSR-223 specs
>>>>
>>> Is it alive though?
>>>
>>> No user email in 2010. One user email in 2011 having trouble building,
>>> but no answer.
>>> 3.1 released by Sebb in 2010. 3.0 in 2009. Which is good stuff,
>>> especially if there is a plan for a 3.2.
>>>
>>>
>>>> (javax.script) that Sun introduced with Java 1.6. BSF 3.x runs on Java
>>>> 1.4 and up and such allows creation and deployment of applications with
>>>> scripts starting from Java 1.4. Not sure whether it got incorporated
>>>> into Harmony, but that would be probably a proper place to live on (it
>>>> is the javax.script implementation Harmony needs to be compatible with
>>>> Java 1.6 in that area as well).
>>>>
>>> Looking at activity since the turn of the year, I think it's more
>>> likely that Harmony would be heading to the Attic someday. You never
>>> know though - needs to be given time to see if things recover (someone
>>> started committing a few patches in July).
>>>
>>> I'm in favour of a BSF TLP. Assuming yourself, Anthony Elder and
>>> Sebastian Bazley are still interested and willing to form the new PMC.
>>>
>> Not sure I see the point of creating a new PMC just for BSF. Seems to
>> me it would fit quite well in Commons, if Commons would accept it.
>>
> +1

Could one of you propose that to Commons?

Hen

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

Re: Ad BSF 2.x (Re: Activity of Jakarta subprojects

[Henri Yandell]

On Mon, Jul 25, 2011 at 1:14 AM, Rony G. Flatscher
 wrote:
>
> On 24.07.2011 19:08, Henri Yandell wrote:
>> On Sun, Jul 24, 2011 at 5:08 AM, Rony G. Flatscher
>>  wrote:
>>
>>> On 23.07.2011 20:47, sebb wrote:
>>>
>>>>> * BSF: Slow activity; only coder in last two years is Sebb.
>>>>>
>>>>> A difficult one to decide on. I think we should challenge on it going
>>>>> to the Attic, and if not send it to Commons where it will have more
>>>>> chance of activity.
>>>>>
>>>>>
>>>> Now that JSR-223 is part of Java 1.6 there is less need for BSF.
>>>> There are no bugs oustanding against BSF 3.x.
>>>> Not sure it is worth fixing any of the 2.x bugs.
>>>>
>>>>
>>> Please wait a little bit. It has been a long time intent to fix the few
>>> bugs in 2.x and add the enhancements in JIRA to it. Maybe also creating
>>> a JSR-223 bridge to allow BSF 2.x engines to be used in JSR-223
>>> environments (not sure whether this is worthwhile, but it may be the
>>> case that there are 2.x engines for which no JSR-223 engines
>>> exist).(Just have not been able to push this more to the front of my
>>> table; have a 2.x engine in use that has the bugfixes incorporated and I
>>> would like to apply them to the official 2.x.
>>>
>> Fair enough request.
>>
>> Still leaves the question of what to do with BSF. Do we:
>>
>> * Leave all of Jakarta open just for BSF.
>> * Move BSF elsewhere. Where? Commons?
>> * Move to the Attic.
>>
>> ---
>>
>> How realistic are we talking on the changes? Your last BSF code commit
>> was in 2007. I know I'm being pushy - but I also know how hard it is
>> to say "Game Over". If we move it to the Attic, it can always move out
>> with the only pain being that you have to do the work locally at
>> first, or fork into a Lab/Commons Sandbox/Incubator project.
>>
> Well, I would like to incorporate the changes in August such that an
> updated (bug-fixed, and the enhancements incorportated) BSF 2.x can then
> be put into the attic. Ideally a POM for it would be great, however I
> can not promise as I have no working knowledge of defining Maven POMs
> (however I can read them ;) ). This way older scripting engines for
> which no JSR-223 bindings exist can still be deployed by Java
> applications. It would be important to make the attic version easily
> findable and downloadable.
>
> ---
>
> Also, I would like to stress the following point, which may be easily
> overseen: BSF 3.x needs to stay alive as it implements the JSR-223 specs

Is it alive though?

No user email in 2010. One user email in 2011 having trouble building,
but no answer.
3.1 released by Sebb in 2010. 3.0 in 2009. Which is good stuff,
especially if there is a plan for a 3.2.

> (javax.script) that Sun introduced with Java 1.6. BSF 3.x runs on Java
> 1.4 and up and such allows creation and deployment of applications with
> scripts starting from Java 1.4. Not sure whether it got incorporated
> into Harmony, but that would be probably a proper place to live on (it
> is the javax.script implementation Harmony needs to be compatible with
> Java 1.6 in that area as well).

Looking at activity since the turn of the year, I think it's more
likely that Harmony would be heading to the Attic someday. You never
know though - needs to be given time to see if things recover (someone
started committing a few patches in July).

I'm in favour of a BSF TLP. Assuming yourself, Anthony Elder and
Sebastian Bazley are still interested and willing to form the new PMC.

Hen

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

[RESULT] Cactus to the Attic

[Henri Yandell]

12 days seems like enough time. No one has spoken for Cactus, so the
vote passes in favour of moving Cactus to the Attic.

I suspect there's no one around to do the move, so I'll go ahead and
inform the Attic PMC etc.

Hen

On Sat, Jul 23, 2011 at 11:25 AM, Henri Yandell  wrote:
> Proposing this as a challenge vote (i.e. if no one has a good -1
> against something moving to the attic, it's a sign it should go to the
> attic).
>
> [ ] +1, G'night Cactus
> [ ] -1, No because:
>
> There's no activity in the project and I think it would be best to
> recognize the reality and call it a day.
>
> Hen
>

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

Re: Ad BSF 2.x (Re: Activity of Jakarta subprojects

[Henri Yandell]

On Sun, Jul 24, 2011 at 5:08 AM, Rony G. Flatscher
 wrote:
>
> On 23.07.2011 20:47, sebb wrote:
>>> * BSF: Slow activity; only coder in last two years is Sebb.
>>>
>>> A difficult one to decide on. I think we should challenge on it going
>>> to the Attic, and if not send it to Commons where it will have more
>>> chance of activity.
>>>
>> Now that JSR-223 is part of Java 1.6 there is less need for BSF.
>> There are no bugs oustanding against BSF 3.x.
>> Not sure it is worth fixing any of the 2.x bugs.
>>
> Please wait a little bit. It has been a long time intent to fix the few
> bugs in 2.x and add the enhancements in JIRA to it. Maybe also creating
> a JSR-223 bridge to allow BSF 2.x engines to be used in JSR-223
> environments (not sure whether this is worthwhile, but it may be the
> case that there are 2.x engines for which no JSR-223 engines
> exist).(Just have not been able to push this more to the front of my
> table; have a 2.x engine in use that has the bugfixes incorporated and I
> would like to apply them to the official 2.x.

Fair enough request.

Still leaves the question of what to do with BSF. Do we:

* Leave all of Jakarta open just for BSF.
* Move BSF elsewhere. Where? Commons?
* Move to the Attic.

---

How realistic are we talking on the changes? Your last BSF code commit
was in 2007. I know I'm being pushy - but I also know how hard it is
to say "Game Over". If we move it to the Attic, it can always move out
with the only pain being that you have to do the work locally at
first, or fork into a Lab/Commons Sandbox/Incubator project.

Hen

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

[VOTE] Move BSF to the Attic

[Henri Yandell]

Proposing this as a challenge vote (i.e. if no one has a good -1
against something moving to the attic, it's a sign it should go to the
attic).

[ ] +1, G'night BSF
[ ] -1, No because:



Per Sebb's statement:

"Now that JSR-223 is part of Java 1.6 there is less need for BSF.
 There are no bugs oustanding against BSF 3.x. Not sure it is worth
fixing any of the 2.x bugs."

Hen

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

Re: Activity of Jakarta subprojects

[Henri Yandell]

On Sat, Jul 23, 2011 at 12:39 PM, Oleg Kalnichevski  wrote:
> ...
>
>>
>> > * JMeter: Lots of activity. New committer in 2010.
>> >
>> > This should go TLP. There are two obvious members of a JMeter PMC
>> > present (sebb and milamber). Reality is that Jakarta=JMeter now, so
>> > hopefully there are other interested parties who simply aren't active.
>>
>> Or perhaps join HttpComonents?
>> I think the charter allows for this, and the main use of JMeter is for
>> HTTP testing (though of course it encompasses many other protocols).
>>
>
> The charter can be amended if needed. There is a lot of overlap between
> JMeter and HttpComponents.

Sounds like an excellent idea to me. +1.

Hen

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

[VOTE] Cactus to the Attic

[Henri Yandell]

Proposing this as a challenge vote (i.e. if no one has a good -1
against something moving to the attic, it's a sign it should go to the
attic).

[ ] +1, G'night Cactus
[ ] -1, No because:

There's no activity in the project and I think it would be best to
recognize the reality and call it a day.

Hen

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

Activity of Jakarta subprojects

[Henri Yandell]

Thought I'd summarize the current activity of the subprojects:


* Cactus: No code commits since February 2009. Weak activity between
2006 and 2009.

I think Cactus should head to the Attic.

* BSF: Slow activity; only coder in last two years is Sebb.

A difficult one to decide on. I think we should challenge on it going
to the Attic, and if not send it to Commons where it will have more
chance of activity.

* JMeter: Lots of activity. New committer in 2010.

This should go TLP. There are two obvious members of a JMeter PMC
present (sebb and milamber). Reality is that Jakarta=JMeter now, so
hopefully there are other interested parties who simply aren't active.

Hen

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

Re: Unable to download Snowball !

[Henri Yandell]

Rahul's pointing you to the Lucene mailing lists. This is the Jakarta
mailing list and only covers the few projects still left within the
Jakarta group; questions related to Snowball will have the best chance
of an answer on its own lists.

To provide context - back in 2002 or so we started to move projects
out of Jakarta as it didn't scale organization-wise to have a single
project with the vast majority of the foundation's products within it.

Do we have an out of date page somewhere pointing you to this list?

Thanks,

Hen

On Sun, Apr 17, 2011 at 6:13 AM, Neil Ghosh  wrote:
> Rahul,  What is this link about ?
>
> On Sun, Apr 17, 2011 at 6:42 PM, Rahul Akolkar wrote:
>
>> On Sun, Apr 17, 2011 at 8:49 AM, Neil Ghosh  wrote:
>> > I have already downloaded lucene but where is the snowball analyzer in
>> that
>> > ?
>> > The one in contrib directory is throwing runtime exception
>> >
>> 
>>
>> http://lucene.apache.org/mail.html
>>
>> -Rahul
>>
>>
>> > On Sun, Apr 17, 2011 at 6:16 PM, Rahul Akolkar 
>> > wrote:
>> >>
>> >> On Sun, Apr 17, 2011 at 8:34 AM, Neil Ghosh 
>> wrote:
>> >> > Hi,
>> >> >
>> >> > Unable to download snowball analyzer
>> >> > I am trying to use snowball analyzer for my search engine but unable
>> to
>> >> > download the library.
>> >> >
>> >> 
>> >>
>> >> http://lucene.apache.org/
>> >>
>> >> -Rahul
>> >>
>> >>
>> >> > Please help
>> >> >
>> >> > --
>> >> > Thanks and Regards
>> >> > Neil
>> >> > http://neilghosh.com
>> >> >
>> >
>> >
>> >
>> > --
>> > Thanks and Regards
>> > Neil
>> > http://neilghosh.com
>> >
>> >
>> >
>> >
>>
>
>
>
> --
> Thanks and Regards
> Neil
> http://neilghosh.com
>

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

Re: [VOTE][LAZY] Move Jakarta Regexp to Attic

[Henri Yandell]

+1. Nom nom.

On Mon, Mar 21, 2011 at 5:00 PM, Rahul Akolkar  wrote:
> This is a vote to move Jakarta Regexp to the Apache Attic, based on
> the outcome of the most recent discussion on the topic.
>
> Since Regexp may not have enough PMC members active, this vote will be
> held by lazy consensus. If you object, please also provide a
> reasonable explanation.
>
> Vote runs for a week, ending no sooner than Mar 28th, ~8:00 pm Eastern
> US. Vote is being held on general@jao but is being cross-posted to
> ensure we reach the full audience. Please include general@jao on any
> replies.
>
> -Rahul
>
> -
> To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: general-h...@jakarta.apache.org
>
>

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

Re: [VOTE][LAZY] Move ECS, ORO and Regexp to Attic

[Henri Yandell]

On Wed, Aug 18, 2010 at 5:27 AM, Vadim Gritsenko  wrote:
> On Aug 18, 2010, at 12:23 AM, Gary Gregory wrote:
>
>> With RegEx in Java since 1.4, I do not see the need for these libs aside 
>> from legacy application support. I consider mothballing a service to the 
>> community at large: please, join us in the 21st century, port your RegEx 
>> code to Java 1.4. ;)
>
> I guess not everybody is satisfied with Java 1.4 version yet, otherwise there 
> would be no such wide variety of choices:
> http://tusker.org/regex/regex_benchmark.html

However that page seems to indicate that Jakarta Regexp is not
preferable to Java 1.4. Given that, the question is whether we believe
we'll be improving it dramatically rather than merely bugfix. Of
course there might be other reasons why Regexp is preferable.

ORO does do better than Java 1.4 and would seem to be the product
worth attention if we want to support a 'java.util.regex' isn't good
enough angle.

Hen

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

Re: New home for ECS, ORO and Regexp?

[Henri Yandell]

+1 on ECS to the Attic.

+1 on ORO/Regexp to the Attic, unless Daniel/Vadim are interested in
moving them to Commons.

To Daniel's not being +1 on Attic - don't worry about the
infrastructure move part, it's a well defined process now and someone
will take care of it.

Hen

On Sun, Feb 28, 2010 at 6:47 PM, Rahul Akolkar  wrote:
> This is cross-posted, please use your discretion to respond to the
> relevant list(s). At a suitable time, I'll try to collate replies in a
> summary post to gene...@.
>
> We have three Jakarta sub-projects that have been discussion points
> for moving elsewhere (viz. ECS, ORO and Regexp). For example, the last
> time this came up was during the merge development mailing lists
> discussion.
>
> There have been a couple of candidate locations spoken of where these
> can be moved:
> (a) Apache Commons, where they can be maintained -- pending Jakarta
> and Commons approvals; and
> (b) Apache Attic, where they can be retired -- pending Jakarta approval.
>
> If there is interest in moving one or more to Commons, we can initiate
> that topic with Commons some time soon.
>
> So, for each of the three sub-projects: Commons or Attic or something else 
> now?
>
> I'll wait three weeks for any responses, please reply by 3/21 if you
> have any comments.
>
> -Rahul
>
> -
> To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: general-h...@jakarta.apache.org
>
>

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

Re: Move Jakarta Slide and Taglibs to the Attic?

[Henri Yandell]

+1 on both being moved into the Attic.

On Sun, Feb 28, 2010 at 6:31 PM, Rahul Akolkar  wrote:
> This is cross-posted to reach most of the potentially interested
> folks, please reply to the gene...@jakarta.a.o mailing list.
>
> Quick recap, Jakarta retired Slide in Nov '07 and most of Taglibs in
> Oct '09 (barring three that moved to Tomcat -- for the purpose of this
> email, Taglibs refers to the retired bits that remain in Jakarta).
> When our last board report was submitted, there was a
> question/suggestion whether Slide and Taglibs should be moved to the
> Attic. Anyone thinks otherwise?
>
> I'll wait three weeks for any responses, please reply by 3/21 if you
> have any comments.
>
> -Rahul
>
> -
> To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: general-h...@jakarta.apache.org
>
>

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

Re: [VOTE] Merge dev lists

[Henri Yandell]

Non-binding +1.

Whether or not the projects find they like being on one list or not,
it will be good. If it's not liked, then it's another reason to go
TLP.

--- as an aside, I thought I'd look at svn activity ---

Number of commits so far this year:

jmeter 481
bsf 143
cactus 97
jcs 63
bcel 15

We already know that ecs, oro and regexp are in the close to attic
situation, so no commits is no surprise. Whether they go Attic, or
whether they go to Commons for a slow maintenance can

Comparing to TLPs:

http://www.svnsearch.org/svnsearch/repos/ASF/search?from=20090101&to=20091231

JMeter is about 66% down the list, ranking alongside Struts for
developer activity.  It's all Sebb.

BSF is about 80% down the list, ranking alongside Roller for developer
activity. It's Sebb and Ant.

Cactus is a bit further down, ranking as a little more active than
mod_perl, mod_tcl and logging. It's Petar with a few commits from
Sebb.

JCS is with stdcxx, just below logging. It's Aaron.

BCEL would be at the bottom of the list with Xalan. It's Dave.

Reason for that is to show that on their own, the Jakarta subprojects
are hardly abnormal. Looking at the ones I mention:

Roller is 3 committers, very much centered on 1 committer.
Struts has 2 highly active committers with a long tail of other committers.
mod_perl is 8 committers.
mod_tcl is 3 committers.
logging is 3 committers.
stdcxx is 2 committers.

So the big difference is not the activity of each subproject, but that
each one is 1 committer shy of being a TLP.

Hen

On Mon, Oct 19, 2009 at 1:02 PM, Rahul Akolkar  wrote:
> [Suggestion is to please reply to the gene...@jakarta list only]
>
> This is a vote to consolidate the development lists at Jakarta into
> one development and one notifications list. For background including
> timing, anticipated benefits and some discussion, see proposal [1]
> thread.
>
> [ ] +1
> [ ] -1
>
> While not required, it'd be nice if anyone voting against could
> briefly state the reason(s). And you're ofcourse welcome to vote +/-0
> if you really want.
>
> Vote will run atleast 72 hours and will close no sooner than Thursday 5 pm 
> EST.
>
> TIA.
> -Rahul
>
> [1] (long, possibly fragmented URL below)
> http://mail-archives.apache.org/mod_mbox/jakarta-general/200910.mbox/%3cce1f2ea80910091443t5cad1db0na0663c416cb83...@mail.gmail.com%3e
>
> -
> To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: general-h...@jakarta.apache.org
>
>

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

Re: [PROPOSAL] One development list

[Henri Yandell]

On Wed, Oct 14, 2009 at 3:40 PM, Henri Yandell  wrote:
> On Tue, Oct 13, 2009 at 12:31 PM, Daniel F. Savarese  
> wrote:
>>
>
>>
>> Although I think we need to discuss and resolve what the future of
>> Jakarta is to be, I agree with Rahul that it should be a separate
>> discussion after resolving his more narrowly scoped dev@/commits@
>> proposal.  The only reason I haven't resigned from the Jakarta PMC
>> (after attic'ing ORO, now that there's an attic) is because JMeter
>> continues to use ORO and someone needs to be willing and able to
>> fix any issues that may arise.  At least with a combined dev list,
>> there can be some assurance that other committers will be alerted
>> to any problems that require fixing (not that there have been any
>> for the better part of a decade).
>
> Help migrate JMeter off of ORO? :)

Slightly less tongue in cheek - maybe now is the time to move ORO,
Regexp and ECS over to Commons.

I'm happy to help out with the move if desired. If active projects
then moving to a new site style and JIRA would come up, but given the
lack of activity I think a gentler migration would imo be fine.

Hen

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

Re: [PROPOSAL] One development list

[Henri Yandell]

On Tue, Oct 13, 2009 at 12:31 PM, Daniel F. Savarese  wrote:
>

>
> Although I think we need to discuss and resolve what the future of
> Jakarta is to be, I agree with Rahul that it should be a separate
> discussion after resolving his more narrowly scoped dev@/commits@
> proposal.  The only reason I haven't resigned from the Jakarta PMC
> (after attic'ing ORO, now that there's an attic) is because JMeter
> continues to use ORO and someone needs to be willing and able to
> fix any issues that may arise.  At least with a combined dev list,
> there can be some assurance that other committers will be alerted
> to any problems that require fixing (not that there have been any
> for the better part of a decade).

Help migrate JMeter off of ORO? :)

Hen

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

[ANNOUNCE] Taglibs moves to Tomcat

[Henri Yandell]

The Jakarta Taglibs project has been retired. The majority of the taglibs
themselves have been, or already were, retired, whilst three of them
have been moved over to the Apache Tomcat project where they will
go by the name of Apache Taglibs. These three taglibs are:

* RDC Taglib - Reusable Dialog Components (used in voice applications)
* Standard Taglib - Apache's implementation of the JSTL specifications
1.0, 1.1 and the unreleased 1.2.
* an in development Extended Taglib that is intended to add tags and
functions 'missing' from JSTL.

The User list has been maintained and moved over to the
tomcat.apache.org domain name, while the main Tomcat development
list will be used for contributor discussions.

For the list of Taglibs that have been retired, please see:

 http://jakarta.apache.org/site/retired-taglibs.html

For the continuing development at Tomcat, please see:

 http://tomcat.apache.org/taglibs/

Thank you,

Henri Yandell
on behalf of the Jakarta PMC

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

Re: [DRAFT] Board Report July 2009

[Henri Yandell]

Looks good.

On Sun, Jul 12, 2009 at 2:13 PM, Rahul Akolkar wrote:
> Here is the draft Board report for this month:
>
>  http://wiki.apache.org/jakarta/JakartaBoardReport-current
>
> Please make any desired changes to the above wiki page directly. The
> report needs to go out in about 20 hours.
>
> -Rahul
>
> -
> To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: general-h...@jakarta.apache.org
>
>

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

Re: Apache commons.net 2.0 support

[Henri Yandell]

Wrong mailing list Dale.

Frustrating I know - but the people who focus on Commons Net probably
aren't paying attention on this list - if they're even subscribed.

See the commons-user list: http://commons.apache.org/net/mail-lists.html

Hen

On Tue, May 26, 2009 at 6:04 PM, Dale Harris
 wrote:
> Hi Simon,
>
> Sorry about being naive but I'm slowly understanding what is happening.  I
> believe my whole issue is something to do with java.net.Socket class trying
> to use a proxy server.  How can I turn this off before trying to connect
> with the TelnetClient class?
>
> Regards,
>
> Dale Harris
> IT Support
>
>
> -Original Message-
> From: Dale Harris [mailto:itsupp...@martinjonkersmotors.com.au]
> Sent: Wednesday, 27 May 2009 8:25
> To: 'Jakarta General List'
> Subject: RE: Apache commons.net 2.0 support
>
> Hi Simon,
>
> Sorry about getting the name wrong, but that is the package that I
> downloaded a couple of weeks ago and trying to use.
>
> The org.apache.commons.net.telnet.TelnetClient class just doesn't work for
> me.  I've tried using the supplied example, which doesn't work either.  I
> know that Java changed somewhat with networking on Windows from Java 1.6.10,
> and I was wondering if that is what has broken the telnet classes.  I don't
> know how it changed, but I know Java 1.6.10 broke the networking (from my
> understanding) in an existing application which we use.
>
> Regards,
>
> Dale Harris
> IT Support
>
>
> -Original Message-
> From: Simon Kitching [mailto:skitch...@apache.org]
> Sent: Tuesday, 26 May 2009 17:37
> To: Jakarta General List
> Subject: Re: Apache CommonNet 2.0 support
>
> Dale Harris schrieb:
>> Hi,
>>
>>
>>
>> I was wondering where I can ask to get support for Apache CommonNet 2.0 as
> I
>> have an issue with TelnetClient class not connecting.  I am using Java
>> 1.6_13 on Windows Vista.  The supplied telnet example doesn't work when
>> trying to connect to a local telnet server; Putty works okay.
>
> The library is "commons net", not CommonNet. Googling for that gives:
>  http://commons.apache.org/net/
> as the first hit, which is correct.
>
> Click on the "Project Information" link to see info about the project
> mailing lists. You should first join the "user" list, then email your
> question to that list.
>
> Regards, Simon
>
> -
> To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: general-h...@jakarta.apache.org
>
> -
> To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: general-h...@jakarta.apache.org
>
> -
> To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: general-h...@jakarta.apache.org
>
>

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

Re: [VOTE] Release Cactus 1.8.1 (Third attempt)

[Henri Yandell]

On Sat, Jan 24, 2009 at 8:50 AM, sebb  wrote:
> On 23/01/2009, Henri Yandell  wrote:
>> MD5 good.
>>
>>  Bit bemused by the following line for JUnit. Wondering why it's
>>  relevant, but not a blocker:
>>
>>  "and is not maintained by Object Mentor."
>>
>>  Build of the samples/ in the bin zip with .m2/repository removed: Succeeds.
>>
>>  Build of all the source with .m2/repository removed:   I accidentally
>>  did it under JDK 1.4 and got errors against the EJB jar. Retried with
>>  1.5 and it succeeds.
>
> Huh?
>
> It builds and tests fine for me using Java 1.4.
> What errors did you get?
>
> If the release does require 1.5+, then that needs to be in the POM and
> release notes etc...

Sorry - home has been a house of ill children and ill parents for the
last couple of days.

The error was that a dependency on an EJB jar complained about v49 of
the classes found therein.

Hen

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

Re: [VOTE] Release Cactus 1.8.1 (Third attempt)

[Henri Yandell]

MD5 good.

Bit bemused by the following line for JUnit. Wondering why it's
relevant, but not a blocker:

"and is not maintained by Object Mentor."

Build of the samples/ in the bin zip with .m2/repository removed: Succeeds.

Build of all the source with .m2/repository removed:   I accidentally
did it under JDK 1.4 and got errors against the EJB jar. Retried with
1.5 and it succeeds.

+1 to the release, I'm looking forward to trying to get the m2 plugin
set up so I can migrate the JSTL impl over to a Maven build.

Hen

On Thu, Jan 22, 2009 at 1:34 PM, Petar Tahchiev
 wrote:
> Hi guys,
>
> here is another attempt to release Cactus 1.8.1
>
> As promised I made a new tag:
> http://svn.apache.org/repos/asf/jakarta/cactus/tags/1.8.1-rc3/
>
> and the artifacts:
> http://people.apache.org/~ptahchiev/1.8.1-rc3/
>
> Please cast you vote.
> Here is mine:
>
> +1
>
> The vote is open 72 hrs.
>
> Thanks
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
>
> EOOXML objections
> http://www.grokdoc.net/index.php/EOOXML_objections
>
> Public PGP Key at:
> http://keyserver.linux.it/pks/lookup?op=get&search=0x1A15B53B761500F9
> Key Fingerprint: AA16 8004 AADD 9C76 EF5B  4210 1A15 B53B 7615 00F9
>

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

Re: [VOTE] Release Jakarta Cactus 1.8.1

[Henri Yandell]

That worked for me - trunk is happy :)

Thanks,

Hen

On Wed, Jan 21, 2009 at 1:24 PM, Petar Tahchiev
 wrote:
> Hi Henry,
>
> I followed your instructions and luckily was able to reproduce the
> behaviour.
> What I did was:
>
> unzip rc-1
> mvn clean install -> Did not fail;
> change the localrepostiry to~/.m2/repository1
> rm -rf rc1
> unzip rc-1
> mvn clean install -> FAILED
>
> Next steps:
> exactly the same, but against the trunk. In the trunk we print the
> testinput.dir property.
> I was not amazed that the testinput.dir was printed to be.src/test-input.
> What amazed me was the value of testInputDir.getAbsolutePath()
> It was
>
> /home/peter/bin/workspace/cactus-1.8.1-rc1-src/src/test-input
>
> The problem was that my test-input should reside in
> /home/peter/bin/workspace/cactus-1.8.1-rc1-src/integration/ant/src/test-input
>
> You see somehow Maven misinterpretes the ${basedir} and
> suggests it to be the root of the project, instead of /root/integration/ant/
>
> I thought that this might be connected with the issue I told sebb about:
> http://jira.codehaus.org/browse/SUREFIRE-98
>
> and since this issue is resolved I updated to the latest version of the
> surefire plugin
> and tested again. This time it all worked for me.
>
> So now I think that it is all fine.
>
> In trunk I have committed to use the latest version of
> surefire plugin.
>
> Can you retest the trunk and let me know the result.
>
> Thanks, Petar.
>
>
> On Wed, Jan 21, 2009 at 7:41 PM, Henri Yandell 
> wrote:
>
>> On Wed, Jan 21, 2009 at 3:41 AM, sebb  wrote:
>> > On 21/01/2009, Henri Yandell  wrote:
>> >> Yep - turning off my local JIRA got me passed that problem and now I
>> >>  get the same set of errors as Seb.
>> >>
>> >
>> > Does this always happen for you?
>> >
>> > If so, what is the path it is trying to find?
>> > This would require testing against trunk...
>>
>> Tried this morning - but against the rc1 (sorry). Will try against
>> trunk later (vacation right now and various parenting tasks I have to
>> do).
>>
>> mvn clean install at top level:  Failed
>> mvn clean install in integration/ant: Passed
>> mvn clean install in integration: Passed
>> mvn clean install at top level: Passed
>> rm -fr cactus-src
>> unzip
>> mvn clean install at top level: Passed
>> mv m2 repo to bckp
>> mvn clean install at top level: Failed
>> mvn clean install at top level: Passed
>>
>> Error in integration/ant failure:
>>
>> junit.framework.AssertionFailedError: The system property
>> 'testinput.dir' must point to an existing directory
>>
>> Hen
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: general-h...@jakarta.apache.org
>>
>>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
>
> EOOXML objections
> http://www.grokdoc.net/index.php/EOOXML_objections
>
> Public PGP Key at:
> http://keyserver.linux.it/pks/lookup?op=get&search=0x1A15B53B761500F9
> Key Fingerprint: AA16 8004 AADD 9C76 EF5B  4210 1A15 B53B 7615 00F9
>

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

Re: [VOTE] Release Jakarta Cactus 1.8.1

[Henri Yandell]

On Wed, Jan 21, 2009 at 3:41 AM, sebb  wrote:
> On 21/01/2009, Henri Yandell  wrote:
>> Yep - turning off my local JIRA got me passed that problem and now I
>>  get the same set of errors as Seb.
>>
>
> Does this always happen for you?
>
> If so, what is the path it is trying to find?
> This would require testing against trunk...

Tried this morning - but against the rc1 (sorry). Will try against
trunk later (vacation right now and various parenting tasks I have to
do).

mvn clean install at top level:  Failed
mvn clean install in integration/ant: Passed
mvn clean install in integration: Passed
mvn clean install at top level: Passed
rm -fr cactus-src
unzip
mvn clean install at top level: Passed
mv m2 repo to bckp
mvn clean install at top level: Failed
mvn clean install at top level: Passed

Error in integration/ant failure:

junit.framework.AssertionFailedError: The system property
'testinput.dir' must point to an existing directory

Hen

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

Re: [VOTE] Release Jakarta Cactus 1.8.1

[Henri Yandell]

Yep - turning off my local JIRA got me passed that problem and now I
get the same set of errors as Seb.

Hen

On Tue, Jan 20, 2009 at 2:11 PM, Petar Tahchiev
 wrote:
> Actually Hentry's problem
> was that he had something alreadty running on port 8080.
>
> But you are right. We check if the property is set :-(
>
> Ok, I will try to investigate further.
>
> On Wed, Jan 21, 2009 at 12:06 AM, sebb  wrote:
>
>> On 20/01/2009, Petar Tahchiev  wrote:
>> > Hi guys,
>> >
>> >  I think I found the problem, but since I cannot reproduce
>> >  this behaviour I am clueless if this will work.
>> >  I think the problem is here:
>> >
>> >  http://jira.codehaus.org/browse/SUREFIRE-98
>>
>> The issue relates to not finding a property - however the code already
>> does a separate check to see if the property has been retrieved OK, so
>> I don't think it applies here.
>>
>> >  I changed the version of the Surefire plugin we use to the latest
>> >  one.
>> >
>> >  I have commited it. Anything else before I make the RC-3 and cast the
>> vote?
>> >
>>
>> Probably best if Henri could provide more info on the failure he saw,
>> which I think was different from mine.
>>
>> I'm also intending to try a test on Unix.
>>
>> I suggest waiting a bit.
>>
>> >
>> >  Thanks again, Petar.
>> >
>> >  On Tue, Jan 20, 2009 at 10:51 PM, Petar Tahchiev <
>> >
>> > paranoiabla.li...@gmail.com> wrote:
>> >
>> >  > Hi Sebb,
>> >  >
>> >  > I removed the CDDL license and described the servlet-api as
>> >  > an Apache 2.0 licensed. I also added the Apache license headers.
>> >  > I also changed the version of AspectJ we are using.
>> >  >
>> >  > About the test failures that you mention I think they are different
>> >  > from what Henry is getting. Anyways I am unable to reproduce them :-(
>> >  >
>> >  > What should I do? Do I need to make a RC-3 and call the vote on it?
>> >  >
>> >  > Thanks for the tips guys.
>> >  >
>> >  >
>> >  > On Tue, Jan 20, 2009 at 9:42 PM, sebb  wrote:
>> >  >
>> >  >> On 20/01/2009, sebb  wrote:
>> >  >> > On 20/01/2009, Petar Tahchiev  wrote:
>> >  >> >  > Hi all,
>> >  >> >  >
>> >  >> >  >  maybe I am too impatient, but has anybody tried the artifacts?
>> >  >> >
>> >  >> >
>> >  >> > 1 minor problem - the .asc files should be detached ascii
>> signatures,
>> >  >> >  not signed archives.
>> >  >> >  No need to recreate the RC, just recreate the .asc files.
>> >  >> >
>> >  >> >  We don't normally provide binary .sig files - they can be deleted.
>> >  >> >
>> >  >> >  I'm still looking at other aspects of the RC.
>> >  >> >
>> >  >>
>> >  >> The servlet-api-2.4.jar file is an Apache version, as Henri already
>> >  >> mentioned.
>> >  >> The cddl licence should be deleted, and the README updated.
>> >  >>
>> >  >> Like Henri, I also get test failures:
>> >  >>
>> >  >> [surefire] Tests run: 5, Failures: 3, Errors: 0, Time elapsed: 0.25
>> >  >> sec  FAILURE !!
>> >  >> [surefire] Running
>> >  >> org.apache.cactus.integration.ant.deployment.webapp.TestWarArchive
>> >  >> [surefire] Tests run: 3, Failures: 3, Errors: 0, Time elapsed: 0.031
>> >  >> sec  FAILURE !!
>> >  >> [surefire] Running
>> >  >> org.apache.cactus.integration.ant.deployment.webapp.TestWebXml
>> >  >> [surefire] Tests run: 54, Failures: 0, Errors: 0, Time elapsed: 2.359
>> sec
>> >  >> [surefire] Running
>> >  >> org.apache.cactus.integration.ant.deployment.webapp.TestWebXmlVersion
>> >  >> [surefire] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.093
>> sec
>> >  >> [surefire] Running
>> org.apache.cactus.integration.ant.TestCactifyEarTask
>> >  >> [surefire] Tests run: 3, Failures: 3, Errors: 0, Time elapsed: 0.031
>> >  >> sec  FAILURE !!
>> >  >> [surefire] Running
>> org.apache.cactus.integration.ant.TestCactifyWarTask
>> >  >> [surefire] Tests run: 21, Failures: 21, Errors: 0, Time elapsed:
>> 0.281
>> >  >> sec  FAILURE !!
>> >  >> [surefire] Running org.apache.cactus.integration.ant.TestCactusTask
>> >  >> [surefire] Tests run: 7, Failures: 7, Errors: 0, Time elapsed: 0.078
>> >  >> sec  FAILURE !!
>> >  >> [surefire] Running
>> org.apache.cactus.integration.ant.TestCactusTestTask
>> >  >> [surefire] Tests run: 7, Failures: 7, Errors: 0, Time elapsed: 0.094
>> >  >> sec  FAILURE !!
>> >  >> [surefire] Running
>> >  >> org.apache.cactus.integration.ant.TestRunServerTestsTask
>> >  >> [surefire] Tests run: 6, Failures: 6, Errors: 0, Time elapsed: 0.078
>> >  >> sec  FAILURE !!
>> >  >>
>> >  >> I ran "mvn test", which failed when it could not find the cactus
>> jars.
>> >  >> It would be better if this worked without needing to do "mvn install"
>> >  >> first.
>> >  >>
>> >  >> I then ran "mvn install" and got the errors shown above.
>> >  >>
>> >  >> It looks like these are all caused by
>> >  >>
>> >  >> junit.framework.AssertionFailedError: The system property
>> >  >> 'testinput.dir' must point to an existing directory
>> >  >>at junit.framework.Assert.fail(Assert.java:4

Re: [VOTE] Release 1.8.1 of Cactus

[Henri Yandell]

Clicked that the cause is my already having something on port 8080.

Hen

On Tue, Jan 20, 2009 at 12:48 AM, Petar Tahchiev
 wrote:
> Hi Henry,
>
> unfortunately I am unable to reproduce this behaviour. :-(
>
> I run "mvn clean install" in the source unpacked directory and everything
> goes smooth.
>
> Can you tell me what is the error in the test-logs?
>
> Or maybe try to run it again?
>
> Or even try the rc2, which is here:
> http://people.apache.org/~ptahchiev/1.8.1-rc2/<http://people.apache.org/%7Eptahchiev/1.8.1-rc2/>
>
> Thanks, Petar
>
> On Tue, Jan 20, 2009 at 2:58 AM, Henri Yandell 
> wrote:
>
>> I ran 'mvn clean install' in the source unpacked directory:
>>
>> ---
>>  T E S T S
>> ---
>> Running org.apache.cactus.extension.jetty.TestJettyTestSetup
>> log4j:WARN No appenders could be found for logger
>> (org.apache.cactus.internal.util.ClassLoaderUtils).
>> log4j:WARN Please initialize the log4j system properly.
>> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 5.05
>> sec <<< FAILURE!
>> Running org.apache.cactus.TestAll
>> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
>>
>> Results :
>>
>> Tests in error:
>>
>>  
>> testSetUpWhenServerNotAlreadyStarted(org.apache.cactus.extension.jetty.TestJettyTestSetup)
>>
>>  
>> testSetUpWhenServerIsAlreadyStarted(org.apache.cactus.extension.jetty.TestJettyTestSetup)
>>
>> Hen
>>
>> On Sun, Jan 18, 2009 at 1:05 PM, Petar Tahchiev
>>  wrote:
>> > Hello guys,
>> >
>> > It's been more than 10 months since I released Cactus version 1.8.0,
>> > and not I am trying to push the 1.8.1 release. I have closed some
>> > issues in the JIRA, added a maven2 plugin for Cactus and included a
>> > sample EJB3 application, as a reference how to test EJB3.
>> >
>> > Here is the tag code-base:
>> > http://svn.apache.org/repos/asf/jakarta/cactus/tags/1.8.1-rc1/
>> >
>> > And here are the archives:
>> > http://people.apache.org/~ptahchiev/1.8.1-rc1/<http://people.apache.org/%7Eptahchiev/1.8.1-rc1/>
>> <http://people.apache.org/%7Eptahchiev/1.8.1-rc1/>
>> >
>> > Please test and cast your vote.
>> >
>> > [+1]Go man, go!
>> >  0]  I don't care.
>> > [-1] I am against it, because ...
>> >
>> > Here is mine:
>> >
>> > +1
>> >
>> > Thanks, Petar.
>> >
>> > --
>> > Regards, Petar!
>> > Karlovo, Bulgaria.
>> >
>> > EOOXML objections
>> > http://www.grokdoc.net/index.php/EOOXML_objections
>> >
>> > Public PGP Key at:
>> > http://keyserver.linux.it/pks/lookup?op=get&search=0x1A15B53B761500F9
>> > Key Fingerprint: AA16 8004 AADD 9C76 EF5B  4210 1A15 B53B 7615 00F9
>> >
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: general-h...@jakarta.apache.org
>>
>>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
>
> EOOXML objections
> http://www.grokdoc.net/index.php/EOOXML_objections
>
> Public PGP Key at:
> http://keyserver.linux.it/pks/lookup?op=get&search=0x1A15B53B761500F9
> Key Fingerprint: AA16 8004 AADD 9C76 EF5B  4210 1A15 B53B 7615 00F9
>

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

Re: [VOTE] Release 1.8.1 of Cactus

[Henri Yandell]

I ran 'mvn clean install' in the source unpacked directory:

---
 T E S T S
---
Running org.apache.cactus.extension.jetty.TestJettyTestSetup
log4j:WARN No appenders could be found for logger
(org.apache.cactus.internal.util.ClassLoaderUtils).
log4j:WARN Please initialize the log4j system properly.
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 5.05
sec <<< FAILURE!
Running org.apache.cactus.TestAll
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec

Results :

Tests in error:
  
testSetUpWhenServerNotAlreadyStarted(org.apache.cactus.extension.jetty.TestJettyTestSetup)
  
testSetUpWhenServerIsAlreadyStarted(org.apache.cactus.extension.jetty.TestJettyTestSetup)

Hen

On Sun, Jan 18, 2009 at 1:05 PM, Petar Tahchiev
 wrote:
> Hello guys,
>
> It's been more than 10 months since I released Cactus version 1.8.0,
> and not I am trying to push the 1.8.1 release. I have closed some
> issues in the JIRA, added a maven2 plugin for Cactus and included a
> sample EJB3 application, as a reference how to test EJB3.
>
> Here is the tag code-base:
> http://svn.apache.org/repos/asf/jakarta/cactus/tags/1.8.1-rc1/
>
> And here are the archives:
> http://people.apache.org/~ptahchiev/1.8.1-rc1/
>
> Please test and cast your vote.
>
> [+1]Go man, go!
>  0]  I don't care.
> [-1] I am against it, because ...
>
> Here is mine:
>
> +1
>
> Thanks, Petar.
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
>
> EOOXML objections
> http://www.grokdoc.net/index.php/EOOXML_objections
>
> Public PGP Key at:
> http://keyserver.linux.it/pks/lookup?op=get&search=0x1A15B53B761500F9
> Key Fingerprint: AA16 8004 AADD 9C76 EF5B  4210 1A15 B53B 7615 00F9
>

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

Re: [VOTE] Release 1.8.1 of Cactus

[Henri Yandell]

On Sun, Jan 18, 2009 at 1:37 PM, sebb  wrote:
> On 18/01/2009, Petar Tahchiev  wrote:
>> Hello guys,
>>
>>  It's been more than 10 months since I released Cactus version 1.8.0,
>>  and not I am trying to push the 1.8.1 release. I have closed some
>>  issues in the JIRA, added a maven2 plugin for Cactus and included a
>>  sample EJB3 application, as a reference how to test EJB3.
>>
>>  Here is the tag code-base:
>>  http://svn.apache.org/repos/asf/jakarta/cactus/tags/1.8.1-rc1/
>
>
> The licences/ directory contains a copy of AL 2.0, which is not really
> needed as it is in the LICENSE file. If you do want to keep it, then
> for consistency it should be referred to from the LICENSE file.
>
> There is also a copy of the CDDL, but that is not referenced from the
> LICENSE file nor in the NOTICE file. According to the README.txt file
> it is for the Servlet API - the N & L files need to be updated
> accordingly.

The servlet-api.jar is an Apache one though, not a CDDL one, so this
seems more like something to delete from the readme.

The HttpUnit license is MIT rather than HttpUnit specific.

Hen

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

Re: [VOTE] JMeter 2.3.2RC3

[Henri Yandell]

MD5, PGP good.

It's a bit odd that the binary version comes chock full of jars and
the source version doesn't. When I run 'ant' in the source version I
get:

BUILD FAILED
/Users/hen/apache/jmeter/jakarta-jmeter-2.3.2/build.xml:925:
/Users/hen/apache/jmeter/jakarta-jmeter-2.3.2/lib/opt not found.

I'm also suspect of whether it will build with so few jars available.
I don't see junit in there, or being hooked up to download.

In the current source download, the geronimo and velocity jars should
ideally have their license and notice files.

The following jars need license files in the binary download:

junit (CPL)
htmllexer (I'm assuming it's under the htmlparser CPL?)
js_rhino (MPL iirc)

Ideally, various ASF Apache 2.0 licenses/notices would also be there;
but those are the three important ones.

Hen

On Tue, May 27, 2008 at 4:50 PM, sebb <[EMAIL PROTECTED]> wrote:
> [Third time lucky, I hope]
>
>  There is one trivial code change from RC1:
>  * Log the property java.vm.name which shows whether the -client or -server
>  Java flag was used when starting JMeter
>
>  Otherwise the main changes relate to the way the archives are created:
>  the tar files use LF endings for native files, and the zip files use
>  CRLF endings. The JMX test and demo files have been updated to the new
>  format. Some AL headers were added.
>
>  As far as I can tell I've fixed all the previous test problems that
> were reported (and one I accidentally introduced in RC2 when the EOL
> settings were tidied up).
>
>  Note that there is a bug in Java on some Linux systems that manifests
>  itself as the follow error:
>
>  [java] WARNING: Couldn't flush user prefs:
>  java.util.prefs.BackingStoreException:
>  java.lang.IllegalArgumentException: Not supported: indent-number
>
>
>  Archives/hashes/sigs and RAT report:
>  http://people.apache.org/~sebb/jmeter-2.3.2RC3/dist
>
>  Site/Docs are here:
>  http://people.apache.org/~sebb/jmeter-2.3.2RC3/docs
>
>  Tag:
>  http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_3_2RC3
>
>  Keys are here:
>  http://svn.apache.org/repos/asf/jakarta/jmeter/trunk/KEYS.txt
>  also
>  http://www.apache.org/dist/jakarta/jmeter/KEYS
>
>  All feedback (and votes!) welcome.
>
>  [  ]+1 - the release candidate is OK
>  [  ]-1 - there is a problem (please indicate what it is)
>
>  The vote will remain open for at least 72 hours.
>
>  Note: If the vote passes, the intention is to release the archive
>  files and create the release tag from the RC3 tag.
>
>  Here's my:
>
>  +1
>
> 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]

Re: Cactus Development For a RC

[Henri Yandell]

On Jan 31, 2008 7:34 AM, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> On Jan 31, 2008 3:26 PM, Magnus Grimsell <[EMAIL PROTECTED]> wrote:
> > > Well, the version of Cargo integrated is: 0.9
> >
> > Ok, I've done some fixes for Cactus to work with Cargo 1.0-SNAPSHOT.
> > Once cargo releases 1.0 I'll be able to commit them.
> >
> > > One other quick question. My PGP key is signed only by Roy
> > > Fielding(I missed
> > > the
> > > key-signing party in Atlanta :-)) so will I be able to make a release?
> >
> > I have never been involved in releasing Cactus. Maybe someone else can 
> > share some light on this?
>
> AFAIK you can (I've done several ASF releases and my key is signed by
> nobody) - its nice to have but not required and the release signing
> FAQ doesn't say its required:
> http://www.apache.org/dev/release-signing.html#web-of-trust

Same view here. Key-signing's not a blocker.

Hen

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

Re: [VOTE] JMeter 2.3.1RC1

[Henri Yandell]

+1, with various minor notes.

Signatures are good. MD5s are good.

The src tgz contains:

> jakarta-jmeter-2.3.1RC1/bin/jmeter
> jakarta-jmeter-2.3.1RC1/bin/jmeter-server
> jakarta-jmeter-2.3.1RC1/bin/jmeter.sh

but the src zip does not.

Otherwise the archives seem the same.

The build fails for just the source. I know the README says to unpack
both source and binary, but it would be good if the build.xml could
state that too. It's an odd thing to do.

=-=-=-=
Buildfile: build.xml

clean:
   [delete] DEPRECATED - Use of the implicit FileSet is deprecated.
Use a nested fileset element instead.

BUILD FAILED
/Users/hen/apache/tmp/jakarta-jmeter-2.3.1RC1/build.xml:1349:
/Users/hen/apache/tmp/jakarta-jmeter-2.3.1RC1/lib/ext not found.
=-=-=-=-=

The build succeeds once I follow the instructions correctly; and
JMeter started happily (though I didn't test actually using it).

"ant test" fails; there are two failures and one error. I'm running on
OS X 10.4, JDK 1.5, Ant 1.6.5.

Error: 1) 
org.apache.jmeter.protocol.http.sampler.TestHTTPSamplersAgainstHttpMirrorServerjava.lang.Exception:
Could not start mirror server
Failure: 1) 
BSH1(org.apache.jmeter.functions.PackageTest)junit.framework.AssertionFailedError:
BeanShell not present
Failure: 2) 
testTimerBSH(org.apache.jmeter.timers.PackageTest)junit.framework.AssertionFailedError:
expected:<60> but was:<0>

Website wise, the download binary and download source links should be
changed to a single Download link pointing to:

http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi

The bugs page has a typo (Bugzilla + BugZilla).

Hen

On Nov 24, 2007 2:45 PM, sebb <[EMAIL PROTECTED]> wrote:
> I've created JMeter 2.3.1 RC1 in the directory:
>
> http://people.apache.org/~sebb/jmeter-2.3.1/dist
>
> Site/Docs are here:
> http://people.apache.org/~sebb/jmeter-2.3.1/docs
>
> Tag:
> http://svn.apache.org/repos/asf/jakarta/jmeter/tags/v2_3_1RC1
>
> Keys are here:
> http://svn.apache.org/repos/asf/jakarta/jmeter/trunk/KEYS.txt
> also
> http://www.apache.org/dist/jakarta/jmeter/KEYS
>
> All feedback (and votes!) welcome.
>
> [ ]+1 - the release candidate is OK
> [ ]-1 - there is a problem (please indicate what it is)
>
> The vote will remain open for at least 72 hours.
>
> If the vote passes, the intention is to create a formal 2.3.1 release
> from the RC1 tag.
>
> Here's my:
>
> +1
>
> sebb AT apache DOT org
>
> -
> 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 at the center of the (ASF) universe

[Henri Yandell]

On Nov 19, 2007 12:44 AM, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On Nov 18, 2007 10:20 AM, Thomas Vandahl <[EMAIL PROTECTED]> wrote:
> > Geir Magnusson Jr. wrote:
> > > Why?  W/o Jakarta, the diagrams don't make any sense.  For example, the
> > > Jakarta-free one has velocity's only relationship to DB (!), and for
> > > Harmony, to DB and XML!  Ant, arguably one of the most pervasive
> > > projects, has no connection to anything else...
> > >
> > I agree with Geir. The graph that includes Jakarta looks much more
> > realistic than the other one.
> >
>
> It also pretty clearly illustrates what happens when splitting up
> Jakarta was a deliberate choice, not a random activity.  In other
> words, the resulting connectivity afterwards is more of the "well,
> duh" variety.  It is effect, not cause.

How would deliberate/random look differently?

Looks to me that it clearly illustrates what happens when people are
left in the svn karma when their subproject goes tlp.

Hen

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

Re: External plugin repository for JMeter?

[Henri Yandell]

On 10/6/07, sebb <[EMAIL PROTECTED]> wrote:
> JMeter has just been offered a Maven plugin for creating reports.
>
> Rather than include the code in JMeter, I think it would be better
> hosted at mojo.codehaus.org, along with the other Maven plugins.

Agreed.

> That got me thinking - perhaps a similar idea could be set up for
> JMeter plugins?
>
> Or is that a silly idea?

Maven plugins are glue, plugging anything out there into the Maven
system and so need a certain agility with respects to license - thus a
non-ASF site. So chiefly I think it comes down to license - is it
strongly likely that there will be lots of plugins that need non AL
2.0 licensing?

Hen

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

Re: [Jakarta Wiki] Update of "Using LGPL'd code" by HenriYandell

[Henri Yandell]

I don't think so - the 3rd party draft I link to says pretty much the
same thing.

On 10/4/07, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
> Hi!
> > The following page has been changed by HenriYandell:
> > http://wiki.apache.org/jakarta/Using_LGPL'd_code
> >
> >
> Does this mean the door to have LGPL dependencies as described below has
> been closed again?
>
> > - = Latest [EMAIL PROTECTED] informations (2006) =
> > -
> > - Lately we discussed that it might be possible that the PMC is able to 
> > vote to add LGPL stuff to a project as long as the following rule will be 
> > fulfilled.
> > -
> > - We still need the ok from legal@ before we start with this procedure.
> > -
> > - At least the jakarta PMC voted that these rules are acceptable.
> > -
> > - == Rules==
> > -
> > -  * ask the original library author to change its license or provide a 
> > double licensing model
> > -  * look for an alternative implementation with an ASF friendly license
> > -  * the build script BY DEFAULT excludes java classes depending on LGPL
> > -  * a special parameter will enable building these classes
> > -  * its not allowed to bundle the LGPL library with any 
> > distribution\\(nightly, release)
> > -  * the function the library gains from the LGPL stuff is fully optional
> > -  * a bridging api (which can reside within the same project - so can be 
> > hosted at apache) will be used to access these LGPL stuff to clearly show 
> > its optional behaviour
> > -  * a vote for adding a LGPL dependency to a project on pmc@
> > -
> > - The technical stuff how to setup the build has to be figured out.
> >
>
> Ciao,
> Mario
>
>
> -
> 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: Suggestion to use OpenGrok to index all Jakarta source code

[Henri Yandell]

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.

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]

Re: [discuss] Slide + HttpComponents => TLP

[Henri Yandell]

On 8/18/07, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-08-18 at 13:40 +0200, Roland Weber wrote:
> > >> Disassociation from the server side.
> > >
> > > What is the benefit of that? At any rate in my opinion it is not worth
> > > trouble of rebranding the whole project.
> >
> > Will the current [EMAIL PROTECTED] and [EMAIL PROTECTED]
> > mailing lists continue to exist alongside [EMAIL PROTECTED]
> > and [EMAIL PROTECTED], where the Slide WebDAV client finds
> > a new home?
>
> Yes, as aliases. I think it is a standard practice. But it is a detail
> when can take care of in the normal course of things.

Living on the same mailing list is the best option. Otherwise you just
end up with yet more fragmented communities.

Hen

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

Re: Add company to Third-Party Support page

[Henri Yandell]

Thanks for the request Rida.

You'll notice that none of the projects you list are in Jakarta -
which is true of most of the vendors listed on that page. We've
decoupled the vendors page from the rest of the site, and will be
removing the page as it's no longer relevant.

Sorry that that had not already happened,

Hen

On 8/23/07, Rida Benjelloun <[EMAIL PROTECTED]> wrote:
> Hi,
> I would like to add Doculibre Inc. to "Third-Party Support" page (Url :
> http://jakarta.apache.org/site/vendors.html) in the section "Complete
> solution providers (alphabetical order)".
>
> Doculibre Inc. / http://www.doculibre.com
> - Open source and Enterprise Content Management consulting. (Lucene, Nutch,
> Hadoop, Solr, Tika, Wiket, Struts etc.)
> - Québec-Montréal-Ottawa, QC, Canada
> - info at doculibre.com
>
> Best Regards.
>
> -
> Rida Benjelloun
> Doculibre inc.
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> Cel: 418-262-3222
> Tel: 418-353-3390
> Site Web : http://www.doculibre.com
> -
>

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

Killing the getinvolved page?

[Henri Yandell]

I've migrated (somewhat) the Get Involved from the Jakarta site to the
Apache site:

* http://jakarta.apache.org/site/getinvolved.html
* http://www.apache.org/foundation/getinvolved.html

Any thoughts on removing the Jakarta one and replacing it with a link
to the central one?

Hen

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

Re: HttpClient 3.x Homepage

[Henri Yandell]

Sorry, yeah. Just doing things at the macro level and then trying to
figure out what got screwed up lower down.

So what should we do?

On 7/31/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote:
> That is a result of the full redirection of the commons from Jakarta to
> commons.apache.org and probably just a honest oversight.
>
> Best regards
> Henning
>
>
>
> On Tue, 2007-07-31 at 20:59 +0200, Roland Weber wrote:
> > Hi all,
> >
> > the HttpClient 3.x homepage seems to have moved to
> > http://commons.apache.org/httpclient/index.html
> >
> > I'm a bit surprised to notice that, considering that
> > I had started a discussion about the future location
> > of that site which has not lead to a conclusion.
> > I would at least have expected some kind of advance
> > warning before a page for which we are responsible
> > is moved?
> >
> > cheers,
> >   Roland
> >
> >
> > -
> > 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: What about HttpClient? (was: Commons is TLP)

[Henri Yandell]

On 6/24/07, Roland Weber <[EMAIL PROTECTED]> wrote:


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

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

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

Please share your thoughts on this. My preferred option
is 3, but I don't know how much trouble that will cause
when setting up redirects to the new commons site.


Probably some. Plus the svn move will be painful.

Either 1 or 2 seem fine to me and whatever those committing to
HttpComponent/HttpClient want to do is fine by me. 3 seems painful to
do.

Hen

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

Re: Commons is TLP

[Henri Yandell]

Don't go the subtask route. Keep it all on the one issue as TLP Admin
and Joe'll take care of things.

Hen

On 6/22/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote:

There is a Velocity JIRA Issue with a lot of subtasks that basically has
everything that is needed/can be done for a new TLP. Scott cloned it for
Turbine, so it is TRB-44 and INFRA-1249. These might be good starting
points.

Best regards
Henning

Torsten Curdt schrieb:
>
> On 21.06.2007, at 00:57, Martin van den Bemt wrote:
>
>> Hi everyone,
>>
>> The new Commons TLP was established today, with Torsten Curdt as Vice
>> President.
>
> ...so where do we start with the TLP move is the question :)
>
> cheers
> --
> Torsten
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

--
Henning P. Schmiedehausen  -- [EMAIL PROTECTED] | J2EE, Linux
91054 Buckenhof, Germany   -- +49 9131 506540  | Apache person
Open Source Consulting, Development, Design| Velocity - Turbine

  "Save the cheerleader. Save the world."

-
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 site directory no longer contains .svn directories

[Henri Yandell]

On 6/14/07, Henri Yandell <[EMAIL PROTECTED]> wrote:

On 6/9/07, Scott Eade <[EMAIL PROTECTED]> wrote:
> Henri Yandell wrote:
> > Sorry - I was doing the POI one on www.apache and jakarta.apache and
> > cleaned up the remaining velocity/turbine bits on jakarta.apache while
> > doing that.
> >
> > The download page points to closer.cgi, so I figured things were good.
> > Do you need me to roll back?
> If it is not too much trouble.  I would rather have the leisure of doing
> this as time becomes available rather than having to drop everything
> else I am working on in order to address this today.

Damn - sorry. Didn't notice the reply.

I'll look into reverting tonight.


Scratch that - jakarta/turbine redirects and there's nothing on
turbine.apache.org pointing to the Jakarta download pages, so doesn't
seem any value in putting the bits back.

Hen

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

Re: Jakarta site directory no longer contains .svn directories

[Henri Yandell]

On 6/9/07, Scott Eade <[EMAIL PROTECTED]> wrote:

Henri Yandell wrote:
> Sorry - I was doing the POI one on www.apache and jakarta.apache and
> cleaned up the remaining velocity/turbine bits on jakarta.apache while
> doing that.
>
> The download page points to closer.cgi, so I figured things were good.
> Do you need me to roll back?
If it is not too much trouble.  I would rather have the leisure of doing
this as time becomes available rather than having to drop everything
else I am working on in order to address this today.


Damn - sorry. Didn't notice the reply.

I'll look into reverting tonight.

Hen

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

Re: Commons TLP for Board Meeting ?

[Henri Yandell]

On 6/11/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote:

Hi everyone,

The board meeting is the 20th, so it would be nice if we can add the commons 
TLP proposal for that
meeting.
So we probably need to finalize the proposal and send it off during the weekend.


I think the majority opinion was to send the proposal as is.

The only problem I can think of is that there were people who said
they'd not put their names on there. Not that it'll be hard to add
them on to the PMC later.

Hen

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

Re: Jakarta site directory no longer contains .svn directories

[Henri Yandell]

Sorry - I was doing the POI one on www.apache and jakarta.apache and
cleaned up the remaining velocity/turbine bits on jakarta.apache while
doing that.

The download page points to closer.cgi, so I figured things were good.
Do you need me to roll back?

Hen

On 6/8/07, Scott Eade <[EMAIL PROTECTED]> wrote:

I set Turbine to redirect yesterday.  I will delete the turbine
directory once I am happy that everything is okay with the new Turbine
TLP site.  We still have Turbine on the Jakarta downloads page - we will
sort this out when we have the Turbine download page working.

In summary: We are taking care of Turbine as part of the TLP move and
will tidy up after ourselves towards the end of this process.

Thanks,

Scott

Martin van den Bemt wrote:
> Good one :) Didn't fix Velocity yet (better to put that in the root .htaccess 
and get rid of subdirs)
>
> So Turbine can be redirected too ?
>
> Mvgr,
> Martin
>
> Henning Schmiedehausen wrote:
>
>> Once, the sites are up, feel free to
>> copy  /www/jakarta.apache.org/velocity/.htaccess
>> and /www/velocity.apache.org/moving.html
>>
>>  Best regards
>>  Henning
>>
>>
>> On Thu, 2007-06-07 at 22:24 +0200, Martin van den Bemt wrote:
>>
>>> Thanx for clearing it up, I was starting to doubt myself, since I did some 
cleanup of old Jakarta
>>> projects a couple of days ago (no worries, didn't touch POI and Turbine yet 
!)
>>>
>>> Mvgr,
>>> Martin
>>>
>>> Thomas Vandahl wrote:
>>>
 sebb wrote:

> Thanks; that's also fixed the missing updates.
>
> I wonder how it happened?
>
 That was me. I could have *sworn* that I copied these over by accident
 and as busy to remove them as fast as possible. Is this procedure "svn
 update - edit - ant - svn commit - svn update site" documented
 somewhere? I've never seen anything like this.


 Bye, Thomas.

 -
 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]




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

Re: [PROPOSAL] The future of Jakarta

[Henri Yandell]

On 5/30/07, Craig McClanahan <[EMAIL PROTECTED]> wrote:

On 5/30/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
> On 5/30/07, Ted Husted <[EMAIL PROTECTED]> wrote:
> > On 5/26/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
> > > Ack in terms of driving a community away because it is unable to meet
> > > our arbitrary criteria.
> >
> > That sort of thinking just seems so Borg to me. It's another way of
> > saying that a software product only has value if its hosted by the
> > ASF.
> >
> > If a subproject, or even a project, is down to one or two committers,
> > and those committers can't find a third, and don't want to apply to
> > the Commons or declare the product dormant, then setting up shop on
> > GoogleCode is an excellent alternative. I've done the same myself, and
> > it's not the least bit painful. In many ways, it's joyful.
>
> Which Apache projects have you moved to GoogleCode and found it a
> joyful experience? ie) I presume you mean starting a project there
> rather than moving a community from the ASF.
>

I suspect you are missing the point that *I* at least think Ted is
making ... doing open source outside of Apache is fun, if you like
doing open source.  Doing open source inside Apache is a pain ... even
if you like doing open source, and even if you are an insider and know
all the loopholes.

> My distaste for driving people to an open source repository is not
> because of the repositories, but because our rules have driven them
> out.
>
> > It might even be healthy if more ASF committers were involved with
> > other hosts. The ASF may be a cult, but it should not also be a fetish
> > :)
>
> Other communities, not 'host's. ie) You won't learn much from
> code.google, java.net or sf.net other than whether you love or hate
> the infrastructure. I bet a lot of us are involved with other
> communities.
>

You're right that it's more community oriented than host oriented
(because it is about the process, not the technology).  You are wrong
if you believe that "the Apache Way" (if there is such a singular
thing, which I would dispute based on seven years of evidence to the
contrary) makes things easier rather than harder.  Yes, there are some
benefits of the "Apache" brand, but it is an open question whether
they are worth the costs.

For myself, I have lots of ideas to do future open source projects,
and (at the moment) zero plans to do them here at Apache.  The
emotional and procedural and cultural costs are too high to compensate
for the branding benefits.


Been there (ie: pissed off), done that (ie: grumbled). It's not the
black and white scenario it seems at first. I'm still trying to decide
what it all means to me though, sometimes moving back to the UK near
my parents and finding a nice dull job pushing numbers is so very very
attractive. Brain dump of current thoughts follows...serves you right
:)

---

A bunch of coders took a project written by others, forked it, hacked
around with it and had a lot of success - based primarily on it being
the right time and secondarily on having created a positive atmosphere
to development. They created a foundation to support this development
- its goal to enforce the atmosphere that the first project naturally
evolved to.

A bit later, as the foundation grew beyond their original development,
they didn't like the different cultures that inhabited the foundation
and, effectively, the Apache Way was created to impose a monoculture.
This is imposed by a relatively vague set of memes that are strongly
applied by many members of the community. The preaching of this way
also happily created a set of memes to resist the monoculture advance;
bureaucracy, hypocrisy, arrogance.

---

Definition for the below: "Enterprise Open Source" - the massing of
open source projects into a larger group. Sorry that that phrase
clashes with existing ones, I haven't got a better term yet. Might
just have to be 'Enterprise Foundation'. So - Enterprise meaning
'large collection of smaller entities'.

---

The strongest anti-meme is the anger against enforcement. This is the
primary difference between Codehaus and Apache for example, where
Apache enforces, Codehaus merely recommends. Once you sit down and
identify many of the Apache memes, I don't think open source
committers would be against them. Open source leaders might.

Remember... the ideas in the Apache Way are not reality, they are
unreachable targets.

Idea -> Individuals. Companies don't get to use their bulk to bully
individuals out of the conversation. Employers don't get to strongarm
their employees.

I think we get relatively near the ideal here. I get to walk in to an
interview and when the obligatory

Re: jakarta-watchdog-4.0 source download

[Henri Yandell]

Surprisingly hard to find.

Watchdog has technically moved to tomcat.apache.org, but as it was
dormant before then there's not been a lot done but move the svn over
there. ie) Jakarta still has the 'it's dormant' bit, but as it moved
the download page was removed.

Looking in http://archive.apache.org/dist/jakarta/ , I'm not even sure
where the Watchdog downloads would be (assuming there were releases).

So next step... to look at the svn history of the downloads part of
the site to see where it used to point. Will do that in a bit - need
to drive to work first.

Hen

On 5/30/07, Peter J Allenbach <[EMAIL PROTECTED]> wrote:

i understand this project is dormant. i would still like to download the
source. i can not seem to locate a download location. if anyone can give
me a pointer that would be very helpful.

thank you.

-
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] Release JCS 1.3

[Henri Yandell]

On 5/30/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote:

On Wed, 2007-05-30 at 19:00 +0100, sebb wrote:
> The NOTICE file is not supposed to contain any licenses.

What makes you think so? I am still a bit stumped that you so strongly
insist on this. Is there any reference (besides the cited httpd project)
to that?


For a long time I thought LICENSE was for the license only and
everything else went in NOTICE. Discussions with Cliff, and I'm pretty
sure watching other discussions on legal-discuss, made it clear that
license-things go in LICENSE, and copyright/ip things go in NOTICE.

Look at the two places in http://people.apache.org/~cliffs/3party.html
where it mentions LICENSE, both imply that the LICENSE file is the
only place to find licensing terms.

Hen

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

Re: [PROPOSAL] The future of Jakarta

[Henri Yandell]

On 5/30/07, Ted Husted <[EMAIL PROTECTED]> wrote:

On 5/26/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
> Ack in terms of driving a community away because it is unable to meet
> our arbitrary criteria.

That sort of thinking just seems so Borg to me. It's another way of
saying that a software product only has value if its hosted by the
ASF.

If a subproject, or even a project, is down to one or two committers,
and those committers can't find a third, and don't want to apply to
the Commons or declare the product dormant, then setting up shop on
GoogleCode is an excellent alternative. I've done the same myself, and
it's not the least bit painful. In many ways, it's joyful.


Which Apache projects have you moved to GoogleCode and found it a
joyful experience? ie) I presume you mean starting a project there
rather than moving a community from the ASF.

My distaste for driving people to an open source repository is not
because of the repositories, but because our rules have driven them
out.


It might even be healthy if more ASF committers were involved with
other hosts. The ASF may be a cult, but it should not also be a fetish
:)


Other communities, not 'host's. ie) You won't learn much from
code.google, java.net or sf.net other than whether you love or hate
the infrastructure. I bet a lot of us are involved with other
communities.

Hen

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

Re: [VOTE] Release JCS 1.3

[Henri Yandell]

On 5/27/07, sebb <[EMAIL PROTECTED]> wrote:

On 27/05/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote:
> The license under which the code gets licensed to our end users is in
> LICENSE.txt.
>
> Copyright notices and optional third-party licenses under which the code
> got licensed to us is in NOTICE.

Are you sure?

That does not seem to agree with the sample NOTICE file:

http://www.apache.org/licenses/example-NOTICE.txt

Nor does it seem to agree with the way that httpd use the NOTICE and
LICENSE files:

http://svn.apache.org/viewvc/httpd/httpd/trunk/

As I understand it, the NOTICE file is for attributions.
The LICENSE file is for licenses.
These may either be included inline, or in separate files referenced
from the main LICENSE file.


That's how I understand it too.

Hen

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

Re: [PROPOSAL] The future of Jakarta

[Henri Yandell]

On 5/26/07, Ted Husted <[EMAIL PROTECTED]> wrote:

On 5/25/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
> 4) Goto code.google. Ack :(

I wouldn't discount GoogleCode (or Java.net or SourceForge or
CodeHaus). Right now, there's a GoogleCode site that I use everyday,
and it's been utterly reliable. There's features I miss, but the UI is
so convenient, I don't mind. We are not Borg, and not every software
product need live under the ASF umbella.


Ack in terms of driving a community away because it is unable to meet
our arbitrary criteria.


> Jakarta2 - A flattened commons-like umbrella which in terms of change
> means a flattened dev@ list and svn changes. What I don't know is
> whether people are going to be demanding that the subsites look the
> same; ie) need to mavenize each project and adjust the site. The
> easiest way to deal with things will be to move the other subprojects
> into Commons and reestablish the Project.

This is probably just an unfortunate turn of phrase, but we can't just
"move" anyone anywhere.


Yes we can, we just choose not to. Our PMC has a history of delegating
the decision making to the subprojects, rather than making it for
them; it's not a requirement.

Still - I'm definitely presuming that that will continue. Subprojects
need to be on board. The problem is when a subproject chooses option
5; do nothing. Is that a decision we're happy with.


The Incubator PMC is not going to accept any code without volunteers to go
with it.


Things get really easy in that situation - we retire it just like
Alexandria. We've not got any code without community currently.


Likewise, we can't do anything
about the subproject websites without volunteers to do that work too.


We can volunteer. (I'll happily go in and change things :) ).


But, as a PMC, we could ask infra@ to create a shared mailing lists to
replace the others, and make karma adjustments.

Here's my take-away from Henri's post. The Jakata PMC, as it stands
today, could set a deadline for the remaining subprojects to make
other hosting arrangements (TLP, Commons, Google). Otherwise, on a
date certain, we would create single Jakarta Dev and User lists for
all the remaining subprojects to share, and open karma to all the
subprojects to all the Jakarta committers, in the style of the
Commons.

In other words, create a TLP,  join the Commons, or become a commons.

One other alternative would be for the active committers to those
remaining subprojects to draft their own resolution proposal for
creating a new Jakarta PMC, and boot the rest of us out. :) Though, if
anyone wanted to make that happen, I'd suggest making it happen for
the June board meeting, to coincide with the Commons proposal.


Chiefly, we need to decide if we're sending the Commons proposal. The
board learnt from the Shale/Struts proposal not to accept anything if
the current PMC are not happy with the situation.

Hen

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

Re: [PROPOSAL] The future of Jakarta

[Henri Yandell]

On 5/25/07, Ted Husted <[EMAIL PROTECTED]> wrote:

On 5/23/07, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> In fact, I object to the fact the it seems to be so difficult to escape 
Jakarta.

:) So far, it's been *much* less difficult than creating the Jakarta
Commons in the first place! Back in the day, we actually had a
separate mailing list just for for the discussions about whether to
create the subproject, and how it would work if we did! :)


:)


So far, the TLP resolution quickly passed by a landslide. Two of us
had reservations about an "Apache Commons" project that's devoted to
Java, as opposed to an "Apache  [Java|Jakarta|Mocha|J] Commons" that's
devoted to Java. There were two other negative votes for different
reasons, and almost thirty votes in the affirmative.

Meanwhile, some of us have pointed out that the other remaining
subprojects are within the scope of the Jakarta Commons, and have
wondered if these subprojects would now like to join the commons. Of
course, that could happen before or after the proposed resolution is
offered to the board. But, if it did happen first, that change would
remove any complaint as to using Apache Jakarta Commons as a project
name.

From the beginning, the intent was to submit the proposed resolution
to the June board meeting. There's time yet to see if the other
subprojects want to join, so nothing is being delayed.


*nod*

I think we're at a point of needing to offer options to the subprojects:

1) Go TLP (or other TLP)
2) Stay for Jakarta2 (see below)
3) Goto the Incubator - I know this is a very disliked option, but
it's better than the only other option I can think of:
4) Goto code.google. Ack :(

I admit to thinking that the three big question marks in terms of
living in a flattened dev@ list for me are Slide, JMeter and Cactus.
I'm willing to be +1 to them being in a flattened Jakarta2 with an eye
to sending them TLP if we can build community. It's effectively the
Jakarta2 community incubating them, but if it helps things move on...

Jakarta2 - A flattened commons-like umbrella which in terms of change
means a flattened dev@ list and svn changes. What I don't know is
whether people are going to be demanding that the subsites look the
same; ie) need to mavenize each project and adjust the site. The
easiest way to deal with things will be to move the other subprojects
into Commons and reestablish the Project.

Hen

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

Re: [VOTE] Commons moving to TLP

[Henri Yandell]

On 5/23/07, Stephen Colebourne <[EMAIL PROTECTED]> wrote:

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

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


At the time it was pretty valid I think - there was zero energy
available to spend on it.  CLI was a good lesson in the dangers of
letting a research revolution take over the momentum of a component.
Something for us to learn with some of our newer revolution rather
than evolution branches.


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


In fact they are :)

A contributor, Brian Egge, is charging on with the 1.x branch and I've
been working with him on that, we've one issue to go. Torsten's also
interested in seeing a release get out, so I'd be surprised if we had
any problems on a release.

I do apologise though to you, Sebb. My 'solutions' are very much a
reflection of me being tired with all this and wanting to make things
happen sooner rather than in much, much later.

Hen

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

Re: [VOTE] Commons moving to TLP

[Henri Yandell]

On 5/22/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:


Quick summary of this thread 28 Votes for (23 binding), 4 against (3
binding). Seems to me that those objecting don't seem to have
pursuaded people to change their vote. At what point do we decide on a
result?


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

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

Here's what I think could happen:

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

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

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

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

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

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

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

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

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

--

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

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

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

Hen

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

Re: [PROPOSAL] The future of Jakarta

[Henri Yandell]

On 5/21/07, Ted Husted <[EMAIL PROTECTED]> wrote:

On 5/21/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
> > Then take it to the next stage. Update the Jakarta home page to
> > include links to our other Java products that were never part of
> > Jakarta, like iBATIS, and invite all ASF Java products to use our news
> > feed. Open the door, and see if anyone walks in.
>
> I am on a different schedule, volunteering on my own terms. In my view doing 
this now is
> *way* too premature. I currently only want to invest my time and energy on 
Jakarta and
> it's current projects.

That's fair. Every volunteer should scratch their own itch :)

If other volunteers were ready to explore this course of action now,
would you object to someone creating a "[EMAIL PROTECTED]" portal here by
extending the Jakarta home page?


Easy enough to do; resurrect this page and start adding to it :)

http://svn.apache.org/viewvc/jakarta/site/xdocs/site/java_at_apache.xml?view=log&pathrev=482036

Hen

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

Re: Voting on releasing RC artificats as Final

[Henri Yandell]

On 5/21/07, Nick Burch <[EMAIL PROTECTED]> wrote:

Hi All

For the 3.0 release of POI, we followed the advice on voting on
artificats, the not the state of the tree. So, we used our ant script to
produce RC artificats, signed them, and placed them on people.apache.org
for review.

After the vote, we renamed the files from -RC4- to -FINAL-, tweaked the
filenames inside the .md5 files, and copied into /dist/.

Two snags though:
* we had to re-generate the maven pom, and re-sign it, as that holds the
release version in it, which changed
* we forgot that the .tar.gz and .zip files all have poi-3.0-rc4 as their
base directory name, since the directory name is generated dynamically
in build.xml

What do other people do about this for their releases, when voting on
artificats? Do you do each build as if it was -FINAL (so that gets embeded
into all the directory names etc), then rename the artificats for voting,
or something else?


Don't your jars contain the version number too?

The most recent release types I've done are the type where you create
the exact release and put it in your ~login where it's voted on. I
like this because it makes the actual release extremely easy. The
biggest downsides are a) someone might be idiotic and use a random jar
from a ~login and b) if you have the release date in there somewhere
you have to use the day the vote ends.

I don't like the Tomcat/Struts/HTTP Server style of bumping the
version each time, but only really because they abuse their numbering
schemes. ie) 1.3.5, 1.3.8 etc rather than 1.3.5build1, 1.3.5build4.
The general principle is sound and if your community can do the
testing to be able to decide on a GA, then it's good.

Hen

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

Re: [PROPOSAL] The future of Jakarta

[Henri Yandell]

On 5/15/07, Danny Angus <[EMAIL PROTECTED]> wrote:

Hi,

Ok, I've followed the commons TLP vote thread with some interest
because it seems to impact directly on the end-game for Jakarta.

I believe that we have to make some pretty fundamental decisions about
that future before we can fully resolve the commons TLP issues.

0/ Do we agree that the end-game is dissolution of the Jakarta PMC and
closure of the project?


+1. Our current system needs to change.


1/ If so do we wish to preserve the Jakarta brand? (the website and
possibly general@)


+1. I like the idea of keeping general.

Effectively we're talking about the much vaunted yet failed to
materialize federation concepts. XML are ahead of us in this position;
they have one project left (Xindice) for which my advice is sending it
TLP and then all they will have left is a moribund PMC and the
federation work they've done. Which I think is much like the
[EMAIL PROTECTED] page I added a couple of years back (and removed not long
ago).


   Con - Others consider that the effort of maintaining the resources
would be unacceptable to anyone.


We need to make sure it is self-maintaining to a large extent. The
DOAP stuff might be a way to go, though I think we would want to mix
it with branding and original content.


2/ If we believe that the brand should be preserved should the commons
TLP take ownership of the brand (if/when Jakarta PMC is dissolved)
   Pro - Commons is an active community which continues to fulfil the
jakarta==java remit.
   Con - Commons is not necessarily interested in the brand or
maintenance of its resources. (would people from other projects step
up)


There's a huge tie between the portal (federation) idea and the
commons idea. Both exist as a span for the projects in their category.
I'd rather see two groups showing responsibility rather than lumping
it on the one PMC. So -1 on this one.


3/ If we believe that a commons TLP should not own the brand are any
of the alternative options acceptable?
  - Retain the Jakarta PMC solely to maintain the brand


Maybe not so bad. It's a good start to being [EMAIL PROTECTED] as far as
committers/members go. We could extend it such that it's very open to
people being added. For example; there'd be no point having a Jakarta
committer without them being on the PMC.


  - Move ownership of the brand to the prc (should they agree to have it)


-1. StackOverflow.


  - Move ownership of the brand to projects.apache maintainers


-1. StackOverflow.


 x/ Should we consult more widely the Members and/or the Board?


I'm very tempted to ask for opinions on the federation idea on behalf
of both Jakarta and XML as they're both hitting the point of needing
to figure out how we would organize it. I think that part is
definitely on the shoulders of the board/members.

If we end up with code that is in maintenance (Slide, ECS, Alexandria,
JServ, whatever); are we suggesting the Jakarta PMC would handle it or
some other random group?

Hen

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

Re: [VOTE] Commons moving to TLP

[Henri Yandell]

On 5/15/07, Ted Husted <[EMAIL PROTECTED]> wrote:


We can create a "Jakarta Commons PMC" without affecting the future of
the "Jakata PMC". We should stop thinking of "Jakarta" only as an
entity, and go back to thinking of it as to the ASF synonym for
"Java", as originally intended.


Very interesting thought in terms of the "What do we call Harmony if
we can't call it Java?".

Hen

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

Re: [VOTE] Commons moving to TLP

[Henri Yandell]

On 5/13/07, Ted Husted <[EMAIL PROTECTED]> wrote:

On 5/13/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
> > I don't see why. As a member of the Jakarta PMC I'm willing to allow
> > jakarta-commons.apache.org to use our trademark :-)
>
> The problem is that you will be hijacking the Jakarta name and since the 
future of Jakarta
> (and usage of the name) is by no way set, using the Jakarta name in a new 
commons
> TLP is for me at this stage a premature call.

We can't "hijack" what is ours. This vote is not taking place on the
Jakarta Commons-Dev list. It is taking place on the Jakarta General
List, and, AFIAK, it represents a vote of the *Jakarta* PMC.

In the alternative, we "hijack" the Commons name, which, as others
have pointed out, is already being used by other ASF entities, not to
mention that it was also used by a top-level project, now closed.

* http://commons.apache.org/

I don't know if Henri has discussed the reuse of the Commons TLP name
with the Board, but it's possible not everyone will be thrilled with
creating a new Commons TLP with a different charter (e.g. "Java").


Nope, all I know of in terms of consensus is that the domain name is
available - there was an opinion that we shouldn't reuse old names,
but the consensus was in favour of commons.apache.org being reusable.

That was at least a year ago.

I think the Commons consensus that the word Java be in the resolution
makes it more likely that there will be debate.


Creating a "Jakarta Commons PMC" avoids overlap with the "closed"
Commons TLP, and avoids overlap with any future projects that might
want to create a TLP


Neither of those seem like things to avoid. The thing to avoid is
being commons.apache.org and then refusing to allow ws-commons to move
to commons.apache.org if they desired, or for .net commons to be
started there.

Maybe the drawing board is needed again.

As my random suggestion that Ted quoted points out, you can have a PMC
without their having to be TLP. Least I was told that a couple of
years ago either on board@ or face to face, so we could do the
following:

* Create the Jakarta Commons PMC, without changing the website (or
even the svn maybe).
* Continue to encourage Jakarta subprojects to move to TLP, go into
maintenance or move over to other PMCs.
* Reach a point at which we can end the Jakarta PMC, or federate or whatever.

Basically we want to clean a room up, but we don't have a spare empty
room to use as a staging point.

Hen

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

Re: [VOTE] Commons moving to TLP

[Henri Yandell]

On 5/10/07, Ted Husted <[EMAIL PROTECTED]> wrote:

On 5/8/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
> [ ] +1 I support the proposal
> [ ] +0 I don't care
> [x] -1  I'm opposed to the proposal because...

I do not feel the draft resolution adequately addresses several
remarks made in the discussion thread.


I'm in agreement with Niall. I think both of the quotes below are
mine, so I'll respond to those.



The resolution should address issues raised as to the scope of the PMC
and the use of the commons namespace. Comments on the other thread
included remarks like

* "We'll do whatever the community wants to do. If someone proposes a
Ruby library and we have a community interested in creating and
supporting a Ruby library, then it would of course be strongly
considered. "


Yep, I stand by this one. Look at Jakarta's resolution and what
Jakarta does now - it's clear that the community overrules the
resolution and I expect it's up to the board to complain if they feel
it's gone too far.



and

* "Multiple PMCs, one website. So we'd have Java Commons, Ruby
Commons, BobsYourUncle Commons PMCs, and they'd all share a
commons.apache.org website."


This one was definitely a random suggestion. If we reach a point of
impasse with another commons wanting to start, then I (with board hat
on) think the solution would be to have multiple PMCs and 1 website.
Or maybe that really means a portal and a site behind it. All
hypothetical though - XML Commons is dead, DB Commons never happened
and WS Commons is afaik not highly active. We do own the Commons space
currently.


But, as it stands, the resolution implies that the proposed PMC will
be excluded to Java and would own both the top-level "Commons" project
name and the "commons.apache.org" namespace. Neither remark is
addressed.


Yep. Personally I think that we don't need Java there. For two reasons:

1) It's community and day to day life that determines our scope, more
so than a resoltion.
2) It's (let's face it) an easier sell without Java in the text.

However the consensus was very clearly in favour of having Java in the
resolution.




Let the focus of this PMC remain on Java, but, in the Apache spirit of
openness and collaboration, make way for other Apache Commons projects
in other languages.


Sure - but let's discuss that then rather than now. Hypotheticals will
just keep us spinning emails out ad infinitum.

Hen

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

Re: [VOTE] Commons moving to TLP

[Henri Yandell]

On 5/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


> However, here's a vote for Commons to officially request that it move
> to TLP.

+1 (non binding)

>
>http://wiki.apache.org/jakarta-commons/TLPResolution
>
> Please add your name if you're a Commons developer and haven't added
> your name yet.

I think you have already explained that yesterday, but I didn't understand ...
The list seems to be intended for PMCs, not for the hundreds of simple
committers like me ?


At this time it tends to be common for the new PMC to be formed of the
committers. It can depend, if someone is a new committer then it'll be
weird adding them to the PMC from the get go (least that seems to be
the general opinion).

I realized today that this is a subject that hasn't come up - where
will the committer list come from. Personally I'm in favour of using
the current jakarta committer list to define the list of people with
karma to a TLP Commons.

If you feel you're an active committer, I'd add your name.

Hen

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

Re: [VOTE] Commons moving to TLP

[Henri Yandell]

This came up on commons-dev when we were discussing the idea:

http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200704.mbox/[EMAIL 
PROTECTED]

My reply was:

http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200704.mbox/[EMAIL 
PROTECTED]

The hard part, as you pointed out, is that we all know that Jakarta
means open source Java. It still shows up on job specs every now and
then as its own technology. However from a community point of view,
Jakarta is still in many ways the same copy of the Apache it was many
years ago and that doesn't fit well into the structure at Apache.
Individual communities should be tlps and not be within tlps.

The extremely loose direction we're moving in is for the remaining
active sub-communities within Jakarta to move to TLP, any nearly
active parts to be discussing whether there is a possible new home
(for example, Regexp/ORO -> Commons has long been discussed) and for
inactive projects to be managed in some way (many of the Taglibs while
maybe still used have no future and no development activity for years;
ECS is also very maintenance and Slide seems to be slowly heading the
same way afaik). That still leaves people stuck in a grey area, and
we'll need to figure out what to do there. As we're a bunch of
subcommunities, we'll continue to do this in our slow galactic-council
way.


From what I've heard - discussion at ApacheCon in Amsterdam was that

we want to continue to do something with the Jakarta name, possibly an
open source Java at Apache portal/federation so the old 'Jakarta
equals open source Java at Apache' viewpoint can come back :) Of
course we might not convince the board on a commons.apache.org, there
was something there before and we do have Java in our tlp resolution
which may be considered bad.

Hope that helps,

Hen

On 5/8/07, Petar Tahchiev <[EMAIL PROTECTED]> wrote:

On 5/9/07, Jörg Schaible <[EMAIL PROTECTED]> wrote:
>
> +1
>
> Henri Yandell wrote on Tuesday, May 08, 2007 7:20 PM:
>
> > Sadly a bit too late to make the next board meeting I suspect.
> >
> > However, here's a vote for Commons to officially request that
> > it move to TLP.
> >
> > http://wiki.apache.org/jakarta-commons/TLPResolution
> >
> > Please add your name if you're a Commons developer and haven't added
> > your name yet.
> >
> > [ ] +1 I support the proposal
> > [ ] +0 I don't care
> > [ ] -1  I'm opposed to the proposal because...
> >
> > Voting will close in one week.
> >
> > 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]
>
> Hi,

I am not a Jakarta commiter, and also vote is not binding, but I want
to ask something. What are the benefits for commons of moving to a
TLP?
Also as I read the official commons intro, it states that commons is a
project "focused on all aspects of reusable Java components". So
as we all know Jakarta is a devision of Apache, that deals with the
Java open-source projects in the foundation, therefore, as I see it,
it would be better for commons to stay in the Jakarta.
So, maybe I am wrong, but I don't see any direct benefit for commons to move
to a TLP.
That's why, I have to vote:

-1

and ask you to prove me wrong.

Thank you all.

--
Regards, Petar!
Karlovo, Bulgaria.

Public PGP Key at:
http://keyserver.linux.it/pks/lookup?op=get&search=0x1A15B53B761500F9
Key Fingerprint: AA16 8004 AADD 9C76 EF5B  4210 1A15 B53B 7615 00F9



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

Re: [VOTE] Commons moving to TLP

[Henri Yandell]

On 5/9/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote:

> [X] -1  I'm opposed to the proposal because...

diffing the Wiki text against the template in SVN
(https://svn.apache.org/repos/private/committers/board/templates/subproject-tlp-resolution.txt)
shows significant differences. I'd like you to update the proposal
accordingly. As this proposal will not make the next board meeting
anyway, there is plenty of time to do so.

If this is done, then my vote will be +1.


Yeah, there was recent activity in changing that. Turbine/POI ones
might have the same problem.

I'll get it fixed (unless someone else hops in and does it).

Hen

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

[VOTE] Commons moving to TLP

[Henri Yandell]

Sadly a bit too late to make the next board meeting I suspect.

However, here's a vote for Commons to officially request that it move to TLP.

   http://wiki.apache.org/jakarta-commons/TLPResolution

Please add your name if you're a Commons developer and haven't added
your name yet.

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

Voting will close in one week.

Hen

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

Re: [VOTE] Move POI to TLP

[Henri Yandell]

+1.

On 5/4/07, Nick Burch <[EMAIL PROTECTED]> wrote:

Hi All

After lots of discussion within POI, and Jakarta in general, we think POI
is ready to graduate to its own TLP. Thanks to the magic of ApacheCon,
lots of people have been on-hand to help finalise the proposal for this,
which is attached below.

So, now is the time to vote on the proposal:
[ ] +1 I support the proposal
[ ] +0 I don't care
[ ] -1  I'm opposed to the proposal because...

Voting will close in one week.

Cheers
Nick



   WHEREAS, the Board of Directors deems it to be in the best
   interests of the Foundation and consistent with the
   Foundation's purpose to establish a Project Management
   Committee charged with the creation and maintenance of
   open-source software related to the continued implementation of
   the library for manipulating files in various business formats
   currently known as Apache POI for distribution at
   no charge to the public.

   NOW, THEREFORE, BE IT RESOLVED, that a Project Management
   Committee (PMC), to be known as the "Apache POI Project", be and
   hereby is established pursuant to Bylaws of the Foundation; and
   be it further

   RESOLVED, that the Apache POI Project be and hereby is
   responsible for the creation and maintenance of software related
   to creation and maintenance of open-source software and documentation
   related to the POI library based on software licensed to
   the Foundation; and be it further

   RESOLVED, that the office of "Vice President, POI" be and
   hereby is created, the person holding such office to serve at
   the direction of the Board of Directors as the chair of the
   Apache POI Project, and to have primary responsibility for
   management of the projects within the scope of responsibility of
   the Apache POI Project; and be it further

   RESOLVED, that the persons listed immediately below be and
   hereby are appointed to serve as the initial members of the
   POI PMC:

 * Nick Burch <[EMAIL PROTECTED]>
 * Amol S. Deshmukh <[EMAIL PROTECTED]>
 * Jason Height <[EMAIL PROTECTED]>
 * Marc Johnson <[EMAIL PROTECTED]>
 * Rainer Klute <[EMAIL PROTECTED]>
 * Yegor Kozlov <[EMAIL PROTECTED]>
 * Danny Muid <[EMAIL PROTECTED]>
 * Andrew C. Oliver <[EMAIL PROTECTED]>
 * Avik Sengupta <[EMAIL PROTECTED]>
 * Glen Stampoultzis <[EMAIL PROTECTED]>
 * Sean Sullivan <[EMAIL PROTECTED]>

   NOW, THEREFORE, BE IT FURTHER RESOLVED, that Nick Burch
   be appointed to the office of Vice President, POI, to serve
   in accordance with and subject to the direction of the Board of
   Directors and the Bylaws of the Foundation until death,
   resignation, retirement, removal or disqualification, or until
   a successor is appointed; and be it further

   RESOLVED, that all responsibility pertaining to the Apache
   POI sub-project and encumbered upon the Apache Jakarta
   PMC are hereafter discharged.

-
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] Move Turbine to TLP

[Henri Yandell]

A belated +1.

On 4/28/07, Scott Eade <[EMAIL PROTECTED]> wrote:

The Turbine project has been discussing a proposal to the board that the
Turbine projects leave the Jakarta umbrella and become their own top
level project.  We are now at the point in the process that calls for a
vote to take place.

The proposal is available at:
http://wiki.apache.org/jakarta-turbine/TLPTurbine

For the interested, most of the discussion took place in the following
thread:
http://www.nabble.com/-DISCUSS--TLP--tf3574436.html

Here are the vote options:
[ ] +1 I support the proposal
[ ] +0 I don't care
[ ] -1  I'm opposed to the proposal because...

Voting will close in one week.

Thanks,

Scott

-
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] Morph as Jakarta-sponsored podling WAS Morph proposal

[Henri Yandell]

On 4/9/07, Matt Benson <[EMAIL PROTECTED]> wrote:


--- Simon Kitching <[EMAIL PROTECTED]> wrote:

> I'm definitely interested. BeanUtils tries to do too
> many things in one
> lib, and besides it is really ugly internally. So
> something like Morph
> would be very useful to have.

To be honest, Morph currently does probably as much as
or more than BeanUtils.  However, its functionality
areas are fairly well compartmentalized so that a
Morph @ ASF could be easily "digested" into smaller
components over time.  This is what I actually hope to
see, FWIW...


Never did reply to this. Sorry.

I'm aiming to call a proper vote on commons-dev about TLP stuff in a
week or so (for the board meeting in a month) then I'm +1 for Morph to
wind its way through the Incubator into Commons after that.

Hen

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

FYI: Commons->TLP discussion on common-dev

[Henri Yandell]

So people know, I started up a discussion on moving Commons to TLP a
couple of days ago. It's looking very positive, so I'll probably go
ahead and kick off a vote in a day or so.

Hen

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

Re: [proposal] Morph as Jakarta-sponsored podling WAS Morph proposal

[Henri Yandell]

Sorry for the lack of reply.

I'm completely interested in mentoring (Roller just went TLP, and
OpenEJB should be going that way very soon, so I'm free on the
Incubator stuff right now).

I'll reply more later. Anyone else interested?

Hen

On 4/3/07, Matt Benson <[EMAIL PROTECTED]> wrote:

Just wanted to confirm the complete lack of interest
here.  Unless I hear differently, I'll assume that's
lazy [-0]s all around and let the matter drop.

Thanks,
Matt

--- Matt Benson <[EMAIL PROTECTED]> wrote:

> Morph's incubation proposal follows, sent here first
> in an effort to gain the sponsorship of Jakarta, and
> possibly to attract mentors as well.  :)  Thanks!
>
> Morph defines a comprehensive API for performing
> object-to-object conversions in
> Java.
>
> PROPOSAL
>
>
> BACKGROUND/RATIONALE
>
>   As information flows through an application, it
> undergoes multiple transformations.  While the most
> prevalent examples of this in the J2EE space are
> well-known (e.g. HTTP request parameters to
> domain/data transfer objects, DTOs to domain
> objects)
> the overall problem space is characterized by the
> lack
> of a simple, well-known, conveniently extensible
> solution.  At least one JSR (295) describes such a
> facility as a dependency.  Having identified the
> basic
> commonalities among the best known application
> operations requiring object conversion, Morph
> consolidates these into a single API which, along
> with
> various bundled implementation classes, seeks to
> achieve the oft-repeated software development goal
> of
> making "the simple things easy, and the hard things
> possible" with regard to its problem domain.
>
>
> CURRENT STATUS
>
> Meritocracy:
>   The Morph team is eager to invest more fully in
> the
> meritocracy approach taken by the ASF.  To date,
> however, Morph's development team has been
> accumulated
> by a sort of "meritocracy-on-spec" approach:  Matt
> Benson was originally given
> commit rights solely on the basis of his ideas; only
> later did his work vindicate that decision.  [If
> sponsored by Jakarta:  This is a similar approach
> to that taken in the Jakarta community:  a community
> member simply announces his desire to work on a
> component, then proceeds with the community's
> blessing.]
>
> Community:
>   It is somewhat difficult to gauge the size of
> Morph's community.  There have been modest but
> consistent downloads of the project since its
> initial
> prerelease:  these average 21/month over 28 months.
> The traffic on its user and developer lists is
> similarly light, but several bug fixes and
> enhancements have resulted from the input of Morph's
> users.  An additional possible benefit of
> Morph's joining the Apache community is that
> increased
> cooperation with and buy-in from other ASF projects
> may increase its user and/or developer communities.
>
> Core Developers:
>   Matt Sgarlata is Morph's founding architect and
> developer.  He has been a member of the Jakarta and
> Struts user communities for some years.  Matt Benson
> is a member of the Apache Ant PMC and a Jakarta
> committer, so is familiar with (and fond of) the
> consensus and transparency encouraged in ASF
> development.
>
> Alignment:
>   Morph currently contains interoperability code for
> commons-beanutils, commons-chain, and Velocity.
> Because it is Morph's secondary purpose to provide
> implementations of common conversions, code that
> facilitates Morph's use with well-known libraries in
> easily anticipated ways is considered in-scope.  As
> has already been implied, it is expected that
> citizenship at the ASF would facilitate cooperation
> with existing projects to mutal benefit.  Finally,
> precedent demonstrating the desirability of such a
> project at Apache exists in the form of Jakarta
> commons-convert (this component ultimately failed to
> achieve maturity).  Morph's original design
> specifications are actually the generic
> subset of those drafted on the commons-dev mailing
> list as a next-generation implementation of this
> project.
>
>
> KNOWN RISKS
>
> Orphaned Products:
>   The Morph developers are part of its user base.
> Object conversion may be relevant to any of various
> components of a basic Java application.  The risk of
> "itch cessation" is therefore minimized; Morph
> should
> continue to be an applicable technology at low risk
> for being abandoned by its developers.
>
> Inexperience with Open Source:
>   As previously indicated, one of the initial
> committers has some years of experience as a
> committer
> and PMC member at the ASF.  Additionally, Morph has
> always been open-source software, with its evolution
> being directly guided by user input and developer
> consensus in similar fashion to other Apache
> projects.
>
> Homogenous Developers:
>   On the plus side, the initial committers are
> united
> only by their common interest in Morph (and their
> coincidental first names and middle initials).
> However, both hail from the United States, and
>

Re: [VOTE] Release Regexp 1.5

[Henri Yandell]

On 3/20/07, Vadim Gritsenko <[EMAIL PROTECTED]> wrote:

Henri Yandell wrote:
> This 'how we release' conversation has been bouncing around the ASF
> for 4 months now, the above is my best grok on the summary. I've not
> seen anyone yet speaking in favour of a view that we should have a
> vote on the idea of releasing and then someone does it when they can.
> Please bring that up on members@ Vadim - good luck.

That is a tough crowd and I don't think I have enough skills to convince them on
anything. OTOH, you can. It's pity though that ASF is loosing its values.


Problem is that that's the crowd who need to be convinced. Otherwise
we're just sitting here spinning around and around.

It's less that it's losing its values and more that it's increasingly
pushing to have one set of values.


Apache begat itself. Then it begat Jakarta somehow. Things were good.
Then Apache looked at Jakarta and it was not pleased for things were
not the same. It argued with itself and declared that things would be
the same. All was good.



The next day Apache looked at itself and was shocked and amazed to
find that declaring all things to be equal had not made things equal.
In the Outer Rim there were projects and committers who had not heard
the declaration and were not doing things in the same way. Indeed they
had the temerity to do things the same way they'd always done things.
Apache was not happy.



Apache gets married, finds a little house in the suburbs and raises
little apachlets. But that's another story.


So not losing values - these are Jakarta values that we relinquished 5
years ago.

On the "OTOH"... I've not got the patience for such convincing atm :)

Hen

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

Re: [VOTE] Release Regexp 1.5

[Henri Yandell]

On 3/18/07, Henri Yandell <[EMAIL PROTECTED]> wrote:

On 3/14/07, Vadim Gritsenko <[EMAIL PROTECTED]> wrote:
> Henning Schmiedehausen wrote:

> > You actually have to roll and sign a tarball/zip ball on which the vote
> > happens. "Release-then-Vote" seems to be the only accepted way by the
> > board these days;
>
> Thankfully, neither events in velocity-private nor board feelings apply here.
> Either Jakarta PMC votes for it or receives an resolution, before that 
happens,
> existing procedures [1] stay.

There are (to my knowledge) three types of vote/release styles that
have been happening at the ASF.

1) A vote to do a release, with no sign of release files. This is how
this thread started and it's against ASF policy.

2) A vote on release-candidate files (or -dev in your case), and then
a release that is trusted to be a repeat of the process used. This is
currently a grey area policy-wise, and is where this release moved to
with the ~/vgritsenko/*-dev files.

3) Creating the actual files that are going to be released and voting
on them. There's pressure to go this way, but it's not the policy yet.

> > personally I do prefer "Vote-then-Release" myself but
> > that seems to be the way it is.

Release-then-Vote has some nice parts, the actual release is really
easy. That's nice if the release process has been painful as it means
I don't have to remember how to do the damn thing. Vote-then-Release
is nice in that you don't end up doing as many vote builds.

Other parts of the ASF seem to do a release where they make a build
and if it passes a vote it goes out, if it doesn't then they up the
bugfix number and do it again (I don't think anyone actually has a
build number, ie: 1.3.5.7). They also have an alpha/beta/GA thing that
the version number doesn't show. Very confusing as a user I think.

Mostly at this stage the mandate is that we have to be voting on
release files, not on "Hey, how about a release".


This has been a pointless thread. Most of the people on the thread are
Members, so if someone could kick it off on members@ then I think
you'll see a much more informed discussion going on.

This 'how we release' conversation has been bouncing around the ASF
for 4 months now, the above is my best grok on the summary. I've not
seen anyone yet speaking in favour of a view that we should have a
vote on the idea of releasing and then someone does it when they can.
Please bring that up on members@ Vadim - good luck.

The reason for members existing (imo) is to provide a backbone to an
otherwise disparate and completely unrelated huge set of communities.
That means showing a bit more empathy and a bit less round and round
arguments.

Course, I'm grumpy and I've got zero patience for reading mailing list
threads over 5 emails nowadays for some reason.

Hen

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

Re: [VOTE] Release Regexp 1.5

[Henri Yandell]

On 3/14/07, Vadim Gritsenko <[EMAIL PROTECTED]> wrote:

Henning Schmiedehausen wrote:



> You actually have to roll and sign a tarball/zip ball on which the vote
> happens. "Release-then-Vote" seems to be the only accepted way by the
> board these days;

Thankfully, neither events in velocity-private nor board feelings apply here.
Either Jakarta PMC votes for it or receives an resolution, before that happens,
existing procedures [1] stay.


There are (to my knowledge) three types of vote/release styles that
have been happening at the ASF.

1) A vote to do a release, with no sign of release files. This is how
this thread started and it's against ASF policy.

2) A vote on release-candidate files (or -dev in your case), and then
a release that is trusted to be a repeat of the process used. This is
currently a grey area policy-wise, and is where this release moved to
with the ~/vgritsenko/*-dev files.

3) Creating the actual files that are going to be released and voting
on them. There's pressure to go this way, but it's not the policy yet.


> personally I do prefer "Vote-then-Release" myself but
> that seems to be the way it is.


Release-then-Vote has some nice parts, the actual release is really
easy. That's nice if the release process has been painful as it means
I don't have to remember how to do the damn thing. Vote-then-Release
is nice in that you don't end up doing as many vote builds.

Other parts of the ASF seem to do a release where they make a build
and if it passes a vote it goes out, if it doesn't then they up the
bugfix number and do it again (I don't think anyone actually has a
build number, ie: 1.3.5.7). They also have an alpha/beta/GA thing that
the version number doesn't show. Very confusing as a user I think.

Mostly at this stage the mandate is that we have to be voting on
release files, not on "Hey, how about a release".

Hen

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

Re: List moderator cleanup..

[Henri Yandell]

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.

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: News feed,

[Henri Yandell]

Howard knocked it together.

XML file that generates HTML and RSS.

The news.xml in the jakarta/site/ in svn.

Hen

On 2/7/07, Danny Angus <[EMAIL PROTECTED]> wrote:

I see jakarta has a news feed, I'd like to nick the idea for James.
How did you do that?

d.

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




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

Re: Howto revive inactive projects ?

[Henri Yandell]

On 2/14/07, Roland Weber <[EMAIL PROTECTED]> wrote:

 Here is my take on a revival procedure...



Pre-precondition.

We need to define what is inactive and place it in such a state.
Dormant seems a favourite word.
In the recent board report for the Commons components, we've gone with
"Inactive" to mean that there is no coding and no one is watching over
it; and "maintenance" to mean that there is no coding, but someone is
watching over it. Something that is "inactive" is up for being made
"dormant".

So we need to define Jakarta components in this way and challenge each
inactive component to explain why it is not suitable for dormancy. I
think we need to do this even if there is an active user community -
being told that Xxx is now being considered inactive might kick people
into being active.

So first - let's get the components defined in these ways and reflect
this on the website(s).

There's been a suggestion on [EMAIL PROTECTED] that dormant projects
should be moved into the Incubator.

The following becomes a process for reactivating:


Preconditions:
- A mentor with committer/admin access to both the software repository
  and the bug tracking system. One that is willing to invest significant
  time and not just give a useful tip once or twice a week.


+1.


- A CLA on file from the revival candidate. ("resurrector")


The mentor should guide them through a few patches to show they are
committed, then we can make them a committer. I don't think there's
any reason to do CLAs without also making them committers.

I'm not sure we need to define a 'resurrector'. Rather we should
define the project as being revived and explain that that means that
Person X is mentoring it and that N people are submitting patches to
get it moving along. Often when one person gets active on a component,
others start to show up. Having a resurrector limits the new
contributions.

We could have a wiki page that lists dormant components and people
could put their names down (emails?) as interested in reviving a
component.


Procedure:


Step 1 - announce to all that the dormant component is being revived.


- Create a "revival" fork of the code base in the software repository.


Probably a good idea. I'd have immediately said to tag a "prerevival"
tag and then go for it in trunk, but that is a pain when the move
fails and someone else tries to do the same later.


- The resurrector submits patches for the revival fork in the bug
  tracking system.


+1


- The mentor reviews patches for style only, not for functionality.


Why not functionality? To keep the time required for the mentor low?


- Patches are committed by the mentor to the revival fork.


+1


- The mentor is responsible for running tools with committers-only
  access, such as Clover. The mentor encourages the writing of test
  cases by the resurrector.


I think this is pretty unnecessary in the process. Clover's the only
example and I don't think it's as used now as it used to be.
Cobertura/Emma/JCoverage seem to have done enough to stop it becoming
predominant.

However - the mentor refuses to commit without a test patch would be
something I'd expect to see.


- All discussions take place on the regular mailing list(s) of the
  project, so that users are aware of the revival attempt.


+1, though a lot tends to take place in JIRA/Bugzilla. The mentor
should be encouraging the people contributing patches to prepare
release plans and communicate them to the mailing list.


- Adventurous users are encouraged to try out the revival branch.
  They'll probably have to compile themselves, or use a manually
  created snapshot as the nightlies would still be based on the
  main trunk rather than the revival branch.


We could be doing the revival branch in the nightlies too.


- If there is a significant number of fixes in the revival branch
  and code quality is considered good enough by the mentor (for
  example based on Clover test coverage results), a "Possible
  REvival alpha release" (PRE-alpha) is created.
- Publication of the not-quite-release is done on a low profile,
  as it is not a full quality release of an Apache project. For
  example, due to the lack of a developer community, there won't
  be three binding votes as required for a real release.


-1. That's nothing more than saying "We think the nightly is pretty
good now" on a mailing list.

Do an actual alpha release. The vote should be held here if there's
not enough voting on the components list.


- Adventurous users are encouraged to try out the PRE-alpha.
- If the PRE-alpha exhibits major quality problems, continue with
  bug fixes and improved test coverage. Repeat PRE-alpha procedure.
  The decision about the quality is at the discretion of the mentor.
- Once a PRE-alpha release meets quality standards, the mentor
  calls for a Jakarta-wide vote to promote the resurrector to
  committer status.


Make them a committer based on their patches. The only problem with
this now is that we don't ten

Re: Nightly builds docu?

[Henri Yandell]

On 1/17/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote:

So how about biting the bullet and installing one of the well
established and obviously easier tools:


* Cruise Control (http://cruisecontrol.sourceforge.net/)


Just downloaded this the other day to sit and play with. When last I
looked at it I disregarded it because it insisted on a source only
distribution and its source wouldn't build on OS X.

They had a new release recently and a binary, so I'm aiming to give that a shot.


* anthill (https://www.anthillpro.com/html/products/anthillos/)


I've always leaned away from free versions that had commercial
superset versions (crippleware). They just changed to a more JIRA like
model.


* Luntbuild (http://luntbuild.javaforge.com/)


Not looked at this in a while (since it was much more recent), but
it's another crippleware. My gut instinct on such things is that while
that'd be fine for half a dozen subprojects within a project, we're
going to find ourselves wanting many of the 'enterprise' features if
we were to scope.


While I appreciate that we do have a ASL licensed CI product, the
arguments "it is too complicated to set up" and "it is better to have
none than having not-Continuum" don't work well with me.


Neither were my arguments. Actually my biggest +ve for Continuum is
that it is very easy to setup.

Reasons against Continuum are:

* Maven were going to run a Continuum on vmbuild and decided not to
due to the machine - so I'm not going to dive in trying to do the
same. There's discusion ongoing to get a machine with more cpu spare.

* I think it's easy to write a specific CI script and hard to write a
generic CI tool. Plus I'm not very bought off on the "gui so you can
do a build 'now!'" bits.

Phil's quick script, and Craig's before that, have been fine in
Commons - but we're going to start needing a visual representation one
of these days and that starts to send you into the CI product world.
We still build everything each day - which would be a hog if we kept
on adding things. However a condition of conditional on-svn-update
builds is that you have to start representing your state - it's more
than just "Last night".

Hen

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

Re: Nightly builds docu?

[Henri Yandell]

Gump's up and running. It was sounding like it was a bit dead, but
seems to have got active again with maven-2 support here or nearly
here. The biggest problem with Gump is that it's not a CI system -
it's a social experiment and it's aim is to tell people when trunks
are breaking for them and not to create nightly artifacts. That might
have changed though. They just started working with Harmony (that's
one of my wishlist bits for whatever build we use - build 1.4, 1.5,
1.6 and Harmony for each project - plus it should be testing the ant,
maven1 and maven2 builds).

vmbuild was intended to be a zone/machine for Continuum - but it
didn't have the cycles. The nightly spamassassin is on the same
machine and (allegedly) eats them all up. There's some talk of setting
a distributed Continuum up, but it involves a fair amount of people
working together so I wouldn't expect that any time soon.

Hen

On 1/17/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote:

As we have at least one "CI" tool inside the ASF: How about setting up
one of these for the nightlies?

Best regards
Henning



Martin van den Bemt schrieb:
> Gump doesn't build against the versions of the dependencies specified in the 
pom / project.xml, but
> builds against the latest of everything, which could mean other trouble if 
you are using those jars.
>
> Mvgr,
> Martin
>
> Andrew C. Oliver wrote:
>> Ummwhy not out of Gump?
>>
>> Phil Steitz wrote:
>>> Henri Yandell wrote:
>>>
>>>> On 1/16/07, Ortwin Glück <[EMAIL PROTECTED]> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Does anyone (Henry?) know what happened to
>>>>>   http://www.apache.org/dev/nightly-builds.html ?
>>>>>
>>>>> It's referenced from
>>>>>   http://www.apache.org/dev/
>>>>> at the very bottom of the page. I'm looking for information how to get
>>>>> nightly builds done for HttpComponents.
>>>>>
>>>> It probably never existed. When that page was created the links were
>>>> made for pages that didn't exist to encourage people to write them -
>>>> didn't work :)
>>>>
>>>> Nightly build wise... it's still an unorganized situation. In Commons
>>>> we have some hand written scripts that are used on a zone (vmbuild) to
>>>> build the code each night. Taglibs used to be built each night on
>>>> Glenn's machine (I suspect that's not true anymore).
>>>>
>>>> We could expand the script for Commons to work from the Jakarta
>>>> perspective and not the Commons one.
>>> +1 and would not be hard to do.  Makes sense to do this for all Jakarta
>>> components that want nightlies and as long as the builds are
>>> "reasonable" in execution time, this should not be a problem.  The
>>> current script supports Ant, Maven 1 and Maven 2.   The script code is
>>> in svn at jakarta/commons/proper/commons-nightly/.  The main script,
>>> commons_nigthly.sh gets svn upped on vmbuild by a crontab wrapper before
>>> executing each night, so if you just make changes to include a new build
>>> or build type into this script and config and check in the changes, the
>>> new component will be added.
>>> Phil
>>>
>>>
>>> -
>>> 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]
>

--
Henning P. Schmiedehausen  -- [EMAIL PROTECTED] | J2EE, Linux
91054 Buckenhof, Germany   -- +49 9131 506540  | Apache person
Open Source Consulting, Development, Design| Velocity - Turbine

  "Save the cheerleader. Save the world."

-
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: Nightly builds docu?

[Henri Yandell]

On 1/16/07, Ortwin Glück <[EMAIL PROTECTED]> wrote:

Hi,

Does anyone (Henry?) know what happened to
  http://www.apache.org/dev/nightly-builds.html ?

It's referenced from
  http://www.apache.org/dev/
at the very bottom of the page. I'm looking for information how to get
nightly builds done for HttpComponents.


It probably never existed. When that page was created the links were
made for pages that didn't exist to encourage people to write them -
didn't work :)

Nightly build wise... it's still an unorganized situation. In Commons
we have some hand written scripts that are used on a zone (vmbuild) to
build the code each night. Taglibs used to be built each night on
Glenn's machine (I suspect that's not true anymore).

We could expand the script for Commons to work from the Jakarta
perspective and not the Commons one. I often ponder if that should be
replaced with a Continuum instance (especially with Commons being just
about on Maven-2 now), but afaiu vmbuild is considered too
crap/overloaded to run lots of builds in Continuum.

Hen

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

Re: My svn account

[Henri Yandell]

Martin - maybe if you forward this to root@ and ask if there's
anything you can do to help etc, it'd be a good nudge?

Hen

On 1/10/07, Andrew C. Oliver <[EMAIL PROTECTED]> wrote:

IIRC, this is my 4th attempt to resolve this (I try like every 3-4
months).  I would like to commit something.  My SVN account is not
working.  per the instructions off the SVN page I emailed [EMAIL PROTECTED]  I 
got
no response.  I am still able to log in to people.apache.org.

Suggestions for resolution?  Account name: acoliver.  Any help would be
appreciated.  I will consider requests for bribes.

-andy

--
No PST Files Ever Again
Buni Meldware Communication Suite
Email, Calendaring, ease of configuration/administration
http://buni.org



-
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 Voting

[Henri Yandell]

On 12/20/06, David Fisher <[EMAIL PROTECTED]> wrote:

Hi Jakarta Board-

A suggestion after reading with interest the recent POI vs. Jakarta
smoke and flames threads.

I think that Jakarta needs a voting application that can include PMC
quorum requirements, direct email vote requests, committer approval,
etc.

Maybe it already exists?

Anyone want to +1 this ;-)


Was pondering on this a little while ago.

Problems it solves (and they're not very big, so I was mostly thinking
about it because I felt like writing something new rather than
maintaining code):

* Simplifies calling a vote.
* Adds a better audit trail.
* Can know about the binding votes and it can decide whether a vote is
successful or not.
* Enforces things - so having an end date to a vote for example.

Problems it causes:

* Might make us vote more often rather than just agree consensus has
been reached.

Problems it shouldn't solve:

* Security. We're not currently secure - I could send an email as
someone else's name to the list and vote for them. It's hard to get
secure and yet still encourage contributors to throw in their +1s or
-1s.

--

Thoughts on implementation.

It needs to use some svn files behind the scenes to know that someone
is in a PMC (and thus binding). That's easy enough - there's a file
that contains that, though the formatting sucks.

It needs to be listening to emails, and communicate with a mailing
list. It needs to offer archival view via a webapp, and a current
state view through a webapp. Calling a vote is interesting - ideally
we'd limit that to committers simply to stop from getting spammed,
however that means the webapp (presuming the webapp would be the one
that held the admin system) would need to know about auth.

As we get more and more into auth, it becomes tempting to auth the
whole thing. Vote through the webapp and not an email, put it behind
SSL and the svnpasswd file (which is just htaccess from memory -
though getting access to that file might be tricky). Still allow a
guest vote.

Allowing a guest vote still raises spam as a possibility if we have
each vote be sent to the list. Possibly the solution is for the voting
tool to send voting summaries rather than votes themselves. Daily it
could send out the current state. People often comment with a vote
though - so that would be weak to not send it to the list.

Another option is to tie into the list management - let emails who are
subscribed vote. Painful dealing with ezmlm I suspect.

Another would be to just monitor the mailing list. Create a bot that
listens to emails and a script that sends out emails in a particular
format. Might work, but parsing replies would probably suck. That
could be completely webapp-less; more like an IRC bot for an email
list.

The only existing vote stuff at the ASF is for member/board voting
each year, but that's ssh/email and defined to be secure and private.
Not much use for us.

Think that's about where my thinking got...

Hen

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

Re: POI TLP -- constructively

[Henri Yandell]

On 12/18/06, Andrew C. Oliver <[EMAIL PROTECTED]> wrote:

Sleep Martinsleep.  All will be answered, resolved...but not today.
Right now I'm going to help my 2 year old draw dinosaurs with his
Hanukkah present (he is obsessed with dinosaurs).


My 2 year old is obsessed with trains. We let the family know this and
his hoard of 16 trains is going to double this christmas. I'm looking
forward to seeing his reaction as he sits and opens presents on
Saturday (yeah, I'm declaring Christmas on the 23rd because I want 3
days of playing with toys and not 1 day followed by 4 days of work :)
).

+1 to this thread (the Jakarta parts - not the let's all talk about
our kids, but if anyone wants to I'm as talkative as any other father
:) ).

Hen

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

Re: [VOTE] Remove POI svn restrictions.

[Henri Yandell]

On 12/17/06, Roland Weber <[EMAIL PROTECTED]> wrote:

Hello Avik,

> I'd have been happy seeing POI move to a TLP. However, some of the
> comments in this thread seem to preclude that possibility either.  I
> think his leaves the community between a rock and a hard place ... I
> dont want us to be subsumed as a commons project

I don't think that the level at which POI resides will make any
difference. I admit that at the beginning of this thread and
after Andy's first responses I also thought "hey, let's get them
promoted to TLP and we're finally rid of these discussions in
Jakarta". I've since had time to reconsider and realize that
this is not a solution. And actually I don't think that it is
even an option. POI is not running the Apache way. Promoting
it to TLP or "hiding" it in commons will not change anything.
If it were a TLP, you'd be having basically the same discussions
directly with the board. Do you think they'll look more kindly
on failure to follow the established Apache procedures? If we
made a proposal to promote POI now, I would expect the board
to reject it and tell us "make POI work in Jakarta before you
promote it to TLP".


I can't speak for the others - but that's what I was saying in the
email I was writing at the same time as you :)


A release can go wrong all right. That this wasn't detected by
the POI community itself is reason for worry. But the kind of
things that went wrong, like files being in the wrong place or
missing is even more reason for worry. The copyright statements
on the POI web site indicate that the project has been around
since 2002. Does that mean that in 4 years nobody cared to write
a build process that generates release jars conforming to
Apache standards?


I bet a lot of Jakarta does not conform - it's only when a release
happens that we think about bringing it up to date. This is not a
problem of the POI community but a problem of the Jakarta community
structure and for the PMC. It's the PMC's responsibility to make sure
these releases are right and not the POI community.

A plus point of POI as a TLP is that then it becomes the POI
community's responsibility far more (as I imagine there would be far
more of 1:1 ratio of committers to PMC there).

Let's not go over the top here - the release itself isn't that bad and
it's got the important things right (license, notice). Having gone and
looked at them, I'm not overly worried about the two particular
releases themselves, just that it's clear that information is not
getting out to POI and that it urgently needs to somehow.

Hen

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

Re: [VOTE] Remove POI svn restrictions.

[Henri Yandell]

On 12/17/06, Martin van den Bemt <[EMAIL PROTECTED]> wrote:


Avik Sengupta wrote:



> I'd have been happy seeing POI move to a TLP. However, some of the
> comments in this thread seem to preclude that possibility either.  I
> think his leaves the community between a rock and a hard place ... I
> dont want us to be subsumed as a commons project

Subsuming is not something I see happening, we already have enough sub sub 
projects. The total
projects in Jakarta is currently at 109 (only sub projects and projects without 
sub projects are
counted).


My previous pro for POI as a TLP is that it would give the POI
community more independence and would allow Jakarta to move in the
direction of having an identity rather than being the "what's left". I
know I come across strongly as thinking that identity is commons-like,
but I'll welcome any workable solution. The other option I could think
of is for Jakarta to be a Java federation (as per XML), but I don't
get the feeling that the federation ideas have had much success. I'd
love to hear other ideas.

[Short aside: Federation idea is for Jakarta to be a place where Java
projects come together - basically the old Jakarta with each
subproject being a TLP and yet still part of the same community. I
think it's 4 years too late to try that :( ]

My current con for POI as a TLP is that I think we shouldn't be going
"the release was wrong, send them TLP"; we should be ensuring that
things are good (source headers, releases, voting, all that
junk^Wjazz) first as that's the Jakarta PMC's responsibility. A
previous con I had was that it seemed to be going inactive, but
activity seems to be happily up.


So.. I think we need to:

1) Get the fixed POI release out. Fixed source headers, vote on the files etc.

2) Sort out the legal statement so that it's more official and
organized (copying Harmony seems good). While everything I'm hearing
when I ask legal-internal, legal vp, secretary etc (and same for
Martin afaik) says we don't _have_ to do anything; I can see the
points of the arguments for playing it safe. Effectively it's Jakarta
PMC policy rather than legal requirement so we need to make it so.
Apologies again to Andy for suggesting the legal statement was a
policy he initiated rather than ancient and lost Jakarta PMC policy.

3) Work on a TLP proposal.

-

On subproject subsuming. My basic premise is that a Jakarta subproject
can only be healthy within Jakarta currently if it is also viable as a
TLP (where healthy => fits into the current ASF structure). An
umbrella without large internal overlap is too weak unless we create
our own internal sub-PMC system and reporting structure and that's one
of the things that lead to splitting Jakarta up in the first place (as
far as I recall).

I'd personally much rather see POI as an active TLP than being
squashed into a flattened umbrella, but I definitely don't want to see
it being stuck in the old subproject structure.

Hen

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

Re: [VOTE] Remove POI svn restrictions.

[Henri Yandell]

On 12/15/06, Henri Yandell <[EMAIL PROTECTED]> wrote:

On 12/15/06, Nick Burch <[EMAIL PROTECTED]> wrote:
> On Fri, 15 Dec 2006, Martin van den Bemt wrote:
> > Apache legal doesn't know anything about this..
>
> Back when I joined POI, I was told the apache legal team had suggested the
> requirement.
>
> Perhaps one of the older POI committers can supply the original details?

My understanding is that the advice is from Andy's personal lawyer
many moons ago, maybe before POI joined the ASF.


I've sat and re-read all email I've ever received from Andy and I
can't find anything to this effect - so  it's no longer my
understanding.  Apologies for misleading everyone.

Hen


From an ASF point of view if someone breaks an NDA on our list or in a
commit, then it's their head and not ours. We would respond as quickly
as possible once we're aware of the issue by removing reference to
that issue (and unless we think it was an honest mistake also yanking
the commit rights of the person who broke it). I'm not sure if we'd
legally have to do that or not - I don't know how NDAs fit into IP
(copyright/trademarks), or if its just a personal agreement between
two parties and the NDA breaker is just breaking that contract. I am
not a lawyer etc etc, but the above is my understanding and would hold
for any of our mailing lists.

Public statements seem like an odd thing. There's no official archive
of them at the ASF (and they're not made to the ASF), so I doubt they
hold any weight or value to the ASF.

Hen



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

Re: [VOTE] Remove POI svn restrictions.

[Henri Yandell]

On 12/15/06, Andrew C. Oliver <[EMAIL PROTECTED]> wrote:

Hey I have an idea!  If it doesn't pass this time we can call another
vote right before the next holiday and hope that none of the POI PMC
members are around...  Then 3 months later do it again.


Reasoning being that Martin has done the same thing I did - asked
legal vp and secretary if they know anything about the need for POI to
be legally special and they don't.

The Harmony case is very cool to see - I suggest we copy what they're
doing (questionnaire that is then stored in the private pmc
directory).


-1 (because my votes don't seem to be counted and Henri will make up
backstory for me)


Your vote definitely counts - which one did I ignore?

My apologies if I've screwed the backstory up - I'd very much like to
know which parts.

Hen

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

Re: [VOTE] Remove POI svn restrictions.

[Henri Yandell]

On 12/15/06, Andrew C. Oliver <[EMAIL PROTECTED]> wrote:

-1.

You are of course misrepresenting the issue but okay.  It is also
because of the legal issues.  Go read the archive and provide a good
faith assertion rather than making an assumption.  If YOU want to work
on POI please submit some patches and following that should you wish to
be a committer then respond that you are not now and have never been
bound by a microsoft NDA regarding the file formats.

what is your interest here?  Do you have nothing better to do?


It should be pretty obvious what Martin's interest is - making sure
Jakarta is running correctly.

Your request that a committer state that they have/are not bound by a
microsoft NDA is ignorable as you're just speaking for yourself
personally and not for the ASF or Jakarta. It's meaningless and a sign
that things are not correct in POI.

Hen

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

Re: [VOTE] Remove POI svn restrictions.

[Henri Yandell]

On 12/15/06, Henri Yandell <[EMAIL PROTECTED]> wrote:

On 12/15/06, Nick Burch <[EMAIL PROTECTED]> wrote:
> On Fri, 15 Dec 2006, Martin van den Bemt wrote:
> > Apache legal doesn't know anything about this..
>
> Back when I joined POI, I was told the apache legal team had suggested the
> requirement.
>
> Perhaps one of the older POI committers can supply the original details?

My understanding is that the advice is from Andy's personal lawyer
many moons ago, maybe before POI joined the ASF.

From an ASF point of view if someone breaks an NDA on our list or in a
commit, then it's their head and not ours. We would respond as quickly
as possible once we're aware of the issue by removing reference to
that issue (and unless we think it was an honest mistake also yanking
the commit rights of the person who broke it). I'm not sure if we'd
legally have to do that or not - I don't know how NDAs fit into IP
(copyright/trademarks), or if its just a personal agreement between
two parties and the NDA breaker is just breaking that contract. I am
not a lawyer etc etc, but the above is my understanding and would hold
for any of our mailing lists.

Public statements seem like an odd thing. There's no official archive
of them at the ASF (and they're not made to the ASF), so I doubt they
hold any weight or value to the ASF.


Additionally - Harmony setup some extra process to help with making
sure everyone involved knew that the ASF didn't want any trade secrets
to be exposed - so there may be something that POI can learn from them
[Geir?].

Hen

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

Re: [VOTE] Remove POI svn restrictions.

[Henri Yandell]

On 12/15/06, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote:

Hm,

does it pose a real legal threat or is it just a "felt threat" from
Andy?


As long as we're not soliciting trade secrets - tis good. I suspect
this is a case of Andy's lawyer back in the day either having a
different opinion or it being a different scenario/context.


I'm +0 for opening. I'm enthusiastic on pushing POI out of Jakarta to
remove this restriction. While I agree that POI fits Jakarta theme-wise,
this "access restriction" thing feels too much like a wart.

Push it to TLP, make Andy chief, wish them farewell. Problem solved. :-)


Nick's been doing lots of work over there :)

I'm +1 for opening, unless it's decided that POI does need to add
extra process to protect from trade secrets. Currently the view is
that it doesn't - however chatting with Harmony to find out how things
worked for them would be of value.

On TLP - the main worry is that POI lacks overlap with the rest of the
ASF - more like an Incubator project than a normal TLP [maybe that's
too harsh]. My thinking is that we (Jakarta PMC) need to bring them up
to speed and then decide whether things are fitting or not.

Apart from the legal issue and the insularity - I'm +1 for POI
becoming a healthy happy part of Jakarta.

Hen

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

Re: [VOTE] Remove POI svn restrictions.

[Henri Yandell]

On 12/15/06, Nick Burch <[EMAIL PROTECTED]> wrote:

On Fri, 15 Dec 2006, Martin van den Bemt wrote:
> Apache legal doesn't know anything about this..

Back when I joined POI, I was told the apache legal team had suggested the
requirement.

Perhaps one of the older POI committers can supply the original details?


My understanding is that the advice is from Andy's personal lawyer
many moons ago, maybe before POI joined the ASF.


From an ASF point of view if someone breaks an NDA on our list or in a

commit, then it's their head and not ours. We would respond as quickly
as possible once we're aware of the issue by removing reference to
that issue (and unless we think it was an honest mistake also yanking
the commit rights of the person who broke it). I'm not sure if we'd
legally have to do that or not - I don't know how NDAs fit into IP
(copyright/trademarks), or if its just a personal agreement between
two parties and the NDA breaker is just breaking that contract. I am
not a lawyer etc etc, but the above is my understanding and would hold
for any of our mailing lists.

Public statements seem like an odd thing. There's no official archive
of them at the ASF (and they're not made to the ASF), so I doubt they
hold any weight or value to the ASF.

Hen

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