Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cbi-dev] Some feedback on the build prototype 
Let me try to rephrase the requirements in my own words to make sure I
understand them properly

* In 3.8 and 4.2, for each git repository, same git commit is used to
build all projects from that repository

* By default, bundle and feature version qualifier changes only if
bundle/feature contents changes, but there should be a way to manually
override version qualifier.

* Rebuilding historical source tree version should produce the same
version qualifier as the original build (same requirement as above, really)

* Different projects use different version qualifier formats.

Did I miss anything?

--
Regards,
Igor

On 11-12-23 10:25 AM, Paul Webster wrote:

On Fri, Dec 23, 2011 at 9:34 AM, Igor Fedorenko <igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>> wrote:

    This is not how Tycho, and Maven in general, work. As I mentioned
    before, Tycho builds source trees, which in virtually all cases consist
    of multiple related projects (or "modules", as in Maven speak) that are
    developed and built together. In case of git, this means that all
    modules' sources belong to the same checkout.


Yes, we noticed that :-)  It's of the problems the LTS build will have
to overcome  to replicate a current Eclipse/Equinox SDK build.  There's
a fundamental requirement in build output of the eclipse project builds:
the qualifier is the same *iff* the bundle is the same.  Up until now,
the map files have provided that, or allowed it to be fixed in the few
instances it fails.

You can look at this in 2 ways.  1) going forward, and 2) support for
3.7.x, 3.6.x, 3.5.x, 3.4.x

1) going forward in 3.8 and 4.2, we're all in git.  With the switch to
using the integration branch as build input, you are in the situation
where the build input is one checkout per repo, the common scenario.
The map files become a secondary, generated set of artifacts which could
in theory be bypassed.  Generating the qualifier for each project using
the UTC timestamp of the last commit to touch  that project [1] (which
is just a convention for our auto-tagging script right now) guarantees
that a change in the source generates a new qualifier, and no change in
the source generates the same qualifier [2], and would make the maven
only build be able to derive qualifiers the same way our current map
based builds do.


2)   To regenerate an existing release build, the map files must be read
because the qualifiers aren't standardized.  For a given maintenance
release I see qualifiers like: I*, M*, r36* v*_r36*, etc.


How to consume map files is important depending on how important support
for #2 is.


Later,
PW


[1] SWT is the exception to this.  Their build qualifier must be the
same in their native binaries, their fragments, and their bundle.
Because of this they can't use the auto-tagging convention without
re-considering their entire build process.

[2] there's always an exception, of course :-) If you re-run a build but
change the basebuilder/compiler out from under the system, you'll get
different compiled content even though technically it's the same.  To
update qualifiers (sometimes necessary) we are considering using a
non-source file with a commit change, so there will be an actual commit
in the repo to reflect the need to bump up a qualifier.  This doesn't
work while trying to reproduce an old build though.



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


_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cbi-dev

Back to the top