Hi Jörg, thanks for writing this; I think it solves in a nice way the "consumer" pom issue.
Some initial remarks : - instead of consumerPomFile, I would use the generic outputDirectory to specify the directory itself, and consumerPomName to actually define the file name in this directory. I believe this is more in line with what existing plugins (jar, war...) use in terms of naming conventions - I'm not sure why the behaviour of updatePomFile would be different for packaging 'pom' and other packagings; in my opinion if it deserves a use case, there should be a separate parameter to control whether packaging pom triggers updatePomFile or not - I guess more control on what gets in the resulting pom could be interesting (like removing the build section or specific dependencies) Unfortunately I have no clue concerning your question on JDK/OS activated profiles Cheers, Vincent 2014-02-25 23:47 GMT+01:00 Jörg Hohwiller <jo...@j-hohwiller.de>: > Hi there, > > I just added consumer-maven-plugin to MOJO sandbox: > https://svn.codehaus.org/mojo/trunk/sandbox/consumer-maven-plugin > > To get directly to the MOJO code use this link: > > https://svn.codehaus.org/mojo/trunk/sandbox/consumer-maven-plugin/src/main/java/org/codehaus/mojo/consumer/ConsumerMojo.java > > It is only an inital draft. I have to implement the logic to remove the > dependencies that have already been activated via JDK or OS triggered > profiles. Any hints how to do that easily without re-implementing the maven > dependency resolution would be appreciated. > > I am looking forward to getting feedback. Read the JavaDoc (typecomment) > and let me know with what you agree and where you disagree. > > Best regards > Jörg > > >
