[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-dev] build failures with latest snapshot

Mylyn is built and tested against each supported Eclipse release:
https://hudson.eclipse.org/hudson/user/spingel/my-views/view/Mylyn%20Integration/

Steffen

On Fri, Aug 26, 2011 at 7:47 PM, Igor Fedorenko <ifedorenko@xxxxxxxxxxxx> wrote:
> How do you build/test this? Always use some canonical Eclipse version
> for compile and then test with all supported eclipse versions? Or you
> both compile and test against all supported eclipse versions?
>
> --
> Regards,
> Igor
>
> On 11-08-26 1:08 PM, Tom Schindl wrote:
>>
>> ... because we ship the complete RCP/RAP application (no p2 update or
>> whatever). So we are of full control. What you see here is the only
>> possibility to singlesource for RAP and RCP (bundle-import is not
>> working in this scenario!)
>>
>> Tom
>>
>> Am 26.08.11 18:21, schrieb Igor Fedorenko:
>>>
>>> How do you guarantee that one of optional dependencies is always
>>> available? As far as I can tell, this Require-Bundle will happy pass p2
>>> installation and OSGi resolution even when none of "optional-required"
>>> dependencies are available.
>>>
>>> --
>>> Regards,
>>> Igor
>>>
>>> On 11-08-26 12:14 PM, Tom Schindl wrote:
>>>>
>>>> Hi,
>>>>
>>>> If I get this right we have the same requirement. Our use case is that
>>>> we build against:
>>>> * RCP-Target
>>>> * RAP-Target
>>>>
>>>> and all our bundle have a dependency on a core bundle which has optional
>>>> dependencies like this:
>>>>
>>>>> Require-Bundle:
>>>>>
>>>>> org.eclipse.ui;bundle-version="3.4.0";resolution:=optional;visibility:=reexport,
>>>>>
>>>>>
>>>>>
>>>>> org.eclipse.ui.forms;bundle-version="3.3.100";resolution:=optional;visibility:=reexport,
>>>>>
>>>>>
>>>>>
>>>>> org.eclipse.jface.databinding;bundle-version="1.2.0";resolution:=optional;visibility:=reexport,
>>>>>
>>>>>
>>>>>
>>>>> org.eclipse.rap.ui;bundle-version="1.2.0";resolution:=optional;visibility:=reexport,
>>>>>
>>>>>
>>>>>
>>>>> org.eclipse.rap.ui.forms;bundle-version="1.2.0";resolution:=optional;visibility:=reexport,
>>>>>
>>>>>
>>>>>
>>>>> org.eclipse.rap.jface.databinding;bundle-version="1.2.0";resolution:=optional;visibility:=reexport,
>>>>>
>>>>
>>>> We always guarantee that one of the optional bundles is available but
>>>> there are never both.
>>>>
>>>> So we'd fail if you require all dependencies to be there and also if
>>>> none is resolved.
>>>>
>>>> Tom
>>>>
>>>>
>>>>
>>>> Am 26.08.11 17:59, schrieb Igor Fedorenko:
>>>>>
>>>>> 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
>>>>
>>>>
>>> _______________________________________________
>>> 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