Build systems are awfully close to editors, in terms of holy wars.
Although in the case of build systems, you can often eventually convert
people if you can get them to 'see the light' of your system - once you
show them in their project something that works better and is easier to
maintain, they'll start using it.
I like the proxy idea, I think; it lets either side control this stuff. If
someone can either 1) implement it for Xalan, or 2) write documentation
that describes what to do, I'll make sure it is maintained for Xalan and
xml-commons. Is there a quick link to any jjar end-user doc available?
- Shane
> ---- "Morrison, John" wrote:
> >
> > I think that getting all the projects to conform would be an impossible
> > task. People just don't like having this sort of thing imposed on them
-
> > even if it is 'the best' and, for want of a better term, 'standard'.
> >
> > Good luck if you try to persue it though - it would make life easier!
;)
>
> ---- geir wrote:
> I guess my thinking was this - I agree that it won't be easy, nor will
> everyone want to play.
>
> But if people start using ant for builds, and ant + jjar makes it easy
> to specify and ensure that dependencies are present and up to date w/o
> each project having to either a) maintain a working set in CVS or b)
> write docs and answer endless questions from users about where, how and
> what to get, then I think there is a compelling reason to do it...
>
> For the projects that don't want to (and of course, there are projects
> outside of jakarta that we would want to support with the jjar
> repository until they wanted to participate), we could simply keep a
> 'proxy' repository descriptor for each one of them. Sam & co. do this
> already within gump - making it external means that jjar and other tools
> can access as well.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
