Re: [VOTE] Move Turbine to TLP

[Jeff Brekke]

+1

Scott Eade wrote:
 > Here are the vote options:

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

Voting will close in one week.


--
=
Jeffrey D. Brekke   [EMAIL PROTECTED]
Wisconsin,  USA [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]


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

Re: Jakarta stats

[Jeff Dever]

My spam filter which dumps nearly all [EMAIL PROTECTED] email, does  
keep messages with my name in them.  Heh.


I'd take "vanished" to mean "became invisible", which is what I had  
become for some time before this thread started.


Emeritus status in Apache context is quite encompassing, which would  
appear to an appropriate place for people in my position.


-jsd

On Jan 14, 2006, at 08:48, Martin van den Bemt wrote:


Hi Jeff,

Jeff Dever wrote:

 I guess I consider myself to be a category 3:
"3) People who are committer, did do some serious work and vanished."


Hmm I miss the part about vanishing, you clearly are monitoring  
lists ?


The situation is simply that I am unable to work on Jakarta any   
further.  HttpClient is very very active and I am pleased that   
development continues under the Apache umbrella.
I'm not sure what, in this context, it means to be moved to   
'emuritus'.  I appreciate recognition of past work, but I don't  
feel  my contributions warrant such a title.


(from http://www.apache.org/foundation/glossary.html)
Emeritus
A term used to formally designate someone as no longer active,  
but still entitled to all of the rights and privileges of the  
position. For example, an ASF member who hasn't attended any  
membership meetings for a long time is declared emeritus; someone  
who no longer has time to work on a particular project may declare  
itself emeritus. Emeritus status indicates interest but not  
activity, as opposed to having resigned.


You decide for yourself :)

Mvgr,
Martin

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






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

Re: Jakarta stats

[Jeff Dever]

 I guess I consider myself to be a category 3:

"3) People who are committer, did do some serious work and vanished."

The situation is simply that I am unable to work on Jakarta any  
further.  HttpClient is very very active and I am pleased that  
development continues under the Apache umbrella.


I'm not sure what, in this context, it means to be moved to  
'emuritus'.  I appreciate recognition of past work, but I don't feel  
my contributions warrant such a title.


-jsd (Jeff Dever)


On Jan 12, 2006, at 15:40, Vadim Gritsenko wrote:


Martin van den Bemt wrote:
The result can be a couple of things (probably depending on the  
response) :

- Leave it as is
- Move them to emuritus


Above two are the only acceptable choices for folks with valid  
accounts. We can discuss means and mechanisms of moving to emeritus  
and back, but removing folks who fall into groups 2) to 5) is  
unacceptable - all IMHO.


Vadim

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






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

Re: Javadoc management

[Jeff Martin]

My involvement was with what has now become tucked away in a zip file
called alexandria-legacy. At this time Alexandria was an ant build
script with some ant extensions. Most of these are now part of ant.

Alexandra's main goal was to allow people to access javadoc and xrefed
source code. The build and testing stuff was just a logical extension of
having a system which could automatically checkout code. Gump now
handles this much better.

Anyway just trying to bring people's attention to an existing solution
rather than trying to start everything from scratch.

On Fri, 2005-03-18 at 12:22 -0500, Henri Yandell wrote:
> My negatives for Alexandria:
> 
> * Seems large and yet dead
> * Has lofty goals, whereas the below is very basic
> 
> Gump is another possibility. I noticed the other day that they have 
> javadoc in the gump.xml.
> 
> My argument for the below over trying to do things with gump is that it is 
> simple to get running and find out what we actually want. Once we have 
> that, we can try to drive gump/alexandria/something-else.
> 
> Hen
> 
> On Fri, 18 Mar 2005, Jeff Martin wrote:
> 
> > Just wondering if anyone had looked at Alexandria.
> > http://jakarta.apache.org/alexandria/legacy/
> >
> > On Fri, 2005-03-18 at 00:31 -0500, Henri Yandell wrote:
> >>
> >> On Thu, 17 Mar 2005, J Aaron Farr wrote:
> >>
> >>> On Wed, 16 Mar 2005 00:49:08 -0500 (EST), Henri Yandell
> >>> <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>> Interested in finding out if anyone else thinks this would be a good 
> >>>> idea.
> >>>>
> >>>> Rather than have each subproject managing their release javadocs
> >>>> separately, I think it would be good if we treated the javadoc more like
> >>>> the releases. Located in a central location, perhaps mirrored, all
> >>>> versions available and perhaps with additional tools like ashkelon or
> >>>> multidoc to bring them together.
> >>>
> >>> I guess I'm hoping for something like:
> >>>
> >>>   http://api.apache.org/$group/$artifact/$version/
> >>
> >> Sounds good, though possibly:
> >>
> >> http://jakarta.apache.org/api/$subproject/$artifact/$version/
> >>
> >> to get a prototype up and running.
> >>
> >>> with features like
> >>>
> >>>   * download the javadocs
> >>
> >> +1. Unsure how this would balance with the download pages.
> >>
> >>>   * search javadocs
> >>
> >> +1 long-term.
> >>
> >>>   * have javadocs linked to source reference  (so maybe have an 'api'
> >>> and a 'src' directory)
> >>
> >> Not hugely essential I think.
> >>
> >>>   * have javadocs linked to each other
> >>
> >> Would be very nice, but seems like a battle. We wouldn't want to rebuild
> >> the javadoc as part of this, and might not be easy to find a way to munge
> >> existing javadoc to point to each other. Also means dependency knowledge,
> >> which version of Collections did this BeanUtils use.
> >>
> >>>   * include test and taglib javadocs
> >>
> >> +1 on taglibs. Test ones are less essential to start with I think.
> >>
> >>> Plus it's got to be pretty simple to set this up or for projects to
> >>> contribute to it.
> >>
> >> To start with, I'm generally thinking of a defined file structure in which
> >> unzipped javadocs appear, a location for downloadable javadoc to be and a
> >> front end to make it easy to get to the relevant javadoc.
> >>
> >> A release would involve putting the new javadoc in place, adding it to the
> >> front-end (hopefully in a one-line kind of way) and then creating a
> >> downloadable zip.
> >>
> >> Initial plan would be to propose a structure for the repository (I like
> >> yours), go extract a lot of javadocs from our downloads to seed the
> >> repository, and come up with a simple-front-end to let people use them.
> >>
> >> An important requirement will be the need for a subproject/group to be
> >> able to link to a page that defines their javadoc, rather than at the top
> >> level.
> >>
> >> Hen
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> > -- 
> > Jeff Martin
> >
> > Memetic Engineer
> >
> > http://www.custommonkey.org/
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-- 
jeff martin
information technologist
mkodo limited

mobile: 44 (0) 78 55 478 331
phone: 44 (0) 20 77 29 45 45
email: [EMAIL PROTECTED]

www.mkodo.com

73 Leonard St, London, EC2A 4QS. U.K





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

Re: Javadoc management

[Jeff Martin]

Just wondering if anyone had looked at Alexandria.
http://jakarta.apache.org/alexandria/legacy/

On Fri, 2005-03-18 at 00:31 -0500, Henri Yandell wrote:
> 
> On Thu, 17 Mar 2005, J Aaron Farr wrote:
> 
> > On Wed, 16 Mar 2005 00:49:08 -0500 (EST), Henri Yandell
> > <[EMAIL PROTECTED]> wrote:
> >>
> >> Interested in finding out if anyone else thinks this would be a good idea.
> >>
> >> Rather than have each subproject managing their release javadocs
> >> separately, I think it would be good if we treated the javadoc more like
> >> the releases. Located in a central location, perhaps mirrored, all
> >> versions available and perhaps with additional tools like ashkelon or
> >> multidoc to bring them together.
> >
> > I guess I'm hoping for something like:
> >
> >   http://api.apache.org/$group/$artifact/$version/
> 
> Sounds good, though possibly:
> 
> http://jakarta.apache.org/api/$subproject/$artifact/$version/
> 
> to get a prototype up and running.
> 
> > with features like
> >
> >   * download the javadocs
> 
> +1. Unsure how this would balance with the download pages.
> 
> >   * search javadocs
> 
> +1 long-term.
> 
> >   * have javadocs linked to source reference  (so maybe have an 'api'
> > and a 'src' directory)
> 
> Not hugely essential I think.
> 
> >   * have javadocs linked to each other
> 
> Would be very nice, but seems like a battle. We wouldn't want to rebuild 
> the javadoc as part of this, and might not be easy to find a way to munge 
> existing javadoc to point to each other. Also means dependency knowledge, 
> which version of Collections did this BeanUtils use.
> 
> >   * include test and taglib javadocs
> 
> +1 on taglibs. Test ones are less essential to start with I think.
> 
> > Plus it's got to be pretty simple to set this up or for projects to
> > contribute to it.
> 
> To start with, I'm generally thinking of a defined file structure in which 
> unzipped javadocs appear, a location for downloadable javadoc to be and a 
> front end to make it easy to get to the relevant javadoc.
> 
> A release would involve putting the new javadoc in place, adding it to the 
> front-end (hopefully in a one-line kind of way) and then creating a 
> downloadable zip.
> 
> Initial plan would be to propose a structure for the repository (I like 
> yours), go extract a lot of javadocs from our downloads to seed the 
> repository, and come up with a simple-front-end to let people use them.
> 
> An important requirement will be the need for a subproject/group to be 
> able to link to a page that defines their javadoc, rather than at the top 
> level.
> 
> Hen
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-- 
Jeff Martin

Memetic Engineer

http://www.custommonkey.org/ 




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

Re: Re:RPM's (was: Jakarta - A study in self defeating projects)

[Jeff Martin]

> Hi Yoav et al,
> Is there good information around somewhere about how to make RPMs for 
> Java libraries?  For instance, HttpClient provides nothing by itself 
> and should be put into the classpath of each project you need to use it 
> with.  It's not a good idea for installers to put things into the 
> extensions directory of the JRE because it can cause conflicts, hides 
> the fact that the jar has to be redistributed with the application and 
> the installer likely has no idea with JVM it needs to install into 
> anyway.

The jpackage RPMs work the other way round. There is a single repository
(not related to a JVM) which holds all the libraries for a system.
Applications then make use of these libraries by dynamically generating
a classpath containing only those libraries that the application
requires.

This does mean that anyone creating an RPM needs to patch any launch
scripts to use the classpath generation tools, but it's the only way
really.

The RPMs for libraries are really just providing dependency information
so that when I request an installer (apt/yum) to install an application
the installer can go off and ensure that all the dependencies are
satisfied before installing the main app.

> 
> So given that, is it useful to have RPMs for Java libraries and if so, 
> how should they be packaged?

Very useful, I don't need to find out what version of what library is
needed for what app. It's all sorted out by an installer when the RPMs
are installed. The system also handles ongoing upgrades of apps as well
as initial installs

> 
> My personal opinion is that Java libraries should be packaged as tar.gz 
> and .zip archives complete with documentation as well as a plain jar 
> file if it's totally standalone (though that's not essential).  I've 
> never wanted an installer and always actively avoid them for libraries. 
>   Complete programs (eg: tomcat and maven) on the other hand I'm all for 
> having an installer for and thus RPMs would be great.
> 
Again RPMs are really archive files with added dependency data which is
then used by an installer.
-- 
Jeff Martin

Memetic Engineer

http://www.custommonkey.org/ 




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

Re: spam via [EMAIL PROTECTED]

[Jeff Dever]

I'm surprised there were no replies to this.  Spam thorough my 
apache.org account is brutal.  We are talking on the order of a 1000 
messages every couple weeks.  Mozilla does a pretty good job identifying 
spam, but I have had to rescue more than one important messaged from the 
junk.

There must be some savings in bandwith, aggrivation and money that can 
be made by using spamassassin or somthing on the server.  I moderate the 
HttpClient mailing list, and do my part by rejecting many spam messages 
everyday but I sure wish the obvious ones could be handled automaticly.

-jsd

otisg wrote:

Hello,

I remember somebody mentioning some spam filters being installed
on Apache's mail servers maybe half a year ago.
Are those really working?
I have been getting more and more spam either via my @apache.org
account which forwards mail to my real address, or maybe via
some @jakarta.apache.org mailing lists that I am subscribed to.
Is there any way to reduce the amount of spam being delivered
through various @*apache.org addresses?
Are spam filters currently installed?
Thank you,
Otis

Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag
-
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]

MPl and ASL compatible?

[Jeff Epstein]

I'm having a lot of trouble deciding on which license I want for my
projects.  I want to be compatible with both GPL and the Apache Software
License, but I'm not sure this is possible.

I believe I want the Mozilla Public License (version 1.1).  Is this
compatible with the Apache Software License?

Thank you.

=
:' )

Jeffy
[EMAIL PROTECTED]
http://www.jeffyjeffy.com

[NOTE:  If you send an email to me, and it has the word "Microsoft" in
the from field, or "Security" in either the from or subject, then your 
message will be automatically trashed  :'  (]

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

Re: Forum Software.

[Jeff Schnitzer]

On Wed, Jan 22, 2003 at 11:15:22PM +, Pier Fumagalli wrote:
> 
> We have a license and an installation of Jive, if someone wants to get it up
> to speed... It's on nagoya.

If you need a volunteer to maintain it, I'll be happy to do so - among
other things, I develop and maintain the Jive-based forums for The Sims
Online.  However, I'm firmly in the mailing-list camp, at least as regards
Apache.  I don't see any reason to "fix" what isn't broken.

IMHO, the forums will be useful to the extent that their purpose does
not overlap with the mailing list and thus split the community.  What
purpose that leaves, I don't know.

Jeff Schnitzer
[EMAIL PROTECTED]

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

Re: Forum Software.

[Jeff Schnitzer]

On Wed, Jan 22, 2003 at 01:08:56PM -0800, Randall J. Parr wrote:
> 
> It seems much of the reason people want to have forums is for the search 
> abilities. There are mail archives available but I must I agree many are 
> so limited in their search abilities and/or interface that they do not 
> help much.

What do you find lacking from http://www.mail-archive.com?  I almost
prefer it to my mailreader.

Jeff

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

Re: Newsletter - Request for content

[Jeff Turner]

On Wed, Jan 08, 2003 at 12:46:25PM -, Rob Oxspring wrote:
> As you can see the timetable has slipped a bit!  However, there doesn't
> seem to be a lot to go in this issue (just an entry for lucene +
> whatever I write to summarise general@) and I was wondering whether it
> was worth bothering with.  I realise this is to be expected with the
> Christmas / New Year but there has been a general decline in content
> volume over the months and I was wondering whether there was something
> that should be done to address this.  A number of thoughts have been
> mentioned by various people and I'd be interested to hear opinions:
> 
> Reduce the frequency - every 2 months has been suggested before.
> Format revamp - no idea how but ideas welcome - perhaps new blood is
> required?

How about setting up an 'ApacheNewsletter' Wiki page, let content
accumulate, and publish once critical mass is achieved?

I'd imagine that writing a newsletter entry is no fun at all. Probably
each project has only 2 or 3 people with a broad enough understanding of
the issues to 'summarize' a month's communications, identifying the
signal amongst the noise.  It's also a rather subjective task, with a
high risk of offending someone by omitting or misrepresenting points.

Using a Wiki doesn't solve the hard problems, but does lower the barrier
to entry, and makes plain that it's everyone's "problem" to create
content, not just the dedicated few listed below.

> Widen the scope - ant and Avalon have grown up to be (at least
> partially) outside the jakarta scope, should we include
> xml.apache.org? and it's children? maybe just a simple *.apache.org?

I know Forrest has a willing contributor :) and I'm sure with some
arm-twisting, one could be found for Cocoon.


--Jeff

> (with some appropriate rename)
> Maybe its fine as it is?
> 
> Thanks,
> 
> Rob
> 
> - Original Message -
> From: "Rob Oxspring" <[EMAIL PROTECTED]>
> To: "'Jakarta General List'" <[EMAIL PROTECTED]>
> Cc: "'James Strachan'" <[EMAIL PROTECTED]>; "'Henri Yandell'" 
><[EMAIL PROTECTED]>; "'Conor MacNeill'"
> <[EMAIL PROTECTED]>; "'Stefan Bodewig'" <[EMAIL PROTECTED]>; "'Otis 
>Gospodnetic'" <[EMAIL PROTECTED]>; "'David
> Sean Taylor'" <[EMAIL PROTECTED]>; "'Martin Poeschl'" <[EMAIL PROTECTED]>
> Sent: Sunday, December 29, 2002 2:30 PM
> Subject: Newsletter - Request for content
...

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

Re: Sun Is Losing Its Way

[Jeff Schnitzer]

On Fri, Dec 13, 2002 at 06:42:36PM +0200, mohammad nabil wrote:
> 
> support Sun, Open Source, and all good manufacturar in our nice world :)
> 

Do you just not grasp that Sun's rigid control of Java is the
antithesis of Open Source, and _especially_ the Apache philosophy?

Try forking the Java codebase sometime.  See how fast it takes 
Sun's lawyers to find you.  Want to port Java to a new platform?
Get special permission from Sun, and don't plan on having public
CVS (see the FreeBSD experience).

There's nothing "open" about that.

Jeff

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

Re: [DRAFT1] Jakarta Newsletter - November 2002

[Jeff Martin]

Don't suppose you'd consider putting a link to XMLUnit
http://xmlunit.sf.net/ in the Jelly section. It's always good to try a
bit of shameless publicity seeking ;-)
-- 
Jeff Martin

Memetic Engineer

http://www.custommonkey.org/ 


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

Re: [PROPOSAL] Tapestry joins Jakarta

[Jeff Turner]

On Sun, Oct 20, 2002 at 03:23:27PM +0100, Vincent Massol wrote:
...
> 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.

Oh well, in the deal, Jakarta got this '[EMAIL PROTECTED]' fellow who's
now doing good stuff in Maven and Commons... :)

The point being: when bringing in a new project, the new people are often
just as valuable as the new codebase.  Along with POI we got Andrew
Oliver... :)  I'm not suggesting anyone try to 'evaluate' people, just be
aware of this possible benefit, which may tilt some +0's to +1.

--Jeff

PS: +1 for adding Tapestry from me btw.

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

Re: Developer wishes to donate project to Apache

[Jeff Turner]

On Sat, Oct 12, 2002 at 12:27:17PM -0400, Geir Magnusson Jr. wrote:
...
> Why not bring into Jmeter?

