How to find list of stable releases for Jetty server? I've checked in github
and maven but still not able to find if its a stable release.
I am getting this warning :
INFO org.eclipse.jetty.server.Server - jetty-9.4.12.RC2;
WARN org.eclipse.jetty.server.Server - THIS IS NOT A STABLE RELEASE! DO NOT USE IN PRODUCTION!
The version "9.4.12.RC2" is a non-final / unstable release.
Some examples of non-final / unstable release keywords found in version strings in the 20 year history of Jetty.
"RC2" - Release Candidate 2
"M1" - Milestone 1
"SNAPSHOT" - A snapshot of a specific build
"Beta"
"Alpha"
"Experimental"
There are 2 different version strings you should be looking for.
<servlet_support>.<major>.<minor>.v<year><month><day> : Extremely Common - this is a historical versioning syntax as seen with Eclipse OSGi, and something that Eclipse Jetty adopted. (eg: 9.4.12.v20180830)
<servlet_support>.<major>.<minor> : Rare - but Jetty will be going back to this shorter form starting in Jetty 10.0 (still many months out)
Note that Jetty versioning has always used the first version to indicate the Servlet support, the second part is the Major version within that Servlet support.
Eg:
7 is Servlet 2.5
8 is Servlet 3.0
9 is Servlet 3.1
10 is Servlet 4.0 (from the new Jakarta EE project)
The documentation has general advice seen at :
https://www.eclipse.org/jetty/documentation/current/what-jetty-version.html
The official downloads page always lists the current stable release as well :
https://www.eclipse.org/jetty/download.html
One final note, don't use mvnrepository.com it's very out of date and often wrong.
Use search.maven.org for the most accurate and up to date information.
Example, if you had used search.maven.org you would have seen what's newer then 9.4.12.RC2
https://search.maven.org/search?q=g:org.eclipse.jetty%20AND%20a:jetty-home&core=gav
Related
I was wondering if it is possible to upgrade DS directly from v8.7 to v11.7? Or is it necessary to upgrade to jump version (e.g v9.1) and then upgrade to v11.7.
We have been using the old version for some time now and this has been a lingering question in the group here. We are looking to get the upgraded functionality of 11.7 but are not sure if it will require upgrading to the jump version first.
we have done many such upgrades from 8.x to various higher versions (9 and 11.3 / 11.5). There is no need to do a "intermediary" upgrade, you can go from 8.x to 11.7. As you are aware, anything lower than 11.3 does not offer in place upgrades.
I would suggest to follow a strategy of exporting all the jobs and settings / message handlers etc and then doing a complete clean install. You have the option to do this on a new server, or, backup and install on your current one.
Once done you can then recreate the projects, import the jobs, amend settings and handlers.
Be aware that between versions things like message handlers may change, settings in DSParams may be slightly different. With importing the jobs it is always a good idea to recompile to ensure there are no issues with the latest version.
Things you may notice: more errors / warnings, such as truncation or type conversions, this is due to older versions of DS not reporting this, but in the newer 9.x and 11.x's these are now announced. Null handling is different (there is a legacy option you can add for example) and some other minor changes. It is a good idea to do a full regression test.
I am going to use SitecoreJSS to develop a website.
- When SitecoreJSS 9.1 would be released?
- what are the limitations and restrictions of using Sitecore JSS 9.0(Tech Preview 4)?
Release date information is not appropriate for StackOverflow. You may want to ask this in the Sitecore Slack community instead (Join via form here: http://siteco.re/SitecoreSlack)
However, for your question on limitations. When JSS is fully released with 9.1, a 9.0-compatible version will also be made available. That version is fully supported.
If you work instead with the Tech Preview 4 that you mention, you will be using preview software which may not be compatible with the GA version of 9.1 and also will not be supported by the Sitecore support team.
Using Redmine v3.3, is it possible to have a custom calculated field based on data in two other custom fields?
e.g. Duration = Date 2 - Date 1
Specifically, I am attempting to calculate the days between two dates as a performance metric. More generally, we will be looking to eventually using other custom calculated fields (simple additions, multiplications, etc.).
It would be preferable to keep this to the "vanilla" Redmine v3.3 without additional plugins but all suggestions are of course welcome.
Not in Vanilla Redmine as of 3.3, unfortunately.
It has been requested and there was some discussion about it. The feature wasn't rejected but nobody has gotten around to building it for Redmine. You can follow the discussion/development here:
http://www.redmine.org/issues/1712
A plugin is discussed in that issue as well but - as with all plugins - a thorough check will be required if it matches your stability/security expectations.
Such feature request has been filed 11 years ago (2008-7-30), while not yet enhanced.
At the moment, you can try Computed Custom Field plugin.
Although it shows "This project is no longer maintained", it stated that it is comptatible with latest stable version of Redmine 4.0.4 (2019-06-10).
Current version: 1.0.7 (2019-01-14)
Compatible with: Redmine 4.0.x, 3.4.x, 3.3.x, 3.2.x, 3.1.x, 3.0.x, 2.6.x, 2.5.x
I'm currently creating an application using silex 1.3.
I want to use the dflydev doctrine orm service provider.
For this service provider pimple >=2.1 is needed - but my silex version comes with pimple 1.x.
I've tried to install a newer version via composer, but this results in an error:
Your requirements could not be resolved to an installable set of
packages.
Problem 1
- silex/silex v1.3.0 requires pimple/pimple ~1.0 -> no matching package foun d.
- silex/silex v1.3.0 requires pimple/pimple ~1.0 -> no matching package foun d.
- silex/silex v1.3.0 requires pimple/pimple ~1.0 -> no matching package foun d.
- Installation request for silex/silex v1.3.0 -> satisfiable by silex/silex[ v1.3.0].
So my question is: how Can I update this pimple version?
EDIT: I've just seen that there's an older release of the dflydev-doctrine-orm-service-provider, which uses pimple 1.x, so I guess I have to use this version.
Nevertheless, I would be intereseted if an update is (theoretical) possible.
Considering how closely Silex is coupled to Pimple, it is not possible to upgrade Pimple without breaking a lot of things in Silex. That said, the upgrade has been a work in progress for a while.
There are several closed issues to update Silex to the new version. Here's one, though there does not seem to be any roadmap for the upgrade.
The master branch of Silex has upgraded to Pimple 3.0. I would watch that branch for any progress. However, as I'm sure you noticed, Pimple 2-3 is not backwards compatible with Pimple 1.0, so if you do upgrade at some point, your other 3rd party service providers will not work until they are updated as well.
Is there a convention for structuring the source code when there are multiple versions of the same web service in the same source code trunk or branch?
Here's our situation.
We version our web services by including the version number in the wsdl URL like this:
url/project/1.0/WebServiceA?wsdl
I'm going to deploy version 1.1 of WebServiceA along with version 1.0 so users of 1.0 don't have to change anything. Version 1.0 and 1.1 of WebServiceA will have their own seperate Java classes.
I want to deploy both versions in the same .war file. (We could adopt a policy of only one version of a web service in the .war and deploy other versions in their own .war. This would result in an increased number of.wars to deploy when we get several versions of several web services. I would prefer to deploy only one .war.)
I'm thinking we should just use a seperate package structure for the various versions:
com.company.dept.ws.WebServiceA (version 1.0)
com.company.dept.ws.v11.WebServiceA (version 1.1)
com.company.dept.ws.WebServiceB (version 1.0)
com.company.dept.ws.v11.WebServiceB (version 1.1)
com.company.dept.ws.v12.WebServiceB (version 1.2)
The Java classes under ws., ws.v11., and ws.v12. would be seperate Java classes.
Can you see any problems down the road with this convention?
If there is a tried-and-true convention for structuring the source code for multiple versions of web service code I'd like to hear about it before I make up my own.
Thanks.
Dean
Since you say you want these versions to all be "in the same source code trunk or branch" I think part of the answer depends on the source control system you're using, and whether or not you ever plan on fixing bugs in older versions.
If you ever want to fix bugs in older versions you'll want the ability to integrate changes forward or backwards between the different versions. For example, suppose you discover a critical security problem that exists in versions 1.0, 1.1 and 1.2. You aren't going to want to fix it 3 times. Most source control systems will let you do that sort of integration between related branches. Some (like Perforce, and I believe also git, and probably a few others) will let you integrate changes between files even within a branch. (in fact, Perforce's concept of a "branch" is just a convenience for recording inter-file integrates)
So you need to think about whether you'll need to make these sorts of multi-version fixes, and if so, can your sorce control system handle intra-branch integrations. If not, then you might be better off using a separate branch for each version.