tbroyer / gwt-maven-archetypes

Apache License 2.0
152 stars 39 forks source link

Set dev as the default profile #12

Closed jgonian closed 12 years ago

jgonian commented 12 years ago

The idea is to always use the dev profile unless otherwise specified. This is because during development starting jetty and running gwt dev mode using the dev profile happens way more often rather than using prod.This way, we avoid the extra typing of the -Ddev property every time we type mvn jetty:run and mvn gwt:run.

Again, to enable the production profile will be a matter of specifying a property (e.g. -Dprod).

Should I create a pull request for this change?

tbroyer commented 12 years ago

While I sympathize with the (all relative) pain of having to specify -Ddev each time you run Jetty or the DevMode, I believe the prod profile should be left as the default one.

  1. I think it's a (generally agreed) best practice that mvn package and similar (verify, install, deploy, etc.) work out-of-the-box, and mvn package -Ddev fails.
  2. mvn jetty:start and mvn gwt:run fail very early (in the very first phase, when verifying dependencies), so a missing -Ddev won't waste much of your time.
  3. I expect most developers to use an IDE and launch these goals from there, where the launch configs will generally be saved in the project/workspace; so most of the time it'll be a one-time setup.
  4. The archetypes could generate scripts such as run-server.sh and run-devmode.sh, or similar, if it happened to be an issue to many people. (developers are supposed to be lazy, and they'll make such scripts themselves if they think they need it; with the advantage that they can write them their way: fo instance, a dev who always launches both will probably do the jetty:start in daemon mode, then launch gwt:run or gwt:debug and finally jetty:stop; in the end, it's probably better to document some of the options than ship scripts with the archetype)

I suggest you ask on the gwt-maven-plugin forum (and/or the GWT forum, Twitter, etc.), pointing people to this issue so we can gather feedback all in one place. In the mean time, I'll let this issue open and will revisit it in a few days when/if we have feedback from the community.

jgonian commented 12 years ago

Well, it's not clear in my initial post but the intention, apart from saving some keystrokes, is to help users get started with minimum effort (which has already been achieved in great degree by this project) and to simplify the POM configuration (if possible).

re. 1. & 2.) I agree that when you can't avoid failure it's better to fail fast. However, with few tweaks in the POM files we could avoid failure completely, regardless of which profile we are using. IMO this is better unless there are design decisions that I'm not aware of.

re. 3. & 4.) I also expect developers to use IDEs and write their own scripts. I also agree it's better not to ship scripts with the archetype. Still, I expect developers to use a Continuous Integration system which will be configured (once) to run with the prod profile. Under this setup, developers will work with dev out-of-the-box and CI server with prod. No need for adjusting your IDE settings, thus the "getting started" effort is minimum.

As you suggested, I will invite more people to join the discussion while in the meantime I will make the changes to my fork so you can review them.

tbroyer commented 12 years ago

with few tweaks in the POM files we could avoid failure completely, regardless of which profile we are using. … in the meantime I will make the changes to my fork so you can review them.

Yes please; if you think you can avoid failure completely then go ahead (at least as a proof it's possible, as I must say I'm a bit skeptical; I mean while at the same time simplifying the POM or at least not complicating it) and make a pull-request. I'll still wait for other opinions before merging it (unless you happen to also convince me ;-) )

dhoffer commented 12 years ago

I don't have a strong opinion on this yet but my 'gut' answer is to default to: make production quality code & defaults should work out-of-the box. That being said I haven't used this plugin yet...but I think I should soon.