Frank tried [1] and was met with the same silence that greeted his ealier
general@jakarta email [2].

Anyone wanting to have a play, the url is:

http://www.PushToTest.com/ptt

Jon might even like it, as it uses a real scripting language (Jython) to
script HTTP tests, rather than XML. All wrapped up in a Netbeans gui.

Attached is an email I wrote to the author with my personal assessment of
TestMaker's chances at Jakarta. I hope it doesn't discourage people from
doing their own analysis, but apparently if these things aren't posted
publicly, Jakarta gains a reputation of ignoring people's approaches.


--Jeff


co-author of a similar Ant-based testing framework, http://aft.sf.net


[1] http://marc.theaimsgroup.com/?l=jmeter-dev&m=103064442221903&w=2
[2] http://marc.theaimsgroup.com/?l=jakarta-general&m=103064493222452&w=2

--- Begin Message ---

On Tue, Sep 03, 2002 at 09:09:49AM -0700, Frank Cohen wrote:
> >> Hi Jeff: Thanks for your interest. TestMaker uses a lot of open-source
> >> libraries: NetBeans, Jython, Xerces, JDOM, Apache SOAP, etc. The download
> >> package on the Web site provides these all integrated and ready to use. The
> >> components we wrote from scratch are the Test Object Oriented Library (TOOL)
> >> and the NetBeans module and localization/branding file.
> >> 
> >> I'm laid up in bed with a nasty head cold - have been for the past 4 days.
> >> Ugh. I'll send you a document that shows how to build TestMaker from all the
> >> parts shortly.
> > 
> > That's okay, I downloaded the whole shebang yesterday, and don't reeeally
> > need to build all from scratch ;)
> 
> Great. How did the install go? Are you running Unix, Windows, ? Did you read
> the docs?

It all went nicely after I fixed the file formats.

> > Anyway, just random thoughts :) I fully agree that the .NET vs Java war
> > is hotting up and that OSS's achilles heel is the lack of coordination
> > and integration.
> 
> Is there a process to getting TestMaker considered as a subproject? I read
> the Jakarta Web pages - which do a very good job a discouraging - but it
> doesn't really say how a subproject is started. :-)

You did it right. There's a Project Management Committee (PMC) of seven
people who decide if a project gets in or not, and they decide based on
interest expressed on general@jakarta. There, 99.9% of people don't know
or use your project, so they form opinions mainly on criteria like these:

 1) Is it suitable as per http://jakarta.apache.org/site/newproject.html
 2) Is it a winner, ie is it leading the pack in it's market niche.
 3) Does it's goals overlap with any existing, more widely know projects.
 4) Does it integrate well with existing Jakarta projects.

I think TestMaker meets 1), and given the sad, fragmented state of open
source functional testing generally, doesn't fail 2) either.

TestMaker's functionality does seem to overlap with JMeter somewhat,
which is what Andrew Oliver said. Lately, people have been very
unforgiving of projects that may fulfil the goals of related, more
widely-known projects (in this case, JMeter). People do realise that
fragmentation is hurting Java, so they'd rather callously say "go away
and merge with X" than accept any project that isn't clearly unique or
market-leading.

Also, TestMaker seems more an integration of existing technologies
(jython, netbeans) than a more traditional straight-Java project. The
TestMaker-specific code (TOOL) has already been implemented at Jakarta,
in the form of the HTTPClient project:

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

At least, that is the impression a casual user gets from the TOOL
description "Tool is the object library that handles communication with
HTTP, HTTPS, SOAP, .NET, JDBC and other protocols."

There's absolutely nothing wrong with projects that meet a need by
integrating existing projects (assuming netbeans + jython + http lib ==
TestMaker), but they don't really "fit" well in Jakarta. There's just so
many permutations. If someone integrated Eclipse + jython + httplib,
should that also live at Jakarta? 

Anyway, that's my brutally honest opinion :)

Perhaps we should form a "Open Source Functional Testing Tools
Consortium" to promote awareness of what's out there, and more
collaboration amongst the various projects (Latka, Anteater, TestMaker,
JMeter, WebTest.. any others?).


--Jeff


> > --Jeff
> > 
> > [1] http://aft.sourceforge.net
> > [2] http://jakarta.apache.org/commons/latka)
> > [3] http://jakarta.apache.org/commons/sandbox/jelly
> > 
> >> -Frank
> &

Re: Differences between Structs and Turbine ???

[Jeff Schnitzer]

On Tue, Oct 08, 2002 at 03:03:37PM -0700, Jon Scott Stevens wrote:
> 
> Interestingly enough, I did write a quick little framework that works very
> similar to Turbine and has the same concept of users/roles/permissions. =)

Well, if you want an MVC framework, someone did a port
of Maverick to PHP:   http://amb.sourceforge.net/

:-P

Jeff Schnitzer
[EMAIL PROTECTED]

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

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

[Jeff Turner]

Carnegie Mellon did a survey of ~300 Apache developers (56 committers) a
while ago, and posted interim results to respondents last month. With the
permission of the researcher, here are some stats:

On Thu, Oct 03, 2002 at 03:35:18PM +0100, Danny Angus wrote:
> 
> Vincent Massol once wrote:
> 
> > I was curious to know who the other committers where, whether they shared
> the same beliefs I have, etc.
> 
> This prompted me to wonder:
> 
> 1/ are we..
> a)male
> b)female

98.89% male
1.11% female

> 2/are we
> a) young
> b) 20-30
> c) 30-40
> d) 40-50
> d) old

 < 19 : 1.1%
20-29 : 50.55%
30-39 : 41.03%
40-49 : 6.59%
 > 50 : 0.73%

> 3/about English
> a)its my native language
> b)its a second language, I live in an English speaking country
> c)I'm fluent but I live in a non-English speaking country
> d)other, tell me..

Strangely they didn't ask this. However, 90% of people come from what I
hazily regard as "English speaking countries" (US, England, Aus, NZ).

> 4/do we have
> a)a full beard
> b)a goatee
> c)a moustache
> d)noneoftheabove
>
> 5/wear sandals
> a)never
> b)sometimes
> c)always

Nor did they ask these, missing a golden opportunity to come up with an
identikit-style portait of J Random Apache Hacker.

The person running the survey is Jeff Roberts (jroberts at
andrew.cmu.edu).


--Jeff

> 
> d.
> 
> 

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

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

[Jeff Prickett]

On Thursday 03 October 2002 07:35, Danny Angus wrote:
> Vincent Massol once wrote:
> > I was curious to know who the other committers where, whether they shared
>
> the same beliefs I have, etc.
>
> This prompted me to wonder:
>
> 1/ are we..
> a)male
> b)female
> c)decline to answer
>

Male

> 2/are we
> a) young
> b) 20-30
> c) 30-40
> d) 40-50
> d) old
>

30-40

> 3/about English
> a)its my native language
> b)its a second language, I live in an English speaking country
> c)I'm fluent but I live in a non-English speaking country
> d)other, tell me..
>

Native language English
Native Country: USA

> 4/do we have
> a)a full beard
> b)a goatee
> c)a moustache
> d)noneoftheabove
>

No facial hair

> 5/wear sandals
> a)never
> b)sometimes
> c)always
>

As often as possible

>
> In the spirit of these things private mail will be kept private, and I'll
> publish an anonymous and glossy breakdown of the stats.
>
> d.


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

karma for jakarta-site2

[Jeff Dever]

I would like to add some info to the jakarta-site2 module.  Could somone
hit me with the karma?

Jeff Dever
HttpClient 2.0 release manager




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

Re: Know each other

[Jeff Martin]

I'm kinda London based at the moment (Although I'm not really actively
apache at the moment) 

I've also met both Vincent Massoll (Cactus) and Paul Hamett (Avalon)
both of whom have been know to attend XTC
http://www.xpdeveloper.com/cgi-bin/wiki.cgi?ExtremeTuesdayClub

On Fri, 2002-07-19 at 07:58, Alex McLintock wrote:
> At 12:14 18/07/02, Aaron wrote:
> >I have a question.  It seems that you all kinda know each other. Where is
> >everyone located?
> >Aaron
> 
> Working with Open Source software is a pretty unpopular pastime - if I was 
> a BEA Weblogic expert for instance I would have people beating down my door 
> to get to know me :-)
> 
> I think most of the people on the general list are concerned with Apache 
> (or at least Jakarta) as a whole rather than just one particular Apache 
> project. It is only natural that people with the same interest get to know 
> more about each other and sometimes meet up in real life.
> 
> I would be quite keen to meet more Apache people in London or nearby but so 
> far the only person I know lives nearby is Pier Fumigalli and I still 
> haven't met him yet.
> 
> I'm particularly keen to hear from UK and other European companies doing 
> Apache Open Source so that I can add them to my OSS directory 
> http://www.OWAL.co.uk/oss_support/
> 
> Alex McLintock
> 
> 
> 
> 
> 
> 
> 
> Openweb Analysts Ltd, London.
> Software For Complex Websites http://www.OWAL.co.uk/
> Open Source Software Companies please register here 
> http://www.OWAL.co.uk/oss_support/
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 
-- 
jeff martin
information technologist
mkodo limited

mobile: 44 (0) 78 5547 8331
phone: 44 (0) 20 2226 4545
email: [EMAIL PROTECTED]

www.mkodo.com


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

Re: Know each other

[Jeff Martin]

I'm kinda London based at the moment (Although I'm not really actively
apache at the moment) 

I've also met both Vincent Massoll (Cactus) and Paul Hamett (Avalon)
both of whom have been know to attend XTC
http://www.xpdeveloper.com/cgi-bin/wiki.cgi?ExtremeTuesdayClub

On Fri, 2002-07-19 at 07:58, Alex McLintock wrote:
> At 12:14 18/07/02, Aaron wrote:
> >I have a question.  It seems that you all kinda know each other. Where is
> >everyone located?
> >Aaron
> 
> Working with Open Source software is a pretty unpopular pastime - if I was 
> a BEA Weblogic expert for instance I would have people beating down my door 
> to get to know me :-)
> 
> I think most of the people on the general list are concerned with Apache 
> (or at least Jakarta) as a whole rather than just one particular Apache 
> project. It is only natural that people with the same interest get to know 
> more about each other and sometimes meet up in real life.
> 
> I would be quite keen to meet more Apache people in London or nearby but so 
> far the only person I know lives nearby is Pier Fumigalli and I still 
> haven't met him yet.
> 
> I'm particularly keen to hear from UK and other European companies doing 
> Apache Open Source so that I can add them to my OSS directory 
> http://www.OWAL.co.uk/oss_support/
> 
> Alex McLintock
> 
> 
> 
> 
> 
> 
> 
> Openweb Analysts Ltd, London.
> Software For Complex Websites http://www.OWAL.co.uk/
> Open Source Software Companies please register here 
> http://www.OWAL.co.uk/oss_support/
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 

-- 
Jeff Martin

Memetic Engineer

http://www.custommonkey.org/ 


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

Divorcing karma from CVS access? (Re: Vicious Abuse?)

[Jeff Turner]

On Sat, May 25, 2002 at 03:51:54PM +0100, Pier Fumagalli wrote:
> "Jeff Turner" <[EMAIL PROTECTED]> wrote:
> 
> > .. and thankful that people like Costin persevere in spite of rather
> > vicious abuse.
> 
> Vicious abuse? All I am proposing is to add greater flexibility to the
> freedom of those who are involved with the Jakarta project.

I was objecting to unprovoked Costin-bashing outside tomcat-dev, not
your proposal. People outside tomcat-dev may not understand why a PMC
member deserved your comments ;P

As for your proposal, a few thoughts:

- AFAIK there is no requirement that a committer be a coder. See the
  definition on http://jakarta.apache.org/site/roles.html. An example:
  Diana Shannon voted as a Cocoon committer, for volunteering to
  coordinate docs:
  http://marc.theaimsgroup.com/?t=10189649374&r=1&w=2

- Your proposal redefined 'contributor' to include CVS access, and I
  think that will cause confusion with the existing, looser meaning.

- (random thoughts..) The whole notion of defining a person's worth in
  terms of their CVS access seems backwards and wrong. The
  'committer/non-committer' dividing line is an artifact of CVS's
  coarse-grained access control, and will disappear once we migrate to
  Subversion or whatever. It would be nice if there was a 'rating'
  system that didn't hijack the versioning system's terminology. Karma
  rated on a different scale to CVS access. Then there could be a
  one-way mapping, X karma -> Y CVS access. The karma system could be
  something like advogato's (http://www.advogato.org/trust-metric.html
  http://www.advogato.org/person/).


--Jeff

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

Re: [PROPOSAL] Committer access and responsibilities...

[Jeff Turner]

On Sat, May 25, 2002 at 02:04:24PM +0100, Pier Fumagalli wrote:
> [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > On Sat, 25 May 2002, Pier Fumagalli wrote:
> > 
> >>> If you are a commiter - you have the same rights with all other commiters.
> >>> If you don't want to exercise some rights - it's your choice.
> >> 
> >> Hola, you tend to forget a part I'm stressing out quite hardly... It's not
> >> only "rights"... It's also "dues", right?
> > 
> > Yes, the 'due' to spend weekends writing code or answering emails or
> > reading flame wars.
> > 
> > Give me a break with the big 'due' to vote or have a say over how the
> > project you're involved with.
> 
> And in fact, Costin, the big opposition you're going to get from me, will
> always be on the fact that you are totally and utterly irresponsible towards
> this community and the ASF... It's years that you're been told that, not
> only from me, but from an extended number of people (do we want to get back
> to the Tomcat 3.x/4.x flamewar? Read those comments)...

Aren't we all happy that 3.3.x exists, and is better than 3.2.x? Aren't
we all happy that we have a choice to 4.x?

Aren't we all happy that Jon was 'mislead' into not -1'ing Struts (one
of Jakarta's biggest successes)?

Perhaps people should be less certain they know what is best for the
community :P

> Anyway, nice talking to you (not).

.. and thankful that people like Costin persevere in spite of rather
vicious abuse.


--Jeff
(a happy 3.3.x and Struts user, whose sense of justice temporarily
outweighs an aversion to general@ flamewars)


> Pier
> 

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

where to send questions about "Other Classes"

[Jeff Barrett]

What's the appropriate list for questions about stuff in the
org.apache.xml.serialize package?

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

Re: Advertisement using Apache lists

[Jeff Turner]

On Mon, May 13, 2002 at 01:20:24PM +0100, Alex McLintock wrote:
> At 13:13 13/05/2002, Jeff Turner wrote:
> >On Mon, May 13, 2002 at 09:54:48AM +0100, Alex McLintock wrote:
> >> At 09:02 13/05/2002, Nicola Ken Barozzi wrote:
> >> >I would like to encourage information about commercial entities
> >> >that support Apache software, but I really have no clue about how
> >> >it should be done.
> >>
> >> I too am setting up an organisation in the UK to help support Apache and
> >> other OSS software.
> >>
> >> I suggest that the first (and simplest) thing to do would be to
> >> setup a top level apache mailing list where it is ok to advertise
> >> oneself, one's company, or to advertise that you need support.
> >
> >I doubt a separate list would work. We've got an announcements@ list
> >and everyone still cc's announcements to general@.
> >
> >Perhaps we should just adopt a simple subject line convention, [ADV]
> >for adverts, to go with [ANN] for announcements.
> 
> It isn't just about announcements - if it were then we would just use
> the announcements mailing lists.  It is really about having a place
> where we can discuss these issues which are welcome no where else.

Ah right. "these issues" being, "commercial entities supporting Apache
software", aka "How to make a buck off Jakarta". Cool :) I'd subscribe.
The Open Source vs. Paid Work conflict sucks.

Maybe start an egroups list, or even just collect a list of people to
Cc. Mail weekly summaries to general@ to maintain interest. Then if it's
still around in 1 month, ping infrastructure@ and beg :)


--Jeff

> Alex
> 

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

Re: Advertisement using Apache lists

[Jeff Turner]

On Mon, May 13, 2002 at 02:04:20PM +0200, Nicola Ken Barozzi wrote:
..
> > Perhaps we should just adopt a simple subject line convention, [ADV] for
> > adverts, to go with [ANN] for announcements.
> 
> I've noticed too that the annoumcement list stuff gets CCd to other lists.
> 
> How about having all content sent to that list be automatically CCd to
> general lists with [ANN]?

To spell out this idea: any mail that gets sent to announcements@jakarta
is forwarded to general@ with "[ANN]" prepended to it's subject
(possibly stripping any existing [ANN] variants).

Same with [EMAIL PROTECTED]

That's kinda nice. In addition to munging the subject line, it could add
an X-Jakarta-Announce: or X-Jakarta-Advert: header, which people could
filter on.

All assuming that people *want* Jakarta-related adverts and
announcements on general@. I get the impression that some do, a few
don't, and most don't care.


--Jeff

> This way if one wants only announcements, he can subscribe to that list,
> while other users get the ANN topics automatically.

> This could be done also with an [EMAIL PROTECTED] list, and [ADV] as
> Jeff suggests.
> Another result of this is having separate mail history for these lists.
> 
> --
> Nicola Ken Barozzi   [EMAIL PROTECTED]
> - verba volant, scripta manent -
>(discussions get forgotten, just code remains)
> 

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

Re: Advertisement using Apache lists

[Jeff Turner]

On Mon, May 13, 2002 at 09:54:48AM +0100, Alex McLintock wrote:
> At 09:02 13/05/2002, Nicola Ken Barozzi wrote:
> >I would like to encourage information about commercial entities that 
> >support
> >Apache software, but I really have no clue about how it should be done.
> 
> I too am setting up an organisation in the UK to help support Apache and 
> other OSS software.
> 
> I suggest that the first (and simplest) thing to do would be to setup a top 
> level apache mailing list where it is ok to advertise oneself, one's 
> company, or to advertise that you need support.

I doubt a separate list would work. We've got an announcements@ list and
everyone still cc's announcements to general@.

Perhaps we should just adopt a simple subject line convention, [ADV] for
adverts, to go with [ANN] for announcements.

--Jeff

> I'm not a committer on any projects so can anyone else try to get this 
> going? It shouldn't be too hard.
> 
> Alex
> 

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

RE: Database Subproject Discussion : creation of DBCommons ?

[Jeff Schnitzer]

How about tweaking "db" enough so that it both pronounces better and has
less explicit meaning?

I like:  dub.apache.org

Let someone else figure out acronym meaning later :-)

