That's fine, I just wanted to ensure changes would be sent back to
codehaus Jira to avoid some sort of fork - we allready hardly merged
the codehaus & googlecode gwt-maven plugins !
I'd be pleased to help if you plan to support some SDK features in an
official GWT Maven plugin
The codeHaus plugin
To add a bit of color here, we patched the existing plugin so that gwt:run
would work with Roo generated code. We decided to host it in our repo simply
because we were short on time leading up to I/O. With that (almost) behind
us, our plan is to work with the codehaus-mojo team/project to formerly
I understand that adding the maven artifact to the svn repo might not
have been to help users. It would be nice to know what the GWTers are
thinking about this... Is Maven integration on a roadmap? is it just
being proposed/tested? It's okay if there's no promises, and if we
shouldn't rely on maven
Not the best way to help Maven users :-/
install-file goal is designed to setup a local repository, not to
create a public shared one.
Please consider writing pom.xml files with complete metadatas.
NB: providing maven metadata and artifact deployment does NOT require
the project itself to be buil
On 18 mai, 14:14, nicolas de loof wrote:
> I also notice the POM used to publish GWT artifacts is limited to required
> data, but does not include what is expected for a valid artifact to be
> deployed on maven central (license, SCM url, mailing lists...) and can be
> used by various tools (incl
I also notice the POM used to publish GWT artifacts is limited to required
data, but does not include what is expected for a valid artifact to be
deployed on maven central (license, SCM url, mailing lists...) and can be
used by various tools (including m2eclipse) to help developers.
Maybe they hav