Discussions

News: Maven-style Dependency Management in Ant

  1. Maven-style Dependency Management in Ant (8 messages)

    The Maven team have released a set of Ant tasks for performing dependency management within your Ant scripts. This includes:
    • Transitive dependencies
    • Snapshot handling
    • Scope tracking
    • Deployment using SCP, SFTP, and file protocols
    The tasks are based on the Maven 2.0 artifact handling code, so they behave identically. The version included is slightly newer, from the upcoming alpha-2 release.

    An example of use:

    <artifact:dependencies pathId="dependency.classpath">
      <dependency groupId="org.apache.maven.wagon" artifactId="wagon-provider-test" version="1.0-alpha-2"/>
    </artifact:dependencies>

    A download is available, and instructions for use are available from the Maven web site.

    Threaded Messages (8)

  2. Good news that this feature is available to ant users !

    For TSS readers information, there are also some other existing tools to manage dependencies, including one on which I work and which should reach its 1.0 version tomorrow: Ivy.

    It has not exactly the same behaviour, but it may interest some of you as being able to handle some different cases, in particular configurable repositories and a more flexible "scope" handling (known in Ivy as "configurations") which gives you a better control over transitive dependencies.

    Just my 2 c.
  3. Merging of Ant and Maven[ Go to top ]

    Maybe we'd just end up ant and maven merging into one product.

    Something like a build.xml that starts with.

    <project maven:descriptor="project.xml">
    </project>

    So ant will have access to maven elements.
  4. No, No, NO![ Go to top ]

    Maybe we'd just end up ant and maven merging into one product.

    Please, in the name of all that's holy, no. Ant does what I need it to do, namely build source code. And, it does it fairly well. I don't need all that additional rubbish required by Maven just to do a build.

    If you need to document a project, don't mess with the build process. Write documentation.
  5. maven and additional rubish[ Go to top ]

    Althought I recognize that setting the POM can seem tedious the first times, it's not that hard.
    And nobody forces you to use the reporting features in maven.

    Maven is not only adding 'additional rubish' to do a build. Dependency management is one, artifact deployment is another one, coherent project structure is another one, etc... Maven appeared to solve some problems that ant users faced on real projects, things that they had to enforce manualy before.

    Once you start to split your work into modules, you end up with a nice build. Ant build projects files have a tendency to grow big if you don't pay attention to them, with a lot of duplicated code across projects if you don't force yourself to reuse the XML code.

    And to come back to the article, the new ant dependency management features come directly from maven2... So the projects aren't merging (and won't), but code reuse is on its way.
  6. UBT-oriented design[ Go to top ]

    <joke>
    this sounds like adopting the UBT (Unique-Big-Tool) model for the ANT and Maven projects.
    Maybe one day we'll have a single vastly configurable tool which does everything.
    Sure M$ is going toward it (DB into the OS, spyware into OS, scripting tool into OS, antivirus into OS...)
    </joke>

    I thinks if would be interesting, however:
    - it should _not_ require POM editing, just support any grain the user wants to have from javac-only to full POM
    - it should _not_ require any environment setup, like ant does not
  7. UBT-oriented design[ Go to top ]

    I thinks if would be interesting, however:
    - it should _not_ require POM editing, just support any grain the user wants to have from javac-only to full POM

    POMs are only required for deployment, and then they only require the minimum information required to make it useful: groupId/artifactId/version and deployment repository, and dependencies to make transitive depenencies work.

    So they are not required for dependencies.
    - it should _not_ require any environment setup, like ant does not

    This does not require any environment setup, unless you are talking about the antlib definition and the inclusion of the JAR in the lib directory which is rather hard to avoid...
  8. Merging Maven + Ant[ Go to top ]

    Chances for merging Maven and Ant are very low. But both are popular tools. And both teams recognize the others work and learn from them. So Maven uses some functionality from Ant and Ant uses some ideas from Maven. Only some! Ant keeps a build tool.
  9. Between Maven and Ant[ Go to top ]

    I agree that's why I decide to create a light build system based on Ant.
     The concept is to generate a standard Ant build.xml from a project description. Plugins are there to provide additional features.
     Let's have a look: http://el4ant.sourceforge.net/