I missed to describe my use case. I will try to do it as detailed as I can, but it can be quite verbose.
I have a project which is built by aggregating other artifacts with different roles: runtime OSGi bundles, plain content, testing OSGi bundles, integration testing modules. You can't build this project with executions of existing plugins (trust me, we tried), so a new plugin has been written to handle the corner cases of the packaging required by the project. The project is usually deployed as a runnable JAR file and a .properties file containing metadata which cannot be contained in a POM file. The packaging plugin contains a LifecycleParticipant as an extension, and dependencies are automatically added on the project depending on the configuration of the plugin. As you can imagine, the code of the LifecycleParticipant is messy, as it tries to scan projects, plugins and configurations to figure out what to use as dependencies of the project. This is done for two reasons. First, the project is inside an aggregator with the bundles it depends on, so it must be built after its dependencies are built. Second, we often inspect dependencies of our projects using the Maven Dependency Plugin or the Versions Maven Plugin and we would like to have tooling support. The pure and correct solution would be to duplicate the same information I have in the configuration of the plugin and to copy it in the dependencies section of the POM. This will satisfy my requirements, but will make the configuration of the build too verbose. If I had custom dependency scopes like "runtime-bundle", "testing-bundle", "content", etc. I could be able to still use the dependency mechanism of Maven, let Maven assemble the POM model as usual, parse the configuration and configure my plugin, instead of doing it in my LifecycleParticipant, which is tedious and error prone (other than duplicated logic). I could write my plugin to scan the dependencies for custom scopes, instead of relying on the configuration only. Do you have better ideas for this problem? 2013/7/30 Stephen Connolly <[email protected]>: > I find the lure of the custom scopes to be a siren's call. > > There are maybe 2-3 "missing" scopes. all other needs are better addressed > with a different project structure in my view. > > We have the separation between test and non-test... but test is an all or > nothing... need the symmetry between the non-test scopes and the test > scopes, e.g. > > compile -> test-compile > runtime -> test-runtime > > I'd also want a "none" scope so that things like the maven dependency and > assembly plugins can reference project dependencies without polluting > compile classpaths. > > of course the real issue that the above masks is that unit tests should not > be using such tricks... and integration tests should be in a separate > module, but we need the integration tests failing to block the module that > they are testing from being built. > > What is also needed is a way to signify architecturally specific artifacts, > and also a way to signify that artifact A subsumes or provides an > equivalent API to artifact B so that when A is on the classpath, B is > automatically excluded from transitive dependencies. > > But what I'd really like to understand is what you think you need these > custom scopes for... because perhaps I am being arrogant and assuming I > have thought of all the valid use cases and you can show me the error of my > thinking > > -Stephen > > > On 30 July 2013 13:22, Francesco Mari <[email protected]> wrote: > >> Hi, >> >> I was wondering why using custom dependency scopes issues a warning >> when the POM model is validated. Why Maven just don't ignore dependecy >> scopes he cannot understand? >> >> I was thinking to treat dependency scopes in a different way. The only >> logic I've found about dependency scopes is in [1] and [2] (I'm pretty >> sure there is more around), respectively how dependency scope >> inheritance is computed and whether to import POM dependencies with >> scope "import". >> >> Can this logic be encapsulated in a component which is able to track >> other optional "dependency scope" components? Each "dependency scope" >> component will define a new dependency scope and will encapsulate the >> rules about it (i.e. what happens if a dependency of the given scope >> is inherited, if it can be imported, and so on). >> >> An alternative and simpler solution could be that a "dependency scope" >> component maps a custom dependency scope to one standard scope defined >> by Maven, so to establish an "is-a" relationship between a custom >> dependency scope and a standard one. >> >> What do you think? >> >> [1]: >> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/project/artifact/MavenMetadataSource.java#L351 >> [2]: >> https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L876 >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
