Christoph Reck wrote:
>
> Hi,
>
> why not use a top level subdirectory called contributions
> (similar to the whiteboard)? You see this in many OS-trees
> even in tomcat!
This was going to be my proposal this morning since I wouldn't want to
implede 'forward' progress since I don't seem to be getting any traction
on this idea. I will plug on a little more though..
> This tree could just contain any org.* net.* com.* packages
> - as long as they are released under the apache license
> and are fully JavaDoc'ed. As JVZ states, thing can go in
> there is it passes the scrutiny of the committers and gets
> the required votes.
But what are we doing here? Making a big bag o' code?
I would rather see us do a *project* that offers a nice toolset,
coherantly documented (not just Javadoc) and maintained by a set of
committers interested in and working regularly on application layer
development. Again, not up to the complexity of a framework like
Turbine, or to the (as I see it) simplicity of Velocity, but there is a
*huge* area between that it could cover.
> A separate jar can be made for the contributions. But any
> user can just pick out what he needs and put it beside
> (or even into) his application tree disregarding the other
> contributions. Patches can be posted just the same as for
> any core file.
And you would get the same out of a project, except you would be less
tempted to 'pick out' stuff. Not everyone wants to pick out things.
I would bet that people would be happier to simply take a
velocity-tools.jar and just drop it into wherever they drop such things
and be done with it, knowing it was 'released'. Certainly for
production use, that would be much better. In my experience, people
*like* a supported prepackaged solution that 'just works'.
> In this way only the source file tar will be a tiny bit
> larger. It's easy to handle and all can then profit.
> Note that through voting the committers can avoid any
> non Velocity stuff getting in there (giving hints to the
> developers where else to post their contributions...
Where? Where can they put them? I have a whole *pile* from you that
there is no place to put. I will emphasize again that I think its
really important to have a place for this stuff.
More and more people are working with servlets, for example, and it
seems that people are *constantly* reinventing the wheel. Why? There is
no place in the Jakarta project currently where a toolset is maintained
for the general servlet programmer. We need one. And yes, I know that
DBResourceLoader isn't a general tool for the servlet programmer....
> but then at least the subject is covered in the mailing
> list and searching for desired tools could be done...).
>
> Just my 2c for what it's worth.
It's funny how we as a group of developers in an OO language exhibit
non-OO behaviors in our organization. :) Here we have a chance to make
a step forward in the direction of shared code (something Jakarta seems
to have trouble with... of course, this has to balance with the 'let the
best codebase win' philosophy) and I think that we should do it. We can
start with a core nucleus of our things, produce an organizational and
process structure. I know that Craig from Struts (yes, and Tomcat..)
and Jon from Turbine (yes, and ...) are both interested in the sharing
idea, and while I don't know or represent that either one of them would
support us taking the initiative, I think they would. Jon is one of 'us'
anyway. For example, Struts apparently has general tools for
internationalized resource management - if these would help solve our
'LocaleResourceLoader' and 'MessageManager' issues, there is a case
where we can share code immediately.
And when (not if) the bigger Jakarta 'library' project gets off the
ground, we have a great contribution.
I'll quit here. It's time for coffee.
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
