Correct. I don't want to duplicate the configuration twice, the first time in my plugin and the second time in the <dependencies> section to let Maven correctly compute the build plan.
2013/7/30 Stephen Connolly <stephen.alan.conno...@gmail.com>: > On 30 July 2013 14:23, Francesco Mari <mari.france...@gmail.com> wrote: > >> 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? >> >> > So really this is a question of build-time information. The "exported" > transitive dependencies will fit neatly into the existing scopes, but you > would like a simplified *build time* configuration? > > >> 2013/7/30 Stephen Connolly <stephen.alan.conno...@gmail.com>: >> > 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 <mari.france...@gmail.com> 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: dev-unsubscr...@maven.apache.org >> >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
