If you want a real life example which is very close to what I'm talking about, you could take a look at [1], which is part of the Launchpad Maven Plugin of the Apache Sling project.
[1]: https://github.com/apache/sling/blob/trunk/tooling/maven/maven-launchpad-plugin/src/main/java/org/apache/sling/maven/projectsupport/LaunchpadPluginLifecycleParticipant.java 2013/7/30 Francesco Mari <[email protected]>: > 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]
