On Tue, Nov 11, 2008 at 11:34 AM, BobV <[EMAIL PROTECTED]> wrote: > Here's a strawman proposal for handling different types of > EmittedArtifacts in the Linker API and how that would interact with a > WAR output format.
Cool. First, it's great to have a list of the categories of output. There seem to not be very many. The following names seem straightforward to me: browser (not listed): things that need to be served out to the browser server (listed as "context"): things needed on the server, but not being sent out extra: other stuff, such as SOYC output and log files One big question: why a separate packer step? My naive understanding is that the point of a linker is to decide where the various bits of compiler output will go on disk. Is there a reason to discontinue that? It sounds possibly quite confusing to have both packers and linkers that the user must choose. With a linker-only strategy, wouldn't all we need to do would be: 1. Update the artifacts to match the new categories. 2. Update the linkers to deal with these. Someone wanting a non-war deployment would have to either pick out the pieces from one of the standard linkers, or write their own linker. Both seem pretty easy. Lex --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
