Bug 408447

Comment 1 Jay Arthanareeswaran 2013-05-20 00:46:43 EDT

*** Bug 405870 has been marked as a duplicate of this bug. ***

Comment 2 Jay Arthanareeswaran 2013-05-20 05:57:16 EDT

I spent some time playing around with the pom file and I have something might work. I have the following piece of code that seem to update the properties file in question. But only question mark is over the property ${project.version}. Right now I see the value in the pom.xml being used - 3.9.0-SNAPSHOT. Is this something I can expect to work during a build? If not, what is the property I should use to get the correct bundle version?

The following goes to org.eclipse.jdt.core/pom.xml

	  <plugin>
		<artifactId>maven-antrun-plugin</artifactId>
		<executions>
			<execution>
				<phase>prepare-package</phase>
				<configuration>
					<tasks>
						<replace token="bundle_qualifier," value="${project.version}," dir="${project.build.directory}/classes">
							<include name="org/eclipse/jdt/internal/compiler/batch/messages.properties" />
						</replace>
					</tasks>
				</configuration>
				<goals>
					<goal>run</goal>
				</goals>
			</execution>
		</executions>
	  </plugin>

Comment 3 Markus Keller 2013-05-30 13:31:49 EDT

I've updated the copyright date with http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=16a2b90114b7d82dfc0b904ad237f557c3de69c2 , but I missed the bundle_qualifier.

Any insight from Maven/Tycho experts about how to write the bundle qualifier into a file at build time?

Comment 4 Jan Sievers 2013-06-03 04:58:29 EDT

(In reply to comment #3)

> Any insight from Maven/Tycho experts about how to write the bundle qualifier
> into a file at build time?

you can use maven properties ${buildQualifier} and ${unqualifiedVersion}, see docs [1]

[1] http://eclipse.org/tycho/sitedocs/tycho-packaging-plugin/build-qualifier-mojo.html

Comment 5 Jay Arthanareeswaran 2013-06-04 03:56:30 EDT

Created attachment 231913 [details]
Proposed fix

(In reply to comment #4)
> you can use maven properties ${buildQualifier} and ${unqualifiedVersion},
> see docs [1]
> 
> [1]
> http://eclipse.org/tycho/sitedocs/tycho-packaging-plugin/build-qualifier-
> mojo.html

That's perfect and thanks for chipping in!

I am attaching the patch, which I have tested and found to be working in my local environment. David, could you take a quick a look at it and see if this would work in the build environment? TIA!

Comment 6 David Williams 2013-06-04 09:27:01 EDT

I'm pretty sure this would work as expected. That is, the buildqualifier would basically be updated/changed each build but, I think, that if there was no other changes in jdt.core, it would not effect its own computed qualifier, so it would be "thrown away" and jdt.core replaced with previous version by comparator. I think this is the desired end-result. So, if there was a "real change", the bundle_qualifier would be updated in the end deliverable, but if there was not, it would simply show up each time in comparator as "something changed", even when replaced by previous version (which, happens all the time for jdt core anyway, for some reason :/. 

You will have to "touch" jdt.core the first time, in git, to make sure it gets in once (since POM only changes are not used in the computation that a bundle gets a new qualifier). 

Seems important enough to me to put in RC4 and if not quite right then improve on it later. For example, at worse, it will make jdt.core change qualifier each build ... I don't think that will happen ... but ... hard to know with 100% certainty. 

And, you'll have to look at jdt_core_* bundle vs. org.eclipse.jdt.core.compiler.batch_* in detail, (such as do binary diff) to make sure each are accurate. For example, while looking at something else, I noticed last night comparing two builds where jdt.core_* did not change, a quick diff said 
Binary files I20130602-2000/plugins/org.eclipse.jdt.core.compiler.batch_3.9.0.v20130530-1629.jar and I20130603-2000/plugins
/org.eclipse.jdt.core.compiler.batch_3.9.0.v20130530-1629.jar differ

Not sure what that difference was, but you'll probably see that now, with this fix, even for jdt_core_* bundle.

Comment 7 Igor Fedorenko 2013-06-04 09:39:46 EDT

Although attached patch should work, I'd probably use standard maven resource filtering [1] instead of custom ant script.


[1] http://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html

Comment 8 Dani Megert 2013-06-04 10:15:53 EDT

(In reply to comment #6)
> Seems important enough to me to put in RC4 and if not quite right then
> improve on it later.

I agree.

Comment 9 Markus Keller 2013-06-04 10:36:11 EDT

Since the patch from comment 5 has already been tested and reviewed, I've released that one for the next build: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=6fe9d61eea2c00b1cd723dbcfb2c6ce66bf0208b


(In reply to comment #7)
> http://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html

Thanks for the pointer. We would probably have used that if we wouldn't have been that close to the finish line.

Comment 10 Jay Arthanareeswaran 2013-06-04 12:02:36 EDT

(In reply to comment #9)
> Since the patch from comment 5 has already been tested and reviewed, I've
> released that one for the next build:
> http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/
> ?id=6fe9d61eea2c00b1cd723dbcfb2c6ce66bf0208b

Thanks Markus! Agree, we can probably look at the alternative during 4.4.

Comment 11 Jay Arthanareeswaran 2013-06-05 01:05:13 EDT

I can confirm that the JAR produced has the correct version (v20130604-1421) set in the messages.properties and also prints the same when this command is invoked:

java -jar ecj-I20130604-2000.jar -version

Comment 12 Dani Megert 2013-06-05 03:23:28 EDT

(In reply to comment #11)
> I can confirm that the JAR produced has the correct version (v20130604-1421)
> set in the messages.properties and also prints the same when this command is
> invoked:
> 
> java -jar ecj-I20130604-2000.jar -version

Besides that, I also verified the message.properties file in the ecj and jdt.core JARs.

Verified in I20130604-2000.