cucumber jars for selenium are given by info.cukes and cucucumber.io , which one should i use. Any specific reason to use any of these
one difference i have observed is that when i have cucumber-java,cucumber-junit,cucumber-jvm,cucumber-jvm-deps, cucumber-reporting, cucumber-picocontainer jars from info.cukes, few features like inheritance ,dependency injunction are not working, when i have changed info.cukes to cucumber.io in pom.xml, the fatures are working. I am not sure if this is because of the info-cucks jars are not working or supported. Is these info.cukes groups is not suitable for cucumber project
Want to know which group jars i should use.
If you are using Cucumber directly you should use io.cucumber. You also should not concern yourself with any dependencies other then cucumber-java, cucumber-junit and cucumber-picocontainer. They'll be pulled in automatically by your dependency management tool. If you are not using a dependency management tool I would recommend using Maven, Gradle or if you are using Ant; Apache Ivy.
If you are using Cucumber through another project, you should use the groupId and version that project recommends.
info.cukes is deprecating slowly and it's not encouraged for further use. Most of the automation scripts written using info.cukes are migrated to io.cucumber
info.cukes was switched to io.cucumber to accompany changes in Gherkin jars which was consumed by Cucumber-JVM.
The info.cukes version of Gherkin is located in https://mvnrepository.com/artifact/info.cukes/gherkin and the io.cucumber version is at https://mvnrepository.com/artifact/io.cucumber/gherkin
It is very important not to mix up the two groupIds in the same POM. It should be same for all the cucumber jar dependencies.
Related
I just made my first Griffon project, using lazybones. I chose griffon-lanterna-groovy for my template, and I then removed pom.xml and maven/ as I will be using Gradle. I then run gradle build test run and everything looked good. (it ran, build succeeded, etc.)
Next, I opened the project in IntelliJ and I've tried this in a variety of ways. No matter what I do, it IntelliJ doesn't recognize that this is a Griffon project.
I am using the latest stable version of all these library's, and I'm using IntelliJ Idea Ultimate Edition. I'm to to lazybones, Griffon, and lanterna, so any help is appreciated.
Griffon 2.x applications are either regular Gradle or Maven projects, you do not need an specific Griffon IDE plugin. IntelliJ ships with a Griffon plugin that's only compatible with Griffon 1.x projects. Do not use this plugin.
Refer to http://griffon-framework.org/tutorials/1_getting_started.html#_tutorial_1_4
Some of our new projects have been migrated to maven3 and some of the older projects are still using the maven2 compliant pom.xml files.
Can maven3 runtime execute maven2 compatible pom.xml files also?
maven 3 is mostly compatible with maven 2 configuration. But there is still some incompatibilities.
For a full list you should check here there is also sometime problems with plugins (as Torsten suggested).
Resources:
Maven 3.x Plugin Compatibility Matrix
On the same topic:
switching to maven3
Typically yes, but it may depend on the plugin version you are using.
Please note that e.g. the maven site plugin is different for maven 2 and maven 3 or some options of the maven enforcer plugin are no longer valid for maven 3. There might be others.
Yes, it is.
At first you may be alarmed by the fact that it reports a bunch of warnings and sometimes refuses to build before you take care of the problems, but this is actually better for you as (if you run into this) it simply tells you what was wrong with your project so far.
Other than that, the site plugin is completely re-written and you need to use the version for Maven 3. (Check here)
I am developing an Eclipse plugin and I use maven to coordinate my source structure. In order to compile the plugin I use the tycho extension for maven. However, I was wondering how to execute unitests.
I want to use the surefire plugin for testing as I additionally use a sonar server for source code quality management. Unitests are applyed if I use eclipse-test-plugin as package target. However, I want to make use of the default surefire plugin for applying unitests.
Now I figured out that the src/test/java that contains my unittest packages is read and compiled correctly but written into the wrong output folder. I need to have the tests in target/test-classes. However they are compiled to target/classes.
As I am new to Eclipse plugin development and maven I could not find out how to write the tests to the correct output folder. I've already tried adding and and changing the build.properties of the eclipse-plugin project. It works also fine for other projects that aren't plugin projects and do not make use of tycho.
Any help appreciated.
Regards,
Florian
Unlike standard maven projects, the convention for eclipse plugins/OSGi bundles is to have tests reside in separate projects. This is because there is no such thing as a maven dependency scope "test" in OSGi.
Thus keeping your tests inside the same project as your code under test would force you to mix up test code/dependencies an productive code/dependencies.
As you mentioned, Tycho provides a separate maven packaging type "eclipse-test-plugin" which you should use for dedicated test plugins/fragments. See https://docs.sonatype.org/display/TYCHO/PackagingTypes
There is no support in Tycho for plain unit tests residing in the same project.
I have a project 'ABC' with the main code and junit tests. I do have the requirement that i can execute the set unit tests against a older version of the product artefacts.
To solve this requirement i would create a maven project which only contains the junit tests.
Another maven product builds my product code and places the artifact into the repository.
Now i could launch my tests against any product build by changing the build dependency within the junit test project.
Is this a good solution? Are there perhaps better solutions to solve this requirement?
I think thats a pretty good approach. You could create a profile for each old version and then activate them via the profile name and test different old versions without having to change the pom file for each run. You could then also run the different profiles separately scheduled on a continuous integration server...
I'm building my application to run in an OSGi container. I use Maven and the Maven Bundle Plugin from Apache Felix to set up the OSGi manifests for my own modules and that works great.
Now, I'm deploying my bundles into an OSGi container together with several 3rd party libraries. Some of these are already OSGi-fied when I get them from the Maven repos, others, I want to convert into OSGi-compatible jars. I want to set up a Maven project that collects all dependencies, and puts each in its own OSGi jar. The ultimate goal is to collect these jars and my own into an assembly that I can use as a standalone deployment package.
I know how to convert standard jars to OSGi jars, and I have a (somewhat hackish) approach to merge multiple OSGi bundles, even if I probably shouldn't. But if I have a dependency that's already fine as it is, and I just want to copy it from the repo into my assembly, what part of Maven do I use? The bundle plugin is wrong, it messes up the manifests if a dependency is already OSGi-compatible. Do I use the dependency-plugin, the assembly plugin or something else?
I have the feeling I'm overlooking something very simple here.
Did you have a look at the PAX tools? In particular Pax-Runner and
pax-construct... They do not only give you a nice template to start with, but also solve most the problems you mentioned for free.
We use many libraries which are not OSGified by the vendor and which are not available on the Spring bundle repository. We also have many of these and want to deploy them all together hassle free. For this we have created a 2-layer maven setup:
Individual maven projects that either download or contain (as 'system' scope depends) the 3rd party lib in question, and OSGify these using the Apache Felix bundle plugin
One container project that has a dependency on all of these small projects and makes an assembly of them using the core assembly maven plugin. This POM also uses the copy-dependencies goal of maven to make sure everything is in place.
Once it is turned into an assembly (ours is a tar file) we deploy this to our servers. We have gone one step further and used this assembly of 3rd party libraries as the Target Platform for our Eclipse build environment. But this may be irrelevant for you.
You can get OSGi friendly versions of many common artifacts from the Spring bundle repository. So you may not have to do it yourself.
See details of how to configure the bundle repository for Maven.
(will update with some ideas for those that aren't available as bundles already)