Under the intended use-case, the consumers of the artefacts published using this lifecycle extension will also be using the same lifecycle extension, and importing/resolving those properties based on business rules/conditions beyond the scope of this specific problem.
Unfortunately, the flatten plugin doesn't appear to work with the tiles-maven-plugin all that well, tho if it comes to it, I could take a nod to it and as part of my lifecycle extension ( plus goals in the same plugin, which run on release prepare ) inline the property values in the POM that gets *published* without changing the source version. That may have to be a compromise I make. NOT forcing consumers to also partake in this wacky scheme I have may itself has it's own advantages, whilst not breaking the original intent. Will ponder and sleep on it ( just gone midnight now, need sleep ). -- "Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree On Wed, Jun 8, 2016 at 11:45 PM, Andreas Sewe < [email protected]> wrote: > Hi Mark, > > > Is there anyway in current maven (3.3.9) that I can replace the > > |DefaultDependencyCollector| with one of my own, that can use > > maven-filtering and demangle the versions as appropriate? Can I register > > a replacement in my |META-INF/plexus/components.xml| file for my > > lifecycle extension at all? > > even if there is (I've no clue), what about all the consumers of your > artifacts? They will fetch you POMs from a Maven repository and have no > idea where to get the dependencies from, as *they* use the > DefaultDependencyCollector. But maybe the flatten-maven-plugin can help > in such cases, so that you use you "magic" properties only during the > build but the published POMs have all properties replaced. > > Best wishes, > > Andreas > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
