public/private mixed warning from STS2.8.0M1 and grails snapshot #6

wstidolph opened this Issue Aug 23, 2011 · 10 comments


None yet
2 participants

This is probably a spurious error, but it seems like a good idea to log it ...

Using the published 0.1.2 of Tropo plugin. with the grails SNAPSHOT development head (commit 53007641ec595b96d9227d3bc35f556eaac6831e), under STS 2.8.0.M1, I get the following error from eclipse about TropoBuilder (after repeated grails clean and eclipse project clean)

Description Resource Path Location Type
Groovy:Mixing private and public/protected methods of the same name causes multimethods to be disabled and is forbidden to avoid surprising behaviour. Renaming the private methods will solve the problem. TropoBuilder.groovy /qdfront/.link_to_grails_plugins/tropo-webapi-grails-0.1.2/src/groovy/com/tropo/grails Unknown Java Problem

Why I think it's spurious (from combining two bleeding edges):

  • don't see any public/private methods of the same name in TropoBuilder
  • don't get any warning from grails run-app from the command line with the SNAPSHOT
  • does not happen with the 2.0.0M1 grails drop under STS 2.8.0.M1

Probably it's not a real issue but just thought I'd register this event, just in case it comes up later


mpermar commented Aug 24, 2011

Wow. Thanks for the report Wayne.

It well may be some grails|grails plugin issue, but I'll have a closer look once moved to STS 2.8.0

Error still present in TB ver 0.2. I find it goes away if I change line 134 "buildElement" declaration from private to public.

@mpermar mpermar closed this in aa1a786 Sep 9, 2011


mpermar commented Sep 9, 2011

Hi Wayne,

So it looks like BuilderSupport probably added a method in the Groovy version bundled with the new STS. I renamed the buildElement method to internalBuildElement. That should fix the issue.

I haven't committed a new version of the plugin yet. I'll wait to see if more stuff comes in.

And thanks for pointing this out!

I also think the issue goes away due to changes in STS 2.8.0M2, that seems to be OK with ver 0.2 of the plugin (pre-namechange).

I was wrong that the issue goes away (or rather, it is back with the recent STS versions) so if I would appreciate it if you could push a new version of the plugin with the renamed method (sorry to ask, but I'm starting to try and push this app to the test servers and they want to pull from the normal grails repos)


mpermar commented Oct 4, 2011

Hi Wayne,

Version 0.2.1 is released with that name change.

Btw, is the name of your customer public? We love to heard from which companies are using Tropo and what cool stuff they are building with it.

Thanks, that will simplify my life ;)

The app isn't yet for a customer, it's a prototype of a product+service idea that I'm trying to start a company around ... if we can pull this off (there's 3 of us now) then the service will be cool - sort of "social media voicemail." The app is named 'quidais' right now but names change fast ...


mpermar commented Oct 4, 2011

cool stuff!

Turns out the public/private complaint still happens, even with the renamed buildElement of ver 0.2.1, with STS 2.8.0 SNAPSHOT builds (using groovy 1.8.2.xx-20110006-0900-e37 supplied by ver 2.5.2.xx-20111006-0900-e37 of the groovy-eclipse plugin). So, I renamed validate() to internalValidate() and the warning has gone away ... again. The no-error state persisted through an eclipse restart and a 'grails clean'

Renaming internalValidate() back to validate() brings the error state back.

I wondered if the issue was somehow a need to rename "any private method" so I tried renaming buildArray() to internalBuildArray() while leaving validate() alone - this did not cure the error state; it had to be renaming validate().

The result is that I have "private internalValidate()" and "private buildArray()" and no eclipse/STS warning of a "mixed private/public" error state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment