Re: [DRAFT1] Jakarta Newsletter - January 2003

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, robert burr
ell donkin writes:
>(here's some bits and pieces from the commons.)
>
>Jakarta Commons
>===

Although the newsletter is for January, here's another item for
Jakarta Commons from February (Commons committers feel free to
ammend this entry):

Near the end of January, Robert Donkin jumpstarted Commons Net
project by calling for a vote to promote it from the Commons Sandbox
after a flurry of recent interest in releasing the current stable
code base.

http://marc.theaimsgroup.com/?t=10437764903&r=1&w=2

The vote concluded in February, with the minimum number of +1's,
an equal number of +0', and no -0's or -1's.

http://marc.theaimsgroup.com/?t=10443842365&r=1&w=2

The Jakarta Commons Team is pleased to announce that Commons Net
(formerly NetComponents) has been promoted out of the sandbox into
the Commons proper.  Commons Net is best known for its FTP package,
but it also implements a number of other Internet client protocols
such as Finger, Whois, TFTP, Telnet, POP3, NNTP, SMTP, and some
miscellaneous protocols like Time and Echo as well as BSD R command
support.

The first order of business for this Commons Net is to freeze
the code and make a formal release that projects using earlier
incarnations of the code, such as Ant, can migrate to.  After
this first release, further development will continue, adding
new features, performance improvements, a test harness, and a
programming guide to supplement the API documentation.  Anyone
interested in helping out is encouraged to contribute.





msg07141/pgp0.pgp
Description: PGP signature

Re: [DRAFT1] Jakarta Newsletter - January 2003

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, "Daniel F. Savarese
" writes:
>Although the newsletter is for January, here's another item for
>Jakarta Commons from February (Commons committers feel free to
>ammend this entry):

Looks like I made some typing turds.  Here's a corrected version:

Near the end of January, Robert Donkin jumpstarted Commons Net
by calling for a vote to promote it from the Commons Sandbox
after a flurry of interest in releasing the current stable
code base.

http://marc.theaimsgroup.com/?t=10437764903&r=1&w=2

The vote concluded in February, with the minimum number of +1's,
an equal number of +0', and no -0's or -1's.

http://marc.theaimsgroup.com/?t=10443842365&r=1&w=2

The Jakarta Commons Team is pleased to announce that Commons Net
(formerly NetComponents) has been promoted out of the sandbox into
the Commons proper.  Commons Net is best known for its FTP package,
but it also implements a number of other Internet client protocols
such as Finger, Whois, TFTP, Telnet, POP3, NNTP, SMTP, and some
miscellaneous protocols like Time and Echo as well as BSD R command
support.

The first order of business for Commons Net is to freeze
the code and make a formal release that projects using earlier
incarnations of the code, such as Ant, can migrate to.  After
this first release, further development will continue, adding
new features, performance improvements, a test harness, and a
programming guide to supplement the API documentation.  Anyone
interested in helping out is encouraged to contribute.





msg07142/pgp0.pgp
Description: PGP signature

Re: Another unused import statement report is out...

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, Hen
ri Yandell writes:
>Basically. Except it's:
>
>Fred fred = (Fred)doSomething();  in some cases.

Shouldn't you actually do something with the result as a precaution
to ensure the assignment doesn't get optimized out (either by the JIT
or the compiler)?  (Or make sure tests are compiled and run
with no optimizations and no jit with a compiler and jvm with
well-understood behavior.)

In any case, all metrics reports have to be taken with a grain of salt
and interpreted by a human rather than blindly trusted as indications
of errors.  So any general out of the box configuration is not going
to be suitable for all subprojects.  One thing subprojects that rely on
Tom's PMD reports could do is adjust their Gump descriptors (or
just their build files) so that Gump will run PMD using their custom PMD
configuration and generate subproject-specific reports on a daily basis.
But I guess that would require Gump to publish the reports.  Short
of developing a comprehensive opt-in cross-subproject process plan, I
think Gump's a good place to focus this sort of stuff so ad hoc process
additions that require asynchronous recurrent generation of artifacts are
localized in a single place.

daniel



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

Re: Another unused import statement report is out...

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, "Tom Copeland" writes:
>assertTrue("Whoa, doSomething returned a non-Fred type!", doSomething()
>instanceof Fred);

I retract my comment about needing to do something with the variable.
Tom's comment here, in my opinion, is the best approach.

daniel



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

Re: answer to Howard or State of the POI (WAS: Re: Jakarta-POI 1.10.0-dev released)

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, "Andrew C. Oliver" writes:
>Next, I measure the success of it by two other things:  Microsoft's 
...
>Microsoft sort of way) and the final crux will be the day this 
>http://www.tidestone.com/index.jsp goes out of business.  The first clue 

