incubator-depot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Moving forward or letting go
Date Sun, 20 Jun 2004 10:43:42 GMT
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 / 
+------//-------------------+


Mime
View raw message