Jeff Schnitzer
[EMAIL PROTECTED]

How many millions of dollars did Andersen spend for the name
"Accenture"? Sounds like some sort of meat seasoning.  No MSG!

> -Original Message-
> From: Jim Seach [mailto:[EMAIL PROTECTED]]
> Sent: Monday, May 06, 2002 3:42 PM
> To: Jakarta General List
> Subject: Re: Database Subproject Discussion : creation of DBCommons ?
> 
> I don't have a problem with db, but if that is associated too strongly
> with relational databases, how about datamanagement or dm?  Another
> option would be just data.
> 
> Jim Seach


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

RE: You guys are so funny.

[Jeff Schnitzer]

> >Hear hear!  (But go emacs! ;-)
> 
> B... vi rules!


Ed is the standard text editor.

http://www.gnu.org/fun/jokes/ed.msg.html

:-)

Jeff Schnitzer
[EMAIL PROTECTED]
Yes, I was reading alt.slack in '91 :-)

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

RE: You guys are so funny.

[Jeff Schnitzer]

Sorry, didn't intend to "throw" the whole mail at you.

I haven't been around as long as you (probably a little over a year),
but this is one of my favorite lists.  It's far more entertaining than
television :-)

Jeff Schnitzer
[EMAIL PROTECTED]

> -Original Message-
> From: Paulo Gaspar [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, May 04, 2002 10:00 AM
> To: Jakarta General List
> Subject: RE: You guys are so funny.
> 
> Hey Jeff,
> 
> 
> I can agree with all you say but I don't understand why you throw
> this on my direction.
> 
> I have been defending the existence of competing projects since the
> Tomcat 3.3 versus Tomcat 4 wars until my most recent posts at the
> commons-dev list.
> 
> Maybe you do not follow the same lists I do. Maybe not for long
> enough.
> 
> If you read Jon's postings along this thread, you will also be
> better informed about whom has a thin skin problem.
> 
> 
> 
> Have fun,
> Paulo Gaspar
> 
> 
> > -Original Message-
> > From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]]
> > Sent: Saturday, May 04, 2002 11:59 AM
> > To: Jakarta General List
> > Subject: RE: You guys are so funny.
> >
> >
> > > From: Paulo Gaspar [mailto:[EMAIL PROTECTED]]
> > >
> > > Of course that from the way Jon talks about me you can tell that
> > > I do not always agree with him - Jon seems to only be friendly
> > > to those that agree with him.
> >
> > For the record, I've even committed the cardinal sin of creating a
MVC
> > webapp framework which is not Turbine (http://mav.sourceforge.net),
and
> > Jon is still pretty friendly to me :-)
> >
> >
> > You guys all need to lighten up.  It's not like this is a workplace
> > where everyone is competing for promotions or something.  How this
> > social game plays out isn't going to affect your paycheck or the
people
> > who hang out with you or whether or not you're going to get laid
this
> > weekend.
> >
> > A fair amount of banter is healthy in any community.  Poking fun at
each
> > other, lighthearted insults, competition, and yes conflict are a
> > standard part of any sitcom production.  Sure, there's a time for
"we
> > all love each other" mushy-type stuff but if it was like that all
the
> > time it would get boring really damn fast.  It is my observation
that
> > Apache works because of thick skins, not because of peace, love, and
> > happiness vibes.
> >
> > There's nothing wrong with a limited number of competing projects
under
> > one roof.  It's probably even a good idea.  It's not like Maven and
> > Centipede are competing implementations of the same API - this is
pretty
> > much a research field, and it's impossible to categorically predict
at
> > this point whether it is better to extend or generate the Gump
> > descriptors, or to use XSLT or DVSL, etc.  Until the science becomes
> > engineering, this mad driving need (among some) to "merge merge
merge"
> > is a pathology.
> >
> > Let it be.  Use the software you like.  Write the software you like.
> > Berate people over the truly important things, like choice of text
> > editor :-)
> >
> > Jeff Schnitzer
> > [EMAIL PROTECTED]
> > ed is the *standard* text editor
> 
> 
> --
> 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: You guys are so funny.

[Jeff Schnitzer]

> From: Paulo Gaspar [mailto:[EMAIL PROTECTED]]
> 
> Of course that from the way Jon talks about me you can tell that
> I do not always agree with him - Jon seems to only be friendly
> to those that agree with him.

For the record, I've even committed the cardinal sin of creating a MVC
webapp framework which is not Turbine (http://mav.sourceforge.net), and
Jon is still pretty friendly to me :-)


You guys all need to lighten up.  It's not like this is a workplace
where everyone is competing for promotions or something.  How this
social game plays out isn't going to affect your paycheck or the people
who hang out with you or whether or not you're going to get laid this
weekend.

A fair amount of banter is healthy in any community.  Poking fun at each
other, lighthearted insults, competition, and yes conflict are a
standard part of any sitcom production.  Sure, there's a time for "we
all love each other" mushy-type stuff but if it was like that all the
time it would get boring really damn fast.  It is my observation that
Apache works because of thick skins, not because of peace, love, and
happiness vibes.

There's nothing wrong with a limited number of competing projects under
one roof.  It's probably even a good idea.  It's not like Maven and
Centipede are competing implementations of the same API - this is pretty
much a research field, and it's impossible to categorically predict at
this point whether it is better to extend or generate the Gump
descriptors, or to use XSLT or DVSL, etc.  Until the science becomes
engineering, this mad driving need (among some) to "merge merge merge"
is a pathology.

Let it be.  Use the software you like.  Write the software you like.
Berate people over the truly important things, like choice of text
editor :-)

Jeff Schnitzer
[EMAIL PROTECTED]
ed is the *standard* text editor

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

RE: You guys are so funny.

[Jeff Schnitzer]

> From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> 
> I really wonder why it is that all one has to do is say "Microsoft" on
> any Apache thread and they get 100 responses.  I wonder if it works
that
> way on whatever-microsoft-related-lists are out there.

Someone needs to update Ellison's Law, s/Hitler/Microsoft :-)

Jeff Schnitzer
[EMAIL PROTECTED]

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

RE: You guys are so funny.

[Jeff Schnitzer]

Dude, do you really need to respond to *every single* piece of mail?

Jeff

> -Original Message-
> From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 02, 2002 5:51 PM
> To: Jakarta General List
> Subject: Re: You guys are so funny.
> 
> [part bazillion deleted]

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

RE: Subproject Proposal - crossdb

[Jeff Schnitzer]

> From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]]
> 
> on 4/22/02 12:19 AM, "Leo Simons" <[EMAIL PROTECTED]> wrote:
> 
> > While these may not be accurate summaries, I hope you now do see
that
> > CrossDB and Torque are not, in the majority of use cases,
alternatives
> > to one another.
> 
> I'm sorry. I don't see that. Torque can do everything crossdb can do
and
> more.

Uhhh:  Outer joins?  Fetch data across multiple objects?  Aggregation
queries?

Torque is an O/R mapping framework, with all of the inherent limitations
of trying to make relational data look like objects.  Crossdb is a
database-independent abstraction of SQL (not JDBC, that's an important
distinction!).  

These are not competitive facilities; in fact they should be highly
complementary.  At the moment, Torque's extremely limited Criteria
object has a tough time with simple conditions like "WHERE bob > 5 and
bob < 10".  Subqueries and joins are hopeless.

Crossdb is what Torque desperately needs - a good database-independent
way of specifying sophisticated conditions.  The WhereClause in Crossdb
could be substituted wholesale for Criteria.

And for those of us that have to query our databases and obtain results
which do not map 1-to-1 with a single object (such as anything that
involves a group by or an outer join), we can bypass Torque and still
have database independence.

I think both Torque and Crossdb (if it has the community) are very much
needed as top-level Jakarta projects.  They are both bread-and-butter
server development tools.  Putting Crossdb under Torque makes about as
much sense as putting Torque under Turbine.

Oh, and Jon, the comparison with ECS is not very good.  Web pages are a
creative endeavor, whereas SQL statements are short and built by
hard-core programmers.  Also, simple HTML does not suffer from the
problem of every web browser on the planet requiring a slightly
different syntax for putting columns in a table... Velocity might be
less useful if a separate template had to be written for every single
web browser.

Jeff Schnitzer
[EMAIL PROTECTED]

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

RE: Managing versions of Apache Jakarta software

[Jeff Prickett]

On Fri, 29 Mar 2002, Danny Angus wrote:

> Morning,
> 
> I wrote:
> > > I'm not qualified to put forward any suggestions
>

That doesnt stop most people, including myself from replying ;)
 
> Sam replied:
> > I respectfully disagree.
> 
> Thanks Sam, I'll now bore you with my own opinion, and see if you change
> your mind.. ;-)
> 
> I believe that there are two conflicting forces at work within Jakarta
> regarding cross sub-project dependancies,
> 
> The first is the desire of individual sub-projects to provide their general
> users (the people who make the sub-projects' existence worthwhile) with a
> single distributable file from which a full working install can be made.
> James and Turbine(which has a version including tomcat) are examples of
> this. This gets positive feedback from users who want a shallow learning
> curve and a fast track to deploying the application.
>

We are going to try to aim for the single distributable file for 
periodicity, which should have a 0.0.1 release soon. For projects like 
turbine and James where you can literally lose users in five minutes if 
they get too frustrated this makes sense.

 
> The second is the worthy and intelligent notion (exemplified by GUMP) that
> no cross project dependancies should be satisfied by an individual
> sub-project.
> This is based on the notion that to do so will inevitably lead people who
> are installing more than one sub-project to have to maintain duplicates of
> some API's that are depended upon (is there a word for that?) by more than
> one sub-project, logging and ant for instance. Tomcat source distributions
> are an (admittedly poor) example of this in that they don't distribute ant,
> but the build depends upon it, there may be better examples.
>

I think that there 
is a growing trend among some projects to have test suites using JUnit. 
Perhaps there will come a day when Gump could automatically build every 
project AND run all the tests associated with every project. This could be 
done by having components that support tests defining a well-known Test 
that would call all tests for that component. Kind of like knowing http is 
port 80. Gump could run the well-known junit test automatically. If 
enough Apache projects used JUnit tests then Gump would not only be able to 
tell us if a build is broke but also if functionality has been affected...

I know I am a dreamer, but it could happen. The only thing for developers 
in all the sub-projects to do is agree on the name of the well-known 
test and implement a JUnit test suite with that name and we would all be 
one step closer to ending jar hell...
 
> I don't know how this helps to clarify the situation, but I expect a
> "Jakarta registry" is probably required, and the ability for sub-projects to
> define their classpaths as part of their installation procedure. In which
> case a manifest reading ant task could ensure dependancies are satisfied
> without sub-projects having to bundle them.
> 



Thanks Jeff Prickett


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

RE: Comments on the commons-logging API

[Jeff Schnitzer]

> From: Morgan Delagrange [mailto:[EMAIL PROTECTED]]
> 
> Yes, the defining advantage to the commons-logging API that I see is
that
> it
> allows users to adopt a single logging implementation, which confers
real

What needs to be appended to that statement is "...if everyone codes to
the commons-logging API".  The exact same statement can be reconstructed
using "Log4J API" and it is equally true.

If everyone uses commons-logging, then only one logger must be
configured.  If everyone uses Log4J, then only one logger must be
configured.  If third-party software is using different loggers, then
you have to configure multiple loggers no matter what API your code
uses.

It seems to me that the commons-logging API just adds Yet Another
Logging API... especially when someone gets the bright idea to make a
"native" implementation of the API for performance reasons.

At least with Turbine, Struts, (Maverick :-), etc, there are some
fundamentally different approaches to the problem of how to publish a
web application.  Logging doesn't seem that complicated.  The massive
duplication of this basic feature in the Jakarta codebase is silly, and
trying to build an abstraction layer on top of it seems even sillier.

Jeff Schnitzer
[EMAIL PROTECTED]

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

Re: subproject layout conventions

[Jeff Turner]

On Wed, Mar 27, 2002 at 03:23:35PM -0800, Jon Scott Stevens wrote:
> on 3/27/02 2:26 PM, "Steven Noels" <[EMAIL PROTECTED]> wrote:
> 
> > All this and more is being tackled (slowly but steadily) in Forrest -
> > and having some Jakarta people involved for cross-pollination would be
> > good.
> > 
> > There's not much yet except for the foundation and build environment and
> > some static site generation, but you could familiarize yourself using
> > http://marc.theaimsgroup.com/?l=forrest-dev&r=1&w=2 and
> > http://cvs.apache.org/viewcvs.cgi/xml-forrest/
> 
> I think Maven will be the pants off forrest and is already further along.

I agree (as much as I like Cocoon and the Centipede build system). Maven
could be a revolution on the scale of Gump.


--Jeff

> -jon
> 

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

Re: Krysalis, Centipede, Generating docs with Cocoon?

[Jeff Turner]

Answered offlist. In the meanwhile, everyone pay homage to the
jakarta-site2 docs:

http://jakarta.apache.org/site/jakarta-site2.html

and acknowledge that anything less ain't good enough for everyday
Jakarta use.

The DVSL-based system that Jason van Zyl mentioned sounds best:

>> Yup, that's my fault. I will remedy the situation with PDFs. A very
>> long time ago before Anakia we had PDFs being produced with
>> stylebook. The Turbine and Velocity docs were actually available in
>> PDF format.  Anakia presented some problems that made it impossible
>> to use the fop stuff we created but that is different now with DVSL.
>> Long story short: you will have PDF docs for BCEL sooner rather than
>> later.


--Jeff

On Fri, Mar 22, 2002 at 01:13:48PM +1100, [EMAIL PROTECTED] wrote:
...
> > Works fine for me. If you had problems, ask on the krysalis-users list.
> 
> It works for me too, but that just builds the existing stuff. If I want to 
> customise it

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

Re: Krysalis, Centipede, Generating docs with Cocoon?

[Jeff Turner]

On Fri, Mar 22, 2002 at 12:10:13PM +1100, [EMAIL PROTECTED] wrote:
> I downloaded Krysalis and Centipede,  hoping to find some easy way of 
> building docs, but I was sorely disappointed. You have to know a ton of 
> stuff about Cocoon, Cocoon's 'book' format (which isn't DocBook), and the 
> other tools involved to even get your head around it.
> 
> If you have to setup and run Cocoon to generate a few HTML files, what's 
> the point? At least the process with site.vsl and site.xsl is documented 
> and easy to set up, and requires no special knowledge, for most commons 
> projects.

export
CVSROOT=:pserver:[EMAIL PROTECTED]:/cvsroot/krysalis
cvs login
cvs co krysalis-centipede
cd krysalis-centipede
chmod +x build.sh
./build.sh docs

Works fine for me. If you had problems, ask on the krysalis-users list.
The doc format is standard Apache document-v10.dtd. You only need to
edit the sitemap if your site has special needs, eg merging XML files
before processing, Docbook -> stylebook, stylebook -> PDF, svg -> .png.
I find that being able to manage the generated site's URI space in one
file is very handy.

--Jeff

> If it's just for L&F, I'd much rather tweak the existing stylesheets.
> --
> dIon Gillard, Multitask Consulting
> Work:  http://www.multitask.com.au
> Developers: http://www.multitask.com.au/developers

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

RE: Micro JakartaOne

[Jeff Schnitzer]

> From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]]
> 
> Also, I'm still willing to show people the club, even if we aren't
doing
> anything...

Definitely!
 
Sorry to hear that a big organized shindig won't happen; a small
disorganized shindig would be fine too though :-)  

Jeff
I just started a new contract, so I'm waaay too overloaded to help
organize.  Sorry.  But I'll help contribute to the revelry :-(

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

News, RSS, blogs, Cocoon (Re: news@jakarta list?)

[Jeff Turner]

On Fri, Mar 08, 2002 at 12:00:11PM +0100, Santiago Gala wrote:
...
> >Then could we perhaps have a news@jakarta list for this sort of thing? A
> >lot of people find announcements like this relevant and interesting.
> >
> On a related (technological) note:
> 
> We Jetspeed people (actually Raphael Lutta) put one year ago RSS 
> channels, for our own purposes of showing them in the demo Jetspeed setup:
> 
> http://jakarta.apache.org/jetspeed/channels/apache.ocs is an Open 
> Content Syndication "feed"
> http://jakarta.apache.org/jetspeed/channels/jetspeed.rss is a channel 
> for Jetspeed
> http://jakarta.apache.org/jetspeed/channels/turbine.rss is a channel for 
> turbine
> 
> The RSS mechanism could be easily used for news and content syndication 
> @apache. Channels can be added, generated, etc. for different projects 
> or activities, and used for dynamic linking to apache news from outside 
> the web site.

Sounds nice. Is this "demo Jetspeed setup" actually live somewhere?

Adding some weblogs as newsfeeds would be good too. Weblogs are
wonderful things. Have a look at http://www.need-a-cake.com/

Any JAMES people lurking here? Would it be possible to rig up a mailet
that wraps incoming posts in XML and makes them available as an RSS feed?
That way we could have an easy-to-use news submission process.

FYI (for those who weren't aware), there's a new xml-forrest project
project at xml.apache.org, specifically for things like this.

Another FYI for Jetspeed people: Cocoon is very much encroaching on your
portal turf ;) See
http://www.need-a-cake.com/stories/2002/02/14/cocoonPortalFirstLook.html


--Jeff

(idling.. friday evening..)


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

news@jakarta list? (Re: Introducing Enterprise Object Broker)

[Jeff Turner]

On Thu, Mar 07, 2002 at 06:03:21PM +, Pier Fumagalli wrote:
> "Paul Hammant" <[EMAIL PROTECTED]> wrote:
> 
> > Folks,
> > 
> > Enterprise Object Broker (EOB) is an application server that tries to a
> > be a simpler EJB container.  It is not complete yet, but we have many
> > demos showing local, remote, and webapp usage.
> 
> Ok. Will we all stop using general@jakarta for advertisement of things which
> are NOT ASF related? Thankyou...

Then could we perhaps have a news@jakarta list for this sort of thing? A
lot of people find announcements like this relevant and interesting.

How is it different from freshmeat? It's that 'community' thing Stefano
goes on about. People have established webs of trust here. EOB is by
Apache people, using Apache code, and that makes it *relevant*.


