You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by "Brekke, Jeff" <Je...@qg.com> on 2002/03/13 06:38:22 UTC

Optionally compiled code in t2

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?

=================================================================
Jeffrey D. Brekke                                   Quad/Graphics
Jeff.Brekke@qg.com                              http://www.qg.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Optionally compiled code in t2

Posted by Jason van Zyl <jv...@zenplex.com>.
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.

 
> =================================================================
> Jeffrey D. Brekke                                   Quad/Graphics
> Jeff.Brekke@qg.com                              http://www.qg.com
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
-- 
jvz.

Jason van Zyl
jvanzyl@apache.org

http://tambora.zenplex.org


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>