search

adamretter / xspec-maven-plugin

XSpec Plugin for Maven
BSD 3-Clause "New" or "Revised" License
4 stars 3 forks source link

Add catalog use, possibility to change Saxon release, XSLT 3.0 support #3

Open cmarchand opened 8 years ago

cmarchand commented 8 years ago

We may specify a catalog. URIResolver is just enhanced, and previous functionalities are not altered We can modify the saxon release to use ; it is to allow to use Saxon-PE or EE. The counterpart is you must specify a Saxon dependency in plugin. A surefire report can be generated. It's to have a correct display in Jenkins. A bug is corrected : xspec document was not provided as source to main transformation.

adamretter commented 8 years ago

@cmarchand Did you mean to also commit the xspec framework itself? Until now it has always been downloaded dynamically by the build!

cmarchand commented 8 years ago

Yes, because the last release is not availabe as a zip file from https://github.com/expath/xspec/. Only the master. And because generate-xspec-tests-oxygen.xsl is added to support XSLT 3.0.

If you can find an URL to download a release from XSpec, for sure it's better !

adamretter commented 8 years ago

@cmarchand So two things here then:

  1. The 0.4.0rc1 release that we are using in the plugin is exactly the same as the EXPath GitHub code apart from this - https://github.com/expath/xspec/commit/70cfe35e472be894236e09582e4fd06e032a3d4e which is just a cosmetic tidy up. Do you really need that? I would rather wait until the next official release of the xspec framework instead of copying all the files in.
  2. Where has generate-xspec-tests-oxygen.xsl come from and what is the Open Source license for it? Also could we not submit those changes to the EXPath XSpec project as a PR to improve the original generate-xspec-tests.xsl rather than maintaining separate code? If we can't sent a PR, I would rather download it by URL and patch what we have in (1), but the license has to be okay for us.
cmarchand commented 8 years ago

Ok for 1.

  1. According to oXygen mailing-list, this file is under MIT, as the XSpec project is. So no license problem. https://www.oxygenxml.com/pipermail/oxygen-user/2016-January/005696.html And yes, it's better to submit these modifications to EXPath GitHub project to enhance it.

So, refuse my pull request, I'm going to prepare a pull request to EXPath / XSpec project, and add the patch in xspec-maven-project. You will have a new pull request tomorrow.

Have a good night, Christophe

Adam Retter notifications@github.com wrote: @cmarchand So two things here then: The 0.4.0rc1 release that we are using in the plugin is exactly the same as the EXPath GitHub code apart from this - expath/xspec@70cfe35 which is just a cosmetic tidy up. Do you really need that? I would rather wait until the next official release of the xspec framework instead of copying all the files in. Where has generate-xspec-tests-oxygen.xsl come from and what is the Open Source license for it? Also could we not submit those changes to the EXPath XSpec project as a PR to improve the original generate-xspec-tests.xsl rather than maintaining separate code? If we can't sent a PR, I would rather download it by URL and patch what we have in (1), but the license has to be okay for us. — Reply to this email directly or view it on GitHub.

adamretter commented 8 years ago

I don't need to reject it outright, I could rework it if you like, pulling in those commits which are ready?

On 14 January 2016 at 19:49, Christophe Marchand notifications@github.com wrote:

Ok for 1.

  1. According to oXygen mailing-list, this file is under MIT, as the XSpec project is. So no license problem. https://www.oxygenxml.com/pipermail/oxygen-user/2016-January/005696.html And yes, it's better to submit these modifications to EXPath GitHub project to enhance it.

So, refuse my pull request, I'm going to prepare a pull request to EXPath / XSpec project, and add the patch in xspec-maven-project. You will have a new pull request tomorrow.

Have a good night, Christophe

Adam Retter notifications@github.com wrote: @cmarchand So two things here then: The 0.4.0rc1 release that we are using in the plugin is exactly the same as the EXPath GitHub code apart from this - expath/xspec@70cfe35 which is just a cosmetic tidy up. Do you really need that? I would rather wait until the next official release of the xspec framework instead of copying all the files in. Where has generate-xspec-tests-oxygen.xsl come from and what is the Open Source license for it? Also could we not submit those changes to the EXPath XSpec project as a PR to improve the original generate-xspec-tests.xsl rather than maintaining separate code? If we can't sent a PR, I would rather download it by URL and patch what we have in (1), but the license has to be okay for us. — Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/adamretter/xspec-maven-plugin/pull/3#issuecomment-171758854 .

Adam Retter

skype: adam.retter tweet: adamretter http://www.adamretter.org.uk

cmarchand commented 8 years ago

