Is there a place for Eclipse plugins in Apache/Jakarta land?

[Vincent Massol]

Hi,

As part of Cactus, we have developed 2 Eclipse plugins. One of them is a
generic webapp plugin. We would like to extract this from the Cactus CVS
and let others benefit from it. 

However, I'm not sure where we should put this new project. 

Obviously one choice is to put it on SourceForge. Before doing this, I
wanted to let us decide first if we wanted to have a place in Apache
land where we would put such IDE plugins.

I think more and more the focus in java land is on usability. Be it
Tomcat, Avalon, Maven, etc, they will all have user-oriented front ends
to increase user productivity. One obvious place is within their own
repository. The real question is about shared plugins, like the webapp
one, which would benefit Tomcat users as well as Cactus ones.

Any idea?

Note: There's no hurry. Just testing the water... :-)

Thank you
-Vincent


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

RE: Mozilla mail filters

[Vincent Massol]

Pier, this is great! I would be happy to use newsgroup instead of emails
but I have 2 questions:

- how fresh are the messages in the newsgroup? It seems there is a few
hours delay between emails and newsgroup. That makes it difficult to use
newsgroup in replacement of emails, don't you think?

- what happens if I respond to the group? Does it also go the
mailing-list? If not, it means it must keep a subscription to the list
and then I'll get both the emails and the newsgroup items...

Thanks
-Vincent

> -Original Message-
> From: Pier Fumagalli [mailto:[EMAIL PROTECTED]]
> Sent: 15 November 2002 02:02
> To: [EMAIL PROTECTED]
> Subject: Re: Mozilla mail filters
> 
> On 15/11/02 0:50 "Stéphane MOR" <[EMAIL PROTECTED]> wrote:
> 
> > I think we could link to the file from the "Mailing Lists" section
> > of jakarta-site2.
> >
> > Any thoughts ?
> 
> Yes, start using news.betaversion.org (which will move to
news.apache.org
> once I'm over my friggin deadline), which works with mozilla and
filters
> messages for you (and expires them after one month so that you won't
clog
> up
> your local cache)...
> 
> Pier
> 
> 
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Is Cactus successful (was RE: [PROPOSAL] Tapestry joins Jakarta)

[Vincent Massol]

> -Original Message-
> From: Andrew C. Oliver [mailto:acoliver@;apache.org]
> Sent: 20 October 2002 19:03
> To: Vincent Massol
> Cc: 'Jakarta General List'
> Subject: RE: Is Cactus successful (was RE: [PROPOSAL] Tapestry joins
> Jakarta)
> 
> 
> > > I'm sorry to have insulted you.  I was only trying to help.  Based
on
> > > what you said, the observations I'd had from where I work and what
I'd
> > > observed.  If my observations were incorrect I apologize.
> >
> > Hey, your observations may be right and I appreciate your help! ;-)
> >
> > My strong reaction was probably due more to the tone of your email.
> > Saying to someone: "you have failed to provide ..." is not a very
nice
> > thing to say. Saying, "maybe you should try to work more on the
> > marketing side" is softer! :-). My turn to apologize if my reaction
was
> > too strong ;-)
> >
> 
> Ahh... word connotation.  I need a Jon page.. . I suck at finding the
> right way of saying things in email.  I'm told I'm abrasive in email,
> but not in person.  The funny thing is I say the same things... They
> just come off differently.  Maybe its my facial expressions or tone of
> voice...  (though my wife always misinterprets my facial expressions)
> 
> > Ok I want to be positive and try to see if there's anything I can do
to
> > improve the overall Cactus community. You say Cactus might be
missing
> > some marketing muscles. I would like to believe that. From the
> > information in my email do you still think there's more the Cactus
team
> > could do?
> >
> 
> Release more often, announce the releases.  While you may have had
> articles published, I've never actually seen one.  (I've seen them on
> Maven, Tomcat, Velocity, Struts to no end, Cocoon, Struts).  I found
the
> best approach to this is to spam magazines and complain that they
> haven't covered it.  Find and article on say JUnit and write the
author
> "but you haven't written on web app testing with cactus!"
> 
> Some people do the JUG tour.
> 

The discussion I had started was not about how to grow Cactus user base.
We are very happy with that (well beyond my expectations actually and
progressing steadily) but more on how to grow the committer's base. Of
course growing the number of people who knows about Cactus may have an
effect on the number of committers but I am not so sure about that
(that's not my observations so far).

My belief is that Cactus is too much viewed as a finished product:
- it works
- it has nice documentation
- it has a nice build process
- it has a quite responsive mailing list (a bit less lately as I have
slightly less time with Maven/other stuff and I'm trying to see if
others jump in when I don't answer 30 seconds after the question has
been posted ;-). It seems to be working! I have the feeling Cactus is
getting more ML participation ...).
- steady releases (9 versions/releases in 16 months, 1 stable releases/4
months).

It is indeed a finished product but there are still so many interesting
things to do to make it even way better ... ;-) (documented on the
todo/goal page).

> > You said the persons in your team were pondering about using Cactus.
> > That means they already know about it. So marketing is good! Maybe
> > documentation need to be improved?
> >
> 
> No not on my team.. . Just people I know at work ;-)
> 
> If I had a need for cactus at the moment the documentation doesn't
look
> too bad.

It isn't but needs reorganization to prevent misreadings like the one
you mention below ... :-)

> 
> > FYI, we have actually started working on the Cactus front-end (Maven
> > plugin, Eclipse plugin, standalone testing application, Ant tasks,
etc)
> > which should make it easier to use (this was one weak-point noted by
the
> > users - the entry barrier).
> >
> 
> Ahh.  i actually use Centipede and haven't figured out what eclipse
> wants from me (I want CVS + compilation...it gives me either or).

Let's not go there... Ok just a little then... Personally I don't want
compilation, which Eclipse gives me ;-) (I'm talking about dynamic
compilation). I want to know right away the result of a change I make to
a class across all my project, I want to know right away if I've broken
any coding convention as I type (using checkstyle for example), I want
to know the code impacted by my Aspects (AOP/AspectJ), if I make a
change deep in the directory structure, I want it to be surfaced so that
I know what is not committed, etc.

If you can resist, try not to answer this as it will lead to another OT
thread ;-) (you've started!).

> 
> The b

RE: Is Cactus successful (was RE: [PROPOSAL] Tapestry joins Jakarta)

[Vincent Massol]

> -Original Message-
> From: Andrew C. Oliver [mailto:acoliver@;apache.org]
> Sent: 20 October 2002 18:32
> To: 'Jakarta General List'
> Subject: Re: Is Cactus successful (was RE: [PROPOSAL] Tapestry joins
> Jakarta)
> 
> 
> > >
> > > Just FYI, you have failed to provide sufficient outside-of-jakarta
> > > marketing.
> >
> > Thanks for the information! You know what I like about you? It is
the
> > faith that you have in yourself and in the fact that you know it
all...
> >
> I'm sorry to have insulted you.  I was only trying to help.  Based on
> what you said, the observations I'd had from where I work and what I'd
> observed.  If my observations were incorrect I apologize.

Hey, your observations may be right and I appreciate your help! ;-)

My strong reaction was probably due more to the tone of your email.
Saying to someone: "you have failed to provide ..." is not a very nice
thing to say. Saying, "maybe you should try to work more on the
marketing side" is softer! :-). My turn to apologize if my reaction was
too strong ;-)

Ok I want to be positive and try to see if there's anything I can do to
improve the overall Cactus community. You say Cactus might be missing
some marketing muscles. I would like to believe that. From the
information in my email do you still think there's more the Cactus team
could do?

You said the persons in your team were pondering about using Cactus.
That means they already know about it. So marketing is good! Maybe
documentation need to be improved?

FYI, we have actually started working on the Cactus front-end (Maven
plugin, Eclipse plugin, standalone testing application, Ant tasks, etc)
which should make it easier to use (this was one weak-point noted by the
users - the entry barrier).

Thanks
-Vincent

> 
> -Andy
> 
> --
> http://www.superlinksoftware.com - software solutions for business
> http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
> Java
> http://krysalis.sourceforge.net/centipede - the best build/project
> structure
>   a guy/gal could have! - Make Ant simple on complex
> Projects!
> The avalanche has already started. It is too late for the pebbles to
> vote.
> -Ambassador Kosh
> 
> 
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Is Cactus successful (was RE: [PROPOSAL] Tapestry joins Jakarta)

[Vincent Massol]

> -Original Message-
> From: Henri Yandell [mailto:bayard@;generationjava.com]
> Sent: 20 October 2002 20:36
> To: Jakarta General List
> Cc: [EMAIL PROTECTED]
> Subject: RE: Is Cactus successful (was RE: [PROPOSAL] Tapestry joins
> Jakarta)
> 
> 
> 
> On Sun, 20 Oct 2002, Vincent Massol wrote:
> 
> >
> >
> > Ok I want to be positive and try to see if there's anything I can do
to
> > improve the overall Cactus community. You say Cactus might be
missing
> > some marketing muscles. I would like to believe that. From the
> > information in my email do you still think there's more the Cactus
team
> > could do?
> 
> Even ignoring my Jakarta-Apache involvement, I had become aware of
Cactus
> through articles [i think] and mention in the media. However, there's
no
> real meme [I think is the phrase] for Cactus. I know that Cactus is
Java,
> I know it tests web pages somehow (least it's hooked up in there) but
I
> don't have a good idea as to why I would choose it, how it differs
from
> httpunit etc. [A quick look at the website shows that my initial
> assumption was off a touch, it tests Java server-side components].

Hehe ... I think you may have nailed the exact problem! Even your last
sentence is not completely correct which proves your point (although it
is written on the web site!)... ;-) It's about *unit* testing java
server-side components (although at the moment it is more restricted to
unit testing J2EE components but that's not the only goal). And it's
about doing it in-container (inside the container).

Would "In-container Unit Testing" or "Integration Unit Testing" be a
nice meme?

I think the problem also comes from the fact that unit tests are still
relatively new. And what Cactus is doing is even newer. Thus there is
not yet any global knowledge of what IUT is about ... Cactus was built
to explore this road and is indeed a precursor ;-)

> 
> So for me personally, and I suspect other people who are aware of
Cactus,
> there's not a real understanding first off of where it fits in, the
level
> of effort to use etc.
> 

Yes, you are right. Everything is described on the web site (included
comparisons with other strategies), etc. BUT the problem is that you
have to read it first ... 

In that sense, Andrew was right. There is a need to do a lot of
evangelization on the concept of IUT so that it enters our global mind.

> [adding it to article list to write at some point, though I'm sure
there
> are many out there. ]

That would be nice ;-)

> 
> Probably not much use, but a report from a prospective customer can
> sometimes be of interest. I'd say Cactus is marketing the brand okay,
but
> not the meme. Not that I really understand brands or memes :)

I think you are completely right :-)

In addition the concept may need to be expanded a bit as it may be too
restrictive. Here are some ideas for the future:
- runtime unit testing (possibly using AOP)
- stress unit testing
(Thus more like tools like Introscope but at a much more agile level.)

It would still be In-Container Unit Testing (ICUT or IUT), though...
 
> 
> Hen
> 

-Vincent



--
To unsubscribe, e-mail:   <mailto:general-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:general-help@;jakarta.apache.org>

Is Cactus successful (was RE: [PROPOSAL] Tapestry joins Jakarta)

[Vincent Massol]

Hi Andrew,

> -Original Message-
> From: Andrew C. Oliver [mailto:acoliver@;apache.org]
> Sent: 20 October 2002 16:09
> To: 'Jakarta General List'
> Subject: RE: [PROPOSAL] Tapestry joins Jakarta
> 
> Just FYI, you have failed to provide sufficient outside-of-jakarta
> marketing.  

Thanks for the information! You know what I like about you? It is the
faith that you have in yourself and in the fact that you know it all...

> Where I work, lots of people talk about "maybe we should use
> cactus", and heck there are those who use all sorts of things from the
> Java Developers Journal that they have insufficient knowledge and
> experience to carry off.  (Yes you can write an object cache...  But
why
> would you, and why would you do it in your stateless session beans)...
> But cactus is a well kept secret.  Its one that gets whispered often.
> 
> From my limited experience, marketing (ugh!) is just as important as
> anything else to increase your community size.

Interesting... However, I do believe the opposite (and maybe I am
wrong)! I believe Cactus is victim of its success ... rather than it's
lack of ...

If you check the cactus stats
(http://jakarta.apache.org/cactus/stats/index.html), you will find it is
receiving quite a lot of attention (1500-2500 visits per day). It gets
between 500-1500 downloads per day which is quite honorable for such a
"niche" project (not only it is unit testing but only J2EE-related unit
testing).

Note: I don't like too much the stats from webalizer and I have started
using awstats
(http://jakarta.apache.org/~vmassol/awstats/awstats.jakarta.apache.org.h
tml) as an experiment. Much better stats I think (except the history).

Cactus is well advertised and easy to find (junit, google, a book with
Cactus in the title, several others having a chapter on Cactus, several
articles on the web, reviews in magazines, a book in progress I am
writing, etc).

I completely agree with you on marketing which is why I have worked on
that since day one of Cactus ... I may not be doing enough of it (who
does?) but it already takes all my night time work ... ;-)

