Michal Maczka wrote: > 1. I want to support mapping between dependencies in POM and multiple > classpaths.
First of all, I think this is a great idea. I would rather called them 'dependency sets' or something because dependency != jar. > I see a need of having at least 3 classpaths: compile, test, runtime. > For the moment I am using 4th classpath: "global" which is used > in case dependency should be visible in all 3 other classpaths > and is also useful for backward compatibility. I'm biased against providing global/all/* set bacause this will make lazy people put their dependencies where they are not needed. > I think that the right way of declaring such mapping is by > introducing new tag inside <dependency>: <kind> > > And use it like follows: > > <kind>global</kind>(default value which is also used when tag was skipped) > <kind>test</kind> > <kind>runtime</kind> > <kind>compile</kind> > > There are few open points there > (e.g. can we have: <kind>tests, runtime</kind> or <kind>cactus</kind> etc.) <kind>tests</kind> <kind>runtime</kind> is probably cleaner to parse. I think that new sets with arbitrary names should be created on demand: <kind>custom-plugin</kind> should be legal, and then custom-plugin sould be able to do something like List deps = dependencyResolver.getDependencySet(PLUGIN_NAME); > 2. I want to prepare a field for <<transitive>> dependencies. I think that > is should be controllable if given dependency is transitive or not. > > So I am proposing to use: > > <transitive>true</transitive> > or > <transitive>false</transitive> (default, can be skipped) As Ben noted, we may need to have dependencies with varying 'transitive' status per kind. For example it is very common that a library is required for compiling and running your project, but at the same time only for running your project dependencies. Suppose we have: <kind>runtime.transitive</kind> <kind>compile</kind> getDependencies(String kind) could return both 'kind' and 'kind.transitive' depependencies, and getTransitiveDependencies(String kind) would return only 'kind.transitive' dependencies. I'm not sure if this scheme addresses all the needs of dependency transitioning, and if it's really simplest possible. > 3. Other proposition is to change a bit a semantic of <properties> tag > and instead of using: > > > <properties> > <war.bundle.jar>true</war.bundle.jar> > <ear.bundle.jar>true</ear.bundle.jar> > </properties> > > > To make it: > > <properties> > war.bundle.jar=true > ear.bundle.jar=true > </properties> > > > There are at least two arguments for such change: > a) It is very easy to implement (It's already done in maven-new :) ) > b) It is easier to use for end user (it's shorter) If we need to have dependencies properties at all, I would support that change. It's easier to read/write. At the same time I think that 'bundle' issue can be elegantly solved with dependency sets. You would just declare an a war dependency to be <kind>war.bundle</kind> and the war plugin would be able to pick it up. Not sure about classloader stuff. Should it be handled with dependency sets, or is that orthogonal to that? R. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
