portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roger Ruttimann <roger.ruttim...@earthlink.net>
Subject Re: [VOTE] J2 Bulid: Ant vs. Maven
Date Sat, 25 Feb 2006 22:30:24 GMT
I have seen all the posts on this thread and it seems that a move to ant 
is in
favor of people that replied.

Despite of some shortcomings of maven-1 (documentation/plugins) it's still
a powerful tool especially the dependency check. We use maven in our company
and an advantage was that it was simple to add a new project by defining the
dependencies (project.xml) and use the default tasks (war) for a build.

The general trend for apache projects builds is to move to maven-2.
The response so far was positive and lot of  maven -1 issues are
resolved with maven-2. If we change the build tool it should be
maven-2 rather than ant.

In my opinion the major issues of the build process are not the tools 
but the
complexity of the project. To many dependencies to internal components.
I don't think ant would be a good tool to manage that. With the current
complexity ant's build.xml would become un-manageable.

There was an email thread to simplify the structure and make the build 
more manageable. We should continue on that.

My suggestion is the following:

    * Simplify the complexity of the Jetspeed build.
    * Decide if we stay with maven-1 or go with maven-2


Randy Watler wrote:

>We now have a marginal Maven2 build that is capable of building J2 and
>installing on Tomcat. While it has been fun reinventing the wheel for
>the Nth time, it is time to get serious about the J2 build. Here are the
>1. Continue on with Maven1/J2 plugin.
>2. Step up and complete the Maven2 build and create an archetype to
>replace the genapp capabilities.
>3. Ditch maven and go with Ant.
>We need to vote on this before I or anyone else puts more sunk time into
>the build. Here are some of the issues:
>1. Ant is simple and everyone understands it.
>2. Maven1 and the plugin are not stable and are generally complex.
>3. Maven2 has simplified things in some ways, but made them more complex
>in other ways with the pom.xml inheritance and transitive dependencies.
>4. Ant build.xml files can become unmanageable.
>5. Maven2 may not be sufficiently mature for our use; we have
>encountered several bugs and have used some ugly workarounds for even
>our simple build cases handled to date.
>6. J2 users have not been exposed to maven, and it can become a
>liability quickly since they expect Ant like builds.
>7. All IDEs, including Eclipse, can natively build Ant based projects.
>8. When the BSR or other repos are down, the Maven offline builds are
>9. The training/learning curve with maven is hurting acceptance of the
>J2 portal solution.
>10. The repository in Maven2 will become even more difficult to manage
>with the transitive dependencies: in the end, we will be forced to
>manage our own repository and all of the J2 users will need to do the
>I am sure there are more... this is not exactly a new topic for any of
>us. We are just at the point where we need to make a final decision that
>can stand the test of time... J2 needs our cycles, not the build
>environment. I am willing to put more time into the build no matter
>which way we choose to go... but not unless there is a consensus on the
>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
>For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

View raw message