That said, I only wish to learn and I would love to know some more
tricks from you!

Thanks
-Vincent

> 
> -Andy
> 
> On Sun, 2002-10-20 at 10:23, Vincent Massol wrote:
> >
> >
> > > -Original Message-
> > > From: Howard M. Lewis Ship [mailto:hlship@;attbi.com]
> > > Sent: 20 October 2002 14:36
> > > To: Jakarta General List
> > > Subject: Re: [PROPOSAL] Tapestry joins Jakarta
> > >
> > > I don't have a way to qualify this, but I'm very concerned about
> > growing
> > > the
> > > community, and therefore I'm very careful not to be arbitrary.
> > Everything
> > > is a discussion, and I prefer that person X be happy with the
ultimate
> > > decision, preferably agreeing with it.
> > >
> > > I've tried to before to spur more organization, but that didn't
really
> > get
> > > started.  The problem is, developers are too happy, I think.  The
> > > framework
> > > does mostly what they need, bugs fixes and improvements happen, so
> > there
> > > hasn't been a need to get involved.  A move to Jakarta will
*force* a
> > few
> > > people (and I know who they are) to step forward, since other
wise, by
> > the
> > > rules, nothing will actually happen.
> >
> > I'm interested to know more about this last part... I have moved
Cactus
> > from SF to Jakarta a bit more than a year ago and I've found that I
> > haven't been able to grow much the number of committers. I believe
there
> > are 2 possible reasons:
> >
> > 1/ Cactus (server-side unit testing - J2EE ATM) is too much of a
niche
> > and people think there's not much more to do in that domain (quite
> > wrongly I can assure you ... :-))
> >
> > 2/ Cactus is a victim of its success. From the beginning I have
tried to
> > work hard to provide everything: documentation, quick answers to ML,
> > quick fixes, be customer driven, etc. Thus, as you say, people do
not
> > participate because it works and the projects moves forward by
itself
> > (so it seems ;-)).
> >
> > So I'm not sure why you say that a move to jakarta would change
point 2/
> > (which seems to be Tapestry's case). I'm interested in knowing if
you
> > have a magic recipe that I could apply ... :-)
> >
> > Thanks
> > -Vincent
> >
> > PS: BTW, how do you unit test tapestry components? ;-)
> >
> > >
> > > - Original Message -
> > > From: "Peter Donald"

RE: [PROPOSAL] Tapestry joins Jakarta

[Vincent Massol]

> -Original Message-
> From: Howard M. Lewis Ship [mailto:hlship@;attbi.com]
> Sent: 20 October 2002 14:36
> To: Jakarta General List
> Subject: Re: [PROPOSAL] Tapestry joins Jakarta
> 
> I don't have a way to qualify this, but I'm very concerned about
growing
> the
> community, and therefore I'm very careful not to be arbitrary.
Everything
> is a discussion, and I prefer that person X be happy with the ultimate
> decision, preferably agreeing with it.
> 
> I've tried to before to spur more organization, but that didn't really
get
> started.  The problem is, developers are too happy, I think.  The
> framework
> does mostly what they need, bugs fixes and improvements happen, so
there
> hasn't been a need to get involved.  A move to Jakarta will *force* a
few
> people (and I know who they are) to step forward, since other wise, by
the
> rules, nothing will actually happen.

I'm interested to know more about this last part... I have moved Cactus
from SF to Jakarta a bit more than a year ago and I've found that I
haven't been able to grow much the number of committers. I believe there
are 2 possible reasons:

1/ Cactus (server-side unit testing - J2EE ATM) is too much of a niche
and people think there's not much more to do in that domain (quite
wrongly I can assure you ... :-))

2/ Cactus is a victim of its success. From the beginning I have tried to
work hard to provide everything: documentation, quick answers to ML,
quick fixes, be customer driven, etc. Thus, as you say, people do not
participate because it works and the projects moves forward by itself
(so it seems ;-)).

So I'm not sure why you say that a move to jakarta would change point 2/
(which seems to be Tapestry's case). I'm interested in knowing if you
have a magic recipe that I could apply ... :-)

Thanks
-Vincent  

PS: BTW, how do you unit test tapestry components? ;-)

> 
> - Original Message -
> From: "Peter Donald" <[EMAIL PROTECTED]>
> To: "Jakarta General List" <[EMAIL PROTECTED]>
> Sent: Saturday, October 19, 2002 9:04 PM
> Subject: Re: [PROPOSAL] Tapestry joins Jakarta
> 
> 
> On Sun, 20 Oct 2002 02:06, Howard M. Lewis Ship wrote:
> > "Benevolent dictatorship".  Probably should have expanded on this.
> Without
> > a formal comittee or voting system, I've reserved the right to
> ultimately
> > decide what goes into the framework and what doesn't.
> 
> Start changing now. I don't know how long it will be before you come
to
> Apache
> but there is no harm and considerable benefit in moving to this model
> IMHO.
> It would also enhance your chances of making it into Apache.
> 
> --
> Cheers,
> 
> Peter Donald
> --
>  Logic: The art of being wrong with confidence...
> --
> 
> 
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

> 
> 
> 
> 
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [PROPOSAL]apache xml stylebook output (HTMLPrinter and Xalan2Processor) encoding configurability

[Vincent Massol]

IAS,

That's great news! I'll add the link the Cactus web site. I'll also try
to commit or get your stylebook patch committed (I'm not a committer on
xml-stylebook ATM). Who can help here?

Thanks,
-Vincent

> -Original Message-
> From: IAS master [mailto:[EMAIL PROTECTED]]
> Sent: 13 October 2002 17:45
> To: [EMAIL PROTECTED]
> Subject: [PROPOSAL]apache xml stylebook output (HTMLPrinter and
> Xalan2Processor) encoding configurability
> 
> Hello, I'm Changshin Lee(usually called "IAS"), a translator of Apache
> Jakarta Cactus project documentation in Korean. (The site is
> http://jakarta.apache-korea.org/cactus/index.html , but I'm afraid you
> might not be able to see those Korean characters.)
> 
> During processes to build Cactus Documentation, I found that Apache
XML
> Stylebook didn't support localization, for example, EUC-KR(Korean)
> encoding. I tested on
> 
> windows XP
> xalan 2.4.0
> xerces 2.2.0
> ant 1.5.1
> stylebook 1.0 b3 (xalan-2)
> JDK 1.4.1
> 
> The reason was org.apache.stylebook.printers.HTMLPrinter has
> 
> final static String ENCODING = "UTF-8";
> 
> and it prevents a HTMLPrinter from generating HTML documents encoded
by
> other character sets except UTF-8.
> 
> Actually XSL has an attribute "encoding" in xsl:output tag, so an idea
> hit me that Xalan2Processor obtains the property from the attribute
and
> pass it over HTMLPrinter.
> 
> The attached source files are those I made some changes to for dynamic
> encoding configuration. I also attached the built package with b4
label.
> The stylebook-1.0-b4_xalan-2.jar works very fine, and now my Cactus
> translations are generated by the following settings, e.g. :
> 
> index.xml
> 
> 
> document2html.xsl
> 
> ...
> 
> ...
> 
> I hope stylebook would support flexible and dynamic localization for
> many people who cannot utilize UTF-8 and get used to read HTML
documents
> encoded by their own character sets. I believe this implementation
from
> XSL is basically very natural as well. Thank you in advance.
> 
> Best Wishes,
> IAS
> 
> Independent Java Technology Evangelist
> http://www.iasandcb.pe.kr
> 
> Jakarta Seoul Project Coodinator
> http://jakarta.apache-korea.org


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [Poll result] Committers, who are we?

[Vincent Massol]

> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]]
> Sent: 20 September 2002 18:47
> To: 'Jakarta General List'
> Subject: RE: [Poll result] Committers, who are we?
> 
> 
> 
> > -Original Message-
> > From: Vincent Massol [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, September 19, 2002 9:56 AM
> > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: [Poll result] Committers, who are we?
> >
> >
> > Hi,
> >
> > A week ago, I have sent an email to all Apache committers. I
> > was curious
> > to know who the other committers where, whether they shared the same
> > beliefs I have, etc.
> >
> > I have posted the questions I sent and the results here:
> >
> > http://jakarta.apache.org/~vmassol/whoarewepoll/docs/site/poll
> /poll.html
> >
> > I haven't done any analysis yet of the results. Do you think there
are
> > any useful analysis that can be made out of this?
> >
> > Does it make you react in any way?
> 
> My initial reaction is that, with responses from only around 1 in 7
> committers, we shouldn't be drawing any big conclusions from the data
> collected. ;-)

... then send yours ... ;-)

BTW, I've had a few more answers since I posted the results and I will
update them in the coming week. I agree that 60 results is not much but
I think they're enough to represent a trend a give some visibility.

I've found a very nice survey of open source (although not Jakarta),
dated June 2002, on http://www.infonomics.nl/FLOSS/report/ . Lots of
nice figures. Some of the results I checked seem to be corroborating the
ones from our survey, although our results are usually on the upper
bands. 

-Vincent


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

RE: [Poll result] Committers, who are we?

[Vincent Massol]

> -Original Message-
> From: Fernandez Martinez, Alejandro
> [mailto:[EMAIL PROTECTED]]
> Sent: 20 September 2002 09:19
> To: 'Jakarta General List'
> Subject: RE: [Poll result] Committers, who are we?
> 
> Hi Vincent,
> 
> I think you accidentally swapped results for B and C on your last
table.

Oops. Sorry. Yes you're right.

> According to my crappy Windows calculator, it should read
> 
> A (company)  - 14 people - 3.44 h/day each - 48.25 total hours a day
> B (personal) - 33 people - 1.73 h/day each - 57.09 total hours a day
> A (both) - 05 people - 3.62 h/day each - 18.10 total hours a day
  ^
  C

> 
> So people with a personal drive contribute more hours in total than
> company-sponsored ones, even if each one has less time to spare. Is
this
> right?

Yes, although I wouldn't say more because we don't have enough numbers
to conclude exactly. I would say "about the same".

-Vincent

> 
> Un saludo,
> 
> Alex.
> 
> > -Mensaje original-
> > De: Vincent Massol [mailto:[EMAIL PROTECTED]]
> > Enviado el: viernes 20 de septiembre de 2002 9:55
> > Para: 'Jakarta General List'
> > Asunto: RE: [Poll result] Committers, who are we?
> >
> >
> > Hi Ellis,
> >
> > I've just compiled the result to answer your question "Who drives
> > Jakarta in term of manpower?". I'll put them online soon.
> >
> > Here are the results (out of 52 answers):
> >
> > A- 14 persons are pushed by companies
> > B- 33 persons are individuals
> > C- 5 persons are both
> >
> > Average participation for A: 3.44
> > Average participation for B: 1.73
> > Average participation for C: 3.62
> >
> > But ...
> >
> > Total number of hours/day:
> >
> > For A: 48.25
> > For B: 14.5
> > For C: 57.15
> >
> > So the result seems to be: Jakarta is drive as much by
> > individuals than
> > by companies in term of hourly participation to projects.
> >
> > Cheers,
> > -Vincent
> >
> > > -Original Message-
> > > From: Ellis Teer [mailto:[EMAIL PROTECTED]]
> > > Sent: 20 September 2002 07:51
> > > To: Jakarta General List
> > > Subject: Re: [Poll result] Committers, who are we?
> > >
> > > Vincent,
> > >
> > > Interesting, thanks for posting that.
> > >
> > > Is it possible to compare the number of hours/day contributed by
day
> > > time vs night time people?
> > >
> > > I am curious how much truth there might be to the question, do
> > companies
> > > /groups drive jakarta or do individuals?  Or to what degree
> > either may
> > > be true.
> > >
> > > -Ellis
> > >
> > > Vincent Massol wrote:
> > > > Hi,
> > > >
> > > > A week ago, I have sent an email to all Apache committers. I was
> > curious
> > > > to know who the other committers where, whether they
> > shared the same
> > > > beliefs I have, etc.
> > > >
> > > > I have posted the questions I sent and the results here:
> > > >
> > > >
> > http://jakarta.apache.org/~vmassol/whoarewepoll/docs/site/poll
> > /poll.html
> > > >
> > > > I haven't done any analysis yet of the results. Do you think
there
> > are
> > > > any useful analysis that can be made out of this?
> > > >
> > > > Does it make you react in any way?
> > > >
> > > > ATM, I have posted this on my own jakarta web page. However, I
you
> > think
> > > > it is worthwhile, we could add it to the jakarta/xml/etc main
web
> > site,
> > > > so that others can get a feeling of what to expect and
> > what kind of
> > > > persons the existing committers are. For jakarta, we could put a
> > link to
> > > > that page on http://jakarta.apache.org/site/whoweare.html
> > > >
> > > > Comments?
> > > > Thanks
> > > >
> > > > -Vincent
> > > >
> > > > ___
> > > > Vincent Massol
> > > > Managing Director
> > > > OCTO Technology UK Ltd
> > > > http://www.octo.com
> > > > [EMAIL PROTECTED]
> > > > Tel: +44 208 996 9540
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:   <mailto:general-
> > > [EMAIL PROTECTED]>
> > > > For additional commands, e-mail: <mailto:general-
> > > [EMAIL PROTECTED]>
> > > >
> > > >
> > > >
> > >
> > > --
> > > Ellis Teer
> > > www.sitepen.com
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> >


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

