Maven Buildprocess about javahamcrest

[npryce]

Maven is obsolete. If we're going to change the build tool we should go for either Gradle (for cross-platform compatibility) or Gnu Makefile (for ease of maintenance). The POMs should be an output of the build.

[EarthCitizen]

Whatever is ued ...Gradle or Maven ...I think the build could be greatly simplified and should be simplified. And dependent jars should not be a part of the project, but rather pulled in by the build.

I would put my money for Gradle as being the way to go for the future until the next great thing comes out down the road. Maven, though still the most widely used tool, has probably peaked in popularity.

But dependency management and ease of build is a definite problem for this project.

[sf105]

Why? We have few dependencies and the versions are fixed. You can check out the project and don't need another connection.

S

Steve Freeman
http://www.higherorderlogic.com

Written on a phone, so please allow for typos and short content.

On 17 Nov 2014, at 19:52, EarthCitizen [email protected] wrote:

Whatever is ued ...Gradle or Maven ...I think the build could be greatly simplified and should be simplified. And dependent jars should not be a part of the project, but rather pulled in by the build.

—
Reply to this email directly or view it on GitHub.

[EarthCitizen]

@sf105 Those dependencies, once they are (automatically) downloaded, are stored in a local repository. They are not fetched each time you build. So, you don't have to be online to use those external dependencies. Connect once to fetch the source and dependencies. And that's it.

[sf105]

I understand that. I'm failing to see what the advantage of the effort of porting to maven is. What exactly is missing from the current set up?

S

On 17 Nov 2014, at 20:07, EarthCitizen [email protected] wrote:

@sf105 Those dependencies, once they are (automatically) downloaded, are stored in a local repository. They are not fetched each time you build. So, you don't have to be online to use those external dependencies. Connect once to fetch the source and dependencies. And that's it.

—
Reply to this email directly or view it on GitHub.

[EarthCitizen]

I am not specifically supporting Maven over Gradle. But,

http://www.kyleblaney.com/benefits-of-maven-over-ant/
http://books.sonatype.com/mvnref-book/reference/installation-sect-compare-ant-maven.html

The short version:

• dependency management
• transitive dependencies
• no jars in the source code repository
• most of the ordinary build tasks that you have to explicity define (or at least give details for) in Ant are built-in to Maven (packaging, testing, compiling, generating source jars, release management)
• consistent project structures making things easier for contributors

If there is still some unusual type of task that absolutely must be done with Ant for some reason, Ant tasks can be run from Maven.

And from what I have read, Gradle is supposed to be leaps and bounds ahead of Maven in the same way that Maven is leaps and abounds ahead of Ant.

[EarthCitizen]

I see tons of verbose information in the build.xml file constantly telling Ant the location of files to use for building, packaging, testing ....In Maven you use a specific directory structure which makes all of that unnecessary.

Unnecessary in Maven as it has a known places where it compiles to:

<target name="clean" description="Clean up all built files">
        <delete dir="build"/>
</target>

Maven will know what you are building and where the classes and test classes are and it knows already that it needs compile and test the code before packaging:

<target name="api" description="Build Hamcrest APIs">
        <path id="cp-hamcrest-api-main" path=""/>
        <path id="cp-hamcrest-api-test" path=""/>
        <compile-module modulename="hamcrest-api"/>
        <jar-module modulename="hamcrest-api"/>
        <test-module modulename="hamcrest-api"/>
</target>

Again, Maven knows where your test classes are and how to run the unit tests:

<macrodef name="test-module" description="run unit tests.">
        <attribute name="modulename" description="Name of the module to test"/>
        <sequential>
            <mkdir dir="build/temp/@{modulename}/test-wrk"/>
            <junit printsummary="no" forkmode="once" tempdir="build/temp/@{modulename}/test-wrk" haltonfailure="${haltonfailure}" dir="@{modulename}">
                <formatter type="brief" usefile="no"/>
                <classpath refid="cp-@{modulename}-test-complete"/>
                <classpath path="build/@{modulename}-${version}-tests.jar"/>
                <batchtest fork="yes" todir="${build.dir}/testreport">
                    <zipfileset src="build/@{modulename}-${version}-tests.jar">
                        <include name="org/hamcrest/**/*Test.class"/>
                        <exclude name="**/Abstract*.class"/>
                    </zipfileset>
                </batchtest>
            </junit>
        </sequential>
    </macrodef>

I didn't tear apart the entire build file, these are just a couple of random examples.

[EarthCitizen]

In Maven when you follow this directory structure:

project-name/
    src/
        main/
            java/
                package-name/File.java
        test/
            java/
                package-name/FileTest.java
    pom.xml

Then Maven can already build, clean and package without telling it how to do that or where anything is.

[npryce]

What problem do you want solved? Can you rewrite this issue without mentioning any technology?

[npryce]

If the verbosity of the build script is what you want improved, then that's an argument for Gnu Make, not Maven. I'm happy with that, but it does mean limiting the build to Unix only. However, does anyone use Windows for Java development any more?

[EarthCitizen]

I think the reason why this issue is raised in the first place is because the project structure follows an old style of "anything goes". That is not a dismissal of the effort that has been put into this project. Everyone used Ant at one time and projects were structured in any way that was deemed fit because there did not used to be such a "standardized" project structure that the community generally followed. And this very issue of non-standard project structures and every project having it's own way to build was exactly what gave rise to Maven.

