Re: [Fwd: Maven as a top-level apache project]

[James Strachan]

From: "Costin Manolache" <[EMAIL PROTECTED]>
> Maven is a nice tool - and I wish it good luck wherever it goes.
> But if Maven charter will include the creation of a maven-only
repository -
> I hope at least some board members will vote -1.

I don't see that ever happening. Already the Maven repository can be used by
Maven itself, the generated Ant builds and, by the sounds of things,
Centipede too

You can even use your web browsers to surf & download jars yourself.

e.g. surf this...

http://www.ibiblio.org/maven/


James
---
http://radio.weblogs.com/0112098/

__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

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

Re: Forum Software.

[James Strachan]

From: "Danny Angus" <[EMAIL PROTECTED]>
> I think this is a terrible idea, unless... we had a mail->news gateway
which would expose the lists as news groups.

They already are.

Point your browser/newsreader at news://news.gmane.org/

or in particular here and follow this thread in your news reader...

news://news.gmane.org/gmane.comp.jakarta.general

James
---
http://radio.weblogs.com/0112098/

__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

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

Re: Forum Software.

[James Strachan]

Try gmane

http://www.gmane.org/

then you can use your favourite news reader software to browse the already
existing mail lists - it supports replies too.

James
---
http://radio.weblogs.com/0112098/
- Original Message -
From: "Robert Simmons" <[EMAIL PROTECTED]>
To: "Jakarta General" <[EMAIL PROTECTED]>
Sent: Wednesday, January 22, 2003 4:07 PM
Subject: Forum Software.


Well, once again I would like to bring up the concept of forum software for
Jakarta. The reason I am bringing it up again is that mailing lists are
intrusive and spammy. Daily I get flooded with a ton of email that I have
absolutely no interest in reading. However if I unsubscribe to the lists
than when there is something that I would like to know about or answer, I
will miss it. In addition, if I unsubscribe I'm not able to post my own
issues. With a mailing list, the communication mechanism is just too
intrusive. On a forum I can pick and choose what I want to read and reply
to.

As for them being used, its a simple matter of retiring mailing lists for
forum software.

When we consider that at least 90% of Jakarta users are not Jakarta
developers but will often have a question or an important insight, than the
folly of communicating only in mailing lists becomes clear.

-- Robert Simmons

__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

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

Re: [DRAFT1] Jakarta Newsletter - November 2002

[James Strachan]

From: "Jeff Martin" <[EMAIL PROTECTED]>
> 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 ;-)

Its pretty well hidden, but there is a link in the Jelly tag reference...

http://jakarta.apache.org/commons/sandbox/jelly/tags.html#jelly:xmlunit

as well as in the javadoc

http://jakarta.apache.org/commons/sandbox/jelly/apidocs/org/apache/commons/j
elly/tags/xmlunit/package-summary.html

so there is at least some XMLUnit publicity there :-)

James
---
http://radio.weblogs.com/0112098/

__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

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

Re: Database Subproject Discussion : creation of DBCommons ?

[James Strachan]

From: "Stefan Bodewig" <[EMAIL PROTECTED]>
> On Thu, 02 May 2002, Geir Magnusson, Jr. <[EMAIL PROTECTED]> wrote:
>
> > Costin suggested, and I supported, that a subproject of wider scope
> > be created to allow the collection of similar technologies into one
> > larger subcommunity.
>
> First of all, I like the idea.  But in general I think this should not
> be something we (we as in general@jakarta) should decide but the
> committers of the current (sub(sub))projects that would make up this
> new subproject had to decide.
>
> If the people working on Torque, commons-dbcp or the Avalon database
> stuff (I'm sure I'm missing something) as well as the people of
> Onjectbridge want to create this new subproject, I'll be all for it -
> but it should be their decision IMHO.

+1. I think db.apache.org is a good idea but lets give the OJB folks time to
settle in first.

Lets bring OJB here, see how well some of the Torque stuff can be moved into
commons and get shared across both projects. (Geir you can bring poolman to
commons too if you like). Then let the dust settle a bit and see if the
communities want to move. While I like the idea of taking the database
related stuff out of the 'frameworks' (avalon/turbine) and into a
database-related top level project that can work with other frameworks - its
maybe a bit early to start db.apache.org.

Who knows, maybe Torque and OJB could merge completely over time then just a
single top level project at Jakarta would be good too.

James



_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

Re: [New Subproject Proposal] ObjectBridge

[James Strachan]

From: "Martin Poeschl" <[EMAIL PROTECTED]>
> - torques sql generation stuff will go to commons and will be used by ojb

Wanna start this effort soon - I'm willing to help if you need any. I'd
really like to use Torque's SQL and Java generation stuff and OJB right now
;-)

James


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

Re: [New Subproject Proposal] ObjectBridge

[James Strachan]

I'm a non-binding +1 on moving OJB to Jakarta BTW. More below...

From: "Jon Scott Stevens" <[EMAIL PROTECTED]>
> on 4/30/02 11:11 AM, "Gerhard Froehlich" <[EMAIL PROTECTED]> wrote:
>
> > PS: hmm curious if takes the "jon hurdle" ;-).
>
> +1.
>
> The proposal and project clearly meet ALL of the requirements set out on
the
> newproject page.
>
> I would really like to see some sort of commitment to torque->obj
> integration/use/conversion/whatever though.

Agreed.

I'd like to see how the Torque XML database schema document could be used to
generate the SQL, documentation and OJB compliant model too. Then we'd have
the best of both worlds.

I noticed Torque already has a 'project-ojb-model' which kinda works (and
looks much cleaner generated code than the Torque equivalent) but doesn't
quite work yet. It certainly looks like a promising area of development.

James


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

Re: Subproject - satyr

[James Strachan]

> It also uses Xalan/Xerces for it's XPATH/XML requirements 

If you want a fast XPath engnie you might find Jaxen useful.

http://jaxen.org

e.g.

http://dom4j.org/benchmarks/xpath/index.html

James




_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

Re: Subproject Proposal - crossdb

[James Strachan]

From: "Peter Donald" <[EMAIL PROTECTED]>
> Sou you end up with something like following in torque
>
> MyData (The Biz Object)
> MyDataVO (The Value Object)
> MyDataPeer (The Peer)
> AbstractMyData (the abstract biz object)
> AbstractMyDataPeer (The abstract Peer)
>
> And the only one decoupled from the persistence framework is MyDataVO. In
an
> ideal situation you would just have a single object "MyData" that is free
> from persistence framework and is nice and simple. (and basically a clone
of
> MyDataVO). The rest of the stuff could be dynamically configured at
runtime -
> including the mapping to physical datasource.
>
> Any system that did that and did not have all the rest of the cruft would
be a
> sure winner IMHO.

Agreed. I've wondered a few times if maybe Torque could be patched so that
in addition it could work with DyanBeans as an alternative to code
generation. Then at runtime Torque could just work given some regular beans
(MyData) or even just figure out its own DynaBeans based on the database
schema.

http://nagoya.apache.org/gump/javadoc/jakarta-commons/beanutils/dist/docs/ap
i/index.html

