My environment is STS 2.8.0-M2 with Grails 1.3.7. I have a Grails project and a plain Java/Maven project in my workspace.
I am used to M2Eclipse workspace dependency resolution for plain Java/Maven projects and I'd love to see something similar working with Grails. According to the docs it appears like Maven dependencies can only be pulled from a repository or a flat directory but NOT from another plain Java/Maven project in the same workspace. As far as I know, that's a feature coming from M2Eclipse, but enabling this one on the Grails project just causes STS to crash and I assume that it would still conflict with Grails even if I would use the Grails Maven plugin.
Do you guys have any advice or practical experience how to enable workspace dependency resolution with Grails in STS 2.8? I want to avoid having to rebuild a dependent project during development over and over.
Thanks!
For Beta/UAT releases I use artifactory to deploy my jars and grails picks up from the local artifactory with the mavenRepo variable in BuildConfig.groovy pointing to the local artifactory.
eg
mavenRepo "http://maya:8081/artifactory/plugins-release-local/"
Development environment:
1)For plugins I use the line
grails.plugin.location.'plugin-name'="../PluginProject"
2) For normal java project I reference it directly using the build properties of the java project.
BuildConfig.groovy fulfills all my requirements and I never used maven in grails projects
Related
I have installed Jenkins plugins in two ways i.e. manually keeping the .hpi file in Jenkins home directory, and installing from Jenkins front-end (Manage Jenkins > Manage Plugins).
What I notice here is when I install the plugin manually (downloaded as .hpi file) it installed with extension .hpi and while installing the plugin through Jenkins front-end I notice that plugin again installed as .jpi.
But why? What is going on in the background? I know functionality won't change but it looks interesting to know.
Both are supposed to be identical to that extend that Jenkins is renaming hpi to jpi when you install it manually as you said.
The reason why you see both in your JENKINS_HOME is the order in which plugins are loaded when Jenkins boots up: plugin.jpi gets precedence over plugin.hpi in case both are present. This is the way the upload installation makes sure the uploaded version will override the existing one after the restart.
Well I think its because Jenkins forked from Hudson so that is the 'H' in hpi. The J is obviously a change to that.
In terms of technology, the jpi plugins are generated using the gradle plugin architecture and hpi plugins are generated with the Maven architecture
Ultimately, as you have found both produce plugins which Jenkins can use. The vast majority are built using Maven but I am a fan of Gradle as it links nicely in with developing plugins in Groovy. You can also build in Groovy using Maven
Plugins as present in $JENKINS_HOME/plugins/ should always be using the .jpi suffix (with the basename being the plugin identifier). Normally Jenkins will enforce this naming pattern even when uploading a plugin manually, regardless of what filename you used for the upload, so I am not sure how you came to have a *.hpi file here, unless you directly copied it into this filesystem location.
I've created new grails plugin with this quick start reference.
How could I install it to local and remote repository to make it available for other plugins to depend on.
Thanks.
If you are creating a grails "plugin", you should be referring to this information instead. The one you are referring is for creating a Grails Application.
Gist:
Grails app (one you are referring to) creates a deployable component which can be deploed to any container and accessed. On the other hand, grails plugins are extension/modules that are created and maintained separately. packaged as zip and are plugged to any Grails Application when required.
If you are creating a grails plugin and want to push it to local/remote repositories, you need to use the release plugin which comes inside a plugin by default.
grails maven-install
The command is taken from release plugin to push your plugin to local maven repositories, if you have any.
We recently converted to maven, I'm really new to it. I've imported the project into eclipse, the "build automatically" by default is on, and I have no idea what it does. Is there a way for me to see the logging message, to configure it so I can make it not to, say, use the default goal, but a different goal every time? BTW, currently, building in CLI is fine, but the resource filtering is not working in eclipse with "build automatically" turned on.
Thanks in advance!
David
If a maven plugin will be executed in an incremental eclipse build depends on the "lifecycle mapping" configuration.
You will find (detailed) information about this topic on the "M2E plugin execution not covered" site.
A quote from this site:
We call these instructions "project build lifecycle
mapping" or simply "lifecycle mapping" because they define how m2e
maps information from project pom.xml file to Eclipse workspace
project configuration and behaviour during Eclipse workspace build.
There are several possibilities how the lifecycle mapping can be configured (in the pom, in m2e extensions, since m2e 1.1 (SNAPSHOT) in metadata provided by the plugin).
You should have a look at this site and hopefully you will be able to setup a configuration/installation that fits your needs.
This has been very upsetting for me up till now. Here is what I am trying to do:
IDE I'm using is Intellij IDEA.
Building a grails application.
Grails application specifies two dependencies on in house grails plugins also being developed in IntelliJ as separate grails plugin projects.
Now to make any changes to plugins, I update the source code in plugin projects and use mavan-install (Maven Publisher plugin) to deploy to local Maven repository.
I have to uninstall the plugin in core grails project. Delete the plugin cache from ivy and then run the core grails project which gets the latest copy of plugin from local maven repository.
What's the effective and ideal way to achieve this? A single change makes me do some 5 minutes of labour work to even test and run core application.
Any recommendations/ best practices?
Use inline plugins for this - see section "Specifying Plugin Locations" in http://grails.org/doc/latest/guide/12.%20Plug-ins.html#12.1%20Creating%20and%20Installing%20Plug-ins
By specifying the plugin project directory with grails.plugin.location.<plugin-name> as the location of the installed plugin, you can edit the real files and the changes will affect the test application, and there's no need to sync anything up.
Good day,
I'm trying to integrate our company's Grails plugins into our Maven repositories (our repositories are named 'snapshots' and 'releases').
To do that, I installed the maven-publisher plugin in all of our plugins, and I'm deploying them using the "grails maven-deploy" command. This works well.
However, if I deploy a SNAPSHOT version of a plugin (say, version 1.0.0-SNAPSHOT), it gets properly deployed in our repository, but I can't install it in our applications (using version "latest.integration").
I'm using Grails 1.3.7.
First of all, when deployed, the actual artifact name has a timestamp added to it ("blablabla-1.0.0-20110421.122823-1.zip"). However, the version is still 1.0.0-SNAPSHOT. I'm guessing that it's Maven that does that transformation.
However, Ivy doesn't seem to understand the transformation, or to handle SNAPSHOT versions. I get errors like:
==== http://myRepo/repository/snapshots: tried
-- artifact myOrg#blablabla;latest.integration!blablabla.zip:
http://myRepo/repository/snapshots/myOrg/blablabla/[revision]/blablabla-[revision].zip
Initial research has revealed that I could create a resolver pattern, but that seems a little bit complicated for something that should work out of the box, and my initial tests were not conclusive anyway (I tried a few patterns, none of which worked).
I should note that deploying my plugins locally using the "maven-install" command works, because the script create an artifact with the proper version (blablabla-1.0.0-SNAPSHOT.zip) alongside the one with timestamps.
Does anybody have a solution?
Thanks!
Guillaume.
I resolved this modifying Artifactory snapshot repository configuration:
<snapshotVersionBehavior>non-unique</snapshotVersionBehavior>
Now when you have foo-plugin-1.0-SNAPSHOT.zip and you upload it the name stays same.