Packaging restx archives

[fcamblor]

This is a follow up for #62
I provided a new app archive command, allowing to generate a restx archive.

Some insight about the restx archive : the hello-world application generated from a restx app new will generate something like this :

$> tree
.
├── META-INF
│   ├── restx
│   │   └── app
│   │       ├── data
│   │       │   ├── credentials.json
│   │       │   └── users.json
│   │       ├── md.restx.json
│   │       ├── module.ivy
│   │       ├── pom.xml
│   │       └── src
│   │           ├── main
│   │           │   ├── java
│   │           │   │   └── helloworld
│   │           │   │       ├── AppModule.java
│   │           │   │       ├── AppServer.java
│   │           │   │       ├── Roles.java
│   │           │   │       ├── domain
│   │           │   │       │   └── Message.java
│   │           │   │       └── rest
│   │           │   │           └── HelloResource.java
│   │           │   ├── resources
│   │           │   │   └── logback.xml
│   │           │   └── webapp
│   │           │       └── WEB-INF
│   │           │           └── web.xml
│   │           └── test
│   │               ├── java
│   │               │   └── helloworld
│   │               │       └── rest
│   │               │           └── HelloResourceSpecTest.java
│   │               └── resources
│   │                   └── specs
│   │                       └── hello
│   │                           ├── should_admin_say_hello.spec.yaml
│   │                           ├── should_user1_say_hello.spec.yaml
│   │                           └── should_user2_not_say_hello.spec.yaml
│   └── services
│       └── restx.factory.FactoryMachine
├── helloworld
│   ├── AppModule.class
│   ├── AppModuleFactoryMachine$1.class
│   ├── AppModuleFactoryMachine$2.class
│   ├── AppModuleFactoryMachine$3.class
│   ├── AppModuleFactoryMachine$4.class
│   ├── AppModuleFactoryMachine$5.class
│   ├── AppModuleFactoryMachine.class
│   ├── AppServer.class
│   ├── Roles.class
│   ├── domain
│   │   └── Message.class
│   └── rest
│       ├── HelloResource.class
│       ├── HelloResourceFactoryMachine$1.class
│       ├── HelloResourceFactoryMachine.class
│       ├── HelloResourceRouter$1.class
│       ├── HelloResourceRouter.class
│       ├── HelloResourceRouterFactoryMachine$1.class
│       └── HelloResourceRouterFactoryMachine.class
└── logback.xml

