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.
