search

linsolas / casperjs-runner-maven-plugin

CasperJS Runner Maven plugin
Apache License 2.0
13 stars 8 forks source link

Generating output directories and output files for each script (xunit, logs, casper generated files, cookies) and minor changes #23

Closed burgacl closed 8 years ago

burgacl commented 10 years ago

Generating output directories in target/casperjs for each script and executing each script in the created directory so that casperjs generated files (such as captures) are saved in the correct directory instead of in the project basedir. Xunit files are all named "results.xml" and are now saved in each script output directory. Added the possibility to generate a log file for each script which contains the command line used and casperjs console output, saved in script output directories. Added the possibility to save the cookies generated with the script execution and to make the scripts run with a preconfigured cookies file (option --cookies-file). Changed --direct option (which is deprecated) to --verbose. Added --ignore-ssl-errors and --proxy-auth options. Fixed comments about how to use parameter.

I am merging my commits in emergency (end of internship) and integration tests are missing, I will add them by the next week

bguerin commented 10 years ago

casperjs generated files (such as captures) are saved in the correct directory instead of in the project basedir

you can already do that by passing a custom option like --output=${project.build.directory} as an argument of the plugin. I am quite hesitating if the plugin should handle that automagically or not, but why not

Xunit files are all named "results.xml" and are now saved in each script output directory.

Don't agree, today the plugin acts as the maven-surefire-plugin do, and I think it is a good think

Added the possibility to generate a log file for each script which contains the command line used and casperjs console output, saved in script output directories.

Good

Added the possibility to save the cookies generated with the script execution and to make the scripts run with a preconfigured cookies file (option --cookies-file).

Why not, but from where does this --cookies-file come from ? Is it a native CasperJS or PhantomJS supported option ?

Changed --direct option (which is deprecated) to --verbose.

You are right, --direct is deprecated, but in fact your --verbose is useless, as now the verbose option of the plugin both sets the plugin itself as verbose and the CasperJS commands being launched

Added --ignore-ssl-errors and --proxy-auth options.

From where does these options come from ? Are them native CasperJS or PhantomJS ones ? If yes, link to the doc please ?

Fixed comments about how to use parameter.

nice catch, thanks !

However, waiting for integration tests to be fixed.

burgacl commented 10 years ago

casperjs generated files (such as captures) are saved in the correct directory instead of in the project basedir

you can already do that by passing a custom option like --output=${project.build.directory} as an argument of the plugin. I am quite hesitating if the plugin should handle that automagically or not, but why not

The main aim of this change was to avoid overwriting of output files having the same name, for example, you want to execute the plugin on the directory organized as follow: .testsDir ..........\subdir1 ..................\test.js ..............\ ................\subdir2 .......................\test.js

If you execute the plugin with the enableXmlReports option, then the xunit command for the two files will be the same: --xunit=targetDir/TEST-test_js.xml and the first xunit file will be overriden.

You will encounter the same issue with casperjs generated captures if some scripts create a capture with the same name, the latest will override the others.

Xunit files are all named "results.xml" and are now saved in each script output directory.

Don't agree, today the plugin acts as the maven-surefire-plugin do, and I think it is a good think

You are totally right. Made the change because if the xunit files were stored in the output directories, there would be no need anymore to use a specific name for each file. Must change the commit so the name remain surefire style.

Added the possibility to save the cookies generated with the script execution and to make the scripts run with a preconfigured cookies file (option --cookies-file).

Added --ignore-ssl-errors and --proxy-auth options.

Woops indeed, should have put the link to the infos. The three options (--cookies-file, --ignore-ssl-errors and --proxy-auth) are native phantomjs. Link here => http://phantomjs.org/api/command-line.html More options exist but I needed those in particular so here they are.

However, waiting for integration tests to be fixed.

Sure, I will be adding them soon

Thanks for your feedback to the request.

bguerin commented 10 years ago

@wadouk : it seem your commits are for #24, no ?

bguerin commented 10 years ago

@burgacl

The main aim of this change was to avoid overwriting of output files having the same name

Ok, I understand now ! What do you think of another approch (again, the same as the surefireplugin) :

This make me think to another thing. At this time the plugin order scripts by their name, but with a structure like yours, this sort can break ...

The three options (--cookies-file, --ignore-ssl-errors and --proxy-auth) are native phantomjs

thanks for the doc, but I am still quite cold to add them. At this time, CasperJS supports both PhantomJS and SlimerJS, so adding all options of both, and why not a third, a fourth ... For --ignore-ssl-errors and --proxy-auth you can already use the arguments option of the plugin. For --cookies-file it seems a little bit more complicated ...

wadouk commented 10 years ago

@bguerin oh yeah, i have'nt read issues before doing that, i'm just following Clément. I have some strange errors. If you have any ideas, it would be great. I don't understand the @ notation in the settings.xml and i suspect this to cause the mismatch of plugins depencies. There is some artifacts not found and the integration test are failling because of those. You can see it in https://travis-ci.org/burgacl/casperjs-runner-maven-plugin/builds/30839924

Thanks for all of your comments

bguerin commented 10 years ago

@wadouk : no problem :)

