>> 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 >>>> [email protected] >>>> https://lists.jboss.org/mailman/listinfo/seam-dev >>> >> >> /max >> http://about.me/maxandersen >> >> >> > /max http://about.me/maxandersen _______________________________________________ seam-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/seam-dev
