Re: [gwt-contrib] Re: Error compiling with trunk and guava-gwt-18.0.jar

[Lars]

You could try to patch the guava-gwt.jar locally by yourself ... you need only 
apply this patch 
https://github.com/google/guava/commit/9e56ef17c335319d21f1f2c454176c9d32687a59 
by editing a java source file in the jar and it should work... I did a similar 
patch for guava 17 and this works with gwt 2.7 and the latest snapshot for gwt 
2.8 (both with Java7)! :-)

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/65bbb6da-574a-4ffc-b49f-5e19708424b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] I think the 2.7.0 GWT release was compiled on Daniel Kurka's machine !

[Colin Alworth]

This was also specific to .gwtar files, which will no longer be shipped
with the release. This also means the total size will drop, from around 30
mb to 16 mb.

On Mon, Nov 23, 2015 at 2:11 AM Arnaud TOURNIER  wrote:

> I confirm this is absolutely not a bug, and does not have any impact on
> production code...
> It was more a "fun fact"...
>
> Thanks
> Arnaud
>
> Le dim. 22 nov. 2015 17:48, Thomas Broyer  a écrit :
>
>>
>>
>> On Sunday, November 22, 2015 at 4:37:17 PM UTC+1, Niels Soeffers wrote:
>>>
>>> Hi Daniel, Arnaud,
>>>
>>> Did you managed to workaround or solve the above issue?
>>>
>>
>> Which issue? Arnaud said “There's no bug, nor problem on GWT side”
>>
>>
>>> I am having the exact same issue. Does this mean that the gwt-user 2.7
>>> jar in maven is useless?
>>>
>>
>> I hope almost everyone's using 2.7 by now. I've been using or toying with
>> those 2.7 artifacts for months and had no such problem.
>>
>>
>>> Kind Regards,
>>>
>>> Niels
>>>
>>> On Monday, July 6, 2015 at 9:34:59 AM UTC+2, Daniel Kurka wrote:

 It's not my desktop machine, but you are right I did the final
 compilation of the release. I thought we had already killed of gwttars
 anyway.

 On Thu, Jul 2, 2015, 11:21 AM Arnaud TOURNIER  wrote:

> Hi Daniel,
>
> I had a closer look to the thing. The paths mentionning your home
> account in google are stored in all the gwtar files in the gwt-user-2.7.0
> artifact
>
> Does that really mean that the offical gwt releases are built on your
> desktop machine ?
>
> Thanks
> Arnaud
>
> Le mer. 1 juil. 2015 à 18:42, Arnaud TOURNIER  a
> écrit :
>
>> It's a project of one of my customers which is on gwt 2.6 and needs
>> to migrate to 2.7.
>>
>> In the cours of doing that, i got this errors...
>>
>> If you need, i can investigate a bit more, but seems to be coming
>> from those [ERROR] java.lang.String cannot be resolved to a class...
>>
>> Thanks
>> ARnaud
>>
>> Le mer. 1 juil. 2015 à 18:20, 'Daniel Kurka' via GWT Contributors <
>> google-web-toolkit-contributors@googlegroups.com> a écrit :
>>
>>> Hi Arnaud,
>>>
>>> how are you producing these?
>>>
>>> -Daniel
>>>
>>> On Wed, Jul 1, 2015 at 9:06 AM Arnaud TOURNIER 
>>> wrote:
>>>
 Just dumping a bit of errors i get for a project :

 Tracing compile failure path for type 'java.lang.Object'
 [INFO]   [ERROR] Errors in 'file:
 */usr/local/google/home/dankurka/gwt/user/super/co*
 m/google/gwt/emul/java/lang/Object.java'
 [INFO]  [ERROR] java.lang.String cannot be resolved to a
 type
 [INFO]   [ERROR] Errors in 'file:/usr/local/google/home/
 *dankurka*
 /gwt/user/src/com/google/gwt/core/client/JavaScriptObject.java'
 [INFO]  [ERROR] java.lang.String cannot be resolved to a
 type
 [INFO]   [ERROR] Errors in 'file:/usr/local/google/home/
 *dankurka*
 /gwt/user/super/com/google/gwt/emul/java/lang/Throwable.java'
 [INFO]  [ERROR] java.lang.String cannot be resolved to a
 type
 [INFO]   [ERROR] Errors in 'file:/usr/local/google/home/
 *dankurka*/gwt/user/super/com/google/gwt/emul/java/lang/Class.java'

 There's no bug, nor problem on GWT side. I just found funny to get
 those kind of paths in a release artifact !!

 Thanks

 Arnaud

 --

