In this case I actually want to add something, or to be precise, I want my
Jenkins job to add something on the fly with each build.
So I can build an open source project deploying to my organization's repository
manager.
The property approach Manfred pointed out earlier seems to be the most
The flatten plugin can remove sections of the POM that are not needed by
consumers of your software binaries, such as the repositories and
pluginRepositories sections. Isn't that what you are trying to achieve?
Robert Patrick
Sent from my iDevice
> On Mar 10, 2016, at 4:29 PM, Manfred Moser
How so? The flatten plugin just flattens the poms right. If they point to an
internal repo manager .. its still wrong..
Manfred
Robert Patrick wrote on 2016-03-10 14:43:
> Take a look at the flatten plugin...this is a much simpler way to solve that
> problem!
>
> Robert Patrick
> Sent from
Take a look at the flatten plugin...this is a much simpler way to solve that
problem!
Robert Patrick
Sent from my iDevice
> On Mar 10, 2016, at 2:38 PM, Max Spring wrote:
>
> Hi Curtis,
>
> I don't want to have the URL of my in-house Maven repository manager out in
m: Max Spring [mailto:m2spr...@springdot.org]
> Sent: Thursday, March 10, 2016 4:39 PM
> To: users@maven.apache.org
> Subject: [EXTERNAL] Re: "conditional" parent POM?
>
> Hi Curtis,
>
> I don't want to have the URL of my in-house Maven repository manager out
> in the
Hi Manfred,
you're right, "property-injection" is what I want.
I updated my example:
https://github.com/m2spring/wild-inhouse-hybrid-example/tree/property-approach
Thank you!
Regards,
-Max
On 03/10/2016 12:40 PM, Manfred Moser wrote:
You should not use different rool poms. The whole
Hi Curtis,
I don't want to have the URL of my in-house Maven repository manager out in the
open.
Regards,
-Max
On 03/10/2016 12:29 PM, Curtis Rueden wrote:
Hi Max,
Why do you need two different parents? What configuration is different
between your "wild" parent and your internal one?
You should not use different rool poms. The whole upstream parents for your
open source project should be open source as well.
And if you want to deploy to a different repo manager you can make the URLs
configurable as a property that you set in the pom and e.g. override in your
internal
Hi Max,
Why do you need two different parents? What configuration is different
between your "wild" parent and your internal one?
Would it be sufficient to enclose the internal-specific configuration
(e.g., distributionManagement) in a profile? This technique is what my OSS
projects do [1].
What's the best structure for a (multi-module) Maven project which should build "in
the wild" without any Maven repository manager and can easily build within my
organization where deployments should happen to my Maven repository manager?
Ideally, I would have two different paren POMs for each
10 matches
Mail list logo