Re: understanding how configs are "mavenized"

I think we need a combination of things.  I think, first and foremost, 
as Mike has said repeatedly, we need to have the Maven build-system 
stabilize and working for all the modules and projects first.  Only then 
can we think of optimizations.

But, I think, we can speed up the cycle by devising a non-JAR, expanded 
classes way of using the Keel client and server sides during 
development.  That, combined with the Keel config and maven tools 
checking modificaion times on source JARs/config-files and using some 
form of disk-cache will go a long way in cutting down the build-times. 

Shash

Nils Döhring wrote:

> 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



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