Copy from Scarab :
Feb 17, 2006 8:52:49 PM GMT | Added by: Raphaël Piéroni

I have found the problem :
here is the pom i had hacked in my local repository :

<project>
<modelVersion>4.0.0</modelVersion>
<groupId>torque</groupId>
<artifactId>torque-gen</artifactId>
<version>3.1.1</version>

<dependencies>
<dependency>
<groupId>ant</groupId>
<artifactId>ant</artifactId>
<version>1.6.5</version>
</dependency>
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>3.0</version>
</dependency>
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.0</version>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.0.4</version>
</dependency>
<dependency>
<groupId>velocity</groupId>
<artifactId>velocity</artifactId>
<version>1.3.1</version>
</dependency>
<!--dependency>
<groupId>village</groupId>
<artifactId>village</artifactId>
<version>2.0-dev-20030825</version>
</dependency-->
<dependency>
<groupId>village</groupId>
<artifactId>village</artifactId>
<version>2.0</version>
</dependency>
<dependency>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
<version>2.6.2</version>
</dependency>
<dependency>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
<version>2.0.2</version>
</dependency>
</dependencies>
</project>

Maybe you can ask the maven evangelism team to update (as you are a torque committer)
Feb 17, 2006 8:14:15 PM GMT | Added by: Raphaël Piéroni

I just attached the result of the command line call of the "clean install" goals.

Maybe the jdk version and/or the use of some repository definitions are in cause for the problem you see.
Feb 17, 2006 12:30:20 PM GMT | Added by: Raphaël Piéroni

Yep, i always try from the ide first and also from the command line because some times, things dont work in the ide and works in command line.

can you send me (directly) the reports so i can see.

maybe it is because i had changed the torque-3.1.1.pom file because it defines no dependency. i had also declared it at the maven-jira-evangelism. It should be modified at ibiblio now.

My system is : linux 2.6 + java 1.5.0 + maven 2.0.2
Feb 17, 2006 11:39:16 AM GMT | Added by: thomas fischer

After looking at the surefire report, the problem is that xerces classes are required but no xerces reference seems to be made. The missing xerces class is org.apache.xerces.dom.CoreDocumentImpl. The java version is 1.5.0, but I do not think this causes the problem.

Raphael, have you ever tried to build the plugin standalone (i.e. outside an ide) ? If not, maybe your IDE has additional classpath references hidden somewhere.
Feb 17, 2006 10:46:11 AM GMT | Added by: Raphaël Piéroni

The status of the patch is : a first draft of the torque pluginfor maven 2 using torque 3.1.1

For the test cases : is any surefire report generated in the target directory ?

For the compilation issue : maybe it is because i use maven 2.0.2

The plexus test case : inherits of junit. and it is used to correctly find the resources when calling maven from the command line and from netbeans. The real reason : i had made a plugin for creating a netbeans freeform project by reading the pom.xml files, and i used the plexus test case in it, so i used the same ways as i was used and confortable with it.

For the construction of the ant tast : i once asked at the mojo list for an example of using ant tasks in a mojo, i was sent at the clover plugin for maven 2, and i used the same way of doing.

I do not mind of the package or the mojo name.

I only have tested it by using the test cases (never in real)
Feb 17, 2006 10:17:01 AM GMT | Added by: thomas fischer

Raphael, thanks for uploading the sources.
I have taken a short look and I've got some questions. This is the first m2 plugin where I look at the source code so some questions might be stupid.

• What is the status of the patch ? When I unpack the jar and type mvn package many testcases (probably all, but I did not check it) print out <<<<<<<< FAILURE !! but no reason what failed. Maybe this is related to the next question.
• When I try to compile the sources using your dependencies I get many unresolved dependencies. For example, the class org.apache.maven.artifact.repository.DefaultArtifactRepository which is referenced from the TorqueSQLMojoTest, can not be found in maven-artifact-2.0.jar
• Is there any reason why Plexus test cases should be used and not JUnit tests ?
• what is the reason for the ant tasks being constructed by antProject.createTask(ANT_TASK) instead of by calling their constructor directly ?
• would you mind if the package name would be changed to org.apache.torque.mojo ?

