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 <[EMAIL PROTECTED]> wrote: > > On Nov 12, 2007 12:15 PM, Simon Laws <[EMAIL PROTECTED]> wrote: > > > On Nov 12, 2007 11:58 AM, ant elder <[EMAIL PROTECTED]> wrote: > > > > > On Nov 12, 2007 11:42 AM, Simon Laws <[EMAIL PROTECTED]> > wrote: > > > > > > > On Nov 8, 2007 10:56 AM, Rajini Sivaram < > [EMAIL PROTECTED]> > > > > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > On 11/7/07, Rajini Sivaram <[EMAIL PROTECTED]> > > 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 <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > On 10/25/07, Rajini Sivaram < > [EMAIL PROTECTED]> > > > > > 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 >
