That is a good summary of the difficulties I'm facing, are you sure we
are not on same office? :-) .
Please see inline for more...
Kalle Korhonen wrote:
I second that. On a large organization, with lesser Java knowledge and
only
very few strong engineering leads, any change meets resistance. I went
through the same converting our project to Maven and there's still
resistance. The most common arguments I hear:
- We have no expertise on Maven (they want somebody to teach them how
to do
things rather than assuming the responsibility of their own learning)
Here, the luck of Maven's documentation join the game, if we only had
good (and short;-) docs describing what is a life cycle, when and why
the local repository should be cleaned up and more and more....
referring the whole team to read "Better Builds With Maven" does not
work for engineers looking for the fast and short solution (but, it's a
great book).
- Build's no different from Ant (managers don't see the benefits because
proper metrics aren't gathered and they don't give it enough time. All
they
see is an immediate disturbance in way things are done)
- No benefit in Maven related goodies (e.g. Maven site, Continuum - I
set up
both, people don't see the benefit: unofficial, not in use, extra, nobody
looks at reports. I mostly think the organization's as a whole is just
not
at the maturity level they could do software differently, based on
test-driven and continous integration principles)
Most of my managers does use the reports, but here comes the other
issue, if we have a 50 component project, you can't see the project's
status, you can only see the component's status, for example: unit tests
summary on a project's level, code coverage rate, even the javadoc
aggregation is broken.
- Builds break of unknown reasons, server down, plugins not found
(somewhat
legitimate. Explain again why my build machine needs http to build? We
resorted to using a file repository only. I think a better way to
solve this
problem is with better maven proxies, like Archiva, and of course setting
the versions of everything you are using)
Yep, and add repositories downtime...
- We don't know the plugins and transitive dependencies we are using (I
mostly attribute this to people just being lazy and not bothering to
check
reports and understand the architecture)
- What's a snapshot, how do we version properly (module versioning had
never
before been used - only the product as a whole) so we were not in any
worse
position. But the truth is that release planning and doing it properly
takes
time, even with Maven)
So, I think you can find some of Maven's disadvantages from the recent
emails, but don't get it wrong, I think Maven is the way to go.
Erez.
Kalle
On 4/12/07, Erez Nahir <[EMAIL PROTECTED]> wrote:
I assume you did not have the opportunity to convince the old C++/Make
guys to change their habits... :-)
Erez.
Barrie Treloar wrote:
> On 4/12/07, Erez Nahir <[EMAIL PROTECTED]> wrote:
>> Here in Cisco we use Maven2.
>> If you can, when your presentation is ready, please share it, we
still
>> have some resistance from old make/ant supporters...
>
> How can there be resistance?
> Once you get things up and running m2 is so much more simpler to
> maintain/manage.
>
> Ant still has it's place for scripting things outside the build
> lifecylce.
> Make definitely isn't needed anymore.
>
---------------------------------------------------------------------
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]
