If you make the strategy a component provided by sisu, then a build extension could provide an alternative implementation for the project that the extension is defined in.
I presume the strategy is something you only want to apply to a project's handling of its dependencies. If another project consumes your project and wants to use a different strategy, that is the other project's business. With extensions being inherited from parent poms you can thus propagate to all your projects via your corp parent On Friday, 23 August 2013, Phillip Hellewell wrote: > Wow, I had no idea about this whole issue with being unable to move forward > with the POM. This is a really tough problem. I just didn't even think > about that because I'm used to working with XML parsers that don't even do > schema validation. > > So I guess I'm pretty much stuck, because I can't put mediation settings in > settings.xml or else I lose predictability, and I can't put them in the pom > without a schema change (unless someone can tell me where to "sneak" them > into the existing schema; j/k). > > Sadly, even if I wanted to just do it in-house and not try and contribute > back, and even though I can get all our devs to install our custom build of > mvn that recognizes the new schema, I'd still be hosed because we use > external tools like Nexus and Jenkins that may parse the pom and barf on > invalid XML. We can't possibly build and maintain patches against all > these external tools :( > > Phillip > -- Sent from my phone
