I am using Grails 2.5.1 and trying to use Authentication Plugin 2.0.1.
However, I have an error due to ConfigurationHolder not being found (this happens INSIDE authentication 2.0.1).
It seems that authentication 2.0.1 does not work with Grails 2.5.1 - it is not compatible with how grails structure changed in 2.4.x version.
What good authentication plugin version could I use? Or... How could I fix it? Or... what good authentication plugin alternative could I use?
Firstly, that plugin is no longer under development. The source code is on github, but no one has touched it in years. See this.
Alternatives
I don't know of a drop-in replacement. The closest one I know of is Grails Spring Security.
Fixing it
With some keyboard grease you can upgrade the plugin. If the holder error is the one I'm thinking of, it's easy to fix. Here's a general guideline:
With the source code in hand, check which version of Grails the p!ugin was written in.
Upgrade the plugin to the next minor version. Avoid skipping around.
Using the upgrading from grails section of the Grails documentation make the necessary changes.
Test, then rinse and repeat.
Change the plugin version and do a plugin local install.
Change the version of the plugin in your app so that it uses the new version.
Consider publishing your changes on github.
Related
While trying to generate build we get some plugin dependencies. When trying to add them in .product file, It shows plugin version as 0.0.0 by default. We have a situation to add more than one version of same plugins.
We tried to manually change 0.0.0 to the required version from the dependencies. We are successfully able to launch the application. But while trying to generate a build we get some errors.We have the required plugins installed.
If anyone knows how to add different versions, the help is much appreciated.
Edit:
Image showing the problem
This is the problem we are facing
The solution we tried
We tried manually changing version number but creates error during build generation
I'm not sure that this scenario is supported by PDE Build, because it sounds exotic a bit.
You can try to use different features to introduce different version of bundle.
But I think that more promissing strategy will be to "align" your dependencies, i.e. in your case it is better to select the version of GMF that uses the right Batik version.
Otherwise sooner or later you will get "blocking" bundle with singleton:true in your dependency tree, as #greg-449 mentioned.
Also, please have a look at this question: Tycho | How to build multiple version of same plugin using tycho
See my answer there:
https://stackoverflow.com/a/62426443/9062163
In fact the details I mentioned in my other answer where the result of a successful integration of Sirius 6.0.1 in an Eclipse RCP based on Photon. The troubles came from the integration of Batik 1.7 and 1.6 in the same product, the latter version being forced by the GMF version I use. I also needed some batik plugins of versions 1.8.0 and 1.9.1 for other reasons.
I was checking the liferay V1.1.1 plugin for intellij idea, I could see that you can add liferay servers, you can debug among other things in the Liferay 7.1 version, the problem goes when I want to use jrebel to work with intellij idea for themes and modules , thanks
Try checking out this blog post written by Andrew Jardine over on the Liferay community blog. He covers how to fully configure JRebel to work with Liferay 7.
One thing to watch out for is that in the article in the Agent Configuration section he recommends setting up a javaagent and Xbootclasspath flags. While this works perfectly fine it is a bit easier to use the new recommended agentpath configuration. There is documentation on the JRebel site here on which library you need to use with the agentpath switch depending on which OS and Java bit version you are using.
If things aren't quite working after walking through that blog I would recommend using the Submit a Support Ticket workflow in your IDE (Help > JRebel > Submit a Support Ticket). From there I or someone else from the support team can work with you to figure out what is still missing.
Im browsing Bukkit plugins here: https://dev.bukkit.org/
and a lot of the plugins are abandoned and are outdated.
These plugins dont work without the current version of Minecraft released.
So how are these plugins actually updated to use the latest version of Minecraft?
I went to YouTube for some tutorials but ALL of them are severely outdated and are vague at best on how its done.
Any help would be appreciated.
Thanks again!
Roughly speaking, a plugin is built using a library, that's the same used in the server.
Usually, plugin developers use Bukkit API or a similar one, such as Spigot API to build their plugins.
When the Bukkit Platform gets updated, so does the Library on which plugins are built. Whenever that happens, plugin Developers must rebuild/recompile their plugins for the new version.
When the plugins aren't updated for the new version, they break. Bukkit doesn't always keep version compatibility, and in those case, older versions won't work.
To update the plugins, a developer must import the new library on their source code, and fix any methods that might have changed. He or she should then recompile the plugin and export the jar to be run in a Bukkit Server.
Problem
I'm trying to create a Play 2.3.1 framework, because the lack of info on how to get started with 2.4.3. So much has changed apparently that the tutorials on youtube is useless and I can't get it to work.
Question
How do I do this?
I have tried to go to https://www.playframework.com/download#older-versions but all versions yield the same link to https://downloads.typesafe.com/typesafe-activator/1.3.6/typesafe-activator-1.3.6-minimal.zip
which installs the newest playframework 2.4.3.
Please say that someone knows how to do this?
Also, why should I bother using 2.4.3 > 2.3.1 if I'm only creating a simple mobile app w/database? Security reasons or just "easier"?
Same question for IntelliJ 14 > IntelliJ 13 ?
https://www.playframework.com/download#older-versions is the link you need.
When you're new to Play! it can be quite confusing so I think a bit of terminology is needed.
SBT - Scala build tool. This is a build tool that is baked into every Play! project but totally independent of Play! framework, ie. many Scala projects use this to manage their builds without ever using Play! It's just the Scala equivilient of a Maven, Gradle or Ant. Nothing special.
Activator - This is Play!'s commandline, like a build-tool++. It's commandline tool with a superset of the SBT commands clean compile etc etc, with Play! specific ones like 'new', 'run'. It actually just amounts to not much more than a script (.sh/.bat) which bootstraps SBT and some extra goodness for running play commands. In earlier versions like 1.x this command was named play. Version 2.x was a practically a re-write so you can ignore all related advice.
Play - the playframework itself is just a regular jar (and all its dependencies). It is declared in the project/plugins.sbt
So the reason all the download links point to activator-1.3.6 is because that is just the version of the commandline tool. This will default to latest: 2.4.x.
When you perform an activator new you get a choice of templates. If you REALLY REALLY want to use 2.3.x you could choose this template when prompted hello-play-2_3-scala.
But I don't suggest you do that because:
The documentation for 2.4.x is comprehensive and there are walkthrough guides, it won't take any longer than a youtube video.
There are bug fixes and new features in 2.4.x
2.4.x introduced dependency injection which means it will be harder to upgrade once you'ved developed everything in 2.3x.
Apart from dependency injection most stuff works the same in 2.4.x
Intellij:
Use 14. Play support is improving all the time. If you can use the Early Access Program and the latest version of the Scala plugin.
Don't run 'activator idea' - this is deprecated. File -> open project from Intellij should be enough.
Since the configuration manager and update manager for eclipse 3.2 is devoid of nice options for REMOVING or DELETING all my plugins it can be cumbersome to deal with needing to get your plugins in order. Just getting your dependencies worked out can be a nightmare when you have installed one version too high than you needed depending on the jdk version you are developing for.
Other than trashing the files in the plugins and features directory (which sometimes works) what other options do we have in a M$ environment?
In the situation where you are using RAD 7 you have to deal with the shared SDP70Shared folder too which is a bit ethereal as well.
I want to see a fool proof way to clean house for regular eclipse 3.x, RAD, or any all in one package that will work.
Eclipse 3.2 has "uninstall" feature for plugins under Help->Software updates->Manage configuration.
Eclipse 3.4 has the same functionality under Help->Software updates->Installed software
You could do a complete uninstall of eclipse and use a custom eclipse builder like http://www.yoxos.com/ondemand/]1 to create a build with the base set of plugins you use. I don't recall how eclipse is configured in Windows, but in Linux there's usually a hidden project directory in your work space that you may want to remove just in case. I'm not sure if there's any registry settings you need to worry about though.
The best solution I have found thus far is to uninstall and rebuild from scratch. Sometimes you can delete files in the plugins dir and run CCleaner on the registry and that might fix issues but it is problematic depending on the situation. If there were an application that really could make sense of eclipse plugins everyone would use it but there isn't.
Though it's not recommended to manually remove plugins managed by p2,
I find a regular plugin cleanup greatly improves performance and postability,
especially if you have a master eclipse configuration copied and shared
with multiple developers. In that case it's better to just archive the
master eclipse install instead of relying on everyone to update their
configs in synch.
see
How to remove old versions of Eclipse plugins?