You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by cvr <cy...@gmail.com> on 2008/10/21 04:16:54 UTC
Advice on dealing with hostility to Maven 2
I have a colleague has recently become a very vocal opponent of Maven. The
problem is that we’re behind a corporate firewall, and he has had a lot of
difficulty getting Maven to work (I googled "firewall" and created a
~/m2./settings.xml file appropriately).
His arguments have been:
- "The build system should be more complicated (harder to run, harder to
configure) than the software"
- "Why all this configuration for a glorified WGET?"
- "Why do you need a shared repository (~/.m2/repository)? Disk space is
really cheap"
- "What’s wrong with just checking the jars in to source control under lib"
- "I just have a build script that I run to compile my project, what's so
hard about that?" (ed. note: it's a bash script)
Having struggled with projects that had *no* build script (from the README:
"step 1: open up Eclipse and click compile"), projects with undocumented
dependencies (yay, ClassNotFoundException at runtime), and having fought
multi-module ant builds for two years - Maven has worked out wonderfully.
However, I can't seem to get this across. His mind is (angrily) closed.
I'm just wondering if others on this forum have encountered similar
hostility and you coped with it.
--
View this message in context: http://www.nabble.com/Advice-on-dealing-with-hostility-to-Maven-2-tp20082277p20082277.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Advice on building a plugin
Posted by Keith Branton <kb...@overstock.com>.
Hi folks,
Concerned about a project being built and deployed with a version of one dependency that another dependency has not been tested with, we are considering developing a new plugin, but first I wanted to ask the community if there is already something that does this, and if not get some pointers as to where to look for the best ways to achieve the steps we want to take. Feedback about pitfalls or easier ways to do this is also very welcome.
The main objective is to recompile the tests of dependencies using the artifact versions that were selected for the project, and execute the tests against the previously packaged classes. Assuming out test coverage is comprehensive, this would alert us to problems that would be caused in one of our modules by changing a version of an artifact that the module has not previously been tested with.
The plugin would work something like this...
1. Capture all the artifacts that were selected for the test phase
2. Identify all the dependencies that match some provided groupId prefixes. For each dependency...
a. check out the project from scm to a temp folder,
b. rewrite the pom, replacing all dependencies with the ones used for the project
c. exec maven with a profile that would activate another plugin that would do the following...
* after building the tests replace all the non-test classes with the contents of the artifact's jar from the repo
* run all the tests
* report any failures back to the parent execution
d. remove the scm check out from the temp folder
Being pretty new to Maven, and never having written a plugin before (and not being all that familiar with the plugins that already exist), if anyone could point at other plugins that do some of the following so I can see how they work it would be helpful...
1. Determine the SCM location of an artifact and check out the artifact into a temp folder
2. Invoking a maven subprocess (currently assuming I would just use a Runtime.getRuntime().exec call)
3. Reporting failures in the maven subprocesses back to the parent process
Thanks,
Keith.
CONFIDENTIALITY NOTICE: This message is intended only for the use and review of the individual or entity to which it is addressed and may contain information that is privileged and confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message solely to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify sender immediately by telephone or return email. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Advice on dealing with hostility to Maven 2
Posted by Aaron Metzger <am...@silkspeed.com>.
Martin Gainty wrote:
> maven's documentation is either scarce and what doc i see doesnt seem to follow a logical progression
That *used* to be somewhat true but it is absolutely no longer true.
Google for "Maven The Definitive Guide". Free copy available online.
Printed copy available for purchase.
No, I'm not affiliated with the authors.
I just think it is a fantastic book that has made a huge difference in
the adoption of Maven within my organization.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Advice on dealing with hostility to Maven 2
Posted by Martin Gainty <mg...@hotmail.com>.
maven's documentation is either scarce and what doc i see doesnt seem to follow a logical progression
1st step is to create a repository where is this located ..what are the consquences of already having a local repo?
now download the necessary distro from repository to local repos (how is this achieved offline and online scp/sftp/rcp?)
then create plugin
then install plugin
publish the plugin
now use the plugin
the dependency generation tools (i'm assuming plugin's coalesce around group-ID) are ok but hard to follow
for someone getting into a build environment for the first time (someone who only used NB or eclipse) I would advise them to use ant first so they get a firm grounding on what a build cycle is 'supposed to accomplish' e.g.
extract_from_repository (BTW if maven cant contact the repository all kinds of misdirected error messages show up)
precompile jsp
compile
run_test_scripts (junit/httpunit)
jar
war
ear
deploy
the strongest feature of maven ensuring version specific integrity..the last place I worked at did'nt have that
and the build engineer would'nt use maven because it was 'too complicated' which was too bad as it would've solved
the multitude of version mismatch scenarios we saw.
If you look at the ant site http://ant.apache.org and steve loughran's ant-in-anger http://ant.apache.org/ant_in_anger.html anyone will be able to get to use Ant in any build environment in 1 day..probably also the reason why NB and Eclipse and JDeveloper will import/export ONLY to build.xml..although I hear of a plugin for eclipse but havent tested it out yet..
Thanks,
Martin
______________________________________________
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission.
> To: users@maven.apache.org
> From: kawazu@zimmer428.net
> Subject: Re: Advice on dealing with hostility to Maven 2
> Date: Tue, 21 Oct 2008 11:37:42 +0200
>
> Hi;
>
> a few thoughts of a happy maven2 user who also sees _some_ of the issues
> while using it internally...:
>
> cvr schrieb:
> > - "The build system should be more complicated (harder to run, harder to
> > configure) than the software"
>
> Is this really what he means, and you're sure you didn't accidentially omit
> a "not" somewhere in this statement? To me this does not make any sense,
> actually... what is his rationale for that? Why have a tool hard
> (impossible) to operate when you can have an easy, straightforward one?
>
>
> > - "Why all this configuration for a glorified WGET?"
>
> Yeah... like "why cut that tree using a chainsaw when we eventually could do
> with a rusty knife?"...
>
>
>
> > - "Why do you need a shared repository (~/.m2/repository)? Disk space is
> > really cheap"
>
> Before switching to maven2/NetBeans, I used Eclipse "default" projects along
> with a vast load of projects referring to jars somewhere on my drive. After
> checking out some _old_ code off our SVN I learnt to know what makes a sane,
> structured artifact repository a rather good thing... :)
>
>
> > - "What’s wrong with just checking the jars in to source control under lib"
>
> Honestly I think this is not too bad an idea if working on internal code
> with an internal SVN repository, as this way one eventually could avoid some
> additional infrastructure (like maven2, archiva, ...). But that doesn't
> still help dealing automatically with transitive dependencies, different
> library versions et al...
>
>
>
> > - "I just have a build script that I run to compile my project, what's so
> > hard about that?" (ed. note: it's a bash script)
> [...]
> > Having struggled with projects that had *no* build script (from the README:
> > "step 1: open up Eclipse and click compile"), projects with undocumented
> > dependencies (yay, ClassNotFoundException at runtime), and having fought
> > multi-module ant builds for two years - Maven has worked out wonderfully.
>
> A way to get around this seems rather easy: Establish documentation
> guidelines, and force developers into getting at the very least basic
> documentation done allowing an arbitrary developer to pull the project from
> some local versioning repository, modify some code and get it built within a
> few moments. As soon as this is part of the requirements, he won't have much
> fun anymore using his self-made build scripts and undocumented dependencies
> as this would drastically increase his documentation work to be done. That's
> what in my opinion is the biggest "pro-maven2" reason from a non-technical
> point of view: You don't have to explain too much - no custom build scripts,
> no custom modified build.xml files including all sorts of "black magic",
> just a rather straightforward mechanism pretty easily usable by anyone who
> manages to build a maven2 project...
>
> Just my $0.02 of course...
> Kristian
>
>
> --
> Kristian Rink * http://zimmer428.net * http://flickr.com/photos/z428/ jab:
> kawazu@jabber.ccc.de * icq: 48874445 * fon: ++49 176 2447 2771 "One dreaming
> alone, it will be only a dream; many dreaming together is the beginning of a
> new reality." (Hundertwasser)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
_________________________________________________________________
When your life is on the go—take your life with you.
http://clk.atdmt.com/MRT/go/115298558/direct/01/
Re: Advice on dealing with hostility to Maven 2
Posted by Kristian Rink <ka...@zimmer428.net>.
Hi;
a few thoughts of a happy maven2 user who also sees _some_ of the issues
while using it internally...:
cvr schrieb:
> - "The build system should be more complicated (harder to run, harder to
> configure) than the software"
Is this really what he means, and you're sure you didn't accidentially omit
a "not" somewhere in this statement? To me this does not make any sense,
actually... what is his rationale for that? Why have a tool hard
(impossible) to operate when you can have an easy, straightforward one?
> - "Why all this configuration for a glorified WGET?"
Yeah... like "why cut that tree using a chainsaw when we eventually could do
with a rusty knife?"...
> - "Why do you need a shared repository (~/.m2/repository)? Disk space is
> really cheap"
Before switching to maven2/NetBeans, I used Eclipse "default" projects along
with a vast load of projects referring to jars somewhere on my drive. After
checking out some _old_ code off our SVN I learnt to know what makes a sane,
structured artifact repository a rather good thing... :)
> - "What’s wrong with just checking the jars in to source control under lib"
Honestly I think this is not too bad an idea if working on internal code
with an internal SVN repository, as this way one eventually could avoid some
additional infrastructure (like maven2, archiva, ...). But that doesn't
still help dealing automatically with transitive dependencies, different
library versions et al...
> - "I just have a build script that I run to compile my project, what's so
> hard about that?" (ed. note: it's a bash script)
[...]
> Having struggled with projects that had *no* build script (from the README:
> "step 1: open up Eclipse and click compile"), projects with undocumented
> dependencies (yay, ClassNotFoundException at runtime), and having fought
> multi-module ant builds for two years - Maven has worked out wonderfully.
A way to get around this seems rather easy: Establish documentation
guidelines, and force developers into getting at the very least basic
documentation done allowing an arbitrary developer to pull the project from
some local versioning repository, modify some code and get it built within a
few moments. As soon as this is part of the requirements, he won't have much
fun anymore using his self-made build scripts and undocumented dependencies
as this would drastically increase his documentation work to be done. That's
what in my opinion is the biggest "pro-maven2" reason from a non-technical
point of view: You don't have to explain too much - no custom build scripts,
no custom modified build.xml files including all sorts of "black magic",
just a rather straightforward mechanism pretty easily usable by anyone who
manages to build a maven2 project...
Just my $0.02 of course...
Kristian
--
Kristian Rink * http://zimmer428.net * http://flickr.com/photos/z428/ jab:
kawazu@jabber.ccc.de * icq: 48874445 * fon: ++49 176 2447 2771 "One dreaming
alone, it will be only a dream; many dreaming together is the beginning of a
new reality." (Hundertwasser)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Advice on dealing with hostility to Maven 2
Posted by Antonio <an...@gmail.com>.
2008/10/21 cvr <cy...@gmail.com>:
> - "The build system should be more complicated (harder to run, harder to
> configure) than the software"
Really? And I thought that efforts should be concentrated on the software...
> - "Why all this configuration for a glorified WGET?"
Because every project is different...
> - "Why do you need a shared repository (~/.m2/repository)? Disk space is
> really cheap"
Why not?
> - "What's wrong with just checking the jars in to source control under lib"
Because the repository could be a remote one, and you have to download
all of the libraries.
> - "I just have a build script that I run to compile my project, what's so
> hard about that?" (ed. note: it's a bash script)
A Bash script? Ok let's laugh together :-D
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Advice on dealing with hostility to Maven 2
Posted by Rusty Wright <ru...@gmail.com>.
I got my words mixed up; I meant "and its dependencies" when I said "and its dependent jar files".
Rusty Wright wrote:
> If he's only using the documentation on the Apache Maven site I can
> sympathize with him feeling that it's too complicated. This past
> Saturday I was trying to figure out how to use the assembly plugin to
> make a zip file containing my executable jar file and its dependent jar
> files and wasted hours flailing around. Luckily, just before I went to
> bed the lightbulb went off over my head and I remembered the Sonatype
> book and looked at it and saw that they had a big chapter on it, so
> Sunday I worked through that and was a happy camper.
>
> The other experience that I've had is that some people are simply
> resistant to change. If your colleague is like that my suggestion would
> be, if you can afford to, is to become The Maven Guy and offer to set up
> his builds for him; in other words, write his pom.xml files. Do it in
> parallel with whatever he's using now and then demonstrate to him and
> the rest of your colleagues how much better it is. Like the old saying
> goes, you'll draw more flies with honey than you will with vinegar.
>
>
> cvr wrote:
>> I have a colleague has recently become a very vocal opponent of
>> Maven. The
>> problem is that we’re behind a corporate firewall, and he has had a
>> lot of
>> difficulty getting Maven to work (I googled "firewall" and created a
>> ~/m2./settings.xml file appropriately).
>> His arguments have been:
>>
>> - "The build system should be more complicated (harder to run, harder to
>> configure) than the software"
>> - "Why all this configuration for a glorified WGET?"
>> - "Why do you need a shared repository (~/.m2/repository)? Disk space is
>> really cheap"
>> - "What’s wrong with just checking the jars in to source control under
>> lib"
>> - "I just have a build script that I run to compile my project, what's so
>> hard about that?" (ed. note: it's a bash script)
>>
>> Having struggled with projects that had *no* build script (from the
>> README:
>> "step 1: open up Eclipse and click compile"), projects with undocumented
>> dependencies (yay, ClassNotFoundException at runtime), and having fought
>> multi-module ant builds for two years - Maven has worked out wonderfully.
>> However, I can't seem to get this across. His mind is (angrily) closed.
>>
>> I'm just wondering if others on this forum have encountered similar
>> hostility and you coped with it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Advice on dealing with hostility to Maven 2
Posted by Graham Leggett <mi...@sharp.fm>.
Rusty Wright wrote:
> I completely agree.
>
> I'd go one step further with your building it on another machine and say
> that it has to build on another machine that's a different platform.
> I.e., if you're building on unix it must also build on Windows, or vice
> versa. And if you're building it in eclipse with the maven plugin it
> must also build outside of eclipse from the command line.
An effective way of doing this is to actively make your CI server as
different as humanly possible to your development environment. Different
OS, different timezone.
The more different you make it, the more likely you are to find latent
defects, like hard coded paths, or failures due to sloppy timezone handling.
In your CI environment you want to active give your code every possible
reason to fail, because if the code succeeds despite this, your code
very probably works bug free.
Developers tend to be resistant to this: "Oh, it's Linux, that's why the
test case fails", which is why this may need a bit of gentle (or not so
gentle) discipline to enforce.
In the example I am referring to, calculations that were failing
"because of a different OS" were actually failing because of bad
timezone handling, and people were resistant to fixing it.
Regards,
Graham
--
Re: Advice on dealing with hostility to Maven 2
Posted by Rusty Wright <ru...@gmail.com>.
I completely agree.
I'd go one step further with your building it on another machine and say that it has to build on another machine that's a different platform. I.e., if you're building on unix it must also build on Windows, or vice versa. And if you're building it in eclipse with the maven plugin it must also build outside of eclipse from the command line.
Graham Leggett wrote:
> Rusty Wright wrote:
>
>> The other experience that I've had is that some people are simply
>> resistant to change. If your colleague is like that my suggestion
>> would be, if you can afford to, is to become The Maven Guy and offer
>> to set up his builds for him; in other words, write his pom.xml
>> files. Do it in parallel with whatever he's using now and then
>> demonstrate to him and the rest of your colleagues how much better it
>> is. Like the old saying goes, you'll draw more flies with honey than
>> you will with vinegar.
>
> In my experience, some people on projects believe that if it works for
> them, then everything is fine. In practice, the build often works for
> them, but doesn't work for anybody else, and they don't care.
>
> What works in this kind of environment is a general rule that says this:
>
> "Your work is not done until it can be shown to build and run cleanly on
> a second machine other than your own".
>
> Being the "maven guy" also works very well, especially if you are also
> the continuous integration guy, and the CI server is the "second
> machine" above.
>
> In many cases resistance to change comes about simply because people are
> too busy to stop and "sharpen the saw".
>
> Regards,
> Graham
> --
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Advice on dealing with hostility to Maven 2
Posted by Graham Leggett <mi...@sharp.fm>.
Rusty Wright wrote:
> The other experience that I've had is that some people are simply
> resistant to change. If your colleague is like that my suggestion would
> be, if you can afford to, is to become The Maven Guy and offer to set up
> his builds for him; in other words, write his pom.xml files. Do it in
> parallel with whatever he's using now and then demonstrate to him and
> the rest of your colleagues how much better it is. Like the old saying
> goes, you'll draw more flies with honey than you will with vinegar.
In my experience, some people on projects believe that if it works for
them, then everything is fine. In practice, the build often works for
them, but doesn't work for anybody else, and they don't care.
What works in this kind of environment is a general rule that says this:
"Your work is not done until it can be shown to build and run cleanly on
a second machine other than your own".
Being the "maven guy" also works very well, especially if you are also
the continuous integration guy, and the CI server is the "second
machine" above.
In many cases resistance to change comes about simply because people are
too busy to stop and "sharpen the saw".
Regards,
Graham
--
Re: Advice on dealing with hostility to Maven 2
Posted by Rusty Wright <ru...@gmail.com>.
If he's only using the documentation on the Apache Maven site I can sympathize with him feeling that it's too complicated. This past Saturday I was trying to figure out how to use the assembly plugin to make a zip file containing my executable jar file and its dependent jar files and wasted hours flailing around. Luckily, just before I went to bed the lightbulb went off over my head and I remembered the Sonatype book and looked at it and saw that they had a big chapter on it, so Sunday I worked through that and was a happy camper.
The other experience that I've had is that some people are simply resistant to change. If your colleague is like that my suggestion would be, if you can afford to, is to become The Maven Guy and offer to set up his builds for him; in other words, write his pom.xml files. Do it in parallel with whatever he's using now and then demonstrate to him and the rest of your colleagues how much better it is. Like the old saying goes, you'll draw more flies with honey than you will with vinegar.
cvr wrote:
> I have a colleague has recently become a very vocal opponent of Maven. The
> problem is that we’re behind a corporate firewall, and he has had a lot of
> difficulty getting Maven to work (I googled "firewall" and created a
> ~/m2./settings.xml file appropriately).
>
> His arguments have been:
>
> - "The build system should be more complicated (harder to run, harder to
> configure) than the software"
> - "Why all this configuration for a glorified WGET?"
> - "Why do you need a shared repository (~/.m2/repository)? Disk space is
> really cheap"
> - "What’s wrong with just checking the jars in to source control under lib"
> - "I just have a build script that I run to compile my project, what's so
> hard about that?" (ed. note: it's a bash script)
>
> Having struggled with projects that had *no* build script (from the README:
> "step 1: open up Eclipse and click compile"), projects with undocumented
> dependencies (yay, ClassNotFoundException at runtime), and having fought
> multi-module ant builds for two years - Maven has worked out wonderfully.
> However, I can't seem to get this across. His mind is (angrily) closed.
>
> I'm just wondering if others on this forum have encountered similar
> hostility and you coped with it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Advice on dealing with hostility to Maven 2
Posted by Graham Leggett <mi...@sharp.fm>.
cvr wrote:
> His arguments have been:
>
> - "The build system should be more complicated (harder to run, harder to
> configure) than the software"
> - "Why all this configuration for a glorified WGET?"
> - "Why do you need a shared repository (~/.m2/repository)? Disk space is
> really cheap"
> - "What’s wrong with just checking the jars in to source control under lib"
> - "I just have a build script that I run to compile my project, what's so
> hard about that?" (ed. note: it's a bash script)
>
> Having struggled with projects that had *no* build script (from the README:
> "step 1: open up Eclipse and click compile"), projects with undocumented
> dependencies (yay, ClassNotFoundException at runtime), and having fought
> multi-module ant builds for two years - Maven has worked out wonderfully.
> However, I can't seem to get this across. His mind is (angrily) closed.
>
> I'm just wondering if others on this forum have encountered similar
> hostility and you coped with it.
I have encountered some shockingly broken build systems out there, but
in all cases people recognised they were broken, and were grateful when
it was fixed for them.
Unfortunately I suspect that your colleague lacks experience with
building projects any larger than trivial, and the only solution is to
work around them until they gain enough experience to "get it".
Regards,
Graham
--
Re: Advice on dealing with hostility to Maven 2
Posted by Mark Struberg <st...@yahoo.de>.
Usually when I hear someone complain about 'maven is sooo complicated, why do we need it', it comes from people who do not know how to _really_ manage a project.
Most of them never did:
.) nightly builds
.) automated regression tests
.) any kind of continous integration at all
.) release management (sometimes they at least do manual tagging before shipping products to their customers)
.) maintenance branches
.) good documentation
.) product planing
.) source quality control
etc
So they sometimes really don't see all the points where their life is getting sooo much easier.
Or from a philosophic point: most people only see what is getting worse but take improving situations as a matter of course. Regardless of how big the improvement is.
LieGrue,
strub
--- David C. Hicks <dh...@i-hicks.org> schrieb am Di, 21.10.2008:
> Von: David C. Hicks <dh...@i-hicks.org>
> Betreff: Re: Advice on dealing with hostility to Maven 2
> An: "Maven Users List" <us...@maven.apache.org>
> Datum: Dienstag, 21. Oktober 2008, 4:38
> I've encountered some level of the frustration that
> you're referring
> to. I have found that it mostly stems from ignorance of
> Maven more than
> anything else. My normal reaction, though, is a very
> simple one. I
> offer to turn maintenance of the build system over to
> whoever is
> complaining. That usually shuts them up.
>
> The ones who complain the most are often those who somehow
> missed out on
> the fact that most development tools are actually
> command-line
> oriented. They just don't know how to behave if they
> don't have a
> button to click on. That's when I introduce them to
> M2Eclipse or a
> well-placed external tool. The fact still remains that if
> given the
> choice between maintaining a build themselves or dealing
> with what I
> give them, they succumb to my will. :-)
>
> cvr wrote:
> > I have a colleague has recently become a very vocal
> opponent of Maven. The
> > problem is that we’re behind a corporate firewall,
> and he has had a lot of
> > difficulty getting Maven to work (I googled
> "firewall" and created a
> > ~/m2./settings.xml file appropriately).
> >
> > His arguments have been:
> >
> > - "The build system should be more complicated
> (harder to run, harder to
> > configure) than the software"
> > - "Why all this configuration for a glorified
> WGET?"
> > - "Why do you need a shared repository
> (~/.m2/repository)? Disk space is
> > really cheap"
> > - "What’s wrong with just checking the jars in
> to source control under lib"
> > - "I just have a build script that I run to
> compile my project, what's so
> > hard about that?" (ed. note: it's a bash
> script)
> >
> > Having struggled with projects that had *no* build
> script (from the README:
> > "step 1: open up Eclipse and click
> compile"), projects with undocumented
> > dependencies (yay, ClassNotFoundException at runtime),
> and having fought
> > multi-module ant builds for two years - Maven has
> worked out wonderfully.
> > However, I can't seem to get this across. His mind
> is (angrily) closed.
> >
> > I'm just wondering if others on this forum have
> encountered similar
> > hostility and you coped with it.
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail:
> users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Advice on dealing with hostility to Maven 2
Posted by "David C. Hicks" <dh...@i-hicks.org>.
I've encountered some level of the frustration that you're referring
to. I have found that it mostly stems from ignorance of Maven more than
anything else. My normal reaction, though, is a very simple one. I
offer to turn maintenance of the build system over to whoever is
complaining. That usually shuts them up.
The ones who complain the most are often those who somehow missed out on
the fact that most development tools are actually command-line
oriented. They just don't know how to behave if they don't have a
button to click on. That's when I introduce them to M2Eclipse or a
well-placed external tool. The fact still remains that if given the
choice between maintaining a build themselves or dealing with what I
give them, they succumb to my will. :-)
cvr wrote:
> I have a colleague has recently become a very vocal opponent of Maven. The
> problem is that we’re behind a corporate firewall, and he has had a lot of
> difficulty getting Maven to work (I googled "firewall" and created a
> ~/m2./settings.xml file appropriately).
>
> His arguments have been:
>
> - "The build system should be more complicated (harder to run, harder to
> configure) than the software"
> - "Why all this configuration for a glorified WGET?"
> - "Why do you need a shared repository (~/.m2/repository)? Disk space is
> really cheap"
> - "What’s wrong with just checking the jars in to source control under lib"
> - "I just have a build script that I run to compile my project, what's so
> hard about that?" (ed. note: it's a bash script)
>
> Having struggled with projects that had *no* build script (from the README:
> "step 1: open up Eclipse and click compile"), projects with undocumented
> dependencies (yay, ClassNotFoundException at runtime), and having fought
> multi-module ant builds for two years - Maven has worked out wonderfully.
> However, I can't seem to get this across. His mind is (angrily) closed.
>
> I'm just wondering if others on this forum have encountered similar
> hostility and you coped with it.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Advice on dealing with hostility to Maven 2
Posted by Ro...@toyota.com.au.
Hi cvr,
I think hostility can exist with any change in general. Sometimes it is
really just an attitude thing so you can't use logic to reason with him.
What you need is a mandate (whether it is concencus from team members or
from someone else).
If you don't have a mandate to use Maven then you might as well give up.
If you need his vote to get a mandate then I'd say bribery or blackmail.
Seriously, nothing is wrong with anything he objects, everyone is open to
an opinion but is he professional and humble enough to try something new
and give it an objective assessment. Maven is not perfect, I have a lot of
gripes with it but it is better than anything out there I know at the
moment.
Cheers,
rOnn c.
Russ Tremain <Ru...@Sun.COM>
Sent by: Russ.Tremain@Sun.COM
22/10/2008 04:43 PM
Please respond to
"Maven Users List" <us...@maven.apache.org>
To
cvr <cy...@gmail.com>
cc
users@maven.apache.org
Subject
Re: Advice on dealing with hostility to Maven 2
have you tried the Maven Kool-Aid on him? It's sort-of purplish
and you can buy it at Trader Joe's, but they are often out of stock. :)
bottom line, in maven you can see the dependencies of a project,
in a clearly specified form. there are even visual tools to help.
not so with ant, make, sh, perl, etc. make and ant moved in that
direction, but were overcome by our need to be procedural.
Clearly written maven specifications, with configuration rules centralized
in
a few parent poms, can offer great simplicity for developers creating
new sub-projects within a build system. You can provide archetypes to
make it even simpler.
In contrast, go back and read some of the ant files you wrote 4 or 10
years ago and see if you can figure them out. Better yet, look at some
of the *generated* ant files coming from IDE's, and try to figure those
out.
Not to say you can't write spaghetti code in maven; I've seen it.
You can replicate cannonical configurations to your hearts content,
and generally succumb to the dark forces of entropy, as you can with
any language. This can happen on any development team, especially
once it grows beyond a certain size (N > 1, I think).
But even then, maven is easier to figure out, and it gives rise to an
urge, in certain talented developers, to tidy things up. :)
And if you can't figure out how to do it in maven, then there is always
the antrun
plugin, or even the exec plugin. I find that I use 'em less and less,
however.
BUT, if your friend is really in love with his shell script, then exec it
from
maven and move on.
my 2 cents.
/r
At 7:16 PM -0700 10/20/08, cvr wrote:
>I have a colleague has recently become a very vocal opponent of Maven.
The
>problem is that we're behind a corporate firewall, and he has had a lot
of
>difficulty getting Maven to work (I googled "firewall" and created a
>~/m2./settings.xml file appropriately).
>
>His arguments have been:
>
>- "The build system should be more complicated (harder to run, harder to
>configure) than the software"
>- "Why all this configuration for a glorified WGET?"
>- "Why do you need a shared repository (~/.m2/repository)? Disk space is
>really cheap"
>- "What's wrong with just checking the jars in to source control under
lib"
>- "I just have a build script that I run to compile my project, what's so
>hard about that?" (ed. note: it's a bash script)
>
>Having struggled with projects that had *no* build script (from the
README:
>"step 1: open up Eclipse and click compile"), projects with undocumented
>dependencies (yay, ClassNotFoundException at runtime), and having fought
>multi-module ant builds for two years - Maven has worked out wonderfully.
>However, I can't seem to get this across. His mind is (angrily) closed.
>
>I'm just wondering if others on this forum have encountered similar
>hostility and you coped with it.
>--
>View this message in context:
http://www.nabble.com/Advice-on-dealing-with-hostility-to-Maven-2-tp20082277p20082277.html
>Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
######################################################################
DISCLAIMER:
This email and any attachment may contain confidential information.
If you are not the intended recipient you are not authorized to copy
or disclose all or any part of it without the prior written consent
of Toyota.
Opinions expressed in this email and any attachments are those of the
sender and not necessarily the opinions of Toyota.
Please scan this email and any attachment(s) for viruses.
Toyota does not accept any responsibility for problems caused by
viruses, whether it is Toyota's fault or not.
######################################################################
Re: Advice on dealing with hostility to Maven 2
Posted by Russ Tremain <Ru...@Sun.COM>.
have you tried the Maven Kool-Aid on him? It's sort-of purplish
and you can buy it at Trader Joe's, but they are often out of stock. :)
bottom line, in maven you can see the dependencies of a project,
in a clearly specified form. there are even visual tools to help.
not so with ant, make, sh, perl, etc. make and ant moved in that
direction, but were overcome by our need to be procedural.
Clearly written maven specifications, with configuration rules centralized in
a few parent poms, can offer great simplicity for developers creating
new sub-projects within a build system. You can provide archetypes to
make it even simpler.
In contrast, go back and read some of the ant files you wrote 4 or 10
years ago and see if you can figure them out. Better yet, look at some
of the *generated* ant files coming from IDE's, and try to figure those out.
Not to say you can't write spaghetti code in maven; I've seen it.
You can replicate cannonical configurations to your hearts content,
and generally succumb to the dark forces of entropy, as you can with
any language. This can happen on any development team, especially
once it grows beyond a certain size (N > 1, I think).
But even then, maven is easier to figure out, and it gives rise to an
urge, in certain talented developers, to tidy things up. :)
And if you can't figure out how to do it in maven, then there is always the antrun
plugin, or even the exec plugin. I find that I use 'em less and less, however.
BUT, if your friend is really in love with his shell script, then exec it from
maven and move on.
my 2 cents.
/r
At 7:16 PM -0700 10/20/08, cvr wrote:
>I have a colleague has recently become a very vocal opponent of Maven. The
>problem is that we're behind a corporate firewall, and he has had a lot of
>difficulty getting Maven to work (I googled "firewall" and created a
>~/m2./settings.xml file appropriately).
>
>His arguments have been:
>
>- "The build system should be more complicated (harder to run, harder to
>configure) than the software"
>- "Why all this configuration for a glorified WGET?"
>- "Why do you need a shared repository (~/.m2/repository)? Disk space is
>really cheap"
>- "What's wrong with just checking the jars in to source control under lib"
>- "I just have a build script that I run to compile my project, what's so
>hard about that?" (ed. note: it's a bash script)
>
>Having struggled with projects that had *no* build script (from the README:
>"step 1: open up Eclipse and click compile"), projects with undocumented
>dependencies (yay, ClassNotFoundException at runtime), and having fought
>multi-module ant builds for two years - Maven has worked out wonderfully.
>However, I can't seem to get this across. His mind is (angrily) closed.
>
>I'm just wondering if others on this forum have encountered similar
>hostility and you coped with it.
>--
>View this message in context: http://www.nabble.com/Advice-on-dealing-with-hostility-to-Maven-2-tp20082277p20082277.html
>Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org