Hi Milos,

Sorry for the delay again, I've been away from code for a while.

On 6 March 2010 13:27, Milos Kleint <mkle...@gmail.com> wrote:
> I see. I think the regular compilation classpath shall be the default
>  though. The question is how to encode this special processor path? is there
> a way to encode <dependency> elements inside the <configuration>? or shall
> we just have a simple boolean parameter that would take plugin's
> classpath/dependencies instead of the project compilation cp and encode the
> processor path as <dependency> of the plugin?

I agree that the compile classpath should be the default, as it is
with javac.  Unless there's any other use case for specifying plugin
dependencies to the compiler plugin, I'd just use them as the
processor path if specified, avoiding the need to encode them.

> what is the purpose of the staleness checking? to avoid regenerating
> resources all over again? The various rules assume you always know what the
> given annotation generates, which might not be applicable to everyone (and
> requires additional mandatory configuration?) If we add it can it be "off"
> be default? So that only those caring enough get to configure it?

Yeah, the staleness checking is merely an optimisation.  Like you say,
It isn't straightforward as you need to know how the processors
generate files.  It can certainly be off by default, and it's more a
nice-to-have than absolutely necessary.  I'm sure builds will be
quicker now if we're only invoking javac once, rather than javac and
then apt.

>> Obviously this is complicated if we're also compiling too.
>
> Yes, you would have to somehow recognize this upfront and pass -proc:none to
> avoid processing? but how do you figure?
>
> the current netbeans annotations do generate resources (layer.xml files and
> META-INF/services content) and also java/class files.  If you generate class
> files, you cannot probably do just annotation processing (in
> process-resources) without compiling  as well.  Or we would have to add the
> generated sources root to the project?
> OTOH when resources get generated in compile phase, it probably only matters
> if you want to do filtering of these resources? but that assumes your
> annotations do generated filterable content. Hmm. I suppose this setup can
> be configured in the pom, additional execution with -proc:only and the
> default compile execution with -proc:none
>
> So I would go with doing annotation processing along with compiling, it's
> going to be faster and is actually the default javac behaviour as well. The
> other scenarios seem to be configurable then as well using the current
> parameters, right?

Sounds good to me.  I just wanted to highlight the fact that this
circumnavigates Maven's traditional lifecycle phases.

Thanks for doing the work on this, I'll look forward to using it soon!

Cheers,

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to