--Jeff

> Pier
> 
> 

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

RE: [VOTE] ASL vs. GPL page: is this okay?

[Jeff Schnitzer]

> From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> 
> The question is: "How do you want to spend your time?"
> 
> Possible answers:
> 
> 1> Fighting an "unwinnable" (defined as the argument having a logical
> conclusion where one side overwhelmingly wins) religious war with the
> GNU hordes (hirds? hurds? ;-) ). . .
> 
> 2> Coding and documenting

There are quite a few people around here who spent an awful lot of time
working on #2 because they weren't successful at #1.  If the WebMacro
folks hadn't stuck to the GPL, it would not have been necessary to
reinvent it as Velocity.

IMHO, evangelizing the APL is an important goal of the Apache project
precisely because it reduces the amount of (re)coding and
(re)documenting we will ultimately have to do.  I applaud Jeff's
document, and I would love to see the finished version linked off the
main Jakarta page (as well as www.apache.org).

Jeff Schnitzer
[EMAIL PROTECTED]

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

Re: [VOTE] ASL vs. GPL page: is this okay?

[Jeff Turner]

On Wed, Mar 06, 2002 at 07:47:49PM -0500, Andrew C. Oliver wrote:
> My opinion is you've come across just about as objective as Richard
> Stallman would be in the Microsoft Beta testing program.  

:-> Pretending to be objective is not my strong point.

> No offense but this is EXACTLY the opposite of what is needed.  Way too
> inflamatory, partisan and counter-productive to the target of just
> "explaining to the confused" as to what the differences are.  

My aim was not to give an exhaustive comparison. The O'Reilly and Perens
pages do it much better than I could. I wanted to give an
Apache-flavoured introduction to the debate, by introducing the main
issue (GPL virality) and showing how that conflicted with Apache's
community-orientedness. And then link to the real thing.

> I kinda think the link off of the Apache Manual was fine...

+1

--Jeff

> -Andy
> 
> On Wed, 2002-03-06 at 16:46, Jeff Turner wrote:
> > Hi,
> > 
> > As promised, I've written up an "ASL vs. GPL" page, for possible
> > inclusion on jakarta-site2.
...

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

Re: [VOTE] ASL vs. GPL page: is this okay?

[Jeff Turner]

On Wed, Mar 06, 2002 at 11:38:42PM +0100, Ceki Gülcü wrote:
> 
> Jeff,
> 
> Kudos for having the courage to proceed with this. Comments inline.

:) It's not easy or fun.

> At 08:46 07.03.2002 +1100, Jeff Turner wrote:
...
> >Why prefer the ASL to a copyleft license (eg GPL)?
> >--
> >
> >This is an slightly distasteful topic for most Apache developers. The license
> >is simply not a central part of the Apache philosophy. Apache is
> >about creating communities that create great software. The ASL is a
> >minimum legal necessity that allows us to do this, nothing more. It
> >promotes no political axe-grinding, and has no great philosophy that
> >needs defending. The ASL, in fact, presents such a small
> >conversational target that any licensing debate inevitably becomes
> >"what is wrong with license X". That inevitably leads to
> >misunderstandings, holy wars and bad feeling, It's not productive,
> >and not fun, and why we find licensing debates distasteful.
> 
> The license is very much part of the Apache philosophy. It may even embody the
> essence of the philosophy.

The license says, basically, "do what you wan't, but don't sue us, don't
abuse our name, and give credit where credit is due". That isn't much of
a philosophy ;) It hints at the underlying importance we attach to the
Apache name, but that's all.

> No need to be apologetic about discussing licensing.

Not apologetic, just reflecting a general lack of keenness for licensing
debates, because they usually end up in unproductive GNU-bashing.

> A good license is more valuable than a million lines of code.  I maybe
> exaggerating but only a little.
> 
> >In particular, it's not fun rubbishing the GPL. The reader is
> >encouraged to read the GNU's philosophy pages
> >(http://www.gnu.org/philosophy/). It is wonderful, high-minded stuff
> >that most programmers instantly resonate with.  Opposing RMS's vision
> >of Free Software at first seems to be like kicking a puppy.
> >
> >But let's kick it anyway. It turns out that the puppy soon grows up
> >to be a bulldog, biting and tenaciously hanging on to any code it
> >can. Due to the GPL's extensive scope and 'viral' linking rules,
> >GPL'ed code cannot be incorporated into proprietary software. It must
> >all be copylefted, or none of it can be.
> 
> A bulldog? :-)

Something with teeth :) But yes, bad analogy; will be removed.

> >In many cases, we at Apache find the GPL's virality a hindrance in *our* goal:
> 
> to (not in) *our* goal?

agreed

> >creating communities that create code. This is because large parts of our
> 
> that write code?

okay

> >"community" are selling custom solutions, not shrink-wrapped products
> >sold in volume for general consumption. Essentially, selling
> >software-based services, not software. When you're selling a service,
> >releasing the code makes no sense to *anyone*. The code is mostly
> >customer- or sector-specific, so is not reusable, and of little
> >interest to fellow developers. The customer *certainly* doesn't want
> >you publicising their code, breaking confidentiality agreements and
> >potentially exposing security flaws to the world.
> 
> Hmm, are you sure we are only selling services? I dunno.

I claimed that "large parts of our community" are selling services, not
software. I don't know how true that is. I *suspect* it's true; that
there are more consultants here than people banging out commercial code.
I could be completely wrong. That's why it's so hard and dangerous to
claim to speak for anyone but oneself.

> Exposing security flaws to the world is very debatable. Most
> cryptographers consider "security-by-obscurity" as bad practice. I
> would drop the exposition argument.

Yes that was very much in my mind :) The detractors of "security through
obscurity" are usually talking about large commercial software. When you
have custom code written in a hurry on a tight budget, security holes
inevitably arise, and security through obscurity is better than nothing.

Though your first impression is how most people will see it, so I agree
it should be removed.

> I found the ethics argument in the Reese-Stenberg article to be very
> powerful.
> 
> The original author has no *absolute* right on extensions and
> improvements.  The fact that I wrote 100 initial lines of code gives
> me no right, moral, ethical or otherwise to impose a license on the
> 10'000 lines that you subsequently write.  I certainly have no rights
> on 10'000 lines of

Re: [VOTE] ASL vs. GPL page: is this okay?

[Jeff Turner]

On Thu, Mar 07, 2002 at 08:46:51AM +1100, Jeff Turner wrote:
> Hi,
> 
> As promised, I've written up an "ASL vs. GPL" page, for possible
> inclusion on jakarta-site2.
...
> Please vote on whether you think the reasons outlined here are
> sufficiently representative. Constructive criticism and change
> suggestions welcome.

On second thoughts...

I'm sure most of us are sick of the whole issue, and are NOT looking
forward to another barrage of email on the subject :-) So preferably,
keep replies to a simple vote and one-line explanation. Constructive
criticism and change suggestions are still welcome, but let's keep that
off-list as much as possible.

--Jeff

 
> --Jeff
> 
> 
> Why prefer the ASL to a copyleft license (eg GPL)?
> --
...

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

[VOTE] ASL vs. GPL page: is this okay?

[Jeff Turner]

Hi,

As promised, I've written up an "ASL vs. GPL" page, for possible
inclusion on jakarta-site2. I've more tried to capture the spirit of the
thing from the Apache POV, than duplicate the detailed arguments in the
O'Reilly article referenced at the end.

Please vote on whether you think the reasons outlined here are
sufficiently representative. Constructive criticism and change
suggestions welcome. If sufficiently approved of, I'll XMLify it and
submit a patch.

--Jeff


Why prefer the ASL to a copyleft license (eg GPL)?
--

This is an slightly distasteful topic for most Apache developers. The license
is simply not a central part of the Apache philosophy. Apache is about creating
communities that create great software. The ASL is a minimum legal necessity
that allows us to do this, nothing more. It promotes no political axe-grinding,
and has no great philosophy that needs defending. The ASL, in fact, presents
such a small conversational target that any licensing debate inevitably becomes
"what is wrong with license X". That inevitably leads to misunderstandings,
holy wars and bad feeling, It's not productive, and not fun, and why we find
licensing debates distasteful.

In particular, it's not fun rubbishing the GPL. The reader is encouraged to
read the GNU's philosophy pages (http://www.gnu.org/philosophy/). It is
wonderful, high-minded stuff that most programmers instantly resonate with.
Opposing RMS's vision of Free Software at first seems to be like kicking a
puppy.

But let's kick it anyway. It turns out that the puppy soon grows up to be a
bulldog, biting and tenaciously hanging on to any code it can. Due to the GPL's
extensive scope and 'viral' linking rules, GPL'ed code cannot be incorporated
into proprietary software. It must all be copylefted, or none of it can be.

In many cases, we at Apache find the GPL's virality a hindrance in *our* goal:
creating communities that create code. This is because large parts of our
"community" are selling custom solutions, not shrink-wrapped products sold in
volume for general consumption. Essentially, selling software-based services,
not software. When you're selling a service, releasing the code makes no sense
to *anyone*. The code is mostly customer- or sector-specific, so is not
reusable, and of little interest to fellow developers. The customer *certainly*
doesn't want you publicising their code, breaking confidentiality agreements
and potentially exposing security flaws to the world.

Thus, to adopt a copyleft license like the GPL would alienate the
service-oriented portion of our community. We want the widest possible
audience, not for "market share", but because the diverse input results in
software with "hybrid vigour", wide applicability and the kind of
tough-as-nails quality we strive for.

Thus, we encourage users to adopt non-copyleft licenses like the ASL for
"everyday" code, as it increases the chances of code sharing and cooperation,
ultimately leading to better software.

For further information, please refer to the well-researched and well-written
O'Reilly article entitled "Working Without Copyleft", at
http://www.oreillynet.com/pub/a/policy/2001/12/12/transition.html
A good general reference of open source licenses is Bruce Perens' book "Open
Sources: Voices from the Open Source Revolution" at
http://www.oreilly.com/catalog/opensources/book/perens.html


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

Re: ASL vs. GPL page?

[Jeff Turner]

On Tue, Mar 05, 2002 at 12:39:20PM +, Pier Fumagalli wrote:
> "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote:
> 
> > You must realize that there are different objectives.  It is the goal of
> > GNU to get all software to use the GPL.  It is not a goal of Apache to
> > get all software covered by the APL.  We're programmers, not lawyers.
> 
> That's why I wouldn't be "that" comfortable with a "Why GPL sucks" page...
> Political propaganda? Looks really like it... And IMO that's not what we're
> here to do... We're here to write software...

.. and if that software is already written, but under the GPL?

a) rewrite the code.
b) try to convince the authors to adopt a more liberal license.

I'd say a normal course of action is to attempt b), and then default to
a). This is what happened with the Webmacro saga, resulting in Velocity.

I will write a small patch for jakarta-site2. A paragraph or two, no GNU
bashing, simply "we feel the ASL has these practical advantages:..",
and a reference to the oreilly article, and we can vote on that.


--Jeff

(thanks also Andrew, Ceki, Danny and others who replied; I agree 100%
with your general sentiments, and hope to express them in the patch)

> Pier
> 

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

ASL vs. GPL page?

[Jeff Turner]

Hi,

Is there a page somewhere at apache.org, explaining why anyone would want to
switch from GPL to ASL? The GNU.org site paints a very inspiring picture of a
world of Free Software. It would be nice if there was an Apache equivalent
somewhere explaining the Apache philosophy. This could be used as ammunition by
people trying to "convert" useful GPL'ed projects. I'm sure many Jakarta
members have found themselves in this situation.

Personal perspective: I know I was quite shocked when I first heard someone
here say "GPL sucks" (back in fighting-with-webmacro days:). I didn't know how
to take it. What kind of philistine wouldn't want RMS's vision of Free Software
to come true? It took me a long time (as a university student) to understand
why the GPL truly does suck as a license for business use.

So, a) is there anything out there already, and b) if not, anyone want to
volunteer? :) I'm not very qualified, but could certainly provide something for
a "testimonial" section.

Here's a starting resource:

http://www.oreillynet.com/lpt/a//policy/2001/12/12/transition.html

"Working Without Copyleft

  It's possible to be an ardent supporter of open source development
  and not be a fan of copyleft and the General Public License. In this
  article the authors -- software developers -- relate how they came to
  embrace copyleft, became disillusioned with its limitations, and
  consequently turned away from it.
"

--Jeff

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

Re: contributing to Jakarta

[Jeff Turner]

On Tue, Feb 26, 2002 at 10:53:08AM -0800, Joe Labbe wrote:
> Hello Everyone -
> 
> I am working on a project porting one of the oldest dynamic content
> servers to the Java platform. The WebDish Presentation Server was
> originally released in 93, and in 95 was named as the platform of
> choice by Charles Schwab for their transition to the web. Since then,
> the marketplace has been flooded with other solutions, and I'm trying
> to see if I can inject new life into WebDish by integrating it with Java
> technology.
> 
> I have discussed with my employers the benefits of developing a project
> as an open source product. As their interest was in the original version
> 
> in C, I am confident I can convince them to release rights to the Java
> version. What I want to know is: would there be any interest from the
> Jakarta program in including WebDish as one of their subprojects?

How about starting off at Sourceforge first?

WebDish sounds like an interesting, ahead-of-it's-time product. It seems
that because of it's pioneering nature, it has it's own alternatives to
the now-prevalent standards ("servitons" instead of servlets, .jpn
instead of JSP). In principle, I think most people here would stick with
the industry standards implemented by many app servers (notably Tomcat),
rather than those concocted only for WebDish. The Servlet API is also
one of the nicest to come from Sun, so a proprietary alternative would
have to be *very* good to capture any developer mindshare.

I'd say, abandon WebDish and instead apply the lessons learned to build
something equivalent on top of Tomcat+Turbine/Cocoon. The result may not
be as architecturally coherent, but it is much likelier to attract
developer mindshare, and ultimately be profitable for your company. It's
also more fun working in teams than soldiering on on your own, as a lone
cathedral-builder, ignoring the world and in turn being ignored.
Developers of your caliber are very very welcome at Jakarta ;)

--Jeff

