[jira] [Closed] (FELIX-4117) Automatic calculation of symbolic name is not working properly
[ https://issues.apache.org/jira/browse/FELIX-4117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed FELIX-4117. -- Resolution: Duplicate Automatic calculation of symbolic name is not working properly -- Key: FELIX-4117 URL: https://issues.apache.org/jira/browse/FELIX-4117 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-2.3.7 Environment: inside eclipse junit-plugin runner. Reporter: Cristiano Gavião Given that I have this settings in the pom: parent groupIdorg.lunifera/groupId artifactIdorg.lunifera.poc.subsystems.erp/artifactId version1.0.0-SNAPSHOT/version /parent artifactIdorg.lunifera.poc.subsystems.erp.it.jbehave.stories/artifactId packagingbundle/packaging I expected that the symbolic name was: org.lunifera.poc.subsystems.erp.it.jbehave.stories But what is being calculated is: org.lunifera.org.lunifera.poc.subsystems.erp.it.jbehave.stories -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (FELIX-3381) Support for {maven-test-resources} and {maven-test-sources} placeholders
[
https://issues.apache.org/jira/browse/FELIX-3381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved FELIX-3381.
Resolution: Fixed
Assignee: Guillaume Nodet
Patch applied, thx !
https://svn.apache.org/viewvc?view=revisionrevision=1602812
Support for {maven-test-resources} and {maven-test-sources} placeholders
Key: FELIX-3381
URL: https://issues.apache.org/jira/browse/FELIX-3381
Project: Felix
Issue Type: Improvement
Components: Maven Bundle Plugin
Reporter: Tuomas Kiviaho
Assignee: Guillaume Nodet
Priority: Minor
Labels: patch
Fix For: maven-bundle-plugin-2.4.1
Attachments: FELIX-3381.diff
I've found the plugin suitable for producing test bundles although bundle
plugin states that test scope isn't supported.
Currently I have to manually keep up with the test resources/sources so that
my test fragment bundle wouldn't be considering {maven-resources} and
{maven-sources}. This is quite ok compared to having a proper test-bundle
goal but I'd love to see corresponding {maven-test-resources} and
{maven-test-sources} placeholder support which would streamline the
configuration.
Now I'm getting WARN messages when I tamper with Include-Resource
_sourcepath. It is also quite error prone to manually list multiple resource
and source locations. Only classifier and outputDirectory have to be
configured in addition to these instructions and dependency embedding works
also when transitive dependencies are not used (in fact test scope isn't even
transitive)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (FELIX-4534) Bundles containing native code fails to start on Windows 7
[ https://issues.apache.org/jira/browse/FELIX-4534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved FELIX-4534. - Resolution: Fixed Thanks for confirming, Benoît. Bundles containing native code fails to start on Windows 7 -- Key: FELIX-4534 URL: https://issues.apache.org/jira/browse/FELIX-4534 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-4.2.0, framework-4.2.1, framework-4.4.0 Environment: Windows 7 Reporter: Benoît Thiébault Assignee: David Bosschaert Fix For: framework-4.6.0 Windows 7 system is not properly recognized which makes bundles containing native code fail to start. The OS name is retrieved using Java system property in org.apache.felix.Felix class, line 4481. OS name is then Windows 7, with a space. It is then normalized using method org.apache.felix.framework.util.manifestparser.R4LibraryClause.normalizeOSName() and stored in the configMap. OS name becomes windows7 without the space. When starting the bundle, method org.apache.felix.framework.util.manifestparser.R4LibraryClause.match() is called, retrieves the already normalized OS name (windows7) in the configMap and normalizes it again. This second normalisation fails as windows7 without the space is not recognized by method org.apache.felix.framework.util.manifestparser.R4LibraryClause.normalizeOSName(). In particular, the condition in the if statement line 392 is false when the OS name is windows7: if ((value.indexOf( 7) = 0) || value.equals(win7)) Possible solutions are: - prevent the OS name to be normalized twice (by checking if it is already normal) - improve the normalisation to deal with windows7 OS name (by replacing the if statement with if ((value.indexOf(7) = 0)) - no space) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FELIX-4530) [SCR Plugin] Revisit setting the default output to target/classes
[
https://issues.apache.org/jira/browse/FELIX-4530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14032215#comment-14032215
]
Felix Meschberger commented on FELIX-4530:
--
[~cziegeler] It's about a default behaviour of the bundle plugin and how the
SCR plugin interferes.
I am absolutely in favor of the SCR plugin adding the generated descriptors to
the project resources. But this is just the manifests not the complete folder
where they reside in.
If the only way to add the desciptors is to add the complete descriptor target
folder, then using target/classes is not a good idea because then you loose all
the fine tuning that the bundle plugin and bnd offer.
And maybe, it is the Sling tooling which should be more intelligent ?
[SCR Plugin] Revisit setting the default output to target/classes
-
Key: FELIX-4530
URL: https://issues.apache.org/jira/browse/FELIX-4530
Project: Felix
Issue Type: Bug
Components: SCR Tooling
Affects Versions: maven-scr-plugin 1.17.0
Reporter: Felix Meschberger
Priority: Critical
Fix For: maven-scr-plugin 1.17.2
With FELIX-4241 the default value for the descriptor output files has been
set to {{target/classes}}. Unfortunately this causes {{target/classes}} to be
added to the Maven Input Resources resulting in all contents of
{{target/classes}} to be included in the final bundle regardless of whether
this is actually desired or not.
Regardless of tooling integration noted in FELIX-4241, it is against the
spirit of the bundle plugin to blindly include everything in
{{target/classes}} in the bundle. So the resolution for FELIX-4241 must be
revisited.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Time for a new release of the maven-bundle-plugin?
Hi, There have been a number of fixes and features added to the maven-bundle-plugin, as well as a recent upgrade to bnd 2.3.0, so I was thinking of staging a release sometime this week. To test the latest snapshot, either build the plugin from source or add the following to your pom.xml and set the version in your maven-bundle-plugin declaration to 2.4.1-SNAPSHOT: pluginRepositories pluginRepository idapache.snapshots/id namesnapshot plugins/name urlhttp://repository.apache.org/snapshots/url releases enabledfalse/enabled /releases snapshots enabledtrue/enabled /snapshots /pluginRepository /pluginRepositories Let me know if you spot any regressions or bugs, or would like the release deferred to get in some additional fixes/features. -- Cheers, Stuart
Re: Time for a new release of the maven-bundle-plugin?
Sounds good to me, though I think it warrants a 2.5.0 release instead of a 2.4.1 ... 2014-06-16 12:10 GMT+02:00 Stuart McCulloch mccu...@gmail.com: Hi, There have been a number of fixes and features added to the maven-bundle-plugin, as well as a recent upgrade to bnd 2.3.0, so I was thinking of staging a release sometime this week. To test the latest snapshot, either build the plugin from source or add the following to your pom.xml and set the version in your maven-bundle-plugin declaration to 2.4.1-SNAPSHOT: pluginRepositories pluginRepository idapache.snapshots/id namesnapshot plugins/name urlhttp://repository.apache.org/snapshots/url releases enabledfalse/enabled /releases snapshots enabledtrue/enabled /snapshots /pluginRepository /pluginRepositories Let me know if you spot any regressions or bugs, or would like the release deferred to get in some additional fixes/features. -- Cheers, Stuart
[jira] [Commented] (FELIX-4534) Bundles containing native code fails to start on Windows 7
[ https://issues.apache.org/jira/browse/FELIX-4534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14032548#comment-14032548 ] Richard S. Hall commented on FELIX-4534: Looks good, David. Thanks! Bundles containing native code fails to start on Windows 7 -- Key: FELIX-4534 URL: https://issues.apache.org/jira/browse/FELIX-4534 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-4.2.0, framework-4.2.1, framework-4.4.0 Environment: Windows 7 Reporter: Benoît Thiébault Assignee: David Bosschaert Fix For: framework-4.6.0 Windows 7 system is not properly recognized which makes bundles containing native code fail to start. The OS name is retrieved using Java system property in org.apache.felix.Felix class, line 4481. OS name is then Windows 7, with a space. It is then normalized using method org.apache.felix.framework.util.manifestparser.R4LibraryClause.normalizeOSName() and stored in the configMap. OS name becomes windows7 without the space. When starting the bundle, method org.apache.felix.framework.util.manifestparser.R4LibraryClause.match() is called, retrieves the already normalized OS name (windows7) in the configMap and normalizes it again. This second normalisation fails as windows7 without the space is not recognized by method org.apache.felix.framework.util.manifestparser.R4LibraryClause.normalizeOSName(). In particular, the condition in the if statement line 392 is false when the OS name is windows7: if ((value.indexOf( 7) = 0) || value.equals(win7)) Possible solutions are: - prevent the OS name to be normalized twice (by checking if it is already normal) - improve the normalisation to deal with windows7 OS name (by replacing the if statement with if ((value.indexOf(7) = 0)) - no space) -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Bundle Repository release sometime soon?
Ok - I'll prepare the release soon. I'll also prepare a release for org.apache.felix.gogo.command as that contains a fix for the obr: commands... Cheers, David On 4 June 2014 11:52, David Bosschaert david.bosscha...@gmail.com wrote: Hi all, Since the Felix OBR now supports the OSGi Repository 1.0 spec [1], it might be worth doing a repository release sometime soon. I'm happy to volunteer preparing the release, but if someone else normally does it, that's fine with me too. Thoughts? David [1] http://www.mail-archive.com/dev@felix.apache.org/msg32974.html
[jira] [Commented] (FELIX-4530) [SCR Plugin] Revisit setting the default output to target/classes
[
https://issues.apache.org/jira/browse/FELIX-4530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14032638#comment-14032638
]
Carsten Ziegeler commented on FELIX-4530:
-
It's not the Sling tooling, it's m2e; maybe there is a way around and this can
be changed as well.
[SCR Plugin] Revisit setting the default output to target/classes
-
Key: FELIX-4530
URL: https://issues.apache.org/jira/browse/FELIX-4530
Project: Felix
Issue Type: Bug
Components: SCR Tooling
Affects Versions: maven-scr-plugin 1.17.0
Reporter: Felix Meschberger
Priority: Critical
Fix For: maven-scr-plugin 1.17.2
With FELIX-4241 the default value for the descriptor output files has been
set to {{target/classes}}. Unfortunately this causes {{target/classes}} to be
added to the Maven Input Resources resulting in all contents of
{{target/classes}} to be included in the final bundle regardless of whether
this is actually desired or not.
Regardless of tooling integration noted in FELIX-4241, it is against the
spirit of the bundle plugin to blindly include everything in
{{target/classes}} in the bundle. So the resolution for FELIX-4241 must be
revisited.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
