Skip to main content

[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?

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>:
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>>:


    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>, 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>
        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
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



--
Regards,
Anton.

Back to the top