James


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

Sun is proposing changes to the JSPA draft so that all of Apache's requirements are satisfied

[James Strachan]

Great news!


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

James


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

Re: "Jakarta is not an open source project in the pure community sense anymore"

[James Strachan]

I thought this was a good article - apart from arguing that Apache is not a
true open source project in the community sense which I think is just plain
wrong. Its got the best community by far of any open source project I'm
aware of though I guess thats pretty subjective.

Other than that I think Fleury & Mason make a very convincing argument that
Sun should allow JBoss to be certified.

The quote from Karen Tegan is interesting...

At the same time, having a strong brand and compatibility standards are
important to the development of a robust market for J2EE platform products,
tools, and components. The "J2EE Compatible" brand has achieved significant
momentum over the past two years, and we want to make sure that any open
source efforts don't impact the viability of that effort.


This does not seem like an argument as to why JBoss cannot be certified.
Indeed this seems to suggest that JBoss should be openly tested for
conformance to protect the 'J2EE Compatible' brand. Otherwise the only
alternative is to create an open source 'JBoss Compatible' brand (i.e. an
open source J2EE test suite) instead which would only serve to fragment the
J2EE marketplace and weaken the viability of the 'J2EE Compatible' brand.

James
- Original Message -
From: "Stephane Bailliez" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, March 22, 2002 4:52 PM
Subject: "Jakarta is not an open source project in the pure community sense
anymore"


>
> Apparentely I did not pay attention to those many gremlins working out for
> Sun and IBM in Jakarta and that are so closed... doh !
>
> See Marc Fleury's interview.
>
> ---
>
> http://www.onjava.com/pub/a/onjava/2002/03/20/jboss_interview.html
>
> [...]
> Anglin: There has been much speculation of late regarding JBoss and Apache
> Jakarta. Could JBoss become a Jakarta project?
>
> Fleury and Mason: No, we don't see that happening. Jakarta is not an open
> source project in the pure community sense anymore. It is dominated by
> Sun/IBM employees. We are more focused on growing our own professional
> services organization through JBoss Group. As such, we form a
> hyper-efficient consultancy, where our open source product base enables us
> to achieve an unparalleled degree of efficiency in sharing and
communicating
> knowledge. You may feel that our open source nature limits us here, but
> never when it comes to high-level knowledge. The ability to see and
> reproduce source code does not automatically give people the understanding
> of how it's used or how it can be optimized. If they do achieve that on on
> their own, that's great. For those who want more insight, we sell the
> services to get them there.
>
> The second reason for our dissatisfaction with Apache has to do with
> problems in the 3.2 version of Tomcat (the new one is better). When those
> problems arose, we grew close to Jetty, a competing open source project
> backed by MortBay Consulting in Australia. We met these guys, spent time
> with them, and we found there were a lot of similarities -- they are a
> husband-and-wife-led company dedicated to their product because it is
their
> business. It just happens that we relate better to people with goals and
> expectations similar to ourselves --dedicated independent professionals.
> JBoss Group is about supporting and promoting that way of life and work,
> which, in our opinion, is conducive to the development of great software.
> [...]
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 



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

Why Sun won't certify JBoss (was Re: "Jakarta is not an open source project in the pure community sense anymore")

[James Strachan]

A thought struck me today which is probably totally obvious to folk but I
thought I'd share it anyways. Sun gets pots of cash from companies who
develop J2EE compliant software from the J2EE license fees. So its in Sun's
interest to protect the BEA's, IBM's and their own J2EE products. The money
they get is based on revenue of the company (so thats quite a lot of money
from BEA & IBM).

The money-men at Sun probably see open source J2EE solutions as lost revenue
to possible commercial J2EE solutions so when folks like JBoss come along
they see it as in Sun's interest to not certify them to protect their J2EE
licence revenue nest egg.

Though with the .NET competition now I think its in their interest to
protect their J2EE market place by allowing open source solutions; otherwise
long term folks will just move away from J2EE.

James

- Original Message -
From: "Stephane Bailliez" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, March 22, 2002 4:52 PM
Subject: "Jakarta is not an open source project in the pure community sense
anymore"


>
> Apparentely I did not pay attention to those many gremlins working out for
> Sun and IBM in Jakarta and that are so closed... doh !
>
> See Marc Fleury's interview.
>
> ---
>
> http://www.onjava.com/pub/a/onjava/2002/03/20/jboss_interview.html
>
> [...]
> Anglin: There has been much speculation of late regarding JBoss and Apache
> Jakarta. Could JBoss become a Jakarta project?
>
> Fleury and Mason: No, we don't see that happening. Jakarta is not an open
> source project in the pure community sense anymore. It is dominated by
> Sun/IBM employees. We are more focused on growing our own professional
> services organization through JBoss Group. As such, we form a
> hyper-efficient consultancy, where our open source product base enables us
> to achieve an unparalleled degree of efficiency in sharing and
communicating
> knowledge. You may feel that our open source nature limits us here, but
> never when it comes to high-level knowledge. The ability to see and
> reproduce source code does not automatically give people the understanding
> of how it's used or how it can be optimized. If they do achieve that on on
> their own, that's great. For those who want more insight, we sell the
> services to get them there.
>
> The second reason for our dissatisfaction with Apache has to do with
> problems in the 3.2 version of Tomcat (the new one is better). When those
> problems arose, we grew close to Jetty, a competing open source project
> backed by MortBay Consulting in Australia. We met these guys, spent time
> with them, and we found there were a lot of similarities -- they are a
> husband-and-wife-led company dedicated to their product because it is
their
> business. It just happens that we relate better to people with goals and
> expectations similar to ourselves --dedicated independent professionals.
> JBoss Group is about supporting and promoting that way of life and work,
> which, in our opinion, is conducive to the development of great software.
> [...]
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 


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

Re: [OT] JCP rant

[James Strachan]

Totally agree. Though its worth mentioning that the Servlet, JSP & JSTL JSRs
all have their their reference implementations developed at Jakarta (Tomcat
& jakarta-taglibs) so there's CVS, a public archived email list and
bugzilla. I do hope that these JSRs start a trend that most/all JSRs open
source the RI and TCK. It just makes so much sense. I think Sun as a company
still have a lot to learn about open source; though there's plenty of good
people at Sun who are showing the way.

I'd prefer all EG communication to be open on a public forum though I
understand that sometimes privacy enables some companies to participate do
to IP issues.

James
- Original Message -
From: "Daniel F. Savarese" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, March 21, 2002 7:12 PM
Subject: [OT] JCP rant


