Like I've said before you could probably pull this off using
includes/excludes like this:
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<includes>
<include>com/google/wave/api/*</include>
<include>com/google/wave/api/event/**/*</include>
<include>com/google/wave/api/impl/**/*</include>
<include>com/google/wave/api/oauth/**/*</include>
<include>com/google/wave/api/v2/**/*</include>
<include>com/google/wave/api/data/**/*</include>
<include>com/google/wave/api/robot/**/*</include>
</includes>
</configuration>
</plugin>
Also we could start refactoring packages, to make the job easier,
without requiring a complete code freeze.
On 28-04-2011 17:02, Michael MacFadden wrote:
This is actually a complicated question. Technically speaking yes, you could have both build
systems in place. However, maven requires you to re-organize your project in to some standard
layouts. It's likely that as you move things around to "mavenize" them, you would be
continually breaking your ant build scripts. The extra overhead in trying to maintain the ant
scripts while trying to introduce maven is probably not worth it. There are ways around this that
can produce a hybrid approach, but to fully "mavenize" the project it gets a little hairy.
~Michael
On Apr 28, 2011, at 7:51 AM, STenyaK wrote:
Just a quick question (sorry if it's obvious, but I don't know ant nor maven
too much): can't the two build systems temporarily coexist, being able to
use and update the current Ant build system as usual, while the Maven build
system is being constructed and updated too?
On Thu, Apr 28, 2011 at 16:35, Michael MacFadden<
michael.macfad...@gmail.com> wrote:
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<eric.char...@u-mangate.com>
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<
michael.macfad...@gmail.com> 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
<michael.macfad...@gmail.com> έγραψε:
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