RE: [Poll result] Committers, who are we?

[Vincent Massol]

Hi Ellis,

I've just compiled the result to answer your question "Who drives
Jakarta in term of manpower?". I'll put them online soon.

Here are the results (out of 52 answers):

A- 14 persons are pushed by companies
B- 33 persons are individuals
C- 5 persons are both

Average participation for A: 3.44
Average participation for B: 1.73
Average participation for C: 3.62

But ...

Total number of hours/day:

For A: 48.25
For B: 14.5 
For C: 57.15

So the result seems to be: Jakarta is drive as much by individuals than
by companies in term of hourly participation to projects.

Cheers,
-Vincent

> -Original Message-
> From: Ellis Teer [mailto:[EMAIL PROTECTED]]
> Sent: 20 September 2002 07:51
> To: Jakarta General List
> Subject: Re: [Poll result] Committers, who are we?
> 
> Vincent,
> 
> Interesting, thanks for posting that.
> 
> Is it possible to compare the number of hours/day contributed by day
> time vs night time people?
> 
> I am curious how much truth there might be to the question, do
companies
> /groups drive jakarta or do individuals?  Or to what degree either may
> be true.
> 
> -Ellis
> 
> Vincent Massol wrote:
> > Hi,
> >
> > A week ago, I have sent an email to all Apache committers. I was
curious
> > to know who the other committers where, whether they shared the same
> > beliefs I have, etc.
> >
> > I have posted the questions I sent and the results here:
> >
> >
http://jakarta.apache.org/~vmassol/whoarewepoll/docs/site/poll/poll.html
> >
> > I haven't done any analysis yet of the results. Do you think there
are
> > any useful analysis that can be made out of this?
> >
> > Does it make you react in any way?
> >
> > ATM, I have posted this on my own jakarta web page. However, I you
think
> > it is worthwhile, we could add it to the jakarta/xml/etc main web
site,
> > so that others can get a feeling of what to expect and what kind of
> > persons the existing committers are. For jakarta, we could put a
link to
> > that page on http://jakarta.apache.org/site/whoweare.html
> >
> > Comments?
> > Thanks
> >
> > -Vincent
> >
> > ___
> > Vincent Massol
> > Managing Director
> > OCTO Technology UK Ltd
> > http://www.octo.com
> > [EMAIL PROTECTED]
> > Tel: +44 208 996 9540
> >
> >
> > --
> > To unsubscribe, e-mail:   <mailto:general-
> [EMAIL PROTECTED]>
> > For additional commands, e-mail: <mailto:general-
> [EMAIL PROTECTED]>
> >
> >
> >
> 
> --
> Ellis Teer
> www.sitepen.com
> 
> 
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>



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

[Poll result] Committers, who are we?

[Vincent Massol]

Hi,

A week ago, I have sent an email to all Apache committers. I was curious
to know who the other committers where, whether they shared the same
beliefs I have, etc.

I have posted the questions I sent and the results here:

http://jakarta.apache.org/~vmassol/whoarewepoll/docs/site/poll/poll.html

I haven't done any analysis yet of the results. Do you think there are
any useful analysis that can be made out of this?

Does it make you react in any way?

ATM, I have posted this on my own jakarta web page. However, I you think
it is worthwhile, we could add it to the jakarta/xml/etc main web site,
so that others can get a feeling of what to expect and what kind of
persons the existing committers are. For jakarta, we could put a link to
that page on http://jakarta.apache.org/site/whoweare.html

Comments?
Thanks

-Vincent

___
Vincent Massol
Managing Director
OCTO Technology UK Ltd
http://www.octo.com
[EMAIL PROTECTED]
Tel: +44 208 996 9540


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

FW: Together ControlCenter for jakarta projects

[Vincent Massol]

What do you think ? Do you think it would be nice to have a free
TogetherCC license so that projects who wish can create UML diagrams as
part of their website docs for example ?

-Vincent

> -Original Message-
> From: Richard Pitt [mailto:[EMAIL PROTECTED]]
> Sent: 19 July 2002 10:47
> To: Vincent Massol (E-mail)
> Subject: Together ControlCenter for jakarta projects
> 
>  Hi Vincent,
> 
>  I am just persuing the Together ControlCenter licence issue for you.
>  I am proposing that TogetherSoft gives the Jakarta Project an
academic
>  licence, and that all the committers be considered as faculty
members.
> 
>  Do you think this would be useful for and/or wanted by jakarta sub-
> projects?
> 
>  Regards,
>  Richard
> 
>  Richard Pitt
>  Mentor
>  TogetherSoft UK
> 
>  direct  +44 14 8986 6029
>  mobile +44 77 7328 6784


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

RE: [VOTE] Switching development to C#

[Vincent Massol]

Good try ... We're on the 1st of april, right ? ;-)

-Vincent

> -Original Message-
> From: Marc [mailto:[EMAIL PROTECTED]]
> Sent: 01 April 2002 19:44
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: [VOTE] Switching development to C#
> 
> Having become convinced by Andy that C# and .NET are the wave of the
> future, I'm proposing that we switch poi development to C#.
> 
> To the Jakarta community at large: will this affect our status as a
> Jakarta project? I mean, I can see where a lot of projects are
> eventually going to follow this same path ...
> 
> Marc
> 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Managing project documentation (release vs CVS versions) ?

[Vincent Massol]

I should have thought about this ... stupid me ... Thanks.

-Vincent

> -Original Message-
> From: Peter Donald [mailto:[EMAIL PROTECTED]]
> Sent: 16 January 2002 23:38
> To: Jakarta General List
> Subject: Re: Managing project documentation (release vs CVS versions)
?
> 
> The "recomended" solution for this is to use a branch. ie When you
make a
> release you also branch at same instant. Then if you need to update
the
> current web docs you modify them in the branch, then update the
website
> (which is using last branch released). If you need to update the docs
for
> the
> current CVS then you do it in the main trunk/HEAD revision. When
needed
> you
> merge the branch back into the main trunk.
> 
> However I don't know of any projects that do this except for ant.
> 
> It may also require a bit more CVS savvy that normal but should be
> possible
> to do if that is what cactus/whatever needs.
> 
> On Thu, 17 Jan 2002 10:34, Vincent Massol wrote:
> > Hi,
> >
> > I have always been pondering how to best manage the following.
Should
> > there be 2 web sites per project : one for the latest release
> > (containing docs + javadoc corresponding to the latest release) and
one
> > for nightly builds (containing docs + javadocs corresponding to the
> > latest code) ?
> >
> > When I work on a new feature that I want to document, I cannot
document
> > it in the xdocs/ directory because next time I change something for
the
> > web site and I want to make that change visible, it will also
contain
> > the new feature documentation. However, that feature is only present
in
> > CVS (not released yet) and users will have trouble understanding why
> > this feature does not work with the code they downloaded. Of course,
I
> > could have a header that says "WARNING: Feature only available in
CVS"
> > but it is awkward. Another solution is to have 2 xdocs directory but
> > again this is awkward ...
> >
> > Any idea ? How are other projects doing this ?
> >
> > Thanks
> > -Vincent
> >
> > ___
> > Vincent Massol
> > OCTO Technology UK Ltd
> > www.octo.com
> > [EMAIL PROTECTED]
> > Tel: (020) 8996 9540
> 
> --
> Cheers,
> 
> Pete
> 
> *--*
> | "Nearly all men can stand adversity, but if you want |
> | to test a man's character, give him power."  |
> |   -Abraham Lincoln   |
> *--*
> 
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
> 




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

Managing project documentation (release vs CVS versions) ?

[Vincent Massol]

Hi,

I have always been pondering how to best manage the following. Should
there be 2 web sites per project : one for the latest release
(containing docs + javadoc corresponding to the latest release) and one
for nightly builds (containing docs + javadocs corresponding to the
latest code) ?

When I work on a new feature that I want to document, I cannot document
it in the xdocs/ directory because next time I change something for the
web site and I want to make that change visible, it will also contain
the new feature documentation. However, that feature is only present in
CVS (not released yet) and users will have trouble understanding why
this feature does not work with the code they downloaded. Of course, I
could have a header that says "WARNING: Feature only available in CVS"
but it is awkward. Another solution is to have 2 xdocs directory but
again this is awkward ...

Any idea ? How are other projects doing this ?

Thanks
-Vincent

_______
Vincent Massol
OCTO Technology UK Ltd
www.octo.com
[EMAIL PROTECTED]
Tel: (020) 8996 9540 




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

License change for new year ?

[Vincent Massol]

I have 2 questions :

1/ Now that we are in 2002, do we need to change the text in all our
license files to be : "Copyright (c) 1999-2002 The Apache Software
Foundation" instead of "Copyright (c) 1999-2001 The Apache Software
Foundation" ?

2/ Some license files only have "Copyright (c) 1999 The Apache Software
Foundation" and some others have a year range as in "Copyright (c)
1999-2001 The Apache Software Foundation". Should one be preferred over
the other ? Are they both valid ?

Thanks
-Vincent



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: proposal for the jakarta startpage

[Vincent Massol]

Good idea. Here is the blurb for Cactus : "A test framework for unit
testing server-side java code".

Thanks for volunteering Gerhard ;-)

-Vincent

> -Original Message-
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
> Sent: 03 January 2002 14:15
> To: Jakarta General List
> Subject: Re: proposal for the jakarta startpage
> 
> On 1/3/02 9:02 AM, "Gerhard Froehlich" <[EMAIL PROTECTED]>
> wrote:
> 
> > hi,
> > following idea for the jakarta startpage:
> > how about adding a short description of each jakarta subproject on
the
> > startpage. something like that:
> >
> > TEXT TEXT TEXT TEXT
> >
> > NAV   Lucene:
> > NAV   A java based text search enginge.
> > NAV   ORO:
> >   A set off...
> >
> > because now you have to click in every subproject to find out what
> > they are doing. with this proposal it would be much easier to find
> > the correct subproject
> >
> 
> Good idea.  We were going to do that at one point.
> 
> Maybe we'll ask each newsletter contributor to make up a *one*
sentence
> blurb and do it that way.
> 
> --
> Geir Magnusson Jr. [EMAIL PROTECTED]
> System and Software Consulting
> "Whoever would overthrow the liberty of a nation must begin by
subduing
> the
> freeness of speech." - Benjamin Franklin
> 
> 
> 
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

> 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Just the JARs

[Vincent Massol]

> -Original Message-
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
> Sent: 01 January 2002 23:19
> To: Jakarta General List
> Subject: Re: Just the JARs
> 
> On 1/1/02 6:04 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
> 
> > Geir Magnusson Jr. wrote:


[snip]

> > Many of the nightly builds for various subprojects are published
based
> on
> > what gump produces in the manner desired by the communities for
these
> > subprojects.  Many of these include in bundled form the jars
referenced
> by
> > the build.
> >
> 
> But a nightly build isn't a release, right?  Wasn't this discussion
> motivated by Ted looking into getting projects to offer release build
jars
> alone w/o the whole source/docs distro to make for convenient
downlaod?
> 

I would say it depends on the project and the meaning you give to the
word "release". For the Cactus project, a nightly build produces exactly
the same files as a "release" and can be used with a great deal of
confidence.  The only difference with a release is that a release has a
goal, i.e. we have voluntarily decided that when such and such features
are put in, then it would warrant a release.

I like to use GUMP for 2 purposes :
* Early detection of contentions with dependent projects,
* Automated builds/integration, leading to a daily "release" (in the
agile way). Users are encouraged to use the nightly builds and not wait
for releases.

It may be different for other projects though but I tend to like this
philosophy ... :-)

[snip]

-Vincent



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Just the JARs

[Vincent Massol]

> -Original Message-
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
> Sent: 01 January 2002 19:26
> To: Jakarta General List
> Subject: Re: Just the JARs
> 
> On 1/1/02 2:00 PM, "Vincent Massol" <[EMAIL PROTECTED]> wrote:
> 
> >
> >
> >> -Original Message-
> >> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> >> Sent: 01 January 2002 18:39
> >> To: Jakarta General List
> >> Subject: Re: Just the JARs
> >>
> >> I think Lucene is already doing something very similar. Except that
> > the
> >> JARs are just put in with the other builds. Perhaps we can just
> >> recommend that everyone follow suit.
> >>
> >> http://jakarta.apache.org/builds/jakarta-lucene/nightly/2002-01-01/
> >>
> >> http://jakarta.apache.org/builds/jakarta-lucene/release/v1.2-rc2/
> >>
> >
> > I'm not sure what you mean. I've had a look and the dependent jars
are
> > _not_ put with the gump build (or the release build). The only jar
there
> > is is the junit one but if you look at the GUMP definition of Lucene
> >
(http://jakarta.apache.org/builds/gump/latest/module_jakarta-lucene.html
> > ) you'll find that it depends on xerces, ant and javacc, which are
not
> > included.
> >
> >
> >> People could then just provide hyperlinks to the appropriate build
> >> directories (say in a build.html file next to the build.xml), and
let
> >> people choose what they want to download.
> >>
> >
> > I agree that it would be nice if the GUMP results were put somewhere
> > publicly accessible (they may be but I have no idea where). However,
the
> > second step is to automatically fetch the correct dependent jars
(and
> > possibly in a validated working state, proved by unit testing of
each
> > project).
> >
> 
> You don't want to use the results of Gump for JJAR.  Gump isn't
bulding
> releases - it's building CVS-tree-du-jour...  There is no reason to
> believe
> anything built by Gump works.
> 
> I hope I'm just confused on what you are advocating.
> 

