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 <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > >
