On 30 July 2013 14:23, Francesco Mari <[email protected]> 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 <[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] > >
