Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 347293 - Rootfiles includes version control metadata
Summary: Rootfiles includes version control metadata
Status: RESOLVED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Tycho (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Jan Sievers CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 361875 (view as bug list)
Depends on: 352251
Blocks:
  Show dependency tree
 
Reported: 2011-05-26 07:13 EDT by Alex Blewitt CLA
Modified: 2021-04-28 16:55 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Blewitt CLA 2011-05-26 07:13:46 EDT
Build Identifier: Tycho 0.12.0

When compiling a feature with eclipse-feature, and a rootfiles folder, the contents of the folder is copied as-is, including version control information (e.g. CVS, .svn). This won't be seen on any Git repository (because it doesn't store information at that level) but is visible on others that store metadata at a per-folder level.

To re-create, create a simple feature with:

root = resources
bin.includes = feature.xml

and in the resources directory have some content (e.g. docs/README.txt) along with version control metadata e.g. CVS/.svn

When the feature is built, you end up with two archives in the target folder:

myfeature-1.2.3.jar
myfeature_root-1.2.3.jar

the myfeature_root contains the CVS/.svn data as well

Unfortunately the root.folder.xxx isn't supported yet (as otherwise I may be able to select the single file to place in the docs/ subdirectory) and patterns don't appear to be honoured (so I can't do **/README.txt).

Reproducible: Always
Comment 1 Alex Blewitt CLA 2011-05-26 07:56:33 EDT
Here's a workaround (for anyone else tripping over the problem)

Add this to your pom.xml for the feature build:

	<build>
		<plugins>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-resources-plugin</artifactId>
				<version>2.5</version>
				<executions>
					<execution>
						<phase>generate-resources</phase>
						<goals>
							<goal>copy-resources</goal>
						</goals>
						<configuration>
							<outputDirectory>${project.build.directory}/rootfiles</outputDirectory>
							<resources>
								<resource>
									<directory>resources</directory>
									<filtering>false</filtering>
								</resource>
							</resources>
						</configuration>
					</execution>
				</executions>
			</plugin>
		</plugins>
	</build>

Then change your build.properties to include

rootfiles = target/rootfiles

Since the copy-resources phase doesn't copy across the metadata, it doesn't get embedded into the rootfiles.zip and so doesn't litter the product with your SCM info.

(or you could just use git)
Comment 2 Tobias Oberlies CLA 2011-06-10 12:11:41 EDT
I like your workaround :-)  In fact, I think that the default filter from the maven-resources-plugin should be applied to root file folders by default. Root files should behave in the same way as other resources in a Maven build.
Comment 3 Jan Sievers CLA 2011-06-14 10:42:18 EDT
as a preparation, commit 858a9d9 adds support for ant-like filesets which have default excludes for typical version control metadata files.

TODO: apply Tobias' FeatureRootAdvice refactoring and then use the fileset with default excludes.
Comment 4 Tobias Oberlies CLA 2011-07-18 07:26:07 EDT
(In reply to comment #3)
> TODO: apply Tobias' FeatureRootAdvice refactoring and then use the fileset with
> default excludes.

This is done. Jan, you can now go ahead and integrate the patterns support (bug 352251), which - through the default excludes - also solves this issue.
Comment 5 Jan Sievers CLA 2011-07-22 10:57:45 EDT
fixed with commit b5151
Comment 6 Jan Sievers CLA 2011-10-25 03:10:11 EDT
*** Bug 361875 has been marked as a duplicate of this bug. ***