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 > > > > > >
