I have modified some grails plugins to customize them for my needs. I am deciding how to best manage these customizations. My thought was to put them in a separate project (which is version controlled) and upload them to my Nexus repository. It seems a little unclean to package the plugin source as part of the project (and check them into version control with the project).
I prefer to have my plugins installed to the .grails directory. Is this the preferred approach for dealing with grails pluging customizations?
The Nexus approach is a good one. It's best to rename the plugin, e.g. with a company-specific suffix, so there's no ambiguity which one you're using.
Related
It is common to have a web admin project which produces a war, and an API project which produces a different war. Each can run on different servers with different firewall rules (in production). The common part is the service and domain layer. Additionally, there may be other components which are optionional which also benefit from being exploded plugins. Exploded plugins allow separation but allow developers to see and modify all source together as if it was one giant project.
In grails 2.5 setting this up was trivial:
create your web admin app in your project root
create your core services app as a plugin in the project root
Add one line in your web admin projects BuildConfig.groovy to use the services project as an exploded plugin, e.g. "grails.plugin.location.coreservices = "../coreservices""
To build the project, you just do grails war in the web admin app folder.
Brilliant. Effortless and effective. Developers just checkout both projects from git and off they go. Works seamlessly with intellij 14 also as a bonus (we dont have a license for 15+ unfortunately so no grails 3 support)
Before we can consider moving to grails 3, we need to be able to do the same thing.
We could only find one post on the subject.
This requires extensive "hacking" of gradle scripts and creation of scripts in the dir above the two projects, which is not ideal for use with git.
In the section "keeping things DRY", they move some stuff from the sub projects build.gradle file into a build.gradle file above the projects. Is this required?
The new master gradle file has "repositories {mavenLocal().." twice. once at the top under buildscript, then again under "subprojects{ project->". Is this correct? Should it not either be only on the main project, or only on the two sub projects, not all 3?
If we introduce optional exploded plugins (with different dependencies), the parent gradle will have to be edited by hand by each developer. This makes it hard to version and control.
The article adds spring security core to the "plugin-domain", not the web app project. Surely the security is added to the web app, not the services/domain layer plugin? an API app project would have different security requirements.
Does anyone have a better way with grails 3, or shall we stick to grails 2.5? There are no features in grails 3 we need, but at some point 2.5 will become too old and migration looks to be infeasible for the most part. The fact there is no affordable IDE with integrated grails 3 support similar to intellij ultimate or GGTS is a big negative also.
"hacking" is not necessary.
Here is official multiproject tutorial:
http://guides.grails.org/grails-quickcasts-multi-project-builds/guide/index.html
mavenLocal() - is a local folder that is used to store all your project’s dependencies. The "buildscript" block only controls dependencies for the buildscript process itself, not for the application code, which the top-level "dependencies" block controls. So you can have different repositories for "buildscript" and "dependencies".
Read the Gradle User Guide for more information. Gradle is harder then old grails build system, but more powerful.
I moved project from grails 2 to 3 and I was pleased with the result.
IntelliJ 2016 - 2017 work perfect with grails 3
I found and followed this tutorial, which is different from most of the other tutorials as it uses create-plugin instead of create-app for the plugin part.
The project then works correctly with eclipse neon 2.
I'm developing a private webapp in JSF which is available over the internet and now reached a stage where I wanted to introduce CI (Which I'm fairly new to) into the whole process. My current project setup looks like this:
myApp-persistence: maven project that handles DB access (DAOs and hibernate stuff)
myApp-core: maven project, that includes all the Java code (Beans and Utils). It has a dependency on myApp-persistence.jar
myApp-a: maven project just with frontend code (xhtml, css, JS). Has a dependency on myApp-core.jar
myApp-b: maven project just with frontend code (xhtml, css, JS). Has a dependency on myApp-core.jar
myApp-a and myApp-b are independent from each other, they are just different instances of the core for two different platforms and only display certain components differently or call different bean-methods.
Currently I'm deploying manually, i.e. use the eclipse built-in export as war function and then manually upload it to the deployments dir of my wildfly server on prod. I'm using BitBucket for versioning control and just recently discovered pipelines in BitBucket and implemented one for each repository (every project is a separate repo). Now myApp-persistence builds perfectly fine because all dependencies are accessible via the public maven repo but myApp-core (hence myApp-a and myApp-b, too) fails of course because myApp-persistence isn't published on the central maven repo.
Is it possible to tell BitBucket somehow to use the myApp-persistence.jar in the corresponding repo on BitBucket?
If yes, how? And can I also tell BitBucket to deploy directly to prod in case the build including tests ran fine?
If no, what would be a best practice to do that? I was thinking of using a second dev server (already available, so no big deal) as a CI server but then still I would need some advise or recommendations on which tools (Jenkins, artifactory, etc.) to use.
One important note maybe: I'm the only person working on this project so this might seem like an overkill but for me the process of setting that up is quite some valuable experience. That said, I'm not necessarily looking for the quickest solution but for the most professional and convenient solution.
From my point of view, you can find the solution in this post-https://christiangalsterer.wordpress.com/2015/04/23/continuous-integration-for-pull-requests-with-jenkins-and-stash/. It guides you step by step how to set up everything. The post is from 2015 but the process and idea are still the same. Hope it helps.
I am still somewhat green to Grails. Seems to me that there are multiple locations where you can put dependent JARs, among them are BuildConfig.groovy and then there is dependencies.txt in the grails folder and then there can also be n number of 'lib' folders.
What is the difference between these? When use one over the other? Why can't Grails have one central place where all dependencies are kept?
The preferred method to manage your dependancies is through BuildConfig.groovy since it's uses repositories (maven for example) for making those resources available.
The reason for grails-app/lib being available for use is because there are cases where resources aren't kept in a repository for one reason or another and you need a way to include the resource directly with the application itself.
When in doubt always use BuildConfig.groovy unless you have a use case where you can't.
Update
The dependencies.txt file is simply a listing of the dependencies used by Grails and is not used to resolve them. You can read more about it in the documentation.
You can find a list of dependencies required by Grails in the
"dependencies.txt" file in the root directory of the unpacked
distribution.
One of the tips Burt Beckwith provides when creating plugins is to delete files you don't use.
So if you don't use UrlMappings.groovy - delete it.
I was wondering about directories. If you have no controllers, should you delete the controller directory?
Thanks
The short answer is "Yes, you should." Looking at some of the other plugins you can see this is pretty standard practice. For example the Redis plugin on GitHub.
You can delete directories, but they'll get re-created after running various scripts, in particular package-plugin. I tend to remove them as source folders in GGTS so they're not distracting - I like to only see directories that are being used. I used to use an Ant script to do various build tasks for plugins, but at this point all I use them for is the post-package-cleanup task that deletes unused folders, e.g .https://github.com/grails-plugins/grails-spring-security-core/blob/master/build.xml.
It turns out that only three plugin files are required - all of the rest can be deleted if they're not used. These are the plugin descriptor, application.properties (although this is only used to specify the Grails version), and BuildConfig.groovy. BuildConfig.groovy might be optional too if you don't need to publish the plugin to a repo and have no dependencies. At a minimum it's needed to specify the release plugin, but if you don't need that they you can probably get by with just 2 files :)
I currently have one workspace for our 'Mainline' code, and 1 workspace for each branch that we create at the end of each iteration. I am using STS and grails 1.3.6, with no added plugins and a couple of java jar files. It seems like whenever I create a new workspace for a new branch, the branch workspace ends up getting corrupted. I start getting build errors locally revolving around missing hibernate classes such as AbstractEntityPersister. I am working in a Windows 7 environment.
My question is two-fold.
One-Is this problem likely related to a caching issue? Theoretically the build grails dependency jars should be the same between the workspaces, so I don't know why one workspace would have problems and one wouldn't
Two-What is the best way to debug said problem? Currently the only thing I'm going on is the Problems view and then comparing the two workspaces as best I can.
By default, grails uses "$USER_HOME/.grails/grailsVersion/projectName" as a working directory, so having two projects with the same name and same grails version will cause you several headaches.
Take a look at the docs below, you'll want to set 'projectWorkDir' in each project BuildConfig to prevent interferences.
http://grails.org/doc/latest/guide/commandLine.html#buildCustomising
Do your project working directories have the exact same name?
Grails creates a project cache folder in $USER_HOME/.grails/<grailsVersion>/projects/<basedirname> which contains compiled plugins and scripts. Even running grails clean does not wipe out these directories.
It's likely that the two projects that have the same name are updating files in this folder simultaneously. In theory this shouldn't mess anything up because you're probably not working on the two projects simultaneously, but if you have both open in STS it might be auto building and messing with the automatic reloading mechanism that Grails uses.
I would try to set the working directory in BuildConfig.groovy or override the folder using grails -Dgrails.project.work.dir=work as documented.
Failing this, I would suggest disabling any auto build in STS as Grails itself will compile/reload classes when run-app is running. Also I would try editing your application using a text editor (Sublime Text 2 is fantastic) instead of STS to see if you have the same problems.