cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Gianni <s.gia...@thebug.it>
Subject Re: [RANT] This Maven thing is killing us....
Date Sun, 02 Jul 2006 03:27:11 GMT
Hi all,
after a weekend of fights, I managed to have all projects (yes, all the
blocks) loaded in eclipse with only 4 errors, which are actually not
real errors. This involved the following operations :
- Adding some dependencies in pom.xml files, in particular :
... Some blocks didn't included junit
... Many blocks didn't have a dependency to core
... A couple of blocks needed many more dependencies (osgi, spring,
avalon, servlet api etc..)
- Changing some packages : we had some
src/java/<somethinghere>/org/apache... folders (mocks mainly) that are
not accepted in maven since it searches for src/main/java/org/apache...
- The eclipse maven plugin quite often does not add the dependency to
core in the eclipse project, althought it's there in the pom.xml file.
- The eclipse maven plugin quite often adds a duplicate dependency to
core, since in the pom there are two dependencies one of which is marked
for tests only.

I don't know if what I've done is a good work or not, I will commit it
in a single revision so that it's easy to roll back it in case I made
mistakes.

In general, my opinion is that :
- Yes, public repositories are a problem, having some control over it
would be useful.
- Yes, we should find a way to add jars not mavenizing stuff from other
projects (see my previous mail about dojo).
- No, we should not move away from maven, at least not for 2.2, because
that would mean not only throw away a lot of work, but also because
maven is a good idea and is an apache product and I think we should
cooperate with the maven team to achieve our common goals.

Things I find more annoying in maven are the following :
- If it fails a download, it simply abort the build, every network
application knows that a temporary problem on a network can happen, and
I think maven should try to redownload the file a couple of times (using
range download would be cool too) before simply giving up. It's so
simple to implement, and would solve so many problems, that I really
cannot understand why it's not there anymore.
- Negative caching : I'm tired of seeing 20 HTTP requests go out
searching for the spring 2.0 RC1 poms which simply does not exist, Maven
should cache negative response to avoid this waste of time.
- Caching in general : there are many similar technologies out there
(linux distros for example, portage for gentoo and dpackage for
debian/ubuntu), and they all relay on having a local copy of the
repository metadata. This greatly improves performances, since
connections to the server are made only to fetch actual payload (jars)
and not to verify if a file is there. Ibiblio currently list 609
"packages" (nothing compared to the thousands of any linux distro), even
only listing existing artifacts in a string form would result in a text
file with a few thousand lines, which zipped would not exceed a few
hundred KB, and would avoid all those useless HTTP requests on the
servers to see if something is there or not. Again, this is so simple
and so effective that I really don't understand why maven team decided
for the current obsolete approach that linux distros dropped years ago.
- There is no GUI support (if you know any please point them out) since
mavenide for eclipse is only for maven 1.0.

Why don't we prepare a mail for the maven team explaining them our
concerns about maven and asking for solutions to our biggest problems?

Simone

-- 
Simone Gianni

Mime
View raw message