Skip to main content

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




Back to the top