Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-user] Problems with Reproducible Version Qualifiers.

Thanks Igor, that makes more sense now.

Regards,

Simon


On 26 November 2012 12:17, Igor Fedorenko <igor@xxxxxxxxxxxxxx> wrote:
There was a long discussion whether Tycho should attempt to identify
identical artifacts even when versions changes, i.e. 1.0.0.A and 1.0.0.B
in your example, in one of CBI bugzillas. In the end we decided it was
too hard a problem, and would likely result in unstable/unpredictable
behaviour.

What was implemented in Tycho essentially enforces "same id/version ==
same contents" policy for p2 artifacts produced by Tycho builds. Changes
to version disable this validation and forcing new version, with an
artificial commit, for example, provides developers with a way to force
new artifact contents even if Tycho believes nothing changed.

Git timestamp provider calculates build timestamp from the most recent
commit that touches any file under project basedir. Doing this on
repository level is too coarse-grained and would pretty much render this
feature useless.

Also note that git timestamp provider allows ignore of files based on
includes/excludes filter. I believe proper stable versions require
filtering of pom.xml files and other source resources that control build
output but are usually not part of project "real" functionality.

--
Regards,
Igor


On 12-11-26 5:22 AM, Simon Goodall wrote:
Thanks Paul,

That's different to the view I had of the baseline repository. I had
somehow to to the idea that given version 1.0.0.A and 1.0.0.B, if the
two plugins were identical, then 1.0.0.B would be replaced by version
1.0.0.A.

I'm currently looking at implementing a timestamp provider for
mercurial. I have something working which provides a timestamp based on
the latest commit for the repository, not the individual project. Is
that the correct behaviour - or is tycho-dev better for this question?
The doc for the git timestamp provider indicates the timestamp is for
the whole repository. This is probably why I thought the baseline
repository would replace 1.0.0.B with 1.0.0.A in the case where the
plugin is otherwise identical.

Regards,

Simon


On 23 November 2012 15:57, Paul Webster <pwebster@xxxxxxxxxxxxxxxxxxx
<mailto:pwebster@alumni.uwaterloo.ca>> wrote:

    The configuration we use for qualifiers [1] and baseline comparator [2].

    If the plugin/version/qualifier is not in the p2 repo specified in
    [2] then you should get a message stating there's no baseline
    version MavenProject.  But if the id/version/qualifier match exactly
    you should get something like:

    [WARNING] MavenProject:
    org.eclipse.equinox.framework:org.eclipse.osgi.services:3.3.100-SNAPSHOT
    @
    /shared/eclipse/builds/R4_2_maintenance/gitCache/eclipse.platform.releng.aggregator/rt.equinox.framework/bundles/org.eclipse.osgi.services/pom.xml:
    baseline and build artifacts have same version but different contents


    [1]
    http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/eclipse-parent/pom.xml?h=R4_2_maintenance#n228

    [2]
    http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/eclipse-parent/pom.xml?h=R4_2_maintenance#n272


    --
    Paul Webster
    Hi floor.  Make me a sammich! - GIR

    _______________________________________________
    tycho-user mailing list
    tycho-user@xxxxxxxxxxx <mailto:tycho-user@xxxxxxxxxxx>
    https://dev.eclipse.org/mailman/listinfo/tycho-user





_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tycho-user

_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tycho-user


Back to the top