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
smime.p7s
Description: S/MIME cryptographic signature