For me, GUMP is doing much more than building the CVS-tree-du-jour,
whatever this means. It is building "releases" every day of all projects
and produces project outputs.

-Vincent

> 
> >> A front-end application that made all of our products more
accessible
> >> would also be a Good Thing, and something I would like to do some
> > time.
> >> But if were to publish some recommendations now, and lead by
example,
> > I
> >> think things could get much easier for us all without much effort.
> >>
> >
> > yep, but also an Ant task (like the one in JJAR) for project
developers.
> >
> >> I'm not suggesting we all run around and post JARs for the old
> > releases,
> >> but as new releases are issued, we might want to follow Lucene's
> > example
> >> (among others).
> >>
> >
> > I guess this is currently done for most projects, isn't it (I mean
that
> > GUMP nightly builds are put in http://jakarta.apache.org/builds/) ?
What
> > I have done in Cactus, but I'm not sure it is the right way is to
> > package an Ant distribution containing all the needed
tasks/dependent
> > jars to build the Cactus project / run Cactus tests in a project,
using
> > Ant. We also package the dependent jars in the release and nightly
> > builds.
> >
> > -Vincent
> >
> >> -Ted.
> >>
> >>
> >>
> >> Vincent Massol wrote:
> >>>
> >>> What would be nice would be to have a JJAR/CJAN project coupled
with
> >>> GUMP. This application would have both an Ant task (for
developers)
> > to
> >>> retrieve versions of dependent jars (latest or specified version
or
> >>> date) and a GUI/Applet in the download area so that end user could
> > use
> >>> it to download dependent jars. What is needed is :
> >>> 1/ a repository for the jars where GUMP would copy nightly builds
> > and
> >>> where releases would be put
> >>> 2/ dependency information (what Jason is building or what the
> > Commons
> >>> JJAR project has) so that dependent jars can be easily downloaded
> >>>
> >>> I think it might be a good idea for JJAR/CJAN to be a subproject
of
> >>> Alexandria.
> >>>
> >>> -Vincent
> >>>
> >>>> -Original Message-
> >>>> From: Jason van Zyl [mailto:[E

RE: Just the JARs

[Vincent Massol]

> -Original Message-
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
> Sent: 01 January 2002 19:24
> To: Jakarta General List
> Subject: Re: Just the JARs
> 
> On 1/1/02 12:57 PM, "Vincent Massol" <[EMAIL PROTECTED]> wrote:
> 
> > What would be nice would be to have a JJAR/CJAN project coupled with
> > GUMP. This application would have both an Ant task (for developers)
to
> > retrieve versions of dependent jars (latest or specified version or
> > date) and a GUI/Applet in the download area so that end user could
use
> > it to download dependent jars. What is needed is :
> > 1/ a repository for the jars where GUMP would copy nightly builds
and
> > where releases would be put
> > 2/ dependency information (what Jason is building or what the
Commons
> > JJAR project has) so that dependent jars can be easily downloaded
> >
> > I think it might be a good idea for JJAR/CJAN to be a subproject of
> > Alexandria.
> 
> I disagree.
> 

You have the right ... ;-) But why ?

My rationale was that the goal of GUMP as I understand it now, is to
ensure that all projects play well with each other in term of
compatibility. It seems natural to extend it so that it can also be
asked to retrieve all dependent jars for a given project.

-Vincent

P.S.: I said Alexandria instead of GUMP in my previous post but I'm not
cleat on the relations between these 2 in the future ... :-)

> --
> Geir Magnusson Jr.
[EMAIL PROTECTED]
> System and Software Consulting
> "They that can give up essential liberty to obtain a little temporary
> safety
> deserve neither liberty nor safety." - Benjamin Franklin
> 
> 
> 
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
> 




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

RE: Just the JARs

[Vincent Massol]

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: 01 January 2002 18:39
> To: Jakarta General List
> Subject: Re: Just the JARs
> 
> I think Lucene is already doing something very similar. Except that
the
> JARs are just put in with the other builds. Perhaps we can just
> recommend that everyone follow suit.
> 
> http://jakarta.apache.org/builds/jakarta-lucene/nightly/2002-01-01/
> 
> http://jakarta.apache.org/builds/jakarta-lucene/release/v1.2-rc2/
> 

I'm not sure what you mean. I've had a look and the dependent jars are
_not_ put with the gump build (or the release build). The only jar there
is is the junit one but if you look at the GUMP definition of Lucene
(http://jakarta.apache.org/builds/gump/latest/module_jakarta-lucene.html
) you'll find that it depends on xerces, ant and javacc, which are not
included.


> People could then just provide hyperlinks to the appropriate build
> directories (say in a build.html file next to the build.xml), and let
> people choose what they want to download.
> 

I agree that it would be nice if the GUMP results were put somewhere
publicly accessible (they may be but I have no idea where). However, the
second step is to automatically fetch the correct dependent jars (and
possibly in a validated working state, proved by unit testing of each
project).

> A front-end application that made all of our products more accessible
> would also be a Good Thing, and something I would like to do some
time.
> But if were to publish some recommendations now, and lead by example,
I
> think things could get much easier for us all without much effort.
> 

yep, but also an Ant task (like the one in JJAR) for project developers.

> I'm not suggesting we all run around and post JARs for the old
releases,
> but as new releases are issued, we might want to follow Lucene's
example
> (among others).
> 

I guess this is currently done for most projects, isn't it (I mean that
GUMP nightly builds are put in http://jakarta.apache.org/builds/) ? What
I have done in Cactus, but I'm not sure it is the right way is to
package an Ant distribution containing all the needed tasks/dependent
jars to build the Cactus project / run Cactus tests in a project, using
Ant. We also package the dependent jars in the release and nightly
builds.

-Vincent

> -Ted.
> 
> 
> 
> Vincent Massol wrote:
> >
> > What would be nice would be to have a JJAR/CJAN project coupled with
> > GUMP. This application would have both an Ant task (for developers)
to
> > retrieve versions of dependent jars (latest or specified version or
> > date) and a GUI/Applet in the download area so that end user could
use
> > it to download dependent jars. What is needed is :
> > 1/ a repository for the jars where GUMP would copy nightly builds
and
> > where releases would be put
> > 2/ dependency information (what Jason is building or what the
Commons
> > JJAR project has) so that dependent jars can be easily downloaded
> >
> > I think it might be a good idea for JJAR/CJAN to be a subproject of
> > Alexandria.
> >
> > -Vincent
> >
> > > -Original Message-
> > > From: Jason van Zyl [mailto:[EMAIL PROTECTED]]
> > > Sent: 01 January 2002 15:52
> > > To: Jakarta General List
> > > Subject: Re: Just the JARs
> > >
> > > On 1/1/02 10:39 AM, "Ted Husted" <[EMAIL PROTECTED]> wrote:
> > >
> > > > Does anyone have a page regarding how to make a Jakarta release?
I'd
> > > > like to put one together and post it with the other guideline
> > materials.
> > >
> > > I tried to make a dist target for helping with a release. The
target
> > makes
> > > source and binary distributions and can be found in the BCEL,
XmlRpc
> > and
> > > Fulcrum. I was going to add this target to the build file that
Berin
> > > offered
> > > the Alexandria project.
> > >
> > > With dependency information I've been adding to the gump
descriptors
> > it
> > > would be possible to combine a standard target for building
release
> > > bundles
> > > with that dependency information to produce whatever we felt was
the
> > > desired
> > > result for a release.
> > >
> > > Maybe we could take this over to the alexandria list?
> > >
> > > > I've noticed that a few releases now include the JARs as a
seperate
> > > > download. Personally, I think that's a good idea, since more and
> > more
> > > > products have inter-dependancies. Would we want to suggest that
as a
> > > > s

RE: Just the JARs

[Vincent Massol]

What would be nice would be to have a JJAR/CJAN project coupled with
GUMP. This application would have both an Ant task (for developers) to
retrieve versions of dependent jars (latest or specified version or
date) and a GUI/Applet in the download area so that end user could use
it to download dependent jars. What is needed is :
1/ a repository for the jars where GUMP would copy nightly builds and
where releases would be put
2/ dependency information (what Jason is building or what the Commons
JJAR project has) so that dependent jars can be easily downloaded

I think it might be a good idea for JJAR/CJAN to be a subproject of
Alexandria.

-Vincent

> -Original Message-
> From: Jason van Zyl [mailto:[EMAIL PROTECTED]]
> Sent: 01 January 2002 15:52
> To: Jakarta General List
> Subject: Re: Just the JARs
> 
> On 1/1/02 10:39 AM, "Ted Husted" <[EMAIL PROTECTED]> wrote:
> 
> > Does anyone have a page regarding how to make a Jakarta release? I'd
> > like to put one together and post it with the other guideline
materials.
> 
> I tried to make a dist target for helping with a release. The target
makes
> source and binary distributions and can be found in the BCEL, XmlRpc
and
> Fulcrum. I was going to add this target to the build file that Berin
> offered
> the Alexandria project.
> 
> With dependency information I've been adding to the gump descriptors
it
> would be possible to combine a standard target for building release
> bundles
> with that dependency information to produce whatever we felt was the
> desired
> result for a release.
> 
> Maybe we could take this over to the alexandria list?
> 
> > I've noticed that a few releases now include the JARs as a seperate
> > download. Personally, I think that's a good idea, since more and
more
> > products have inter-dependancies. Would we want to suggest that as a
> > standard practice?
> >
> > This could save a lot of effort and bandwidth, since now you often
have
> > to download a 3mb archive when all you want is a 150k JAR.
> >
> > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > -- Building Java web applications with Struts.
> > -- Tel +1 585 737-3463.
> > -- Web http://www.husted.com/struts/
> >
> > --
> > To unsubscribe, e-mail:    [EMAIL PROTECTED]>
> > For additional commands, e-mail:  [EMAIL PROTECTED]>
> 
> --
> 
> jvz.
> 
> Jason van Zyl
> 
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
> 
> 
> 
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

> 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Standardized jar manifest entries? (Re: How do you version jar files?)

[Vincent Massol]

You should also have a look at the jjar project in Jakarta Commons and also
the related discussion threads on jakarta-commons on the subject. There are
some common ideas :)

-Vincent

- Original Message -
From: "Danny Angus" <[EMAIL PROTECTED]>
To: "Jakarta General List" <[EMAIL PROTECTED]>
Cc: "'Ant Users List'" <[EMAIL PROTECTED]>
Sent: Friday, November 16, 2001 2:01 PM
Subject: RE: Standardized jar manifest entries? (Re: How do you version jar
files?)


