Jason van Zyl wrote: > > On Wed, 2002-03-13 at 00:38, Brekke, Jeff wrote: > > In attempting to get t2 building with Maven for the beta release I ran > > across the issue of the conditionally compiled code in the current t2 tree. > > Code that is conditionally compiled in the t2 build depend on the presence > > of: > > > > jsp > > castor > > webmacro > > jython > > freemarker > > > > Currently Maven doesn't support conditional selection of source for > > compiling so I attempted to build all this code. Jython had an old import > > that when removed the code compiled clean, and Freemarker service has some > > old code that currently will not compile. Castor, JSP, and Webmacro code > > all builds fine. In the current production 2.1 tdk, I believe the jsp and > > webmacro code is the only optional code included. It seems that having the > > conditional build has left some code gathering dust in the t2 tree. So some > > questions on how to move forward with the t2 builds: > > > > For the future releases of t2, should we only include those two optional > > services in the jar since that is what is in our current production release > > ( jsp & webmacro )? > > > > ( I'm +1 for keeping it simple ) Remove the conditional compile option. > > Compile/build everything in the tree. Use the update-jars to provide the > > user the ability to find these optional jars. If there is no support/users > > for a specific services, can we move the other optional code ( castor, > > jython, freemarker ) to the attic? > > +1 For keeping it simple > > Either the code in the repository is all compiled, otherwise no one is > going to take care of it and it will degrade into disrepair as the > freemarker has. > > It's easy enough to make maven do condition compiles based on the > resources available but I think the real issue here is the maintenance > of the code we have in our repository. It's there right now so people > might be using it so we have to deprecate its use first. So I'm > > +1 > > On compiling everything and letting Maven bring down the required > resources. Conditional compilation is not a good method of > modularization. These bits have to become components that can be picked > up by a running Turbine system. I don't think selective exclusion based > on resources available has been good as the code no longer even works. >
I really do not like moving to a system that adds these jars as a requirement. If they are required to compile then unless I do a careful survey, I have to leave them in my runtime lib directory or risk unexpected errors. So we are considering making castor, jython, etc. required libraries to use turbine? john mcnally -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
