You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beehive.apache.org by Carlin Rogers <ca...@gmail.com> on 2007/12/11 02:11:01 UTC

Add an option to the Beehive AptTask to allow a user to define an AP factory or factory path

I opened an improvement request in JIRA for the Beehive AptTask
(BEEHIVE-1210). I'd like to extend the AptTask to allow a user to
define apt specific options for the name of an annotation processor
(AP) factory to use or the factory path for finding the AP factories.
This allows apt to bypass the default discovery process or specify
where to find AP factories.

Here's more information that I included in JIRA...

This can help resolve build issues users may experience when multiple
annotation processors conflict. For example,...

A project may contain Beehive annotations as well as JAX-RPC 1.1 Web
Services annotations.
However, starting with JDK1.6, JDK bundles the JAX-WS 2.0 AP in its
tool jar. JAX-RPC and JAX-WS use the same JSR 181 annotations but the
JAX-WS 2.0 AP doesn't support the earlier JAX-RPC use of the
RPC/ENCODED soapbinding annotation on an endpoint. A user running the
build through the Beehive AptTask and using Java 6, would see APT fail
on JAX-RPC 1.1 services thinking they are invalid JAX-WS services.

This improvement would allow a user to define the AP factory to use.

Note that for the above scenario, unfortunately, using the
-factorypath option would not disable the built-in annotation
processor because tools.jar is always in APT's class path. In this
case, exposing the option to use a specific factory solves the
problem. There can only be one factory name when invoking APT, so a
user of this task and the factory name option may need to pass a
wrapper factory that is an aggregated annotation processor factory.

Any additional thoughts?

Thanks,
Carlin

Re: Add an option to the Beehive AptTask to allow a user to define an AP factory or factory path

Posted by Jacob Danner <ja...@gmail.com>.
Sounds great Carlin.
Let me know if I can help at all.
-jacobd

On 12/10/07, Carlin Rogers <ca...@gmail.com> wrote:
> I opened an improvement request in JIRA for the Beehive AptTask
> (BEEHIVE-1210). I'd like to extend the AptTask to allow a user to
> define apt specific options for the name of an annotation processor
> (AP) factory to use or the factory path for finding the AP factories.
> This allows apt to bypass the default discovery process or specify
> where to find AP factories.
>
> Here's more information that I included in JIRA...
>
> This can help resolve build issues users may experience when multiple
> annotation processors conflict. For example,...
>
> A project may contain Beehive annotations as well as JAX-RPC 1.1 Web
> Services annotations.
> However, starting with JDK1.6, JDK bundles the JAX-WS 2.0 AP in its
> tool jar. JAX-RPC and JAX-WS use the same JSR 181 annotations but the
> JAX-WS 2.0 AP doesn't support the earlier JAX-RPC use of the
> RPC/ENCODED soapbinding annotation on an endpoint. A user running the
> build through the Beehive AptTask and using Java 6, would see APT fail
> on JAX-RPC 1.1 services thinking they are invalid JAX-WS services.
>
> This improvement would allow a user to define the AP factory to use.
>
> Note that for the above scenario, unfortunately, using the
> -factorypath option would not disable the built-in annotation
> processor because tools.jar is always in APT's class path. In this
> case, exposing the option to use a specific factory solves the
> problem. There can only be one factory name when invoking APT, so a
> user of this task and the factory name option may need to pass a
> wrapper factory that is an aggregated annotation processor factory.
>
> Any additional thoughts?
>
> Thanks,
> Carlin
>