>>> You received this message because you are subscribed to the Google
 Groups "GWT Contributors" group.
 To unsubscribe from this group and stop receiving emails from it,
 send an email to
 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>>>
>>>
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/4a744841-48ca-4a75-a5e4-91ba966aea80%40googlegroups.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>> --
>>> You received this message because you are subscribed to a topic in
>>> the Google Groups "GWT Contributors" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/google-web-toolkit-contributors/SyRZzSQeDWg/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, send an email to
>>> google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujiqP2rwYW9e2eqDUxL8qUA-5VKaGFbGi4bPS_-sNbGN3HA%40mail.gmail.com
>>> 

Re: [gwt-contrib] Re: GWTCon 2015 keynote question

[CodeLess Solutions]

No, but intend to will write a blog or an article about this. I will let 
you know when it's done. Probably in a few weeks as I need to write some 
other things before this.

In the meantime, you can take a look here: http://www.codeless.solutions or 
here: https://www.youtube.com/channel/UCgyHx-eZSXvVPvAVKa6BhHg

Maybe you will understand a bit more from the movies. Note: When you design 
the form in Form Designer you are working with real widgets (you drag and 
drop, move around real widget), when you save the form you only save Meta 
description of it, you do not save any UIBinder file, or Java file with 
content like: TextBox tb = new TextBox("text") anywhere. In other words, 
this is not a simple generator. The proof is that you can use new form 
immediately without the need to compile anything as shown in the movies, 
otherwise it would not be possible. That is what I call "Remote" meta form. 
The same as remote you can get with "Local" meta form (Local is written 
each time you save it in Form Designer so it's exactly the same as remote). 
Instantiation of real widgets from meta description is very fast and you 
will not notice any performance degradation. The similar counts for Remote 
meta form. If form (meta description) is missing, it will be fetched but 
only once, similar how gwt code splitting works but with the difference 
that here you can control this cache in the runtime (see Cache Manager 
movie).

This is not XUL and it does not use a single XML file. Yes it could, but 
there is no reason to do so.

BTW, I hope you are ok there in Leuven, not so nice things are happening 
recently in the Bruxelles.

P.S. Fill free to email me with any question you might have.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/9bebcf1f-96a0-41de-91ac-150c192cc581%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: GWTCon 2015 keynote question

[David]

did you post any articles about the design of your meta approach - I'm very
interested in reading a bit about it to see if I can learn from it ? I've
seen similar approaches where an XML representation was used (looking a lot
like XUL syntax), but I had to help in improving the performance and
factoring out GXT widgets with custom made ones.

On Mon, Nov 23, 2015 at 11:32 AM, CodeLess 
wrote:

> Good points and I agree with almost all you said ;-) We did not notice any
> performance degradation by using meta approach comparing to manual or
> UIBinder way, but that is something that we will try to demonstrate in the
> following weeks. Well, we do not have to support IE6/IE7 so this would be a
> good test, thanks for mentioning this! I will let you know when we create
> such a demo so you can take a look if you like.
>
> Let's see what will happen with Elemental2 in the following couple of
> weeks, I think Julien is working on it and if I remember well he
> said somewhere that he will have something in the following month or two.
> Anyway, I hope your fears will not come true.
>
> Cheers.
>
> On Mon, Nov 23, 2015 at 9:58 AM, David  wrote:
>
>> Good points and in most cases we are covered:
>> - Using a Command Processor over GWT-RPC, but I will move it to a REST
>> implementation.
>> - GUI is split up in MVP and the important code is not depending on any
>> GWT widgets or anything else.
>>
>> We are using UiBinder in our current application, but switching to
>> something else is not something that I am afraid off. When I use UiBinder I
>> try to avoid using widgets as much as possible. So if this needs to move to
>> Angular or some other HTML based template mechanism, I don't expect a lot
>> of difficulties since it is already close to pure HTML anyway.
>>
>> Abstracting behind a meta description language for the UI that part we
>> did not do. One of the main reasons is that you lose a lot of the
>> performance benefits that GWT is offering. This optimisations mattered
>> because we needed to support older browser (IE6/IE7).
>>
>> One important component we have does this, but that one is very much
>> tuned for one specific task (editing financial messages defined through
>> XSchema's). It can not handle writing entire GUI's with rich tables, tabs,
>> splitter panels etc. But has some domain specific optimisations that are
>> not that easy to do when you need to write a complete abstraction of the UI.
>>
>> We alse have dependencies on the CellTables because they offer quite good
>> performance and we enhanced the capabilities of those cell tables to add
>> missing functionality. But the CellTables are hidden behind a factory and
>> the interactions happens against interfaces, so the client code will not
>> too much impacted either.
>>
>> What I am mostly afraid of with losing Element or Widget classes is that
>> every widget vendor will start declaring their own base classes and
>> interfaces for common functionality. This will make it hard to mix
>> components from different vendors.
>>
>> Web Components are interesting, but as usual it is too soon to go down
>> that trail. Chrome is not the most used browser in banking and enterprise
>> environments and web components on IE11 is still a mess. I tried polymer
>> but it is way too slow to scale to large GUI's at this point.
>>
>>
>> On Sun, Nov 22, 2015 at 12:19 PM, CodeLess Solutions <
>> codelessoluti...@gmail.com> wrote:
>>
>>> This is very good question and actually one of the biggest problem not
>>> only in this particular situation but also in general software development.
>>>
>>>
>>> Imagine you decide to build something large like ERP or Banking
>>> Information system for an example (with hundreds even thousands of tables
>>> and forms) You didn’t even finish it because of its complexity and one day
>>> you find out that Swing or Angular1 or Flex or “something else” come to its
>>> end of living and you are not able to switch easily to anything else?
>>>
>>>
>>> I happened to me once long time ago with some other widget library, so I
>>> am talking from the personal experience :-(
>>>
>>>
>>> I will try to explain our strategy how to solve this problem:
>>>
>>>
>>> We are using GWT and we are really enjoying to use it but:
>>>
>>>
>>> We are not using WindowBuilder (it’s not supported anymore since version
>>> GWT 2.6 and it’s also useless when you are creating large application
>>> because it’s to slow), not using UIBinder because it generates to much
>>> boilerplate that we do not need at all, not using Request Factory that
>>> generates who knows what, not using MVP… nothing that is too specific or
>>> bound too much for the platform. The only thing that we use and is specific
>>> is Code Splitting but it’s totally hidden from developers and done
>>> automatically for each controller. We are not using any external library to
>>> do this. It’s simple to implement and it would be probably easy to replace
>>> it with something else tomorrow. Everythi

Re: [gwt-contrib] Re: GWTCon 2015 keynote question

[CodeLess]

Good points and I agree with almost all you said ;-) We did not notice any
performance degradation by using meta approach comparing to manual or
UIBinder way, but that is something that we will try to demonstrate in the
following weeks. Well, we do not have to support IE6/IE7 so this would be a
good test, thanks for mentioning this! I will let you know when we create
such a demo so you can take a look if you like.

Let's see what will happen with Elemental2 in the following couple of
weeks, I think Julien is working on it and if I remember well he
said somewhere that he will have something in the following month or two.
Anyway, I hope your fears will not come true.

Cheers.

On Mon, Nov 23, 2015 at 9:58 AM, David  wrote:

> Good points and in most cases we are covered:
> - Using a Command Processor over GWT-RPC, but I will move it to a REST
> implementation.
> - GUI is split up in MVP and the important code is not depending on any
> GWT widgets or anything else.
>
> We are using UiBinder in our current application, but switching to
> something else is not something that I am afraid off. When I use UiBinder I
> try to avoid using widgets as much as possible. So if this needs to move to
> Angular or some other HTML based template mechanism, I don't expect a lot
> of difficulties since it is already close to pure HTML anyway.
>
> Abstracting behind a meta description language for the UI that part we did
> not do. One of the main reasons is that you lose a lot of the performance
> benefits that GWT is offering. This optimisations mattered because we
> needed to support older browser (IE6/IE7).
>
> One important component we have does this, but that one is very much tuned
> for one specific task (editing financial messages defined through
> XSchema's). It can not handle writing entire GUI's with rich tables, tabs,
> splitter panels etc. But has some domain specific optimisations that are
> not that easy to do when you need to write a complete abstraction of the UI.
>
> We alse have dependencies on the CellTables because they offer quite good
> performance and we enhanced the capabilities of those cell tables to add
> missing functionality. But the CellTables are hidden behind a factory and
> the interactions happens against interfaces, so the client code will not
> too much impacted either.
>
> What I am mostly afraid of with losing Element or Widget classes is that
> every widget vendor will start declaring their own base classes and
> interfaces for common functionality. This will make it hard to mix
> components from different vendors.
>
> Web Components are interesting, but as usual it is too soon to go down
> that trail. Chrome is not the most used browser in banking and enterprise
> environments and web components on IE11 is still a mess. I tried polymer
> but it is way too slow to scale to large GUI's at this point.
>
>
> On Sun, Nov 22, 2015 at 12:19 PM, CodeLess Solutions <
> codelessoluti...@gmail.com> wrote:
>
>> This is very good question and actually one of the biggest problem not
>> only in this particular situation but also in general software development.
>>
>>
>> Imagine you decide to build something large like ERP or Banking
>> Information system for an example (with hundreds even thousands of tables
>> and forms) You didn’t even finish it because of its complexity and one day
>> you find out that Swing or Angular1 or Flex or “something else” come to its
>> end of living and you are not able to switch easily to anything else?
>>
>>
>> I happened to me once long time ago with some other widget library, so I
>> am talking from the personal experience :-(
>>
>>
>> I will try to explain our strategy how to solve this problem:
>>
>>
>> We are using GWT and we are really enjoying to use it but:
>>
>>
>> We are not using WindowBuilder (it’s not supported anymore since version
>> GWT 2.6 and it’s also useless when you are creating large application
>> because it’s to slow), not using UIBinder because it generates to much
>> boilerplate that we do not need at all, not using Request Factory that
>> generates who knows what, not using MVP… nothing that is too specific or
>> bound too much for the platform. The only thing that we use and is specific
>> is Code Splitting but it’s totally hidden from developers and done
>> automatically for each controller. We are not using any external library to
>> do this. It’s simple to implement and it would be probably easy to replace
>> it with something else tomorrow. Everything is done with a single
>> annotation.
>>
>>
>> GWT-RPC may also disappear? We are using JPA classes (with Hibernate) but
>> we don’t use DTOs because there is simply no need to pack and unpack
>> everything. We do not write code for every document we need to save
>> (create, update, delete), there is only ONE class that is doing the job via
>> GWT-RPC. Exceptions are rare (less than 10%) that you have to do something
>> special while persisting the document and you are able to do that as a
>>

Re: [gwt-contrib] Re: Elemental 2?

[dad]

Hi Ray,

We are keenly interested in this.
How does one get hold of your hacky Elemental2 prototype in order to play
with?

Thanks

On Fri, Nov 20, 2015 at 8:36 PM, 'Ray Cromwell' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> Another thing to consider is that J2CL was developed as a 'bake off', in
> which multiple prototypes and designs were discussed/looked at (compile
> from Java with JDT, compile from bytecode, compile using Javac APIs,
> writing parser by hand, etc) It would have been a bit premature to release
> any of them as they were all known ahead of time to be throwaways.
>
> I have a hacky Elemental2 prototype (which is not the official one that
> Julien is working on), if you want to take it and play around.
>
>
>
> On Fri, Nov 20, 2015 at 10:30 AM, 'Goktug Gokdogan' via GWT Contributors <
> google-web-toolkit-contributors@googlegroups.com> wrote:
>
>> No worries :)
>>
>> On Fri, Nov 20, 2015 at 10:27 AM, Stephen Haberman <
>> stephen.haber...@gmail.com> wrote:
>>
>>> Hi Goktug,
>>>
>>> That's all true, thanks for providing a counter data point. You're
>>> right, the JsInterop design docs/etc. were all out in the open from day 1,
>>> which I thought was pretty exiting.
>>>
>>> I definitely can't take any credit for providing useful feedback, but I
>>> enjoyed seeing the thoughts and process from the community.
>>>
>>> So, apologies for the sweeping statement.
>>>
>>> - Stephen
>>>
>>>
>>>
>>> On Fri, Nov 20, 2015 at 11:58 AM, 'Goktug Gokdogan' via GWT Contributors
>>>  wrote:
>>>
 Singular is not a Google project and not being developed internally. It
 is Daniel's personal project and as fas as I know it is already in the open
 source.

 We don't have anything to share for Elemental yet. We are talking with
 other teams, thinking about alternatives etc. Also when we release, it will
 not be part of GWT-SDK so there is going be extra work to move the
 development outside; which doesn't make sense at this stage.

 The big things we recently developed for GWT, JsInterop and
 SuperDevMode and they were all open source from day one.

 On Fri, Nov 20, 2015 at 5:34 AM, Stephen Haberman <
 stephen.haber...@gmail.com> wrote:

> > Meanwhile I will revive my own generator project.
>
> I'll take the opportunity to hop on a soapbox, but the "closed
> source/eventually open source" model is a curious trend that I think I've
> only seen in the GWT community (are their other examples?)...
>
> Musing, it probably stems from Google setting the example with GWT
> itself, where historically a lot happened internally before being mirrored
> externally, but it happens a bit for non-Google-GWT projects as well, like
> the repackaging of GPE, which was closed during initial development
> (although the result is great, and I really appreciate it), Singular, 
> which
> is still closed during initial development, now Elemental2. I dunno,
> I find it curious.
>
> E.g. with Singular, it's like it's being developed like the next Apple
> phone; we have to be secret about it, not say anything, so we can have an
> awesome keynote where we surprise the world with how awesome it is.
>
> Granted, I'm sure those keynotes are very fun, but I guess I don't
> understand, wtf, why not just open source things from day 1? IMO the best
> case scenario, and most likely, is that you're going to attract early
> adopters who will a) give you feedback to validate approaches/etc and b)
> give you free work by tracking down bugs and committing patches.
>
> Keeping things closed source "until they're ready", IMO, stifles the
> potential contributor/committer pool that's needed for the long term 
> health
> of an open source project.
>
> I suppose the risk is people writing a 100k LOC production app on a
> pre-1.0 project, and then they bitch about changes...but hopefully lots of
> disclaimers and 0.x release points would help mitigate that...
>
> Anyway, that is my soapbox. Or one of them, I guess. :-P Of course,
> we're all getting this work for free, so everyone is free to do what they
> please, and I will be very excited and thankful for both
> Elemental2/Singular when they are available to us.
>
> So please don't read this as "bah, that is dumb", but just as "gentle
> nudge towards open sourcing sooner, if that's okay, thanks!". :-)
>
> - Stephen
>
>
>
> On Fri, Nov 20, 2015 at 6:14 AM, Rene Hangstrup Møller <
> rhmol...@gmail.com> wrote:
>
>> Thanks for the update.
>> Looking forward to seeing what you have been cooking up.
>> Meanwhile I will revive my own generator project.
>>
>> /Rene
>>
>> Den fredag den 20. november 2015 kl. 11.05.44 UTC+1 skrev Julien
>> Dramaix:
>>>
>>> It's a bit too early to answer to th

