felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Egli (JIRA)" <j...@apache.org>
Subject [jira] [Created] (FELIX-4246) maven-scr-plugin 1.14 deletes scr descriptor .xml files on subsequent (incremental) eclipse build
Date Fri, 27 Sep 2013 10:01:02 GMT
Stefan Egli created FELIX-4246:
----------------------------------

             Summary: maven-scr-plugin 1.14 deletes scr descriptor .xml files on subsequent
(incremental) eclipse build
                 Key: FELIX-4246
                 URL: https://issues.apache.org/jira/browse/FELIX-4246
             Project: Felix
          Issue Type: Bug
          Components: Maven SCR Plugin
    Affects Versions: maven-scr-plugin 1.14.0
         Environment: Eclipse, m2eclipse
            Reporter: Stefan Egli


There's a regression bug introduced in maven-scr-plugin 1.14.0 which *worked fine in 1.13.0*.
Consider the following scenario:

 * a project is setup in eclipse/m2eclipse using the maven-scr-plugin 1.14.0 and contains
java classes annotated with @Service and/or @Components
 * the project is cleaned ('clean project') and built ('build project')
 -> the descriptor .xml files are created as expected

 * when the project is built again (incrementally, eg manually triggering another 'build project'),
the descriptor .xml files are deleted


Some debugging narrows the problem down to the MavenProjectScanner.getSourcesForScanKind,
where the buildContext.newScanner is invoked. The scanner returned there is of type EclipseBuildContext
(set by m2eclipse) when doing a build right after a clean - and in this case the scanner finds
java files, sets those via project.setSources and MetaTypeIO.generateDescriptors correctly
generates the descriptors.

In the incremental(-eclipse)-build case though, the buildContext.newScanner returns an EclipseIncrementalBuildContext
- which results in an empty set of sources being passed to project.setScanner, hence later
down the call-stack MetaTypeIO.generateDescriptors gets an empty list of components, thus
*thinks it's a good idea to go through the metatype directory and delete 'obsolete' metatype
files* - when in fact they are not quite obsolete..

Maybe it would be better to hook into the 'clean' method for deleting/cleaning up?

--
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

Mime
View raw message