2.0-beta24 release announcement

[Charlie Collins]

Some minor enhancements are present in 2.0-beta24 - hence the new
release.

Merged web.xml servlet path OPTIONALLY left alone
http://code.google.com/p/gwt-maven/issues/detail?id=129

Different URL mapping for shell servlet -
http://code.google.com/p/gwt-maven/issues/detail?id=134

Leopard test patch -
http://code.google.com/p/gwt-maven/issues/detail?id=155

Provided deps for shell -
http://code.google.com/p/gwt-maven/issues/detail?id=159

Filter web war resources -
http://code.google.com/p/gwt-maven/issues/detail?id=160

Also note that the support jar was upped to 1.6.1 to support the merge
and shell servlet features, and now handles JDOM 1.1 from central repo
(no special repo there anymore - most won't notice this either way,
but nice for those that do get into it).

And, all the samples, docs, archetype were updated to include up to
date info and a few tweaks to the default poms (archetype version is
now 1.0.1).

Mega mucho props to all those that submitted issue reports and patches
in the forums and tracker.

[Charlie Collins]

Need some feedback on the scope runtime/provided/compile thing. I
took the advice of a few others here and changed the
@requiresDependencyResolution in GwtMojo BACK to "compile." Comparing
the commit notes and diffs I now realize that I have changed that back
and forth now several times.

I changed a few deps in some of my projects that really should have
been "provided" (like commons dbcp - provided by the container I use,
but needed for the shell and for tests, etc) to provided, and it WORKS
FINE with 2.0-beta24 - but, I bet we will start hearing from others
now that "runtime" scoped deps are not available in the shell.

And, they aren't. Compile gives us compile and provided in the shell,
but NOT runtime. What do we really need there though, that is the
question. Is that really "runtime" AND "compile" - is it special,
like other GWTisms?

I would like to have the community chime in on this one, what dep
scopes should the shell support. We can change the plugin to support
whatever (we can even make it bastardize the maven standard and
include runtime and compile together, just for the shell), I just need
to sort of have an idea of what people this is required, and why.

For my own purposes "provided" seems to make more sense, but some
others may have runtime deps they need in the shell?

On Oct 2, 3:37 pm, Charlie Collins <charlie.coll...@gmail.com> wrote:
> Some minor enhancements are present in 2.0-beta24 - hence the new
> release.
>

> Merged web.xml servlet path OPTIONALLY left alonehttp://code.google.com/p/gwt-maven/issues/detail?id=129

>
> Different URL mapping for shell servlet -http://code.google.com/p/gwt-maven/issues/detail?id=134
>

> Leopard test patch -http://code.google.com/p/gwt-maven/issues/detail?id=155
>
> Provided deps for shell -http://code.google.com/p/gwt-maven/issues/detail?id=159
>
> Filter web war resources -http://code.google.com/p/gwt-maven/issues/detail?id=160

[eldzi]

Well I guess we need all of them in shell - compile, runtime and
provided. The only thing with provided scope is that we are not able
to "provide" jars for shell in another way than modified classpath
pointing to maven repo (or probably somewhere else - but then hacking
comes :). In deployment time it is already in container so we don't
care.

On 3. Okt, 02:21 h., Charlie Collins <charlie.coll...@gmail.com>
wrote:

[Mirko Nasato]

2008/10/3 Charlie Collins <charlie...@gmail.com>

And, they aren't.  Compile gives us compile and provided in the shell,
but NOT runtime.  What do we really need there though, that is the
question.  Is that really "runtime" AND "compile" - is it special,
like other GWTisms?

Uhm maybe yes, because the shell is running the app deployed in a server - so "runtime" deps should be available - but it's also doing automatic recompilation - so it needs "compile" ones too.

Cheers

Mirko

[Charlie Collins]

Ok, that's what I thought you guys would say, but it's gonna be a pain
to do. Or maybe not, we'll see. The thing is, the
@requiresDependencyResolution annotation can only be one or the other,
and then the mojo only has access to whichever is set, then when we
pass to our buildClassPath util we will have to re-resolve for the GWT
mojo. I am sure it can be done, but it might involve some hoops.

Right now, for the record, 2.0-beta23 has RUNTIME, and 2.0-beta24 has
COMPILE.

I will add this to the tracker though, and try to hit it next.

On Oct 3, 4:59 am, "Mirko Nasato" <mirko.nas...@gmail.com> wrote:
> 2008/10/3 Charlie Collins <charlie.coll...@gmail.com>