Bug 418711 - [xtend] Generated code is bogus when guava not present and user not notified
Summary: [xtend] Generated code is bogus when guava not present and user not notified
Status: NEW
Alias: None
Product: Xtend
Classification: Tools
Component: Core (show other bugs)
Version: 2.4.3   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 440631 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-10-04 16:07 EDT by Miles Parker CLA
Modified: 2017-04-13 04:38 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Miles Parker CLA 2013-10-04 16:07:42 EDT
When the com.google.guava library is not present on the project class path, the xtend generator produces bogus code. e.g. instead of:

        boolean _equals = Objects.equal(_source, "foo");
        
We get:

        boolean _equals = void.equal(_source, "com.tasktop.ui");
        
That in itself is ok, though I'm not sure why there is the need to have it, I'm sure there is an interesting reason. :) The problem is that the user isn't notified that there is a problem with the project. After puzzling with this for a while, I looked at a projec where it was working and noticed that the code was different and included the reference to the guava class.

Note that this came up within a WTP project -- perhaps it is handled more helpfully in OSGi bundle projects.
Comment 1 Sven Efftinge CLA 2013-10-07 03:46:50 EDT
Guava is a mandatory dependency of org.eclipse.xbase.lib.
User's will get an error marker when the latter is not on the classpath.

So yes, OSGi takes care of the transitive dependency.

Maybe you are interested in this bug as well : bug #414775
Comment 2 Miles Parker CLA 2013-10-07 12:40:27 EDT
(In reply to Sven Efftinge from comment #1)
> Guava is a mandatory dependency of org.eclipse.xbase.lib.
> User's will get an error marker when the latter is not on the classpath.
> 
> So yes, OSGi takes care of the transitive dependency.

Yes, the problem then is with web projects and other build targets where you have different dependency models. Then you never get to see the broken dependency, because the code that would have been broken is never produced! So I like Sven's  suggestion in bug 414775 comment 1 that we produce an error marker in the source xtend file.
Comment 3 Christian Dietrich CLA 2017-04-13 04:38:13 EDT
*** Bug 440631 has been marked as a duplicate of this bug. ***