On Oct 5, 2006, at 7:10 AM, Ken Tam wrote:
Yeah, I haven't run into the ordering issue because I'm just dealing
with individual extensions, but that completely makes sense.
It feels like if we're going to stay on the track of this maven(-like)
depot system for managing extensions, I would support going whole hog
and relying on the POM to express all dependencies -- then your
comment in 765:
"If we plan on supporting just dropping in of extension jars to a
directory will need a means to either prescan to resolve their
dependencies or load all and then begin to autowire."
would be addressed by doing the same kind of "prescan/resolution" that
maven does today when there are transitive and redundant dependencies.
Otherwise it feels like we are signing up for an increasingly crappy
user experience as they are forced to understand what extensions
depend on what other ones and in what order.
We need to be clear about the difference between classloader (and
other resource) dependencies and functional dependencies between
components. We might use the same words but they are very different
things.
Maven's <dependency> mechanism reflects resource dependencies between
jar files. It was originally designed to construct the classpath for
compilation and test and has been used by assembly-style plugins to
reflect that classpath structure in their output artifacts (like the
way the maven war plugin uses it to populate the /WEB-INF/lib
classpath).
What Rick is running into is a functional dependency between
components - instances that need to be registered in the right order
due to the wires (explicit or autowire) that connect them. That's a
very different problem. It's also a problem that we have recognized
and discussed before and provided some workarounds for (e.g. the init-
order configuration) although IMO we have not yet implemented a full
solution. Classifying this as "signing up for an increasingly crappy
user experience" is deriding all the work people have put into this
already and is certainly disrespectful of the motivations this
community. Quit whining, and thanks for volunteering to help fix
these issues.
One solution proposed but not yet implemented is to load all the
extensions before starting them rather than the current way we load/
start each one in turn - that should be a fairly simple change to the
AbstractExtensionDeployer and the two subclasses that use it. A patch
for that would be welcome.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
