Hi,
I looked at it, and you can specify what packages you want to export,
along with the
added info.
Adding this to the build part of the pom should take care of it:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<configuration>
<instructions>
<Import-Package>
javax.faces.context;resolution:=optional,
javax.servlet;resolution:=optional,
javax.servlet.jsp;resolution:=optional,
javax.servlet.jsp.el;resolution:=optional,
javax.xml.parsers;resolution:=optional,
javax.xml.transform;resolution:=optional,
javax.xml.transform.dom;resolution:=optional,
javax.xml.transform.stream;resolution:=optional,
org.apache.commons.digester,
org.apache.commons.el;resolution:=optional,
org.apache.commons.jexl;resolution:=optional,
org.apache.commons.logging,
org.apache.xml.utils;resolution:=optional,
org.apache.xpath;resolution:=optional,
org.apache.xpath.objects;resolution:=optional,
org.w3c.dom;resolution:=optional,
org.xml.sax;resolution:=optional
</Import-Package>
</instructions>
</configuration>
</plugin>
I tried that, and deploying that with just
commons.loggin/digester/beanutils seems to be working fine.
BTW, I just noticed that there isn't any import for beanutils in the
manifest generated, but it's listed as a
mandatory dependency. commons.digester have a deploy dependency on
beanutils though I think.
Cheers,
Niklas
On 11/18/2010 2:07 PM, Rahul Akolkar wrote:
On Wed, Nov 17, 2010 at 7:45 PM, niklas modin<[email protected]> wrote:
Hi again,
Looked into it a little bit more, and there is indeed a way to note import
packages as optional,
but it seems like this isn't set properly in the manifest file.
Not sure if there is an issue with the maven assembly plugin, or if there is
a way to instruct it to
include the "resolution:=optional" parameter in the manifest file.
<snip/>
The manifest entries are generated by the maven bundle plugin [1].
I haven't checked, but it would be worthwhile to see if the plugin has
more intelligence about optional dependencies today than it did when
the last Commons SCXML release was cut.
If not, we can also look at hard-coding the appropriate OSGi related
manifest entries via following properties defined in the parent pom
[2]:
<Export-Package>${commons.osgi.export}</Export-Package>
<Private-Package>${commons.osgi.private}</Private-Package>
<Import-Package>${commons.osgi.import}</Import-Package>
<DynamicImport-Package>${commons.osgi.dynamicImport}</DynamicImport-Package>
I'll take a look when I get a chance. If you'd like to suggest
improvements (or want to track this), feel free to open an issue (with
an appropriate patch, if available) to JIRA [3].
-Rahul
[1] http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
[2] http://svn.apache.org/repos/asf/commons/proper/commons-parent/trunk/pom.xml
[3] http://commons.apache.org/scxml/issue-tracking.html
/Niklas
On 11/17/2010 9:46 AM, niklas modin wrote:
Hi,
Looking at the manifest for scxml, it seems like all optional maven
dependencies along
with the required ones, all gets translated into an entry under the
Import-Package: part.
AFAIK, I don't think there is a notion for optional dependency injection
in OSGi, so I guess
that means that all dependencies are in fact required for an OSGi
deployment.
Not sure how to proceed here, but seems that also deploying JSF and all
transitive
dependencies is what I need to do.
Another quick Q:
Are there any plans for a 0.10 release ?
Thanks,
Niklas
On 11/16/2010 2:23 PM, Rahul Akolkar wrote:
On Tue, Nov 16, 2010 at 4:53 PM, niklas modin<[email protected]>
wrote:
Hi,
I'm trying to get SC XML up and running in an equinox OSGi environment,
and
I'm having some dependencies issues.
What's the reason for having a dependency to myfaces-api ? This isn't a
big
issue per say I guess, but it just seems
like that drag's in a lot of dependencies, and can't really see what JSF
is
used for.
<snip/>
You are indeed correct that most applications that use Commons SCXML
may be unrelated to JSF (and some of the other optional dependencies
as well).
Commons SCXML has three required dependencies, which are listed at the
top of this page:
http://commons.apache.org/scxml/dependencies.html
Note that the others are optional. In addition, the JSF API is meant
to be "provided" (by the environment).
If the OSGi related headers in the release jar file don't reflect this
correctly, then they should.
-Rahul
Cheers,
Niklas
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
