diff --git a/maven2-use-cases.xml b/maven2-use-cases.xml index 56a59146c9..394aca9e85 100644 --- a/maven2-use-cases.xml +++ b/maven2-use-cases.xml @@ -4,79 +4,6 @@ -
-

- 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) - * is this something that is needed at the goal level though? Maybe we need to be - able to specify goal properties such as this (BP). -

- - - -

- - 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) -

-

@@ -87,24 +14,6 @@

- -

- - 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 @@ -132,74 +41,6 @@

- -

- - 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. - - -- definitely a good idea, but I don't think we should restrict Maven as a Java build tool. I'd like to be - able to build C and .Net stuff with Maven at some point in the future, and the build process is similar enough - to be possible (BP). -

- - - -

- - 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". - 

-          
-            a
-            b
-            native
-            2.0
-          
-
- - 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 @@ -216,60 +57,6 @@

- -

- - File inclusion in POM - project inheritance allows to factorize some common pom attributes, - however there are some cases where this mechanism is not enough. For instance we might want - to share common dependencies between projects whose ancestors union is empty. Providing poms - easier to read by extracting various elements into their own xml fragments is another example. - - afaik the only way to obtain this behaviour today is to use xml entities. There are some really - bad limitations to this system : - - * cannot use interpolation b/c doctype is processed before pom is interpolated - * if using reactor, there is no uniform way to declare the entities since it - depends badly on the multiproject structure (nested vs. parallel projects) - * being able to run maven from either parent project dir or subproject - dir is not straigthforward b/c we have to think about the directory structure - which is a low-level concern - - Also i dont know what is the behaviour when running from an arbitrary folder (-d, -p options) - - adding support for file inclusion in pom would provide simplification and better consistency - among pom base. - - POM could perhaps have an - section : - - - - - path_to_xml_fragment - toBeIncluded - - - - then we could reference the fragment with something like : - - toBeIncluded - - where path_to_xml_fragment would be relative to ${basedir}. another advantage is the - possibility to perform some filtering on the included files, for instance dependending - on some (build dependent) properties. - - the drawback of this proposal is the complexity it adds to the POM structure, polluting it - with non project related elements. - - -- I think it makes more sense just to use - at the point of inclusion, and avoid the - declaration of entity-like aliases. The only extra usefulness in the declaration is that it could be stored in - a parent POM, but that goes against the original use case and isn't worth the complexity -- BrettPorter. - - - We should be able to allow a project to clearly specify which version of a plugin it uses and not get other versions - interfering. This would be done by a plugin dependency (BP). -

- -

- How do we discover the set of plugins to use? It would be good to just use a set of plugin dependencies in the @@ -279,6 +66,9 @@ - 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)

@@ -313,17 +103,6 @@

- -

- - Maven needs to support forked codebases as part of its versioning strategy. This can integrate with CVS branches and - the branches element in the model. While the actual versions should not conflict across branches, snapshots will and - determining the latest snapshot should only find it from that branch, not everything. - So if a project has - 1_0_BUGFIXES specified, snapshots would be maven-1_0_BUGFIXES-SNAPSHOT.jar, and - SCM operations should refer to that branch tag. -

- -