Forget it, I'm already doing it now.

Christophe

Adam Retter notifications@github.com wrote:I don't need to reject it outright, I could rework it if you like, pulling in those commits which are ready?

On 14 January 2016 at 19:49, Christophe Marchand notifications@github.com wrote:

Ok for 1.

  1. According to oXygen mailing-list, this file is under MIT, as the XSpec project is. So no license problem. https://www.oxygenxml.com/pipermail/oxygen-user/2016-January/005696.html And yes, it's better to submit these modifications to EXPath GitHub project to enhance it.

So, refuse my pull request, I'm going to prepare a pull request to EXPath / XSpec project, and add the patch in xspec-maven-project. You will have a new pull request tomorrow.

Have a good night, Christophe

Adam Retter notifications@github.com wrote: @cmarchand So two things here then: The 0.4.0rc1 release that we are using in the plugin is exactly the same as the EXPath GitHub code apart from this - expath/xspec@70cfe35 which is just a cosmetic tidy up. Do you really need that? I would rather wait until the next official release of the xspec framework instead of copying all the files in. Where has generate-xspec-tests-oxygen.xsl come from and what is the Open Source license for it? Also could we not submit those changes to the EXPath XSpec project as a PR to improve the original generate-xspec-tests.xsl rather than maintaining separate code? If we can't sent a PR, I would rather download it by URL and patch what we have in (1), but the license has to be okay for us. — Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/adamretter/xspec-maven-plugin/pull/3#issuecomment-171758854 .

Adam Retter

skype: adam.retter tweet: adamretter http://www.adamretter.org.uk

— Reply to this email directly or view it on GitHub.

cmarchand commented 8 years ago

Ah ! Ok ! I did'nt see that pull requests where based on branches, I thought there were based on commits.

So, I've commited what needed to go back to download from googlecode, and add only the patch. The same patch has been submitted to expath/xspec.

Best regards, Christophe

Adam Retter notifications@github.com wrote:I don't need to reject it outright, I could rework it if you like, pulling in those commits which are ready?

On 14 January 2016 at 19:49, Christophe Marchand notifications@github.com wrote:

Ok for 1.

  1. According to oXygen mailing-list, this file is under MIT, as the XSpec project is. So no license problem. https://www.oxygenxml.com/pipermail/oxygen-user/2016-January/005696.html And yes, it's better to submit these modifications to EXPath GitHub project to enhance it.

So, refuse my pull request, I'm going to prepare a pull request to EXPath / XSpec project, and add the patch in xspec-maven-project. You will have a new pull request tomorrow.

Have a good night, Christophe

Adam Retter notifications@github.com wrote: @cmarchand So two things here then: The 0.4.0rc1 release that we are using in the plugin is exactly the same as the EXPath GitHub code apart from this - expath/xspec@70cfe35 which is just a cosmetic tidy up. Do you really need that? I would rather wait until the next official release of the xspec framework instead of copying all the files in. Where has generate-xspec-tests-oxygen.xsl come from and what is the Open Source license for it? Also could we not submit those changes to the EXPath XSpec project as a PR to improve the original generate-xspec-tests.xsl rather than maintaining separate code? If we can't sent a PR, I would rather download it by URL and patch what we have in (1), but the license has to be okay for us. — Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/adamretter/xspec-maven-plugin/pull/3#issuecomment-171758854 .

Adam Retter

skype: adam.retter tweet: adamretter http://www.adamretter.org.uk

— Reply to this email directly or view it on GitHub.

adamretter commented 8 years ago

@cmarchand I am away for most of this week with work. Can you prod me next week if I haven't got to it by then?

cmarchand commented 8 years ago

No problem, you are welcome ! Christophe

Adam Retter notifications@github.com wrote: @cmarchand I am away for most of this week with work. Can you prod me next week if I haven't got to it by then? — Reply to this email directly or view it on GitHub.

adamretter commented 8 years ago

@cmarchand Still in progress?

cmarchand commented 8 years ago

bug-xspec-mvn-plg_pendingCount.zip Hi Adam,

I've now something quite robust. As XSpec folks do not have release a new .zip dist file, we can not rely on, so I keep all XSpec patches in project. But we use a lot the xspec-maven-plugin successfully, in various cases.

I still have a bug in error count when pending scenarii exists. It's a problem because build fails if there is some pending scenarii. May you have a look at it ? I can't make it work correctly...

Attached a sample project with one implemented scenario and one pending scenario. The message generated by XSL has a correct count, but the one generated by plugin is wrong. Sometimes, pending are counted as failed...

Best, Christophe