I thought the plan was for JBDS to natively understand Solder
annotations to overcome this problem.
That does not solve the problems.
We got two of them:
1) finding which jar's to scan (haven't checked this but using the service
declaration in META-INF might be enough)
2) when scanning the jar knowing which classes in the jar's that looks like compliant
CDI beans really aren't beans.
I really don't think that forcing some xml file on extension
developers is very clever - either they would have to use this as the canonical source of
info in which case we're back to programming in XML and it doesn't look good when
people ask for examples of using CDI extensions, or we have to keep this stuff in sync.
Since the annotations aren't descriptive enough we'll need to come up with
something ;)
/max
On 24 Mar 2011, at 20:56, Max Rydahl Andersen wrote:
> Hi,
>
> Talking with Seam/CDI tooling team at EclipseCon and we are still in the dark on how
tooling are supposed to identify CDI extensions that are registered programmatically and
often does not have a beans.xml to "mark" them.
>
> Today we do it by simply scanning jars with *weld*.jar naming pattern (very brittle
and not good for 3rd party extensions).
>
> Furthermore we also have a list of classes to include/exclude since some components
in these jars aren't CDI compliant.
>
> How do we go about identifying these things ?
>
> The idea discussed with Dan/Pete on this topic previously were to add a
design-beans.xml
> and use that as a marker + list the classes we should load/configure as possible
injection/navigation candidates in the tooling.
>
> I was hoping this were settled before Seam 3 GA but it seem to fallen through the
cracks ?
>
> Something I missed ?
>
> /max
>
http://about.me/maxandersen
>
>
>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/seam-dev
/max
http://about.me/maxandersen