> -----Original Message-----
> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
> 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
non-disposable.
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
>
[1] http://www.dpml.net/about/resources/lists.html
[2] http://www.dpml.net/transit/concepts/index.html
[3] http://www.dpml.net/station/concepts/index.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
