Hello, After reading the whole thread - it has gotten quite large, I would like to share some thoughts, too. ;)
Personally I regard creating something like a desktop JRE for GWT to be a suboptimal solution. From my point of view all GWT application/ projects/... already have a common base - HTML 4, CSS and JS. Every new GWT application is based on these three components. So in a certain way this can be seen as a - and I quote you - "desktop GWT JRE". Creating a common library with GWT logic that may or may not be needed by every new application sure sounds promising when thinking about filesizes and transfer time. After all this library would have to be transferred only once to the client and live on inside the browser cache for some time. BUT the code inside this "library" would not be optimized for your specific application. Moreover it would contain code for all possible browsers supporting all of their "weird interpretations". One of the strength of GWT is the compile step and the optimization of the produced code for one specific application - one specific problem. And for the next project the code will be optimized again - but maybe in a different way. So personally I can not honestly see your problem. Greetings Stefan On Dec 16, 3:31 pm, "[email protected]" <[email protected]> wrote: > I think you're still not understanding the distinction Christian, > since GWT is Java let's try to use an appropriate Java analogy rather > than .exe's... The distinction is more like whether a class is on the > environment/server classpath (even part of the JRE itself like Swing) > vs each app having a distinct copy of it. The JRE is kind of the most > obvious example - in theory, we could compile up only the relevant > bits of the JRE and deliver one hyper-optimal download for each app. > Given Java's classloading architecture, anything above the JRE level > is probably less analogous. So that's kind of the two things that I'd > like to see... > > 1) Some way to deliver a single sort of desktop "JRE" which would > include the GWT JavaScript JRE stuff + an exposed base of the whole > "WT" part which the rest of my projects can just use... Just like the > regular JRE, I'm totally willing to say "go ahead and get the whole > thing, because I only have to get it once per version no matter how > many programs I develop against it"... I can stick it on a CDN and > I'll never have to "re-get", in fact, if more people did it, most apps > would never even pay the initial cost. Even in IE6, the memory > required for that whole kit to be there once loaded is comparatively > negligible. > > 2) (ideally) Something more or less analogous to a specialized URL > classloader for this (and potentially of things like it) where I can > provide a URL to point it at some GWT lib resource, effectively > putting it on the classpath and accounted for by the compiler by not > attempting to optimize it, but merely reference. > > On Dec 16, 9:00 am, Christian Goudreau <[email protected]> > wrote: > > > > But would it be possible in the future to allow building GWT-app by > > > reusing > > > previously built "GWT-dlls" > > > It is already possible. Just build your "dll" project and export a Jar to be > > used within your ".exe". > > > On Thu, Dec 16, 2010 at 7:34 AM, yves <[email protected]> wrote: > > > Hi, > > > > Some times ago I had same kind of questions than bkardell. > > > > Actually I would reformulate it another way : I compare the problem to > > > an .exe that is using .dll files > > > > If you build a new .exe app you may reuse existing .dlls > > > > I understand that this is not possible with GWT as when you compile > > > your GWT-app, you compile the entire code in once. > > > The big advantage is the javascript optimization. > > > > But would it be possible in the future to allow building GWT-app by > > > reusing previously built "GWT-dlls" ? > > > This implies that those "GWT-dlls" have a know API-contract used by > > > the main "GWT-exe" > > > > In a distributed and disparate environment this has been solved with > > > the SOA concept using SOAP, an ESB,... with all the paylod and > > > complexity allowing the communication between the components. > > > > So I don't have in mind an ESB solution, as the environment is not > > > distributed nor disparate. > > > > But in the context of GWT, would it be nonsense (for the future of > > > course) to build new app by using pre-compiled building blocks having > > > their own life-cycle independant of each other ? > > > > Yves > > > > On 15 déc, 21:40, zixzigma <[email protected]> wrote: > > > > if you use JQuery or any other Library, > > > > there is a core JSLibrary, > > > > and third party plugins. > > > > > in a typical app/site you end up adding plugin after plugin to your > > > > site/app. > > > > > each of those plugins are developed by separate developer somewhere in > > > > the world. > > > > they might have used similar utility library, but when you use them > > > > together you have no idea. > > > > > so this problem is not a GWT related problem. > > > > > your team/company should put in a place a process regarding code- > > > > reuse. > > > > > one alternative could be to rely on only one 3rd party provider, such > > > > as Ext, > > > > you can be pretty sure that they have a common base library > > > > underneath. > > > > you might have to pay. well decisions are about tradeoff. > > > > the other alternative is assembling random plugins over the internet, > > > > developed by developers with varying degree of skills. > > > > you end up with bloated tangled JavaScript code, where plugin after > > > > plugin, > > > > contains duplicate code. this is the case with JQuery plugins. > > > > > JQuery itself is a neat library, > > > > but if you assemble random plugins you found over the internet, > > > > the problem you described also applies. > > > > > and it is not just JavaScript,in any programming language, > > > > if you rely on third-party packages/libraries, there is a good chance > > > > there might be a fair amount of duplication, > > > > resulting in larger size of file. > > > > thats why in Java World, build tools such as Maven, help manage > > > > dependencies, so you don't use more than what you need. > > > > but even then, each of the .jar in your project, might have used > > > > custom String/Math/Algorithms utility classes. > > > > > it is not a GWT problem, becareful when using external libraries. > > > > tradeoff: you get a piece of functionality out of the box VS > > > > maintainability and duplication > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "Google Web Toolkit" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]<google-web-toolkit%2Bunsubs > > > [email protected]> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/google-web-toolkit?hl=en. > > > -- > > Christian Goudreauwww.arcbees.com > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
