We follow a similar method here. Any "system" testing that is to be done
at a unit level must use mocks. Each project's test directory contains
unit and system dirs, with the <unitTestSourceDirectory> pointing to the
desired test type at build/post-deploy time.
cheers,
Justin
"Stevenson,
Chris"
<Chris.Stevenson@ To
DrKW.com> 'Maven Users List'
<[email protected]>
14/06/2005 01:28 cc
AM
Subject
RE: Why I hate Maven :-)
Please respond to
"Maven Users
List"
<[EMAIL PROTECTED]
he.org>
Jim,
On your point about SOA and Maven. We have the same problem at my company.
But you have to remember that the unit tests are to test the unit of
deployment and its code. It sounds like what you're doing is integration
testing (proxy code -> server code) which is a different kettle of fish.
We are thinking of getting around this using mock objects to actually test
the proxy code and creating a custom project of integration tests which
will
be built separately when all the code has been deployed.
Chris
-----Original Message-----
From: Jim Mochel [mailto:[EMAIL PROTECTED]
Sent: 13 June 2005 16:15
To: Maven Users List
Subject: Why I hate Maven :-)
Brett Porter recently posted a BLOG entry asking why some people hate
Maven.
I couldn't get the blog entry dialog to take more than two sentences so I
figured I would post it here.
Please read this without assuming that I am attacking Maven 1x. I clearly
like something about
Maven since I am still using it. Keeping in mind that much of this looks
like it is being solved by M2 here are
some of my all time greats hassles:
ISSUE: Multiproject handling is a "tacked on option" whose interaction
with other goals
becomes problematic.
M2: Appears to have been addressed in M2.
ISSUE: The Clean goal isn't clean. Requires all dependencies to be
available before
deletion.
M2: Appears to have been addressed in M2.
ISSUE: The majority of the functionality is undocumented and therefore,
inaccessible at speed. With the exception of a _small_ number of _core_
tasks
there is almost no documentation. I currently have all the plugins
expanded in a
subdirectory so that I have an online dictionary of jelly and java code
and
properties and goals.
M2: It may or may not be addressed in M2 but it looks like the
basic explanantions of
lifecycle are there and it looks like it may be easier for me to
help update the
documentation built on top of that foundation.
Ideology
---------
More often than not, If Maven's best practices doesn't fit my real world
issues
I am screwed. The workarounds take much more time than they might
(aggravated
by lack of documentation issues) and almost always cause bad side
effects..
Maven's best practices often don't address corporate real world headaches.
Even
when I agree with them I bump up against the problems inherent with what
an
existing corporate practise and/or current tool sets.
ISSUE: The attaching of the test and install goals in such a way that they
cannot be
separated easily and cleanly AND The assumption that testing can occur
immediately after compilation and installation... without a deployment.
There are circumstances here at my site with an SOA deployment which
means
that EVERYDAY we deal with the negative impact of those features. We
can
have all unit testing OR none AND we have to write all of our own code
to
manage the issues many of which could have been avoided if we had a
way to
run the tests as a process after we had successfully built, installed,
and
did a deploy to the app servers. Yes, we have workarounds and they
are not ideal.
M2: I am not yet clear that this is resolved in M2.
ISSUE: The one project, one artifact rule is a great rule for
configuration management
BUT it puts the onus of managing complexity on the developer rather than
the tool.
At one point I was giving developers a process that had them creating
8
projects for each service to be deployed even though the actual source
code was 3-11 files per service. This was necessary so we could manage
the
generation of key elements and unit tests. In effect, the source code
was
the same but it had several expressions in the world at large and each
one
required a separate project.
Now we currently put it all in one project and I have created a group
of
rules to generate ALL the artifacts for a single service from the one
project. It doesn't fit perfectly with the existing other practices
inside
Maven but it gives my fellow developers a lot less complexity to
manage and
thus there are a lot fewer mistakes along the way.
The ability for a project to be able to register that it produces N
artifacts and list those artifacts, ids, types, etc, would make a huge
difference.
M2: I have seen no sign that this is simpler in M2.
ISSUE: The versioning of artifacts is VERY much a "one size fits rarely"
UNLESS
you are in total control of all of your codebase. If there is any place
where a
specific artifact name doesn't work or cannot contain a version at
deployment
time (.NET strongly named assemblies come to mind - painfully) then there
are
rarely workarounds that don't take many hours to implement and integrate
into
the process.
M2: I have seen no sign that this is simpler in M2.
ISSUE: Repositories assume WORA semantics for the artifacts. Building
systems
that require special dependencies for one platform but not for another is
problematic.
M2: This appears to be handled at the repository side by the new M2
repos structure.
I am not clear about the use of Maven to build multiple configurations.
ISSUE: Using multiple source paths in a single projecty is a headache. It
has
most often come up in the code generation arena but also when dealing
with
tools that require the source tree to be processed to be available AND
cannot
filter the source files to be processed by package name.
M2: I am not sure if this is addressed in M2.
Thanks for listening,
Jim Mochel
--------------------------------------------------------------------------------
The information contained herein is confidential and is intended solely for
the
addressee. Access by any other party is unauthorised without the express
written permission of the sender. If you are not the intended recipient,
please
contact the sender either via the company switchboard on +44 (0)20 7623
8000, or
via e-mail return. If you have received this e-mail in error or wish to
read our
e-mail disclaimer statement and monitoring policy, please refer to
http://www.drkw.com/disc/email/ or contact the sender. 3166
--------------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
