Skip to main content

[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

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



Back to the top