Community
Participate
Working Groups
Need to investigate what these jars are and if should be "ignored" or move to "target", or .. what. = = = = = = = Entering 'eclipse.platform.releng' # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: bundles/org.eclipse.cvs/about.mappings # modified: bundles/org.eclipse.rcp/about.mappings # modified: bundles/org.eclipse.sdk.examples/about.mappings # modified: bundles/org.eclipse.sdk.tests/about.mappings # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # bundles/org.eclipse.releng.tests/relengtests.jar # bundles/org.eclipse.releng.tools/tools.jar # bundles/org.eclipse.test/automated.jar no changes added to commit (use "git add" and/or "git commit -a")
(In reply to David Williams from comment #0) > # > # Untracked files: > # (use "git add <file>..." to include in what will be committed) > # > # bundles/org.eclipse.releng.tests/relengtests.jar > # bundles/org.eclipse.releng.tools/tools.jar > # bundles/org.eclipse.test/automated.jar > no changes added to commit (use "git add" and/or "git commit -a") I have looked at these ... and was surprised the only "fault" is that we specify the jar the code should go in, inside the bundle, instead of have .class files in the root of the bundle's directory. I would have thought if a "clean working tree" was so important, that Tycho could have put these jars directly in the target. As far as I know the only "fix" for a case like this is to change to bundle definition to have the .class files in the root of the bundle. I guess that is a "best practice" and as far as I can tell, there is no reason not to, in this case. I checked the feature.xml files, and none of them are "unziped" as directories (which would be a warning sign that the jar is used directly, by someone).
(In reply to David Williams from comment #1) > (In reply to David Williams from comment #0) > As far as I know the only "fix" for a case like this is to change to bundle > definition to have the .class files in the root of the bundle. I guess that > is a "best practice" and as far as I can tell, there is no reason not to, in > this case. I checked the feature.xml files, and none of them are "unziped" > as directories (which would be a warning sign that the jar is used directly, > by someone). I guess another "quick fix" is to use .gitignore file, and list the specific jar. It is, after all, not checked into Git nor should it be (in case someone did a "local build" in their workspace). I realized this after I noticed some were listed in the old .cvsignore files.
I took a look at org.eclipse.releng.tools and I think the issue is the build.properties. I'm still not completely familiar with build.properties parameters but I think the source.something.jar= line creates the jar in the project directory. For example: source.tools.jar = src/ is there a way using build.properties to say that these files should be placed in target/ instead?
(In reply to Thanh Ha from comment #3) > I took a look at org.eclipse.releng.tools and I think the issue is the > build.properties. I'm still not completely familiar with build.properties > parameters but I think the source.something.jar= line creates the jar in the > project directory. > > For example: > > source.tools.jar = src/ > > > is there a way using build.properties to say that these files should be > placed in target/ instead? No, not really. (That statement tells it what folder to use to make the jar, not where to put it). But, These sorts of things are typically best fixed via Manifest.mf editor, and then the build.properties file is updated automatically. (In most cases).
I'm going to flatten the o.e.tests bundle first, since it'd most likely to have some problem, if any. http://git.eclipse.org/c/platform/eclipse.platform.releng.git/commit/?id=5697859197a153f767dd522d50fa643bffbcb491
(In reply to David Williams from comment #5) > I'm going to flatten the o.e.tests bundle first, since it'd most likely to > have some problem, if any. > > http://git.eclipse.org/c/platform/eclipse.platform.releng.git/commit/ > ?id=5697859197a153f767dd522d50fa643bffbcb491 unit tests can still run, so assuming that went ok. Though looking at it now see I forgot to increment version number, so increased service field by +100 so version will now be 3.3.201. (containing feature had already been incremented). Also, I've flattened org.eclipse.releng.tools. Its version had already been incremented over R4_3_maintenance. For the last one, org.eclipse.releng.tests ... just glancing at it, I am not sure it can be safely flattened ... at least without some more investigation and/or code changes and/or testing (and, we currently do not run these during unit tests, so ... maybe later. For now, I just added a .gitignore file and added the output jar to it. I'm pretty sure all this will work in tonight's Nightly build ... should verify "releng tools" still operates as expected, when installed ... such as brings up copyright assistance dialog, etc.
