GWT as part of repository or not?

1 view
Skip to first unread message

jbdhl

unread,
Nov 21, 2009, 6:22:35 PM11/21/09
to Google Web Toolkit
I can't decide where we should place GWT itself for a project with
multiple developers:

1) In the svn repository as part of the project.
Pros:
* The developers GWT version will always match what is being
used in the project
* No potential problems with GWT binaries being located
differently for different developers. All scripts can just refer to
the same relative path(s).
Cons:
* It's kind of ugly to commit third-party stuff into the
project repository

2) Each developer download their own GWT version and let an
environment variable, GWT_ROOT, point to it.
Pros:
* No third party stuff in project repository
Const:
* Possible conflicts if developers use different GWT versions
* Possible problems with developers different placements of
GWT.

What would you suggest?

rjcarr

unread,
Nov 21, 2009, 7:22:17 PM11/21/09
to Google Web Toolkit
You list good pros and cons so you'll have to just decide which is the
stronger argument for your situation.

Since our project is developed in mixed environments, and the
developer base isn't very big, it made sense for us to go with your
second option (although we use property files not environment
variables). However, I can see justification in checking it in.

Good luck!

Angel Marquez

unread,
Nov 22, 2009, 12:17:24 AM11/22/09
to google-we...@googlegroups.com
I think in an ideal dream the Project Manager would be able to create a work breakdown structure that would reflect granular components that could be checked out by the appropriate party(ies). This would make it easy to report status of progress if executed properly. Make the project architecture conform to branching off from the trunk for the developer(s) assigned to it checking and merging back a seamless operation. Along with the defect DB being tied into the mix so QA would be included at the very beginning of the project. I would totally implement the constraints of making a bug # and a message mandatory. 

I'm a novice at the dev svn environment but from what experience I do/did have I know the primary hurdles are:
-Conflicts when merging
-GWT(anything that evloves) versioning and upgrades scenarios 

I know my routine would be;
Checkout // Yes, GWT is part of the core put it in the repo and have your team on a start your day routine.
Branch // Work on WBS's that have been split up for efficiency
Update // Always note what and why with reference to anything applicable

I guess apply standards to all the svn methods...Add=Must, should, format etc....

Everyone should be on the same page, when I change occurs run the drill that you've put in place, a good design would account for everything you mentioned.


--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=.



Javier Molina

unread,
Nov 21, 2009, 10:32:26 PM11/21/09
to Google-We...@googlegroups.com
I recommend you put it in your VCS. Having it in the repository does not
impact anyone negatively and makes everybody's life easier. If you must,
set up your project so that you can override the default version by
changing a per-developer setting or an environment variable and you're
good to go, but this should be for experimentation only. You should
dictate an approved version and everyone should be using that; otherwise
someone will commit code that uses newer features not available in
previous versions and, generally, chaos will take over your project.

rjcarr escribi�:
Reply all
Reply to author
Forward
0 new messages