What is your favorite build tool?
Mario Fusco
as often happens while browsing the NET
http://kent.spillner.org/blog/work/2009/11/14/java-build-tools.html
Mario Fusco
>
> as often happens while browsing the NET
>
> http://kent.spillner.org/blog/work/2009/11/14/java-build-tools.html
Sorry I sent a partial post by mistake.
Anyway what I wanted to point out is that I found that blog entry
linked in the former email and I have to admit that I 99% agree with
it.
I don't like maven more or less for all the reason underlined in that
post ... plus one: it is not possible with maven to have more than one
source folder in the same module. In more detail I wanted to create a
project partially written in Java and partially in Scala but I
discovered I cannot keep separated the 2 languages in 2 different
source folder. And in my opinion, for a building tool, this is an
unbearable limitation.
In a word I use maven just because almost the whole rest of the world
do the same, but I am far to say that I am happy with it. Often I
found myself regretting the good old Ant.
What do you think about it? Do you feel comfortable with maven or do
you use some other building tool?
Bye
Mario
Fabrizio Giudici
Hi all, as often happens while browsing the NET http://kent.spillner.org/blog/work/2009/11/14/java-build-tools.html
Of course that post spawned discussions in other JUGs too... I try to keep my point short: I've moved from Ant to Maven and I'm sure I'm working much better now; but Maven causes headaches and is not the best option for all cases. But I think that a kind of facility to manage dependencies will become more and more important in future.Sorry I sent a partial post by mistake. Anyway what I wanted to point out is that I found that blog entry linked in the former email and I have to admit that I 99% agree with it. What do you think about it? Do you feel comfortable with maven or do you use some other building tool?
My sad conclusion is that there are no satisfying tools around - which is somewhat surprising!
For what concerns the quoted post, there's some FUD inside:
http://weblogs.java.net/blog/johnsmart/archive/2010/01/06/maven-mythbusters-maven-automatically-updates-every-build
PS I've never compiled a single scala file, so figure out my experience... but I'm not sure the fact that Maven has a "single source folder" is a problem. AFAIK there's src/java, src/resource and there could be src/anythingelse (I mean, it should depend on the Scala compiler plugin rather than on Maven). But this is just my ONE cent ...
-- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/people Fabrizio...@tidalwave.it
federico.y...@post.ch
I think it is very easy to agree with this post. He pointed out a lot of true points.
I would also be ready to evaluate a valid alternative if a migration tool is available...
But I want to see also the good points:
Maven introduced a number of good concepts in the java community:
directory structure, dependency management, build lifecycle and reporting just to list few.
Who uses Maven easily understand the advantages we get for "free".
What is hard to accept is why it produces so many headaches :-)
I think one problem is project immaturity (Maven1 had a lot of limits and a poor design) and a wide scope in an area where no standard was defined.
Maven2 already improved a lot.
With Maven3 they should fix the mismatch between IDE build process (on-the-fly) and command line building (batch).
The second main reason is that those concepts were only understood by a niche of development teams.
Most of Java teams before Maven didn't gave so much attention to code quality and reporting, test cases execution during build, fix directory structure and component reusing.... at least this was true for me: we "just" wanted to build our code.
With Maven exposing those facilities and best practices we all wanted to align and jump on the quality wagon.
Unfortunately most of us were not ready to pay the effort required to implement and maintain that.
A simple problem like splitting a project in multiple components could easily become a nightmare, and the energies required to maintain TestCases "green" for each build led to the natural short cut of commenting the failing test methods.
... but those problems are not caused by Maven! Those goals are hard to reach and to maintain per definition. It is a company strategic decision to decide if it is worth or not to aim for such a quality.
Long story short: I'm positive. The tool is slowly improving to a robust and reliable platform and we are doing a great experience useful for many years.
... and maybe one day we will also change the tool if we get more advantages.
Community and opensource will again demonstrate they payback (at least in the long-term).
Keep on improving!
Ciao,
Federico
-----Messaggio originale-----
Da: jugl...@googlegroups.com [mailto:jugl...@googlegroups.com] Per conto di Mario Fusco
Inviato: venerdì, 8. gennaio 2010 19:19
A: juglugano
Oggetto: [juglugano] Re: What is your favorite build tool?
Mario Fusco
> experience... but I'm not sure the fact that Maven has a "single source
> folder" is a problem. AFAIK there's src/java, src/resource and there
> could be src/anythingelse (I mean, it should depend on the Scala
> compiler plugin rather than on Maven). But this is just my ONE cent ...
Hi Fabrizio,
as you can read at the end of this blog entry
http://www.sonatype.com/people/2009/12/response-to-maven-problems-on-the-jboss-wiki-part-three/
it is sadly true that: "Maven only allows a single source directory
per project". The source, test and resource folders are something
built in the pom file. You can change their default paths, but not
have more than one per module. If you want to have different folders
because you have some generated code you can have an additional folder
by configuring it in the plugin that does the code generation. But if
you need different folders for other reasons (for example to keep 2
languages separated) for what I know there isn't a way to do it.
The purpose of a building tool is of course ... to build your code.
And if it cannot build from more than one source folder, I am sorry,
but IMHO something went extremely wrong :(
Bye
Mario
Mario Fusco
> ... and maybe one day we will also change the tool if we get more advantages.
>
> Community and opensource will again demonstrate they payback (at least in the long-term).
>
> Keep on improving!
>
> Ciao,
> Federico
Hi Federico,
I would like to be as positive as you. But there are some issues
underlined by that post that make me less positive than you. Just to
resume:
1. Maven adds tons of useless dependency to your project making it
even twice or three times bigger than it needs.
2. To have a deterministic build maven requires users to explicitly
specify every version of every dependency, and every dependency’s
dependencies. And being obliged of doing that makes virtually useless
a tool that claims to resolve the dependencies for you.
3. Maven often requires a network connection even when you don't
expect you should need it.
4. Maven configuration is inconsistent and it can behave differently
on your laptop at the office and at home. This is caused mainly by the
fact that the project's configuration it is not completely contained
in the project itself being partially defined in the settings.xml
file.
5. Maven doesn't allow to have more than a source folder per project.
Is that enough to be a little worried, unhappy and negative?
Moreover I don't agree that maven enables some best practices. You can
easily enforce best practices in your team even without it. We had
unit and integration tests, checked their coverage and used tools for
static code analysis even we were still on Ant. Weather you want to
introduce best practices in your team or not it is only up to you.
Cheers
Mario
federico.y...@post.ch
you are probably right.
My main problem in this moment is to define a working structure for a distributed group of people.
I probably rely in Maven to solve this problem instead of searching for another definition.
It could be really interesting to see the concepts correctly applied by another tool, producing the same results.
Anyone available for showing an alternative?
Topic for a JUG meeting?
See you soon,
Federico
-----Messaggio originale-----
Da: jugl...@googlegroups.com [mailto:jugl...@googlegroups.com] Per conto di Mario Fusco
Inviato: venerdì, 8. gennaio 2010 23:07
A: juglugano
Oggetto: Re: R: [juglugano] Re: What is your favorite build tool?
federico.y...@post.ch
-----Messaggio originale-----
Da: Yankelevich Federico, IT161
Inviato: venerdì, 8. gennaio 2010 23:12
A: 'jugl...@googlegroups.com'
Oggetto: R: R: [juglugano] Re: What is your favorite build tool?
Hi Mario,
you are probably right.
My main problem in this moment is to define a working structure for a distributed group of people.
I probably rely in Maven to solve this problem instead of searching for another definition.
It could be really interesting to see the concepts correctly applied by another tool, producing the same results.
Anyone available for showing an alternative?
Topic for a JUG meeting?
See you soon,
Federico
-----Messaggio originale-----
Da: jugl...@googlegroups.com [mailto:jugl...@googlegroups.com] Per conto di Mario Fusco
Inviato: venerdì, 8. gennaio 2010 23:07
A: juglugano
Oggetto: Re: R: [juglugano] Re: What is your favorite build tool?
Fabrizio Giudici
PS I've never compiled a single scala file, so figure out my experience... but I'm not sure the fact that Maven has a "single source folder" is a problem. AFAIK there's src/java, src/resource and there could be src/anythingelse (I mean, it should depend on the Scala compiler plugin rather than on Maven). But this is just my ONE cent ...Hi Fabrizio, as you can read at the end of this blog entry http://www.sonatype.com/people/2009/12/response-to-maven-problems-on-the-jboss-wiki-part-three/ it is sadly true that: "Maven only allows a single source directory per project". The source, test and resource folders are something built in the pom file. You can change their default paths, but not have more than one per module. If you want to have different folders because you have some generated code you can have an additional folder by configuring it in the plugin that does the code generation. But if you need different folders for other reasons (for example to keep 2 languages separated) for what I know there isn't a way to do it.
In any case, the impossibility to do that would be a typical dead-brain inflexibility of Maven.
Fabrizio Giudici
> Hi Mario,
> you are probably right.
> My main problem in this moment is to define a working structure for a distributed group of people.
>
charge for setting up best practices, tools help of course, but both
Ant, Maven and some other can do. What I see is a different way to spend
the time needed to set up the stuff. If you're running a team that you
can control, you can set up the best practice with a mix of Ant and
"documentation" (written or verbal now doesn't matter), where the latter
is prominent. I say so because you end up creating large Ant
infrastructures that others should learn to use. As I said, if you're in
good control of the team and there's good communication, this is doable.
When this is not possible, Maven can be more helpful than Ant since
enforces more stuff and has less variability (it's even too strict and
inflexible, as we were saying two messages ago, but in this case it
could be a positive aspect). You don't have to document the structure of
a project, since it's Maven that "documents" it. Unfortunately, you have
to spend more for making it work in the way you like. I've convinced
myself that large open source project are best handled with Maven -
think them as the extreme case for the "distributed group of people"
Federico was referring to.
So, you spend a lot in either case, just in different ways.
I absolutely agree that Maven bring less determinism into the picture;
especially when you consider the use of a local repository (e.g. Nexus),
that is something you definitely want for serious development, but that
unfortunately brings more complexity (e.g. cache expiration times,
etc...) - and if your build works, you're testing it against your
locally proxied repos, not necessarily what others see. See my latest
blog post for instance.
Andrea Chiodoni
The point is, forgetting for a moment the maven tool and its good or bad features, the project structure standardization it forced "world wide" is a good thing. Not because the structure itself is perfect BUT JUST BE BECAUSE EVERYBODY IS USING IT.
Speaking about dependency management: the rules and the syntax the tools (maven, ivy,...) implements are important BUT THE MOST IMPORTANT IS TO HAVE CORRECT METADATA ON THE DEPENDENCY REPOSITORY. Without good metadata any tool will never be better! For this reason, since both ivy and maven use the same repositories, I'm quite convinced that with both maven or ivy you end-up with more or less the same "build result" (probably writing little less dependency configuration with ivy (or even not if you let ivy use you pom)).
@Mario: why would not be ok to keep scala files on src/main/scala and java files on src/main/java if they logically belong to the same module? (http://scala-tools.org/mvnsites/maven-scala-plugin/usage_compile.html) At the end, one maven module = one artifact = one, why not one source folder?
Andrea
Fabrizio Giudici
>
> Speaking about dependency management: the rules and the syntax the tools (maven, ivy,...) implements are important BUT THE MOST IMPORTANT IS TO HAVE CORRECT METADATA ON THE DEPENDENCY REPOSITORY. Without good metadata any tool will never be better! For this reason, since both ivy and maven use the same repositories, I'm quite convinced that with both maven or ivy you end-up with more or less the same "build result" (probably writing little less dependency configuration with ivy (or even not if you let ivy use you pom)).
>
report? And Maven implements some "intelligence" to get the right
artifact when there are conflicts (for instance, your project has a
transitive dependence to X that is v1.2 and another which is v1.3) -
does Ivy do the same?