Re: Discussion: gwt-user.jar-like uber jar for T.Broyer's multi-module project.

[vitrums]

On Friday, April 27, 2018 at 7:38:41 PM UTC+3, Thomas Broyer wrote:
 

> - **
>>
>
> I must say I don't understand what you're talking about here (i.e. how 
> you'd use them here)
>

In context of *maven-jar-plugin* I was simply referring to something like 
e.g. 
https://maven.apache.org/plugins/maven-jar-plugin/examples/attached-jar.html
 

> - *BOM* parent to manage dependencies better. I think it also helps to 
>> keep versioning clean.
>>
>
> I'm not sure how this is related to the issue, but that can be useful to 
> the users of the libraries yes.
>

I've seen a hack for large multi-module projects. It introduced another 
bom-like parent with a dynamic list of child modules to better controll 
what has to be rebuild. Plus it allowed a "multiartifact" nature of build.

If your lib does not have one single main gwt.xml entry point but really is 
> more like a gwt-user.jar "set of libraries", then you'd probably better 
> skip the gwt:generate-module and gwt:generate-module-metadata and *put 
> all your modules in src/main/resources (and not use 
> src/main/module.gwt.xml).*
>
 
To recap. Are you suggesting to get rid of *module.gwt.xml* and related to 
it *gwt:generate-module* and *gwt:generate-module-metadata* in the build 
process, because you don't think using this pattern to be a good practice 
anymore? So I should simply get back to the roots of GWT, where I had to 
manually put *MyTextBox.gwt.xml* in the directory that is root for *client* 
folder, 
but this time under *resources *(as opposed to *src*), shouldn't I?

The real question is why you're developing my-client-lib and 
> my-client-lib-a separately if your goal is to ship them as a single 
> artifact (there can be use cases of course, but it's the exception rather 
> than the rule).
>

Because I look at *module.gwt.xml* in *my-client-lib* and simply don't 
fully understand how I can have my little widget-size modules like 
*TextBox.gwt.xml* as a part of this module, since it would go against the 
*gwt:generate-module* idiom. Therefore I'm left to think, that have to 
physically slice the project into many little modules... *That is a big 
part of the my overall confusion*. Look at *gwt-user.jar*. Googlers made it 
the way that it logically contains dozens of modules. But imagine they were 
using Maven and this archetype. Did they really have to physically keep 
them as different modules?

I noticed your note of criticism about how erroneously I use this 
archetype. Basically you imply that I should not use it to develop library 
code. But I'm not sure why it would be such a bad idea. I mean I have to 
develop it somewhere. This way I have a separate "playground" project 
dedicated to develop some components that are frequently reused in other 
projects. It's not a huge scale widget library, but still a set of shared 
interfaces, classes and resources common to more than one project. And in 
terminology of *sandbox* example I have a *gwt-app* packaged 
*sandbox-client* with Entry Point. I add dependencies to lib-packaged 
client modules like *my-client-lib* to debug and develop them. But then I 
stumbled across the "one module.gwt.xml per one Maven module" limitation 
and started to think about workarounds like *uber-jar* one. That's where 
the whole buzz came from.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Using StyleInjector with Polymer and Custom CSS Properties

[Tyler Moore]

Can't figure out how to edit posts, last line should be

Document.get().getHead().appendChild(element);

On Friday, April 27, 2018 at 1:57:01 PM UTC-4, Tyler Moore wrote:
>
>
> Made a workaround for this.
>
> Instead of using StyleInjector. I just created a wrapper class that treats 
> it like a mundane style element with loaded innerHTML from the resource:
>
> public interface CSSStuff extends ClientBundle {
>
> public static final PageCSSResources INSTANCE = GWT.create(
> PageCSSResources.class);
>
> @Source("styles.css")
> TextResource siteCss();
>
> }
>
> //...Somewhere else
> StyleElement element = Document.get().createStyleElement();
> element.setInnerHTML(CSSStuff.INSTANCE.siteCss().getText());
> Document.get().getHead().appendChild(shared.getElement());
>
> On Friday, April 27, 2018 at 10:01:11 AM UTC-4, Tyler Moore wrote:
>>
>> I use StyleInjector to inject CSS rules that work with Shadow DOM Custom 
>> Properties: https://www.polymer-project.org/2.0/docs/devguide/shadow-dom
>>
>> A snippit from the CSS I inject:
>>
>> event-action-table.event-action-list-editor {
>> --table-height: 200px;
>> a-property-with-no-double-minus-prefix: 0;
>> }
>>
>> A snippit from the custom element template:
>> 
>> vaadin-grid {
>>   width: 100%;
>>   height: var(--table-height);
>> }
>> 
>>
>>
>> However, at run time, it looks like anything that is prefixed with '--' 
>> get's ignored by the injector. In the above case, my output element style 
>> looks like:
>> event-action-table.event-action-list-editor {
>> a-property-with-no-double-minus-prefix: 0;
>> }
>>
>> Why is that?
>>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Using StyleInjector with Polymer and Custom CSS Properties

[Tyler Moore]

Made a workaround for this.

Instead of using StyleInjector. I just created a wrapper class that treats 
it like a mundane style element with loaded innerHTML from the resource:

public interface CSSStuff extends ClientBundle {

public static final PageCSSResources INSTANCE = GWT.create(PageCSSResources.
class);

@Source("styles.css")
TextResource siteCss();

}

//...Somewhere else
StyleElement element = Document.get().createStyleElement();
element.setInnerHTML(CSSStuff.INSTANCE.siteCss().getText());
Document.get().getHead().appendChild(shared.getElement());

On Friday, April 27, 2018 at 10:01:11 AM UTC-4, Tyler Moore wrote:
>
> I use StyleInjector to inject CSS rules that work with Shadow DOM Custom 
> Properties: https://www.polymer-project.org/2.0/docs/devguide/shadow-dom
>
> A snippit from the CSS I inject:
>
> event-action-table.event-action-list-editor {
> --table-height: 200px;
> a-property-with-no-double-minus-prefix: 0;
> }
>
> A snippit from the custom element template:
> 
> vaadin-grid {
>   width: 100%;
>   height: var(--table-height);
> }
> 
>
>
> However, at run time, it looks like anything that is prefixed with '--' 
> get's ignored by the injector. In the above case, my output element style 
> looks like:
> event-action-table.event-action-list-editor {
> a-property-with-no-double-minus-prefix: 0;
> }
>
> Why is that?
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Using StyleInjector with Polymer and Custom CSS Properties

[Tyler Moore]

Made a workaround for this.

Instead of using StyleInjector. I just created a wrapper class that treats 
it like a mundane style element with loaded innerHTML from the resource:

public interface CSSStuff extends ClientBundle {

public static final PageCSSResources INSTANCE = GWT.create(PageCSSResources.
class);

@Source("styles.css")
TextResource siteCss();

}

//...Somewhere else
StyleElement element = Document.get().createStyleElement();
element.setInnerHTML(CSSStuff.INSTANCE.siteCss().getText());




On Friday, April 27, 2018 at 10:01:11 AM UTC-4, Tyler Moore wrote:
>
> I use StyleInjector to inject CSS rules that work with Shadow DOM Custom 
> Properties: https://www.polymer-project.org/2.0/docs/devguide/shadow-dom
>
> A snippit from the CSS I inject:
>
> event-action-table.event-action-list-editor {
> --table-height: 200px;
> a-property-with-no-double-minus-prefix: 0;
> }
>
> A snippit from the custom element template:
> 
> vaadin-grid {
>   width: 100%;
>   height: var(--table-height);
> }
> 
>
>
> However, at run time, it looks like anything that is prefixed with '--' 
> get's ignored by the injector. In the above case, my output element style 
> looks like:
> event-action-table.event-action-list-editor {
> a-property-with-no-double-minus-prefix: 0;
> }
>
> Why is that?
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Discussion: gwt-user.jar-like uber jar for T.Broyer's multi-module project.

[Thomas Broyer]

On Friday, April 27, 2018 at 4:34:25 PM UTC+2, vitrums wrote:
>
> Any experienced developer tends to reuse existing components and organize 
> his own code to allow reusability in future whenever it is possible. 
> Division of labor further encourages a group of developers to physically 
> split a big project into modules and work independently on each part. I 
> think T.Broyer's multi-module project archetype for Maven introduces a 
> great platform enabling these features and making versioning task look 
> effortless.
>
> However I personally start to have issues with the last part, when it 
> comes to the release. Specifically, should I aggregate the build artifacts 
> into one *gwt-user.jar* kind of unit? I know it's a broad topic, and 
> there're multiple angles to look at this problem, one of which says "it's 
> not Maven way" (though I start to doubt that I applied "Maven way" concept 
> in the appropriate contex). Therefore I want to hear your advice regarding 
> this matter and avoid reinventing the wheel. If there's a sample project 
> already configured to do the similar task with grace, then I guess a link 
> to github will be sufficient.
>

