Re: [VOTE] Release Maven SCR Plugin 1.0.5
+1 Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [VOTE] Release Maven SCR Plugin 1.0.5
Carsten Ziegeler wrote: http://people.apache.org/~cziegeler/releasesmaven-scr-plugin/ Sorry this url is wrong, its actually: http://people.apache.org/~cziegeler/releases/maven-scr-plugin/ Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Updated: (FELIX-593) Fix handling of immediate attribute of component factories
[ https://issues.apache.org/jira/browse/FELIX-593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-593: --- Summary: Fix handling of immediate attribute of component factories (was: Fix handling of immedaite attribute of component factories) > Fix handling of immediate attribute of component factories > -- > > Key: FELIX-593 > URL: https://issues.apache.org/jira/browse/FELIX-593 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR), Maven SCR Plugin >Affects Versions: maven-scr-plugin-1.0.4, scr-1.0.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: maven-scr-plugin-1.0.5, scr-1.0.1 > > > According to the clarification regarding the immediate attribute of the > element of a Declarative services component, the validation of > the component element has to be changed. > Currently the validation assumes this definition of the immediate attribute > 112.4.3: > "immediate - Controls whether component configurations must be immediately > activated after becoming satisfied or whether activation should be delayed. > The default value is false if the service element is specified and true > otherwise. If this attribute is specified, its value must be true unless the > service element is also specified." > which does not take into account factory components. > A better description would be: > "immediate - Controls whether component configurations must be immediately > activated after becoming satisfied or whether activation should be delayed. > The default value is false if the factory attribute or if the service element > is specified and true otherwise. If this attribute is specified, its value > must be false if the factory attribute is also specified or must be true > unless the service element is also specified." > This means: > * The "scr" ComponentMetadata class must assume a different default value for > the immediate attribute for component factories and validate differently. > * The "maven-scr-plugin" Component class must assume a different default > value for the immediate attribute for component factories and validate > differently. > [1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg00092.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE] Release Maven SCR Plugin 1.0.5
Hi, we done some updates to the maven scr plugin: Bug * [FELIX-593] - Fix handling of immediate attribute of component factories Improvement * [FELIX-594] - Pretty print generated xml files New Feature * [FELIX-576] - Add support for referencing name constants for property names. So I think its time for a 1.0.5 release :) I've compiled the release candidate and put it up here: http://people.apache.org/~cziegeler/releasesmaven-scr-plugin/ The KEYS file for verifying the signature is also in this directory. So, please check the release and cast your votes - the vote will be open for 72 hours. Thanks Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Library Enabling Test Framework...?
On Wed, Jun 4, 2008 at 11:46 PM, Niclas Hedhman <[EMAIL PROTECTED]> wrote: > On Wednesday 04 June 2008 20:55, Alex Karasulu wrote: > > It sounded to me as if Robert was more interested in a integration > testing > > framework rather than the build tool used to generate the manifest and > > build the bundle. Please excuse me if I'm wrong here tho. > > Yes, I know Robert asked for integration testing, BUT if you are totally > new > to OSGi, you need to get the build right first. AND if you are "only" going > for getting your Manifest in order, and not a fully fledged OSGi app, then > that will be a lot already. > And not actively monitoring this list, it might not be apparent that BND > will > give you a lot of the things you need to get that part right. > Yep yep all good very points indeed for someone just diving in. BND is the starting point you're right. I thought there might have been some misinterpretation and it sounded to me like Robert wanted something I too desire. It was a good opportunity for me to ask again :). Seems there are more options than I had initially thought on this front thanks to people like Mr. Nodet and others pointing out the Spring-DM goods. Please do carry on ... would love to see how James goes forward. Regards, Alex
[jira] Commented: (FELIX-596) getResource() doesn't work on META-INF while getResources() does
[
https://issues.apache.org/jira/browse/FELIX-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602535#action_12602535
]
Richard S. Hall commented on FELIX-596:
---
As stated on the mailing list, I am fairly certain that we discussed this issue
within the CPEG and came to the conclusion that bundles without directory
entries are in error and should not expect to get resource URLs for the
directory entries that do not exist. I will look into it to be certain.
> getResource() doesn't work on META-INF while getResources() does
>
>
> Key: FELIX-596
> URL: https://issues.apache.org/jira/browse/FELIX-596
> Project: Felix
> Issue Type: Improvement
> Components: Framework
>Reporter: Costin Leau
>
> I think I've discovered a regression bug.
> I'm doing a getResource() on META-INF inside each bundle as part of a
> integration test but this fails on a bundle from SpringSource Bundle
> Repsitory (even though it appears to be valid).
> The Jar in question is ObjectWeb ASM:
> http://tinyurl.com/4tbljg
> Its content is:
> # jar -tvf com.springsource.org.objectweb.asm-2.2.0.jar
>467 Tue May 20 13:41:56 EEST 2008 META-INF/MANIFEST.MF
>435 Tue May 20 13:41:56 EEST 2008 org/objectweb/asm/AnnotationVisitor.class
> 3659 Tue May 20 13:41:56 EEST 2008 org/objectweb/asm/AnnotationWriter.class
>
> Basically it seems that for some reason, Felix doesn't consider META-INF/ as
> a valid path probably because it doesn't exist as a real entry in the JAR in
> the first place. There were some discussions some time ago (with Richard)
> about what the proper behaviour should be - Equinox for example will return
> an entry to the folder. In Felix getResources() works but getResource()
> fails.
> See below the tests:
> public void testCallGetResourceOnADifferentBundle() throws Exception {
> // find bundles
> Bundle[] bundles = bundleContext.getBundles();
> for (int i = 1; i < bundles.length; i++) {
> Bundle bundle = bundles[i];
> logger.debug("calling #getResource on bundle " +
> OsgiStringUtils.nullSafeNameAndSymName(bundle));
> URL url = bundle.getResource(LOCATION);
> if (!OsgiBundleUtils.isFragment(bundle))
> assertNotNull("bundle " +
> OsgiStringUtils.nullSafeNameAndSymName(bundle) + " contains no META-INF/",
> url);
> }
> }
> public void testCallGetResourcesOnADifferentBundle() throws Exception {
> // find bundles
> Bundle[] bundles = bundleContext.getBundles();
> for (int i = 1; i < bundles.length; i++) {
> Bundle bundle = bundles[i];
> logger.debug("calling #getResources on bundle " +
> OsgiStringUtils.nullSafeNameAndSymName(bundle));
> Enumeration enm = bundle.getResources(LOCATION);
> if (!OsgiBundleUtils.isFragment(bundle))
> assertNotNull("bundle " +
> OsgiStringUtils.nullSafeNameAndSymName(bundle) + " contains no META-INF/",
> enm);
> }
> }
> You can find the original test at:
> https://springframework.svn.sourceforge.net/svnroot/springframework/spring-osgi/trunk/integration-tests/tests/src/test/java/org/springframework/osgi/iandt/compliance/io/CallingResourceOnDifferentBundlesTest.java
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Searching class spaces - noob
Niclas Hedhman wrote: On Thursday 05 June 2008 04:44, Bhaskar Maddala wrote: Question : Does anyone know of a way to search class spaces for the location (bundle/jar file) from which a specified class is being loaded? If you are talking about Exported/Imported (i.e. public classes) packages, then you should be able to retrieve that info very easily from the Package Admin service. For private packages, the answer from Richard seems to reflect(!) reality, and will be framework dependent. Also, I guess my answer depends on what you mean by "location". If by "location" you mean the actual provider (i.e., the logical bundle) of the class or you mean the physical JAR file in the system. The former would be possible (but with a lot of not easy calculations), the latter would not be possible in a standard way. -> richard
Re: Searching class spaces - noob
On Thursday 05 June 2008 04:44, Bhaskar Maddala wrote: > Question : Does anyone know of a way to search class spaces for the > location (bundle/jar file) from which a specified class is being > loaded? If you are talking about Exported/Imported (i.e. public classes) packages, then you should be able to retrieve that info very easily from the Package Admin service. For private packages, the answer from Richard seems to reflect(!) reality, and will be framework dependent. Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug
Re: Library Enabling Test Framework...?
On Wednesday 04 June 2008 20:55, Alex Karasulu wrote: > It sounded to me as if Robert was more interested in a integration testing > framework rather than the build tool used to generate the manifest and > build the bundle. Please excuse me if I'm wrong here tho. Yes, I know Robert asked for integration testing, BUT if you are totally new to OSGi, you need to get the build right first. AND if you are "only" going for getting your Manifest in order, and not a fully fledged OSGi app, then that will be a lot already. And not actively monitoring this list, it might not be apparent that BND will give you a lot of the things you need to get that part right. Now, Robert, it might be helpful to know if JAMES is going to be an OSGi application (i.e. deployable as an operational server in OSGi without further work) or "just" have its manifest in proper order for others to embed it in their OSGi applications. Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug
Searching class spaces - noob
Hello, Couple of days back I sent the email with the same subject to the users mailing list, to which Richard Hall did reply, I gather Richard is also part of this mailing list, so firstly thanks for the reply Richard. I summarize the question and Richard's response below [1] I had a couple of questions that I would like to follow-up with, which I thought would be more appropriate on the dev mailing list. Are there any plans to provide such functionality (in the web console sub project perhaps)? From the response, I gather that this would not be an impossible task, however what would be the feasibility of implementing this functionality? Would the solution be specific to felix or could the bundle be deployed in other OSGi implementations (equinox, knopflerfish etc)? I ask these questions this is functionality that I am used to from application server administration consoles. Thanks Bhaskar [1] Question : Does anyone know of a way to search class spaces for the location (bundle/jar file) from which a specified class is being loaded? Reply : It might not be completely impossible, but it would require a lot of reflection over all of your bundles' content as well as the current set of wirings among them...it would not be pretty. Thanks Bhaskar
Re: svn commit: r663149 - in /felix/trunk/metatype/src/main/java/org/apache/felix/metatype: Attribute.java MetaDataReader.java
Christian van Spaandonk wrote: You're right, thanks. Created and resolved FELIX-597. Wow, a very quick bug fix :) Thanks! Regards Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Updated: (FELIX-597) Meta type service incorrectly parses attribute element content when the content is specified in value child tags
[ https://issues.apache.org/jira/browse/FELIX-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-597: --- Affects Version/s: metatype-1.0.0 Fix Version/s: metatype-1.0.1 > Meta type service incorrectly parses attribute element content when the > content is specified in value child tags > > > Key: FELIX-597 > URL: https://issues.apache.org/jira/browse/FELIX-597 > Project: Felix > Issue Type: Bug > Components: Metatype Service >Affects Versions: metatype-1.0.0 >Reporter: Christian van Spaandonk >Assignee: Christian van Spaandonk >Priority: Minor > Fix For: metatype-1.0.1 > > > Metatype resources can specify attribute content as content="my,Content"> or as > myContent. In the first > form content should be split on comma, in the latter it shouldn't. At the > moment the latter form is also split on comma. See the compendium spec > 105.6.1 for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-597) Meta type service incorrectly parses attribute element content when the content is specified in value child tags
[ https://issues.apache.org/jira/browse/FELIX-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian van Spaandonk closed FELIX-597. - > Meta type service incorrectly parses attribute element content when the > content is specified in value child tags > > > Key: FELIX-597 > URL: https://issues.apache.org/jira/browse/FELIX-597 > Project: Felix > Issue Type: Bug > Components: Metatype Service >Reporter: Christian van Spaandonk >Assignee: Christian van Spaandonk >Priority: Minor > > Metatype resources can specify attribute content as content="my,Content"> or as > myContent. In the first > form content should be split on comma, in the latter it shouldn't. At the > moment the latter form is also split on comma. See the compendium spec > 105.6.1 for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r663149 - in /felix/trunk/metatype/src/main/java/org/apache/felix/metatype: Attribute.java MetaDataReader.java
Carsten Ziegeler wrote: [EMAIL PROTECTED] schrieb: Author: christian Date: Wed Jun 4 08:00:34 2008 New Revision: 663149 URL: http://svn.apache.org/viewvc?rev=663149&view=rev Log: Fixed small bug in the meta type service: when reading meta type resources the content of an attribute tag was incorrectly split on comma's when it was provided in one or more value child tags instead of in the content argument of the attribute tag itself. Hi, could you please add a bug in jira for this issue (and set it to fixed/closed)? This helps us in keeping the changelog proper. Thanks Carsten You're right, thanks. Created and resolved FELIX-597. friendly, Christian van Spaandonk
[jira] Resolved: (FELIX-597) Meta type service incorrectly parses attribute element content when the content is specified in value child tags
[ https://issues.apache.org/jira/browse/FELIX-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian van Spaandonk resolved FELIX-597. --- Resolution: Fixed Fixed in r663149. > Meta type service incorrectly parses attribute element content when the > content is specified in value child tags > > > Key: FELIX-597 > URL: https://issues.apache.org/jira/browse/FELIX-597 > Project: Felix > Issue Type: Bug > Components: Metatype Service >Reporter: Christian van Spaandonk >Assignee: Christian van Spaandonk >Priority: Minor > > Metatype resources can specify attribute content as content="my,Content"> or as > myContent. In the first > form content should be split on comma, in the latter it shouldn't. At the > moment the latter form is also split on comma. See the compendium spec > 105.6.1 for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-597) Meta type service incorrectly parses attribute element content when the content is specified in value child tags
Meta type service incorrectly parses attribute element content when the content is specified in value child tags Key: FELIX-597 URL: https://issues.apache.org/jira/browse/FELIX-597 Project: Felix Issue Type: Bug Components: Metatype Service Reporter: Christian van Spaandonk Assignee: Christian van Spaandonk Priority: Minor Metatype resources can specify attribute content as or as myContent. In the first form content should be split on comma, in the latter it shouldn't. At the moment the latter form is also split on comma. See the compendium spec 105.6.1 for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r663149 - in /felix/trunk/metatype/src/main/java/org/apache/felix/metatype: Attribute.java MetaDataReader.java
[EMAIL PROTECTED] schrieb: Author: christian Date: Wed Jun 4 08:00:34 2008 New Revision: 663149 URL: http://svn.apache.org/viewvc?rev=663149&view=rev Log: Fixed small bug in the meta type service: when reading meta type resources the content of an attribute tag was incorrectly split on comma's when it was provided in one or more value child tags instead of in the content argument of the attribute tag itself. Hi, could you please add a bug in jira for this issue (and set it to fixed/closed)? This helps us in keeping the changelog proper. Thanks Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Commented: (FELIX-596) getResource() doesn't work on META-INF while getResources() does
[
https://issues.apache.org/jira/browse/FELIX-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602362#action_12602362
]
Costin Leau commented on FELIX-596:
---
Thanks for the quick reply Richard.
The jar doesn't have the entry so I guess that's normal behaviour.
Probably getResources() returns an entry from a different jar (maybe the osgi
platform itself).
Thanks again.
Cheers,
> getResource() doesn't work on META-INF while getResources() does
>
>
> Key: FELIX-596
> URL: https://issues.apache.org/jira/browse/FELIX-596
> Project: Felix
> Issue Type: Improvement
> Components: Framework
>Reporter: Costin Leau
>
> I think I've discovered a regression bug.
> I'm doing a getResource() on META-INF inside each bundle as part of a
> integration test but this fails on a bundle from SpringSource Bundle
> Repsitory (even though it appears to be valid).
> The Jar in question is ObjectWeb ASM:
> http://tinyurl.com/4tbljg
> Its content is:
> # jar -tvf com.springsource.org.objectweb.asm-2.2.0.jar
>467 Tue May 20 13:41:56 EEST 2008 META-INF/MANIFEST.MF
>435 Tue May 20 13:41:56 EEST 2008 org/objectweb/asm/AnnotationVisitor.class
> 3659 Tue May 20 13:41:56 EEST 2008 org/objectweb/asm/AnnotationWriter.class
>
> Basically it seems that for some reason, Felix doesn't consider META-INF/ as
> a valid path probably because it doesn't exist as a real entry in the JAR in
> the first place. There were some discussions some time ago (with Richard)
> about what the proper behaviour should be - Equinox for example will return
> an entry to the folder. In Felix getResources() works but getResource()
> fails.
> See below the tests:
> public void testCallGetResourceOnADifferentBundle() throws Exception {
> // find bundles
> Bundle[] bundles = bundleContext.getBundles();
> for (int i = 1; i < bundles.length; i++) {
> Bundle bundle = bundles[i];
> logger.debug("calling #getResource on bundle " +
> OsgiStringUtils.nullSafeNameAndSymName(bundle));
> URL url = bundle.getResource(LOCATION);
> if (!OsgiBundleUtils.isFragment(bundle))
> assertNotNull("bundle " +
> OsgiStringUtils.nullSafeNameAndSymName(bundle) + " contains no META-INF/",
> url);
> }
> }
> public void testCallGetResourcesOnADifferentBundle() throws Exception {
> // find bundles
> Bundle[] bundles = bundleContext.getBundles();
> for (int i = 1; i < bundles.length; i++) {
> Bundle bundle = bundles[i];
> logger.debug("calling #getResources on bundle " +
> OsgiStringUtils.nullSafeNameAndSymName(bundle));
> Enumeration enm = bundle.getResources(LOCATION);
> if (!OsgiBundleUtils.isFragment(bundle))
> assertNotNull("bundle " +
> OsgiStringUtils.nullSafeNameAndSymName(bundle) + " contains no META-INF/",
> enm);
> }
> }
> You can find the original test at:
> https://springframework.svn.sourceforge.net/svnroot/springframework/spring-osgi/trunk/integration-tests/tests/src/test/java/org/springframework/osgi/iandt/compliance/io/CallingResourceOnDifferentBundlesTest.java
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (FELIX-596) getResource() doesn't work on META-INF while getResources() does
I am traveling right now, but I can give a quick response now.
If you are saying that the original jar does not have a directory entry for
META-INF, then Felix will not find it.
We had a discussion on CPEG about this issue and consider such JAR files in
error. They should include proper directory entries.
So, unless I am missing something or misremembering, this is a "won't fix"
issue.
-> richard
-Original Message-
From: "Costin Leau (JIRA)" <[EMAIL PROTECTED]>
Subj: [jira] Created: (FELIX-596) getResource() doesn't work on META-INF while
getResources() does
Date: Wed Jun 4, 2008 9:21
Size: 2K
To: dev@felix.apache.org
getResource() doesn't work on META-INF while getResources() does
Key: FELIX-596
URL: https://issues.apache.org/jira/browse/FELIX-596
Project: Felix
Issue Type: Improvement
Components: Framework
Reporter: Costin Leau
I think I've discovered a regression bug.
I'm doing a getResource() on META-INF inside each bundle as part of a
integration test but this fails on a bundle from SpringSource Bundle Repsitory
(even though it appears to be valid).
The Jar in question is ObjectWeb ASM:
http://tinyurl.com/4tbljg
Its content is:
# jar -tvf com.springsource.org.objectweb.asm-2.2.0.jar
467 Tue May 20 13:41:56 EEST 2008 META-INF/MANIFEST.MF
435 Tue May 20 13:41:56 EEST 2008 org/objectweb/asm/AnnotationVisitor.class
3659 Tue May 20 13:41:56 EEST 2008 org/objectweb/asm/AnnotationWriter.class
...
Basically it seems that for some reason, Felix doesn't consider META-INF/ as a
valid path probably because it doesn't exist as a real entry in the JAR in the
first place. There were some discussions some time ago (with Richard) about
what the proper behaviour should be - Equinox for example will return an entry
to the folder. In Felix getResources() works but getResource() fails.
See below the tests:
public void testCallGetResourceOnADifferentBundle() throws Exception {
// find bundles
Bundle[] bundles = bundleContext.getBundles();
for (int i = 1; i < bundles.length; i++) {
Bundle bundle = bundles[i];
logger.debug("calling #getResource on bundle " +
OsgiStringUtils.nullSafeNameAndSymName(bundle));
URL url = bundle.getResource(LOCATION);
if (!OsgiBundleUtils.isFragment(bundle))
assertNotNull("bundle " +
OsgiStringUtils.nullSafeNameAndSymName(bundle) + " contains no META-INF/",
url);
}
}
public void testCallGetResourcesOnADifferentBundle() throws Exception {
// find bundles
Bundle[] bundles = bundleContext.getBundles();
for (int i = 1; i < bundles.length; i++) {
Bundle bundle = bundles[i];
logger.debug("calling #getResources on bundle " +
OsgiStringUtils.nullSafeNameAndSymName(bundle));
Enumeration enm = bundle.getResources(LOCATION);
if (!OsgiBundleUtils.isFragment(bundle))
assertNotNull("bundle " +
OsgiStringUtils.nullSafeNameAndSymName(bundle) + " contains no META-INF/",
enm);
}
}
You can find the original test at:
https://springframework.svn.sourceforge.net/svnroot/springframework/spring-osgi/trunk/integration-tests/tests/src/test/java/org/springframework/osgi/iandt/compliance/io/CallingResourceOnDifferentBundlesTest.java
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-596) getResource() doesn't work on META-INF while getResources() does
getResource() doesn't work on META-INF while getResources() does
Key: FELIX-596
URL: https://issues.apache.org/jira/browse/FELIX-596
Project: Felix
Issue Type: Improvement
Components: Framework
Reporter: Costin Leau
I think I've discovered a regression bug.
I'm doing a getResource() on META-INF inside each bundle as part of a
integration test but this fails on a bundle from SpringSource Bundle Repsitory
(even though it appears to be valid).
The Jar in question is ObjectWeb ASM:
http://tinyurl.com/4tbljg
Its content is:
# jar -tvf com.springsource.org.objectweb.asm-2.2.0.jar
467 Tue May 20 13:41:56 EEST 2008 META-INF/MANIFEST.MF
435 Tue May 20 13:41:56 EEST 2008 org/objectweb/asm/AnnotationVisitor.class
3659 Tue May 20 13:41:56 EEST 2008 org/objectweb/asm/AnnotationWriter.class
Basically it seems that for some reason, Felix doesn't consider META-INF/ as a
valid path probably because it doesn't exist as a real entry in the JAR in the
first place. There were some discussions some time ago (with Richard) about
what the proper behaviour should be - Equinox for example will return an entry
to the folder. In Felix getResources() works but getResource() fails.
See below the tests:
public void testCallGetResourceOnADifferentBundle() throws Exception {
// find bundles
Bundle[] bundles = bundleContext.getBundles();
for (int i = 1; i < bundles.length; i++) {
Bundle bundle = bundles[i];
logger.debug("calling #getResource on bundle " +
OsgiStringUtils.nullSafeNameAndSymName(bundle));
URL url = bundle.getResource(LOCATION);
if (!OsgiBundleUtils.isFragment(bundle))
assertNotNull("bundle " +
OsgiStringUtils.nullSafeNameAndSymName(bundle) + " contains no META-INF/",
url);
}
}
public void testCallGetResourcesOnADifferentBundle() throws Exception {
// find bundles
Bundle[] bundles = bundleContext.getBundles();
for (int i = 1; i < bundles.length; i++) {
Bundle bundle = bundles[i];
logger.debug("calling #getResources on bundle " +
OsgiStringUtils.nullSafeNameAndSymName(bundle));
Enumeration enm = bundle.getResources(LOCATION);
if (!OsgiBundleUtils.isFragment(bundle))
assertNotNull("bundle " +
OsgiStringUtils.nullSafeNameAndSymName(bundle) + " contains no META-INF/",
enm);
}
}
You can find the original test at:
https://springframework.svn.sourceforge.net/svnroot/springframework/spring-osgi/trunk/integration-tests/tests/src/test/java/org/springframework/osgi/iandt/compliance/io/CallingResourceOnDifferentBundlesTest.java
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-595) Update core bundle to r4.1
Update core bundle to r4.1 -- Key: FELIX-595 URL: https://issues.apache.org/jira/browse/FELIX-595 Project: Felix Issue Type: Task Components: Specification compliance Reporter: Christian van Spaandonk If we upgrade to compendium r4.1 we should also update the core to r4.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Library Enabling Test Framework...?
Toni Menzel wrote: Yes, documentation is on the way. The project goals as well as the main obstacles for not using springDM's implementation can be found here: https://scm.ops4j.org/repos/ops4j/laboratory/users/tonit/incubator/drone/README Hi Toni, I wasn't aware of the obstacles you mentioned in your link - have you considered reporting or discussing this issues on Spring-DM mailing list/forum? We're keen on improving the user experience. Since the topic was opened, I'd like to (briefly) address the issues mentioned in the README: a) "it pulls in a lot of dependencies (about 8 extra bundles that are just infrastructure)" A: this is completely customizable. In fact all the jars are read from a property file which can be modified (declaratively or programatically). Only half of the bundles (or less) are needed - the rest are provided as convenience for installing Spring-DM infrastructure. If size is an issue, the util methods used can be potentially implemented locally but frankly, the extra 50-100K doesn't seem to be worth it. For 1.1.x we played with the idea of profiles but we postponed this for 1.2 (see below). However, you can do this yourself now by selecting what bundles you want installed based on some criteria. b) "uses base-classloader to hold and transfer data from the osgi framework" This is actually on purpose. Remoting involves serialization which is quite slow. To improve performance we went from small serialization (the initial design) to class loading which improved performance around 20% on a simple code base. The numbers are not accurate since we didn't do extensive benchmarking but it did show improvements in the nightly builds. Everything takes place inside the same VM so the test results or all the objects and their state are returned to the IDE in pristine state, w/o any transformation. Remoting was not (nor is) on the roadmap but we can consider it (there are many things that can be said on OSGi and remoting). c) "hard to extend (singletons, classloader tricks,big classes,many dependencies)" The testing framework was aimed initially for Spring-DM alone. It can be customized quite a lot and extended (from OSGi platforms to how bundles are retrieved or installed). Since we use Junit 3, we're forced to have certain parents and are somewhat limited in what we can do. However, post 1.1, we plan to improve the testing framework by integrating it with JUnit 4 and TestNG. As for the singletons, that's actually on purpose - you don't want to start a new OSGI framework for each test inside your test case. The same for the Spring application context. If you really want to, then just write another test case. Again, the consideration here is speed. I'd be curios to know what sort of issues you ran with regard to class loading as it doesn't interfere with plugability nor extension. You keep mentioning but I don't see why this is a problem. These being said, I don't want to hijack this thread so please, if you want to follow up (I hope you do), please consider using the Spring-DM forum/mailing list. Cheers, Costin There will be an official announcement on the ops4j mailinglist along with "real" documentation on the ops4j wiki somehwat next week. (hope every one is subscribed to it ;-) ?) till then, /Toni Original-Nachricht Datum: Wed, 4 Jun 2008 16:41:26 +0300 Von: "Alin Dreghiciu" <[EMAIL PROTECTED]> An: dev@felix.apache.org Betreff: Re: Library Enabling Test Framework...? As Guillaume pointerd out, Spring DM Testing support should be able to solve your use case. Toni Menzel is also working on such a testing support as part of Pax Drone, which is now in hie incubator but I expect that soon to be "ready" to use. There is no documentation yet about, but soon. Toni? Alin Dreghiciu On Wed, Jun 4, 2008 at 3:55 PM, Alex Karasulu <[EMAIL PROTECTED]> wrote: Niclas, Robert, It sounded to me as if Robert was more interested in a integration testing framework rather than the build tool used to generate the manifest and build the bundle. Please excuse me if I'm wrong here tho. I just wanted to say that Directory too would like to start using OSGi but the biggest impediment to date is having a good mini/micro integration testing framework to test our components in the container right after the bundle is generated by Maven for that module. We don't want to have to create a foo module then a foo-test module just to integration test since this will lead to a (Maven) module explosion. It would be nice to have a JUnit-ish framework for in situ testing OSGi bundles inside target containers. Like Robert we want to take bundle foo and make sure if it's a library, the classes there in function properly by running some tests that access those classes within the container. If foo bundle exposes a service we'd like to get a handle on that service and start running some tests on it etc. I think such a frame
Re: Library Enabling Test Framework...?
Yes, documentation is on the way. The project goals as well as the main obstacles for not using springDM's implementation can be found here: https://scm.ops4j.org/repos/ops4j/laboratory/users/tonit/incubator/drone/README There will be an official announcement on the ops4j mailinglist along with "real" documentation on the ops4j wiki somehwat next week. (hope every one is subscribed to it ;-) ?) till then, /Toni Original-Nachricht > Datum: Wed, 4 Jun 2008 16:41:26 +0300 > Von: "Alin Dreghiciu" <[EMAIL PROTECTED]> > An: dev@felix.apache.org > Betreff: Re: Library Enabling Test Framework...? > As Guillaume pointerd out, Spring DM Testing support should be able to > solve your use case. > Toni Menzel is also working on such a testing support as part of Pax > Drone, which is now in hie incubator but I expect that soon to be > "ready" to use. There is no documentation yet about, but soon. Toni? > > Alin Dreghiciu > > On Wed, Jun 4, 2008 at 3:55 PM, Alex Karasulu <[EMAIL PROTECTED]> > wrote: > > Niclas, Robert, > > > > It sounded to me as if Robert was more interested in a integration > testing > > framework rather than the build tool used to generate the manifest and > build > > the bundle. Please excuse me if I'm wrong here tho. > > > > I just wanted to say that Directory too would like to start using OSGi > but > > the biggest impediment to date is having a good mini/micro integration > > testing framework to test our components in the container right after > the > > bundle is generated by Maven for that module. We don't want to have to > > create a foo module then a foo-test module just to integration test > since > > this will lead to a (Maven) module explosion. It would be nice to have > a > > JUnit-ish framework for in situ testing OSGi bundles inside target > > containers. > > > > Like Robert we want to take bundle foo and make sure if it's a library, > the > > classes there in function properly by running some tests that access > those > > classes within the container. If foo bundle exposes a service we'd like > to > > get a handle on that service and start running some tests on it etc. > > > > I think such a framework would help increase uptake. > > > > Best Regards, > > Alex > > > > On Wed, Jun 4, 2008 at 8:37 AM, Niclas Hedhman <[EMAIL PROTECTED]> > wrote: > > > >> On Saturday 31 May 2008 15:02, Robert Burrell Donkin wrote: > >> > over in JAMES, we'd like to OSGi enable our upcoming library releases > >> > so that they can be used unforked in OSGi environments. the plan is > to > >> > use the maven plugin but we don't have a lot of OSGi experience. so > >> > i'd like to add some integration tests to check that the libraries > >> > function ok when used in an OSGi environment. this seems a reasonably > >> > general requirement and i was wondering about a general integration > >> > testing micro library to test that a library was correctly enabled. > >> > >> Robert, > >> > >> I think the first necessary step is to incorporate the so called BND > tool > >> into > >> your build. If you are using Maven, then there is a plugin available > here > >> to > >> make it easier. > >> > >> BND recursively walks through the classes and figures out what is > needed > >> and > >> compares that against a "recipe" that you specify. The recipe can > either be > >> explicit (in which case every import has to specified or else an error) > or > >> you use wildcards (less recommended). > >> The recipe also contains information about which packages should be > >> Exported, > >> ignored and kept private. > >> > >> With BND it is not too hard to maintain the recipe (typically an > external > >> file), and will lower the initial need for in-container tests. > >> > >> Setting it up is easy, if you know what you are doing, so I suggest > that > >> someone here volunteers (Stuart???) to help you out. > >> > >> > >> Cheers > >> -- > >> Niclas Hedhman, Software Developer > >> > >> I live here; http://tinyurl.com/2qq9er > >> I work here; http://tinyurl.com/2ymelc > >> I relax here; http://tinyurl.com/2cgsug > >> > > > > > > -- > Alin Dreghiciu > http://www.ops4j.org - New Energy for OSS Communities - Open > Participation Software. > http://www.qi4j.org - New Energy for Java - Domain Driven Development. > http://malaysia.jayway.net - New Energy for Projects - Great People > working on Great Projects at Great Places
Re: Library Enabling Test Framework...?
Guillaume Nodet wrote: Btw, here is an example of such an osgi integration test: http://svn.apache.org/repos/asf/servicemix/smx4/nmr/trunk/jbi/itests/src/test/java/org/apache/servicemix/jbi/IntegrationTest.java Hi guys, thanks for pointing out Spring-DM integration testing framework. There is also a screencast showing its usage on the Spring-DM home page: http://www.springframework.org/osgi/demos Hopefully, you'll find it useful. If you want to find out more or have any questions, feel free to use teh Spring-DM forum (http://forum.springframework.org/forumdisplay.php?f=43). As for examples, besides Guillaume's code sample and the screencast, one can also consider the Spring-DM integration tests (the reason why the testing framework was created in the first place). Cheers, Costin Leau On Wed, Jun 4, 2008 at 3:13 PM, Guillaume Nodet <[EMAIL PROTECTED]> wrote: Once again, I think Spring-DM test support can somewhat fills this gap. From a junit test, it creates an OSGi runtime where you can specify the bundle you want to deploy, then run the junit tests inside the test bundle which is automatically created. I would encourage anyone wanting to do OSGi integration tests to take a look at that first and see if it can fit their use case. On Wed, Jun 4, 2008 at 2:55 PM, Alex Karasulu <[EMAIL PROTECTED]> wrote: Niclas, Robert, It sounded to me as if Robert was more interested in a integration testing framework rather than the build tool used to generate the manifest and build the bundle. Please excuse me if I'm wrong here tho. I just wanted to say that Directory too would like to start using OSGi but the biggest impediment to date is having a good mini/micro integration testing framework to test our components in the container right after the bundle is generated by Maven for that module. We don't want to have to create a foo module then a foo-test module just to integration test since this will lead to a (Maven) module explosion. It would be nice to have a JUnit-ish framework for in situ testing OSGi bundles inside target containers. Like Robert we want to take bundle foo and make sure if it's a library, the classes there in function properly by running some tests that access those classes within the container. If foo bundle exposes a service we'd like to get a handle on that service and start running some tests on it etc. I think such a framework would help increase uptake. Best Regards, Alex On Wed, Jun 4, 2008 at 8:37 AM, Niclas Hedhman <[EMAIL PROTECTED]> wrote: On Saturday 31 May 2008 15:02, Robert Burrell Donkin wrote: over in JAMES, we'd like to OSGi enable our upcoming library releases so that they can be used unforked in OSGi environments. the plan is to use the maven plugin but we don't have a lot of OSGi experience. so i'd like to add some integration tests to check that the libraries function ok when used in an OSGi environment. this seems a reasonably general requirement and i was wondering about a general integration testing micro library to test that a library was correctly enabled. Robert, I think the first necessary step is to incorporate the so called BND tool into your build. If you are using Maven, then there is a plugin available here to make it easier. BND recursively walks through the classes and figures out what is needed and compares that against a "recipe" that you specify. The recipe can either be explicit (in which case every import has to specified or else an error) or you use wildcards (less recommended). The recipe also contains information about which packages should be Exported, ignored and kept private. With BND it is not too hard to maintain the recipe (typically an external file), and will lower the initial need for in-container tests. Setting it up is easy, if you know what you are doing, so I suggest that someone here volunteers (Stuart???) to help you out. Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Library Enabling Test Framework...?
As Guillaume pointerd out, Spring DM Testing support should be able to solve your use case. Toni Menzel is also working on such a testing support as part of Pax Drone, which is now in hie incubator but I expect that soon to be "ready" to use. There is no documentation yet about, but soon. Toni? Alin Dreghiciu On Wed, Jun 4, 2008 at 3:55 PM, Alex Karasulu <[EMAIL PROTECTED]> wrote: > Niclas, Robert, > > It sounded to me as if Robert was more interested in a integration testing > framework rather than the build tool used to generate the manifest and build > the bundle. Please excuse me if I'm wrong here tho. > > I just wanted to say that Directory too would like to start using OSGi but > the biggest impediment to date is having a good mini/micro integration > testing framework to test our components in the container right after the > bundle is generated by Maven for that module. We don't want to have to > create a foo module then a foo-test module just to integration test since > this will lead to a (Maven) module explosion. It would be nice to have a > JUnit-ish framework for in situ testing OSGi bundles inside target > containers. > > Like Robert we want to take bundle foo and make sure if it's a library, the > classes there in function properly by running some tests that access those > classes within the container. If foo bundle exposes a service we'd like to > get a handle on that service and start running some tests on it etc. > > I think such a framework would help increase uptake. > > Best Regards, > Alex > > On Wed, Jun 4, 2008 at 8:37 AM, Niclas Hedhman <[EMAIL PROTECTED]> wrote: > >> On Saturday 31 May 2008 15:02, Robert Burrell Donkin wrote: >> > over in JAMES, we'd like to OSGi enable our upcoming library releases >> > so that they can be used unforked in OSGi environments. the plan is to >> > use the maven plugin but we don't have a lot of OSGi experience. so >> > i'd like to add some integration tests to check that the libraries >> > function ok when used in an OSGi environment. this seems a reasonably >> > general requirement and i was wondering about a general integration >> > testing micro library to test that a library was correctly enabled. >> >> Robert, >> >> I think the first necessary step is to incorporate the so called BND tool >> into >> your build. If you are using Maven, then there is a plugin available here >> to >> make it easier. >> >> BND recursively walks through the classes and figures out what is needed >> and >> compares that against a "recipe" that you specify. The recipe can either be >> explicit (in which case every import has to specified or else an error) or >> you use wildcards (less recommended). >> The recipe also contains information about which packages should be >> Exported, >> ignored and kept private. >> >> With BND it is not too hard to maintain the recipe (typically an external >> file), and will lower the initial need for in-container tests. >> >> Setting it up is easy, if you know what you are doing, so I suggest that >> someone here volunteers (Stuart???) to help you out. >> >> >> Cheers >> -- >> Niclas Hedhman, Software Developer >> >> I live here; http://tinyurl.com/2qq9er >> I work here; http://tinyurl.com/2ymelc >> I relax here; http://tinyurl.com/2cgsug >> > -- Alin Dreghiciu http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software. http://www.qi4j.org - New Energy for Java - Domain Driven Development. http://malaysia.jayway.net - New Energy for Projects - Great People working on Great Projects at Great Places
Re: Library Enabling Test Framework...?
As Guillaume pointerd out, Spring DM Testing support should be able to solve your use case. Toni Menzel is also working on such a testing support as part of Pax Drone, which is now in hie incubator but I expect that soon to be "ready" to use. There is no documentation yet about, but soon. Toni? Alin Dreghiciu On Wed, Jun 4, 2008 at 3:55 PM, Alex Karasulu <[EMAIL PROTECTED]> wrote: > Niclas, Robert, > > It sounded to me as if Robert was more interested in a integration testing > framework rather than the build tool used to generate the manifest and build > the bundle. Please excuse me if I'm wrong here tho. > > I just wanted to say that Directory too would like to start using OSGi but > the biggest impediment to date is having a good mini/micro integration > testing framework to test our components in the container right after the > bundle is generated by Maven for that module. We don't want to have to > create a foo module then a foo-test module just to integration test since > this will lead to a (Maven) module explosion. It would be nice to have a > JUnit-ish framework for in situ testing OSGi bundles inside target > containers. > > Like Robert we want to take bundle foo and make sure if it's a library, the > classes there in function properly by running some tests that access those > classes within the container. If foo bundle exposes a service we'd like to > get a handle on that service and start running some tests on it etc. > > I think such a framework would help increase uptake. > > Best Regards, > Alex > > On Wed, Jun 4, 2008 at 8:37 AM, Niclas Hedhman <[EMAIL PROTECTED]> wrote: > >> On Saturday 31 May 2008 15:02, Robert Burrell Donkin wrote: >> > over in JAMES, we'd like to OSGi enable our upcoming library releases >> > so that they can be used unforked in OSGi environments. the plan is to >> > use the maven plugin but we don't have a lot of OSGi experience. so >> > i'd like to add some integration tests to check that the libraries >> > function ok when used in an OSGi environment. this seems a reasonably >> > general requirement and i was wondering about a general integration >> > testing micro library to test that a library was correctly enabled. >> >> Robert, >> >> I think the first necessary step is to incorporate the so called BND tool >> into >> your build. If you are using Maven, then there is a plugin available here >> to >> make it easier. >> >> BND recursively walks through the classes and figures out what is needed >> and >> compares that against a "recipe" that you specify. The recipe can either be >> explicit (in which case every import has to specified or else an error) or >> you use wildcards (less recommended). >> The recipe also contains information about which packages should be >> Exported, >> ignored and kept private. >> >> With BND it is not too hard to maintain the recipe (typically an external >> file), and will lower the initial need for in-container tests. >> >> Setting it up is easy, if you know what you are doing, so I suggest that >> someone here volunteers (Stuart???) to help you out. >> >> >> Cheers >> -- >> Niclas Hedhman, Software Developer >> >> I live here; http://tinyurl.com/2qq9er >> I work here; http://tinyurl.com/2ymelc >> I relax here; http://tinyurl.com/2cgsug >> > -- Alin Dreghiciu http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software. http://www.qi4j.org - New Energy for Java - Domain Driven Development. http://malaysia.jayway.net - New Energy for Projects - Great People working on Great Projects at Great Places
Re: Library Enabling Test Framework...?
Btw, here is an example of such an osgi integration test: http://svn.apache.org/repos/asf/servicemix/smx4/nmr/trunk/jbi/itests/src/test/java/org/apache/servicemix/jbi/IntegrationTest.java On Wed, Jun 4, 2008 at 3:13 PM, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > Once again, I think Spring-DM test support can somewhat fills this gap. > From a junit test, it creates an OSGi runtime where you can specify > the bundle you want to deploy, then run the junit tests inside the > test bundle which is automatically created. > I would encourage anyone wanting to do OSGi integration tests to take > a look at that first and see if it can fit their use case. > > On Wed, Jun 4, 2008 at 2:55 PM, Alex Karasulu <[EMAIL PROTECTED]> wrote: >> Niclas, Robert, >> >> It sounded to me as if Robert was more interested in a integration testing >> framework rather than the build tool used to generate the manifest and build >> the bundle. Please excuse me if I'm wrong here tho. >> >> I just wanted to say that Directory too would like to start using OSGi but >> the biggest impediment to date is having a good mini/micro integration >> testing framework to test our components in the container right after the >> bundle is generated by Maven for that module. We don't want to have to >> create a foo module then a foo-test module just to integration test since >> this will lead to a (Maven) module explosion. It would be nice to have a >> JUnit-ish framework for in situ testing OSGi bundles inside target >> containers. >> >> Like Robert we want to take bundle foo and make sure if it's a library, the >> classes there in function properly by running some tests that access those >> classes within the container. If foo bundle exposes a service we'd like to >> get a handle on that service and start running some tests on it etc. >> >> I think such a framework would help increase uptake. >> >> Best Regards, >> Alex >> >> On Wed, Jun 4, 2008 at 8:37 AM, Niclas Hedhman <[EMAIL PROTECTED]> wrote: >> >>> On Saturday 31 May 2008 15:02, Robert Burrell Donkin wrote: >>> > over in JAMES, we'd like to OSGi enable our upcoming library releases >>> > so that they can be used unforked in OSGi environments. the plan is to >>> > use the maven plugin but we don't have a lot of OSGi experience. so >>> > i'd like to add some integration tests to check that the libraries >>> > function ok when used in an OSGi environment. this seems a reasonably >>> > general requirement and i was wondering about a general integration >>> > testing micro library to test that a library was correctly enabled. >>> >>> Robert, >>> >>> I think the first necessary step is to incorporate the so called BND tool >>> into >>> your build. If you are using Maven, then there is a plugin available here >>> to >>> make it easier. >>> >>> BND recursively walks through the classes and figures out what is needed >>> and >>> compares that against a "recipe" that you specify. The recipe can either be >>> explicit (in which case every import has to specified or else an error) or >>> you use wildcards (less recommended). >>> The recipe also contains information about which packages should be >>> Exported, >>> ignored and kept private. >>> >>> With BND it is not too hard to maintain the recipe (typically an external >>> file), and will lower the initial need for in-container tests. >>> >>> Setting it up is easy, if you know what you are doing, so I suggest that >>> someone here volunteers (Stuart???) to help you out. >>> >>> >>> Cheers >>> -- >>> Niclas Hedhman, Software Developer >>> >>> I live here; http://tinyurl.com/2qq9er >>> I work here; http://tinyurl.com/2ymelc >>> I relax here; http://tinyurl.com/2cgsug >>> >> > > > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Library Enabling Test Framework...?
Once again, I think Spring-DM test support can somewhat fills this gap. >From a junit test, it creates an OSGi runtime where you can specify the bundle you want to deploy, then run the junit tests inside the test bundle which is automatically created. I would encourage anyone wanting to do OSGi integration tests to take a look at that first and see if it can fit their use case. On Wed, Jun 4, 2008 at 2:55 PM, Alex Karasulu <[EMAIL PROTECTED]> wrote: > Niclas, Robert, > > It sounded to me as if Robert was more interested in a integration testing > framework rather than the build tool used to generate the manifest and build > the bundle. Please excuse me if I'm wrong here tho. > > I just wanted to say that Directory too would like to start using OSGi but > the biggest impediment to date is having a good mini/micro integration > testing framework to test our components in the container right after the > bundle is generated by Maven for that module. We don't want to have to > create a foo module then a foo-test module just to integration test since > this will lead to a (Maven) module explosion. It would be nice to have a > JUnit-ish framework for in situ testing OSGi bundles inside target > containers. > > Like Robert we want to take bundle foo and make sure if it's a library, the > classes there in function properly by running some tests that access those > classes within the container. If foo bundle exposes a service we'd like to > get a handle on that service and start running some tests on it etc. > > I think such a framework would help increase uptake. > > Best Regards, > Alex > > On Wed, Jun 4, 2008 at 8:37 AM, Niclas Hedhman <[EMAIL PROTECTED]> wrote: > >> On Saturday 31 May 2008 15:02, Robert Burrell Donkin wrote: >> > over in JAMES, we'd like to OSGi enable our upcoming library releases >> > so that they can be used unforked in OSGi environments. the plan is to >> > use the maven plugin but we don't have a lot of OSGi experience. so >> > i'd like to add some integration tests to check that the libraries >> > function ok when used in an OSGi environment. this seems a reasonably >> > general requirement and i was wondering about a general integration >> > testing micro library to test that a library was correctly enabled. >> >> Robert, >> >> I think the first necessary step is to incorporate the so called BND tool >> into >> your build. If you are using Maven, then there is a plugin available here >> to >> make it easier. >> >> BND recursively walks through the classes and figures out what is needed >> and >> compares that against a "recipe" that you specify. The recipe can either be >> explicit (in which case every import has to specified or else an error) or >> you use wildcards (less recommended). >> The recipe also contains information about which packages should be >> Exported, >> ignored and kept private. >> >> With BND it is not too hard to maintain the recipe (typically an external >> file), and will lower the initial need for in-container tests. >> >> Setting it up is easy, if you know what you are doing, so I suggest that >> someone here volunteers (Stuart???) to help you out. >> >> >> Cheers >> -- >> Niclas Hedhman, Software Developer >> >> I live here; http://tinyurl.com/2qq9er >> I work here; http://tinyurl.com/2ymelc >> I relax here; http://tinyurl.com/2cgsug >> > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Library Enabling Test Framework...?
Niclas, Robert, It sounded to me as if Robert was more interested in a integration testing framework rather than the build tool used to generate the manifest and build the bundle. Please excuse me if I'm wrong here tho. I just wanted to say that Directory too would like to start using OSGi but the biggest impediment to date is having a good mini/micro integration testing framework to test our components in the container right after the bundle is generated by Maven for that module. We don't want to have to create a foo module then a foo-test module just to integration test since this will lead to a (Maven) module explosion. It would be nice to have a JUnit-ish framework for in situ testing OSGi bundles inside target containers. Like Robert we want to take bundle foo and make sure if it's a library, the classes there in function properly by running some tests that access those classes within the container. If foo bundle exposes a service we'd like to get a handle on that service and start running some tests on it etc. I think such a framework would help increase uptake. Best Regards, Alex On Wed, Jun 4, 2008 at 8:37 AM, Niclas Hedhman <[EMAIL PROTECTED]> wrote: > On Saturday 31 May 2008 15:02, Robert Burrell Donkin wrote: > > over in JAMES, we'd like to OSGi enable our upcoming library releases > > so that they can be used unforked in OSGi environments. the plan is to > > use the maven plugin but we don't have a lot of OSGi experience. so > > i'd like to add some integration tests to check that the libraries > > function ok when used in an OSGi environment. this seems a reasonably > > general requirement and i was wondering about a general integration > > testing micro library to test that a library was correctly enabled. > > Robert, > > I think the first necessary step is to incorporate the so called BND tool > into > your build. If you are using Maven, then there is a plugin available here > to > make it easier. > > BND recursively walks through the classes and figures out what is needed > and > compares that against a "recipe" that you specify. The recipe can either be > explicit (in which case every import has to specified or else an error) or > you use wildcards (less recommended). > The recipe also contains information about which packages should be > Exported, > ignored and kept private. > > With BND it is not too hard to maintain the recipe (typically an external > file), and will lower the initial need for in-container tests. > > Setting it up is easy, if you know what you are doing, so I suggest that > someone here volunteers (Stuart???) to help you out. > > > Cheers > -- > Niclas Hedhman, Software Developer > > I live here; http://tinyurl.com/2qq9er > I work here; http://tinyurl.com/2ymelc > I relax here; http://tinyurl.com/2cgsug >
Re: Library Enabling Test Framework...?
On Saturday 31 May 2008 15:02, Robert Burrell Donkin wrote: > over in JAMES, we'd like to OSGi enable our upcoming library releases > so that they can be used unforked in OSGi environments. the plan is to > use the maven plugin but we don't have a lot of OSGi experience. so > i'd like to add some integration tests to check that the libraries > function ok when used in an OSGi environment. this seems a reasonably > general requirement and i was wondering about a general integration > testing micro library to test that a library was correctly enabled. Robert, I think the first necessary step is to incorporate the so called BND tool into your build. If you are using Maven, then there is a plugin available here to make it easier. BND recursively walks through the classes and figures out what is needed and compares that against a "recipe" that you specify. The recipe can either be explicit (in which case every import has to specified or else an error) or you use wildcards (less recommended). The recipe also contains information about which packages should be Exported, ignored and kept private. With BND it is not too hard to maintain the recipe (typically an external file), and will lower the initial need for in-container tests. Setting it up is easy, if you know what you are doing, so I suggest that someone here volunteers (Stuart???) to help you out. Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug
