ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve" <>
Subject RE: Building from a list...
Date Tue, 25 Apr 2006 20:22:01 GMT

> -----Original Message-----
> From: Dominique Devienne [] 
> Sent: Wednesday, 26 April 2006 4:56 AM
> To: Ant Users List
> Subject: Re: Building from a list...
> > [...] While Depot is not final, it does provide:
> >
> >  1. transitive dependency management
> >  2. plugin build system deployment
> >  3. automated path management (build, test and runtime)  4. source 
> > normalization  5. automated filtering, compilation, jar production, 
> > testing, etc.
> >  6. build automation support via custom processors  7. build 
> > customization via ant
> Sounds too good to be true Steve ;-)
> Would I still be doing Java CM with Ant, 

Yes and no.

Depot provides to distinct services:

  1. a CM layer which is build system independent 
     (within which you can define build, truntime and test phase
     dependencies, produced resources, resouse info, and production
     information - largely product oriented as opposed to the process
     orientation tipified by Ant)

  2. a build solution that is plugin driven
     (i.e. a project defintion declares a build strategy and the build
     system will automatically load the strategy - the default build
     strategy is based on Ant).

> I'd definitely check 
> it out, to replace all the custom stuff I used to do. But one 
> aspect of what I was doing I don't see in Maven or other 
> dependency management tools is the fact that the build 
> artifacts I was depending upon were only partly 
> cross-platform. Half of it was native code with the JNI layer 
> on top. I was jumping thru a lot of hoops because of this.

Native content can be a RPITA.  In terms of build sequencing this is not 
a big issue.  At the level of Depot's notion of a project the things that 
are important are produced artifacts (files plus supplementary attributes).
Where things get tricky is in the runtime (specifically runtime metadata and
test phase data) largely due to the fact the native content is
There are some posts of the DPML support list [1] related to the native 
subject which may be relevant (including some demonstrations of how to 
achieve this).

> Each component had to be continuously built on several 
> platforms. When downloading a dependency, getting all 4 
> platforms' binaries was too big (Solaris .so are huge), so 
> only the current platforms binaries had to be downloaded. 

This is not a problem.  Underlying Depot is a resource management layer 
named Transit [2] that provides the mechanisms for targeted resource 
downloading and local caching (with support for multiple host schemas 
including Maven-1, Maven-2 and Eclispse).

> Solaris builds slower than Linux or Windows, so platforms 
> were not synced. This kind of complications...
> How would depot deal with such a mixed native+Java code situation?
> Just wondering. Maybe it's too specific a case, although I'm 
> sure there must be other people doing mixed Java / 
> C/C++/Fortran development out there.

Mixed native+Java code has not been a priority and as mentioned about
there are runtime issues - but this is more related to the overall 
management of things like runtime and test phase classloader 
construction.  On one hand the DPML content is very focussed on 
components and the infrastructure to automate component assembly, 
composition and decommissioning - and native content in this much more
aligned with a specific JVM configuration.  Just initially I would 
Think that runtime concerns could best be addressed within the scope 
Of the DPML Station (a JVM instance management system) [3].

Cheers, Steve.

> --DD


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message