maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Graham <chrisgw...@gmail.com>
Subject Re: Build vs Consumer POM study
Date Thu, 19 Apr 2018 10:38:59 GMT
If I've read through (and understood !!!) this thread correctly, then I'd
like to add this:

As the discussions reflect the mature (read: wierd and wonderful!) ways
that Maven is being used, then it is looking like more and more edge cases
are coming up (eg, profiles), and that would appear to reduce the need for
(ie increase the complexity) a consumer pom.

Personally, I am not convinced that it is a good idea. Keep the pom, work
with what you need and ignore the bits that you don't. Only the developer
of the module will really want to read <build> section, the rest of us
consume it and just list it as a depency.

We are adding complexity (and certainly a lot of potential confusion!), and
adding complexity is rarely a good thing as it just tends to break more
things.


On Wed, Apr 18, 2018 at 3:47 AM, Jörg Schaible <joerg.schaible@gmx.de>
wrote:

> Hi Mirko,
>
> On Tue, 17 Apr 2018 04:44:57 +0000 Mirko Friedenhagen wrote:
>
> > Hello Jörg,
> >
> > I understand your problem, however this is quite specific. AFAIK
> > currently profiles are *not* evaluated while resolving imported
> > dependencies, only those inherited, so this would be a very drastic
> > change.
>
> Well, the import scope is special anyway, but I agree, that dependency
> resolution should not make a
> difference if you use this compared to a "normal" (transitive) dependency.
>
> > For your eclipse example: maybe put OS specific stuff in modules and
> > mark them as optional while importing?
>
> If SWT is not optional, your user's might be quite surprised if it had
> been declared optional. But I do not like
> this situation also.
>
> Cheers,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

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