Without having dipped my toes into the wave codebase, maybe it would be
worth following an incremental approach to any build changes:
- split the build where sensible (e.g. slow jUnits)
- separate the codebase to allow more modular builds
- ship poms for the individual deployable assets
- investigate migrating to maven.
Taking the first three steps with the existing build infrastructure:
- allows incremental changes while dev work happens elsewhere
- encourages debate about structure before tooling
- demonstrates that there is a team happy to commit the time to these
changes
- achieves some quick wins while avoiding any religious debate
Dave
On 09/05/11 10:35, Daniel Danilatos wrote:
Thanks for starting this survey.
I'd like to point out that still most of the "advantages" people are
listing are either vague or easily achievable without maven. We need
an "alternatives considered" section: i.e. for each proposed benefit,
I would like to see why that benefit is only possible (or much easier)
to achieve through maven.
For example: breaking the unit tests up into smaller pieces to run
them more incrementally can be done now without too much hassle - and
furthermore, the granularity of maven modules might not be high enough
as the test cases in some modules, particularly the client ones which
have GwtTestCases, might still take a very long time. I may of course
have missed something, but this is what I mean when we need to put
both alternatives in the balance, otherwise it just feels (to someone
like me) that we're doing this out of a general enthusiasm maven.
Dan
Στις 2 Μαΐου 2011 1:54 π.μ., ο χρήστης Michael MacFadden
<[email protected]> έγραψε:
All,
Let's start a new thread focused on planning out what a possible move to maven
would look like. I know it's easy to dive in to the code and just start
playing around, but if not done right, we are going to get a lot of push back
from others on moving to maven. We need to plan this out and identify exactly
what we intend to do, who is going to do it, how were are going to do it, and
when it will be done. The discussion of this should happen on the mailling
list, and the results of the discussion should be captured in the development
wiki (which I can set up).
The following questionnaire should help us get going. I realize that some of this
discussion has already taken place. I would suggest simply answering the questions for
yourself in this thread. If we need to discuss a particular question lets start a
separate thread for each question. I don't want to distract people from filling out the
"survey". Thanks.
~Michael
Questions:
1)
What is the objective (just provide maven jars to a repo? fully mavenize the
project? etc)?
2)
What are the benefits of what we are proposing? Why should we move to maven?
I would be curious to see the point I mentioned about "modules" in the
other email thread addressed. (Regarding the granularity and weight of
modules in maven).
3)
Who is really committed to work on this?
4)
hat is the general approach for adding maven support (just writing poms? moving
source around? etc)?
5)
How will the development cycle of the developers who are not working on this be
impacted?
This is the most important point. There must be absolutely no
regression in the development cycle after switching to maven - talk of
having to restart development mode scares me, as I've had this
experience in the past and it's horrible. Even if hosted mode startup
is fast, the very act of having to close it and reopen it adds another
5-10 seconds per iteration.
6)
What are our deliverables? Other than the mavenized project, do we need to
provide documentation or tutorials to show others how to work with the new
system?
7)
What are the various modules we would propose having and what is the purpose of
each (simply stating that we stick with the current jars is not enough info)?
8)
What group ids / artifact ids should we use?
9)
What are the timelines and milestones?
