archives.ui is compiled without problems in both dev environments, which means problem is in P2 metadata. I checked both target platforms and for ui.ide I found in indigo contents.xml

    <unit id='org.eclipse.ui.ide' version='3.7.0.v20110928-1505'>
...
      <requires size='12'>
...
        <required namespace='osgi.bundle' name='org.eclipse.ui.views' range='[3.2.0,4.0.0)' optional='true'/>
...
      </requires>

for juno contents.xml declares

    <unit id='org.eclipse.ui.ide' version='3.8.0.v20120228-1703'>
...
      <requires size='12'>
...
        <required namespace='osgi.bundle' name='org.eclipse.ui.views' range='[3.2.0,4.0.0)' optional='true' greedy='false'/>
...
      </requires>

it seems what they say here http://wiki.eclipse.org/Tycho/Release_Notes/0.14

" Optional bundle dependencies are fully supported during compilation now. By default, Tycho treats optional dependencies as required"

is not true, because it not just treats optional dependencies as required, but analyze greedy attribute as well.

Denis

On 04/16/2012 04:49 PM, Max Rydahl Andersen wrote:
this sounds very weird.

It would make sense if the dependency is now optional in Juno and was not optional in Indigo.

Then failure on Juno is expected since there is no longer  a required dependency listed and then this compile error is actually correct.

/max

On Apr 17, 2012, at 1:36 , Rob Stryker wrote:

It's possible it has to do with that it is optional, but this is still a 
change for us as developers. it was optional in Indigo and the build 
then still worked just fine. It is still optional in Juno, but now the 
build craps out. So it's still something to pay attention to.

On 04/17/2012 07:10 AM, Rob Cernich wrote:
Upon closer inspection, in Indigo at least, org.eclipse.ui.views is an _optional_ dependency of org.eclipse.ui.ide.  Given that, do you think this problem may be related to the fact that the imported dependency is optional?

Best,
Rob

----- Original Message -----
Hi All:

I've added a section to this wiki page
(https://community.jboss.org/wiki/HowToBuildJBossToolsWithMaven3#Tips_and_tricks_for_making_BOTH_PDE_UI_and_headless_Maven_builds_happy)
describing the issue, but, to summarize it, all compile time
dependencies must now be explicitly declared in your manifest.mf if
you
expect your plugin to build against juno.

While investigating /JBIDE-11545, we discovered archives.ui built
fine
against indigo, but failed against juno. The reason was that
archives.ui
had a compile-time dependency on org.eclipse.ui.views, but the
manifest.mf did not declare this dependency. The dependency was
resolved
fine in the past because archives.ui depended on org.eclipse.ui.ide,
and
org.eclipse.ui.ide depended on org.eclipse.ui.views.

It seems tycho will no longer resolve nested dependencies. If you
have a
compile time dependency on a plugin or bundle, you must declare it
explicitly in your manifest.mf. You can no longer trust that tycho
will
be able to resolve these nested dependencies and provide all
available
plugins at build time.

This will be a huge pain for some people.  I know in my dev style, I
just try to implement an interface, and, if eclipse does not resolve
it,
then I add it to manifest.mf.  It seems to me that doing so now will
maybe cause errors and broken builds for devs who do not build
locally
before every commit. If for example you try to implement an
interface,
and eclipse does not complain, it is likely that a plugin you already
depend on also provides you access to the interface you are seeking.
But
when building in tycho against juno, this plugin won't be found.

So update those manifest.mf files, and if you haven't been building
locally for every commit, start doing it, at least for compilation.
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev

_______________________________________________
jbosstools-dev mailing list
jbosstools-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev

_______________________________________________
jbosstools-dev mailing list
jbosstools-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev