On Friday 2 September 2016, Robert Scholte <[email protected]> wrote:
> On Wed, 31 Aug 2016 22:51:20 +0200, Stephen Connolly < > [email protected]> wrote: > > On Wednesday 31 August 2016, Robert Scholte <[email protected]> wrote: >> >> On Wed, 31 Aug 2016 19:35:02 +0200, Stephen Connolly < >>> [email protected]> wrote: >>> >>> On Wednesday 31 August 2016, Christian Schulte <[email protected]> wrote: >>> >>>> >>>> Am 08/31/16 um 18:39 schrieb Christian Schulte: >>>> >>>>> > Am 08/31/16 um 07:52 schrieb Stephen Connolly: >>>>> >> I've been thinking about what to call the "consumer Pom"... >>>>> >> >>>>> >> I think this is actually not a project object model, but the project >>>>> >> dependency trees >>>>> >> >>>>> >> It should list each side artifact and their dependency trees... >>>>> >> >>>>> >> So for example: >>>>> >> >>>>> >> * the java doc artifacts should depend on the corresponding >>>>> dependency >>>>> java >>>>> >> doc artifacts (in an ideal world) because we expect {@link} >>>>> references >>>>> >> >>>>> >> * the source artifacts do not depend on anything else (normally) but >>>>> for an >>>>> >> über jar (which yes is a bad pattern) you would actually be correct >>>>> to >>>>> >> depend on the bundled artifacts source jars... So the concept still >>>>> makes >>>>> >> sense >>>>> >> >>>>> >> * the test jar artifact would have the full test dependency tree >>>>> exposed as >>>>> >> this would allow for test reuse >>>>> > >>>>> > +1 >>>>> > >>>>> > Sounds like dependency trees by scope. The compile scope tree, the >>>>> > runtime scope tree, the test scope tree, the documentation scope >>>>> tree, >>>>> > the source code scope tree, the invented by a 3rd party scope tree, >>>>> etc. >>>>> > >>>>> >>>>> >>>>> public interface DependencyTreeProvider >>>>> { >>>>> >>>>> DependencyNode getDependencyTree( String logicalScopeName ) >>>>> throws IOException; >>>>> >>>>> } >>>>> >>>>> >>>> >>>> Not `String logicalScopeName` but `Artifact artifact` >>>> >>>> Because... Otherwise we have to pick a defined list of scope names and >>>> their meaning... Any defined list of scope names will be different... So >>>> better is to just publish the one tree per artifact >>>> >>>> Exposing the logical scope is a mistake IMHO >>>> >>>> There is one gotcha though... Sometimes you need a transitive dependency >>>> to >>>> compile but do not need it at runtime... How to handle that needs some >>>> thought... But right now it is a problem anyway, and it is probably >>>> safer >>>> to just force it onto the "effective" tree and let the consumer who >>>> *knows >>>> they don't really need it* strip it from their tree (at the final point >>>> of >>>> use... Because it would also need to be on their compile path) >>>> >>>> I think the original view we had with maven where compile scope would >>>> not >>>> be transitive is no longer compatible with JavaC and basically compile >>>> scope will always need to be transitive. >>>> >>>> So I am -1 on exposing details like "scope" to consumers >>>> >>>> We do need to expose "optional" so the consumer can resolve version >>>> conflicts with the optional dependency >>>> >>>> HTH >>>> >>>> >>>> >>>> I agree that scope is something to filter on, it should not be part of >>> the >>> resolution result. >>> The challenge I see is to select the proper artifact in case of multiple >>> scopes. >>> For example: the compiler:compile wants all dependencies with the scopes >>> 'compile', 'provided' (and 'system'). if the same GA has different >>> versions >>> per scope it must be clear which one to choose. >>> I hope we can resolve this without "nearest wins" strategy, the answer >>> should somehow be in the .pdt; >>> >> >> >> Well I am not seeing a case for *consumers* to need different trees for >> the >> same artifact. >> > > I had a discussion with Christian Schulte about this[1][2]. > Going for nearest doesn't always give a rational result. I think you > should first go for the scope, next for nearest. > Somehow such questions must be answered in the .pdt > > To me, scope is a *build time* concept... As such we should not be exposing it in the .pdt At build time we can produce each artifacts tree (which should not resolve version conflicts rather present the full tree) >From my PoV I see that what matters here is the artifact who's dependency tree the consumer wants. The consumer knows what other trees it has when it is building and what scopes each of those trees have... The consumer knows if it should resolve version conflicts or not.., the consumer knows how it should transform its scoped dependency trees for publishing its own dependency trees The .pdt cannot and should not know that IMHO I am interested in seeing concrete examples because I worry the vision I have in my head is too singular in origin and has some invalid bias or cognitive oversight. If anyone here is going to be at Jenkins World, we should meet up and discuss (I have a promo code... Not sure how much discount remains on the promo code though! if you want to go and haven't booked drop me a mail and I'll forward my code) I don't think I'll be able to make ApacheCon this year :-( I'm working on a straw man schema for the .pdt at present which may also help flesh out my version of a vision - Stephen Robert > > [1] http://maven.markmail.org/thread/qkudtbkiru4yynpl > [2] https://issues.apache.org/jira/browse/MNG-4800 > >> >> The only case I can imagine is our *old* vision for compile scope... But I >> think that need can be handled by optional in the worst case... My >> preference is to let the consumer of the dependency remove the bits they >> don't want... >> >> In essence each jar artifact's dependency tree would be that artifacts >> effective runtime tree. >> >> So for the tests-jar.., that would have a declared dependency on the >> regular .jar and provide the tree for the test-runtime scope... It may >> even >> be that there are therefore closer overrides of the main artifact's >> dependencies in the test jar's tree... That should all be fine. >> >> If you are compiling against the dependency and want to use a different >> version of the dependencies then you *as consumer* can override the tree >> by >> configuration... I think that is the best compromise. >> >> >> >> >>> Robert >>> >>> >>> The implementation of that method is broken down to just reading/parsing >>>>> an XML file that way. You can implement that easily with every >>>>> programming language of interest. There is no scope logic to implement. >>>>> That's done at build time. >>>>> >>>>> When all those different trees have been fetched, the 'only' thing left >>>>> to implement is conflict resolution / building the effective dependency >>>>> tree. Since scopes have already been resolved, that could possibly also >>>>> be broken down to just one very simple rule: nearest wins - no >>>>> exceptions. Version ranges are only there to be able to check for >>>>> conflicting ranges or hard requirements, right? >>>>> >>>>> Regards, >>>>> -- >>>>> Christian >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> <javascript:;> >>>>> For additional commands, e-mail: [email protected] >>>>> <javascript:;> >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>> 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] > > -- Sent from my phone
