Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cbi-dev] tycho and qualifiers 
Build configuration can be inherited from a parent pom, so build output
can change even if the files under project basedir did not. Using pde.ui
as an example, one can specify jsr14 compile target in
eclipse.pde.ui/pom.xml and this will affect all pde.ui bundles.

This is why I suggest using two-phase approach for generating build
versions

1. Generate build qualifier using tagged commit.
2. Compare build results to a baseline build ignoring version qualifier.
   If build results did not change, use build results from the
   baseline build.

--
Regards,
Igor

On 12-02-10 11:13 AM, Paul Webster wrote:

On Fri, Feb 10, 2012 at 10:36 AM, Igor Fedorenko <igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>> wrote:


    What is the usecase for using different version qualifiers for different
    projects from the same git repository?


Our bundle qualifiers change when the code changes.  For example.
eclipse.platform.ui has 92 bundles and most of them haven't changed
since 3.7.  Their qualifiers shouldn't change either.

Git is happy to provide the last commit to touch a subdirectory and
that's what we're currently using to generate a qualifier for each
bundle, which we are using as part of the standard PDE build/map file
process.

We are in a partial state right now, which is changing bundles have the
new v<UTCtimestamp> qualifier that's tied to the last commit  to touch
that bundle.  Bundles that haven't changed are using the tag from the
map file, and that works for us currently because of the Git PDE fetch
factory copies each bundle out of its git repo.  One of our options for
3.8/4.2 is to switch all of the bundle qualifiers to the new format ...
take some churn now for some stability going forward.

Or are you asking about our build input?  It's always been our intent to
supply one commit as the build input (our auto-tagging works from our
integration or master branch, and I believe it's consistent with the LTS
prototype being an aggregate repo that specifies the other repos as
submodules).

Later,
PW

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