[vote] plans for torque 3.1

[Martin Poeschl <mp...@marmot.at>]

i posted my plans for the next version of torque some weeks ago .. now 
it's voting time ;-)

o remove all deprecated stuff (+ code cleanup)

o switch to commons-logging

o remove the legacy build (if we really need an ant build let's improve 
the maven generated ant build files .. it's a real pain to keep both 
versions up to date)

o seperate the generation and runtime parts of torque (move the 
generator to src/generator)



+4

martin

AW: about stratum jar

[Marc Lustig <ma...@marclustig.com>]

Hi Andreou, that's pretty interesting to me.
Since I started with maven 4 weeks ago, I never got the Torque-plugin
running. Goal torque:whatever always reports an error not finding the
stratum-lib.
Did you get the torque-plugin running?

I have both stratum-1.0-b3-dev.jar and stratum-1.0-b3.jar in my
repo/stratum/jars.
And I also tried both
<version>1.0-b3</version>
and
<version>1.0-b3-dev</version>

in my project.xml, without having any effect on the error that occurs.
Do you have an idea where another entry could be that would cause maven not
finding the stratum-lib?

Regards
Marc


> -----Ursprungliche Nachricht-----
> Von: Andreou Andreas [mailto:andyhot@di.uoa.gr]
> Gesendet: Dienstag, 10. Dezember 2002 10:49
> An: Turbine Torque Developers List
> Betreff: about stratum jar
>
>
> Maybe this is just another silly question,
> but in default.properties i see a
>
> stratum.jar = ${lib.repo}/stratum/jars/stratum-1.0-b3-dev.jar
>
> and in project.xml
>
>     <dependency>
>       <id>stratum</id>
>       <version>1.0-b3</version>
>       <url>http://jakarta.apache.org/turbine/stratum/</url>
>     </dependency>
>
> This causes the runtime:test goal to fail (even though the java:jar
> works ok), unless i override the stratum.jar in my build.properties .
> Is this intentional?
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>

about stratum jar

[Andreou Andreas <an...@di.uoa.gr>]

Maybe this is just another silly question,
but in default.properties i see a

stratum.jar = ${lib.repo}/stratum/jars/stratum-1.0-b3-dev.jar

and in project.xml

    <dependency>
      <id>stratum</id>
      <version>1.0-b3</version>
      <url>http://jakarta.apache.org/turbine/stratum/</url>
    </dependency>

This causes the runtime:test goal to fail (even though the java:jar 
works ok), unless i override the stratum.jar in my build.properties .
Is this intentional?

Re: [vote] plans for torque 3.1

[Neeme Praks <ne...@apache.org>]

If you tend to lean more towards the UML side of things, then you could 
possibly collaborate with AXgen:
http://axgen.sourceforge.net/

Rgds,
Neeme

Stephen Haberman ::

> >Do you think some of the template refactoring (proposed by Stephen
> >Haberman I think) should take place in this release, or wait for 4.0?
>
>
> I think template refactoring would be great; in doing so, I'll agree
> with Jon that OJB is not the-end-all-killer-tool, however, I think they
> have a much better (in terms of cross-database test cases, etc.)
> implementation of persistence than Torque currently has.
>
> Torque's strong point has always been code generation. I think it would
> be great of Torque to focus on just that and offload all of the
> persistence baggage to OJB where they have a dedicated team doing solely
> that.
>
> Assuming this happens, Torque could fall back on generating the nice om
> layers it always has, except easier and with more reliable results. And
> it also leads Torque towards doing more generation, e.g. of UI's (both
> AWT/Swing/SWT-based and Turbine-based), as Martin was saying he'd really
> like as a feature.
>
> At that point it'd also be really awesome to explore the possibilities
> of round trip engineering (e.g. of the om data layer and UI's). I'm a
> bit naïve in knowing exactly how useful it would be, I just think it
> sounds awesome (I ran a TogetherSoft trial a year or so ago and was
> really impressed by what the round-trip engineering, if done correctly,
> could do).
>
> So, I guess in the long run I'd really like to see Torque mature into
> pseudo-UML generation/reverse-generation framework. Kinda like ArgoUML,
> but without the GUI, and ideally a real nice implementation and
> integration between features like data layer and UI generation.
>
> Dunno; with my current lurking status, my opinion is of little weight,
> but I just thought I'd put in my two cents.
>
> Thanks,
> Stephen
>
>
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:
>

RE: [vote] plans for torque 3.1

[Stephen Haberman <st...@chase3000.com>]

> Do you think some of the template refactoring (proposed by Stephen
> Haberman I think) should take place in this release, or wait for 4.0?

I think template refactoring would be great; in doing so, I'll agree
with Jon that OJB is not the-end-all-killer-tool, however, I think they
have a much better (in terms of cross-database test cases, etc.)
implementation of persistence than Torque currently has.

Torque's strong point has always been code generation. I think it would
be great of Torque to focus on just that and offload all of the
persistence baggage to OJB where they have a dedicated team doing solely
that.

Assuming this happens, Torque could fall back on generating the nice om
layers it always has, except easier and with more reliable results. And
it also leads Torque towards doing more generation, e.g. of UI's (both
AWT/Swing/SWT-based and Turbine-based), as Martin was saying he'd really
like as a feature.

At that point it'd also be really awesome to explore the possibilities
of round trip engineering (e.g. of the om data layer and UI's). I'm a
bit naïve in knowing exactly how useful it would be, I just think it
sounds awesome (I ran a TogetherSoft trial a year or so ago and was
really impressed by what the round-trip engineering, if done correctly,
could do).

So, I guess in the long run I'd really like to see Torque mature into
pseudo-UML generation/reverse-generation framework. Kinda like ArgoUML,
but without the GUI, and ideally a real nice implementation and
integration between features like data layer and UI generation.

Dunno; with my current lurking status, my opinion is of little weight,
but I just thought I'd put in my two cents.

Thanks,
Stephen

Re: [vote] plans for torque 3.1

["James A. Hillyerd" <ja...@hillyerd.com>]

On Sun, 2002-12-08 at 06:18, Martin Poeschl wrote:
> i posted my plans for the next version of torque some weeks ago .. now 
> it's voting time ;-)
> 
> o remove all deprecated stuff (+ code cleanup)
> 
> o switch to commons-logging
> 
> o remove the legacy build (if we really need an ant build let's improve 
> the maven generated ant build files .. it's a real pain to keep both 
> versions up to date)
> 
> o seperate the generation and runtime parts of torque (move the 
> generator to src/generator)
> 
> 

I'm not sure if contributors can vote, but I +4 all of the above.

Do you think some of the template refactoring (proposed by Stephen
Haberman I think) should take place in this release, or wait for 4.0?  

-james

-- 
James A. Hillyerd <ja...@hillyerd.com>
Java Software Engineer - http://www.whynotown.com/