Re: understanding how configs are "mavenized"

Shash,

That sounds like a sound approach. Although from the looks of it, the
maven build-system seems to have largely stabalized at this point. Still
some kinks, but from my experience, my problems were due to not
understanding how the build system works.

It is no exaggeration though to say that it takes me 5 minutes to do a
build/deploy on my laptop - which is probably an "average" development
platform from a hardware perspective. This is glacially slow when I need
to tweak a JSP and see the results, or make a quick change to a model
(non-config change) and test it. I have heard that jdk 1.5 can help
optimize some operations, I will give that a try. I think I will be
doing some quick-and-dirty shell scripting to get around some of these
issues for the short-term.

Regards,

Adam


On Mar 14, 2005 09:32 AM, Sasvata (Shash) Chatterjee <[email protected]>
wrote:

> 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
> 


-- 
Adam Rossi
President, PlatinumSolutions, Inc.
[email protected]
http://www.platinumsolutions.com
Two Discovery Square, 12012 Sunset Hills Road, Suite 445
Reston, VA 20190    PH: 703.471.9793  FAX: 703.471.7140

This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately and delete
the original. Any other use of the email by you is prohibited.

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