>
> Somebody asked on the axi-user mailing list why they should use Axis
> instead of JAXM.  I offered some comments, but tried not to stray
> too off topic.  In light of a recent JCP-related thread, I thought
> there might not be any objections on general@jakarta if I vented for
> a minute.
>
> When you use JAXM, you'll run up against all sorts of limitations and
> the best you can do is send a suggestion/comment to an email address.
> With Axis, or any Apache project, if you run up against a limitation,
> you can discuss it on a mailing list and submit a patch.
> Hypothesis: JCP JSRs that have more frequent feedback iteration cycles and
> provide source code tend to produce better results than those with fewer
> feedback cycles.  I'll use JAXM and JAX-RPC as examples.  JAXM
> had no mailing list for developer discussion/feedback as it was being
> designed/developed with only the usual JCP JSR comment address.  JAX-RPC
> has a jaxrpc-interest mailing list that has helped the spec evolve into
> something more likely to be useful to developers.  With something as
> simple as a mailing list a JCP JSR can gather much better requirements.
> However, neither JSR provided source for their reference implementations,
> making debugging and patch submission an impossibility.
>
> The problem with the JCP is not merely the licensing.  It is also the
> basic JSR procedures.  The objective of a new API is to meet some set
> of developer requirements in a particular application domain.  If you
> don't consult with your users, the target developer group, you probably
> won't develop a useful result.  JSRs would produce better results if run a
> little more like Apache projects, with more opportunity for user feedback
> in an open forum to mold the ultimate result into something useful.
>
> daniel
>
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 


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

Re: Back to JakartaOne planning...

[James Strachan]

- Original Message -
From: "Geir Magnusson Jr." <[EMAIL PROTECTED]>
> On 3/5/02 10:40 PM, "Jon Scott Stevens" <[EMAIL PROTECTED]> wrote:
>
> > Hey all,
> >
> > I suggest that a few people step up to volunteer to make JakartaOne
happen
> > because it isn't going to happen all by itself. :-) Maybe even setup
another
> > mailing list to do planning on so that people who are interested in
planning
> > can join it and discuss things. If people are going to speak, a call for
> > papers needs to go out, etc...
> >
> > As far as I'm concerned with StudioZ, I think we have agreed that
Tuesday
> > the 26th is the day, but I still need a decision for the time's that the
> > event will happen for.
>
> Good question - day or night?  Which implies less conflict with things
> people want to see/do at JavaOne?

Maybe both? Daytime could be a bit more formal & organised and night time
could be more adhoc & beery ;)

Last year was my first JavaOne and I found most of the stuff in the day in
the first day or two to be miss-able - its usually the evening sessions or
stuff later in the week that were most fun.

> Are the schedules available yet?
>
> I'm happy to do the call for presentations if I can get two others to help
> me select if there are too many.  I assume we'll take all that we can fit
> into the allotted time, but with more than one person, we can judiciously
> select if we have to.

I'll gladly help.

James


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

Re: POI web update

[James Strachan]

> jakarta.apache.org/ant and jakarta.apache.org/avalon added.

Is jakarta.apache.org/commons in the list - if not can we add that too
please?

James


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

Re: JakartaOne?

[James Strachan]

This all sounds great - am looking forward to it. And to answer Jon's mail
too, Tuesday sounds good.

Apart from just meeting folks, having techie chats and drinking beer, it
will be nice to do some cross-group fertilization. There's so much going on
that its hard to keep track of it all. e.g. Maven is new to me ;-)

James

- Original Message -
From: "Geir Magnusson Jr." <[EMAIL PROTECTED]>
> On 3/4/02 1:25 AM, "James Strachan" <[EMAIL PROTECTED]> wrote:
>
> > JavaOne is around the corner. Do any Jakarta folks fancy a JavaOne get
> > together in a bar somewhere? Maybe Jon's new bar?
> >
>
> I was thinking about this earlier in feb, but wasn't sure we had the
time...
>
> I wanted to call it 'OpenOne' (but 'JakartaOne' is nice...) and use a
space
> like Jon's where we could have both a social gathering as well as some
short
> technical talks on things that didn't make it into JavaOne (for example,
if
> it didn't have anything to do with XML or web services).
>
> Here's what I had so far as a draft :
>
> I would like to get a sense of community interest for the following idea
>
> Proposal
> 
>
> Hold an off-site convention during the week of JavaOne to provide a venue
> for topics that didn't make the cut for JavaOne as well as topics that
did,
> of course.  Examples include (imagination challenged right now...)
>
>  o bastard J2EE technologies
>- template engines (could you guess I would suggest this ?)
>- publishing frameworks (Cocoon et al)
>- web app frameworks (Turbine, Maverick, Struts)
>- ?
>
>  o mainstream technologies
>- web services (I want to hear Sam talk about Axis :)
>- XML-RPC
>- ?
>
>  o community discussions
>- JSPA issues
>- ?
>
>  o other stuff
>- how about JDD talking about Objective C
>- Gump sociology
>- Maven
>
>
> Rationale
> -
>
> There are a lot of interesting things in the world that Sun's marketing
crew
> doesn't have space or interest for at JavaOne.   Many of these things are
in
> daily production use by people, and it would be nice to hear about them.
>
> Many developers will be in the area for this week, and if we could find a
> way to bring us together for both social interaction as well as learning
> about some of the topics we work on and are interested in, it seems like a
> win all around.
>
> Thoughts
> 
>
> We have an in with an event space in San Francisco (hey, Jon!) and from
what
> I understand, it has two distinct spaces, one of which can serve alcohol.
> So we can divide, cleanly, the social space and the technical space.
Those
> in the social space can bring their own, I guess :)
>
> However, I think if we do this, we should pay for the space (unless
> studio.tv wants the publicity :), and there lies a conflict of interest
> problem, but I assume that if the rate is competitive, as I am sure it
will
> be, we can all look the other way.
>
> I don't know if we have the time to pull it off - it would be nice to put
> something non-lame together.  I think we shouldn't be aggressive about
this
> - find a spot in the schedule so people aren't torn between J1 and this...
>
>
> --
> Geir Magnusson Jr. [EMAIL PROTECTED]
> System and Software Consulting
> The bytecodes are language independent. - Sam Ruby
>
>
> --
> 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]>

JakartaOne?

[James Strachan]

JavaOne is around the corner. Do any Jakarta folks fancy a JavaOne get
together in a bar somewhere? Maybe Jon's new bar?

James


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

Re: Apache Manual (was ApacheForge)

[James Strachan]

I think one thing this conversation seems to have highlighted is that
there's plenty of good documentation all over the apache sites, we could
just do with some more sitemap / indexing / searching features to be able to
find stuff.

