Peter Kriens schrieb:
> Did you take a look at OBR?
Oh, well, let's put that one on the list, too. Remember: This build
system will support OSGi fully, at least, that's the goal, but it won't
be limited to it. E.g., the project I'm currently working on is awfully
structured, from that point of view, the "fileset" handler is the most
interesting one. The goal is that it finally supports everything, from
compiling HelloWorld without any configuration to compiling complex
OSGi projects.
My question was actually a different one: Think of plugging in OSGi. Are
there any holes in this? Or is it, on the contrary, too open, so it's
too much work to realise an OSGi plugin?
Drinking some beer I found a hole myself, however, this hole isn't
really related to setting up the classpath.
> 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>
As promised above: ;)
- obr: Resolve dependencies using OBR
> 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> }
Here we've got a major problem. Look at my description of meta projects:
http://wiki.ops4j.org/confluence/display/ops4j/Loom#Loom-core
(Subsection "Multi-Project Builds and Meta Projects")
I didn't describe that idea very well in the Wiki, sorry about that. The
idea is very clear in my mind, but it's difficult to describe,
particulary, if you're not using your mother tongue ... :)
What's completely missing here, is how the BS would reverse-map such
dependencies to a project it found as source. The idea behind meta
projects is that one can put a project into the working directory,
which will cause the BS to build it, instead of downloading some build.
If it's not present, it will try to look it up in some repository.
An example:
Let's assume, I'm working on commons-digester. It uses commons-beanutils
and I'm fine with that, so I just use some build that has been found in
some repository. Now, I encounter a problem with commons-beanutils and
have to work a little bit on that one, too, and test them together. So,
I just put beanutils into my working directory => digester and
beanutils will be built together. Of course, this wouldn't work with
any project, just with projects that are closely related by being
member of the same meta project.
Anyway, it has some more implications: My plan was that the core plugin
would handle the <info> section of the project description. This isn't
possible like that, because the core plugin can't know, how the <info>
section is structured and what information it actually contains. Which
basically means: A project must have a target deployment system (local,
ivy, obr, whatever) and must take care of that, too. It must take care
of generating all the meta information needed by the particular system,
and it must be able to reverse-map such information from a dependency
declaration to a project that has been found by the core to trigger a
multi-project build.
This has to be further thought out ...
cu,
Raffi
--
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
