SHRINKWRAP-104: Empty Directories

[alrubinger]

https://jira.jboss.org/jira/browse/SHRINKWRAP-104

I've added support for empty directories (and tests) in r3836. This is nice, because importers can now account for empty dirs as well.

The design I've used is a new Asset implementation:

public enum DirectoryAsset implements Asset {

 /**
 * Singleton Instance
 */
 INSTANCE;

 /**
 * {@inheritDoc}
 * @see org.jboss.shrinkwrap.api.Asset#openStream()
 */
 @Override
 public InputStream openStream()
 {
 // To signify that we've got nothing to back us (we're just a directory),
 // we use null. A stream backed by an empty byte array would be an
 // empty file, which is different.
 return null;
 }

}

This sucks because:

1) We don't really obey the contract of "Asset", returning a null reference on "openStream"
2) The implementation relies upon "instanceof" runtime type checking to do things like creating directories in the exporter. Meaning we're checking for a specific implementation.

An alternate approach is to add:

Asset.isDirectory()

...to all Asset types. In this case "DirectoryAsset.openStream" would still return null, but we could do "Asset.isDirectory" instead of the runtime type checking.

Which is uglier to you?

S,
ALR

[aslak]

What if we drop the Asset all together and make a add method like:

archive.add(Path)

Maybe we then also have to support all the convenience overloads like ?

addManifestResource(Path)
addWebResource(Path)
etc..

Path should then probably have a isDirectory method, checking if it ends with '/' seems to be common. Could add checks to other add methods so you can't add a Asset to a directory Path, can't get the Asset of a directory path etc..

[jesper.pedersen]

I say follow the java.io.File API and add

isFile()
isDirectory()

I'll let you worry about the implementation details ;)

[alrubinger]

"aslak" wrote:
What if we drop the Asset all together and make a add method like:

archive.add(Path)

@see DirectoryContainer, which has:

container.addDirectory(Path);
container.addDirectories(Path...);
container.addDirectory(String);
container.addDirectories(String...);

All spec archives types bring in DirectoryContainer support.

"aslak" wrote:
Path should then probably have a isDirectory method, checking if it ends with '/' seems to be common. Could add checks to other add methods so you can't add a Asset to a directory Path, can't get the Asset of a directory path etc...

Paths, as defined, don't know anything about what's under them in the context of an archive. So in my view a directory is more of an Asset; it's what's some Path in an archive.

S,
ALR

[alrubinger]

jesper.pedersen wrote:

I say follow the java.io.File API and add

isFile()
isDirectory()

I'll let you worry about the implementation details ;)

The motivation behind ArchivePath was that it specifically did *not* follow this pattern, which IMO couples things.

On some further review, we can just say in the JavaDoc of Asset that "returning null on getInputStream() denotes a logical Path only with no content".  Then we follow the API.