First, the archetypes are all about applications, not libraries. The 
archetypes will produce one WAR with the full application, that you can 
deploy effortlessly to any servlet container.

If you're going to talk about libraries, then let's step away from the 
archetypes and concentrate on the gwt-lib packaging from the 
net.ltgt.gwt.maven:gwt-maven-plugin (as that's what you're talking about).
 

> Imagine you're developing *gwt-user*. Inside *com\google\gwt\user* folder 
> you'll find *client *direcotry and a bunch of *.gwt.xml* files 
> such as *User.gwt.xml, UI.gwt.xml, TextBox.gwt.xml.* The latter contains 
> a bunch of deferred binding instructions, e.g.:
>
>   
>   
> 
> 
>   
>
> *User* inherits *UI *and *UI *inherits *TextBox*. But then we also have a 
> subfolder *datepicker *with *DatePicker.gwt.xml* and it's own *client*
>  directory.
>
> So my view on this is that you don't wanna ship *datepicker.jar* to your 
> clients, but instead combine the components from all related projects and 
> modules into one library.
>
>
> 
>
> Further in the text I'm gonna present my hack to multi-module archetype 
> build configuration based on *maven-shade-plugin*, so let's get into 
> details.
>
> There were three strong candidates to do this job: *maven-jar-plugin, *
> *maven-assembly-plugin* and *maven-shade-plugin*. However the latter was 
> specifically made for:
> - This plugin provides the capability to package the artifact in an 
> *uber-jar*, including its dependencies and to shade - i.e. rename - the 
> packages of some of the dependencies.
> - The Shade Plugin has a single goal: *shade:shade *is bound to the *package 
> *phase and is used to create a shaded jar.
>
> In multi-module structure of my *sandbox *project I have two *gwt-lib* 
> packaged 
> modules *my-client-lib* and *my-client-lib-a*. The task is to gather 
> their build artifacts inside one jar. My solution was to create 
> a subsidiary *module* *sandbox-gwt* (though it could as well be another 
> *project*) with the same groupId as *my-client-lib** and to include only 
> such artifacts in the uber-jar. Making it this way automates the task of 
> naming by exploiting ${project.groupId} and ${project.version} properties.
>

