SWARM-578: Introduce FileSystemLayout abstraction

[heiko-braun]

Supports the IDE:run cases by providing abstraction to resolve gradle and maven specific file systems locations.

[heiko-braun]

@bobmcwhirter Here's the abstraction we talked about the other day. It's only used for the IDE:run cases. In the most simple case, it will implicitly use the 'user.dir' system property:

fsLayout = FileSystemLayout.create();
Path p = fsLayout.resolveBuildClassesDir();
[...]

[kenfinnigan]

Would it make sense to move the FS layout classes from /bootstrap to /container?

there's no guarantee that the bootstrap module will be loaded in anything other than an uber jar situation, as container module only has an optional dep on bootstrap module. And every fraction definitely has a dependency on the container module.

[bobmcwhirter]

Container does have a maven dep on bootstrap so it should transitive
around.

The module dep is optional only because the bootstrap module doesn't have a
real module.xml and that freaks out the fraction plugin. It's always
available.

Sent from my iPhone

On Aug 4, 2016, at 5:56 AM, Ken Finnigan notifications@github.com wrote:

Would it make sense to move the FS layout classes from /bootstrap to
/container?

there's no guarantee that the bootstrap module will be loaded in anything
other than an uber jar situation, as container module only has an optional
dep on bootstrap module. And every fraction definitely has a dependency on
the container module.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#60 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAA-T6BXivU790v5RFnhvefMCS7cGTiyks5qcbdngaJpZM4Jcbyx
.

[heiko-braun]

I can't really remember why I moved it there. But I agree, /container seems to be more sensible.

[heiko-braun]

retest this please

[gastaldi]

---

Comments from Reviewable