Re: [tycho-dev] build failures with latest snapshot

[Steffen Pingel <steffen.pingel@xxxxxxxxxxx>]

We build the same set of modules on all platforms. That way we
insulate consumers of our APIs from differences in the underlying
platform versions.

In the past we had branches for each supported platform version and
separate update sites that targeted a specific Eclipse release. This
made sense when differences between platforms were significant. It put
burden on committers and consumers though who had to manage branches
and deal with multiple repositories.

Since Eclipse 3.4 the differences between platform versions that
affect Mylyn have become minor and we are now using a slightly
different strategy (4.2 support is a different story). We don't have
branches for platform versions any longer but build everything from
master. The code either uses reflection or pre-compiled class files
that are loaded at runtime depending on the running platform in the
places where upstream APIs differ between versions. To consume new
uptream APIs (e.g. when p2 moved to 2.0) we add optional dependencies
on the new bundles.

In terms of maintenance and build complexity I have found this
approach far less overhead than dealing with branches. We have unit
tests in place to ensure that the pre-compiled classes and reflection
calls don't cause regressions due to upstream changes that would go
unnoticed otherwise.

Steffen


On Fri, Aug 26, 2011 at 5:59 PM, Igor Fedorenko <igor@xxxxxxxxxxxxxx> wrote:
> Can you provide more details about building against different versions
> of Eclipse? Do you build different subset of modules when building
> against eclipse 3.5 and 3.7 (this is how we do it for some internal
> projects) or you build the same modules but they have different
> dependencies when built against eclipse 3.5 and 3.7 (I want to
> understand why).
>
> --
> Regards,
> Igor
>
> On 11-08-26 11:55 AM, Steffen Pingel wrote:
>>
>> For Mylyn we have a need to specify runtime dependencies that are not
>> available at compile-time. The most common scenario is support for
>> different Eclipse platform releases. If optional dependencies were
>> always required we wouldn't be able to compile code against older
>> Eclipse platforms anymore.
>>
>> On the other hand, if you always ignore optional dependencies by
>> default you will need to explain that to every new user who uses
>> optional dependencies.
>>
>> I would go for a greedy-but-optional behavior by default and support a
>> configuration option to set Tycho to always-ignore or always-require.
>>
>> Steffen
>>
>>
>> On Fri, Aug 26, 2011 at 5:33 PM, Igor Fedorenko<igor@xxxxxxxxxxxxxx>
>>  wrote:
>>>
>>> Optional/greedy makes target platform (and thus build result) unstable.
>>> I think Tycho should either always ignore optional dependencies or
>>> require them.
>>>
>>> --
>>> Regards,
>>> Igor
>>>
>>> On 11-08-26 11:30 AM, Steffen Pingel wrote:
>>>>
>>>> I would at least want the resolver to always be greedy and add
>>>> optional dependencies to the target if they are available. I guess it
>>>> would be too harsh to fail by default if an optional dependency can't
>>>> be resolved and not all optional dependencies are required at
>>>> compile-time anyways.
>>>>
>>>> Steffen
>>>>
>>>> On Fri, Aug 26, 2011 at 5:19 PM, Igor Fedorenko<ifedorenko@xxxxxxxxxxxx>
>>>>  wrote:
>>>>>
>>>>> Do you mean treat all optional dependencies as required during during
>>>>> the build?
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Igor
>>>>>
>>>>> On 11-08-26 11:13 AM, Steffen Pingel wrote:
>>>>>>
>>>>>> Thanks for the responses. I'll update our build accordingly.
>>>>>>
>>>>>> For the record, here is the bug for handling optional dependencies
>>>>>> during compile-time:
>>>>>>
>>>>>>  351842: builds fails when implicit target is used and optional
>>>>>> dependency is specified as non greedy in p2.inf
>>>>>>  https://bugs.eclipse.org/bugs/show_bug.cgi?id=351842
>>>>>>
>>>>>> I would prefer if optional dependencies were resolved by default and
>>>>>> didn't need to be specified in the build.properties.
>>>>>>
>>>>>> Steffen
>>>>>>
>>>>>>
>>>>>> On Fri, Aug 26, 2011 at 4:20 PM, Igor Fedorenko<igor@xxxxxxxxxxxxxx>
>>>>>>  wrote:
>>>>>>>
>>>>>>> For optional dependencies, I think it is common to have optional
>>>>>>> runtime
>>>>>>> dependencies that are required for compilation, so I think we need a
>>>>>>> way
>>>>>>> to decouple compile- and run- time dependencies. Currently,
>>>>>>> jars.extra.classpath can be used to express compile-only
>>>>>>> dependencies,
>>>>>>> but I am not sure if this is the best solution going forward.
>>>>>>>
>>>>>>> For feature id matching bundle ID... just don't do it. I realize this
>>>>>>> will cause migration problems, but this never worked reliably
>>>>>>> before and there are no plans to support artifactId != bundle/feature
>>>>>>> ID
>>>>>>> in Tycho going forward (see [1]).
>>>>>>>
>>>>>>> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=353384
>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>> Igor
>>>>>>>
>>>>>>> On 11-08-26 9:42 AM, Steffen Pingel wrote:
>>>>>>>>
>>>>>>>> Since the latest Tycho snapshot release Mylyn builds are starting to
>>>>>>>> fail. From a quick glance, there are two changes: Optional
>>>>>>>> dependencies are no longer resolved (we use implicit targets in
>>>>>>>> nightly builds) and Maven artifact ids are now expected to match
>>>>>>>> feature and plug-in ids.
>>>>>>>>
>>>>>>>> Concerning the optional dependencies, is the Tycho behavior going to
>>>>>>>> change again or do these now need to be marked as greedy in all
>>>>>>>> manifests (assuming that's the cause of the problem)?
>>>>>>>>
>>>>>>>> Changing artifact ids is easy but what is the recommended strategy
>>>>>>>> in
>>>>>>>> case a plug-in and feature use the same id?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Steffen
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> tycho-dev mailing list
>>>>>>> tycho-dev@xxxxxxxxxxx
>>>>>>> https://dev.eclipse.org/mailman/listinfo/tycho-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> tycho-dev mailing list
>>>>> tycho-dev@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/tycho-dev
>>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> tycho-dev mailing list
>>> tycho-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/tycho-dev
>>>
>>
>>
>>
> _______________________________________________
> tycho-dev mailing list
> tycho-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/tycho-dev
>



-- 
Steffen Pingel
Committer, http://eclipse.org/mylyn
Senior Developer, http://tasktop.com