(whose opinions are highly uninformed when it comes to WebDish, and
apologises if they're based on misunderstandings)

> 
> Joe Labbe
> [EMAIL PROTECTED]
> 
> 

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

RE: Java is dead... but it could still be saved!

[Jeff Schnitzer]

Those license terms are for the Microsoft "Shared Source" implementation
of .NET, which MS is building on FreeBSD.

The Mono implementation is not based on the Microsoft code and is not
encumbered by their license restrictions.  The runtime is GPL'd, the
classes are covered by the MIT X Consortium license.

You are perfectly free to write commercial applications for Mono without
paying a dime to Microsoft.  You are perfectly free to fork the Mono
codebase if you really want to.  Mono runs on Linux.

I'm definitely going to be looking into it soon.

Jeff Schnitzer
[EMAIL PROTECTED]
(sorry about the duplicate link to J#)

> -Original Message-
> From: Fernandez Martinez, Alejandro
> [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 05, 2002 9:10 AM
> To: 'Jakarta General List'
> Subject: RE: Java is dead... but it could still be saved!
> 
> Hi Stefano,
> 
> > -Mensaje original-
> > De: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
> [...]
> > My position: give me a solid (possibly GPL-ed) CLI implementation, a
> > Java2C# porting tool, a BSD-licensed library of .NET classes and
> > java-cloning classes and I say let's kiss java good bye.
> 
> And you will be a tinkerer, able to create a non-commercial bare-bones
> application in two seconds. For more, you will have to pay Microsoft.
> 
> "This implementation is intended to meet the needs of academics,
> researchers, curious tinkerers, and those who wish to build
independent
> versions of the proposed ECMA standards."
> 
> Courtesy of Sam Ruby:
>
http://www.microsoft.com/partner/products/microsoftnet/SharedSourceCshar
pC
> LI
> FAQ.asp
> 
> "The Microsoft .NET Framework and its accompanying C# compiler are a
> commercial product, and have features not found in the ECMA working
> drafts."
> [...] "The source code to the .NET Framework will be available under
> Microsoft's Shared Source Licensing Framework-see
> http://www.microsoft.com/sharedsource for more details."
> 
> Is that acceptable for an Apache developer?
> 
> Un saludo,
> 
> Alex.

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

RE: Java is dead... but it could still be saved!

[Jeff Schnitzer]

> From: Scott Sanders [mailto:[EMAIL PROTECTED]]
> 
> Stefano, you are right on the mark as usual.  As soon as a java2c#
> porting tool is available, the hordes will probably be moving on...

Actually, forget a porting tool.  I want an open-source version of
something like this:

http://msdn.microsoft.com/visualj/jsharp/beta.asp

Jeff Schnitzer
[EMAIL PROTECTED]

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

RE: [ot] J2EE considered harmful

[Jeff Schnitzer]

> From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> 
> On Fri, 2002-02-01 at 09:19, Alef Arendsen wrote:
> > So what's the score? DotNet is the new Microsoft initiative, and -
as
> always - they've perfectly imitated J2EE and have had a good look at
all
> J2EE's pitfalls. USed J2EE as a basis and extended it in a very very
very
> good way (ok, little bit devil's advocate here). So maybe that's the
next
> thing.
> >
> 
> Yeah, the catch is being tied to their unstable insecure platform.

There is a great quote attributed to Winston Churchill:

Woman to Churchill:  "You're drunk!"
Churchill to Woman:  "And you, madam, are ugly.  But I shall be sober in
the morning."

Unstable and insecure is fixable.  Proprietary is not.  There are
projects like Mono which offer a platform not required to answer to any
single corporation.  You cannot say the same for the J2SE, and vastly
less so the J2EE.

Not that I'm suggesting everyone in Jakarta should drop Java and start
.NET development, but don't harbor illusions about the technology you're
using.  It serves the interests of Sun, not "the community".

Jeff Schnitzer
[EMAIL PROTECTED]

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

RE: [OT] RE: J2EE considered harmful

[Jeff Schnitzer]

> From: Steve Downey [mailto:[EMAIL PROTECTED]]
> 
> Most objects don't work if they are made distributed without careful
> consideration.

I wonder if that has to be the case.  Right now, our distributed object
containers are blissfully stupid.  We (humans) can point at any
individual class or interface and say "remote thyself!" but that's as
far as it goes.  The container just does what we programmers tell it to.

Just like me, a hypothetical "smart container" could make some pretty
educated guesses about where and when a set of existing objects should
be remoted.  Furthermore, it could automatically learn, over time, not
only where the best boundaries are, but what are the best situations to
perform the remoting/migration.  Instead of deciding which classes
should be remote, a smart container could decide which *objects* should
be remote.  And it could "learn" the answers by watching object behavior
over time.

Of course, architecture would still have a big effect on performance -
but it does already, even in a single-machine environment.  We don't
hand-optimize our assembly anymore, and suspect that eventually we won't
be hand-optimizing our distributed systems, either.
 
JADE and Mobile Agents are not quite what I have in mind.  The "agent"
concept is very thread-centric, whereas this idea is object-centric.  It
sounds like EOB and AltRMI are closer to the mark.  I'm going to have to
take a long look, and maybe try to restart this discussion on one of
their mailing lists :-)

Jeff Schnitzer
[EMAIL PROTECTED]

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

RE: J2EE considered harmful

[Jeff Schnitzer]

> From: James Strachan [mailto:[EMAIL PROTECTED]]
> 
> (*) One thing I've noticed with SOAP is that developers from the
different
> camps (web/MOM, CORBA/EJB) seem to see SOAP as different things. The
> web/MOM
> guys tend to think of SOAP as a universal message format so the same
> structured message can pass across many transports http/email/news/MOM
to
> connect anything to anything in a language, platform and transport
neutral
> way which is kinda cool. CORBA/EJB guys seem to view SOAP as, well its
> CORBA
> but using XML rather than IIOP and go off building stubs/proxies/IDL
> compilers etc just like with EJB/CORBA.

I don't think web/MOM/SOAP and CORBA/EJB are comparable technologies.
The former are communication protocols, and the latter are (primarily)
programming APIs.  To emphasize this point, in the .NET universe, the
remote invocation protocols are pluggable... you can write to their
distributed object model API and use SOAP, DCE-RPC, IIOP, JRMP, SMTP, or
just about anything else you can dream up.  For that matter, there is no
reason why you couldn't create an EJB container which used HTTP/SOAP as
the transport protocol.

I would compare EJB to the programming API for your SOAP or MOM
implementation.  Theoretically EJB (or any distributed object model)
provides a high-level abstraction so you don't need to fuss with the
complexity of all the protocols and mechanisms underneath.  Of course,
the tradeoff is flexibility and performance.  The problem with EJB,
IMHO, is that it has merely replaced the complexity of the underlying
system with the even greater complexity of the EJB system, and still
significantly inhibits your ability to write well-performing
applications.

Jeff Schnitzer
[EMAIL PROTECTED]

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

RE: J2EE considered harmful

[Jeff Schnitzer]

> From: Micael Padraig Og mac Grene [mailto:[EMAIL PROTECTED]]
> 
> Are you just talking about creating a new language, or what?  What is
your
> idea?  I cannot tell.

That's a good question, and ultimately one which would be determined by
the constraints of the technology.  Prototyping would probably involve
using an existing language and platform, and maybe we would ultimately
discover that it is possible to build a system like this on top of a JVM
(or CLR).  My suspicion is that it is not, and may be undesirable for
legal reasons anyways.

The later part of my diatribe was a hastily phrased way of approaching
this subject:

Unless you want to go back to the dark ages of C++, the future is
shaping up to look like a choice between writing for the Sun platform or
the Microsoft platform.  This does not make me comfortable, especially
considering that Sun's approach to Java so far has been *wholly*
anathema to the principals of Open Source.  At least Microsoft has
submitted C# and the CLI to ECMA.  Quoth Jon: *WAKE UP PEOPLE*

I am tantalized by the idea of a third choice:  the Apache platform.  I
propose a discussion of just what that might be.

Jeff Schnitzer
[EMAIL PROTECTED]

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

RE: J2EE considered harmful

[Jeff Schnitzer]

Amusingly enough, I've been considering writing an article with this
exact same title.  I've implemented two medium-sized systems using EJBs
(http://www.similarity.com and http://mav.sourceforge.net/pig) and I've
been haunting the ejb-interest list for more than a year.  I was never
ecstatic about the technology, but now I'm starting to feel downright
disillusioned with it.

This is not coming from someone stumbling around with the technology.
The first thing I did was read Richard Monson-Haefel's book
cover-to-cover, and I started with EJB2.0 (pd1) when Orion was the only
implementation.  I've got most of the 2.0 spec memorized.  I have no
trouble writing the deployment descriptors by hand.

The problem is, even after more than a year of this, I still find that
writing software using EJBs is a steady progress of fighting the
technology to make it do what you want.  It shouldn't be like this.

Having to write three or four different classes, plus an elaborate
deployment descriptor for each object slows things down a bit.  Tools
like xdoclet help, but it's still a complicated and painful process to
refactor anything.

Basic software design patterns are agonizing or impossible to implement.
Observable?  Time to learn JMS and Message-Driven Beans.  Singleton?
Not in the framework... you have to set up an external RMI server.

Presistance in the EJBland is a disappointment.  Even with EJB 2.0,
entity beans are not remotely mature.  There is no support for
relationship attributes or automatically generated primary keys.  The
query language is constrictive, offering no support for ordering,
aggregation functions, or retrieving data which spans more than a single
class.  After 20+ years of research and advancement in RDBMS technology,
this is a colossal step backwards, and the consequence is that entity
beans radically underperform systems with more direct database access.
I find that I must constantly sidestep the container with direct JDBC in
order to meet performance or feature requirements, and it sounds like
this is a common problem.

Overall, my feeling is that Sun tried to cram too many disparate
technologies into a single API.  EJB!  It's a distributed object model,
transaction model, security model, persistence model, component model,
message queue, desert topping, and floor wax all rolled into one!  Some
of it makes sense, but some of it (especially persistence) doesn't.

I'm surprised that people can build large applications with EJB.  My
guess is that it's probably very effective for one particular class of
problem - ecommerce apps.  I'm sure it's no accident that all the
examples in the spec are Order, LineItem, etc.  Unfortunately, this
doesn't help me, or any of the rest of the people who are working on
applications that are actually interesting.  And my guess is that since
ecommerce is 90% of the market for expensive app servers, Sun doesn't
really care.


Ok, enough whining.  What to do about it?  I really like the idea of an
Apache community building a truly free competitor to J2EE.  I don't like
being tied to technologies owned by a single company, so I'm already
pretty nervous by the stranglehold that Sun has on Java and (especially)
J2EE.  But it's not enough to build a marginal improvement over the
existing system, even with Apache's mindshare.  Besides, who wants to
copy a mediocre idea? :-)

I've been giving a lot of thought to distributed object models lately.
I've worked with DCOM, CORBA, RMI, and EJB, and for the most part it's a
lot of the same.  Since networks are getting so fast these days, I'm
starting to really wonder what it would be like to have a model in
which:

* All objects are inherently remotable.
* Objects transparently migrate for efficiency.

I can think of many interesting, fairly revolutionary consequences of
such a system and I'd love to discuss them.  Ultimately, if such a
system ever made it out of research and into prototype, it could
challenge both Java and .NET, and possibly stave off the coming hegemony
of the Sun/Microsoft duopoly.  (Yeah, yeah, there will always be people
who enjoy working on nonvirtual machines, but they're crazy :-)

Does anyone think some variant of this idea to be worth pursuing?  Or is
everyone wedded to the idea of working on the proprietary Sun platform
known as Java?

Jeff Schnitzer
[EMAIL PROTECTED]

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

Re: ECS?? _TOP_ level project of Jakarta??

[Jeff Prickett]

Scott Sanders wrote:
> 
> Calendar is much more apropos in JAMES IMHO.  I think that JAMES could
> become an Exchange killer :)
> 

Good point, I would accept that place as a home for the back end
objects. Possibly split
iCalendar between JAMES and Jetspeed or make it its own module that
plugs in to either.
Front end - Jetspeed, Back end JAMES. I would like to see Apache create
an Exchange killer, but that talk is premature :).

Jeff Prickett


Rest of converstion

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

Re: ECS?? _TOP_ level project of Jakarta??

[Jeff Prickett]

Ceki Gulcu wrote:
> 
> In your opinion, what are the key factors in nurturing a developer
> community?
> 

I know what does not nuture a development environment.
1. Working in a vacuum and hoping someone magically finds out.
2. Mispresenting (Intentionally or Unintentionally) the status of the
project.
3. Not having a clear vision of what features we want to see and when.

Actually, I am going to put my flame suit on before I say this, but I
was reading an MS Press book by Jim McCarthy (VC++ manager) called
Dynamics of Software Development. He outlines 50 some odd "rules" of
software development.

One rule is to have a Multi-release technology plan. Its just a big word
for a document that outlines which features will be available in what
release or in what time frame. Ideally, this document should have the
buy in of the whole development team.

I think what Mr. McCarthy is trying to do with the Multi-Release plan is
to create Vision. Great communities development or otherwise share a
common vision.

The multi-release technology plan serves two purposes. It establishes a
vision and then breaks it down into a set of smaller steps which are
easier and less frustrating to accomplish.

When I have a community of developers around icalendar. I am going to
borrow a page from the MS playbook and create a Multi-release technology
plan.

> --
> Ceki
> 
> > It is very easy to monday-morning quaterback and second guess the
> > decisions that were made in the distant past with perfect 20-20
> > hindsight.  Some might even find it amusing to single out some of the
> > participants and try to act as the judge, jury, and executioner of
> > that person's reputation in the court of public opinion.
> >

It is easy to play Monday morning quarterback. One of the reasons I
stayed away so long was the initial dread of trying to explain what had
happened (why I "quit", why iCalendar had
failed).



Jeff Prickett

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

Re: ECS?? _TOP_ level project of Jakarta??

[Jeff Prickett]

"Geir Magnusson Jr." wrote:
> 
> On 1/29/02 7:02 AM, "Endre Stølsvik" <[EMAIL PROTECTED]> wrote:
> 
> >
> > | What's the point?
> > |
> > | They will still always be separate communities in separate CVS repositories.
> > |
> > | Let me put it another way : what problem are we trying to solve?
> >
> > Me coming to the front page and trying to understand what Jakarta is all
> > about. "Browsing" it.. Reading about all the cool technologies that's in
> > there.
> >
> > |
> > | That people have trouble finding out what's here? That's something we need
> > | to address on the website, I think.
> >
> > Yes.
> >
> 
> Good.  We agree :)
> 
> > |
> > |
> > | > 2) If a guy that's already within Jakarta decides that he'll make a nice,
> > | > thight, _small_ little library, it seems like getting it into Jakarta just
> > | > takes a cvs commit. Even top level.
> > |
> > | No way.  I'm a guy in Jakarta.  I have commit privs to Velocity, Commons and
> > | a small section of Turbine, and the main site, IIRC.  That's it.
> >
> > I was kind of kidding there. But it does look like it's easy to get a
> > project accepted at Jakarta if you already have "some control" over the
> > community.
> 
> Example?  Stefano pushed to get POI in, and there was *huge* pushback.
> 
> 
> >
> > [..] | The point is that even as part of the 'management committee' of
> > | jakarta, I have no special privs.  And I think that is the right way,
> > | BTW.
> >
> > I basically try to point out that I think this isn't the case now..
> >
> > People from "the outside" is met with a very hostile attitude if they ask
> > whether this or that project could interest/supplement Apache/Jakarta,
> > while people (or.. Jon?) on the inside says "yo, dudes, what about me
> > stuffing this little lib toplevel onto jakarta?".. "Ok, that's 5 minutes
> > response time, it's now in place."
> 
> Can you offer an example?
> 
> > | > While if fantastically cool projects
> > | > that are outside of Jakarta wants to get in, it's about impossible.
> > |
> > | Come on.  This year we started Commons and added Lucene, BCEL, POI.
> >
> > How much cooler isn't the idea of POI compared to ECS? BCEL? And how much
> > more hassle and stress did the POI dudes have to go through, compared to
> > ECS?
> 
> Don't know about ECS - that was something from java.apache.org days, I
> think, and I suspect just grandfathered in.
> 
> Seems right to me.
> 
> And I am not saying that because I am a jakarta guy, or Jon is my friend, or
> anything like that.
> 
> In the evolution of Jakarta, java.apache.org came before - it makes sense to
> keep the continuity.
> 
> > | What 'fantastically cool projects' want to get in?
> >
> > BCEL and POI are the ones I'm especcialy pointing towards here.
> 
> Both are in...  What is the argument again?
> 
> 
> > | > (Corollary (?!): Jon Stevens' vote is about 10 times bigger than
> > | > everybody elses.)
> > |
> > | Nope.  Some of us just tend to listen to him...
> >
> > I know.
> >
> >
> > As a complement to this: how is the "deprecating" system of Jakarta? If a
> > project "dies", that nobody seems to update it, the list dies or something
> > like this, does it die away from Jakarta too?
> 
> It seems to - look at the calendar project :)
> 

As we speak I am trying to restart the calendar effort. I think that I
have a point to
make here in this forum. First a lot of these sub-projects are spun off
from other projects iCalendar originally started in Jetspeed. The same
is true for Torque and Fulcrum. They started in Turbine.

One reason calendar died is because, there is no community around it. It
was just me contributing to jetspeed. One of my first goals as a
developer with calendar this time is to get more people involved. It is
not that easy.

Thanks
Jeff Prickett



> --
> Geir Magnusson Jr. [EMAIL PROTECTED]
> System and Software Consulting
> "We will be judged not by the monuments we build, but by the monuments we
> destroy" - Ada Louise Huxtable
> 
> --
> 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: The future of java-icalendar

[Jeff Prickett]

"Andrew C. Oliver" wrote:
> 
> On Sun, 2002-01-27 at 23:17, Peter Donald wrote:

> +1, proper encapsulation should include EJB functionality for those who
> desire it while not requiring it for those who do not.  There is also a
> matter of licensing involved there.
> 

Thanks, I guess you are right. Requiring EJB is quite a lot.

I would like to take this time to formally request that the
java-icalendar module be moved over to the jakarta-commons sandbox and
that my apache commiter account be reinstated so that I can commit the
new code into cvs.

Once we have the new source code in place I will contact all the people
who have emailed me about the project over the last year and tell them
to join the commons mailing list if they are still interested.

In the meantime I will be preparing the website with an initial set of
project guidelines, documentation, and continuing to work on the code.

Thanks for your input. Now back to listening

Jeff Prickett


> www.superlinksoftware.com
> www.sourceforge.net/projects/poi - port of Excel format to java
> http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
> - fix java generics!
> 
> The avalanche has already started. It is too late for the pebbles to
> vote.
> -Ambassador Kosh
> 
> --
> 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: The future of java-icalendar

[Jeff Prickett]

Peter Donald wrote:
> 
> Hi,
> 
> On Mon, 21 Jan 2002 07:38, Jeff Prickett wrote:
> > I would like to name the project Periodicity.
> > I would like to utilize the EJB architecture and support most of the
> > major EJB containers starting with JBoss of course.
> > I would like to use JUnit to write Unit Tests for the project
> 
> I would highly recomend you have a look at XDoclet stuff (on sourceforge)
> aswell ... (Im just reading through the docs and it is brilliant).
>
> > I have begun writing the project guidelines and have started building
> > the project website.
> > I have rewritten the API to take full advantage of Java 2 Enterprise
> > Edition.
> > I have saved the email addresses of most of the people who have emailed
> > me regarding the icalendar project in the last year.
> > I have begun personally responding to email inquiries about icalendar.
> >
> > My questions are this:
> > Would ASF accept my sincere apology and work with me to help make the
> > project viable?
> 
> I doubt the ASF holds grudges ;) and a fully operationaly ICalendar compliant
> product would be a very good addition to Jakarta. The problem mainly is that
> you don't have a community about your product. While it used to be a product
> at java apache you would effectively be proposing a new project. And
> accoridng to the guidelines at
>

When I quit programming at ASF it wasnt really a decision I made to
quit. It was more like things kept keeping me from contributing. After a
while I became to self-consicous to try and come back. Then ASF servers
were hacked and I could not even logon as all passwords had been
changed.
 
> http://jakarta.apache.org/site/newproject.html
> 
> you don't yet satisfy them.
> 
> So what I would suggest you do is propose/add the product to the commons
> sandbox. When it becomes stable enough you can propose it be moved to commons
> proper and when you get a large enough community about it you can propose it
> to be a top-level jakarta project.
>

I will formally propose that they be added today, later in the day.
 
> > Would periodicity be an acceptable name for the project?
> 
> It's up to you but I like it ;)
> 
> > Can I base the iCalendar objects on EJB technologies?
> 
> You *can* but I suspect it will make your job of attracting a community
> harder. It would be much more widely useful if it did not require EJB
> technologies and I suspect iy would thus be much easier to attract more
> developers. If at all possible I would suggest making it run in non-EJB
> environments but thats completely up to you ;)
>

I had a hard time deciding this myself and am not sure that EJB is the
way to go, but part of me wants to push the envelope with this. 

It goes back to a lesson I learned about a year and a half ago when I
was still working. Do not be ignorant of industry trends. One of my
reasons for wanting to use EJB is that
I dont want people to outgrow the product. I have gotten a wide range of
responses from all types of people from college students all over the
world to IT professionals at large corporations and everywhere in
between.

If I chose EJB I am probably going to spend a lot of time explaining it
to newcomers, it is a lot more complicated than non-EJB, but it will be
based on what is fast becoming the industry standard for server side
components.

To be honest I am not sure, but I might try EJB if no one bites than I
might have to 
rethink my strategy.

 
> > Is the IBM Public License compatible with Apache license? (Can I use
> > Junit for testing?).
> 
> Yep - this is fine and plenty of other projects use Junit at Apache (Just
> remember to put the license into the CVS).
>
> Anyways good luck - I hope you decide to stay and hopefully it will get
> enough exposure and a big enough community to get it off and going ;)
> 
> --
> Cheers,
> 
> Pete
> 
> *--*
> | "Computers are useless. They can only give you   |
> |answers." - Pablo Picasso |
> *--*
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <

Thanks for the words of encouragement. Back to programming for me.

Sincerely,
Jeff Prickett

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

The future of java-icalendar

[Jeff Prickett]

Hello Apache Software Foundation Community:

I have previously donated a large chunk of time to starting the
java-icalendar module which I had to stop maintaining about a year ago.
This was because of personal reasons. I would like to publicly apologize
to the ASF for not continuing the project.

I would like to restart the project and take the initial steps to make
java-icalendar a full-fledged jakarta project. During the last month I
have begun rewriting the icalendar module to get it ready for release. 

I would like to name the project Periodicity.
I would like to utilize the EJB architecture and support most of the
major EJB containers starting with JBoss of course.
I would like to use JUnit to write Unit Tests for the project

I have begun writing the project guidelines and have started building
the project website.
I have rewritten the API to take full advantage of Java 2 Enterprise
Edition.
I have saved the email addresses of most of the people who have emailed
me regarding the icalendar project in the last year.
I have begun personally responding to email inquiries about icalendar.

My questions are this:
Would ASF accept my sincere apology and work with me to help make the
project viable?
Would periodicity be an acceptable name for the project?
Can I base the iCalendar objects on EJB technologies?
Is the IBM Public License compatible with Apache license? (Can I use
Junit for testing?).

You can take a peak at the revamped code base at
http://www.shpimp.com/apache.

Thanks All...

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

Re: Commons Validator Packaging/Content

[Jeff Turner]

On Tue, Jan 08, 2002 at 10:48:42AM -, Danny Angus wrote:
>  Jon wrote:
> 
> > My opinion is that there are to many peers in the process and that is what
> > is breaking Jakarta. This wasn't a problem until now. We are starting to
> > explode under our own ever growing weight.
> 
> I've been involved in other organisations that tried, from best intentions,
> to have a non hierarchical structure.
...

This is a meritocracy. In some projects, the 'merit slope' is so steep
you could ski down it :) Don't let the lack of obvious hierarchy blind
you to the very strong internal hierarchy. Even if people are cheeky to
Jon, they know where on the slope he sits ;)


--Jeff

> 
> d.

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

Avalon, Commons, once again (Re: Commons Validator Packaging/Content)

[Jeff Turner]

On Tue, Jan 08, 2002 at 09:29:18PM +1100, Peter Donald wrote:
...
> > To drive this point home, the subject line of this thread identifies
> > exactly one such set of duplication - between Turbine and Struts.  My
> > nagging lead Berin to propose moving the Avalon collections code into
> > commons, to which you responded, and I quote, "+/- 0".
> 
> I was hoping Jeff would do it as he seemed to be involved over there ;)

I saw the "+/- 0", and that Berin hadn't voted, and then thought of how
this would look to Commons people: as a code "dump"; abandoned by it's
authors, singlehandedly maintained by someone who might disappear at any
moment (from their POV; I'm not going anywhere;). Quite a big ask.

Though if you're okay with it (forking is a bit.. impolite:), I'll make
an attempt sometime late Feb (after holidays.. wheee).

> I have no time atm and no real motiviation to do it. Last time I was
> on the list I watched 3 things be proposed to commons - nobody even
> voted !!! There was no response whatsoever. Apparently Jeff has
> similar comments when he offered some of the avalon bits over there.

'twasn't Avalon code, but yes.. it pains me to think of all those XML
doctype decls flying around, unchanged.. ;)

The lack of project-wide sense of responsibility is the biggest problem
for Commons (and jakarta-taglibs, incidentally). It's something I aim to
help solve the old-fashioned way.

> * I no longer care about duplication and wheel reinvention (it will happen 
> anyway)

Yep, to a degree. Though without a simultaneous commitment to document
the resulting forks/duplications and preferably cull the old code, then
Jon's worst predictions will come true and we can kiss Jakarta goodbye
now. 

> > You can say all you want that you predicted how commons would turn out -
> > but lack of participation by people such as yourself have made such
> > predictions self fulfilling prophesies.
> 
> Heres what sucks about commons;
> 
> 1. People who are not associated with codebase nor ever contributed to it get 
> voting rights over codebase (who needs meritocracy anyways)

Has that turned out to be a problem in practice? Say if you think so,
and we can propose a modification to the charter: "The votes of those
who haven't committed to a project are non-binding".

> 2. Stable packages still have to go via sandbox and go through that whole 
> painful voting process (yet more non-contributors getting votes over codebase)
> 3. Im not a committer

You are. 'donaldp' listed for jakarta-commons and
jakarta-commons-sandbox.


--Jeff

> Change (1) and I will migrate the majority of excaalibur across in time (and 
> bitch and moan till (2)/(3) is changed). Change (1), (2) and (3) and I will 
> move stuff across tomorrow (though still take time to actually do releases).
> 
> -- 
> Cheers,
> 
> Pete
> 
> ---
>  "Remember, your body is a temple; however, it's also your 
>  dancehall and bowling alley"   -- Dharma Montgomery
> ---
> 
> --
> 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]>

Avalon, Commons, once again (Re: Commons Validator Packaging/Content)

[Jeff Turner]

On Tue, Jan 08, 2002 at 09:29:18PM +1100, Peter Donald wrote:
...
> > To drive this point home, the subject line of this thread identifies
> > exactly one such set of duplication - between Turbine and Struts.  My
> > nagging lead Berin to propose moving the Avalon collections code into
> > commons, to which you responded, and I quote, "+/- 0".
> 
> I was hoping Jeff would do it as he seemed to be involved over there ;)

I saw the "+/- 0", and that Berin hadn't voted, and then thought of how
this would look to Commons people: as a code "dump"; abandoned by it's
authors, singlehandedly maintained by someone who might disappear at any
moment (from their POV; I'm not going anywhere;). Quite a big ask.

Though if you're okay with it (forking is a bit.. impolite:), I'll make
an attempt sometime late Feb (after holidays.. wheee).

> I have no time atm and no real motiviation to do it. Last time I was
> on the list I watched 3 things be proposed to commons - nobody even
> voted !!! There was no response whatsoever. Apparently Jeff has
> similar comments when he offered some of the avalon bits over there.

'twasn't Avalon code, but yes.. it pains me to think of all those XML
doctype decls flying around, unchanged.. ;)

The lack of project-wide sense of responsibility is the biggest problem
for Commons (and jakarta-taglibs, incidentally). It's something I aim to
help solve the old-fashioned way.

> * I no longer care about duplication and wheel reinvention (it will happen 
> anyway)

Yep, to a degree. Though without a simultaneous commitment to document
the resulting forks/duplications and preferably cull the old code, then
Jon's worst predictions will come true and we can kiss Jakarta goodbye
now. 

> > You can say all you want that you predicted how commons would turn out -
> > but lack of participation by people such as yourself have made such
> > predictions self fulfilling prophesies.
> 
> Heres what sucks about commons;
> 
> 1. People who are not associated with codebase nor ever contributed to it get 
> voting rights over codebase (who needs meritocracy anyways)

Has that turned out to be a problem in practice? Say if you think so,
and we can propose a modification to the charter: "The votes of those
who haven't committed to a project are non-binding".

> 2. Stable packages still have to go via sandbox and go through that whole 
> painful voting process (yet more non-contributors getting votes over codebase)
> 3. Im not a committer

You are. 'donaldp' listed for jakarta-commons and
jakarta-commons-sandbox.


--Jeff

> Change (1) and I will migrate the majority of excaalibur across in time (and 
> bitch and moan till (2)/(3) is changed). Change (1), (2) and (3) and I will 
> move stuff across tomorrow (though still take time to actually do releases).
> 
> -- 
> Cheers,
> 
> Pete
> 
> ---
>  "Remember, your body is a temple; however, it's also your 
>  dancehall and bowling alley"   -- Dharma Montgomery
> ---
> 
> --
> 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: Proposal: Component survey

[Jeff Turner]

This idea was (is) part of the Commons charter:

  "(1.5.2) the directory 

   The subproject will also catalog packages and other resources
   available to the public related to other Jakarta subprojects and ASF
   projects.  This will be a dynamic catalog, like Bugzilla and Jyve,
   similar in functionality to download.com, cpan.org, or
   SourceForge.net.  New entries may be added by Jakarta committers,
   developers, and users.  Entries by developers and users will be
   approved by a committer before being made public."

   -- http://jakarta.apache.org/commons/charter.html


So if you want to do this, Commons is the place to do it. I volunteer to
do the Avalon bits (Berin outlined the reusable stuff recently).

--Jeff


On Tue, Jan 08, 2002 at 05:19:48AM +0200, Kief Morris wrote:
> I've been meaning to trawl through the jakarta subprojects looking for 
> components that could be suitable for using in a project of mine. It
> occurs to me that having an inventory of components could be a useful
> thing for Jakarta, both for general developers who may be overwhelmed
> by what's there, and to make Jakarta subproject developers more aware
> of what's available so they can avoid duplication.
...
> Kief

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

Jakarta code search engine? (Re: crushed)

[Jeff Turner]

On Mon, Jan 07, 2002 at 05:59:51PM -0800, Jon Scott Stevens wrote:
> on 1/7/02 5:10 PM, "Paulo Gaspar" <[EMAIL PROTECTED]> wrote:
> 
> > I see you crying a lot over this but no POSITIVE initiative.
> 
> That is because I don't see a way to fix the problems and I'm not sure I
> have the energy to actually go through with it anymore.
> 
> I haven't seen you give any positive initiative's either.

The idea of a Jakarta code search engine has arisen a few times. Any
lucene or alexandria developers care to comment? Cocoon docs are already
searchable apparently, though this functionality isn't online.

Alternatively, a simple link to Google (restricted by
site:jakarta.apache.org) from the front page might help.


--Jeff

> 
> -jon
> 
> 

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

Re: crushed

[Jeff Turner]

On Mon, Jan 07, 2002 at 03:44:50PM -0500, Andrew C. Oliver wrote:
> Guys,
> 
> This whole experience has become a bit disheartening.  Craig McClanahan
> who is like an idol of mine said this:
> 
> "
> We will continue to do what we've done in the past -- reject projects
> that only want the "name recognition" value of being under Apache, and
> don't have a development community compatible with Apache's style.
> That's much more important than whether it's server-side versus
> client-side, or in one repository versus another.
> "
> 
> Seemingly directed at POI.

I don't see what the problem is. Read it carefully.. for that statement
to apply, POI would have to:

 - _only_ want the name recognition.
 - have a development community incompatible with Apache's style

Do either of those statements apply to POI?

Incidentally, the other statement Craig made in that email sums it all
up for me:

>> The point from Jon that I *do* dismiss is his feeling that there
>> should be one and only one implementation of any particular
>> functionality -- "one size fits all" is a very rare phenomenon in my
>> experience, and having some choice is helpful.

I have _never_ seen a user complain about having too many choices. Not
even between notorious duplications like Tomcat 3/4 and Crimson/Xerces.

I _have_ seen users want comparisons, and better docs to help them make
the choice. 

Choice is good. Documented choice is infinitely better :)

I would encourage people (esp. Jon, Ceki, Peter) to read Linus' emails
on design:

  "The problem with "singlemindedness and strict control" (or "design")
  is that it sure gets you from point A to point B in a much straighter
  line, and with less expenditure of energy, but how the HELL are you
  going to consistently know where you actually want to end up?  It's
  not like we know that B is our final destination."

   -- http://kerneltrap.org/article.php?sid=398


--Jeff

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

Re: crushed

[Jeff Turner]

On Mon, Jan 07, 2002 at 03:44:50PM -0500, Andrew C. Oliver wrote:
> Guys,
> 
> This whole experience has become a bit disheartening.  Craig McClanahan
> who is like an idol of mine said this:
> 
> "
> We will continue to do what we've done in the past -- reject projects
> that only want the "name recognition" value of being under Apache, and
> don't have a development community compatible with Apache's style.
> That's much more important than whether it's server-side versus
> client-side, or in one repository versus another.
> "
> 
> Seemingly directed at POI.

I don't see what the problem is. Read it carefully.. for that statement
to apply, POI would have to:

 - _only_ want the name recognition.
 - have a development community incompatible with Apache's style

Do either of those statements apply to POI?

Incidentally, the other statement Craig made in that email sums it all
up for me:

>> The point from Jon that I *do* dismiss is his feeling that there
>> should be one and only one implementation of any particular
>> functionality -- "one size fits all" is a very rare phenomenon in my
>> experience, and having some choice is helpful.

I have _never_ seen a user complain about having too many choices. Not
even between notorious duplications like Tomcat 3/4 and Crimson/Xerces.

I _have_ seen users want comparisons, and better docs to help them make
the choice. 

Choice is good. Documented choice is infinitely better :)

I would encourage people (esp. Jon, Ceki, Peter) to read Linus' emails
on design:

  "The problem with "singlemindedness and strict control" (or "design")
  is that it sure gets you from point A to point B in a much straighter
  line, and with less expenditure of energy, but how the HELL are you
  going to consistently know where you actually want to end up?  It's
  not like we know that B is our final destination."

   -- http://kerneltrap.org/article.php?sid=398


--Jeff

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

Re: More abuse of coding styles...

[Jeff Turner]

On Thu, Jan 03, 2002 at 05:54:20PM -0800, Jon Scott Stevens wrote:
> It is amazing to me...with all the discussion about coding styles and
> following them, we still have people committing code that doesn't follow
> what rules we do have...
> 
> on 1/3/02 11:00 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> 
> Re: cvs commit: jakarta-commons/logging/src/java/org/apache/commons/logging
> SimpleLog.java
> 
> > +if(_showtime) {

We had that discussion once on Commons, and many people liked the
underscore convention.

> <http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367>
> 
> "Variable names should not start with underscore _ or dollar sign $
> characters, even though both are allowed."
> 
> <http://jakarta.apache.org/site/source.html>
> 
> "All Java Language source code in the repository must be written in
> conformance to the "Code Conventions for the Java Programming Language as
> published by Sun."

Maybe that's what needs changing.. I'd suggest:

"All Java source code _should_ follow the existing conventions
established by that project's committers. Projects are strongly
encouraged to follow the "Code Conventions for the Java Programming
Language" as published by Sun."

Perhaps adding:

"Projects whose coding conventions deviate from the Sun standard must
document the changes, with justifications."

Simply because justifications are always fun to read :)


--Jeff

> -jon
> 

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

RE: commentary by Linus Torvalds

[Jeff Schnitzer]

There seems to be some debate about whether or not that is really the
case.  At least it has Richard Monson-Haefel (the author of the O'Reilly
EJB book) and Floyd Marinescu (from TheServerSide.com) confused, from
this post to ejb-interest a couple months ago:
http://www.mail-archive.com/ejb-interest@java.sun.com/msg19000.html

My take:

While section 10.5.2 maked it look like you can leave the PK unset in
ejbCreate and the container will automatically generate a key for you,
the spec doesn't (that I could find) explicitly specify anywhere that
this is in fact the case.  The wording of section 10.5.2 could be
explained by the use of deferred key types, which could conceivably
provide an akward way of making autogenerated PKs, but only in wholly
container-dependent manner.  In the 1.1 spec, it was necessary to set
the PK explicitly in ejbCreate, so some explanation would seem to be in
order... blah.

Jeff Schnitzer
[EMAIL PROTECTED]

> -Original Message-
> From: Richard Kirby [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 05, 2001 11:54 PM
> To: Jakarta General List
> Subject: RE: commentary by Linus Torvalds
> 
> 
> EJB2 does allow for automatic generation of "freaking primary 
> keys" - unless
> I misunderstood you. Thats one of the points of having ejbCreate and
> ejbPostCreate. Mind you, I personally feel that Torque offers 
> far more than
> EJB, if you are building from scratch and don't have legacy systems.
> 
> Richard
> [EMAIL PROTECTED]
> 
> > -Original Message-
> > From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]]
> > Sent: 06 December 2001 07:28
> > To: Jakarta General List
> > Subject: RE: commentary by Linus Torvalds
> >
> 
> > As a case in point, I would like to point out EJB CMP as an 
> example of
> > "design-driven" technology which may very well look really stupid in
> > another few years, especially given its atrociously slow 
> mutation rate.
> > If anyone who was writing this crap (the spec) was actually 
> *using* it,
> > it would probably allow for automatic generation of freaking primary
> > keys...
> >
> > Jeff Schnitzer
> > [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: commentary by Linus Torvalds

[Jeff Schnitzer]

And for an example of a dead company whose products are gone too, how
about Ashton-Tate (anyone remember dBase?).

I liked Linus' comments.  They essentially echo the arguments for XP,
that software should be evolved rather than Designed (captial-D).  Even
though he was (apparently) talking about Solaris when critisizing Sun,
the same argument indicts the acolytes of the Java Community Process as
well.

As a case in point, I would like to point out EJB CMP as an example of
"design-driven" technology which may very well look really stupid in
another few years, especially given its atrociously slow mutation rate.
If anyone who was writing this crap (the spec) was actually *using* it,
it would probably allow for automatic generation of freaking primary
keys...

Jeff Schnitzer
[EMAIL PROTECTED]

> -Original Message-
> From: Neville Burnell [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 05, 2001 2:22 PM
> To: 'Jakarta General List'
> Subject: RE: commentary by Linus Torvalds
> 
> 
> their products are still around, still evolving, but those 
> corporations
> are long gone
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, 4 December 2001 10:55 AM
> To: Jakarta General List
> Subject: Re: commentary by Linus Torvalds
> 
> 
> Neville Burnell <[EMAIL PROTECTED]> writes:
> 
> > anyone remember Lotus Developments and WordPerfect Corporation ...
> they had
> > billions in the bank too
> 
> 
> Lotus == IBM
> WordPerfect == Corel.
> 
> Still around... just different names :)
> 
> -- 
> Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED],
> [EMAIL PROTECTED] )
>  Location - San Francisco, CA, Cell - 415.595.9965
> Jabber - [EMAIL PROTECTED],  Web - 
> http://relativity.yi.org/
> 
> Yoink dot adios backslash loosers!
> 
> --
> 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: Cross site scripting

[Jeff Schnitzer]

Since CSS vulnerabilities are due to the nature of html presentation, it
seems to me that the presentation layer is clearly the place to fix it.

Storing encoded data is a bad idea, IMHO, because:

You've got to somehow ensure that all input data is channeled through
your encoder.  Sure, this may be easy for web forms, but what about
direct updates or imports to the database?

What happens when you try to use your data in a different presentation
technology such as a Swing or console app?  Trying to de-escape the data
everwhere you use it would suck.

