Don't do it manually. That's just bad, bad, bad. Have it generated by the Gradle script instead. Once you have the classpath generated within the Gradle script, you can move that code into a plugin very easily. I'm more than happy to help you out on that point, but better you do it than me, because you're getting paid for this work whereas it will be sucking up my free time (and will have to wait until after I get more confidence in my Maven Proxy and OneJar plugins).
~~ Robert. On 11 October 2010 14:09, Alessandro Novarini <[email protected]>wrote: > I would be more than happy if I could install that project and make it > work. > So for now I'll write the classpath manually, but I guess this won't > convince the devs in my company to get rid of that bunch of useless xml ( > but I'll keep trying ) > > Thank you > Ale > -- > > > Robert Fischer <[email protected]> kirjoitti 11.10.2010 > kello 19.22: > > You'll have to write the classpath stuff manually, although that's not a > bad idea for a plugin to provide (stay tuned...). What else, specifically, > are you looking to add into your Manifest file? > > ~~ Robert. > > On 11 October 2010 12:01, Alessandro Novarini <<[email protected]> > [email protected]> wrote: > >> Yes, the package was meant to be just an osgi bundle, there is no way >> to run it as a stand-alone app anyway. >> I'll try to follow your advice for the dependency issue. >> >> When I run gradle assemble I get the following manifest: >> >> Manifest-Version: 1.0 >> Export-Package: >> com.acme.prj;uses:="org.apache.commons.digester,javax.xml.parsers, >> org.w3c.dom.ls,org.w3c.dom,org.w3c.dom.bootstrap";version="2.3" >> Private-Package: org.apache.commons.* >> Tool: Bnd-0.0.384 >> Bundle-Name: overwrittenSpecialOsgiName >> Created-By: 1.6.0_20 (Apple Inc.) >> Bundle-Version: 2.3 >> Bnd-LastModified: 1286812061592 >> Embed-Transitive: true >> Bundle-ManifestVersion: 2 >> Import-Package: >> >> com.acme.prj;version="2.3",javax.xml.parsers,org.apache.commons.digester;version="2.1",org.w3c.dom,org.w3c.dom.bootstrap, >> org.w3c.dom.ls >> Bundle-SymbolicName: .something >> Embed-Dependency: commons-*;scope=compile|runtime >> >> Some differences are found in the values related to each package >> instruction, and there's no dependency jar included in the final >> package, of course. >> You've caught a good point noticing that there's no Bundle-ClassPath >> instruction; is it something I have to write explicitly in the plugin >> configuration or it's supposed to exist because the dependencies? >> >> Thank you very much for you time and consideration >> Ale >> >> On Mon, Oct 11, 2010 at 5:40 PM, Robert Fischer >> < <[email protected]>[email protected]> >> wrote: >> > The reason the jar-in-jar thing works is because it's specified using >> > Bundle-ClassPath: that works just for the JAR being run as an OSGi >> bundle, >> > and won't help you if you execute the JAR directly or from outside of >> OSGi. >> > I'd suggest adding the dependencies from the configuration into the jar >> > task's "from" properties, although that might you get you into >> > resolution-time issues. >> > What is failing to happen with that configuration? It looks like it'd >> work >> > for me. >> > >> > ~~ Robert. >> > >> > On 11 October 2010 11:34, Alessandro Novarini <<[email protected]> >> [email protected]> >> > wrote: >> >> >> >> Thank you for your reply. >> >> >> >> I'll try to explain better my purpose here, my fault in the previous >> >> mail, sorry: >> >> >> >> I have a java project built using maven; this project is an osgi >> >> bundle, and it's built using maven-bundle-plugin, which in turn uses >> >> bnd like osgi plugin for gradle. >> >> >> >> What I would like to do is to create a package with gradle that's the >> >> exact copy of the one generated using maven. >> >> >> >> The manifest created by maven is the following: >> >> >> >> Manifest-Version: 1.0 >> >> Export-Package: >> >> >> >> com.acme.prj;uses:="org.w3c.dom.ls >> ,javax.xml.parsers,org.w3c.dom,org.w3c.dom.bootstrap";version="0.0.1" >> >> Private-Package: >> >> >> >> >> org.apache.commons.beanutils,org.apache.commons.beanutils.converters,org.apache.commons.beanutils.expression,org.apache.commons.beanutils.locale,org.apache.commons.beanutils.locale.converters,org.apache.commons.collections,org.apache.commons.digester,org.apache.commons.digester.parser,org.apache.commons.digester.plugins,org.apache.commons.digester.plugins.strategies,org.apache.commons.digester.substitution,org.apache.commons.digester.xmlrules,org.apache.commons.logging,org.apache.commons.logging.impl >> >> Ignore-Package: org.apache.log,org.apache.avalon.framework.logger >> >> Bundle-ClassPath: >> >> >> >> >> .,commons-beanutils-1.8.0.jar,commons-digester-2.0.jar,commons-logging-1.1.1.jar >> >> Built-By: me >> >> Tool: Bnd-0.0.255 >> >> Bundle-Name: acme - useless project >> >> Created-By: Apache Maven Bundle Plugin >> >> Build-Jdk: 1.6.0_20 >> >> Bundle-Version: 0.0.1 >> >> Bnd-LastModified: 1286810196596 >> >> Embed-Transitive: true >> >> Bundle-ManifestVersion: 2 >> >> Embed-Dependency: commons-*;scope=compile|runtime >> >> Import-Package: >> >> >> >> >> com.acme.prj;version="0.0.1",javax.servlet,javax.xml.parsers,javax.xml.validation,org.apache.commons.collections.comparators,org.apache.commons.collections.keyvalue,org.apache.commons.collections.list,org.apache.commons.collections.set,org.apache.log4j,org.w3c.dom,org.w3c.dom.bootstrap, >> org.w3c.dom.ls,org.xml.sax,org.xml.sax.helpers >> >> Bundle-SymbolicName: com.acme.prj >> >> >> >> The configuration in the pom.xml is the following: >> >> <configuration> >> >> <instructions> >> >> >> <Export-Package>com.acme.prj.*;version=${pom.version}</Export-Package> >> >> >> >> >> >> <Import-Package>!org.apache.log|org.apache.avalon.framework.logger,*</Import-Package> >> >> <Embed-Dependency>commons-*;scope=compile|runtime</Embed-Dependency> >> >> <Embed-Transitive>true</Embed-Transitive> >> >> </instructions> >> >> </configuration> >> >> >> >> The critical parts to me, because I can't figure out how I can >> >> reproduce them with gradle, are the Import,Export and Private Package >> >> and the Embed-Dependency. Taking and copying them 'as is' doesn't >> >> work; here my last attempt: >> >> >> >> jar { >> >> manifest { >> >> version = 2.3 >> >> name = 'overwrittenSpecialOsgiName' >> >> instruction 'Embed-Dependency', >> 'commons-*;scope=compile|runtime' >> >> instruction 'Private-Package', 'org.apache.commons.*' >> >> instruction 'Export-Package', "com.acme.prj.*;version=$version" >> >> instruction 'Import-Package', >> >> '!org.apache.log|org.apache.avalon.framework.logger,*' >> >> instruction 'Embed-Transitive', 'true' >> >> } >> >> } >> >> >> >> The jar inside the jar thing, well, I really don't know why it was >> >> done in that way, but for sure it works, and honestly I can't think >> >> another way to put a dependency that's not shared among all bundles in >> >> a different way. >> >> >> >> I apologize for this - too - long email, I hope you don't get bored >> >> while reading, but I don't have a clue at the moment. >> >> >> >> Thanks again for the kind support >> >> Ale >> >> >> >> On Mon, Oct 11, 2010 at 4:37 PM, Robert Fischer >> >> < <[email protected]>[email protected]> >> wrote: >> >> > If you already have a Manifest file generated, you're going to have >> to >> >> > configure the jar task's manifest file given the existing one. I'm >> not >> >> > entirely sure about the best way to do that. >> >> > What's your purpose in including the Apache-Commons JAR file within >> your >> >> > generated JAR? You can, of course, add the JAR file itself into your >> >> > JAR by >> >> > adding the JAR into the resources source set, but unless I'm >> mistaken, >> >> > the >> >> > classloader won't know how to load classes from that internal JAR. >> >> > The other option is to create a fat jar by merging the other jar and >> >> > your >> >> > generated jar. That can cause problems with licensing, if you're not >> >> > careful. >> >> > >> >> > ~~ Robert. >> >> > >> >> > On 8 October 2010 15:33, Alessandro Novarini >> >> > < <[email protected]>[email protected]> >> >> > wrote: >> >> >> >> >> >> Hi all, >> >> >> Reading both gradle and bnd documentation didn't help me to find >> >> >> answers to the following questions, I hope you can turn the light on >> >> >> and make me see the truth on the OSGI plugin: >> >> >> >> >> >> Instructing properly the plugin >> >> >> The gradle documentation says: "The classes in the classes dir are >> >> >> analyzed regarding there package dependencies and the packages they >> >> >> expose. Based on this the Import-Package and the Export-Package >> values >> >> >> of the OSGi Manifest are calculated." >> >> >> >> >> >> I can't understand what I have to do in this situation, because >> >> >> neither Import-Package nor Export-Package instructions are included >> in >> >> >> the generated manifest file. >> >> >> So, how does the plugin know which are the packages to be imported >> and >> >> >> which are the ones to export? >> >> >> >> >> >> Private Package instruction >> >> >> In the example 26.2 of the gradle documentation the instruction >> >> >> 'Private-Package" has a list of packages explicitly written. >> >> >> In my example I want to make private the package >> org.apache.commons.*, >> >> >> so that in the manifest file I'll see org.apache.commons.beanutils, >> >> >> org.apache.commons.beanutils.converters etc. etc. >> >> >> The wildcard * doesn't expand the package list, all I see in the >> >> >> manifest is the string org.apache.commons.*. Is there a way to >> achieve >> >> >> this goal? >> >> >> >> >> >> Including dependencies >> >> >> Continuing with the example above, is there a way to include the jar >> >> >> of apache-commons in my jar using some feature of the plugin? Or >> >> >> should I add in some way scripting my build? >> >> >> >> >> >> All these questions came out because I already have a manifest file >> of >> >> >> this project generated by the maven plugin (that uses bnd as well), >> >> >> and I would like to reproduce the exact output using gradle, but I'm >> >> >> far from the expected. >> >> >> >> >> >> Thank you in advance >> >> >> Ale >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> To unsubscribe from this list, please visit: >> >> >> >> >> >> <http://xircles.codehaus.org/manage_email> >> http://xircles.codehaus.org/manage_email >> >> >> >> >> >> >> >> > >> >> > >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe from this list, please visit: >> >> >> >> <http://xircles.codehaus.org/manage_email> >> http://xircles.codehaus.org/manage_email >> >> >> >> >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> <http://xircles.codehaus.org/manage_email> >> http://xircles.codehaus.org/manage_email >> >> >> >
