[gwt-contrib] Transform GWT tools SVN in a Maven dependency
Hello All, I'm playing with the src of GWT in these days to try out some hack, using Maven, and while doing this I needed the GWT-Tools dependencies. I've searched the dependencies in Maven Central Repo: http://search.maven.org/ but because some jar is rebased with JarJar, I've used maven-shade-plugin to rebase in the same way the dependencies I needed. So, I came out with a "PoC" that proves it is possible to build (a subset of) GWT-Dev using dependencies based and rebased on maven. As the actual way to manage the gwt-tools seems to be an "throw all in the bucket" approach, with folders like Guava that includes 5 different versions: Handwritten:gwt-tools cristcost$ ll lib/guava/: total 0 drwxr-xr-x 7 cristcost staff 238 2 Nov 2013 guava-10.0.1 drwxr-xr-x 5 cristcost staff 170 2 Nov 2013 guava-15.0 drwxr-xr-x 5 cristcost staff 170 30 Giu 09:51 guava-16.0.1 drwxr-xr-x 6 cristcost staff 204 30 Giu 09:51 guava-18.0 drwxr-xr-x 10 cristcost staff 340 2 Nov 2013 guava-r06 Wouldn't it make sense to define a maven project what represents the required libs and try to get rid of gwt-tools folder for the build? In this way, retrieving the dependencies to build with ant could be done easily with the command: mvn dependency:copy-dependencies (and the project dependencies are downloaded into target/dependecies) In a new message I'll share a synthesis with significant excerpt of pom.xml configuration required to make the PoC to work. Cristiano -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/d0792b09-b467-4d8f-936e-220bb0063422%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: Transform GWT tools SVN in a Maven dependency
I have created 2 maven projects:
1. gwt-tools-rebased
2. gwt-tools
The first project declares these dependencies:
com.google.guava
guava
18.0
com.google.javascript
closure-compiler
v20150901
and rebases them with maven-shade-plugin:
org.apache.maven.plugins
maven-shade-plugin
2.4.1
package
shade
com.google.javascript.jscomp
com.google.gwt.thirdparty.javascript.jscomp
com.google.javascript.rhino
com.google.gwt.thirdparty.javascript.rhino
com.google.debugging.sourcemap
com.google.gwt.thirdparty.debugging.sourcemap
com.google.common
com.google.gwt.thirdparty.guava.common
The second project declares these dependencies:
net.cristcost
gwt-tools-rebased
${project.version}
org.apache.ant
ant
1.7.1
org.ow2.asm
asm
5.0.3
colt
colt
1.2.0
xerces
xercesImpl
2.11.0
org.eclipse.tycho
org.eclipse.jdt.core
3.11.0.v20150520-2033
The execution of the mvn dependency:copy-dependencies command has this
console output:
Handwritten:gwt-tools cristcost$ mvn dependency:copy-dependencies
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building GWT Tools as Maven dependencies test 1.0.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-dependency-plugin:2.8:copy-dependencies (default-cli) @
gwt-tools ---
[INFO] Copying concurrent-1.3.4.jar to
/Users/cristcost/dev/cristcost/test/gwt-tools/target/dependency/concurrent-1.3.4.jar
[INFO] Copying asm-5.0.3.jar to
/Users/cristcost/dev/cristcost/test/gwt-tools/target/dependency/asm-5.0.3.jar
[INFO] Copying org.eclipse.jdt.core-3.11.0.v20150520-2033.jar to
/Users/cristcost/dev/cristcost/test/gwt-tools/target/dependency/org.eclipse.jdt.core-3.11.0.v20150520-2033.jar
[INFO] Copying colt-1.2.0.jar to
/Users/cristcost/dev/cristcost/test/gwt-tools/target/dependency/colt-1.2.0.jar
[INFO] Copying gwt-tools-rebased-1.0.0-SNAPSHOT.jar to
/Users/cristcost/dev/cristcost/test/gwt-tools/target/dependency/gwt-tools-rebased-1.0.0-SNAPSHOT.jar
[INFO] Copying xercesImpl-2.11.0.jar to
/Users/cristcost/dev/cristcost/test/gwt-tools/target/dependency/xercesImpl-2.11.0.jar
[INFO] Copying xml-apis-1.4.01.jar to
/Users/cristcost/dev/cristcost/test/gwt-tools/target/dependency/xml-apis-1.4.01.jar
[INFO] Copying ant-1.7.1.jar to
/Users/cristcost/dev/cristcost/test/gwt-tools/target/dependency/ant-1.7.1.jar
[INFO] Copying ant-launcher-1.7.1.jar to
/Users/cristcost/dev/cristcost/test/gwt-tools/target/dependency/ant-launcher-1.7.1.jar
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1.119 s
[INFO] Finished at: 2015-10-14T08:42:18+02:00
[INFO] Final Memory: 16M/309M
[INFO]
and produces this contents:
Handwritten:gwt-tools cristcost$ ll target/dependency/
total 31552
-rw-r--r-- 1 cristcost staff 1323005 14 Ott 08:42 ant-1.7.1.jar
-rw-r--r-- 1 cristcost staff12143 14 Ott 08:42 ant-launcher-1.7.1.jar
-rw-r--r-- 1 cristcost staff53231 14 Ott 08:42 asm-5.0.3.jar
-rw-r--r-- 1 cristcost staff 581945 14 Ott 08:42 colt-1.2.0.jar
-rw-r--r-- 1 cristcost staff 189284 14 Ott 08:42 concurrent-1.3.4.jar
-rw-r--r-- 1 cristcost staff 6678108 14 Ott 08:42
gwt-tools-rebased-1.0.0-SNAPSHOT.jar
-rw-r--r-- 1 cristcost staff 5716475 14 Ott 08:42
org.eclipse.jdt.core-3.11.0.v20150520-2033.jar
-rw-r--r-- 1 cristcost staff 1367760 14 Ott 08:42 xercesImpl-2.11.0.jar
-rw-r--r-- 1 cristcost staff 220536 14 Ott 08:42 xml-apis-1.4.01.jar
Handwritten:gwt-tools cristcost$
I hope this is inspiring and helpful
Cristiano
--
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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/417dbe05-b5c7-4ae8-8028-e3ab3c62571b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] is gwt-codeserver.jar artifact useless ?
Hello all,
I was asking myself when I should use the gwt-codeserver.jar
I'm not including it into my project but I can run Super Dev Mode anyway,
so I've checked the content of the gwt-codeserver.jar to see what it does
provide that is not provided by gwt-dev:
Handwritten:gwt-0.0.0 cristcost$ pwd
/Users/cristcost/dev/Open-Source/gwt-trunk/build/staging/gwt-0.0.0
Handwritten:gwt-0.0.0 cristcost$ *unzip -l gwt-codeserver.jar*
Archive: gwt-codeserver.jar
Length Date TimeName
0 10-05-15 10:39 META-INF/
157 10-05-15 10:39 META-INF/MANIFEST.MF
0 10-05-15 10:39 com/
0 10-05-15 10:39 com/google/
0 10-05-15 10:39 com/google/gwt/
0 10-05-15 10:39 com/google/gwt/dev/
0 10-05-15 10:39 *com/google/gwt/dev/codeserver*/
8425 10-05-15 10:39 *com/google/gwt/dev/codeserver/*CodeServer.class
*[...omissis...]*
2492 06-30-15 09:52 *com/google/gwt/dev/codeserver*/stub.nocache.js
122 10-05-15 10:39 META-INF/INDEX.LIST
---
509150 122 files
Handwritten:gwt-0.0.0 cristcost$
everything is inside the folder *com/google/gwt/dev/codeserver* , ok, let's
compare with dev:
Handwritten:gwt-0.0.0 cristcost$ unzip -l *gwt-dev.jar*
com/google/gwt/dev/codeserver/*
Archive: gwt-dev.jar
Length Date TimeName
0 10-05-15 10:39 com/google/gwt/dev/codeserver/
8425 10-05-15 10:39 com/google/gwt/dev/codeserver/CodeServer.class
*[...omissis...]*
2492 06-30-15 09:52 com/google/gwt/dev/codeserver/stub.nocache.js
---
*508871* *115 files*
Handwritten:gwt-0.0.0 cristcost$
and now let's filter more with more precision gwt-codeserver.jar to compare
the differences:
Handwritten:gwt-0.0.0 cristcost$ unzip -l *gwt-codeserver.jar*
com/google/gwt/dev/codeserver/*
Archive: gwt-codeserver.jar
Length Date TimeName
0 10-05-15 10:39 com/google/gwt/dev/codeserver/
8425 10-05-15 10:39 com/google/gwt/dev/codeserver/CodeServer.class
*[...omissis...]*
2492 06-30-15 09:52 com/google/gwt/dev/codeserver/stub.nocache.js
---
*508871* *115 files*
Handwritten:gwt-0.0.0 cristcost$
same number of files, same size, so gwt-codeserver.jar I think this is not
coincidence and then codeserver is completely included in gwt-dev.
So, is useless?
What is the purpose of it?
thanks,
Cristiano
--
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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/d3f919c1-cd7e-44b7-8c90-5918bef18284%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: is gwt-codeserver.jar artifact useless ?
Ok, thank you for the feedback! Il giorno giovedì 8 ottobre 2015 10:31:50 UTC+2, Thomas Broyer ha scritto: > > Oh my, I totally missed this: > https://gwt-review.googlesource.com/#/q/Iaef14e17716e0f4784a466361db13930f887c996 > > (forgot actually, as I apparently commented on it) > So yes, gwt-codeserver is actually useless starting with GWT 2.7.0-rc1. > > On Thursday, October 8, 2015 at 9:48:15 AM UTC+2, Cristiano wrote: >> >> Hello all, >> >> I was asking myself when I should use the gwt-codeserver.jar >> I'm not including it into my project but I can run Super Dev Mode anyway, >> so I've checked the content of the gwt-codeserver.jar to see what it does >> provide that is not provided by gwt-dev: >> >> Handwritten:gwt-0.0.0 cristcost$ pwd >> /Users/cristcost/dev/Open-Source/gwt-trunk/build/staging/gwt-0.0.0 >> Handwritten:gwt-0.0.0 cristcost$ *unzip -l gwt-codeserver.jar* >> Archive: gwt-codeserver.jar >> Length Date TimeName >> >> 0 10-05-15 10:39 META-INF/ >> 157 10-05-15 10:39 META-INF/MANIFEST.MF >> 0 10-05-15 10:39 com/ >> 0 10-05-15 10:39 com/google/ >> 0 10-05-15 10:39 com/google/gwt/ >> 0 10-05-15 10:39 com/google/gwt/dev/ >> 0 10-05-15 10:39 *com/google/gwt/dev/codeserver*/ >> 8425 10-05-15 10:39 *com/google/gwt/dev/codeserver/* >> CodeServer.class >> *[...omissis...]* >> 2492 06-30-15 09:52 *com/google/gwt/dev/codeserver* >> /stub.nocache.js >> 122 10-05-15 10:39 META-INF/INDEX.LIST >> --- >>509150 122 files >> Handwritten:gwt-0.0.0 cristcost$ >> >> everything is inside the folder *com/google/gwt/dev/codeserver* , ok, >> let's compare with dev: >> >> Handwritten:gwt-0.0.0 cristcost$ unzip -l *gwt-dev.jar* >> com/google/gwt/dev/codeserver/* >> Archive: gwt-dev.jar >> Length Date TimeName >> >> 0 10-05-15 10:39 com/google/gwt/dev/codeserver/ >> 8425 10-05-15 10:39 com/google/gwt/dev/codeserver/CodeServer.class >> *[...omissis...]* >> 2492 06-30-15 09:52 com/google/gwt/dev/codeserver/stub.nocache.js >> --- >>*508871* *115 files* >> Handwritten:gwt-0.0.0 cristcost$ >> >> >> and now let's filter more with more precision gwt-codeserver.jar to >> compare the differences: >> >> Handwritten:gwt-0.0.0 cristcost$ unzip -l *gwt-codeserver.jar* >> com/google/gwt/dev/codeserver/* >> Archive: gwt-codeserver.jar >> Length Date TimeName >> >> 0 10-05-15 10:39 com/google/gwt/dev/codeserver/ >> 8425 10-05-15 10:39 com/google/gwt/dev/codeserver/CodeServer.class >> *[...omissis...]* >> 2492 06-30-15 09:52 com/google/gwt/dev/codeserver/stub.nocache.js >> --- >>*508871* *115 files* >> Handwritten:gwt-0.0.0 cristcost$ >> >> >> same number of files, same size, so gwt-codeserver.jar I think this is >> not coincidence and then codeserver is completely included in gwt-dev. >> So, is useless? >> What is the purpose of it? >> >> thanks, >> Cristiano >> > -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/856cc80c-b92c-4afb-869c-7202cc569ca9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: JsInterop Function Callback
I think you could try to use a class annotated with @JsType, both for
return type and arguments...
if you pass in jQuery an object like this json:
{ "key1": "value1", "key2": "value2"}
and your code is
public MyObject call(Event event, MyObject param1, MyObject param2) { ... }
with a MyObject class like this :
@JsType
public class MyObject {
public String key1;
public String key2;
}
it should work.
The concept is that you'll rather have to manage potential runtime issue!
No compile time type checking will prevent you to invoke the function from
jquery with invalid type of the parameter...
I'm still exploring JsInterop so please correct me if I am wrong ;)
Cristiano
Il giorno venerdì 25 settembre 2015 23:33:33 UTC+2, Cristian Rinaldi ha
scritto:
>
> Hey:
>
>I'm using JsInterop to map some JS APIs.
> What is the best way to map a callback to receive multiple parameters?
>
> For example, a jQuery click handler: function (event, params)
>
> In Java could be:
>
> Function fn = new Function() {
> @Override
> public Object call(Event event, Object... params) {
> setVisible(!visible);
> return null;
> }
>
>
> but then is complicated to manipulate the "Object []", there is a more
> direct way?
>
>
--
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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/006c06dd-9c64-4dbe-a3b9-b08be4d2f506%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: External library to generate the remote service's Async interface
Could you write an an example to explain better what you mean, please? Thanks Il giorno martedì 15 settembre 2015 13:05:23 UTC+2, Lars ha scritto: > > What is the plan do deal with custom classes (including inheritance and > generics) as a parameter or return type? -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/7b871089-bce0-4a25-b553-dfb93164d611%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: External library to generate the remote service's Async interface
Hi, there is no problem in using a custom object, the characteristic of the examples with collections or maps is that they TEST the use of Generics: the generic parameter must be reused correctly in the Async interface. I've added a new example with a CustomObject to the asynchronize-example project to show that using a custom object is not a problem. Please consider that the processor only generates the interface, but then it need to be used with a real RPC implementation like GWT RPC. I am considering to release an RPC implementation library based on HTTP and GSON, but it is pure Java, it works with Android but it does not work with GWT (we use the same async interface both on the Android client and GWT client, so we can better reuse code logic and handle with the same code the (asynchronous) requests to the server), but I do not foreseen to release it soon... Regards, Cristiano Il giorno martedì 15 settembre 2015 14:37:53 UTC+2, Lars ha scritto: > > All your samples deal with primitive stuff or collections of this. For a > real RPC we need custom objects as well and a way to transfer them, but as > I see it right now you generate only the async interface?! -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/5b36f100-ff32-4bff-9f49-eeafd175f694%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] External library to generate the remote service's Async interface
Hello all, we are using an annotation processor to generate the async interfaces that are required by the GWT RPC services. This annotation processor automatizes the generation and works smoothly both with the maven build and on the IDE, plus we have other generation requirements and we have then added some more options to customize the output. Code generation is triggered by adding the @Asynchronize annotation to the original interface. We *have released it open source*, on https://github.com/codejuicer/asynchronize and the first public release is already available and published into Maven Central repo: org.codejuicer asynchronize-processor 0.9.1 Here is a Youtube video overview <https://youtu.be/YC853Kkm_6E> I have made to show how to use the processor and what it does (but generically it is sufficient to add this dependency and put @Asynchronize to make it work). We would like it to be used for future GWT, so we ask please the main contributors to have a look and give feedback, report issues (on github!) or ask documentation clarification so we can improve it for GWT developers needs. Thank you all, Cristiano -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/9f90feae-e904-4e7b-a13b-9e6fad203afd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: External library to generate the remote service's Async interface
thanks! it should be ok now https://youtu.be/YC853Kkm_6E Il giorno lunedì 14 settembre 2015 15:14:13 UTC+2, Matic Petek ha scritto: > > Hi, > Your video is private. > > On Monday, September 14, 2015 at 2:50:02 PM UTC+2, Cristiano wrote: >> >> Hello all, >> >> we are using an annotation processor to generate the async interfaces >> that are required by the GWT RPC services. This annotation processor >> automatizes the generation and works smoothly both with the maven build and >> on the IDE, plus we have other generation requirements and we have then >> added some more options to customize the output. Code generation is >> triggered by adding the @Asynchronize annotation to the original interface. >> >> We *have released it open source*, on >> https://github.com/codejuicer/asynchronize and the first public release >> is already available and published into Maven Central repo: >> >> org.codejuicer >> asynchronize-processor >> 0.9.1 >> >> >> Here is a Youtube video overview <https://youtu.be/YC853Kkm_6E> I have >> made to show how to use the processor and what it does (but generically it >> is sufficient to add this dependency and put @Asynchronize to make it >> work). >> >> We would like it to be used for future GWT, so we ask please the main >> contributors to have a look and give feedback, report issues (on github!) >> or ask documentation clarification so we can improve it for GWT developers >> needs. >> >> Thank you all, >> >> Cristiano >> > -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/639842f9-8053-4779-b438-7b39d116bb40%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: External library to generate the remote service's Async interface
Hi Thomas, now that the processor project is setup, updating it to allow each specific method to customize the return type or callback is tricky. OfCourse, the method needs to be someway annotated. If you plan to try to use the processor, please add an issue on github and I'll be pleased to implement it. Regards, Cristiano Il giorno lunedì 14 settembre 2015 17:21:06 UTC+2, Thomas Broyer ha scritto: > > IMO, it should be possible to set the "returnType" on each method of the > interface, so you could have an async method returning 'void', another one > returning 'Request' and yet another returning 'RequestBuilder', all in one > interface. Same could be useful for the callback type too (and actually > probably all the options you provide). > I had long thought about using RemoteServiceRelativePath to trigger an > annotation processor, but I would have to come up with some annotation to > define the return type. In the end, it's probably easier to generate the > sync interface from the async one: all you have to do is to decide whether > you want the boxed or primitive types when your callback takes a boxed type > as type-argument (e.g. AsyncCallback), but it wouldn't be a real > issue in practice I believe to always pick the type-argument as-is and > never convert to the primitive type. > > On Monday, September 14, 2015 at 2:50:02 PM UTC+2, Cristiano wrote: >> >> Hello all, >> >> we are using an annotation processor to generate the async interfaces >> that are required by the GWT RPC services. This annotation processor >> automatizes the generation and works smoothly both with the maven build and >> on the IDE, plus we have other generation requirements and we have then >> added some more options to customize the output. Code generation is >> triggered by adding the @Asynchronize annotation to the original interface. >> >> We *have released it open source*, on >> https://github.com/codejuicer/asynchronize and the first public release >> is already available and published into Maven Central repo: >> >> org.codejuicer >> asynchronize-processor >> 0.9.1 >> >> >> Here is a Youtube video overview <https://youtu.be/YC853Kkm_6E> I have >> made to show how to use the processor and what it does (but generically it >> is sufficient to add this dependency and put @Asynchronize to make it >> work). >> >> We would like it to be used for future GWT, so we ask please the main >> contributors to have a look and give feedback, report issues (on github!) >> or ask documentation clarification so we can improve it for GWT developers >> needs. >> >> Thank you all, >> >> Cristiano >> > -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/33256ce3-c625-4ae6-8b85-c383b45d7548%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: External library to generate the remote service's Async interface
Hi Jens, yeah, basically I do what you wanted to do with @RemoteService, but then I had to rearrange the dependencies (moved in a project where I couldn't depend on GWT) and so I moved to processing on the @Asynchronize annotation (which I created initially with a different name and purpose similar to your @GenerationStrategy). And yes there is the possibility to customize the return type, for example if you want a boolean, use it as @Asynchronize(returnType = boolean.class). Plus there are some other inspiring options. I really think that being an independent project it makes it better in terms of modularity, but its code is Apache Licensed and I allow freedom of copying it to make a processor specific for GWT, working with @RemoteService annotation. Also I have some ideas (see the github issues) to make it completely transparent as a dependency so that subprojects don't inherit the processor and processing is not triggered in all the hierarchy. Please give it a try, your feedback could be helpful ;-) Il giorno lunedì 14 settembre 2015 15:43:15 UTC+2, Jens ha scritto: > > Hey, > > I actually also thought about that in the past but never had time to > implement it. You can read my thoughts at > https://groups.google.com/d/msg/codehaus-mojo-gwt-maven-plugin-users/tSI4ZqjNZD8/uMt0TMHW2sUJ > > Basically instead of @Asynchonize I would have used @RemoteService as that > matches the "old" interface name you currently have to extend. Also I would > have introduced a @GenerationStrategy annotation because in the Async > interface you can return void, Request or RequestBuilder which allows you > to customize the request or even cancel it. > > -- J. > -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/6834e4ab-1690-46a8-9c73-7dc45e6cc8c6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Serialization of @XmlType classes
Hi all,
*Question:*
Would you consider supporting classes annotated with JaxB (with annotation
javax.xml.bind.annotation.XmlType) to be serializable by GWT service?
*Motivation:*
I work a lot with classes annotated with JaxB that are not
java.io.Serializable and neither I can implement in them the
com.google.gwt.user.client.rpc.IsSerializable interface.
This constrict our project to maintain an almost clone of the server data
model and use Dozer to map jaxb-xml classes to gwt-IsSerializable ones.
*(Potential) Solution:*
Today I've tested hacking the
com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder (the one in
GWT 2.7.0 sources) by changing isAutoSerializable() method into this:
static boolean isAutoSerializable(JClassType type) {
try {
JClassType isSerializable = getIsSerializableMarkerInterface(type);
JClassType serializable = getSerializableMarkerInterface(type);
return type.isAssignableTo(isSerializable) || type.isAssignableTo(
serializable) ||
type.isAnnotationPresent(XmlType.class);
} catch (NotFoundException e) {
return false;
}
}
where I have added to the OR condition the check to see if type is
annotated with JaxB's @XmlType.
I've made some quick test, and with this hack I've successfully compiled a
very large data set of JaxB annotated POJOs, and successfully exchanged in
a GWT RPC service a couple of these object (in the next days I'll make more
deep testing).
*Discussion:*
The solution is easy to apply, from my point of view the only negative
impact is that it adds a new import to SerializableTypeOracleBuilder, but
JSR 222 is integrated into Java SE since 1.6.
The contract on XmlType should be as restrictive as the one on
Serializable, so if it is annotated correctly for JaxB, then it should
serialize with GWT safely.
The above solution is partial, as to be fully compliant with JSR 222, it
should also implement other JaxB annotations (among others @XmlAccessorType and
@XmlTransient) but it could be initially implemented like this as
Experimental feature enabled by a compiler option.
Could you please express your opinion and your level of harmony with this
proposal? ;-)
If there is a bit of interest and nobody is against, I can open a issue and
propose a patch, but it is 1 year I don't propose GWT patches and if
someone with the hands in the code and gerrit could do it, I welcome him!
Thank you,
Cristiano
--
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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/96f1f18c-f50e-420a-b8a4-ba08861b423c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: proposing a hypothetically breaking change to gwt-servlet.jar: comments?
Hi Liu,
I agree and share your considerations,
but I think it is best to address the issue with a better modularization of
the whole GWT distribution.
In fact it is not just a problem of the gwt-servlet.jar, but it is a
problem also affecting gwt-user.jar and gwt-dev.jar:
all features of GWT in these years have been added to a monolithic
project (sub-framework like GWT RPC, activity and places, UiBinder are all
coupled into the same jar, only request factory is modularized).
GWT Java modularity only makes distinction between runtime code (gwt-user)
and build time code (gwt-dev). The gwt-servlet is not a real component, it
is jar with a bunch of classes filtered out from the other two. I would not
say this is a best practice as it causes broken dependencies,
with undesired java import which are not resolved and work as long as the
gwt-servlet.jar classes are supposed not to use that code, and it is
causing me a lot of issues as I'm using GWT in OSGi environment :-).
Now GWT packages are polluted with dependencies hard to maintain, and
so modularizing GWT is HARD!
So, I definitively would tolerate that 6 MB jar for the moment (but I must
say that honestly in my OSGi approach the war is a Skinny War and it does
not include gwt-servlet.jar =
maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html), and
encourage the community toward a better modularization of GWT for example
in GWT 3.0.
In any case, you could try to make your customized gwt-servlet.jar removing
unnecessary code and use it when you deploy your webapp: you would not do
anything architecturally worst than what GWT does (remember you don't use
get-servlet.jar for building).
I take this opportunity to make stronger a position of mine on the GWT
build system:
I believe the bad modularization to be an historical legacy of having used
Ant for build, it's high degree of freedom has made GWT source code grow in
a improper way (note that inside google they don't use Ant and probably
this is why this aspect is of poor quality). Other web framework like
Apache Wicket (built with maven) achieve a better degree of modularization.
Probably also Gradle would orient the project in a better direction.
There have been already many discussion on the subject, I suggest you to
search for this topic (GWT modularization) on this group for getting an
idea of the actual problems in advancing in this direction and would be
glad if you'll participate to the discussion next time it arise.
Regards,
Cristiano
2014/1/16 dapeng liu verydap...@gmail.com javascript:_e({}, 'cvml',
'verydap...@gmail.com');
any follow up on this?
would like to see a saner gwt-servlet.jar
include a 6M jar just to serve a single RemoteServlet is just absurd ...
On Friday, June 25, 2010 4:09:29 AM UTC+8, Freeland Abbott wrote:
Right now, if you pore through servlet/build.xml, we build
gwt-servlet.jar by first building the classes for gwt-user, then filtering
out a set of blacklisted packages from it. As we've added things, of
course, the secret blacklist has grown stale, and that explains why some
never-sane-in-server-context things like UiBinder are now packaged into
gwt-servlet.jar.
I'd like to change that, but it's breaking at least theoretically if
anyone *had* found a server-side use, sane or otherwise. The fix would
be easy (nothing stops you from dropping gwt-user onto your server, I
suppose), and I'd be a bit disturbed if you did have a sane server-side
use... but hey, I've been surprised before, which is why I'm asking.
It also turns out that I-think-too-many legitimately server-side things
(like, say, RPC) need to touch client packaged classes for things like
enums and whatnot, and the classes with those enums then pull in a large
list of other client things, and so client-only stuff like DomEvents turns
out actually to be required. I'm not---at least not yet---talking about
refactoring those things, just about getting to a whitelist algorithm for
gwt-servlet with a minimal set of grandfathered client classes.
As near as I can tell, the new definition of gwt-servlet would be, using
ant ** and * wildcards mixed with shell-style comments 'cause XML ones are
ugly:
# what I actually want to keep in gwt-servlet:
com/google/gwt/**/server/**/*.java
com/google/gwt/**/shared/**/*.java
# What server and shared RPC need, despite the client designation:
com/google/gwt/user/client/rpc/*.java
com/google/gwt/user/client/rpc/impl/AbstractSerialization*.java
com/google/gwt/user/client/rpc/RpcRequestBuilder.java
com/google/gwt/http/client/*.java
com/google/gwt/xhr/client/ReadyStateChangeHandler.java
com/google/gwt/xhr/client/XMLHttpRequest.java
com/google/gwt/user/client/Timer.java
com/google/gwt/user/client/rpc/SerializationException.java
com/google/gwt/user/client/rpc/SerializationStreamReader.java
com/google/gwt/user/client/rpc/SerializationStreamWriter.java
com/google/gwt/rpc/client/ast/*.java
com/google/gwt/rpc
[gwt-contrib] What about the release of 2.6.0?
Hello all, it is many days I don't see info about the release date for GWT 2.6.0... I see in GWT issues there are 7 issues for milestone 2_6 that are not in state FixedNotReleasedhttps://code.google.com/p/google-web-toolkit/issues/detail?id=5524q=milestone%3A2_6sort=status%20milestonecolspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Stars. Is the community only waiting to have these 7 issues fixed before releasing 2.6.0? Any hypothesis on when the final 2.6.0 will be released? Cristiano -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Some random modularization/cleanup-related news
I do care a lot about this topic: I'm new to the source code of GWT; I did started digging into it less than one month ago with the intent of ease use of GWT in OSGi environment. For this reason, I did a (simple) run of JDepend on the GWT source code, merged all together in a single project, to study packages dependencies. I got this report http://goo.gl/U688XQ that also gives an idea of the complexity. Another proof of the coupling comes from the final OSGi Import-Package and and Export-Package setup I had to use (see at the end) to make gwt-servlet.jar work as an independent OSGi bundle serving gwt examples from the distribution. My overall feeling is that the initial partition into User Dev is no more sufficient to the size of the project, and I also judge a mistake that need to be fixed the way Servlet jar is formed by extracting classes from the two previous. I think it would help designing the ideal modularity of GWT with a mind map or in another breakdown structure form, so that new developments could follow a good orientation. If the vision is clear, people could refactor code gradually while working on other features and patches. Probably we will need to be prepared to breaking some backward compatibility (for example, gwt-servlet that is expected to depend only on server side or shared code, won't work without the package com.google.gwt.user.client.rpc and I think com.google.gwt.user.client.rpc should be moved to com.google.gwt.user.shared.rpc) and this could be only acceptable for a very major release (GWT 3.0.0?). If this has to be done, it has to be motivated by a clear path. In the end, as an example, take a look at the Apache Wicket project, it probably have the same size of GWT and the level of modularity of it source code seems good (Wicket has however a other design issues and I prefer a lot GWT ;-) ) Please go on and deep on this topic, Cristiano PS. OSGi's Import-Package and Export-Package necessary for gwt-servlet.jar. Note the setup may not be optimal, I did followed a Test Driven approach stopping as soon as each example was working. Import-Package = com.google.web.bindery.event.shared com.google.web.bindery.requestfactory.shared.messages javax.annotation javax.annotation.processing javax.imageio javax.imageio.metadata javax.imageio.stream javax.inject javax.lang.model javax.lang.model.element javax.lang.model.type javax.lang.model.util javax.servlet javax.servlet.http javax.tools javax.validation javax.validation.bootstrap javax.validation.constraints javax.validation.groups javax.validation.metadata javax.validation.spi junit.framework org.json org.w3c.css.sac org.w3c.dom org.w3c.flute.parser sun.misc Export-Package = com.google.gwt.activity.shared com.google.gwt.codegen.server com.google.gwt.core.server com.google.gwt.core.shared com.google.gwt.dev.asm com.google.gwt.dev.asm.commons com.google.gwt.dev.asm.signature com.google.gwt.dev.asm.tree com.google.gwt.dev.asm.util com.google.gwt.dev.protobuf com.google.gwt.dev.util com.google.gwt.dom.builder.shared com.google.gwt.event.logical.shared com.google.gwt.event.shared com.google.gwt.event.shared.testing com.google.gwt.i18n.linker com.google.gwt.i18n.server com.google.gwt.i18n.server.keygen com.google.gwt.i18n.server.testing com.google.gwt.i18n.shared com.google.gwt.junit.linker com.google.gwt.logging.server com.google.gwt.logging.shared com.google.gwt.place.shared com.google.gwt.precompress.linker com.google.gwt.regexp.shared com.google.gwt.resources.css com.google.gwt.resources.css.ast com.google.gwt.resources.ext com.google.gwt.resources.rg com.google.gwt.rpc.linker com.google.gwt.rpc.server com.google.gwt.safecss.shared com.google.gwt.safehtml.shared com.google.gwt.text.shared com.google.gwt.text.shared.testing com.google.gwt.thirdparty.debugging.sourcemap com.google.gwt.thirdparty.debugging.sourcemap.proto com.google.gwt.thirdparty.guava.common.annotations com.google.gwt.thirdparty.guava.common.base com.google.gwt.thirdparty.guava.common.base.internal com.google.gwt.thirdparty.guava.common.cache com.google.gwt.thirdparty.guava.common.collect com.google.gwt.thirdparty.guava.common.escape com.google.gwt.thirdparty.guava.common.eventbus com.google.gwt.thirdparty.guava.common.hash com.google.gwt.thirdparty.guava.common.html com.google.gwt.thirdparty.guava.common.io com.google.gwt.thirdparty.guava.common.math com.google.gwt.thirdparty.guava.common.net com.google.gwt.thirdparty.guava.common.primitives com.google.gwt.thirdparty.guava.common.reflect com.google.gwt.thirdparty.guava.common.util.concurrent com.google.gwt.thirdparty.guava.common.xml com.google.gwt.thirdparty.streamhtmlparser com.google.gwt.thirdparty.streamhtmlparser.util com.google.gwt.typedarrays.server com.google.gwt.typedarrays.shared com.google.gwt.uibinder.attributeparsers com.google.gwt.uibinder.elementparsers com.google.gwt.user.client.rpc com.google.gwt.user.client.rpc.core.com.google.gwt.core.shared com.google.gwt.user.client.rpc.core.java.lang
Re: [gwt-contrib] Re: Problem on sample Validation due to missing class in gwt-servlet
Hi All,
I then think that it is needed a patch to include guava-15.0-rebased.jar,
sourcemap-rebased.jar, protobuf-java-rebased-2.5.0.jar and
streamhtmlparser-jsilver-r10-1.5-rebased.jar in gwt-servlet.jar
The patch should be as easy as moving the following lines in
servlet/build.xml up within the gwt.jar task of -servlet target:
zipfileset
src=${gwt.tools.lib}/guava/guava-15.0/guava-15.0-rebased.jar /
zipfileset
src=${gwt.tools.lib}/jscomp/20131014/sourcemap-rebased.jar /
zipfileset
src=${gwt.tools.lib}/protobuf/protobuf-2.5.0/protobuf-java-rebased-2.5.0.jar
/
zipfileset
src=${gwt.tools.lib}/streamhtmlparser/streamhtmlparser-jsilver-r10/streamhtmlparser-jsilver-r10-1.5-rebased.jar
/
else, people may be deploying GWT web application without being able to
make them work.
Make the patch is easy, get the contributors to take a final decision is
harder:
but I think that the problem should be solved for 2.6.0 as Validation is a
feature described in the GWT dev guide
(http://www.gwtproject.org/doc/latest/DevGuideValidation.html) and the
problem is there since gwt 2.5 (I would not be surprised if no one use that
feature).
So, what you do think?
Cristiano
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Problem on sample Validation due to missing class in gwt-servlet
Uploaded the patch: https://gwt-review.googlesource.com/#/c/5400 I've tested it with validation sample, that now works with only gwt-servlet,jar on the classpath, and on dynatable examples plus 3 applications from my own with no visible change. Cristiano -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Problem on sample Validation due to missing class in gwt-servlet
Hi All,
I'm making some test on the validation example from the gwt source code
samples,
it runs ok from Eclipse, but when I deploy to both Glassfish or Apache
Karaf (a OSGi container), I get the following NoClassDefFoundError:
[In Glassfish]
Exception while dispatching incoming RPC call
com.google.gwt.user.server.rpc.UnexpectedException: Service method 'public
abstract com.google.gwt.safehtml.shared.SafeHtml
com.google.gwt.sample.validation.client.GreetingService.greetServer(com.google.gwt.sample.validation.shared.Person)
throws
java.lang.IllegalArgumentException,javax.validation.ConstraintViolationException'
threw an unexpected exception: java.lang.NoClassDefFoundError:
com/google/gwt/thirdparty/streamhtmlparser/ParseException
at
com.google.gwt.user.server.rpc.RPC.encodeResponseForFailure(RPC.java:389)
at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:579)
at
com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:208)
at
com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:248)
at
com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
[In Apache Karaf]
Caused by: java.lang.NoClassDefFoundError:
com/google/gwt/thirdparty/streamhtmlparser/ParseException
at
com.google.gwt.safehtml.shared.SafeHtmlBuilder.appendHtmlConstant(SafeHtmlBuilder.java:214)[230:com.google.gwt.gwt-servlet:2.6.0.rc1]
at
com.google.gwt.sample.validation.server.GreetingServiceImpl.greetServer(GreetingServiceImpl.java:68)[231:gwt-karaf-validation:1.0.0.SNAPSHOT]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_40]
The problem is that the class
com.google.gwt.thirdparty.streamhtmlparser.ParseException is missing on
gwt-servlet.jar
(see below the filters on the classes selected to be included into the jar).
When running into eclipse, the example works as it resolve the class from
gwt-user.jar
So, I ask you:
1. should gwt-servlet also include
com.google.gwt.thirdparty.streamhtmlparser classes?
2. or should the validation example be adapted to avoid using that class?
I do care to know which one of the two path should be embraced as I'm
working on a patch proposal (https://gwt-review.googlesource.com/#/c/5351/)
that it will be influenced by this choice.
The ParseException is used by
com.google.gwt.safehtml.shared.SafeHtmlHostedModeUtils
and maybe it should not depend on com.google.gwt.thirdparty.* as these are
not available on gwt-servlet,
but changing this dependency is probably hard and then the package should
be then included... but then there could be other issues coming from this
modification
For your convenience of inspection, here is the rules for selecting what is
included in gwt-servlet.jar:
fileset dir=${gwt.dev.bin}
include name=com/google/gwt/dev/asm/** /
include name=com/google/gwt/dev/util/Name*.class /
include name=com/google/gwt/dev/util/StringKey.class /
include name=com/google/gwt/util/tools/shared/** /
include name=com/google/gwt/core/shared/** /
!-- CHECK: do we need to add this rule? include
name=com/google/gwt/thirdparty/streamhtmlparser/** / --
/fileset
fileset dir=${gwt.user.bin}
exclude name=**/rebind/** /
exclude name=**/tools/** /
exclude name=**/super/** /
exclude name=com/google/gwt/json/** /
exclude name=com/google/gwt/junit/* /
exclude name=com/google/gwt/junit/client/GWTTestCase.* /
exclude name=com/google/gwt/junit/remote/** /
exclude name=com/google/gwt/junit/server/** /
exclude name=com/google/gwt/benchmarks/* /
exclude name=**/*.gwtar /
/fileset
Thank you,
Cristiano
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Problem on sample Validation due to missing class in gwt-servlet
apparently the package com.google.gwt.thirdparty does not included into
gwt-servlet as it is neither in ${gwt.dev.bin} or in ${gwt.user.bin}...
I'm trying to build a GWT that include it to see if then validation
example could work after that.
thank you Thomas for let me note it is included in gwt-servlet-deps, I'll
try a build with:
zipfileset
src=${gwt.tools.lib}/streamhtmlparser/streamhtmlparser-jsilver-r10/streamhtmlparser-jsilver-r10-1.5-rebased.jar
/
added to gwt-servlet (as 'streamhtmlparser' is rebased).
Cristiano
Il giorno martedì 12 novembre 2013 15:54:50 UTC+1, Thomas Broyer ha scritto:
On Tuesday, November 12, 2013 3:20:43 PM UTC+1, Cristiano wrote:
So, I ask you:
1. should gwt-servlet also include
com.google.gwt.thirdparty.streamhtmlparser classes?
IMO yes. It's currently in gwt-servler-deps IIRC, but that one should only
contain external deps that can be retrieved from elsewhere (and could
therefore cause conflicts if you do use them otherwise, particularly in
different versions)
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Problem on sample Validation due to missing class in gwt-servlet
2013/11/12 Jens jens.nehlme...@gmail.com Just wanted to throw in that if you use GWT's remote logging along with source maps then the StackTraceDeobfuscator also needs some classes from gwt-servlet-deps. As I think it's a pretty common scenario nowadays to enable source maps where possible you maybe should handle this case as well. IMHO everything in gwt-servlet-deps that is found under the package com.google should go into gwt-servlet. Doesn't really makes sense to me to have these classes in a jar that is not deployed to maven. At first I've read everything in gwt-servlet-deps should go into gwt-servlet and I was against that... ...then I've read it better the that is found under the package com.google and yes I agree!! You basically means that if something in gwt-servelt-deps has been rebased then it should go into gwt-servlet and I am okay with this! Alternatively I think it is better to split gwt-servlet-deps into 2, for example: - gwt-servlet-deps-external.jar - gwt-servlet-deps-rebased.jar Cristiano -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Problem on sample Validation due to missing class in gwt-servlet
so, FYI, validation example worked on karaf after compiling GWT Servlet with embedded streamhtmlparser-jsilver-r10-1.5-rebased.jar the examples can be found here: https://github.com/cristcost/gwt-karaf-examples but they are a little too messy yet... I now want to focus on making work on OSGi the Dynamic Table sample, so I'm not going to write instruction for running them. If someone want to try them and have problems, please ask me and I'll be glad to help you. Cristiano Il giorno martedì 12 novembre 2013 19:07:22 UTC+1, Thomas Broyer ha scritto: On Tuesday, November 12, 2013 5:37:36 PM UTC+1, Cristiano wrote: 2013/11/12 Jens jens.ne...@gmail.com Just wanted to throw in that if you use GWT's remote logging along with source maps then the StackTraceDeobfuscator also needs some classes from gwt-servlet-deps. As I think it's a pretty common scenario nowadays to enable source maps where possible you maybe should handle this case as well. IMHO everything in gwt-servlet-deps that is found under the package com.google should go into gwt-servlet. Doesn't really makes sense to me to have these classes in a jar that is not deployed to maven. At first I've read everything in gwt-servlet-deps should go into gwt-servlet and I was against that... ...then I've read it better the that is found under the package com.google and yes I agree!! You basically means that if something in gwt-servelt-deps has been rebased then it should go into gwt-servlet and I am okay with this! Alternatively I think it is better to split gwt-servlet-deps into 2, for example: - gwt-servlet-deps-external.jar - gwt-servlet-deps-rebased.jar No, if it's been rebased, it's safe to include in gwt-servlet (for Maven, for example), and I don't see any reason for putting it in another JAR. If it's been rebased, it's become an internal API of GWT. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: GWT 2.6.0 will be still Ant based or already Gradle bases? (for OSGI-fy GWT)
Hi All, maybe I have a patch for this (testing it now). I've opened an Issue https://code.google.com/p/google-web-toolkit/issues/detail?id=8424 and I will try to submit the patch as soon as possible. My biggest issue is that I need to learn how to use gerrit :-) If there is common acceptance, it could be ready for final release of 2.6.0. I will also make some demo project (sorry it will be made with maven) of a Web application for Apache Karaf (an OSGi container) that use GWT-Servlet as an OSGi. Regards, Cristiano -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Question about how making prepare a patch for gerrit
Hi all, I'm making a patch for the issue https://code.google.com/p/google-web-toolkit/issues/detail?id=8424 Actually I have tested the patch over the branch release/2.6 = $ git status # On branch release/2.6 # Changes to be committed: # (use git reset HEAD file... to unstage) # # modified: servlet/build.xml # new file: servlet/gwt-servlet.bnd # # Untracked files: # (use git add file... to include in what will be committed) # # build/ is this correct or should I work on the master branch? thank you! Cristiano -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Question about how making prepare a patch for gerrit
Many thanks Thomas! 2013/11/7 Thomas Broyer t.bro...@gmail.com According to https://groups.google.com/d/msg/google-web-toolkit-contributors/ay4gLCa9cuM/w8fNyLS6xKgJ, work on master and then cherrypick to release/2.6 (IOW, the release branch will never be merged back to master) On Thursday, November 7, 2013 7:09:58 PM UTC+1, Cristiano wrote: Hi all, I'm making a patch for the issue https://code.google.com/ p/google-web-toolkit/issues/detail?id=8424 Actually I have tested the patch over the branch release/2.6 = $ git status # On branch release/2.6 # Changes to be committed: # (use git reset HEAD file... to unstage) # # modified: servlet/build.xml # new file: servlet/gwt-servlet.bnd # # Untracked files: # (use git add file... to include in what will be committed) # # build/ is this correct or should I work on the master branch? thank you! Cristiano -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: GWT 2.6.0 will be still Ant based or already Gradle bases? (for OSGI-fy GWT)
I all, I link you a post on ServiceMix dev mailing list where I am taking on OSGi-fy GWT-Servlet and where I report my actual tests and my ideas: http://servicemix.396122.n5.nabble.com/OSGIfy-server-jar-of-GWT-td5718247.html Regards, Cristiano 2013/11/4 Dann Martens m...@dannmartens.com Hi Thomas, You're right, it wasn't gwt-servlet, I found them in gwt-user and gwt-dev; I did it manually a long time ago and had to check back to see what I actually did there. Thanks for clearing that up! During development, an OSGi-fied gwt-user bundle was added to the list of deployed bundles and was providing implementations of classes from the javax.servlet package. I refer to a fat jar whenever I find more than one package tree inside. It's not meant to have a derogatory connotation. Maybe 'fat' belongs in the space where really everything is just in one jar; and 'obese' should be a better match for the former case. At any rate, it's something we need to be careful with, especially in an OSGi context. Cheers, Dann On Monday, November 4, 2013 3:23:50 PM UTC+1, Thomas Broyer wrote: On Monday, November 4, 2013 9:00:13 AM UTC+1, Dann Martens wrote: Hi All, Better OSGi support would be great: right now we bundleize everything manually. The fat gwt-servlet jar pulls in a lot of 'stray' platform extension packages, e.g. javax.servlet which whould be provided by proper osgi-ified platform extension libraries. gwt-servlet is not fat (it's bloated with unneeded classes, but not a fat jar), and certainly doesn't embed javax.servlet. gwt-user is, but you don't deploy it, you only use it in your classpath at build-time (javac then GWT compilation). External dependencies are bundled in a gwt-servlet-deps fat jar in the downloadable SDK, and simply declared in the POM when you pull gwt-servlet from Central. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: GWT 2.6.0 will be still Ant based or already Gradle bases? (for OSGI-fy GWT)
Thank you Thomas, I'm not 100% sure the fact that JDT embed other the Jar due to OSGi, it could be but I've never used that feature. And it sound weird to me as then JDT should be used in an OSGi environment (yes Eclipse is based on OSGi, but I don't think GWT Ant build starts any OSGi environment) I mean, I remember it is possible to do embed jars, but OSGi does not mandate to do that, and in fact I use OSGi exactly for the opposite reason: to not have 20 MB .war files with all the libs embedded in it. In OSGi the manifest is used to declare dependencies, it works at the level of packages (instead of artifacts like Maven), you declare dependencies on packages and packages exported by it. It is a bit complex sometime but allow to have a good modularity for applications. What I would like to do, is to OSGI-fy GWT-Servlet (at first, and if it works the same could be applied to requestfactory) so it can be used inside an OSGi container. In that case, the GWT-Servlet could be deployed as a bundle providing the GWT classe, it will be available as a platform library, and web application will not need to embed it (I remember time ago I was putting libraries in Tomcat endorsed folder, consider it something like that but standardized). I will try to add the BND Ant Task on the GWT Build and if it work I will report it and we can evaluate if it is ok to use it also for the official release. Regards, Cristiano 2013/11/3 Thomas Broyer t.bro...@gmail.com On Thursday, October 31, 2013 9:16:57 AM UTC+1, Cristiano wrote: Hi All, I would like to know if the plan for 2.6.0 is to still use Ant or release it already from Gradle. Ant. I ask this because I would to check the feasibility of OSGIfy the GWT-Servlet jar. Having an OSGi compliant GWT-Servlet should make it easier to use GWT on OSGi containers (I suppose it is enough to OSGIfy GWT-Servlet as it is the only Jar I expect to to on the server side). There's requestfactory-client and requestfactory-server too. Some background information: OSGI-fization takes place by modify the META-INF/MANIFEST.MF file of the Jar and adding new headers that allow the jar to be used more friendly in an OSGi environment. This modification is mostly transparent, many much jar lbraries you are using are already OSGIfied or exist in an OSGIfied version (one example among all: the org.eclipse.jdt.core_3.8.3.v20130121-145325.jar that is in GWT-Tools is OSGIfied). Not the best example, as JDT's OSGi nature is an issue for us (need to extract a JAR that's embedded in the JAR; I think it's because of OSGi, but don't know OSGi that much) -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Maven-ization Status
Hi James, in the report of the latest GWT Contributor Hangout it is written that you want to work on Mavenization. I would like to help in some way (if I have time and the right skills). Can you tell us what it is your idea? It is written that you have shell scripts that do the conversion, can you share them? Thank you, Cristiano 2013/10/30 James Northrup northrup.ja...@gmail.com * dependencies have to be deployed to a Maven repo I wanted to chime in here, the dependencies to build a splattered hierarchy of java with poms using intellij to back-fill dependencies is here, tested on 2.5.0--rc i beleive. repository idgwt-maven-rewraps/id urlhttp://gwt-maven-rewraps.googlecode.com/git//url /repository if intellij can backfill gradle builds the same way it backfills with maven deps, all the better. in my experience things reach a point of mvn clean install with poms if you cordone off unit test support to be last and then don't run the unit tests. On Wednesday, October 2, 2013 9:29:46 AM UTC-7, Thomas Broyer wrote: On Wednesday, October 2, 2013 4:48:14 PM UTC+2, Geoffrey Wiseman wrote: On Sunday, September 29, 2013 8:51:47 PM UTC-4, Matthew Dempsky wrote: Anyway, I'm of the same opinion here as Thomas: I want to make it easy for developers to use GWT in their projects and to contribute to GWT itself. I supported switching to Maven as a means to this end, but I'm no fan of it beyond that, and I don't think any other core GWT contributors are at this point. To summarize: if anyone still feels strongly that GWT should use Maven, those individuals need to roll up their sleeves and work on making it happen. I neither love or hate Maven. It's one of the best supported build tools in Java, and I end up using it for that reason as much as anything else. It simplifies some things and makes other things more complex. If one of its alternatives got really popular, I would probably try it. In the end, I probably prefer Maven to Ant, mainly because Maven projects /tend/ to be a little more likely to work out of the box without configuration on an individual developer's machine, but that's more to do with how people use Ant than with Ant itself. That said, I agree with a bunch of the comments here that getting GWT to the point where someone can contribute to it without days of setup is key; I once tried to contribute a patch to something, but after a few hours of not getting the project fully set up, I gave up and went back to what I was actually working on. If you can reduce the barrier to entry so that it's not hard to contribute, even if that means installing Gradle or Buck, I think the problem is solved. If you moved to Maven and still had immense setup hurdles, the problem still isn't solved, AFAICS. The main issue with Maven here is that the road is long to reach a state where setting up your dev env is a breeze: * dependencies have to be deployed to a Maven repo * code *has* to be modularized a bit (because, as I said, gwt-dev tests depend on gwt-user and the hello sample sources) There might be some intermediary steps but we'd then lose features of the build (e.g. no gwt-dev tests), and/or it wouldn't solve the setup issue (if you don't deploy deps to a Maven repo) So moving to Maven requires a big bang move, i.e. the easiest way to fail. Gradle allows for baby steps: 1) make it work 2) make it better 3) modularize, piece by piece. Buck would require some work to setup IDEs, including hand-generating Eclipse .project/.classpath files by hand. So, I'd just be happy if that barrier to entry could be reduced -- reduced setup, increased modularity, simpler out-of-the-box configuration, etc. That'd make it easier for people like me to be more involved. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Maven-ization Status
Ok, thank you, I will check it as soon as I find some extra time (this afternoon I fear I'll end up fighting other issues all the time) I will try to give some useful feedback after that. Did you participated to the hangout this week? Do GWT 2.6.0 will be still released using Ant? Any update about the Gradle approach (is it going on?) thank you, Cristiano -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] GWT 2.6.0 will be still Ant based or already Gradle bases? (for OSGI-fy GWT)
Hi All, I would like to know if the plan for 2.6.0 is to still use Ant or release it already from Gradle. I ask this because I would to check the feasibility of OSGIfy the GWT-Servlet jar. Having an OSGi compliant GWT-Servlet should make it easier to use GWT on OSGi containers (I suppose it is enough to OSGIfy GWT-Servlet as it is the only Jar I expect to to on the server side). Some background information: OSGI-fization takes place by modify the META-INF/MANIFEST.MF file of the Jar and adding new headers that allow the jar to be used more friendly in an OSGi environment. This modification is mostly transparent, many much jar lbraries you are using are already OSGIfied or exist in an OSGIfied version (one example among all: the org.eclipse.jdt.core_3.8.3.v20130121-145325.jar that is in GWT-Tools is OSGIfied). The best way to OSGIfy a Jar is to use the BND tool at build time, which automates most of the process of creating OSGI headers. BND tool can be invoked with ant task (http://www.aqute.biz/Bnd/Ant) or with the maven-bundle-plugin (http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html) or I see it exists also a Gradle OSGI plugin (http://www.gradle.org/docs/current/userguide/osgi_plugin.html). In the end, I would like to know if it is best to focus on trying the BND Ant Task or the Gradle OSGI Plugin. Thank you, Cristiano P.S. On maven central repo it exists an OSGIfied version of GWT: org.apache.servicemix.bundles/org.apache.servicemix.bundles.gwt-user/2.4.0_1 org.apache.servicemix.bundles/org.apache.servicemix.bundles.gwt-dev/2.4.0_1 which they old (linked to gwt 2.4.0) and not optimal as exactly the gwt-servlet jar is missing! -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Question about the source: how does GWT builds *.translatable.*, *.emul.*, etc. packages?
As part as a jdepend documentation effort, it would be great to have a report when using these sources instead of the non-super-source ones. Ideally, we'd also want to teach jdepend to read into JSNI. Teaching JDepend to read JSNI is out of my path :-) but if you check the link of the report now, it is generated by analyzing the code using the super sources. The super sources are simply merged into the project at their destination package, so please note that some non-super-source file is then overwritten (see below for the list) For having this big merged project to compile, I had to exclude super sources of JRE emulation (coming from com.google.gwt.emul.*) and for JUnit (coming from com.google.gwt.junit.translatable.junit.*, that is the following files: junit.framework.Assert.java, junit.framework.AssertionFailedError.java, junit.framework.Test.java, junit.framework.TestCase.java, junit.framework.TestSuite.java) The old report is still available at this link http://cristcost.net/gwtdepend/jdepend-report-22-oct.html but please note the new report is related to commit 7ad390d50555ce072a080b3f0b0f80db5ac7648e while the report of 22 october was from 67fbd3cc714c81ea66c619c389692cc2d3552799 My first goal is to understand the GWT code from high level but hopefully this could help managing the split of packages into distinct artifacts. I have many scripts to move the code of GWT around (remember my idea of automatically moving files with scripts? well... let's say that I am just studying the feasibility), I have no problem in sharing them if someone needs, but first they are not complete (now they moves only Java files), and inside these scripts there are a lot of paths hardcoded to my mac. At last, this is the list non-super-source java files overwritten with super-source ones in the new report (other super-source files are merged without overwriting): com/google/gwt/core/client/impl/WeakMapping.java com/google/gwt/core/shared/impl/ThrowableTypeResolver.java com/google/gwt/junit/client/GWTTestCase.java com/google/gwt/junit/client/impl/GWTRunner.java com/google/gwt/junit/client/impl/GWTTestAccessor.java com/google/gwt/regexp/shared/MatchResult.java com/google/gwt/regexp/shared/RegExp.java com/google/gwt/regexp/shared/SplitResult.java com/google/gwt/rpc/client/impl/ClientWriterFactory.java com/google/gwt/rpc/client/impl/EscapeUtil.java com/google/gwt/safecss/shared/SafeStylesHostedModeUtils.java com/google/gwt/safehtml/shared/SafeHtmlHostedModeUtils.java com/google/gwt/safehtml/shared/SafeUriHostedModeUtils.java com/google/gwt/typedarrays/shared/TypedArraysFactory.java com/google/gwt/user/client/rpc/impl/ClientSerializationStreamReader.java com/google/gwt/user/client/rpc/impl/ReflectionHelper.java com/google/gwt/user/client/rpc/core/java/util/EnumMap_CustomFieldSerializer.java com/google/gwt/user/client/rpc/core/java/util/LinkedHashMap_CustomFieldSerializer.java com/google/gwt/validation/client/GwtMessageInterpolator.java com/google/gwt/validation/client/impl/GwtConfiguration.java com/google/gwt/validation/client/spi/GwtConfigurationState.java com/google/web/bindery/autobean/shared/impl/StringQuoter.java com/google/web/bindery/autobean/shared/ValueCodexHelper.java com/google/web/bindery/requestfactory/shared/impl/MessageFactoryHolder.java com/google/gwt/junit/client/DevModeOnCompiledScriptTest.java Sorry for the verbosity, if anyone have more direct questions I will be pleased to answer. Regards, Cristiano -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Question about the source: how does GWT builds *.translatable.*, *.emul.*, etc. packages?
com.google.gwt.emul.java.lang.reflect java.math does not match the expected package com.google.gwt.emul.java.math java.security does not match the expected package com.google.gwt.emul.java.security java.sql does not match the expected package com.google.gwt.emul.java.sql java.text does not match the expected package com.google.gwt.emul.java.text java.util does not match the expected package com.google.gwt.emul.java.util java.util.logging does not match the expected package com.google.gwt.emul.java.util.logging junit.framework does not match the expected package com.google.gwt.junit.translatable.junit.framework Thank you, Cristiano -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: packages com.google.gwt.thirdparty.*
yes, it is :-( I got unresolved imports without it. I cannot say why exactly but I can find it if required. Curiously, the dependency of JDT from Jetty Orbit, which is the most close to the JDT jar available on GWT-Tools, include the contents of jdtCompilerAdapter.jar, but with the Jetty artifact there ware other missing imports and I had to move to the approach suggested by Thomas and deploy them to the Maven repo (even if I did it with a partially automated process that adds them from the GWT tools folder during the maven build). I've made progresses but I'm still far from my goal, thank you again for now. 2013/10/21 Roberto Lublinerman rlu...@google.com On Sun, Oct 20, 2013 at 3:21 PM, Thomas Broyer t.bro...@gmail.com wrote: See $GWT_TOOLS/lib/eclipse/README.jdt-upgrade (last paragraph), and comments in https://gwt-review.googlesource.com/#/c/2361/1/dev/build.xml (if you understand them; reading them now, I don't ;-) ) In retrospective I am not sure if extracting jdtCompilerAdapter.jar from JDT is really needed. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] packages com.google.gwt.thirdparty.*
Hi All, I'm studying the gwt source code and I bumped into imports of classes under packages com.google.gwt.thirdparty.* like: import com.google.gwt.thirdparty.guava.common.base.Preconditions; import com.google.gwt.thirdparty.streamhtmlparser.HtmlParser; import com.google.gwt.thirdparty.streamhtmlparser.HtmlParserFactory; import com.google.gwt.thirdparty.streamhtmlparser.ParseException; I cannot find the above in the GWT sources, I searched into the GWT tools and there they are: $ unzip -l ./lib/guava/guava-10.0.1/guava-10.0.1-rebased.jar | grep Preconditions 5209 10-10-11 10:44 com/google/gwt/thirdparty/guava/common/base/Preconditions.class Can some good soul explain me the story behind these rebased dependencies? More specifically, for example, how does the ./lib/guava/guava-10.0.1/guava-10.0.1-rebased.jar is created and maintained? and why GWT can't use the original com.google.common.base.Preconditions without shading it? I was trying to compile GWT with replacing all the lib in GWT tools with dependencies coming from maven central repo, but I had to stop when I bumped into this imports as I will not find guava-10.0.1-rebased for GWT in it. Maybe it is possible (even if it may require lot of effort) to recreate these rebased dependencies with Maven Shade Plugin, and so I can put a step on my build chain where these missing dependencies com.google.gwt.thirdparty libs are built with it. but there could be lot of reason why this could be unfeasible... if I understand better the strategy, maybe I can find some idea on how to deal with it... thank you, Cristiano -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: packages com.google.gwt.thirdparty.*
There are README files that explain it for each lib (BTW, GWT now uses guava-15.0, have a look at the Ant build files; Eclipse files might not always be up-to-date) sorry, I missed that! I see that there are rules (jarjar-rules) that explain the applied rebase. Good for understanding it. You won't be able to do it. JDT and ICU, to mention a few, are not available there (or in any other Maven repo BTW) At least for JDT and ICU (is it icu4j?) I see there are some recent artifact on Maven Central Repo: http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.ibm.icu%22%20AND%20a%3A%22icu4j%22 and maybe this ones http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.eclipse.jdt.core.compiler%22%20AND%20a%3A%22ecj%22 if in Maven Central Repo the exact version required by GWT is not available, maybe GWT can be adapted with minor effort to what is available there. That was my plan when I was working on the Mavenization. Yeah, I know. :-) I actually have tried it, and I have a poms which shade Guava (15) and JSilver and fit them into a maven build lifecycle. I of course will share it if I achieve something good. How about just deploying those deps in a repo? well, yes, I would like to have them deployed on Maven Central Repo ;-) Thank you - as usual ;-) - Thomas, Cristiano P.S: I know Gradle can resolve dependencies from maven repos, I hope that - even if GWT adopt Gradle and not Maven - at least dependencies could be all externalized from GWT and get rid of the GWT Tools. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: packages com.google.gwt.thirdparty.*
Unfortunately, the JDT JARs contain JARs as resources (used by some sort of OSGi classloader dance I suppose) and we need internal APIs from one of those, that we have extracted. So unless the JARs available in Central have solved this issue (either extracted the JAR as a distinct artifact, or possibly merged it with the deployed artifact), it won't work. Which one, the one on GWT Tools or the ones in Maven Central Repo? (I want to have a look at it just for the sake of curiosity) Either we'll reference the dependency right from GWT_TOOLS (http URL to the SVN repo, without the need to svn checkout the repo beforehand) and bundle it into gwt-dev like we do now (so that it works at runtime without an external dependency), or we'll publish it to Central (in a com.google.gwt.thirdparty groupId). There were discussions about rebasing JDT inside a com.google.gwt.thirdparty subpackage too (the problem currently being possible conflicts with other libs that need JDT too) I vote for or publishing it to Central, com.google.gwt.thirdparty groupId is ok, For example, Jetty project does this in a groupId named org.eclipse.jetty.orbit. (curiously they do it also for org.eclipse.jdt.core which is used for JSP but without rebasing and I got conflicts debugging in GWT DevMode together with JSP on a Jetty 7 server because of different JDT in the classpath. Anyhow I would prefer to have both GWT and Jetty to depend on the same JDT dependency rather than having rebased dependencies inherited on my project). Regards, Cristiano -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Can someone explain me why I get the following error?
Thank you for the useful info! 2013/10/17 Jens jens.nehlme...@gmail.com How did you recognized that? is that 51.0 in Unsupported major.minor version (for me it is a non-sense) ? Jip. Each Java Version writes its own internal version into each class file. Java 8 = 52.0 Java 7 = 51.0 Java 6 = 50.0 ... A given JVM can only load classes up to their own version number. If the class version number is higher than the supported one for a given JVM then you get the above error containing the version number of the class file that could not be loaded. -- J. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Can someone explain me why I get the following error?
Hi All
maybe I can be a little off-topic posting here but this is not an usual
user question and hopefully some contributor can help me.
I want to understand an error that I get in DevMode. The error is the
following:
00:00:09,841 [ERROR] Unable to initialize static dispatcher
java.lang.UnsupportedClassVersionError:
com/google/gwt/core/client/JavaScriptObject$ : Unsupported major.minor
version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at java.lang.ClassLoader.defineClass(ClassLoader.java:465)
at
com.google.gwt.dev.shell.CompilingClassLoader.findClass(CompilingClassLoader.java:1121)
at
com.google.gwt.dev.shell.CompilingClassLoader.loadClass(CompilingClassLoader.java:1194)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:249)
at com.google.gwt.dev.shell.JsValueGlue.set(JsValueGlue.java:220)
at
com.google.gwt.dev.shell.ModuleSpaceOOPHM.doInvoke(ModuleSpaceOOPHM.java:129)
at com.google.gwt.dev.shell.ModuleSpace.invokeNative(ModuleSpace.java:576)
at
com.google.gwt.dev.shell.ModuleSpace.invokeNativeVoid(ModuleSpace.java:304)
at com.google.gwt.dev.shell.ModuleSpace.onLoad(ModuleSpace.java:347)
at
com.google.gwt.dev.shell.OophmSessionHandler.loadModule(OophmSessionHandler.java:200)
at
com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:526)
at
com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364)
at java.lang.Thread.run(Thread.java:680)
I'm not working on the standard release of GWT, I'm running a custom build
coming from current GWT development.
To make things more weird, I'm running the application on a Jetty 7 server
(with -noserver option) and debugging with DevMode using the following code
snippet:
String[] newArgs = (-noserver -war target/webapp -startupUrl gwt.html
+ -logLevel INFO -codeServerPort 9997
+ net.cristcost.test.gwt.DemoApp).split( );
DevMode.main(newArgs);
I get that error when I try to open the page with the GWT app in DevMode
(http://localhost:8080/gwt.html?gwt.codesvr=127.0.0.1:9997)
With GWT 2.5.1 everything was working, but I had an issue and I needed to
exclude org.eclipse.jdt.core dependency from the project due to
incompatibility with GWT:
dependency
groupIdorg.eclipse.jetty/groupId
artifactIdjetty-jsp/artifactId
version${jetty.version}/version
scopetest/scope
!-- This dependency cause issue in GWT compilation in DevMode --
exclusions
exclusion
artifactIdorg.eclipse.jdt.core/artifactId
groupIdorg.eclipse.jetty.orbit/groupId
/exclusion
/exclusions
/dependency
(in fact, I am really trying 2.6.0 nightly to see if this problem will
persists)
Can someone give me some light on the error and explain it? I want to see
if I find some workaround.
Thank you,
Cristiano
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Can someone explain me why I get the following error?
Good catch! It is true I compiled GWT with Java 7 and my eclipse may be launching it still with Java 6! I'll check it immediately. How did you recognized that? is that 51.0 in Unsupported major.minor version (for me it is a non-sense) ? Thank you! Cristiano 2013/10/17 Jens jens.nehlme...@gmail.com Looks like your DevMode is running with Java 6 but it tries to load classes that are compiled against Java 7. I would guess you have compiled GWT trunk using Java 7 (as its probably the default in your operating system) but Eclipse is configured to still use Java 6 to run DevMode. GWT trunk is fully compatible to Java 7 and you could reconfigure Eclipse to use Java 7 for your GWT project to fix the problem. If your server, you plan to deploy to for production, still needs Java 6 you must make sure that your build script uses -target 1.6 for the java compile so that Java 6 can load classes. -- J. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Can someone explain me why I get the following error?
Yes, I confirm it is working and I no more have a conflict with with Jetty 7's org.eclipse.jetty.orbit/org.eclipse.jdt.core/3.7.1, inherited by org.eclipse.jetty/jetty-jsp/7.6.12.v20130726 ;-) Thank you Cristiano -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Maven-ization Status
Hello, Exporting maven artifacts from Gradle could be very interesting, but I would like to point out one aspect: we should also create proper pom.xml files with dependencies defined in it rather than embedded in the jars, else there would be no benefit in adopting maven - from the GWT developer point of view. Probably this is feasible with Gradle, but I expect it requires a lot of configuration to be achieve as the plugin probably outputs standards simple pom.xml. This is much relevant to what I was meaning this morning: I was re-thinking to the approach of first modularize GWT, then mavenize it. It seemed good to me at first glance, then I realized that modularization of GWT is the real missing aspect now, and when you get a good modularization, maybe it is not mavenization that makes difference (publishing maven artifacts is _required_ but it could also be achieved in many other ways). So, I asked myself why am I so inspired by Maven? And I realized that it is thanks to Maven that I have been able to make the most modular projects in my career, so I would trust this tool to perform this modularization task and not a tool I just started to learn. Especially because modularization is not a matter of a tool, but a matter of the mind of the modularization's architect. Thomas seems to have a lot of experience with Maven and with GWT, so I want to suggest him, why not to start from Mavenization and then try doing Modularization with Maven? To better explain my perspective, here what I would do. In maven central repo I see there are 5 jars plus a pom for GWT : gwt-servlet - is a jar gwt-elemental - is a jar gwt-codeserver - is a jar gwt-user - is a jar gwt-dev - is a jar gwt - is a pom My mavenization first approach, would create a set of Maven projects which has exactly the above 5 artifacts as output. I mean something different than doing (as we already have in maven subfolder of GWT src code) ant clean dist-dev maven/push-gwt.sh I mean real maven projects that someone build by changing directory and launching mvn install. This should be automatized, Gradle or ant or even shell scripts could be used, and I the end it should be possible to build GWT with maven with something like: ant prepare-maven cd maven mvn clean install (probably the pom.xml are written completely and the prepare-maven step copy source code into the maven folders). The output of the maven build should be validated to be compatible with the one of the ant build, maybe something like clirr could be used for this. This will be a huge step, and the maven build would be 100% compatible, we should ask the community to move contributing to GWT using maven build. Then, if my thesis is right, start out the modularization, which with maven on the background could be easier. It seems a good approach to me, but I admit I am blind a lot about the whole GWT build and I will not be surprised if someone has already started blaming me for what I've written up to now. I believe that doing modularization requires the lead of a deep connoisseur of GWT src code project, if I would modularize it, I would probably fail leaving legacy un-modularized code or throw away parts. I would trust Thomas opinion on this most that everyone's else. He has done the most of the research on GWT and Maven and has also explored other roads with Buck and Gradle. I've achieved this idea only thanks to having studied his work (btw, I've not been able to make buck build work...) I would like to have some feedback on this idea. If Thomas want to try this way, I would be glad to help him, else, if I get at least some significant +1, I can start making some test... then if I discover it is harder than I can achieve, it could hopefully provide at least some useful feedback for who will come after. Regards, Cristiano 2013/9/29 Brian Slesinsky skybr...@google.com I haven't tried it, but it says here that Gradle has support for publishing to Maven: http://www.gradle.org/docs/current/userguide/publishing_maven.html On Sat, Sep 28, 2013 at 10:49 PM, Cristiano Costantini cristiano.costant...@gmail.com wrote: Hello, What do you think of having gradle (or something else) generating the pom.xml files? I was thinking that as an approach to mavenizzation... I'll try to elaborate more this concept if my laptop battery last enough. Cristiano Il giorno domenica 29 settembre 2013, Ray Cromwell ha scritto: Here's a commit on my private fork containing the gradle stuff https://github.com/cromwellian/gwt-sandbox/commit/8f26f05d78109d0d9a91871df9102c0b461bef90 On Sat, Sep 28, 2013 at 3:59 PM, Thomas Broyer t.bro...@gmail.comwrote: On Sunday, September 29, 2013 12:11:29 AM UTC+2, Ray Cromwell wrote: I bit the bullet and came up with a set of gradle files that can generate IDEA projects which successfully import and then allow you to build dev/user in the IDE and launch compilation of the samples. It's non-ideal because the builtin IDEA
Re: [gwt-contrib] Re: Maven-ization Status
Hello,
What do you think of having gradle (or something else) generating the pom.xml
files?
I was thinking that as an approach to mavenizzation...
I'll try to elaborate more this concept if my laptop battery last enough.
Cristiano
Il giorno domenica 29 settembre 2013, Ray Cromwell ha scritto:
Here's a commit on my private fork containing the gradle stuff
https://github.com/cromwellian/gwt-sandbox/commit/8f26f05d78109d0d9a91871df9102c0b461bef90
On Sat, Sep 28, 2013 at 3:59 PM, Thomas Broyer
t.bro...@gmail.comjavascript:_e({}, 'cvml', 't.bro...@gmail.com');
wrote:
On Sunday, September 29, 2013 12:11:29 AM UTC+2, Ray Cromwell wrote:
I bit the bullet and came up with a set of gradle files that can
generate IDEA projects which successfully import and then allow you to
build dev/user in the IDE and launch compilation of the samples. It's
non-ideal because the builtin IDEA support for importing gradle projects
doesn't give enough control (need to add Java source to class path but
exclude it from javac compile) However, running gradle idea generates the
proper files from the command line and you just open them.
And now I regret not having (seriously) looked at Gradle before ;-)
IIUC, thanks to the Ivy backend, we could even remove the need to
checkout the tools from SVN, and simplifying dependency management at the
same time; with a combination of client module
dependencieshttp://www.gradle.org/docs/current/userguide/dependency_management.html#sub:client_module_dependencies
and
an Ivy repository with custom
patternshttp://www.gradle.org/docs/current/userguide/dependency_management.html#N14ECC;
maybe not worth the effort if we want to stop bundling our dependencies in
the JARs (they'll have to be deployed to some Maven repo –Central– to
support Maven).
I'm gonna work on adding support for building and running unit tests and
adding SuperDevMode launch rules, then I'll put it up for review.
Would you mind publishing what you have already? (publish as a draft
–refs/drafts/master instead of refs/for/master– and add me as a reviewer if
you don't want to publicize it yet)
I'm curious how well Gradle will handle the fact that gwt-dev tests
require gwt-user.jar (and includes the sources of the HelloWorld sample,
but that's easy)
Eclipse users will have to figure out their own gradle magic. ;-p
I'll have a look at it then (yep, still mostly an Eclipse user)
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
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
google-web-toolkit-contributors+unsubscr...@googlegroups.comjavascript:_e({},
'cvml',
'google-web-toolkit-contributors%2bunsubscr...@googlegroups.com');.
For more options, visit https://groups.google.com/groups/opt_out.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
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
google-web-toolkit-contributors+unsubscr...@googlegroups.comjavascript:_e({},
'cvml',
'google-web-toolkit-contributors%2bunsubscr...@googlegroups.com');.
For more options, visit https://groups.google.com/groups/opt_out.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Maven-ization Status
For reference, here are my gripes with Maven: http://blog.ltgt.net/maven-is-broken-by-design/ Yes I've seen, I'm preparing a reply ;-) -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Maven-ization Status
Il giorno venerdì 27 settembre 2013, Goktug Gokdogan ha scritto: I have been in favor of Buck because that is what most contributors are already familiar with and can bring their expertise. This is a good point which need to be taken into account. But I've found frustrating buck cannot be built on windows, and no binaries are provided. Also, it required me to upgrade to JDK 7 on the mac before I can start to try building GWT... If this is the way to start with contributing to GWT it could be a limitation... -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Maven-ization Status
Hi Thomas, I'm (part-time) having a look at your gwt-sandbox with maven build; I like the way it is modularized: gwt-dev-parent gwt-jsni-parser gwt-util-parent gwt-shared gwt-tools-api gwt-dev-json gwt-dev-ext gwt-user-parent gwt-core-shared gwt-core-client gwt-compiler gwt-maven-plugin gwt-regexp-server gwt-http gwt-safehtml-server gwt-codegen gwt-jetty-launcher gwt-devmode gwt-codeserver gwt-i18n-shared gwt-i18n-server gwt-core-server gwt-regexp-client gwt-bindery-parent event event-gwt gwt-event-shared gwt-event-client gwt-event-logical-shared gwt-event-logical-client gwt-safehtml-client gwt-dom gwt-i18n-client gwt-rpc-shared gwt-rpc-api gwt-rpc-client gwt-rpc-server gwt-browsermanager gwt-resources-core gwt-window gwt-timer gwt-junit gwt-jsonp gwt-resources gwt-mockutilities gwt-safecss-server gwt-safecss-client autobean-shared autobean-vm autobean-gwt gwt-user requestfactory-shared requestfactory-client requestfactory-server requestfactory-gwt requestfactory-apt gwt-dev gwt-user gwt-codeserver gwt-legacy-parent I think it is a very precious piece of work! The build process fails however in resolution of a pugin, com.google.gwt.maven:gwt-maven-plugin:jar:2.6.0-SNAPSHOT but it is not the org.codehaus.mojohttp://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.codehaus.mojo%22 :gwt-maven-plugin:jar:2.6.0-SNAPSHOT is that the one at https://github.com/tbroyer/gwt-maven-plugin ? (maybe it can me moved inside the reactor build of the project). I don't like that it is still required to have the gwt-tools in the environment path; referring to the your post ;-) for me the ultimate build tool is the one that allow you to build a project in two steps: [me@host]# ultimate-scm checkout http://my.project.org/source_code trunk [me@host]# ultimate-build-tool build trunk having to configure gwt-tools it is out of my ideal way of building a project: I don't know if it possible, but gwt-tools should be mavenized too in my opinion. Many libs found inside the gwt tools are available as maven artifacts in Maven Central Repo (for stability, I always try to avoid referring dependency not found on http://search.maven.org/) but this may require Later I also want to try out your buck build files at https://gwt-review.googlesource.com/3741, (if I find out how the command line options to apply the patch :-D) so to compare the buck output. Just let me know if you want me to continue providing feedback, here ore somewhere else, or I will make some tests by myself and only give news in case i achieve something useful. Have a nice day, Cristiano 2013/9/24 Thomas Broyer t.bro...@gmail.com On Tuesday, September 24, 2013 5:51:33 PM UTC+2, John A. Tamplin wrote: On Tue, Sep 24, 2013 at 10:37 AM, Thomas Broyer t.br...@gmail.comwrote: It means two things: - replacing our hard-to-maintain Ant-based build (and Maven has the best IDE tooling among build tools) Yeah, I guess that is why I spent half of yesterday getting a build to work in IntelliJ when it worked running from the command line. I have had similar issues with Eclipse before. Maven is great when it works, but you are just SOL when it doesn't. You resort to deleting your .m2/repository, re-importing maven in your IDE, deleting your IDE project and recreating it, etc and (hopefully) it just starts working again and you have superstitions about what actually fixed it (so asking others for advice you get totally different suggestions for how to fix it, none of which actually fix it by themselves). That is before you even get into all the useless work that Maven does, such as downloading stuff to find out there is no work to do. +1 Except I don't think I ever had any issue loading projects in either Eclipse or IntelliJ. On the contrary, I have never once had an issue with ant, so I have no idea why people say Ant is hard to maintain. The problem is not Ant per-se, but how its been used for GWT. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Maven-ization Status
Hi Thomas, today I've tried to test the build with buck, but it has not worked for me... On the root, the command buck build asks to specify a build target, while buck targets prints lots of empty lines then it rise a RuntimeException: Not an ordinary file: gwt_tools/lib/javax/validation/validation-api-1.0.0.GA.jar while on the /user folder running buck targets gives a No such build target: //:servlet-api. (I've used the latest buck compiled after a master clone of github, on a Mac OS X with a freshly installed jdk 7 as buck don't run on windows and I didn't had yet java 7 on the mac). Which operative system do you use to build GWT with buck? Tomorrow I will try to find time to take a look at the POMs. If there is something else I can do for you (i.e. test patches), let me know I will try to support you. Cristiano 2013/9/25 Thomas Broyer t.bro...@gmail.com On Wednesday, September 25, 2013 9:52:25 AM UTC+2, Cristiano wrote: Hi Thomas, I'm (part-time) having a look at your gwt-sandbox with maven build; I like the way it is modularized: gwt-dev-parent gwt-jsni-parser gwt-util-parent gwt-shared gwt-tools-api gwt-dev-json gwt-dev-ext gwt-user-parent gwt-core-shared gwt-core-client gwt-compiler gwt-maven-plugin gwt-regexp-server gwt-http gwt-safehtml-server gwt-codegen gwt-jetty-launcher gwt-devmode gwt-codeserver gwt-i18n-shared gwt-i18n-server gwt-core-server gwt-regexp-client gwt-bindery-parent event event-gwt gwt-event-shared gwt-event-client gwt-event-logical-shared gwt-event-logical-client gwt-safehtml-client gwt-dom gwt-i18n-client gwt-rpc-shared gwt-rpc-api gwt-rpc-client gwt-rpc-server gwt-browsermanager gwt-resources-core gwt-window gwt-timer gwt-junit gwt-jsonp gwt-resources gwt-mockutilities gwt-safecss-server gwt-safecss-client autobean-shared autobean-vm autobean-gwt gwt-user requestfactory-shared requestfactory-client requestfactory-server requestfactory-gwt requestfactory-apt gwt-dev gwt-user gwt-codeserver gwt-legacy-parent I think it is a very precious piece of work! The build process fails however in resolution of a pugin, com.google.gwt.maven:gwt-**maven-plugin:jar:2.6.0-**SNAPSHOT but it is not the org.codehaus.mojohttp://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.codehaus.mojo%22 :gwt-maven-**plugin:jar:2.6.0-SNAPSHOT is that the one at https://github.com/tbroyer/**gwt-maven-pluginhttps://github.com/tbroyer/gwt-maven-plugin ? No, it's the modulemaven/module. It's a snapshot/copy of the one linked above. I don't like that it is still required to have the gwt-tools in the environment path; This is a temporary step in the migration process. The goal is to migrate to non-patched/non-repackaged dependencies whenever possible, and deploy the third-party deps on Central otherwise. referring to the your post ;-) for me the ultimate build tool is the one that allow you to build a project in two steps: [me@host]# ultimate-scm checkout http://my.project.org/source_**codehttp://my.project.org/source_codetrunk [me@host]# ultimate-build-tool build trunk having to configure gwt-tools it is out of my ideal way of building a project: I don't know if it possible, but gwt-tools should be mavenized too in my opinion. Many libs found inside the gwt tools are available as maven artifacts in Maven Central Repo (for stability, I always try to avoid referring dependency not found on http://search.maven.org/) but this may require Later I also want to try out your buck build files at https://gwt-review. **googlesource.com/3741 https://gwt-review.googlesource.com/3741, (if I find out how the command line options to apply the patch :-D) so to compare the buck output. There's a download section next to each patch set giving you the Git commands to checkout, pull or cherry-pick the changes. Just let me know if you want me to continue providing feedback, here ore somewhere else, or I will make some tests by myself and only give news in case i achieve something useful. Feedback is always welcome! I'd particularly appreciate a review of the POMs (not much which modules I created and what I put into them, more about how each module is built and who module dependencies are managed). I tried to follow The Maven Way™ as much as possible. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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
[gwt-contrib] Re: Maven-ization Status
Hi folks, I read and hear about the Maven-ization of GWT, which is something I would love because I love maven. However I've found it difficult to understand what does it means... I've checked out the latest source code and I see it is still based on ant build... On the repo there is only a master and google/pu branches and I don't see any trace of a pom.xml file. Where can I find a branch of a maven-ized GWT? If maven-ization is not moving the build system to maven, can you please kindly explain what it means? Thank you, Cristiano Il giorno lunedì 18 marzo 2013 02:20:46 UTC+1, Brandon Donnelson ha scritto: Good job!! :) Have a good day, Brandon Donnelson +Follow Me https://plus.google.com/u/0/111739836936169749229/posts On Sun, Mar 17, 2013 at 5:57 PM, Thomas Broyer t.br...@gmail.comjavascript: wrote: Status update before I go to bed (it's 1:50 AM over here): - the latest push to GitHub compiles OK (mvn clean install -DGWT_TOOLS=/home/tbr/Projets/gwt/tools -DskipTests) - tests pass until gwt-junit (but user modules are untested), which fails (I haven't investigated yet). - modules past gwt-junit (according to the Maven build plan) include gwt-jsonp, gwt-safecss-client and gwt-safecss-server, gwt-resources and gwt-mockutilities. - I excluded AutoDirectionHandler from gwt-i18n-client as it depends on user.ui (HasText, HasKeyUpHandler, etc.) I cleaned up the commit history a bit, but it's still quite messy (that's probably not a problem, as I suppose we'll either squash everything to one or a few big commits, or replay the changes) Note: we quickly discussed with Brian on G+ about how to integrate those changes to GWT proper in the end: https://plus.google.com/113945685385052458154/posts/Sf6bg55vXsa That's something in the hand of Google though, as we don't want to break their builds; but we're not there yet! On Sun, Mar 17, 2013 at 1:06 PM, Thomas Broyer t.br...@gmail.comjavascript: wrote: [please follow-up to gwt-contrib] OK, another trap: Window (WindowImplIE) uses TextResources, Resources (ExternalTextResource) uses JsonpRequestBuilder, which needs Timer, which in turn needs Window (and specifically the thing that needs TextResources); the loop is closed. I'll have to cut the Jsonp dependency on Timer the same way I already cut the dependency between RequestBuilder and Timer, except that XHR generate an event themselves when the page unloads so it wasn't a problem, but I don't think there's an equivalent for json-p. The alternative would be to move ExternalTextResource to its own artifact, separate from gwt-resources; BTW, moving CssResource and ImageResource out of gwt-resources would also remove the dependency on i18n; not sure what's best… I ended up splitting Resources into gwt-resources-core (ClientBundle, GwtDotCreateResource, TextResource, DataResource) and gwt-resources (ExternalTextResource, ImageResource, CssResource). I haven't upstreamed the change yet (introduces a ResourcesBase.gwt.xml inherited by Window.gwt.xml); it might be a good idea to split Resources.gwt.xml further (CssResources.gwt.xml and ExternalTextResources.gwt.xml with their specific configuration properties), and possibly split the modules at the Maven level too (so that if you don't use ExternalTextResource you're not forced to have Jsonp on your classpath, and similarly if you don't use CssResources you're not forced to have W3C SAC and W3C Flute in your classpath –I assume you'll have I18N anyway–) -- Thomas Broyer /tɔ.ma.bʁwa.je/ http://xn--nna.ma.xn--bwa-xxb.je/ -- You received this message because you are subscribed to the Google Groups Google Web Toolkit Steering group. To unsubscribe from this group and stop receiving emails from it, send an email to gwt-steering...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Maven-ization Status
I used to really like it; not so sure nowadays, therefore exploring Buck and Gradle. wow, I know it could cause issues if not used in the proper way, I have now addressed multiple issues and I'm very satisfied with maven even if I continue to improve it day after day. Apache Camel and Apache CXF are two open source projects with a very mature approach to Maven, and I've found many good practices and inspiration looking into their sources. Do you mind telling me why you don't love it anymore? Hopefully, as I would love to sponsor Maven, I can give some good hint... See https://github.com/tbroyer/gwt-sandbox/ Unfortunately very out of date… cloned! it is big but I'll have a look at it. It means two things: - replacing our hard-to-maintain Ant-based build (and Maven has the best IDE tooling among build tools) - modularizing GWT in much smaller and non-overlapping parts than gwt-dev and gwt-user (and gwt-servlet, and requestfactory-*), those parts would also declare their dependencies on third-party tools rather than bundle them. This will make GWT easier to use as a managed dependency (Maven, Ivy, Gradle, SBT, etc.) Exactly what I mean for Maven-ization ! I'm sorry you got to a dead end, I'm really curious to know what stopped you to see if I can help. Regards, Cristiano -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] HTML5 tags in com.google.gwt.dom.DOM.gwt.xml module
Hello all, I need to work with new HTML5 elements: video and SVG's tags. Now I'm doing some experiment and I'm working out this HTML5 support by myself on a modified src of GWT: I'm adding some new Element subclasses for some example element (video,svg,g,image) and extending the com.google.gwt.dom.client.Document.java and com.google.gwt.user.client.DOM.java classes by adding in a straightforward way all the SVG and video element creation methods I need for my tests. I want to ask you if is there anyone else who is doing the same on an official branch of GWT or into the incubator, so not to do a duplicate work. Thank you, Cristiano -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: DockLayoutPanel
I think it is reallay interesting:
I've been able to realize flexible and fluid layout before passing to
use GWT, by using CSS and a combination of properties position:
absolute; top:xxx, bottom;xxx, width:xxx etc.
and I liked this approach because it does not use tables!
In gwt, I've tried to do the same by using AbsolutePanel but it was
not posible mainly because AbsolutePanel ony let you to set top and
left value, (and, if I remember correctly, only as integer value).
I don't know if it could be of any help, but here I want to give you a
sample (in html) which I wrote while studing how to apply this kind of
CSS layouts in GWT (for sure it works on IE7, I don't know if it works
on IE6 but it was not important for me):
{{{
div id=Main class=panel
div id=Left class=panel
style=position:absolute;top:0;bottom:0;left:0;right:50%;
div id=LeftLeft class=panel
style=position:absolute;top:0;bottom:0;left:0;width:200px;
div id=LeftLeftTop class=widget
style=position:absolute;top:0;height:300px;left:0;right:0;h2Left
Left Top/h2/div
div id=LeftLeftBottom class=widget
style=position:absolute;top:300px;bottom:0;left:0;right:0;h2Left
Left Bottom/h2/div
/div
div id=LeftRight class=panel
style=position:absolute;top:0;bottom:0;left:200px;right:0;
div id=LeftRightTop class=widget
style=position:absolute;top:0;height:200px;left:0;right:0;h2Left
Right Top/h2/div
div id=LeftRightBottom class=panel
style=position:absolute;top:200px;bottom:0;left:0;right:0;
div id=LeftRightBottomTop class=panel
style=position:absolute;top:0;height:200px;left:0;right:0;
div id=LeftRightBottomTopLeft class=widget
style=position:absolute;top:0;bottom:0;left:0;right:50%;h2Left
Right Bottom Top Left/h2/div
div id=LeftRightBottomTopRight class=widget
style=position:absolute;top:0;bottom:0;left:50%;right:0;h2Left
Right Bottom Top Right/h2/div
/div
div id=LeftRightBottomSplit class=panel
style=position:absolute;top:200px;height:5px;left:0;right:0; cursor:s-
resize;hr//div
div id=LeftRightBottomBottom class=widget
style=position:absolute;top:205px;bottom:0;left:0;right:0;h2Left
Right Bottom Bottom/h2/div
/div
/div
/div
div id=Rightclass=panel
style=position:absolute;top:0;bottom:0;left:50%;right:0;
div id=RightLeft class=widget
style=position:absolute;top:0;bottom:0;width:300px;right:
0;h2Right Left/h2/div
div id=RightRight class=widget
style=position:absolute;top:0;bottom:0;left:0;right:300px;h2Right
Right/h2/div
/div
/div
}}}
I would like to be able to reproduce such a layout in GWT.
NB. Any news on UiBinder?
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] gwt-servlet in eclipse
Hi all, I've succesfully compiled GWT trunk by using Ant, now I want to debug it inside eclipse. I followed instructions on http://code.google.com/p/google-web-toolkit/source/browse/trunk/eclipse/README.txt, with the exception that I'm using Eclipse 3.4 and I've left compiler compliance level to 1.6. I've been able to import the basic projects, but gwt-servlet show a lot of errors (657) which seem to be related to missing classes in the classpath (UnableToCompleteException cannot be resolved to a type RpcPolicyManifestLinker.javagwt-servlet/core/src/com/google/gwt/user/ linker/rpc, line 41 TreeLogger cannot be resolved to a type RpcPolicyManifestLinker.java gwt-servlet/core/src/com/google/gwt/user/linker/rpc , line 40 ...) do anyone understand what's wrong? I suppose I misconfigured something... (to be clear, my intent is to try out oophm and to see if there are any sign of UiBinder, but I'm usual to go into deep and to try to understand what's happen in the underground) thanks! Cristiano ps. I solved first issues in compiling with ant, mainly due to an old version of Subversion in my system, which I have solved by installing (= unzipping to a folder + adding the bin directory to the path) subversion binaries from Tigris.org: Subversion Win32 binaries for Apache 2.2.x - svn-win32-1.6.3.zip --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