(quickly ducking before people think I'm volunteering).

James
- Original Message -
From: "Fernandez Martinez, Alejandro" <[EMAIL PROTECTED]>
To: "'Jakarta General List'" <[EMAIL PROTECTED]>
Sent: Thursday, February 21, 2002 12:31 PM
Subject: RE: Apache Manual (was ApacheForge)


Ok, thanks a lot, Marc and Jon.

Included are some links from xml.apache.org, luckily they resemble Jakarta's
documents a lot. I know nothing about other Apache projects; I started
adding links from httpd.apache.org like crazy, but then realized that the
TOC was losing focus exponentially. Probably, someone else should tackle
this problem.

Now, including the valuable contributions of Marc and Jon, the annotated
Apache manual TOC would look like this.

1.- Introduction
  Who we are, why are we doing this.

  http://jakarta.apache.org/site/whoweare.html
  http://xml.apache.org/whoweare.html
  http://httpd.apache.org/ABOUT_APACHE.html

2.- Project proposal
  Proposal stage, committers needed, community.

  http://jakarta.apache.org/site/getinvolved.html
  http://jakarta.apache.org/site/newproject.html

3.- Apache rules
  Who gets to vote what.
  Voting rules, valid votes, +1/+0/0/-0/-1.

  http://jakarta.apache.org/site/roles.html
  http://jakarta.apache.org/site/decisions.html
  http://xml.apache.org/roles.html
  http://xml.apache.org/decisions.html
  http://cvs.apache.org/viewcvs.cgi/xml-admin/charter.txt

4.- Code organization and repositories
  Naming of packages, repositories, what to find in them.
  Who touches what.

  http://jakarta.apache.org/site/dirlayout.html
  http://jakarta.apache.org/site/guidelines.html
  http://jakarta.apache.org/site/agreement.html

5.- Code quality
  Add copyright notice, add authors.
  Format your code but not others'.

  http://jakarta.apache.org/site/agreement.html
  http://xml.apache.org/source.html

6.- Testing
  Adding test cases.
  Solving bugs, errors, showstoppers.
  Security problems.

  http://httpd.apache.org/security_report.html

7.- Build system
  Use Ant, use Ant, use Ant.
  Use Gump.
  Use Scarab.

  Not done yet.

8.- Dependencies
  What jar's to use and what to avoid.

  http://jakarta.apache.org/site/jars.html

9.- Documentation
  Where to look for it.
  What to expect, what not to expect.

  Not done yet.

10.- Releases
  When to release, what to release.
  Release process.

  http://jakarta.apache.org/site/binindex.html

11.- Support
  Whom you should ask, what you should figure out yourself.

  http://jakarta.apache.org/site/mail.html
  http://xml.apache.org/mail.html

12.- Licensing and guarantee
  Why you should use Apache license, and what's wrong with other licenses.
  What you can do with Apache products. Giving credit.
  All that implied warranty things.

  http://www.apache.org/foundation/licence-FAQ.html
  http://xml.apache.org/dist/LICENSE.txt

> -Mensaje original-
> De: Marc Saegesser [mailto:[EMAIL PROTECTED]]
> Enviado el: miércoles 20 de febrero de 2002 20:19
> Para: Jakarta General List
> Asunto: RE: Apache Manual (was ApacheForge)
>
>
> Alex,
>
> That's a really good start.  My only comment right now is to
> point out that
> some of the topics in this list are Jakarta specific and
> Apache is much
> bigger than Jakarta.  It would be cool if a manual such as
> this covered how
> other Apache projects handle similar tasks.
>
> I'd also include a chapter on Apache and Jakarta rules.  For
> example, voting
> rules, what constitutes a valid vote, what are the voting
> types and when
> they apply, what are meanings of +1/+0/0/-0/-1 in the various
> voting types.
>
> A collection of release instructions for various projects
> might also be
> useful.  When I was the release manager for Tomcat 3.2.x I
> got some initial
> help from Craig, but after that I had to invent most of the
> process myself
> (and I'll be the first admit that I didn't document that
> process :-( ).
>
> I'm sure I think of more after giving it some more thought.
> Good start,
> though.
>
> Marc Saegesser
>



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

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

[James Strachan]

> on 2/4/02 8:29 PM, "Aaron Smuts" <[EMAIL PROTECTED]> wrote:
>
> > Could someone explain the issue, especially with reference to JSR107
> > (JCACHE).
> >
> > Aaron
>
> Yes. I'm on JSR 107 and I seem to be the only really vocal person there
> about my needs. Brian Goetz cares as well, but isn't nearly as vocal.
>
> Simple:
>
> JSR107 is being created under a non-open source license and Oracle will
own
> the rights to the specification of the JSR. I'm complaining about this
> wildly.

I've asked Jerry the Oracle guy several times (off-list) and he claims that
one day Oracle will commit to releasing an open source reference
implementation - but I'm still waiting for an official announcement - and
its been 5 months and counting...

James


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

Re: [OT] RE: J2EE considered harmful

[James Strachan]

I agree Jeff; though for such a smart container to work in an elegant way
I'd prefer to develop the beans in a non-distributed manner and the smart
container do the rest - distributing what it thinks makes sense - along the
EOB / AltRMI lines. Not code to a server side componet API like EJB.

Though it seems EJB is going along the 'assume everythings remote and we'll
try optimise when things are local'. So maybe there's some sense in that.

James

- Original Message -
From: "Jeff Schnitzer" <[EMAIL PROTECTED]>
> 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:   
For additional commands, e-mail: 


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

Re: J2EE considered harmful

[James Strachan]

Hey Jeff

- Original Message -
From: "Jeff Schnitzer" <[EMAIL PROTECTED]>
> 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.

Agreed they are quite different. Though they both try to solve similar
problems like distributing your business logic, clustering or load
balancing. Some are better or worse at these kinds of things.

e.g. MOMs are usually much better at fault tolerance & real load balancing
than EJBs and Servlet engines are usually more scalable than EJB servers (in
my experience at least).


> The former are communication protocols, and the latter are (primarily)
> programming APIs.

They are both technologies that have their own APIs.
For example with web technologies we can use the Servlets API or JavaMail or
even the URL class. With MOM we can use JMS and with SOAP we can use JAXM or
JAX-RPC. So the web/MOM/SOAP technologies have APIs too.


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

Just like JAX-RPC can have any protocol underneath. I like the looks of JAXM
and JAX-RPC, neither are based on RMI or EJB at all but can be used to
implement asynchronous SOAP messaging or remote invocation respectively. Its
just a shame JAXM doesn't work with JMS yet.

So JAX-RPC is probably the closest thing around to the .NET remote
invocation protocols. Has nothing at all to do with EJBs though.
.

> I would compare EJB to the programming API for your SOAP or MOM
> implementation.

EJB is *totally* different from MOM. Though I agree some SOAP frameworks are
EJB-like or EJB-biased.


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

I'm arguing against 'distributed object models' really. Whether its DCOM,
CORBA, EJB or a SOAP framework that tries to implement 'distributed
objects'. I think the distributed object paradigm of stubs/skeletons &
distributed garbage collection doesn't work that well. I prefer to build
distributed systems using more messaging focussed techniques like web
technologies, HTTP/email/news/Servlets, SOAP messaging and MOM/JMS.

James


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

Re: Re: J2EE considered harmful

[James Strachan]

From: "acoliver" <[EMAIL PROTECTED]>
> >On Fri, 1 Feb 2002 18:35:55 - "James Strachan"
> <[EMAIL PROTECTED]> wrote.
> >> JMS is not
> >> appropriate for a number of areas.
> >
> >Like what?
> >
>
> UI, guaranteed failure situations.

I don't follow. JMS/MOM is one of the only solutions where clients and
servers work in a connectionless way - clients and servers don't need to be
running at the same time. The system can handle failures gracefully, with
persistent messages, retry, reconciliation, load balancing, fault tolerance
etc.

>
> >> In truth I've not yet learned enough
> >> about SOAP to speak intelligently  about it
> >
> >All I'll say is I think SOAP has a much better future than EJBs.
> >
>
> From what I've read I'd tend to agree, though it looks...bulky.

Agreed - though its a universal messaging format that can pass across all
transports; which is kinda handy. So whether http/email/news/MOM is used you
can connect anything to anything across diverse transports.

> >I was just emphasizing that web applications are scalable - just add more
> >boxes - and often they require quite modest hardware. EJB systems on the
> >other hand can often need huge machines just to make quite simple
systems.
> >
>
> Agreed.  I have fully stated: EJB sucks.  However it would be nice to have
> something there where you can isolate your database resources into a pool
of
> *servers* such as with any transaction processing system (going back to
even
> DCE crap -- which did suck too, but served a purpose)

Totally agree. I think adding TP type abilities to web/MOM/SOAP would be
cool.

> So it looks like we basically agree. ;-)  We're very verbose guys ;-)

+10 ;-)

