I am working in a fairly big project. We have lots of projects and each project has dependencies. We use maven and normally we don't have any problems. So, without giving much details, imagine that for a given project, say, tps-reports the dependencies section of the pom.xml looks like:
<name>TPS-Reports</name>
<description>
TPS Reports frontend.
</description>
<dependencies>
<dependency>
<groupId>com.initech</groupId>
<artifactId>gui-components</artifactId>
<version>2.5</version>
</dependency>
<dependency>
<groupId>com.initech</groupId>
<artifactId>multithreading</artifactId>
<version>3.7</version>
</dependency>
<dependency>
<groupId>com.initech</groupId>
<artifactId>utils</artifactId>
<version>2.3.0.0</version>
</dependency>
<dependency>
<!-- TODO: update to new version -->
<groupId>com.initech</groupId>
<artifactId>object-pooling</artifactId>
<version>1.9.3.1</version>
</dependency>
</dependencies>
Now, Initech has tons of projects that depend on, say, object-pooling, which also depends on many other more components, such as (utils and multithreading).
Life is good for object-pooling developers. It is a pretty stable module and it all goes well. As any other module, it also has dependencies. object-pooling developers are all gentlemen and fair ladies and whenever they find a critical bug, they update all projects that depend on object-pooling.
Now, version 1.9.3.1 of object-pooling is stable and has no known critical bugs. Developers work really hard to add a ton of new features and after some time, they release version 2.0.0.0. Of course, between 1.9.3.1 and 2.0.0.0, there are intermediate releases (e.g. 1.9.3.1, 1.9.3.2, 1.9.4.0, 1.9.5.3 and so on). As I said, life is good for object-pooling developers. Version 2.0.0.0 has new features and lots of fixes.
However, hell is just around the corner for tps-reports developers. They've been using 1.9.3.1 for quite a while now and, since there are no known bugs in this version, they're comfortable with an old version. Now, they want to use the revamped object-pooling, so they update their pom.xml to use version 2.0.0.0 and it now looks like this:
<name>TPS-Reports</name>
<description>
TPS Reports frontend.
</description>
<dependencies>
<dependency>
<groupId>com.initech</groupId>
<artifactId>gui-components</artifactId>
<version>2.5</version>
</dependency>
<dependency>
<groupId>com.initech</groupId>
<artifactId>multithreading</artifactId>
<version>3.7</version>
</dependency>
<dependency>
<groupId>com.initech</groupId>
<artifactId>utils</artifactId>
<version>2.3.0.0</version>
</dependency>
<dependency>
<!-- use object poooling's new features -->
<groupId>com.initech</groupId>
<artifactId>object-pooling</artifactId>
<version>2.0.0.0</version>
</dependency>
</dependencies>
They discover that they have new bugs. Needless to say, these bugs did not exist when they depended on version 1.9.3.1 of object-pooling. They dig into their code repository's log and they discover that, not only the object-pooling guys have done thousands of commits, but also that they are using the newest versions of multithreading and utils, which also have lot of commits.
There are, obviously, a myriad of places where the problem can reside. It can be on object-pooling, it can be in the interaction between object-pooling and tps-reports, it can be on multithreading or utils or any weird combination.
The question(s) is(are): How do you guys go around this kind of problems? How do you manage dependencies on big projects that in turn depend on other projects? Are there some tools out there to assist on this task?
Thanks!
Sorry, no silver bullet here: unit testing is the answer. The bigger the project gets, the more important automatic testing becomes.
In your case, even if the bugs arise in manual testing it eventually comes down to particular case of using the library and you may be able to reduce this to a unit test. The test will pass in 1.9.3.1 and fail in 2.0.0.0.
Now you can send the test case to the object-pooling developers and tell them you are not upgrading until they make this and other tests pass. This will make their life a bit like yours and given enough test cases, your life will eventually be more like theirs :-)
If the bug is in their dependent library, they will have to do the same thing to their downstream developers.
I'd use several pom-configurations and put them all into a continouos integration server to get an overview under which circumstances certain tests fail.
Related
I'm trying to update my karate project with the newest version of karate-junit5 library.
In the documentation for Maven it's mentioned that only one dependency is required to run karate.
<dependency>
<groupId>com.intuit.karate</groupId>
<artifactId>karate-junit5</artifactId>
<version>1.3.0</version>
<scope>test</scope>
</dependency>
Previously I was using karate-jersey and karate-junit4 and everything was working flawless.
<dependency>
<groupId>com.intuit.karate</groupId>
<artifactId>karate-jersey</artifactId>
<version>0.9.6</version>
<scope>test</scope>
</dependency>
<!-- https://mvnrepository.com/artifact/com.intuit.karate/karate-junit5 -->
<dependency>
<groupId>com.intuit.karate</groupId>
<artifactId>karate-junit4</artifactId>
<version>0.9.6</version>
<scope>test</scope>
</dependency>
I managed to update karate-junit4 to karate-junit5 but I see that karate-core is still using 0.9.6
When I want to replace jersey with karate-core 1.3.0 and run my tests I have an error with loading my karate-config.js
karate-config.js failed
js failed:
org.graalvm.polyglot.PolyglotException: SyntaxError: Unnamed:82:0 Expected ) but found function
This is strange because I didn't change anything besides the dependencies.
Do I still have to use karate-jersey in my project? The documentation doesn't mention this.
I tried to update the dependency to the newest version. Now I got a failing karate-config.js
There's no such thing as karate-jersey. Get rid of that dependency, the HTTP client is now built-in.
Since you are upgrading from such an old version, you need to read all the release notes. For example this one: https://github.com/karatelabs/karate/wiki/1.0-upgrade-guide#java-projects
But let's hope you get by with just this one change. Else be prepared to scan all the release notes. The JS engine has changed, but all those who kept tracking the project and tried RC versions (we spend a lot of time on this) have been having a smooth experience.
I guess this is what folks call "technical debt" ;)
Can anyone help me to find the link of below jar
org.openqa.selenium.support.ui.Select
How did you add selenium to your project and what IDE are you using?
If you downloaded the jars manually from the selenium website then they're here:
They're in client-combined-3.141.59.jar and when you add it to your IDE you'll have the path you want.
However its not good practice to download and add them manually. You'll be stuck manually upgrading them and having trouble with remote execution.
It's much better if you use maven or gradle to manage this for you.
As one quick example, in maven you add this in you pom.xml:
<!-- https://mvnrepository.com/artifact/org.seleniumhq.selenium/selenium-java -->
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>3.141.59</version>
</dependency>
It manages your dependencies for you. You get this in your project:
I would like to upgrade to Karate 0.9.0 which is released recently. How can i do this easily. My existing .pom file contains many dependencies in 0.8.0 version. Should i replace each with updated one? Or, is there a better way to do this?
And again, i can see many RC versions of dependencies in maven repository which one's stable?
And, Finally, Is there any separate dependency for KarateOptions? Because, I was using 0.8.0 and was not able to find any dependency jars for this.
This is actually a maven question. But yes the recommended practice is to define a maven "property" once and then use it in the multiple places.
I'm surprised, because at the max you should have only 2.
<properties>
<karate.version>0.9.0</karate.version>
</properties>
<dependencies>
<dependency>
<groupId>com.intuit.karate</groupId>
<artifactId>karate-apache</artifactId>
<version>${karate.version}</version>
</dependency>
<dependency>
<groupId>com.intuit.karate</groupId>
<artifactId>karate-junit4</artifactId>
<version>${karate.version}</version>
<scope>test</scope>
</dependency>
</dependencies>
And yes, KarateOptions is new in 0.9.0 - please read the release notes carefully and you don't even need to change that immediately when you upgrade: https://github.com/intuit/karate/releases/tag/v0.9.0
I have recently switched from using Eclipse to IntelliJ, and am preferring the experience.
However, the IDE is not understanding any of the Annotations. I am using Spring #Autowired annotation as well as some of the Spring-WS annotations and the IDE is telling me that they are unresolved.
When the project is built using Maven, it builds fine, and the Annotations are recognised in Eclipse.
Im sure this is a simple setup thing, but cannot find any information on how to set it up.
As Peter said, when correctly importing the Maven project the dependencies should be correctly recognized. The IntelliJ manual has a section on how to import a Maven project.
For the record, in our project pom, we have the following dependencies:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>3.0.5.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-orm</artifactId>
<version>3.0.5.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework.ws</groupId>
<artifactId>spring-ws-core</artifactId>
<version>2.0.1.RELEASE</version>
</dependency>
The former two have been present already before implementing a web service, so they may not be required strictly for web services.
I'm trying to build a WS with Spring 3.0 and CXF. I'm following the steps of this article http://www.ibm.com/developerworks/library/ws-pojo-springcxf/
But in that article, the authors assume that you have cxf installed. I'd like to embed CXF in my .war.
Thanks in advance.
Normally, just depend on cxf-rt-frontend-jaxws and cxf-rt-transport-http. Pretty much the rest of the stuff needed would be pulled in transitively from those. (might not even need cxf-rt-transport-http) That would cover 90% of the usecases.
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-jaxws</artifactId>
<version>2.2.5</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-transports-http</artifactId>
<version>2.2.5</version>
</dependency>
For more advanced things like WS-Security and WS-RM and JAX-RS, you would need to add additional modules.