From: Herko t. H. <her...@ad...> - 2009-02-04 13:22:47
|
Aperturians, As we discussed[1] last year, Mavenization of Aperture would bring several benefits at the cost of introducing the complexity of Maven to the project. Now, with the much-requested ability to use Aperture in an OSGi environment, I think Maven - and especially the Maven bundle plugin developed by the Apache Felix project[2] - brings additional benefits that outweigh the complexity issues. The attempt I made at Mavenizing Aperture last year was cut short because of a missing "business case". Now, it seems there is a clear business case: the use of Aperture in the SMILA project. This means I can give it another shot. The upside of the delay is that I have learned much more about Maven :) I think most of the goals we identified last year still stand. One goal is no longer essential: the separation of OSL vs AFL licensed modules is no longer necessary because of the move to the BSD-style license. Added goals are: - the ability to build plain jars as well as OSGi-compatible jars - the ability to run automated integration tests using an OSGi container Just to get a feel for how Maven and the bundle plugin can help, I've added OSGi compatiblity to the already Mavenized "Commons" modules at Aduna. I was glad to see this was pretty much painless. Of course, these are "just" library modules, which don't expose or need services in an OSGi framework, but still... Using the bundle plugin also helped me setup OSGi access to these bundles/artifacts, by turning our Maven repository into an OBR[3] repository[4]. With the added effort made by Antoni and Gunnar to get the previously unreleased dependencies either releaseable or removed, I feel confident I can get it done this time. I'll keep everyone informed. Cheers, Herko [1] http://sourceforge.net/mailarchive/forum.php?thread_name=47A05014.6010508%40aduna-software.com&forum_name=aperture-devel [2] http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html [3] http://www.osgi.org/download/rfc-0112_BundleRepository.pdf [4] http://repo.aduna-software.org/maven2/snapshots/repository.xml |
From: Leo S. <leo...@df...> - 2009-02-04 13:35:39
|
Hi, I agree, with important comments: It was Herko ter Horst who said at the right time 04.02.2009 14:22 the following words: > Aperturians, > > As we discussed[1] last year, Mavenization of Aperture would bring > several benefits at the cost of introducing the complexity of Maven to > the project. Now, with the much-requested ability to use Aperture in an > OSGi environment, I think Maven - and especially the Maven bundle plugin > developed by the Apache Felix project[2] - brings additional benefits > that outweigh the complexity issues. > > The attempt I made at Mavenizing Aperture last year was cut short > because of a missing "business case". Now, it seems there is a clear > business case: the use of Aperture in the SMILA project. This means I > can give it another shot. The upside of the delay is that I have learned > much more about Maven :) > > I think most of the goals we identified last year still stand. One goal > is no longer essential: the separation of OSL vs AFL licensed modules is > no longer necessary because of the move to the BSD-style license. > > Added goals are: > - the ability to build plain jars as well as OSGi-compatible jars > no, in my view this can read: - the ability to build plain jars that are also OSGi compatible jars (= we have one JAR release that is both plain jar and OSGi) This is easily possible without maven, you just tweak (by hand) the manifest, and gotcha. with maven, I guess you have suddnely a dependency on OSGi in the artifact, which may cause an import-cascade to the full osgi frenzy for the plain-java users. if this is the case, then it reads as you said imho we also have to add this: - the ability to build two plain jars (core, impl) for easy-going developers - the ability to build two osgi jars (core, impl) for easy-going developers (such as NEPOMUK) > - the ability to run automated integration tests using an OSGi container > > Just to get a feel for how Maven and the bundle plugin can help, I've > added OSGi compatiblity to the already Mavenized "Commons" modules at > Aduna. I was glad to see this was pretty much painless. Of course, these > are "just" library modules, which don't expose or need services in an > OSGi framework, but still... Using the bundle plugin also helped me > setup OSGi access to these bundles/artifacts, by turning our Maven > repository into an OBR[3] repository[4]. > > With the added effort made by Antoni and Gunnar to get the previously > unreleased dependencies either releaseable or removed, I feel confident > I can get it done this time. > good, this is very positive news! I would think it would be good to have all changes done within a month, so that your branch does not get too far away from trunk best Leo > I'll keep everyone informed. > > Cheers, > > Herko > > [1] > http://sourceforge.net/mailarchive/forum.php?thread_name=47A05014.6010508%40aduna-software.com&forum_name=aperture-devel > [2] http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html > [3] http://www.osgi.org/download/rfc-0112_BundleRepository.pdf > [4] http://repo.aduna-software.org/maven2/snapshots/repository.xml > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > Aperture-devel mailing list > Ape...@li... > https://lists.sourceforge.net/lists/listinfo/aperture-devel > -- ____________________________________________________ DI Leo Sauermann http://www.dfki.de/~sauermann Deutsches Forschungszentrum fuer Kuenstliche Intelligenz DFKI GmbH Trippstadter Strasse 122 P.O. Box 2080 Fon: +49 631 20575-116 D-67663 Kaiserslautern Fax: +49 631 20575-102 Germany Mail: leo...@df... Geschaeftsfuehrung: Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 ____________________________________________________ |
From: Herko t. H. <her...@ad...> - 2009-02-04 13:46:07
|
Leo Sauermann wrote: > Hi, I agree, with important comments: >> Added goals are: >> - the ability to build plain jars as well as OSGi-compatible jars >> > no, in my view this can read: > - the ability to build plain jars that are also OSGi compatible jars (= > we have one JAR release that is both plain jar and OSGi) > This is easily possible without maven, you just tweak (by hand) the > manifest, and gotcha. > with maven, I guess you have suddnely a dependency on OSGi in the artifact, > which may cause an import-cascade to the full osgi frenzy for the > plain-java users. > if this is the case, then it reads as you said Right, fully agree. We'll just have the one jar for each module that contains an OSGi-compatible manifest and possibly an Activator that plain-jar users can safely ignore. There will be no dependency on OSGi for plain-jar users. > imho we also have to add this: > - the ability to build two plain jars (core, impl) for easy-going > developers > - the ability to build two osgi jars (core, impl) for easy-going > developers (such as NEPOMUK) Ok. >> With the added effort made by Antoni and Gunnar to get the previously >> unreleased dependencies either releaseable or removed, I feel >> confident I can get it done this time. >> > > good, this is very positive news! > > I would think it would be good to have all changes done within a month, > so that your branch does not get too far away from trunk Actually, I'm going to try to get most of it done by the end of next week :) I should be able to at least get it working well enough so further development can take place in the Mavenized version (meaning the full project can be built with Maven). Cheers, Herko |
From: Leo S. <leo...@df...> - 2009-02-04 14:14:20
|
It was Herko ter Horst who said at the right time 04.02.2009 14:45 the following words: > Actually, I'm going to try to get most of it done by the end of next > week :) I should be able to at least get it working well enough so > further development can take place in the Mavenized version (meaning the > full project can be built with Maven). > that would rock. best Leo > Cheers, > > Herko > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > Aperture-devel mailing list > Ape...@li... > https://lists.sourceforge.net/lists/listinfo/aperture-devel > -- ____________________________________________________ DI Leo Sauermann http://www.dfki.de/~sauermann Deutsches Forschungszentrum fuer Kuenstliche Intelligenz DFKI GmbH Trippstadter Strasse 122 P.O. Box 2080 Fon: +49 631 20575-116 D-67663 Kaiserslautern Fax: +49 631 20575-102 Germany Mail: leo...@df... Geschaeftsfuehrung: Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 ____________________________________________________ |
From: Herko t. H. <her...@ad...> - 2009-02-04 19:05:02
|
Aperturians, Here's the first progress report of the Maven/OSGi transformation process. I've moved the aperture-tools modules to their final destination, setup a root pom and implemented the OSGi bundle plugin for Maven. The result can be seen here: http://repo.aduna-software.org/maven2/snapshots/repository.xml OSGi-enabled (hence the three-digit version number), and fully "backwards" compatible. The only thing that's different is some entries in the Manifest. Lessons learned: - don't split packages across modules. The bundle plugin doesn't like it, and I think it's right: I suppose it breaks OSGi "Import-Package" capabilities. (both unionsail and infsail have an o.s.n.openrdf package) Note 1: I've updated the dependency on Sesame to version 2.3.0-SNAPSHOT. This is the (fully backwards-compatible) version of Sesame I plan to make OSGi-friendly (meaning it's not going to be fully OSGi aware and capable yet, but it will be exporting the right packages and stuff). It uses the already OSGi-friendly versions of the Aduna Commons libraries as well. Note 2: I've set up the Aperture tools project on our continuous integration server, so it will build automatically (each hour, if there are any changes, or in response to changes in upstream projects, such as Sesame and Aduna Commons.) Note 3: To import the Sesame dependencies in one go (so I don't have to copy/paste them from the Sesame root pom), I've used the newly introduced "import" scope. This scope only became available in Maven version 2.0.9 (the latest version as of April 10, 2008). It is NOT compatible with older Maven versions. Cheers, Herko |
From: Antoni M. <ant...@gm...> - 2009-02-04 19:13:42
|
2009/2/4 Herko ter Horst <her...@ad...>: > Aperturians, > > Here's the first progress report of the Maven/OSGi transformation process. > > I've moved the aperture-tools modules to their final destination, setup > a root pom and implemented the OSGi bundle plugin for Maven. > > The result can be seen here: > http://repo.aduna-software.org/maven2/snapshots/repository.xml > > OSGi-enabled (hence the three-digit version number), and fully > "backwards" compatible. The only thing that's different is some entries > in the Manifest. > > Lessons learned: > - don't split packages across modules. The bundle plugin doesn't like > it, and I think it's right: I suppose it breaks OSGi "Import-Package" > capabilities. (both unionsail and infsail have an o.s.n.openrdf package) It's a limitation of OSGI itself. Only one bundle can export a package. If more than one bundle exports a package, only one of them package will be found (chosen at random). This may be a problem, e.g. with the DefaultRegistries, that's why we will need to move the default registries to a separate module, which will not be usable in osgi. In aperture 2.0 each default registry will have to go into its own package. > Note 1: > I've updated the dependency on Sesame to version 2.3.0-SNAPSHOT. This is > the (fully backwards-compatible) version of Sesame I plan to make > OSGi-friendly (meaning it's not going to be fully OSGi aware and capable > yet, but it will be exporting the right packages and stuff). It uses the > already OSGi-friendly versions of the Aduna Commons libraries as well. > > Note 2: > I've set up the Aperture tools project on our continuous integration > server, so it will build automatically (each hour, if there are any > changes, or in response to changes in upstream projects, such as Sesame > and Aduna Commons.) > > Note 3: > To import the Sesame dependencies in one go (so I don't have to > copy/paste them from the Sesame root pom), I've used the newly > introduced "import" scope. This scope only became available in Maven > version 2.0.9 (the latest version as of April 10, 2008). It is NOT > compatible with older Maven versions. > > Cheers, > > Herko > Great, looking forward to get more. -- Antoni Myłka ant...@gm... |
From: Herko t. H. <her...@ad...> - 2009-02-06 18:03:07
|
Aperturians, Despite getting side-tracked a bit yesterday and today (bloody paying customers ;)), I've made good progress with a couple of essential modules now ready to go. Central to all of Aperture are the various ontologies used to represent the (meta-)data of the resources Aperture is able to process. The Java classes for these (RDF) vocabularies used to be semi-automatically generated from an Ant build file, with the results committed to SVN. In the new Maven setup, I've removed the generated Java files from source control. They will now be generated automatically on the fly (but only if needed, e.g. if a vocabulary file is seen that is newer than the Java file) when running pretty much any Maven target (including 'mvn eclipse:eclipse'). To get this to work, I had to implement my first Maven plugin (yay!). This was surprisingly easy. I introduced a "Vocabulary" class to capture the various settings for generating Java code from each vocabulary. I then implemented a "mojo" (as Maven plugins are commonly known) that wants a list of these Vocabulary objects as input. Configuration for a single vocabulary looks like this: <vocabulary> <ontology>${vocabulary.input.dir}/tagging.rdfs</ontology> <namespace>http://aperture.sourceforge.net/ontologies/taggingl#</namespace> <javaClass>${vocabulary.java.package}.TAGGING</javaClass> <outputDir>${vocabulary.output.dir}</outputDir> </vocabulary> This is inserted into a Maven pom file as part of the configuration for the plugin (the ${blah} thingies are properties defined elsewhere in the same pom). For more info, see the aperture-vocabulary-core pom file[1]. I'll use the same approach for generating the DataSource classes when I get to those. I've now added Aperture itself to our build server too, so as soon as something builds successfully, it will be available from our Maven/OSGi repository.[2] Lessons learned: 1. Apparently, there's a weird bug in the maven-eclipse-plugin (or somewhere...). This bug bit me when I first tried to generated Eclipse files for the datasource-maven-plugin. It doesn't seem to occur any more at the moment, though... However, should anyone get strange missing dependencies messages when trying to run 'mvn eclipse:eclipse', the work-around is to add the 'package' goal before the 'eclipse:eclipse' goal, i.e. execute 'mvn package eclipse:eclipse'. 2. Implementing Maven plugins is pretty easy, so we shouldn't hesitate to implement a Maven plugin for specific functionality that is not already provided by existing plugins (like the class generation from RDF models we do). Enjoy the weekend! Cheers, Herko [1] http://aperture.svn.sourceforge.net/viewvc/aperture/aperture/trunk/core/vocabulary/core/pom.xml?view=markup [2] http://repo.aduna-software.org/maven2/snapshots/ |
From: Antoni M. <ant...@gm...> - 2009-02-07 00:15:14
|
2009/2/6 Herko ter Horst <her...@ad...>: > Aperturians, > > Despite getting side-tracked a bit yesterday and today (bloody paying > customers ;)), I've made good progress with a couple of essential > modules now ready to go. > > Central to all of Aperture are the various ontologies used to represent > the (meta-)data of the resources Aperture is able to process. The Java > classes for these (RDF) vocabularies used to be semi-automatically > generated from an Ant build file, with the results committed to SVN. > > In the new Maven setup, I've removed the generated Java files from > source control. They will now be generated automatically on the fly (but > only if needed, e.g. if a vocabulary file is seen that is newer than the > Java file) when running pretty much any Maven target (including 'mvn > eclipse:eclipse'). > > To get this to work, I had to implement my first Maven plugin (yay!). > This was surprisingly easy. I introduced a "Vocabulary" class to capture > the various settings for generating Java code from each vocabulary. I > then implemented a "mojo" (as Maven plugins are commonly known) that > wants a list of these Vocabulary objects as input. Configuration for a > single vocabulary looks like this: > > <vocabulary> > <ontology>${vocabulary.input.dir}/tagging.rdfs</ontology> > <namespace>http://aperture.sourceforge.net/ontologies/taggingl#</namespace> > <javaClass>${vocabulary.java.package}.TAGGING</javaClass> > <outputDir>${vocabulary.output.dir}</outputDir> > </vocabulary> > > This is inserted into a Maven pom file as part of the configuration for > the plugin (the ${blah} thingies are properties defined elsewhere in the > same pom). For more info, see the aperture-vocabulary-core pom file[1]. > > I'll use the same approach for generating the DataSource classes when I > get to those. Great, I've been thinking about this for a long time. > I've now added Aperture itself to our build server too, so as soon as > something builds successfully, it will be available from our Maven/OSGi > repository.[2] That's a great idea too. We need a maven repository for the OSGI versions of the dependencies. > Lessons learned: > > 1. Apparently, there's a weird bug in the maven-eclipse-plugin (or > somewhere...). This bug bit me when I first tried to generated Eclipse > files for the datasource-maven-plugin. It doesn't seem to occur any more > at the moment, though... However, should anyone get strange missing > dependencies messages when trying to run 'mvn eclipse:eclipse', the > work-around is to add the 'package' goal before the 'eclipse:eclipse' > goal, i.e. execute 'mvn package eclipse:eclipse'. I personally don't use eclipse:eclipse, the new maven plugin for eclipse seems much better, it can even handle embedded projects, which was supposed to be the limitation of the eclipse workspace model. > 2. Implementing Maven plugins is pretty easy, so we shouldn't hesitate > to implement a Maven plugin for specific functionality that is not > already provided by existing plugins (like the class generation from RDF > models we do). > > Enjoy the weekend! > > Cheers, > > Herko > > [1] > http://aperture.svn.sourceforge.net/viewvc/aperture/aperture/trunk/core/vocabulary/core/pom.xml?view=markup > [2] http://repo.aduna-software.org/maven2/snapshots/ > If there is anything I could help with, just ask. -- Antoni Myłka ant...@gm... |
From: Herko t. H. <her...@ad...> - 2009-02-17 19:41:51
|
Aperturians, Thanks to Antoni, the core modules (accessor, crawler and extractor) are now ready to go. I've also Mavenized the accessor and crawler implementations (subcrawlers are next on my to-do list). For this, I also needed to Mavenize a few other modules, such as the Security modules, the Mime-type Identifier, the Link Extractor and a HTML parser helper module. This meant moving a couple of classes around. This has been and will be discussed elsewhere (in the "Aperture Mavenization - comments" thread). IMO, it's unavoidable. Although we've been relatively careful about inter-package dependencies from the start (thank goodness, as I remember the "mess" we had to untangle when we modularized Sesame and AutoFocus was much worse), sometimes there's a class, a method or even just a particular Exception that gets in the way of creating a module with clear responsibilities and clean dependencies. Case in point: the HTML parser helper module. The HtmlParserUtil class (which provides a simple facade to the 'htmlparser' library) is used by a couple of different classes in what are now different modules. It's used not only by the HTML Extractor, but also by the mail crawlers and the WebCrawler implementation. Yet, the parse() utility method threw an ExtractorException. This tied it to the extractor-core module, which would have been OK if the HTML parser had been used only by the HTML extractor. Now, it's not so nice. In this case, I opted to replace the ExtractorException with a custom HtmlParserException. Yes, this is a backwards-incompatible change, but it is needed to keep a clean separation between modules and their dependencies. Cheers, Herko |
From: Herko t. H. <her...@ad...> - 2009-02-27 10:51:54
|
Aperturians, The good news is that just now I've committed the last of the "core" Mavenized Aperture modules. This means that the core functionality of Aperture can now be built using Maven. The slightly less good news is that a lot of work remains to attain the goals we set for this procedure. First of all, a "one-jar" is needed that fulfills the need of current Aperture users. All unit and integration tests still have to be copied to the new modules (which may introduce additional dependencies). The examples and contributed modules still need to be moved as well. However, all this seems very doable. Lessons learned: 1. platform-dependent builds using Maven profiles[1] A couple of modules in Aperture are dependent on a particular platform. For example, the Outlook module needs a Microsoft Windows environment (and Outlook itself, obviously). Another example is the Apple addressbook module, that relies on a couple of Mac-specific classes. I've learned that Maven profiles are the way to deal with platform-specific builds. The way I've currently implemented this is by defining (at least) two profiles in each platform-specific module: one to represent what should be done when the right platform is available, and one that specifies what do when it isn't. For example, the platform-specific profile could define additional platform-specific dependencies such as DLLs, while the second profile could prevent unit/integration tests from running on "other" platforms. For a more elaborate example, please take a look at the pom.xml file in the aperture-outlook module[2]. Kind regards, Herko [1] http://maven.apache.org/guides/introduction/introduction-to-profiles.html [2] https://aperture.svn.sourceforge.net/svnroot/aperture/aperture/trunk/core/outlook/pom.xml |
From: Leo S. <leo...@df...> - 2009-02-27 14:23:11
|
good news! out of pure curiosity: net.sf.jacob-project - this means that there is a mavenized version of jacob available? best Leo It was Herko ter Horst who said at the right time 27.02.2009 11:51 the following words: > Aperturians, > > The good news is that just now I've committed the last of the "core" > Mavenized Aperture modules. This means that the core functionality of > Aperture can now be built using Maven. > > The slightly less good news is that a lot of work remains to attain the > goals we set for this procedure. First of all, a "one-jar" is needed > that fulfills the need of current Aperture users. All unit and > integration tests still have to be copied to the new modules (which may > introduce additional dependencies). The examples and contributed modules > still need to be moved as well. However, all this seems very doable. > > Lessons learned: > 1. platform-dependent builds using Maven profiles[1] > A couple of modules in Aperture are dependent on a particular platform. > For example, the Outlook module needs a Microsoft Windows environment > (and Outlook itself, obviously). Another example is the Apple > addressbook module, that relies on a couple of Mac-specific classes. > > I've learned that Maven profiles are the way to deal with > platform-specific builds. The way I've currently implemented this is by > defining (at least) two profiles in each platform-specific module: one > to represent what should be done when the right platform is available, > and one that specifies what do when it isn't. > > For example, the platform-specific profile could define additional > platform-specific dependencies such as DLLs, while the second profile > could prevent unit/integration tests from running on "other" platforms. > > For a more elaborate example, please take a look at the pom.xml file in > the aperture-outlook module[2]. > > Kind regards, > > Herko > > [1] > http://maven.apache.org/guides/introduction/introduction-to-profiles.html > [2] > https://aperture.svn.sourceforge.net/svnroot/aperture/aperture/trunk/core/outlook/pom.xml > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Aperture-devel mailing list > Ape...@li... > https://lists.sourceforge.net/lists/listinfo/aperture-devel > -- ____________________________________________________ DI Leo Sauermann http://www.dfki.de/~sauermann Deutsches Forschungszentrum fuer Kuenstliche Intelligenz DFKI GmbH Trippstadter Strasse 122 P.O. Box 2080 Fon: +49 631 20575-116 D-67663 Kaiserslautern Fax: +49 631 20575-102 Germany Mail: leo...@df... Geschaeftsfuehrung: Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 ____________________________________________________ |
From: Herko t. H. <her...@ad...> - 2009-02-27 14:15:38
|
Hi Leo, > good news! > > out of pure curiosity: > net.sf.jacob-project > - this means that there is a mavenized version of jacob available? Yes, it's even in the central Maven repository. It has the jar and DLLs for 32 and 64 bit systems. It's a bit newer even than the version we used before (so we'll need to test with this version). http://repo1.maven.org/maven2/net/sf/jacob-project/jacob/1.14.3/ Cheers, Herko |
From: Antoni M. <ant...@gm...> - 2009-03-13 19:20:35
|
Hello, aperture-dev Just wanted you to know that all tests and examples have been migrated to the new maven-based build. I'm beginning to look into proper migration of the osgi-based integration test, to see how many of our dependencies we need to convert to OSGI ourselves. Then we'll need to set up a release build. Don't know how to do it (yet), but I'm sure there are people on this list who have much more experience in these matters. You know who you are :) All kinds of comments welcome. Antoni Mylka ant...@gm... |
From: Antoni M. <ant...@gm...> - 2009-03-13 22:10:36
|
I did a mvn dependency:resolve on the current state of aperture-runtime-default. The dependencies found can be divided in three groups, libraries with osgi headers in their original repos commons-lang:commons-lang:jar:2.4:compile info.aduna.commons:aduna-commons-text:jar:2.3.0-SNAPSHOT:compile info.aduna.commons:aduna-commons-xml:jar:2.3.0-SNAPSHOT:compile org.osgi:osgi_R4_core:jar:1.0:provided org.semweb4j:rdf2go.api:jar:4.7.0:compile org.slf4j:jcl-over-slf4j:jar:1.5.6:runtime org.slf4j:slf4j-api:jar:1.5.6:compile libraries with osgi headers in orbit javax.mail:mail:jar:1.4.1:compile (only the 1.4.0 version) javax.activation:activation:jar:1.1.1:compile (only 1.1.0) commons-codec:commons-codec:jar:1.3:compile commons-io:commons-io:jar:1.3.2:compile commons-httpclient:commons-httpclient:jar:3.1:compile libraries with no osgi headers bouncycastle:bcmail-jdk14:jar:132:compile bouncycastle:bcprov-jdk14:jar:132:compile com.aetrion.flickr:flickrapi:jar:1.1:compile com.beetstra.jutf7:jutf7:jar:0.9.0:compile com.drewnoakes:metadata-extractor:jar:2.4.0-beta1:compile commons-compress:commons-compress:jar:20050911:compile net.fortuna.ical4j:ical4j:jar:1.0-rc2-SNAPSHOT:compile net.fortuna.ical4j:ical4j-vcard:jar:0.9.1-SNAPSHOT:compile net.fortuna.mstor:mstor:jar:0.9.11:compile net.sf.jacob-project:jacob:jar:1.14.3:compile org.apache.poi:poi:jar:3.2-FINAL:compile org.apache.poi:poi-scratchpad:jar:3.2-FINAL:compile org.fontbox:fontbox:jar:0.2.0:compile org.jempbox:jempbox:jar:0.2.0:compile pdfbox:pdfbox:jar:0.7.4:compile org.htmlparser:htmlparser:jar:1.6:compile org.jaudiotagger:jaudiotagger:jar:1.0.8:compile In order for the migration to succeed we need all of them in a maven repository. My best idea is to create an aperture maven repository, and deploy all those libraries as maven artifacts, with the -osgi suffix in the artifactId. We can automate it with ant scripts similar to this one: http://tinyurl.com/cvqcmb This is a task for a day or two, which will provide a quick-and-dirty solution. We can do it in the SF web space. In the long term we should submit patches to the maintainers of all libraries, that would make as many jars from the 3rd group jump to the 1st. Or to submit them to apache-felix-commons. What do you think? Antoni Myłka ant...@gm... Antoni Mylka pisze: > Hello, aperture-dev > > Just wanted you to know that all tests and examples have been migrated > to the new maven-based build. > > I'm beginning to look into proper migration of the osgi-based > integration test, to see how many of our dependencies we need to convert > to OSGI ourselves. > > Then we'll need to set up a release build. Don't know how to do it > (yet), but I'm sure there are people on this list who have much more > experience in these matters. You know who you are :) > > All kinds of comments welcome. > > Antoni Mylka > ant...@gm... > |
From: Herko t. H. <her...@ad...> - 2009-03-16 14:14:13
|
Hi Antoni, Good work on the tests and examples! > I did a mvn dependency:resolve on the current state of > aperture-runtime-default. The dependencies found can be divided in three > groups, > > libraries with osgi headers in their original repos > libraries with osgi headers in orbit > libraries with no osgi headers > In order for the migration to succeed we need all of them in a maven > repository. My best idea is to create an aperture maven repository, and > deploy all those libraries as maven artifacts, with the -osgi suffix in > the artifactId. We can automate it with ant scripts similar to this one: > > http://tinyurl.com/cvqcmb No more Ant scripts :) The Maven bundle plugin is able to do this as well (it uses bnd), in pretty much the same way we currently use it to build Aperture's own bundles. With regards to the -osgi suffix: I've used the -bundle suffix (classifier in Maven terminology) up till now... > This is a task for a day or two, which will provide a quick-and-dirty > solution. We can do it in the SF web space. In the long term we should > submit patches to the maintainers of all libraries, that would make as > many jars from the 3rd group jump to the 1st. Or to submit them to > apache-felix-commons. We could set this up in a separate branch, define modules for each of the jars in the 3rd group that use the Maven bundle plugin to add a proper manifest. Cheers, Herko |
From: Leo S. <leo...@df...> - 2009-03-17 15:23:14
|
It was Herko ter Horst who said at the right time 16.03.2009 15:13 the following words: >> This is a task for a day or two, which will provide a quick-and-dirty >> solution. We can do it in the SF web space. In the long term we should >> submit patches to the maintainers of all libraries, that would make as >> many jars from the 3rd group jump to the 1st. Or to submit them to >> apache-felix-commons. >> > > We could set this up in a separate branch, define modules for each of > the jars in the 3rd group that use the Maven bundle plugin to add a > proper manifest. > I wonder - why a branch? a maven repo is steady and not a branch, versioning is builtin in maven. putting them on the SF webspace should be fine. best Leo > Cheers, > > Herko > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Aperture-devel mailing list > Ape...@li... > https://lists.sourceforge.net/lists/listinfo/aperture-devel > -- ____________________________________________________ DI Leo Sauermann http://www.dfki.de/~sauermann Deutsches Forschungszentrum fuer Kuenstliche Intelligenz DFKI GmbH Trippstadter Strasse 122 P.O. Box 2080 Fon: +49 631 20575-116 D-67663 Kaiserslautern Fax: +49 631 20575-102 Germany Mail: leo...@df... Geschaeftsfuehrung: Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 ____________________________________________________ |
From: Antoni M. <ant...@gm...> - 2009-03-20 11:25:19
Attachments:
pom.xml
|
Herko ter Horst pisze: > > No more Ant scripts :) The Maven bundle plugin is able to do this as > well (it uses bnd), in pretty much the same way we currently use it to > build Aperture's own bundles. With regards to the -osgi suffix: I've > used the -bundle suffix (classifier in Maven terminology) up till now... > I've spent some time trying to figure out how to write a pom.xml that would be able to. 1. download the jar from orbit 1.5 (for those that need it) modify the manifest 2. install it in my local repo 3. deploy it to the given remote repo 4. with correct dependencies And failed, I guess using maven for this is not a good idea. I suggest 1. download the pom and modify by hand: - the version number of the artifact (e.g. to: 1.1.0.v200806101325_orbitS20090307012903) - versions of the dependencies (to osgi-enabled ones) 2. write a script that will - download the jar - modify the manifest - deploy it in the aperture repository It would be trivial in ruby, actually the first step could also be automated, just a simple method modify_version_number and voila, all in a single file. If no-one objects I will do it with ruby - a single script with simple declarations of what we need to do, one run and the entire aperture-maven repository in the aperture web space is ready. Attached are my efforts at convincing maven to do something like this. The best I could do is to generate a proper jar, without the classifiers. Antoni Mylka ant...@gm... |
From: Antoni M. <ant...@gm...> - 2009-03-26 23:38:58
|
Hello Aperturians, It's been a week since my last email and some of you may be wondering what I've been up to. Well, I've been trying to create osgi-enabled versions of all dependencies. I tried to do it with maven and failed (see my mail from 20.03.2009). The prospect of manual conversion seemed too scary, so I started hacking together some ruby code that does two things. 1. for orbit jars - downloads the jar - downloads a pom from repo1 - modifies that pom - changes the artifact version number, to the one from orbit - changes the versions of dependencies to use other ones from orbit - thus we're sure that the orbit jar is byte-by-byte identical to the one actualy posted on the eclipse.org website, even though the name has been chaged to fit within the maven conventions, 2. for maven jars - downloads the jar from repo1 (or other maven repository as needed) - downloads the pom - changes the pom as above - generates a simple .bnd file for use with the bnd tool - runs the bnd tool with the generated bnd jar - adds a bundle-info subfolder to the META-INF that contains detailed instructions how to recreate this jar (if someone wanted to fix some bug and/or repackage the jar) Then the script either installs the jars and poms to the local repository, or deploys them on our sourceforge server. I used following conventions - orbit jars have a version number from orbit with the _orbit suffix, to mark the fact that it is an orbit jar - normal jars, have the same version number as original, but with a .bundle suffix - appropriate version numbers are modified in poms, so that we can ensure that the entire dependency closure of aperture is osgi-aware - the bundle version in the manifest is usually independent from the artifact version in the pom.xml, especially for repo1 jars, e.g. bcmail version 132 becomes a 1.32.0 bundle etc. I don't use classifiers for external dependencies (e.g. commons-io-1.4-bundle.jar) because in many cases I need to modify the pom, and all artifacts with the same group/artifact/version have the same pom. In order to change the pom, i need to change the maven identity of the artifact (either group, or artifactid, or the version). Spring guys change the artifactId and leave the version intact [1], I chose to keep the artifactId intact, but to change the version (.bundle suffix). Though this is debatable. What do you think? The ruby scripts have the advantage, that if you don't like any of those conventions, I can change them in a single place and regenerate all jars and poms, instead of having to spend 3 days. And It will be easier to adapt, once the dependencies change. We will have to accept that anyone using aperture in a non-osgi application will either have to accept our OSGI-enabled dependencies or exclude them and supply their own, also for very common libs like commons-lang or commons-io. It's all about 80% complete. I intend to upload those jars to a new maven repo in the aperture SF web space by the end of the week. I have a minor problem with mstor. The newest version fixes an important issue, but introduces four additional dependencies we don't need or want, will have to work around that somehow. All kinds of comments welcome Antoni Mylka ant...@gm... [1] http://www.springsource.com/repository/app |
From: Christiaan F. <chr...@ad...> - 2009-03-27 08:19:08
|
Antoni Mylka wrote: > I have a minor problem with mstor. The newest version fixes an important > issue, but introduces four additional dependencies we don't need or > want, will have to work around that somehow. When defining a dependency, you can exclude particular transitive dependencies that it brings along. See e.g. http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management BTW: I noticed that the pdfbox.jar that we have at some point in time got renamed to pdfbox 0.7.4, whereas 0.7.4 is still not officially released. Is this a good idea? Even though the final 0.7.4 release will probably use a different groupId due to the move to Apache, it may still confuse some people. Regards, Chris -- |
From: Antoni M. <ant...@gm...> - 2009-03-27 10:27:47
|
Christiaan Fluit pisze: > Antoni Mylka wrote: >> I have a minor problem with mstor. The newest version fixes an important >> issue, but introduces four additional dependencies we don't need or >> want, will have to work around that somehow. > > When defining a dependency, you can exclude particular transitive > dependencies that it brings along. See e.g. > http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management I know, just that it doesn't work without them. Throws ClassNotFoundErrors. > BTW: I noticed that the pdfbox.jar that we have at some point in time > got renamed to pdfbox 0.7.4, whereas 0.7.4 is still not officially > released. Is this a good idea? Even though the final 0.7.4 release will > probably use a different groupId due to the move to Apache, it may still > confuse some people. If someone asks, it's the JBoss guys' idea, not ours :) Antoni MYlka ant...@gm... |
From: Antoni M. <ant...@gm...> - 2009-04-11 01:25:09
|
Herko ter Horst pisze: > Aperturians, I've managed to migrate the in-container osgi integration test to the new maven setup. It seems to pass. I've also committed a preliminary version of the aperture-sdk assembly. To see it 1. checkout the trunk 2. type mvn install 3. type mvn package assembly:assembly PLEASE TEST!!! and send any error messages you see. What is/should be in the assembly: The assembly contains one folder 'lib' with 4 subfolders 1. aperture-libs - the Aperture jars. 2. required-libs - CQ candidates 3. optional-libs - Sesame, the rdf2go driver, and slf4j-jdk14 4. aperture-supportlibs - tests, examples, nrlvalidator, maven plugins the sum of 1 and 2 and 3 yields a fully functional eclipse target platform, where all bundles start. What is not in the assembly 1. sources and javadocs 2. outlook dll's - OutlookCrawler probably doesn't work 3. applewrapper - mac-specific stuff probably doesn't work 4. sesame 2.3.0-SNAPSHOT does NOT have OSGI headers 5. onejar version of aperture - pretty easy Remarks: For some reason typing mvn assembly:assembly without 'package' doesn't work, fails with a cryptic error halfway down the road, any ideas? The current integration test is very brittle, it contains a hard-coded list of all bundles in the transitive dependency closure. We must make this list dynamic. Idea: make a separate integration-test module, let the dependency plugin dump the dependency closure to a file and let the unit test read it from that file I'd rather go the onejar way, prepare a single jar that would work in osgi and in plain jvms, CQ it. Make it fail gracefully when some dependency is missing (which will be the case in SMILA). The onejar would contain everything that's currently placed in the aperture-libs folder (that's why aperture-libs is a separate folder). Herko planned to make the 2.3.0 version of sesame osgi-aware, it seems that it's not. What's the plan for this? I haven't managed to get the javadoc plugin to produce an aggregated javadoc. Googled, copied the tutorial, typed 'mvn site' but maven halted halfway down the road, without any error message, just stopped responding. Ideas? All kinds of comments welcome. Antoni Mylka ant...@gm... |
From: Antoni M. <ant...@gm...> - 2009-04-17 14:49:33
|
Aperturians, Having spent some time on the intricacies of the Maven Assembly plugin, I've added the javadocs, a license and the README file to the assembly. The readme file might be interesting both for developers and users of Aperture. Right now the assembly takes 8 minutes (without tests) on my machine. It can be speeded up: 1. Modify the testcore and testdocs modules in a way described here: http://tinyurl.com/cgf79z 2. Divide all dependencies by SCOPE. Tweak them until all the required-jars are compile-scope, optional-jars are 'provided', which is the case actually. The user is supposed to provide their own logging implementation and rdf store implementation (theoretically). This will drastically reduce the number of inclusion/exclusion patterns in the assembly descriptor, which in turn will drastically speed up the build. All kinds of comments welcome. Antoni Mylka ant...@gm... Antoni Mylka pisze: > Herko ter Horst pisze: >> Aperturians, > > I've managed to migrate the in-container osgi integration test to the > new maven setup. It seems to pass. I've also committed a preliminary > version of the aperture-sdk assembly. To see it > > 1. checkout the trunk > 2. type mvn install > 3. type mvn package assembly:assembly > > PLEASE TEST!!! and send any error messages you see. > > What is/should be in the assembly: > > The assembly contains one folder 'lib' with 4 subfolders > 1. aperture-libs - the Aperture jars. > 2. required-libs - CQ candidates > 3. optional-libs - Sesame, the rdf2go driver, and slf4j-jdk14 > 4. aperture-supportlibs - tests, examples, nrlvalidator, maven plugins > the sum of 1 and 2 and 3 yields a fully functional eclipse target > platform, where all bundles start. > > What is not in the assembly > > 1. sources and javadocs > 2. outlook dll's - OutlookCrawler probably doesn't work > 3. applewrapper - mac-specific stuff probably doesn't work > 4. sesame 2.3.0-SNAPSHOT does NOT have OSGI headers > 5. onejar version of aperture - pretty easy > > Remarks: > > For some reason typing mvn assembly:assembly without 'package' doesn't > work, fails with a cryptic error halfway down the road, any ideas? > > The current integration test is very brittle, it contains a hard-coded > list of all bundles in the transitive dependency closure. We must make > this list dynamic. Idea: make a separate integration-test module, let > the dependency plugin dump the dependency closure to a file and let the > unit test read it from that file > > I'd rather go the onejar way, prepare a single jar that would work in > osgi and in plain jvms, CQ it. Make it fail gracefully when some > dependency is missing (which will be the case in SMILA). The onejar > would contain everything that's currently placed in the aperture-libs > folder (that's why aperture-libs is a separate folder). > > Herko planned to make the 2.3.0 version of sesame osgi-aware, it seems > that it's not. What's the plan for this? > > I haven't managed to get the javadoc plugin to produce an aggregated > javadoc. Googled, copied the tutorial, typed 'mvn site' but maven halted > halfway down the road, without any error message, just stopped > responding. Ideas? > > All kinds of comments welcome. > > Antoni Mylka > ant...@gm... > |
From: Arjohn K. <arj...@ad...> - 2009-04-20 09:42:46
|
Antoni Mylka wrote: [...] > For some reason typing mvn assembly:assembly without 'package' doesn't > work, fails with a cryptic error halfway down the road, any ideas? http://maven.apache.org/plugins/maven-assembly-plugin/faq.html#module-binaries [...] > Herko planned to make the 2.3.0 version of sesame osgi-aware, it seems > that it's not. What's the plan for this? He did make some changes to pom's en created some additional modules. I'm not sure what if this work was finished though. If someone can indicate what the problem is, or even supply a patch then I'd be willing to make the necessary changes to the code. -- Arjohn Kampman, Senior Software Engineer Aduna - Semantic Power www.aduna-software.com |
From: Antoni M. <ant...@gm...> - 2009-04-23 15:16:04
|
2009/4/20 Arjohn Kampman <arj...@ad...>: > Antoni Mylka wrote: > [...] >> >> For some reason typing mvn assembly:assembly without 'package' doesn't >> work, fails with a cryptic error halfway down the road, any ideas? > > http://maven.apache.org/plugins/maven-assembly-plugin/faq.html#module-binaries I understand the reasoning behind that FAQ entry. What I don't understand is why mvn install mvn assembly:assembly doesn't work. -- Antoni Myłka ant...@gm... |