- 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)
- 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:
org.tigris
style
web-component
2.0
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)
- 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)
- 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)
- 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.
- 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?
- 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.