The real question is why you're developing my-client-lib and 
my-client-lib-a separately if your goal is to ship them as a single 
artifact (there can be use cases of course, but it's the exception rather 
than the rule).
If your lib does not have one single main gwt.xml entry point but really is 
more like a gwt-user.jar "set of libraries", then you'd probably better 
skip the gwt:generate-module and gwt:generate-module-metadata and put all 
your modules in src/main/resources (and not use src/main/module.gwt.xml).

But maybe please consider the future where J2Cl in GWT3 will transpile all 
source files from JARs, without any kind of filtering. You'd better have 
many small jars then, than a bigger jar containing several libs users won't 
necessarily all use.
 

> But there's a set of techniques mentioned in different sources, which 
> might do the task better?! Those include the use of:
> - **
>

Don't use profiles, that's not what they're made 
for: 
https://www.cloudbees.com/blog/maven-profiles-and-%E2%80%9C-maven-way%E2%80%9D
 

> - **
>

I must say I don't understand what you're talking about here (i.e. how 
you'd use them here)
 

> - *BOM* parent to manage dependencies better. I think it also helps to 
> keep versioning clean.
>

I'm not sure how this is related to the issue, but that can be useful to 
the users of the libraries yes.
 

>
>
> 

Discussion: gwt-user.jar-like uber jar for T.Broyer's multi-module project.

[vitrums]

Any experienced developer tends to reuse existing components and organize 
his own code to allow reusability in future whenever it is possible. 
Division of labor further encourages a group of developers to physically 
split a big project into modules and work independently on each part. I 
think T.Broyer's multi-module project archetype for Maven introduces a 
great platform enabling these features and making versioning task look 
effortless.

However I personally start to have issues with the last part, when it comes 
to the release. Specifically, should I aggregate the build artifacts into 
one *gwt-user.jar* kind of unit? I know it's a broad topic, and there're 
multiple angles to look at this problem, one of which says "it's not Maven 
way" (though I start to doubt that I applied "Maven way" concept in the 
appropriate contex). Therefore I want to hear your advice regarding this 
matter and avoid reinventing the wheel. If there's a sample project already 
configured to do the similar task with grace, then I guess a link to github 
will be sufficient.

