Hey Adolfo!
This is great. I think that in order to resolve this, you'll probably need
to implement your own directory handling in your ZipResource, similar to
JavaResource and others using the Resource API to return virtual entries
that represent intermediate folders.
so listResources() would return org/, then org/jboss/, then
org/jboss/forge/ as you recursively travel down the structure.
I'm not sure exactly if ZipEntry really supports this kind of directory
navigation, so you might need to implement it yourself.
~Lincoln
On Sun, Nov 18, 2012 at 2:19 PM, Adolfo Jr. <adolfojunior(a)gmail.com> wrote:
Hi everyone,
I am a new Forge entusiast, it's a great project!
So decided to learn and help, i started to do some code.
I developed a plugin based in issue
https://issues.jboss.org/browse/FORGE-559
The implementation suggest a full list of entries in a zip archive.
[plugin-lszip] plugin-lszip.jar $ ls
META-INF/
META-INF/beans.xml
README.TXT
org/
org/jboss/
org/jboss/forge/
org/jboss/forge/dev/
org/jboss/forge/dev/zip/
org/jboss/forge/dev/zip/LsZipPlugin.class
org/jboss/forge/resources/
org/jboss/forge/resources/ZipEntryResource$ZipEntryInputStream.class
org/jboss/forge/resources/ZipEntryResource.class
org/jboss/forge/resources/ZipResource.class
Then i sent a pull to github:
https://github.com/forge/core/pull/239
The code works fine for list command.
But in some other tests with "cat" command to read a ZipEntry content, and
"cd" command to change the current resource, the commands didn't work!
I realised that the name of entries contains slash and the PathspecParser
class split the name and navigate recursively.
I think that implementation like a DirectoryResource hierarquicali could
work fine. But will lose the full list of entries.
Some suggestion to resolve the behavior?
Thank you,
Adolfo Jr.
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."