Stefano Mazzocchi wrote:
We should try to make it easier for gump to work with us. Our build
system is a little hacky in that regard since it uses partial gump
information to build cocoon.
Gump strongly suggests people to move their gump descriptors over to the
gump repository, so that all apache committers have access to it, not
just cocoon committers. This increases the ability for others to fix the
problems that we might introduce. At the same time, this is not
possible, since our build depends on that *and* we can't svn:externalize
it because the gump metadata is not (yet!) in SVN (we could get it from
viewcvs, though, but it sounds hacky)
So, the easiest thing is to allow gump committers to modify our
'gump.xml' files.
So, issue #1: would you like to allow this?
+1. Let's knowledged gumpers fix the descriptor when then find errors
rather than having to send patches.
- o -
There is another issue: cocoon has unique packages that we only depend
on and we place them in our gump.xml file, problem is that later on
other projects might start using those and collisions might happen. Gump
is not really happy when naming collisions happen (its datamodel is not
namespaced, yet) so one way to do it better is to ask the gump folks to
package the things we depend on directly. Means that its a little slower
turnover.
What does this mean concretely? That the libs we depend on will be
managed at Gump?
So, issue #2, would you like to ask the gump people to move our library
dependencies currently in gump.xml over in the gump metadata repository
instead?
Don't know yet...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
