jboss-scanning.xml

[alesj]

Moving this
- http://lists.jboss.org/pipermail/jboss-development/2008-November/012965.html
discussion here.

How would this file look like?
e.g.

<scanning>
 <include path="org/jboss/acme/ejbs" filter="ant:*.*Bean"/>
 <include path="org/jboss/domain/hibernate" filter="regexp:<some-reg-exp>"/>
 <exclude path="org/jboss/logic"/>
 <exclude module="rules-impl.jar" />
</scanning>

Or what info should we expect from ScanningMetaData?

ejb-jar.xml and web.xml are mentioned in ml discussion.
How would we transform them into ScanningMetaData?

[adrian.brock]

"alesj" wrote:
Moving this
- http://lists.jboss.org/pipermail/jboss-development/2008-November/012965.html
discussion here.

How would this file look like?
e.g.

<scanning>
 <include path="org/jboss/acme/ejbs" filter="ant:*.*Bean"/>
 <include path="org/jboss/domain/hibernate" filter="regexp:<some-reg-exp>"/>
 <exclude path="org/jboss/logic"/>
 <exclude module="rules-impl.jar" />
</scanning>

That's a horrible syntax. If you really need to go beyond file/ant globbing
for a file filter couldn't you have a seperate attribute to specify a different
fitlerType="regexp"?

Or what info should we expect from ScanningMetaData?

Classes - with a short syntax for ease of use in some cases,
e.g. including specific paths

<scanning xmlns="urn:jboss:scanning:1.0">
 <path name="myejbs.jar">
<!-- long form -->
 <classes>
 <include name="com.acme.foo.**"/>
 <exclude name="com.acme.foo.bar.*"/>
 </classes>
 </path>
<!-- short form -->
 <path name="my.war/WEB-INF/classes" include="com.acme.foo.**"/>
</scanning>

How much of this you actually implement in the first version is upto you.
The minimum would be a list of explicit paths to include (exclusion being the default).

Also, the paths need to be able to handle "external jars",
e.g. those referenced from the manifest

ejb-jar.xml and web.xml are mentioned in ml discussion.
How would we transform them into ScanningMetaData?

metadata-complete (or pre javaee5 dds) means nothing is scanned

<scanning xmlns="urn:jboss:scanning:1.0"/> <!-- nothing -->

otherwise all the jars and all the classes are scanned

<scanning xmlns="urn:jboss:scanning:1.0">
 <include name="**"/>
</scanning>

[adrian.brock]

That's a horrible syntax. If you really need to go beyond file/ant globbing
for a file filter couldn't you have a seperate attribute to specify a different
fitlerType="regexp"?

It's a horrible syntax, because can you imagine explaining to an admin
using a GUI consol e what "ant:*.*" means?

You'd need a whole seperate wizard just to guide them through constructing a filter
using point and click. ;-)

[alesj]

I've committed simple
- ScanningDeploymentUnitFilter
- ScanningMetaDataRecurseFilter
- ScanningMetaDataResourceFilter

I also fixed a small glitch in my GenericAnnotationResourceVisitor,
removing lookup for super and interfaces unless explicitly asked,
otherwise this can go past scanning metadata filter.

Also, the paths need to be able to handle "external jars",
e.g. those referenced from the manifest

I have a simple test where jar's manifest references ear's/lib jars.
But this ear/lib jars are then scanned as part of top deployment (remember our urls issue in AnnEnvDeployer?).

Can you think of any other test case that would check your 'external jars'?