mirror of https://github.com/apache/maven.git
o everything moved to confluence
PR: Obtained from: Submitted by: Reviewed by: git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@162905 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
Jason van Zyl
parent
981a6cbfd0
commit
fd16292852
|
|
@ -1,110 +0,0 @@
|
||||||
<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>
|
|
||||||
|
|
||||||
|
|
||||||
Loading…
Reference in New Issue