You can escape data for HTML 4.0 and store it... but what about years
from now when HTML 8.0 rolls around and there are new things to escape,
or old things that should be escaped differently?  Reprocess your whole
database?

I think you should always store the data model in as "pure" a form as
possible, and let any particular presentation layer make sure that data
behaves well.  HTML output escaping is pretty computationally trivial,
so performance doesn't seem like much of an issue.  Mixing
presentation-specific encoding into the data model, on the other hand,
is setting up for future peril :-)

Jeff Schnitzer
[EMAIL PROTECTED]

> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 21, 2001 1:20 PM
> To: Jakarta General List
> Subject: RE: Cross site scripting
> 
> 
> Actually I was busy, what I really wanted to say was that I 
> agree with every
> one of the points you make, but still stick to my prefrence 
> for escaping on
> the way in, but ok lets say only where practical.
> I've been involved myself in a project where we had to accept input of
> script and prepare output of it for display or execution.
> And there are a number of other legitimate uses for some of 
> the techniques
> which come under the umbrella of CSS.
> 
> The only truly compatible answer is to delegate to the 
> application designer
> full responsibility for this task.
> 
> Hence, of course, the requirement for a small API to help 
> her/him do the
> dull hard work. (which I'm right behind)
> 
> d.
> 
> 
> > -Original Message-
> > From: Danny Angus [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, November 21, 2001 6:57 PM
> > To: Jakarta General List
> > Subject: RE: Cross site scripting
> >
> >
> > Ok, you're right!
> > d.
> >
> 
> 
> --
> 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: Cross site scripting

[Jeff Schnitzer]

> From: Jon Stevens [mailto:[EMAIL PROTECTED]]
> 
>Does anyone have code they want to contribute to get this started? How
are
>you currently dealing with these issues? What is your favorite way to
escape
>things? Do you filter/escape all content or only some content? Etc.

In the world of XSL, I think these issues are already taken care of.  At
least in a "domified" approach, the data only ever gets translated into
XML as a final step, and the XSL processor automatically escapes
anything that will have XML or HTML meaning.

In the world of JSP, I would expect that bean-access custom tags would
do this escaping.  Do the Struts taglibs or any of the jakarta taglibs
take care of this?

In the world of Velocity... is there a switch that can be set on
Velocity to automatically escape anything with XML/HTML meaning?  Should
there be?
 
Of course, all these effectively disable _all_ htmlish tags, which might
not be wholly desirable... still, it seems to me that that the best
approach is to escape everything and then selectively translate *back*
only the tags you want working (like ).

Jeff Schnitzer
[EMAIL PROTECTED]

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

[ANN] DoctypeChanger: pre-parse DOCTYPE manipulation

[Jeff Turner]

Howdy,

I've written up a Java utility, called DoctypeChanger, that I hope could
be useful to many people who exchange XML documents. I've mentioned it
on jakarta-commons and briefly on general@xml, but I thought I should
introduce it properly:

Probably the first "XML interoperability" issue that many users
encounter is when they are on the receiving end of XML with a DOCTYPE
declaration. Assuming one wants to validate, there are a number of
situations in which your parser will barf:

 - You are offline, or otherwise cannot retrieve the specified DTD.
 - The DOCTYPE declaration's SYSTEM id may be relative to someone else's
   system ("./dtds/foo.dtd").
 - The DOCTYPE declaration's PUBLIC or SYSTEM id might be just plain wrong.
 - If the incoming XML doesn't have a DOCTYPE declaration, there is no
   way to force the parser to validate against a local DTD [1].

In short, the categories are "incorrect", "inaccessible", "non-existent"
and "correct".

By writing a custom EntityHandler or using an entity catalog, one can
deal with "incorrect" and "inaccessible". The remaining case,
"non-existent", is AFAIK, unsolvable with mainstream techniques.

Simon St.Laurent wrote a Java stream filter to solve this, which
replaces or adds DOCTYPE declarations on the fly [1]. I have since
generalized and extended it, so that one can now add, modify, replace
and conditionally replace it (based on the old value).

The documentation (including background, rationale, examples) is
available at:

http://opensource.socialchange.net.au/doctypechanger/latest/apidocs/

And the code can be downloaded here:

http://opensource.socialchange.net.au/doctypechanger/

It's under the Mozilla Public License 1.1, for historical reasons (it's
APL-compatible, right?).

I hope people find this useful :) Feedback very welcome.


--Jeff

[1] http://www.simonstl.com/projects/doctypes/

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

RE: Business-Oriented XML

[Jeff Schnitzer]

Uhhh, let me tell you what comes and goes much more often than
"platform" languages:  scripting languages.  You're proposing to
exchange a widely understood, highly evolved programming language with a
homebrewed scripting language that has a very high likelihood of
becoming nothing more than a blurb in the jakarta-general list archives
in a few years.  The mere fact that your script has an XML form doesn't
inherently give it staying power; hell, I could pretty easily define an
XML form for Java grammar if I wanted to.

Java is obviously not the endpoint of language design, but it does
happen to be about as good as we have come up with so far.  It's a great
tool for defining business logic because it's flexible, fast (enough),
and very widely understood.  It has sufficient critical mass that it
will be around long after you have gotten tired of working on BOX.  So I
don't buy the argument that BOX buys you longevity - the world of
software is littered with dead scripting languages for dead tools.


The problem I have with the BOX concept is that it is a step *backwards*
from all the progress we have been making towards three-tiered
architectures.  The idea of a new scripting language which abstracts the
writing of business logic in some useful way is not bad.  The idea of
binding it tightly to an HTML publishing framework is *terrible*.  You
talk about how important it is to separate business logic from
presentation, yet you seem to have missed the primary *reason* for this
separation - so that the business layer can live on long after any
particular presentation technology is dead and gone.  The point is that
business logic *can* be reused in a Swing client, or as a SOAP service,
or as part of some sort of XML messaging system, or with the Microsoft
Telepathy Mouse, or whatever else comes along.  Tying your business
logic to HTML or HTTP isn't any better than embedding it in JSP pages.

Jeff Schnitzer
[EMAIL PROTECTED]

> -Original Message-
> From: Dave Jarvis [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, November 17, 2001 11:08 AM
> To: Jakarta General List
> Subject: Re: Business-Oriented XML
> 
> Hi, Jeff.
> 
> > I'm with Jon here:  Why the heck would you want to do this?
> 
> See previous reply.  In addition, languages come and go.  Remember
when
> TurboPascal was hot?  QuickBASIC?  C and C++?  Perl?  PHP?  What
happens
> in 5 years when another awesome language makes an appearance and
> everyone forgets Java?  Legacy code, I believe is the term.  COBOL,
> FORTRAN, Smalltalk, etc.  Tying yourself to a language isn't a viable
> long-term strategy.  I love Java, don't get me wrong.  But don't fool
> yourself into thinking it's going to be around forever.  ;-)  (This
> isn't flame bait; I'm using history and nearly 20 years development
> experience as a guide.)  XML, on the other hand, is a technology with
> staying power and a history that extends back into the late 1960s!
> 
> Another reason is that you can write more efficiently in a new
> language.  I've found that BOX source is typically 5 to 30 percent
> smaller than equivalent Java.  It has an extremely tight focus on
basic
> business logic.
> 
> > for defining business logic.  Why?  It's trivial to define such
logic in
> > Java, and doing so avoids the limitations of your script (whatever
they
> > may be).
> 
> The only limits are those imposed by the processing engine's
> implementation language.  (Currently Java, but could be C, C++, Perl,
> etc.)
> 
> Again, coupling yourself to Java (or any language for that matter) is
> not a good thing from a long-term perspective.
> 
> > What if you wanted to use a one-way hash on the passwords?  What if
user
> 
> I had a similar problem already.  The solution:
> 
> 
> 
> So long as "generatePasswordHash" is available to the system (neither
> defined nor imposed), it'll work.
> 
> > information was stored in EJBs or LDAP?  What if you wanted to use
the
> > standard J2EE authentication and role-based security system?  Can
your
> > script handle this?
> 
> This can be solved in either of two ways:
> 
>   1) Set up a small (internal) server that uses an XML-based
protocol
> for
> information exchange.
>   2) Write a wrapper function to extract the information you want
> (e.g.,
> generateHashKey).
> 
> > You can use whatever scheme you would like to test the password,
limited
> > only by your ability to express the behavior in Java.  Furthermore,
it
> 
> 
>   
>   
> 
> 
> As before, not limited to a particular language.  But you might as
well
> use Java, because Java rocks.  :-)
> 
> > this example, the yourHelper object).  How would your system 

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

[Jeff Turner]

(detaching ant-user, where this is very OT)

On Sat, Nov 17, 2001 at 01:12:10AM +1100, Peter Donald wrote:
> Personally I would instead choose to just enhance the jdk1.3 "Optional 
> Pacakge" spec with an extra attribute. (ie Jakarta-Rules: true or something 
> better named) and then just add more fixed rules on interpretation of 
> versions. The reason is that the "Optional Pacakge" spec is used in servlet, 
> ejb and applet containers (and webstart???) atm. It will most likely be 
> incorporated into other specs as time goes on.
>
> It would be much less effort IMO to create a document and magic attribute 
> that described meanings exactly rather than adding another cutdown version 
> which is not used anywhere outside jakarta.

I think we've both been barking up the wrong tree.. mostly me :P

There are two documents mentioning versioning:

1) The "Optional Package" spec:
  The http://java.sun.com/j2se/1.4/docs/guide/extensions/versioning.html

2) The "Java Product Versioning" spec:
  http://java.sun.com/j2se/1.4/docs/guide/versioning/spec/VersioningSpecification.html


The "Optional Package" spec suggests these manifest entries:

Extension-Name: javax.help
Specification-Vendor: Sun Microsystems, Inc 
Specification-Version: 1.0 
Implementation-Vendor-Id: com.sun 
Implementation-Vendor: Sun Microsystems, Inc 
Implementation-Version: 1.0 


The "Java Product Versioning" spec has these:

Specification-Title: Java Utility Classes 
Specification-Vendor: Sun Microsystems Inc. 
Specification-Version: 1.3
Implementation-Title: java.util
Implementation-Vendor: SunMicrosystems. Inc.
Implementation-Version: build57" 


The difference is all in the name/title/id attributes:

 - The "Optional Package" spec defines how one jar can declare a
   dependency on another (to say "I need extension 'javax.help'"). It's
   "Extension-Name" attribute must be a reliable identity.

 - The "Java Product Versioning" spec says nothing about how to specify
   dependencies. Therefore the "Specification-Title" attribute is purely
   informational.


So the questions is, do we want to:

  1) "add fixed rules of interpretation" to one of these attribute sets
  2) define our own attribute set and associated meanings

Assuming 1), which spec? We've both been assuming the "Optional Package"
spec, but I think the "Java Product Versioning" spec is more
appropriate, as it is _intended_ to be general-purpose; it's just
horribly under-specified :)

--Jeff

> On Sat, 17 Nov 2001 01:01, Danny Angus wrote:
> > 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.
> 
> -- 
> Cheers,
> 
> Pete
> 
> --
> Ancient Go proverb: "Only amateurs 
> try to come up with 'fancy' moves"
> --

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

RE: Business-Oriented XML

[Jeff Schnitzer]

I'm with Jon here:  Why the heck would you want to do this?

Ok, you've defined a new XML-based scripting language to replace Java
for defining business logic.  Why?  It's trivial to define such logic in
Java, and doing so avoids the limitations of your script (whatever they
may be).

What if you wanted to use a one-way hash on the passwords?  What if user
information was stored in EJBs or LDAP?  What if you wanted to use the
standard J2EE authentication and role-based security system?  Can your
script handle this?

For the functionality you mention, in typical MVC systems (Struts,
Maverick, WebWork, Turbine), all you need to do is define a JavaBean
something like this simplistic example (using Maverick):

class TestPassword extends ControllerBase
{
  protected String pw = "";
  protected String email = "";

  public void setPassword(String pw) { this.pw = pw; }
  public void setEmail(String email) { this.email = email; }

  public String perform()
  {
if (yourHelper.checkPassword(email, pw))
  return "success";
else
  return "error";
  }
}

You can use whatever scheme you would like to test the password, limited
only by your ability to express the behavior in Java.  Furthermore, it
becomes very easy to encapsulate business logic in
presentation-independent facilities like EJBs or standard JavaBeans (in
this example, the yourHelper object).  How would your system reuse
business logic to build a Swing client?

And about the last point you brought up... how is your system any more
platform, language, or database neutral than Struts, Maverick, Turbine,
or WebWork?

Jeff Schnitzer
[EMAIL PROTECTED]

> -Original Message-
> From: Dave Jarvis [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, November 17, 2001 1:19 AM
> To: Jakarta General List
> Subject: Re: Business-Oriented XML
> 
> Hi, Jon.
> 
> > Why the heck would you want to do this anyway? You have to be nuts
to
> write
> 
> To begin with, it is a very simple stepping stone for moving old
systems
> that don't scale well (e.g., FoxPro) to one that does.  The system I'm
> working with has hundreds of tables, some with tens of thousands of
> rows, others with over thirty million; not hand-coding the SQL is out
of
> the question.
> 
> > SQL by hand anymore and why would you want to embed it into your
code
> > anyway?
> 
> Embedding the SQL in this fashion creates a tight modular unit that
> performs one piece of the entire site's functionality.  For example,
> consider logging in: a relatively simple task.  The user enters their
> e-mail address and password using an HTML form.  To verify that they
got
> it correct, one would write:
> 
> [File: /logic/Login/main.xml]
> 
> 
> 
> 
>   * FROM USERS WHERE EMAIL=? AND PASSWORD=?
>   
> 
> 
>   
>   
> 
> 
>   http://www.yahoo.com'"/>
> 
> 
> 
> 
> In this fashion, no other part of the system needs to know how the
login
> functionality works.  Also, since the code is interpreted, you can
> change the SQL as required while the system is running.
> 
> How would you write the following functionality:  A web page is
> presented to the user with an HTML FORM composed of two TEXT INPUT
boxes
> (named email and password; with no hidden fields).  They fill in their
> information and now the system must verify it -- simply, easily, and
> quickly.  Please show me a simpler means to perform this task.  Once
> that's done, please make the solution platform, language, and database
> neutral.
> 
> > You guys have totally lost touch with simple concepts like 'MVC'...
> 
> The Database is the Model.
> The Logic is the Controller.
> The XSL is the View.
> 
> I fail to see what I'm missing.  Please enlighten me!
> 
> Sincerely,
> Dave Jarvis
> 
> --
> 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: Business-Oriented XML

[Jeff Turner]

On Fri, Nov 16, 2001 at 08:58:06PM -0800, Dave Jarvis wrote:
> Hello, again.
> 
> Neeme Praks wrote:
> > Have you ever had a look at Apache Cocoon project? That achieves all the
> 
> Yes.
> 
> > benefits you outlined in your paper plus more.
> 
> Here are a few items BOX addresses that Cocoon does not (as far as I can
> discern; please correct my errors):
> 
>   o doesn't provide an inherent state-based architecture (it's an aside,
> not focus)

Nope, they threw out the "reactor" (state machine) pattern as being too
hard to manage.

>   o doesn't automatically apply a different view of logic based on the
> domain

Certainly can :) Have a look at Cocoon 2's class
org.apache.cocoon.selection.HostSelector.

>   o extremely complex; it mixes multiple languages and odd syntax (e.g.,
> &connectDatabase)

That's just your particular XSP, which uses an XML entity
"&connectDatabase;" to pull in other XSP. If you put your logic in
logicsheets as intended, then your XSP pages are pure XML.

>   o makes it easy to couple presentation and logic (see below)

Actually, XSP makes it easy to mix *content* and logic (presentation is
in XSLs).

>   o lacks an integrated expression parser
>   o doesn't expose a consistent syntax for doing tasks such as:
>   - file I/O
>   - sending XML to remote servers

Have a look at Cocoon 2's xscript SOAP demo (xscript being an XSP
equivalent of James Strachan's xtags taglib).

>   - calling native code (Java, C, Perl, etc.)
>   - SQL statements
>   o cookies, FORM parameters, and URL encoded variables are not treated
> uniformly
>   o doesn't use plain XML (i.e., embeds other language source directly)

