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

[james northrup]

I'll parrot Ray as well as I can:

the gwt team doesn't really use maven so the current build will probably
proceed as is.  Mavenized sources should be in gerrit (marked as
review-only) because maven is not a bad thing, it's just not the gwt team's
thing.  Thomas Broyer is looking into Gradle and Buck migration.

Gradle is somehow closer to ant semantics so seems to offer more
modularization conveniences.

the repo work done by this effort carries over to Gradle as far as i know.

this commit in this maven repo cdn project
https://code.google.com/p/gwt-maven-rewraps/source/detail?r=9fc5649f06a86ff1c08a84f6239ae98ae39f2326
has
the libs I pushed from GWT_TOOLS as maven repo format.


On Sat, Nov 2, 2013 at 8:53 AM, Cristiano Costantini <
cristiano.costant...@gmail.com> wrote:

> 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 a topic in the
> Google Groups "GWT Contributors" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-web-toolkit-contributors/MZRnJwCbKUM/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
Jim Northrup  *  (408) 837-2270 *

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

[james northrup]

Hi

I have to figure out the gerrit instructions but you may fork this in the
mean time.

the initial transform was chronicled on a  plus posting and is hopefully
repeatable on current trunk to some degree at
https://plus.google.com/u/0/112159826230131242033/posts/2vWKkHoiZZT

current most-effort sha1 for pre-2.5.0  is at
https://github.com/jnorthrup/gwt/commit/36b079a550b2f6959750d1647766677b6207bb92

