On Sunday 20 June 2004 16:51, Markus M. May wrote: > > Yes, you will need to define or use server-side meta-data. The immediate > > effect after solving that is the Classloader (not classloading) > > establishment, since the 'type' of classloader the dependency belongs to, > > MUST be managed by the repository system, or you have missed a major > > goal.
> I agree on the meta-data stored on the server-side, but I did not > understood the 'type' of classloader and the major goal. Can you please > enlighten me? Yes, most people don't get it immediately, and possibly not until faced with the problem straight in your face (like for me, Stephen been on about it for a long time.) Exactly how much support is required by the Repository system is perhaps debatable, but the basic concept is needed; Project A depends on Jar B. Jar B has a chained, perhaps indirect, dependency on Jar C The Repository system is responsible to establish that Jar C must reside in a different classloader from Jar B. Example; Any pluggable functionality can not reside in the same classloader as the management, since it must be possible to purge the classes and reload. Example; In Avalon Merlin, the components doesn't have access to system (Merlin) implementation classes at all. They have access to the API only, so the top level component classloader has the APIs classloader as its parent, just like the Merlin implementation classes has. For Project TomDickHarry this may be 'fluff' and above their heads, but for seriously managed application frameworks, this is important. Maven lacks this completely, and because of it, it is very difficult for us to do proper unit testing. (The compile time dependency is required, and is thrown in by Maven, and ends up in the wrong classloader...) > > If Depot is only a tool for build systems itself, then you are also > > missing the goal, i.e. providing a functionality to a handful of build > > systems, each having their own solutions to this concern, is not a recipe > > for wide-spread acceptance, and a chicken-egg problem. > > You mean basically, that build systems like Maven need some plugins to > load from a central repository. This is done through the antlets and the > loading of this was one of the goals for a next release of depot, when i > remember correctly? Chicken-egg problem I was referring to was basically, Depot needs "real projects/products" to be using it, for it to gather enough use-cases, start getting something useful together to graduate from the Incubator. Noone is keen on being dependent on projects in Incubator. And if the consensus at Depot community, is that Depot should provide some rudimentary support for Maven, Ant-extensions and other build systems out there, you are narrowing the choices of willing projects to provide the 'spring board' out of Incubator, as they already have solutions for the problem at hand. The community here must have some balls to step up to the task beyond Maven. Doing artifact downloads from Maven repositories is too little too late, as Leo Simons can do that in <100 lines of javascript in Ant. Without the minimum of chained dependencies (which will lead to the classloader concern) there is no incentives at all to use Depot today. There is a real need for advanced applications like Avalon Meriln (who have a solution) and Geronimo (?). Without the balls and the vision, I doubt that Depot will flourish, as 'in-house solutions' is just as good, and we maintain control. Not until you get the snowball effect, projects/products will pick it up and use it. Cheers Niclas P.S. I am very opinionated based on 'fragmented excerpts' from the mailing list. I have not studied with Depot really consist of today at a detail level, so a lot of the above could be utterly wrong. If so, Depot needs to step up and get the message across louder to the other ASF projects that can benefit. -- +------//-------------------+ / http://www.bali.ac / / http://niclas.hedhman.org / +------//-------------------+
