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

2011-12-04 Thread 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 bay...@apache.org 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

2011-11-11 Thread 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 seb...@gmail.com wrote:
 At present, BSF, BCEL and JCS downloads still use /dist/jakarta/proj.

 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/proj to
 /dist/commons/proj
 - add redirect for /dist/jakarta/proj to
 http://ww.apache.org/dist/commons/proj
 (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 proj download page to use /dist/commons/proj
 - delete /dist/jakarta/proj

 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



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

2011-11-10 Thread 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: [VOTE] Move Jakarta to the Attic; close down Jakarta PMC

2011-11-10 Thread 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 p...@steitz.com 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 bay...@apache.org 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



Re: Top Level Jakarta Website

2011-11-08 Thread 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 geigle...@peacetech.comwrote:

 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

2011-10-28 Thread 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 rahul.akol...@gmail.com 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

2011-09-21 Thread Henri Yandell
On Thu, Sep 22, 2011 at 1:30 AM, Rahul Akolkar rahul.akol...@gmail.com wrote:
 On Tue, Sep 20, 2011 at 3:15 AM, Henri Yandell
 bay...@generationjava.com 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.

 snip/

 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

2011-09-21 Thread Henri Yandell
On Thu, Sep 22, 2011 at 2:31 AM, sebb seb...@gmail.com wrote:
 On 22 September 2011 01:15, Rahul Akolkar rahul.akol...@gmail.com wrote:
 On Wed, Sep 21, 2011 at 7:33 PM, Henri Yandell
 bay...@generationjava.com wrote:
 On Thu, Sep 22, 2011 at 1:30 AM, Rahul Akolkar rahul.akol...@gmail.com 
 wrote:
 On Tue, Sep 20, 2011 at 3:15 AM, Henri Yandell
 bay...@generationjava.com 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.

 snip/

 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

2011-09-20 Thread 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 rahul.akol...@gmail.com 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

2011-09-11 Thread Henri Yandell
On Tue, Aug 30, 2011 at 4:36 AM, Rony G. Flatscher
rony.flatsc...@wu-wien.ac.at 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



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

2011-08-06 Thread Henri Yandell
On Mon, Jul 25, 2011 at 1:14 AM, Rony G. Flatscher
rony.flatsc...@wu-wien.ac.at wrote:

 On 24.07.2011 19:08, Henri Yandell wrote:
 On Sun, Jul 24, 2011 at 5:08 AM, Rony G. Flatscher
 rony.flatsc...@wu-wien.ac.at 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



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

2011-08-06 Thread Henri Yandell
On Sat, Aug 6, 2011 at 1:58 PM, Rony G. Flatscher
rony.flatsc...@wu-wien.ac.at wrote:


 On 06.08.2011 18:41, sebb wrote:
 On 6 August 2011 08:40, Henri Yandell bay...@generationjava.com wrote:

 On Mon, Jul 25, 2011 at 1:14 AM, Rony G. Flatscher
 rony.flatsc...@wu-wien.ac.at wrote:

 On 24.07.2011 19:08, Henri Yandell wrote:

 On Sun, Jul 24, 2011 at 5:08 AM, Rony G. Flatscher
 rony.flatsc...@wu-wien.ac.at 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



[RESULT] Cactus to the Attic

2011-08-05 Thread 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 bay...@apache.org 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



[VOTE] Move BSF to the Attic

2011-07-24 Thread 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: Ad BSF 2.x (Re: Activity of Jakarta subprojects

2011-07-24 Thread Henri Yandell
On Sun, Jul 24, 2011 at 5:08 AM, Rony G. Flatscher
rony.flatsc...@wu-wien.ac.at 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



Activity of Jakarta subprojects

2011-07-23 Thread 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



[VOTE] Cactus to the Attic

2011-07-23 Thread 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



Re: Activity of Jakarta subprojects

2011-07-23 Thread Henri Yandell
On Sat, Jul 23, 2011 at 12:39 PM, Oleg Kalnichevski ol...@apache.org 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



Re: Unable to download Snowball !

2011-04-19 Thread 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 neil.gh...@gmail.com wrote:
 Rahul,  What is this link about ?

 On Sun, Apr 17, 2011 at 6:42 PM, Rahul Akolkar rahul.akol...@gmail.comwrote:

 On Sun, Apr 17, 2011 at 8:49 AM, Neil Ghosh neil.gh...@gmail.com wrote:
  I have already downloaded lucene but where is the snowball analyzer in
 that
  ?
  The one in contrib directory is throwing runtime exception
 
 snip/

 http://lucene.apache.org/mail.html

 -Rahul


  On Sun, Apr 17, 2011 at 6:16 PM, Rahul Akolkar rahul.akol...@gmail.com
  wrote:
 
  On Sun, Apr 17, 2011 at 8:34 AM, Neil Ghosh neil.gh...@gmail.com
 wrote:
   Hi,
  
   Unable to download snowball analyzer
   I am trying to use snowball analyzer for my search engine but unable
 to
   download the library.
  
  snip/
 
  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

2011-03-22 Thread Henri Yandell
+1. Nom nom.

On Mon, Mar 21, 2011 at 5:00 PM, Rahul Akolkar rahul.akol...@gmail.com 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

2010-09-04 Thread Henri Yandell
On Wed, Aug 18, 2010 at 5:27 AM, Vadim Gritsenko va...@reverycodes.com 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: Move Jakarta Slide and Taglibs to the Attic?

2010-03-23 Thread Henri Yandell
+1 on both being moved into the Attic.

On Sun, Feb 28, 2010 at 6:31 PM, Rahul Akolkar rahul.akol...@gmail.com 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: New home for ECS, ORO and Regexp?

2010-03-23 Thread 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 rahul.akol...@gmail.com 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: [VOTE] Merge dev lists

2009-10-22 Thread 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=20090101to=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 rahul.akol...@gmail.com 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

2009-10-14 Thread Henri Yandell
On Tue, Oct 13, 2009 at 12:31 PM, Daniel F. Savarese d...@savarese.org 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



Re: [PROPOSAL] One development list

2009-10-14 Thread Henri Yandell
On Wed, Oct 14, 2009 at 3:40 PM, Henri Yandell bay...@apache.org wrote:
 On Tue, Oct 13, 2009 at 12:31 PM, Daniel F. Savarese d...@savarese.org 
 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



[ANNOUNCE] Taglibs moves to Tomcat

2009-10-10 Thread 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

2009-07-13 Thread Henri Yandell
Looks good.

On Sun, Jul 12, 2009 at 2:13 PM, Rahul Akolkarrahul.akol...@gmail.com 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

2009-05-26 Thread 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
itsupp...@martinjonkersmotors.com.au 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)

2009-01-22 Thread 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
paranoiabla.li...@gmail.com 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=getsearch=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

2009-01-21 Thread Henri Yandell
On Wed, Jan 21, 2009 at 3:41 AM, sebb seb...@gmail.com wrote:
 On 21/01/2009, Henri Yandell bay...@generationjava.com 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 1.8.1 of Cactus

2009-01-20 Thread 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
paranoiabla.li...@gmail.com 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 
 bay...@generationjava.comwrote:

 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
 paranoiabla.li...@gmail.com 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=getsearch=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=getsearch=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

2009-01-20 Thread 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
paranoiabla.li...@gmail.com 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 seb...@gmail.com wrote:

 On 20/01/2009, Petar Tahchiev paranoiabla.li...@gmail.com 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 seb...@gmail.com wrote:
   
On 20/01/2009, sebb seb...@gmail.com wrote:
 On 20/01/2009, Petar Tahchiev paranoiabla.li...@gmail.com 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:47)
   at junit.framework.Assert.assertTrue(Assert.java:20)
   at
   
 org.apache.cactus.integration.ant.AntTestCase.getBuildFile(AntTestCase.java:370)
   
