Hello Chris, I do think that a consumer pom might be a good thing. It will provide backwards compatibility for current Maven, Gradle, sbt, kobalt etc. users and allow to improve the model for those using future Maven versions for building stuff.
Best regards Mirko -- Sent from my mobile Chris Graham <chrisgw...@gmail.com> schrieb am Do., 19. Apr. 2018, 12:39: > 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.schai...@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-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
