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

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