[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [swtbot-dev] Moving build to Tycho
|
This is not a rant against you, I like you personally. I just don't like
it when people I like, like maven :P
Based on some real life war stores, and some real scars to go along:
<really long maven rant>
Maven is a festering pile of shit with absolutely no redeeming
qualities. I'm disappointed to see others being so generous to it in
this thread. :( My honeymoon period with maven ended beyond the
Everything Maven advocates tell you is a fscking lie:
* Convention over configuration: bullshit! The only convention Maven
supports without requiring configuration is: compile, run unit tests,
package .jar file. Anything else requires configuration, and lots of
it! Things you can do in 1 or 2 lines in an Ant build script require 6,
7, 8 lines of verbose configuration in your pom files (if you can even
do it at all).
-- Check out the pom.xml configuration reference to see how you declare
filesets with exclusion/inclusion filters in Maven :(
* Dependency management: Maven is NOT a dependency management tool!
Maven is a "download ibiblio and dump everything on the classpath" tool.
-- The original Maven build on a recent project took 3 minutes and
produced a 51 MB .war file; after switching to Ant with manual
dependency management, our build took only 1 minute to run the same
tests and produce a functionally equivalent 17 MB .war file.
-- I recently endured a 10 minute "mvn clean" Apparently, there were
unresolved dependencies Maven needed to download before it could delete
./target/
-- Maven dependency management is broken and wrong (aside: automatic,
transparent transitive dependency management is an intractable problem
due to human factors, and ultimately not worth solving, regardless of
tool; it's not that hard to correctly manage dependencies by hand, it is
the only correct and proper way to manage dependencies, and
svn:externals or git submodules are your only real dependency management
friends). Your build WILL break when the dependencies of your
dependencies upload new .jar files with the same version number, but
with non-backwards compatible changes. The workarounds (explicitly
configuring specific instances of artifacts in some local artifact
repository) are all functionally equivalent to checking in .jars to your
version control repository, but more complicated - and sometimes more
expensive.
* You can always rebuild the same artifact twice: fscking lie.
-- Your build is at the mercy of a maven repository always having the
same jar you need. Turns out that this is *NEVER* the case. Try building
any open source project using maven off a tag that is an year old.
Chances are that it will not build. Ever tried building an year old
version of something that uses ant ?
* Consistent builds and build files: there's nothing consistent about
either Maven itself or the builds it performs. Some things in Maven are
configured as classpath references to .properties files bundled in a JAR
and included with a project's dependencies, and some things are
configured as absolute or relative paths to files on disk, and some
things are configured as system properties in the JVM running Maven.
And some of those absolute paths are portable across projects because
Maven knows how to correctly resolve them, but some are not. And
sometimes Maven is smart enough to recursively build projects in the
correct order, but sometimes it's not.
-- Maven builds are nondeterministic.
-- The original Maven build on a recent project also suffered from a
curious anomaly that we never solved: the first build of the morning
would always fail. The work-around was to explicitly build only the
first module in our project (i.e. the one that didn't depend on any of
the other modules in our project), install it into the local Maven
repository, and then re-run the full build. This was the case with
every machine, every day. WTF?!
If you get shafted with Maven on any project, you have my deepest and
most sincere sympathy. Maven build processes are an infinite cycle of
despair that will slowly drag you into the deepest, darkest pits of hell
(where Maven itself was forged). You will initially only spend 10
minutes getting Maven up and running, and might even be happy with it
for a while. But as your project evolves, and your build grows, the
basic pom that you started with will prove inadequate. You will slowly
add more configuration to get things working the way you need, but
there's only so much you can configure in Maven; you will come to desire
the flexibility and scripting abilities of Ant (I know! Can you believe
it?! Yearning for the flexibility and scriptability of Ant?! Only with
Maven...). Soon thereafter, you will encounter Maven's low glass
ceiling for the first time. By "encounter," I mean "smash your head
painfully against." By "for the first time," I mean "you will do this
repeatedly and often." Eventually, you'll figure out some convulted
pom.xml hackery to work around your immediate issue. You might even be
happy with Maven again for a while... until another Maven limitation
rears its ugly little head. It's a lot like some tragic Greek myth,
only you are the damned soul and the eternity of suffering is your day job.
I'd save myself that pain and headache and use Ant, Buildr, Rake,
anything but Maven!
</really long maven rant>
--
Ketan
http://ketan.padegaonkar.name | http://eclipse.org/swtbot
On 11/8/10 3:21 PM, Mickael Istria wrote:
Hi all,
Since I get convinced by Pascal Rapicault and other folks at
EclipseSummit that Tycho is a great build tool, I started some work on
SWTBot to move the build to Tycho.
Tycho allow bundles to be built separately, and then reaggregated in a
feature or a p2 repository. Moreover, it is easy to leverage several
target platforms and to build and test bundles against different
releases of Eclipse.
The benefits of such a move would be:
* Easy to kick a build: "mvn clean install".
* Easy to modify code and see tests and results immediatly.
* Easy to tweak build. Since it is Maven, anyone who want to tweak the
build can do it in the Maven way, which is far more easy to understand
than hacking ant scripts.
* More community around Tycho. Tycho is rising, more and more people use
it, it is easy to get help if necessary
* Tycho is Maven, then it is really easy to integrate it in CI tools
such as Hudson.
All that stuff makes the project easier to tweak and to build. Newcomers
to SWTBot will have less pain to work on bugfixes and so on. It will for
sure be a step forward in increasing the SWTBot contributors community.
Moreover, if we succeed to have SWTBot building and testing on a very
repeatable way, we can easily integrate the release build in the
hudson.eclipse.org, and that would be a great move towards integration
of SWTBot in an Eclipse release train...
When I tried to move to Tycho with the help of Pascal during ESE, I
faced the problem reported on bug 329436
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=329436>, which is a hacky
way to resolve the issue of dependency management against different
versions of Eclipse. I reversed some of these dependencies to solve the
issue in a more OSGi-friendly way, leveraging optional dependencies and
contrained versions. I can get it working in dev-mode, but I did not try
to kick a build yet. Now it seems that there is no more need of hacking
the MANIFEST files and so on, so that I can start trying Tycho. I'll
give you some results ASAIGET (as soon as I get enough time). Any help
is welcome on this topic.
What do you think of such a move? I personnally think it is a great way
to facilitate development of SWTBot and to gather more people around the
project. Do you agree with it?
Regards,
--
Mickael Istria
R&D Engineer
BonitaSoft - Open your processes <http://www.bonitasoft.com>
email : mickael.istria@xxxxxxxxxxxxxx
This message and any attachment (the "message") is intended solely for
the addressees and is confidential. If you receive this message by
mistake, please delete it and notify the sender immediately. Any use not
in accordance with its purpose, any out-spread or disclosure, either as
a whole or partially, is prohibited except with formal approval.
Internet cannot guarantee the integrity of this message, therefore
BonitaSoft will not be liable for the message if modified.
_______________________________________________
swtbot-dev mailing list
swtbot-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/swtbot-dev
