What's in a name...

Using descriptive names is a good programming practice. Today I came across an example that does quite the opposite. In Maven 2 you can define a proxy when you are working behind a proxy server, and there is this active flag that sets this proxy to active or inactive.... or at least that is what you expect right?

Here is how you can configure a proxy in your settings.xml

  
    
      company-proxy
      false
      http
      proxy.company.nl
      8080
    
  

You would think this would mark the company-proxy as not active. But reality taught me otherwise. Here is the corresponding Maven code that returns the active proxy:

    public synchronized Proxy getActiveProxy()
    {
        if(activeProxy == null)
        {
            java.util.List proxies = getProxies();
            if ( proxies != null && !proxies.isEmpty() )
            {
                if ( proxies.size() > 1 )
                {
                    for ( java.util.Iterator it = proxies.iterator(); it.hasNext(); )
                    {
                        Proxy proxy = (Proxy) it.next();
                        if ( proxy.isActive() )
                        {
                            activeProxy = proxy;
                            break;
                        }
                    }
                }
                else
                {
                    // If we only have one proxy, use it as the active one.
                    activeProxy = (Proxy) proxies.get( 0 );
                }
            }
        }

        return activeProxy;
    }

So apparently "active" does not mean "active", but actually means "active if there is more than one proxy defined". So I suggest to change the name of the "active" property into something like: activeButIfIAmTheOnlyProxyDefinedInTheListOfProxiesThenIAmAlwaysActive. Or perhaps clear documentation would also be an option if you think the name is too long.

Would have saved me half a day of debugging....

Lars

Comments (7)

  1. Erik Pragt - Reply

    August 28, 2008 at 11:37 am

    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 😉

  2. Lars Vonk - Reply

    August 31, 2008 at 9:53 pm

    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 .

  3. Olivier Croisier - Reply

    September 2, 2008 at 12:42 pm

    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.

  4. Nick Stolwijk - Reply

    September 3, 2008 at 12:46 pm

    Have you mentioned this on the mailinglist? This seems like a bug or at least unwanted behaviour.

  5. Lars Vonk - Reply

    September 3, 2008 at 2:14 pm

    @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...

  6. Nick Stolwijk - Reply

    September 4, 2008 at 10:21 am

    @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.

  7. Olivier Croisier - Reply

    September 4, 2008 at 11:32 am

    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.

Add a Comment