[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tycho-user] "Reproducible Version Qualifiers" -> what about binary-only changes?
|
There are only two meaningful choices, either perform baseline
validation or don't. The other choices really expose internal workings
of this feature to the user who isn't in the position to use them correctly.
baselineMode=warn that you have will write a warning message to the
build log if it find any discrepancies between baseline and build
artifact versions but does nothing else. This is utterly useless, if you
ask me, no one is going to watch build logs or know what to do about
these warnings even if they notice them. Don't use baselineMode=warn.
baselineMode=failCommon together with baselineReplace deals with
attached artifacts, or, more specifically, what to do with set of
artifacts produced from a project during the build is different from the
set of artifacts in the baseline. For example, project build may produce
sources bundle, while there is no sources bundle in the baseline
repository. Although it wasn't clear to me at the time, now I believe
the only correct behaviour is to always consider all artifacts produced.
If there are any changes compared to baseline, there must be a new
version. Don't use baselineMode=failCommon and don't set baselineReplace.
So this leaves us with baselineMode=disable, which disables baseline
validation and baselineMode=fail, which fails the build if artifacts
produced by the build have the same id/version but different content
than baseline.
Couple of other points worth mentioning
There is special handling of artifact contents. For example, there is
logic to compensate for classfile optimization performed by pack200, so
packed and original classes are still considered identical. There is
also special handling of bundle manifest and properties files.
When build and baseline artifacts are determined to be the same, the
build artifacts will be replaced baseline version. This guarantees that
artifacts with the same id/version are identical both logically and at
byte-level.
--
Regards,
Igor
On 2014-09-26, 5:47, Michael Schaufelberger wrote:
Thank you for your replies.
@Igor:
In our case, the newly generated artifact has been used (even though
there was an artifact with the same id and version (but different
content) in the repository). But we assume now, that's because we
configured the wrong baseline repository (so the case "base repository
does not contain artifact with the same id and version" was always true).
We would like to have the setup you mentioned (fail the build => need to
create an artificial change). I found that there are (at least) two
relevant parameters (besides the repository to compare with):
baselineMode and baselineReplace. Thus there are (at least) 4 possible
combinations. The quote from the wiki only mentions two cases, "fail" or
"replace". Could you elaborate on the parameter values (and their
defaults) and which combination we need to get the desired setup?
Currently our configuration (*.parent\pom.xml) looks as follows (note
that comparator.repo has been set incorrectly, see above):
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-p2-plugin</artifactId>
<version>${tycho.version}</version>
<configuration>
<baselineMode>warn</baselineMode>
<baselineReplace>none</baselineReplace>
<baselineRepositories>
<repository>
<url>${comparator.repo}</url>
</repository>
</baselineRepositories>
</configuration>
</plugin>
Thanks in advance.
Michael
2014-09-24 14:52 GMT+02:00 Anton Tanasenko <atg.sleepless@xxxxxxxxx
<mailto:atg.sleepless@xxxxxxxxx>>:
Having an option to at least issue a warning for a project that has
a dependency in the same reactor with a more recent qualifier than
the project's own could prove helpful.
2014-09-24 15:20 GMT+03:00 Igor Fedorenko <igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>>:
This would result in a lot of unnecessary version changes and
would make
this feature lot less useful. Binary only changes are relatively
rare,
so just detecting them seems to be good enough, at least this is
what I
was told by eclipse platform developers when I implemented this
feature.
You should be able to find original discussions and various
approaches
we considered on cbi-dev mailing list.
Also, there are serious unresolved problems with versioning of
features,
which happen when git commits are effectively created in the
past, for
example when a developer creates a commit locally today and
pushes it to
the canonical repository several days from today.
--
Regards,
Igor
On 2014-09-24, 8:10, Anton Tanasenko wrote:
Feature artifacts do actually take qualifiers of included
features and
plugins into account.
Is there a reason that same can't be made for plugin
dependencies, at
least for those in the same reactor build?
2014-09-24 14:50 GMT+03:00 Igor Fedorenko
<igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>
<mailto:igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>>>:
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
<https://wiki.eclipse.org/__Tycho/Reproducible_Version___Qualifiers>
<https://wiki.eclipse.org/__Tycho/Reproducible_Version___Qualifiers
<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 <mailto:tycho-user@xxxxxxxxxxx>
<mailto:tycho-user@xxxxxxxxxxx
<mailto: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
<https://dev.eclipse.org/__mailman/listinfo/tycho-user>
<https://dev.eclipse.org/__mailman/listinfo/tycho-user
<https://dev.eclipse.org/mailman/listinfo/tycho-user>>
___________________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx <mailto:tycho-user@xxxxxxxxxxx>
<mailto:tycho-user@xxxxxxxxxxx
<mailto: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
<https://dev.eclipse.org/__mailman/listinfo/tycho-user>
<https://dev.eclipse.org/__mailman/listinfo/tycho-user
<https://dev.eclipse.org/mailman/listinfo/tycho-user>>
--
Regards,
Anton.
_________________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx <mailto: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
<https://dev.eclipse.org/mailman/listinfo/tycho-user>
_________________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx <mailto: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
<https://dev.eclipse.org/mailman/listinfo/tycho-user>
--
Regards,
Anton.
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx <mailto: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
