| Re: [tycho-user] "Reproducible Version Qualifiers" -> what about binary-only changes? |
Here is a relevant quote from the wiki you linked
"Generated artifacts are then compared to artifacts available from
configured baseline repositories. If baseline repositories contain
artifacts with the same id and version and equal contents, the generated
artifacts are replaced with baseline version. If baseline repositories
contain artifacts with the same id and version but different contents,
depending on <baselineMode> configuration parameter the build will
either fail or generated artifacts will be replaced with baseline
version. If the base repository does not contain artifact with the same
id and version, the generated artifacts are used. In all three cases the
same artifact id/version are guaranteed to represent the same artifact
contents.
The end result is that build output contains new versions of the
artifacts that did change and baseline version of the artifacts that did
not."
IIRC, Tycho is supposed to fail the build if "new" and "old" jars have
the same id/version but different contents. When this happens, you need
to create an artificial change in the bundle to force new version. I
believe this is what eclipse platform developers do.
--
Regards,
Igor
On 2014-09-24, 4:25, Michael Schaufelberger wrote:
______________________________________________________________________________________________Hi,
According to
https://wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers, only
source code changes trigger the build of a new artifact version of a
project. This concept leads to problems in cases where there are only
binary changes (due to source code changes in another project).
Assume a project p.helloworld containing a source file Hello.java with a
source code line Printer.print("Hello World"). That project has a
dependency on another project named p.commons, containing a source file
Printer.java with a method print(String s). Furthermore, assume the last
source code change in p.commons was made today at 01:00, the last change
in p.helloworld was made today at 05:00.
At 20:00 the method signature in Printer.java is changed to
print(CharSequence s), no source code changes are made in Hello.java
(the application still works as expected). But Hello.class will change,
as it contains the signature of the referenced method. Now we've got the
following artifacts:
p.commons_1.0.0.20140924-0100.jar - OK
p.commons_1.0.0.20140924-2000.jar - OK
p.helloworld_1.0.0.20140924-0500.jar - containing the "old" Hello.class
p.helloworld_1.0.0.20140924-0500.jar - containing the "new" Hello.class (!)
The last artifact for p.helloworld contains class files newer than the
timestamp denoted by the artifact's filename. The content of the two
artifacts built for p.helloworld differ, while the filenames are the
same (so it's considered the same artifact/file/version).
When resolving/updating dependencies in yet another project (assuming a
dependency on p.helloworld) the "old" p.helloworld artifact will
possibly (happened in our team) not be replaced with the "new"
p.helloworld artifact because it seems the correct artifact is already
there.
This then leads to runtime errors (NoSuchMethodError) because the
(outdated) Hello.class is still looking for a method print(String s)
while there is only a method print(CharSequence s) available.
How can this be avoided? Should projects also check for source code
changes in (explicit and implicit) dependencies to trigger a new
artifact version? Could there be a post-check to ensure an artifact with
the same version/filename as the previous build also has the same
content/checksum (otherwise the version of the new build will be adjusted)?
What do you recommend?
Cheers
Michael
tycho-user mailing list
tycho-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user
tycho-user mailing list
tycho-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user