SHRINKWRAP-97: Verbose toString format

[alrubinger]

Jesper's proposed we provide for:

log.info(Archives.create("alr", JavaArchive.class).addClass(this.getClass()).toString(true));

from:

/org/jboss/shrinkwrap/impl/base/unit/MemoryMapArchiveTestCase.class

...to:

/org
/org/jboss
/org/jboss/shrinkwrap
/org/jboss/shrinkwrap/impl
/org/jboss/shrinkwrap/impl/base
/org/jboss/shrinkwrap/impl/base/unit
/org/jboss/shrinkwrap/impl/base/unit/MemoryMapArchiveTestCase.class

My question is: why spit out the empty directories? What use is that information?

S,
ALR

[alrubinger]

Or perhaps this is another one for user choice:

archive.toString(Verbosity.ALL); // Jesper's proposal; parent dirs listed
archive.toString(Verbosity.CONTENTS); // Current impl
archive.toString(Verbosity.MINIMAL); // Same as archive.toString()
archive.toString(true); // We deprecate this, defaulting to Verbosity.CONTENTS

S,
ALR

[aslak]

Having all these different versions of toString seems a bit odd to me.

Is there a usecase for the string representation outside of 'debug/log' ?

Maybe we should move it to a Visitor of the Content instead?

public interface Printer
{
 void write(Asset, Path, PrintStream)
}

archive.print(Printers.minimal(), System.out)
archive.print(Printers.content())

And the toString could be a simple

archive.toString() {
 return name + content.toString()
}

[alrubinger]

"aslak" wrote:
Having all these different versions of toString seems a bit odd to me.

My example still has one overloaded toString; only instead of accepting a boolean is takes in an enum.

I think the Visitor approach just moves the problem and makes it more complex.

But I'd still like to understand the requirements/desire behind the request. Why the empty dirs? :)

S,
ALR

[jaikiran]

"ALRubinger" wrote:

But I'd still like to understand the requirements/desire behind the request. Why the empty dirs? :)

S,
ALR

Just to be sure - we aren't talking about "empty" dirs, are we? From the example posted earlier in this thread, we are talking about "parent" dirs. Although i don't see an advantage as such, i do think it would be good to print the parents too (as Jesper suggests) since it would then match the output of the standard:

jar -tf somejar.jar

[alrubinger]

"jaikiran" wrote:
Just to be sure - we aren't talking about "empty" dirs, are we?

Right; they're not "empty", just parents of directories which contain resources. Actually ShrinkWrap doesn't even support empty directories ATM. So:

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

"jaikiran" wrote:
i do think it would be good to print the parents too (as Jesper suggests) since it would then match the output of the standard (jar utility)

Thanks for the input. The more I think on this the more I think we need user options. I personally find the extra parent dirs a bit unnecessary/noisy in most cases.

S,
ALR

[jesper.pedersen]

The enum would work, as it gives the developer greater control.

[aslak]

A Enum gives the ShrinkWrap developer control, but the user is stuck with the preset options.

public interface Formater {
 String format(Map<Path, Asset> content);
}

Archie.toString(Formater formater)

archie.toString(Formaters.full())
archie.toString(new MyFormater())

archie.toString()
{
 return toStirng(Formaters.simple())
}

If the user could choose between some 'predefined' impls or could specify his own, that would give him control.

[alrubinger]

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

I like Aslak's extension formatters example, so I've added them.

archive.toString();   // Same as toString(false) and toString(Formatters.SIMPLE)
archive.toString(false);
archive.toString(true); // Same as toString(Formatters.VERBOSE)
archive.toString(Formatters.SIMPLE);
archive.toString(Formatters.VERBOSE);
archive.toString(new Formatter()
{
   @Override
   public String format(final Archive<?> archive) throws IllegalArgumentException
   {
      return "my custom thing here";
   }
});

We haven't yet done SHRINKWRAP-97, to show all dirs.  That can easily become a new Formatter implementation; do we like "Formatters.FULL" ?

S,

ALR

[jesper.pedersen]

Formatters.FULL or Formatters.ALL - up to you

[alrubinger]

jesper.pedersen wrote:

Formatters.FULL or Formatters.ALL - up to you

I'm leaving this one as an open issue for the time being for community contributors; it's a good entry point.

S,

ALR