Hi Matthias,

I completely agree with you. Maven - I assume you targeted Maven2 ;-) - is fine to setup and build more complex projects with lot of dependencies to external libraries etc. Compared with ANT, there is for JUnit no real benefit at the end.

A restructuring following "standard" directory schemas as proposed below is in general a good idea, but requires a migration to SVN first (as you mentioned too).

So I would propose:

1. Stay at the current ANT based build process
2. Migrate some day from CVS to SVN (it is up to the committers and work load, but not too hard using cvs2svn migration tools)
3. Restructure directory structure to a well known standard layout

Meanwhile, the current build process can be beautified a litte bit, to ensure a more clean junit4x.jar with only the required resources at the end. That is even possible with the current directory layout.

Only me 2 cents of worth, Cheers, Jochen

On 10/27/06, Matthias Schmidt <matthias.schmidt@gmx.de> wrote:

yes I have used Maven. Maven can do what we would like to do with JUnit with just a few lines of XML:
- compile the sources
- build a junit.jar with the JUnit core
- build a src.jar
- build a test.jar for the tests
- create javadoc
- run unit tests (I know there is a plugin for 3.8.1 but I am not sure about 4.x)

But the downside is: To use maven, we would have to move the files. So it would be good to move to Suversion before. The outline would have to look like this:
|-- pom.xml
`-- src
    |-- main
    |   `-- java
    |       `-- org
    |           `-- junit
    |               `-- Assert.java
    `-- test
        `-- java
            `-- org
                `-- junit
                    `-- AssertionTest.java

The pom.xml (Maven's equivalent to build.xml) is IMHO not as readable as a clean build.xml. Here is a short example from the Maven site:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance "
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <version>1.0-SNAPSHOT </version>
  <name>Maven Quick Start Archetype</name>

Another disadvantage is that Maven does not come bundled with every IDE. And he last time I looked at the Maven Eclipse plugin, it was not nearly as good as the Ant support.

I agree that in the end we only get the same junit.jar that we got from Ant before. I tend to only use Maven in new projects, but not migrate from Ant to Maven.

Any thoughts from anybody else?


-------- Original-Nachricht --------
Datum: Tue, 24 Oct 2006 16:33:39 -0400
Von: David Saff < saff@mit.edu>
An: Matthias Schmidt <matthias.schmidt@gmx.de>
Betreff: Re: [Junit-devel] Refactoring of ANT build (see patch 1581944)

> Matthias,
> Have you used Maven?  I've been intrigued in the past, but concerned
> that the incremental improvement in build structure wouldn't be worth
> the extra dependency.  What's your take?
>     David Saff
> Matthias Schmidt wrote:
> > Thomas,
> >
> > Then we could move to Maven. Maven does all you suggest automatically
> > (more or less ;-)).
> >
> > But you are right: Files would have to be moved for that.
> >
> > Regards,
> > Matt
> >
> > worodin schrieb:
> >
> >> Hey ho list!
> >>
> >> Is there any opinion regarding the ideas I mentioned in
> >>
> https://sourceforge.net/tracker/?func=detail&atid=315278&aid=1581944&group_id=15278 ?
> >>
> >> What I'm suggesting there is, moving into the direction of a layout,
> >> that has been prouven in many open source projects.
> >>
> >> A.)
> >> Arguments for separating sources from generated output (e. g. classes)
> >> - much easier to do a clean
> >> - no need to to maintain .cvsignore, IDE view filters etc just to have
> a
> >>  nice and clean screen.
> >> - fewer messy exclusion filters in ant
> >>
> >> B.)
> >> Arguments for separating test from application sources:
> >> - fewer messy exclusion filters in ant
> >> - easier separation of sources, even if they are not in a *.test.*
> >> package and do not contain the infix *Test* e. g. for javadoc, jar.
> >>
> >> - Only drawback here: you need to navigate two trees (actually, I don't
> >> see this as a drawback, but rather as a visual aid)
> >>
> >> A.) is easy to achieve with the current CVS layout, but B.) would
> >> require moving some things around. In CVS this would result in loosing
> >> the change history. Now I'm remembering remotely somebody else
> >> suggesting to move to SVN. Doing so, would offer the following:
> >>
> >> - First, migrate to SVN first. SVN documentation states, that CVS
> >> history can be ported too.
> >> - Then start B.) SVN versions directories, keeping the history, when
> >> moving files.
> >>
> >> Let me know, what you think of it.
> >>
> >>
> >> Thomas
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
Junit-devel mailing list