Good point. In this case would we just export
org.apache.geronimo.mail.handlers.* in addition to javax.*?
Regards,
Alan
On Oct 19, 2007, at 5:03 PM, Dain Sundstrom wrote:
I'm not sure that would work for javamail. Javamail has a strange
discovery system where implementation of
I need to check, but my assumtion was that these classes from the
javamail bundle and not from other bundles. I will try next week and
fix the problem if any.
On 10/20/07, Dain Sundstrom [EMAIL PROTECTED] wrote:
I'm not sure that would work for javamail. Javamail has a strange
discovery
The bundle plugin may also put classes from dependencies inside the
bundle. If you put everything private, it will include all the
classes from the first level dependencies iirc.
On 10/19/07, Alan D. Cabrera [EMAIL PROTECTED] wrote:
Why not just have this in the root pom
Why not just have this in the root pom
geronimo.osgi.import.pkg*/geronimo.osgi.import.pkg
geronimo.osgi.export.pkgjavax.*/
geronimo.osgi.export.pkg
geronimo.osgi.private.pkg*/geronimo.osgi.private.pkg
Then the modules' pom would be more simple because we
I'm not sure that would work for javamail. Javamail has a strange
discovery system where implementation of protocols, such as smtp, are
loaded directly from the application class loader. I believe that if
you hide the geronimo protocol implementations, javamail won't work.
-dain
On Oct
The second option would still include the classes inside the jar. The
only difference is that these classes would be hidden when inside an
OSGi environment, while the javax.* classes would be visible. In a
non-OSGi env, everything would be visible.
I've just committed a fix and the classes are
So the question is wether these classes are meant to be seen by other
jars or if they are only used by the javax.mail package. If they are
to be exported, then it should be
geronimo.osgi.export.pkgjavax.mail*,org.apache.geronimo.mail*/geronimo.osgi.export.pkg
but if they should be of
Did you compiled from trunk ? or just the activation spec tree ?
You need a recent version of the parent pom which declares the bundle
maven plugin.
On 9/24/07, Rick McGuire [EMAIL PROTECTED] wrote:
I'm getting an error trying to build the javamail specs now, which
appears related to the OSGI
Can this be added to the existing Maven2 spec builds?
Is there a maven plugin for generating OSGi bundles?
Yes there is. We developed one over at Felix. It has been released
too. Have a look at:
http://felix.apache.org/site/maven-bundle-plugin-bnd.html
The plugin makes it easy to create jars
On 9/21/07, Donald Woods [EMAIL PROTECTED] wrote:
Okay, was just looking for more details. Wasn't trying to shoot you down...
:-)
So, you're not going as far as proposing real OSGi/Eclipse bundles, where we
control which classes/methods are exported for others to use
It is a real OSGi
I've jist attached a patch to
https://issues.apache.org/jira/browse/GERONIMO-3482 to show what it
would look like. Of course we need to bring all specs from the tags
to the trunk and OSGify them, but it's usually just a matter of
changing the packaging to packagingbundle/packaging.
On 9/21/07,
On 9/21/07, Guillaume Nodet [EMAIL PROTECTED] wrote:
I've jist attached a patch to
https://issues.apache.org/jira/browse/GERONIMO-3482 to show what it
would look like. Of course we need to bring all specs from the tags
to the trunk and OSGify them, but it's usually just a matter of
changing
+1
On Sep 20, 2007, at 6:40 PM, Guillaume Nodet wrote:
For ServiceMix 4.0, which will be based on OSGi, I will need to have
OSGified versions of some of the spec jars that geronimo provides.
It's quite easy to do in ServiceMix (see
http://svn.apache.org/repos/asf/incubator/servicemix/branches/
So I have something more consistent, but I can really put it as a
patch as it involves copying from tags to trunk, so I guess I'll just
commit it for review.
The only problem I have comes from the commonj spec: the package is
java.commonj and it seems the felix plugin does not really like java.*
So I have something more consistent, but I can really put it as a
patch as it involves copying from tags to trunk, so I guess I'll just
commit it for review.
The only problem I have comes from the commonj spec: the package is
java.commonj and it seems the felix plugin does not really like
I guess given that no framework support it and that nobody uses this
jar yet, I will just defer ;-)
Many thanks for this explanation.
On 9/21/07, Karl Pauls [EMAIL PROTECTED] wrote:
So I have something more consistent, but I can really put it as a
patch as it involves copying from tags to
So I've just commited a patch for everybody to review.
I have tested some of the bundles inside servicemix 4.0, so at least
i'm confident it won't break servicemix ;-)
Seriously, they seem to be ok, though i had to limit the exported
package from stax-api to javax.xml.stream* to not clash with
On Sep 21, 2007, at 9:08 AM, Guillaume Nodet wrote:
I guess given that no framework support it and that nobody uses this
jar yet, I will just defer ;-)
Many thanks for this explanation.
There isn't a current release of the commonj spec. We only released
commonj when we released all specs
On 9/21/07, Guillaume Nodet [EMAIL PROTECTED] wrote:
I guess given that no framework support it and that nobody uses this
jar yet, I will just defer ;-)
Makes sense, although it might not be too hard to split it up in two
different jars and turn it into an extension bundle - might give use a
For the specs, there are generally 2 version identifiers. The first
level is the implementation level the spec is supposed to be at. For
example, javamail 1.4 or javamail 1.3.1. The second is the Geronimo
release version of that specification. For example, the javamail 1.4
spec in trunk is
On 9/21/07, Guillaume Nodet [EMAIL PROTECTED] wrote:
Yeah, good point.
I've managed to somehow include both versions in the manifest.
The specification version (javamail 1.4) goes into the package version
for OSGi, whereas the maven version (1.2-SNAPSHOT) goes into the
Bundle-Version manifest
Yeah, good point.
I've managed to somehow include both versions in the manifest.
The specification version (javamail 1.4) goes into the package version
for OSGi, whereas the maven version (1.2-SNAPSHOT) goes into the
Bundle-Version manifest entry.
I suppose this is the right way to deal with that,
Well, I previously used an OSGified bundle of stax-api that only
contained java.xml.stream packages. The geronimo one contains other
classes in javax.xml* packages, so I've first tried to export all
these packages from the bundle. When I did that, I end up with the
following exception in my
On 9/21/07, Guillaume Nodet [EMAIL PROTECTED] wrote:
So I've just commited a patch for everybody to review.
I have tested some of the bundles inside servicemix 4.0, so at least
i'm confident it won't break servicemix ;-)
Seriously, they seem to be ok, though i had to limit the exported
For ServiceMix 4.0, which will be based on OSGi, I will need to have
OSGified versions of some of the spec jars that geronimo provides.
It's quite easy to do in ServiceMix (see
http://svn.apache.org/repos/asf/incubator/servicemix/branches/servicemix-4.0/bundles/
for servlet, j2ee-management, jms
Wait, wait
I'm just talking about making the needed changes to add the manifest
entries so that the current jars can be recognized as valid OSGi
bundles. This can be easily done using the felix maven plugin. The
jars would be a minor update of the existing ones and would be
published to the
Okay, was just looking for more details. Wasn't trying to shoot you down... :-)
So, you're not going as far as proposing real OSGi/Eclipse bundles, where we
control which classes/methods are exported for others to use
Sounds like a good start, as long as we can include the required bits
On Sep 20, 2007, at 10:31 PM, Donald Woods wrote:
Okay, was just looking for more details. Wasn't trying to shoot
you down... :-)
So, you're not going as far as proposing real OSGi/Eclipse bundles,
where we control which classes/methods are exported for others to
use
From
28 matches
Mail list logo