> I like this, a lot, if I had a +1 here I'd use it..
> its simple
> its addresses a real need
> it would facilitate the production of tools to deal with the nightmare
that
> is .jars and the classpath
>
> Ant could check jars against dependencies, and build the jars from scratch
> only if need be.
> A new tool could be produced to manage the jar collections on a machine,
(an
> Ant subproject?) and export the list to the classpath, only one entry for
> each package-name, and that the highest version.
>
> Of course that suggests there should be a fourth entry like
>
> Package-stability: alpha | beta | release
>
> so you could a) see this info, and b) decide what version should be used
> based on stability.
>
> d.
>
>
> > -Original Message-
> > From: Jeff Turner [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, November 16, 2001 12:36 PM
>
>
> 
> > So how about defining a Jakarta-wide standard subset of jar manifest
> > entries?  Something very simple, eg:
> >
> > Package-name: xalan
> > Package-version: 2.2
> > Package-depends: xerces, 1.4.3
> >
> > Then write a standard Java tool that can query any conforming jar, and
> > print this info. The dependency information would allow the tool to
> > recursively trace down dependencies, and print a complete list.
> 
> > Does that sound workable? Don't be distracted by talk of taxonomies and
> > classloaders.. those are just applications. All I'm proposing right now
> > is 3 standardized manifest entries, and a tool to read them. That alone,
> > if adopted widely, would be of great benefit in a world of proliferating
> > unidentifiable jars.
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Integration

[Vincent Massol]

You're ready to preach the GUMP way ... ;-)

In other words : no project is allowed to store external jars in CVS. GUMP
runs everyday with latest versions of everything. Integration problems are
fixed when the arise instead of being pushed back to later. The emphasis
should be on the responsability of any given project to the outside (its
users), end users or other frameworks using them. When a project breaks
something, GUMP reports it.

-Vincent

- Original Message -
From: "Frans Thamura" <[EMAIL PROTECTED]>
To: "Jakarta General List" <[EMAIL PROTECTED]>
Sent: Friday, November 02, 2001 11:33 PM
Subject: Re: Integration


> I got this problem.
>
> cocoon 1.82 and jetspeed using different xalan..
>
> and what should we do?
>
> or there is a integration in jetspeed called CocoonPortlet
>
> and whatt happen if cocoon portlet got error, this is jetspeed problem or
> cocoon..
>
> because most of the cocoon user don't use jetspeed
>
> but several jetspeed user don;t use cocon also..
>
> like that..
> - Original Message -
> From: "Peter Donald" <[EMAIL PROTECTED]>
> To: "Jakarta General List" <[EMAIL PROTECTED]>
> Sent: Friday, November 02, 2001 5:45 PM
> Subject: Re: Integration
>
>
> > On Sat, 3 Nov 2001 05:16, Frans Thamura wrote:
> > > Dear All,
> > >
> > > I see there is a lot of API in Apache... Jakarta and XML
> > >
> > > who resposible for integration, or is there a project for integrating
of
> > > it..
> >
> > integration in what way?
> >
> > > I think we need that. esp, the documentation..
> >
> > I don't think I follow.
> >
> > > there is several issue said this..
> > >
> > > you must post this to this mailing list.. and bla..bla..bla..
> >
> > could you outline
> >
> > --
> > Cheers,
> >
> > Pete
> >
> > 
> >  These aren't the droids you're
> >  looking for. Move along.
> > 
> >
> > --
> > To unsubscribe, e-mail:

> > For additional commands, e-mail:

>
>
> _
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs export problems?

[Vincent Massol]

- Original Message -
From: "Bob Tanner" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, October 24, 2001 11:49 PM
Subject: cvs export problems?


> $ cvs export -d jakarta-cactus -D now  jakarta-cactus
> cvs export: Updating jakarta-cactus
> U jakarta-cactus/.cvsignore
> U jakarta-cactus/LICENSE
> U jakarta-cactus/README
> cvs [export aborted]: cannot write : No such file or
directory
>
> Any reason I cannot do a cvs export?

I have no clue (I have actually never done a cvs export). I am forwarding
the question to the general mailing list.
-Vincent

>
> --
> Bob Tanner <[EMAIL PROTECTED]> | Phone : (952)943-8700
> http://www.mn-linux.org, Minnesota, Linux | Fax   : (952)943-8500
> Key fingerprint =  6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: BCEL @ Jakarta

[Vincent Massol]

+0

I'll go with the majority as I don't want to block the process. I have to
admit I have not completely followed the full thread. I remember the only
concern I had when I read the first proposal was that it seemed to me that
the move to jakarta was mainly because the owner of BCEL had no longer any
time to work on it and wanted to project to live on (which is understandable
:) ). My concern was simply to know who would drive the project, as we all
know, there needs to be at least one person 100% committed to drive the
project forward. I'm sure this issue has been resolved since then and I'm
thus voting +0.

Thanks
-Vincent

- Original Message -
From: "Jason van Zyl" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 25, 2001 5:17 PM
Subject: BCEL @ Jakarta


Hi,

Here's a summary of the PMC voting with respect to moving BCEL
to Jakarta:

[+1] Peter Donald
[+1] Pierpaolo Fumagalli
[+1]Ted Husted
[     ] Ceki Gülcü
[+1] Geir Magnusson Jr.
[ ] Vincent Massol
[+1] Craig McClanahan
[+1] Sam Ruby
[+1] Daniel Savarese
[+1] Jon Stevens
[+1] Jason van Zyl

This gives us the 3/4 PMC approval rating so I believe BCEL will be moving
to Jakarta unless Ceki and/or Vincent express disapproval. We'll let this
float for another day or two to let anyone get their votes/concerns
registered.

--

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



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




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

mailing list problem ?

[Vincent Massol]

Hi,

I have sent 5 mails to the [EMAIL PROTECTED] mailing list
yesterday and they have not yet appeared on the list (after more than 15
hours). Is there any problem currently with the jakarta mail server ?

Thanks
-Vincent


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: New jar dependency for Cactus

[Vincent Massol]

- Original Message -
From: "Daniel F. Savarese" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, October 22, 2001 6:32 PM
Subject: Re: New jar dependency for Cactus


>
> In message <01e701c15b16$c9eee7d0$[EMAIL PROTECTED]>,
"Vince
> nt Massol" writes:
> >I'd like to ask if anyone sees a problem for using AspectJ
> >(http://www.aspectj.org) with Cactus ? More specifically the license is
MPL
> >(http://aspectj.org/servlets/AJSite?channel=download&subChannel=license).
Is
> >that a problem ? I don't believe so, but just wanted to be sure.
>
> I don't think there's a problem.  Redistributing the support libraries
> doesn't appear to conflict, but Jon, Sam, and others know better than I
> what licenses are compatible and which aren't.  Is there a list of
> compatible licenses somewhere on www.apache.org (or did I just
> accidentally volunteer to put one together)?
>
> >If it works, I think a lot of jakarta projects may find aspectj very
useful.
>
> The main issue for me up until recently has been that AspectJ has been
> changing too fast to rely on for significant development purposes.  Now
> that it's stabilized, my main concern is with efficiency (how good is
> the generated byte-code, how intrusive is the use of reflection, etc.).
> So I'd tend to use AOP with AspectJ for testing, where I can compile
> without aspects for production use.  Using it in Cactus is probably an
> excellent fit.  I just wonder how ready Java programmers are to adopt AOP
> at this stage.  If you use AOP under the covers in a development library,
> users of the software aren't going to care.  But if the development
library
> includes an aspect library requiring the use of the AspectJ compiler, I
> wonder if programmers will shy away from it because of the additional
> learning curve and its "non-standard" nature.  At any rate, it will be
> interesting to see how AOP makes its way into Java, C++, and other OOP
> languages over time.
>

Indeed, I agree with all this. I'd like to try it on Cactus for :
- internal stuff: logging entries/exits of methods without having to write
log in each method,
- non-intrusively providing runtime check of Cactus setup : verify if
correct jars are on the classpath, verify properties files, ...

As you see, the initial goal is to try it non-critical things and see how
well it works and how easy to use. There is also a steep learning curve as
it is a different way of thinking. After that, as you have pointed out, I'd
like to use it to help write unit test cases (not sure exactly how yet ...
:) ).

One idea that I have for now is to use AOP to complement testing of
applications :
- we have unit testing with junit/cactus,
- we have functional testing with httpunit or others
- we are missing pattern testing ! And this could be done with aspectj. What
is pattern testing ? It will test the following kind of things :
  - verify that any business method that is called as actually passed
through a controller (MVC model) first,
  - verify that no JDBC code is used anywhere in the code except in such
class/method,
  - verify threading,
  - verify that log4j is used through a wrapper,
  - ...

-Vincent

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

New jar dependency for Cactus

[Vincent Massol]

I'd like to ask if anyone sees a problem for using AspectJ
(http://www.aspectj.org) with Cactus ? More specifically the license is MPL
(http://aspectj.org/servlets/AJSite?channel=download&subChannel=license). Is
that a problem ? I don't believe so, but just wanted to be sure.

If it works, I think a lot of jakarta projects may find aspectj very useful.
I highly recommend reading the tutorial :
http://aspectj.org/doc/dist/tutorial.pdf

Thanks
-Vincent


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

Re: Yesterday's changes to junit and Gump

[Vincent Massol]

We can quickly change it for Cactus. However this means that Cactus users
will have to use JUnit 3.7 from now on ...But I guess it had to happen,
someday and it's a normal event. I'll make the change.

Thanks to GUMP for the good catch .. :)
-Vincent

- Original Message -
From: "Sam Ruby" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, October 22, 2001 2:44 PM
Subject: Re: Yesterday's changes to junit and Gump


> Stefan Bodewig wrote:
> >
> >> yesterday, changes to junit were made that broke a number of
> >> projects.
> >
> >I guess their response will be that TestCase.name() has been
> >deprecated since five months now and the alternative getName() is
> >available in the 3.7 release.
>
> That covers cactus, and perhaps soap and axis.
>
> What about the velocity, and xalan-smoketest failures?
>
> - Sam Ruby
>
> P.S.  How the heck did that compile?  Am I somehow using the version of
> junit which is checked into jakarta-ant?  Is build.sysclasspath broken?
>
>
> -
> 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] New Project Creation Guidelines

[Vincent Massol]

- Original Message - 
From: "Jon Stevens" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 18, 2001 11:41 PM
Subject: Re: [PROPOSAL] New Project Creation Guidelines


> Sam,
> 
> I have integrated the changes that you suggested, please take a look.
> 
> 
> 
> -jon

+1



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

Re: FW: Apache logs problem

[Vincent Massol]

Hi Brian,

Thanks for that answer which explains things. At least I know that there
won't be duplicate logs. Now, I have been generating logs for Cactus for the
past 5 months and I had a script which was checking if logs for day D had
already been processed. There never was a problem (i.e. logs for day D were
never found in file D-1.gz) ... until one month ago approx. I'm wondering
what changed and how it could have been ok prior to this ?

Thanks
-Vincent

- Original Message -
From: "Brian Behlendorf" <[EMAIL PROTECTED]>
To: "Vincent Massol" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Jon
Stevens" <[EMAIL PROTECTED]>
Sent: Monday, October 01, 2001 7:47 PM
Subject: Re: FW: Apache logs problem


>
> There's a very simple explanation for this - sometimes transactions (like
> a big download) take a long time to complete, and the file descriptors to
> logs persist even after the midnight roll is done, so when that
> transaction completes the record is logged to the old log.  This is OK,
> we're talking about a couple hits out of millions.  Just don't rely on the
> file 2001/09/24.gz only containing hits from that day, or hits from 9/24
> only appearing in 2001/09/24.gz.
>
> For a question of relevancy: there are 4200070 hits recorded in 09/24.gz.
> Of those, 12307 hits are actually from the 25th.  That's higher than I
> thought, but tracked it down to the fact that a graceful restart (-USR1)
> doesn't appear to shut down persistant connections.
>
> Also, don't rely on the hits in the logs being in strict time order, as
> logfile writing is buffered, and different buffers from different child
> processes may flush at different times.
>
> Brian
>
> > -- Forwarded Message
> > From: "Vincent Massol" <[EMAIL PROTECTED]>
> > Reply-To: [EMAIL PROTECTED]
> > Date: Sat, 29 Sep 2001 11:39:50 +0100
> > To: <[EMAIL PROTECTED]>
> > Subject: Apache logs  problem
> >
> > It seems there is a problem of dates with the generated apache logs in
> > /x2/logarchive/www/2001
> >
> > For example if you look at 2001/09/24.gz, the last entry is dated
> > 25/Sep/2001:00:21:09 and the first entry of 2001/09/25.gz is dated
> > 25/Sep/2001:00:00:04 !!
> >
> > Now, even worse, I have tried to find in 24.gz the first entry that is
in
> > 25.gz with no success. It is not there ! It means there is a problem of
> > dates and the entries do not seem to be duplicate ... !??
> >
> > This is a big problem for handling logs, especially for generating
> > statistics.
> >
> > This problem is quite new (maybe 1 month at most) and it worked fine
before.
> >
> > Can anyone help ?
> > Thanks
> >
> > -Vincent Massol
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > -- End of Forwarded Message
> >
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> CollabNet  | open source | do what's right
>
>
>


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

Re: Apache logs problem

[Vincent Massol]

Thanks for the tip Ceki !

* Yes, I am using the -p flag (incremental)

* I did not know about the -f one and just checked the man page. It seems
that by using it webalizer will process all logs from previous dates as if
had the time/date of the last known process log. Let's imagine a cron job
for day D : it will need to process D-1.gz (not too easy because we need to
consider when D is at the end of the month - but doable) and D.gz. For
D-1.gz, no -f flag should be used. For D.gz, I will need to use the D.gz
flag but then won't all logs accumulate for the time of the last entry in
D-1.gz, instead of the correct times at which these log happened ? Also, it
looks a bit complicated to me. It would seem normal that D.gz would contain
all logs for the D day  (as was happening before the past month). So, I
would prefer to correct that behaviour instead of trying to accomodate this
[unless someone tells me this behaviour is actually correct for such and
such reason].

* Do you know who is managing daedalus logs so that I can contact him and
solve this out ?

Thanks
-Vincent

- Original Message -
From: "Ceki Gülcü" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, October 01, 2001 1:11 PM
Subject: Re: Apache logs problem



Hello Vincent,

Assuming you are using webalizer, have you tried using the -f (fold sequence
errors) and the -p (preserve state) flags?

Regards, Ceki

At 11:39 29.09.2001 +0100, Vincent Massol wrote:
>It seems there is a problem of dates with the generated apache logs in
>/x2/logarchive/www/2001
>
>For example if you look at 2001/09/24.gz, the last entry is dated
>25/Sep/2001:00:21:09 and the first entry of 2001/09/25.gz is dated
>25/Sep/2001:00:00:04 !!
>
>Now, even worse, I have tried to find in 24.gz the first entry that is in
>25.gz with no success. It is not there ! It means there is a problem of
>dates and the entries do not seem to be duplicate ... !??
>
>This is a big problem for handling logs, especially for generating
>statistics.
>
>This problem is quite new (maybe 1 month at most) and it worked fine
before.
>
>Can anyone help ?
>Thanks
>
>-Vincent Massol
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]

--
Ceki Gülcü - http://qos.ch

The world owes Israel a great debt for destroying Saddam's
French built nuclear reactor in 1981 and thus preventing
nuclear blackmail in the region and perhaps beyond.
   -- Garry Kasparov (yes, the chess player)


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

Apache logs problem

[Vincent Massol]

It seems there is a problem of dates with the generated apache logs in
/x2/logarchive/www/2001

For example if you look at 2001/09/24.gz, the last entry is dated
25/Sep/2001:00:21:09 and the first entry of 2001/09/25.gz is dated
25/Sep/2001:00:00:04 !!

Now, even worse, I have tried to find in 24.gz the first entry that is in
25.gz with no success. It is not there ! It means there is a problem of
dates and the entries do not seem to be duplicate ... !??

This is a big problem for handling logs, especially for generating
statistics.

This problem is quite new (maybe 1 month at most) and it worked fine before.

Can anyone help ?
Thanks

-Vincent Massol


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

Re: Web logs & statistics

[Vincent Massol]

- Original Message -
From: "Peter Donald" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 27, 2001 11:25 AM
Subject: Re: Web logs & statistics


> On Thu, 27 Sep 2001 18:55, Vincent Massol wrote:
> > Statistics :
> >
> > Is it possible to set up a statistics tool for all jakarta projects (and
> > even others) so that each project does not have to do its own
statistics.
> > For example, I had to install webalizer in my jakarta account to create
> > Cactus statistics (available at
> > http://jakarta.apache.org/~vmassol/webalizer/). It provides some very
> > useful information. However, I know that I am eating quite a lot of
space
> > on daedalus [and am concerned by that], especially as I am a rookie in
> > webalizer and have not spent the time (yet) to know how to properly do
diff
> > statistics so I have stored all logs related to Cactus in a big file
which
> > eats 145Mo and do a full parsing using webalizer every time (it's quite
> > fast and only takes about 10 seconds). I also have to do this process
> > manually as I didn't want to set a cron job.
>
> Thansk for volunteering!
>

hehe ... I knew it  I always get caught the same way within my own
company, I should have known better ... ;-)

