You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Rajini Sivaram <ra...@googlemail.com> on 2007/11/07 16:45:34 UTC
OSGi-based Tuscany runtime
Hello,
https://issues.apache.org/jira/browse/TUSCANY-1897 creates a set of bundles
to enable Tuscany to be run inside an OSGi runtime. At the moment, there are
five bundles:
1. org.apache.tuscany.sca.api.jar 18,701
2. org.apache.tuscany.spi.jar 430,563
3. org.apache.tuscany.runtime.jar 538,660
4. org.apache.tuscany.extensions.jar 1,374,045
5. org.apache.tuscany.depends.jar 57,872,558
I would like to split the 3rd party bundle first and then possibly the
Tuscany extensions bundle. Ideally I would like to have bundles which match
the jar files provided in "distribution" so that OSGi manifest headers can
be added to the jars in "distribution" enabling a binary Tuscany
distribution to be run under OSGi.
I would like to satisfy as many of Sebastien's use cases (
http://marc.info/?l=tuscany-dev&m=119326781123561&w=2) as possible. But I am
not sure what the granularity of the bundles should be if we want to have
the same set of jars for both an OSGi and non-OSGi distribution. More fine
grained jars provide better versioning under OSGi, but requires the
maintenance of more package dependencies in the manifest files. Would it be
better to group related 3rd party jars together (eg. all Axis2 related jars
into one bundle) where each jar belongs to one and only one bundle?
Any thoughts on what the Tuscany distribution should look like (should it
continue to be the current list of jars, or should related jars be grouped
together), and on the granularity required for versioning when running
Tuscany under OSGi are appreciated.
Ant,
Would it be possible for you to provide a list of third party jars used by
each extension? Since maven dependencies in the extension/pom.xml include
the dependencies for testing (sometimes without a scope), I am not sure if I
could use a dependency list generated by maven.
Thank you...
Regards,
Rajini
On 10/25/07, ant elder <an...@gmail.com> wrote:
>
> On 10/25/07, Rajini Sivaram <ra...@googlemail.com> wrote:
>
> <snip>
>
> This does imply splitting both Tuscany extension bundle
> > and the big 3rd party bundle, into smaller chunks. Because of its size,
> I
> > am
> > more inclined to split the 3rd party bundle into smaller bundles first
> > (though I have no idea where to start with this huge big list of jar
> > files).
>
>
> I can help with that, after doing lots of releases i've a good
> understanding
> of what each jar is for and what uses it. How about starting with whatever
> bundle make up is easiest for you and then we can juggle things around to
> get to something everyone is happy with.
>
> ...ant
>
Re: OSGi-based Tuscany runtime
Posted by Simon Laws <si...@googlemail.com>.
Hi Rajini
By "due to multiple versions of the files" do you mean multiple different
version numbers? Is this reflected accurately in the report that I posted
previously in this thread. If so maybe that is a way into this, i.e. lets
try and rationalize the multiple version issue that Ant point out. It seems,
from his previous reply, that he has been doing the manually to date. It may
be that we can't do anything about some of the transitive dependencies but
we may be able to upgrade and get rid of some of them.
Regards
Simon
On Nov 12, 2007 1:12 PM, Rajini Sivaram <ra...@googlemail.com>
wrote:
> I was under the impression that maven generated a minimal list of
> dependent
> jar versions using copy-dependencies, and I assumed that Tuscany used this
> in some form to generate the minimal set (with the highest versions). I
> was
> trying to use maven-bundle-plugin to generate bundles out of the
> dependencies, and ended up with 90 more jar files than those copied by
> copy-dependencies, and most of these seem to be due to multiple versions
> of
> the files. A manual approach to sorting out third party versions will add
> a
> lot of work to bundle-ized Tuscany, for transitive dependencies within
> third
> party bundles, since package versions of export/import package
> statements will have to be manually edited in the manifest files.
>
>
> Thank you...
>
> Regards,
>
> Rajini
>
>
> On 11/12/07, ant elder <an...@apache.org> wrote:
> >
> > On Nov 12, 2007 12:15 PM, Simon Laws <si...@googlemail.com> wrote:
> >
> > > On Nov 12, 2007 11:58 AM, ant elder <an...@gmail.com> wrote:
> > >
> > > > On Nov 12, 2007 11:42 AM, Simon Laws <si...@googlemail.com>
> > wrote:
> > > >
> > > > > On Nov 8, 2007 10:56 AM, Rajini Sivaram <
> > rajinisivaram@googlemail.com>
> > > > > wrote:
> > > > >
> > > > > > Simon,
> > > > > >
> > > > > > Thank you. Yes, I would really appreciate your help in sorting
> out
> > > the
> > > > > > poms.
> > > > > >
> > > > > >
> > > > > > Thank you...
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Rajini
> > > > > >
> > > > > >
> > > > > > On 11/8/07, Simon Laws <si...@googlemail.com> wrote:
> > > > > > >
> > > > > > > Hi Rajini
> > > > > > >
> > > > > > > I'd forgotten about project-info-reports. Thanks for reminding
> > > me!.
> > > > I
> > > > > > > think
> > > > > > > the answer here is for us to get our poms right so that all
> > > > > dependencies
> > > > > > > have the correct scope. I'm happy to help out here. It's easy
> > > enough
> > > > > to
> > > > > > > work
> > > > > > > out which are compile time dependencies but it's note clear
> > that
> > > we
> > > > > are
> > > > > > > marking runtime/test dependencies accurately. I don't think
> > there
> > > is
> > > > > an
> > > > > > > automatic way of distinguishing.
> > > > > > >
> > > > > > > Simon
> > > > > > >
> > > > > > > On 11/8/07, Rajini Sivaram <ra...@googlemail.com>
> wrote:
> > > > > > > >
> > > > > > > > Simon,
> > > > > > > >
> > > > > > > > maven-bundle-plugin can be used to generate manifest files
> for
> > > the
> > > > > jar
> > > > > > > > files, but the recommended practice is to explicitly specify
> > the
> > > > > > > exported
> > > > > > > > packages rather than export everything from the jar. I tried
> > to
> > > > use
> > > > > > this
> > > > > > > > to
> > > > > > > > generate manifest files for all the third party jars
> > separately,
> > > > but
> > > > > I
> > > > > > > > couldn't get these jars to install and resolve under Felix.
> So
> > > at
> > > > > the
> > > > > > > > moment, there is a single large third party jar with
> hardcoded
> > > > > > > > export-packages. Once the bundles are finalized, I will try
> > and
> > > > use
> > > > > > > > maven-bundle-plugin to generate as much of the manifest as
> > > > possible.
> > > > > > > >
> > > > > > > > Most of the 3rd party jars do not have OSGi manifest headers
> (
> > a
> > > > few
> > > > > > > like
> > > > > > > > SDO do). I will try and use existing headers wherever they
> are
> > > > > > available
> > > > > > > > (again, I will try to do this after the bundles are
> > finalized).
> > > > > > > >
> > > > > > > > I had a look at the dependency graph generated by "mvn
> > > > > > > > project-info-reports:dependencies", and the dependency tree
> > > format
> > > > > > looks
> > > > > > > > much more usable to generate a full visual graph of the
> > > > > dependencies,
> > > > > > > > compared to a flat classpath. My only concern is that many
> of
> > > the
> > > > > test
> > > > > > > > dependencies in the modules are not marked with scope test
> and
> > > > would
> > > > > > > > probably result in unnecessary dependencies (and I am not
> sure
> > > > which
> > > > > > > > dependencies I can safely remove).
> > > > > > > >
> > > > > > > > Thank you...
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > >
> > > > > > > > Rajini
> > > > > > > >
> > > > > > > > On 11/7/07, Simon Laws <si...@googlemail.com> wrote:
> > > > > > > > >
> > > > > > > > > On 11/7/07, Rajini Sivaram <ra...@googlemail.com>
> > > wrote:
> > > > > > > > > >
> > > > > > > > > > Hello,
> > > > > > > > > >
> > > > > > > > > > https://issues.apache.org/jira/browse/TUSCANY-1897creates
> > a
> > > > set
> > > > > > of
> > > > > > > > > > bundles
> > > > > > > > > > to enable Tuscany to be run inside an OSGi runtime. At
> the
> > > > > moment,
> > > > > > > > there
> > > > > > > > > > are
> > > > > > > > > > five bundles:
> > > > > > > > > >
> > > > > > > > > > 1. org.apache.tuscany.sca.api.jar 18,701
> > > > > > > > > > 2. org.apache.tuscany.spi.jar
> 430,563
> > > > > > > > > > 3. org.apache.tuscany.runtime.jar 538,660
> > > > > > > > > > 4. org.apache.tuscany.extensions.jar 1,374,045
> > > > > > > > > > 5. org.apache.tuscany.depends.jar 57,872,558
> > > > > > > > > >
> > > > > > > > > > I would like to split the 3rd party bundle first and
> then
> > > > > possibly
> > > > > > > the
> > > > > > > > > > Tuscany extensions bundle. Ideally I would like to have
> > > > bundles
> > > > > > > which
> > > > > > > > > > match
> > > > > > > > > > the jar files provided in "distribution" so that OSGi
> > > manifest
> > > > > > > headers
> > > > > > > > > can
> > > > > > > > > > be added to the jars in "distribution" enabling a binary
> > > > Tuscany
> > > > > > > > > > distribution to be run under OSGi.
> > > > > > > > > >
> > > > > > > > > > I would like to satisfy as many of Sebastien's use
> cases
> > (
> > > > > > > > > > http://marc.info/?l=tuscany-dev&m=119326781123561&w=2)
> as
> > > > > > possible.
> > > > > > > > But
> > > > > > > > > I
> > > > > > > > > > am
> > > > > > > > > > not sure what the granularity of the bundles should be
> if
> > we
> > > > > want
> > > > > > to
> > > > > > > > > have
> > > > > > > > > > the same set of jars for both an OSGi and non-OSGi
> > > > distribution.
> > > > > > > More
> > > > > > > > > fine
> > > > > > > > > > grained jars provide better versioning under OSGi, but
> > > > requires
> > > > > > the
> > > > > > > > > > maintenance of more package dependencies in the manifest
> > > > files.
> > > > > > > Would
> > > > > > > > it
> > > > > > > > > > be
> > > > > > > > > > better to group related 3rd party jars together (eg. all
> > > Axis2
> > > > > > > related
> > > > > > > > > > jars
> > > > > > > > > > into one bundle) where each jar belongs to one and only
> > one
> > > > > > bundle?
> > > > > > > > > >
> > > > > > > > > > Any thoughts on what the Tuscany distribution should
> look
> > > like
> > > > > > > (should
> > > > > > > > > it
> > > > > > > > > > continue to be the current list of jars, or should
> related
> > > > jars
> > > > > be
> > > > > > > > > grouped
> > > > > > > > > > together), and on the granularity required for
> versioning
> > > when
> > > > > > > running
> > > > > > > > > > Tuscany under OSGi are appreciated.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Ant,
> > > > > > > > > >
> > > > > > > > > > Would it be possible for you to provide a list of third
> > > party
> > > > > jars
> > > > > > > > used
> > > > > > > > > by
> > > > > > > > > > each extension? Since maven dependencies in the
> > > > > extension/pom.xml
> > > > > > > > > include
> > > > > > > > > > the dependencies for testing (sometimes without a
> scope),
> > I
> > > am
> > > > > not
> > > > > > > > sure
> > > > > > > > > if
> > > > > > > > > > I
> > > > > > > > > > could use a dependency list generated by maven.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Thank you...
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > >
> > > > > > > > > > Rajini
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On 10/25/07, ant elder <an...@gmail.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On 10/25/07, Rajini Sivaram <
> > rajinisivaram@googlemail.com>
> > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > <snip>
> > > > > > > > > > >
> > > > > > > > > > > This does imply splitting both Tuscany extension
> bundle
> > > > > > > > > > > > and the big 3rd party bundle, into smaller chunks.
> > > Because
> > > > > of
> > > > > > > its
> > > > > > > > > > size,
> > > > > > > > > > > I
> > > > > > > > > > > > am
> > > > > > > > > > > > more inclined to split the 3rd party bundle into
> > smaller
> > > > > > bundles
> > > > > > > > > first
> > > > > > > > > > > > (though I have no idea where to start with this huge
> > big
> > > > > list
> > > > > > of
> > > > > > > > jar
> > > > > > > > > > > > files).
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I can help with that, after doing lots of releases
> i've
> > a
> > > > good
> > > > > > > > > > > understanding
> > > > > > > > > > > of what each jar is for and what uses it. How about
> > > starting
> > > > > > with
> > > > > > > > > > whatever
> > > > > > > > > > > bundle make up is easiest for you and then we can
> juggle
> > > > > things
> > > > > > > > around
> > > > > > > > > > to
> > > > > > > > > > > get to something everyone is happy with.
> > > > > > > > > > >
> > > > > > > > > > > ...ant
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Hi Rajini
> > > > > > > > >
> > > > > > > > > Some OSGi novice questions...
> > > > > > > > >
> > > > > > > > > Is there any automation available for management the OSGi
> > > > > manifests?
> > > > > > > > > Do any of the jars we depend on already come with suitable
> > > > > manifest
> > > > > > > > > information for grouping jars?
> > > > > > > > >
> > > > > > > > > I was trying to work out how to get the non-test
> dependency
> > > list
> > > > > the
> > > > > > > > other
> > > > > > > > > day. I didn't look that hard but the answer wasn't
> obvious.
> > > The
> > > > > only
> > > > > > > > > (semi-)automatic way I can think of doing it is to comment
> > out
> > > > the
> > > > > > > test
> > > > > > > > > dependencies and then look at the maven classpath that
> > results
> > > (
> > > > > e.g.
> > > > > > > mvn
> > > > > > > > > dependency:build-classpath)
> > > > > > > > >
> > > > > > > > > Regards
> > > > > > > > >
> > > > > > > > > Simon
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > Hi
> > > > >
> > > > > I've done a bit of work on this trying to work out how to answer
> the
> > > > > question. Firstly I spent a bit of time looking at various maven
> > > plugins
> > > > > that do dependency processing. Along the way I found out some
> > > > interesting
> > > > > things...
> > > > >
> > > > > This is slightly off topic but CxF have a new NOTICE format that
> is
> > > > > produced
> > > > > by the remote dependency plugin. I've had a play with it and I
> think
> > > we
> > > > > should consider setting it up for Tuscany.
> > > > >
> > > > > Back to the matter at hand. I wanted something that printed out
> all
> > > the
> > > > > dependencies in a simple textual format so that I could analyse
> > them.
> > > > > Nothing came to hand immediately (I'm sure there is something but
> I
> > > > > couldn't
> > > > > find it) so I knocked up a simple plugin to print out each project
> > > > > dependency along with the transitive dependency path that caused
> the
> > > > > dependency to be included.
> > > > >
> > > > > FYI - the plugin is in my sandbox (
> > > > >
> > > > >
> > > >
> > >
> >
> http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/maven-sca-dependencies/
> > > > > )
> > > > >
> > > > > I ran this plugin against all the modules, concatenated all the
> > output
> > > > > together into a single file and then sorted it so that I can see,
> > for
> > > > each
> > > > > artifact what depends on it. Here's the result (
> > > > > http://people.apache.org/~slaws/dependencies.htm<http://people.apache.org/%7Eslaws/dependencies.htm>
> <
> > http://people.apache.org/%7Eslaws/dependencies.htm>
> > > <http://people.apache.org/%7Eslaws/dependencies.htm>
> > > > <http://people.apache.org/%7Eslaws/dependencies.htm>
> > > > > )
> > > > >
> > > > > What I'm looking at now it any inconsistencies that appear in this
> > > list,
> > > > > for
> > > > > examples, things that are test dependencies for one module but
> > runtime
> > > > > dependencies for another. It'd be great it you can take a look
> also
> > > and
> > > > we
> > > > > can discuss here how best to work toward the answer you need about
> > > > > ensuring
> > > > > that dependencies are properly scoped.
> > > > >
> > > > > Regards
> > > > >
> > > > > Simon
> > > > >
> > > >
> > > > Not exactly what it was intended for but one thing that report shows
> > is
> > > > numerous cases where we have different versions of the same
> > dependency.
> > > If
> > > > nothing else fixing this so everything uses the same version could
> > > making
> > > > building Tuscany from an empty local repository faster.
> > > >
> > > > ...ant
> > > >
> > > It will also hit us when we start trying to get some of the new
> modules
> > > into
> > > a release. IIRC the release was pretty well sorted in terms of
> shipping
> > > the
> > > minimal set of jars. How did you arrive at the set that we have?
> You're
> > > right that we should sort the poms out now but I'd be interested to
> know
> > > what the process you went through was identifying the minimum set of
> > jars
> > > for past releases.
> > >
> > > Simon
> > >
> >
> > It was very manual. For every jar in the distribution i looked at where
> it
> > came from and what it was for. If there were multiple version i kept the
> > highest, if it wasn't required or I wasn't sure but suspected it wasn't
> > and
> > the samples worked without it then i excluded it.
> >
> > We'll probably always need an element of that manual approach every time
> > something is added to the distribution/release - to check for any
> > license/notice updates - and as so many of the dependencies seem to have
> > problems in their pom.xml files dragging in unnecessary things so we
> need
> > to
> > check for any jar changes to try to verify if they're really required.
> >
> > ...ant
> >
>
Re: OSGi-based Tuscany runtime
Posted by Rajini Sivaram <ra...@googlemail.com>.
I was under the impression that maven generated a minimal list of dependent
jar versions using copy-dependencies, and I assumed that Tuscany used this
in some form to generate the minimal set (with the highest versions). I was
trying to use maven-bundle-plugin to generate bundles out of the
dependencies, and ended up with 90 more jar files than those copied by
copy-dependencies, and most of these seem to be due to multiple versions of
the files. A manual approach to sorting out third party versions will add a
lot of work to bundle-ized Tuscany, for transitive dependencies within third
party bundles, since package versions of export/import package
statements will have to be manually edited in the manifest files.
Thank you...
Regards,
Rajini
On 11/12/07, ant elder <an...@apache.org> wrote:
>
> On Nov 12, 2007 12:15 PM, Simon Laws <si...@googlemail.com> wrote:
>
> > On Nov 12, 2007 11:58 AM, ant elder <an...@gmail.com> wrote:
> >
> > > On Nov 12, 2007 11:42 AM, Simon Laws <si...@googlemail.com>
> wrote:
> > >
> > > > On Nov 8, 2007 10:56 AM, Rajini Sivaram <
> rajinisivaram@googlemail.com>
> > > > wrote:
> > > >
> > > > > Simon,
> > > > >
> > > > > Thank you. Yes, I would really appreciate your help in sorting out
> > the
> > > > > poms.
> > > > >
> > > > >
> > > > > Thank you...
> > > > >
> > > > > Regards,
> > > > >
> > > > > Rajini
> > > > >
> > > > >
> > > > > On 11/8/07, Simon Laws <si...@googlemail.com> wrote:
> > > > > >
> > > > > > Hi Rajini
> > > > > >
> > > > > > I'd forgotten about project-info-reports. Thanks for reminding
> > me!.
> > > I
> > > > > > think
> > > > > > the answer here is for us to get our poms right so that all
> > > > dependencies
> > > > > > have the correct scope. I'm happy to help out here. It's easy
> > enough
> > > > to
> > > > > > work
> > > > > > out which are compile time dependencies but it's note clear
> that
> > we
> > > > are
> > > > > > marking runtime/test dependencies accurately. I don't think
> there
> > is
> > > > an
> > > > > > automatic way of distinguishing.
> > > > > >
> > > > > > Simon
> > > > > >
> > > > > > On 11/8/07, Rajini Sivaram <ra...@googlemail.com> wrote:
> > > > > > >
> > > > > > > Simon,
> > > > > > >
> > > > > > > maven-bundle-plugin can be used to generate manifest files for
> > the
> > > > jar
> > > > > > > files, but the recommended practice is to explicitly specify
> the
> > > > > > exported
> > > > > > > packages rather than export everything from the jar. I tried
> to
> > > use
> > > > > this
> > > > > > > to
> > > > > > > generate manifest files for all the third party jars
> separately,
> > > but
> > > > I
> > > > > > > couldn't get these jars to install and resolve under Felix. So
> > at
> > > > the
> > > > > > > moment, there is a single large third party jar with hardcoded
> > > > > > > export-packages. Once the bundles are finalized, I will try
> and
> > > use
> > > > > > > maven-bundle-plugin to generate as much of the manifest as
> > > possible.
> > > > > > >
> > > > > > > Most of the 3rd party jars do not have OSGi manifest headers (
> a
> > > few
> > > > > > like
> > > > > > > SDO do). I will try and use existing headers wherever they are
> > > > > available
> > > > > > > (again, I will try to do this after the bundles are
> finalized).
> > > > > > >
> > > > > > > I had a look at the dependency graph generated by "mvn
> > > > > > > project-info-reports:dependencies", and the dependency tree
> > format
> > > > > looks
> > > > > > > much more usable to generate a full visual graph of the
> > > > dependencies,
> > > > > > > compared to a flat classpath. My only concern is that many of
> > the
> > > > test
> > > > > > > dependencies in the modules are not marked with scope test and
> > > would
> > > > > > > probably result in unnecessary dependencies (and I am not sure
> > > which
> > > > > > > dependencies I can safely remove).
> > > > > > >
> > > > > > > Thank you...
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Rajini
> > > > > > >
> > > > > > > On 11/7/07, Simon Laws <si...@googlemail.com> wrote:
> > > > > > > >
> > > > > > > > On 11/7/07, Rajini Sivaram <ra...@googlemail.com>
> > wrote:
> > > > > > > > >
> > > > > > > > > Hello,
> > > > > > > > >
> > > > > > > > > https://issues.apache.org/jira/browse/TUSCANY-1897 creates
> a
> > > set
> > > > > of
> > > > > > > > > bundles
> > > > > > > > > to enable Tuscany to be run inside an OSGi runtime. At the
> > > > moment,
> > > > > > > there
> > > > > > > > > are
> > > > > > > > > five bundles:
> > > > > > > > >
> > > > > > > > > 1. org.apache.tuscany.sca.api.jar 18,701
> > > > > > > > > 2. org.apache.tuscany.spi.jar 430,563
> > > > > > > > > 3. org.apache.tuscany.runtime.jar 538,660
> > > > > > > > > 4. org.apache.tuscany.extensions.jar 1,374,045
> > > > > > > > > 5. org.apache.tuscany.depends.jar 57,872,558
> > > > > > > > >
> > > > > > > > > I would like to split the 3rd party bundle first and then
> > > > possibly
> > > > > > the
> > > > > > > > > Tuscany extensions bundle. Ideally I would like to have
> > > bundles
> > > > > > which
> > > > > > > > > match
> > > > > > > > > the jar files provided in "distribution" so that OSGi
> > manifest
> > > > > > headers
> > > > > > > > can
> > > > > > > > > be added to the jars in "distribution" enabling a binary
> > > Tuscany
> > > > > > > > > distribution to be run under OSGi.
> > > > > > > > >
> > > > > > > > > I would like to satisfy as many of Sebastien's use cases
> (
> > > > > > > > > http://marc.info/?l=tuscany-dev&m=119326781123561&w=2) as
> > > > > possible.
> > > > > > > But
> > > > > > > > I
> > > > > > > > > am
> > > > > > > > > not sure what the granularity of the bundles should be if
> we
> > > > want
> > > > > to
> > > > > > > > have
> > > > > > > > > the same set of jars for both an OSGi and non-OSGi
> > > distribution.
> > > > > > More
> > > > > > > > fine
> > > > > > > > > grained jars provide better versioning under OSGi, but
> > > requires
> > > > > the
> > > > > > > > > maintenance of more package dependencies in the manifest
> > > files.
> > > > > > Would
> > > > > > > it
> > > > > > > > > be
> > > > > > > > > better to group related 3rd party jars together (eg. all
> > Axis2
> > > > > > related
> > > > > > > > > jars
> > > > > > > > > into one bundle) where each jar belongs to one and only
> one
> > > > > bundle?
> > > > > > > > >
> > > > > > > > > Any thoughts on what the Tuscany distribution should look
> > like
> > > > > > (should
> > > > > > > > it
> > > > > > > > > continue to be the current list of jars, or should related
> > > jars
> > > > be
> > > > > > > > grouped
> > > > > > > > > together), and on the granularity required for versioning
> > when
> > > > > > running
> > > > > > > > > Tuscany under OSGi are appreciated.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Ant,
> > > > > > > > >
> > > > > > > > > Would it be possible for you to provide a list of third
> > party
> > > > jars
> > > > > > > used
> > > > > > > > by
> > > > > > > > > each extension? Since maven dependencies in the
> > > > extension/pom.xml
> > > > > > > > include
> > > > > > > > > the dependencies for testing (sometimes without a scope),
> I
> > am
> > > > not
> > > > > > > sure
> > > > > > > > if
> > > > > > > > > I
> > > > > > > > > could use a dependency list generated by maven.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Thank you...
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > >
> > > > > > > > > Rajini
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 10/25/07, ant elder <an...@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On 10/25/07, Rajini Sivaram <
> rajinisivaram@googlemail.com>
> > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > <snip>
> > > > > > > > > >
> > > > > > > > > > This does imply splitting both Tuscany extension bundle
> > > > > > > > > > > and the big 3rd party bundle, into smaller chunks.
> > Because
> > > > of
> > > > > > its
> > > > > > > > > size,
> > > > > > > > > > I
> > > > > > > > > > > am
> > > > > > > > > > > more inclined to split the 3rd party bundle into
> smaller
> > > > > bundles
> > > > > > > > first
> > > > > > > > > > > (though I have no idea where to start with this huge
> big
> > > > list
> > > > > of
> > > > > > > jar
> > > > > > > > > > > files).
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I can help with that, after doing lots of releases i've
> a
> > > good
> > > > > > > > > > understanding
> > > > > > > > > > of what each jar is for and what uses it. How about
> > starting
> > > > > with
> > > > > > > > > whatever
> > > > > > > > > > bundle make up is easiest for you and then we can juggle
> > > > things
> > > > > > > around
> > > > > > > > > to
> > > > > > > > > > get to something everyone is happy with.
> > > > > > > > > >
> > > > > > > > > > ...ant
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > Hi Rajini
> > > > > > > >
> > > > > > > > Some OSGi novice questions...
> > > > > > > >
> > > > > > > > Is there any automation available for management the OSGi
> > > > manifests?
> > > > > > > > Do any of the jars we depend on already come with suitable
> > > > manifest
> > > > > > > > information for grouping jars?
> > > > > > > >
> > > > > > > > I was trying to work out how to get the non-test dependency
> > list
> > > > the
> > > > > > > other
> > > > > > > > day. I didn't look that hard but the answer wasn't obvious.
> > The
> > > > only
> > > > > > > > (semi-)automatic way I can think of doing it is to comment
> out
> > > the
> > > > > > test
> > > > > > > > dependencies and then look at the maven classpath that
> results
> > (
> > > > e.g.
> > > > > > mvn
> > > > > > > > dependency:build-classpath)
> > > > > > > >
> > > > > > > > Regards
> > > > > > > >
> > > > > > > > Simon
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > Hi
> > > >
> > > > I've done a bit of work on this trying to work out how to answer the
> > > > question. Firstly I spent a bit of time looking at various maven
> > plugins
> > > > that do dependency processing. Along the way I found out some
> > > interesting
> > > > things...
> > > >
> > > > This is slightly off topic but CxF have a new NOTICE format that is
> > > > produced
> > > > by the remote dependency plugin. I've had a play with it and I think
> > we
> > > > should consider setting it up for Tuscany.
> > > >
> > > > Back to the matter at hand. I wanted something that printed out all
> > the
> > > > dependencies in a simple textual format so that I could analyse
> them.
> > > > Nothing came to hand immediately (I'm sure there is something but I
> > > > couldn't
> > > > find it) so I knocked up a simple plugin to print out each project
> > > > dependency along with the transitive dependency path that caused the
> > > > dependency to be included.
> > > >
> > > > FYI - the plugin is in my sandbox (
> > > >
> > > >
> > >
> >
> http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/maven-sca-dependencies/
> > > > )
> > > >
> > > > I ran this plugin against all the modules, concatenated all the
> output
> > > > together into a single file and then sorted it so that I can see,
> for
> > > each
> > > > artifact what depends on it. Here's the result (
> > > > http://people.apache.org/~slaws/dependencies.htm<
> http://people.apache.org/%7Eslaws/dependencies.htm>
> > <http://people.apache.org/%7Eslaws/dependencies.htm>
> > > <http://people.apache.org/%7Eslaws/dependencies.htm>
> > > > )
> > > >
> > > > What I'm looking at now it any inconsistencies that appear in this
> > list,
> > > > for
> > > > examples, things that are test dependencies for one module but
> runtime
> > > > dependencies for another. It'd be great it you can take a look also
> > and
> > > we
> > > > can discuss here how best to work toward the answer you need about
> > > > ensuring
> > > > that dependencies are properly scoped.
> > > >
> > > > Regards
> > > >
> > > > Simon
> > > >
> > >
> > > Not exactly what it was intended for but one thing that report shows
> is
> > > numerous cases where we have different versions of the same
> dependency.
> > If
> > > nothing else fixing this so everything uses the same version could
> > making
> > > building Tuscany from an empty local repository faster.
> > >
> > > ...ant
> > >
> > It will also hit us when we start trying to get some of the new modules
> > into
> > a release. IIRC the release was pretty well sorted in terms of shipping
> > the
> > minimal set of jars. How did you arrive at the set that we have? You're
> > right that we should sort the poms out now but I'd be interested to know
> > what the process you went through was identifying the minimum set of
> jars
> > for past releases.
> >
> > Simon
> >
>
> It was very manual. For every jar in the distribution i looked at where it
> came from and what it was for. If there were multiple version i kept the
> highest, if it wasn't required or I wasn't sure but suspected it wasn't
> and
> the samples worked without it then i excluded it.
>
> We'll probably always need an element of that manual approach every time
> something is added to the distribution/release - to check for any
> license/notice updates - and as so many of the dependencies seem to have
> problems in their pom.xml files dragging in unnecessary things so we need
> to
> check for any jar changes to try to verify if they're really required.
>
> ...ant
>
Re: OSGi-based Tuscany runtime
Posted by ant elder <an...@apache.org>.
On Nov 12, 2007 12:15 PM, Simon Laws <si...@googlemail.com> wrote:
> On Nov 12, 2007 11:58 AM, ant elder <an...@gmail.com> wrote:
>
> > On Nov 12, 2007 11:42 AM, Simon Laws <si...@googlemail.com> wrote:
> >
> > > On Nov 8, 2007 10:56 AM, Rajini Sivaram <ra...@googlemail.com>
> > > wrote:
> > >
> > > > Simon,
> > > >
> > > > Thank you. Yes, I would really appreciate your help in sorting out
> the
> > > > poms.
> > > >
> > > >
> > > > Thank you...
> > > >
> > > > Regards,
> > > >
> > > > Rajini
> > > >
> > > >
> > > > On 11/8/07, Simon Laws <si...@googlemail.com> wrote:
> > > > >
> > > > > Hi Rajini
> > > > >
> > > > > I'd forgotten about project-info-reports. Thanks for reminding
> me!.
> > I
> > > > > think
> > > > > the answer here is for us to get our poms right so that all
> > > dependencies
> > > > > have the correct scope. I'm happy to help out here. It's easy
> enough
> > > to
> > > > > work
> > > > > out which are compile time dependencies but it's note clear that
> we
> > > are
> > > > > marking runtime/test dependencies accurately. I don't think there
> is
> > > an
> > > > > automatic way of distinguishing.
> > > > >
> > > > > Simon
> > > > >
> > > > > On 11/8/07, Rajini Sivaram <ra...@googlemail.com> wrote:
> > > > > >
> > > > > > Simon,
> > > > > >
> > > > > > maven-bundle-plugin can be used to generate manifest files for
> the
> > > jar
> > > > > > files, but the recommended practice is to explicitly specify the
> > > > > exported
> > > > > > packages rather than export everything from the jar. I tried to
> > use
> > > > this
> > > > > > to
> > > > > > generate manifest files for all the third party jars separately,
> > but
> > > I
> > > > > > couldn't get these jars to install and resolve under Felix. So
> at
> > > the
> > > > > > moment, there is a single large third party jar with hardcoded
> > > > > > export-packages. Once the bundles are finalized, I will try and
> > use
> > > > > > maven-bundle-plugin to generate as much of the manifest as
> > possible.
> > > > > >
> > > > > > Most of the 3rd party jars do not have OSGi manifest headers ( a
> > few
> > > > > like
> > > > > > SDO do). I will try and use existing headers wherever they are
> > > > available
> > > > > > (again, I will try to do this after the bundles are finalized).
> > > > > >
> > > > > > I had a look at the dependency graph generated by "mvn
> > > > > > project-info-reports:dependencies", and the dependency tree
> format
> > > > looks
> > > > > > much more usable to generate a full visual graph of the
> > > dependencies,
> > > > > > compared to a flat classpath. My only concern is that many of
> the
> > > test
> > > > > > dependencies in the modules are not marked with scope test and
> > would
> > > > > > probably result in unnecessary dependencies (and I am not sure
> > which
> > > > > > dependencies I can safely remove).
> > > > > >
> > > > > > Thank you...
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Rajini
> > > > > >
> > > > > > On 11/7/07, Simon Laws <si...@googlemail.com> wrote:
> > > > > > >
> > > > > > > On 11/7/07, Rajini Sivaram <ra...@googlemail.com>
> wrote:
> > > > > > > >
> > > > > > > > Hello,
> > > > > > > >
> > > > > > > > https://issues.apache.org/jira/browse/TUSCANY-1897 creates a
> > set
> > > > of
> > > > > > > > bundles
> > > > > > > > to enable Tuscany to be run inside an OSGi runtime. At the
> > > moment,
> > > > > > there
> > > > > > > > are
> > > > > > > > five bundles:
> > > > > > > >
> > > > > > > > 1. org.apache.tuscany.sca.api.jar 18,701
> > > > > > > > 2. org.apache.tuscany.spi.jar 430,563
> > > > > > > > 3. org.apache.tuscany.runtime.jar 538,660
> > > > > > > > 4. org.apache.tuscany.extensions.jar 1,374,045
> > > > > > > > 5. org.apache.tuscany.depends.jar 57,872,558
> > > > > > > >
> > > > > > > > I would like to split the 3rd party bundle first and then
> > > possibly
> > > > > the
> > > > > > > > Tuscany extensions bundle. Ideally I would like to have
> > bundles
> > > > > which
> > > > > > > > match
> > > > > > > > the jar files provided in "distribution" so that OSGi
> manifest
> > > > > headers
> > > > > > > can
> > > > > > > > be added to the jars in "distribution" enabling a binary
> > Tuscany
> > > > > > > > distribution to be run under OSGi.
> > > > > > > >
> > > > > > > > I would like to satisfy as many of Sebastien's use cases (
> > > > > > > > http://marc.info/?l=tuscany-dev&m=119326781123561&w=2) as
> > > > possible.
> > > > > > But
> > > > > > > I
> > > > > > > > am
> > > > > > > > not sure what the granularity of the bundles should be if we
> > > want
> > > > to
> > > > > > > have
> > > > > > > > the same set of jars for both an OSGi and non-OSGi
> > distribution.
> > > > > More
> > > > > > > fine
> > > > > > > > grained jars provide better versioning under OSGi, but
> > requires
> > > > the
> > > > > > > > maintenance of more package dependencies in the manifest
> > files.
> > > > > Would
> > > > > > it
> > > > > > > > be
> > > > > > > > better to group related 3rd party jars together (eg. all
> Axis2
> > > > > related
> > > > > > > > jars
> > > > > > > > into one bundle) where each jar belongs to one and only one
> > > > bundle?
> > > > > > > >
> > > > > > > > Any thoughts on what the Tuscany distribution should look
> like
> > > > > (should
> > > > > > > it
> > > > > > > > continue to be the current list of jars, or should related
> > jars
> > > be
> > > > > > > grouped
> > > > > > > > together), and on the granularity required for versioning
> when
> > > > > running
> > > > > > > > Tuscany under OSGi are appreciated.
> > > > > > > >
> > > > > > > >
> > > > > > > > Ant,
> > > > > > > >
> > > > > > > > Would it be possible for you to provide a list of third
> party
> > > jars
> > > > > > used
> > > > > > > by
> > > > > > > > each extension? Since maven dependencies in the
> > > extension/pom.xml
> > > > > > > include
> > > > > > > > the dependencies for testing (sometimes without a scope), I
> am
> > > not
> > > > > > sure
> > > > > > > if
> > > > > > > > I
> > > > > > > > could use a dependency list generated by maven.
> > > > > > > >
> > > > > > > >
> > > > > > > > Thank you...
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > >
> > > > > > > > Rajini
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 10/25/07, ant elder <an...@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > On 10/25/07, Rajini Sivaram <ra...@googlemail.com>
> > > > wrote:
> > > > > > > > >
> > > > > > > > > <snip>
> > > > > > > > >
> > > > > > > > > This does imply splitting both Tuscany extension bundle
> > > > > > > > > > and the big 3rd party bundle, into smaller chunks.
> Because
> > > of
> > > > > its
> > > > > > > > size,
> > > > > > > > > I
> > > > > > > > > > am
> > > > > > > > > > more inclined to split the 3rd party bundle into smaller
> > > > bundles
> > > > > > > first
> > > > > > > > > > (though I have no idea where to start with this huge big
> > > list
> > > > of
> > > > > > jar
> > > > > > > > > > files).
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I can help with that, after doing lots of releases i've a
> > good
> > > > > > > > > understanding
> > > > > > > > > of what each jar is for and what uses it. How about
> starting
> > > > with
> > > > > > > > whatever
> > > > > > > > > bundle make up is easiest for you and then we can juggle
> > > things
> > > > > > around
> > > > > > > > to
> > > > > > > > > get to something everyone is happy with.
> > > > > > > > >
> > > > > > > > > ...ant
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > Hi Rajini
> > > > > > >
> > > > > > > Some OSGi novice questions...
> > > > > > >
> > > > > > > Is there any automation available for management the OSGi
> > > manifests?
> > > > > > > Do any of the jars we depend on already come with suitable
> > > manifest
> > > > > > > information for grouping jars?
> > > > > > >
> > > > > > > I was trying to work out how to get the non-test dependency
> list
> > > the
> > > > > > other
> > > > > > > day. I didn't look that hard but the answer wasn't obvious.
> The
> > > only
> > > > > > > (semi-)automatic way I can think of doing it is to comment out
> > the
> > > > > test
> > > > > > > dependencies and then look at the maven classpath that results
> (
> > > e.g.
> > > > > mvn
> > > > > > > dependency:build-classpath)
> > > > > > >
> > > > > > > Regards
> > > > > > >
> > > > > > > Simon
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > Hi
> > >
> > > I've done a bit of work on this trying to work out how to answer the
> > > question. Firstly I spent a bit of time looking at various maven
> plugins
> > > that do dependency processing. Along the way I found out some
> > interesting
> > > things...
> > >
> > > This is slightly off topic but CxF have a new NOTICE format that is
> > > produced
> > > by the remote dependency plugin. I've had a play with it and I think
> we
> > > should consider setting it up for Tuscany.
> > >
> > > Back to the matter at hand. I wanted something that printed out all
> the
> > > dependencies in a simple textual format so that I could analyse them.
> > > Nothing came to hand immediately (I'm sure there is something but I
> > > couldn't
> > > find it) so I knocked up a simple plugin to print out each project
> > > dependency along with the transitive dependency path that caused the
> > > dependency to be included.
> > >
> > > FYI - the plugin is in my sandbox (
> > >
> > >
> >
> http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/maven-sca-dependencies/
> > > )
> > >
> > > I ran this plugin against all the modules, concatenated all the output
> > > together into a single file and then sorted it so that I can see, for
> > each
> > > artifact what depends on it. Here's the result (
> > > http://people.apache.org/~slaws/dependencies.htm<http://people.apache.org/%7Eslaws/dependencies.htm>
> <http://people.apache.org/%7Eslaws/dependencies.htm>
> > <http://people.apache.org/%7Eslaws/dependencies.htm>
> > > )
> > >
> > > What I'm looking at now it any inconsistencies that appear in this
> list,
> > > for
> > > examples, things that are test dependencies for one module but runtime
> > > dependencies for another. It'd be great it you can take a look also
> and
> > we
> > > can discuss here how best to work toward the answer you need about
> > > ensuring
> > > that dependencies are properly scoped.
> > >
> > > Regards
> > >
> > > Simon
> > >
> >
> > Not exactly what it was intended for but one thing that report shows is
> > numerous cases where we have different versions of the same dependency.
> If
> > nothing else fixing this so everything uses the same version could
> making
> > building Tuscany from an empty local repository faster.
> >
> > ...ant
> >
> It will also hit us when we start trying to get some of the new modules
> into
> a release. IIRC the release was pretty well sorted in terms of shipping
> the
> minimal set of jars. How did you arrive at the set that we have? You're
> right that we should sort the poms out now but I'd be interested to know
> what the process you went through was identifying the minimum set of jars
> for past releases.
>
> Simon
>
It was very manual. For every jar in the distribution i looked at where it
came from and what it was for. If there were multiple version i kept the
highest, if it wasn't required or I wasn't sure but suspected it wasn't and
the samples worked without it then i excluded it.
We'll probably always need an element of that manual approach every time
something is added to the distribution/release - to check for any
license/notice updates - and as so many of the dependencies seem to have
problems in their pom.xml files dragging in unnecessary things so we need to
check for any jar changes to try to verify if they're really required.
...ant
Re: OSGi-based Tuscany runtime
Posted by Simon Laws <si...@googlemail.com>.
On Nov 12, 2007 11:58 AM, ant elder <an...@gmail.com> wrote:
> On Nov 12, 2007 11:42 AM, Simon Laws <si...@googlemail.com> wrote:
>
> > On Nov 8, 2007 10:56 AM, Rajini Sivaram <ra...@googlemail.com>
> > wrote:
> >
> > > Simon,
> > >
> > > Thank you. Yes, I would really appreciate your help in sorting out the
> > > poms.
> > >
> > >
> > > Thank you...
> > >
> > > Regards,
> > >
> > > Rajini
> > >
> > >
> > > On 11/8/07, Simon Laws <si...@googlemail.com> wrote:
> > > >
> > > > Hi Rajini
> > > >
> > > > I'd forgotten about project-info-reports. Thanks for reminding me!.
> I
> > > > think
> > > > the answer here is for us to get our poms right so that all
> > dependencies
> > > > have the correct scope. I'm happy to help out here. It's easy enough
> > to
> > > > work
> > > > out which are compile time dependencies but it's note clear that we
> > are
> > > > marking runtime/test dependencies accurately. I don't think there is
> > an
> > > > automatic way of distinguishing.
> > > >
> > > > Simon
> > > >
> > > > On 11/8/07, Rajini Sivaram <ra...@googlemail.com> wrote:
> > > > >
> > > > > Simon,
> > > > >
> > > > > maven-bundle-plugin can be used to generate manifest files for the
> > jar
> > > > > files, but the recommended practice is to explicitly specify the
> > > > exported
> > > > > packages rather than export everything from the jar. I tried to
> use
> > > this
> > > > > to
> > > > > generate manifest files for all the third party jars separately,
> but
> > I
> > > > > couldn't get these jars to install and resolve under Felix. So at
> > the
> > > > > moment, there is a single large third party jar with hardcoded
> > > > > export-packages. Once the bundles are finalized, I will try and
> use
> > > > > maven-bundle-plugin to generate as much of the manifest as
> possible.
> > > > >
> > > > > Most of the 3rd party jars do not have OSGi manifest headers ( a
> few
> > > > like
> > > > > SDO do). I will try and use existing headers wherever they are
> > > available
> > > > > (again, I will try to do this after the bundles are finalized).
> > > > >
> > > > > I had a look at the dependency graph generated by "mvn
> > > > > project-info-reports:dependencies", and the dependency tree format
> > > looks
> > > > > much more usable to generate a full visual graph of the
> > dependencies,
> > > > > compared to a flat classpath. My only concern is that many of the
> > test
> > > > > dependencies in the modules are not marked with scope test and
> would
> > > > > probably result in unnecessary dependencies (and I am not sure
> which
> > > > > dependencies I can safely remove).
> > > > >
> > > > > Thank you...
> > > > >
> > > > > Regards,
> > > > >
> > > > > Rajini
> > > > >
> > > > > On 11/7/07, Simon Laws <si...@googlemail.com> wrote:
> > > > > >
> > > > > > On 11/7/07, Rajini Sivaram <ra...@googlemail.com> wrote:
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > https://issues.apache.org/jira/browse/TUSCANY-1897 creates a
> set
> > > of
> > > > > > > bundles
> > > > > > > to enable Tuscany to be run inside an OSGi runtime. At the
> > moment,
> > > > > there
> > > > > > > are
> > > > > > > five bundles:
> > > > > > >
> > > > > > > 1. org.apache.tuscany.sca.api.jar 18,701
> > > > > > > 2. org.apache.tuscany.spi.jar 430,563
> > > > > > > 3. org.apache.tuscany.runtime.jar 538,660
> > > > > > > 4. org.apache.tuscany.extensions.jar 1,374,045
> > > > > > > 5. org.apache.tuscany.depends.jar 57,872,558
> > > > > > >
> > > > > > > I would like to split the 3rd party bundle first and then
> > possibly
> > > > the
> > > > > > > Tuscany extensions bundle. Ideally I would like to have
> bundles
> > > > which
> > > > > > > match
> > > > > > > the jar files provided in "distribution" so that OSGi manifest
> > > > headers
> > > > > > can
> > > > > > > be added to the jars in "distribution" enabling a binary
> Tuscany
> > > > > > > distribution to be run under OSGi.
> > > > > > >
> > > > > > > I would like to satisfy as many of Sebastien's use cases (
> > > > > > > http://marc.info/?l=tuscany-dev&m=119326781123561&w=2) as
> > > possible.
> > > > > But
> > > > > > I
> > > > > > > am
> > > > > > > not sure what the granularity of the bundles should be if we
> > want
> > > to
> > > > > > have
> > > > > > > the same set of jars for both an OSGi and non-OSGi
> distribution.
> > > > More
> > > > > > fine
> > > > > > > grained jars provide better versioning under OSGi, but
> requires
> > > the
> > > > > > > maintenance of more package dependencies in the manifest
> files.
> > > > Would
> > > > > it
> > > > > > > be
> > > > > > > better to group related 3rd party jars together (eg. all Axis2
> > > > related
> > > > > > > jars
> > > > > > > into one bundle) where each jar belongs to one and only one
> > > bundle?
> > > > > > >
> > > > > > > Any thoughts on what the Tuscany distribution should look like
> > > > (should
> > > > > > it
> > > > > > > continue to be the current list of jars, or should related
> jars
> > be
> > > > > > grouped
> > > > > > > together), and on the granularity required for versioning when
> > > > running
> > > > > > > Tuscany under OSGi are appreciated.
> > > > > > >
> > > > > > >
> > > > > > > Ant,
> > > > > > >
> > > > > > > Would it be possible for you to provide a list of third party
> > jars
> > > > > used
> > > > > > by
> > > > > > > each extension? Since maven dependencies in the
> > extension/pom.xml
> > > > > > include
> > > > > > > the dependencies for testing (sometimes without a scope), I am
> > not
> > > > > sure
> > > > > > if
> > > > > > > I
> > > > > > > could use a dependency list generated by maven.
> > > > > > >
> > > > > > >
> > > > > > > Thank you...
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Rajini
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 10/25/07, ant elder <an...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On 10/25/07, Rajini Sivaram <ra...@googlemail.com>
> > > wrote:
> > > > > > > >
> > > > > > > > <snip>
> > > > > > > >
> > > > > > > > This does imply splitting both Tuscany extension bundle
> > > > > > > > > and the big 3rd party bundle, into smaller chunks. Because
> > of
> > > > its
> > > > > > > size,
> > > > > > > > I
> > > > > > > > > am
> > > > > > > > > more inclined to split the 3rd party bundle into smaller
> > > bundles
> > > > > > first
> > > > > > > > > (though I have no idea where to start with this huge big
> > list
> > > of
> > > > > jar
> > > > > > > > > files).
> > > > > > > >
> > > > > > > >
> > > > > > > > I can help with that, after doing lots of releases i've a
> good
> > > > > > > > understanding
> > > > > > > > of what each jar is for and what uses it. How about starting
> > > with
> > > > > > > whatever
> > > > > > > > bundle make up is easiest for you and then we can juggle
> > things
> > > > > around
> > > > > > > to
> > > > > > > > get to something everyone is happy with.
> > > > > > > >
> > > > > > > > ...ant
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > > Hi Rajini
> > > > > >
> > > > > > Some OSGi novice questions...
> > > > > >
> > > > > > Is there any automation available for management the OSGi
> > manifests?
> > > > > > Do any of the jars we depend on already come with suitable
> > manifest
> > > > > > information for grouping jars?
> > > > > >
> > > > > > I was trying to work out how to get the non-test dependency list
> > the
> > > > > other
> > > > > > day. I didn't look that hard but the answer wasn't obvious. The
> > only
> > > > > > (semi-)automatic way I can think of doing it is to comment out
> the
> > > > test
> > > > > > dependencies and then look at the maven classpath that results (
> > e.g.
> > > > mvn
> > > > > > dependency:build-classpath)
> > > > > >
> > > > > > Regards
> > > > > >
> > > > > > Simon
> > > > > >
> > > > >
> > > >
> > >
> > Hi
> >
> > I've done a bit of work on this trying to work out how to answer the
> > question. Firstly I spent a bit of time looking at various maven plugins
> > that do dependency processing. Along the way I found out some
> interesting
> > things...
> >
> > This is slightly off topic but CxF have a new NOTICE format that is
> > produced
> > by the remote dependency plugin. I've had a play with it and I think we
> > should consider setting it up for Tuscany.
> >
> > Back to the matter at hand. I wanted something that printed out all the
> > dependencies in a simple textual format so that I could analyse them.
> > Nothing came to hand immediately (I'm sure there is something but I
> > couldn't
> > find it) so I knocked up a simple plugin to print out each project
> > dependency along with the transitive dependency path that caused the
> > dependency to be included.
> >
> > FYI - the plugin is in my sandbox (
> >
> >
> http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/maven-sca-dependencies/
> > )
> >
> > I ran this plugin against all the modules, concatenated all the output
> > together into a single file and then sorted it so that I can see, for
> each
> > artifact what depends on it. Here's the result (
> > http://people.apache.org/~slaws/dependencies.htm<http://people.apache.org/%7Eslaws/dependencies.htm>
> <http://people.apache.org/%7Eslaws/dependencies.htm>
> > )
> >
> > What I'm looking at now it any inconsistencies that appear in this list,
> > for
> > examples, things that are test dependencies for one module but runtime
> > dependencies for another. It'd be great it you can take a look also and
> we
> > can discuss here how best to work toward the answer you need about
> > ensuring
> > that dependencies are properly scoped.
> >
> > Regards
> >
> > Simon
> >
>
> Not exactly what it was intended for but one thing that report shows is
> numerous cases where we have different versions of the same dependency. If
> nothing else fixing this so everything uses the same version could making
> building Tuscany from an empty local repository faster.
>
> ...ant
>
It will also hit us when we start trying to get some of the new modules into
a release. IIRC the release was pretty well sorted in terms of shipping the
minimal set of jars. How did you arrive at the set that we have? You're
right that we should sort the poms out now but I'd be interested to know
what the process you went through was identifying the minimum set of jars
for past releases.
Simon
Re: OSGi-based Tuscany runtime
Posted by ant elder <an...@gmail.com>.
On Nov 12, 2007 11:42 AM, Simon Laws <si...@googlemail.com> wrote:
> On Nov 8, 2007 10:56 AM, Rajini Sivaram <ra...@googlemail.com>
> wrote:
>
> > Simon,
> >
> > Thank you. Yes, I would really appreciate your help in sorting out the
> > poms.
> >
> >
> > Thank you...
> >
> > Regards,
> >
> > Rajini
> >
> >
> > On 11/8/07, Simon Laws <si...@googlemail.com> wrote:
> > >
> > > Hi Rajini
> > >
> > > I'd forgotten about project-info-reports. Thanks for reminding me!. I
> > > think
> > > the answer here is for us to get our poms right so that all
> dependencies
> > > have the correct scope. I'm happy to help out here. It's easy enough
> to
> > > work
> > > out which are compile time dependencies but it's note clear that we
> are
> > > marking runtime/test dependencies accurately. I don't think there is
> an
> > > automatic way of distinguishing.
> > >
> > > Simon
> > >
> > > On 11/8/07, Rajini Sivaram <ra...@googlemail.com> wrote:
> > > >
> > > > Simon,
> > > >
> > > > maven-bundle-plugin can be used to generate manifest files for the
> jar
> > > > files, but the recommended practice is to explicitly specify the
> > > exported
> > > > packages rather than export everything from the jar. I tried to use
> > this
> > > > to
> > > > generate manifest files for all the third party jars separately, but
> I
> > > > couldn't get these jars to install and resolve under Felix. So at
> the
> > > > moment, there is a single large third party jar with hardcoded
> > > > export-packages. Once the bundles are finalized, I will try and use
> > > > maven-bundle-plugin to generate as much of the manifest as possible.
> > > >
> > > > Most of the 3rd party jars do not have OSGi manifest headers ( a few
> > > like
> > > > SDO do). I will try and use existing headers wherever they are
> > available
> > > > (again, I will try to do this after the bundles are finalized).
> > > >
> > > > I had a look at the dependency graph generated by "mvn
> > > > project-info-reports:dependencies", and the dependency tree format
> > looks
> > > > much more usable to generate a full visual graph of the
> dependencies,
> > > > compared to a flat classpath. My only concern is that many of the
> test
> > > > dependencies in the modules are not marked with scope test and would
> > > > probably result in unnecessary dependencies (and I am not sure which
> > > > dependencies I can safely remove).
> > > >
> > > > Thank you...
> > > >
> > > > Regards,
> > > >
> > > > Rajini
> > > >
> > > > On 11/7/07, Simon Laws <si...@googlemail.com> wrote:
> > > > >
> > > > > On 11/7/07, Rajini Sivaram <ra...@googlemail.com> wrote:
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > https://issues.apache.org/jira/browse/TUSCANY-1897 creates a set
> > of
> > > > > > bundles
> > > > > > to enable Tuscany to be run inside an OSGi runtime. At the
> moment,
> > > > there
> > > > > > are
> > > > > > five bundles:
> > > > > >
> > > > > > 1. org.apache.tuscany.sca.api.jar 18,701
> > > > > > 2. org.apache.tuscany.spi.jar 430,563
> > > > > > 3. org.apache.tuscany.runtime.jar 538,660
> > > > > > 4. org.apache.tuscany.extensions.jar 1,374,045
> > > > > > 5. org.apache.tuscany.depends.jar 57,872,558
> > > > > >
> > > > > > I would like to split the 3rd party bundle first and then
> possibly
> > > the
> > > > > > Tuscany extensions bundle. Ideally I would like to have bundles
> > > which
> > > > > > match
> > > > > > the jar files provided in "distribution" so that OSGi manifest
> > > headers
> > > > > can
> > > > > > be added to the jars in "distribution" enabling a binary Tuscany
> > > > > > distribution to be run under OSGi.
> > > > > >
> > > > > > I would like to satisfy as many of Sebastien's use cases (
> > > > > > http://marc.info/?l=tuscany-dev&m=119326781123561&w=2) as
> > possible.
> > > > But
> > > > > I
> > > > > > am
> > > > > > not sure what the granularity of the bundles should be if we
> want
> > to
> > > > > have
> > > > > > the same set of jars for both an OSGi and non-OSGi distribution.
> > > More
> > > > > fine
> > > > > > grained jars provide better versioning under OSGi, but requires
> > the
> > > > > > maintenance of more package dependencies in the manifest files.
> > > Would
> > > > it
> > > > > > be
> > > > > > better to group related 3rd party jars together (eg. all Axis2
> > > related
> > > > > > jars
> > > > > > into one bundle) where each jar belongs to one and only one
> > bundle?
> > > > > >
> > > > > > Any thoughts on what the Tuscany distribution should look like
> > > (should
> > > > > it
> > > > > > continue to be the current list of jars, or should related jars
> be
> > > > > grouped
> > > > > > together), and on the granularity required for versioning when
> > > running
> > > > > > Tuscany under OSGi are appreciated.
> > > > > >
> > > > > >
> > > > > > Ant,
> > > > > >
> > > > > > Would it be possible for you to provide a list of third party
> jars
> > > > used
> > > > > by
> > > > > > each extension? Since maven dependencies in the
> extension/pom.xml
> > > > > include
> > > > > > the dependencies for testing (sometimes without a scope), I am
> not
> > > > sure
> > > > > if
> > > > > > I
> > > > > > could use a dependency list generated by maven.
> > > > > >
> > > > > >
> > > > > > Thank you...
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Rajini
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 10/25/07, ant elder <an...@gmail.com> wrote:
> > > > > > >
> > > > > > > On 10/25/07, Rajini Sivaram <ra...@googlemail.com>
> > wrote:
> > > > > > >
> > > > > > > <snip>
> > > > > > >
> > > > > > > This does imply splitting both Tuscany extension bundle
> > > > > > > > and the big 3rd party bundle, into smaller chunks. Because
> of
> > > its
> > > > > > size,
> > > > > > > I
> > > > > > > > am
> > > > > > > > more inclined to split the 3rd party bundle into smaller
> > bundles
> > > > > first
> > > > > > > > (though I have no idea where to start with this huge big
> list
> > of
> > > > jar
> > > > > > > > files).
> > > > > > >
> > > > > > >
> > > > > > > I can help with that, after doing lots of releases i've a good
> > > > > > > understanding
> > > > > > > of what each jar is for and what uses it. How about starting
> > with
> > > > > > whatever
> > > > > > > bundle make up is easiest for you and then we can juggle
> things
> > > > around
> > > > > > to
> > > > > > > get to something everyone is happy with.
> > > > > > >
> > > > > > > ...ant
> > > > > > >
> > > > > >
> > > > >
> > > > > Hi Rajini
> > > > >
> > > > > Some OSGi novice questions...
> > > > >
> > > > > Is there any automation available for management the OSGi
> manifests?
> > > > > Do any of the jars we depend on already come with suitable
> manifest
> > > > > information for grouping jars?
> > > > >
> > > > > I was trying to work out how to get the non-test dependency list
> the
> > > > other
> > > > > day. I didn't look that hard but the answer wasn't obvious. The
> only
> > > > > (semi-)automatic way I can think of doing it is to comment out the
> > > test
> > > > > dependencies and then look at the maven classpath that results (
> e.g.
> > > mvn
> > > > > dependency:build-classpath)
> > > > >
> > > > > Regards
> > > > >
> > > > > Simon
> > > > >
> > > >
> > >
> >
> Hi
>
> I've done a bit of work on this trying to work out how to answer the
> question. Firstly I spent a bit of time looking at various maven plugins
> that do dependency processing. Along the way I found out some interesting
> things...
>
> This is slightly off topic but CxF have a new NOTICE format that is
> produced
> by the remote dependency plugin. I've had a play with it and I think we
> should consider setting it up for Tuscany.
>
> Back to the matter at hand. I wanted something that printed out all the
> dependencies in a simple textual format so that I could analyse them.
> Nothing came to hand immediately (I'm sure there is something but I
> couldn't
> find it) so I knocked up a simple plugin to print out each project
> dependency along with the transitive dependency path that caused the
> dependency to be included.
>
> FYI - the plugin is in my sandbox (
>
> http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/maven-sca-dependencies/
> )
>
> I ran this plugin against all the modules, concatenated all the output
> together into a single file and then sorted it so that I can see, for each
> artifact what depends on it. Here's the result (
> http://people.apache.org/~slaws/dependencies.htm<http://people.apache.org/%7Eslaws/dependencies.htm>
> )
>
> What I'm looking at now it any inconsistencies that appear in this list,
> for
> examples, things that are test dependencies for one module but runtime
> dependencies for another. It'd be great it you can take a look also and we
> can discuss here how best to work toward the answer you need about
> ensuring
> that dependencies are properly scoped.
>
> Regards
>
> Simon
>
Not exactly what it was intended for but one thing that report shows is
numerous cases where we have different versions of the same dependency. If
nothing else fixing this so everything uses the same version could making
building Tuscany from an empty local repository faster.
...ant
Re: OSGi-based Tuscany runtime
Posted by Simon Laws <si...@googlemail.com>.
On Nov 8, 2007 10:56 AM, Rajini Sivaram <ra...@googlemail.com>
wrote:
> Simon,
>
> Thank you. Yes, I would really appreciate your help in sorting out the
> poms.
>
>
> Thank you...
>
> Regards,
>
> Rajini
>
>
> On 11/8/07, Simon Laws <si...@googlemail.com> wrote:
> >
> > Hi Rajini
> >
> > I'd forgotten about project-info-reports. Thanks for reminding me!. I
> > think
> > the answer here is for us to get our poms right so that all dependencies
> > have the correct scope. I'm happy to help out here. It's easy enough to
> > work
> > out which are compile time dependencies but it's note clear that we are
> > marking runtime/test dependencies accurately. I don't think there is an
> > automatic way of distinguishing.
> >
> > Simon
> >
> > On 11/8/07, Rajini Sivaram <ra...@googlemail.com> wrote:
> > >
> > > Simon,
> > >
> > > maven-bundle-plugin can be used to generate manifest files for the jar
> > > files, but the recommended practice is to explicitly specify the
> > exported
> > > packages rather than export everything from the jar. I tried to use
> this
> > > to
> > > generate manifest files for all the third party jars separately, but I
> > > couldn't get these jars to install and resolve under Felix. So at the
> > > moment, there is a single large third party jar with hardcoded
> > > export-packages. Once the bundles are finalized, I will try and use
> > > maven-bundle-plugin to generate as much of the manifest as possible.
> > >
> > > Most of the 3rd party jars do not have OSGi manifest headers ( a few
> > like
> > > SDO do). I will try and use existing headers wherever they are
> available
> > > (again, I will try to do this after the bundles are finalized).
> > >
> > > I had a look at the dependency graph generated by "mvn
> > > project-info-reports:dependencies", and the dependency tree format
> looks
> > > much more usable to generate a full visual graph of the dependencies,
> > > compared to a flat classpath. My only concern is that many of the test
> > > dependencies in the modules are not marked with scope test and would
> > > probably result in unnecessary dependencies (and I am not sure which
> > > dependencies I can safely remove).
> > >
> > > Thank you...
> > >
> > > Regards,
> > >
> > > Rajini
> > >
> > > On 11/7/07, Simon Laws <si...@googlemail.com> wrote:
> > > >
> > > > On 11/7/07, Rajini Sivaram <ra...@googlemail.com> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > https://issues.apache.org/jira/browse/TUSCANY-1897 creates a set
> of
> > > > > bundles
> > > > > to enable Tuscany to be run inside an OSGi runtime. At the moment,
> > > there
> > > > > are
> > > > > five bundles:
> > > > >
> > > > > 1. org.apache.tuscany.sca.api.jar 18,701
> > > > > 2. org.apache.tuscany.spi.jar 430,563
> > > > > 3. org.apache.tuscany.runtime.jar 538,660
> > > > > 4. org.apache.tuscany.extensions.jar 1,374,045
> > > > > 5. org.apache.tuscany.depends.jar 57,872,558
> > > > >
> > > > > I would like to split the 3rd party bundle first and then possibly
> > the
> > > > > Tuscany extensions bundle. Ideally I would like to have bundles
> > which
> > > > > match
> > > > > the jar files provided in "distribution" so that OSGi manifest
> > headers
> > > > can
> > > > > be added to the jars in "distribution" enabling a binary Tuscany
> > > > > distribution to be run under OSGi.
> > > > >
> > > > > I would like to satisfy as many of Sebastien's use cases (
> > > > > http://marc.info/?l=tuscany-dev&m=119326781123561&w=2) as
> possible.
> > > But
> > > > I
> > > > > am
> > > > > not sure what the granularity of the bundles should be if we want
> to
> > > > have
> > > > > the same set of jars for both an OSGi and non-OSGi distribution.
> > More
> > > > fine
> > > > > grained jars provide better versioning under OSGi, but requires
> the
> > > > > maintenance of more package dependencies in the manifest files.
> > Would
> > > it
> > > > > be
> > > > > better to group related 3rd party jars together (eg. all Axis2
> > related
> > > > > jars
> > > > > into one bundle) where each jar belongs to one and only one
> bundle?
> > > > >
> > > > > Any thoughts on what the Tuscany distribution should look like
> > (should
> > > > it
> > > > > continue to be the current list of jars, or should related jars be
> > > > grouped
> > > > > together), and on the granularity required for versioning when
> > running
> > > > > Tuscany under OSGi are appreciated.
> > > > >
> > > > >
> > > > > Ant,
> > > > >
> > > > > Would it be possible for you to provide a list of third party jars
> > > used
> > > > by
> > > > > each extension? Since maven dependencies in the extension/pom.xml
> > > > include
> > > > > the dependencies for testing (sometimes without a scope), I am not
> > > sure
> > > > if
> > > > > I
> > > > > could use a dependency list generated by maven.
> > > > >
> > > > >
> > > > > Thank you...
> > > > >
> > > > > Regards,
> > > > >
> > > > > Rajini
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 10/25/07, ant elder <an...@gmail.com> wrote:
> > > > > >
> > > > > > On 10/25/07, Rajini Sivaram <ra...@googlemail.com>
> wrote:
> > > > > >
> > > > > > <snip>
> > > > > >
> > > > > > This does imply splitting both Tuscany extension bundle
> > > > > > > and the big 3rd party bundle, into smaller chunks. Because of
> > its
> > > > > size,
> > > > > > I
> > > > > > > am
> > > > > > > more inclined to split the 3rd party bundle into smaller
> bundles
> > > > first
> > > > > > > (though I have no idea where to start with this huge big list
> of
> > > jar
> > > > > > > files).
> > > > > >
> > > > > >
> > > > > > I can help with that, after doing lots of releases i've a good
> > > > > > understanding
> > > > > > of what each jar is for and what uses it. How about starting
> with
> > > > > whatever
> > > > > > bundle make up is easiest for you and then we can juggle things
> > > around
> > > > > to
> > > > > > get to something everyone is happy with.
> > > > > >
> > > > > > ...ant
> > > > > >
> > > > >
> > > >
> > > > Hi Rajini
> > > >
> > > > Some OSGi novice questions...
> > > >
> > > > Is there any automation available for management the OSGi manifests?
> > > > Do any of the jars we depend on already come with suitable manifest
> > > > information for grouping jars?
> > > >
> > > > I was trying to work out how to get the non-test dependency list the
> > > other
> > > > day. I didn't look that hard but the answer wasn't obvious. The only
> > > > (semi-)automatic way I can think of doing it is to comment out the
> > test
> > > > dependencies and then look at the maven classpath that results (e.g.
> > mvn
> > > > dependency:build-classpath)
> > > >
> > > > Regards
> > > >
> > > > Simon
> > > >
> > >
> >
>
Hi
I've done a bit of work on this trying to work out how to answer the
question. Firstly I spent a bit of time looking at various maven plugins
that do dependency processing. Along the way I found out some interesting
things...
This is slightly off topic but CxF have a new NOTICE format that is produced
by the remote dependency plugin. I've had a play with it and I think we
should consider setting it up for Tuscany.
Back to the matter at hand. I wanted something that printed out all the
dependencies in a simple textual format so that I could analyse them.
Nothing came to hand immediately (I'm sure there is something but I couldn't
find it) so I knocked up a simple plugin to print out each project
dependency along with the transitive dependency path that caused the
dependency to be included.
FYI - the plugin is in my sandbox (
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/maven-sca-dependencies/
)
I ran this plugin against all the modules, concatenated all the output
together into a single file and then sorted it so that I can see, for each
artifact what depends on it. Here's the result (
http://people.apache.org/~slaws/dependencies.htm)
What I'm looking at now it any inconsistencies that appear in this list, for
examples, things that are test dependencies for one module but runtime
dependencies for another. It'd be great it you can take a look also and we
can discuss here how best to work toward the answer you need about ensuring
that dependencies are properly scoped.
Regards
Simon
Re: OSGi-based Tuscany runtime
Posted by Rajini Sivaram <ra...@googlemail.com>.
Simon,
Thank you. Yes, I would really appreciate your help in sorting out the poms.
Thank you...
Regards,
Rajini
On 11/8/07, Simon Laws <si...@googlemail.com> wrote:
>
> Hi Rajini
>
> I'd forgotten about project-info-reports. Thanks for reminding me!. I
> think
> the answer here is for us to get our poms right so that all dependencies
> have the correct scope. I'm happy to help out here. It's easy enough to
> work
> out which are compile time dependencies but it's note clear that we are
> marking runtime/test dependencies accurately. I don't think there is an
> automatic way of distinguishing.
>
> Simon
>
> On 11/8/07, Rajini Sivaram <ra...@googlemail.com> wrote:
> >
> > Simon,
> >
> > maven-bundle-plugin can be used to generate manifest files for the jar
> > files, but the recommended practice is to explicitly specify the
> exported
> > packages rather than export everything from the jar. I tried to use this
> > to
> > generate manifest files for all the third party jars separately, but I
> > couldn't get these jars to install and resolve under Felix. So at the
> > moment, there is a single large third party jar with hardcoded
> > export-packages. Once the bundles are finalized, I will try and use
> > maven-bundle-plugin to generate as much of the manifest as possible.
> >
> > Most of the 3rd party jars do not have OSGi manifest headers ( a few
> like
> > SDO do). I will try and use existing headers wherever they are available
> > (again, I will try to do this after the bundles are finalized).
> >
> > I had a look at the dependency graph generated by "mvn
> > project-info-reports:dependencies", and the dependency tree format looks
> > much more usable to generate a full visual graph of the dependencies,
> > compared to a flat classpath. My only concern is that many of the test
> > dependencies in the modules are not marked with scope test and would
> > probably result in unnecessary dependencies (and I am not sure which
> > dependencies I can safely remove).
> >
> > Thank you...
> >
> > Regards,
> >
> > Rajini
> >
> > On 11/7/07, Simon Laws <si...@googlemail.com> wrote:
> > >
> > > On 11/7/07, Rajini Sivaram <ra...@googlemail.com> wrote:
> > > >
> > > > Hello,
> > > >
> > > > https://issues.apache.org/jira/browse/TUSCANY-1897 creates a set of
> > > > bundles
> > > > to enable Tuscany to be run inside an OSGi runtime. At the moment,
> > there
> > > > are
> > > > five bundles:
> > > >
> > > > 1. org.apache.tuscany.sca.api.jar 18,701
> > > > 2. org.apache.tuscany.spi.jar 430,563
> > > > 3. org.apache.tuscany.runtime.jar 538,660
> > > > 4. org.apache.tuscany.extensions.jar 1,374,045
> > > > 5. org.apache.tuscany.depends.jar 57,872,558
> > > >
> > > > I would like to split the 3rd party bundle first and then possibly
> the
> > > > Tuscany extensions bundle. Ideally I would like to have bundles
> which
> > > > match
> > > > the jar files provided in "distribution" so that OSGi manifest
> headers
> > > can
> > > > be added to the jars in "distribution" enabling a binary Tuscany
> > > > distribution to be run under OSGi.
> > > >
> > > > I would like to satisfy as many of Sebastien's use cases (
> > > > http://marc.info/?l=tuscany-dev&m=119326781123561&w=2) as possible.
> > But
> > > I
> > > > am
> > > > not sure what the granularity of the bundles should be if we want to
> > > have
> > > > the same set of jars for both an OSGi and non-OSGi distribution.
> More
> > > fine
> > > > grained jars provide better versioning under OSGi, but requires the
> > > > maintenance of more package dependencies in the manifest files.
> Would
> > it
> > > > be
> > > > better to group related 3rd party jars together (eg. all Axis2
> related
> > > > jars
> > > > into one bundle) where each jar belongs to one and only one bundle?
> > > >
> > > > Any thoughts on what the Tuscany distribution should look like
> (should
> > > it
> > > > continue to be the current list of jars, or should related jars be
> > > grouped
> > > > together), and on the granularity required for versioning when
> running
> > > > Tuscany under OSGi are appreciated.
> > > >
> > > >
> > > > Ant,
> > > >
> > > > Would it be possible for you to provide a list of third party jars
> > used
> > > by
> > > > each extension? Since maven dependencies in the extension/pom.xml
> > > include
> > > > the dependencies for testing (sometimes without a scope), I am not
> > sure
> > > if
> > > > I
> > > > could use a dependency list generated by maven.
> > > >
> > > >
> > > > Thank you...
> > > >
> > > > Regards,
> > > >
> > > > Rajini
> > > >
> > > >
> > > >
> > > >
> > > > On 10/25/07, ant elder <an...@gmail.com> wrote:
> > > > >
> > > > > On 10/25/07, Rajini Sivaram <ra...@googlemail.com> wrote:
> > > > >
> > > > > <snip>
> > > > >
> > > > > This does imply splitting both Tuscany extension bundle
> > > > > > and the big 3rd party bundle, into smaller chunks. Because of
> its
> > > > size,
> > > > > I
> > > > > > am
> > > > > > more inclined to split the 3rd party bundle into smaller bundles
> > > first
> > > > > > (though I have no idea where to start with this huge big list of
> > jar
> > > > > > files).
> > > > >
> > > > >
> > > > > I can help with that, after doing lots of releases i've a good
> > > > > understanding
> > > > > of what each jar is for and what uses it. How about starting with
> > > > whatever
> > > > > bundle make up is easiest for you and then we can juggle things
> > around
> > > > to
> > > > > get to something everyone is happy with.
> > > > >
> > > > > ...ant
> > > > >
> > > >
> > >
> > > Hi Rajini
> > >
> > > Some OSGi novice questions...
> > >
> > > Is there any automation available for management the OSGi manifests?
> > > Do any of the jars we depend on already come with suitable manifest
> > > information for grouping jars?
> > >
> > > I was trying to work out how to get the non-test dependency list the
> > other
> > > day. I didn't look that hard but the answer wasn't obvious. The only
> > > (semi-)automatic way I can think of doing it is to comment out the
> test
> > > dependencies and then look at the maven classpath that results (e.g.
> mvn
> > > dependency:build-classpath)
> > >
> > > Regards
> > >
> > > Simon
> > >
> >
>
Re: OSGi-based Tuscany runtime
Posted by Simon Laws <si...@googlemail.com>.
Hi Rajini
I'd forgotten about project-info-reports. Thanks for reminding me!. I think
the answer here is for us to get our poms right so that all dependencies
have the correct scope. I'm happy to help out here. It's easy enough to work
out which are compile time dependencies but it's note clear that we are
marking runtime/test dependencies accurately. I don't think there is an
automatic way of distinguishing.
Simon
On 11/8/07, Rajini Sivaram <ra...@googlemail.com> wrote:
>
> Simon,
>
> maven-bundle-plugin can be used to generate manifest files for the jar
> files, but the recommended practice is to explicitly specify the exported
> packages rather than export everything from the jar. I tried to use this
> to
> generate manifest files for all the third party jars separately, but I
> couldn't get these jars to install and resolve under Felix. So at the
> moment, there is a single large third party jar with hardcoded
> export-packages. Once the bundles are finalized, I will try and use
> maven-bundle-plugin to generate as much of the manifest as possible.
>
> Most of the 3rd party jars do not have OSGi manifest headers ( a few like
> SDO do). I will try and use existing headers wherever they are available
> (again, I will try to do this after the bundles are finalized).
>
> I had a look at the dependency graph generated by "mvn
> project-info-reports:dependencies", and the dependency tree format looks
> much more usable to generate a full visual graph of the dependencies,
> compared to a flat classpath. My only concern is that many of the test
> dependencies in the modules are not marked with scope test and would
> probably result in unnecessary dependencies (and I am not sure which
> dependencies I can safely remove).
>
> Thank you...
>
> Regards,
>
> Rajini
>
> On 11/7/07, Simon Laws <si...@googlemail.com> wrote:
> >
> > On 11/7/07, Rajini Sivaram <ra...@googlemail.com> wrote:
> > >
> > > Hello,
> > >
> > > https://issues.apache.org/jira/browse/TUSCANY-1897 creates a set of
> > > bundles
> > > to enable Tuscany to be run inside an OSGi runtime. At the moment,
> there
> > > are
> > > five bundles:
> > >
> > > 1. org.apache.tuscany.sca.api.jar 18,701
> > > 2. org.apache.tuscany.spi.jar 430,563
> > > 3. org.apache.tuscany.runtime.jar 538,660
> > > 4. org.apache.tuscany.extensions.jar 1,374,045
> > > 5. org.apache.tuscany.depends.jar 57,872,558
> > >
> > > I would like to split the 3rd party bundle first and then possibly the
> > > Tuscany extensions bundle. Ideally I would like to have bundles which
> > > match
> > > the jar files provided in "distribution" so that OSGi manifest headers
> > can
> > > be added to the jars in "distribution" enabling a binary Tuscany
> > > distribution to be run under OSGi.
> > >
> > > I would like to satisfy as many of Sebastien's use cases (
> > > http://marc.info/?l=tuscany-dev&m=119326781123561&w=2) as possible.
> But
> > I
> > > am
> > > not sure what the granularity of the bundles should be if we want to
> > have
> > > the same set of jars for both an OSGi and non-OSGi distribution. More
> > fine
> > > grained jars provide better versioning under OSGi, but requires the
> > > maintenance of more package dependencies in the manifest files. Would
> it
> > > be
> > > better to group related 3rd party jars together (eg. all Axis2 related
> > > jars
> > > into one bundle) where each jar belongs to one and only one bundle?
> > >
> > > Any thoughts on what the Tuscany distribution should look like (should
> > it
> > > continue to be the current list of jars, or should related jars be
> > grouped
> > > together), and on the granularity required for versioning when running
> > > Tuscany under OSGi are appreciated.
> > >
> > >
> > > Ant,
> > >
> > > Would it be possible for you to provide a list of third party jars
> used
> > by
> > > each extension? Since maven dependencies in the extension/pom.xml
> > include
> > > the dependencies for testing (sometimes without a scope), I am not
> sure
> > if
> > > I
> > > could use a dependency list generated by maven.
> > >
> > >
> > > Thank you...
> > >
> > > Regards,
> > >
> > > Rajini
> > >
> > >
> > >
> > >
> > > On 10/25/07, ant elder <an...@gmail.com> wrote:
> > > >
> > > > On 10/25/07, Rajini Sivaram <ra...@googlemail.com> wrote:
> > > >
> > > > <snip>
> > > >
> > > > This does imply splitting both Tuscany extension bundle
> > > > > and the big 3rd party bundle, into smaller chunks. Because of its
> > > size,
> > > > I
> > > > > am
> > > > > more inclined to split the 3rd party bundle into smaller bundles
> > first
> > > > > (though I have no idea where to start with this huge big list of
> jar
> > > > > files).
> > > >
> > > >
> > > > I can help with that, after doing lots of releases i've a good
> > > > understanding
> > > > of what each jar is for and what uses it. How about starting with
> > > whatever
> > > > bundle make up is easiest for you and then we can juggle things
> around
> > > to
> > > > get to something everyone is happy with.
> > > >
> > > > ...ant
> > > >
> > >
> >
> > Hi Rajini
> >
> > Some OSGi novice questions...
> >
> > Is there any automation available for management the OSGi manifests?
> > Do any of the jars we depend on already come with suitable manifest
> > information for grouping jars?
> >
> > I was trying to work out how to get the non-test dependency list the
> other
> > day. I didn't look that hard but the answer wasn't obvious. The only
> > (semi-)automatic way I can think of doing it is to comment out the test
> > dependencies and then look at the maven classpath that results (e.g. mvn
> > dependency:build-classpath)
> >
> > Regards
> >
> > Simon
> >
>
Re: OSGi-based Tuscany runtime
Posted by Rajini Sivaram <ra...@googlemail.com>.
Simon,
maven-bundle-plugin can be used to generate manifest files for the jar
files, but the recommended practice is to explicitly specify the exported
packages rather than export everything from the jar. I tried to use this to
generate manifest files for all the third party jars separately, but I
couldn't get these jars to install and resolve under Felix. So at the
moment, there is a single large third party jar with hardcoded
export-packages. Once the bundles are finalized, I will try and use
maven-bundle-plugin to generate as much of the manifest as possible.
Most of the 3rd party jars do not have OSGi manifest headers ( a few like
SDO do). I will try and use existing headers wherever they are available
(again, I will try to do this after the bundles are finalized).
I had a look at the dependency graph generated by "mvn
project-info-reports:dependencies", and the dependency tree format looks
much more usable to generate a full visual graph of the dependencies,
compared to a flat classpath. My only concern is that many of the test
dependencies in the modules are not marked with scope test and would
probably result in unnecessary dependencies (and I am not sure which
dependencies I can safely remove).
Thank you...
Regards,
Rajini
On 11/7/07, Simon Laws <si...@googlemail.com> wrote:
>
> On 11/7/07, Rajini Sivaram <ra...@googlemail.com> wrote:
> >
> > Hello,
> >
> > https://issues.apache.org/jira/browse/TUSCANY-1897 creates a set of
> > bundles
> > to enable Tuscany to be run inside an OSGi runtime. At the moment, there
> > are
> > five bundles:
> >
> > 1. org.apache.tuscany.sca.api.jar 18,701
> > 2. org.apache.tuscany.spi.jar 430,563
> > 3. org.apache.tuscany.runtime.jar 538,660
> > 4. org.apache.tuscany.extensions.jar 1,374,045
> > 5. org.apache.tuscany.depends.jar 57,872,558
> >
> > I would like to split the 3rd party bundle first and then possibly the
> > Tuscany extensions bundle. Ideally I would like to have bundles which
> > match
> > the jar files provided in "distribution" so that OSGi manifest headers
> can
> > be added to the jars in "distribution" enabling a binary Tuscany
> > distribution to be run under OSGi.
> >
> > I would like to satisfy as many of Sebastien's use cases (
> > http://marc.info/?l=tuscany-dev&m=119326781123561&w=2) as possible. But
> I
> > am
> > not sure what the granularity of the bundles should be if we want to
> have
> > the same set of jars for both an OSGi and non-OSGi distribution. More
> fine
> > grained jars provide better versioning under OSGi, but requires the
> > maintenance of more package dependencies in the manifest files. Would it
> > be
> > better to group related 3rd party jars together (eg. all Axis2 related
> > jars
> > into one bundle) where each jar belongs to one and only one bundle?
> >
> > Any thoughts on what the Tuscany distribution should look like (should
> it
> > continue to be the current list of jars, or should related jars be
> grouped
> > together), and on the granularity required for versioning when running
> > Tuscany under OSGi are appreciated.
> >
> >
> > Ant,
> >
> > Would it be possible for you to provide a list of third party jars used
> by
> > each extension? Since maven dependencies in the extension/pom.xml
> include
> > the dependencies for testing (sometimes without a scope), I am not sure
> if
> > I
> > could use a dependency list generated by maven.
> >
> >
> > Thank you...
> >
> > Regards,
> >
> > Rajini
> >
> >
> >
> >
> > On 10/25/07, ant elder <an...@gmail.com> wrote:
> > >
> > > On 10/25/07, Rajini Sivaram <ra...@googlemail.com> wrote:
> > >
> > > <snip>
> > >
> > > This does imply splitting both Tuscany extension bundle
> > > > and the big 3rd party bundle, into smaller chunks. Because of its
> > size,
> > > I
> > > > am
> > > > more inclined to split the 3rd party bundle into smaller bundles
> first
> > > > (though I have no idea where to start with this huge big list of jar
> > > > files).
> > >
> > >
> > > I can help with that, after doing lots of releases i've a good
> > > understanding
> > > of what each jar is for and what uses it. How about starting with
> > whatever
> > > bundle make up is easiest for you and then we can juggle things around
> > to
> > > get to something everyone is happy with.
> > >
> > > ...ant
> > >
> >
>
> Hi Rajini
>
> Some OSGi novice questions...
>
> Is there any automation available for management the OSGi manifests?
> Do any of the jars we depend on already come with suitable manifest
> information for grouping jars?
>
> I was trying to work out how to get the non-test dependency list the other
> day. I didn't look that hard but the answer wasn't obvious. The only
> (semi-)automatic way I can think of doing it is to comment out the test
> dependencies and then look at the maven classpath that results (e.g. mvn
> dependency:build-classpath)
>
> Regards
>
> Simon
>
Re: OSGi-based Tuscany runtime
Posted by Simon Laws <si...@googlemail.com>.
On 11/7/07, Rajini Sivaram <ra...@googlemail.com> wrote:
>
> Hello,
>
> https://issues.apache.org/jira/browse/TUSCANY-1897 creates a set of
> bundles
> to enable Tuscany to be run inside an OSGi runtime. At the moment, there
> are
> five bundles:
>
> 1. org.apache.tuscany.sca.api.jar 18,701
> 2. org.apache.tuscany.spi.jar 430,563
> 3. org.apache.tuscany.runtime.jar 538,660
> 4. org.apache.tuscany.extensions.jar 1,374,045
> 5. org.apache.tuscany.depends.jar 57,872,558
>
> I would like to split the 3rd party bundle first and then possibly the
> Tuscany extensions bundle. Ideally I would like to have bundles which
> match
> the jar files provided in "distribution" so that OSGi manifest headers can
> be added to the jars in "distribution" enabling a binary Tuscany
> distribution to be run under OSGi.
>
> I would like to satisfy as many of Sebastien's use cases (
> http://marc.info/?l=tuscany-dev&m=119326781123561&w=2) as possible. But I
> am
> not sure what the granularity of the bundles should be if we want to have
> the same set of jars for both an OSGi and non-OSGi distribution. More fine
> grained jars provide better versioning under OSGi, but requires the
> maintenance of more package dependencies in the manifest files. Would it
> be
> better to group related 3rd party jars together (eg. all Axis2 related
> jars
> into one bundle) where each jar belongs to one and only one bundle?
>
> Any thoughts on what the Tuscany distribution should look like (should it
> continue to be the current list of jars, or should related jars be grouped
> together), and on the granularity required for versioning when running
> Tuscany under OSGi are appreciated.
>
>
> Ant,
>
> Would it be possible for you to provide a list of third party jars used by
> each extension? Since maven dependencies in the extension/pom.xml include
> the dependencies for testing (sometimes without a scope), I am not sure if
> I
> could use a dependency list generated by maven.
>
>
> Thank you...
>
> Regards,
>
> Rajini
>
>
>
>
> On 10/25/07, ant elder <an...@gmail.com> wrote:
> >
> > On 10/25/07, Rajini Sivaram <ra...@googlemail.com> wrote:
> >
> > <snip>
> >
> > This does imply splitting both Tuscany extension bundle
> > > and the big 3rd party bundle, into smaller chunks. Because of its
> size,
> > I
> > > am
> > > more inclined to split the 3rd party bundle into smaller bundles first
> > > (though I have no idea where to start with this huge big list of jar
> > > files).
> >
> >
> > I can help with that, after doing lots of releases i've a good
> > understanding
> > of what each jar is for and what uses it. How about starting with
> whatever
> > bundle make up is easiest for you and then we can juggle things around
> to
> > get to something everyone is happy with.
> >
> > ...ant
> >
>
Hi Rajini
Some OSGi novice questions...
Is there any automation available for management the OSGi manifests?
Do any of the jars we depend on already come with suitable manifest
information for grouping jars?
I was trying to work out how to get the non-test dependency list the other
day. I didn't look that hard but the answer wasn't obvious. The only
(semi-)automatic way I can think of doing it is to comment out the test
dependencies and then look at the maven classpath that results (e.g. mvn
dependency:build-classpath)
Regards
Simon