#2 maven plugin to support the generic dbConfig like for ant

[matthias g]

Until now it is necessary to update the maven plugin manually if a new DatabaseConfig parameter is introduced by adding a property to the corresponding MOJO class. This should be switched to the way it works with ant using the "dbConfig" xml element which allows users to specify properties and features that are parsed in a generic way.

Very first draft example (copied from the ant task):

<configuration>
<dbconfig>
<property name="datatypeFactory" value="org.dbunit.ext.oracle.OracleDataTypeFactory" />
<property name="tableType" value="TABLE,SYNONYM" />
<feature name="batchedStatements" value="true" />
<feature name="caseSensitiveTableNames" value="true" />
</dbconfig>
</configuration>

[Roberto Lo Giacco]

Two considerations:
1. shouldn't be better if we remove the difference between property and feature?
2. I would avoid the dbconfig additional tag if not strictly necessary

Both considerations are not really relative to the maven plugin only but are effective on the framework and on the ant task too

[John Hurst]

I agree with the idea of consolidating properties and features. However, as this is a significant change for users (as you say it should be effective on the whole framework), should we perhaps note this as a possible change for DbUnit 3.0?

(We should start a wiki page to discuss DbUnit 3.0 changes, even if we're not going to do it for some time yet.)

[matthias g]

Behind the scenes the properties and features are already consolidated in class DatabaseConfig. So if you set a feature using a "property"/"setProperty" method it is properly set.
Actually for the maven plugin I agree and we should always use properties. I did not have a detailed look into it but I think it can be implemented in a backwards compatible way setting the old attributes to deprecated only. So it's again a seamless thing for a minor release.

For a 3.0 release I'd like to remove all deprecated code - it would actually clean up the code base quite a bit. But good idea with the wiki, I'm just a bit short of time...

[Roberto Lo Giacco]

I suggest the following procedure to simplify the process:

1. remove the difference between feature and property allowing each feature/property to be specified both as a feature and as a property (this will avoid breaking the current code)
2. mark the features as deprecated both in code AND documentation (this will suggest people to move toward the properties convention)
3. delay the definitive removal of the features support until a major release is performed

This way we can suggest our final solution without breaking existing code...

[Roberto Lo Giacco]

Opps, sorry, I commented before reading the gommma post... anyway we wrote the same conclusions ;)

[matthias g]

I think I'll go for this one which is also the easiest way to implement properties :

<configuration>
<dbconfig>
<property>
<name>datatypeFactory</name>
<value>org.dbunit.ext.hsqldb.HsqldbDataTypeFactory</value>
</property>
<property>
<name>tableType</name>
<value>TABLE,SYNONYM</value>
</property>
<property>
<name>batchedStatements</name>
<value>true</value>
</property>
<property>
<name>caseSensitiveTableNames</name>
<value>true</value>
</property>
</dbconfig>
...

[matthias g]

[matthias g]

Just attached a patch for review (if anybody likes) that will work as soon as the 2.4.7 dbunit is on the central maven repo.

[Roberto Lo Giacco]

May be you missed my comment or may be my considerations were so silly you simply ignored them anyway I'm reposting my opinion on this: shouldn't be better if we use a structure like

<configuration>
<property>
<name>...</name>
<value>...</value>
</property>
...
</configuration>

or something like

<configuration>
<properties>
<property>
<name>...</name>
<value>...</value>
</property>
....
</properties>
</configuration>

and eliminate the dbconfig tag? I think it's a duplication as we are already in the dbunit plugin configuration section and everything we put in here is a dbunit configuration, in addition with those properties we are not only configuring the database but even the dataset and the framework: in my humble opinion we are misleading people with the dbconfig tag name

[matthias g]

Sorry Roberto, I've totally overlooked this one. I totally agree that it would be simpler to have the properties directly beneath the <configuration> tag.
There are 2 caveats/thoughts (I see/have at the moment):

1. I did not find out how to implement generic properties with MOJOs directly unter the configuration element. If you have a java.util.Properties element in your mojo you must give it a name which is dbconfig here. If you know how that works please give me advice.

2. It is conceptually not that bad to encapsulate the values that are set on the java DatabaseConfig object in a separate XML tag to maintain proper semantics. And with the <dbconfig> element it would be consistent to the ant task.

[matthias g]

Implemented for the upcoming release of the dbunit-maven-plugin (will probably be 1.0) - SVN rev 1119

[SourceForge Robot]

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

[Jeff Jensen]

Ticket moved from /p/dbunit/feature-requests/146/

Can't be converted:

• _priority: 5
• _milestone: