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
