also this http://jira.codehaus.org/browse/MSCMCHGLOG-26
On Mon, Dec 1, 2014 at 4:43 PM, Dan Tran wrote:
> I ran into similar issue when running with license:third-party-report on
> command line. Is there a special handling to get the this type of report
> MOJO to run by itself?
>
> Thanks
>
> -
I ran into similar issue when running with license:third-party-report on
command line. Is there a special handling to get the this type of report
MOJO to run by itself?
Thanks
-D
On Wed, Mar 20, 2013 at 1:07 PM, Li, Jing wrote:
> Hi there,
>
> We have maven projects, it works when using mvn
>
But I see we should probably move to use the PluginDescriptor .. hahahah
Manfred Moser wrote on 01.12.2014 15:58:
> We have implemented a mechanism for this in the Android Maven Plugin .. you
> can
> use the same..
>
> https://github.com/simpligility/android-maven-plugin/blob/master/src/main/ja
We have implemented a mechanism for this in the Android Maven Plugin .. you can
use the same..
https://github.com/simpligility/android-maven-plugin/blob/master/src/main/java/com/jayway/maven/plugins/android/PluginInfo.java
Also check out the build setup in the pom for populating the properties
It looks more like a Spring problem with a bean definition.
It looks like you have configured something that is looking for a
resource bundle that you have not provided.
In your build section you do not mention any resources that you want
included in your war.
When you look at the deployed
Firstly, thank you for your answers.
1 - Spring Tool Suite is Eclipse with some plugins to work with Spring. 2 -
The path is correct and there are jars downloaded via maven.
I believe if someone can give me possibilities for this message it will be
very usefull.
I placed the pom below and the entir
Just to be sure that we are on the same page:
Your request is if the maven-release-plugin could be changed, so you can
specify versions for external (i.e. non reactor/multimodule) dependencies.
I won't allow this unless it can be automated, hence the introduction of
the VersionPolicy. This is
It all depends how you use them.
There are some use cases where they make sense.
Usually these use cases include aggressive shading of the dependencies you
are bundling.
Some cases where it can be useful:
* If you are interfacing with a non-maven aware build tool chain - here the
uberjar makes
I don't know about 'harmful', but there are certainly some good ways to
shoot your toes off.
My convention is that I only use shaded jars as exports to the non-Maven
world, I discourage using shaded jars as part of a larger dependency graph.
I could detail some mishaps which motivated that convent
I wrote this in 2011
http://blog.artifact-software.com/tech/?p=121
which describe our use of aggregation jars.
It is, of course, focused on the wonderful advantages that these offer.
It may have prompted the discussion that you recall so this might give
you a time-frame to narrow your search.
I seem to recall a post in the not too distant past where is was at least
implied (if not outwardly stated) that the use of uber jars was an
anti-practice. Unfortunately I can't find it now and my google-fu is
failing me.
Am I making this up? Can anyone confirm my recollection?
Is there a best
Hi all!
I have two multi-module projects where the first one is a dependency of
the second one. Usually before a release of the second one also the first
one is released and the second one has to update the dependency-version
which is set via a property.
For this update I use versions-maven-plugi
Am 01.12.14 um 12:11 schrieb Stephen Connolly:
/**
* This plugin's descriptor
*/
@Parameter(property = "plugin")
private PluginDescriptor pluginDescriptor;
From there you use
http://maven.apache.org/ref/3.2.3/maven-plugin-api/apidocs/org/apache/maven/plugin/descriptor
/**
* This plugin's descriptor
*/
@Parameter(property = "plugin")
private PluginDescriptor pluginDescriptor;
>From there you use
http://maven.apache.org/ref/3.2.3/maven-plugin-api/apidocs/org/apache/maven/plugin/descriptor/PluginDescriptor.html#getVersion()
On 1 December 201
Thomas Scheffler wrote:
> Hi there,
>
> I try to write a simple plugin. I want to have access to the version of
> this plugin. As maven already knows it, I wondered, if I can get access
> to this version string somehow without hardcoding it in properties or
> java code.
Read it from the manifest
15 matches
Mail list logo