Imagine you're developing *gwt-user*. Inside *com\google\gwt\user* folder 
you'll find *client *direcotry and a bunch of *.gwt.xml* files such 
as *User.gwt.xml, UI.gwt.xml, TextBox.gwt.xml.* The latter contains a bunch 
of deferred binding instructions, e.g.:

  
  


  

*User* inherits *UI *and *UI *inherits *TextBox*. But then we also have a 
subfolder *datepicker *with *DatePicker.gwt.xml* and it's own *client*
 directory.

So my view on this is that you don't wanna ship *datepicker.jar* to your 
clients, but instead combine the components from all related projects and 
modules into one library.



Further in the text I'm gonna present my hack to multi-module archetype 
build configuration based on *maven-shade-plugin*, so let's get into 
details.

There were three strong candidates to do this job: *maven-jar-plugin, *
*maven-assembly-plugin* and *maven-shade-plugin*. However the latter was 
specifically made for:
- This plugin provides the capability to package the artifact in an 
*uber-jar*, including its dependencies and to shade - i.e. rename - the 
packages of some of the dependencies.
- The Shade Plugin has a single goal: *shade:shade *is bound to the *package 
*phase and is used to create a shaded jar.

In multi-module structure of my *sandbox *project I have two *gwt-lib* packaged 
modules *my-client-lib* and *my-client-lib-a*. The task is to gather their 
build artifacts inside one jar. My solution was to create a subsidiary 
*module* *sandbox-gwt* (though it could as well be another *project*) with 
the same groupId as *my-client-lib** and to include only such artifacts in 
the uber-jar. Making it this way automates the task of naming by exploiting 
${project.groupId} and ${project.version} properties.

*pom.xml* of *sandbox-gwt *module*:*

http://maven.apache.org/POM/4.0.0;
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
 4.0.0
 
   com.example.project
   sandbox
   0.0.1-SNAPSHOT
 
 net.coolcode.gwt
 sandbox-gwt

 
   
 ${project.groupId}
 my-client-lib
 ${project.version}
   
   
 ${project.groupId}
 my-client-lib-a
 ${project.version}
   
 

 
   
 
   org.apache.maven.plugins
   maven-shade-plugin
   3.1.1
   
 
   
 ${project.groupId}
   
 
 true
   
   
 
   package
   
 shade
   
 
   
 
   
 


*artifactSet* - Artifacts to include/exclude from the final artifact. 
Artifacts are denoted by composite identifiers of the general form 
*groupId:artifactId:type:classifier*.

But there's a set of techniques mentioned in different sources, which might 
do the task better?! Those include the use of:
- **
- **
- *BOM* parent to manage dependencies better. I think it also helps to keep 
versioning clean.



I also noticed, that *gwt-maven-plugin* can generate some code in <
*actual-module-name>.gwt.xml*, such as adding



In the context of a large uber-jar such as *gwt-user.jar* if it could 
establish the crossreferencing between modules based only on Maven 
dependencies, that would be interesting. E.g. to put 



inside *MyCoolCodeApp.gwt.xml*, if *my-client-lib* depends on 
*my-client-lib-a*.