Regarding your test failures, without access to the build.log files, I can not see what is going wrong. The only thing I can say it that some tests (the toolchain ones) requires some extra configuration in a dedicated toolchains.xml which used to be in the ${HOME}/.m2 directory, and also some variables (I have a profile for this on my settings.xml file)

bguerin commented 10 years ago

@wadouk : I found something. The integration tests use the local maven repository, not central (for speed). So if anything (dependency or plugin) is missing, the build fails. The maven-toolchain-plugin is only used in the integration tests, not in the main POM, so it is not available in the local maven repository for integration tests ...

I am adding it to the main pom, doing nothing, but just to be downloaded and available for integration tests.

edit : I just saw that you add an after_script to your travis configuration. Ok, so I see what is happening during integration tests on travis. It the same story (missing plugins in the local repository). I just push (a34f06823c8a6540beeb021c08a1bbe562647ed8) a correction to not call the clean phase during integration tests, which is useless.

And for the rest of the configuration, here it is (of course, the paths have to be adapted) :

<?xml version="1.0" encoding="UTF-8"?>
<toolchains>

  <toolchain>
    <type>casperjs</type>
    <provides>
      <version>1.0.4</version>
    </provides>
    <configuration>
      <casperjsExecutable>/opt/casperjs-1.0.4/bin/casperjs</casperjsExecutable>
    </configuration>
  </toolchain>
  <toolchain>
    <type>casperjs</type>
    <provides>
      <version>1.1.0</version>
    </provides>
    <configuration>
      <casperjsExecutable>/opt/casperjs-1.1.0-beta3/bin/casperjs</casperjsExecutable>
    </configuration>
  </toolchain>

</toolchains>
...
    <profiles>
        ...
        <profile>
            <id>casperjs</id>
            <activation>
                <activeByDefault>true</activeByDefault>
            </activation>
            <properties>
                <casperjs-default-path>/opt/casperjs/bin</casperjs-default-path>
                <phantomjs-for-casper-1.0-path>/opt/phantomjs-1.8.2-linux-x86_64/bin</phantomjs-for-casper-1.0-path>
                <phantomjs-for-casper-1.1-path>/opt/phantomjs-1.9.7-linux-x86_64/bin</phantomjs-for-casper-1.1-path>
            </properties>
        </profile>
        ...
    </profiles>
...
wadouk commented 10 years ago

I don't understand why you use toolchain for casper and not for phantomjs. For me it's the same thing. To have someting in the user profile is not a main guideline on travis.

I have understand the @ notation in maven files : the process resources will do it in the invoker plugin

I have some tests that fail in local because of casperjs 1.0.4 (the binary distribution doesn't contain windows binary).

on windows (at work) it will be painfull to continue.

wadouk commented 10 years ago

The last build was by writing a toolchains.xml and the build goes a little more away but still fail. I have'nt write a settings.xml to add the configuration. There is already a phantomjs binary in travis. i don't think it's a good idea to install an other version. Those way of doing are a little bit too intrusive to easily build a developer station.

It would be great to split the tests that need specific version of tool. In this way we could use the matrix functionnality of travis to tests on multiple casper versions.

bguerin commented 10 years ago

I don't understand why you use toolchain for casper and not for phantomjs. For me it's the same thing.

Because this is a casperjs plugin, not a phantom one. Phantom is one dependency of casperjs, but casperjs can also work with slimer .. I do not want to handle all possible dependency of casperjs in this plugin !

There is already a phantomjs binary in travis. i don't think it's a good idea to install an other version.

the integration test does not need another version, but two different version, one to run with casperjs 1.1 and another one to run with casperjs 1.0 as casperjs 1.0 does not work with phantomjs >= 1.9

It would be great to split the tests that need specific version of tool. In this way we could use the matrix functionnality of travis to tests on multiple casper versions.

do not agree, the plugin is compatible with both version of Casperjs (ie 1.0 and 1.1), so the integration test are here to ensure that.

wadouk commented 10 years ago

do not agree, the plugin is compatible with both version of Casperjs (ie 1.0 and 1.1), so the integration test are here to ensure that.

I don't say that the integration test will not cover all the cases, i just say that's the job of the CI and it will be probably easier to switch tool with travis implementation than with the maven one (because of the agnosticism of travis). If your more familiar with Jenkins, imagine how you will overwrite those user configurations at build time with a jenkins blank at each build. You can't say that you have prerequisite in maven installation.

bguerin commented 10 years ago

I would agree if the test.js / test.coffee scripts run by CasperJS were the same for both version 1.0 and 1.1, but this is not the case ... And they are so different that some kind of wrapper on top of them is too difficult to write. For your information, I have, from my side, a Jenkins build of this plugin, and there is no problem at all with that ...

bguerin commented 10 years ago

@wadouk : I have a Travis CI working, can see on my fork

bguerin commented 8 years ago

Hi !

Sorry for all this silent time ! CasperJS is not dead, neither it's maven plugin ! I just joined the CasperJs community : https://github.com/casperjs, and I will now work on the maven plugin directly from here : https://github.com/casperjs/casperjs-runner-maven-plugin

I will take parts of your PR there !

linsolas commented 8 years ago

Congratulations Benoit :)