recursing directories on deployment

[bill.burke]

I'm having a problem where I deploy a directory to the kernel and a .jar in a nested directory isn't getting deployed:

foo/lib/deployme.jar


I'm created a deployment context with "foo" as the root. The structure code successfully processes the foo/ directory. Mainly because the JARStructure deployer has determined that "foo/" is a top level directory, and so, it must process the children.

Now, when lib/ is processed, the JARStructure deployer determines it is neither a "archive" nor a top level directory, so it does not process lib's children.

Why do we do this? I can think of one reason. Maybe we don't want to process every single entry of every Jar file?

If that doesn't really matter we could move directory processing out of JARStructure and into FileStructure.

[starksm64]

The JARStructure either recoginizes a jar or it does not. It should not go searching subdirectories for that. If you want that either uses an explicit structure declaration, or add an option to the FileStructure to traverse into directories similar to what we have in the URLDeploymentScanner.RecursiveSearch behavior.

[adrian.brock]

Now, when lib/ is processed, the JARStructure deployer determines it is neither a "archive" nor a top level directory, so it does not process lib's children.

How could it know that lib/ is a subdeployment whereas com/ or org/
that just contain classes are not?

You need to provide extra information if you want a subdirectory deployed
and that subdirectory doesn't have a recognisable suffix.

I guess we could make an exception for the special case "lib'
and then hope nobody has a class called
lib.blah.Some.class :-)

[adrian.brock]

NOTE: The other way to do it is to add an empty META-INF subdirectory to the lib/
folder. The JARStructureDeployer should then recognise it as a jar.