On 10/19/2011 09:32 PM, Anders Hammar wrote:
>> 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. A
>>> Regarding your use case: do you have a) N products which need to be
>>> packaged all in the same way or b) one product which has to be packaged
>>> in N similar variants? Or where is the variation in your packaging
>>> otherwise? What differs between the projects you're attempting to package?
>
On 20 October 2011 06:38, Dirk Olmes wrote:
> 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 install
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
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
n every project (like the site-plugin)
LieGrue,
strub
[1] http://mojo.codehaus.org/sql-maven-plugin/execute-mojo.html
- Original Message -
> From: Dirk Olmes
> To: Maven Users List
> Cc:
> Sent: Wednesday, October 19, 2011 7:55 PM
> Subject: Re: writing a 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
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 Anders,
Anders Hammar wrote:
> Today, activating a profile defined in a parent from the child is not
> possible.
this is not entirely true:
= %<
$ find .
.
./child1
./child1/pom.xml
./child2
./child2/pom.xml
./child2/v.xml
./pom.xml
= %< =
Today, activating a profile defined in a parent from the child is not possible.
/Anders
On Tue, Oct 18, 2011 at 14:35, Tomasz Pik wrote:
> On Tue, Oct 18, 2011 at 1:28 PM, Dirk Olmes wrote:
>> Hi,
>>
>> our Maven (2.2.1) build generates install zips with obfuscated sources
>> from the artifacts
On Tue, Oct 18, 2011 at 1:28 PM, Dirk Olmes wrote:
> Hi,
>
> our Maven (2.2.1) build generates install zips with obfuscated sources
> from the artifacts within the build. Over the last year we created more
> and more installer packages this way, using the famous copy/paste approach.
>
> I'd like t
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. Not sure though how this would work with your
obfuscated sources jars though as pl
Hi,
our Maven (2.2.1) build generates install zips with obfuscated sources
from the artifacts within the build. Over the last year we created more
and more installer packages this way, using the famous copy/paste approach.
I'd like to clean things up so I thought I'd create a parent POM with
pom
15 matches
Mail list logo