Re: understanding how configs are "mavenized"

I think the proclaimed test-driven development only improves the issue 
from the developer's side. but think of the design of a web page. you 
usually try out a thousand things, change a tidbit here and there and 
then see how it looks. so always building the whole stuff is no solution 
here.

what i currently would do is to fiddle around with the jsp's (et al) in 
the exploded war in tomcat and then later move them to the project. 
however, imho that's not a tidy approach and we should think of another 
solution for this. maybe 'inject' new/changed view files into a war?

e.g.:
maven keel:injectview   -- adds the jsp's etc into the war (overwrite=true)

i don't know if that's possible. one step further and supercool would be 
if maven could track which concat comes from where in the 
struts-config.xml (et al), so that changes there could also be injected. 
i don't know if you can follow me:

imagine a struts-config like this:

---SECTION APP-HOJ--
...
---/SECTION APP-HOJ--
---SECTION APP-XYZ--
...
---/SECTION APP-XYZ--

so when i change something in struts-config of app-xyz and do a maven 
keel:injectview, the SECTION APP-XYZ gets deleted and reinjected. also, 
all jsps etc of app-xyz would get deleted and reinjected... would save a 
lot of compiletime...

Nils

Michael Nash wrote:

>
>Well, the uberjar and war process are not that quick, no question. There
>are no doubt optimizations we can do, but the first thing to try is to
>localize the unit tests to the app-* jar, e.g. if you have a series of
>unit tests in app-timewarp that excercise things, then you basically
>work "within" the app-timewarp project until a set of tests are running
>clean. Then you do the "whole 9 yards" of building the webapp.
>
>One issue that cropped up with Maven is that what we've been calling
>"unit tests" really aren't - they're *integration* tests, which is why
>most of the current keel modules have maven.test.failure.ignore=true in
>their build.properties - this is actually not recommended, as normally a
>"maven jar" (or jar:install-snapshot) will run the unit tests, and only
>create and install the jar *if* all unit tests are passing.
>
>In our case, for the moment at least, you have to do the whole "uberjar"
>build and then run the tests from *that* project (e.g. where you build
>the war), which is tedious.
>
>So, ideally we should be working towards a "test-driven" development
>cycle I believe, where the normal process is to work with app-xxx until
>it's testing clean, then build the war/uberjar only for the purposes of
>integration testing (less frequently then unit testing).
>
>HTH!
>
>Mike
>
>  
>

http://keelframework.org/documentation.shtml
Keelgroup mailing list
[email protected]
http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com