I have a need to use GORM, but to use certain libraries which require JPA 2 or 2.1. I see there is a plugin here (http://grails.org/plugin/gorm-jpa) for using GORM with JPA 1, but it's not been updated since 2012.
Is there a way to use GORM and JPA 2.x together? If not, what steps would one need to take to develop such capabilities?
Thanks in advance.
Related
I am having an application build on grails 2.2.4. I need to update it to grails 4.0.8 Can i upgrade directly. As i checked from various sources, i need to jump first from 2.2.4 to 3.x then thereafter 3.x to 4.x. Please suggest me optimum way to do this upgrade.
Similar to other question about Grails upgrades
Major version upgrades in Grails are rarely trivial. I'd suggest starting a new app in the target version, and migrating classes/functionalities.
In Grails framework, the effort required to update your application depends on multiple factors, such as:
The standard practices. For instance, the persistence stuff in the Grails services instead of controller or domains itself.
The underline plugins your application depends on. You would need to update to the latest version of the plugin, or in some case find an alternative approaches as the plugin may longer be maintained, or there maybe better ways of doing it. For instance, we had some custom plugin for multi-tenancy back when I started with Grails, But now, GORM has great support for multi-tenancy.
I personally think you should directly jump from Grails 2 to Grails 4 by creating a new application, and then move your source code. But, first you need to identify all the variables such as plugins or libraries.
Can Olingo v2.x and v4.x run in the same Java webapp side-by-side?
I know some libraries like Jackson 1.x and 2.x support this: a project can depend on both Jackson 1.x and 2.x, without conflicts
I'm using just Olingo 4, but as far as I know v2 and v4 are growing independently. I don't think it would be a problem to use them both.
And, in the worst scenario, you can use Olingo 2 for OData 2 and SDL OData Frameworks for OData 4, which are totally different libraries.
That should work. I've encapsulated olingo-odata2 and olingo-odata4 in their own Spring Framework based REST controllers and provide services side by side.
I am working on a Grails 2.3 project, and they ask me have to do a study to see if it is possible to pass on the 3.x version of grails.
you can tell me what is it advantageous to switch to the version 3.x, and what's the best way for the update properly.
at the environment working I guess GGTS not supporting GRAILS 3.x, then it is mandatory to work with IntelliJ IDEA.
This section of official documentation covers the topic nicely
Upgrading from previous versions of Grails - Reference Documentation
http://docs.grails.org/latest/guide/upgrading.htmlv
You can also check the following presentation on the topic of the migration
Migrating from Grails 2 to Grails 3
http://www.slideshare.net/SpringCentral/migrating-from-grails-2-to-grails-3
Yes, GGTS currently does not support Grails 3.x, so IDEA Ultimate edition is probably the best choice as described in STARTING WITH GRAILS3 – CHOOSING AN IDE.
Which version of the neo4j plugin should I be using with grails?
The official grails site claims that version 2.0.0-M02 is the latest, but the associated documentation is from version 1.x. Is there later documentation? Has much changed?
I'm interested in particular in how the node structure has been changed to represent the domain model. Is it now the case that labels are being used instead of SUBREFERENCE nodes now?
Is it possible to use a grails plugin outside a grails application?
I would like to use the functionality of grails-mail-plugin in a simple groovy/gradle app.
I found some information about binary plugins but I'm not sure how to define the dependency to an official grails plugin.
Thanks!
I don't think you could use any Grails plugin itself outside the Grails environment, usually there is a ton of Grails-specific assumptions built into the plugins' code.
If your Groovy application uses Spring, you could migrate the most important functionality out of it.
For this, you will have to get into the innards of the source code of the plugin (e.g. how it uses the Spring Mail package for example) which not may be very quick or easy work.
If your requirements are simple, you may be better of with building a standalone solution, possibly, directly on top of JavaMail.
If you already have a heterogeneous architecture, you may build a separate Grails application/module which only does mailing functionality (possibly through the Async Mail plugins database tables) in integration with the module you build in pure Groovy.