Again, my intention is not to criticize or dismiss the effort put in so far. I am just making the point that there is a generally accepted structure for Java projects and tools that make the build easier by taking advantage of that common structure.

I would prefer you to stay with Ant rather than switch to Gnu Make :-)

[npryce]

The trouble is that Maven standardises very poor practices for organising Java projects. E.g. separating resources and source code into separate trees, build "phases" instead of dependency graphs, lots of implicit connaissance in the build script (which is also a problem with Ant and to a lesser extent Gradle, to be fair). Modern build tools work well with any project structure the team find helpful, manage dependencies for you and help you avoid duplication caused by connaissance. And so do older build tools, come to that!

I'm still not sure what problem you have encountered, other than "projects that are different are organised differently"

[EarthCitizen]

Some benefits of having a separate resources directory:

• If one is not familiar with the project, that person will immediately know that there are indeed resources and know exactly where to find them
• A project could have both Java and Groovy source files for example that both use the same resources

Anyway ...I think this issue is closeable ...switching the build tool is a massive undertaking (even if there were an agreement) and the priority is on a new release and pull requests which no one as time to do as it is.

[Tibor17]

Sorry guys I had no notion that my post would open such hot discussion.
I am a developer in JUnit and I would say that I have started Maven build there.
Currently I am a Maven committer at ASF (extended parallel test executions).
The Maven build activity started with introducing OSGi in JUnit.
I can tell you that these activities were strategic because we got a higher popularity through introducing the Maven build. The OSGi activity was about the same.
The result is that we've got awards at ATI Automation Honors this year. From my PoV all the effort was positive.
After some time the JUnit established CI at CloudBees, a new web page (Maven site), static code analysis plugins and real deployment to the Maven Central.

[npryce]

I want to modernise the build after we've got the project back on track. But I'd want to start with a modern build tool that addresses Maven and Ant's failings. Gradle is my current best guess.

[sf105]

It's slower to run but there's good support in tools like Idea.

S

On 21 Nov 2014, at 00:04, Nat Pryce [email protected] wrote:

I want to modernise the build after we've got the project back on track. But I'd want to start with a modern build tool that addresses Maven and Ant's failings. Gradle is my current best guess.

—
Reply to this email directly or view it on GitHub.

[Derbeth]

Gradle slower than Maven? You must be joking. It's hard to match the sluggishness of Maven. If you use Gradle with "deamon" option, it's blazing fast. Plus, it's horrible how stupid Maven is - it's safer to run "clean" before every task to make sure you don't get old rubbish. With Gradle, cleaning needs to be done on really special circumstances. I also think that Gradle is a very good choice if you want to migrate from Ant gradually, because it's able to import (load) Ant build scripts on the fly.

[EarthCitizen]

So it sounds like there is agreement after all :-)

I am betting on Gradle and not Maven for the future.

[sf105]

Slower than ant and make. Especially for small builds. But perhaps I'm out of date.

S

Steve Freeman
http://www.higherorderlogic.com

Written on a phone, so please allow for typos and short content.

On 21 Nov 2014, at 07:10, Piotr Kubowicz [email protected] wrote:

Gradle slower than Maven? You must be joking. It's hard to match the sluggishness of Maven. If you use Gradle with "deamon" option, it's blazing fast. Plus, it's horrible how stupid Maven is - it's safer to run "clean" before every task to make sure you don't get old garbage. With Gradle, cleaning needs to be done on really special circumstances. I also think that Gradle is a very good choice if you want to migrate from Ant gradually, because it's able to import (load) Ant build scripts on the fly.

—
Reply to this email directly or view it on GitHub.

[Tibor17]

I think we don't need too much complicated features in the build process. The Maven community is quite large and therefore I would switch to Maven.

[npryce]

The build process is complicated. It has a compilation step that feeds into a codegen step that feeds into a compilation step that both feed into a JAR-ing step, packaging the same code into different JARs. Maven is not a good fit for builds that don't fit its simplistic model.

Maven has long been obsoleted by better, more flexible tools. We should use one of those.

[Tibor17]

@npryce
I remember the JavaHamcrest build process several years and I know that we are aggregating matchers in utility class. The jar file used in ANT can be utilized in whatsoever way, maven-ant-plugin, exec plugin, BeanShell scripting plugin, ...
The most important is the fact that the professionals in Maven group are quite many people and they are able to help you to make release and CI config on regular basis. The same with generating Maven site which is not trivial as it first seems in the documentation.

[josephw]

If you're interested in what a Maven build could look like, josephw/JavaHamcrest build-with-maven is a working version (diff). The build process needed a couple of changes to sort out some otherwise-cyclic dependencies, and the necessary changes were merged in #66.

I wouldn't make the case that it's the best build tool but, with the existing poms and current conventions, it's got wide support and would be very easy to adopt.

[josephw]

What problem do you want solved? Can you rewrite this issue without mentioning any technology?

It would be nice to have:

• A repository with no binary artifacts
• A project that can be opened in all major IDEs
• The ability to build, test (and deploy) the project using a widely-installed command
• A build that generates POMs specifying the actual dependencies it was built with

[EarthCitizen]

Nice work @josephw !!

[npryce]

Steve has rewritten the build in Gradle. See the v7.0 branch.