[
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
|
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
> >
> > _______________________________________________
> > cbi-dev mailing list
> > cbi-dev@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/cbi-dev
>
> _______________________________________________
> cbi-dev mailing list
> cbi-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cbi-dev
>
>
>
>
> _______________________________________________
> cbi-dev mailing list
> cbi-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cbi-dev
>
_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cbi-dev
_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cbi-dev
