This blog post may be helpful to you: http://blog.sonatype.com/2009/08/create-a-customized-build-process-in-maven/
If I was in your shoes, I would at least consider this approach. Wayne On Wed, Apr 1, 2015 at 4:50 PM, Steve Cohen <[email protected]> wrote: > JK- > > After half a day messing around, I am now convinced that you are right. > Writing a new plugin is harder than it looked at first, even though I was > able to grok what the plugin was doing fairly well. But there's a lot of > stuff going on under the covers that isn't well documented. > > for just one example ${project.compileSourceRoots} > > Plus - even if that was all okay, how would you turn maven-compiler-plugin > off? I notice it appears in my effective POM in Eclipse without even > specifying to use it in the POM. > > So a hack on a lesser scale it must be! Preprocessing it into a form > maven is comfortable with would work better. In fact, the current nmake > system uses its own form of preprocessing. > > Steve > > > On 04/01/2015 12:14 PM, Jim Klo wrote: > >> Don’t let me discourage you on that choice if you choose it - however it >> sounds like this might be a stopgap in a transition to a more modern >> solution? >> >> From my POV, which is a defensive approach towards configuration >> management - if this is just a transitionary step to removing nmake, I >> would not bother investing that time, unless: >> 1) you are going to make a conscious decision on embracing and >> maintaining your modified fork for a long time because this is going to be >> a critical part of your solution. >> or >> 2) you were going to contribute that enhancement back to the plugin >> projects and get it adopted - which I don’t know what the process is for >> that with the maven project (I’ve done it with other apache projects - and >> it’s not exactly an easy process) >> >> Otherwise it would just add one more piece of forked code to your bucket >> list maintain. We all know none of us has time, or desire usually, to >> manage yet another forked project. :) >> >> I’m sure others have their own opinion on this, but as a "maven user” and >> not a "maven developer” - I personally don’t like enhancing other tools >> unless there’s an easy way for me to contribute that fix back and get it >> into the main build. >> >> Just my 2 cents advice. >> >> - JK >> >> >> On Apr 1, 2015, at 9:48 AM, Steve Cohen <[email protected]> wrote: >>> >>> That sounds like it might be a possibility. But after looking at it, my >>> initial take (which is quite possibly wrong!!) is that it might be easier >>> to extend the compiler plugin, and the jar plugin, to use the vpath. >>> Basically, you're just writing a new SourceInclusionScanner. This seems >>> like it would have the benefit of staying within known Maven channels. >>> >>> On 04/01/2015 10:23 AM, Jim Klo wrote: >>> >>>> Is there a reason you cannot just use the exec plugin? We use that to >>>> manage all sorts of esoteric make-like systems the have similar problems as >>>> you list. >>>> >>>> Jim Klo >>>> Senior Software Engineer >>>> SRI International >>>> t: @nsomnac >>>> >>> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