Re: [gwt-contrib] Re: GWTCon 2015 keynote question

[David]

Good points and in most cases we are covered:
- Using a Command Processor over GWT-RPC, but I will move it to a REST
implementation.
- GUI is split up in MVP and the important code is not depending on any GWT
widgets or anything else.

We are using UiBinder in our current application, but switching to
something else is not something that I am afraid off. When I use UiBinder I
try to avoid using widgets as much as possible. So if this needs to move to
Angular or some other HTML based template mechanism, I don't expect a lot
of difficulties since it is already close to pure HTML anyway.

Abstracting behind a meta description language for the UI that part we did
not do. One of the main reasons is that you lose a lot of the performance
benefits that GWT is offering. This optimisations mattered because we
needed to support older browser (IE6/IE7).

One important component we have does this, but that one is very much tuned
for one specific task (editing financial messages defined through
XSchema's). It can not handle writing entire GUI's with rich tables, tabs,
splitter panels etc. But has some domain specific optimisations that are
not that easy to do when you need to write a complete abstraction of the UI.

We alse have dependencies on the CellTables because they offer quite good
performance and we enhanced the capabilities of those cell tables to add
missing functionality. But the CellTables are hidden behind a factory and
the interactions happens against interfaces, so the client code will not
too much impacted either.

What I am mostly afraid of with losing Element or Widget classes is that
every widget vendor will start declaring their own base classes and
interfaces for common functionality. This will make it hard to mix
components from different vendors.

Web Components are interesting, but as usual it is too soon to go down that
trail. Chrome is not the most used browser in banking and enterprise
environments and web components on IE11 is still a mess. I tried polymer
but it is way too slow to scale to large GUI's at this point.


On Sun, Nov 22, 2015 at 12:19 PM, CodeLess Solutions <
codelessoluti...@gmail.com> wrote:

> This is very good question and actually one of the biggest problem not
> only in this particular situation but also in general software development.
>
>
> Imagine you decide to build something large like ERP or Banking
> Information system for an example (with hundreds even thousands of tables
> and forms) You didn’t even finish it because of its complexity and one day
> you find out that Swing or Angular1 or Flex or “something else” come to its
> end of living and you are not able to switch easily to anything else?
>
>
> I happened to me once long time ago with some other widget library, so I
> am talking from the personal experience :-(
>
>
> I will try to explain our strategy how to solve this problem:
>
>
> We are using GWT and we are really enjoying to use it but:
>
>
> We are not using WindowBuilder (it’s not supported anymore since version
> GWT 2.6 and it’s also useless when you are creating large application
> because it’s to slow), not using UIBinder because it generates to much
> boilerplate that we do not need at all, not using Request Factory that
> generates who knows what, not using MVP… nothing that is too specific or
> bound too much for the platform. The only thing that we use and is specific
> is Code Splitting but it’s totally hidden from developers and done
> automatically for each controller. We are not using any external library to
> do this. It’s simple to implement and it would be probably easy to replace
> it with something else tomorrow. Everything is done with a single
> annotation.
>
>
> GWT-RPC may also disappear? We are using JPA classes (with Hibernate) but
> we don’t use DTOs because there is simply no need to pack and unpack
> everything. We do not write code for every document we need to save
> (create, update, delete), there is only ONE class that is doing the job via
> GWT-RPC. Exceptions are rare (less than 10%) that you have to do something
> special while persisting the document and you are able to do that as a
> custom business logic that executes in the same transaction. Current
> implementation is GWT-RPC based, but when we decide to change this, it can
> be done in a single day (probably in couple of hours) because its’ ONE
> class and not hundreds/thousands of classes that we have to change. We are
> not afraid of changes when someone decide to stop supporting GWT-RPC or
> it’s suddenly surprisingly proven that it is prone to vulnerabilities. We
> have less than 10 services to change and note that we are dealing with >650
> forms/JPA classes in this moment. All custom actions go via ONE custom
> action service, we do not create 100 services because it is used in 100
> controllers.
>
>
> About UI: We are using something that I call “meta description approach”
> for UI. Describe you fields, views and forms on technology agnostic way
> includin

Re: [gwt-contrib] I think the 2.7.0 GWT release was compiled on Daniel Kurka's machine !

[Arnaud TOURNIER]

I confirm this is absolutely not a bug, and does not have any impact on
production code...
It was more a "fun fact"...

Thanks
Arnaud

Le dim. 22 nov. 2015 17:48, Thomas Broyer  a écrit :

>
>
> On Sunday, November 22, 2015 at 4:37:17 PM UTC+1, Niels Soeffers wrote:
>>
>> Hi Daniel, Arnaud,
>>
>> Did you managed to workaround or solve the above issue?
>>
>
> Which issue? Arnaud said “There's no bug, nor problem on GWT side”
>
>
>> I am having the exact same issue. Does this mean that the gwt-user 2.7
>> jar in maven is useless?
>>
>
> I hope almost everyone's using 2.7 by now. I've been using or toying with
> those 2.7 artifacts for months and had no such problem.
>
>
>> Kind Regards,
>>
>> Niels
>>
>> On Monday, July 6, 2015 at 9:34:59 AM UTC+2, Daniel Kurka wrote:
>>>
>>> It's not my desktop machine, but you are right I did the final
>>> compilation of the release. I thought we had already killed of gwttars
>>> anyway.
>>>
>>> On Thu, Jul 2, 2015, 11:21 AM Arnaud TOURNIER  wrote:
>>>
 Hi Daniel,

 I had a closer look to the thing. The paths mentionning your home
 account in google are stored in all the gwtar files in the gwt-user-2.7.0
 artifact

 Does that really mean that the offical gwt releases are built on your
 desktop machine ?

 Thanks
 Arnaud

 Le mer. 1 juil. 2015 à 18:42, Arnaud TOURNIER  a
 écrit :

> It's a project of one of my customers which is on gwt 2.6 and needs to
> migrate to 2.7.
>
> In the cours of doing that, i got this errors...
>
> If you need, i can investigate a bit more, but seems to be coming from
> those [ERROR] java.lang.String cannot be resolved to a class...
>
> Thanks
> ARnaud
>
> Le mer. 1 juil. 2015 à 18:20, 'Daniel Kurka' via GWT Contributors <
> google-web-toolkit-contributors@googlegroups.com> a écrit :
>
>> Hi Arnaud,
>>
>> how are you producing these?
>>
>> -Daniel
>>
>> On Wed, Jul 1, 2015 at 9:06 AM Arnaud TOURNIER 
>> wrote:
>>
>>> Just dumping a bit of errors i get for a project :
>>>
>>> Tracing compile failure path for type 'java.lang.Object'
>>> [INFO]   [ERROR] Errors in 'file:
>>> */usr/local/google/home/dankurka/gwt/user/super/co*
>>> m/google/gwt/emul/java/lang/Object.java'
>>> [INFO]  [ERROR] java.lang.String cannot be resolved to a type
>>> [INFO]   [ERROR] Errors in 'file:/usr/local/google/home/
>>> *dankurka*
>>> /gwt/user/src/com/google/gwt/core/client/JavaScriptObject.java'
>>> [INFO]  [ERROR] java.lang.String cannot be resolved to a type
>>> [INFO]   [ERROR] Errors in 'file:/usr/local/google/home/
>>> *dankurka*
>>> /gwt/user/super/com/google/gwt/emul/java/lang/Throwable.java'
>>> [INFO]  [ERROR] java.lang.String cannot be resolved to a type
>>> [INFO]   [ERROR] Errors in 'file:/usr/local/google/home/
>>> *dankurka*/gwt/user/super/com/google/gwt/emul/java/lang/Class.java'
>>>
>>> There's no bug, nor problem on GWT side. I just found funny to get
>>> those kind of paths in a release artifact !!
>>>
>>> Thanks
>>>
>>> Arnaud
>>>
>>> --
>>>
>> You received this message because you are subscribed to the Google
>>> Groups "GWT Contributors" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to
>>> google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>>
>>
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/4a744841-48ca-4a75-a5e4-91ba966aea80%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> You received this message because you are subscribed to a topic in
>> the Google Groups "GWT Contributors" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/google-web-toolkit-contributors/SyRZzSQeDWg/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujiqP2rwYW9e2eqDUxL8qUA-5VKaGFbGi4bPS_-sNbGN3HA%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
 You received this message because you are subscribed to the Google
 Groups "GWT Contributors" group.
 To unsubscri