The question seems easy, but according to my research, the maven repository http://repo.maven.apache.org/maven2/org/primefaces/primefaces/ has only major releases 5.2,5.3,...,6,2
what I want exactly is to use the version 5.2.9 in order to correct the problem of the reCAPTCHA by implementing its v2, the use of the version 5.3 will have much impact on the developed application.
X.Y.Z releases are only available for paying customers as an elite release. You can then download the jar in a portal and put it in your own maven repo. They are not available in any public repository.
What you could try to do is to compare the sources of the 5.2 and 5.3 release regarding the captcha and just backport those. Still, really upgrading (to 6.2) is a better choice
If you have luck, maybe 5.3.RC1, which implements reCAPTCHA v2, is close to 5.2.9. You can get 5.3.RC1 via primefaces repo: https://repository.primefaces.org/org/primefaces/primefaces/5.3.RC1/
Related
I'm working with a Grails application version 2.2.4 and I need a procedure for upgrade to latest version (I hope it can be possible). I have thought as a first step to follow the indications of the official site, but that let me to upgrade to version 3.
I'd like to know if anyone already did it or have experience about that. How long take it?, the process and the main problems.
Many thanks in advance.
I think you need to follow both upgrade instructions. the one for 3.x and the 4.x.
start with the 3.x and them move to the 4.x changes.
Another approach I think may be better is to start an empty 4.x application and then start moving you code there. also check first that all the plugins that you are you sing have 3+ version.
The effort required to upgrade can change massively depending on multiple factors, including the size of the project, the quality of the original code, were plugins used and if so have they been updated or will the functionality need replacing, were deprecated taglibs used, e.g remoteFunction etc. etc.
There is not a great deal of difference between 3.x and 4.x so it makes sense to upgrade to 4.x.
Tackle it in stages from the basis of a new project, attempting to rebuild the project between stages.
Reestablish configuration, you don't have to use application.yaml (the default in 4.x) so can create an application.groovy with the same parameters as per your old project.
Move over domain objects but use a new database URL, compare the schema's between the old db and new db to ensure the database is the same. Unless you don't rely on GORM to recreate/update the schema.
Move over any other source and command objects ensuring the project will build. You may need to modify buildconfig at this stage to bring in dependencies and plugins.
Move over services, ensure all compiles and make sure transactions are behaving as intending.
Move over controllers ensuring any tests run successfully.
Move over the views.
Hopefully if the project is still building at this stage, you can run it!
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
Ours a complex enterprise app and we use one third party library which we would like upgrade.But we do want to maintain two versions atleast for couple of releases till we are good with the newer version and switch which version to use by a configuration property.
We are trying maven shading for the same.
However the problem we are facing is like this. The changes between the two releases are very drastic. For example A is a class in version 1.0 and is now an interface in version 2.0
So let us say for example in the existing client code we say
A a = new A();
This would have to be changed to some other call in the new version.
Are there any ideas on how to make the client code compatible with both the versions?
I don't believe there is a way to write code compatible with both the versions.
Keeping multiple versions of same jar may create maintenance nightmares.
I suggest to create/maintain separate SVN branches for each version of this jar.
You can decide which SVN branch should go into production based on maturity of that branch.
You can simply replace the war from other branch, if any issue during deployment/in production.
We use Maven, Jenkins and Nexus to build and deploy our software. The problem is that it's difficult for support and all of our people to know if a version is still in the QA staging repository, Beta or Release.
What tools are people using to make visibility of this possible? One option is to create a custom webapp that uses the nexus REST api to make it visible but I would imagine this is a solved problem and I shouldn't have to do that.
Any help or pointers in the right direction would be appreciated.
Last year I got virtual server for my server needs, configuration is not great, but things work without problem... Few months ago I installed Nexus Repository manager and after that I have daily problem with tomcat... I now restart machine every night, but still it seems that nexus is unavailable most of time.
I am working on OS project and we need to have repository manager (RM) available to host all our stuff and also all libraries our project needs...
I have currently 3 options (how to solve this problem):
Downgrading maven version to 1.6 (or at least some that is stable and doesn't need so much resources)
Using artifactory (their package seems to be the same size as nexus, but I don't know if it will be better - resource wise)
Using archiva (no idea how stable this is and how good it is)
I am thinking about going with option 3, I just don't know if this is right solution. I am sure some of you have your own RM running, what would you recommend? Do you have perhaps any other options? If I use option 1, which version would you recomend...
Thanks in advance,
Andy
By "downgrading Maven version to 1.6" I assume you're referring to the Java version, as if you're using such an old Nexus, then it doesn't shock me that you're having problems. Upgrade your Java to 1.7.x, as well as your Nexus to the latest one.
Archiva and Artifactory are always options, but I don't think the problem is in Nexus itself, but rather your setup (and you haven't mentioned anything about it).
What version of Java, Nexus, Tomcat are you using?
Also, by "OS project", I assume you mean "OSS" (open source) project. If so, you can use Sonatype's OSS hosting. I've described how to set up an OSS project (using Github, BuildHive and Maven Central) here. You can also just skip to using Maven Central directly, checking here. I think this would be a better option for you, if you're not familiar enough with managing your own repository manager.
I would suggest to run Nexus with the native jetty as supplied by the default download bundle instead of on tomcat. This will give you better performance and also better support.
Of course if you can get all libraries into the Central Repository via OSSRH it would be even easier since you could get by without maintaining a repository manager altogether.