On Tuesday, March 4, 2003, at 03:42 PM, Nathan Bubna wrote:


Geir said
On Monday, March 3, 2003, at 04:39 PM, Nathan Bubna wrote:
My (latest version of the) proposal was *not* to eliminate a generic
tools
package, but to merely fold the directory trees together. There would
then
be a org.apache.velocity.tools.generic.* package to replace the
excised and
ill-named org.apache.velocity.tools.tools.* package.

That's not so bad. It's just a renaming? I'd easily retract the -1 if
just a renaming. I never liked tools.tools either.

yes, in terms of package structure, it's just a renaming.


BUT, that doesn't need to imply multiple jars are required for
deployment. The build.xml could still build three jars but the view
jar
would also include tools; struts jar would include both view and
tools.
The tools jar would just be generic tools. So no matter what your
use, there's still only one jar to deploy. It should be rather easy
to
fix the build.xml to do this.

True, this deployment scheme (which sounds great) can (and, barring strenous objection, will) be implemented with either the current three-tree structure or the single-tree structure i propose. Given this assurance, would you agree that the single-tree structure is more efficient and easier to maintain (esp. when traversing file paths)?

?

but... in terms of how we have the files organized in CVS, this would involve moving pretty much all the source code around and reworking the build.xml to have convenient "build just this part targets."

see, right now we not only build into three separate jars, but we also have
three source code directory trees to match. this is a PITA IMHO. instead
of having
view/src/java/org/blah/blah/blah/view
tools/src/java/org/blah/blah/blah/tools
struts/src/java/org/blah/blah/blah/struts
i would like to have just
src/java/org/blah/blah/blah/[view|tools|struts]


this is really not that radical of a concept. with the proper ant targets,
no theoretical users will be horribly inconvenienced, and nathan's
bizarre-perfectionist-neat-freak urges will be temporarily satiated. now,
is that really worth a veto? :-)



As long as there is separation of the code, and the build target for the tool.jar doesn't require j2ee.jar to compile, I'm perfectly fine with it....


geir

Nathan Bubna
[EMAIL PROTECTED]


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


--
Geir Magnusson Jr                                   203-956-2604(w)
Adeptra, Inc.                                       203-434-2093(m)
[EMAIL PROTECTED]                                   203-247-1713(m)


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



Reply via email to