> 1) finding which jar's to scan (haven't checked this but
using the service declaration in META-INF might be enough)
I think it should
> 2) when scanning the jar knowing which classes in the jar's that looks like
compliant CDI beans really aren't beans.
I think this is simple. If it has beans.xml, as normal. If it doesn't look for Solder
annotations and register those beans...
that sounds like a plan.
and just to be sure - you mean beans.xml as normal + scan solder annotations and if no
beans.ml and just service declaration in manifest.mf only scan solder annotations ?
and this will also mean that if an archive actually contains "normal" CDI beans
they would not be picked up. Correct?
>> 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 ;)
I think we need to revisit why the annotations aren't descriptive enough...
Last time it was that the beans simply didn't have annotations or any metadata when
registered programmatically.
/max
>
> /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
>
>
>
/max
http://about.me/maxandersen