After looking at the GPE bootstrapping for DevMode, I think I found a good 
way to start the CodeServer, which means two launch configs go when dev 
mode is started. Then I could sync up the launch configs in case more than 
one, or persist one and not the other. At anyrate there are some options 
with out having to worry about accidentally stopping one and not the other. 
My demo used CodeServer as the main type although it creates more waves in 
changes, and I suspect I could change the main types around, DevMode being 
main and this would cause less changes. I think I could have this worked up 
in a couple of half days and get back with a demo, screencast for thoughts. 
This would mean I could have all the steps wrapped up shortly and it would 
work seamlessly for a 2.5.1+.

Eclipse Goals

   1. no precompile flag on 
   2. create a no cache file, with just dev mode, that code server 
   initializes 
   3. start the code server, which starts the servlet container, dev mode, 
   -server flag 
   4. remove code server flag


   - clean compile - generates clean no cache with sum logic 
   - start sdm 
   - start servlet container 
   - start browser 
   - dev mode on 



On Tuesday, July 1, 2014 1:07:48 PM UTC-7, Brandon Donnelson wrote:
>
> After looking at it a bit more, I think it would be nice to add in a 
> -server argument like DevMode has to the change, but that looks like it 
> also needs a couple other args like -war. Having the -server arg would 
> allow for another server type to launch other than the embedded jetty, and 
> maybe its a matter of providing a separate jetty launcher like appengines 
> so none of the jetty code is in the main type class that provides the GWT 
> logic. This way it extracts the responsibility and decouples jetty as a 
> dependency b/c folks use tomcat, jboss, vaadin, or other backend platform. 
> Thoughts?
>
> On Tuesday, July 1, 2014 12:19:03 PM UTC-7, Brian Slesinsky wrote:
>>
>> I don't understand the details enough to make an informed recommendation, 
>> but I think introducing a new entry point is a good time to transition to 
>> the standard way (assuming it is standard).
>>
>> We could add the backward-compatibility flag if needed after some testing 
>> to see what the breakage would be.
>>
>> - Brian
>>
>> On Tue, Jul 1, 2014 at 6:36 AM, Manuel Carrasco Moñino <[email protected]
>> > wrote:
>>
>>> Following the discussion here: 
>>> https://gwt-review.googlesource.com/#/c/8150/2
>>>
>>> What do you guys think about changing the way of how embedded jetty 
>>> class loader works?
>>>
>>> Options:
>>> - leave it as current: a bunch of hacks to load certain classes at first
>>> - modify it to use the standard way: first WEB-INF/lib  then classpath
>>> - a mix of both, so as the default is #2 but we maintain a flag for 
>>> using #1
>>> - more... ? 
>>>
>>>
>>>
>>>  -- 
>>> 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 [email protected]
>>> .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAtaxEabPDFt-2CEFR154GOHcBYMj47BQOVXHUfqvbyGBw%40mail.gmail.com
>>>  
>>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAtaxEabPDFt-2CEFR154GOHcBYMj47BQOVXHUfqvbyGBw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>> 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 unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/ae294613-6514-4f1a-a202-cc001dd32425%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to