> I simplified the model to consider a static module dependency (compile > and > runtime are identical for that first implementation - I really think it > is far > enough). A module simply declares it needs a third-party jar (log4j, > velocity...) or another module.
this approach can also take advantage of the new library (and ext dependencies task) tasks for refreshing a build/run env as well....though I found the sticking point (from enabling forward development at the developer level) is allowing developers to have a debug and release set of dependencies...this assists release versioning and packaging by ensuring that any cruft is removed. Do u reuse the same concept if a module needs another project module (component)? Its much easier to enforce everyone to use a specific version of a 3rd party lib....its much more difficult to expect each development team to use the latest version of all project components...too much volatility (data layer for example) usually means a knee jerk reaction to fall back to a last known good build of a specific component....though this can be solved with regular integration parties. > A specific feature of our build system is the support of generating and > using > versionned binary packages for modules (to ease delivery) I too have found its much better to make the difference between a debug and release version here....for example there is nearly always an impendence mismatch between version numbers for client consumption and internal versioning....also the release step could have all sorts of activities; remote deployment and unique file stamping seems to be my bugbear there. Perhaps the biggest thing to recognize is that once software attains a release 'state' it will inherantly be managed by different people, an operations type approach with their own view on change management...its a big mistake to convert the build system for use as Release management for big jobs. Build systems generate artifacts useful for software developers not necc. for the engineers who have to maintain all release versions of software/data for the years to come. > For data, nothing is done yet but I think I will use the same concept > from our > internal previous build system: SQL scripts splitted into actions =create, > insert, delete= and they are stored in each module. So "schema" and "data" > are > versionned with the code - aka with the versionning tool. neat, I have been toying around with XDoclet, letting developers embed sql script in code...keeping things nice and tight with the code; though in large projects convincing DBA's to adopt such tools is tough....I like the fact that persistence layers are almost de rigor in large projects now..it usually means I have everyone generate test data in xml files...much more amenable to source control (think doing a diff when merging). > EJB testing is OK with that design. mock objects, cactus, etc...there still seems to be a lot of missing harness that needs building up before proper testing of ejb's can occur....looking for more simplicity here....as it seems to be impossible to apply unit testing at this level with a minimum of pain. > For message queues, we used a test toolkit to generate messages and check > they > were managed correctly. might be time for a JMS task for ant...cant swing a dead cat without hitting websphere these days... nice to hear of your efforts. cheers, Jim Fuller > Regards > -- > Yves Martin > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
