[torque] Separate out runtime from other library ?

[Peter Donald <do...@apache.org>]

Hi,

Is there any demand for separating out runtime required classes from 
build/compile-time orientated classes ?

-- 
Cheers,

Pete

--------------------------------------------------
you've made a dangerous leap right over common 
sense, like some kind of metaphysical Evil Knievel
--------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Re: [torque] Separate out runtime from other library ?

[Daniel Rall <dl...@finemaltcoding.com>]

Peter Donald <do...@apache.org> writes:

> I just started looking at it an hour or two ago but it looks like the ant 
> tasks, engine subdirectory and a few other bits and pieces are not needed at 
> runtime.
>
> While they could be used at runtime (I actually have a system right waiting 
> to do just that ;]) they are mainly a develop/deploy-time thing. I just 
> thought it would be useful to separate out the two bits of code to make it 
> easier to evolve it ;)

In the 2.x tree, Torque is exactly that--a set of classes used for
code generation.  Jason moved the database connection pooling and
query building classes into Torque when it was spun off for the 3.x
code tree, the reasoning for which was to more clearly define Torque
as a database persistance framework.

All the Java code currently generated by Torque adheres to the API
provided by the connection pooling and query building classes which
Jason rolled into it.

Dan

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Re: [torque] Separate out runtime from other library ?

[Peter Donald <do...@apache.org>]

On Mon, 15 Oct 2001 16:50, Daniel Rall wrote:
> Peter Donald <do...@apache.org> writes:
> > Is there any demand for separating out runtime required classes from
> > build/compile-time orientated classes ?
>
> Hi Pete.  What libraries are used at build-time that are not used at
> run-time?
>
> A quick glance at the build file turns up Xerces and Velocity as
> possiblities, since I believe these are used primarily for parsing XML
> schemas and generating code.  However, this functionality could just
> as easily be used at run-time.  Would you elaborate a bit?

Well I guess I was really thinking about two different things. There are 
libraries like xerces, velocity, that are primarily build time.And it also 
looks like there are some internal torque classes that are only used during 
generate/build/deploy process ?

I just started looking at it an hour or two ago but it looks like the ant 
tasks, engine subdirectory and a few other bits and pieces are not needed at 
runtime.

While they could be used at runtime (I actually have a system right waiting 
to do just that ;]) they are mainly a develop/deploy-time thing. I just 
thought it would be useful to separate out the two bits of code to make it 
easier to evolve it ;)

-- 
Cheers,

Pete

----------------------------------------------
Money is how people with no talent keep score.
----------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Re: [torque] Separate out runtime from other library ?

[Daniel Rall <dl...@finemaltcoding.com>]

Peter Donald <do...@apache.org> writes:

> Is there any demand for separating out runtime required classes from 
> build/compile-time orientated classes ?

Hi Pete.  What libraries are used at build-time that are not used at
run-time?

A quick glance at the build file turns up Xerces and Velocity as
possiblities, since I believe these are used primarily for parsing XML
schemas and generating code.  However, this functionality could just
as easily be used at run-time.  Would you elaborate a bit?

Daniel

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org