This is a bit odd, as the directory appears to be there.
   
The assert() message ought to quote the directory name it is looking
 for.
[I'll update SVN trunk.]
   
Even odder, the problem does not occur when I reran the test.
I've tried several 

Re: [VOTE] Release 1.8.1 of Cactus

2009-01-19 Thread Henri Yandell
On Sun, Jan 18, 2009 at 1:37 PM, sebb seb...@gmail.com wrote:
 On 18/01/2009, Petar Tahchiev paranoiabla.li...@gmail.com 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] Release 1.8.1 of Cactus

2009-01-19 Thread 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
paranoiabla.li...@gmail.com 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/

 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=getsearch=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] JMeter 2.3.2RC3

2008-05-28 Thread 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

2008-01-31 Thread 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

2007-11-26 Thread 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

2007-11-19 Thread 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?

2007-10-06 Thread 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

2007-10-04 Thread 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: Add company to Third-Party Support page

2007-08-24 Thread 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]



Re: [discuss] Slide + HttpComponents = TLP

2007-08-24 Thread 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]



Killing the getinvolved page?

2007-08-15 Thread 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

2007-08-08 Thread 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)

2007-06-28 Thread 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

2007-06-24 Thread 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

2007-06-15 Thread 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: Commons TLP for Board Meeting ?