James


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

Re: J2EE considered harmful

[James Strachan]

- Original Message -
From: "Andrew C. Oliver" <[EMAIL PROTECTED]>
> No EJBs suck.  I'm arguing we need something better.  I think you're
> thinking distributed systems as a whole are bad and perhaps we've worked
> in different problem areas so we've reached differing opinions on this.
> Distributed systems are NOT the answer for every system.  In fact MOST
> systems do not.  That being said, I've worked on plenty that used or
> needed a distributed approach regardless of whether they had one.
>
> I do thing CTMs are a good and necessary thing for some systems.  I just
> think the EJB implementation of one is very poor.

I've worked alot with CORBA, messaging middleware systems (MOM) , EJB
systems, web systems and more recently dabbled with SOAP (*). Each of these
main 'istributed system architectures have their own strengths & weaknesses
and approaches.

The interesting thing I've found wtih using all these technologies is that
at first, to an OO guy, CORBA and EJB seem kinda cool when you just start
looking at them (just like Object Databases too), - there's the 'wow,
everything looks like Objects and the network stuff gets hidden' feeling,
along with 'ooh, this is probably going to be the next big thing'. Then once
you've learnt and absorbed the technology, figured out how to use it and get
it to work well (which takes a very long time, much longer than you would
think for somthing that hides the network), there's a general feeling of
disappointment. That the emperor has no clothes - or maybe its just that the
object thing shouldn't pass across process boundaries ;-). The 'distributed
object' approach of distributed garbage collection, connection based
protocols, stubs and skeletons of CORBA and EJB just don't quite seem to
work properly, they're *very* complex, take many years to master properly,
require many patterns to use effectively and its far too easy to build slow,
unscalable, unperformant systems that take alot of time to build.

Now the interesting thing about MOM, web technologies and now SOAP is that
at first to an OO guy they seem, well, not very OO. They are all based on a
simple idea of message passing using MOM, HTTP/email/news or SOAP. Its
mostly passing data around though usually in a language andplatform neutral
way. All objects stay local, its just the messages that cross process
boundaries. You send a message/request to something, it does its thing and a
response may go somewhere, which may be back to you. You can layer on
synchronous programming if you wish, but often scalable & performant systems
often use asynchronous communication.

The web/MOM/SOAP approach is very easy to work wtih, its very easy to put
together a 'distributed system' that works well using various technologies
(look at the web).  Developers I work wtih tend to pick up the concepts
pretty fast. There's no hidden gotchas or huge books of patterns requjred to
describe how to build systems using 'messaging' since its pretty simple
stuff. The more you use them and work with them, the easier and more
powerful they seem. They feel 'right' in a worse is better approach.

They all pretty much have location transparency and are easy to implement
load balancing & fault tolerance but don't at all try to hide the network -
there's no magic you can pretty much dive in and see whats going on.

The interesting thing I find is that the web/MOM/SOAP approaches are all
pretty similar really. Both web and SOAP (JAXM) often use Servlets on the
Java Platform. The Commons Messenger project has some Servlets (and servlet
extensions called Messagelets) that processs MOM / JMS messages. i.e. the
only application server platform you require is a good servlet engine and
away you go (Aside: I should take a look at JAMES as well).


So you can probably guess my bias towards web/MOM/SOAP approaches for
distributed systems.
In terms of what's next in the distributed system arena, my own guess would
be more unification of the web / MOM / SOAP approaches (they are pretty
similar already) - maybe SOAP is this unification - with maybe a
consolidation of the platform/application server. Then maybe more tools on
top (AltRMI is one example) that put an object facade on top of the message
passing approach without making the same CORBA/EJB mistakes of connection
based protocols & distributed garbage collections.

Well thats my rather long & rambling 0.02 euros.

James

(*) 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.

Re: J2EE considered harmful

[James Strachan]

From: "Andrew C. Oliver" <[EMAIL PROTECTED]>
> > #1 you don't need to use EJBs to distribute business logic If you do
need to
> > distribute business logic, then there are various alternatives open,
from
> > HTTP/Servlets, JMS, SOAP or EJB. Each should be evaluated on their
merits,
> > cost/benefits etc.
> >
>
> True, I don't like the Servlet approach.  I tend to admire clean code
> and a Servlet approach makes this less likely (assuming the team is more
> than 1 guy and you have differing skill levels on the team).

There are many ways to work with HTTP, servlets is just one. There are many
others even just at Jakarta. JSP, Velocity, Struts, Turbine, Avalon, Cocoon
etc.

Incidentally having worked with various 'distributed models' such as CORBA
and EJB I find Servlets the cleanest and best designed applicaiton server
solution so far by quite some margin. There's a great open source
implementation of the spec (Tomcat 4) and look at all the diversity in
layers added on top to improve developer productivity.


> JMS is not
> appropriate for a number of areas.

Like what?

> In truth I've not yet learned enough
> about SOAP to speak intelligently  about it

All I'll say is I think SOAP has a much better future than EJBs.

> > #2 just because you may eventually distribute your business logic,
assuming
> > you're going to from the start (and assuming that means EJBs and then
> > jumping through lots of EJB hoops & headeaches and paying a fortune to
some
> > EJB vendors) is bad XP practice IMHO
> >
>
> I'm not into XP, but often the scalability concern happens over night.
> There should be some framework in place for making it possible to do
> this somewhat suddenly.

There should be a strategy yes. Though this doesn't advocate EJBs. (Though I
don't think you are advocating them).


> I'd say you have about a weeks warning on most systems on just how much
> you need to scale up after deployment.  Systems are make it or break
> it.  You can apply techniques to make this more predictive, but a lot of
> this happens outside my area of control most of the time.  (Political,
> socio-economic and chaos theory are involved which often result in
> unpredictable community size, and you must plan to be way off no matter
> how careful or disciplined your approach)

Agreed. Scalability needs to be thought about seriously.

