commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <>
Subject Re: [commons-parent] m2 profiles for PuTTY?
Date Sun, 10 Dec 2006 22:05:47 GMT
On 12/10/06, Jochen Wiedmann <> wrote:
> On 12/10/06, Martin Cooper <> wrote:
> > Using profiles to provide two different options makes perfect sense to
> me. I
> > see no need to proscribe a "one size fits all" solution that may be
> > non-optimal for many folks when there is a simple means of providing two
> > alternatives that allows for each person to select their preferred
> solution.
> We aren't talking about "joe average profile" here. In particular the
> "release" profile is *the* profile, which is responsible for
> deployment settings.
> I have no objection against duplicating the distributionManagement
> part, so that others may switch to a different deployment scheme. But,
> as I said, this profile does more than simply selecting the deployment
> target. It is also responsible for adding the "source" and "javadoc"
> archives. In the future, it might add additional reports or do more.
> Duplicating the most important part of the POM (and maintaining both
> source and duplicate in the future) seems to me to be bad practice, at
> least if you aren't forced to do it. I do not see that we are forced.

I didn't say anything about duplicating anything. Why can't we split out the
scp-related part into separate profiles, one for scp and one for scpexe?
That way, you could choose "mvn -P release,scp" or "mvn -P release,scpexe"
depending on your preference. That way, all of the stuff you're concerned
about stays in one place, in the 'release' profile.

Martin Cooper

> --
> My wife Mary and I have been married for forty-seven years and not
> once have we had an argument serious enough to consider divorce;
> murder, yes, but divorce, never.
> (Jack Benny)
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message