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.
Related
I am also facing the same issue with Sonar-Gerrit jenkins plugin. Downloaded it from Jenkins plugins site.Using Sonar-Gerrit plugin 2.2.1, and analysing sonar scan against jenkins workspace.
For a sample,have changed just one file and provided the project base directory to the path of that file, and ran the sonar analysis in issues mode.
Issues are not loaded in Gerrit and jenkins logs say
Report has loaded and contains 759 issues Issues to be commented: 0 Issues to be involved in score calculation: 0 Review has been sent
Have already referred the StackOverflow Page Sonar Gerrit plugin not reporting results. Kindly advice on this
I faced a similar issue and for me the resolution was to point the Project Base Directory to my source folder. If you're using sonar to scan all of your source files then pointing the Project Base directory at only one file I don't think it will like that.
There is a bug in 2.2.1. If you have custom sub-project settings, the filter option "affect changed lines only" is not working correctly and removes all the files from the result. This issue will be fixed in the next release.
For now you can use the plugin without this option (all the issues satisfying severity and is new criteria will be posted to the changed files)
If this does not help, make sure that you have your project settings being set up correctly.
UPD: a new version of plugin with the fix was released
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
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.
With TFS 2010 build controllers/agents there is the option to set a version control path to custom assemblies that will be available on all build agents. The documentation states that this works for custom workflow activities as well as custom MSBuild tasks (about in the middle of the page):
http://msdn.microsoft.com/en-us/library/ee330987.aspx
Does someone know how this feature can be used for custom MSBuild tasks? I checked into version control an assembly with a custom task and set the option on our build controller to the correct version control path. But I don't know where the assembly will be on the build agent and how I can reference it from within my MSBuild targets file (i.e., UsingTask).
I even searched for the assembly on the build agent but could not find it...
Any help is very much appreciated!
Here's the answer: the contents of the version control path is stored on the build agent in this folder:
C:\Documents and Settings\<user>\Local Settings\Temp\BuildAgent\<num>\
where <user> is the account that runs the build service, and <num> is the number of your build agent.
I have no clue why it was not there at first and what caused the build agent to finally fetch it from source control. Maybe just some patience is required if the version control path is changed or its contents gets updated?
It's possible, but the simpler solution is to just check your custom MSBuild tasks into a shared location in version control, then map that location into the source configuration for your build. That will also make it easier to use the MSBuild tasks for both desktop and server builds.
I use $(Temp)\BuildAgent\$(BuildAgentID) in TFS 2012. Note that in TFS 2010 it was slightly different. Don't expect this to be stable for future releases.
At my new gig, they use Ant and cannot be persuaded to move to Maven.
I've looked everywhere for a decent example of how a multi-project ant build system should be assembled. The apache site falls short. I'm looking specifically for best practices to:
Automatically build local projects that are dependencies of a project
Share artifacts from project to their dependents
Export a project's dependencies and generated artifacts (jars) to be inherited by dependent projects
Share third-party dependencies between projects
I'm sure I can do all this without using Ivy - what did people do before Ivy? I really don't want to have to set up a corporate repository or rely on external repositories - the engineers here are really against that and have all their third-party jars checked into src control.
Can anyone point me at a good open source example of a multi-project ant build?
I don't have too much hands on experience with building large numbers of dependent projects with Ant, but this tutorial looks like it will do what you need without any additional tools.