You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by jv...@apache.org on 2003/03/16 19:02:39 UTC
cvs commit: jakarta-turbine-maven/xdocs roadmap.xml
jvanzyl 2003/03/16 10:02:39
Added: xdocs roadmap.xml
Log:
o Start of the road map document. I will expand as I'm going over the
new branch and try to get this puppy in today.
Revision Changes Path
1.1 jakarta-turbine-maven/xdocs/roadmap.xml
Index: roadmap.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Maven Road Map</title>
<author email="jason@zenplex.com">Jason van Zyl</author>
</properties>
<body>
<section name="Road Map">
<p>
Many people often ask "Where is Maven going?" and this documents tries
to answer that question. This document will be of interest to anyone who
uses Maven but is primarily directed at those developers who want to
get more involved in Maven's development. There is a branch that has
been checked in and for the sake of brevity will be referred to from
here on as the Road Map Branch or RMB.
</p>
<subsection name="Creating a coherent model for Maven">
<p>
The MavenSession class has moved back to the name Maven. I have
tried to move any and all code that would be of use when running Maven
in any environment from the App class into the Maven class. The App
class is now a very thin class whose only real purpose is to allow access
to the Maven model via the command line.
</p>
<p>
In the RMB I've tried to move all the brains into the Maven class
which lead us into the next subsection.
</p>
</subsection>
<subsection name="Maven as an Avalon application">
<p>
The main idea behind trying to isolate the Model of Maven into the
single class is part of an attempt to make Maven an Avalon component.
Eventually I would like all the distinct portions of Maven to be
Avalon components that can be run under Plexus. Turning the code
in the RMB into Avalon components will definitely allow developers
to easily experiment with new implementations safely.
</p>
</subsection>
<subsection name="Separate dependency resolution code">
<p>
It's seems that Maven has spawned a raft of efforts to produce small
libraries to deal with the downloading of dependencies. I feel that
Maven still leads the way in this effort by dealing not only with JAR
dependencies but any project artifact that can be a dependency. This
code should be separately into a simple set of beans. From there we
can wrap it in component logic for use inside Maven and others can
use the code as they wish. One of our mandates now is to encourage
other projects to be involved in Maven and this is probably the
biggest way we can encourage collaboration. Much work has gone into
our dependency resolution package. That coupled with the work in Werkz
and the commons-graph pacakge I think we can make a tool that will
satisfy any common requirements.
</p>
</subsection>
<subsection name="Removing Ant as a core dependency">
<p>
I would like to remove Ant as a core dependency as it's become more
a pain in the ass than anything. The coupling of Tasks to the
AntClassLoader and Project have become a real nuisance. Having Tasks
loaded into separate ClassLoaders just doesn't seem to work and Ant
was not designed for long-lived processes.
</p>
<p>
The plugins can definitely specify Ant as a dependency and remove the
implicit use of Ant. But there are many maven.xml files that use
Ant semantics and we can't cut off people at the knees. We need
separate mechanisms for dealing with Plugins and arbitrary Jelly
scripts. Currently they are dealt with in the same fashion which
is a problem.
</p>
</subsection>
<subsection name="Pure Java API">
<p>
I would like to create a pure Java API for plugins. I have nothing
against Jelly but I am not entirely sure I want it as the primary path of
extension. I don't want to change anything about the way Jelly
plugins work. They should just continue to work they always have but
I would like to add a pure Java API so I can write plugins purely in
Java with no Jelly interaction. So people could easily created their
own plugin mechanisms for their own scripting languages or BSF for
example. I'm not overly fond of BSF but I think something like BSF
would make for a better plugin mechanism than Jelly.
</p>
</subsection>
</section>
</body>
</document>