2007-06-14 Thread 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

2007-06-14 Thread 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: Jakarta site directory no longer contains .svn directories

2007-06-09 Thread 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: [VOTE] Release JCS 1.3

2007-05-30 Thread 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: jakarta-watchdog-4.0 source download

2007-05-30 Thread 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: [PROPOSAL] The future of Jakarta

2007-05-26 Thread 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

2007-05-25 Thread 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

2007-05-23 Thread 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

2007-05-22 Thread 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: Voting on releasing RC artificats as Final

2007-05-21 Thread 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

2007-05-21 Thread 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=logpathrev=482036

Hen

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



Re: [VOTE] Commons moving to TLP

2007-05-15 Thread 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: [PROPOSAL] The future of Jakarta

2007-05-15 Thread 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

2007-05-13 Thread 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

2007-05-10 Thread 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

2007-05-10 Thread 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.

snip


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

2007-05-09 Thread 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]



Re: [VOTE] Commons moving to TLP

2007-05-09 Thread 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=getsearch=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] Move POI to TLP

2007-05-04 Thread 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

2007-05-01 Thread 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

2007-04-19 Thread 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]



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

2007-04-04 Thread 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
 acknowledge this as a less-than-optimal level of
 diversity.  As Java Locale support is a key strength
 of Morph's transformation API, 

FYI: Commons-TLP discussion on common-dev

2007-04-04 Thread 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: [VOTE] Release Regexp 1.5

2007-03-20 Thread 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.

ancient history - very concise
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.
/ancient history

modern history
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.
/modern history

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

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

2007-03-19 Thread 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

2007-03-18 Thread 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..

2007-02-18 Thread 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: Howto revive inactive projects ?

2007-02-14 Thread 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 tend to pay enough 

Re: News feed,

2007-02-14 Thread 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: Nightly builds docu?

2007-01-18 Thread 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?

2007-01-17 Thread 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?

2007-01-16 Thread 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

2007-01-10 Thread 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

2006-12-21 Thread 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

2006-12-18 Thread 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.

2006-12-17 Thread 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.

2006-12-17 Thread 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.

2006-12-17 Thread 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.

2006-12-16 Thread 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.

2006-12-15 Thread 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]



Re: [VOTE] Remove POI svn restrictions.

2006-12-15 Thread 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.

2006-12-15 Thread 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.

2006-12-15 Thread 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: [site] proposed changes

2006-12-05 Thread Henri Yandell

On 12/4/06, Andrew C. Oliver [EMAIL PROTECTED] wrote:



 Why not just move all of the content of all of these pages to the
 wiki and
 change the links.
 Or better still have a section of wiki links in the right hand nav for
 them.

 Linking to pages in the wiki is bad, I think. When a page in a wiki
 has reached a point of wanting to be individually linked to, then I
 think that's a sign that it wants to be on the site.