Lastly I'm curious, in a context of development of *gwt-user* project it 
seems that due to an unconventional for GWT applications module structure (
*src/main/module.gwt.xml* not 

Using StyleInjector with Polymer and Custom CSS Properties

[Tyler Moore]

I use StyleInjector to inject CSS rules that work with Shadow DOM Custom 
Properties: https://www.polymer-project.org/2.0/docs/devguide/shadow-dom

A snippit from the CSS I inject:

event-action-table.event-action-list-editor {
--table-height: 200px;
a-property-with-no-double-minus-prefix: 0;
}

A snippit from the custom element template:

vaadin-grid {
  width: 100%;
  height: var(--table-height);
}



However, at run time, it looks like anything that is prefixed with '--' 
get's ignored by the injector. In the above case, my output element style 
looks like:
event-action-table.event-action-list-editor {
a-property-with-no-double-minus-prefix: 0;
}

Why is that?

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Documentation: incorrect mixing of Dev Mode and SuperDev Mode in 'Overview' article

[Jens]

Yeah you are right, the GWT site needs a little love here and there. It is 
a community effort to keep it up to date. The GWT site is available on 
Github and accepts pull requests (requires a CLA though) so you could 
invest some time to improve it.

-- J.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Docs on debugging

[Jens]

Out of date. GWT site is a community effort and it is not uncommon that 
some documentation has become outdated over time. But that also means you 
could start working on an update and make a pull request on github ;-)

-- J.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Docs on debugging

[Blake McBride]

Greetings,

The GWT site has a doc on debugging at
http://www.gwtproject.org/doc/latest/DevGuideCompilingAndDebugging.html

It mainly talks about Development Mode but has (what amounts to) a footnote
on Super Dev Mode.  Am I mistaken, or is this way out-of-date?
(Development Mode basically doesn't work at all anymore and we must use
Super Dev Mode.)

Thanks.

Blake McBride

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Documentation: incorrect mixing of Dev Mode and SuperDev Mode in 'Overview' article

[Георгий Савчук]

Hello, GWT Team!

I would like to address the incorrect mixing of Dev Mode and SuperDev Mode 
in 'Overview' article:
"You can debug AJAX applications in your favorite IDE just like you would a 
desktop application, and in your favorite browser just like you would if 
you were coding JavaScript. The GWT developer plugin spans the gap between 
Java bytecode in the debugger and the browser’s JavaScript.

Thanks to the GWT developer plugin, there’s no compiling of code to 
JavaScript to view it in the browser. You can use the same 
edit-refresh-view cycle you’re used to with JavaScript, while at the same 
time inspect variables, set breakpoints, and utilize all the other debugger 
tools available to you with Java. And because GWT’s development mode is now 
in the browser itself, you can use tools like Firebug and Inspector as you 
code in Java."

It's not clear that developer can use one option or another, not both at 
the same time. When someones read "utilize all the other debugger tools 
available to you with Java", he starts thinking about his Java IDE, but 
then immediately he reads "And because GWT’s development mode is now in the 
browser itself, you can use tools like Firebug and Inspector" - he becomes 
confused, how is that possible to set breakpoints in both Java IDE and in 
Firebug? The same thing about "like you would a desktop application, and in 
your favorite browser", instead "and" its better to say "or", and specify 
exactly that these are two different approaches to debug the app.

Also, which is more important, in Docs -> Coding Basics -> Compile And 
Debugging, entire article is dedicated to obsolete Dev Mode, and only a 
single sentence saying "Early adopters may wish to try out an alternative 
to Development Mode. See Introducing Super Dev Mode 
". That's very 
confusing for first time users of GWT, because they spend time read entire 
article and at the end it is revealed that this approach is obsolete and 
they have to consider SuperDev Mode. Moreover, Dev Mode is even disabled by 
default when they try any new GWT 2.8 project from scratch, so they will 
read the article, try it locally - and it won't give expected results.

In my opinion it's better to entirely cut off Dev Mode related phrases in 
these two sections and move it to a separate article for GWT users with 
versions <2.5. Also, Docs -> Coding Basics -> Compile And Debugging article 
should be entirely rewritten to include the information from "Introducing 
Super Dev Mode " 
article instead.

Thanks, Georgiy

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.