You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Thomas Dewire (JIRA)" <ji...@apache.org> on 2008/05/07 19:10:55 UTC
[jira] Created: (FELIX-548) Import-Package version qualifiers vary
depending on dependency scope.
Import-Package version qualifiers vary depending on dependency scope.
---------------------------------------------------------------------
Key: FELIX-548
URL: https://issues.apache.org/jira/browse/FELIX-548
Project: Felix
Issue Type: Bug
Components: Maven Bundle Plugin
Affects Versions: maven-bundle-plugin-1.4.0
Environment: N/A
Reporter: Thomas Dewire
Priority: Minor
The produced Import-Package directive appears to vary depending on the declared scope of a dependency.
Assuming that a dependency is a valid OSGi bundle:
- "compile" scope will include a version qualifier (eg. Import-Package: org.springframework.core;version="2.5.4").
- "provided" scope will not include a version qualifier (eg. Import-Package: org.springframework.core).
In this case, I believe the 'compile' behavior is correct.
I have not tested all possible scopes. A similar inconsistency might exist for runtime, test, etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-548) Import-Package version qualifiers
vary depending on dependency scope.
Posted by "Stuart McCulloch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670649#action_12670649 ]
Stuart McCulloch commented on FELIX-548:
----------------------------------------
it's a combination of two things: we now pass the complete set of dependencies to the Bnd Tool, and the latest Bnd Tool now handles versions more consistently.
> Import-Package version qualifiers vary depending on dependency scope.
> ---------------------------------------------------------------------
>
> Key: FELIX-548
> URL: https://issues.apache.org/jira/browse/FELIX-548
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
> Affects Versions: maven-bundle-plugin-1.4.0
> Environment: N/A
> Reporter: Thomas Dewire
> Assignee: Stuart McCulloch
> Priority: Minor
> Fix For: maven-bundle-plugin-1.4.2
>
> Attachments: bugtest3.tar.gz
>
>
> The produced Import-Package directive appears to vary depending on the declared scope of a dependency.
> Assuming that a dependency is a valid OSGi bundle:
> - "compile" scope will include a version qualifier (eg. Import-Package: org.springframework.core;version="2.5.4").
> - "provided" scope will not include a version qualifier (eg. Import-Package: org.springframework.core).
> In this case, I believe the 'compile' behavior is correct.
> I have not tested all possible scopes. A similar inconsistency might exist for runtime, test, etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-548) Import-Package version qualifiers vary
depending on dependency scope.
Posted by "Thomas Dewire (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Dewire updated FELIX-548:
--------------------------------
Attachment: bugtest3.tar.gz
A small demo project. Alter the dependency scope to see the difference in the output.
> Import-Package version qualifiers vary depending on dependency scope.
> ---------------------------------------------------------------------
>
> Key: FELIX-548
> URL: https://issues.apache.org/jira/browse/FELIX-548
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
> Affects Versions: maven-bundle-plugin-1.4.0
> Environment: N/A
> Reporter: Thomas Dewire
> Priority: Minor
> Attachments: bugtest3.tar.gz
>
>
> The produced Import-Package directive appears to vary depending on the declared scope of a dependency.
> Assuming that a dependency is a valid OSGi bundle:
> - "compile" scope will include a version qualifier (eg. Import-Package: org.springframework.core;version="2.5.4").
> - "provided" scope will not include a version qualifier (eg. Import-Package: org.springframework.core).
> In this case, I believe the 'compile' behavior is correct.
> I have not tested all possible scopes. A similar inconsistency might exist for runtime, test, etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-548) Import-Package version qualifiers
vary depending on dependency scope.
Posted by "Stuart McCulloch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595096#action_12595096 ]
Stuart McCulloch commented on FELIX-548:
----------------------------------------
That is correct - the bundleplugin only adds the compile and runtime dependencies to the classpath passed to BND.
This has always been the case, since before I joined the project - the bundle mojo has @requiresDependencyResolution set to runtime, which means Maven will only resolve the compile and runtime dependencies on the project classpath, not provided ones (AFAIK Maven doesn't allow you to set it to provided, and if you omit this tag then you inherit whatever classpath was resolved by previous plugins, which could lead to unreproducible builds).
A beneficial side-effect of this setting is that it avoids people accidentally including content from other bundles (ie. scope provision) when setting Export-Package:*, etc. Removing this setting to add provision dependencies to the BND classpath would definitely break large numbers of existing projects that rely on this behavior.
The unfortunate side-effect is that you lose automatic versioning of imports which means that you need to add versions and ranges explicitly - but again, a lot of projects seem to prefer this rather than nailing down imports to a specific version by default.
> Import-Package version qualifiers vary depending on dependency scope.
> ---------------------------------------------------------------------
>
> Key: FELIX-548
> URL: https://issues.apache.org/jira/browse/FELIX-548
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
> Affects Versions: maven-bundle-plugin-1.4.0
> Environment: N/A
> Reporter: Thomas Dewire
> Priority: Minor
> Attachments: bugtest3.tar.gz
>
>
> The produced Import-Package directive appears to vary depending on the declared scope of a dependency.
> Assuming that a dependency is a valid OSGi bundle:
> - "compile" scope will include a version qualifier (eg. Import-Package: org.springframework.core;version="2.5.4").
> - "provided" scope will not include a version qualifier (eg. Import-Package: org.springframework.core).
> In this case, I believe the 'compile' behavior is correct.
> I have not tested all possible scopes. A similar inconsistency might exist for runtime, test, etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-548) Import-Package version qualifiers
vary depending on dependency scope.
Posted by "Sahoo (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670317#action_12670317 ]
Sahoo commented on FELIX-548:
-----------------------------
Stuart,
Per your last comment, this bug has been fixed. I am curious to know what was the fix. As per most of the comments, the behavior was intended.
Thanks,
Sahoo
> Import-Package version qualifiers vary depending on dependency scope.
> ---------------------------------------------------------------------
>
> Key: FELIX-548
> URL: https://issues.apache.org/jira/browse/FELIX-548
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
> Affects Versions: maven-bundle-plugin-1.4.0
> Environment: N/A
> Reporter: Thomas Dewire
> Assignee: Stuart McCulloch
> Priority: Minor
> Fix For: maven-bundle-plugin-1.4.2
>
> Attachments: bugtest3.tar.gz
>
>
> The produced Import-Package directive appears to vary depending on the declared scope of a dependency.
> Assuming that a dependency is a valid OSGi bundle:
> - "compile" scope will include a version qualifier (eg. Import-Package: org.springframework.core;version="2.5.4").
> - "provided" scope will not include a version qualifier (eg. Import-Package: org.springframework.core).
> In this case, I believe the 'compile' behavior is correct.
> I have not tested all possible scopes. A similar inconsistency might exist for runtime, test, etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-548) Import-Package version qualifiers vary
depending on dependency scope.
Posted by "Stuart McCulloch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stuart McCulloch updated FELIX-548:
-----------------------------------
Fix Version/s: maven-bundle-plugin-1.4.2
Will update online docs to make this clearer.
> Import-Package version qualifiers vary depending on dependency scope.
> ---------------------------------------------------------------------
>
> Key: FELIX-548
> URL: https://issues.apache.org/jira/browse/FELIX-548
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
> Affects Versions: maven-bundle-plugin-1.4.0
> Environment: N/A
> Reporter: Thomas Dewire
> Assignee: Stuart McCulloch
> Priority: Minor
> Fix For: maven-bundle-plugin-1.4.2
>
> Attachments: bugtest3.tar.gz
>
>
> The produced Import-Package directive appears to vary depending on the declared scope of a dependency.
> Assuming that a dependency is a valid OSGi bundle:
> - "compile" scope will include a version qualifier (eg. Import-Package: org.springframework.core;version="2.5.4").
> - "provided" scope will not include a version qualifier (eg. Import-Package: org.springframework.core).
> In this case, I believe the 'compile' behavior is correct.
> I have not tested all possible scopes. A similar inconsistency might exist for runtime, test, etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-548) Import-Package version qualifiers
vary depending on dependency scope.
Posted by "Stuart McCulloch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670650#action_12670650 ]
Stuart McCulloch commented on FELIX-548:
----------------------------------------
The "fix" for 1.4.3 was to document the behaviour in the online and packaged docs [as per comment https://issues.apache.org/jira/browse/FELIX-548?focusedCommentId=12595096#action_12595096]
In the 1.5.0-SNAPSHOT we now pass the complete set of dependencies to the Bnd Tool, and the latest Bnd Tool also handles versioning more consistently (it has a well defined policy setting for managing ranges) so the final versions in the manifest are now consistent.
> Import-Package version qualifiers vary depending on dependency scope.
> ---------------------------------------------------------------------
>
> Key: FELIX-548
> URL: https://issues.apache.org/jira/browse/FELIX-548
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
> Affects Versions: maven-bundle-plugin-1.4.0
> Environment: N/A
> Reporter: Thomas Dewire
> Assignee: Stuart McCulloch
> Priority: Minor
> Fix For: maven-bundle-plugin-1.4.2
>
> Attachments: bugtest3.tar.gz
>
>
> The produced Import-Package directive appears to vary depending on the declared scope of a dependency.
> Assuming that a dependency is a valid OSGi bundle:
> - "compile" scope will include a version qualifier (eg. Import-Package: org.springframework.core;version="2.5.4").
> - "provided" scope will not include a version qualifier (eg. Import-Package: org.springframework.core).
> In this case, I believe the 'compile' behavior is correct.
> I have not tested all possible scopes. A similar inconsistency might exist for runtime, test, etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-548) Import-Package version qualifiers
vary depending on dependency scope.
Posted by "Thomas Dewire (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595236#action_12595236 ]
Thomas Dewire commented on FELIX-548:
-------------------------------------
That sounds reasonable enough to me.
Rather than treating this like a bug in the plugin, might we consider this an area where the documentation could be improved? I grant that it is a relatively nit-picky point, but one that seems worth calling out.
> Import-Package version qualifiers vary depending on dependency scope.
> ---------------------------------------------------------------------
>
> Key: FELIX-548
> URL: https://issues.apache.org/jira/browse/FELIX-548
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
> Affects Versions: maven-bundle-plugin-1.4.0
> Environment: N/A
> Reporter: Thomas Dewire
> Priority: Minor
> Attachments: bugtest3.tar.gz
>
>
> The produced Import-Package directive appears to vary depending on the declared scope of a dependency.
> Assuming that a dependency is a valid OSGi bundle:
> - "compile" scope will include a version qualifier (eg. Import-Package: org.springframework.core;version="2.5.4").
> - "provided" scope will not include a version qualifier (eg. Import-Package: org.springframework.core).
> In this case, I believe the 'compile' behavior is correct.
> I have not tested all possible scopes. A similar inconsistency might exist for runtime, test, etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-548) Import-Package version qualifiers vary
depending on dependency scope.
Posted by "Stuart McCulloch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stuart McCulloch resolved FELIX-548.
------------------------------------
Resolution: Fixed
Updated the wiki: http://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Maven+Bundle+Plugin+(BND) - changes will appear on the website after an hour or so.
> Import-Package version qualifiers vary depending on dependency scope.
> ---------------------------------------------------------------------
>
> Key: FELIX-548
> URL: https://issues.apache.org/jira/browse/FELIX-548
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
> Affects Versions: maven-bundle-plugin-1.4.0
> Environment: N/A
> Reporter: Thomas Dewire
> Assignee: Stuart McCulloch
> Priority: Minor
> Fix For: maven-bundle-plugin-1.4.2
>
> Attachments: bugtest3.tar.gz
>
>
> The produced Import-Package directive appears to vary depending on the declared scope of a dependency.
> Assuming that a dependency is a valid OSGi bundle:
> - "compile" scope will include a version qualifier (eg. Import-Package: org.springframework.core;version="2.5.4").
> - "provided" scope will not include a version qualifier (eg. Import-Package: org.springframework.core).
> In this case, I believe the 'compile' behavior is correct.
> I have not tested all possible scopes. A similar inconsistency might exist for runtime, test, etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-548) Import-Package version qualifiers
vary depending on dependency scope.
Posted by "Stuart McCulloch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595262#action_12595262 ]
Stuart McCulloch commented on FELIX-548:
----------------------------------------
Certainly, I think updating the documentation to make this difference clear is a good idea.
> Import-Package version qualifiers vary depending on dependency scope.
> ---------------------------------------------------------------------
>
> Key: FELIX-548
> URL: https://issues.apache.org/jira/browse/FELIX-548
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
> Affects Versions: maven-bundle-plugin-1.4.0
> Environment: N/A
> Reporter: Thomas Dewire
> Priority: Minor
> Attachments: bugtest3.tar.gz
>
>
> The produced Import-Package directive appears to vary depending on the declared scope of a dependency.
> Assuming that a dependency is a valid OSGi bundle:
> - "compile" scope will include a version qualifier (eg. Import-Package: org.springframework.core;version="2.5.4").
> - "provided" scope will not include a version qualifier (eg. Import-Package: org.springframework.core).
> In this case, I believe the 'compile' behavior is correct.
> I have not tested all possible scopes. A similar inconsistency might exist for runtime, test, etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Porting Question
Posted by ja...@cox.net.
Thanks, from what I have read so far iPOJO seems like a good fit.
-Pete
---- Clement Escoffier <cl...@gmail.com> wrote:
=============
Hi,
On 09.02.2009, at 07:37, Pete Haidinyak wrote:
> Thanks for the help. I just printed out the iPOJO documentation and
> will be going through it.
iPOJO can ease your development. I add some comments below.
>
>
> -Pete
>
> On Sat, 07 Feb 2009 08:34:27 -0800, Marcel Offermans <marcel.offermans@luminis.nl
> > wrote:
>
>> A big question, let me have a go at providing some generic answers.
>> I'm sure others will join in on this. :)
>>
>> On Feb 7, 2009, at 9:20 , Pete Haidinyak wrote:
>>
>>> Ok, enough of the background, my question is "What is the best
>>> approach
>>> for Porting a JMX enabled Component to OSGi?" Currently the
>>> Components
>>> send and receive 'Events/Message' using JMX (Publish/Subscribe).
>>
>> That maps nicely onto the Event Admin specification.
iPOJO provides a way to send and receive events with the Event Admin
without managing the Event Admin interaction (see http://felix.apache.org/site/event-admin-handlers.html)
>>
>>
>>> They are
>>> also managed (stopped/started/unload/loaded/configuration changes,
>>> etc.)
>>> using a JMX Console.
>>
>> If you make your beans map onto bundles, then those can be managed
>> in the same way. We have a local shell, telnet and webconsole, and
>> even a wrapper to expose bundles through JMX again.
iPOJO instances can also be exposed as MBean. In this case, they don't
know that there are accessible remotely ... (http://felix.apache.org/site/ipojo-jmx-handler.html
)
>>
>>
>>> I also will be running parts of the application
>>> outside of the OSGi container which will need access to components
>>> running
>>> inside the OSGi container. Components running inside of the OSGi
>>> contain
>>> will need access to resources that are in the classpath (created at
>>> startup).
>>
Regards,
Clement
--
1. If a man is standing in the middle of the forest talking, and there is no woman around to hear him, is he still wrong?
2. Behind every great woman... Is a man checking out her ass
3. I am not a member of any organized political party. I am a Democrat.*
4. Diplomacy is the art of saying "Nice doggie" until you can find a rock.*
5. A process is what you need when all your good people have left.
*Will Rogers
Re: Porting Question
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
On 09.02.2009, at 07:37, Pete Haidinyak wrote:
> Thanks for the help. I just printed out the iPOJO documentation and
> will be going through it.
iPOJO can ease your development. I add some comments below.
>
>
> -Pete
>
> On Sat, 07 Feb 2009 08:34:27 -0800, Marcel Offermans <marcel.offermans@luminis.nl
> > wrote:
>
>> A big question, let me have a go at providing some generic answers.
>> I'm sure others will join in on this. :)
>>
>> On Feb 7, 2009, at 9:20 , Pete Haidinyak wrote:
>>
>>> Ok, enough of the background, my question is "What is the best
>>> approach
>>> for Porting a JMX enabled Component to OSGi?" Currently the
>>> Components
>>> send and receive 'Events/Message' using JMX (Publish/Subscribe).
>>
>> That maps nicely onto the Event Admin specification.
iPOJO provides a way to send and receive events with the Event Admin
without managing the Event Admin interaction (see http://felix.apache.org/site/event-admin-handlers.html)
>>
>>
>>> They are
>>> also managed (stopped/started/unload/loaded/configuration changes,
>>> etc.)
>>> using a JMX Console.
>>
>> If you make your beans map onto bundles, then those can be managed
>> in the same way. We have a local shell, telnet and webconsole, and
>> even a wrapper to expose bundles through JMX again.
iPOJO instances can also be exposed as MBean. In this case, they don't
know that there are accessible remotely ... (http://felix.apache.org/site/ipojo-jmx-handler.html
)
>>
>>
>>> I also will be running parts of the application
>>> outside of the OSGi container which will need access to components
>>> running
>>> inside the OSGi container. Components running inside of the OSGi
>>> contain
>>> will need access to resources that are in the classpath (created at
>>> startup).
>>
Regards,
Clement
Re: Porting Question
Posted by Pete Haidinyak <ja...@cox.net>.
Thanks for the help. I just printed out the iPOJO documentation and will
be going through it.
-Pete
On Sat, 07 Feb 2009 08:34:27 -0800, Marcel Offermans
<ma...@luminis.nl> wrote:
> A big question, let me have a go at providing some generic answers. I'm
> sure others will join in on this. :)
>
> On Feb 7, 2009, at 9:20 , Pete Haidinyak wrote:
>
>> Ok, enough of the background, my question is "What is the best approach
>> for Porting a JMX enabled Component to OSGi?" Currently the Components
>> send and receive 'Events/Message' using JMX (Publish/Subscribe).
>
> That maps nicely onto the Event Admin specification.
>
>> They are
>> also managed (stopped/started/unload/loaded/configuration changes, etc.)
>> using a JMX Console.
>
> If you make your beans map onto bundles, then those can be managed in
> the same way. We have a local shell, telnet and webconsole, and even a
> wrapper to expose bundles through JMX again.
>
>> I also will be running parts of the application
>> outside of the OSGi container which will need access to components
>> running
>> inside the OSGi container. Components running inside of the OSGi contain
>> will need access to resources that are in the classpath (created at
>> startup).
>
> Check out the documentation on embedding Felix for more details about
> this. Stuff on the classpath can be exposed through the system bundle.
> The bundle context can be used outside the framework to lookup services
> and use them.
>
> Greetings, Marcel
>
>
Re: Porting Question
Posted by Marcel Offermans <ma...@luminis.nl>.
A big question, let me have a go at providing some generic answers.
I'm sure others will join in on this. :)
On Feb 7, 2009, at 9:20 , Pete Haidinyak wrote:
> Ok, enough of the background, my question is "What is the best
> approach
> for Porting a JMX enabled Component to OSGi?" Currently the Components
> send and receive 'Events/Message' using JMX (Publish/Subscribe).
That maps nicely onto the Event Admin specification.
> They are
> also managed (stopped/started/unload/loaded/configuration changes,
> etc.)
> using a JMX Console.
If you make your beans map onto bundles, then those can be managed in
the same way. We have a local shell, telnet and webconsole, and even a
wrapper to expose bundles through JMX again.
> I also will be running parts of the application
> outside of the OSGi container which will need access to components
> running
> inside the OSGi container. Components running inside of the OSGi
> contain
> will need access to resources that are in the classpath (created at
> startup).
Check out the documentation on embedding Felix for more details about
this. Stuff on the classpath can be exposed through the system bundle.
The bundle context can be used outside the framework to lookup
services and use them.
Greetings, Marcel
Porting Question
Posted by Pete Haidinyak <ja...@cox.net>.
Good evening,
I am porting an application I have been working on from a JMX managed
system to OSGi. My original design was based off an earlier version of
JBoss where you could load different version of JBoss based on command
line parameters. It would create a custom URL classloader based on the
version loaded. Anyway, I have a core launcher which sets up the
Classloader and command line parameters and now loads Felix. In my old
system I have core components which are always available (Logging,
Dependency Management, Configuration, Inter-Service communication
(JGroups), Intra-Service Communication (JMX), Group Communication
(JGroups), etc.) and then I load components that are only used by the
service which was started (Database, UDP Reader, Rules Engine, Socket
Communications, etc.) All of this was controlled via JMX since all of the
components were MBeans. Problem is I found I was spending to much time on
the 'plumbing' and not on solving the business problem. That is the reason
for the port to OSGi.
Ok, enough of the background, my question is "What is the best approach
for Porting a JMX enabled Component to OSGi?" Currently the Components
send and receive 'Events/Message' using JMX (Publish/Subscribe). They are
also managed (stopped/started/unload/loaded/configuration changes, etc.)
using a JMX Console. I also will be running parts of the application
outside of the OSGi container which will need access to components running
inside the OSGi container. Components running inside of the OSGi contain
will need access to resources that are in the classpath (created at
startup).
I have been looking at your wiki, books on OSGi (precious few), Googling
the web, and the last thousand or so email from this group trying to get
my head around this. What would y'all best suggestion to point my efforts?
Thanks for your time!
-Pete Haidinyak
[jira] Updated: (FELIX-548) Import-Package version qualifiers vary
depending on dependency scope.
Posted by "Stuart McCulloch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stuart McCulloch updated FELIX-548:
-----------------------------------
Comment: was deleted
> Import-Package version qualifiers vary depending on dependency scope.
> ---------------------------------------------------------------------
>
> Key: FELIX-548
> URL: https://issues.apache.org/jira/browse/FELIX-548
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
> Affects Versions: maven-bundle-plugin-1.4.0
> Environment: N/A
> Reporter: Thomas Dewire
> Assignee: Stuart McCulloch
> Priority: Minor
> Fix For: maven-bundle-plugin-1.4.2
>
> Attachments: bugtest3.tar.gz
>
>
> The produced Import-Package directive appears to vary depending on the declared scope of a dependency.
> Assuming that a dependency is a valid OSGi bundle:
> - "compile" scope will include a version qualifier (eg. Import-Package: org.springframework.core;version="2.5.4").
> - "provided" scope will not include a version qualifier (eg. Import-Package: org.springframework.core).
> In this case, I believe the 'compile' behavior is correct.
> I have not tested all possible scopes. A similar inconsistency might exist for runtime, test, etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FELIX-548) Import-Package version qualifiers vary
depending on dependency scope.
Posted by "Stuart McCulloch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stuart McCulloch reassigned FELIX-548:
--------------------------------------
Assignee: Stuart McCulloch
> Import-Package version qualifiers vary depending on dependency scope.
> ---------------------------------------------------------------------
>
> Key: FELIX-548
> URL: https://issues.apache.org/jira/browse/FELIX-548
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
> Affects Versions: maven-bundle-plugin-1.4.0
> Environment: N/A
> Reporter: Thomas Dewire
> Assignee: Stuart McCulloch
> Priority: Minor
> Attachments: bugtest3.tar.gz
>
>
> The produced Import-Package directive appears to vary depending on the declared scope of a dependency.
> Assuming that a dependency is a valid OSGi bundle:
> - "compile" scope will include a version qualifier (eg. Import-Package: org.springframework.core;version="2.5.4").
> - "provided" scope will not include a version qualifier (eg. Import-Package: org.springframework.core).
> In this case, I believe the 'compile' behavior is correct.
> I have not tested all possible scopes. A similar inconsistency might exist for runtime, test, etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.