Live mode + apt

[Thomas DELHOMENIE]

Hi,

I have a mavenized Juzu project that I deploy in my Tomcat server.

I want to use the live mode, so I can make a change in my Java classes in my maven project and see my change without redeploying.

I saw that I can tell Juzu where my sources files are thanks to the 'src_path' context param in my web.xml. The problem is that, in a Juzu project, all the source files are not located at the same location, since some of them are generated with apt (and this is true for any other third part livrary which uses apt). And Juzu complains if it can't find all of the source files (even the apt generated ones).

So I have 2 locations (my sources + the ones generated by apt), and only one possible path in src_path.

(I know I can configure my IDE to make it generate the apt classes in the same location than my source files, but this is ugly)

Am I doing something wrong ? Is there another way to achieve what I want ? Shouldn't we have the capability to add several sources location in src_path ?

Regards,

Thomas

[Arnaud Héritier]

I'm also interested by such feedbacks. 

Also I would like to go futher and to not configure such thing in the web.xml (too difficult to manage a dev version vs a prod version)

--
You received this message because you are subscribed to the Google Groups "Juzu" group.
To unsubscribe from this group and stop receiving emails from it, send an email to juzu+uns...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

-----

Arnaud Héritier

http://aheritier.net

Mail/GTalk: aheritier AT gmail DOT com

Twitter/Skype : aheritier

[Julien Viet]

Hi Thomas

live mode work need all sources must be in the same directory, in practice it means src/main/java and the resources processed at compilation time such as the assets. I think this could be related and use several directories.

however APT generated source does not need to be exposed, as in the live mode, Juzu will compile everything in memory and the output of the compiler will be in memory (classes and APT generated sources).

[Julien Viet]

that should be overridable by a runtime configuration value such as a system property. The problem is that it would be VM wide (all applications would so switch in live mode) unless we would have a way to scope the setting for a given application.

[Arnaud Héritier]

In fact in tomcat I can do it using a context parameter entry : http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Context_Parameters

Thus I can define one dedicated for development mode

[Julien Viet]

what advantage does it provide over just changing web.xml itself ?

[Arnaud Héritier]

I don't want to manage several web.xml files (they might be complex).

Having one for dev, one for prod, ... could be a nightmare to manage at build time.

Using externalization of such setting let's me define my web.xml like it must be in a production environment and then override few stuffs while being in development mode.

[Thomas DELHOMENIE]

You mean I should not need the APT generated sources in src_path ? That should work without them ?

If I don't add them in src_path, I have exceptions (class not found) at runtime.

2013/9/23 Julien Viet <jul...@julienviet.com>

[Thomas DELHOMENIE]

I agree. This would be nice to externalize this param. And this could avoid commit a web.xml in live mode by mistake :)

It could be also a system property with a name depending on the application name : juzu.<my-appication-name>.mode

2013/9/23 Arnaud Héritier <aher...@gmail.com>

[Julien Viet]

I'm considering actually doing property replacement in the XML files pretty much like what we have in some exo products.

so something like <param-value>${whatevervalueyouwant:prod}</param-value>

that would achieve the same but allows the developer to pick whatever name he wants for the property