Feb 12, 2006 7:05:47 PM GMT | Added by: Raphaël Piéroni

The patch has been uploaded
Jan 28, 2006 1:42:26 PM GMT | Added by: thomas fischer

Sorry, your attachment did not make it to scarab. Can you try to append it again, please ?

The first draft of a torque plugin for maven 2 using torque 3.1.1

The result of the call of the clean install goals in command line.

copied from scarab
http://issues.apache.org/scarab/issues/template/ViewIssue.vm/id/TRQS343

I have looked at the implementation of the om goal. The main focus of the maven2 plugin is to translate the initialisation process of maven2 to an initialisation process of the generator's ant files.
I have created an implementation of the OM goal based on Raphael's draft which could serve as a draft for other implementations. I have changed the following things from Raphael's draft:

• Changed the maven2 initialisation source. The idea is to make all settings in the pom.xml. Therefore, no context properties needs to be created by the user, this is generated automatically by the mojo.
• Changed the class hierarchy to match the class hierarchy in the generator. On top of the classes corresponding to the generator, we need one more class level which translates the settings in the pom.xml to the context properties file needed by velocity. So there is TexenTaskMojo wrapping a Texen task, DataModelTaskMojo wrapping a DataModelTask, and the OMTask on top which knows the context properties for om generation.
• Changed package name to org.apache.torque.mojo
• Changed code style to torque code style

The following things still need to be done in the mojo

• make all needed context properties configurable (just the basic properties are configurable now to prove the principle)
• I'd like to replace the PlexusTestCase by a simple JUnit test case to keep things simple (we do not use plexus anywhere else in Torque)

I'll attach the draft as maven2-plugin.jar. For clarity, I have removed all other stuff which is not needed by the om goal.

proof-of-concept implementation of om goal

Forgot to mention that: I changed the version of the generator to be included from 3.1.1 to 3.2

I started this plugin using version 3.1.1 because we use this version of torque at work.

It would be nice to have a multi-torque-version plugin.

In principle, I did not change anything which would disallow to use the 3.1.1 generator. However, as the dependencies must be stated at build time of the plugin in its pom.xml, how can one tell the plugin to use a different version of Torque at run-time ?

There is an option in the pom to activate a dependency for a plugin.

I know it is used to declare which jdbc provider to call (oracle, mysql, ...) when using a plugin.

It is called extension. alas i don't know how to use it correctly.

Could we agree on that per default, the newest version of Torque is used in the plugin? This would mean thah the torque developers would not actively test the plugin against older versions of Torque. The reason for this is that I do not think that the Torque project has enough manpower to support a multi-version plugin. However, if you find a mechanism which allows using an older version of the generator without rebuilding, I'd be happy to include it.

I do not expect many problems, though, as the API and initialisation process of the generator tasks has not changed since 3.1.1.

agree with one restriction : if the plugin do not evolve and torque yet, what is done ?

This will not happen. Torque's policy in the past was to release all components in a single release, and the plan is to keep this policy in the future. This policy will also include the maven2-plugin, so whenever a new generator is released, so will a new maven2-plugin.

Raphael, why did you use @execute phase="generate-sources" and not simply @pahe="generate-sorces" ? As I understand, the @execute starts a separate build cycle but I do not see why this is needed.

maybe when i created the draft, i did not find the @phase tag, and though the @execute was the one to do.
have you tried both ? which one works ?

Both of them work, but the @execute starts a separated execution cycle, which is kind of non-standard. I'd like to avoid this, if possible. So if you had no particular reason to use the @execute tag, I'll use the @phase tag and see if it gives any trouble (I did not run across any so far).

Is development on this plugin still ongoing? I'm looking at the possibility of using torque on a project where maven 2 is a strong possibility.

I can put in some dev time if necessary to more it along.

In my opinion this should be pretty complete, except the docs. File an issue in jira if you think anything is missing or malfunctioning.

The functionality is implemented in svn. It might need a bit of testing, though.