We're upgrading the jetty version from 8.x to 9.x in our project.
It was org.eclipse.jetty.aggregate:jetty-all-server:8.1.7.v20120910
But for 9.x, I can't find jetty-all-server anymore, instead, I found org.eclipse.jetty.aggregate:jetty-all:9.2.7.v20150116, notice the package name has changed to jetty-all
So I wonder is jetty-all-server stopped at 8.x and it changes the name to jetty-all at 9.x? Or there will be new jetty-all-server at 9.x in the future?
There is no such thing as jetty-all-server for Jetty 9.
Seeing as there are so many components of Jetty that are, in fact, conflicting with each other, the whole aggregate concept is really not viable any more. The introduction of npn/alpn for the spdy/http2 support also makes the aggregate impossible due to bootclasspath requirements.
The choices for the jetty group with aggregates are to either make every permutation of aggregates (currently standing at over 400 different combinations) or none.
We left jetty-all as a helpful one for use in the jetty-documentation for the getting started / introduction to Jetty phases, but it is absolutely inappropriate for production use.
Use a build tool (maven, gradle, ivy, buildr, grape, sbt, leinengen, eclipse, intellij, netbeans, make, shell script, etc..) and add the components from standard jetty to your project. You can even make an aggregate of your own.
Related
My RCP application makes calls to SOAP web services and has been using the built-in JAXB/JEE components in Java 1.8. I have set up the build process to force the use of Java 1.8 and this had been working well.
Recently, the build stopped working because the builder (Tycho) now has a component which only works with later Java versions. If I compile with the later version I get 100's of JEE-related errors such as JaxbElement not found or #WebMethod not found.
At some point we will have to move away from Java 1.8 and use a Java version which does not provide those JEE components, so forcing the use of 1.8 can only be a short-term solution.
Is there an eclipse plugin which already provides those missing components? (I have searched but not found anything) Or do I need to create my own helper plugin which contains the necessary libraries? Is there perhaps a JAXB alternative which I could use for the SOAP calls?
The JAXB plugins/bundles are available on Eclipse Orbit: the plugins/bundles starting with javax..
In the plugins/bundles where they are needed, add the dependency in the MANIFEST.MF file via Import-Package (using Require-Bundle would require that these plugins/bundles are available even when using Java 8).
See also this answer.
I have a few components and some projects using them. All the dependency management is done using maven. I'd like jenkins to check if code changes for a component would impact a project even if the project isn't using the newest version of it.
Let's say I have component foo, and projects bar and baz.
project_bar uses component_foo version 1.0.0
project_baz uses component_foo version 1.1.0-SNAPSHOT
While I'm changing component_foo version 2.0.0-SNAPSHOT so it can be used by project_baz I'd like to know if it could break project_bar build.
Being able to ignore a major version change (don't check compatibility if component_foo new version was 2.0.0-SNAPSHOT) would be a bonus but not required.
There is on magical way in Jenkins to do that.
This is something handled by compiling the projects with the new dependecy version. To ensure functionality is not broken you need to have unit tests and preferably possibly system tests for you projects.
Recently I was assigned to a task wherein I have to upgrade the existing standalone java application from Java 1.6 to Java 1.8.
I'm yet to go through the code and I have no idea about this project.
They were using
ANT 1.6.1,
AXIS 1.5.1,
ABINITIO 2.15,
ORACLE 11.1.0.7,
AUTOSYS R11,
Java 1.6.
I got to know that first I need to identify whether the above mentioned Tools/Frameworks are compatible with Java 1.8.
Please suggest what are the other challenges I might encounter while compiling and building the application?
Although Java is supposed to be backward compatible between versions, it's also known that backward compatibility in any language isn't aways as straight forward as the name suggests. Some (most) projects release it's libs versions compiled specifically targeting one or another development kit, to take advantage of new features and enhancements added to the language.
That being said, I believe the smarter way to go would be: first, update the project's JDK and rebuild it targeting the new bytecode's version. There's a chance you'll have to upgrade both Ant and (if that's your IDE of choice) Eclipse (see here why).
Second, you'll have to check for compilation errors, which will most likely lead you to update libraries conditionally to get them fixed. With those solved, you MUST run your app and see if it's running as intended; remember that compilation problems are just the top of the iceberg when the subject are dependencies.
Carefully check the app's logs looking for exceptions of any kind but mainly the ones related to class loading exceptions such as ClassCastException, ClassNotFoundException, NoClassDefFoundException, UnsatisfiedLinkError and others. If any apear, you'll have to pinpoint one by one and search for the specific solution of the specific troublemaker library.
With all that covered, you should have your app running healthily again.
One last hint, if this project of yours is still being developed, it would be a very good practice to keep the tools you use updated to their very last release. Keep also the development tools updated, like build (such as Ant, Maven, Gradle and others), JDK's and IDE's. It way easier to upgrade the pieces as they are release than to handle a mass scale upgrade :)
I am migrating an application that used Jetty 7.4.5.v20110725 to Jetty 9.3.0.M2, using Maven. I already had upgraded the javax.servlet-api to 3.1.0.
But I am using the FakeHttpServer version 0.3.0 for tests, and at this time there is no newer version. It uses the org.eclipse.jetty.server.nio.SelectChannelConnector class that used to exist up to Jetty 8.x, but does not exists anymore in Jetty 9.
Currently my projects breaks at runtime with a NoClassDefFoundError due to the removed class in Jetty that FakeHttpServer tries to use, holding me back from upgrading Jetty. What can I do to fix that?
Note, this was also cross-posted in the Portuguese StackOverflow version: https://pt.stackoverflow.com/q/64548/132
Upgrade the code that uses Jetty on FakeHttpServer for Jetty 9.
That is your only choice if you want to use Jetty 9 with FakeHttpServer.
Looking at the project page for FakeHttpServer, it seems that there have been no updates (commits) to the project tree since Dec 2012.
You'll either have to convince the project leads to update it, or do it yourself.
Note that Jetty contains several ways of testing webapps. Look at the unit tests in the jetty source code and I'm sure you will find the equivalent of FakeHttpServer.
ServletTester comes to mind as one example. Or just create a Server using the LocalConnector is another way.
I developed a plugin using Eclipse Indigo. It depends merely on the usual suspects like org.eclipse.core.runtime etc., there is only a single unusal prerequisiste org.eclipse.imp.runtime.
I am quite sure that the latter should run with 3.5.
Now I have the problem telling potential users what Eclipse version they'd need at least to install it.
Will it even be installable on previous versions when developed with 3.7?
If so, how can I find out what the minimal required versions are (I hope that I do not need to edit version numbers etc. in the plugin.xml?)
If not, does this mean I have to install, say, Eclipse 3.5 somewhere and build it there if I want to support 3.5 and higher?
Can this help you: http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Fguide%2Ftools%2Feditors%2Fmanifest_editor%2Fdependencies.htm
It is said, that:
You can also specify the Minimum Version and Maximum Version of the plug-in dependency.