ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: maven
Date Wed, 15 Dec 2004 11:03:55 GMT

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

nice to hear of your efforts.

cheers, Jim Fuller

>  Regards
> -- 
> Yves Martin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message