Last checked and updated on 30 May 2026
What Is New in Apache Maven 1
Apache Maven 1.0 was the foundational release that established the core concepts of project object model (POM) driven builds and dependency management. It introduced a declarative approach to building Java projects, moving away from the imperative scripting of Apache Ant.
| Category | Key Changes |
|---|---|
| New Features | Introduction of the Project Object Model (POM), declarative build process, and dependency management. |
| Core Architecture | Jelly-based build scripting and the concept of plugins (formerly called plugins). |
| Conventions | Established standard project directory layout and build lifecycle. |
| Repository | Centralized dependency resolution from remote repositories. |
How did Maven 1 change project building?
The core innovation was the Project Object Model (POM), an XML file (project.xml) that described the
project, its dependencies, and build steps. This was a massive shift from writing procedural Ant scripts. You
just declared your project's structure and Maven knew how to build it.
This mattered because it standardized project builds. Teams could jump into any Maven project and immediately understand its structure and dependencies without deciphering custom build logic.
What was dependency management like in Maven 1?
Maven 1 introduced automatic dependency management by downloading libraries from remote repositories. You listed your project's dependencies in the POM, and Maven would fetch them, along with their transitive dependencies, into your local cache.
In practice, this eliminated the dreaded "jar hell" of manually managing library versions and copying JAR files
into a /lib folder. It was the first time many Java developers experienced automated dependency
resolution.
How were plugins and goals used?
The build process was executed by plugins (then called plugins) that contained goals. You ran a command like
maven java:compile to execute the compile goal from the java plugin.
This plugin system was powerful but was built on Apache Jelly for XML scripting. While flexible, the Jelly-based scripting could become complex and was a primary reason for the complete rewrite in Maven 2.
What was the standard project layout?
Maven 1 enforced a conventional directory structure, which was one of its most impactful features. Source code
went in src/java, resources in src/resources, and test code in src/test.
The output was directed to a target directory.
This convention over configuration approach meant you didn't have to tell Maven where your files were. It already knew, which simplified the POM and made projects uniform.
FAQ
What is the main difference between Maven 1 and later versions?
The core POM and dependency
concepts are the same, but Maven 2 was a complete rewrite. It replaced the Jelly-based runtime with a Java-based
core, introduced the pom.xml file, and simplified the plugin architecture, making it more stable
and performant.
Can I still use Maven 1 today?
Technically yes, but it's strongly discouraged. Support ended
long ago, it lacks modern features and security updates, and most plugins and repositories are incompatible. All
projects should have migrated to Maven 3.
Why was the POM file called project.xml in Maven 1?
That was the original naming convention.
The switch to the now-standard pom.xml filename was a key change in Maven 2 to better reflect its
purpose as the Project Object Model.
What replaced Apache Jelly in Maven?
Maven 2 replaced the Jelly scripting with a more robust,
Java-based plugin API. This change drastically improved performance and reliability, as plugins were no longer
defined by XML scripts but compiled Mojo classes.
Did Maven 1 have a built-in lifecycle?
Yes, it introduced the concept of a build lifecycle,
but it was less defined than in Maven 2. The sequence of goals was more fluidly defined in the
maven.xml file, which was later replaced by the fixed lifecycle phases we know today.