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