utPLSQL / utPLSQL-maven-plugin

Maven plugin for running Unit Tests with utPLSQL v3
Apache License 2.0
13 stars 10 forks source link

Maven plugin doesn't work #9

Closed jgebal closed 5 years ago

jgebal commented 6 years ago

See utPLSQL/utPLSQL#665

jgebal commented 6 years ago

@alberto-hernandez any chance to get the plugin up and running with 3.1.0 API?

alberto-hernandez commented 6 years ago

Yesterday, I finished the upgrade to the new API and now I have to test it.. I hope that between today and tomorrow I would make the commit.

alberto-hernandez commented 6 years ago

I've just push the changes to the develop branch. Could you check the changes in order complete the work?

jgarec commented 6 years ago

Hi @alberto-hernandez ,

I think the plugin version should be set to 3.1.0-SNAPSHOT.

I just compile the plugin, install it in a local repository and run it in another project. The plugin is not able to use oracle driver without explicitly "load" it.

I add this line in UtPLSQLMojo

Class.forName("oracle.jdbc.OracleDriver");

and it's ok then.

It is also done in the CLI (see https://github.com/utPLSQL/utPLSQL-cli/blob/develop/src/main/java/org/utplsql/cli/OracleLibraryChecker.java#L12) => should be moved to java-api ?

jgarec commented 6 years ago

Seems not compatible with 3.0.4.1372

org.apache.maven.plugin.MojoExecutionException: Unexpected error opening file ouput
        at org.utplsql.reporter.ReporterWriter.writeReports(ReporterWriter.java:110)
        at org.utplsql.reporter.ReporterWriter.writeReporters(ReporterWriter.java:59)
        at org.utplsql.UtPLSQLMojo.execute(UtPLSQLMojo.java:135)
        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
        at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuil
        at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
        at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
        at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
        at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
        at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: java.sql.SQLSyntaxErrorException: ORA-00904: "UT_RUNNER"."GET_REPORTERS_LIST" : identificateur non valide

is it necessary to upgrade to 3.1.0 ? If yes, we should check that DBHelper.getDatabaseFrameworkVersion(connection) is greater or equal than 3.1.0 ?

alberto-hernandez commented 6 years ago

First notice that I need load oracle before using it..

About the version compatibility problem?

Did you adjust the utplsql version used with the plugin parameter "version"? In the plugin test I adjust to the version that I've used (3.1.0) but if you change the UTPLSQL version you need to adjust this.

 <configuration>
    <ignoreFailure>false</ignoreFailure>
        <version>3.0.4.1372</version>
 .....
pesse commented 6 years ago

Why can't you determine the version from the database as I do it in cli?

pesse commented 6 years ago

@jgarec I don't think we should take how Oracle driver is loaded to java-api or we will lose the possibility to integrate java-api with other solutions where you don't load it via Class.for (Spring for example)

@alberto-hernandez I couldn't dive into the code yet, but maybe you don't check for compatibility? if so, it will assume latest version to be present (3.1.0, for 3.1.1 has no API changes). You should provide a compatibilityProxy to support downwards-compatibility

alberto-hernandez commented 6 years ago

Push new changes with version upgraded. The framework version is obtained with the utility of the API in order simplify the integration. I need to create another environment with 3.0.X to check if the problem is solved.

@pesse, IMHO it doesn't make sense that maven-plugin have a proxy compatibility. This kind of feature is actually developed in the API that is the appropiate component to abstract all posible framework versions. For me, it makes sense creating some aligment between versions, for example: utlplsql version 3.1.X is compatible with api version 3.1.X and maven plugin version 3.1.X. It could be easier to understand to the final user with version should use.

jgebal commented 6 years ago

Would it mean that the maven plugin 3.1.x is supporting utPLSQL 3.0 and 3.1?

pesse commented 6 years ago

@alberto-hernandez Well, we discussed that topic a while ago according to java-api and cli and decided it's better to have the latest cli/java-api support all the 3.x versions (be completely downwards compatible). Java-API 3.1.0 (latest) is therefore compatible with the utPLSQL versions 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.1.0 and 3.1.1. From my point of view this is a huge benefit for both, end-users and tool-providers.

In my opinion creating separate versions of maven-plugin which are only compatible with the exact same version of the framework is an unnecessary complication for the user - especially because all the extra work, which is needed to provide downwards compatibility, is already done in java-api. Also: wouldn't the approach to have one specific version of maven-plugin for each utPLSQL version mean that we won't have maven-plugin Support for versions < 3.1.0? That would be very sad, because the maven-plugin seems to be interesting for many users.

jgarec commented 6 years ago

After #18, i think we could close this issue.

jgebal commented 5 years ago

Closing as #18 is merged