> > I prefer to take an XP approach, first build a web application that
works,
> > is performant and scalable then worry about whether business logic needs
to
> > be distributed later. Afterall us Java folk are OO guys right? We can
write
> > our business logic in such a way that it could migrate to EJB later if
we
> > think thats the right thing to do.
> >
>
> I'm more into a scalable version of the RUP.  In my opinion XP is a hack
> of a methodology (the RUP actually covers most of its issues).  XP also
> suffers from the misconception that programming is the most important
> activity in software development (I would argue requirements gathering
> as the most important activity in software development...programming is
> easy, figuring out WHAT to program is hard This is not to say I'm
> not into an iterative approach to this, only that I think XP is
> lacking.  At least it admits its own lack of scalability.)
>
> One day I'll start a project to create a methodology that merges the
> disciplined approach to software that I admire with the opensource
> principles and approaches that I think are necessary for effective
> teamwork.  (minus the flamewars ;-) ).
>
> > Or to put that another way - I'd prefer to focus on giving the customer
what
> > they want and making a good web application than grappling with EJBs
just
>
> That is irrelevant to the issue.

Not really but maybe I'm not expressing it properly. Using EJBs wastes
*alot* of valuable developer time when they could be doing something more
useful like adding new features, making things more scalable or making
things more performant.


> I would like to see an adequate
> distributed system (which it looks like there are at least 2 in the
> works within or slightly external to our community), and EJB does not
> fit the definition.

Agreed.

> > because one day, maybe, under some conditions, I might want to
distribute
> > some of the business logic in the web app under the 'faith' that its the
> > right thing to do.
> >
>
> That doesn't mean you plug your fingers in your ears and say "na na na
> scalability I'll refactor later".

Agreed.

>  I find a balanced approach between
> planing for the future and refactoring later works best.  We do need an
> adequate distributed object system for some situations.

Agreed - but like I said, they are pretty easy to do with HTTP, SOAP, JMS
etc. It doesn't *have* to be EJB. That was my main point. Too many
developers start building a web application and *start* with the EJB parts -
rather than building the actual web application then seeing where EJB, JMS,
SOAP or HTTP servers might help to distribute some of

Re: J2EE considered harmful

[James Strachan]

Hey Andrew

Insteresting thread ;-)

- Original Message -
From: "Andrew C. Oliver" <[EMAIL PROTECTED]>
> On Fri, 2002-02-01 at 04:14, James Strachan wrote:
> > Hi Jeff
> >
> > I share your oppinions on EJB. Whenever I ask developers why they are
using
> > EJB the common answer I get from people is 'well I get transactions for
> > free'. When most of the time they don't do 2 phase commit with their
> > database anyways. And all that extra work just to get 'acceptable'
> > performance from EJB. Jeez this stuff is meant to help us not hinder us.
> >
> > I agree that EJB has shoved too many things together in one 'server side
> > component' framework. Perhaps working from core specs is better and just
> > choosing the bits you want/need, JTA, JDO, JNDI:, JMS etc. My personal
bias
> > is to use 'local' object technologies such as Java Beans, Servlets,
JDBC,
> > JSP, JDO, Turbine etc. Then use 'messaging' (whether it be SOAP, JMS,
HTTP
> > or whatnot) when distribution is required. I try to avoid RMI if truth
be
> > told. It seems so 80s ;-)
> >
> > I'm still not convinced at all that EJBs are even worth considering when
> > when building web applications - why should be business logic be remote
in a
> > web-centric world? Why not deploy the business logic with the web
>
> I agree with everything but this.
>
> For scalability you should have the option but should not always use
> it.

Agreed. Though I've 2 points to make.

#1 you don't need to use EJBs to distribute business logic If you do need to
distribute business logic, then there are various alternatives open, from
HTTP/Servlets, JMS, SOAP or EJB. Each should be evaluated on their merits,
cost/benefits etc.

#2 just because you may eventually distribute your business logic, assuming
you're going to from the start (and assuming that means EJBs and then
jumping through lots of EJB hoops & headeaches and paying a fortune to some
EJB vendors) is bad XP practice IMHO

I prefer to take an XP approach, first build a web application that works,
is performant and scalable then worry about whether business logic needs to
be distributed later. Afterall us Java folk are OO guys right? We can write
our business logic in such a way that it could migrate to EJB later if we
think thats the right thing to do.

Or to put that another way - I'd prefer to focus on giving the customer what
they want and making a good web application than grappling with EJBs just
because one day, maybe, under some conditions, I might want to distribute
some of the business logic in the web app under the 'faith' that its the
right thing to do.

Most business logic in most web applications is pretty minimal in terms of
computation and is often mostly database intensive so moving this code to
another process doesn't usually buy much in terms of scalability - if
anything its the reverse thats true - what with all that EJB distributed
garbage collection & connection based protocol stuff that needs to be done
scalability (and usually always performance) can go down.



> If your application will grow it is good to have a middle tier that
> can be moved and load balanced.  With Entity beans of course this is
> less possible.

(And stateful session beans ;-).

I think this is true of traditional GUIs, say a Swing client front end, a
middle tier server (say server side beans aka EJBs) and a database. I don't
think this is true of web applications as they are quite different things -
a servlet engine is not a 'GUI' client.

Servlet engines are a stable, performant and very scalable application
servers in their own right. Get a hardware load balancer and a farm of
servlet engines and your *way* scalable.

Arguing for the need for another, remote CORBA component-centric application
server based on mostly connection-based protocols, RMI, stubs and
distributed garbage collection to make your web-application more scalable
seems, well, strange.

In my experience web applications scale best when you have a big server farm
of servlet engines which are load balanced. A database at the back and
hopefully some kind of read only caching going on to take as much load off
the poor database as you can. Then you can distribute parts of your web
application into different server farms, get load balancing, shuffle things
around as load changes etc. Then pick the web technologies of your choice,
Struts, JSP, Velocity, Turbine etc. Away you go.

I still don't see the 'scalability' argument as in any way advocating that
EJBs are actually useful for web applications.

In fact this idea that EJBs are required to build scalable web applications
is plain false - probably marketing hype spread by the EJB vendors.

James


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

Re: J2EE considered harmful

[James Strachan]

Hi Jeff

I share your oppinions on EJB. Whenever I ask developers why they are using
EJB the common answer I get from people is 'well I get transactions for
free'. When most of the time they don't do 2 phase commit with their
database anyways. And all that extra work just to get 'acceptable'
performance from EJB. Jeez this stuff is meant to help us not hinder us.

I agree that EJB has shoved too many things together in one 'server side
component' framework. Perhaps working from core specs is better and just
choosing the bits you want/need, JTA, JDO, JNDI:, JMS etc. My personal bias
is to use 'local' object technologies such as Java Beans, Servlets, JDBC,
JSP, JDO, Turbine etc. Then use 'messaging' (whether it be SOAP, JMS, HTTP
or whatnot) when distribution is required. I try to avoid RMI if truth be
told. It seems so 80s ;-)

