mirror of https://github.com/apache/maven.git
147 lines
6.7 KiB
Plaintext
147 lines
6.7 KiB
Plaintext
Trying to get a large set of use cases that we can use to help drive
|
|
development in the right direction. I would like to collect some here and then
|
|
post them to the wiki as examples users can template to express what their
|
|
use cases are. So my first example is something I chatted about with Aslak
|
|
this morning. So they are brief and possibly naive but a huge collection
|
|
of these would help I think.
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
- Being able to write artifact handler that would operate to install an
|
|
xdoclet plugin correctly when an xdoclet plugin is stated as a dependency.
|
|
* Maybe this pattern could be generalized so you could register arbitrary
|
|
ArtifactInterceptors (possibly a DAG of them) that will be called to handle
|
|
events and operations on artifacts. They could even be used to actually
|
|
implement the operation (ie have a interceptor actually fetch the artifact
|
|
on request). This is basically an expansion of handler system as it stands
|
|
so you can add more context and generalize how artifact operations are
|
|
handled. (PD)
|
|
|
|
- With Maven installed it should be a simple command that allows you to
|
|
checkout the sources for a project.
|
|
* Maybe this could be generalized so that if you reference a remote
|
|
descriptor it will download the project. Something like
|
|
|
|
$ maven --project http://www.realityforge.org/daedalus-project.xml
|
|
|
|
would result in download of project either from remote location or
|
|
maybe from scm declarations in project descriptor.
|
|
|
|
As part of this remote downloading though the user may be asked for
|
|
input of particular configuration data (ie username etc). (PD)
|
|
|
|
- Unified source directory structure that is analagous to the repository
|
|
itself. This way locations of intermediary artifacts of a build would be
|
|
in a known location. This would also help with developer setup i.e. getting
|
|
new developers up and running. They could run a maven command and have all
|
|
their source trees set up in the same way as their collegues.
|
|
|
|
- I would like to be able to execute some goals (like 'clean') even when
|
|
not all dependencies are satisfied.
|
|
* hell yes!!!! Maybe dependency resolution could be a plugin that
|
|
other plugins depend upon (PD)
|
|
|
|
- Support for "specification" dependencies. I would like to be able to
|
|
say that I depend on a "specification" dependency such as
|
|
"javax.jaxp.parser" with specific version. It is possible that multiple
|
|
artifacts exist that satisfy this specification. ie Several versions
|
|
of Crimson and Xerces may implement the "specification" and I want maven
|
|
to select one and just use it. I dont care which does it but preferrably
|
|
the one with the latest version. (PD)
|
|
|
|
- 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)
|
|
|
|
- Support for transitive and group dependencies
|
|
* I would like to see this dependency information either encoded directly
|
|
into the artifacts where possible (ie META-INF/maven/dependencies.xml in
|
|
jar files) or accessible from repository at peer level for each artifact
|
|
much like signature data is accessible for each artifact. (PD)
|
|
|
|
- It should be easy to create a single report without a need to (call like it has place now)
|
|
maven:site. It will be nice if report generators can produce docs in few diffrent formats
|
|
(e.g pdf, html, rtf) and this format can be also choosen for group of reports.
|
|
|
|
- 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:
|
|
|
|
<depenedency>
|
|
<groupId>org.tigris</groupId>
|
|
<artifactId>style</artifactId>
|
|
<type>web-component</type>
|
|
<version>2.0</version>
|
|
</depenedency>
|
|
|
|
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)
|
|
|
|
- Maven is Java Build Tool. It should be well defined what does it mean to "build java project".
|
|
It means that stages of the process should be well defined.
|
|
|
|
pre-compile (this is when tools like JAXB, XDoclet)
|
|
compile (javac, aspectj)
|
|
post-compile (aspectj? )
|
|
pre-jar
|
|
...
|
|
etc
|
|
|
|
It should e.g be possible to use Castor, JAXB plugin, XDoclet plugin without writing a single line
|
|
of build script. In the ideal case it should be just enough to plug-in XDoclet into process simply
|
|
by "checking the checkbox in IDE".
|
|
This is someting what Vincent Massol started in maven-caller plugin. It will be nice to explore this idea.
|
|
|
|
- Reorganization of repository layout - are we going to map groupId : "a.b.c.d" to path "a/b/c/d"?
|
|
Are there some better alternatives?
|
|
* I am not sure that is such a good idea - how can you tell when a
|
|
directory is an artifact container (ie jar, sar, distribution etc) and when
|
|
it is a group container (ie a/b/c/d). (PD)
|
|
|
|
- (Michal) I have tried to implement "platform dependend dependecies".
|
|
|
|
<depenedency>
|
|
<groupId>a</groupId>
|
|
<artifactId>b</artifactId>
|
|
<type>native</type>
|
|
<version>2.0</version>
|
|
</depenedency>
|
|
|
|
is resolved as
|
|
|
|
a/b-2.0.dll (on windows) or a/b-2.0.so (unix)
|
|
|
|
|
|
Maybe it can/should be done differently?
|
|
What other "platform depended" artifact type do we have?
|
|
exe? shell-script?
|
|
|
|
* the problem with this approach is that most things that load native libs
|
|
expect the name of the lib to follow a very specific name which usually will
|
|
not conform to maven naming conventions (ie probably wont have -version on
|
|
end). No idea how to fix this. (PD)
|
|
|
|
- how to declare a dependency on JDK and what are possible implications of such dependency
|
|
(e.g javac/javadoc target jdk)
|
|
|
|
- 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)
|
|
|