I want to use Spark-Java 2.0 with Jetty 9.2. The trick here is that the Maven repository for Spark has dependency on jetty 9.0. The reason is that we already have working code using 9.2. When we bind/load the Spark jar at runtime there are class load errors.
The question is what issues may arise for Spark if I do a build to use jetty 9.2?
They other question could be, can I use excludes some how to load Jetty 9.2 over the 'requested' 9.0 classes? Is that possible, or will it cause me more bother?
Let me know if you think of other considerations. Also let me know where to find release notes for Jetty if you can? I looked for Jetty release notes here: Jetty Documentation hub; it is a little disappointing because they simply link to updated manuals. I look for Release Notes to show me what's different and changed between versions -- A new manual won't help unless I have a way to do 'diff' on the two manuals.
My thinking is that a jump between 9.0 to 9.2 should be a valid increment. My thanks in advance for your insights.
Related
I am using Derby 10.8.2 which requires Gemini DBAcess. These versions are very old (circa 2011) and do not work with JRE > 1.8.
As the title asks, does anyone know of a more recent version that will work in an OSGi evnironment?
Thanks
The Derby community have an open Enhancement Request to support OSGi on the most recent versions of Derby: DERBY-7056
There are a set of proposed changes to provide this support.
My understanding is that the primary blocker on this is access to somebody who is relatively familiar with OSGi and could test the support, as none of the Derby committers are users of OSGi.
So perhaps you could volunteer to work with the Derby community and help get the OSGi support tested and committed?
I'm in need of code that only exists in the master at the moment, and the docs specifically mention a version called 2.0.0.BUILD-SNAPSHOT, but I'll be damned if I can figure out which repository is hosting such a build. Anyone have any clues?
Also, is there any information published about release schedules? I'm loath to develop against the 1.x API because I want the retry and recovery functionality (which doesn't work in either of the 2.0.0 milestone builds, hence my need for a snapshot), but I don't want to commit to an unreleased library without some sense of when a release might happen.
The BUILD-SNAPSHOT you can find in the https://repo.spring.io/snapshot. So, you should configure that for your project.
The next Spring Kafka 2.0.0.RC1 is scheduled for this June 28.
You can find that info on the project page as well: https://github.com/spring-projects/spring-kafka/milestone/20
As per this post Infinispan 4.x can be run on Jboss AS 5.1.0 GA.
1. So, is that it? Can't we run higher versions of Infinispan on Jboss AS 5.1.0 GA?
2. Some bug fixes would have been done on Infinispan 4.x and upgraded to higher versions. So, if I use Infinispan 4.x what all bugs I could face?
You can run any version you like, but you'll have to isolate the classes to avoid conflicting with the ones included in the AS. Of course you can't replace the clustering technology in AS5 with it: you can use it exclusively with your own applications. If you intend to use it with Hibernate make sure you pick an Hibernate version compatible with the Infinispan version you choose: consequentially you might need to bundle a custom Hibernate version as well, and isolate from the older version provided in AS5. Generally, the Infinispan team does not consider AS5 support a goal and we're not actively testing for this.
Hard to tell which issues could affect you not knowing what you plan to use it for. All issues are tracked in the open as well so feel free to check: Infinispan changelog or ask for more advice on the Infinispan forums.
I've been trying to build the 3.2.2 and 3.2.3 tags of WSO2 Carbon from here using Maven 2:
https://wso2.org/repos/wso2/tags/carbon/3.2.2
https://wso2.org/repos/wso2/tags/carbon/3.2.3
However, the Maven pom.xml files throughout the directory trees beneath these tags still refer to version 3.2.0 in both cases - am I missing something obvious please?
When I try and analyse the results of both the builds using our in-house tool I get identical results in the two cases (and indeed results that are identical to those for 3.2.0), which makes me think I may be building 3.2.0 repeatedly by accident.
3.2.2 and 3.2.3 are point releases and typically involves bug fixes/optimizations that do not introduce new features to the 3.2.0 release. If a particular component do not have any fixes/changes, the version still be the older version, no new version is introduced. This is how the versions are handled.
You're not missing anything. It seems they did screw up. Maybe that was their intention, but then it doesn't make any sense at all (at least for me).
Any ideas when cobertura will support java 7?
Found http://sourceforge.net/tracker/index.php?func=detail&aid=3295711&group_id=130558&atid=720018
We preferred cobertura over emma and other code coverage tools and looks like we have to redo all those again, now that none of them support java 7 yet.
Thanks
Cobertura 2.0.3 supports Java 7, the cobertura-maven-plugin version 2.6 which uses this version has been just released
I was able to get it to work by adding the following argument:
-XX:-UseSplitVerifier
I got it from here.
I think the answer is: it won't. There is discussion on the mailing list that the project is not being maintained, and there are Java 7 bugs that have been open for a year. On the bright side, JaCoCo functionality is comparable and is being actively maintained.
Further to Jagger's comment, it looks like this is now being actively worked on for the next release - see:
https://github.com/cobertura/cobertura/commit/b303fdc94851088a3c8699651770faef33180924
with the comment "Fix java 7 stack map issue".
Old thread, but my answer may be useful: Cobertura does support the latest Java versions and is actively maintained. eCobertura (the Eclipse plug-in for Cobertura) hasn't been maintained since 2010, but Cobertura itself is still maintained.
eCobertura will not run with Java 7 or higher, but Cobertura will.
If you are looking for coverage reports (suc h as the ones that eCobertura used to provide), just run the Cobertura maven plugin with mvn cobertura:cobertura and check the HTML report under target/site/cobertura/index.html