I'm still not convinced at all that EJBs are even worth considering when
when building web applications - why should be business logic be remote in a
web-centric world? Why not deploy the business logic with the web
application and save all those costly synchronous RMI calls. You can have
seperation of concerns without making things remote. You only have to look
at MS's PetShop to see how simple and fast to develop web applications could
be while still seperating business logic, persistence and presentation - or
how slow and painful they can be if you follow the EJB path.

I do think a simple open source alternative to EJB would be a good thing.
Already Jakarta has most of the bits almost in place, tying them all
together would be cool.

FWIW you might want to keep an eye on the AltRMI project at Jakarta Commons
which hopes to make RMI and the Remote stuff much easier.

James
- Original Message -
From: "Jeff Schnitzer" <[EMAIL PROTECTED]>
To: "Jakarta General List" <[EMAIL PROTECTED]>
Sent: Thursday, January 31, 2002 8:38 PM
Subject: RE: J2EE considered harmful


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 ti

Re: is a statement of the license in all source files?

[James Strachan]

From: "Jon Scott Stevens" <[EMAIL PROTECTED]>
> on 12/28/01 2:03 AM, "James Strachan" <[EMAIL PROTECTED]> wrote:
>
> > I thought I saw a mail go by a month or so ago whereby a short form of
the
> > licence was allowable in source files that refers the reader to a
> > LICENSE.txt file?
> >
> > James
>
> I have said it about a thousand times...it isn't ok. There is no short
form
> ASF license at this point. There is one for the 2.0 license, but not the
> 1.1.

Thanks for the clarification Jon. I dug out the mail I was thinking of - its
5th December by Roy Fielding titled 'proposed change to ASF license' on
[EMAIL PROTECTED] And 2.0 of the license is just a proposal right now -
so it should not be used.

Just out of interest does anyone know the current status of the 2.0
proposal? Any ideas if or when it might become accepted?

James


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

Re: is a statement of the license in all source files?

[James Strachan]

- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
>
> On Thu, 27 Dec 2001, robert burrell donkin wrote:
>
> > am i right in thinking that for legal reasons we need to
> > include the complete license text in every source file (rather than just
> > the short form)?
> >
>
> My recollection is that you are correct ... we need to be using the long
> form, at least for the version 1.1 license (i.e. the current one).

I thought I saw a mail go by a month or so ago whereby a short form of the
licence was allowable in source files that refers the reader to a
LICENSE.txt file?

James


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

Re: Object Relational Mapping

[James Strachan]

- Original Message -
From: "Chen, Alan (GSAM)" <[EMAIL PROTECTED]>
> Hi,
>
> I wonder if you have any plans to implement an Object Relational mapping
> framework.
>
> I am very interested to participate in such a project because I don't see
> EJB entity bean as the solution for all developments.  In fact, most
people
> who purchase J2EE servers most likely should be using TomCat instead
> because they are just buying a very expensive servlet engine with a jdbc
> connection pool.
>
> With an OR layer, we can easily turn TomCat into a scalable application
> server and developers can focus on writing business rules and logics.  We
> could follow JDO spec to start with and I really think an open source JDO
> can penetrate into the development community much quicker than Sun's
> Reference implementation.

Or you could petition Sun to open source the reference implementation of JDO
then others can contribute to it & extend it - like they've already done
with Serlvets & JSP (Tomcat) and the standard tag library (JSTL).

Remember to look out for Castor though I don't think its JDO compatible.

http://castor.exolab.org/

Then there's Torque in the Turbine project which is in a similar space,
though not JDO.

http://jakarta.apache.org/turbine/torque/index.html

James



_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

request for Karma for jakarta-site2

[James Strachan]

I'd like to be able to add myself (and maintain my bio) to the who we are
page. Could I please have sufficient karma for my user account: jstrachan

Many thanks.

James


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

Re: [OT] MS makes a better PetShop...

[James Strachan]

From: "Geir Magnusson Jr." <[EMAIL PROTECTED]>
> On 11/2/01 3:13 AM, "Jon Stevens" <[EMAIL PROTECTED]> wrote:
>
> > on 11/1/01 11:59 PM, "Matt Egyhazy" <[EMAIL PROTECTED]> wrote:
> >
> >> perhaps sun should make it more clear that petshop is not a benchmark
and is
> >> instead a multi-faceted example of the possibilities offered by j2ee.
i
> >> suppose they could rework it and create a benchmark out of it...
> >>
> >> microsoft is obviously misusing it...and that is possibly what they do
best
> >> (and are 'doing right'), spread FUD.
> >>
> >> matt
> >
> > I don't get it though. Why shouldn't a fully functional demo also be
able to
> > be used as a real application (or the basis for one)? A pet store
shopping
> > cart isn't rocket science. Even if it is just an educational science
> > project, why does it have to be that much more complex and overly done
than
> > an equivalent application in another language/system/os.
> >
> > The point being is that M$ claims that their version of PetStore is that
> > much smaller and easier to understand. Well, if their version also has
all
> > of the same showcase of features, then how come it is still that much
> > smaller/simpler/faster?
>
> Except that (someone noted) that the MSFT version doesn't have all the
same
> features, so it's not a valid comparison.
>
> This is an opportunity for us to build a PetStore example w/o a middle
tier,
> and see how that compares to the .NET version.

Agreed.

It could also be a useful comparison to see how simple Java of PetStore, w/o
a middle tier compares to the full-monty, multi-tiered EJB PetStore
implementation with data access objects, session beans, entity beans, state
beans and all those other patterns.

i.e. a way for developers to evaluate what the time & performance
differences are (both in development, maintenance and runtime) from doing
things in a simple way, just at the web tier with a seperation from business
logic, persistence & presentation or using all the various EJB technologies
& related patterns.

Then developers could see how it affects the amount of code, what different
deployment topologies are open to them etc. It could help developers decide
when EJB is right for them and when its not.

I admit I'm an EJB-cynic myself after being burnt on several projects -
however it would be good if the EJB-petstore could clearly demonstrate the
benefits they offer over using just regular beans in a single-tier petstore.

All that extra money we need to pay to the EJB vendors and all that extra
code & complexity must have some clearly demonstrable benefits right? :-)

James


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

Re: [OT] MS makes a better PetShop...

[James Strachan]

From: "Geir Magnusson Jr." <[EMAIL PROTECTED]>
> On 10/31/01 6:45 PM, "James Strachan" <[EMAIL PROTECTED]> wrote:
>
> > - Original Message -
> > From: "Jon Stevens" <[EMAIL PROTECTED]>
> >> on 10/31/01 1:54 PM, "James Strachan" <[EMAIL PROTECTED]>
wrote:
> >>
> >>> It would be interesting to have a Java competition - trying the
various
> >>> different techniques, tools and frameworks and seeing how each of them
> > stack
> >>> up to .NET. Comparing code complexity, performance etc.
> >>>
> >>> e.g. with beans or EJBs, with JDBC stored procedures or Turbine, with
> > JSP or
> >>> Velocity, then on a bunch of runtime platforms and databases and see
how
> >>> they stack up doing the same application.
> >>>
> >>> James
> >>
> >> Unfortunately, none of us in Jakarta land get paid to write demo's so I
> >> doubt you will see one soon. :-(
> >
> > I know! I was thinking about it another way.
> >
> > Most frameworks end up making a sample web application to demonstrate
them
> > in action. So Velocity, Struts, XMLC, EJBDoclet, JSP tags and so on
could
> > just pick the PetStore as a demo to build in the future (or at least a
part
> > of it).
>
>
> I've been thinking of converting PetStore to Velocity, as we have had
> questions on the Velocity list asking about just that.
>
> It would give a real apples to apples comparison.
>
> As jon notes, it's going to be a bit of work, although we could try to
> recycle the lutris simple beans...
>
> Now, if I could just avoid sleep...

;-)

