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