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.
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.
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
We have a quite big application built on the version 1.8.1. We would like to migrate to version 2.0 or higher. We have a few guestions:
Does exist some step-by-step manual how to do it?
Can we use 2 different versions of ember in the same time? Because of continuous migration...
We would like to avoid overwriting of the whole application...
I would suggest you to update the ember. and keep deprecation warnings open. Then you can try investigating each warning one by one and update the code with the new syntax.
This guide can be very useful : Upgrade to ember 2.x step-by step
Since Ember uses global window scope, it will result in conflicts and its not advisable to use two versions of ember.
It's possible to load different Ember versions based on which route you are on, but I really don't recommend doing that, as you lose all the benefits of having a Single Page App (apps will load again when you transition between them), and you end up doing significantly more work for yourself, with more opportunities to screw up. I'd follow locks' advice and upgrade the app step by step, testing as you go.
I am cleaning up a build system for a product that uses Jetty. Currently the project has
javax.servlet.jsp:jsp-api:2.1
as a dependency. Given that I am using Jetty for my project I suspect using
org.mortbay.jetty:jsp-api-2.1:6.1.5
would be the better option. Am I right/wrong? Can they be used interchangeably? Does jsp-api-2.1 leverage a different implementation? Or is it simply a repackage if jsp-api to assert compatibility with Jetty?
I've been trying to find information about this on the web, so far nothing has come up.
Update: Seems like org.mortbay.jetty:servlet-api-2.5:6.1.5 and javax.servlet.jsp:servlet-api:2.1 have the same relationship.
Jetty has a long and colorful history with jsp, having no jsp implementation of our own we have leveraged other implementations often, judging by the version numbers your looking at those are very old versions where we were maintaining patches on top of the glassfish jsp implementation. I think it was a patch for supporting logging in jetty and then a bug fix or three.
Now a days we have been using the jsp artifacts from the java.net project which was spun out from glassfish a while back. However that doesn't seem to be tracking bug fixes very regularly either so we are kicking around trying the jasper implementation in tomcat.
Back on your question, the jsp-api artifacts are typically just repackaged artifacts since the api doesn't change frequently. We historically rebundled them to keep them paired with the patched implementation.
Now, you are obviously using a jetty-6 setup since your still using org.mortbay packaging but jetty6 and jetty7 are both servlet-api 2.5 so you might be able to get away with using the jetty7 jsp setup, we have a handy pom that declares these artifacts here:
http://central.maven.org/maven2/org/eclipse/jetty/jetty-jsp/7.6.5.v20120716/jetty-jsp-7.6.5.v20120716.pom
These are glassfish bundles as well, repackaged and made into osgi bundles in the process so they can be used with jetty in osgi environments....they ought to work normally though, we package them in our jetty7 distributions.
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.