I don't think this is an attitude we want to promote.  Unless I've
been hoodwinked, the purpose of Apache (sub)projects is not to put
companies out of business.  It may be an unfortunate and unintended
side-effect, but not a motivating goal or metric for success.  Your
statement about causing Microsoft (or any other company for that matter)
to start
>flirting with open file formats (I'm sure it will be "open" in that

is much healthier.

daniel



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

Re: "jakarta" name - (?vote?)

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, Vic Cekvenich writes:
>This not a topic that anyone wants to bring up:
>Should jakarta.apache.org be changed to xyz.apache.org?
...
>"Jakarta" name has a a bit of political connotations, some PHB might see 
>as negtaive and has had for about a year now.
>A non city name would be better.

Jakarta has no more political connotations than Apache, or Java, or Axis,
and so on.  You cannot do anything about people reading things into names
that aren't there and you shouldn't cater to or be manipulated by other
people's inability to exercise common sense.  Apache Jakarta is a
well-established/recognized brand and changing the name would be silly. 
A project name, whether it references a geographical location, happens to
have an unintended double meaning (which is the case with more than a couple
of Apache projects), or whatever else, is not an endorsement of
attributes/events/etc. surrounding the intended or unintended reference.
Jakarta is a nice play on the name Java for obvious reasons.  Anyone who
chooses to overinterpret the significance of the name doesn't deserve
to be catered to.

daniel



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

[VOTE] ORO 2.0.8 maintenance release

[Daniel F. Savarese]

I know now may not be the best time to have a vote, but I would ask
the PMC to vote on approving the release of jakarta-oro 2.0.8.
The current code base contains important bug fixes and has gone too
long without a public release.

[ ] +1  I approve the release of jakarta-oro version 2.0.8.
[ ] -1  I do not approve the release of jakarta-oro version 2.0.8.

This vote will last until the end of Saturday 27th, 2003 (72 hours
minus the Christmas holiday).  In accordance with
http://jakarta.apache.org/site/decisions.html, at least three binding
+1 votes are required for this vote to pass and the number of +1 votes
must exceed the number of -1 votes.  Non-PMC members are encouraged
to cast their non-binding votes (please indicate your vote is
non-binding to facilitate vote tabulation).

RELEASE INFORMATION:

The 2.0.8 release will be a maintenance release incorporating the following
changes since the 2.0.7 release made in January (taken from
http://cvs.apache.org/viewcvs/~checkout~/jakarta-oro/CHANGES?content-type=text/plain):

 o examples moved to an examples package and com.oroinc migration tool
   moved to tools package.

 o Fixed bug whereby compiling an expression with
   Perl5Compiler.MULTILINE_MASK wasn't always having the proper effect
   with respect to the matching of $ even though
   Perl5Matcher.setMultiline(true) exhibited the proper behavior.  For
   example, the following input
" aaa bbb \n ccc ddd \n eee fff "
   should produce "bbb ", "ddd ", and "fff " as matches for both the
   patterns "\S+\s*$" and "\S+ *$" when compiled with MULTILINE_MASK.
   Perl5Matcher was only producing the correct matches for the second
   pattern, producing only "fff " as a match for the first pattern
   unless setMultiline(true) had been called.  This has now been fixed.

 o Fixed embarrassing bug whereby an expression like (A)(B)((C)(D))+
   when matched against input like ABCDE would produce matching groups
   of: "A" "B" "" null "D" instead of "A" "B" "CD" "C" "D".

These changes have been available to the public in the CVS repository
for testing since May 2003.  There are no outstanding/unresolved issue
reports for the code.

Daniel Savarese (dfs.apache.org) will serve as the release manager for
this release.  A release announcement will be sent to
{oro-dev,oro-user,[EMAIL PROTECTED]



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

Re: [VOTE] ORO 2.0.8 maintenance release

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, "Daniel F. Savarese
" writes:
>[X] +1  I approve the release of jakarta-oro version 2.0.8.
>[ ] -1  I do not approve the release of jakarta-oro version 2.0.8.

I vote +1.

daniel





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

[RESULT][VOTE] ORO 2.0.8 maintenance release

[Daniel F. Savarese]

The resolution to approve a 2.0.8 maintenance release of jakarta-oro
has passed with 4 binding +1 votes from Jakarta PMC members and no -1
votes.  Many thanks to all who voted.  I will now proceed to package and
upload a release for distribution, update appropriate Web pages, and
email an announcement after 24 hours to give sufficient time for mirrors
to pick up the release.  A summary of the voting results follows:

Binding +1 Votes:

Geir Magnusson Jr  
Craig McClanahan   
Scott Sanders  
Daniel Savarese

Non-Binding +1 Votes:

Gary Gregory(PMC membership pending paperwork)
Mark F. Murphy  (oro user and code contributor)
Takashi Okamoto (oro user and code contributor)



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

Re: [RESULT][VOTE] ORO 2.0.8 maintenance release

[Daniel F. Savarese]

>Now I see it went "just" to general & pmc, because I was following on 
>the informative re-broadcast, so this is the reason why it has not been 
>counted.

No, I screwed up.  I remember counting your vote and verifying "bindingness"
against the committee file, but screwed up and didn't record it because
I was interrupted by something else at the time.

>I think (I seem to recall it used to be done) that VOTEs should specify 
>"where" they should happen.

Yes, I should have done that.  It was okay for the announcement to go
to multiple lists, but I should have specified a list for the casting of
votes.  I'll restate the vote results for the record.

daniel



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

[CORRETION][RESULT][VOTE] ORO 2.0.8 maintenance release

[Daniel F. Savarese]

The original vote tally for this vote was incorrectly listed as 4
+1 binding votes.  There were in fact 5 +1 binding votes.  The
restated results follow:

-
The resolution to approve a 2.0.8 maintenance release of jakarta-oro
has passed with 5 binding +1 votes from Jakarta PMC members and no -1
votes.  Many thanks to all who voted.  I will now proceed to package and
upload a release for distribution, update appropriate Web pages, and
email an announcement after 24 hours to give sufficient time for mirrors
to pick up the release.  A summary of the voting results follows:

Binding +1 Votes:

Santiago Gala  
Geir Magnusson Jr  
Craig McClanahan   
Scott Sanders  
Daniel Savarese

Non-Binding +1 Votes:

Gary Gregory(PMC membership pending paperwork)
Mark F. Murphy  (oro user and code contributor)
Takashi Okamoto (oro user and code contributor)



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

Re: Updating the PMC bylaws

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, robert burr
ell donkin writes:
>that's why i would prefer something more positive. i'd prefer something 
>about mandating the pmc to take action to ensure appropriate 
>supervision when the number of active committers on the pmc falls below 
>three. this could mean something as simple as asking for volunteers 
>(from the pmc) to monitor the sub-project, restructuring the control 
>structure (keeping the code base and infrastructure but eliminating the 
>formal sub-project with all committers gaining karma on request and all 
>decisions passing directly to the pmc), hibernating the sub-project or 
>closing it completely.

Here's the way I see things, using ORO as the running example.  There's
no question ORO has a deficit of committers.  Therefore, all release
votes are now performed by the PMC.  (Technically, the release votes
for allsubprojects are performed by the PMC, but it just so happens
that those PMC members voting are committers for the subproject and the
votes happen on the subproject list.)  I see that as the default stopgap
measure to ensure users can get bug fix release while maintaining
PMC oversight until further corrective measures are taken.  However,
as much as I and others have proposed various solutions to the ORO
committer deficit, we haven't built up the motivation to act on them.
That's where I think something explicit is needed in the bylaws
to force this kind of issue to be resolved, instead of lingering on
the way it has with ORO.  Although I don't like the idea of closing
down subprojects, the threat of it in the absence of some other
resolution may provide the impetus required to avoid a perpetual
status quo.  That's all to say I +1 Robert's preference, but I
don't have anything more specific to suggest than making explicit
the requirement that the PMC takes over release votes for subprojects
with active committer deficits.

daniel



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

Re: SVN of ECS Re: [Jakarta Wiki] Updated: JakartaBoardReport-September2004

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, Henri Yandell writes:
>Well, do we know who would be the one to accept the offer?

I made a dump of jakarta-oro in ~dfs/pub/oro.svn.dump.  I can't do
  svnadmin load --parent-dir jakarta-oro /x1/svn/test < oro.svn.dump
because you need to be in the svnadmin group.  If someone with appropriate
access wants to do the load feel free.  I think it's better to move to
svn sooner rather than later.

daniel



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

Re: SVN of ECS Re: [Jakarta Wiki] Updated: JakartaBoardReport-September2004

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, "Noel J. Bergman" w
rites:
>Done.

Thanks Noel!  I know these things are normally supposed to go through
infrastructure, but I thought I could test it out in the test repository
without troubling anyone first.  Everything looks good and doing the
conversion even helped me detect that at some point I'd checked in
html files for the Web site that had literal character values instead
of character entities like © in them.  I can regenerate those and
check them in the next time there's a release.  At any rate, if Henri
wants a guinea pig, he can send infrastructure a formal request to
convert jakarta-oro over to SVN.  The default cvs2svn values are fine.
e.g.,
  cvs2svn -v --dump-only --dumpfile=oro.svn.dump /home/cvs/jakarta-oro/
  svn mkdir https://svn.apache.org/repos/asf/jakarta/oro/
  svnadmin load --parent-dir jakarta/oro /x1/svn/asf < oro.svn.dump

Why oro instead of ECS?  Only because I jumped the gun with Noel's help
and tested the svn conversion.  ECS can always go next.

daniel



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

Re: CVS->SVN Was: SVN of ECS

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, Henri Yandell writes:
>2
>-
>Going with the example of trunk/tags/branches/site, I'd like to suggest 
>using releases/ rather than tags/. It seems closer to what we mean. Tags 
>does seem more common though, so just a suggestion.
...
>-
>
>jakarta/
>   tomcat/
> trunk/
> releases/
> branches/
> site/

+1

I think it's a good idea to have all the subprojects use the same
structure.  Whether it's tags/ or releases/ doesn't matter to me,
even though sometimes you want to tag things permanently that aren't
a release.  The site/ tree is a good convention to have for the reasons
you put forth.

daniel



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

Re: Dormancy worries

[Daniel F. Savarese]

I'm not a fan of the mothballing concept as I understand its
proposed implementation, but I agree that some process for
officially relegating a project to maintenance mode may be
necessary.  In some sense, projects like oro and regexp have
been victims of their own success.  Both moved into Jakarta at a
relatively feature complete stage and as a result there has been
little demand for making enhancements or following through on
suggested enhancements to the respective code bases.  Given the
widespread use of the software and its inclusion in commercial
products like WebLogic and WebSphere, I think Jakarta's shepherding
of these projects has done a lot of good.

At some point, the Java standards process obviates the need for some
software.  java.util.regex has been influenced by, reinvented, and even
borrowed features from at least oro, if not also regexp.  Even with
J2SE 5, we have seen the addition of a MatchResult interface that is
very much like what has long been in oro.  My first encounter with it
was when it broke the JDK 1.5 Gump build because of class name aliasing.

As more programmers migrate to J2SE 1.4 and 5, I really don't see any
demand growing for oro and regexp.  There are many things that could
be done to continue development of the projects, but is there really
a demand?  I don't see it.

As far as what to do, I don't think the projects need separate
foo-dev and foo-user mailing lists.  But it may be an unnecessary
imposition on infrastructure to merge them into just [EMAIL PROTECTED]  Here's
a spontaneous and ill-thought suggestion.  As a first step we could
have a "Legacy Products" or "Dormant Products" section between
"Products" and "Related" on the Jakarta pages.  We could list dormant
projects under that category.  Then we can solicit volunteers
from the PMC to be committers for each project to ensure that each
has at least three.  Volunteering means you agree to review and
adddress patches and bug reports, vote on releases, etc., but not
necessarily undertake new development initiatives (unless you want
to).  I volunteer to play that role for regexp and I'm pretty sure
Vadim wouldn't have a problem doing so for oro.  That gives us two
committers for each and we'd need a third.  From Noel's comments, it
sounds like rounding up a quorum for BSF should be doable as well.  If
activity on a dormant project increases to the point the PMC volunteers
are no longer needed to maintain 3 active committers, then the project
can move back to the "Products" section.  Otherwise, it stays in a
dormant maintenance mode.  At some point, if it can be established that
a dormant project isn't being used, then I'm okay with the mothballing
concept as I understand it.  I just think there's a transition state.
First we need to ensure oversight (3 PMC members monitoring the project)
and then give the projects a shot at revival.  Anyway, that's just
a spontaneous suggestion I haven't thought through.

With respect to oro and regexp specifically, one of the following
might help even though I don't really expect them to reawaken:
  1. merge oro-dev,regexp-dev,regexp-user,oro-user into just regexp@
  2. or move them into commons
  3. or actually merge the code bases into one and work on a new API
 (I don't see this happening because it's a pointless exercise when
  there's no demand)
Moving into commons is probably the best thing for oro because its
io, util, and text packages have the potential to be incorporated
into other commons components or be reinvented into something more
text processing oriented and less regex oriented.  That's just not
going to happen given the status quo.  Anyway, after the move to
Subversion, moving into commons will be really easy (although
we'll need a URL redirect and the build process will have to switch
to maven).

daniel



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

Re: [VOTE] Release Regexp 1.4

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, Vadim Gritsenko writes:
>and vote for a release.

+1



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

Standard Implementation-Vendor-Id

[Daniel F. Savarese]

Someone submitted a Bugzilla request for an Implementation-Vendor-Id
value to be added to the oro jars (without explaining why they needed
it given that Implementation-Vendor is defined).  I don't think we've
ever specified a standard Implementation-Vendor-Id for Jakarta jar files.
Will the following do:
  Implementation-Vendor-Id: org.apache

Should I add that to:
  http://jakarta.apache.org/site/packageversioning-manifest.template

Or do we just not care about Implementation-Vendor-Id, in which case
I'll close the issue report as WONTFIX?

daniel

-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-
s a v a r e s e  # In distant lands, I hear the call of my home.
   software research # Yet my work is not done.  My journey's just begun.
http://www.savarese.com/ #  -- http://www.sleepandthetraveller.com/


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

Re: Standard Implementation-Vendor-Id

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, robert burrell donkin write
s:
>i've done some hunting round and it appears that now this really should
>be set: implementation-vendor-id is used by later versions of the
>extension mechanism and it no longer works unless it is set. see
>http://java.sun.com/j2se/1.5.0/docs/guide/extensions/versioning.html.

Yep, it looks like that's why they needed it.  This is the additonal
explanation I got today via bugzilla:

 "... actually, we need this (in my company) to specify dependencies in to
  oro in our apps with the Extension-List mechanism. For instance Tomcat
  does not consider that a dependency is resolved if the "extension" we
  depend on does not specify this entry."

After looking at the previous JDK docs, it appears this requirement was
introduced in J2SE 1.3.

>the org.apache looks about right and it'd be great if you could update
>the documentation :)

Okay, I took care of it.  Thanks for the guidance.

daniel


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

Re: [PROPOSAL] Two community proposals

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, Henri Yandell writes:
>1) Remove SVN restrictions, all Jakarta committers can commit anywhere in 
>Jakarta, with the exception of the Commons-Sandbox as it allows Apache 
>committers in general to commit.
>
>2) All vote threads to occur on the general@ mailing list; or the pmc@ 
>mailing list if deemed private.

I'm okay with both suggestions because it maps directly to how I thought
things were supposed to work (i.e., all committers in a project are on
PMC, only PMC members have binding votes for releases, PMC should be
monitoring all releases, and so on).  But I got out of the business of
trying to understand how things are supposed to work at Apache a couple
of years ago :)