( https://github.com/jnorthrup/gwt/network )

Bhaskar has sent me a link to gerrit this week but other priorities have
held me from it.

it may be as simple as stealing the poms that are here since they link the
custom gwt tools jars cdn entries.  It seems universally accepted that the
unit tests will not survive this effort.

On Sat, Nov 2, 2013 at 7:02 AM, Cristiano Costantini <
cristiano.costant...@gmail.com> wrote:

> 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 

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

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

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

[Thomas Broyer]

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.

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

[Geoffrey Wiseman]

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.

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.

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

[Ray Cromwell]

The @jar stuff isn't needed, I was just experimenting around in my patch.


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

[Matthew Dempsky]

On Sun, Sep 29, 2013 at 3:55 PM, Thomas Broyer  wrote:

> The problem is that gwt-dev tests depend (at runtime) on gwt-user (which
> depends on gwt-dev).
> So you'll want one Maven artifact with dev/core/src and dev/core/super
> (gwt-dev.jar), another one with user/* (gwt-user), and a third one with
> dev/core/test (gwt-dev tests, depend on both gwt-dev and gwt-user).
> You can probably hack something with Maven, but it would be just that: an
> ugly big hack. It would probably not work in your IDE too (believe me, I
> tried).
>

Ugh, this is another one of my gripes with Maven.  In a separate project
(error-prone), I wanted to move some of the test helper classes from
core:test into a separate testhelpers package so they could be reused in
other projects' tests.  Having a dependency path like "core:test" =>
"testhelpers:main" => "core:main" works fine in Google's BUILD system, but
Maven throws a fit about it.  (If someone has a good solution to this, feel
free to comment here:
https://code.google.com/p/error-prone/issues/detail?id=62)


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.

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

[Thomas Broyer]

On Sunday, September 29, 2013 10:24:42 PM UTC+2, Cristiano wrote:
>
> 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,
>

It is *obviously* possible.
 

> but I expect it requires a lot of configuration to be achieve as the 
> plugin probably outputs standards simple pom.xml.
>

No, it's built-in. Deploying to a Maven repo with a "naked" POM (without 
declared dependencies) would be a total nonsense.

See http://www.gradle.org/docs/current/userguide/maven_plugin.html and 
http://www.gradle.org/docs/current/userguide/publishing_maven.html
Don't forget that Hibernate and Spring (among others) are built with Gradle.

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

We have several goals with this "build refactoring":

   - lower the barrier to entry for contributors, by making it easier to 
   get your dev environment (IDE, etc.) configured to hack on GWT.
   - modularize GWT into smaller pieces (this, BTW, needs some preliminary 
   refactoring work at the code level), for many reasons (both for people 
   coding on GWT and people using GWT)
   - because of #2 above, the Ant build script and maven/push-gwt.sh would 
   quickly become an unmaintainable mess; we need something that's easier to 
   maintain (declarative at the high level would be best, imperative at the 
   low level even better)
   - stop bundling dependencies and instead reference them from a 
   repository.

I tried doing it all at once (except referencing deps as system deps), 
because I couldn't see another way to do it with Maven.
Note that I also tried to have a working build, and then reverse-engineer a 
transition path.
In retrospect, that was probably a mistake.

We hadn't discuss it earlier, but if we could also have a way to ensure the 
Google and open-source build definitions are in sync (e.g. generate one 
form the other), it would be the cherry on the cake!

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

Unless the tool gets in your way.
 

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

The problem is that gwt-dev tests depend (at runtime) on gwt-user (which 
depends on gwt-dev).
So you'll want one Maven artifact with dev/core/src and dev/core/super 
(gwt-dev.jar), another one with user/* (gwt-user), and a third one with 
dev/core/test (gwt-dev tests, depend on both gwt-dev and gwt-user).
You can probably hack something with Maven, but it would be just that: an 
ugly big hack. It would probably not work in your IDE too (believe me, I 
tried).
I'm not even talking about gwt-dev tests importing the HelloWorld sample 
sources and all our dependencies that don't exist in a Maven repo (also get 
in your way).
 

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

There also are requestfactory-* JARs in com.google.web.bindery.
 

> My "mavenization first" approach, would create a set of Maven projects 
> which has exactly the above 5 artifacts as output.
>

Possibly not as easy as it sounds. gwt-servlet should only contain "shared" 
and "server" code, but there are probably dependencies on classes from 
"client" packages with deep ramifications (I must say I can't remember if 
this is actually the case, or only theoretically possible).
 

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

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

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

[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/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
>>> .
>>> 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.
>>
>  --
> 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,
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

[Ray Cromwell]

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

[Thomas Broyer]

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.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Ray Cromwell]

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.

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. Eclipse
users will have to figure out their own gradle magic. ;-p



On Thu, Sep 26, 2013 at 10:29 PM, Brian Slesinsky wrote:

> I skimmed the Gradle manual and it looks pretty decent. While the syntax
> and terminology is different, it looks like the concepts map back to stuff
> I'm already comfortable with.
>
> It has "tasks" which are basically build rules which are configured via
> Groovy (instead of Python macros). The tool builds and executes a
> dependency graph, and you can look at the dependency graph before running
> it. There is a dependency cache and it sounds like they care about both
> avoiding duplicate work and reproducible builds. It has Maven and Ant
> compatibility without actually being Maven or Ant. Also, Android is
> standardizing on it which is a plus.
>
> Here's a good place to start reading:
> http://www.gradle.org/docs/current/userguide/tutorial_using_tasks.html
>
> - Brian
>
>
>
> On Thu, Sep 26, 2013 at 5:12 PM, Cristiano Costantini <
> cristiano.costant...@gmail.com> wrote:
>
>>
>>
>> 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.
>>
>
>  --
> 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

[Brian Slesinsky]

I skimmed the Gradle manual and it looks pretty decent. While the syntax
and terminology is different, it looks like the concepts map back to stuff
I'm already comfortable with.

It has "tasks" which are basically build rules which are configured via
Groovy (instead of Python macros). The tool builds and executes a
dependency graph, and you can look at the dependency graph before running
it. There is a dependency cache and it sounds like they care about both
avoiding duplicate work and reproducible builds. It has Maven and Ant
compatibility without actually being Maven or Ant. Also, Android is
standardizing on it which is a plus.

Here's a good place to start reading:
http://www.gradle.org/docs/current/userguide/tutorial_using_tasks.html

- Brian



On Thu, Sep 26, 2013 at 5:12 PM, Cristiano Costantini <
cristiano.costant...@gmail.com> wrote:

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

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

[Thomas Broyer]

On Friday, September 27, 2013 1:33:10 AM UTC+2, Ray Cromwell wrote:
>
> At Google our BUILD files are distributed throughout the source 
> directories as we try to make them as simple as possible with as strict 
> dependencies as possible.  I'd love to have a Buck file that could compile 
> gwt-dev/user/servlet, but it would be even better if there was one for each 
> and every module and important subsystem. 
>
> The former is important because, we'd likely want to write a 
> "gwt_module"/"gwt_application" plugin for Buck (What Google has internally, 
> they are the equivalent of java_library/java_binary, but run GWT) and to 
> make incremental compilation work, we'd want things modularized in smaller 
> pieces. The latter because, there are parts of gwt-dev people would like to 
> use that are not neccessarily needed in the jar.
>
> Is the Buck experiments you're doing working with the trunk as is, or on 
> your de-tangling dependency work you've done as part of the mavenization 
> attempt?
>

For now I only used Buck for the de-tangling dependency work. To use it, 
you still have to build gwt-dev using Ant; that's because I didn't want to 
duplicate in Buck what I already did with Maven, as I didn't intend to keep 
Buck as the build tool for GWT. I also used a single BUCK file to make it 
easier to edit (just open it in a text editor and use search to navigate 
within it, vs. having to chase down BUCK files sprinkled all over the 
source tree)

I don't think it would be possible currently to have one BUILD/BUCK file 
for each "piece" of gwt-dev (and similarly for gwt-user, to a lesser 
extent) without moving files, as we'd probalby want one "piece" to include 
classes from several packages under com.google.gwt or com.google.gwt.dev. 
So we'd basically either live with a big BUILD/BUCK file in dev/core that 
builds the various pieces of gwt-dev, or move files so we can have one 
BUILD/BUCK file per "piece", or we could build even smaller pieces (a bunch 
of BUILD/BUCK files would still probably have several java_library, as 
we're going to need to "split" packages into different JARs, unless we also 
rename classes) and assemble them into slightly bigger ones.

As much as I wouldn't mind using Buck for GWT (and most probably like it), 
I still think we should try other things first (such as Gradle) if our goal 
is to make it easier for new contributors to jump in (or for existing 
contributors configuring new dev environments). Gradle support in Eclipse 
is surprisingly good (OK, not for editing build.gradle files, but most 
contributors wouldn't have to deal with them anyway).
At this point though, I'm still open to anything that would make 
command-line builds easy and *fast*, and easy to maintain with a lot of 
small pieces to build. IDE automatic/easy configuration is also a 
requirement, but I wouldn't really mind building it manually (like they did 
for Gerrit).

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

[Ray Cromwell]

At Google our BUILD files are distributed throughout the source directories
as we try to make them as simple as possible with as strict dependencies as
possible.  I'd love to have a Buck file that could compile
gwt-dev/user/servlet, but it would be even better if there was one for each
and every module and important subsystem.

The former is important because, we'd likely want to write a
"gwt_module"/"gwt_application" plugin for Buck (What Google has internally,
they are the equivalent of java_library/java_binary, but run GWT) and to
make incremental compilation work, we'd want things modularized in smaller
pieces. The latter because, there are parts of gwt-dev people would like to
use that are not neccessarily needed in the jar.

Is the Buck experiments you're doing working with the trunk as is, or on
your de-tangling dependency work you've done as part of the mavenization
attempt?



On Thu, Sep 26, 2013 at 4:09 PM, Thomas Broyer  wrote:

>
>
> On Thursday, September 26, 2013 3:35:15 AM UTC+2, Ray Cromwell wrote:
>>
>> Thomas,
>>   In terms of Gradle vs Buck models, is there any possibility of writing
>> a tool that takes a Buck build file and produces Gradle files? That would
>> seem like a good option in lieu of waiting for Buck support in IntelliJ and
>> Eclipse. This isn't to say I have anything against Buck, it is literally a
>> clone of Google's BUILD system, and so that would actually help us to have
>> just one set of build files for internal vs external. However, it would be
>> nice not to have to hack the IDE stuff manually.
>>
>
> It would of course be possible, but would *a priori* require duplicating
> a bunch of code from Buck (search for all BUCK files, exec them with custom
> implementations of the build rules, find the "source root" using the
> .buckconfig's java.src_roots config)
> "buck targets --json --type java_library" wouldn't work as it "resolves"
> the glob() calls, so you'd have to call the tool every time you create a
> file so it updates the Gradle files to include the new file)
>
> That said, based on Shawn Pearce's experience on Gerrit, I'm not sure
> having the IDE configured the same way as the build is a requirement (for
> Gerrit, there's a single Eclipse project with all the sources)
>
> If Buck is like Google's BUILD, then a genrule could be used to download
>> dependencies from Maven repos. ;-)
>>
>
> That's what Gerrit is doing ;-)
> (they also “hack the IDE stuff” that way, generating Eclipse .project and
> .classpath; Buck has built-in support for IntelliJ but it only work if you
> have BUCK files spread within your project's source tree, rather than a
> single BUCK file like I did)
> Ivy would also work, used as a standalone tool. And a small tool could
> produce a BUCK file with prebuilt_jar rules for the downloaded
> dependencies, without the need to handle transitive dependencies manually.
> Ivy would also help deploy the generated JARs to Central.
> The more I think about it, the more I like the Buck+Ivy combo idea, but it
> requires building a few additional tools… (IDE configuration, release
> script, etc.)
> I'm just starting to try Gradle for a project at work, if it goes well,
> maybe I'll experiment with it on GWT (first step: replace Ant with Gradle,
> then possibly modularize in the same way I did it with Buck, without moving
> files, then we could decide the best file/folder layout for both Gradle and
> Google)
>
> --
> 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

[Thomas Broyer]

On Tuesday, September 24, 2013 5:48:03 PM UTC+2, Cristiano wrote:
>
>
> 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...
>

For reference, here are my gripes with Maven: 
http://blog.ltgt.net/maven-is-broken-by-design/

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

[Thomas Broyer]

On Thursday, September 26, 2013 7:26:45 PM UTC+2, Jens wrote:
>
>
>>   In terms of Gradle vs Buck models, is there any possibility of writing 
>> a tool that takes a Buck build file and produces Gradle files? That would 
>> seem like a good option in lieu of waiting for Buck support in IntelliJ and 
>> Eclipse. This isn't to say I have anything against Buck, it is literally a 
>> clone of Google's BUILD system, and so that would actually help us to have 
>> just one set of build files for internal vs external. However, it would be 
>> nice not to have to hack the IDE stuff manually.
>>
>> If Buck is like Google's BUILD, then a genrule could be used to download 
>> dependencies from Maven repos. ;-)
>>
>
> Shouldn't it be the other way around? A Gradle plugin that generates 
> Google build files sounds more logical to me as you have more freedom to 
> adjust the generated files to your internal system. Outside Google no one 
> will really use these buck/internal build scripts anyways (lack of IDE 
> support).
>

It would only work reliably if you stick to hard rules in the Gradle files 
(i.e. nothing fancy). Buck has a much simpler model than anything else, 
declarative at a (relatively) high level (a java_library has srcs, 
resources and deps and produces a JAR) and imperative (hard-coded in Buck) 
at a lower level (to build a java_library, compile the srcs with the deps 
in the classpath, then package the resulting classes and the resources).

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

[Thomas Broyer]

On Thursday, September 26, 2013 3:35:15 AM UTC+2, Ray Cromwell wrote:
>
> Thomas,
>   In terms of Gradle vs Buck models, is there any possibility of writing a 
> tool that takes a Buck build file and produces Gradle files? That would 
> seem like a good option in lieu of waiting for Buck support in IntelliJ and 
> Eclipse. This isn't to say I have anything against Buck, it is literally a 
> clone of Google's BUILD system, and so that would actually help us to have 
> just one set of build files for internal vs external. However, it would be 
> nice not to have to hack the IDE stuff manually.
>

It would of course be possible, but would *a priori* require duplicating a 
bunch of code from Buck (search for all BUCK files, exec them with custom 
implementations of the build rules, find the "source root" using the 
.buckconfig's java.src_roots config)
"buck targets --json --type java_library" wouldn't work as it "resolves" 
the glob() calls, so you'd have to call the tool every time you create a 
file so it updates the Gradle files to include the new file)

That said, based on Shawn Pearce's experience on Gerrit, I'm not sure 
having the IDE configured the same way as the build is a requirement (for 
Gerrit, there's a single Eclipse project with all the sources)

If Buck is like Google's BUILD, then a genrule could be used to download 
> dependencies from Maven repos. ;-)
>

That's what Gerrit is doing ;-)
(they also “hack the IDE stuff” that way, generating Eclipse .project and 
.classpath; Buck has built-in support for IntelliJ but it only work if you 
have BUCK files spread within your project's source tree, rather than a 
single BUCK file like I did)
Ivy would also work, used as a standalone tool. And a small tool could 
produce a BUCK file with prebuilt_jar rules for the downloaded 
dependencies, without the need to handle transitive dependencies manually.
Ivy would also help deploy the generated JARs to Central.
The more I think about it, the more I like the Buck+Ivy combo idea, but it 
requires building a few additional tools… (IDE configuration, release 
script, etc.)
I'm just starting to try Gradle for a project at work, if it goes well, 
maybe I'll experiment with it on GWT (first step: replace Ant with Gradle, 
then possibly modularize in the same way I did it with Buck, without moving 
files, then we could decide the best file/folder layout for both Gradle and 
Google)

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

[Ray Cromwell]

Direct IDE still has benefits. Anytime a change is made to the build file
that requires regenerating the project, you run the risk of not preserving
project settings by overwriting stuff that is stored in those files that is
not part of the build, unless your generator has surgical capabiltiy (like
the IDE does).

IntelliJ has surgical Maven capability. If you import some dependency, it
can automatically offer to add it to a pom file, and if you edit the pom
file, it can automatically update the build dependencies in the IDE file.
It's just faster roundtripping.

That said, I am not opposed to writing a plugin or genrule for Buck to do
this. I would only say that if we are going to move to Buck, a prerequisite
is that we restructure the code the way Thomas has been moving to work more
like it does in Google3. Instead of one 'dev' dir and one 'user' dir, each
subdirectory that houses a major component should have a build file in it.
I should be able to rebuild say, the javac/jdt stuff without rebuilding all
of gwt-dev while developing. Things need to be more modular.



On Thu, Sep 26, 2013 at 3:35 PM, Brian Slesinsky wrote:

>
> On Thu, Sep 26, 2013 at 10:26 AM, Jens  wrote:
>
>>
>>>   In terms of Gradle vs Buck models, is there any possibility of writing
>>> a tool that takes a Buck build file and produces Gradle files? That would
>>> seem like a good option in lieu of waiting for Buck support in IntelliJ and
>>> Eclipse. This isn't to say I have anything against Buck, it is literally a
>>> clone of Google's BUILD system, and so that would actually help us to have
>>> just one set of build files for internal vs external. However, it would be
>>> nice not to have to hack the IDE stuff manually.
>>>
>>> If Buck is like Google's BUILD, then a genrule could be used to download
>>> dependencies from Maven repos. ;-)
>>>
>>
>> Shouldn't it be the other way around? A Gradle plugin that generates
>> Google build files sounds more logical to me as you have more freedom to
>> adjust the generated files to your internal system. Outside Google no one
>> will really use these buck/internal build scripts anyways (lack of IDE
>> support).
>>
>
> I don't think direct IDE support for the build system is necessary so long
> as we can generate correct IDEA and Eclipse projects via commands that
> everyone can run, sort of like the webAppCreator command. The real question
> is what language we want the project definitions to be in; it should be
> something easy to understand, edit, and generate other representations from.
>
>  --
> 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

[Goktug Gokdogan]

I have been in favor of Buck because that is what most contributors are
already familiar with and can bring their expertise. It is already proved
to work well with gwt.
Also the compiler speed optimizations are done and experimented based on
the architecture of Buck; especially new stuff that John is working on.
That might be another advantage as our assumptions may or may not hold for
other systems like maven.


On Thu, Sep 26, 2013 at 3:35 PM, Brian Slesinsky wrote:

>
> On Thu, Sep 26, 2013 at 10:26 AM, Jens  wrote:
>
>>
>>>   In terms of Gradle vs Buck models, is there any possibility of writing
>>> a tool that takes a Buck build file and produces Gradle files? That would
>>> seem like a good option in lieu of waiting for Buck support in IntelliJ and
>>> Eclipse. This isn't to say I have anything against Buck, it is literally a
>>> clone of Google's BUILD system, and so that would actually help us to have
>>> just one set of build files for internal vs external. However, it would be
>>> nice not to have to hack the IDE stuff manually.
>>>
>>> If Buck is like Google's BUILD, then a genrule could be used to download
>>> dependencies from Maven repos. ;-)
>>>
>>
>> Shouldn't it be the other way around? A Gradle plugin that generates
>> Google build files sounds more logical to me as you have more freedom to
>> adjust the generated files to your internal system. Outside Google no one
>> will really use these buck/internal build scripts anyways (lack of IDE
>> support).
>>
>
> I don't think direct IDE support for the build system is necessary so long
> as we can generate correct IDEA and Eclipse projects via commands that
> everyone can run, sort of like the webAppCreator command. The real question
> is what language we want the project definitions to be in; it should be
> something easy to understand, edit, and generate other representations from.
>
>  --
> 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

[Brian Slesinsky]

On Thu, Sep 26, 2013 at 10:26 AM, Jens  wrote:

>
>>   In terms of Gradle vs Buck models, is there any possibility of writing
>> a tool that takes a Buck build file and produces Gradle files? That would
>> seem like a good option in lieu of waiting for Buck support in IntelliJ and
>> Eclipse. This isn't to say I have anything against Buck, it is literally a
>> clone of Google's BUILD system, and so that would actually help us to have
>> just one set of build files for internal vs external. However, it would be
>> nice not to have to hack the IDE stuff manually.
>>
>> If Buck is like Google's BUILD, then a genrule could be used to download
>> dependencies from Maven repos. ;-)
>>
>
> Shouldn't it be the other way around? A Gradle plugin that generates
> Google build files sounds more logical to me as you have more freedom to
> adjust the generated files to your internal system. Outside Google no one
> will really use these buck/internal build scripts anyways (lack of IDE
> support).
>

I don't think direct IDE support for the build system is necessary so long
as we can generate correct IDEA and Eclipse projects via commands that
everyone can run, sort of like the webAppCreator command. The real question
is what language we want the project definitions to be in; it should be
something easy to understand, edit, and generate other representations from.

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

[Ray Cromwell]

It really depends on what Thomas or contributors are going to do, I don't
think we have any bandwidth on the GWT team to work on this right now ;-)



On Thu, Sep 26, 2013 at 10:26 AM, Jens  wrote:

>
>>   In terms of Gradle vs Buck models, is there any possibility of writing
>> a tool that takes a Buck build file and produces Gradle files? That would
>> seem like a good option in lieu of waiting for Buck support in IntelliJ and
>> Eclipse. This isn't to say I have anything against Buck, it is literally a
>> clone of Google's BUILD system, and so that would actually help us to have
>> just one set of build files for internal vs external. However, it would be
>> nice not to have to hack the IDE stuff manually.
>>
>> If Buck is like Google's BUILD, then a genrule could be used to download
>> dependencies from Maven repos. ;-)
>>
>
> Shouldn't it be the other way around? A Gradle plugin that generates
> Google build files sounds more logical to me as you have more freedom to
> adjust the generated files to your internal system. Outside Google no one
> will really use these buck/internal build scripts anyways (lack of IDE
> support).
>
> -- 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

[Jens]

>
>
>   In terms of Gradle vs Buck models, is there any possibility of writing a 
> tool that takes a Buck build file and produces Gradle files? That would 
> seem like a good option in lieu of waiting for Buck support in IntelliJ and 
> Eclipse. This isn't to say I have anything against Buck, it is literally a 
> clone of Google's BUILD system, and so that would actually help us to have 
> just one set of build files for internal vs external. However, it would be 
> nice not to have to hack the IDE stuff manually.
>
> If Buck is like Google's BUILD, then a genrule could be used to download 
> dependencies from Maven repos. ;-)
>

Shouldn't it be the other way around? A Gradle plugin that generates Google 
build files sounds more logical to me as you have more freedom to adjust 
the generated files to your internal system. Outside Google no one will 
really use these buck/internal build scripts anyways (lack of IDE support).

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

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

[Ray Cromwell]

Thomas,
  In terms of Gradle vs Buck models, is there any possibility of writing a
tool that takes a Buck build file and produces Gradle files? That would
seem like a good option in lieu of waiting for Buck support in IntelliJ and
Eclipse. This isn't to say I have anything against Buck, it is literally a
clone of Google's BUILD system, and so that would actually help us to have
just one set of build files for internal vs external. However, it would be
nice not to have to hack the IDE stuff manually.

If Buck is like Google's BUILD, then a genrule could be used to download
dependencies from Maven repos. ;-)



On Wed, Sep 25, 2013 at 10:26 AM, Thomas Broyer  wrote:

>
>
> On Wednesday, September 25, 2013 6:20:19 PM UTC+2, Ray Cromwell wrote:
>>
>>
>> The biggest problem with being a GWT contributor today is that it is
>> hard, very hard, to set up an environment to develop. If you look at the
>> original GWT instructions for Eclipse, and that was *with* already provided
>> .project/.classpath files, it was ridiculous. Starting from scratch is even
>> harder.
>>
>> My dream for mavenization was
>> a) fixing the spaghetti soup of cyclic dependencies so that IDEs would
>> have less trouble modeling the project layout
>> b) having a cross IDE platform representation of the project
>>
>
> +1
>
>
>> The way GWT exists today, after years of working with it, requires me to
>> spend over an hour configuring a new IntelliJ project from scratch if I
>> want to do it right, be able to develop both user and dev, be able to run
>> unit tests in the IDE, be able to debug the compiler in the IDE, etc.
>>
>> Ant is fine for command line builds, but it sucks for a) and b), and its
>> flexibility has allowed the GWT source tree to have a structure that would
>> not be tolerated by other build tools -- sometimes too much power is bad. I
>> don't have any particular love for Maven, I'd be fine with Buck or Gradle
>> (IntelliJ seems to have some support for Gradle), but the biggest issue for
>> me is, I don't want to spend an hour fiddling with IDE sub-projects,
>> hand-adding library dependencies (oh wait, which project needs
>> tomcat-jk2.jar?), etc.
>>
>
> Looking at Gradle currently for work, support in Eclipse is rather good
> too. IDE support is much more easily done with Gradle than with Maven,
> because of their design. I'm writing a blog post about my issues with Maven
> that'll talk about that, will publish it soon.
>
> Even on the GWT team at Google, members have taken to rather absurd
>> techniques like creating one working set of IPR/IML files, and copy/pasting
>> them everytime you start a new repository or branch because they have often
>> forget the precise order of magic tricks they used to set up the build the
>> first time.
>>
>
> +1 to what Brian said re. checking the .iml et al. in the Git repo; and
> add Konstantin as a reviewer ;-)
>
> IMHO, here should be how someone contributes to GWT:
>>
>> git clone http://some-repo
>> IDE open-project some-repo
>> git branch
>> hack hack hack
>> run tests/debug in IDE
>> git commit
>> git push
>>
>> Any more steps than that and I think you've lost.
>>
>
> +1
>
> (OK, I wouldn't mind an intermediate "download dependencies once and for
> all" after the "git clone" if needed; oh, and you should probalby do a
> command-line build –or at least using "the build tool"– before pushing, but
> that's a detail, and the current state of the Ant build is the main reason
> I don't do it today)
>
> --
> 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

[Thomas Broyer]

On Thursday, September 26, 2013 1:47:22 AM UTC+2, Cristiano wrote:
>
> 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?
>

I'm running Ubuntu (13.04).
You have to do a symlink from gwt_tools to your GWT_TOOLS svn checkout, and 
build gwt-dev first using Ant. Then you should be able to "buck build 
//user:user". I'll add that to the commit message when I'll update the 
review.

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

[Thomas Broyer]

On Wednesday, September 25, 2013 6:20:19 PM UTC+2, Ray Cromwell wrote:
>
>
> The biggest problem with being a GWT contributor today is that it is hard, 
> very hard, to set up an environment to develop. If you look at the original 
> GWT instructions for Eclipse, and that was *with* already provided 
> .project/.classpath files, it was ridiculous. Starting from scratch is even 
> harder. 
>
> My dream for mavenization was 
> a) fixing the spaghetti soup of cyclic dependencies so that IDEs would 
> have less trouble modeling the project layout
> b) having a cross IDE platform representation of the project
>

+1
 

> The way GWT exists today, after years of working with it, requires me to 
> spend over an hour configuring a new IntelliJ project from scratch if I 
> want to do it right, be able to develop both user and dev, be able to run 
> unit tests in the IDE, be able to debug the compiler in the IDE, etc.
>
> Ant is fine for command line builds, but it sucks for a) and b), and its 
> flexibility has allowed the GWT source tree to have a structure that would 
> not be tolerated by other build tools -- sometimes too much power is bad. I 
> don't have any particular love for Maven, I'd be fine with Buck or Gradle 
> (IntelliJ seems to have some support for Gradle), but the biggest issue for 
> me is, I don't want to spend an hour fiddling with IDE sub-projects, 
> hand-adding library dependencies (oh wait, which project needs 
> tomcat-jk2.jar?), etc.
>

Looking at Gradle currently for work, support in Eclipse is rather good 
too. IDE support is much more easily done with Gradle than with Maven, 
because of their design. I'm writing a blog post about my issues with Maven 
that'll talk about that, will publish it soon.

Even on the GWT team at Google, members have taken to rather absurd 
> techniques like creating one working set of IPR/IML files, and copy/pasting 
> them everytime you start a new repository or branch because they have often 
> forget the precise order of magic tricks they used to set up the build the 
> first time.
>

+1 to what Brian said re. checking the .iml et al. in the Git repo; and add 
Konstantin as a reviewer ;-)

IMHO, here should be how someone contributes to GWT:
>
> git clone http://some-repo
> IDE open-project some-repo
> git branch
> hack hack hack
> run tests/debug in IDE
> git commit
> git push
>
> Any more steps than that and I think you've lost.
>

+1

(OK, I wouldn't mind an intermediate "download dependencies once and for 
all" after the "git clone" if needed; oh, and you should probalby do a 
command-line build –or at least using "the build tool"– before pushing, but 
that's a detail, and the current state of the Ant build is the main reason 
I don't do it today)

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

[Brian Slesinsky]

As a stop-gap measure, can you clean up and check in your IDEA module(s)?

- Brian

On Wed, Sep 25, 2013 at 9:20 AM, Ray Cromwell wrote:

>
> The biggest problem with being a GWT contributor today is that it is hard,
> very hard, to set up an environment to develop. If you look at the original
> GWT instructions for Eclipse, and that was *with* already provided
> .project/.classpath files, it was ridiculous. Starting from scratch is even
> harder.
>
> My dream for mavenization was
> a) fixing the spaghetti soup of cyclic dependencies so that IDEs would
> have less trouble modeling the project layout
> b) having a cross IDE platform representation of the project
>
> The way GWT exists today, after years of working with it, requires me to
> spend over an hour configuring a new IntelliJ project from scratch if I
> want to do it right, be able to develop both user and dev, be able to run
> unit tests in the IDE, be able to debug the compiler in the IDE, etc.
>
> Ant is fine for command line builds, but it sucks for a) and b), and its
> flexibility has allowed the GWT source tree to have a structure that would
> not be tolerated by other build tools -- sometimes too much power is bad. I
> don't have any particular love for Maven, I'd be fine with Buck or Gradle
> (IntelliJ seems to have some support for Gradle), but the biggest issue for
> me is, I don't want to spend an hour fiddling with IDE sub-projects,
> hand-adding library dependencies (oh wait, which project needs
> tomcat-jk2.jar?), etc.
>
> Even on the GWT team at Google, members have taken to rather absurd
> techniques like creating one working set of IPR/IML files, and copy/pasting
> them everytime you start a new repository or branch because they have often
> forget the precise order of magic tricks they used to set up the build the
> first time.
>
> IMHO, here should be how someone contributes to GWT:
>
> git clone http://some-repo
> IDE open-project some-repo
> git branch
>  hack hack hack
> run tests/debug in IDE
> git commit
> git push
>
> Any more steps than that and I think you've lost.
>
>
>
>
> On Wed, Sep 25, 2013 at 1:32 AM, Thomas Broyer  wrote:
>
>>
>>
>> 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 alwa

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

[Ray Cromwell]

The biggest problem with being a GWT contributor today is that it is hard,
very hard, to set up an environment to develop. If you look at the original
GWT instructions for Eclipse, and that was *with* already provided
.project/.classpath files, it was ridiculous. Starting from scratch is even
harder.

My dream for mavenization was
a) fixing the spaghetti soup of cyclic dependencies so that IDEs would have
less trouble modeling the project layout
b) having a cross IDE platform representation of the project

The way GWT exists today, after years of working with it, requires me to
spend over an hour configuring a new IntelliJ project from scratch if I
want to do it right, be able to develop both user and dev, be able to run
unit tests in the IDE, be able to debug the compiler in the IDE, etc.

Ant is fine for command line builds, but it sucks for a) and b), and its
flexibility has allowed the GWT source tree to have a structure that would
not be tolerated by other build tools -- sometimes too much power is bad. I
don't have any particular love for Maven, I'd be fine with Buck or Gradle
(IntelliJ seems to have some support for Gradle), but the biggest issue for
me is, I don't want to spend an hour fiddling with IDE sub-projects,
hand-adding library dependencies (oh wait, which project needs
tomcat-jk2.jar?), etc.

Even on the GWT team at Google, members have taken to rather absurd
techniques like creating one working set of IPR/IML files, and copy/pasting
them everytime you start a new repository or branch because they have often
forget the precise order of magic tricks they used to set up the build the
first time.

IMHO, here should be how someone contributes to GWT:

git clone http://some-repo
IDE open-project some-repo
git branch
hack hack hack
run tests/debug in IDE
git commit
git push

Any more steps than that and I think you've lost.




On Wed, Sep 25, 2013 at 1:32 AM, Thomas Broyer  wrote:

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

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

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

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.

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

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

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

[Thomas Broyer]

On Tuesday, September 24, 2013 5:48:03 PM UTC+2, Cristiano wrote:
>
>
> 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...
>

http://blog.ltgt.net/in-quest-of-the-ultimate-build-tool/ is a good start. 
The main issues are the linear lifecycle, badly integrated with reactor 
builds, and lack of clean incremental builds (particularly with reactor 
builds, especially when you want to run tests rather than just package). 
Also, I came to dislike the src/main/java vs. src/main/resources dichotomy.
 

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

I stopped because I lack time, and I think the approach was wrong. Ongoing 
work is at https://gwt-review.googlesource.com/3741 (and previous patch): 
first cleanly "modularize" the gwt.xml without moving files, then only move 
files and mavenize.
The work done there is still valid though (and gwt-dev is ready).

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

[John A. Tamplin]

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.

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.

YMMV of course.

-- 
John A. Tamplin

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

[gwt-contrib] Re: Maven-ization Status

[Thomas Broyer]

On Tuesday, September 24, 2013 2:41:10 PM UTC+2, Cristiano wrote:
>
> Hi folks,
> I read and hear about the Maven-ization of GWT, which is something I would 
> love because I love maven.
>

I used to really like it; not so sure nowadays, therefore exploring Buck 
and Gradle.
 

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

See https://github.com/tbroyer/gwt-sandbox/
Unfortunately very out of date… 

If maven-ization is not moving the build system to maven, can you please 
> kindly explain what it means?


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

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

[Cristiano]

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 
>  
>
> On Sun, Mar 17, 2013 at 5:57 PM, Thomas Broyer 
> > 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 
>> > 
>> 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/ 
>>
>> -- 
>> 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 .
>> 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] Re: Maven-ization Status

[Brandon Donnelson]

Good job!! :)

Have a good day,
Brandon Donnelson
+Follow Me 


On Sun, Mar 17, 2013 at 5:57 PM, Thomas Broyer  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  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/ 
>
> --
> 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+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 
"Google Web Toolkit 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: Maven-ization Status

[Thomas Broyer]

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  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://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit 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: Maven-ization Status

[Thomas Broyer]

On Sunday, March 17, 2013 6:52:06 PM UTC+1, Stevko wrote:
>
> A question concerning the partitioning of the code... Will this exercise 
> help allow for code splitting of the GWT libraries? Even with severe code 
> splitting, I am not able to reduce the initial load size to below a 
> megabyte which is prohibitive for a mobile device.
>

It won't have any impact on code splitting. It *should* help with compile 
time in some cases (reducing the size of the classpath, which GWT scans; 
depending on what you use), but could have the reverse effect if you use 
many libs (explosion of the number of libs, slowing done the classpath 
scanning; but if that's the case we could add workarounds: unpack all 
dependencies into a folder and only use that folder for the classpath of 
the GWT compiler)
 

>
>
> On Sun, Mar 17, 2013 at 5:06 AM, Thomas Broyer 
> > 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…
>>
>> Sigh…
>>
>>
>> On Fri, Mar 15, 2013 at 11:56 AM, Thomas Broyer 
>> 
>> > wrote:
>>
>>>
>>>
>>> On Wednesday, March 13, 2013 5:31:25 PM UTC+1, Ray Cromwell wrote:


 Hey guys,
   Google I/O is almost upon us, and it's been a year since we started 
 GWT steering. I feel like if there's one big thing we could announce this 
 year that people would love, it would be the opening of the external 
 commits combined with mavenization.

>>>
>>> +1
>>>  
>>>
 It seems like we have a number of people interested in rolling up 
 sleeves, and I think if we could finish dis-entanglement, then we could 
 actually work in parallel in doing poms for many of the pieces of it and 
 finish rather quickly.  I volunteer to spend some late nights helping out. 

   Maybe someone could produce a quick status / overview of the current 
 state and what the remaining problems are.

>>>
>>> My goal was to get gwt-junit so we can run the tests in other modules 
>>> (create gwt-core-tests, gwt-rpc-tests, etc. and for the other modules not 
>>> used *by* gwt-junit then simply depend on gwt-junit and run the tests in 
>>> the module itself). I'm almost done but my working tree is a bit of a mess 
>>> (with other things started but unfinished, etc.) Let me get to a clean 
>>> state this week-end and push everything to my gwt-sandbox GitHub repo, then 
>>> we can work in parallel on the remaining modules.
>>> Last I checked, the remaining issue was with gwt-i18n; there are 
>>> intricate dependencies: i18n depends on safehtml, but the SafeHtmlTemplates 
>>> generator uses a base generator that depends on GwtLocale (oh, and 
>>> SafeHtmlUtils depends on c.g.g.http.client.URL, under a GWT.isClient() 
>>> check). I had a discussion with John Tamplin about it back in December (Ray 
>>> you were in copy, it was a private follow-up to the "Disentangle module 
>>> dependencies" review) and he was proposing having I18N (and SafeHtml and 
>>> RequestBuilder, or at least URL) in gwt-core. I'm not opposed to it and 
>>> that would probably simplify a few things; what do you think?
>>>
>>> The next step will be the tools, samples and the SDK distrib (and of 
>>> course continuous integration).
>>> One thing that can be done in parallel with my ongoing work right now is 
>>> to deal with the external dependencies and possibly start deploying the 
>>> missing ones to Central (or another Maven repo as a sandbox), so we can 
>>> reconcile them with the current POMs that use scope=system dependencies.
>>>
>>> As a side-note, I have a new gwt-maven-plugin written from scratch that 
>>> provides gwt-lib and gwt-app packaging with (what I hope are) sensible 
>>> defaults for GWT projects. I would like to move it to GWT proper and use it 
>>> for GWT's own modules *and* release it at the same time as GWT for global 
>>> consumption.
>>> One feature I've added recently is a way to automatically generate a 
>>> gwt.xml file from the Maven dependencies (based on a 
>>> META-INF/gwt/mainModule found in these dependencies), with optional "extra 
>>> inherits" (for those dependencies that don't have the mainModule file or 
>>> that provide more than one module), rename-to and entry-point class. The 
>>> remaining open question is where to put 

[gwt-contrib] Re: Maven-ization Status

[Thomas Broyer]

On Sunday, March 17, 2013 6:26:20 PM UTC+1, Abraham Lin wrote:
>
> On Sunday, March 17, 2013 8:06:00 AM UTC-4, Thomas Broyer wrote:
>>
>> Also, one thing to discuss asap is where to put the sources: say I have 
>>> lib-shared and lib-client, would you bundle the sources of lib-shared into 
>>> the lib-client JAR or rather just have a dependency from lib-client to the 
>>> lib-shared:sources? Would there be an impact on compilation time? For now, 
>>> I used the maven-dependency-plugin to unpack the lib-shared sources into 
>>> lib-client and bundle them in the lib-client JAR; and I have a similar 
>>> thing done automatically in the gwt-maven-plugin (just use a dependency 
>>> with type=java-source and it'll be unpacked and bundled; type=java-source 
>>> dependencies are not transitive, contrary to classifier=sources ones, 
>>> whereas resolving to the same JAR in the repository). Moving to the 
>>> gwt-maven-plugin would simply the POMs a lot, but if we prefer not bundling 
>>> them in the lib-client JAR, then we can simplify the POMs without 
>>> necessarily using the gwt-maven-plugin, and I can possibly removing the 
>>> feature from the plugin.
>>>
>>  
> For my company, I created a new "gwt-jar" packaging type that contains 
> both the compiled class files and the source files. In addition, I created 
> two new artifact types: gwt-module (for client code) and shared-module (for 
> shared code). The former generates a gwt-jar, whereas the latter produces 
> both a generic jar (i.e. no sources files) and a gwt-jar. Client modules 
> then declare dependencies to the gwt-jar versions of shared dependencies, 
> while server modules declare dependencies to the shared-module versions.
>
> The major drawback of this approach is that you need two 
> dependencyManagement entries per shared module, but this could be worked 
> around if the plugin automatically resolves the gwt-jar version of every 
> shared-module dependency.
>

The problem with a "shared lib" producing 2 artifacts is that your non-gwt 
code doesn't need a dependency on a gwt-jar, whereas your gwt code needs 
it. For instance, requestfactory depends on events and autobeans; on 
Android you only need the "VM" implementations, whereas on GWT you need the 
gwt-jars; even if you depend on requestfactory with classifier=gwt or 
type=gwt-jar, you won't have an automatic dependency on event or autobean 
with the same classifier or type. That's just not the Maven Way™ or doing 
things (rule of thumb: one POM == one artifact).
The way I do it is to have requestfactory depend on event and autobean, and 
a requestfactory-gwt depend on requestfactory, event-gwt and autobean-gwt 
(and thus transitively on event and autobean). It gives you a "diamond" 
dependency graph.

Not sure if this is really the best way to handle the situation, but maybe 
> there are some ideas that are worth considering.
>

That's what I'm doing in my gwt-maven-plugin: gwt-lib and gwt-app 
packagings.

-- 
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit 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: Maven-ization Status

[Abraham Lin]

On Sunday, March 17, 2013 8:06:00 AM UTC-4, Thomas Broyer wrote:
>
> Also, one thing to discuss asap is where to put the sources: say I have 
>> lib-shared and lib-client, would you bundle the sources of lib-shared into 
>> the lib-client JAR or rather just have a dependency from lib-client to the 
>> lib-shared:sources? Would there be an impact on compilation time? For now, 
>> I used the maven-dependency-plugin to unpack the lib-shared sources into 
>> lib-client and bundle them in the lib-client JAR; and I have a similar 
>> thing done automatically in the gwt-maven-plugin (just use a dependency 
>> with type=java-source and it'll be unpacked and bundled; type=java-source 
>> dependencies are not transitive, contrary to classifier=sources ones, 
>> whereas resolving to the same JAR in the repository). Moving to the 
>> gwt-maven-plugin would simply the POMs a lot, but if we prefer not bundling 
>> them in the lib-client JAR, then we can simplify the POMs without 
>> necessarily using the gwt-maven-plugin, and I can possibly removing the 
>> feature from the plugin.
>>
>  
For my company, I created a new "gwt-jar" packaging type that contains both 
the compiled class files and the source files. In addition, I created two 
new artifact types: gwt-module (for client code) and shared-module (for 
shared code). The former generates a gwt-jar, whereas the latter produces 
both a generic jar (i.e. no sources files) and a gwt-jar. Client modules 
then declare dependencies to the gwt-jar versions of shared dependencies, 
while server modules declare dependencies to the shared-module versions.

The major drawback of this approach is that you need two 
dependencyManagement entries per shared module, but this could be worked 
around if the plugin automatically resolves the gwt-jar version of every 
shared-module dependency.

Not sure if this is really the best way to handle the situation, but maybe 
there are some ideas that are worth considering.

-- 
-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit 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: Maven-ization Status

[Andy Stevko]

A question concerning the partitioning of the code... Will this exercise
help allow for code splitting of the GWT libraries? Even with severe code
splitting, I am not able to reduce the initial load size to below a
megabyte which is prohibitive for a mobile device.


On Sun, Mar 17, 2013 at 5:06 AM, Thomas Broyer  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…
>
> Sigh…
>
>
> On Fri, Mar 15, 2013 at 11:56 AM, Thomas Broyer wrote:
>
>>
>>
>> On Wednesday, March 13, 2013 5:31:25 PM UTC+1, Ray Cromwell wrote:
>>>
>>>
>>> Hey guys,
>>>   Google I/O is almost upon us, and it's been a year since we started
>>> GWT steering. I feel like if there's one big thing we could announce this
>>> year that people would love, it would be the opening of the external
>>> commits combined with mavenization.
>>>
>>
>> +1
>>
>>
>>> It seems like we have a number of people interested in rolling up
>>> sleeves, and I think if we could finish dis-entanglement, then we could
>>> actually work in parallel in doing poms for many of the pieces of it and
>>> finish rather quickly.  I volunteer to spend some late nights helping out.
>>>
>>>   Maybe someone could produce a quick status / overview of the current
>>> state and what the remaining problems are.
>>>
>>
>> My goal was to get gwt-junit so we can run the tests in other modules
>> (create gwt-core-tests, gwt-rpc-tests, etc. and for the other modules not
>> used *by* gwt-junit then simply depend on gwt-junit and run the tests in
>> the module itself). I'm almost done but my working tree is a bit of a mess
>> (with other things started but unfinished, etc.) Let me get to a clean
>> state this week-end and push everything to my gwt-sandbox GitHub repo, then
>> we can work in parallel on the remaining modules.
>> Last I checked, the remaining issue was with gwt-i18n; there are
>> intricate dependencies: i18n depends on safehtml, but the SafeHtmlTemplates
>> generator uses a base generator that depends on GwtLocale (oh, and
>> SafeHtmlUtils depends on c.g.g.http.client.URL, under a GWT.isClient()
>> check). I had a discussion with John Tamplin about it back in December (Ray
>> you were in copy, it was a private follow-up to the "Disentangle module
>> dependencies" review) and he was proposing having I18N (and SafeHtml and
>> RequestBuilder, or at least URL) in gwt-core. I'm not opposed to it and
>> that would probably simplify a few things; what do you think?
>>
>> The next step will be the tools, samples and the SDK distrib (and of
>> course continuous integration).
>> One thing that can be done in parallel with my ongoing work right now is
>> to deal with the external dependencies and possibly start deploying the
>> missing ones to Central (or another Maven repo as a sandbox), so we can
>> reconcile them with the current POMs that use scope=system dependencies.
>>
>> As a side-note, I have a new gwt-maven-plugin written from scratch that
>> provides gwt-lib and gwt-app packaging with (what I hope are) sensible
>> defaults for GWT projects. I would like to move it to GWT proper and use it
>> for GWT's own modules *and* release it at the same time as GWT for global
>> consumption.
>> One feature I've added recently is a way to automatically generate a
>> gwt.xml file from the Maven dependencies (based on a
>> META-INF/gwt/mainModule found in these dependencies), with optional "extra
>> inherits" (for those dependencies that don't have the mainModule file or
>> that provide more than one module), rename-to and entry-point class. The
>> remaining open question is where to put the rest of the module
>> configuration: either have a src/main/module.gwt.xml and merge the
>> "inherits from dependencies" in it (and remove the "extra inherits" and
>> entry-point from the POM configuration; the "short module name" can still
>> be useful for application packaging), or put everything in the POM. For now
>> I generate a minimal gwt.xml, and if you want more you just disable the
>> generation and provide the full module yourself (and lose the "inherits
>> from dependencies" feature).
>> You can check it out at https://github.com/tbroyer/gwt-maven-plugin and
>> I intend to release an alpha this week-end so people can start evaluating
>> it. The earlier we 

[gwt-contrib] Re: Maven-ization Status

[Thomas Broyer]

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

Sigh…


On Fri, Mar 15, 2013 at 11:56 AM, Thomas Broyer  wrote:

>
>
> On Wednesday, March 13, 2013 5:31:25 PM UTC+1, Ray Cromwell wrote:
>>
>>
>> Hey guys,
>>   Google I/O is almost upon us, and it's been a year since we started GWT
>> steering. I feel like if there's one big thing we could announce this year
>> that people would love, it would be the opening of the external commits
>> combined with mavenization.
>>
>
> +1
>
>
>> It seems like we have a number of people interested in rolling up
>> sleeves, and I think if we could finish dis-entanglement, then we could
>> actually work in parallel in doing poms for many of the pieces of it and
>> finish rather quickly.  I volunteer to spend some late nights helping out.
>>
>>   Maybe someone could produce a quick status / overview of the current
>> state and what the remaining problems are.
>>
>
> My goal was to get gwt-junit so we can run the tests in other modules
> (create gwt-core-tests, gwt-rpc-tests, etc. and for the other modules not
> used *by* gwt-junit then simply depend on gwt-junit and run the tests in
> the module itself). I'm almost done but my working tree is a bit of a mess
> (with other things started but unfinished, etc.) Let me get to a clean
> state this week-end and push everything to my gwt-sandbox GitHub repo, then
> we can work in parallel on the remaining modules.
> Last I checked, the remaining issue was with gwt-i18n; there are intricate
> dependencies: i18n depends on safehtml, but the SafeHtmlTemplates generator
> uses a base generator that depends on GwtLocale (oh, and SafeHtmlUtils
> depends on c.g.g.http.client.URL, under a GWT.isClient() check). I had a
> discussion with John Tamplin about it back in December (Ray you were in
> copy, it was a private follow-up to the "Disentangle module dependencies"
> review) and he was proposing having I18N (and SafeHtml and RequestBuilder,
> or at least URL) in gwt-core. I'm not opposed to it and that would probably
> simplify a few things; what do you think?
>
> The next step will be the tools, samples and the SDK distrib (and of
> course continuous integration).
> One thing that can be done in parallel with my ongoing work right now is
> to deal with the external dependencies and possibly start deploying the
> missing ones to Central (or another Maven repo as a sandbox), so we can
> reconcile them with the current POMs that use scope=system dependencies.
>
> As a side-note, I have a new gwt-maven-plugin written from scratch that
> provides gwt-lib and gwt-app packaging with (what I hope are) sensible
> defaults for GWT projects. I would like to move it to GWT proper and use it
> for GWT's own modules *and* release it at the same time as GWT for global
> consumption.
> One feature I've added recently is a way to automatically generate a
> gwt.xml file from the Maven dependencies (based on a
> META-INF/gwt/mainModule found in these dependencies), with optional "extra
> inherits" (for those dependencies that don't have the mainModule file or
> that provide more than one module), rename-to and entry-point class. The
> remaining open question is where to put the rest of the module
> configuration: either have a src/main/module.gwt.xml and merge the
> "inherits from dependencies" in it (and remove the "extra inherits" and
> entry-point from the POM configuration; the "short module name" can still
> be useful for application packaging), or put everything in the POM. For now
> I generate a minimal gwt.xml, and if you want more you just disable the
> generation and provide the full module yourself (and lose the "inherits
> from dependencies" feature).
> You can check it out at https://github.com/tbroyer/gwt-maven-plugin and I
> intend to release an alpha this week-end so people can start evaluating it.
> The earlier we use it in GWT, the simpler the POMs will be, saving us a few
> hours of work (and we'll have an official Maven plugin, even if
> experimental in the first few releases).
>
> Also, one thing to discuss asap is where to put the sources: say I have
> lib-shared and lib-client, would you bundle the sources of lib-shared into
> the lib-client JAR or rather just have a dependency from lib-client to the
> lib-shared:sources? Wou