[jira] [Updated] (FELIX-3772) maven-bundle-plugin does not scan blueprint in workspace outside default location
[
https://issues.apache.org/jira/browse/FELIX-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stuart McCulloch updated FELIX-3772:
Fix Version/s: maven-bundle-plugin-2.4.0
> maven-bundle-plugin does not scan blueprint in workspace outside default
> location
> -
>
> Key: FELIX-3772
> URL: https://issues.apache.org/jira/browse/FELIX-3772
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.3.7
> Environment: Windows 7, Maven 3.0.4
>Reporter: Rigas Grigoropoulos
>Priority: Minor
> Fix For: maven-bundle-plugin-2.4.0
>
>
> maven-bundle-plugin will not scan blueprint xml files in the workspace during
> a Maven build, unless the blueprint file is located at OSGI-INF/blueprint/
> and an instruction "Bundle-Blueprint: OSGI-INF/blueprint" is provided.
> The bug is in org.apache.felix.bundleplugin.BlueprintPlugin and in method
> analyzeJar.
> Original code:
> String bpHeader = analyzer.getProperty( "Bundle-Blueprint",
> "OSGI-INF/blueprint" );
> Map> map = Processor.parseHeader(
> bpHeader, null );
> for ( String root : map.keySet() )
> {
> Jar jar = analyzer.getJar();
> Map dir = jar.getDirectories().get( root );
> if ( dir == null || dir.isEmpty() )
> {
> Resource resource = jar.getResource( root );
> if ( resource != null )
> process( analyzer, root, resource, headers );
> return false;
> }
> This code reads a custom location from the Bundle-Blueprint instruction,
> locates the resource in the classpath and does the processing, but then just
> returns false.
> Changing as follows fixes the problem:
>if ( resource != null )
> process( analyzer, root, resource, headers );
> continue;
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3565) Embed-Transitive leaks transitive dependencies of excluded artifacts
[ https://issues.apache.org/jira/browse/FELIX-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-3565: Fix Version/s: (was: maven-bundle-plugin-2.4.0) maven-bundle-plugin-2.4.1 > Embed-Transitive leaks transitive dependencies of excluded artifacts > > > Key: FELIX-3565 > URL: https://issues.apache.org/jira/browse/FELIX-3565 > Project: Felix > Issue Type: Bug > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.7 >Reporter: Tuomas Kiviaho > Labels: patch > Fix For: maven-bundle-plugin-2.4.1 > > Attachments: maven-bundle-plugin.patch > > > I was trying to re-config some of my projects so that I get compile(+runtime) > scoped dependencies and their transitive dependencies embedded by using > Embed-Transitive=true with the exception of dependencies that I had with type > bundle. Exclusion of bundles turned out to be trickier than I though because > I can't use provided scope without sacrificing the respective transitive > dependencies in the process. Everything went ok until I noticed that > inclusion process with the transitive dependencies of already excluded > compile scoped dependencies that had type set to bundle as shown below where > I'm getting bb-2.2 embedded although it should be excluded. > myproject (*;scope=compile|runtime;type=!bundle) > +a-1;scope=compile;type=jar // included ok > +aa-1.1;scope=compile;type=jar // included ok > -ab-1.2;scope=compile;type=bundle // excluded ok and there are no > transitive dependency candidates available > -ac-1.3;scope=provided;type=bundle // excluded ok because scope is provided > -aca-1.3.1;scope=compile;type=jar // excluded ok although scope is > compile because provided scope doesn't reveal any of the existing > dependencies as transitive dependencies > -b-2;scope=compile;type=bundle // excluded ok because type is bundle > -ba-2.1;scope=provided;type=jar // excluded ok because scope is provided > +bb-2.2;scope=compile;type=jar // NOT excluded ok because parent already > excluded > In short: Everything not matching exclusion pattern (and matching inclusion > pattern) will be excluded no matter if their origin has been already excluded. > I checked the codebase and noticed that the reason for having 'NOTE: test > scoped dependencies are not included in the classpath seen by BND.' on the > web page accumulated from the problem. It seems that dependency tree shared > component seems to have given problems before and that Aether isn't backwards > compatible but I suggest giving a try to maven-dependency-tree 2.0 that is > Aether based for Maven 3 but remains still backwards compatible with Maven 2. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3973) Exclusion from {local-packages} doesn't work anymore
[
https://issues.apache.org/jira/browse/FELIX-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stuart McCulloch resolved FELIX-3973.
-
Resolution: Fixed
Applied in r1490854 - thanks!
> Exclusion from {local-packages} doesn't work anymore
>
>
> Key: FELIX-3973
> URL: https://issues.apache.org/jira/browse/FELIX-3973
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
> Environment: bnd 2.0.0.x
>Reporter: Tuomas Kiviaho
> Labels: patch
> Fix For: maven-bundle-plugin-2.4.0
>
> Attachments: FELIX-3973.diff
>
>
> I've been using Export-Package: !org.apache.jsp.*, {local-packages} to
> exclude jspc compilers output, but with BND 2.0.0 this stopped working
> completely (although until now I was getting a bunch of warnings).
> BND currently gives a second chance to non matching packages. This feature
> will rended !org.apache.jsp.* useless since {local-packages} is expanded to
> clause that contains org.apache.jsp prefixed packages.
> A fix would be to pre-filter the {local-packages} against
> Export/Private-Package clauses
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3324) Allow maven-bundle-plugin:manifest to dump SCR component definitions generated by bnd
[ https://issues.apache.org/jira/browse/FELIX-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-3324: Fix Version/s: (was: maven-bundle-plugin-2.4.0) maven-bundle-plugin-2.4.1 > Allow maven-bundle-plugin:manifest to dump SCR component definitions > generated by bnd > - > > Key: FELIX-3324 > URL: https://issues.apache.org/jira/browse/FELIX-3324 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.6 >Reporter: Ivan Dubrov > Labels: patch > Fix For: maven-bundle-plugin-2.4.1 > > Attachments: export-scr.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > maven-bundle-plugin allows dumping generated MANIFEST.MF, but does not allow > dumping SCR component definitions generated by the bnd (based on the > component annotations). For example, this could be useful if you need those > files to run the OSGi framework from the IDE without packaging everything. > "unpackBundle" allows achieving the desired behaviour, but it could be too > heavy for large bundles. > I suggest adding two properties to the plugin, "exportScr" to enable SCR > definitions export and "scrLocation" to specify directory to dump those > definitions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3349) wrong bundle manifest contents in some cases
[
https://issues.apache.org/jira/browse/FELIX-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stuart McCulloch resolved FELIX-3349.
-
Resolution: Fixed
Fixed in r1490846
> wrong bundle manifest contents in some cases
>
>
> Key: FELIX-3349
> URL: https://issues.apache.org/jira/browse/FELIX-3349
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.3.6
>Reporter: Igor Fedorenko
> Fix For: maven-bundle-plugin-2.4.0
>
> Attachments: mbp-wrong-bsn.zip
>
>
> When maven-jar-plugin configuration uses relative manifestFile path (i.e.
> META-INF/MANIFEST.MF),
> org.apache.felix.bundleplugin.JarPluginConfiguration will calculate
> manifestFile relative to JVM current working directory instead of
> ${project.basedir}. This can result in unexpected/wrong generated bundle
> manifest contents for multi-module projects. I'll attach an example project
> that demonstrates the problem shortly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3352) Maven Bundle Plugin ignores resource properties configured inside section
[ https://issues.apache.org/jira/browse/FELIX-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch resolved FELIX-3352. - Resolution: Fixed Fixed in r1490836 > Maven Bundle Plugin ignores resource properties configured inside > section > --- > > Key: FELIX-3352 > URL: https://issues.apache.org/jira/browse/FELIX-3352 > Project: Felix > Issue Type: Bug > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.6 >Reporter: Ivan Dubrov > Labels: patch > Fix For: maven-bundle-plugin-2.4.0 > > Attachments: felix-3352.patch, felix-3352.zip > > > maven-bundle-plugin does not pass properties from the files configured inside > section to the BND. As a result, all properties configured > in external filter files are unresolved in the final bundle. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3582) finalName not properly populated in maven-bundle-plugin with buildnumber-maven-plugin
[
https://issues.apache.org/jira/browse/FELIX-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stuart McCulloch resolved FELIX-3582.
-
Resolution: Fixed
Fixed in r1490801
> finalName not properly populated in maven-bundle-plugin with
> buildnumber-maven-plugin
> -
>
> Key: FELIX-3582
> URL: https://issues.apache.org/jira/browse/FELIX-3582
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.3.7
>Reporter: Jason Woodrich
>Priority: Minor
> Labels: patch
> Fix For: maven-bundle-plugin-2.4.0
>
>
> If the finalName element in the build section contains elements that are
> dynamically populated, such as ${buildNumber}, and the packaging element is
> set to bundle, the literal string "${buildNumber}" will appear in the jar
> file that's produced. I took a look at the source code and found what I
> believe to be the problem and applied a fix in a local copy of the source
> code. In org/apache/felix/bundleplugin/BundleInfo.java:1113 there is this
> line of code:
> String finalName = currentProject.getBuild().getFinalName();
> I removed this line (1113) and added the following near the top of the class:
> /**
> * Name of the generated JAR.
> * @parameter alias="jarName" expression="${jar.finalName}"
> default-value="${project.build.finalName}"
> * @required
> */
> private String finalName;
> This properly populates the finalName in the jar file and all of the unit
> tests pass. I'm not sure if this affects anything else but as far as I can
> tell it doesn't.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3462) Nicer Manifest formatting does not work in maven bundle plugin
[ https://issues.apache.org/jira/browse/FELIX-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-3462: Fix Version/s: (was: maven-bundle-plugin-2.4.0) maven-bundle-plugin-2.4.1 > Nicer Manifest formatting does not work in maven bundle plugin > -- > > Key: FELIX-3462 > URL: https://issues.apache.org/jira/browse/FELIX-3462 > Project: Felix > Issue Type: Bug > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.7 >Reporter: Christian Schneider > Fix For: maven-bundle-plugin-2.4.1 > > > Version 2.3.6 introduced the nicer formatting for manifests where after each > e.g. Import package a newline should happen. This never worked for me. I > already asked on the original issue but never got an answer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-974) Possibility to install dependencies to obr repository when installing maven artifact
[ https://issues.apache.org/jira/browse/FELIX-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-974: --- Fix Version/s: (was: maven-bundle-plugin-2.4.0) maven-bundle-plugin-2.4.1 > Possibility to install dependencies to obr repository when installing maven > artifact > > > Key: FELIX-974 > URL: https://issues.apache.org/jira/browse/FELIX-974 > Project: Felix > Issue Type: New Feature > Components: Maven Bundle Plugin >Reporter: Kristian Koehler > Labels: patch > Fix For: maven-bundle-plugin-2.4.1 > > Attachments: FELIX-974-patch-29_07_2009.txt, > FELIX-974-patch-30_04_2009.txt, patch.txt, > patch-with-one-write-operation.txt, patch-with-transitive-deps.txt > > > Hi > currently there is no option to add the project dependencies to the local obr > repository file. This prevents me to use the local obr at all because some > dependencies are not available via 'obr update'. If the plugin would also add > the dependencies to the local obr file I could install my bundles with all > dependencies from there. > Kristian -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3994) Optional merging of duplicate manifest headers
[
https://issues.apache.org/jira/browse/FELIX-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stuart McCulloch updated FELIX-3994:
Fix Version/s: (was: maven-bundle-plugin-2.4.0)
maven-bundle-plugin-2.4.1
> Optional merging of duplicate manifest headers
> --
>
> Key: FELIX-3994
> URL: https://issues.apache.org/jira/browse/FELIX-3994
> Project: Felix
> Issue Type: Improvement
> Components: Maven Bundle Plugin
>Reporter: Tuomas Kiviaho
>Priority: Minor
> Labels: patch
> Fix For: maven-bundle-plugin-2.4.1
>
> Attachments: FELIX-3994.diff
>
>
> Bundle plugin seems to always overwrite exported manifest. There are
> currently several other ways of merging manifest headers together but none of
> them can merge duplicated headers back to one or omit unwanted/uninteresting
> headers altogether.
> [Archiver|http://maven.apache.org/shared/maven-archiver/examples/manifestFile.html]
> can already be used pass headers to BND process but what I'm after is to
> only have an impact what is written out to the manifest location at the end
> and not tamper with the produced artifact itself.
> The idea is to be able to print out project artifact's manifest for Eclipse
> PDE and later on selectively overlay it with test artifact's manifest so that
> PDE sees simultaneously information from both artifacts excluding test-only
> headers such as {{Fragment-Host}} and those starting with {{Bundle-}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (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
]
Stuart McCulloch updated FELIX-3381:
Fix Version/s: (was: maven-bundle-plugin-2.4.0)
maven-bundle-plugin-2.4.1
> 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
>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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3497) Wrong artifact type attached as a secondary artifact when project packaging is set to "pom"
[
https://issues.apache.org/jira/browse/FELIX-3497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stuart McCulloch resolved FELIX-3497.
-
Resolution: Fixed
Fixed in r1490772
> Wrong artifact type attached as a secondary artifact when project packaging
> is set to "pom"
> ---
>
> Key: FELIX-3497
> URL: https://issues.apache.org/jira/browse/FELIX-3497
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.3.7
> Environment: any
>Reporter: Martin Petrovsky
> Labels: maven, maven-bundle-plugin, patch
> Fix For: maven-bundle-plugin-2.4.0
>
> Attachments: example.pom, maven-bundle-fix.patch
>
>
> When trying to create a ${artifactid}-tests.jar in a maven project that does
> not produce a primary bundle the plugin attaches the ${artifactid}-tests.jar
> bundle as ${artifactid}-tests.pom. The plugin does not abide by the
> "jar" config.
> I have attached both an example POM and a simple fix in the form of a patch.
> Example POM:
> {code}
>
> foo
> bar
> 1.5.1-SNAPSHOT
> pom
>
>
>
>
> org.apache.felix
> maven-bundle-plugin
>
>
> bundle-tests
> package
>
> bundle
>
>
>
> tests
> jar
>
> pom
>
> target/test-classes
>
>
> com.foo.*
>
> .*Test
> Integration
> Tests - ${project.description}
> Integration Tests
> for ${project.name}
>
> ${groupId}.${artifactId}-tests
>
>
>
>
>
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3619) "IOException: Failed to delete repository.xml while trying to rename" in maven-bundle-plugin
[ https://issues.apache.org/jira/browse/FELIX-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch resolved FELIX-3619. - Resolution: Fixed Fixed in r1490744 > "IOException: Failed to delete repository.xml while trying to rename" in > maven-bundle-plugin > > > Key: FELIX-3619 > URL: https://issues.apache.org/jira/browse/FELIX-3619 > Project: Felix > Issue Type: Bug > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.6 >Reporter: Victor Burdejny >Priority: Minor > Fix For: maven-bundle-plugin-2.4.0 > > Attachments: maven-repository-xml-issue.txt > > > The following problem has been found in console when parallel build was used > (-T command line parameter): > [INFO] — maven-bundle-plugin:2.3.6:install (default-install) @ my-bundle — > [WARNING] Exception while updating local OBR: IOException > org.apache.maven.plugin.MojoExecutionException: IOException > at > org.apache.felix.obrplugin.ObrUpdate.writeRepositoryXml(ObrUpdate.java:293) > at org.apache.felix.obrplugin.ObrInstall.execute(ObrInstall.java:149) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > ... > 'stderr' contains the following stacktrace: > java.io.IOException: Failed to delete c:\.m2\repository.xml while trying to > rename C:\Users\User\AppData\Local\Temp\repository8243840781003249024.xml > at org.codehaus.plexus.util.FileUtils.rename(FileUtils.java:2128) > at > org.apache.felix.obrplugin.ObrUpdate.writeRepositoryXml(ObrUpdate.java:288) > ... > Full stacktraces are provided in the attachment. > I did not find any problems that it causes for the build, but I suspect that > such problems might exist. The problem itself is (I suspect) a trivial race > condition. > Cloned from http://jira.codehaus.org/browse/MNG-5321 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-974) Possibility to install dependencies to obr repository when installing maven artifact
[ https://issues.apache.org/jira/browse/FELIX-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-974: --- Labels: patch (was: ) > Possibility to install dependencies to obr repository when installing maven > artifact > > > Key: FELIX-974 > URL: https://issues.apache.org/jira/browse/FELIX-974 > Project: Felix > Issue Type: New Feature > Components: Maven Bundle Plugin >Reporter: Kristian Koehler > Labels: patch > Fix For: maven-bundle-plugin-2.4.0 > > Attachments: FELIX-974-patch-29_07_2009.txt, > FELIX-974-patch-30_04_2009.txt, patch.txt, > patch-with-one-write-operation.txt, patch-with-transitive-deps.txt > > > Hi > currently there is no option to add the project dependencies to the local obr > repository file. This prevents me to use the local obr at all because some > dependencies are not available via 'obr update'. If the plugin would also add > the dependencies to the local obr file I could install my bundles with all > dependencies from there. > Kristian -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3973) Exclusion from {local-packages} doesn't work anymore
[
https://issues.apache.org/jira/browse/FELIX-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stuart McCulloch updated FELIX-3973:
Labels: patch (was: )
> Exclusion from {local-packages} doesn't work anymore
>
>
> Key: FELIX-3973
> URL: https://issues.apache.org/jira/browse/FELIX-3973
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
> Environment: bnd 2.0.0.x
>Reporter: Tuomas Kiviaho
> Labels: patch
> Fix For: maven-bundle-plugin-2.4.0
>
> Attachments: FELIX-3973.diff
>
>
> I've been using Export-Package: !org.apache.jsp.*, {local-packages} to
> exclude jspc compilers output, but with BND 2.0.0 this stopped working
> completely (although until now I was getting a bunch of warnings).
> BND currently gives a second chance to non matching packages. This feature
> will rended !org.apache.jsp.* useless since {local-packages} is expanded to
> clause that contains org.apache.jsp prefixed packages.
> A fix would be to pre-filter the {local-packages} against
> Export/Private-Package clauses
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3352) Maven Bundle Plugin ignores resource properties configured inside section
[ https://issues.apache.org/jira/browse/FELIX-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-3352: Labels: patch (was: ) > Maven Bundle Plugin ignores resource properties configured inside > section > --- > > Key: FELIX-3352 > URL: https://issues.apache.org/jira/browse/FELIX-3352 > Project: Felix > Issue Type: Bug > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.6 >Reporter: Ivan Dubrov > Labels: patch > Fix For: maven-bundle-plugin-2.4.0 > > Attachments: felix-3352.patch, felix-3352.zip > > > maven-bundle-plugin does not pass properties from the files configured inside > section to the BND. As a result, all properties configured > in external filter files are unresolved in the final bundle. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3324) Allow maven-bundle-plugin:manifest to dump SCR component definitions generated by bnd
[ https://issues.apache.org/jira/browse/FELIX-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-3324: Labels: patch (was: ) > Allow maven-bundle-plugin:manifest to dump SCR component definitions > generated by bnd > - > > Key: FELIX-3324 > URL: https://issues.apache.org/jira/browse/FELIX-3324 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.6 >Reporter: Ivan Dubrov > Labels: patch > Fix For: maven-bundle-plugin-2.4.0 > > Attachments: export-scr.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > maven-bundle-plugin allows dumping generated MANIFEST.MF, but does not allow > dumping SCR component definitions generated by the bnd (based on the > component annotations). For example, this could be useful if you need those > files to run the OSGi framework from the IDE without packaging everything. > "unpackBundle" allows achieving the desired behaviour, but it could be too > heavy for large bundles. > I suggest adding two properties to the plugin, "exportScr" to enable SCR > definitions export and "scrLocation" to specify directory to dump those > definitions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3994) Optional merging of duplicate manifest headers
[
https://issues.apache.org/jira/browse/FELIX-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stuart McCulloch updated FELIX-3994:
Labels: patch (was: )
> Optional merging of duplicate manifest headers
> --
>
> Key: FELIX-3994
> URL: https://issues.apache.org/jira/browse/FELIX-3994
> Project: Felix
> Issue Type: Improvement
> Components: Maven Bundle Plugin
>Reporter: Tuomas Kiviaho
>Priority: Minor
> Labels: patch
> Fix For: maven-bundle-plugin-2.4.0
>
> Attachments: FELIX-3994.diff
>
>
> Bundle plugin seems to always overwrite exported manifest. There are
> currently several other ways of merging manifest headers together but none of
> them can merge duplicated headers back to one or omit unwanted/uninteresting
> headers altogether.
> [Archiver|http://maven.apache.org/shared/maven-archiver/examples/manifestFile.html]
> can already be used pass headers to BND process but what I'm after is to
> only have an impact what is written out to the manifest location at the end
> and not tamper with the produced artifact itself.
> The idea is to be able to print out project artifact's manifest for Eclipse
> PDE and later on selectively overlay it with test artifact's manifest so that
> PDE sees simultaneously information from both artifacts excluding test-only
> headers such as {{Fragment-Host}} and those starting with {{Bundle-}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3582) finalName not properly populated in maven-bundle-plugin with buildnumber-maven-plugin
[
https://issues.apache.org/jira/browse/FELIX-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stuart McCulloch updated FELIX-3582:
Labels: patch (was: )
> finalName not properly populated in maven-bundle-plugin with
> buildnumber-maven-plugin
> -
>
> Key: FELIX-3582
> URL: https://issues.apache.org/jira/browse/FELIX-3582
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.3.7
>Reporter: Jason Woodrich
>Priority: Minor
> Labels: patch
> Fix For: maven-bundle-plugin-2.4.0
>
>
> If the finalName element in the build section contains elements that are
> dynamically populated, such as ${buildNumber}, and the packaging element is
> set to bundle, the literal string "${buildNumber}" will appear in the jar
> file that's produced. I took a look at the source code and found what I
> believe to be the problem and applied a fix in a local copy of the source
> code. In org/apache/felix/bundleplugin/BundleInfo.java:1113 there is this
> line of code:
> String finalName = currentProject.getBuild().getFinalName();
> I removed this line (1113) and added the following near the top of the class:
> /**
> * Name of the generated JAR.
> * @parameter alias="jarName" expression="${jar.finalName}"
> default-value="${project.build.finalName}"
> * @required
> */
> private String finalName;
> This properly populates the finalName in the jar file and all of the unit
> tests pass. I'm not sure if this affects anything else but as far as I can
> tell it doesn't.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (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
]
Stuart McCulloch updated FELIX-3381:
Labels: patch (was: )
> 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
>Priority: Minor
> Labels: patch
> Fix For: maven-bundle-plugin-2.4.0
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3565) Embed-Transitive leaks transitive dependencies of excluded artifacts
[ https://issues.apache.org/jira/browse/FELIX-3565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-3565: Labels: patch (was: ) > Embed-Transitive leaks transitive dependencies of excluded artifacts > > > Key: FELIX-3565 > URL: https://issues.apache.org/jira/browse/FELIX-3565 > Project: Felix > Issue Type: Bug > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.7 >Reporter: Tuomas Kiviaho > Labels: patch > Fix For: maven-bundle-plugin-2.4.0 > > Attachments: maven-bundle-plugin.patch > > > I was trying to re-config some of my projects so that I get compile(+runtime) > scoped dependencies and their transitive dependencies embedded by using > Embed-Transitive=true with the exception of dependencies that I had with type > bundle. Exclusion of bundles turned out to be trickier than I though because > I can't use provided scope without sacrificing the respective transitive > dependencies in the process. Everything went ok until I noticed that > inclusion process with the transitive dependencies of already excluded > compile scoped dependencies that had type set to bundle as shown below where > I'm getting bb-2.2 embedded although it should be excluded. > myproject (*;scope=compile|runtime;type=!bundle) > +a-1;scope=compile;type=jar // included ok > +aa-1.1;scope=compile;type=jar // included ok > -ab-1.2;scope=compile;type=bundle // excluded ok and there are no > transitive dependency candidates available > -ac-1.3;scope=provided;type=bundle // excluded ok because scope is provided > -aca-1.3.1;scope=compile;type=jar // excluded ok although scope is > compile because provided scope doesn't reveal any of the existing > dependencies as transitive dependencies > -b-2;scope=compile;type=bundle // excluded ok because type is bundle > -ba-2.1;scope=provided;type=jar // excluded ok because scope is provided > +bb-2.2;scope=compile;type=jar // NOT excluded ok because parent already > excluded > In short: Everything not matching exclusion pattern (and matching inclusion > pattern) will be excluded no matter if their origin has been already excluded. > I checked the codebase and noticed that the reason for having 'NOTE: test > scoped dependencies are not included in the classpath seen by BND.' on the > web page accumulated from the problem. It seems that dependency tree shared > component seems to have given problems before and that Aether isn't backwards > compatible but I suggest giving a try to maven-dependency-tree 2.0 that is > Aether based for Maven 3 but remains still backwards compatible with Maven 2. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-4066) Unable to load blueprint augmented jars with OBR
[ https://issues.apache.org/jira/browse/FELIX-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-4066: Component/s: (was: Manifest Generator (mangen)) > Unable to load blueprint augmented jars with OBR > > > Key: FELIX-4066 > URL: https://issues.apache.org/jira/browse/FELIX-4066 > Project: Felix > Issue Type: Bug > Components: Bundle Repository (OBR), Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.7 >Reporter: Andrew Schurman > Fix For: maven-bundle-plugin-future > > Attachments: example.tar.gz > > > There appear to be 2 somewhat related issues regarding consuming blueprint > augmented bundles in OBR. Both stem from the generated manifest: > 1) when exporting a service bean with 2 or more interfaces, only the first is > exposed in the manifest > 2) when importing a service via interface and component-name, you never find > the service as the component-name is never exposed on the exporting side -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FELIX-3060) WAR overlay projects seem to generate incorrect imports
[ https://issues.apache.org/jira/browse/FELIX-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch closed FELIX-3060. --- Resolution: Incomplete Closing as stale issue - if you have more details (ie. example project) please attach and re-open > WAR overlay projects seem to generate incorrect imports > --- > > Key: FELIX-3060 > URL: https://issues.apache.org/jira/browse/FELIX-3060 > Project: Felix > Issue Type: Bug > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.4 > Environment: Maven 3.0.3 > Windows XP SP3 >Reporter: Kristoffer Peterhänsel > > To do a slightly specialized version of a WAR bundle I exploited the overlay > feature of the WAR plugin. > In general it seems to have worked pretty well. But I am getting imports of > packages that I have gotten from then project I am overlaying. > The odd thing is that I have no actual code in my new Maven project. So for > some reason bnd is reading required packages from the classes from the > original project. But it is not registering that they are already there. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3060) WAR overlay projects seem to generate incorrect imports
[ https://issues.apache.org/jira/browse/FELIX-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-3060: Fix Version/s: (was: maven-bundle-plugin-future) > WAR overlay projects seem to generate incorrect imports > --- > > Key: FELIX-3060 > URL: https://issues.apache.org/jira/browse/FELIX-3060 > Project: Felix > Issue Type: Bug > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.4 > Environment: Maven 3.0.3 > Windows XP SP3 >Reporter: Kristoffer Peterhänsel > > To do a slightly specialized version of a WAR bundle I exploited the overlay > feature of the WAR plugin. > In general it seems to have worked pretty well. But I am getting imports of > packages that I have gotten from then project I am overlaying. > The odd thing is that I have no actual code in my new Maven project. So for > some reason bnd is reading required packages from the classes from the > original project. But it is not registering that they are already there. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3060) WAR overlay projects seem to generate incorrect imports
[ https://issues.apache.org/jira/browse/FELIX-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-3060: Fix Version/s: maven-bundle-plugin-future > WAR overlay projects seem to generate incorrect imports > --- > > Key: FELIX-3060 > URL: https://issues.apache.org/jira/browse/FELIX-3060 > Project: Felix > Issue Type: Bug > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.4 > Environment: Maven 3.0.3 > Windows XP SP3 >Reporter: Kristoffer Peterhänsel > Fix For: maven-bundle-plugin-future > > > To do a slightly specialized version of a WAR bundle I exploited the overlay > feature of the WAR plugin. > In general it seems to have worked pretty well. But I am getting imports of > packages that I have gotten from then project I am overlaying. > The odd thing is that I have no actual code in my new Maven project. So for > some reason bnd is reading required packages from the classes from the > original project. But it is not registering that they are already there. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3460) Warning for duplicate package imports
[ https://issues.apache.org/jira/browse/FELIX-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678075#comment-13678075 ] Stuart McCulloch commented on FELIX-3460: - Can you add a test project that shows the problem? You also might want to try the latest 2.4.0-SNAPSHOT available from https://repository.apache.org/content/groups/snapshots/org/apache/felix/maven-bundle-plugin/2.4.0-SNAPSHOT/ (or you can build from source) as it includes the latest version of bnd which has improved error handling/detection. > Warning for duplicate package imports > - > > Key: FELIX-3460 > URL: https://issues.apache.org/jira/browse/FELIX-3460 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.4 >Reporter: Basil Brunner >Priority: Minor > > Recently I had a problem with an invalid manifest due to a duplicate package > import statement. It would be helpful if the Maven Bundle Plugin displays an > error message if there is a duplicate package import. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3472) Source inclusion for targets of
[ https://issues.apache.org/jira/browse/FELIX-3472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-3472: Fix Version/s: maven-bundle-plugin-future > Source inclusion for targets of > --- > > Key: FELIX-3472 > URL: https://issues.apache.org/jira/browse/FELIX-3472 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.7 >Reporter: Brian Topping >Priority: Minor > Fix For: maven-bundle-plugin-future > > > This seems like it would be rather hideous to fix, but I didn't see it > anywhere and thought I would note it. > When the instruction is used along with the > maven-source-plugin, source artifacts that otherwise exist alongside the > dependency jar artifacts are not included in the source jars of the artifact > being built. It's not difficult to manually add the source jars for each > embedded dependency on a remote project, but gets annoying when changes to > the project cause the source jar attachments to be wiped out when the project > is reloaded. > It seems like it would be difficult to fix because either maven-source-plugin > needs to know about the various locations that bundle instructions can live > or bundle plugin needs to add sources to existing source jars. Both of of > those solutions violate containment of the other plugin's role. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3937) Issues with maven-bundle-plugin
[ https://issues.apache.org/jira/browse/FELIX-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-3937: Fix Version/s: maven-bundle-plugin-question > Issues with maven-bundle-plugin > --- > > Key: FELIX-3937 > URL: https://issues.apache.org/jira/browse/FELIX-3937 > Project: Felix > Issue Type: Bug > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.7 > Environment: Windows, Solaris >Reporter: Ramkumar Rao >Priority: Minor > Labels: newbie > Fix For: maven-bundle-plugin-question > > > My situation is that, I am trying to change the implementation of a class in > an existing bundle, for which I don't have the rights to edit. The existing > bundle has got additional classes which I don't intend to modify. > As a workaround, I am trying to create a secondary bundle with only the > overridden implementation classes and use maven dependency plugin to copy > the remaining classes which I don't intend to modify. > When I override the intended class and try to create a new version of the > bundle by including all the un-touched classes, I ran into an problem of not > able to eliminate the original class from the bundle. > The maven bundle plugin is including all the classes from the original > bundle, even when there exist only few classes from the original bundle. I am > not able to workaround this issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3937) Issues with maven-bundle-plugin
[ https://issues.apache.org/jira/browse/FELIX-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-3937: Fix Version/s: (was: maven-bundle-plugin-question) > Issues with maven-bundle-plugin > --- > > Key: FELIX-3937 > URL: https://issues.apache.org/jira/browse/FELIX-3937 > Project: Felix > Issue Type: Bug > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.7 > Environment: Windows, Solaris >Reporter: Ramkumar Rao >Priority: Minor > Labels: newbie > > My situation is that, I am trying to change the implementation of a class in > an existing bundle, for which I don't have the rights to edit. The existing > bundle has got additional classes which I don't intend to modify. > As a workaround, I am trying to create a secondary bundle with only the > overridden implementation classes and use maven dependency plugin to copy > the remaining classes which I don't intend to modify. > When I override the intended class and try to create a new version of the > bundle by including all the un-touched classes, I ran into an problem of not > able to eliminate the original class from the bundle. > The maven bundle plugin is including all the classes from the original > bundle, even when there exist only few classes from the original bundle. I am > not able to workaround this issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2991) Allow the creating of fragments that populate Export-Package
[ https://issues.apache.org/jira/browse/FELIX-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678065#comment-13678065 ] Stuart McCulloch commented on FELIX-2991: - You might want to try the latest 2.4.0-SNAPSHOT available from https://repository.apache.org/content/groups/snapshots/org/apache/felix/maven-bundle-plugin/2.4.0-SNAPSHOT/ (or you can build from source) as it includes the latest version of bnd. > Allow the creating of fragments that populate Export-Package > - > > Key: FELIX-2991 > URL: https://issues.apache.org/jira/browse/FELIX-2991 > Project: Felix > Issue Type: New Feature > Components: Maven Bundle Plugin >Reporter: Michael Van Geertruy > Fix For: maven-bundle-plugin-patches-welcome > > > When using the maven-bundle-plugin to create fragments which add > export-packages to a host bundle, the maven-bundle-plugin considers all of > the export-packages as superfluous, does not add them to the fragment's > MANIFEST.MF file and fails to compile. > The specific case is when attempting to add exports to a bundle where > bnd-wrapping doesn't pick up all of the necessary packages. For example, when > executing this line in Karaf: > osgi:install -s mvn:tibco/tibco-crypt/5.1.2 > The wrap command skips over a number of packages. So creation of a fragment > is necessary. However, the build fails for the above noted reason. The > work-around for this issue is to use the maven-jar-plugin to create the > fragment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3937) Issues with maven-bundle-plugin
[ https://issues.apache.org/jira/browse/FELIX-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678067#comment-13678067 ] Stuart McCulloch commented on FELIX-3937: - Can you attach an example project? There are various macros which you could use with other instructions to select classes, such as $(classes;...) which is described in http://www.aqute.biz/Bnd/Macros#classesx and you can also use the -split-package: directive to decide how to merge overlapping packages, see the sub-section under http://www.aqute.biz/Bnd/Format#export-package > Issues with maven-bundle-plugin > --- > > Key: FELIX-3937 > URL: https://issues.apache.org/jira/browse/FELIX-3937 > Project: Felix > Issue Type: Bug > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.7 > Environment: Windows, Solaris >Reporter: Ramkumar Rao >Priority: Minor > Labels: newbie > > My situation is that, I am trying to change the implementation of a class in > an existing bundle, for which I don't have the rights to edit. The existing > bundle has got additional classes which I don't intend to modify. > As a workaround, I am trying to create a secondary bundle with only the > overridden implementation classes and use maven dependency plugin to copy > the remaining classes which I don't intend to modify. > When I override the intended class and try to create a new version of the > bundle by including all the un-touched classes, I ran into an problem of not > able to eliminate the original class from the bundle. > The maven bundle plugin is including all the classes from the original > bundle, even when there exist only few classes from the original bundle. I am > not able to workaround this issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-974) Possibility to install dependencies to obr repository when installing maven artifact
[ https://issues.apache.org/jira/browse/FELIX-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-974: --- Fix Version/s: (was: maven-bundle-plugin-patches-welcome) maven-bundle-plugin-2.4.0 > Possibility to install dependencies to obr repository when installing maven > artifact > > > Key: FELIX-974 > URL: https://issues.apache.org/jira/browse/FELIX-974 > Project: Felix > Issue Type: New Feature > Components: Maven Bundle Plugin >Reporter: Kristian Koehler > Fix For: maven-bundle-plugin-2.4.0 > > Attachments: FELIX-974-patch-29_07_2009.txt, > FELIX-974-patch-30_04_2009.txt, patch.txt, > patch-with-one-write-operation.txt, patch-with-transitive-deps.txt > > > Hi > currently there is no option to add the project dependencies to the local obr > repository file. This prevents me to use the local obr at all because some > dependencies are not available via 'obr update'. If the plugin would also add > the dependencies to the local obr file I could install my bundles with all > dependencies from there. > Kristian -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-974) Possibility to install dependencies to obr repository when installing maven artifact
[ https://issues.apache.org/jira/browse/FELIX-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-974: --- Fix Version/s: maven-bundle-plugin-patches-welcome > Possibility to install dependencies to obr repository when installing maven > artifact > > > Key: FELIX-974 > URL: https://issues.apache.org/jira/browse/FELIX-974 > Project: Felix > Issue Type: New Feature > Components: Maven Bundle Plugin >Reporter: Kristian Koehler > Fix For: maven-bundle-plugin-patches-welcome > > Attachments: FELIX-974-patch-29_07_2009.txt, > FELIX-974-patch-30_04_2009.txt, patch.txt, > patch-with-one-write-operation.txt, patch-with-transitive-deps.txt > > > Hi > currently there is no option to add the project dependencies to the local obr > repository file. This prevents me to use the local obr at all because some > dependencies are not available via 'obr update'. If the plugin would also add > the dependencies to the local obr file I could install my bundles with all > dependencies from there. > Kristian -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-2991) Allow the creating of fragments that populate Export-Package
[ https://issues.apache.org/jira/browse/FELIX-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-2991: Fix Version/s: maven-bundle-plugin-patches-welcome > Allow the creating of fragments that populate Export-Package > - > > Key: FELIX-2991 > URL: https://issues.apache.org/jira/browse/FELIX-2991 > Project: Felix > Issue Type: New Feature > Components: Maven Bundle Plugin >Reporter: Michael Van Geertruy > Fix For: maven-bundle-plugin-patches-welcome > > > When using the maven-bundle-plugin to create fragments which add > export-packages to a host bundle, the maven-bundle-plugin considers all of > the export-packages as superfluous, does not add them to the fragment's > MANIFEST.MF file and fails to compile. > The specific case is when attempting to add exports to a bundle where > bnd-wrapping doesn't pick up all of the necessary packages. For example, when > executing this line in Karaf: > osgi:install -s mvn:tibco/tibco-crypt/5.1.2 > The wrap command skips over a number of packages. So creation of a fragment > is necessary. However, the build fails for the above noted reason. The > work-around for this issue is to use the maven-jar-plugin to create the > fragment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3392) Generated Manifest ignores properties set by other plugins
[
https://issues.apache.org/jira/browse/FELIX-3392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stuart McCulloch updated FELIX-3392:
Fix Version/s: maven-bundle-plugin-patches-welcome
> Generated Manifest ignores properties set by other plugins
> --
>
> Key: FELIX-3392
> URL: https://issues.apache.org/jira/browse/FELIX-3392
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.3.7
>Reporter: Paul Gier
> Fix For: maven-bundle-plugin-patches-welcome
>
> Attachments: test-bundle-properties.zip
>
>
> My usecase is that I want to generate a build timestamp for my build using
> the buildnumber-maven-plugin, then add this timestamp to my jar manifest.
> Using the maven jar plugin, this works as expected and the property is set.
> Using the bundle plugin, the property is not resolved and I get something
> like "${timestamp}" in my manifest. It appears that the bundle plugin does
> not resolve properties that were set earlier in the build.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-4009) maven bundle plugin should be integrated directly with eclipse
[ https://issues.apache.org/jira/browse/FELIX-4009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678057#comment-13678057 ] Stuart McCulloch commented on FELIX-4009: - Note that the m2eclipse-tycho repository has moved to https://github.com/tesla/m2eclipse-tycho > maven bundle plugin should be integrated directly with eclipse > -- > > Key: FELIX-4009 > URL: https://issues.apache.org/jira/browse/FELIX-4009 > Project: Felix > Issue Type: New Feature > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.7 >Reporter: Andrei Pozolotin > Labels: m2e > Fix For: maven-bundle-plugin-patches-welcome > > > Stuart: > 1) currently, to integrate maven-bundle-plugin into m2e, one must use tycho > configurator > https://github.com/sonatype/m2eclipse-tycho > which adds needles complexity, and makes few strange assumptions > https://github.com/sonatype/m2eclipse-tycho/blob/master/org.sonatype.tycho.m2e/src/org/sonatype/tycho/m2e/internal/OsgiBundleProjectConfigurator.java#L74 > which no one it seems is there to care to correct > https://github.com/sonatype/m2eclipse-tycho/pull/8 > 2) instead, I suggest maven-bundle-plugin to provide direct integration with > eclipse via > http://wiki.eclipse.org/M2E_compatible_maven_plugins#BuildContext > which I would expect to be more customizable / flexible for the end user. > I recently made similar switch with my DS plugin, and life got easier :-) > https://github.com/carrot-garden/carrot-maven/tree/master/carrot-maven-scr-plugin > thanks. > Andrei. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-4112) Add meta annotations for handler description
Guillaume Sauthier created FELIX-4112: - Summary: Add meta annotations for handler description Key: FELIX-4112 URL: https://issues.apache.org/jira/browse/FELIX-4112 Project: Felix Issue Type: Improvement Components: iPOJO Affects Versions: ipojo-manipulator-1.10.0 Reporter: Guillaume Sauthier Assignee: Guillaume Sauthier I want to provide a way to decorate annotation in order to express that they are bound to a handler. This will be cleaner than relying on a naming convention (package name containing 'ipojo' or 'handler'). Along with this change, we can introduce a flag in our manipulator frontends to deactivate custom annotation processing (that's probably better than an @Ignore annotation) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3877) Transitive optional dependencies add non-optional Import-Packages
[ https://issues.apache.org/jira/browse/FELIX-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-3877: Fix Version/s: maven-bundle-plugin-patches-welcome > Transitive optional dependencies add non-optional Import-Packages > - > > Key: FELIX-3877 > URL: https://issues.apache.org/jira/browse/FELIX-3877 > Project: Felix > Issue Type: Bug > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.7 >Reporter: Xavier Courangon > Fix For: maven-bundle-plugin-patches-welcome > > > When a Maven dependency is marked optional, the imported packages are > optional also as expected. > But it this is not true for transitive dependencies of embedded dependencies > the imported packages are not optional. The Bundle cannot start. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3142) Add option to ignore any other manifest files when calculating manifest
[
https://issues.apache.org/jira/browse/FELIX-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stuart McCulloch updated FELIX-3142:
Fix Version/s: maven-bundle-plugin-patches-welcome
> Add option to ignore any other manifest files when calculating manifest
> ---
>
> Key: FELIX-3142
> URL: https://issues.apache.org/jira/browse/FELIX-3142
> Project: Felix
> Issue Type: Improvement
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.3.5
>Reporter: Matthew T. Adams
> Labels: manifest
> Fix For: maven-bundle-plugin-patches-welcome
>
>
> If ${project.build.outputDirectory} includes a resource META-INF/MANIFEST.MF,
> maven-bundle-plugin uses it, and there is no way to override that behavior.
> I would like to be able to tell the maven-bundle-plugin to ignore an existing
> META-INF/MANIFEST.MF or, more generally, any set of manifest resources/files
> via a
> ...
> I don't know if this would also require a change to the underlying bnd tool
> or not, but it seems like it would, because I don't see this feature there,
> either. I defer to the experts to determine whether bnd needs such an
> associated enhancement.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-1981) The OBR URI is wrong for artifacts using classifier
[ https://issues.apache.org/jira/browse/FELIX-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-1981: Fix Version/s: maven-bundle-plugin-patches-welcome > The OBR URI is wrong for artifacts using classifier > --- > > Key: FELIX-1981 > URL: https://issues.apache.org/jira/browse/FELIX-1981 > Project: Felix > Issue Type: Bug > Components: Maven Bundle Plugin >Reporter: Clement Escoffier > Fix For: maven-bundle-plugin-patches-welcome > > > The maven-bundle-plugin generates an URL for the bundle without classifier. > In fact the classifier is ignored. > This opens a second issue, if the project defines several artifacts (with > classifier) how this case has to be described in the OBR file. > First the id has to be unique (so the classifier should be used), but the > bundle name / symbolic name should also be different. Moreover, the > classifier may be described as a property of the bundle capacity. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-4009) maven bundle plugin should be integrated directly with eclipse
[ https://issues.apache.org/jira/browse/FELIX-4009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-4009: Fix Version/s: maven-bundle-plugin-patches-welcome > maven bundle plugin should be integrated directly with eclipse > -- > > Key: FELIX-4009 > URL: https://issues.apache.org/jira/browse/FELIX-4009 > Project: Felix > Issue Type: New Feature > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.7 >Reporter: Andrei Pozolotin > Labels: m2e > Fix For: maven-bundle-plugin-patches-welcome > > > Stuart: > 1) currently, to integrate maven-bundle-plugin into m2e, one must use tycho > configurator > https://github.com/sonatype/m2eclipse-tycho > which adds needles complexity, and makes few strange assumptions > https://github.com/sonatype/m2eclipse-tycho/blob/master/org.sonatype.tycho.m2e/src/org/sonatype/tycho/m2e/internal/OsgiBundleProjectConfigurator.java#L74 > which no one it seems is there to care to correct > https://github.com/sonatype/m2eclipse-tycho/pull/8 > 2) instead, I suggest maven-bundle-plugin to provide direct integration with > eclipse via > http://wiki.eclipse.org/M2E_compatible_maven_plugins#BuildContext > which I would expect to be more customizable / flexible for the end user. > I recently made similar switch with my DS plugin, and life got easier :-) > https://github.com/carrot-garden/carrot-maven/tree/master/carrot-maven-scr-plugin > thanks. > Andrei. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3018) Allow updation of an artifact's manifest at the final stage
[ https://issues.apache.org/jira/browse/FELIX-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-3018: Fix Version/s: maven-bundle-plugin-patches-welcome > Allow updation of an artifact's manifest at the final stage > --- > > Key: FELIX-3018 > URL: https://issues.apache.org/jira/browse/FELIX-3018 > Project: Felix > Issue Type: New Feature > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.4 >Reporter: Sahoo > Fix For: maven-bundle-plugin-patches-welcome > > > Please take a look at the discussion in FELIX-1571 that triggered this RFE to > be filed. > There are at least two predominant approaches to generating OSGi bundles > using maven-bundle-plugin: > a) Use packaging type like war, jar, ejb, etc., configure bundle plugin's > manifest goal to be run in an appropriate phase like process-classes and > configure the maven-archiver to use bundle plugin generated MANIFEST.MF in > the final artifact. > b) Use packaging type bundle so that bundle plugin is responsible for making > the final jar as well. > Each have their pros and cons. Contrary to approach #b, which is an > OSGi-first approach, approach #a is where OSGi metadata generation is an > additional step in the build process. User sets up the their project > following maven conventions as per their packaging type and then they > additionally configure bundle plugin to help them generate a valid OSGi > bundle. It is but natural that many enterprise Java developers who are used > to developing wars, ejb jars, etc. prefer approach #a. > With all the recent fixes to maven-bundle-plugin, things have improved quite > a lot. Approach #a is an optimal way to generate proper OSGi bundle except > when there are dependencies embedded in the final jar. e.g., user may like to > embed some jars in their WEB-INF/lib of the WAB. In such a case, maven > archiver knows what all jars to be embedded; after all it is making the final > war file. Yet, one has to repeat some of this in Embed-Dependency instruction > of bundle plugin in order for bundle plugin to generate proper > Bundle-ClassPath and Import-Package header. If Embed-Dependency has extra > jars, then unnecessary Import-Package and Bundle-ClassPath will appear in the > OSGi metadata. If Embed-Dependency has less jars, then the reverse will > happen. I agree to the following comment made by Stuart in FELIX-1571: > "I think the proper solution may be to create a new feature that lets you > update the manifest in the generated project artifact. That way you have the > WAR artifact available, so bnd can produce the right manifest (and verify it) > - although one outstanding issue is this might affect signing... " > I don't know if there is someway to intercept maven-archiver processing, then > bundle plugin could generate the manifest as the penultimate step in the > packaging process. Anyway, I am sure with all the maven experts around, > someone will suggest a way to do this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-4067) Old BND used causes problems during annotations processing
[
https://issues.apache.org/jira/browse/FELIX-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stuart McCulloch resolved FELIX-4067.
-
Resolution: Fixed
Fixed in the latest 2.4.0-SNAPSHOT available from
https://repository.apache.org/content/groups/snapshots/org/apache/felix/maven-bundle-plugin/2.4.0-SNAPSHOT/
> Old BND used causes problems during annotations processing
> --
>
> Key: FELIX-4067
> URL: https://issues.apache.org/jira/browse/FELIX-4067
> Project: Felix
> Issue Type: Wish
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.3.7
>Reporter: Stepan Hrbacek
>Priority: Critical
> Fix For: maven-bundle-plugin-2.4.0
>
>
> I use following plugin configuration in Maven to create OSGi bundle that
> makes a use of annotations:
>
>
>
> org.apache.felix
> maven-bundle-plugin
>
>
>
> ${project.artifactId}
>
> net.atos.dirx.access.sample.osgi.datasource.caller.module.ModuleController
>
>
> net.atos.dirx.access.sample.osgi.datasource.caller.module,
>
> net.atos.dirx.access.sample.osgi.datasource.caller.service
>
>
> <_dsannotations>*
>
>
>
>
>
> When running mvn package, I get following error:
> [ERROR] Bundle
> net.atos.dirx.access.sample.osgi.datasource.caller:dirx.access.sample.osgi.datasource.caller:bundle:0.0.1-SNAPSHOT
> : Activate method for
> net.atos.dirx.access.sample.osgi.datasource.caller.module.BundleIdentifierSourceFactory
> does not have an acceptable prototype, only Map, ComponentContext, or
> BundleContext is allowed. Found: ()Ljava/lang/String;
> The issue is in BND 1.50.0 that is used by the maven-bundle-plugin. When
> running BND 2.0.0 from command line, there is no issue.
> When is it please expected a release of new maven-bundle-plugin that uses BND
> 2.0.0? Is there a workaround for this issue in the current version 2.3.7?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-4067) Old BND used causes problems during annotations processing
[
https://issues.apache.org/jira/browse/FELIX-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stuart McCulloch updated FELIX-4067:
Fix Version/s: maven-bundle-plugin-2.4.0
> Old BND used causes problems during annotations processing
> --
>
> Key: FELIX-4067
> URL: https://issues.apache.org/jira/browse/FELIX-4067
> Project: Felix
> Issue Type: Wish
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.3.7
>Reporter: Stepan Hrbacek
>Priority: Critical
> Fix For: maven-bundle-plugin-2.4.0
>
>
> I use following plugin configuration in Maven to create OSGi bundle that
> makes a use of annotations:
>
>
>
> org.apache.felix
> maven-bundle-plugin
>
>
>
> ${project.artifactId}
>
> net.atos.dirx.access.sample.osgi.datasource.caller.module.ModuleController
>
>
> net.atos.dirx.access.sample.osgi.datasource.caller.module,
>
> net.atos.dirx.access.sample.osgi.datasource.caller.service
>
>
> <_dsannotations>*
>
>
>
>
>
> When running mvn package, I get following error:
> [ERROR] Bundle
> net.atos.dirx.access.sample.osgi.datasource.caller:dirx.access.sample.osgi.datasource.caller:bundle:0.0.1-SNAPSHOT
> : Activate method for
> net.atos.dirx.access.sample.osgi.datasource.caller.module.BundleIdentifierSourceFactory
> does not have an acceptable prototype, only Map, ComponentContext, or
> BundleContext is allowed. Found: ()Ljava/lang/String;
> The issue is in BND 1.50.0 that is used by the maven-bundle-plugin. When
> running BND 2.0.0 from command line, there is no issue.
> When is it please expected a release of new maven-bundle-plugin that uses BND
> 2.0.0? Is there a workaround for this issue in the current version 2.3.7?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-4066) Unable to load blueprint augmented jars with OBR
[ https://issues.apache.org/jira/browse/FELIX-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678051#comment-13678051 ] Stuart McCulloch commented on FELIX-4066: - Note that blueprint XML is processed into bnd instructions by src/main/resources/org/apache/felix/bundleplugin/blueprint.xsl - there's already some transformations there for the multiple interface case, but it seems to only pick the first child node. If you (or anyone watching) can provide a patch that fixes the multiple case then I'm happy to merge it in. > Unable to load blueprint augmented jars with OBR > > > Key: FELIX-4066 > URL: https://issues.apache.org/jira/browse/FELIX-4066 > Project: Felix > Issue Type: Bug > Components: Bundle Repository (OBR), Manifest Generator (mangen), > Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.7 >Reporter: Andrew Schurman > Fix For: maven-bundle-plugin-patches-welcome > > Attachments: example.tar.gz > > > There appear to be 2 somewhat related issues regarding consuming blueprint > augmented bundles in OBR. Both stem from the generated manifest: > 1) when exporting a service bean with 2 or more interfaces, only the first is > exposed in the manifest > 2) when importing a service via interface and component-name, you never find > the service as the component-name is never exposed on the exporting side -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-4066) Unable to load blueprint augmented jars with OBR
[ https://issues.apache.org/jira/browse/FELIX-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-4066: Fix Version/s: maven-bundle-plugin-patches-welcome > Unable to load blueprint augmented jars with OBR > > > Key: FELIX-4066 > URL: https://issues.apache.org/jira/browse/FELIX-4066 > Project: Felix > Issue Type: Bug > Components: Bundle Repository (OBR), Manifest Generator (mangen), > Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.7 >Reporter: Andrew Schurman > Fix For: maven-bundle-plugin-patches-welcome > > Attachments: example.tar.gz > > > There appear to be 2 somewhat related issues regarding consuming blueprint > augmented bundles in OBR. Both stem from the generated manifest: > 1) when exporting a service bean with 2 or more interfaces, only the first is > exposed in the manifest > 2) when importing a service via interface and component-name, you never find > the service as the component-name is never exposed on the exporting side -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FELIX-4107) Allow to specify import version range only for the case the package is needed
[ https://issues.apache.org/jira/browse/FELIX-4107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch closed FELIX-4107. --- Resolution: Not A Problem BTW, the current options when specifying package imports are: 1. Wildcard, such as the default * - can also use ? to match a single character rather than * (multiple) 2. Explicit without a wildcard - no expansion, always added 3. Bnd macro $(...) - see http://www.aqute.biz/Bnd/Macros, very powerful but can be tricky to get right You can also use negation to select all subpackages except for certain ones, for example: com.foo.*, !com.foo.internal.* If you have a example that cannot be solved by one of the above options please raise it on the users list or attach the example project to an issue on JIRA. > Allow to specify import version range only for the case the package is needed > - > > Key: FELIX-4107 > URL: https://issues.apache.org/jira/browse/FELIX-4107 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Reporter: Reto Bachmann-Gmür > > As StuartMcCulloch has shown in > http://mail-archives.apache.org/mod_mbox/felix-users/201304.mbox/%3c70a7020d-cef0-4e3d-811b-4cdc88ed4...@gmail.com%3E > is is possible to specify the impor range in a parent without causing > unneded imports if this is spcified with a wildcard. While in many cases this > can be used in some cases this is not possible as using a wildcard would > broaden the matching packages too much. > A possible solution could look like: if the package name is specified betwen > square brackets then it is only added to the final manifest if it is actually > needed by the bundle (i.e. would be part of the auto-generated imports). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3930) New Interceptor model for handlers
[ https://issues.apache.org/jira/browse/FELIX-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678029#comment-13678029 ] Pierre Bourret commented on FELIX-3930: --- Here is a proposal for a new interception model : https://github.com/bourretp/felix/tree/feature/interception-api It is based on the Interceptor pattern customized for POJOs. Constructors & method invocations + field access can be intercepted, arguments/return value can be injected/changed/removed. For methods, the real method invocation can be completely skipped (e.g. a cache-handler) For constructors, the choice of the correct constructor to call depends on the actual type of the injected arguments. An error is raised if no suitable constructor can be found. A warning occurs if there is an ambiguity (and the "first" one is chosen) For fields, nothing special, except that the injected values are _really_ put in the POJO fields... Really nice for debugging. All injected references are cleared when the component is stopped, to avoid keeping stale references of services and blocking bundle GC. Documentation is _ongoing_, and implementation is still open to fixes/enhancement. One _big_ blot : this proposition, especially changes in the manipulator, break compatibility with iPOJO components built with previous versions of the manipulator. Keeping this compatibility seems really complicated (at east). So this feature cannot be integrated in the mainline now, and must wait for iPOJO version 2.0.0. > New Interceptor model for handlers > -- > > Key: FELIX-3930 > URL: https://issues.apache.org/jira/browse/FELIX-3930 > Project: Felix > Issue Type: Improvement > Components: iPOJO >Reporter: Clement Escoffier >Assignee: Clement Escoffier > > Define and implement a new interceptor model. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-2322) Configurable JAR compression level
[ https://issues.apache.org/jira/browse/FELIX-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-2322: Fix Version/s: maven-bundle-plugin-patches-welcome > Configurable JAR compression level > -- > > Key: FELIX-2322 > URL: https://issues.apache.org/jira/browse/FELIX-2322 > Project: Felix > Issue Type: New Feature > Components: Maven Bundle Plugin >Reporter: Trustin Lee > Fix For: maven-bundle-plugin-patches-welcome > > > It seems like there is no way to specify the compression level of the bundle > JAR file generated by maven-bundle-plugin. To reduce the bandwidth, I'd like > to compress the JAR as much as possible. It would be nice if there is a > configurable property in the plugin's section in the pom.xml. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-2919) Aggregate sources when aggregate binaries
[ https://issues.apache.org/jira/browse/FELIX-2919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-2919: Fix Version/s: maven-bundle-plugin-future > Aggregate sources when aggregate binaries > - > > Key: FELIX-2919 > URL: https://issues.apache.org/jira/browse/FELIX-2919 > Project: Felix > Issue Type: New Feature > Components: Maven Bundle Plugin >Reporter: Stephane Chomat > Fix For: maven-bundle-plugin-future > > Original Estimate: 720h > Remaining Estimate: 720h > > maven bundle plugin allows to aggregate binaries but it doesn't aggregate > source when it's possible. > Add this action on goal source:jar and a configuration to activate this > feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-1837) Specify custom capabilities etc. in POM
[ https://issues.apache.org/jira/browse/FELIX-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-1837: Fix Version/s: maven-bundle-plugin-future > Specify custom capabilities etc. in POM > --- > > Key: FELIX-1837 > URL: https://issues.apache.org/jira/browse/FELIX-1837 > Project: Felix > Issue Type: New Feature > Components: Maven Bundle Plugin >Reporter: Henrik Niehaus >Priority: Minor > Fix For: maven-bundle-plugin-future > > > It would be nice, if custom capabilities etc. could be specified in the POM > instead of the obr.xml, so that project inheritance and other maven features > can be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-760) Version range in Fragment-Host declaration
[ https://issues.apache.org/jira/browse/FELIX-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-760: --- Fix Version/s: maven-bundle-plugin-future > Version range in Fragment-Host declaration > -- > > Key: FELIX-760 > URL: https://issues.apache.org/jira/browse/FELIX-760 > Project: Felix > Issue Type: Bug > Components: Bundle Repository (OBR), Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-1.4.3, bundlerepository-1.2.0 > Environment: Maven Bundle Plugin 1.4.3 > Apache Felix Bundle Repository 1.2.0 > Apache Felix 1.2.1/Eclipse Equinox 3.4.0 >Reporter: Dirk Mahler > Fix For: maven-bundle-plugin-future > > > The catalina coyote bundle in the SpringSource.com bundle repository > (http://www.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.coyote&version=6.0.16) > specifies a Fragment-Host using a version range (which IMHO is correct): > Fragment-Host: com.springsource.org.apache.catalina;version="[6.0.16, 6.0.16]" > The Maven Bundle Plugin creates an entry in the OBR repository metadata which > contains a capability with a version "[6.0.16, 6.0.16]": > > > > > This cannot be read by the bundle repository plugin resulting in the > following exception: > java.lang.NumberFormatException: For input string: "[6" > at > java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) > at java.lang.Integer.parseInt(Integer.java:447) > at java.lang.Integer.parseInt(Integer.java:497) > at org.osgi.framework.Version.(Version.java:128) > at > org.apache.felix.bundlerepository.PropertyImpl.convertType(PropertyImpl.java:85) > at > org.apache.felix.bundlerepository.PropertyImpl.setT(PropertyImpl.java:62) > at sun.reflect.GeneratedMethodAccessor43.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.felix.bundlerepository.metadataparser.XmlCommonHandler.startElement(XmlCommonHandler.java:490) > at > org.apache.felix.bundlerepository.metadataparser.kxmlsax.KXml2SAXParser.parseXML(KXml2SAXParser.java:67) > ... > PS: is the declaration of a Fragment-Host really a capability? I think it > should be requirement... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-2920) Check a list of bundles to see if all bundles can be resolved when its will deploy on osgi framework.
[ https://issues.apache.org/jira/browse/FELIX-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-2920: Fix Version/s: maven-bundle-plugin-future > Check a list of bundles to see if all bundles can be resolved when its will > deploy on osgi framework. > - > > Key: FELIX-2920 > URL: https://issues.apache.org/jira/browse/FELIX-2920 > Project: Felix > Issue Type: New Feature > Components: Maven Bundle Plugin >Reporter: Stephane Chomat > Fix For: maven-bundle-plugin-future > > Original Estimate: 720h > Remaining Estimate: 720h > > It's helpfull to add another goal checkConfig to check a configurations of > bundles with the bundle 0 to see if all bundles can be resovled and reports > some warning or errors like a package exported by two bundles, a package > exported by a bundle less version and by another with a version > It's a test to see if these bundles can be started on a osgi configuration. > You can use felix implemention to do it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-1654) BND should WARN when the Bundle-Activator is not present in the current bundle
[ https://issues.apache.org/jira/browse/FELIX-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-1654: Fix Version/s: maven-bundle-plugin-future > BND should WARN when the Bundle-Activator is not present in the current bundle > -- > > Key: FELIX-1654 > URL: https://issues.apache.org/jira/browse/FELIX-1654 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Reporter: Niclas Hedhman > Fix For: maven-bundle-plugin-future > > > Currently, if a declared Bundle-Activator is not present, BND will add an > Import-Package statement for such activator. > I think it would be better that it at least create a warning that the > activator doesn't exist in the current bundle, or even generate an error so > that the developer is forced to include the package import explicitly (but I > understand that this might be too strong for people's taste.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-1119) Jar plugin configuration is ignored by the maven-bundle-plugin
[ https://issues.apache.org/jira/browse/FELIX-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-1119: Fix Version/s: maven-bundle-plugin-future > Jar plugin configuration is ignored by the maven-bundle-plugin > - > > Key: FELIX-1119 > URL: https://issues.apache.org/jira/browse/FELIX-1119 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.0.0 >Reporter: Sylvain MARIE > Fix For: maven-bundle-plugin-future > > > Hi all, > This issue relates to FELIX-806 (fixed). It is still about configuration of > the plugin. > In a particular project we need to generate ressources (therefore they end-up > being in target/classes) but we need to exclude them. With the jar plugin > there is an option to do that, the , see > http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html#excludes. > However this option is not used by the maven bundle plugin, could it be > supported ? (and more generally everything that is in the jar and archive > configuration) > Thanks for the 2.0.0 by the way :) > Best regards > Sylvain -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-1633) Change -snapshot by the build number in the generated OBR description
[ https://issues.apache.org/jira/browse/FELIX-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated FELIX-1633: Fix Version/s: maven-bundle-plugin-future > Change -snapshot by the build number in the generated OBR description > - > > Key: FELIX-1633 > URL: https://issues.apache.org/jira/browse/FELIX-1633 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Reporter: Clement Escoffier > Fix For: maven-bundle-plugin-future > > > When deploying a snapshot bundle on OBR, the generated version is the > artifact version such as: 0.7.0-SNAPSHOT. However, if we redeploy another > version without increasing the version to 0.7.1-SNAPSHOT, the OBR keeps the > same version. So, it is not possible to update the bundle has it's the same > version. > This improvement propose to replace -SNAPSHOT in the generated version by the > build number (contained in the deployed maven metadata). It will give > something like: 0.7.0-01. The next deployment will be something like: > 0.7.0-02. We can't directly use the time stamp as we need to be compliant > with the OSGi versionning scheme and order. > The resource id can still use SNAPSHOT (so, next deployment with replace the > previous description) or can be also replaced. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FELIX-4111) TypeDeclarations for handlers do not expose namespace (explicitly)
[
https://issues.apache.org/jira/browse/FELIX-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Sauthier reassigned FELIX-4111:
-
Assignee: Guillaume Sauthier
> TypeDeclarations for handlers do not expose namespace (explicitly)
> --
>
> Key: FELIX-4111
> URL: https://issues.apache.org/jira/browse/FELIX-4111
> Project: Felix
> Issue Type: Bug
> Components: iPOJO
>Affects Versions: ipojo-runtime-1.10
> Environment: N/A
>Reporter: Pierre Bourret
>Assignee: Guillaume Sauthier
>Priority: Minor
> Attachments:
> FELIX-4111_possible_fix__TypeDeclarations_for_handlers_do_not_expose_namespace_explicitly.patch
>
>
> The TypeDeclaration services allows to retrieve the component types that have
> been declared, and their current status (bound/unbound , reason, ...)
> However, there is something missing about iPOJO handlers : their
> TypeDeclaration services do not allow to retrieve their namespaces. For
> example, the dependency handler TypeDeclaration.getComponentName() method
> returns "requires".
> It would be very appreciable to retrieve the namespace information via the
> getComponentName() method (or getComponentNameSpace() ?).
> One possible workaround it to retrieve the namespace from the component
> metadata :
> String ns =
> typeDeclaration().getComponentMetadata().getAttribute("namespace");
> It is not very elegant since it relies on iPOJO internals (the metadata
> structure) and it returns null for iPOJO core handlers (instead of the
> "org.apache.felix.ipojo" namespace)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-4111) TypeDeclarations for handlers do not expose namespace (explicitly)
[
https://issues.apache.org/jira/browse/FELIX-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13677988#comment-13677988
]
Guillaume Sauthier commented on FELIX-4111:
---
Thanks for the path, I'll review it soon
As a side note, the TypeDeclaration.getExtension() method suffer the same
problem (simple name returned in place of the fully qualified name)
> TypeDeclarations for handlers do not expose namespace (explicitly)
> --
>
> Key: FELIX-4111
> URL: https://issues.apache.org/jira/browse/FELIX-4111
> Project: Felix
> Issue Type: Bug
> Components: iPOJO
>Affects Versions: ipojo-runtime-1.10
> Environment: N/A
>Reporter: Pierre Bourret
>Priority: Minor
> Attachments:
> FELIX-4111_possible_fix__TypeDeclarations_for_handlers_do_not_expose_namespace_explicitly.patch
>
>
> The TypeDeclaration services allows to retrieve the component types that have
> been declared, and their current status (bound/unbound , reason, ...)
> However, there is something missing about iPOJO handlers : their
> TypeDeclaration services do not allow to retrieve their namespaces. For
> example, the dependency handler TypeDeclaration.getComponentName() method
> returns "requires".
> It would be very appreciable to retrieve the namespace information via the
> getComponentName() method (or getComponentNameSpace() ?).
> One possible workaround it to retrieve the namespace from the component
> metadata :
> String ns =
> typeDeclaration().getComponentMetadata().getAttribute("namespace");
> It is not very elegant since it relies on iPOJO internals (the metadata
> structure) and it returns null for iPOJO core handlers (instead of the
> "org.apache.felix.ipojo" namespace)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-4111) TypeDeclarations for handlers do not expose namespace (explicitly)
[
https://issues.apache.org/jira/browse/FELIX-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Bourret updated FELIX-4111:
--
Attachment:
FELIX-4111_possible_fix__TypeDeclarations_for_handlers_do_not_expose_namespace_explicitly.patch
Here is a possible fix for this issue.
I've added a method getComponentNameSpace() that returns the namespace
(retrieved from metadata).
If the targeted iPOJO extension is "handler" and the component metadata doesn't
define the "namespace" attribute, the method returns the implicit namespace
(for core handlers) : "org.apache.felix.ipojo"
> TypeDeclarations for handlers do not expose namespace (explicitly)
> --
>
> Key: FELIX-4111
> URL: https://issues.apache.org/jira/browse/FELIX-4111
> Project: Felix
> Issue Type: Bug
> Components: iPOJO
>Affects Versions: ipojo-runtime-1.10
> Environment: N/A
>Reporter: Pierre Bourret
>Priority: Minor
> Attachments:
> FELIX-4111_possible_fix__TypeDeclarations_for_handlers_do_not_expose_namespace_explicitly.patch
>
>
> The TypeDeclaration services allows to retrieve the component types that have
> been declared, and their current status (bound/unbound , reason, ...)
> However, there is something missing about iPOJO handlers : their
> TypeDeclaration services do not allow to retrieve their namespaces. For
> example, the dependency handler TypeDeclaration.getComponentName() method
> returns "requires".
> It would be very appreciable to retrieve the namespace information via the
> getComponentName() method (or getComponentNameSpace() ?).
> One possible workaround it to retrieve the namespace from the component
> metadata :
> String ns =
> typeDeclaration().getComponentMetadata().getAttribute("namespace");
> It is not very elegant since it relies on iPOJO internals (the metadata
> structure) and it returns null for iPOJO core handlers (instead of the
> "org.apache.felix.ipojo" namespace)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FELIX-4110) @ServiceProperty and @StaticServiceProperty are missing the immutable attribute
[ https://issues.apache.org/jira/browse/FELIX-4110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Sauthier closed FELIX-4110. - Resolution: Fixed Fix Version/s: ipojo-manipulator-1.10.1 Fixed in trunk > @ServiceProperty and @StaticServiceProperty are missing the immutable > attribute > --- > > Key: FELIX-4110 > URL: https://issues.apache.org/jira/browse/FELIX-4110 > Project: Felix > Issue Type: Bug > Components: iPOJO >Reporter: Guillaume Sauthier >Assignee: Guillaume Sauthier > Fix For: ipojo-manipulator-1.10.1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FELIX-4109) ComponentTypeDescription.addProperty() ignore immutable parameter
[ https://issues.apache.org/jira/browse/FELIX-4109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Sauthier closed FELIX-4109. - Resolution: Fixed Fix Version/s: ipojo-runtime-1.10.1 Fixed in trunk > ComponentTypeDescription.addProperty() ignore immutable parameter > - > > Key: FELIX-4109 > URL: https://issues.apache.org/jira/browse/FELIX-4109 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-runtime-1.10 >Reporter: Guillaume Sauthier >Assignee: Guillaume Sauthier > Fix For: ipojo-runtime-1.10.1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-4108) Deadlock in the new extender
[ https://issues.apache.org/jira/browse/FELIX-4108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Sauthier resolved FELIX-4108. --- Resolution: Fixed I just pushed some changes I hope that it will fix your issue > Deadlock in the new extender > > > Key: FELIX-4108 > URL: https://issues.apache.org/jira/browse/FELIX-4108 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-runtime-1.10 >Reporter: Clement Escoffier >Assignee: Guillaume Sauthier > Fix For: ipojo-runtime-1.10.1 > > > Here is the deadlock trace: > State: BLOCKED on org.apache.felix.ipojo.InstanceManager@31f94 owned by: > FelixStartLevel > Total blocked: 2 Total waited: 1 > Stack trace: > org.apache.felix.ipojo.InstanceManager.getState(InstanceManager.java:585) > org.apache.felix.ipojo.IPojoFactory.stop(IPojoFactory.java:568) >- locked org.apache.felix.ipojo.ComponentFactory@59a6b5 > org.apache.felix.ipojo.IPojoFactory.dispose(IPojoFactory.java:591) >- locked org.apache.felix.ipojo.ComponentFactory@59a6b5 > org.apache.felix.ipojo.extender.internal.linker.ManagedType.stop(ManagedType.java:167) > org.apache.felix.ipojo.extender.internal.linker.DeclarationLinker.removedService(DeclarationLinker.java:107) > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956) > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864) > org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:902) > org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932) > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) > org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) > org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4419) > org.apache.felix.framework.Felix.access$000(Felix.java:74) > org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:401) > org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151) > org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127) > org.apache.felix.framework.ServiceRegistry.unregisterServices(ServiceRegistry.java:196) > org.apache.felix.framework.Felix.stopBundle(Felix.java:2555) > org.apache.felix.framework.BundleImpl.stop(BundleImpl.java:991) > org.apache.felix.fileinstall.internal.DirectoryWatcher.stopTransient(DirectoryWatcher.java:1103) > org.apache.felix.fileinstall.internal.DirectoryWatcher.installOrUpdateBundle(DirectoryWatcher.java:954) > org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:877) > org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:790) > org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:428) > org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:245) > END OF FIRST TRACE > - > Name: FelixStartLevel > State: BLOCKED on org.apache.felix.ipojo.ComponentFactory@59a6b5 owned by: > fileinstall-/home/torito/workspace/iCasa/iCasaPlatform/tests/core-platform-tests/distributions-test/icasa-distribution-test/target/distribution/icasa.platform.distribution/load > Total blocked: 65 Total waited: 55 > Stack trace: > org.apache.felix.ipojo.IPojoFactory.disposed(IPojoFactory.java:724) > org.apache.felix.ipojo.InstanceManager.dispose(InstanceManager.java:497) >- locked org.apache.felix.ipojo.InstanceManager@31f94 > org.apache.felix.ipojo.extender.internal.linker.ManagedType$InstanceSupport.removedService(ManagedType.java:346) > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956) > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864) > org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:902) > org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932) > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) > org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) > org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4419) > org.apache.felix.framework.Felix.access$000(Felix.java:74) > org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:401) > org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151) > org.apache.felix.framework.Ser
[jira] [Created] (FELIX-4111) TypeDeclarations for handlers do not expose namespace (explicitly)
Pierre Bourret created FELIX-4111:
-
Summary: TypeDeclarations for handlers do not expose namespace
(explicitly)
Key: FELIX-4111
URL: https://issues.apache.org/jira/browse/FELIX-4111
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: ipojo-runtime-1.10
Environment: N/A
Reporter: Pierre Bourret
Priority: Minor
The TypeDeclaration services allows to retrieve the component types that have
been declared, and their current status (bound/unbound , reason, ...)
However, there is something missing about iPOJO handlers : their
TypeDeclaration services do not allow to retrieve their namespaces. For
example, the dependency handler TypeDeclaration.getComponentName() method
returns "requires".
It would be very appreciable to retrieve the namespace information via the
getComponentName() method (or getComponentNameSpace() ?).
One possible workaround it to retrieve the namespace from the component
metadata :
String ns = typeDeclaration().getComponentMetadata().getAttribute("namespace");
It is not very elegant since it relies on iPOJO internals (the metadata
structure) and it returns null for iPOJO core handlers (instead of the
"org.apache.felix.ipojo" namespace)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FELIX-4108) Deadlock in the new extender
[ https://issues.apache.org/jira/browse/FELIX-4108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Sauthier reassigned FELIX-4108: - Assignee: Guillaume Sauthier > Deadlock in the new extender > > > Key: FELIX-4108 > URL: https://issues.apache.org/jira/browse/FELIX-4108 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-runtime-1.10 >Reporter: Clement Escoffier >Assignee: Guillaume Sauthier > Fix For: ipojo-runtime-1.10.1 > > > Here is the deadlock trace: > State: BLOCKED on org.apache.felix.ipojo.InstanceManager@31f94 owned by: > FelixStartLevel > Total blocked: 2 Total waited: 1 > Stack trace: > org.apache.felix.ipojo.InstanceManager.getState(InstanceManager.java:585) > org.apache.felix.ipojo.IPojoFactory.stop(IPojoFactory.java:568) >- locked org.apache.felix.ipojo.ComponentFactory@59a6b5 > org.apache.felix.ipojo.IPojoFactory.dispose(IPojoFactory.java:591) >- locked org.apache.felix.ipojo.ComponentFactory@59a6b5 > org.apache.felix.ipojo.extender.internal.linker.ManagedType.stop(ManagedType.java:167) > org.apache.felix.ipojo.extender.internal.linker.DeclarationLinker.removedService(DeclarationLinker.java:107) > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956) > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864) > org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:902) > org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932) > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) > org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) > org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4419) > org.apache.felix.framework.Felix.access$000(Felix.java:74) > org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:401) > org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151) > org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127) > org.apache.felix.framework.ServiceRegistry.unregisterServices(ServiceRegistry.java:196) > org.apache.felix.framework.Felix.stopBundle(Felix.java:2555) > org.apache.felix.framework.BundleImpl.stop(BundleImpl.java:991) > org.apache.felix.fileinstall.internal.DirectoryWatcher.stopTransient(DirectoryWatcher.java:1103) > org.apache.felix.fileinstall.internal.DirectoryWatcher.installOrUpdateBundle(DirectoryWatcher.java:954) > org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:877) > org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:790) > org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:428) > org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:245) > END OF FIRST TRACE > - > Name: FelixStartLevel > State: BLOCKED on org.apache.felix.ipojo.ComponentFactory@59a6b5 owned by: > fileinstall-/home/torito/workspace/iCasa/iCasaPlatform/tests/core-platform-tests/distributions-test/icasa-distribution-test/target/distribution/icasa.platform.distribution/load > Total blocked: 65 Total waited: 55 > Stack trace: > org.apache.felix.ipojo.IPojoFactory.disposed(IPojoFactory.java:724) > org.apache.felix.ipojo.InstanceManager.dispose(InstanceManager.java:497) >- locked org.apache.felix.ipojo.InstanceManager@31f94 > org.apache.felix.ipojo.extender.internal.linker.ManagedType$InstanceSupport.removedService(ManagedType.java:346) > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956) > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864) > org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:902) > org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932) > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) > org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) > org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4419) > org.apache.felix.framework.Felix.access$000(Felix.java:74) > org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:401) > org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151) > org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java
[jira] [Created] (FELIX-4110) @ServiceProperty and @StaticServiceProperty are missing the immutable attribute
Guillaume Sauthier created FELIX-4110: - Summary: @ServiceProperty and @StaticServiceProperty are missing the immutable attribute Key: FELIX-4110 URL: https://issues.apache.org/jira/browse/FELIX-4110 Project: Felix Issue Type: Bug Components: iPOJO Reporter: Guillaume Sauthier Assignee: Guillaume Sauthier -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-4109) ComponentTypeDescription.addProperty() ignore immutable parameter
Guillaume Sauthier created FELIX-4109: - Summary: ComponentTypeDescription.addProperty() ignore immutable parameter Key: FELIX-4109 URL: https://issues.apache.org/jira/browse/FELIX-4109 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: ipojo-runtime-1.10 Reporter: Guillaume Sauthier Assignee: Guillaume Sauthier -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-4108) Deadlock in the new extender
[ https://issues.apache.org/jira/browse/FELIX-4108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13677929#comment-13677929 ] Guillaume Sauthier commented on FELIX-4108: --- So, on 1 thread, we have the iPOJO bundle that is stopping, so it deactivate all known bundles. On the other thread, we have fileInstall that decide to undeploy a bundle. Question, do you remove a bundle from the deploi directory of fileinstall during the shutdown sequence ? Or is this FI that, during it's stop process, perform an asynchronous uninstall ? > Deadlock in the new extender > > > Key: FELIX-4108 > URL: https://issues.apache.org/jira/browse/FELIX-4108 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-runtime-1.10 >Reporter: Clement Escoffier > Fix For: ipojo-runtime-1.10.1 > > > Here is the deadlock trace: > State: BLOCKED on org.apache.felix.ipojo.InstanceManager@31f94 owned by: > FelixStartLevel > Total blocked: 2 Total waited: 1 > Stack trace: > org.apache.felix.ipojo.InstanceManager.getState(InstanceManager.java:585) > org.apache.felix.ipojo.IPojoFactory.stop(IPojoFactory.java:568) >- locked org.apache.felix.ipojo.ComponentFactory@59a6b5 > org.apache.felix.ipojo.IPojoFactory.dispose(IPojoFactory.java:591) >- locked org.apache.felix.ipojo.ComponentFactory@59a6b5 > org.apache.felix.ipojo.extender.internal.linker.ManagedType.stop(ManagedType.java:167) > org.apache.felix.ipojo.extender.internal.linker.DeclarationLinker.removedService(DeclarationLinker.java:107) > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956) > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864) > org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:902) > org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932) > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) > org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) > org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4419) > org.apache.felix.framework.Felix.access$000(Felix.java:74) > org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:401) > org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151) > org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127) > org.apache.felix.framework.ServiceRegistry.unregisterServices(ServiceRegistry.java:196) > org.apache.felix.framework.Felix.stopBundle(Felix.java:2555) > org.apache.felix.framework.BundleImpl.stop(BundleImpl.java:991) > org.apache.felix.fileinstall.internal.DirectoryWatcher.stopTransient(DirectoryWatcher.java:1103) > org.apache.felix.fileinstall.internal.DirectoryWatcher.installOrUpdateBundle(DirectoryWatcher.java:954) > org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:877) > org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:790) > org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:428) > org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:245) > END OF FIRST TRACE > - > Name: FelixStartLevel > State: BLOCKED on org.apache.felix.ipojo.ComponentFactory@59a6b5 owned by: > fileinstall-/home/torito/workspace/iCasa/iCasaPlatform/tests/core-platform-tests/distributions-test/icasa-distribution-test/target/distribution/icasa.platform.distribution/load > Total blocked: 65 Total waited: 55 > Stack trace: > org.apache.felix.ipojo.IPojoFactory.disposed(IPojoFactory.java:724) > org.apache.felix.ipojo.InstanceManager.dispose(InstanceManager.java:497) >- locked org.apache.felix.ipojo.InstanceManager@31f94 > org.apache.felix.ipojo.extender.internal.linker.ManagedType$InstanceSupport.removedService(ManagedType.java:346) > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956) > org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864) > org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:902) > org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932) > org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) > org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) > org.apache.felix.framework.
[jira] [Created] (FELIX-4108) Deadlock in the new extender
Clement Escoffier created FELIX-4108: Summary: Deadlock in the new extender Key: FELIX-4108 URL: https://issues.apache.org/jira/browse/FELIX-4108 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: ipojo-runtime-1.10 Reporter: Clement Escoffier Fix For: ipojo-runtime-1.10.1 Here is the deadlock trace: State: BLOCKED on org.apache.felix.ipojo.InstanceManager@31f94 owned by: FelixStartLevel Total blocked: 2 Total waited: 1 Stack trace: org.apache.felix.ipojo.InstanceManager.getState(InstanceManager.java:585) org.apache.felix.ipojo.IPojoFactory.stop(IPojoFactory.java:568) - locked org.apache.felix.ipojo.ComponentFactory@59a6b5 org.apache.felix.ipojo.IPojoFactory.dispose(IPojoFactory.java:591) - locked org.apache.felix.ipojo.ComponentFactory@59a6b5 org.apache.felix.ipojo.extender.internal.linker.ManagedType.stop(ManagedType.java:167) org.apache.felix.ipojo.extender.internal.linker.DeclarationLinker.removedService(DeclarationLinker.java:107) org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956) org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864) org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:902) org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932) org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4419) org.apache.felix.framework.Felix.access$000(Felix.java:74) org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:401) org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151) org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127) org.apache.felix.framework.ServiceRegistry.unregisterServices(ServiceRegistry.java:196) org.apache.felix.framework.Felix.stopBundle(Felix.java:2555) org.apache.felix.framework.BundleImpl.stop(BundleImpl.java:991) org.apache.felix.fileinstall.internal.DirectoryWatcher.stopTransient(DirectoryWatcher.java:1103) org.apache.felix.fileinstall.internal.DirectoryWatcher.installOrUpdateBundle(DirectoryWatcher.java:954) org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:877) org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:790) org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:428) org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:245) END OF FIRST TRACE - Name: FelixStartLevel State: BLOCKED on org.apache.felix.ipojo.ComponentFactory@59a6b5 owned by: fileinstall-/home/torito/workspace/iCasa/iCasaPlatform/tests/core-platform-tests/distributions-test/icasa-distribution-test/target/distribution/icasa.platform.distribution/load Total blocked: 65 Total waited: 55 Stack trace: org.apache.felix.ipojo.IPojoFactory.disposed(IPojoFactory.java:724) org.apache.felix.ipojo.InstanceManager.dispose(InstanceManager.java:497) - locked org.apache.felix.ipojo.InstanceManager@31f94 org.apache.felix.ipojo.extender.internal.linker.ManagedType$InstanceSupport.removedService(ManagedType.java:346) org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956) org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:864) org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:902) org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932) org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4419) org.apache.felix.framework.Felix.access$000(Felix.java:74) org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:401) org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151) org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127) org.apache.felix.ipojo.extender.internal.AbstractService.stop(AbstractService.java:73) org.apache.felix.ipojo.extender.internal.processor.ComponentsBundleProcessor$ComponentsAndInstances.stop(ComponentsBundleProcessor.java:220) org.apache.felix.ipojo.extender.internal.processor.ComponentsBundleProcessor.deactivate(ComponentsBundleProces
[jira] [Commented] (FELIX-4005) Maven Bundle Plugin fails with ArrayIndexOutOfBoundsException, "Invalid Class File" errors with Java 8 features
[
https://issues.apache.org/jira/browse/FELIX-4005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13677904#comment-13677904
]
Julien Ponge commented on FELIX-4005:
-
The Golo project is also in need for a new release with a bnd tool that
correctly supports post-Java 7 bytecode.
https://github.com/golo-lang/golo-lang/pull/47
> Maven Bundle Plugin fails with ArrayIndexOutOfBoundsException, "Invalid Class
> File" errors with Java 8 features
> ---
>
> Key: FELIX-4005
> URL: https://issues.apache.org/jira/browse/FELIX-4005
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.3.7
>Reporter: Nick Williams
>Priority: Blocker
> Fix For: maven-bundle-plugin-2.4.0
>
> Attachments: pom.xml
>
>
> I have the POM file attached. Its parent is "com.fasterxml:oss-parent"
> version 8 (which can be found in central repository). The module I'm creating
> is a Mapping Jackson plugin that supports the Java 8 Date & Time API. It uses
> lambda expressions and method references as well. The Maven Bundle Plugin, it
> would seem, does not like this. I cannot build (which is kind of a big deal).
> The classes compile fine as you can see, so there isn't a problem with my
> Java code. Just the plugin.
> Here is the output from the build process:
> {code}
> [WARNING] Command line option -npr is deprecated and will be removed in
> future Maven versions.
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building Jackson-Datatype-JSR310 2.2.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.1.1:enforce (enforce-java) @
> jackson-datatype-jsr310 ---
> [INFO]
> [INFO] --- replacer:1.5.2:replace (process-packageVersion) @
> jackson-datatype-jsr310 ---
> [INFO] Replacement run on 1 file.
> [INFO]
> [INFO] --- build-helper-maven-plugin:1.7:add-source (add-generated-sources) @
> jackson-datatype-jsr310 ---
> [INFO] Source directory:
> C:\Users\Nicholas\Desktop\jackson-datatype-jsr310\target\generated-sources
> added.
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> jackson-datatype-jsr310 ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> C:\Users\Nicholas\Desktop\jackson-datatype-jsr310\src\main\resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.0:compile (default-compile) @
> jackson-datatype-jsr310 ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 21 source files to
> C:\Users\Nicholas\Desktop\jackson-datatype-jsr310\target\classes
> [INFO]
> [INFO] --- maven-bundle-plugin:2.3.7:manifest (bundle-manifest) @
> jackson-datatype-jsr310 ---
> java.lang.ArrayIndexOutOfBoundsException: 18
> at aQute.lib.osgi.Clazz.parseClassFile(Clazz.java:448)
> at aQute.lib.osgi.Clazz.parseClassFile(Clazz.java:369)
> at aQute.lib.osgi.Clazz.parseClassFileWithCollector(Clazz.java:359)
> at aQute.lib.osgi.Clazz.parseClassFile(Clazz.java:349)
> at aQute.lib.osgi.Analyzer.analyzeJar(Analyzer.java:1725)
> at aQute.lib.osgi.Analyzer.analyzeBundleClasspath(Analyzer.java:1595)
> at aQute.lib.osgi.Analyzer.analyze(Analyzer.java:124)
> at aQute.lib.osgi.Builder.analyze(Builder.java:306)
> at aQute.lib.osgi.Analyzer.calcManifest(Analyzer.java:301)
> at
> org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer(ManifestPlugin.java:206)
> at
> org.apache.felix.bundleplugin.ManifestPlugin.getManifest(ManifestPlugin.java:114)
> at
> org.apache.felix.bundleplugin.ManifestPlugin.execute(ManifestPlugin.java:69)
> at
> org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:264)
> at
> org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:255)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle
[jira] [Commented] (FELIX-4107) Allow to specify import version range only for the case the package is needed
[ https://issues.apache.org/jira/browse/FELIX-4107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13677878#comment-13677878 ] Reto Bachmann-Gmür commented on FELIX-4107: --- I just found out that foo.bar.* matches foo.bar so that I can specify the range on that and don't need to broaden it to foo.* as I thought. > Allow to specify import version range only for the case the package is needed > - > > Key: FELIX-4107 > URL: https://issues.apache.org/jira/browse/FELIX-4107 > Project: Felix > Issue Type: Improvement > Components: Maven Bundle Plugin >Reporter: Reto Bachmann-Gmür > > As StuartMcCulloch has shown in > http://mail-archives.apache.org/mod_mbox/felix-users/201304.mbox/%3c70a7020d-cef0-4e3d-811b-4cdc88ed4...@gmail.com%3E > is is possible to specify the impor range in a parent without causing > unneded imports if this is spcified with a wildcard. While in many cases this > can be used in some cases this is not possible as using a wildcard would > broaden the matching packages too much. > A possible solution could look like: if the package name is specified betwen > square brackets then it is only added to the final manifest if it is actually > needed by the bundle (i.e. would be part of the auto-generated imports). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-4107) Allow to specify import version range only for the case the package is needed
Reto Bachmann-Gmür created FELIX-4107: - Summary: Allow to specify import version range only for the case the package is needed Key: FELIX-4107 URL: https://issues.apache.org/jira/browse/FELIX-4107 Project: Felix Issue Type: Improvement Components: Maven Bundle Plugin Reporter: Reto Bachmann-Gmür As StuartMcCulloch has shown in http://mail-archives.apache.org/mod_mbox/felix-users/201304.mbox/%3c70a7020d-cef0-4e3d-811b-4cdc88ed4...@gmail.com%3E is is possible to specify the impor range in a parent without causing unneded imports if this is spcified with a wildcard. While in many cases this can be used in some cases this is not possible as using a wildcard would broaden the matching packages too much. A possible solution could look like: if the package name is specified betwen square brackets then it is only added to the final manifest if it is actually needed by the bundle (i.e. would be part of the auto-generated imports). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