daniel

-#-#-#-#-| Sleep and The Traveller |-#-#-#-#-#-#-#- http://www.savarese.org/
In distant lands, I hear the call of my home. # s a v a r e s e
Yet my work is not done.  My journey's just begun.-software research
 -- http://www.sleepandthetraveller.com/  # http://www.savarese.com/


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

Re: Representing project inactivity on the site

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, "Yoav 
Shapira" writes:
>I do care, a lot, as a user.  Active means bugs are getting fixed, the
>mailing lists are a reasonable source for help, and if new standards

I think that's a reason why perhaps a finer gradation than inactive and
active may be in order.  For example, if any new/real bug is reported
to ORO, it will get fixed in short order.  If any enhancement that
includes a patch is submitted, it will be reviewed and applied or
rejected with a critique in short order.  However, if an enhancement
request is made with no willingness on the part of the submitter to
help implement the enhancement, my guess is it will not be implemented
unless it's not particularly time-consuming.  I see the spectrum more
as Active, Maintenance Mode, and Inactive, with subprojects like ORO and
Regexp being in Maintenance Mode.  But if the difference boils down to
semantic perception, then as long as the meaning of Active vs. Inactive
is explained to the site visitor, I'm not going to quibble because a
project like ORO definitely falls into the category of "no new features
are planned for this product."

daniel

-#-#-#-#-| Sleep and The Traveller |-#-#-#-#-#-#-#- http://www.savarese.org/
In distant lands, I hear the call of my home. # s a v a r e s e
Yet my work is not done.  My journey's just begun.-software research
 -- http://www.sleepandthetraveller.com/  # http://www.savarese.com/


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

Re: Representing project inactivity on the site

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, Henri Yandell writes:
>Active Development
>Maintenance Mode
>Unsupported

I think you nailed it.  Active, Supported, and Unsupported.  Or
Active, Inactive (Supported), and Inactive (Unsupported).  Anyway,
whatever the specific names end up being, that's the gist of it.

daniel

-#-#-#-#-| Sleep and The Traveller |-#-#-#-#-#-#-#- http://www.savarese.org/
In distant lands, I hear the call of my home. # s a v a r e s e
Yet my work is not done.  My journey's just begun.-software research
 -- http://www.sleepandthetraveller.com/  # http://www.savarese.com/


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

Re: [VOTE] Remove SVN restrictions

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, Henri Yandell writes:
>Vote to remove the SVN barriers within Jakarta such that all jakarta-* 
>groups are merged into the one jakarta group with the exception of 
>jakarta-hivemind, jakarta-slide, jakarta-cactus and jakarta-jmeter under 
>the assumption that they are moving to having their own PMCs. Tapestry is 
>already within its own auth group.

[X] +1

-#-#-#-#-| Sleep and The Traveller |-#-#-#-#-#-#-#- http://www.savarese.org/
In distant lands, I hear the call of my home. # s a v a r e s e
Yet my work is not done.  My journey's just begun.-software research
 -- http://www.sleepandthetraveller.com/  # http://www.savarese.com/


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

Tracking Jakarta Software Dependencies

[Daniel F. Savarese]

Hi All,

I and other Jakarta committers received an email today from a
developer at Wachovia pointing out how difficult it is to discover
library and JDK dependencies for Jakarta subprojects as a whole,
even though his main focus was Commons.  I couldn't really dispute
his observation upon trying to find dependency information for a
couple of software releases.  Would it be useful to start a Wiki
page containing a table where after each software release, we list
the library and JDK dependencies/compatibility for the release?
Or would it be better to simply agree on a common place in each
subproject's Web page hierarchy to list that information?
Interest for easy access to this information appears to be coming
from corporate developers using older JDK versions who are having
a hard time figuring out what's compatible with what.

daniel


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