> The best way to get thing to do to get this implemented is to volunteer to
do
> it ;) I am sure it would be fine to create a dir at
> /www/jakarta.apache.org/statistics/ and pump out the webpages there. Then
all
> you need to do is modify jakarta-site docs to link to appropriate web logs
> and your good to go. Chuck in a cron job and voila` - its done ;)
>

Ok, I can do it but I'll probably need some help. For example to install
webalizer in the correct directory I would need the correct rights. Also,
where should it go : in /usr/local/bin ? Once I got webalizer (or any
another one. I have only tried this one), I can probably manage the rest
alone.

Thanks
-Vincent


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

Web logs & statistics

[Vincent Massol]

General Remark:

It seems the web logs have been moved recently from
/x2/logarchive/www/jakarta.apache.org/$YEAR/$MONTH to
/x2/logarchive/www/$YEAR/$MONTH. Also the .gz files now contains logs
for the J day and also some logs for the J+1 day ... which makes it harder
to get statistics for a given day. Any reason for that ?

Statistics :

Is it possible to set up a statistics tool for all jakarta projects (and
even others) so that each project does not have to do its own statistics.
For example, I had to install webalizer in my jakarta account to create
Cactus statistics (available at
http://jakarta.apache.org/~vmassol/webalizer/). It provides some very useful
information. However, I know that I am eating quite a lot of space on
daedalus [and am concerned by that], especially as I am a rookie in
webalizer and have not spent the time (yet) to know how to properly do diff
statistics so I have stored all logs related to Cactus in a big file which
eats 145Mo and do a full parsing using webalizer every time (it's quite fast
and only takes about 10 seconds). I also have to do this process manually as
I didn't want to set a cron job.

I'm sure this is not a new subject and it may have been discussed in the
past. I think offering a statistics page on jakarta.apache.org would be nice
and would also provide a good and healthy competition between projects ...
:) It may even make the project committers more conscious about their user
base and pay more attention to the users (like trying not to remove public
API too fast, ) ... :)

Thanks
-Vincent


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

[announcement] Cactus is now a Jakarta top level project

[Vincent Massol]

Thanks to all who made this possible. The jakarta site has been updated to
reflect the change.

The new home for Cactus is http://jakarta.apache.org/cactus.

-Vincent


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

Re: [VOTE] Making Commons-Cactus a top level projet

[Vincent Massol]

- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Vincent Massol" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Saturday, September 15, 2001 4:21 PM
Subject: Re: [VOTE] Making Commons-Cactus a top level projet


> I've set up the new top-level entry.  Let me know what "components" and
> "versions" you would like set up, and I will do those as well.
>

Thanks Craig. Do I have the correct rights to do it myself, as I don't want
to bother you or anyone every time I'll need to change it ?

For the time being, the versions are : "1.0", "1.1" and "Nightly build". The
components are : "Web site", "Documentation", "Example", "Tests", "Unknown",
"Server side", "Client side".

-Vincent




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

Re: [VOTE] Making Commons-Cactus a top level projet

[Vincent Massol]

Can someone add Cactus to the Apache Bug Database (as a top level project)
and remove its entry from Commons (as a sub component) ? Or tell me how to
do it ...

Thanks
-Vincent


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

Re: [VOTE] Making Commons-Cactus a top level projet

[Vincent Massol]

- Original Message -
From: "Pier Fumagalli" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, September 14, 2001 10:11 PM
Subject: Re: [VOTE] Making Commons-Cactus a top level projet


> All done... CVS moved (preserving history in jakarta-commons and renaming
> packages and directories in jakarta-cactus), mailing lists have been
> created, so, I believe I'm done... Have fun...
>

Thanks a lot for you help Pier ! WRT the dev mailing-list, do you have
subscribed archive@jab.org to it (see
http://www.mail-archive.com/faq.html#newlist) ?

-Vincent



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

Re: [VOTE] Making Commons-Cactus a top level projet

[Vincent Massol]

- Original Message -
From: "Sam Ruby" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 14, 2001 8:42 PM
Subject: Re: [VOTE] Making Commons-Cactus a top level projet


> Geir Magnusson Jr. wrote:
> >
> > Don't you want to preserve your history?
>
> What Vincent appears to be contemplating is a number of changes along the
> lines of s/org.apache.commons.cactus/org.apache.cactus/ - both in terms of
> the actual directory structure along with corresponding global changes to
> the global import statements.  I'm fairly handy with Perl, so if I can
> help, let me know.
>

Thanks for the proposition ! Actually I am currently using the IDEA IDE from
IntelliJ. It is really nice and has powerful search/replace features, along
with features like "who is using this variable", "show me where it is
declared", "rename this method and all the calls to it", ... It is my
favorite IDE so far ...

What I meant by saying  that I didn't car too much about the history is that
I thought it might be an opportunity to start with a clean repository
without all the empty directories (for which content has been deleted in the
past) and moving to org.apache.cactus will create yet a handful of these
directories (I'm waiting eagerly for subversion ... :) ). As Jon said, the
history can be preserved in jakarta-commons. However, I am quite novice with
CVS so if there are pros for moving everything with history to the new
location, then lets do it.

> - Sam Ruby
-Vincent


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

Re: [VOTE] Making Commons-Cactus a top level projet

[Vincent Massol]

- Original Message -
From: "Vincent Massol" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, September 14, 2001 4:43 PM
Subject: Re: [VOTE] Making Commons-Cactus a top level projet

[snip]
>
> We need:
> - a new CVS. Is it possible to not to loose any history by copying the CVS
> files rather than doing an import ?

Actually, it may be a good idea to move to a clean CVS (?). Otherwise, as
there will be a package change it will mean a lot of empty directories in
the src/ directory.

thanks
-Vincent


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

Re: [VOTE] Making Commons-Cactus a top level projet

[Vincent Massol]

- Original Message -
From: "Ted Husted" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, September 14, 2001 4:04 PM
Subject: Re: [VOTE] Making Commons-Cactus a top level projet


> Yes, Jason's vote came in after I posted. Counting Craig, that makes 8,
> which is the threshhold.
>

:-)

> Jason and I (with assists from Sam and Brian) are just finishing up
> Lucene, which could launch next week.
>
> I guess for Catcus all we need is a new CVS where Vincent can upload the
> source. The Website and mailing lists are all ready in place.
>
> Should the +1's from the commons vote be the intial committer list,
> Vincent?
>
> Commons Committers:
>
> Morgan Delagrange, +1
> Craig R. McClanahan, +1
> Rodney Waldhoff, +1
> Scott Sanders, +1
> Geir Magnusson Jr., +1
> James Strachan, +1
> Vincent Massol, +1
>

We need:
- a new CVS. Is it possible to not to loose any history by copying the CVS
files rather than doing an import ?
- a new web site location: Cactus is currently in
/www/jakarta.apache.org/commons/cactus. It should probably be moved in
/www/jakarta.apache.org/cactus (so that it can be accessed by
http://jakarta.apache.org/cactus). I guess this is just a matter of doing a
copy.
- mailing list is fine for cactus-users. We will need to set up one for
cactus-dev
- Jyve: a new entry for Cactus. At the current time, the Cactus FAQ is in
the Jakarta-Commons FAQ.
- modify the Jakarta web site to reflect the change (menu, mailing list,
download, announcement, ...)

[And we need to make a few changes to Cactus : package name + documentation
+ others]

But I agree, the most important at this stage is the new CVS.

WRT the Cactus committers, there are already 2 for Cactus :
-Vincent Massol
-Jari Worsley
and there is a pending vote for Nicholas Lesiecki as a new Cactus committer.

If I understand, we need a minimum of 3 committers: we have already 2.
Either Nicholas is voted in or any committers from Commons who would like to
be Cactus committers ...

> We might also want to add a "Who We Are" page to the Cactus site listing
> the Committers and other developers working on the product.
>

It's already done (I did that a few days ago, although I think I forgot to
put Rob Leland and you, Ted .. oops  If I remember correctly you were
the 2 initial committers for Cactus, right ?).

thanks for your help!

-Vincent



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

Re: lists that don't require subscriber approval

[Vincent Massol]

- Original Message -
From: "Jon Stevens" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, September 08, 2001 5:51 PM
Subject: Re: lists that don't require subscriber approval


> on 9/8/01 5:26 AM, "Vincent Massol" <[EMAIL PROTECTED]> wrote:
>
> > Ok for doing the website but I would have preferred someone who has
already
> > done it and has everything set up on his machine (I don't and will have
to
> > learn the mechanism before so it'll take a some time). To summarise,
there
> > are 2 things to correct: remove the "doc" mailing list and correct the
> > commons one.
>
> cvs co jakarta-site2
> cd jakarta-site2
> edit xdocs/site/mail2.xml
> ant
> cvs ci
>
> It isn't rocket science.
>

you forgot the second part (which I had to make up myself ! :) ):

ssh -l xxx jakarta.apache.org
cd /www/jakarta.apache.org/site
cvs update mail2.html

-Vincent


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

Re: lists that don't require subscriber approval

[Vincent Massol]

- Original Message -
From: "Jon Stevens" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, September 08, 2001 5:51 PM
Subject: Re: lists that don't require subscriber approval


> on 9/8/01 5:26 AM, "Vincent Massol" <[EMAIL PROTECTED]> wrote:
>
> > Ok for doing the website but I would have preferred someone who has
already
> > done it and has everything set up on his machine (I don't and will have
to
> > learn the mechanism before so it'll take a some time). To summarise,
there
> > are 2 things to correct: remove the "doc" mailing list and correct the
> > commons one.
>
> cvs co jakarta-site2
> cd jakarta-site2
> edit xdocs/site/mail2.xml
> ant
> cvs ci
>
> It isn't rocket science.
>

Yep, thanks for the tutorial. I have done the changes. However, I haven't
modified the archiving on mail-archive for Commons as I'm not sure what to
do (and do not have the rights). We probably need to subscribe the new
commons-dev@... to it. Do we need to do something to prevent creating a new
archive (http://www.mail-archive.com/faq.html#duplicate) ?

thanks
-Vincent


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

Re: lists that don't require subscriber approval

[Vincent Massol]

Hey, don't take me wrong here  :-)

I just jumped in because I saw some post on this newsgroup saying that you
wanted to homogeneise mailing lists ... I probably misunderstood the intent
which was maybe only to standardise on the mailing-list names (or rather to
align with the existing standard :)) ...

Ok for doing the website but I would have preferred someone who has already
done it and has everything set up on his machine (I don't and will have to
learn the mechanism before so it'll take a some time). To summarise, there
are 2 things to correct: remove the "doc" mailing list and correct the
commons one.

Regarding your "quote", I looked for it in my emails ... and couldn't find
it ... :) I guess I dreamed it ... So I apologise and I owe you a beer. Tell
me when you are in London and we'll go to the pub someday :-)

Have a goo weekend
Cheers,
-Vincent

- Original Message -
From: "Pier Fumagalli" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, September 08, 2001 12:44 PM
Subject: Re: lists that don't require subscriber approval


> "Vincent Massol" <[EMAIL PROTECTED]> wrote:
>
> > I've had a look at http://jakarta.apache.org/site/mail2.html ...
> >
> > Here are the strange things I found :
> > * Alexandria : no user list (Pier I thought you said ALL projects had
both
> > lists ;-) )
>
> I thought doesn't work... Give me a quote of me saying that, and I'll owe
> you a beer...
>
> > * Avalon : no user list and a strange cvs list (I thought all CVS
messages
> > went to the devlist ?)
>
> Depends on the project...
>
> > * Commons : information not updated
>
> Do it :) I manage EZMLM, someone please kick some code in the website...
>
> > * Jakarta documentation : only a docs@ : no user and dev and a cvs list
...
>
> In fact there was no traffic... I deleted that mailing list yesterday
since
> noone complained...
>
> > * Log4j : a cvs list
>
> They have a CVS list, so what? APR, HTTPD, and many others have a -cvs
list.
> Some of the Jakarta project decided to collapse it with the -dev... Some
> didn't...
>
> > * Velocity a TDK list : Question : do we say that -user and -dev lists
are
> > mandatory and projects are allowed to create additional lists ?
>
> Their list is velocity-tdk-dev... So, (kudos to Jon)
> project-subproject-identifier, in line with our guidelines... As CVS
> trees... Jakarta-project-subproject-subsubproject
>
> > * Watchdog : no user list
>
> So?
>
> > In summary, there is still some work to be done to homogeneize lists ...
:)
>
> No, there's no work to be done... Apart from a website fix (and I am NOT
> going to do that... Someone else please volunteer): removing docs and
> modifying commons.
>
> If a project don't wont a -user list because they don't feel like having
> reached that point where users do bother on the developer list, I'm not
> going to force them to have one. If a project wants a CVS list because
they
> don't want all -dev traffic mixed with it, that's FINE... As long as we
> agree on the basic naming scheme, I'm fine...
>
> > Who takes charge of changing this ?
>
> You :) At least for the website part... Nothing else need to be done...
>
> Pier
>
>
> -
> 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: lists that don't require subscriber approval

[Vincent Massol]

I've had a look at http://jakarta.apache.org/site/mail2.html ...

Here are the strange things I found :
* Alexandria : no user list (Pier I thought you said ALL projects had both
lists ;-) )
* Avalon : no user list and a strange cvs list (I thought all CVS messages
went to the devlist ?)
* Commons : information not updated
* Jakarta documentation : only a docs@ : no user and dev and a cvs list ...
* Log4j : a cvs list
* Velocity a TDK list : Question : do we say that -user and -dev lists are
mandatory and projects are allowed to create additional lists ?
* Watchdog : no user list

In summary, there is still some work to be done to homogeneize lists ... :)

Who takes charge of changing this ?

Thanks
-Vincent

- Original Message -
From: "Pier Fumagalli" <[EMAIL PROTECTED]>
To: "Brian Behlendorf" <[EMAIL PROTECTED]>; "Ted Husted" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, September 08, 2001 3:53 AM
Subject: Re: lists that don't require subscriber approval


> "Brian Behlendorf" <[EMAIL PROTECTED]> wrote:
>
> >> Lists to moderate:
> >> - slide-dev (Remy)
> >> - slide-user (Remy)
> >
> > Email address?  Er, I'll let you deal with it.
>
> [EMAIL PROTECTED] :) He's one of my fellow bandwidth stealers :)
> (I contacted him and he agreed, in exchange for WebMail on
betaversion.org.
> Done - apart from webmail!)
>
> >> Lists to nuke:
> >> - check-dev
> >> - docs
> >> - josper-dev
> >
> > I'll let you do these.
>
> Done...
>
> >> Lists to rename:
> >> - jakarta-commons (commons-dev)
>
> Renamed... (or better, created new mailing list, moved all regular and
> digest subscribers, posted a couple of test messages to see that
everything
> was working right and removed the old list - leaving the post address to
be
> an alias to the new mailing list!)
>
> >> - cactus-user (commons-user or commons-cactus-user)
> >> - servletapi-dev (collapse into tomcat-dev)
> >> - watchdog-dev (collapse into tomcat-dev)
> >
> > I'll let you do these.
>
> I'm waiting for feedback on those...
>
> Pier
>
>
> -
> 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: lists that don't require subscriber approval

[Vincent Massol]

- Original Message -
From: "Pier Fumagalli" <[EMAIL PROTECTED]>
To: "Brian Behlendorf" <[EMAIL PROTECTED]>; "Ted Husted" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, September 08, 2001 3:53 AM
Subject: Re: lists that don't require subscriber approval

[snip]
> >> - cactus-user (commons-user or commons-cactus-user)
> >> - servletapi-dev (collapse into tomcat-dev)
> >> - watchdog-dev (collapse into tomcat-dev)
> >
> > I'll let you do these.
>
> I'm waiting for feedback on those...
>

Regarding cactus :

I think we should leave a few more days for other committer to vote. I don't
know what the standard number of days to leave. Why don't we say until
monday 12:00 PM GMT. Then we submit the proposition to the PMC for their
blessing.

How is that ?
Thanks
-Vincent


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

Re: lists that don't require subscriber approval

[Vincent Massol]

- Original Message -
From: "Pier Fumagalli" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, September 06, 2001 3:44 PM
Subject: Re: lists that don't require subscriber approval


> "Vincent Massol" <[EMAIL PROTECTED]> wrote:
> >
> > You're right. The name [EMAIL PROTECTED] was the
voted
> > name. I seem to remember that the list name was changed at the last
minute
> > to be cactus-user@... because there was the intention to make Cactus a
root
> > project in the future and a name change being a major change it was
> > preferred to name right away cactus-user@...
>
> And making a hell-of-confusion :) Joking, of course... I tend to agree
with
> Brian and with the "guidelines" he gave when we opened the new subprojects
> (back in 99, I believe)... It's just that since (now) cactus is not a
> top-level project, it shouldn't have a top level Mailing List, but it
should
> be always be prepended by the name of the project in which it resides...
>

I also agree. It was a mistake and I apologize for that. Please forgive me
... I promise not to do it again ... :-)

> > However, you're right and I don't think it was done in a orderly manner
and I
> > don't remember any voting on the subject.
>
> I believe that, if you developers want to be a "real" root-level project,
> well, you have all the right to be... Did you have a vote on the commons
> mailing list to "split out" ??? :)

just sent a request for vote now on [EMAIL PROTECTED] ...
:)

>
> > Maybe now is the right time to vote for making Cactus a top level
project ?
> > Are there conditions for that (like number of hits,downloads, community)
?
> > Who decides, PMC members ?
>
> Once the developers agree that they want to become top level, I believe
that
> it's only a matter of PMC "blessing" of that... I would be +1...
>

Thanks.

> Pier
-Vincent


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

Re: lists that don't require subscriber approval

[Vincent Massol]

- Original Message -
From: "Peter Donald" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, September 06, 2001 2:45 PM
Subject: Re: lists that don't require subscriber approval


> On Thu, 6 Sep 2001 23:44, Pier Fumagalli wrote:
> > Things I also noticed:
> >
> > - cactus-user
> >
> > I don't know what this is all about... There is no archive, cactus is
> > related to the "commons" project, so, it should be really a
> > "commons-user@jakarta"...
>
> I think when it was initially voted on it was to be named
> "commons-cactus-user@" or "commons-cactus@" or similar. Not sure
what
> happened though. The reason for keeping it separate was that it was
> generating a fair number of messages that most commons users didn't want
to
> see ;)
>

You're right. The name [EMAIL PROTECTED] was the voted
name. I seem to remember that the list name was changed at the last minute
to be cactus-user@... because there was the intention to make Cactus a root
project in the future and a name change being a major change it was
preferred to name right away cactus-user@... However, you're right and I
don't think it was done in a orderly manner and I don't remember any voting
on the subject.

Maybe now is the right time to vote for making Cactus a top level project ?
Are there conditions for that (like number of hits,downloads, community) ?
Who decides, PMC members ?

Thanks
-Vincent Massol



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

Re: Proposed dirlayout document

[Vincent Massol]

- Original Message -
From: "Ceki Gülcü" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, May 07, 2001 5:09 PM
Subject: Re: Proposed dirlayout document


[znip]

>I have asked this before but is there a need for an intermediary directory?
For example, to take an example I am familiar with, Tomcat 4.x, a damn good
project I might add, has a build/ directory and a dist/ directory where
dist/ is a copy of build/. I do not know why Tomcat is doing this but it is.
Other projects are doing similar things. I am obviously missing something...

The intermediate directory (out/ in my proposition) is mostly used to
replace tokens and will contain files that are not needed for the
distribution. For example :
- in the Cactus project, I copy all the java source to the out/ directory
and replace the @version@ token by the current version. This is before doing
the compilation and generating the javadoc
- it contains the classes files which are not part of the distribution
- it contains copies of the manifest file in which tokens have been replaced
(@version@ for example)
- for Cactus, this is where I run the servlet engines and run the unit and
functional tests,
- ...

[snip]
Cheers,
Vincent



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

Re: Proposed dirlayout document

[Vincent Massol]

- Original Message -
From: "Sam Ruby" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, May 07, 2001 4:36 PM
Subject: Re: Proposed dirlayout document


> Peter Donald wrote:
> >
> > >6) 2 options should be left to the project for the external jar needed
> to
> > >build/run the project. Until we reach an agreement on course ... (maybe
> > >CJAN/JJAR - see the discussion on jakarta-commons mailing list - will
> help)
> > >:
> > >a) leave the external jars out of CVS. i.e. use a build.properties file
> > >(used by Ant) that defines the location of needed external jars
> > >b) or check the needed external libs in CVS with the project.
> >
> > or both ;)
>
> An expansion on Peter's comments.
>
> What should be recommended is the ability to (1) control the actual jars
> used via Ant properties, and (2) be able to easily specify these
properties
> using Ant properties files which can be found in the current working
> directory or the user's home directory.  (Note: the name of these
> properties files should be standardized too, my only vote is that they
> don't start with a "dot").
>
> What the defaults for such properties should be is subject to much
> controversy.  If jars are checked into CVS, then the path to these jars
> would be a reasonable default.
>

+1 for defining this properties file and having the link to the jars
specified in it. My proposal for the name is build.properties as we already
have build.xml ...(please no "dot" as a prefix !).

> - Sam Ruby
Vincent


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

Re: Proposed dirlayout document

[Vincent Massol]

- Original Message -
From: "Peter Donald" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, May 07, 2001 3:28 PM
Subject: Re: Proposed dirlayout document


> At 03:03  7/5/01 +0100, Vincent Massol wrote:
> >1) There is no directory defined for configuration files (top level
> >properties file, top level xml files, manifest file to include in jar,
...).
> >Do we want to define a location for these ?
>
> yup. I recomend
>
> src/conf for config files (as many are manipulated via value substitution)

+1

> src/manifest for manifests .. mainly as it is less unixy than src/etc ;)
>

hum ... do we want so many different directories for config files. I would
prefer just one like src/conf and then leave it up to the project for
creating as many subdirectories as deemed necessary ... Why make it a
special case for manifests ?

> >2) The rule for the output directory says : either bin/ or build/. I
think
> >that a) we must make up our minds on one choice only and b) then names
are
> >not well choosen as they be misinterpreted. I would suggest something
less
> >equivocal like out/
>
> +1 for out (basically intermediates directory right?)

right

>
> >3) Until we all agree, I would let the project decide on how to use Ant :
> >a) as an application that need to be installed on the computer doing the
> >build. This means no need to have ant.jar, optional.jar, xerces.jar,
> >xalan.jar, stylebook.jar,  in the build/lib directory and no .bat or
.sh
> >files needed either.
> >b) as a "component", i.e. located in build/lib with all it's needed jar
> >files
>
> Again - a lot of projects use build as intermediate directory and it would
> be unnacceptable to have it transmogify into something that contains
> scripts/tools/etc - hence I recomend "tools" dir to hold this if present.
>

No, I meant strategies on how to use Ant : as an installed application vs an
"embedded" application/component.

> >4) The section on docs/ is not clear. Is it output docs not in CVS or non
> >generated docs in CVS. It seems to be both. Should be clarified I think
>
> the problem is the answer is "it depends" until someone implements a
> jakarta wide building of website docs ;)
>
> >5) There should be only one name for the build scripts and tools. I would
> >tend to prefer build/ with the output directory named out/. I don't
really
> >care about the name but there should be only one proposed
>
> I prefer build.xml and build.[sh|bat] if present to be at base of tree
> while the rest of tools/scripts in "tools" dir. This doesnm't cause any
> conflicts with any projects I have noticed.
>

I see. You want to remove the build configuration from the build/tools
directory so that you can have only tools in that directory (basically Ant +
dependent jars) and name it "tools/", right ? So for those who use Ant as an
installed application, this "tools/" directory won't be need (unless they
use other tools).

> >6) 2 options should be left to the project for the external jar needed to
> >build/run the project. Until we reach an agreement on course ... (maybe
> >CJAN/JJAR - see the discussion on jakarta-commons mailing list - will
help)
> >:
> >a) leave the external jars out of CVS. i.e. use a build.properties file
> >(used by Ant) that defines the location of needed external jars
> >b) or check the needed external libs in CVS with the project.
>
> or both ;)
>

Yes. That's why I said "2 options should be left [...]" ... :)

> Cheers,
>
> Pete
Cheers,
Vincent.


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

Re: Proposed dirlayout document

[Vincent Massol]

+1 also

Here are some comments I have after reading the dirlayout.html file (for the
first time, I have to admit. Actually I don't know where it is linked to on
the jakarta web site !) ...

I don't want to start a lengthy discussion (as it is very difficult to reach
an agreement on these subjects ... :) ) but I still wanted to help ... :)

1) There is no directory defined for configuration files (top level
properties file, top level xml files, manifest file to include in jar, ...).
Do we want to define a location for these ?

2) The rule for the output directory says : either bin/ or build/. I think
that a) we must make up our minds on one choice only and b) then names are
not well choosen as they be misinterpreted. I would suggest something less
equivocal like out/ : build/ can be both the location of the files needed
for building the project or the result of the build and bin/ can be location
of generated executables or executable needed by the project for some tasks.
Also, bin/ is inherited from previous languages like C/C++ where you built
and executable. In java it is not really an executable, more like a library
but lib/ wouldn't be good either.

3) Until we all agree, I would let the project decide on how to use Ant :
a) as an application that need to be installed on the computer doing the
build. This means no need to have ant.jar, optional.jar, xerces.jar,
xalan.jar, stylebook.jar,  in the build/lib directory and no .bat or .sh
files needed either.
b) as a "component", i.e. located in build/lib with all it's needed jar
files

4) The section on docs/ is not clear. Is it output docs not in CVS or non
generated docs in CVS. It seems to be both. Should be clarified I think

5) There should be only one name for the build scripts and tools. I would
tend to prefer build/ with the output directory named out/. I don't really
care about the name but there should be only one proposed

6) 2 options should be left to the project for the external jar needed to
build/run the project. Until we reach an agreement on course ... (maybe
CJAN/JJAR - see the discussion on jakarta-commons mailing list - will help)
:
a) leave the external jars out of CVS. i.e. use a build.properties file
(used by Ant) that defines the location of needed external jars
b) or check the needed external libs in CVS with the project.

Hope it helps.
Thanks
Vincent.


- Original Message -
From: "Conor MacNeill" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, May 07, 2001 1:51 PM
Subject: Re: Proposed dirlayout document


> Ceki,
>
> +1
>
> I agree. Too much optionality in a standard means there is nothing
standard
> about it. I raised some issues about the original layout. These were just
> raising what I thought was the common Jakarta approach to some of these
> things.
>
> So, lets have a single approach with little optionality. It should be
> non-binding with a goal to move current projects to this standard.
>
> I don't think Ant should dictate the structure. I'm confident it will be
> able to support anything reasonable.
>
> Bring it on ...
>
> Conor
>
> - Original Message -
> From: "Ceki Gülcü" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, May 07, 2001 9:13 PM
> Subject: Proposed dirlayout document
>
>
>
> Hi everyone,
>
> Having recently looked at http://jakarta.apache.org/site/dirlayout.html,
my
> impression was that it allowed  too many alternatives on a large number of
> points rendering the document somewhat confusing (useless?). I am against
> making the dirlayout document an exhaustive list of all possible layout
> structures. A guideline document should be a bit more assertive.
>
> With your permission I would like to eliminate some of the alternatives.
> This is surely going upset some people. I am asking for the permission to
> make some potentially controversial  changes. Let me repeat that I do not
> consider myself as an expert in ANT or to know the optimal directory
> structures.  As such, you are strongly encouraged to make suggestions.
>
> In order to avoid endless discussion, I am willing to cede my role if
> anyone volunteers to take up the responsibility for the document. Best
> regards, Ceki
>
>
>
> --
> Ceki Gülcü
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


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

Re: [PROPOSAL] J2EEUnit donation to ASF

[Vincent Massol]

- Original Message -
From: "John Summerfield" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, March 28, 2001 5:15 AM
Subject: Re: [PROPOSAL] J2EEUnit donation to ASF


> > Thoughts and Comments:
>
> It makes no sense to me to switch lists as it seems you've done. People
here
> have no idea what you're rattling on about, and those on the other list
won't
> benefit from your great wisdom.
>

I agree. I just made a mistake and was told that this discussion should
happen on both [EMAIL PROTECTED] and
[EMAIL PROTECTED], which are the 2 interested parties.

Sorry for the trouble I may be causing you and for my lack of knowledge
about Apache and Jakarta organization in general ...
Cheers,
Vincent.

>
>
> --
> Cheers
> John Summerfield
> http://www2.ami.com.au/ for OS/2 & linux information.
> Configuration, networking, combined IBM ftpsites index.
>
> Microsoft's most solid OS: http://www.geocities.com/rcwoolley/
>
> Note: mail delivered to me is deemed to be intended for me, for my
disposition.
>
>
>
>
> -
> 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] J2EEUnit donation to ASF

[Vincent Massol]

- Original Message -
From: "Paul Michael Reilly" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Vincent Massol" <[EMAIL PROTECTED]>
Sent: Tuesday, March 27, 2001 11:27 PM
Subject: Re: [PROPOSAL] J2EEUnit donation to ASF


> Vincent Massol writes:
>  >
>  > - Original Message -
>  > From: "Ted Husted" <[EMAIL PROTECTED]>
>  > To: <[EMAIL PROTECTED]>
>  > Sent: Tuesday, March 27, 2001 7:50 PM
>  > Subject: Re: [PROPOSAL] J2EEUnit donation to ASF
>  >
>  >
>  > > Jon Stevens wrote:
>  > > > Does Victor have the express copyright on all of the code that was
>  > submitted
>  > > > under the GPL license?
>  > >
>  > > Yes.
>  > >
>  >
>  > Yes. My name is Vincent, although Victor is also a nice name ... :)
>  >
>  > > > > Nice catch on the name. I'm sure we can work that out.
>  > > >
>  > > > Given that the PMC is what is worried about the legalities of
things and
>  > as
>  > > > a member of the PMC, I'm still -1 on the name.
>  > >
>  > > Agreed. We'll find another name.
>  >
>  > OK ... sigh  If you have ideas, they are welcome ...
>
> JUnitEE seems like a reasonable and safe choice.
>

yes, I agree but unfortunately it's already taken (see
http://c2.com/cgi/wiki?JavaUnit). We could of course ask Jeff Schnitzer (the
author) if he would be willing to merge with J2EEUnit and join our effort
under the ASF.

I have sent a request to Sun to ask them if I could keep the name J2EEUnit.

> -pmr
>
thanks
Vincent


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

Re: [PROPOSAL] J2EEUnit donation to ASF

[Vincent Massol]

- Original Message -
From: "Ted Husted" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, March 27, 2001 7:50 PM
Subject: Re: [PROPOSAL] J2EEUnit donation to ASF


> Jon Stevens wrote:
> > Does Victor have the express copyright on all of the code that was
submitted
> > under the GPL license?
>
> Yes.
>

Yes. My name is Vincent, although Victor is also a nice name ... :)

> > > Nice catch on the name. I'm sure we can work that out.
> >
> > Given that the PMC is what is worried about the legalities of things and
as
> > a member of the PMC, I'm still -1 on the name.
>
> Agreed. We'll find another name.

OK ... sigh  If you have ideas, they are welcome ...

>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
>

Vincent Massol


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

[PROPOSAL] J2EEUnit donation to ASF

[Vincent Massol]

0) rationaleRegression testing is an essential 
part of developing"commercial-quality" software. JUnit is a  popular 
testing platform,butis primarily designed for standard Java classes. 
J2EEUnit extends theJunit API to facilitate unit testing of server-side Java 
code. SinceJakarta products are mainly servlet-based, J2EEUnit is a 
naturaladdition to the Jakarta family. I am the sole author of J2EEUnit 
andwould like to donate the source code to the ASF for distribution 
underthe Apache License. I am currently a Committer to the 
Strutssubproject.(1) scopeJ2EEUnit provides a set of classes 
which help developers create testcases and test suites of server-side 
products. J2EEUnit extends JUnit,a popular open source product distributed 
under the IBM Public License.For Web application testing, J2EEUnit 
complements another JUnitextension, HttpUnit < http://httpunit.sourceforge.net/ 
>. HttpUnitis designed to test the output of Web pages, while J2EEUnit is 
designedto test server-side classes living inside a 
container.(1.5) interaction with other productsJ2EEUnit already 
uses Ant as its build system for compiling andgenerating the runtime jars, 
Javadoc, a sample application, and also torun unit and functional 
tests.J2EEUnit has been built with continuous integration in mind, 
meaningthat J2EEUnit unit tests can easily be  automated using Ant. 
J2EEUnitprovides such Ant scripts for the most common servlet engines 
(Tomcat3.x,  Tomcat 4.x, Resin 1.2 & 1.3, WebLogic 5.1, Orion 1.4). 
Also,J2EEUnit is already integrated with GUMP (part of Alexandria) 
andbuildsare run every day on the jakarta servers (thanks to Sam Ruby). 
Work isunderway in the Struts subproject to create a testing suite for 
thatframework.(2) identify the initial source from which the 
subproject is to bepopulatedA release (0.9) of J2EEUnit is now 
available from SourceForge <http://j2eeunit.sourceforge.net/ 
> under the GPL and also through theCommons-Sandbox CVS. Vincent Massol, 
thedonor, certifies that he is the sole author and owner of the 
sourcecode. If accepted, the latest version (0.9) will be donated to the 
ASFand may be released under the Apache License.(2.1) source 
statusJ2EEUnit is reaching maturity. The current version is 0.9 and has 
beenthrough several releases on SourceForge. The project 
directorystructurealready generally follows the Apache guidelines. The 
source code isheavily commented and I would call the code production 
quality.(2.2) dependenciesJ2EEUnit imports classes only from 
java, javax, and junit.framework.(3) identify any Jakarta-Commons 
resources to be createdThe J2EE source code can be checked into a 
directory in the main CVS,and can use the Jakarta-Commons mailing list for 
communications.(4) identify the initial set of committers to be listed 
in the StatusFile.Vincent MassolRobert LelandTed 
Husted(5) my goals and wishesMy goal is to transform a one-man 
codebase that is gaining visibilitybut is still developed by a single person 
into a thriving product withmultiple developers contributing to the 
codebase. I believe this can beachieved by donating the product to the 
Apache Software Foundation.Along with this goal, I also believe that 
J2EEUnit could benefit manyother Jakarta products, especially if they share 
a common license.
 

Re: [PROPOSAL] J2EEUnit donation to ASF

[Vincent Massol]

- Original Message -
From: "Jon Stevens" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Tuesday, March 27, 2001 6:29 PM
Subject: Re: [PROPOSAL] J2EEUnit donation to ASF


> Thoughts and Comments:
>
> #1. IMHO, this discussion should be on [EMAIL PROTECTED] and NOT
> [EMAIL PROTECTED] I really can't understand why it was sent to PMC@
> given all the hoohaah over doing things privately. Sigh. If you are
getting
> this for the first time, look in the jakarta-commons mailing list archives
> for the original proposal. If I have to tell you were the archives are,
I'm
> going to scream. 
>

Sorry about this mail sent to [EMAIL PROTECTED] I just did a reply to
a mail that was sent to me mentionning that I had to change the J2EEUnit
license and pmc was in copy. As I am new here I didn't know sending to pmc
was not relevant. I'm the only one to blame. This is the last mail you'll
receive from me ... :)

> #2. There is no mention in the proposal about what sort of community is
> already formed around this software. Is there just one guy working on it?
> Remember, we are not a dumping ground.
>

The J2EEUnit project was started on november 2000 and has been well
received. There have been more than 12,000 downloads and around 800 pages
viewed per day. It started as a one guy project (me) but there are now a few
users (I'd say around 3-4) also sending changes. Others (in the range of 20)
are sugessting changes but not doing the modifications themselves. The
majority are just end users.

> #3. Where will this project live? Is it a top level project or something
> that is under the Jakarta Commons (as suggested by only CC'ing it to the
> jakarta-commons mailing list and (3) in the proposal). If it will live
under
> the Commons project, then why is it a proposal going to the PMC@ mailing
> list? I think that this is a decision for the Commons project and not the
> overall Jakarta Project.
>

Again, I'm not too familiar with the different options. From the previous
discussions I have had and followed, it seems that Jakarta-Commons would the
right place. This is where I have uploaded it.

> #3. I'm worried about the name. Given that Sun owns the trademark for
"J2EE"
> and seem to take it pretty seriously, they *might* have a problem with us
> having a product with that in the name...regardless of whether not not it
is
> legal. Note, I understand he didn't have a problem with it under SF, but
the
> reality of the matter is that we are in more public view than a SF project
> is. Therefore, it matters more.
>

It's a pity if I have to change the name ... I would of course very much
prefer to keep it. But I can see your point. Let's wait for others to
comment on that.

> p.s. Overall, I'm +0 after the above clarifications...
>
> thanks,
>
> -jon
>

Thanks
And sorry for my mistakes.

Vincent Massol
Creator and donator of J2EEUnit


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