On 20.10.2011, at 00:21, Ansgar Konermann wrote:
Am 18.10.2011 13:28, schrieb Dirk Olmes:
I am aware of the section but fail to see if it
would
help: I'd still have to list all the plugins to be executed in the
individual installer POMs.
True, but IMHO a lot better than specifying the whole
On Thu, Oct 20, 2011 at 3:33 PM, Cody Zhang wrote:
> Thank's replay! So sorry！It's wrong！
> I mean,only somebody download source.jar ,but can't download by default!
> Best Regards，
> --Cody.Zhang
Cody, I appreciate that english is not a native language, but I can't
understand what you m
Thank's replay! So sorry！It's wrong！
I mean,only somebody download source.jar ,but can't download by default!
Best Regards，
--Cody.Zhang
On Thu, Oct 20, 2011 at 11:41 AM, Barrie Treloar wrote:
> On Thu, Oct 20, 2011 at 12:05 PM, Cody Zhang
> wrote:
> > Hi,All
> >Deploy source.j
On Thu, Oct 20, 2011 at 12:05 PM, Cody Zhang wrote:
> Hi,All
> Deploy source.jar to maven repository in Our company.
> Maven repository is management by nexus of Sonatype.
> We want that somebody access the source.jar when download binary jar?
> Best Regards，
> --Cody.Zhang
>
When yo
Hi,All
Deploy source.jar to maven repository in Our company.
Maven repository is management by nexus of Sonatype.
We want that somebody access the source.jar when download binary jar?
Best Regards，
--Cody.Zhang
Am 18.10.2011 13:28, schrieb Dirk Olmes:
> I am aware of the section but fail to see if it would
> help: I'd still have to list all the plugins to be executed in the
> individual installer POMs.
True, but IMHO a lot better than specifying the whole plugin
configuration over and over again. This is
Unfortunately it is not possible to include configuration of a plugin
in a custom packaging type. You need to create specific plugins (with
the proper default config) and use them in the packaging type.
/Anders
On Wed, Oct 19, 2011 at 13:43, Dirk Olmes wrote:
> On 10/18/2011 01:55 PM, Anders Ham
> I was able to make the profile idea work in the end. The trick is the
> enablement: the parent module defines a profile that is enabled through a
> property. The child module defines that property. Works like a charm.
That should not work. Are you using Maven 3.0.x or 2.x?
/Anders
>
> More d
Ok, thank you Robert
On 18/10/2011 13:53, Robert Scholte wrote:
The findbugs-maven-plugin is part of Codehaus Mojo[1]
Try their mailing list[2]
-Robert
[1] http://mojo.codehaus.org/
[2] http://mojo.codehaus.org/mail-lists.html
Date: Tue, 18 Oct 2011 10:52:56 -0300
From: fabricio.le
Some plugins already provide the following 2 properties
* skip
* forceMojoExecution
The idea is that those plugins must not get executed when the project is of
type 'pom'. But since most of this plugins in bigger projects get defined in a
'backend-parent' module (or kind of) which is the parent
Am 18.10.2011 um 14:41 schrieb Anders Hammar :
> Today, activating a profile defined in a parent from the child is not
> possible.
I was able to make the profile idea work in the end. The trick is the
enablement: the parent module defines a profile that is enabled through a
property. The child
Well this would have been my guess too, but as I mentionned earlier in
another e-mail, I can also reproduce this on my laptop where there is
absolutely no trace of jenkins.
If you have git and maven on your path, you can reproduce this issue
with this:
* Checkout the code: git clone git://git
> Could it be that you also changed something else? Anyway, I find it very
> disturbing that with 2 projects in jenkins with the exact same configuration
> to the exception of their name (the one that works has a suffix '_2'), one
> of them works and not the other.
Does this not point to perhaps a
Thank you very much for the kind response.
I just made several attempts according to your remarks:
1) Increasing the Heap size to 1G (it used to be 512M)--> that did not work
2) I then tried to configure the maven compiler plugin to fork--> that
did not work either
3) I also increases the maxmem
I saw the same issue this week.
It appeared after a colleague merged in a large piece of work from a branch.
The remedy for us was to increase the heap size used by maven by setting
MAVEN_OPTS.
So i suspect it's caused by some 'silent' OutOfMemory error.
If you havent tried this, trying increas
On 10/18/2011 01:55 PM, Anders Hammar wrote:
> I'm thinking that a custom packing type is what you want to create.
> Then use that as the packaging in those Maven projects where you
> create the install zips, and it will bind the appropriate plugins to
> the lifecycle.
Thanks, Anders. I looked int
Hi,
from my point of view, I would rather use the Maven assembly plugin since:
* the documentation if far more complete
* it may meet additional future requirements
* it seems more active
Its usage is all explained on their website:
http://maven.apache.org/plugins/maven-assembly-plugin/usage.ht
Hi,
I know this post has been quite dated to date, however, i believe it
continues to be relevant to many out there trying to create a zip package.
I have found a maven zip plugin at
http://people.apache.org/~olamy/snapshots/maven-zip-plugin/index.html
http://people.apache.org/~olamy/snapshots/ma
18 matches
Mail list logo
