Hi,
I was thinking about dependency resolution and how to build a flexible
system that's also able to handle the complexities of OSGi dependency
management and some of the other approaches discussed here.
Let's first look at the configuration file, which is trivial:
<dependencies defaultType="someType">
<dependency>
<!-- contents depends on the type -->
</dependency>
<dependency type="local">
<!-- contents depends on the type -->
</dependency>
</dependencies>
How would this work? Well, there would be a deps plugin. This plugin
provides some component, let's call it DependencyHandlerRegistry. The
deps plugin itself contributes 3 built-in handlers:
- local: Local files
- url: Any URL supported by the JVM
- fileset: All files in an Ant FileSet
Other handlers I could think of:
- ivy: Resolve dependencies using Ivy
- bundle: OSGi dependencies
- pom: Resolve dependencies using (Maven1) POMs
- pom2: Resolve dependencies using M2 POMs
- ...: <add your favourite system here>
The interface would look somewhat like this:
import org.w2c.dom.Document;
import org.apache.tools.ant.types.Path;
public interface DependencyFactory {
Dependency createDependency(LoomProject project, Document config)
throws ConfigurationException;
}
public interface Dependency {
void setupClasspath(LoomProject project, Path classpath,
File cacheDir, File classpathDir);
}
The DependencyFactory implementations are contributed by plugins. While
handling the <dependencies> element, the deps plugin will invoke the
suitable factory for each dependency to allow the factory to process
the configuration and setup the "thing" which will finally contribute
its part of the classpath.
Now, for setting up the classpath: There would be a rule with high
salience that is activated for every CompilationUnit found, that has no
classpath attached. This rule will attach an empty classpath to the
CompilationUnit and set the focus on an agenda group
"java:compile:setupClasspath". Using an agenda group there makes sure
that all rules in this group are processed until the agenda for this
group is empty, before any other rule (like e.g. compile) is allowed to
fire.
This would be the point where deps plugin invokes setupClasspath() on
each dependency found during configuration phase. Each plugin gets some
directory where it may cache things (cacheDir, by default somewhere in
~/.loom/) and a classpathDir, where it may store JARs/classes needed
for the classpath (e.g. /project/basedir/target/classpath/main/plugin).
It's up to the plugin what it puts there, where it takes it from etc.
Basically, it just has to add its entries to the classpath, e.g. the
local plugin wouldn't need those directories at all.
BTW, a JUnit plugin would use this agenda group to automatically add
junit.jar to the classpath when compiling the test classes.
I think, like this, all the flexibility is given to provide plugins for
about any dependency management needs, including OSGi.
WDYT?
cu,
Raffi
PS: I'm aware that just passing around DOM fragments isn't optimal. It
needs to replaced by some configuration framework. Later. ;) When
things get more conrete ... :)
If anyone knows an existing framework which can handle scoped
configurations (system config -> user config -> meta project
config -> project config), please let me know.
--
The difference between theory and practice is that in theory, there is
no difference, but in practice, there is.
[EMAIL PROTECTED] · Jabber: [EMAIL PROTECTED] · PGP Key 5D1FF5F4
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
