Comments on: What’s in a name… http://blog.xebia.com/2008/08/28/whats-in-a-name/ Thu, 11 Mar 2010 16:23:01 +0100 http://wordpress.org/?v=2.8.4 hourly 1 By: Olivier Croisier http://blog.xebia.com/2008/08/28/whats-in-a-name/comment-page-1/#comment-52192 Olivier Croisier Thu, 04 Sep 2008 09:32:55 +0000 http://blog.xebia.com/?p=728#comment-52192 Yes, Ant scripts can also run quickly out of control if no guidelines / good practices are set by the architects or integration team. But I believe that if you follow some common sense practices (for example, having standard targets like "clean", "build"... and parameters put into properties files), Ant scripts can stay rather clean. Using calls between scripts, you can even factorize standart targets into a project-agnostic reusable script, and then extend it with additional project-specific (or temporary) targets in another file. One thing I don't like in Ant, though, is the ability/need to (re)name the tasks when you import them, as the very same task can then be named differently in different scripts... This helps prevent task name collision, but I think namespaces would've been a better solution. As for parameter naming (back to the main topic), I suggest never using negative forms, as double negative are harder to understand (ex: inactive=false) : use "active" (or "isActive") instead of "inactive", "enabled" instead of "disabled" - you get the idea. Yes, Ant scripts can also run quickly out of control if no guidelines / good practices are set by the architects or integration team.

But I believe that if you follow some common sense practices (for example, having standard targets like “clean”, “build”… and parameters put into properties files), Ant scripts can stay rather clean.
Using calls between scripts, you can even factorize standart targets into a project-agnostic reusable script, and then extend it with additional project-specific (or temporary) targets in another file.

One thing I don’t like in Ant, though, is the ability/need to (re)name the tasks when you import them, as the very same task can then be named differently in different scripts… This helps prevent task name collision, but I think namespaces would’ve been a better solution.

As for parameter naming (back to the main topic), I suggest never using negative forms, as double negative are harder to understand (ex: inactive=false) : use “active” (or “isActive”) instead of “inactive”, “enabled” instead of “disabled” – you get the idea.

]]> By: Nick Stolwijk http://blog.xebia.com/2008/08/28/whats-in-a-name/comment-page-1/#comment-52181 Nick Stolwijk Thu, 04 Sep 2008 08:21:53 +0000 http://blog.xebia.com/?p=728#comment-52181 @Lars: It also doesn't have a patch or that many votes, so maybe not many people are annoyed at it. Maybe if you could provide a patch and or vote on it, it can be in the next release. I wouldn't think anyone relies on this behavior. @Lars: It also doesn’t have a patch or that many votes, so maybe not many people are annoyed at it. Maybe if you could provide a patch and or vote on it, it can be in the next release. I wouldn’t think anyone relies on this behavior.

]]> By: Lars Vonk http://blog.xebia.com/2008/08/28/whats-in-a-name/comment-page-1/#comment-52059 Lars Vonk Wed, 03 Sep 2008 12:14:31 +0000 http://blog.xebia.com/?p=728#comment-52059 @Oliver: I have some negative experiences with ant; it quickly becomes an unmaintable buildscript.... But perhaps it is time to give ant and ivy a real change. @Nick: I didn't post it on the mailing list since there is already a bug reported on this issue on 17-06-2006: http://jira.codehaus.org/browse/MNG-2387. Apparently it has no priority. As workaround I just added an extra dummy proxy that always has its active flag set to false... @Oliver: I have some negative experiences with ant; it quickly becomes an unmaintable buildscript…. But perhaps it is time to give ant and ivy a real change.

@Nick: I didn’t post it on the mailing list since there is already a bug reported on this issue on 17-06-2006: http://jira.codehaus.org/browse/MNG-2387.
Apparently it has no priority.

