Re: understanding how configs are "mavenized"

Adam:

I think there are three things we can do to make builds faster:

1. Do less: We're honing down the dependencies in many cases, as
unnecessary files are included. This has the side benefit of making the
jar/war smaller and can have a pretty big impact on build time. It will
take a bit of refactoring to get this fully optimized, but it gets
better every day.

2. Do it faster: There are some buffering things we can do in
KeelUberJar and KeelConfig/Maven tool to make things considerably
faster.

3. Do it smarter: This is basically Shash's point about checking mod
times, etc. Right now we're running the Xdoclet stuff whether it needs
it or not, this isn't very "optimized".

I'm sure with a combination of these we'll get the cycle time down to
something very reasonable.

At the same time, nothing wrong with a "RAD" goal that can just slap
some files from the app straight into the webapp, during development -
I'll look into that as well! This is especially handy for UI stuff - not
sure how it would work for code, though, but I'll check it out.

Mike

On Mon, 2005-03-14 at 12:42, Adam Rossi wrote:
> 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
> > 
> 

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