mirror of https://github.com/apache/maven.git
111 lines
4.7 KiB
XML
111 lines
4.7 KiB
XML
<document>
|
|
<properties>
|
|
|
|
</properties>
|
|
|
|
<body>
|
|
|
|
<subsection>
|
|
<p>
|
|
- Support for retrieval of compatible versions for objects. For example I may
|
|
say that I want version 1.1 of Crimson but Maven may return 1.1.1, 1.1.4 etc
|
|
as it knows that these are compatible. This means aadding in some versioning
|
|
specification or different strategies for resolution. (PD)
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection>
|
|
<p>
|
|
- groupId
|
|
- Let's assume that there exists an artifact type "web-component"
|
|
which is a zip file containg css/js/gifs/jpegs etc
|
|
Example of such artifact is for example distribution of tigris style.
|
|
|
|
Say an user has declared the following dependency:
|
|
|
|
<pre>
|
|
<depenedency>
|
|
<groupId>org.tigris</groupId>
|
|
<artifactId>style</artifactId>
|
|
<type>web-component</type>
|
|
<version>2.0</version>
|
|
</depenedency>
|
|
</pre>
|
|
|
|
A dependency of this type should be processed only when users assembles the web application
|
|
(war:webapp goal in maven-old)
|
|
|
|
In short: user can be able to declare goal decorators and goals should be fine-grained
|
|
* This very similar to only resolving some dependencies depending on what goals
|
|
are running as specified above. (PD)
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection>
|
|
<p>
|
|
- I don't know if this will add too much complexity, but being able to generate multiple
|
|
and compound artifacts from a single project would be nice. If we want to have a
|
|
"Ant Compatibility Layer", then this would be required.
|
|
|
|
Think of a project for a web application, it will have java code as well as web resources.
|
|
The java code is collected into a JAR file, and then that is packaged with the web
|
|
resources into a WAR.
|
|
|
|
Of course, none of this is really required, as it can all be accomplished by breaking the
|
|
project out into multiple projects with a reactor, per the Maven 1 guidelines. But if this
|
|
limitation was removed, it might help Marvin adoption. (PR)
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection>
|
|
<p>
|
|
- How do we discover the set of plugins to use? It would be good to just use a set of plugin dependencies in the
|
|
default model, and override them in subprojects if you need a newer/older version. Issues with this:
|
|
- there needs to be a per-user default model and a installation wide default model that can be updated
|
|
- the model needs to be updated when a new plugin is installed
|
|
- this isn't flexible for discovering new goals that are not part of the project's build process. eg a plugin
|
|
may depend on aspectj to build correctly, but "console" won't be a dependency because it is a "user" plugin.
|
|
This is leads to plugin types, which I'll add later.
|
|
|
|
A form of cascading much the same that properties files currently
|
|
work. project, user/project, user, global (jvz)
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection>
|
|
<p>
|
|
- Installing plugins should be a clearly defined process. When a new plugin is installed, is it installed for the user
|
|
only be default and for the Maven installation optionally. This ties in to the point above about discovery.
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection>
|
|
<p>
|
|
- Dependencies could support multiple versions (1.1+, for example, would get the latest release). This
|
|
would be helpful for the plugins above. Issues with this:
|
|
- do we really search the repository for later releases, or just use what's local?
|
|
- how is a newer release signified? How is this affected by branches and snapshots?
|
|
</p>
|
|
</subsection>
|
|
|
|
<subsection>
|
|
<p>
|
|
- We need plugin categories that treat certain plugins in different ways. I can think of:
|
|
- reporting plugins
|
|
- user plugins (eg console) - not project specific
|
|
- project specific user plugins (eg cactus, idea, ...)
|
|
- build plugins (clean, jaxb, java, test)
|
|
- artifact generating plugins (jar, war, ear, plugin)
|
|
It may not be that we need to treat these in any particular way, but rather that for each category, define particular
|
|
hooks - like the reporting plugins do in maven1. One issue is that some of these categories overlap (eg cactus runs
|
|
build tests but also generates a report) - so it may be that plugins just have to provide an interface (and can have
|
|
many) rather than conform to a certain pattern.
|
|
</p>
|
|
</subsection>
|
|
|
|
</section>
|
|
</body>
|
|
</document>
|
|
|
|
|