Hi Brett, thanks for your positive feedback! My answers interleaved....
> This is a good proof-of-concept, perhaps worth trying on some projects to > see how it goes without needing to use a new Maven version. > I've tried already with the wicket-quickstart (one of the easiest archetypes to test) and I was planning to test others; any specific project/build that you'd be interested to try out? > I was surprised that you could get that far with the existing extension > mechanism - it seems the model mergers are helping get this mostly right :) > > Me too! :) It was also the first time I was 'hacking' around Maven Core and I wasn't expecting such a result; a good chance to kudo Maven devs for providing such a simple way to inject logic within Maven. FTR, the ThycoMavenLifecycleParticipant[1] helped a lot ;-) > However, I'm sure you're already noticing some limitations: > - you can't get in before interpolation, so properties used anywhere other > than plugin configuration will not be set > Yes, this is probably the biggest issue ATM with this approach, but I thought there would be good opportunities to fix it. I don't know how Maven interpolation works, so I don't have an idea how to solve this; could you provide me any pointers on code so that I can have a look (and learn some more) ? > - the POM has to be completely valid, which risks dropping in unwanted > elements to the target (like name of tile, distribution management, etc.) if > the consumer forgets > True, I did not think of it; the problem here is that the POM file which represents the tile should not allow any lifecycle executions (on the tile itself) rather than install & deploy (and should not need any additional POM elements than artifactId,groupId,version and packaging). A "template" (or "tile") packaging would solve the issue tough, since we can introduce a custom lifecycle and inhibit all unwanted lifecycle executions > - you can't utilise dependency ordering to pick up templates from the > reactor if you want to build them in your multi-module build and then use > them again > True. I think that tiles are not the best way to include dependencies indeed, but you can simply use transitive deps to get the very same result; in my POM I can define a dep to a another POM file which just contains dependencies. I would not handle dependencies in any other way than transitive dependencies, whatever the Mixin approach would be, but that's just a personal thought. > - without POM changes, it can look a bit messier > > I don't understand this; what do you mean with "POM changes"? you're referring to SCM changes? > I also noticed you're impacting the raw model - was that necessary to work, > or just part of the experimenting? > > It's part of the experiment, but I'm not sure if it's still needed; will do some further investigation. > What are your thoughts on my other comments about a general approach, if it > can be built into the model building? > Well, looking at the first email of this thread, I see a lot of common points between your approach and mine: - templates should look like a normal POM.... Agree. ATM a tile is a POM - any POM element is valid, other than ...., <templates> Completely agree, the <templates> element looks awesome and cool; in my solution I just wanted to 'postpone' this issue and use the <properties> tag with a simple naming convention, but your <templates> solution is where I was aiming at. - templates need to be sourced from the repository using the normal mechanism.... Agree. I use Aether to resolve deps and it works like a charm. - templates should have an extension "xml" in the repository ... Agree. I think that having a different packaging for templates/tiles/mixin (whatever the name will be :-) would make it cleaner and clearer for users; however, if we *really* can make it working by just using a POM packaging, this issue is not really a priority and could be considered a nice to have, agree? - we rely on the later interpolation step to resolve variables.... Agree, and that's where Tiles fails ATM (as discussed above) - there should be no additional merge semantics.... Agree and done, ModelMerger rocks :-) - ... the sequence of project building... Agree, but I need to know more about Maven internals to have a better opinion on that. Sorry for the long email! -- Maurizio Pillitu http://maurizio.pillitu.name [email protected] [1] - http://www.jarvana.com/jarvana/view/org/sonatype/tycho/tycho-osgi-components/0.7.0/tycho-osgi-components-0.7.0-sources.jar!/org/codehaus/tycho/maven/TychoMavenLifecycleParticipant.java
