Great to see so many people commited to this.
I will answer the survey Micheal created so we can understand the
motivations for adopting Maven.
I would however like to suggest again the use of a separate maven
project structure with an includes/excludes scheme for now... this way
it won't have any impact on the work done by other devs and will allow
us to evolve our maven modules. This seems to be the main concern with
the dev community and it is perfectly understandable. If we refactor the
whole project structure in a go to use maven it will take a while for
people to get familiar with it thus loosing precious time.
On 01-05-2011 16:34, Michael MacFadden wrote:
Rohit,
This is great work. I think technically it shows what can be done in a short
amount of time. This would help scope out the work much better.
However, I would like to take a step back a little bit and actually plan this
out. I will start another thread right now, where we can discuss. Thanks.
~Michael
On May 1, 2011, at 4:15 AM, Rohit Rai wrote:
Hi All,!
Nice to see that we are moving on with a constructive discussion and
Michael, thanks for laying out the basics of how a community can work so
clearly! Yuri, thanks for laying out the process structure, probably this is
the process we should follow whenever someone comes up with a new idea. He
takes the ownership, gather a group around the idea, involves a contributor
and gets the idea in the project. :)
Well, to move on...
Nelson, I worked thursday night and part of friday to reorganize the then
checkout to a maven build format... of course taking a lot from your maven
project, but following the currently builds output modules generated by ant
dist.
I am sure, this is very crude with some work remaining, but I did this in
hardly 5-6 hours. If we give it time and take a shot together we can put it
out in a day or two ready for review.
I wanted to stretch on and complete it but am running fever since friday
evening... I have no idea, how the process will go further but anytime you
decide to pick up this task, I'll happily contribute in any way possible.
I'll take a shot at it once more monday night (India) to atleast get a
working build.
please take a look at this -
https://github.com/rohit-tingendab/Mavenized-Wave-In-A-Box and let me know
your thoughts.
Regards,
Rohit
The diamond cannot be polished without friction, nor man perfected without
trials
http://mytechrantings.blogspot.com
On Sun, May 1, 2011 at 12:37 AM, Michael MacFadden<
[email protected]> wrote:
Yuri,
Totally agree. Thanks for structuring this in this way.
Nelson,
Let's start another thread to discuss how a possible maven migration might
go. Why don't you start with your current ideas. Those who want can
participate in the discussion. I can capture a "plan" in our development
wiki, which needs to get set up anyway.
~Michael
On Apr 30, 2011, at 9:44 AM, Yuri Z wrote:
Ok, I think you got good points that send us back to a constructive
discussion.
I think that we should proceed in the following fashion:
1. Those who want to move to maven should organize and openly declare
that
they are committed to the task. There should be at least one existing
Apache
Wave committer in the group as someone who already demonstrated its merit
and ability to deliver. It will also ensure that there will be someone
available to review the changes and push them.
2. The "Maven" group should produce a plan with measurable milestones.
The
plan should state the task, amount of effort, timeline, and who is
assigned
to which task.
3. At this point we will be able to discuss this concrete suggestion and
make a vote.
2011/4/30 Michael MacFadden<[email protected]>
All,
I think we have gotten a little off track on the maven discussion. What
it
has basically boiled down to is a discussion on if we should migrate to
maven or spend time working on other items. I don't think this is the
right
way to look at it at the moment. Here are my thoughts.
1)
We should asses whether maven is even something we like regardless of
the
effort it takes. What are the merits of maven? Do we agree that there
would be a benefit? Assuming zero effort would we want maven? If the
answer is no, then everything else is irrelevant. I think we need to
have
an objective conversation about this first.
2)
We are assuming that there is a choice between doing the work to
"mavenize"
the project vs. doing some other work that people feel is more
important.
The major flaw here is that assumes that the resources that would do the
maven work would otherwise do something else. Although we are a
community
that should come to a consensus on priorities, we need to remember that
we
are also just individual committers. We can't force and individual to
work
on anything specific. If there is one or more resources out there who
want
to work on brining maven to the project we can't simply tell them "no"
if
the only reason is that we would prefer that they would work on
something
else. It's quite possible that the people that want to work on brining
maven to the project wouldn't work on other things even if we asked them
to.
In other words if in point #1 we decide that we do want to go with maven
eventually (a big if), and there is some one out there who is
volunteering
to help us with that now, we shouldn't discourage them. Consider the
non-commiter who has a project that uses maven. That person might want
to
use WiaB components in his project. He might write a patch that
mavenizes
the project and send it to us. In that case we haven't lost out on
working
on any other functionality.
3)
So if we do want maven (point #1), and "WE" don't have to stop working
on
"OUR" priorities to get it because some one else is offering to do the
work
(point #2), then the last question is how disruptive would switching to
maven be on the rest of the development process. This could be the
tricky
part. Depending on how its done it could be very disruptive, or it
could be
fairly painless. If there was a way to slowly introduce maven, without
much
impact to the current development tasks then maybe we would be more
inclined
to do it. If everyone has to stop what they are doing for two weeks
while
we sort it out, then maybe not.
Point being this is another area where some discussion would be very
helpful.
Anyway, I would really like to have objective conversations about
point's
#1 and #3 and to move away from the "doing X right now should be more of
a
priority" conversation that we have gotten in to. While I agree that
priorities are important, and we need to start setting them for the
project,
I think we need to look at this from a ROI perspective first, and then
figure out where it fits on the roadmap given the project impact and the
resources that would need to be involved. Just my opinion.
~Michael
On Apr 29, 2011, at 1:59 AM, Daniel Danilatos wrote:
Hi guys,
I am inclined to agree with Yuri and STenyaK (forgive me I'm not sure
what your first name is). Right now what this project needs most is
some real momentum in terms of features and stability, and major
refactorings of the code base merely to change build system seem like
far too big a risk. I think any effort to port to maven would be much
better spent on directly addressing the one or two most annoying pain
points, such as making the build or unit tests run more incrementally,
or exporting maven targets (so other projects that use maven can
depend on our code). I am confident someone could get that fixed with
a few hours work or less. Other benefits listed are far less concrete
and don't seem worth the risk to me right now. I have no doubt that
when we have a cool product, people will jump on board regardless of
what build system we are using - it would be a bad sign for our
project if it is the build system that is what attracts/repels
contributors.
Regarding maven itself (I'll try to be brief-ish until I collect my
thoughts further): From what I can tell, reading people's opinions
here and on the internet at large, there are two broad reasons why
people seem to like maven. (1) it automates fetching dependencies,
which is an annoying task to do manually. (2) it is an improvement
over "normal" ant monolithic builds, by breaking applications down
into modules and forbidding circular dependencies. Regarding (1), I
can see how this can improve a lot of things, but I can also see how
it adds more points of failure for a build setup. So it's not quite a
dead-clear win. Regarding (2), I am a big fan, and you'll notice that
we've tried hard to do that in the client code with fine-grained GWT
module dependencies. Internally at Google, our build system
encourages/enforces this. In both these examples, the module breakdown
is fine-grained (often on the package-level), and this really makes
sure you don't screw up, and helps keep code highly decoupled. Also,
doing this is very lightweight - all you need is a small file that
declares the deps. If you have a section of your code base that is
well written with good dependency injection, adding these module
declarations is a snap - it requires no code change or refactorings.
The problem I see with maven is that modules seem to be quite heavy
weight, and harder to split/join/move around. Please correct me if I'm
wrong, but it seems that each module requires its own separate source
tree, with a deep set of top level directory and other "boilerplate" -
or, alternatively, fighting maven to maintain some other directory
structure (but the consensus on the internet is that you don't fight
maven unless you're a masochist).
Full disclaimer: I have only used maven a little, and done a bunch of
reading. But please don't discount my opinion on those grounds. Also,
I hate ant, don't get me wrong.
I do not in any way intend to start a "maven is awesome" vs "maven
sucks" religious war here. My opinions above regarding maven are
tentative, and I would love to revisit them. I provided them partly to
play the devil's advocate, and partly to justify why I feel it's not a
clear win to migrate, and so probably not worth the risk to the
project's momentum until we are healthily going full steam ahead. At
that point it'd be great to revisit this question and learn more about
maven. I think ultimately whatever pleases the majority of the active
contributors is best.
Dan
Στις 29 Απριλίου 2011 3:10 π.μ., ο χρήστης STenyaK<[email protected]>
έγραψε:
In the end, long term plans have to take into account the consequences
of
trying to future-proof the project: If focusing on long-term future
during
2011 makes wave lose (or "not increase") the precious momentum it has
thanks
to inertia of googlers and other interested parties, then maybe it is
actually *not* such a good long-term plan.
Just to put things in perspective: the project has blindly migrated
from
git
to svn, and accepted not to dog-feed itself, but is now considering
changing
a (afaik) perfectly working build system, which will disrupt
development
for
an unknown period of time. Also, time is being wasted in this
bike-shed-color discussion (ehm, sorry for contributing to it O:-).
IMO continuing with ant for a few more weeks/months is probably going
to
be
better in the *actual* long term.
2011/4/28 Yuri Z<[email protected]>
Michael
I hate to be the devil's advocate, but I ll take the role this time.
First of all, you are right of course - all decisions should be
wighted
on
the base of effort vs. gain and after analysis of the risks.
Also, the analysis should build on the past relevant experiences. So
let's
try to understand what happened with the move to Apache (sorry if I
kick a
sacred cow). I think that the move to Apache is positive development,
but
much ahead of the time.
At the time I advocated to postpone the move because: "There are no
immediate gains for the Wave in a Box project, but the prices are
immediate". I mentioned that we should first
- To focus on attaining the goals outlined in the WIAB roadmap
- Use of Apache mailing list instead of dog food WIAB instance is a
very
heavy price.
- The move will take too much effort that instead can be devoted to
development of core WIAB features.
I was told then that:
- The move will possibly attract an influx of commiters - didn't
happen.
- It will be probably possible communicated with Apache so allow us
to
use dog food instance instead - didn't happen
- The move to Apache infra can be done in parallel and won't affect
ongoing development efforts - not quite true.
And it is clear that giving up on dog food instance - is a really
heavy
price. Off course, the move could take only a few hours or days, but
in
reality it taken 4 months and counting.
So I think the lessons that we should learn:
- Focus on the main product, do things only when necessary and not
ahead
of time to gain possible value.
- Don't assume that problems can be solved later, either have a
clean
2011/4/28 Michael MacFadden<[email protected]>
Yuri,
I don't think we can view it as to high a price right now vs later.
The
fact of the matter is that if we push it off to some later date when
we
will
have "free time" to take on something like this, it will honestly
never
get
done. Plus we haven't quantified how much effort it would take.
What
if
it
could get done in a few hours? Would it be worth it then? What
about
a
few
days? I think the benefits are pretty clear, but we need to
quantify
how
much work it would take to get it done.
Only then can we decide if it's worth it. One plug for doing it now
rather
than after a "1.0" would be I imaging that a 1.0 release would be
ready
for
a lot more wide spread use. If you imagine that you could see a lot
more
people downloading and using WiaB after 1.0. At that point we will
be
getting a lot more attention and enhancement and bug requests. We
might
even get an influx of committers. At that point it would be almost
impossible to justify a code freeze for a few days to switch to
maven.
In my view we are almost in a now or never type of scenario.
~Michael
On Apr 28, 2011, at 12:09 AM, Yuri Z wrote:
IMHO code freeze price is too high for now. Maybe after we release
ver
1.0
then ver 1.1 can be about moving to maven.
2011/4/28 Eric Charles<[email protected]>
Hi,
I've been paid for 6 months by one of my client to migrate
numerous
project
from ant to maven. Some were trivial, other were really
complicated
due
to
legacy technologies,... and needed code refactoring.
At the end, the result we got much more
manageable/testable/deployable
components based applications.
I don't know wave code, but I bet maven compared to ivy will drive
to
a
better code base, even if the prices may be high (work,
freeze,...).
Tks,
- Eric
On 28/04/2011 06:34, Rohit Rai wrote:
+1 for migrating to maven
Though I share the concern raised by Michael, "it is not going to
be
easy"
(have experience in earlier changing from monolithic ant builds
to
modular
maven builds...) and it will disrupt the development temporarily.
But as mentioned in the mails above, we should think on these
line
-
1. Maven being the accepted build standard on date, will make it
easy
for
new developers to start with WIAB.
2. Developers can pick a module and focus on working with it
rather
than
spending time trying to understand the current project format
and
figuring
out what goes where.
3. It will make it easy for developers to integrate WIAB
components
individually and also to embed WIAB in there applications.
4. IDE integration is very helpful to start of quickly
At this point when Google is removing people from this project, I
think
it
makes sense for us to make it easy for any newbie coming to get
started
on
it, the more the merrier!
And if we don't do it now,
1. that we are transferring it from Google Code to Apache (when
we
can
have
a scheduled downtime for a couple of days)
2. the code base is manageable size
3. the contributors are limited in number
We may never have an better opportunity and it is going to be
"much
more
difficult" once the codebase and number of committers grow!
Just my 2 cents from past experiences . . .
And to back up my words, I will be all willing to spare couple of
days,
taking leave from my day job and weekend along if required to
assist
with
the migration to maven.
Note: If we have to move to maven, we should first list out what
will
be
the
modules and then what part of code goes into which module. This
will
speed
up the actual transition process.
Regards,
Rohit
The diamond cannot be polished without friction, nor man
perfected
without
trials
http://mytechrantings.blogspot.com
On Thu, Apr 28, 2011 at 8:52 AM, Michael MacFadden<
[email protected]> wrote:
All,
I am not sold on maven at this point. Don't get me wrong I am a
strong
advocate of Maven, and although it has its issues, I think it
can
be
a
big
benefit to a project. I am just not sold that it is worth the
effort
at
the
moment. That being said here are a couple ways which maven
could
help
the
wave in a box project:
Modularization
Maven encourages the construction of distinct modules for a
project.
As
the wave project grows, we will likely want to build a set of
reusable
components that other projects could use. For example we may
have
concurrency control stacks, protocol stacks, interface
components,
etc
that
other projects might want to take advantage of. We have already
gotten
request to use the editor, and we know people are interested in
building
new
UI's leveraging the client server protocol. With maven, the
project
can
easily be organized such that these modules are reference-able
and
usable
by
others. Things like the Robot and Gadget API are obvious
examples.
This could be done without maven, but maven makes this the norm
rather
than
the exception.
Build Time
Right now we have a pretty monolithic build. When I change
anything,
I
have to rebuild the whole project. With maven it's fairly easy
to
go
in
to
the sub module you are working on and make "local" changes
there.
You
can
rebuild and deploy easily without having to do a whole build.
Of
course
you
can run a full build if you like.
Testing
Right now we have an issue with testing. The unit tests are
also
monolithic. Originally, they all run or they all didn't.
Unfortunately,
it
took too long to run all of them, so we now have a somewhat
arbitrary
distinction between long running and short running tests. Only
the
short
ones run by default.
With maven, unit tests are scoped to the module which they test.
If
we
had
a Robot API module, we would have tests in that module that just
unit
test
the Robot API. If you are working on the Robot API, you can
make
changes
and easily just run the Robot API unit tests. You can actually
work
on
the
sub module, make changes, test and check in code, without having
to
run
ALL
the unit tests for the whole project, assuming the tests are
comprehensive
for the module. The job of running all the tests can be the job
of
the
integration build.
Standardization
When I was ramping up on wave, it took me over a month to become
fully
comfortable with the nested ant scripts and how the project
ultimately
built
itself. As ant projects try to become more modular, the
complexity
of
their
build scripts goes exponentially up. Furthermore, each project
does
it
differently. You have to study the build to figure it out.
With
maven,
its
all pretty standard. Any developer experienced in maven can
check
out
your
project, rigure out the module layout and how to build any
specific
module
they need within minutes.
Other Random Things
Great IDE integration.
Dependency management.
A standard mechanism to deploy our artifacts for other projects
to
use.
Lot's of reports that can be generated about dependancies,
tests,
etc.
Integration with SVN and standard mechanism to perform releases,
tagging
and branches.
In my opinion maven would help us:
Organize the project better.
Make our codebase more testable.
Shorten our development and test cycles.
Make our project more accessible to new developers.
Make our project more reusable for others.
All of that said... it's not going to be easy to switch over, so
I
don't
take the decision lightly.
~Michael
On Apr 27, 2011, at 7:31 PM, Daniel Danilatos wrote:
It seems the real problem here is the large amount of jars
checked
into the repository. What about something that just does
dependency
management, for example apache ivy?
Does maven solve any other problems we have that make it worth
going
all the way with it? I'm worried it could cause as much trouble
as
it
solves. I'm not fundamentally against it but I'd like to be
confident
there are solid reasons/benefits to the waveprotocol project
for
migrating to maven.
My 2c.
Dan
Στις 27 Απριλίου 2011 7:51 π.μ., ο χρήστης Michael MacFadden
<[email protected]> έγραψε:
Nelson,
I am all for this. I am very experienced with Maven and the
proper
ways
to set up multi module projects including dependency
management,
etc.
I
think your assessment of the situation is correct. We would
ultimately
need
a code free to get this done.
However, before you go to far, I would try to get a real
discussion
going on if this is something the team wants to do. If so we
need
to
discuss what the right modules are, what artifact and group ids
we
would
want, etc. I would hate to see you set up a lot of poms.xml
that
don't
line
up with how we would ultimately do things.
As a side note, if we did want to go to maven, now would be
the
right
time. Everything else has to be migrated anyway, might as well
take
the
hit
now. However, I would recommend that we get the current source
migrated
over first.
~Michael
On Apr 26, 2011, at 10:12 AM, Nelson Silva wrote:
Hi all,
There have been several discussions on adding maven as a
build
tool.
I've decided to start working on this by adding a tools/maven
subdirectory with a multimodule project layout.
I pushed my ongoing work to a branch in my GitHub clone :
https://github.com/nelsonsilva/wave-protocol/tree/maven/tools/maven
While a complete port to maven as the main build tool would
required a
code freeze and a healthy discussion of code reorganization
into
proper
modules we should be able to use a simple includes/excludes
approach
for
now
and in the end, if everyone is ok with it, we could easily make
the
port
happen.
I would like to get some help with this from everyone who's
interested.
There are lots of plugins and lots of ways to acomplish things
in
maven
so
this should get the discussion started.
I chose to go with GitHub so everyone can fork it and send me
pull
requests. If you'd rather go with the issue/patchset approach
I'll
open
the
issue but the idea here was to have several people contribute
and
not
a
single patch + review process.
Quickstart:
cd tools/maven
./install_deps.sh # This will install a couple of
dependencies
that
were either patched or were not found in existing maven repos
mvn install
cd server
ln -s ../../../war
mvn exec:java # This should start the server, although you'll
have
to
symlink the war directory for now
TO DO:
- Use profiles for dev/prod
- Remove as many ant tasks as possible and use pure maven
plugins
- Use the assembly plugin to package the server with the
webclient
- Setup the surefire tests for each module
- Rethink the modules, we should have pure api modules and
the
several
impl modules for persistence, websockets, auth, etc ...
- etc....
Looking forward to getting this going...
Regards,
Nelson Silva
--
Saludos,
Bruno González
_______________________________________________
Jabber: stenyak AT gmail.com
http://www.stenyak.com
