[
https://issues.apache.org/jira/browse/FELIX-4999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14680709#comment-14680709
]
Philipp Kunz commented on FELIX-4999:
-------------------------------------
[~cziegeler], have you ever thought about the case the outputDirectory of the
maven-scr-plugin an existing directory which is not empty and at the same time
not defined as a maven resource directory when scr is executed such as basedir
in my case? Might happen rarely but would then be even more confusing. I have
encountered a somewhat similar case with the complete project directory tree
ending up copied into target/classes resulting in a build failure. I think I
was lucky having got this problem reported by the bundle plugin but it has
still wasted considerable amount of time to find out where the confusion
originated from. With some inclusion pattern to cover exactly the generated
files this case might have worked well. On the other hand I'm still not
conviced of the added value of such behaviour as it would be quite easier to
manually add a maven resource to the configuration when finding the generated
stuff not ending up in the final artifact. For better understanding the purpose
of {{<outputDirectory>${project.basedir}</outputDirectory>}} my intention in
the first place was to get it known to Eclipse PDE so that I can launch my app
from within the workspace. There might be more promising options, feel free to
give me a hint. In case this might have become a little bit off-topic, I
apologize in advance.
> 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
(v6.3.4#6332)
