I can not get the resin-maven-plugin working. Actually I want to test my web app on different App Servers (Jetty, Tomcat, JBoss, Glassfish all work great) by executing resin:run.
I tried the snapshots and final versions, but all have problems. The latest versions report:
Cannot find setter, adder nor field in com.caucho.maven.MavenRun for
'contextRoot'
There is a bug report about this issue, but Caucho is not supporting this plugin anymore.
So here my questions:
Is there a working version available?
If not, where can I find the source code (and then fix it myself)
Related
We are using this openAM 9.5 RC1 branch source in our project. https://github.com/svn2github/openam.git
In order to fix some bugs, we have to modify existing openAM's amserver library. For this, we have downloaded the source code from above location and tried to compile it offline using ant (as stated in README). But we are not able to compile it anyhow (even after making necessary changes, adding dependencies etc.)
Is there any way to construct required library (amserver.jar) from this source code ?
The OpenAM 9.5.x and 10.0.x versions are rather difficult to build, but from 11.0.0 the build process should be much more simpler since the project has been migrated over to Maven build system.
In any case, the version you are using (Snapshot 9.5.1 RC1) is very much outdated and most likely has several critical issues (not to mention the security issues).
I would strongly advise against putting effort into backporting fixes to that ancient version. Instead you should realize that you are running a more than 4 years old version of a security component, and upgrade your system to a more recent version as soon as possible.
First of all I'd like to start by saying that I'm actually a .Net programmer, and it so happens that I need to develop a J2ME app again today. I've have had innumerable problems developing J2ME apps with Netbeans in the past, to the extent that I have had to use someone else's laptop to do the job.
Today I installed Netbeans 7.3. Clean install. I installed the WTK 2.5.2 right afterwards. I managed to configure the platform on Netbeans and all, but once I make a J2ME app and run it I'm getting the following error message:
"Classpath to J2ME Ant extension library (libs.j2me_ant_ext.classpath property) is not set."
Trust me this is quite upsetting since I've looked it up on the net, and it seems the menu items to solve that problem that people have been pointing out to DO NOT EXIST in Netbeans 7.3.
I added an ANT variable: libs.j2me_ant_ext.classpath and set it to C:\Program Files\NetBeans 7.3\mobility\ant\nblib
Still not working. I'm not even sure if that's the correct path, if those are the correct files.
This is extremely frustrating. Can somebody please help?
I've encountered similar problem with nb 7.2.1, it's probably a bug which destroys a part of .properties file in those versions.
Fix your properties in file %project_folder%\nbproject\project.properties (you can copy them from such files in similar healthy projects)
IDEA 11.1.2
I have a Grails app I need to upgrade. The application consists of several modules. One being the application and a few others being plugins. I right clicked on the application and went to Grails -> Change SDK Version. I chose the version I wanted, then IDEA asked me if I wanted to upgrade the application. Clicked yes and all was good.
I've been trying to do the same thing on the plugin modules. IDEA never asks if I want to upgrade and it doesn't appear to change the SDK. If I upgrade the modules from the command line, when I come back to IDEA, it thinks there is a version mismatch and automatically downgrades me without even asking.
Is there a workaround for this?
It worked for me in this IDEA version. Make sure that you change Grails version in application.properties of all plugins:
app.grails.version=2.1.0
Then right-click on every module (plugin), Grails, Change SDK version. It should be changed already.
Have exactly same problem - app + plugins wich requires different SDK (for testing).
After some investigation found that it's an IntelliJ IDEA bug IDEA-114418. So, I think, it will be good if you'll vote for this bug there too.
I also had the same bug. I took extreme measures to rectify it.
I deleted the old grails from the Global Libraries. Go to file>Project Structure > Global Libraries . It should complain that this is used by a module.
Then I had to add grails framework support, but added the new one.
I've just inherited an application written in Grails (version 1.0.3) and would like to upgrade it to the newest release (version 1.3.5).
I can't seem to find a reference that enumerates the differences between the two versions. I know there is the "grails upgrade" command - but is this the best option given the large differences in versions.
I have a similar question that I asked today as well for upgrading the version of Groovy, and the sntactical differences to be aware of (between version 1.3.5 and 1.7.5) - but I thought it may be best to separate the two questions to focus on each.
Many thanks,
~Aki
Things have changed quite a bit since 1.0.3, and unfortunately grails upgrade isn't going to do much for you.
Two significant changes that come to mind are that there was a bug in 1.0.3 and previous where 1-many and many-to-many collections (hasMany/belongsTo) were supposed to be lazy-loaded but weren't. This was fixed in 1.0.4 and several users found that they were relying on the behavior and saw issues. Most people didn't, and just saw a significant performance boost. So watch out for lazy loading exceptions.
Another thing that changed is that plugins are no longer in the root of the project in the 'plugins' folder but are now stored under your $HOME/.grails folder. If you've checked the plugins into source control (and especially if you've made any changes) then you can revert to 1.0.x behavior by adding a property to BuildConfig.groovy (a new file that was introduced in 1.1):
grails.project.plugins.dir = 'plugins'
I described my process for upgrading plugins and apps here: How to install Grails plugin from source code? - it's about a plugin project but the same goes for app upgrades.
The log4j configuration changed from one that's properties-based to a DSL. This means that if you leep your config settings from Config.groovy the log4j behavior will be the default, so you'll need to convert that.
Another change that isn't required but should be considered is that Ivy jar file resolution from Maven repos is now preferred over putting jar files in the lib directory. You can still put them in the lib dir, but it's more DRY to have Ivy download them once.
You'll probably also find that some of the plugins you have don't work in 1.3, so there might be some migration work there.
There are two recent books that cover Grails 1.2/1.3, "Grails: A Quick-Start Guide": http://www.amazon.com/dp/1934356468/ and "Getting Started with Grails, 2nd ed": http://www.infoq.com/minibooks/grails-getting-started - you should probably check those out since they're the most current Grails books.
Overall it shouldn't be that bad, as long as you don't try to upgrade in-place. Use the approach I described in the other post I referenced, i.e. create empty apps and diff files to see what changed (basically a 3-way diff).
The newest release is 1.3.6 (as of Dec 15). You can get a list of changes from the Release Notes of each release. Also, the upgrading from previous versions link the documentation is a good source of changes.
Have been developing with Grails for couple of weeks now,
Though I've loved the experience and the possibilities, I've seen following problems starting up.
Please share if you've had similar issues.. and remedies would help too.
Transaction management (in-built) doesn't seem to work in some circumstances.
AOP with domain objects doesn't work
Grails IDE-plugins are pretty primitive
GWT-Integration (with the plugin)
Plugin installation (fails unusually) probably cause plugins are not matured enough.
Lack of extensive documentation (though what is available is pretty good)
Debugging support
If you actually want solutions for these problems you should post a separate question for each with a lot more information than you've provided here. For example, I can't possibly diagnose the cause of the problem when all I know is
Transaction management (in-built)
doesn't seem to work in some
circumstances.
Here is my opinion on these issues:
Transaction management (in-built) doesn't seem to work in some circumstances.
I haven't noticed any such problem
AOP with domain objects doesn't work
I guess what you mean here is that meta-programming domain objects doesn't work. I have encountered this and haven't found any solution. If you really meant AOP then I can't help you as I've never used it with Groovy.
Grails IDE-plugins are pretty primitive
The IntelliJ plugin is very, very good. The Netbeans plugin is OK. Last time I tried the Eclipse Groovy plugin it was awful. However, I believe that a new Eclipse Groovy plugin has recently been released as part of the Spring Tool Suite (STS). It's supposed to be big improvement on the previous Eclipse Groovy plugin, but I don't think it has much Grails support yet
GWT-Integration (with the plugin)
I don't use GWT, so have no comment
Plugin installation (fails unusually) probably cause plugins are not matured enough.
I've never had problems installing plugins, though if I update a plugin, I sometimes need to manually remove the old version from the .grails directory.
Lack of extensive documentation (though what is available is pretty good)
I think the level of documentation for Grails is way ahead of most OS projects. There is a wide range of Grails books available, there's an active mailing list, and the official document is 176 page long.
Debugging support
Again, it depends on the tools you're using. With IntelliJ, debugging a Grails app is as easy as debugging a Java app with Eclipse.
My own pet peeves about Grails development are:
Upgrading from one version to another is often a very painful process due to lack of backward compatibility. When I upgraded from 1.0.4 to 1.1.1 about 20% of my tests started failing
Application reloading is very hit and miss.
My feedback after few months with Grails:
Didn't happen to me.
I don't use AOP
Wrong. IntelliJ is very good and especially the last beta version. You can download it for a free trial. I know that Eclipse support is very limited and NetBeans becomes better but still behind IntelliJ
I can't say. I don't use it
Agree. My piece of advice here is to follow these following principles: 1.Use plugins as few as you can. Your application will be lighter and more maintainable. Also, you will upgrade Grails version more easily. 2.if you want to use a plugin, test it before with a dummy project. It takes few minutes for creating a grails application and you could test your next plugin rapidly. Be aware that sometimes plugins have compatibility issues between theselves so, do not hesitate to install all of the plugins you need into your dummy project
Agree. Grails is a very complex framework and documentation does not cover every aspect of Grails. But what is available is well explained. Also, grails community is very responsive, so if you don't find something you will easily have an answer in Grails forum or even on StackOverflow
Definitely Agree. Again, with IntelliJ you can debug easily but it is resource-consuming and takes time when reloading your app. So usually, I end up with logging traces and I debugg my full stack of exceptions like that! IMHO, this is one of the major shortcomings of Grails.