I actually favor the idea of the whole site being a wiki.  I see little
value from hand coding the p tags and wanking around with the tools to
build it.Then the process for structuring the site is democratized
and the process for generating the consensus and structuring the site
will be closer to the metal.


A wiki as in our moinmoin setup - ie) classic anarchy/randomness; or a
wiki as in the cwiki confluence approach of site generation?

The former always seems to be painful when I've seen sites trying it
(from a user point of view at least); I think because it's still very
obviously a wiki and unpolished. The latter just seems to continue the
tool masturbation.

Maybe it's a case of not noticing when a site is using a wiki well. I
only notice the crap ones.


However, I've never been much of one for ceremony.


If we're on the I'd likes

I'd like the Jakarta site to be an xml file(s) with a bunch of xslt's.
Then I'd like each subproject/component to be product documentation
sites and not waste time with infrastructure (the jakarta site can
take care of all that) and I'd like a separate developer focused site
for each subproject/component that is refreshed automatically each
night.

Hen

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



Re: svn commit: r482344 - in /jakarta/site: docs/site/news/news-2006-q4.html docs/site/rss.xml news.xml

2006-12-05 Thread Henri Yandell

On 12/4/06, Rahul Akolkar [EMAIL PROTECTED] wrote:

On 12/4/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Author: bayard
 Date: Mon Dec  4 12:34:35 2006
 New Revision: 482344

 URL: http://svn.apache.org/viewvc?view=revrev=482344
 Log:
 Fixed up the Digester news item to inline the links rather than show them

snip/

The rationale behind showing the links is to make sure the feed
doesn't contain sentences like Download Digester from Digester
download page or some such equally hopeless text (since we lose
anchor tags). Don't care about this change per se, but thats the
reason it was done that way.


Gotya. Seems odd to lose the tags in a feed - they're meant to be html
snippets aren't they?

Hen

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



Re: [site] proposed changes

2006-12-04 Thread Henri Yandell

On 12/4/06, Danny Angus [EMAIL PROTECTED] wrote:

   2. Vendor support. This is getting increasingly threadbare - so
 raising the removal of this again. Content to be moved to the Wiki.

Why not just move all of the content of all of these pages to the wiki and
change the links.
Or better still have a section of wiki links in the right hand nav for
them.


Linking to pages in the wiki is bad, I think. When a page in a wiki
has reached a point of wanting to be individually linked to, then I
think that's a sign that it wants to be on the site.

These pages are all ones that have less value than the screen real
estate they take up, so definitely wouldn't want to keep the links.

Hen

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



[site] proposed changes

2006-12-03 Thread Henri Yandell

Back on a kick to clean up the site a bit more.

Removals:
 1. Remove the faqs page. It's getting low on content.
 2. Vendor support. This is getting increasingly threadbare - so
raising the removal of this again. Content to be moved to the Wiki.
 3. Removal of the JSPA Agreement link. It's very dated - however
there are a few historical sites linking to the page, so I'd not
remove the page yet.
 4. Acknowledgements.  I don't think we need to link to this.
 5. Translation sites. They can't keep up, time to go I think.
 6. Reference Library. Move this to the Wiki.
 7. 'Jakarta Webmaster' link from the contact us page.

+1s/-1s?

I'll wait 'til Friday to do whatever bits haven't been -1'd.

Hen

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



Re: commons-fileupload: Streaming mode

2006-11-04 Thread Henri Yandell

Done:

http://people.apache.org/repo/m1-snapshot-repository/commons-fileupload/jars/

Hen

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

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

Thanks,

-dain

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

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

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

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

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

 Hen

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

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

 Thanks for any help,

 -dain

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

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


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



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


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




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



Re: commons-fileupload: Streaming mode

2006-11-02 Thread Henri Yandell

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

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

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

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

Hen

On 10/29/06, Dain Sundstrom [EMAIL PROTECTED] wrote:

Has this code been Released yet?  The latest version I see is 1.1.1
and it doesn't seem to contain the FileItemIterator class.  Also
there don't seem to be any nightly snapshots available.

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

Thanks for any help,

-dain

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

 Wow.

 I can't wait to get my hands on this code.

 -dain

 On May 23, 2006, at 4:24 AM, Yoav Shapira wrote:

 Hola,
 +1 to you getting commons-fileupload karma and doing it yourself ;)

 Yoav

 On 5/23/06, Jochen Wiedmann [EMAIL PROTECTED] wrote:

 Hi,

 I have developed a modified version of the commons-fileupload, which
 allow a true streaming mode. In other words, there's no need for
 internal byte arrays or temporary disk files, you simply iterate
 through
 the items, get an InputStream on the items, read and process the
 InputStream (for example, run an XML parser on it) and that's it.
 The
 API remains unchanged and the modifications are strictly internally.

 For obvious reasons, the patches are non-trivial. So far I have
 splitted
 some changes into three patches, which I have posted in Jira issues.
 However, to get this patches in, one after the other, I see as my
 only
 chances, if an existing developer would express interest on the
 changes,
 review and guide my work and accept patches step by step. Is there
 anyone who volunteers doing the job? Perhaps, being an active ws
 committer, I might after some time as well receive Karma for
 commons-fileupload and finish the work, if I have earned some trust.

 Regards,

 Jochen


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




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

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



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


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




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



Re: jakarta.apache.org down?

2006-09-18 Thread Henri Yandell

The ISP appear to be having problems. Joe's on it and will be moving
to the backups (minotaur) if they don't have things fixed soon enough
(few hours).

Babelfish translation of the surfnet.nl info:

quasi: There is at present SURFnet network jamming as a result of
which a number of IP does not cram of outside SURFnet contactable is.
In any case the CIDR ranges 192.87.0.0/16 and 195.169.0.0/16 and
probably a number of other address block-systems has this problem.
Customers who IP addresses these use block-systems, because of this IP
at present no will have connectivity with the outside world 

Hen

On 9/18/06, Will Glass-Husain [EMAIL PROTECTED] wrote:

anyone have info on this?

Just wondering...

--
Forio Business Simulations

Will Glass-Husain
[EMAIL PROTECTED]
www.forio.com

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




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



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

2006-09-07 Thread Henri Yandell


Easy one first - the site definitely needs to say 'Apache Lucene' when it 
refers to Lucene the ASF project rather than Lucene Consulting or Lucene 
in Action. It should also say Apache HTTP Server or Apache Web Server 
(whatever the name is this month) rather than just Apache.


Harder one - I don't think we'd be okay with a company named Lucene 
Consulting. It's not as if it's descriptive of the company - it offers 
much more than just consulting on Lucene. Plus there's the old caveat that 
if we don't defend against this trademark infringement then we can't 
defend the next one.


However, I might not understand how things work - apache.com seems to 
happily exist.


Hen

On Wed, 6 Sep 2006, Martin Cooper wrote:


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

--
Martin Cooper


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


Hello,

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

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

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

Thanks,
Otis





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






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



Re: problems with JIRA

2006-09-07 Thread Henri Yandell


All 4 jiras were bounced around Thu,  7 Sep 2006 13:24:48 +0100 (BST); 
which I think was between your two emails (too early to think). So things 
might be fixed.


Hen

On Thu, 7 Sep 2006, Martin van den Bemt wrote:

I tried downloading all attachments and I have no problems.. Not saying this 
is a solution, but it could be : logout, relogin or remove jira cookies (just 
guessing here :)


Mvgr,
Martin


Will Glass-Husain wrote:

Anyone having problems with JIRA?  We have an issue (VELOCITY-453)
that half of the uploaded patches aren't accessible -- I reliably get
a Tomcat error when downloading. Very frustrating -- hopefully not too
discouraging for the new contributor.

I files a bug report with infrastructure but haven't heard back.
https://issues.apache.org/jira/browse/INFRA-933

WILL



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



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



  1   2   3   4   5   6   7   >