As workaround I just added an extra dummy proxy that always has its active flag set to false…

]]> By: Nick Stolwijk http://blog.xebia.com/2008/08/28/whats-in-a-name/comment-page-1/#comment-52058 Nick Stolwijk Wed, 03 Sep 2008 10:46:04 +0000 http://blog.xebia.com/?p=728#comment-52058 Have you mentioned this on the mailinglist? This seems like a bug or at least unwanted behaviour. Have you mentioned this on the mailinglist? This seems like a bug or at least unwanted behaviour.

]]> By: Olivier Croisier http://blog.xebia.com/2008/08/28/whats-in-a-name/comment-page-1/#comment-51922 Olivier Croisier Tue, 02 Sep 2008 10:42:35 +0000 http://blog.xebia.com/?p=728#comment-51922 If you want an alternative, Ant and Ivy work just fine, and provide dependency management via maven repositories (which is often the main feature causing the adoption of Maven over Ant). In my opinion, from a paradigm point of view, Ant and Maven are perfect opposites : - the first is non-invasive and easily adapts to any project's structure, whereas the second forces your projects to fit into its own rigid structure (which I think is inherently a *bad* idea). - Ant's scripts are transparent to the developers and integrators, can be looked at and easily changed or extended; Maven is a big black box and extending it is quite... painful. Admitted, my opinion might be (well, IS) quite biased by several negative experiences with Maven (including those you mention : slooow dependency resolution, bad IDE plugins, mysterious un-debuggable behaviours...). Let's not forget that Maven was developed for the specific needs of the Apache Foundation, whose many projects needed "standardized" automated building and website generation. Using it blindly on each and every enterprise project doesn't seem a good idea to me. If you want an alternative, Ant and Ivy work just fine, and provide dependency management via maven repositories (which is often the main feature causing the adoption of Maven over Ant).

In my opinion, from a paradigm point of view, Ant and Maven are perfect opposites :
- the first is non-invasive and easily adapts to any project’s structure, whereas the second forces your projects to fit into its own rigid structure (which I think is inherently a *bad* idea).
- Ant’s scripts are transparent to the developers and integrators, can be looked at and easily changed or extended; Maven is a big black box and extending it is quite… painful.

Admitted, my opinion might be (well, IS) quite biased by several negative experiences with Maven (including those you mention : slooow dependency resolution, bad IDE plugins, mysterious un-debuggable behaviours…).

Let’s not forget that Maven was developed for the specific needs of the Apache Foundation, whose many projects needed “standardized” automated building and website generation.
Using it blindly on each and every enterprise project doesn’t seem a good idea to me.

]]> By: Lars Vonk http://blog.xebia.com/2008/08/28/whats-in-a-name/comment-page-1/#comment-51674 Lars Vonk Sun, 31 Aug 2008 19:53:35 +0000 http://blog.xebia.com/?p=728#comment-51674 Hi Erik, actually I am not implying to ditch Maven... (although sometimes I feel like it). But if you know a serious alternative let me know . Hi Erik, actually I am not implying to ditch Maven… (although sometimes I feel like it). But if you know a serious alternative let me know .

]]> By: Erik Pragt http://blog.xebia.com/2008/08/28/whats-in-a-name/comment-page-1/#comment-51394 Erik Pragt Thu, 28 Aug 2008 09:37:08 +0000 http://blog.xebia.com/?p=728#comment-51394 I very much agree on the naming of 'stuff' in general, but I also have a +1 on ditching Maven. That's what you're implying right? Even though I'm quite a big fan of Maven (especially since IntelliJ integrates so well with it), my experience also learns me that we spend more than a day each iteration fixing Maven. Problem we encounter are not being able to find dependencies (even though we have a transparant proxy, and it worked yesterday), the build behaving differently on our build server than locally, very, very, very slow dependency resolution, conflicint dependencies, more pom XML than we have code (well, almost....) So I totally agree on the naming. And replacing Maven ;) I very much agree on the naming of ’stuff’ in general, but I also have a +1 on ditching Maven. That’s what you’re implying right?

Even though I’m quite a big fan of Maven (especially since IntelliJ integrates so well with it), my experience also learns me that we spend more than a day each iteration fixing Maven. Problem we encounter are not being able to find dependencies (even though we have a transparant proxy, and it worked yesterday), the build behaving differently on our build server than locally, very, very, very slow dependency resolution, conflicint dependencies, more pom XML than we have code (well, almost….)

So I totally agree on the naming. And replacing Maven ;)

]]>