felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-4999) maven-scr-plugin messes project resources when outputDirectory configuration present on windows
Date Mon, 10 Aug 2015 07:52:45 GMT

    [ https://issues.apache.org/jira/browse/FELIX-4999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14679735#comment-14679735

Carsten Ziegeler commented on FELIX-4999:

[~philipp.kunz] Thanks for reporting, I'Ve committed in rev 1694981 a slightly different fix.
The idea of replacing the file separator char with "/" is basically to work with resource
definitions that use any path character, e.g. there might be a resource definition for dir
foo/bar in the pom, but the project is built on windows. I think I fixed all the places where
this should matter with the patch. Could you please try this out?

> maven-scr-plugin messes project resources when outputDirectory configuration present
on windows
> -----------------------------------------------------------------------------------------------
>                 Key: FELIX-4999
>                 URL: https://issues.apache.org/jira/browse/FELIX-4999
>             Project: Felix
>          Issue Type: Bug
>          Components: SCR Tooling
>    Affects Versions: maven-scr-plugin 1.21.0
>         Environment: Windows
>            Reporter: Philipp Kunz
>              Labels: easyfix, patch-available
>             Fix For: maven-scr-plugin 1.22.0
>         Attachments: FELIX-4999.patch
> As I look at the following code, I easily can conclude problems on Windows.
> {code:title=org.apache.felix.scrplugin.mojo.SCRDescriptorMojo#updateProjectResources()}
>     private boolean updateProjectResources() {
>         final String classesDir = this.project.getBuild().getOutputDirectory().replace(File.separatorChar,
>         final String ourRsrcPath = this.outputDirectory.getAbsolutePath().replace(File.separatorChar,
>         if ( !classesDir.equals(ourRsrcPath) ) {
>             // now add the descriptor directory to the maven resources
>             boolean found = false;
>             @SuppressWarnings("unchecked")
>             final Iterator<Resource> rsrcIterator = this.project.getResources().iterator();
>             while (!found && rsrcIterator.hasNext()) {
>                 final Resource rsrc = rsrcIterator.next();
>                 found = rsrc.getDirectory().equals(ourRsrcPath);
>             }
>             if (!found) {
>                 final Resource resource = new Resource();
>                 resource.setDirectory(this.outputDirectory.getAbsolutePath());
>                 this.project.addResource(resource);
>             }
>             return true;
>         }
>         return false;
>     }
> {code}
> The problematic snippet is *{{.replace(File.separatorChar, '/')}}*. On any other environment
that Windows this might work but it does not work with backslash file separators.
> At first *{{classesDir}}* is compared to *{{ourRsrcPath}}* which is correct as both values
have their slashes replaced. The second comparison on line [545|http://svn.apache.org/viewvc/felix/trunk/scrplugin/maven-scr-plugin/src/main/java/org/apache/felix/scrplugin/mojo/SCRDescriptorMojo.java?view=markup&revision=1616419],
however, is invalid because *{{rsrc.getDirectory()}}* contains native file separators when
compared to *{{ourRsrcPath}}* with replaced file separators.
> As a consequence, the outputDirecory becomes (is added as a) maven project resource and
everything inside it if previously existing is copied into the target directory. In my case
I specified the project root directory as outputDirectory so that Eclipse PDE finds the OSGI-INF
folder in the place expected and added the root folder with an inclusion pattern of OSGI-INF/**
to the project resources. The issue caused the whole project to get copied into the target/classes
folder resulting in something like target/classes/target/classes, which maven-bundle-plugin
is then complaining with an error because:
> {code}
> [ERROR] ... : Classes found in the wrong directory: {target/classes/target/clases/...=...}
> {code}

This message was sent by Atlassian JIRA

View raw message