Niclas Hedhman wrote:
...On Monday 21 June 2004 13:04, Nick Chalko wrote:
Classloading is a real problem in java, and an important one to tackle but I prefer to keep the scope of Depot limited. Other project's like Avalon can tackle the classloaders. Perhaps we can take over the version/download/security stuff.
I don't agree here, Nick, classloading is part of artifact handling, albeit in the JVM.
It can and IMHO should live as a Depot subproject.
The problem comes in when you introduce chained dependency. How do you signal that such a thing exist to the 'user' ?...
The issue chained dependencies is important, and I think gump can be of assistance. However gump only reflects the current state and we need access to the dependencies for other versions as well.
Gump?? Sorry, how on earth did you manage to get a "Continuous Integration System" to be part of a 'Jar Hell' solution?
The Gump Metadata is a rich source of dependencies. Stephen AFAIK is investigating in this too.
We have chained dependencies in place. It works well, but our down side is that only Avalon tools generate and understand the necessary meta information required to support this feature.
That's why using Gump metadata would bring projects closer.
...
What do you see as the common ground for us to participate on ?
ATM, the biggest problem is that we; * Know too little about each other's concerns and view points. * Doesn't understand each other's codebases. * Disagree of the total scope of Depot.
What _I_ really would like to do is move Avalon Repository to Depot as a sub-project, but there are some 'community problems' with that, i.e. Depot is in Incubator, and Avalon has said NO to depending on Incubator projects.
Anyway, once Repository was in Depot, one could take out the bits and pieces that exist elsewhere in the Depot codebase.
I have read the Avalon Repository site and it's very much in line with Depot.
The only real issue I see is the catch22 problem you have outlined about Avalon using Incubator code and viceversa.
Let me disagree with it though. It's ok that an Apache project does not rely on incubating projects, but if some of the developers are part of this incubating project, does it still make sense?
I mean, imagine that we move Avalon repository code in Depot and start merging. I don't see it a problem for Avalon, as the development of it is still happening also with Avalon people, as it was before, and Avalon can still decide to fork back in case it wants to.
Would this ease concerns?
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
