Issue No 84

[click]

Hi there!

I would be interested in contibuting code that solves the problem with
issue 84
(http://code.google.com/p/gwt-maven/issues/detail?id=84) for Windows
computers. I am not 100% sure how much same problem affects Linux
(Unix) OS too but it is worth looking into it, too.

Solution is permanent and is tested in internal build I had to fix it
for.

Regards,
Click

[Charlie Collins]

Send me your gmail account id (required for Google code, I think), and
I will make you a project member. Then you can work on and submit to
SVN, we welcome the help.

[Charlie Collins]

Wait, you are still welcome to join, but I am pretty sure that
particular issue is already fixed in SVN.

[click]

Thanks - I will give it a go with the latest from the repository, but
when I checked the latest (then 2.0-beta9) it didn't work and it was
pretty obvious why it doesn't :(

[click]

I have just tested it with 2.0-beta12 and the problem still persist. I
do not mind explaining it in greated detail if someone is interested -
but in the mean time at least good thing is that there is a fix if you
are interested!

Will send you my account id shortly! :)

[Charlie Collins]

Just to update the group, I added click (daniel) as a member,
hopefully with some help we can iron out the spaces-Windows issues.

[click]

Sorry for not being able to react sooner. I have committed new version
of ScriptWriterWinodws with code for compilation. Now class path
length doesn't matter as it is written to a file and read by new
'ClasspathInvoker' class.

Unfortunately same doesn't work for running GWT from the plugin due to
classpath(!) problems. I suspect that either I was picking wrong
classpath (compile against runtime?) or embedded Tomcat doesn't like
being invoked this way due to some other reason. Or it is just my
project being awkward is some way to affect it. No idea... Anyway, I
have left my code in the committed class although it is not used at
the moment.

I will look more into this issue in following days but all ideas are
more the appreciated.

[Jamie Whitehouse]

On Apr 1, 9:42 am, click <dan...@sendula.com> wrote:

> Hi there!
>
> I would be interested in contibuting code that solves the problem with
> issue 84
> (http://code.google.com/p/gwt-maven/issues/detail?id=84) for Windows
> computers.

I just tackled this last night as well. I haven't looked at your code
(Click), but here's what I did:
Instead of using a script file to invoke the compiler and move files
around (for 1.5 M1) I used a process to do the same thing
(Runtime.exec) and normal Java file manipulation. Originally I
started with ProcessBuilder to replace the ScriptWriter but then
realised that there was already a 'ProcessWatcher' as part of the code
base so I just used that. This change works for both Windows and
Linux, and in fact replaces both ScriptWriter.writeCompileScript
methods. I don't have a Mac to test on but I used the 'gwt.os' trick
along with printing out the command output for manual verification.
Once I was satisfied I removed that bit of debugging code.

I've uploaded the single class to the group for submission into the
source tree: http://groups.google.com/group/gwt-maven/web/CompileUsingJavaMojo.java.
Charlie, is that a reasonable way to have this reviewed? BTW: I used
a different goal name 'compileNg' for my use to not conflict with the
old way, but I'd prefer that this be changed to the 'compile' goal if
accepted.

Cheers,
Jamie.

[Jamie Whitehouse]

BTW: this file was created based on the r603 from Subversion
(beta15ish).

On May 1, 10:08 am, Jamie Whitehouse <basil.whiteho...@gmail.com>
wrote:

[Charlie Collins]

Contributions are much appreciated, and that's a perfect way to get it
reviewed. I took a quick look at that code and it looks fine to me, I
like the approach too (didn't have time to run it mind you, real busy
at the moment with JavaOne and Google I/O coming up).

Also, in general, if you think something works and is ready to go,
feel free to commit it (it's only the trunk after all, not a release,
and especially if you made a new experimental goal). Our philosophy
here is sort of anyone that wants to contribute can, and if we have to
rollback we will rollback (it's all in SVN - though we need to start
using tags better). Because we aren't all full time dedicated to this
project, effort sort of comes in bursts - hard to have to wait around
with disparate schedules.

Basically the bottom line is, once you are committer (and anyone who
expresses interest can get that status) you can commit as you see fit.
We do appreciate testing, and being diligent so as not to break
everything and so on - but we also understand mistakes occur - and
unless someone repeatedly screws up stuff, or otherwise demonstrates
they really just don't know what they are doing, they can commit and
will remain committers. I know this is a lenient policy and some might
not prefer it, but it has worked on this and other projects in the
past, and we really don't have the capacity to do it differently -
really only interested people get involved anyway, no one is usually
malicious or incompetent, and if either of those things did occur we
could rollback.

Don't get me wrong, if you are more comfortable with a review, that
works too, just saying do it as you see fit, and we appreciate it
however we can get it ;). (Just don't always expect a review response
right away.)

Thanks again Jamie,

On May 1, 10:08 am, Jamie Whitehouse <basil.whiteho...@gmail.com>
wrote:

[Jamie Whitehouse]

On May 1, 1:51 pm, Charlie Collins <charlie.coll...@gmail.com> wrote:
> Contributions are much appreciated, and that's a perfect way to get it
> reviewed. I took a quick look at that code and it looks fine to me, I
> like the approach too (didn't have time to run it mind you, real busy
> at the moment with JavaOne and Google I/O coming up).

> Basically the bottom line is, once you are committer (and anyone who
> expresses interest can get that status) you can commit as you see fit.

Great, can you add me to the committers list?
I didn't want to step on any toes, but I'd be interested in having the
change in the next release as the default 'compile' goal. Is that
something I should integrate, or have one of the "Project Owners" do?

As well, who performs the actual releases?

> Don't get me wrong, if you are more comfortable with a review, that
> works too, just saying do it as you see fit, and we appreciate it
> however we can get it ;). (Just don't always expect a review response
> right away.)

For some changes I may prefer a review to ensure they're inline with
the projects direction. If you're comfortable with no review that's
okay with me as well.

> Thanks again Jamie,

You're welcome.

[Charlie Collins]

Added you.

As for official releases, those are sort of seat of the pants too.
Usually Cooper, Will, or I, do them - but no reason anybody else
can't . We used to use the Wiki pages to discuss features in next
release - etc, which was good, but that hasn't happened a lot lately
either. I guess again the bottom line is whomever is willing and
enable can go for it.

On May 1, 3:23 pm, Jamie Whitehouse <basil.whiteho...@gmail.com>