Thinking a bit more about it, using Turbine/Torque or Castor or EJBDoclet or
JDO or whatever it should be a pretty quick job to make the 'simple beans'.

Then sharing the same set of simple beans we could experiment with plugging
in the various display/templating/framework technologies, Turbine, Velocity,
JSP/tags, struts, XMLC, Cocoon/XSLT etc.

James



_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

Re: [OT] MS makes a better PetShop...

[James Strachan]

From: "Jon Stevens" <[EMAIL PROTECTED]>
> on 10/31/01 1:19 PM, "James Strachan" <[EMAIL PROTECTED]> wrote:
>
> > http://msdn.microsoft.com/net/compare/petshop.asp
> >
> > Its not a very fair comparison (suprise suprise) but from a quick look
at
> > the source code, it seems MS achieve their performance gains by not
using
> > EJBs :-)
>
> Ok. Now that is funny. I got a good laugh out of that one. Hi Justy!
>
> > I wonder what the figures would look like if the PetStore were
implemented
> > along similar techniques using just regular JavaBeans and JSP...
>
> I wonder what the figures would look like if the PetStore were implemented
> along similar techniques using just Turbine and Velocity...
>
> Velocity already had results show it to be faster than JSP.

I knew I shoulda said 'servlet' and not 'JSP' ;-)

It would be interesting to have a Java competition - trying the various
different techniques, tools and frameworks and seeing how each of them stack
up to .NET. Comparing code complexity, performance etc.

e.g. with beans or EJBs, with JDBC stored procedures or Turbine, with JSP or
Velocity, then on a bunch of runtime platforms and databases and see how
they stack up doing the same application.

James


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

[OT] MS makes a better PetShop...

[James Strachan]

http://msdn.microsoft.com/net/compare/petshop.asp

Its not a very fair comparison (suprise suprise) but from a quick look at
the source code, it seems MS achieve their performance gains by not using
EJBs :-)

I wonder what the figures would look like if the PetStore were implemented
along similar techniques using just regular JavaBeans and JSP...

James


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

Re: [OT] Microsoft Sets Tolls for .Net Developers

[James Strachan]

Any plans to do an open source Java implementation of it? :)

Then we could do an open alternative to My Services. 'Open Services' anyone?
:)

James
- Original Message -
From: "Chuck Murcko" <[EMAIL PROTECTED]>
To: "Jakarta General List" <[EMAIL PROTECTED]>
Sent: Wednesday, October 31, 2001 4:05 PM
Subject: Re: [OT] Microsoft Sets Tolls for .Net Developers


We did, several years ago, at Trintech, for Visa, Mastercard, and Amex.
They all use it. I think Brother International just adopted it. It even
worked over WAP. 8^)

But it is not getting all the hoopla that Passport is getting. And it
was meant for users to select as a choice, from a website, not to be
supplied to them as the default/only thing they can use.

Chuck

On Wednesday, October 31, 2001, at 06:39 AM, Endre Stølsvik wrote:

> On Thu, 25 Oct 2001, Fernandez Martinez, Alejandro wrote:
>
> | Paying for an online agenda? document storage? e-wallet? This looks
> like the
> | e-commerce flop on steroids.
>
> This is the stuff that will succeed:
>   Microsoft Passport. Mix in Activation Code. Then pay for My Services.
> And find yourself placed firmly within "MS World" with no other options.
>
>  - Be afraid. Be very afraid!
>
> In my opinion, the net does need some kind of ewallet stuff. It's just
> that M$ is the last company in the world that should own it. Why hasn't
> VISA and MasterCard and the like done this stuff ages ago?
>
>
> --
> Mvh,
> Endre
>
>
> --
> To unsubscribe, e-mail:    [EMAIL PROTECTED]>
> For additional commands, e-mail:  [EMAIL PROTECTED]>
>
>
>
Chuck Murcko
Topsail Group
http://www.topsail.org/


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


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

Re: RMI Messaging

[James Strachan]

JXTA is an attempt to define peer-peer based 
protocols. (http://jxta.org)
 
RMI is client-server and so not the best way of 
doing peer based messaging. You might find JMS useful instead for publish / 
subscribe or queue based communication. Publish / subscribe is very peer 
based.
James

  - Original Message - 
  From: 
  intan 

  To: [EMAIL PROTECTED] 
  Sent: Thursday, October 25, 2001 5:27 
  AM
  Subject: RMI Messaging
  
  Hi all,
   
  I'm Intan, from Malaysia.
  Does anybody knows 'bout peer-to-peer 
  system?  I really need a help here.
  please give me your opinion on this coz i've been 
  assign an application which is on messaging system between peers in a real 
  time environment. I've decided to use RMI as the networking structure. So 
  please give me yur opinion on this.
  Thanx.
   
  Regards,
  Intan -junior 
programmer

Re: [OT] Microsoft Sets Tolls for .Net Developers

[James Strachan]

Agreed. I've also been suprised by the recent rise in FUD thats coming our
way...

http://www.javaworld.com/javaworld/jw-10-2001/jw-1019-iw-netvsjava.html?

A nice MS marketting strategy seems to be comparing .Net to EJBs rather than
to Java (or Servlets or JAXM or whatnot). Hardly a fair or useful
comparison. .Net still seems to use COM under the covers anyways so COM v
EJB or .NET v. Java seems more sensible but then I suppose thats the point
of FUD afterall.

James
- Original Message -
From: "Jon Stevens" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, October 24, 2001 10:41 PM
Subject: [OT] Microsoft Sets Tolls for .Net Developers


> Why am I not surprised?
>
> The funny thing is that even in this down economy and with all the free
> (better?) alternatives that are out there, people will actually still pay
> for this stuff!
>
> We should put a paypal link on the Jakarta homepage and donate the money
to
> AIDS research or some other worthy cause.
>
> -jon
>
> -- Forwarded Message
>
> Link: http://slashdot.org/article.pl?sid=01/10/24/010249
> Posted by: michael, on 2001-10-24 11:40:44
> Topic: ms, 153 comments
>
>from the firstborn-son-comes-later dept.
>matsh writes: "Today Microsoft [1]revealed the cost of signing up as a
>developer to .Net. Entry level is $1,000. Standard level $10,000.
>Custom support will cost even more."
>
> References
>
>1. http://news.cnet.com/news/0-1003-200-7629784.html
>
> -- End of Forwarded Message
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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