Re: Tracking Jakarta Software Dependencies

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, "Yoav 
Shapira" writes:
>(e.g. build.properties).  I'm hesitant to have a separate web page
>just to list dependencies unless that page is auto-generated (as is

I agree.  I'm sure there's a way to autogenerate a master table for
all the mavenized projects, but since I'm not volunteering to do it,
I'm not going to suggest it.  I haven't seen anyone listing their JDK
requirements in the maven dependency report.  Could we then just ask
mavenized projects to add their minimum JDK requirement to the dependencies
report (I've never tried entering a 'fake' entry and ant projects
to add the info to their docs if they don't already have it?

These situations are always weird for me since I'm not the one
experiencing the actual issue, yet have been asked to raise it.
However, I think it's a reasonable reminder that despite all the
progress Jakarta has made, users still have problems navigating
our documentation.

daniel


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

Re: Tracking Jakarta Software Dependencies

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, =?ISO-8859-1?Q?Ortwin_Gl=FCck?= writes:
>JDK version: what a mess. IMHO this is THE information that is missing
>on almost ANY project page out there.

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

I'm sorry if I caused a rehash of a discussion that had already been
resolved earlier in the year.  It's actually made me realize that I list
JDK requirements in the README for some non-Jakarta software I've released,
but I don't make the README available on the Web page, so you don't know
the requirements until you download and unarchive the source code.  There's
always some little detail that goes unattended...

daniel


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

Re: Checking in jars - an update

[Daniel F. Savarese]

I follow the digest, so by the time I read the list a thread has pretty
much reached conclusion.  But I've never seen this discussed before and
it's something I've had questions about.  As a general rule, I think
you should never check in libraries (i.e., jars) upon which a revision
controlled module is dependent.  That is, I don't believe they should be
checked in with the source.  The configuration management of dependent
libraries is tracked separately, matching source versions to library
versions.  I don't know that Jakarta has any conventions for doing this.
Are there any in the works?  I'm not familiar with Gump.  Where can I find
it?  Finally, what's the right way to deal with Ant?
 1. should we assume someone has Ant installed already the way the use
of Makefiles assumes you've already got make
 2. should we include the ant jar in CVS so that anoncvs users can build
immediately even if they don't have Ant installed
 3. should we leave the ant jar out of CVS, assuming that someone doing
a checkout has it installed, but package it with releases so a user
doesn't have to download ant separately to build the source

I'm thinking 3 makes the most sense, but I'd like to know what the official
convention is before removing ant.jar from the jakarta-oro source tree.
Having that jar in there has always bothered me since it gets "stale."

>Checking in generated code (java, html, etc.) is still something I am
>working to eliminate.

That's another good general rule.  Anything that's generated
should not be revision controlled as it is derived from existing
revision controlled units (e.g., you check in YACC grammars, not the
generated parser).

>P.S.  I still maintain that CJAN is unworkable until there is some level of
>version-to-version compatibility observed by the various projects.

Ditto.

Your message said [moving from library-dev].  I don't see that mailing list
advertised on the web site.  What's its purpose and does one subscribe via
the usual listname-subscribe mechanism?

daniel



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

Re: general Digest 12 Apr 2001 19:55:17 -0000 Issue 349

[Daniel F. Savarese]

>The two somewhat workable times are 1200 GMT and 2000 GMT.  I'd like to
>hear opinions on the following two options:

Sorry for the belated reply -- digest mode and 16 hour work days.
Either time will work for me (I'm on EDT, which appears to get the
best deal).

daniel




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

bug report handling

[Daniel F. Savarese]

Please ignore the who part of my previous email as has been kindly pointed
out to me I should have just used the "view bug activity" option.  However,
the "spurious changing of bug status" part of my email holds.  Can just
anyone change a bug's status?  If so, that's a problem that we need to
fix.  I don't appreciate the spurious changing of the status of bugs,
especially when they are incorrectly modified.  In this case, the original
reporter of the bug went in and changed the status of the bug without
heeding the bug resolution comment.  The procedure I would recommend
is that anyone can report a bug, but once reported, only the committers
(or whomever is responsible for investigating and resolving the report)
associated with that project may alter the status of the bug (and that
all status changes require supplemental comments).  I believe this is
supported by bugzilla, but perhaps nagoya hasn't been configured this
way.  Thoughts?

daniel



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

Re: bug report handling

[Daniel F. Savarese]

>especially when they are incorrectly modified.  In this case, the original
>reporter of the bug went in and changed the status of the bug without
>heeding the bug resolution comment.  The procedure I would recommend

Ok, I keep on putting my foot in my mouth.  Get a little free time and
see what happens ...  Ok, my understanding now is that VERIFIED does
not mean that the bug report has been verified.  It means that the
RESOLUTION of the bug has been verified.  So, in this case, the reporter
of the bug saw the resolution (which indicated the bug was invalid because
there were no capturing parentheses in the regular expression) and verified
that it was correct.  So that was fine, except there was no comment added
to that effect.  I still stick to my immediately previous recommendation.
Apologies to all affected by my rather hasty reactions.

daniel




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

Re: [Bug 1346] Changed - substitue gives strange result

[Daniel F. Savarese]

Sorry for hitting three lists, but it's the only way to root out the
culprit.

Who changed the status of this bug (the one at the end of this message)
to VERIFIED?  Why weren't any comments added?  Unless someone points out
the capturing parentheses in the expression (all appear to be non-capturing)
and addresses my previous comment about the alleged bug and the behavior of
Perl 5.003 capturing parentheses, I am going to change the status back to
RESOLVED and INVALID.  You can't just change the status of a bug without
providing any explanation whatsoever.

First, confirm that there are some capturing parentheses
and point them out.  I can't find any, but the expression is so long maybe
I missed something, but I did in fact use a regular expression to search
for a non-capturing open parenthesis in the expression and could not find one.
Second confirm that the behavior of the substitution is different from that
of Perl 5.003 (not 5.004, 5.005, 5.6 or anything else).  Finally, if there
really is a discrepancy, change the status to verified and provide a full
explanation.  Otherwise there is NO way whatsoever to try to fix the problem
if it is a problem.

Also, is just anyone allowed to change the status of bug reports or
just committers?  Bug tracking is useless if the bug handlers don't
follow reasonable procedures.  Right now someone has changed a bug
from Status: RESOLVED Resolution: INVALID to Status: VERFIFIED
Resolution: INVALID.  At the very least, if you're not going to add
comments put the bug in a state that makes sense.  How can a bug be
both VERIFIED and INVALID?

If you're reading this and you changed the status of this bug please
go back and do the things I suggested and then change the status of
the bug report appropriately and add some helpful comments.  Also,
don't take my crankiness personally.  You'll surely get a chance to
reprimand me about something in the future.

Before I quiet down, I move that no bug report shall have its status
changed without a comment, just as no code change should be committed 
without a log message.

daniel

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1346

*** shadow/1346 Wed Apr 18 14:25:16 2001
--- shadow/1346.tmp.6409Wed Apr 25 14:28:48 2001
***
*** 2,8 
  | substitue gives strange result 
|
  +
+
  |Bug #: 1346Product: ORO 
|
! |   Status: RESOLVEDVersion: 2.0.2   
|
  |   Resolution: INVALIDPlatform: PC  
|
  | Severity: Normal   OS/Version: Linux   
|
  | Priority: High  Component: Main
|
--- 2,8 
  | substitue gives strange result 
|
  +
+
  |Bug #: 1346Product: ORO 
|
! |   Status: VERIFIEDVersion: 2.0.2   
|
  |   Resolution: INVALIDPlatform: PC  
|
  | Severity: Normal   OS/Version: Linux   
|
  | Priority: High  Component: Main
|




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

Re: Proposed dirlayout document

[Daniel F. Savarese]

>IMHO, the intermediate build directory can and should be avoided. Instead of s
>electively copying from the intermediate build/ directory to dist/, one can ge
>nerate directly to dist/ and use tar/zip selectively to create the distributio
>n. The latter solution keeps just one copy of files which saves space. More im
>portantly the latter is less error-prone as there is only one place to edit fi
>les. Does that make sense? Ceki

It's pretty normal to do this kind of a thing.
The distribution is meant for outside consumption and is automatically
generated by the configuration management system (in this case ant),
so you never directly modify it.  Therefore it shouldn't be any more
error-prone.  The build tree is meant for internal consumption and can
contain a significantly different layout, containing all sorts of stuff
such as infrastructure for quality assurance that never makes it into the
distribution, but is generally tailored for facilitating development and
testing.

I think the reason this whole thing is a bit muddled is because we're
mostly producing development software, where the line between consumer
and producer is blurred.  Also, being open source, with an emphasis
on open, there's less of an impetus to hide development artifacts
from the consumer.  At any rate, I think there's a clear need for
allowing a development build tree separate from the distribution tree.
Projects primarily constituted of development libraries probably won't
make use of it, but others consisting of one or more applications,
probably will.

daniel



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

Re: [proposal] Jakarta Deprecation Policy

[Daniel F. Savarese]

>What I propose is that we take this document (or one similar to it) and
>migrate it up to the overall Jakarta Project instead of just being a Turbine
>policy and get all the projects to "sign" their name on it.
>
>

+1

>Comments?

Nothing controversial in the document.  The time thing or whether removal
should coincide with minor or major version numbers (e.g., 2.1 to 2.2
instead of 2.1 to 2.1.1) should be as flexible as stated in the document
because it is both dependent on the nature of the project and its stage.
For example, projects in their early stages or in a revamping mode may 
very well be deprecating things left and right and require an accelerated
removal schedule.  Older more stable projects will probably opt for a slower
removal schedule.

daniel



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

Re: Hosting FAQs on jGuru +1

[Daniel F. Savarese]

>>>from the forum to the FAQ (our standard system).  We will need a
>>>participating project to provide a manager.  It should require about
>>1-3hrs
>>>a week from the manager (depending on how busy the Forum/FAQ is).  Is

-1

Reasons:
  o The FAQs at jGuru are mostly AQs and are not adequately subcategorized
within a category.  Keyword searching is not as useful as a
well-organized table of contents.
  o I'm not donating 1-3 hours a week of my time to help
jGuru/MageLang's advertising revenue.  I've done this type of Q&A work
in the past and I'm not doing it again.  You wade through thousands
of questions, most of which are repeats of previously asked questions
because the questioners never bother to search all of the already
answered questions (mostly because keyword searching isn't very useful).
It turns into a major time sink if you care about doing the job right.
  o jGuru forums bypass and possibly defeat jakarta user mailing lists.
  o The best FAQs are works of writing and not hasty online Q&A's.

There's a counterargument to or opposite view for each of my reasons, but
they represent my opinion.  At the very least, if the vote approves going
with jGuru, I would advocate requiring that we be able to generate an HTML
file cosolidating the complete FAQ list for a project so that it may be
distributed with a release.  I shouldn't have to be online to get access
to a FAQ for software I've installed.  My preference is for questions to
be culled from mailing lists and that a FAQ be maintained as a written
document along with the project documentation in CVS.  Online Q&A systems
tend to rot (you have to poll them to answer questions) and yield low-quality
results (entropy sets in quickly) because they are not tightly coupled to
the development process.

daniel



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

site/bindindex.xml

[Daniel F. Savarese]

http://jakarta.apache.org/site/mail2.html
made it seem like [EMAIL PROTECTED] was the right place to send
this request but
http://jakarta.apache.org/site/jakarta-site2.html
indicates general is the right place.  At any rate:

--- Forwarded Message

To: [EMAIL PROTECTED]
Subject: site/binindex.xml patch
Mime-Version: 1.0
Content-Type: multipart/mixed ;
boundary="==_Exmh_14427391380"
Date: Wed, 23 May 2001 00:41:33 -0400
From: "Daniel F. Savarese" <[EMAIL PROTECTED]>
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

Hi,

Could someone please either apply this patch to site/binindex.xml or
add me to the committer list for jakarta-site2?  I just released
a new jakarta-oro version and wanted to update any affected links
on the main site.

thanks,
daniel

--- End of Forwarded Message




Index: binindex.xml
===
RCS file: /home/cvs/jakarta-site2/xdocs/site/binindex.xml,v
retrieving revision 1.47
diff -u -r1.47 binindex.xml
--- binindex.xml2001/05/20 15:10:21 1.47
+++ binindex.xml2001/05/23 04:34:28
@@ -70,7 +70,7 @@
 James 1.2.1
 JMeter 1.5
 Log4j 1.1.1
-ORO 2.0.2
+ORO 2.0.3
 Regexp 1.2
 Tomcat 3.1.1
 Tomcat 3.2.1



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

Re: [Lucene-dev] jakarta (fwd)

[Daniel F. Savarese]

>Is the rest of the PMC interested in seeing this happen? (I am and will
>be the PMC sponsor).

+1

So when do we start using it on the jakarta site? :)

daniel



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

Re: What are we doing in regards to JDK 1.4?

[Daniel F. Savarese]

>I've been playing with regex along with the nio classes and I must say that 
>they integrate with each other extremely well. You must try out some of the 
>new api's to fully appreciate the performance gains you will get from their 
>new SocketChannel/ByteBuffer approach to networking. The regex code will 
>parse through an existing buffer which could be a direct memory map from an 
>io device. I don't think there would be any way to do that level of 
>integration without rewriting lots of native code.

The java.util.regex package is completely orthogonal to the nio stuff and
reading input from a CharSequence doesn't qualify as integration.  Any
third-party package could do the same.  The nio stuff was sorely needed
and we shouldn't have had to wait for over 5 years for Java to be able to
do decent I/O.  The regex stuff has serious problems from both a
performance and API design perspective and had no business being thrown
in as an afterthought with JSR-51.

Regular expression and logging have no business being in the core anyway.
The story of Java is one of getting the APIs wrong and having to fix them
in a later release, throwing in unnecessary classes and packages,
retrofitting the language to make up for obvious oversights, and flat out
ignoring the lessons learned during the standardization process of languages
that came before, such as C++.  Guy Steele's OOPSLA 98 keynote is a model
of how Java should have evolved but clearly hasn't:
http://www.cs.bell-labs.com/who/wadler/pizza/gj/Documents/steele-oopsla98.pdf
A couple of years ago, Rick Ross wrote an editorial about the problem of
Sun putting Java companies out of business by putting the functionality
of their products into the Java core ("Tools Before Jewels", Java Developer's
Journal, April 1999 http://www.sys-con.com/java/archives/subscribe/0404/)
It mistakenly implied my old company went out of business because of Sun
(it didn't), but visits the same issue brought up about JDK 1.4 and some
of its new APIs.  This is a problem that's been with us for a while
and is not going away.

Anyway, my comments have strayed off-topic.  All we can do is keep writing
code as usual and hammer Sun with constructive criticism when they go astray
in the hopes they'll listen.  Yes, some of our projects will lose a certain
amount of following because their functionality is duplicated in JDK 1.4,
but they won't die.  For two years I didn't update the software that
became jakarta-oro, yet its following grew even though there were actively
maintained alternative products.  If you provide something that programmers
need and want that others don't, programmers will use your software and
stick with you.  log4j and jakarta-oro are distinguished by their
performance, feature set, and flexibility of their designs.
It's unfortunate that the JCP is leading to the unnecessary bloat of the
Java core by introducing functionality that is already provided by
numerous third-parties, but Jakarta will survive if we focus on quality
and the advantages of an open source development model.  As Jon
pointed out, you can get bugs fixed quickly, have your changes introduced,
and directly influence the development of the software.  Jakarta
evolves more rapidly and is much more responsive to developer needs.

No worries here.

daniel



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

Re: Proposal to make BSF an ASF project

[Daniel F. Savarese]

>"Pier P. Fumagalli" wrote:
>> 
>> Sam Ruby at [EMAIL PROTECTED] wrote:
>> 
>> > Craig R. McClanahan wrote:
>> >>
>> >> +1 for BSF as a Jakarta project.
>> >
>> > Ditto.
>> 
>> Doh :) +1
>> 
>> Pier
>
>Re me
>
>+1
>
>geir

+1



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

Re: Helma XML-RPC @ Jakarta

[Daniel F. Savarese]

>> [  ]Jon Stevens
>
>-0
>
>It seems like xml.apache.org should be the place, but I really don't care
>where it lives that much cause we can always move projects around if we need
>to. I do think that if it goes to xml.apache.org it should be a top level
>project.

I feel about the same.  xml.apache.org seems the logical place for it,
but I understand some of the motivation to place it in jakarta.

[ 0] Daniel Savarese



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

Re: Reply-to munging

[Daniel F. Savarese]

>Can we turn off the munging of headers that is currently adding Reply-to on 
>all the jakarta lists?
>
>Please read
>   http://www.unicom.com/pw/reply-to-harmful.html
>before asking why it's a problem.

It was only a matter of time before this came up as it always does on
mailing lists.  The point of the Jakarta mailing lists is to build
community and keep discussions in the open.  For some mailing lists
it is appropriate to not have the reply-to header point to the list,
for others it is.  For the Jakarta mailing lists it is.  My vote on
the proposal is:

-1

daniel



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

Re: Reply-to munging

[Daniel F. Savarese]

>HELL YES!
>
>That essay conveys *exactly* what I was thinking. I love it. Thanks for the
>link. I'm saving that one forever.

Me too.  It did a great job of capturing the vacuous nature of each
argument in the original essay.  I took the liberty of adding a neutral
statement with links to both essays in the
   Summary: Watch where you are sending email.
guideline on:
   http://jakarta.apache.org/site/mail.html
in the hope it might prevent this from coming up again.

daniel



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

Re: jakarta-site2 process changes needed (heads up)

[Daniel F. Savarese]

In message , "Craig R. McCl
anahan" writes:
>doesn't happen again, and also update the permissions to add group write
>on the following files:
...
>  mail.html (dfs owner)

Fixed.  Sorry.  I'm usually pretty meticulous about permissions.

daniel



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

Re: Contact info...

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, "Pier P. Fumagalli" writes:
>Trying to send mail to Daniel F. Savarese <[EMAIL PROTECTED]>, but all I get
>are bounces... Anyone has different contact info?

Send it to dfs at apache.org and it will forward to me.  I'm overly aggressive
about blocking mail from relays that have sent me spam and may have blocked
your relay.  Any idea what relay you're going through so I can unblock it?

daniel




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

Scope

[Daniel F. Savarese]

I'm a loss to understand the problem.  People assert that projects are
out of scope yet also assert how much they like them.  Is it not better
to generate good code that lots of people use than to nitpick about
staying in scope?  If Jakarta is home to a bunch of projects that people
think are crap then that's a problem.  The ability to manage the collection
of projects and whether projects meet a high standard of quality is much
more of an issue than whether projects are in scope.  If it becomes too
difficult to manage the collection of projects, then we split off another
Apache subproject.

I can see that duplication can be a problem.  For example, jakarta-oro
and regexp overlap in the functionality they provide.  The groups have
already discussed this and agreed on an integration plan.  Identify a
problem, discuss possible solutions, come to an agreement, and execute
on it.  Failing to do that is a problem, so if this scope thing is really
a problem, let's take the next step and discuss possible solutions
(refer me to the archives if it's already been done).

Poll a set of server-side Java developers and you'll probably find that
most of them will tell you that regular expressions, logging, and efficient
build systems are all essential to their server side development projects.
(I base that prediction on empirical evidence I've gathered over time
supporting it for the first two items).  Yes, these things are more general
in nature.  Is it time to spawn off a new Java-oriented Apache subproject?
What is the motivating factor?  A subjective view of what's in scope and
out of scope, or the more concrete issues of project management and
product quality?  I'd honestly like to understand the views of the project
members a lot better.  I have companies breathing down my neck about why I
haven't open sourced NetComponents yet.  Aside from recently resolved time
availability issues, I'm reluctant to revisit the possibility of releasing it 
through Jakarta, as original suggested by Jon, because, unlike the projects
mentioned so far, it is unambiguously out of scope, being a set of _client_
libraries for IETF protocols.

In any case, Java developers are starting to look at Jakarta as a
supplier of de facto standard Java class libraries that provide an
alternative to waiting for things they need to show up through the Sun
Community Process.  If this is not a good thing for Jakarta, then
should we start a project which assumes that role?  I don't know
the answer because I think things are working pretty well right now.
Talking about scope is not very useful (to me at least) unless you
address the consequences of being out of scope.  Please help me
understand the consequences.  If there's a real problem here, I'd 
like to solve it sooner rather than later.  If it's time for a split
of some kind, or if the time is approaching, let's analyze the situation
and take care of it proactively.

daniel



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

Re: Scope

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, "Sam Ruby
" writes:
>Duplication (e.g., multiple templating technologies) doesn't bother me so
>much as different focus.
>
>An RDB is a big endeavor.

I'm sorry, I didn't indicate that I wasn't addressing the RDB proposal,
but rather the ancillary comments about Ant, James, Log4J, Regexp, and
"other projects" being out of scope.  My personal opinion about an RDB,
is "why do you need yet another one, much less one in Java?"  I don't
see the point and would leave it to others to enlighten me.  Please don't
though.  I stayed out of the RDB discussion because I didn't have anything
useful to offer being of the "what's wrong with PostgresSQL if you can't
afford Oracle, DB2, or SQL Server?" mindset, as well as the Java is not
well-suited to building relational databases mindset.  Again, that's not
meant to start a debate.  Keep the "scope" thread to articulating the
consequences, adverse and benign, of being "out of scope."  Sam has
indirectly pointed out that there are different degrees.

daniel



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

Summary (was Re: Scope)

[Daniel F. Savarese]

I don't know how useful this thread has been to everyone else, but it's
been helpful to me because I was starting to feel I misunderstood
the spirit of the Jakarta project.

I think it might be useful to add these extracts from the thread
as addenda to "Creation of subprojects" on 
  http://jakarta.apache.org/site/management.html
They coincide with what I had understood to be guidelines and
would have relieved my doubts, and presumably those of any future PMC
members.

o We're not a software repository, we're here to host communities
  of developers, communities working in our way.

o Don't go chasing projects; let them come to us.

o Projects must have a community that can be supported by an
  Apache meritocracy.

o At any time, the majority of committers of a code base may vote
  to remove their project from Jakarta.

o Projects should be compatible with the Jakarta mission
  (http://jakarta.apache.org/site/mission.html), but not to the point
  that a strictly literal interpretation of "server solutions" excludes
  projects that meet the criteria of utility, community, and quality.

At any rate, since I've gotten chatty all of a sudden, it must
mean I have some time on my hands, so I think I'll return to a
"less talk, more coding" mode.  

daniel



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

Re: Summary (was Re: Scope)

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, Ted Husted writes:
>And, oops, I just realized that I never promoted the working draft of
>the guidelines 
>
>< http://jakarta.apache.org/site/proposal.html >
>
>to the top level of the site. Assuming that's still OK, I'll go ahead
>and do that.
>
>Perhaps I should also add the above as a "preamble" to clarify what we
>are really suppose to be doing here -- developing open source software
>the Apache way. 

Great!  I had already forgotten about the proposed guidelines document.
I think the preamble would be a good addition.

>I don't know if that's exactly true. Anyone can go off and start a new
>codebase based on any Apache product, but they are suppose to use a new
>name and their own copyright. An active codebase exists whereever people
...
>improve it, but the brand belongs to Apache. Once the brand is donated,
>I don't think the donation is revockable by anyone except the ASF. 

I'm sure you're right.  At any rate, I think making proposal.html more
visible takes care of the additional clarity I was looking for.  It
captures the conclusions of previous discussions and provides a framework
for recording the conclusions of future discussions.

daniel



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

Re: [OT] FW: Sun Headquarter Briefings: Developing Web Services

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, Jon Stevens writes:
>Can someone explain to me what the heck "web services" are so that I can
>decide whether or not this is even worthwhile to learn about?

Right now it's mostly vapor, at least on the Sun ONE end of things.
Too many of the Java APIs related to Web services are still making their
way through the JCP (JAXB, JAXM, JAXR, JAX-RPC, Java APIs for WSDL)
and several of the XML standards are still in flux (SOAP is now part of
the W3C XML Protocol Activity and WSDL is only a W3C Note).  Furthermore,
every whitepaper seems to define web services slightly differently.
Apparently though, if you pump in XML to a server via HTTP and get XML
back, it's a Web service.

daniel






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

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

[Daniel F. Savarese]

+1

daniel



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

Re: [PROPOSAL] New Project Creation Guidelines

[Daniel F. Savarese]

+1 

daniel



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

Re: New jar dependency for Cactus

[Daniel F. Savarese]

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.

daniel



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

Re: [Vote] BCEL @ Jakarta

[Daniel F. Savarese]

I finally caught up on the whole BCEL thread.

+1

daniel



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

Re: ASPizer

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, Ceki Gulcu writes:
>Coming back to the issue at hand, if ASPizer authors are truly
>committed to open source and the Apache model, they should counter
>Jon's remarks and justify the reasons why their product should be part
>of Jakarta.
...
>I did not read anyone but Jon take
>the time challenge the inconsistencies in the proposal. We can all sit
>back and criticize Jon's style. In the mean time, somebody has to get
>the job done and it's often Jon. 

I just wanted to echo Ceki's above statements which capture the two
issues beating around (project acceptance and Jon's critique).  Any
project proposal must overcome the criticisms leveled against it in
order to be accepted.  The debate can get seemingly ugly, but it's
a necessary filter to keep Jakarta on track.  Also, while some of us (I'm
thinking of myself in this instance) think "I don't have the time to write
a lengthy diplomatic criticism." and procrastinate on addressing an issue,
Jon takes the time out of his busy schedule and very efficiently summarizes
the issues in a couple of sentences (which is sometimes unfortunately taken
as tactless or even offensive rather than brief and to the point).  I've
lost track if we've brought this to a vote or not, but unless Jon's points
are adequately addressed, I have to cast a vote of -1 on accepting the
proposal.

daniel



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

Re: Just the JARs

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, Ted Husted writes:
>The license issue is well taken. I think it would be a good practice for
>us to include a license in all of our JARs. Even when we don't
>distribute them seperately ourselves, they are intended to be
>distributed seperately by our licensees. Point noted.

+1





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

Re: [PROPOSAL] Jakarta PMC bylaws change

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, "Sam Ruby
" writes:
>The number of PMC seats will be set at seven.  Annually, all seven seats
>will be up for renewal.  The ASF board will be asked to provide a person or
>persons to administer the nominations and a subsequent ballot. The
>administrator(s) will determine the mechanics of the voting procedures.
>Any committer to any Jakarta code base will be eligible to vote.  Once the
>new PMC is in place, the first order of business will be to determine a
>chairperson from amongst their ranks.
>
>Once ratified, this proposal would be effective immediately, and an
>election would be initiated.

+1



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

Re: [PROPOSAL] POI @ Jakarta

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, "Andrew C. 
Oliver" writes:
>Proposal for "POI" - A Jakarta Subproject 
>version 1.0 - 17 Jan 2002 
...

+1



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

Re: Jakarta ORO NetComponents or some other Java FTP API?

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] 
writes:
>I'm trying to get in touch with the Jakarta PMC to find out what the status is
>of accepting Daniel Savarese's ORO NetComponents to be part of Jakarta. Also,

No proposal has been made.  As I indicated on my web site, before making
any proposal there has to be a clear development community that is willing
to continue to maintain, support, and further develop the software.  Now
that the source is LGPL'ed, anyone is free to go forward with a proposal
and I'll give the ok to switch the license terms.  I've tried to put the
onus on the NetComponents user community to take control and decide what
it wants to do with the software.  Jakarta is rather full of projects and
I wasn't going to initiate a proposal for yet another project if it wasn't
clear that there was a strong committed development community.  However,
there are several alternatives to proposing a new project.  There's the
Commons (or commons-sandbox) and it's also possible to expand the scope
of jakarta-oro, which may or may not make sense.  At any rate, as I
indicated somewhere, I don't have any vested interested in dedicating much
time to NetComponents because I don't use it and would redesign and
rewrite it if I did.  There appear to still be a lot of people using
NetComponents based on the thousands of monthly downloads of the software, 
so if you, Winston Ojeda, and friends can organize them, then you can
decide if SourceForge is the right thing, a Jakarta proposal, or a merging
with an existing subproject.

daniel



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

Re: Jakarta ORO NetComponents or some other Java FTP API?

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, "Daniel F. Savares
e" writes:
>time to NetComponents because I don't use it and would redesign and
>rewrite it if I did.  There appear to still be a lot of people using

Rather, I don't use it much because of the types of projects I work on
these days.  Didn't mean to imply I used something else for the stuff
NetComponents does.  At any rate, I think I explained the status more
fully under the "What about NetComponents 2.0?" section of
http://www.savarese.org/java/

daniel





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

Re: ApacheForge

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, Paul Hammant writes:
>I like the idea of a seperate, but endorsed ApacheForge site.  It would 
>give i) Encouragement ii) Independance but also iii) Community.  I think 
>it is a good and safe solution to what I think is the catch-22 situation 
>of trying to get a project hosted at Apache.

-1

I'm not going to rebut every one of your points, but I will offer that
running such a site would incur major monetary and temporal costs.  Are
you going to contribute the necessary resources?

daniel



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

Re: POI web update

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, "Andrew C.
 Oliver" writes:
>Hi, We've committed a number of changes to the POI site.  If someone
>with requisite karma could apply this on the http server we'd appreciate
>it.

I just did a cvs update in /www/jakarta.apache.org/poi on daedalus.  A
bunch of the files were owned by remm with 644 for permissions, but the
directories were 775, so I was able to overwrite the files.  Remy may want
to change his umask to 002 to avoid potential update problems.

daniel





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

Re: jakarta-site2 update (please)

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, "Andrew C. 
Oliver" writes:
>Announced new POI pre-release.. . please update site-2 -- thanks

done





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

[OT] JCP rant

[Daniel F. Savarese]

Somebody asked on the axi-user mailing list why they should use Axis
instead of JAXM.  I offered some comments, but tried not to stray
too off topic.  In light of a recent JCP-related thread, I thought
there might not be any objections on general@jakarta if I vented for
a minute.

When you use JAXM, you'll run up against all sorts of limitations and
the best you can do is send a suggestion/comment to an email address.
With Axis, or any Apache project, if you run up against a limitation,
you can discuss it on a mailing list and submit a patch.  
Hypothesis: JCP JSRs that have more frequent feedback iteration cycles and
provide source code tend to produce better results than those with fewer
feedback cycles.  I'll use JAXM and JAX-RPC as examples.  JAXM
had no mailing list for developer discussion/feedback as it was being
designed/developed with only the usual JCP JSR comment address.  JAX-RPC
has a jaxrpc-interest mailing list that has helped the spec evolve into
something more likely to be useful to developers.  With something as
simple as a mailing list a JCP JSR can gather much better requirements.
However, neither JSR provided source for their reference implementations,
making debugging and patch submission an impossibility.

The problem with the JCP is not merely the licensing.  It is also the
basic JSR procedures.  The objective of a new API is to meet some set
of developer requirements in a particular application domain.  If you
don't consult with your users, the target developer group, you probably
won't develop a useful result.  JSRs would produce better results if run a
little more like Apache projects, with more opportunity for user feedback
in an open forum to mold the ultimate result into something useful.

daniel



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

JCP Program Chair responds to Apache Software Foundation (fwd)

[Daniel F. Savarese]

Hot off the press:

--- Forwarded Message
From: Harold Ogle <[EMAIL PROTECTED]>
Subject:  JCP Program Chair responds to Apache Software Foundation
To: [EMAIL PROTECTED]

JCP Program Chair responds to Apache Software Foundation:

The Apache Software Foundation published a position statement summarizing its
concerns on the work in process to revise the JSPA. Sun is proposing changes to
the JSPA draft so that all of Apache's requirements are satisfied.  To find out
how this is or will be made so, both in letter and in spirit:

http://jcp.org/aboutJava/communityprocess/announce/LetterofIntent.html

===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JCP-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

--- End of Forwarded Message




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

Re: Did somebody update the Jakarta site directly?

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]
bm.com>, "Sam Ruby" writes:
>http://www.apache.org/~rubys/updatesite.log4
>
>Note the mod to 'whoweare.html" and the errors in poi...

I did a fresh checkout of jakarta-site2 and edited xdocs/whoweare.xml last
night, did the usual build docs/whoweare.html, and checked in both
xdocs/site/whoweare.xml and docs/site/whoweare.html.  Then I did a cvs
update of whoweare.html on the web site.  I did notice an M and a "merging
differences" message.  I think it said "merging differences between revision
1.84 and 1.86.  So someone must have edited it directly after 1.84, but
before 1.85, since Remy checked in revision 1.85 shortly before me.  At
any rate, a diff between rev 1.86 and what's on the site says
whoever edited it directly added:

http://jakarta.apache.org/site/overview.html";>Overview
 

In any case, sorry the merge didn't register with me last night and I wasn't
the one asking your question.  Brain was too fuzzy from watching recorded
JavaOne keynotes.

daniel



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

Re: News Page Problems

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, Kur
t Schrader writes:
>It seems that whomever updated http://jakarta.apache.org/site/news.html
>last somehow managed to generate it in such a way so that it has two
>menus, instead of just one.  The jakarta-site2 build from CVS appears to
>work correctly though, so someone with karma probably just needs to
>rebuild and update the site.

When I tried to update news.html I got a conflict, so I moved it to
news.html.conflict and did an update for the sake of having the Web
site look right.  I'll leave it to someone else who knows what was
intended to resolve the conflict.

daniel



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

Re: [PATCH] http://jakarta.apache.org/site/mail2.html broken url

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, Santiago Gala writes:
>Santiago Gala wrote:
>I have enough karma for xml/html committing, but not for ssh to the web 
>machine. So, could anybody with enough karma update the site?

I just did a cvs update mail2.html, but it doesn't look like there was
any change committed.  I tried doing an update and rebuild of my
jakarta-site2 checkout, but there ws no difference in mail2.html.
I don't have the email with the original patch, so I'll pass the buck
to someone else.

daniel






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

Re: New logo for Jakarta, following the one on www.apache.org

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, Nicola Ken Barozzi writes:
>Attached is a rehashed logo for Jakarta to mimic more the one on the 
>main Apache page, and explicitly state that Jakarta is an Apache project.

Nitpick: Don't forget to add a trailing slash in the URL
(e.g., http://jakarta.apache.org/ instead of http://jakarta.apache.org).

daniel




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

jakarta-site2 graffiti

[Daniel F. Savarese]

Who's the joker who changed some of the copyright statements at the bottom
of some pages in jakarta-site2 from "Apache Software Foundation" to
"ApacheARSE Software Foundation"?  I just noticed it when I updated
site/binindex.html and ran a diff before doing a check in.  Doing some 
further checking, I found them in index.html, site/news.html, and
site/sourceindex.html.  They seem to have been introduced in versions 1.183 of
index.html, 1.262 of site/news.html, 1.247 of site/binindex.html, and 1.169 of
site/sourceindex.html.  All of these were checked in by username
[EMAIL PROTECTED]

Anyway, I'm sure it was accidental, but someone should probably check his/her
local development setup because I don't think we want random instances of
ARSE popping up all over the Web site :)

daniel



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

Re: [PROPOSAL] Create [EMAIL PROTECTED] mailinglist..

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, Martin van den Bemt writes:
>The strength of this list should be is that with a lot of hands the chance tha
>t nothing happens when
>there is activity is minimized. If someone has an hour to spare, it could very
> well be useful to
>apply a patch and mentor people.

Vadim has regexp covered and I have oro covered as far as maintenance
requests go, but no, I don't think either project merits its own
separate -dev and -user lists anymore.  The trick is getting users who
want new features (as opposed to maintenance like bug fixing) to contribute
new features instead of always expecting the maintainers to add them
(e.g., Commons Net has been pretty successful in attracting user
contributed features).  But regexp and oro are special cases which will
likely see no new features in the future, having been rendered obsolete
by standardization of the functionality they provide in the Java core api.

>Since I don't like to extend the scope of the general list, I prefer dev discu
>ssion not to take
>place there.
>
>Thoughts ?

As long as user traffic can go to general, it sounds okay.  Most, if not all,
activity will be triggered by users (who won't be subscribed to dev), so
I'd think at least some threads should be permitted to start on general
and then migrate to dev if there is follow-on development related discussion.

daniel


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

Re: [PROPOSAL] Create [EMAIL PROTECTED] mailinglist..

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, "Andrew C. Oliver" writes:
>lists.  (If you disagree look at the list archive for
>each over the last 6 months and see if you REALLY disagree in more than 
>THEORY).

At least for oro, some Linux distributions continue to ship it as part of
their core packages.  For example, Fedora Core 4, 5, and 6 all included
it and 7 will include it as well.  That's millions of real installations.
It would be negligent to give the impression that Apache will no longer
support the software should maintenance requests be made when there are
in fact committers dedicated to doing the work.  No, there haven't been
any bug reports for oro for years and I don't know why it ships with
Linux distributions, but it does and until it doesn't, it's not a
"dead" project.  There's no need for project-specific mailing lists
anymore, but I'm -1 on putting up a "closed" page for any project
with a user base that continues to require support and for which we
are able to provide support.  Users do need to be directed somewhere
for support and I don't care if that's general@ or some other list
as long as there's an avenue for providing that support.

daniel


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

Re: [VOTE] Release Regexp 1.5

[Daniel F. Savarese]

+1



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

Re: [VOTE] Commons moving to TLP

[Daniel F. Savarese]

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



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

Re: [VOTE] Commons moving to TLP

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, Roland Weber writes:
>Rory Winston - was added by Daniel Savarese
>Torsten Curdt - was added as chair by Henri Yandell

Rory voted for the proposal so I saved him the time and redundancy
when I added myself after voting for the proposal.  I assume Henri
did the same for Torsten.

daniel



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

Re: [PROPOSAL] The future of Jakarta

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, "Henr
i Yandell" writes:
>Chiefly, we need to decide if we're sending the Commons proposal. The

We decided already to submit the Commons proposal by virtue of the vote
result.  I suggest we uphold the current decision and submit the proposal
in order to make some progress.

daniel


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

Re: [PROPOSAL] One development list

[Daniel F. Savarese]

In message , Rahul
 Akolkar writes:
>We currently have 8 active development lists at Jakarta, each devoted
>to a subproject. I've been subscribed to all for a while and based on
>my observations and the overall benefits of doing so, I think its time
>to consolidate them into a single development list at Jakarta.
...
>Thoughts?

No objections from me.  That's been my preferred course of action
for many years now (along with opening commit access for all Jakarta
projects to all Jakarta committers, if we haven't already done so).

>lists before that. Throw in site-cvs@ as well for good measure.
>* We could repurpose general@ as the one dev list, but OTOH, seems
>worthwhile to maintain the dev / general separation.
>* No changes proposed to the user lists.

I'd rather site-cvs be rolled into a single c...@jakarta.apache.org
containing commit traffic for all Jakarta projects.  Redesignate
general@ as user@ to contain user traffic for all Jakarta projects,
retiring all the -user lists in the process.  People can specify the
specific project referred to in the subject a la Commons (e.g.,
Subject: [oro] how do glob expressions work?).  Then add
d...@jakarta.apache.org (also like commons).

daniel


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

Re: [PROPOSAL] One development list

[Daniel F. Savarese]

In message <4ad4c6e2.2090...@dubioso.net>, Roland Weber writes:
>Have you noticed how much traffic there is on jmeter-user?
>It will easily drown all other communication on a combined
>user list. Subscribers to any other Jakarta user list will
>*not* be amused about getting all that into their inboxes.

In my opinion, JMeter should really go top-level, but the community
has not yet (and may never) come to that conclusion.  It's similar
to the relationship httpclient/httpcomponents once had vis a vis
jakarta-commons.  Perhaps we could combine all user lists except
for JMeter.  In any case, it was a suggestion meant to provoke exactly
this kind of discussion (but it's clear now I should have started a
separate thread).

How one feels about the various ideas that have surfaced in this
thread depends on whether one believes Jakarta should or can be revived,
retired, or continue as is.  Provoking discussion helps sort out
exactly what we're trying to accomplish beyond administrative
simplification.  As you say, combining jmeter-user with a
u...@jakarta list is probably not a good idea.  But from my point
of view, it's not because combining user lists is inherently unworkable.
Instead, it's because JMeter is a vibrant project that should go
top-level instead of residing in what some may view as Jakarta's
almost-dead carcass.  Another point of view might be that JMeter
shouldn't go top-level at all and can serve as a focal point for
reviving Jakarta.

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

daniel


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

Re: [VOTE] Merge dev lists

[Daniel F. Savarese]

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

[X] +1





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

Re: New home for ECS, ORO and Regexp?

[Daniel F. Savarese]

In message <25aac9fc1003031751x7d696c4anfe502bc69979a...@mail.gmail.com>, sebb 
writes:
>JMeter also uses ORO, but so long as the existing release remains
>available, it does not matter if it moves to Attic, as ORO works fine
>as it is. There are some RE features that it does not support (such as
>the \Q and \E meta-characters), but otherwise no problems have been
>noticed.

\Q and \E are part of Perl double-quoted string processing and are not
per se regular expression constructs, which is why they weren't
implemented and a quotemeta function was made available instead.  I have
absolutely no problem with it moving into that Attic, but if anyone
requires enhancements, such as adding \Q and \E, then just keep in mind
that you're on your own after ORO moves into the Attic.  The products
that continue to use the software (and there are actually still quite
a few outside of Apache, including commercial products) seem to have
been happy with 2.0.8 for years.  Those who do report issues of one
sort or another do so in a hit and run fashion, such as last December
when I spent time implementing a feature request and never heard back
from the original requestor.  Therefore, no matter how many users there
are, I see no reason to keep ORO out of the Attic if users are not
even willing to follow up on the responses to the issues they report.

That said, I'm not voting a +1 because I don't have the time to help
with satisfying the administrative details of the move.  However, I'd
like to thank in advance those who do spend the time implementing the
move.

daniel


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

Re: [VOTE] Release JMeter 2.4 based on RC3

[Daniel F. Savarese]

In message , sebb
 AT ASF writes:
>Please can I have votes for the release of JMeter 2.4?

>[X ] +1  I support this release

daniel


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

Re: New home for ECS, ORO and Regexp?

[Daniel F. Savarese]

In message , Rahu
l Akolkar writes:
>Daniel (or anyone else) - Should we check if there is interest at
>Commons in taking ORO?

I'm reluctant to encourage additional expenditure of effort to keep
ORO going (although I'm always available to apply patches and respond
to issue reports).  Let's wait a week and see if "anyone else" would
like to explore a move to Commons.  If no one expresses interest by
next Friday, then I'd think it's off to the Attic by default.

daniel


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

removing attic'ed projects from www.apache.org/dist

[Daniel F. Savarese]

For anyone who didn't see the original thread, the PMC received instructions
to review their release distribution areas in www.apache.org/dist and
remove any old releases.  sebb removed some older releases, and I asked
if the oro tree could be removed entirely since it has moved to the attic.
However, the same is true for ecs and taglibs, so I'm expanding this topic
to cover ECS, ORO, and Taglibs, all of which have been attic'ed, but still
have directory trees in dist/.

In message , sebb
 writes:
>Perhaps we should update the websites of such projects to make it
>possible to find releases?
>At present, there are no working download links for ORO.

After looking into it, I can't find any download links off of
attic.apache.org for the above projects pointing visitors to
archive.apache.org/dist/.  I may have simply missed it.

>Probably my fault when I cleared up the downloads site definitions.

I don't think you missed anything (and thanks for all the work you did
by the way).  Everything at http://attic.apache.org/process.html
appears to have been done.  I think we should remove the download links
on the dead project pages and leave it up to the Attic PMC to decide whether
they should place a link to archive.apache.org/dist/ on their site
(it's probably there somehwere and I just couldn't find it).

Whatever the case may be, I'd still like to remove
www.apache.org/dist/jakarta/{ecs,oro,taglibs} if there are no objections.
If someone can point me to instructions on updating dead project pages
(do I just modify the HTML directly on /www/jakarta.apache.org/... and check
that in?), I can remove the "Downloads" link from the oro and ecs pages.
I can't find any download links on the taglibs pages, but its attic page
has a bunch of non-functioning download links.

>BTW, this discussion should presumably now be on the Jakarta general list.
>
>Not sure why it was ever private (I responded to the original e-mail
>which was private)

Done.

daniel


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

Re: removing attic'ed projects from www.apache.org/dist

[Daniel F. Savarese]

I wrote:
>Whatever the case may be, I'd still like to remove
>www.apache.org/dist/jakarta/{ecs,oro,taglibs} if there are no objections.
...
>that in?), I can remove the "Downloads" link from the oro and ecs pages.

Since there were no objections, I executed the above actions.

daniel


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

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

[Daniel F. Savarese]

In message , Rahu
l Akolkar writes:
>We will not move Regexp at this time as vgritsenko has expressed some
>interest in a recent bugfix (his vote to move Regexp to the Attic was
>+0). Lets revisit Regexp in 6 months time if there isn't much
>activity.

Six months have passed and there hasn't been much activity.
Should we revisit this now?  Someone recently offered to contribute some
code on regexp-user@, but it didn't generate enough interest for anyone
to reply. 

daniel


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

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

[Daniel F. Savarese]

In message , Rahu
l Akolkar writes:
>This is a vote to move Jakarta Regexp to the Apache Attic, based on
>the outcome of the most recent discussion on the topic.

+1



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