[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cbi-dev] [jdt-core-dev] Fwd: compare artifacts to baseline version
|
On 12-07-06 9:20 AM, John Arthorne wrote:
Ah right, sorry for being dense. So the only choices are to always pick
the latest batch compiler, or else publish the batch compiler in the
repository so we can use it for baseline comparison. But would the
version qualifier still be derived from the last commit timestamp?
Yes, version qualifier of all bundles derived from the same project is
generated from the timestamp of the most recent commit that touches any
project file. There is currently no way to determine what sources
contributed to each of the bundles.
Now that I look in our published repositories, I do actually see the
batch compiler being published:
http://download.eclipse.org/eclipse/updates/4.2/R-4.2-201206081400/plugins/org.eclipse.jdt.core.compiler.batch_3.8.0.I20120608-1400.jar
The version of the batch compiler does not match the version of jdt core
in that repository and does not match timestamp of the most recent git
commit. Tycho can't correlate the batch compiler produced by the build
with the batch compiler from the baseline repository.
org.eclipse.jdt.core.compiler.batch 3.8.0.I20120608-1400
org.eclipse.jdt.core 3.8.1.v20120531-0637
--
Regards,
Igor
I don't see the ant adapter though.
John
*Igor Fedorenko <igor@xxxxxxxxxxxxxx>*
Sent by: cbi-dev-bounces@xxxxxxxxxxx
07/06/2012 08:38 AM
Please respond to
Common-build Developers discussion <cbi-dev@xxxxxxxxxxx>
To
cbi-dev@xxxxxxxxxxx
cc
Subject
Re: [cbi-dev] [jdt-core-dev] Fwd: compare artifacts to
baseline version
But that's exactly the problem -- there is no baseline version of the
batch compiler jar to compare build output with, so it is impossible to
tell if it's unchanged or not.
--
Regards,
Igor
On 12-07-06 8:22 AM, John Arthorne wrote:
> Yes I think it is fine to use artifacts from different builds in this
> case, assuming we have done a comparison and confirmed they are
unchanged.
>
> John
>
>
>
> *Igor Fedorenko <igor@xxxxxxxxxxxxxx>*
> Sent by: cbi-dev-bounces@xxxxxxxxxxx
>
> 07/06/2012 07:48 AM
> Please respond to
> Common-build Developers discussion <cbi-dev@xxxxxxxxxxx>
>
>
>
> To
> cbi-dev@xxxxxxxxxxx
> cc
>
> Subject
> Re: [cbi-dev] [jdt-core-dev] Fwd: compare artifacts
to baseline
> version
>
>
>
>
>
>
>
>
> By "reactor version" I meant artifacts generated by the current build,
> which is probably not the right use of the term. Sorry about the
confusion.
>
> To continue your example, do you think it is okay to use jdt core jar
> from baseline repository and the batch compiler jar from the current
> build? Or should we plan to setup baseline repository for build-time
> artifacts?
>
> --
> Regards,
> Igor
>
> On 12-07-05 10:20 AM, John Arthorne wrote:
> > I don't know if I fully understand the question and I'm not familiar
> > with some of the terms, such as "reactor version". Let me try to
restate
> > the question to see if I understand it. Say for simplicity we have two
> > artifacts generated from the JDT core source repository: the batch
> > compiler jar and the jdt core jar. Now say there is a source code
change
> > that does not affect the batch compiler, but does affect the jdt core
> > jar. If you run a build and compare with baseline, you might conclude
> > the new batch compiler jar is identical to the baseline, so its
version
> > number does not change. But, the jdt core jar has changed so it has a
> > new version. If we discard artifacts that are identical to previous
> > build, we end up with the two JDT artifacts being derived from
different
> > source versions. This isn't a big problem if we have already run a
> > comparison and concluded they are identical. In fact it's already
common
> > for us to have multiple plugins in one source repository with
different
> > tags, so it seems like just another case of that. So, I would say
do the
> > same thing in this case and only retain the artifacts that are
different
> > from the baseline. Now your second problem is that there isn't a
> > baseline repository containing some of these artifacts. Perhaps we can
> > resolve that by publishing all artifacts to a "build-time" repository
> > that is only used by the build and not published to others?
> >
> > John
> >
> >
> >
> >
> > *Igor Fedorenko <igor@xxxxxxxxxxxxxx>*
> > Sent by: cbi-dev-bounces@xxxxxxxxxxx
> >
> > 07/05/2012 09:52 AM
> > Please respond to
> > Common-build Developers discussion <cbi-dev@xxxxxxxxxxx>
> >
> >
> >
> > To
> > cbi-dev@xxxxxxxxxxx
> > cc
> >
> > Subject
> > Re: [cbi-dev] [jdt-core-dev] Fwd: compare artifacts
> to baseline
> > version
> >
> >
> >
> >
> >
> >
> >
> >
> > I used jdt as an example to illustrate potential problem -- we
have two
> > sets of artifacts that are built from the same sources but they
are most
> > likely not byte-to-byte identical. Differences can be as benign as
> > different jar entry timestamps, but can be more serious, like
different
> > jar signer certificates, different pack200 normalization, etc.
> >
> > So my question is, when the build cannot validate all project
artifacts
> > against baseline, is it okay to mix artifacts produced by the
build with
> > artifacts from the baseline or should we do something else?
> >
> > --
> > Regards,
> > Igor
> >
> > On 12-07-05 9:22 AM, Stephan Herrmann wrote:
> > > I'd be happy to help with some details from JDT/Core.
> > > Unfortunately I can't claim I fully understand the CBI background.
> > >
> > >
> > >> From: *Igor Fedorenko* <igor@xxxxxxxxxxxxxx
> > <mailto:igor@xxxxxxxxxxxxxx>>
> > >> Date: Mon, Jul 2, 2012 at 12:00 AM
> > >> Subject: [cbi-dev] compare artifacts to baseline version
> > >> To: Common-build Developers discussion <cbi-dev@xxxxxxxxxxx
> > >> <mailto:cbi-dev@xxxxxxxxxxx>>
> > >>
> > >>
> > >> As part of "do not generate new version qualifier"
> implementation, Tycho
> > >> compares reactor project artifacts to baseline version to make
> sure the
> > >> build does not try to publish new contents under old/existing
> version.
> > >> This works reasonably well for majority of projects (well, at
least
> > >> Tycho is able to find baseline artifacts), but there are few
> artifacts
> > >> that are not available from any p2 repository I can find and I
am not
> > >> sure what to do about them.
> > >>
> > >> Specifically, I could not find p2 repository that provides jdt
batch
> > >> compiler and ant adaptors, many/all test bundle sources and
few other
> > >> source bundles.
> > >
> > > Does this come as a surprise? I don't see reasons why batch
compiler
> > > and ant adaptor should ever appear in any p2 repository. They
are not
> > > supposed to be consumed in any OSGi nor Maven contexts.
> > >
> > > Well, this is not fully true for the batch compiler. While
regular use
> > > is standalone, this might be exactly the bundle that tools like
> > > tycho-compiler-plugin may want to consume? It seems to be an OSGI
> bundle
> > > already. Maybe it should be published in a p2 repository after all.
> > > Would that make a difference for your question?
> > >
> > > Still for the ant adapter I don's see use in having it in a p2
repo.
> > > Also tests are not typically consumed other than from source.
> > >
> > >> Note that all these bundles are "attached artifacts" and at
least one
> > >> other artifact is produced from the same project source tree.
> > >
> > > These may be obvious, but let me mention anyway:
> > > org.eclipse.jdt.core_version.jar "contains" both of the other
> artifacts:
> > >
> > > - jdtCompilerAdapter.jar is a nested jar inside o.e.jdt.core_v.jar
> > >
> > > - batch compiler is a subset of o.e.jdt.core_v.jar, the latter can
> > > actually be used in place of the former.
> > >
> > >> Using jdt core as example, what is supposed to happen to batch
> compiler
> > >> and ant adaptor if Tycho finds "equal" baseline version of jdt
core
> > >> bundle?
> > >
> > > If baseline version of jdt core bundle is equal to current
workspace
> > > version, then batch compiler and ant adapter can not have changed
> > > either, if that's the question.
> > >
> > >> Should Tycho replace jdt core bundle with baseline version and
keep
> > >> reactor version of the batch compiler and ant adaptor, i.e.
> running the
> > >> risk of inconsistency between jdt core and other two artifacts?
> > >>
> > >> Should Tycho keep reactor version of all three artifacts and
risk of
> > >> inconsistency between reactor and baseline versions of jdt core
> bundle?
> > >>
> > >> Should Tycho just fail the build?
> > >>
> > >> None of these approaches looks good, tbh, but I can't think of any
> > >> better/workable alternative.
> > >>
> > >> --
> > >> Regards,
> > >> Igor
> > >
> > > does this already help?
> > > Stephan
> > >
