Hi Henri,
Mostly agree with all your responses.
I want to emphasize though that Jakarta has two entry points for users
* People coming finding a general "Java @ Apache" resource. (which the
reorg helps)
* People looking for a specific resource after reading about it, hearing
word-of-mouth, etc. (there's a risk the reorg could hurt this).
For the last point, every component needs to have a distinctive name and
permanent URL. There's a lot of articles out there on Velocity (which
admittedly should be referred to as Jakarta Velocity though it generally
isn't), and also ORO, POI, taglibs, DBCP, etc. Let's not hide these popular
components behind a blank generic front. They should remain easy to find
and link to.
Cheers,
WILL
----- Original Message -----
From: "Henri Yandell" <[EMAIL PROTECTED]>
To: "Jakarta General List" <[email protected]>
Sent: Tuesday, January 10, 2006 8:32 AM
Subject: Re: Notice of intent.... #2
On Wed, 11 Jan 2006, Will Glass-Husain wrote:
Thanks, Henri.
My feedback.
Thanks, very useful stuff.
* Generally positive with an aversion to anything involving significant
work for the sake of a "cleaner Jakarta". By this I mean that I like the
idea of a flatter hierarchy and a clearer message to the public as to
what Jakarta is about. As I noted on the Velocity list, 4 years ago I
discovered Velocity after identifying Jakarta as a "cool Java project
resource" and then browsing through every project looking for useful
libraries. We should encourage that.
Yep. I need to post on Idea #3: Jakarta as Java federation at some point
:) Which mainly means having links and decriptions to other Java projects
at Apache and making [EMAIL PROTECTED] more of a discussion list than
Jakarta business list.
* I'm skeptical about the "common build and web site" part of your plan.
Agreed that technical issues may cloud this one. Having common structure
allows for people to work on each component more easily; but more
importantly it forces us into a single community.
It also stops components becoming component trees. ie) I'll be pushing for
velocity-tools to be a separate component from velocity. Guess an SVN
reorg will probably be in the works at some point :)
One part of common build is that each component produces only 1
deliverable. Not sure if that's worked perfectly in Commons, a few
components have a couple of jars, though 1 is always the most important
(much like velocity/velocity-tools). Producing 1 deliverable stops
subcomponentizing.
Seems like an awful lot of reorg work for little purpose. Many sites
have a maven site build. Who is going to integrate all of the projects
so that the individually desired features appear on each site. Same for
building. Velocity has a mildly customized build script that compiles
differently under JDK 1.3 and JDK 1.4/5. If we go to a "master web site
and build" this will make it too difficult to introduce changes to the
proces and will stifle innovation. Better to keep this at the subproject
level. (Note:
*goto jail, do not pass go* s/subproject/component/
No more subprojects :)
Jakarta-wide style guidelines with common fonts, colors, logos would be a
great idea though).
Good point. Common general l&f binds us together more.
* Also, I'm against changing the project names. Velocity (for example)
is a recognizable brand name. Calling it "Jakarta Template Language" or
something similar would be foolish.
It'd be Jakarta Velocity; but it might fall in the TemplateLanguage group.
I think we'll need groupings for sanity's sake, but we have to avoid them
gaining character. They're just vague tags and not actual subprojects.
* On a positive note, establishing a standard template for web site
format and build would speed up the introduction of new subprojects. We
could migrate the common subprojects to a standard, and encourage new
subprojects to use it. But if a group wants to modify this template for
one piece of it - why not? (as long as they keep some common Jakarta
fonts, colors, etc).
Right. Individual character is important. Same with the build; as long as
it's largely the same, individual bits to handle individual issues are
fine. We just need to have the norm be to be similar.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
