> What I was thinking was that you would generate the build.properties from
> the list of gumped projects, rather than dependencies.
Not quite following the distinction, but maybe I am too close to the
currently implementation. Gump has a list of projects it is working on
and/or knows about, and a project has dependencies within that list.
Gump does know (in advance of any building) exactly what jars each project
ought produce, and where, but without having done any building knowledge of
'failed, but optional' is missing. As such, any behaviour on this (if we
chose any) would be lost.
What I'm saying it is I can build a build.properties based on the list of
Gumped projects & intersected with the dependencies. For me to understand
what is 'not right' about this, are you sayign this is fine, but any Maven
plug-ins that the build uses has dependencies that are not listed?
If so, in Gump <ant builds, we handle that by making those dependencies into
dependencies of the current project. Would that work here? [Point me back at
the archive if I've finally caught on to what you explain a few mails back.]
> If a project is not
> gumped, the dependency will have to come from a repository anyway, right?
Not quite, see below.
> How do you intend to handle this case as projects come on board that use
> non-ASF libraries?
Just to be clear, we already Gump plenty of non-ASF projects, see:
http://lsd.student.utwente.nl/gump/repositories.html
and for those we don't we can package:
http://lsd.student.utwente.nl/gump/packages.html
That said, is this debatably a locally managed repository? I'd say yes, and
would like to see it replaced (where legally possible) with one, simply for
consistency & leveraging what others do there.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