Anyway, if you've got time, hop on cocoon-dev.. I'm sure there's much
mutual learning to be had (it's a fun place to lurk anyway). Cocoon 2
has a very generic architecture, and I've no doubt that your code could
be integrated as an XSP alternative.


--Jeff

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

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

[Jeff Turner]

(was getting off-topic for ant-user)

On Fri, Nov 16, 2001 at 09:36:24AM +0100, Markus Kohler wrote:
> Hi, 
> 
> > -Original Message-
> > From: Peter Donald [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, November 16, 2001 12:19 AM
> > To: Ant Users List
> > Subject: Re: How do you version jar files?
> > 
> > 
> > On Fri, 16 Nov 2001 09:47, Conor MacNeill wrote:
> > > Scott,
> > >
> > > There are a number of ways to version jars depending on your taste.
[..]
> > > 4. Add a manifest entry to the jar.

[..]
> 
> If Java would have a standard for this  (I haven't found one) it would
> be really cool to support this with an Ant Task.

Java's official versioning spec [1] seems curiously irrelevant. It talks
about API specifications, and implementations thereof; not the sort of
scenario most people deal with. It's primary use-case seems to be
applets (it amuses me how Sun documents can be dated this way;)

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.

Btw, note the difference between "Class-Path:" and "Package-depends:".
One specifies physical jar names (a brittle, error-prone solution), and
the other specifies logical, abstract dependencies. This "abstractness"
would allow jar taxonomies to be defined; eg:

Package-depends: jaxp-parser, 1,1

would be satisfied by any JAXP 1.1-compatible parser.

Then one could have an abstract-to-physical-dependency mapping tool, to
translate "xerces, 1.4.3" to wherever you keep your 1.4.3 xerces.jar. An
init script or custom ClassLoader could then make use of this info, so
you'd no longer need 15 xerces.jar files on your harddisk :)

alexandria-dev folks (JvZ, SamR, Geir,..): think of this as proposing a
"guaranteed substratum" of jar metadata, which Gump, JJAR etc can use.


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.


--Jeff


[1] http://java.sun.com/j2se/1.4/docs/guide/extensions/versioning.html

[..]
> 
> Markus

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

Re: The CEO

[Jeff Turner]

On Sun, Sep 02, 2001 at 07:48:05PM -0700, Tal Dayan wrote:
> 
> For all the Microsoft lovers (and not so lovers) in this list. Take a look
> at http://tal.ontero.net/home/Mocrosoft. This is a 1:15min mpeg file showing
> Steve Balmar shouting, dancing and getting the Microsoft crowd excited.

Is this the one that appeared on theregister.co.uk?

"""

Ballmer's screen test for Planet of the Apes

  We find it hard to believe that Microsoft CEO Steve Ballmer failed to
  get a major part in simian costume for Tim Burton's remake of Planet
  of the Apes with this command performance... 

http://www.theregister.co.uk/content/archive/20840.html
"""

And if you were thinking Steve Ballmer is one scary dude, you're not
alone.

http://www.theregister.co.uk/content/archive/20228.html

;)

--Jeff

> Tal

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

Re: ANN: Java Project Environment, a simple way to manage multiple projects

[Jeff Turner]

On Mon, Jul 02, 2001 at 10:11:28AM -0700, Jon Stevens wrote:
> on 7/2/01 4:54 PM, "jeff" <[EMAIL PROTECTED]> wrote:
> 
> > Hope someone finds it useful. I tend to jump between a lot of projects,
> > and it's has saved me quite a lot of time.
> > 
> > --Jeff
> 
> I'm confused. Why not just use Ant to manage your classpath?

Primarily because invoking Ant every time I want to recompile one file
is too slow. Jikes takes milliseconds; Ant takes seconds.

The secondary reason is because often I want to prototype something, and
don't have an Ant build.xml file set up.

Hopefully this will change when Peter Donald's Ant 2, with incremental
builds, takes over the world. For now, using this in conjunction with
Ant gives you the best of both worlds.

--Jeff


> I haven't set a real $CLASSPATH in about 2 years.
> 
> [152][ ~ ]% echo $CLASSPATH
> .
> 
> -jon
> 
> 
> -
> 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]

ANN: Java Project Environment, a simple way to manage multiple projects

[jeff]

This may be of interest to other *nix Java developers..

http://newgate.socialchange.net.au/~jeff/jpe/

Here is a summary, from the docs:

 "[The JPE is] a simple system for working on multiple Java projects
 under GNU/Linux, in particular for managing project classpaths.
 ..
 One of the most painful aspects of Java programming, particularly for
 new programmers, is dealing with classpaths. Every project requires a
 set of jars, which must be listed in the $CLASSPATH variable before the
 project compiles or runs. Of course, every project requires a different
 set of jars. Since there is only one classpath, fixing it is a frequent
 chore.
 ..
 A solution: nested shell-based environments

 The idea (and I'm sure it's pretty old..) is to start a new shell,
 inside your current one, when you start working on a project. The
 Subshell" can be customized in project-specific ways. Specifically,
 the $CLASSPATH variable is automatically populated with jars from
 certain directories (eg lib/), and directories containing classes (eg
 src/java/).
 ..
 Here's what happens when one enters the project subshell:

   jeff@expresso:~$ cd myproj/
   jeff@expresso:~/myproj$ proj.sh 
   -
Java Project Environment: version 1.24, 2001/06/28 12:46:49
   -
   Proj name:  My wonderful new project
   Proj alias: myproj
   Proj author:Jeff Turner
   Proj description:
   
   This fictitious project exists solely to illustrate the JPE
   
   -
   Adding directories to classpath
   Adding /home/jeff/myproj/src
   Adding /home/jeff/myproj/src/java
   Loading jars from /home/jeff/myproj/lib
   Adding /home/jeff/myproj/lib/jaxp.jar
   Adding /home/jeff/myproj/lib/xalan.jar
   Adding /home/jeff/myproj/lib/xerces.jar
   Setting cdc alias to src/java/org/myco/myproj
   
   [jeff@expresso myproj ~]$ 
  
 ..
 ..
 When you start a project subshell:

* The $HOME variable is reset to point to the project root.
* The prompt ($PS1) is customized to include the project name.
* jars from various predefined and user-specified directories are added to
  the classpath.
* predefined and user-specified directories are added to the classpath (if
  present).
* Project aliases are set up.



Hope someone finds it useful. I tend to jump between a lot of projects,
and it's has saved me quite a lot of time.


--Jeff

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

RE: Let the games begin...

[Brekke, Jeff]

The O'Reilly interview is also interesting.  Talk about control.

http://www.oreillynet.com/pub/a/dotnet/2001/06/27/dotnet.html

-
Throw away my code, but never, never throw away my tests.
-
Jeffrey D. Brekke   Quad/Graphics
[EMAIL PROTECTED]  http://www.qg.com
-



> -Original Message-
> From: Jon Stevens [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 27, 2001 2:17 PM
> To: [EMAIL PROTECTED]
> Subject: Let the games begin...
> 
> 
>  es_shared-sour
> ce_strategy_1.html>
> 
> As previously predicted, M$ is starting to play the game 
> where they give out
> the source code for their C# language as well as port it to non-OSS
> platforms...
> 
> One more thing to notice is the OSS M$ platform of 
> choice...FreeBSD...not
> Linux. Duh. 
> 
> Sun still doesn't have an official JVM for FreeBSD...even 
> though it is the
> #1 RFE...by an astonishing amount...
> 
> 
> 
> -jon
> 
> 
> -
> 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: How times change !!

[Jeff Schnitzer]

> From: Alex Fernández [mailto:[EMAIL PROTECTED]]
> 
> I wonder: when Microsoft announces things like those, do they 
> even take
> it seriously (since everyone knows they'll cancel it later)? Do they
> hire people? Allocate time for the tasks using Project? Even draw a
> PowerPoint or two to show around?

Actually, I think all of the products mentioned in the article
materialized.  The COM support in the MS JVM was (and still is) really
cool.  The IDE mentioned has several features that NetBeans still lacks
(like syntax checking as-you-type and a startup time shorter than
Ellison's droning speech at J1).  Compared to VB or VC++, J++ was pretty
nice.  It (and the MS JVM) are pretty antiquated these days, but the
products looked like they had a bright future before the Sun lawsuit
pushed them into the development of .NET.

Jeff
- Suddely realizing that he said something polite about MS, and that the
room got very, very quiet :-)

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

Re: Directory layout feedback

[jeff]

On Thu, Mar 15, 2001 at 11:02:27AM +1100, Conor MacNeill wrote:
> Ceki,
> 
> I would like to give you some feedback on the common directory layout
> http://jakarta.apache.org/site/dirlayout.html
> 
> This is mostly from my Ant perspective and somewhat from my impression of
> some other common practices in the Jakarta sub-projects. I do realize that
> these are just recommendations.
[..]
> build directory
> 
> Many of the Jakarta projects put the build files in the project's root
> directory and use the build directory for build results, such as build
> classes which will be jarred up into the distribution
> 
> build/lib
> ==
> If this is a non-binding recommendation, I don't see why it supports two
> locations to put the binary jars. It should either be lib or build/lib,
> IMHO.

Not sure what the intention with /lib and /build/lib was, but I have found it
useful to make this distinction:

/lib# compile-time jars
/src/lib# run-time jars

Eg, ant.jar, stylebook.jar and junit.jar are compile-time dependencies. Having
two /lib directories simplifies the creation of binary distributions that don't
require compile-time jars.


--Jeff

> Cheers
> Conor

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

Re: [NOTICE] + [PROPOSAL] nightly builds + nightly source checkouts

[Jeff Martin]

>
>IMHO Gump serves a different, also valid, purpose as a tinderbox detector
>of incompatibilities.
>
>The goal of nightly builds is different -- it is to create something that
>ought to be marginally usable.  For that reason, a nightly build would use
>a stable Ant (for example), instead of hot-off-the-CVS code that Gump
>uses.
>
>That being said, it might well be possible to tweak the Gump scripts so
>that they operate in a different mode for nightly builds.  Sam?
>


Gump probably can be tweaked to do this. The other option is Alexandria
which supports Ant builds, but as yet doesn't really support tinderbox.
http://staff.synamic.co.uk/~jmartin/ Currently only setup to build
Alexandria and Ant but builds docs for everything else (well most things)

>> Comments?
>>
>> -jon
>>
>
>Craig McClanahan
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>


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

RE: Nightly builds

[Jeff Martin]

Little history,
about 6 months ago I added build support to Alexandria. It seemed to
make sense that since I wanted to test build and Alexandria already had a
means getting hold of the source from cvs without to much hassle it seemed
good to just added in the ability to kick off a build.xml file is there was
one.

This mean where I work we have a hourly process that checks out all the code
and builds it (also runs JUnit tests) and produces a nice html page with
shows any build errors in red. This works pretty well, what it doesn't
provide is confirmation that any interproject dependencies are not being
broken buy code which is in development, this is important information for
some people but distracting for others who what information on how their
changes are affecting their code not how other peoples affect their code.

Enter Sam and Gump,
at the same time Sam was working on Gump which allows him to see
where dependencies between development version of projects. A good example
of how this is useful is the relationship between Alexandria and Castor
thanks to Gump Sam was able to identify a change in the behavior of Castor
which made is slightly stricter in the way it processed xsd files. This
meant one of the files in Alexandria was failing to build properly, because
we had warning of this prior to the release of the next version of Castor
Sam was able to fix the problem (Cheers for that Sam, I was a bit slow on
the uptake there). Brilliant we've caught and fixed a problem before it even
occurred.

Today,
I'm looking at how to integrate the sets of code Gump and Alexandria
part of this is making sure that both styles of build (checks against
release and dev code) are supported and it is easy to have both type running
at the same time. The other side of this is to look at the differing ways in
which the actual build is handled. Alexandria used to be based around bash,
but it became clear that Using Ant throughout the process was a better way
to handle things. I personally would like to see Gump go the same way, but I
don't want to through out the baby with the bath water so we're not just
going to abandon Gump as it stands at the moment.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 15 February 2001 20:07
To: [EMAIL PROTECTED]
Subject: Re: Nightly builds


Hi Sam,

I (think ) I got gump to work, it's not updating/building. There are few 
issues/sugestions. I tried to find the alexandria list ( I assume the
discussion on gump happens on alexandria ), I'm sure it is somewhere and
I'll keep searching :-)

Anyway - it would be possible to switch tomcat3.x nightly builds to use
gump, with few small changes in the project definition. 

The main issue is that (IMHO) you should relax a bit the
dependencies: a number of projects had  releases, and I think other
projects should depend on the (stable) release of those projects.

For example, tomcat, servletapi, etc should depend on released-ant-1.2,
not jakarta-ant, etc. 


Whenever a project has a major release - we should of course update the
scripts to make all projects depend on the latest "stable" and fix all
projects that are in development mode to match the latest "stable".

Given that each project has independent release cycle, I don't think it's
normal for a stable release of a project to depend on a development
release of another project ( for example, tomcat 3.3 shouldn't depend on
the dev. release of ant - but on the latest "stable" ant. If ant1.3 will 
be released before 3.3 is "frozen", then tomcat3.3 should be fixed to
make sure it works with ant 1.3 - if not, it should stay dependent on
the released ant 1.2 ).

This can be resolved by adding "project/released-ant-12.xml", etc.

Another issue - wouldn't be better to generate build.xml instead of
build.sh and build.bat ? Most of the code inside build.sh can be done
easily in a "super" build.xml that calls ant. It is even possible to
use  tags to start different VMs. 

I think this would be easier to maintain and enhance.

Another think - one planned feature for tc3.x build was a mechanism to
triger a build from a web page ( so if someone does a change, he doesn't
have to wait until the next night to find out if it brakes something ). 
My plan was to use the  taglib ( that is also used to run the tests
from a web page ) and write a simple build.war that will allow runs of 
the build from the web. 
That would also allow a lot of simplification ( since wars are
self contained and have a stable environment/structure ). It would also
modularize a bit the build ( a page to update a repository, a page to
build, no more "echo \", etc )

Finally: it would be nice if the build scripts would get the sources using
 instead of . 


Costin


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

-

Re: Test Infrastructure Project Proposal

[Jeff Martin]

Just thought I'd throw a couple of points into the mix. Personally I'm a big
fan of JUnit, you do have to use it propely though.

It's designed to be used by programmers, the idea being you actually write a
test which exersises a method before you actually write the method itself.
The idea is that this focuses the programmer on what the method is supposed
to be doing and you know when the method is finished when the test you've
already writen passes. As such it's a pretty low level way of testing, so
it's very good for testing compontents but doesn't really help when it comes
to testing whole systems.

JUnit tests are designed to be run in no specific order, in some ways this
is good, in some ways bad. One things I have descussed with colleagues in
the past is developing a layer on top of JUnit which allows scripting of a
series of JUnit tests to exercise a usecase. Never actually did anything
about it though ;o) to much like hard work.

One thing that might be work looking at is http://httpunit.sourceforge.net/
which is an extension to JUnit for handling http tests.

Other thing I should probably mention it that Alexandria has for sometime
now supported using JUnit for automated testing. This is a feature we use
where I work so that we can check on a daily basis that all code is building
successfully and also passes all the unit test which have been written.

- Original Message -
From: Sam Ruby <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, February 11, 2001 11:38 PM
Subject: Re: Test Infrastructure Project Proposal


> Jon Stevens wrote:
> >
> > I will try one more time before I ask Sam to go
> > down to your office an explain it to you.
>
> I've been to his office.  Suffice it to say that he has about as thick of
a
> head as, well, some of the people around here.  ;-)
>
> > Lets use Sam as an example here:
> [snip]
>
> Good example, as far as it goes.  The rest of the story is that the bulk
of
> my work was layered on top of Ant.  I'm in the process of joining forces
> with another incubator project (Alexandria) to complete this work.
>
> - Sam Ruby
>
>
> -
> 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: Using contents of Jakarta CVSROOT?

[Jeff Turner]

Cool :) 

Attached is some documentation on what all the scripts do, and
step by step instructions for installing the whole system on a new CVS
repository.

--Jeff


On Sun, 4 Feb 2001, Jon Stevens wrote:

> on 2/4/01 12:03 AM, "Jeff Turner" <[EMAIL PROTECTED]> wrote:
> 
> > Hi,
> > 
> > I'd like to use the Jakarta CVS access control and commit emailing for a
> > company CVS server. This is the stuff get get if you run 'cvs checkout
> > CVSROOT'.
> > 
> > There isn't any indication that the files are under the APL (or any
> > license), so can I assume it's in the public domain and usable by anyone?
> > 
> > I'll post installation instructions if that's the case.
> > 
> > 
> > --Jeff
> 
> Yep, it is in the public domain. Have fun.
> 
> -jon
> 
> -- 
> If you come from a Perl or PHP background, JSP is a way to take
> your pain to new levels. --Anonymous
> <http://jakarta.apache.org/velocity/> | <http://java.apache.org/turbine/>
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


Jeff Turner <[EMAIL PROTECTED]>
Written 4 Feb 2001
$Revision: 1.2 $ $Date: 2001/02/04 10:26:42 $

Introduction


This file documents the Apache projects' CVS setup, namely the contents of
the CVSROOT directory, and how to install the Apache CVS system on a new
system. All comments and improvements welcome.



Access Control Lists


The Apache access control system is very flexible and very simple (much better
than the OS username technique described in the CVS book). The ACLs (access
control lists) determine whether a user has *write* access. Who has read access
is still determined by the 'readers', 'writers' and 'passwd' files. The Apache
ACLs work in addition to the standard CVS mechanism, not replacing it.

Here is a list of new files implementing the ACL, and what they do:

avail
  The access control lists for determining write access. See
  the description in cvs_acls.pl

cvs_acls.pl
  Program that parses 'avail' and decides whether a user has
  commit access

commit_prep.pl
  Once a user has been authenticated against the ACL, this
  script creates a list of the files modified in this commit.
  This data is stored for later use by the logging script
  log_accum.pl. In this way, log_accum.pl can combine
  changes in multiple directories, and mail a single message.

commitcheck
  Program invoked from commitinfo (the standard
  CVS hook into the commit process), which in turn invokes
  cvs_acls.pl and commit_prep.pl.




Commit message Mailing System
=

By default with CVS, if files README and src/Foo.java are modified, two
separate commit messages will be emailed to the committers. This is because CVS
has a very file-centric model, and has little idea of project-wide differences,
and thus doesn't associate the changes in README and src/Foo.java.

The Apache script 'log_accum.pl' works in tandem with the commit checking
script 'commit_prep.pl' to accumulate all changes made in one commit, and the
mailing *one* message to the list.

'log_accum.pl' by default mails an Apache list, and thus needs minor
modification. See below for details.




Getting ACLs working on a new system


Here are the steps I performed to use the Apache CVSROOT system on a new CVS
repository:

1) Download the Apache CVSROOT directory as follows:

  [~/jakarta]$ cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login
  password: anoncvs
  [~/jakarta]$ cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic checkout 
CVSROOT


2) Download the new server CVSROOT directory:

  [~/server]$ cvs -d :ext:jeff@localhost:/usr/local/src/CVS
  [~/server]$ cvs checkout CVSROOT


3) Tag the current version of new server's CVSROOT from a CVSROOT sandbox: 

  [~/server/CVSROOT]$ cvs tag before_apache


4) Copy the following files from the checked-out jakarta CVSROOT to the
checked-out server CVSROOT:

  [~/server/CVSROOT]$ cp ~/jakarta/CVSROOT/commitcheck .
  [~/server/CVSROOT]$ cp ~/jakarta/CVSROOT/cvs_acls.pl .
  [~/server/CVSROOT]$ cp ~/jakarta/CVSROOT/commit_prep.pl .
  [~/server/CVSROOT]$ cp ~/jakarta/CVSROOT/avail .


5) Add these new files to the 'checkoutlist' file, so they'll be checked out on
the server CVSROOT:

[~/server/CVSROOT]$ cat >> checkoutlist 
commitcheck
cvs_acls.pl
commit_prep.pl
avail
[$/server/CVSROOT]$


6) Add the new fil

Using contents of Jakarta CVSROOT?

[Jeff Turner]

Hi,

I'd like to use the Jakarta CVS access control and commit emailing for a
company CVS server. This is the stuff get get if you run 'cvs checkout
CVSROOT'.

There isn't any indication that the files are under the APL (or any
license), so can I assume it's in the public domain and usable by anyone?

I'll post installation instructions if that's the case.


--Jeff


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