Just a thought, would I be right in guessing that if ever our
SdoBundleActivator is touched in the runtime, then the environment would be
expected to provide the classes to satisfy
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
?
in which case I think declaring a "provided" scope for the felix dependency
would be the right way to do things
Kelvin.
2008/6/3 kelvin goodson <[EMAIL PROTECTED]>:
> Thanks Ant, that looks like progress, but the felix framework jar is now
> not in the list of distributed jars.
>
> Kelvin.
>
> 2008/6/3 ant elder <[EMAIL PROTECTED]>:
>
> Adding an exclude for felix to the distribution pom can fix that, eg here's
>> local changes i have just tried:
>>
>> Index: src/main/assembly/bin.xml
>> ===================================================================
>> --- src/main/assembly/bin.xml (revision 662488)
>> +++ src/main/assembly/bin.xml (working copy)
>> @@ -120,13 +120,13 @@
>> <dependencySets>
>> <dependencySet>
>>
>> <outputDirectory>tuscany-sdo-${sdo.version}/lib</outputDirectory>
>> - <includes>
>> -
>> <include>org.apache.tuscany.sdo:tuscany-sdo-api-r2.1</include>
>> + <!-- includes>
>> +
>> <include>org.apache.tuscany.sdo:tuscany-sdo-api-r2.1</include>
>> <include>org.apache.tuscany.sdo:tuscany-sdo-lib</include>
>> <include>org.apache.tuscany.sdo:tuscany-sdo-impl</include>
>>
>> <include>org.apache.tuscany.sdo:tuscany-sdo-tools</include>
>> <include>org.apache.tuscany.sdo:sample-sdo</include>
>> - </includes>
>> + </includes -->
>> <fileMode>0644</fileMode>
>> </dependencySet>
>>
>> Index: pom.xml
>> ===================================================================
>> --- pom.xml (revision 662488)
>> +++ pom.xml (working copy)
>> @@ -56,6 +56,12 @@
>> <groupId>org.apache.tuscany.sdo</groupId>
>> <artifactId>tuscany-sdo-impl</artifactId>
>> <version>${pom.version}</version>
>> + <exclusions>
>> + <exclusion>
>> + <groupId>org.apache.felix</groupId>
>> + <artifactId>org.apache.felix.main</artifactId>
>> + </exclusion>
>> + </exclusions>
>> </dependency>
>> <dependency>
>> <groupId>org.apache.tuscany.sdo</groupId>
>> @@ -67,6 +73,7 @@
>> <artifactId>sample-sdo</artifactId>
>> <version>${pom.version}</version>
>> </dependency>
>> +
>> </dependencies>
>>
>> <build>
>>
>> Which results in a lib directory containing:
>>
>> backport-util-concurrent-3.0.jar
>> codegen-2.2.3.jar
>> codegen-ecore-2.2.3.jar
>> common-2.2.3.jar
>> ecore-2.2.3.jar
>> ecore-change-2.2.3.jar
>> ecore-xmi-2.2.3.jar
>> sample-sdo-1.1.1-incubating-SNAPSHOT.jar
>> stax-api-1.0.1.jar
>> tuscany-sdo-api-r2.1-1.1.1-incubating-SNAPSHOT.jar
>> tuscany-sdo-impl-1.1.1-incubating-SNAPSHOT.jar
>> tuscany-sdo-lib-1.1.1-incubating-SNAPSHOT.jar
>> tuscany-sdo-tools-1.1.1-incubating-SNAPSHOT.jar
>> wstx-asl-3.2.1.jar
>> xsd-2.2.3.jar
>>
>> ...ant
>>
>> On Tue, Jun 3, 2008 at 11:31 AM, kelvin goodson <[EMAIL PROTECTED]>
>> wrote:
>>
>> > I had an offline chat with Rajini. It seems we need just the framework
>> jar
>> > of felix in the distro, but if the dependency on felix is declared as
>> test
>> > scope in the pom, then that jar is not available to main phase of the
>> > build. If its not declared as test scope then we get 5 felix jars in
>> the
>> > binary distro. Rajini's going to take a look when she gets some time.
>> >
>> > Kelvin.
>> >
>> >
>> > 2008/6/3 kelvin goodson <[EMAIL PROTECTED]>:
>> >
>> >> The felix jars were introduced in the fix for "SDO does not work with
>> >> OSGi" [1] in commit 620763 [2]. I don't know if this is expected
>> >> behaviour, not being an OSGI expert. Comments anyone?
>> >>
>> >> Kelvin.
>> >>
>> >> [1] https://issues.apache.org/jira/browse/TUSCANY-1293
>> >> [2] http://svn.apache.org/viewcvs?view=rev&rev=620763
>> >>
>> >> 2008/6/3 kelvin goodson <[EMAIL PROTECTED]>:
>> >>
>> >> The required libraries are
>> >>>
>> >>> sample-sdo-%RELEASE%.jar
>> >>> sdo-api-r2.1-%RELEASE%.jar
>> >>> tuscany-sdo-lib-%RELEASE%.jar
>> >>> tuscany-sdo-impl-%RELEASE%.jar
>> >>> tuscany-sdo-tools-%RELEASE%.jar
>> >>> codegen-ecore-2.2.3.jar
>> >>> codegen-2.2.3.jar
>> >>> ecore-2.2.3.jar
>> >>> ecore-change-2.2.3.jar
>> >>> ecore-xmi-2.2.3.jar
>> >>> common-2.2.3.jar
>> >>> xsd-2.2.3.jar
>> >>> stax-api-1.0.1.jar
>> >>> wstx-asl-3.2.0.jar
>> >>>
>> >>> with
>> >>> backport-util-concurrent being optional if you want threadsafe
>> >>> collections with Java 1.4 IIRC
>> >>>
>> >>> The felix jar inclusions were introduced some time between commit
>> level
>> >>> 600913 and 627754; I'm working on narrowing this down at the moment.
>> >>>
>> >>> Kelvin.
>> >>>
>> >>>
>> >>> 2008/6/2 ant elder <[EMAIL PROTECTED]>:
>> >>>
>> >>> It is strange.
>> >>>>
>> >>>> Removing the <includes> at the bottom of the assembly bin.xml changes
>> it
>> >>>> so
>> >>>> that the dependencies do get included again, but several felix
>> >>>> dependencies
>> >>>> also get dragged in. What is the complete list of jars that should be
>> >>>> included?
>> >>>>
>> >>>> ...ant
>> >>>>
>> >>>> On Mon, Jun 2, 2008 at 6:02 PM, kelvin goodson <
>> [EMAIL PROTECTED]>
>> >>>> wrote:
>> >>>>
>> >>>> > This failure also occurs with the 2.1 version and the 2.2-beta-1
>> >>>> version.
>> >>>> > The current trunk version is 2.2-beta-3-SNAPSHOT, which I haven't
>> >>>> found in
>> >>>> > a repository yet, so the only version that seems ever to have
>> worked
>> >>>> is
>> >>>> > the
>> >>>> > 2.2-SNAPSHOT version. I have taken a look at the assembly plugin
>> >>>> JIRAs,
>> >>>> > but
>> >>>> > it's hard to trawl that since so many JIRAs reference the word
>> >>>> dependency.
>> >>>> > It's not clear to me whether we benefited from a freak bug that was
>> to
>> >>>> our
>> >>>> > advantage in the 2.2-SNAPSHOT version or whether all the other
>> >>>> versions
>> >>>> > have
>> >>>> > a bug/bugs.
>> >>>> >
>> >>>> > Kelvin.
>> >>>> >
>> >>>> > 2008/6/2 kelvin goodson <[EMAIL PROTECTED]>:
>> >>>> >
>> >>>> > > I have pinned down the change that caused the absence of EMF jars
>> in
>> >>>> the
>> >>>> > > distribution zip to be the switch from the maven assembly plugin
>> >>>> version
>> >>>> > > 2.2-SNAPSHOT to the 2.2-beta-2 as altered here [1]. I hope to
>> >>>> look at
>> >>>> > > this again soon, but have to stop for now. If anyone has any
>> views
>> >>>> on
>> >>>> > what
>> >>>> > > version we should be using please pipe up.
>> >>>> > >
>> >>>> > > Kelvin.
>> >>>> > >
>> >>>> > > [1]
>> >>>> > >
>> >>>> >
>> >>>>
>> http://svn.apache.org/viewvc/incubator/tuscany/java/sdo/pom.xml?r1=628691&r2=642349&pathrev=642349&diff_format=h
>> >>>> > >
>> >>>> > > Kelvin.
>> >>>> > >
>> >>>> > > 2008/5/19 kelvin goodson <[EMAIL PROTECTED]>:
>> >>>> > >
>> >>>> > > I'm looking at fixing a problem wrt running the samples at the
>> >>>> moment.
>> >>>> > >>
>> >>>> > >> Also, I found that with a combination of using IBM JDK 1.5 and
>> >>>> maven
>> >>>> > 2.0.7
>> >>>> > >> I got hit by http://jira.codehaus.org/browse/MJAVADOC-135 when
>> >>>> trying
>> >>>> > to
>> >>>> > >> build from the top. We say in our BUILDING doc that 2.0.7 is
>> OK,
>> >>>> > perhaps
>> >>>> > >> if we need to respin we should raise that in order to avoid IBM
>> JDK
>> >>>> > users
>> >>>> > >> hitting this issue. It's fine with 2.0.9
>> >>>> > >>
>> >>>> > >> Kelvin.
>> >>>> > >>
>> >>>> > >>
>> >>>> > >> 2008/5/18 ant elder <[EMAIL PROTECTED]>:
>> >>>> > >>
>> >>>> > >> Please review and vote on the SDO 1.1.1 release.
>> >>>> > >>>
>> >>>> > >>> The artifacts including binary and source distributions,
>> staging
>> >>>> maven
>> >>>> > >>> repo
>> >>>> > >>> and release notes are available at
>> >>>> > >>> http://people.apache.org/~antelder/tuscany/sdo/1.1.1-RC1/<http://people.apache.org/%7Eantelder/tuscany/sdo/1.1.1-RC1/>
>> <http://people.apache.org/%7Eantelder/tuscany/sdo/1.1.1-RC1/>
>> >>>> <http://people.apache.org/%7Eantelder/tuscany/sdo/1.1.1-RC1/>
>> >>>> > <http://people.apache.org/%7Eantelder/tuscany/sdo/1.1.1-RC1/>
>> >>>> > >>> <http://people.apache.org/%7Eantelder/tuscany/sdo/1.1.1-RC1/>.
>> >>>> > >>> The only difference between this and the 1.1 release is the fix
>> >>>> for
>> >>>> > >>> http://issues.apache.org/jira/browse/TUSCANY-2240.
>> >>>> > >>>
>> >>>> > >>> +1 from me.
>> >>>> > >>>
>> >>>> > >>> ...ant
>> >>>> > >>>
>> >>>> > >>
>> >>>> > >>
>> >>>> > >
>> >>>> >
>> >>>>
>> >>>
>> >>>
>> >>
>> >
>>
>
>