ATM, I'm packaging sources files into the restx archive (because api doc might rely on it to display source contents)
For the same reason, I package the src/test/* file hierarchy.

You can test it easily :

restx app new
................
restx app archive /tmp/hello.jar
................
restx app grab file:///tmp/hello.jar + app run

FYI, I just created a maven-restx-plugin which will re-use the RestxArchive.pack() utility method, in order to package a standard restx archive (with -restx classifier).

Important note : having the *.class files in the archive is totally useless since the first thing I do in app grab is to unzip & chroot to META-INF/restx/app/ directory (then, auto compile does the stuff for us).

[fcamblor]

It would be a good thing to extract RestxArchive into a dedicated module (since the restx-maven-plugin relies on it, and some other tools like ant or gradle might want to rely on it in order to provide a smooth integration for generating restx archives)

But I don't know where to put it.

I don't think putting it inside restx-common would be a good idea since it would be really uncommon to have to manipulate RestxArchive when developping with restx.
OTOH, creating a dedicated module for only 1 class seems weird :P

[fcamblor]

It would be a good thing to extract RestxArchive into a dedicated module (since the restx-maven-plugin relies on it, and some other tools like ant or gradle might want to rely on it in order to provide a smooth integration for generating restx archives)

But I don't know where to put it.

I don't think putting it inside restx-common would be a good idea since it would be really uncommon to have to manipulate RestxArchive when developping with restx.
OTOH, creating a dedicated module for only 1 class seems weird :P

[fcamblor]

I would need some help on this : is it easily feasible ? (namely ivy.xml / pom.xml => md.restx.json file)

[fcamblor]

I would need some help on this : is it easily feasible ? (namely ivy.xml / pom.xml => md.restx.json file)

[xhanin]

Yes, it's feasible but very limited. You can have a look at these tests:
https://github.com/restx/restx/blob/325ea5fdb95e5d380b4cf0b252268e1dc92074d3/restx-build/src/test/java/restx/build/RestxBuildTest.java

[fcamblor]

Implemented it on 6da7c1a & 4b26b5b

[xhanin]

Good job! I've reviewed the commits, everything seems fine to me.

About what is packaged inside the app, maybe making that configurable would be nice. Maybe something very simple like making the list Arrays.asList("target", "tmp", "logs") configurable through a system property or an injected Named String.

[xhanin]

Good job! I've reviewed the commits, everything seems fine to me.

About what is packaged inside the app, maybe making that configurable would be nice. Maybe something very simple like making the list Arrays.asList("target", "tmp", "logs") configurable through a system property or an injected Named String.

[fcamblor]

I'm ok with an optional command parameter such as restx app archive /tmp/foo.jar -excludes "target,tmp,logs"

About injected named string, I suppose you're talking about an entry in the AppSettings class ? Named, for instance, restx.archive.excludes ?
How will the overloading of these properties be made at application level ?
By providing a Name(ConfigSupplier.class, "coreAppConfigSupplier") with overriden restx.archive.exclude property in the application's AppModule ? (because re-defining an appConfig.properties at application level is dangerous, especially on restx version upgrades)
Is there an easier way ?

[fcamblor]

I'm ok with an optional command parameter such as restx app archive /tmp/foo.jar -excludes "target,tmp,logs"

About injected named string, I suppose you're talking about an entry in the AppSettings class ? Named, for instance, restx.archive.excludes ?
How will the overloading of these properties be made at application level ?
By providing a Name(ConfigSupplier.class, "coreAppConfigSupplier") with overriden restx.archive.exclude property in the application's AppModule ? (because re-defining an appConfig.properties at application level is dangerous, especially on restx version upgrades)
Is there an easier way ?

[xhanin]

Yes, something in the AppSettings. Then to override it you only need to
provide a @nAmed String (either through settings, system property or
@provides) with better priority (i.e. lower priority number), you don't
need to override the whole config supplier.

On Fri, Mar 21, 2014 at 10:31 AM, Frédéric Camblor <notifications@github.com

wrote:

I'm ok with an optional command parameter such as restx app archive
/tmp/foo.jar -excludes "target,tmp,logs"

About injected named string, I suppose you're talking about an entry in
the AppSettings class ? Named, for instance, restx.archive.excludes ?
How will the overloading of these properties be made at application level ?
By providing a Name(ConfigSupplier.class, "coreAppConfigSupplier") with
overriden restx.archive.exclude property in the application's AppModule ?
(because re-defining an appConfig.properties at application level is
dangerous, especially on restx version upgrades)
Is there an easier way ?

Reply to this email directly or view it on GitHubhttps://github.com/restx/restx/pull/72#issuecomment-38260081
.

Xavier Hanin
Lead architect at 4SH France - http://www.4sh.fr/
RESTX creator and lead developer - http://restx.io/
BordeauxJUG creator - http://www.bordeauxjug.org/
Apache Ivy Creator - http://ant.apache.org/ivy/

[xhanin]

Yes, something in the AppSettings. Then to override it you only need to
provide a @nAmed String (either through settings, system property or
@provides) with better priority (i.e. lower priority number), you don't
need to override the whole config supplier.

On Fri, Mar 21, 2014 at 10:31 AM, Frédéric Camblor <notifications@github.com

wrote:

I'm ok with an optional command parameter such as restx app archive
/tmp/foo.jar -excludes "target,tmp,logs"

About injected named string, I suppose you're talking about an entry in
the AppSettings class ? Named, for instance, restx.archive.excludes ?
How will the overloading of these properties be made at application level ?
By providing a Name(ConfigSupplier.class, "coreAppConfigSupplier") with
overriden restx.archive.exclude property in the application's AppModule ?
(because re-defining an appConfig.properties at application level is
dangerous, especially on restx version upgrades)
Is there an easier way ?

Reply to this email directly or view it on GitHubhttps://github.com/restx/restx/pull/72#issuecomment-38260081
.

Xavier Hanin
Lead architect at 4SH France - http://www.4sh.fr/
RESTX creator and lead developer - http://restx.io/
BordeauxJUG creator - http://www.bordeauxjug.org/
Apache Ivy Creator - http://ant.apache.org/ivy/

[fcamblor]

Back on the topic.

Ok then if I add an entry in the AppSettings, how would I get "current application's AppSettings instance" from the restx-shell classloader ?

Would there be a shell mechanism allowing to provide current visited app classes in a dedicated classloader, thus allowing to create a Factory from current visited application classes (where will reside the AppSettings) ?

[fcamblor]

Back on the topic.

Ok then if I add an entry in the AppSettings, how would I get "current application's AppSettings instance" from the restx-shell classloader ?

Would there be a shell mechanism allowing to provide current visited app classes in a dedicated classloader, thus allowing to create a Factory from current visited application classes (where will reside the AppSettings) ?

[xhanin]

That sounds like too much complexity for such little value. A better place
may be a property in md.restx.json, or simply don't support it except
through command parameters after all, we don't even know if someone will
actually have to change these excludes :).

On Sat, Mar 29, 2014 at 4:00 PM, Frédéric Camblor
notifications@github.comwrote:

Back on the topic.

Ok then if I add an entry in the AppSettings, how would I get "current
application's AppSettings instance" from the restx-shell classloader ?

Would there be a shell mechanism allowing to provide current visited app
classes in a dedicated classloader, thus allowing to create a Factoryfrom current visited application classes (where will reside the
AppSettings) ?

Reply to this email directly or view it on GitHubhttps://github.com/restx/restx/pull/72#issuecomment-38997965
.

Xavier Hanin
Lead architect at 4SH France - http://www.4sh.fr/
RESTX creator and lead developer - http://restx.io/
BordeauxJUG creator - http://www.bordeauxjug.org/
Apache Ivy Creator - http://ant.apache.org/ivy/

[xhanin]

That sounds like too much complexity for such little value. A better place
may be a property in md.restx.json, or simply don't support it except
through command parameters after all, we don't even know if someone will
actually have to change these excludes :).

On Sat, Mar 29, 2014 at 4:00 PM, Frédéric Camblor
notifications@github.comwrote:

Back on the topic.

Ok then if I add an entry in the AppSettings, how would I get "current
application's AppSettings instance" from the restx-shell classloader ?

Would there be a shell mechanism allowing to provide current visited app
classes in a dedicated classloader, thus allowing to create a Factoryfrom current visited application classes (where will reside the
AppSettings) ?

Reply to this email directly or view it on GitHubhttps://github.com/restx/restx/pull/72#issuecomment-38997965
.

Xavier Hanin
Lead architect at 4SH France - http://www.4sh.fr/
RESTX creator and lead developer - http://restx.io/
BordeauxJUG creator - http://www.bordeauxjug.org/
Apache Ivy Creator - http://ant.apache.org/ivy/

[fcamblor]

Note that currently, in different shell commands, we rely on AppSettings for some configuration values.
But we are, I think, fooled by the different contexts (shell context and current application context) in most of the cases.

Maybe should we file an issue about this topic ?

[fcamblor]

Note that currently, in different shell commands, we rely on AppSettings for some configuration values.
But we are, I think, fooled by the different contexts (shell context and current application context) in most of the cases.

Maybe should we file an issue about this topic ?

[xhanin]

About the usage of AppSettings, yes an issue to address it would be fine. I think at least some of these settings should be made available to the shell easily (at least all the paths and app package), and therefore having to rely on the module sources / classpath is not very simple / easy to address. But I currently don't see how to make that simple, so an issue to later address it is fine for me.

[xhanin]

About the usage of AppSettings, yes an issue to address it would be fine. I think at least some of these settings should be made available to the shell easily (at least all the paths and app package), and therefore having to rely on the module sources / classpath is not very simple / easy to address. But I currently don't see how to make that simple, so an issue to later address it is fine for me.

[xhanin]

And BTW the PR is fine for me like that, feel free to merge it, it's a nice feature!

[xhanin]

And BTW the PR is fine for me like that, feel free to merge it, it's a nice feature!

[fcamblor]

Concerning RestxArchive location, I'm wondering if it wouldn't be better to move the RestxArchive class to restx-build module.

It would be more natural for external tools to depend on restx-build than on restx-core-shell.

Drawback for this will be to add a dependency restx-build -> restx-core in order to be able to manipulate AppSettings class (plus some guava / commons-io classes) inside RestxArchive

WDYT ? (if you're ok, I'll move the class before the release)

[fcamblor]

Concerning RestxArchive location, I'm wondering if it wouldn't be better to move the RestxArchive class to restx-build module.

It would be more natural for external tools to depend on restx-build than on restx-core-shell.

Drawback for this will be to add a dependency restx-build -> restx-core in order to be able to manipulate AppSettings class (plus some guava / commons-io classes) inside RestxArchive

WDYT ? (if you're ok, I'll move the class before the release)

[xhanin]

I agree that its current location doesn't make it very easy to reuse, and that moving it to restx-build is probably a good idea. But I think it's a pretty big change in terms of module dependencies (especially with the requirement to have the core module as a dependency, I'm not sure we shouldn't rather move AppSettings to another module / review it / split it / discuss it). So I wouldn't change that the day of the release, I think it can wait.

[xhanin]

I agree that its current location doesn't make it very easy to reuse, and that moving it to restx-build is probably a good idea. But I think it's a pretty big change in terms of module dependencies (especially with the requirement to have the core module as a dependency, I'm not sure we shouldn't rather move AppSettings to another module / review it / split it / discuss it). So I wouldn't change that the day of the release, I think it can wait.

[fcamblor]

ok I'm fine with it.

[fcamblor]

ok I'm fine with it.