[gwt-contrib] Re: proposing a hypothetically breaking change to gwt-servlet.jar: comments?

[Cristiano Costantini]

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 >

> 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/

Re: [gwt-contrib] Some random modularization/cleanup-related news

[Cristiano Costantini]

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
com.g

Re: [gwt-contrib] Problem on sample "Validation" due to missing class in gwt-servlet

[Cristiano Costantini]

Ok,
I'll follow your indications,
I'll give it a try before pushing it and in case of surprises I'll come
back here to discuss.

Do you want me also to create an issue associated to this, for tracking
purposes?

Cristiano

Il giorno mercoledì 13 novembre 2013, Roberto Lublinerman ha scritto:

>
>
>
> On Wed, Nov 13, 2013 at 9:33 AM, Thomas Broyer 
> 
> > wrote:
>
>>
>>
>> On Wednesday, November 13, 2013 5:41:12 PM UTC+1, Cristiano wrote:
>>>
>>> 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
>>>
>>
>> No, not protobuf, it's only used for DevMode's "remote UI" (what makes
>> the Dev Mode view in Eclipse possible)
>>
>> Guava is only needed for SafeHtml and SafeUri, so it'd be better to
>> provide guava-less implementation of the two classes that use it; except if
>> it's also needed for sourcemap, in which case it's OK to put it into
>> gwt-servlet.
>>
>
> Guava is used by sourcemap so it must be provided as well.
>
> @Cristiano would you want to make the patch yourserf? If so just add me as
> a reviewer
>
>
>  --
> 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  '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: Problem on sample "Validation" due to missing class in gwt-servlet

[Cristiano Costantini]

2013/11/12 Jens 

> 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: Question about how making prepare a patch for gerrit

[Cristiano Costantini]

Many thanks Thomas!



2013/11/7 Thomas Broyer 

> 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 ..." to unstage)
>> #
>> # modified: servlet/build.xml
>> # new file: servlet/gwt-servlet.bnd
>> #
>> # Untracked files:
>> # (use "git add ..." 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)

[Cristiano Costantini]

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 

> 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] Reminder: Branching GWT 2.6 later today

[Cristiano Costantini]

I'm using the 'nightly' with maven since some week, I had to create
non-snapshot artifacts to address this: if you generate 2.6.0-rc1 artifacts
it should work.


Il giorno mercoledì 6 novembre 2013, Matthew Dempsky ha scritto:

> Thanks for testing, Colin!  I'll try another push tonight using your
> scripts.
>
>
> On Tue, Nov 5, 2013 at 5:14 PM, Colin Alworth 
> 
> > wrote:
>
>> It looks like while I can get maven from the command line to get along
>> with that repo, IntelliJ isn't having it - it is getting confused by the
>> fact that the latest gwt-user snapshot 2.6.0-20131105.081128-3 only has a
>> sources jar and a pom, no actual jar with compiled code in it. The -1 jar
>> is only the compiled code, the -2 is only javadoc, and the -3 is, as
>> mentioned, sources.
>>
>> The maven/push-gwt.sh patch I put up should resolve this - for now this
>> setup is good for maven builds, but not for IDEs that expect to have
>> sources and javadocs available in the 'same' snapshot.
>>
>>
>> On Tuesday, November 5, 2013 2:18:30 AM UTC-6, Matthew Dempsky wrote:
>>
>>> In the mean time though, I think I successfully pushed 2.6.0-SNAPSHOT to
>>> https://oss.sonatype.org/content/repositories/google-snapshots/.
>>>
>>>
>>> On Tue, Nov 5, 2013 at 12:04 AM, Matthew Dempsky wrote:
>>>
 As promised, I created the "release/2.6" branch for tracking
 development towards 2.6.  At this point, development can continue on master
 towards the next release.  If you think a change should be made for 2.6,
 please propose it against master, and then notify me to cherry pick it onto
 release/2.6.

 Setting up the 2.6 release branch took longer than expected due to some
 last minute changes and technical issues.  I plan to finish preparing the
 2.6rc1 snapshot tomorrow morning, and push them out.  I'll send an
 announcement when that's ready.  Thanks for your patience and sorry for the
 slight delay.


 On Mon, Nov 4, 2013 at 1:58 PM, Matthew Dempsky wrote:

> As a reminder, I'm going to create the GWT 2.6 branch later today and
> prepare a 2.6rc1 snapshot.  There's still some time to propose and submit
> patches, but it's down to hours remaining now.  Don't fret if you miss the
> deadline: there will be more releases in the future!
>


>>>  --
>> 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>  '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  '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: GWT 2.6.0 will be still Ant based or already Gradle bases? (for OSGI-fy GWT)

[Cristiano Costantini]

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 

>
>
> 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

[Cristiano Costantini]

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.

Re: [gwt-contrib] Re: Maven-ization Status

[Cristiano Costantini]

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 

> >* 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.
>
> 
> gwt-maven-rewraps
> http://gwt-maven-rewraps.googlecode.com/git/
> 
>
> 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: packages com.google.gwt.thirdparty.*

[Cristiano Costantini]

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 

> On Sun, Oct 20, 2013 at 3:21 PM, Thomas Broyer  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.

Re: [gwt-contrib] Re: packages com.google.gwt.thirdparty.*

[Cristiano Costantini]

> 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: packages com.google.gwt.thirdparty.*

[Cristiano Costantini]

>
> 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: Can someone explain me why I get the following error?

[Cristiano Costantini]

Thank you for the useful info!



2013/10/17 Jens 

> 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.

Re: [gwt-contrib] Re: Can someone explain me why I get the following error?

[Cristiano Costantini]

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 

> 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: Maven-ization Status

[Cristiano Costantini]

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 

> 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/comm

Re: [gwt-contrib] Re: Maven-ization Status

[Cristiano Costantini]

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 
> 
> > 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 
>> dependencies"
>>  and
>> an Ivy repository with custom 
>> patterns;
>> 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.com>  '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  '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

[Cristiano Costantini]

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

[Cristiano Costantini]

>
> 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

[Cristiano Costantini]

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 

>
>
> 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.mojo
>> :gwt-maven-**plugin:jar:2.6.0-SNAPSHOT
>>
>> is that the one at 
>> https://github.com/tbroyer/**gwt-maven-plugin
>>  ?
>>
>
> No, it's the maven. 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_**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 ,
>> (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://group

Re: [gwt-contrib] Re: Maven-ization Status

[Cristiano Costantini]

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.mojo
: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 

>
>
> 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 wrote:
>>
>>> 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

[Cristiano Costantini]

> 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.