OSGi dependency resolution could also be done using Equinox's Resolver API, which is what Equinox uses at runtime to resolve bundles. This might be easier than resolving in an actual framework.
Jeremy On 5/6/07, Peter Neubauer <[EMAIL PROTECTED]> wrote: > Oh sorry, > that was my fault, I changed the artifact ID in my last commit, and > had the old bundles in left in my cache. Can you commit that change? > As I said, this is without any rules bundles, will do that later, but > that should be inspired from Raffael anyway. > > Andreas bidl system is a bit more Rake+Ivy inspired. IMHO I would like > something like Rake or Drools in the middle, but do the dependency > resolution on package level through a running OSGi framework against a > virtual set of packages, read from either OBR, Maven Repos or directly > searchable RDF repositories that have parsed up all code. Look at > http://srv03.ops4j.org:8080/openrdf-client/server/[EMAIL > PROTECTED]&basePath=http%3A%2F%2Fsrv03.ops4j.org%3A8080%2Fopenrdf-client%2F&path=%2Fopenrdf-client&[EMAIL > > PROTECTED]&org.springframework.validation.BindingResult.server=org.springframework.validation.BeanPropertyBindingResult%3A+0+errors¤tYear=2007, > Niclas is adding Manifest parsing to this I believe, so it could be > the base for an RDF based meta info structure. > > /peter > > On 5/6/07, Jeremy Volkman <[EMAIL PROTECTED]> wrote: > > Peter, > > > > Thanks, I got it to build. I did have to change the artifactId for > > org.ops4j.silk.api from "api" to "org.ops4j.silk.api" in both the > > system and process bundles, as Maven was complaining that it couldn't > > find the resource "org.ops4j.silk:api:jar:0.1.0-SNAPSHOT". I.e., > > > > From: > > <dependency> > > <groupId>org.ops4j.silk</groupId> > > <artifactId>api</artifactId> > > <version>${project.version}</version> > > </dependency> > > > > To: > > <dependency> > > <groupId>org.ops4j.silk</groupId> > > <artifactId>org.ops4j.silk.api</artifactId> > > <version>${project.version}</version> > > </dependency> > > > > Does that make sense? Perhaps the artifactId for the API bundle should > > have been changed from "org.ops4j.silk.api" to "api". I'm not an > > expert on Maven conventions. > > > > Thanks, > > Jeremy > > > > On 5/6/07, Peter Neubauer <[EMAIL PROTECTED]> wrote: > > > Jeremy, > > > for reference, I have put the central pats (strands are missing right > > > now) into laboratory in order to fix the build. > > > > > > svn co https://scm.ops4j.org/repos/ops4j/laboratory/users/peter/silk silk > > > cd silk > > > mvn clean install pax:provision > > > > > > after mvn install, you should be able to import the projects into > > > Eclipse (they are generated), and fix the classpath of the silk.api > > > project to incolude the libs in target/libs instead of just libs/ (bug > > > reported on PaxConstruct). > > > > > > Cheers > > > > > > /peter > > > > > > On 5/4/07, Jeremy Volkman <[EMAIL PROTECTED]> wrote: > > > > Cool. I'll take a look. > > > > > > > > -Jeremy > > > > > > > > On 5/4/07, Peter Neubauer <[EMAIL PROTECTED]> wrote: > > > > > Btw, > > > > > http://wiki.ops4j.org/confluence/download/attachments/57/speechops4j.pdf?version=1 > > > > > is a presentation on OSGi and Hansa/Silk I did for Öredev some time > > > > > ago. page 28 and down is about Hansa and Silk. Much regarding the > > > > > rules is actually beter thought out by Rafffael, but I think you get > > > > > the idea - RDF for all meta data, Rules for intelligence and > > > > > pluggablility and OSGi for dynamic runtime. > > > > > > > > > > /peter > > > > > > > > > > On 5/4/07, Jeremy Volkman <[EMAIL PROTECTED]> wrote: > > > > > > OPS4Jers, > > > > > > > > > > > > I checked out the Silk project and I'd like to mess around with it > > > > > > in > > > > > > my Eclipse environment. I noticed that many of the modules include > > > > > > "project" and "classpath" files under a src/eclipse subdirectory. > > > > > > Was > > > > > > there some convention in place for using these files where they > > > > > > reside, or were they simply reference files for developers to use in > > > > > > setting up their own workspace? Currently, I've got each file > > > > > > symlinked as ".project" and ".classpath" in the correct location, > > > > > > however the project files reference a "SILK_ROOT" keyword (not a > > > > > > valid > > > > > > Eclipse variable, I don't think), which obviously doesn't resolve: > > > > > > e.g., > > > > > > > > > > > > <link> > > > > > > <name>build.xml</name> > > > > > > <type>1</type> > > > > > > > > > > > > <locationURI>SILK_ROOT/core/jena/build.xml</locationURI> > > > > > > </link> > > > > > > > > > > > > For now I'll just tailor the files to my local environment. > > > > > > > > > > > > Thanks, > > > > > > Jeremy > > > > > > > > > > > > _______________________________________________ > > > > > > general mailing list > > > > > > [email protected] > > > > > > http://lists.ops4j.org/mailman/listinfo/general > > > > > > > > > > > > > > > > _______________________________________________ > > > > > general mailing list > > > > > [email protected] > > > > > http://lists.ops4j.org/mailman/listinfo/general > > > > > > > > > > > > > _______________________________________________ > > > > general mailing list > > > > [email protected] > > > > http://lists.ops4j.org/mailman/listinfo/general > > > > > > > > > > _______________________________________________ > > > general mailing list > > > [email protected] > > > http://lists.ops4j.org/mailman/listinfo/general > > > > > > > _______________________________________________ > > general mailing list > > [email protected] > > http://lists.ops4j.org/mailman/listinfo/general > > > > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general > _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
