[Engine-devel] if there is a updated debug environment how to?
Alon Bar-Lev
alonbl at redhat.com
Tue Jun 18 14:56:49 UTC 2013
----- Original Message -----
> From: "Vojtech Szocs" <vszocs at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: awels at redhat.com, engine-devel at ovirt.org
> Sent: Tuesday, June 18, 2013 4:16:25 PM
> Subject: Re: [Engine-devel] if there is a updated debug environment how to?
>
>
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "Vojtech Szocs" <vszocs at redhat.com>
> > Cc: awels at redhat.com, engine-devel at ovirt.org
> > Sent: Tuesday, June 18, 2013 1:32:52 PM
> > Subject: Re: [Engine-devel] if there is a updated debug environment how to?
> >
> >
> >
> > ----- Original Message -----
> > > From: "Vojtech Szocs" <vszocs at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: awels at redhat.com, engine-devel at ovirt.org
> > > Sent: Tuesday, June 18, 2013 2:01:01 PM
> > > Subject: Re: [Engine-devel] if there is a updated debug environment how
> > > to?
> > >
> > > Hi Alon,
> > >
> > > revisiting this thread, I have some comments regarding GWT debugging via
> > > standard development environment, as described in README.developer.
> >
> > Thank you for your comments!
> > As the file is within git, you can submit a patch... :)
> > I will create one for the following comments.
>
> Thanks! I +2'ed your patch [http://gerrit.ovirt.org/#/c/15827/]
>
> >
> > > - README.developer says:
> > > For example, if your machine is low on memory, use:
> > > EXTRA_BUILD_FLAGS_DEV="-Dgwt-plugin.localWorkers=2"
> > > however this should be:
> > > For example, if your machine is low on memory, use:
> > > EXTRA_BUILD_FLAGS_DEV="-Dgwt.compiler.localWorkers=2"
> >
> > Fixed.
> >
> > >
> > > - README.developer says:
> > > By default, only the gecko1_8 support is built
> > > I'd rather explain what this means:
> > > By default, only the gecko1_8 (Mozilla Firefox) support is built
> >
> > Fixed.
> >
> > > - what's the point of having EXTRA_BUILD_FLAGS_DEV_GWT vs.
> > > EXTRA_BUILD_FLAGS_DEV ?
> >
> > I wanted to allow customization of GWT as standalone as it require more
> > flags
> > and defaults.
> >
> > So I can put the following with a default for gwt while allowing
> > application
> > customization.
> >
> > For example if I have:
> > EXTRA_BUILD_FLAGS_DEV_GWT:=-D gwt.userAgent=gecko1_8
> >
> > and execute:
> > $ make EXTRA_BUILD_FLAGS_DEV="-DskipTests"
> >
> > I do not override the GWT settings.
>
> I see, so developer should only use EXTRA_BUILD_FLAGS_DEV to provide any
> additional settings (or override existing settings), i.e. both GWT and
> non-GWT settings can be customized via EXTRA_BUILD_FLAGS_DEV.
>
> If I understand correctly, EXTRA_BUILD_FLAGS_DEV_GWT is used internally for:
> - setting default target browser to Firefox (only)
Right.
> - enabling draft compile (if DEV_BUILD_GWT_DRAFT == 1)
I am going to change that[1]
[1] http://gerrit.ovirt.org/#/c/15736/
> We can consider renaming EXTRA_BUILD_FLAGS_DEV_GWT ->
> EXTRA_BUILD_FLAGS_DEV_GWT_DEFAULTS.
OK, will do.
> But in any case, I suggest to apply
> EXTRA_BUILD_FLAGS_DEV_GWT *before* EXTRA_BUILD_FLAGS_DEV (instead of the
> opposite like today). This way, EXTRA_BUILD_FLAGS_DEV can be used to
> override any settings set by EXTRA_BUILD_FLAGS_DEV_GWT.
>
> For example:
>
> $(MVN) \
> $(EXTRA_BUILD_FLAGS_DEV_GWT) \ --> GWT-specific defaults
> $(EXTRA_BUILD_FLAGS_DEV) \ --> generic overrides (both GWT and
> non-GWT)
> ...
>
> install \
> EXTRA_BUILD_FLAGS="$(EXTRA_BUILD_FLAGS_DEV_GWT)
> $(EXTRA_BUILD_FLAGS_DEV)" \ --> this one is OK
>
> Let me know what you think about this.
Good for me.
>
> >
> > BTW: there is a pending patch to rename this to DEV_XXXX[1] to be more
> > consistent.
> >
> > [1] http://gerrit.ovirt.org/#/c/15735/
>
> +1'ed this patch.
>
> >
> >
> > > if EXTRA_BUILD_FLAGS_DEV_GWT is meant to control target browser(s) then
> > > it
> > > should be renamed appropriately
> >
> > Any flags, including debug port and such. But I am opened to suggestions...
> > what do you expect it to be named?
> >
> > > if EXTRA_BUILD_FLAGS_DEV_GWT is meant to group all GWT-specific flags,
> > > README.developer shouldn't advise to do
> > > EXTRA_BUILD_FLAGS_DEV="-Dgwt..."
> >
> > But then I lose the gwt settings.
>
> Right, please see my suggestion above.
>
> >
> > > - Makefile gwt-debug target looks OK to me
> > >
> > > > What I do expect is that the debugger not to require a specific
> > > > relation
> > > > with
> > > > specific application (Webadmin, userportal).
> > >
> > > gwt-maven-plugin must be invoked in context of a specific Maven module
> > > representing GWT application you want to debug. In other words, you need
> > > to
> > > start GWT Development Mode for specific application module. This is why
> > > you
> > > need to "cd" to specific directory (webadmin/userportal-gwtp) before
> > > invoking "mvn ... gwt:debug" command.
> > >
> > > You cannot start GWT Development Mode in a generic (application-agnostic)
> > > way
> > > and *then* connect to it from browser and Java IDE, this is not how GWT
> > > Development Mode is meant to be used. JBoss remote socket debugging and
> > > GWT
> > > application debugging are two different things.
> >
> > Well, I do expect this to be a feature of top level pom.xml...
> >
> > something like:
> > $ mvn -Pgwt-debug -Ddebug.module=webadmin
> >
> > so that the profile will do whatever necessary to activate the debugger.
>
> This would be problematic because when you invoke Maven on root pom, Maven
> only sees root pom classpath/artifacts, and we need Maven/GWT-Plugin to see
> application-specific classpath/artifacts.
>
> I'm not saying this is impossible, I'm just saying it will be much harder to
> do than just "cd" to webadmin/userportal-gwtp directory and invoking Maven
> there.. We could introduce new flags like DEBUG_GWT_WEBADMIN [0/1] which
> would take care of providing correct settings to gwt-maven-plugin, not sure
> if it's really worth it, because we already have DEBUG_MODULE and Makefile
> internally cd's to it.
OK, this issue is not that important now... :)
>
> >
> > > > The fact that maven is used to start the debugger is not important.
> > >
> > > gwt-maven-plugin is just a wrapper to invoke GWT Development Mode (Java
> > > class). Regardless of how you start GWT Development Mode, you need to
> > > specify which application (more precisely, GWT modules) you want to debug
> > > right when starting GWT Development Mode. See [1] - "module(s)" are
> > > always
> > > specific for given application.
> >
> > So basically what you saying is that you cannot debug two modules at one
> > time...
> > It is strange... but as long as you fine with it, we are OK.
>
> Yes, basically you need to specify all "modules" that make up for one
> application at time when you start GWT Development Mode. So GWT Development
> Mode, once started, is tied to specific application.
>
> >
> > >
> > > [1]
> > > https://developers.google.com/web-toolkit/doc/latest/DevGuideCompilingAndDebugging#DevGuideCompilerOptions
> > >
> > > > If I add "-P gwtdev" to default build using install-dev, all gwt
> > > > applications
> > > > should be built and installed using the extra debugging information,
> > > > using:
> > >
> > > Yes, as described in [2], besides using "gwtdev" profile for debugging,
> > > it
> > > can also be used for GWT compilation (i.e. "make install-dev") - in this
> > > case, resulting JavaScript will be un-obfuscated and not-too-optimized in
> > > order to easily profile the JavaScript application in the browser. In
> > > other
> > > words, using "gwtdev" for GWT compilation has nothing to do with
> > > debugging,
> > > maybe we should create separate profile for this purpose.
> >
> > That's good.
>
> OK, I'll make a patch to introduce "gwtdraft" profile with following effects
> once activated (via -Pgwtdraft):
> - set draftCompile to true -> prevent JavaScript code optimizations
> - set style to DETAILED -> produce pretty JavaScript without obfuscation
>
> After this, I suggest to modify Makefile so that DEV_BUILD_GWT_DRAFT=1
> activates "gwtdraft" profile, instead of just doing -Dgwt.draftCompile=true
>
> >
> > > [2]
> > > http://www.ovirt.org/DebugFrontend#Compiling_Frontend_applications_in_detailed_mode
> > >
> > > PS: I'll update http://www.ovirt.org/DebugFrontend with regard to
> > > standard
> > > development environment, as described in README.developer
> > >
> > > Vojtech
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > To: awels at redhat.com
> > > > Cc: engine-devel at ovirt.org
> > > > Sent: Friday, June 7, 2013 10:07:40 PM
> > > > Subject: Re: [Engine-devel] if there is a updated debug environment how
> > > > to?
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > > From: "Alexander Wels" <awels at redhat.com>
> > > > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > > Cc: engine-devel at ovirt.org, "bigclouds" <bigclouds at 163.com>
> > > > > Sent: Friday, June 7, 2013 10:56:40 PM
> > > > > Subject: Re: [Engine-devel] if there is a updated debug environment
> > > > > how
> > > > > to?
> > > > >
> > > > > > > > So if I understand correctly, the following is sequence is
> > > > > > > > required:
> > > > > > > >
> > > > > > > > Build and deploy code:
> > > > > > > > $ make install-dev PREFIX="${HOME}/ovirt-engine"
> > > > > > > > $
> > > > > > > > "${HOME}/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py"
> > > > > > > > start
> > > > > > >
> > > > > > > You missed this part:
> > > > > > > 1. cd into the source code directory of either webadmin or user
> > > > > > > portal.
> > > > > > > you have to change directory to either
> > > > > > > frontend/webadmin/modules/webadmin
> > > > > > > or frontend/webadmin/modules/userportal-gwtp
> > > > > > >
> > > > > > > As the maven gwt plugin is only defined in the webadmin and
> > > > > > > userportal
> > > > > > > poms
> > > > > > > and
> > > > > > > not in the root pom.
> > > > > >
> > > > >
> > > > > It doesn't make much sense to put the gwt plugin in the root pom, as
> > > > > the
> > > > > root
> > > > > pom has nothing to do with GWT. The plugin exists in userportal and
> > > > > webadmin
> > > > > as those are GWT modules. The debugger is specifically a GWT
> > > > > debugger,
> > > > > you
> > > > > can't debug anything else with it.
> > > >
> > > > You perceive this as something of gwt project, while I perceive this
> > > > part
> > > > of
> > > > the environment.
> > > >
> > > > What I expect it to allow as simple development environment as we can.
> > > > Just like I enable the debug port of jboss automatically I would like
> > > > to
> > > > enable gwt debug.
> > > >
> > > > If I add "-P gwtdev" to default build using install-dev, all gwt
> > > > applications
> > > > should be built and installed using the extra debugging information,
> > > > using:
> > > >
> > > > $ make install-dev PREFIX="${HOME}/ovirt-engine"
> > > >
> > > > I can even add GWT_DEBUGGER=1 to optionally enable/disable this
> > > > feature.
> > > >
> > > > Now, after starting ovirt-engine service, all I expect is a simple
> > > > command
> > > > to
> > > > start the gwt debugger.
> > > >
> > > > $ make gwt-debugger
> > > > or:
> > > > ./gwt-debugger
> > > >
> > > > The fact that maven is used to start the debugger is not important.
> > > >
> > > > What I do expect is that the debugger not to require a specific
> > > > relation
> > > > with
> > > > specific application (Webadmin, userportal).
> > > >
> > > > I would have understood if I had to execute something like the
> > > > following
> > > > to
> > > > run the debugger:
> > > >
> > > > $ cd frontend
> > > > $ mvn gwt:debug -Dgwt.noserver=true
> > > >
> > > > Or better to avoid building anything:
> > > >
> > > > $ cd frontend/debugger
> > > > $ mvn gwt:debug -Dgwt.noserver=true
> > > >
> > > > But I do not understand why a cd to specific application is required.
> > > >
> > > > Thanks!
> > > > Alon
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >
> > >
> >
>
More information about the Devel
mailing list