Re: svn commit: r1127331 - in /maven/wagon/trunk: ./ wagon-provider-api/ wagon-provider-test/ wagon-providers/wagon-ftp/ wagon-providers/wagon-ssh-common-test/ wagon-providers/wagon-ssh/ wagon-tcks/wa

On 25/05/2011, at 9:19 AM, strub...@apache.org wrote: > > Modified: maven/wagon/trunk/wagon-providers/wagon-ftp/pom.xml > URL: > http://svn.apache.org/viewvc/maven/wagon/trunk/wagon-providers/wagon-ftp/pom.xml?rev=1127331&r1=1127330&r2=1127331&view=diff > ===

notification emails from jenkins

I just noticed that few, if any, jobs set up at https://builds.apache.org/hudson/view/M-R/view/Maven/ are sending notification emails. Shouldn't that go to notifications@m.a.o? Are people reading this list (actually I don't)? -Lukas -

maven-changes-plugin patch buddy sought

Tonight I submitted a little raft of jiras with patches for the maven-changes-plugin. I have some hope that they will prove digestible. I would be very grateful if someone could take them on. If we can make the committable, I would be really really grateful for a release. --benson --

Re: PMC please ACK the mailing list change in INFRA

Done On Wed, May 25, 2011 at 1:07 AM, Mark Struberg wrote: > Hi PMC! > > As discussed on the list I've created a Jira requesting to collapse all our > commit mailing lists to comm...@maven.apache.org > > Could any1 of the Maven PMC members please formally ACK this over in > > https://issues.apac

PMC please ACK the mailing list change in INFRA

Hi PMC! As discussed on the list I've created a Jira requesting to collapse all our commit mailing lists to comm...@maven.apache.org Could any1 of the Maven PMC members please formally ACK this over in https://issues.apache.org/jira/browse/INFRA-3653 txs and LieGrue, strub ---

Re: svn commit: r1127124 - in /maven/wagon/trunk: ./ wagon-provider-test/ wagon-provider-test/src/main/java/org/apache/maven/wagon/ wagon-providers/wagon-ftp/ wagon-providers/wagon-ftp/src/test/java/o

On 2011-05-24 18:11, strub...@apache.org wrote: > Author: struberg > Date: Tue May 24 16:11:30 2011 > New Revision: 1127124 > > URL: http://svn.apache.org/viewvc?rev=1127124&view=rev > Log: > WAGON-331 upgrade to java5, junit-4.8.2 and MINA ftpserver > > This code needs review, please! 2 wagon-ft

Re: drop wagon-users list?

On 2011-05-24 21:34, Daniel Kulp wrote: > On Tuesday, May 24, 2011 3:24:34 PM Mark Struberg wrote: >> Done. >> >> https://issues.apache.org/jira/browse/INFRA-3653 >> >> Are there any other subprojects which we like to fold? >> (Lukas mentioned Doxia, right?) > > We currently have: > > [/maven] >

Re: drop wagon-users list?

On Tuesday, May 24, 2011 3:24:34 PM Mark Struberg wrote: > Done. > > https://issues.apache.org/jira/browse/INFRA-3653 > > Are there any other subprojects which we like to fold? > (Lukas mentioned Doxia, right?) We currently have: [/maven] for_paths = maven/ to_addr = comm...@maven.apache.org su

Re: drop wagon-users list?

Done. https://issues.apache.org/jira/browse/INFRA-3653 Are there any other subprojects which we like to fold? (Lukas mentioned Doxia, right?) LieGrue, strub --- On Tue, 5/24/11, Arnaud Héritier wrote: > From: Arnaud Héritier > Subject: Re: drop wagon-users list? > To: "Maven Developers List

Re: drop wagon-users list?

We need to ask to infra. Just create a task in INFRA Jira project. Le 24 mai 2011 à 21:09, Mark Struberg a écrit : > who/how is going to do this? Is this a post-commit hook in SVN we need to > change? > > LieGrue, > strub > > --- On Tue, 5/24/11, Arnaud Héritier wrote: > >> From: Arnaud Hé

Re: drop wagon-users list?

who/how is going to do this? Is this a post-commit hook in SVN we need to change? LieGrue, strub --- On Tue, 5/24/11, Arnaud Héritier wrote: > From: Arnaud Héritier > Subject: Re: drop wagon-users list? > To: "Maven Developers List" > Cc: "Maven Developers List" > Date: Tuesday, May 24, 201

Re: drop wagon-users list?

+1 to merge everything into maven mls Arnaud Le 24 mai 2011 à 20:53, Mark Struberg a écrit : > already changed the wagon pom deprecating the old lists (textual) and adding > the official maven-dev and maven-users lists. > > Btw, what about the commit messages? Should we keep them at wagon-com

Re: drop wagon-users list?

already changed the wagon pom deprecating the old lists (textual) and adding the official maven-dev and maven-users lists. Btw, what about the commit messages? Should we keep them at wagon-commits? http://markmail.org/search/?q=list%3Aorg.apache.maven.wagon-commits or better move them to maven-c

Re: drop wagon-users list?

+1 -- Olivier Le 24 mai 2011 13:36, "Mark Struberg" a écrit : > Hi! > > I was curious if someone still uses the wagon-usrs list. > It is currently configured in wagons parent pom but I'd suggest to move this to maven-users and maybe even consolidate the wagon-dev list which is barely used too...

Re: drop wagon-users list?

On 2011-05-24 13:36, Mark Struberg wrote: > Hi! > > I was curious if someone still uses the wagon-usrs list. > It is currently configured in wagons parent pom but I'd suggest to move this > to maven-users and maybe even consolidate the wagon-dev list which is barely > used too... > The traffic i

Re: Anyone want to help?

they are fine. if they pass for plexus, then they are in the tck - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 24 May 2011 18:53, "Brian Demers" wrote: > Not exactly clea

Re: Anyone want to help?

Not exactly clean room, but I have a feeling a lot of test cases could be copied from the given commons-* projects such as: http://svn.apache.org/viewvc/commons/proper/io/trunk/src/test/java/org/apache/commons/io/FileUtilsTestCase.java?view=markup This should work for methods with the same signatu

Re: Anyone want to help?

> Hey if we could just copy the plexus source code in tree we wouldn't > be doing this would we? If you have the provenance of the code and it > is ASL license friendly, then fine copy & paste. > That'd really be depending on the overall usage of a shim layer, wouldn't it ? I think a shim makes

Re: POM 4+ was Re: Moving forward with mixins

On Tue, May 24, 2011 at 11:17 AM, Stephen Connolly wrote: > deploy new poms as poms with classifier > > new maven tries to download pom with classifier... fails and falls > back to pom without > > old maven only ever sees pom without classifier > I don't think classifier is the right use for this

Re: POM 4+ was Re: Moving forward with mixins

We get it right this time w.r.t. extensions so that we don't have to do this again! ;-) 2011/5/24 Arnaud Héritier : > ok, but we'll deploy a new pom with a different classifier for each new > version ? > Whe we'll have 3 possible versions, how will we do ? > If I 'm building a new project with a m

Re: Moving forward with mixins

Hi Brett, thanks for your positive feedback! My answers interleaved > This is a good proof-of-concept, perhaps worth trying on some projects to > see how it goes without needing to use a new Maven version. > I've tried already with the wicket-quickstart (one of the easiest archetypes to tes

Re: POM 4+ was Re: Moving forward with mixins

On 24 May 2011 16:30, nicolas de loof wrote: > +1, simple and efficient Well we still have to cache the fact that there is no pom with classifier for any of the "old" artifacts... But at MRM should be able to handle that / generate a map from the "old" to the 5.0.0 model > > 2011/5/24 Stephen C

Re: POM 4+ was Re: Moving forward with mixins

ok, but we'll deploy a new pom with a different classifier for each new version ? Whe we'll have 3 possible versions, how will we do ? If I 'm building a new project with a maven compatible with POM 4.2.0 can I extend a pom 4.0.0 or 4.1.0 ? Said differently imagine we have a really new cool feature

Re: POM 4+ was Re: Moving forward with mixins

On 24 May 2011 16:19, John Casey wrote: > +1 > > Also, generated 4.0.0 POMs should only contain deps and things to support > deps, not build section etc. > > In other words, it's not to be used as a parent...if you can't use the newer > POM syntax, don't use this artifact as a parent. +1 > > On

Re: POM 4+ was Re: Moving forward with mixins

+1, simple and efficient 2011/5/24 Stephen Connolly > deploy new poms as poms with classifier > > new maven tries to download pom with classifier... fails and falls > back to pom without > > old maven only ever sees pom without classifier > > 2011/5/24 Arnaud Héritier : > > It doesn't seem so ea

Re: POM 4+ was Re: Moving forward with mixins

+1 Also, generated 4.0.0 POMs should only contain deps and things to support deps, not build section etc. In other words, it's not to be used as a parent...if you can't use the newer POM syntax, don't use this artifact as a parent. On 5/24/11 11:17 AM, Stephen Connolly wrote: deploy new po

Re: POM 4+ was Re: Moving forward with mixins

deploy new poms as poms with classifier new maven tries to download pom with classifier... fails and falls back to pom without old maven only ever sees pom without classifier 2011/5/24 Arnaud Héritier : > It doesn't seem so easy for me. > If we deploy 4.0.0 only we'll never be able to reuse new

Re: Moving forward with mixins

The main issue with mixins is to define in which part of the resolution mechanism we need to apply it and all the rules to override or add entries in the POM We need to provide flexibility but in an understandable way. nowadays it is already difficult sometime to know why when the POM is resolved w

Re: svn commit: r1127056 - in /maven/sandbox/trunk/plexus-utils-commons-bridge: ./ plexus-utils-commons-bridge/ plexus-utils-commons-bridge/src/main/java/org/codehaus/plexus/util/ plexus-utils-tck/src

assertThat(new Base64().encode("test".getBytes()), is("dGVzdA==")); will cover most of your needs... it comes into it's own with arrays and collections On 24 May 2011 16:12, nicolas de loof wrote: >> +        assertEquals("dGVzdA==", new Base64().encode("test".getBytes())); >> >> assertThat wit

Re: Anyone want to help?

On 24 May 2011 16:05, Kristian Rosenvold wrote: > ti., 24.05.2011 kl. 12.23 +0100, skrev Stephen Connolly: >> The general consensus is that Martin is a bot. >> >> The idea is that we write tests that cover all the functionality of >> plexus-utils (preference is to write tests without looking at th

Re: svn commit: r1127056 - in /maven/sandbox/trunk/plexus-utils-commons-bridge: ./ plexus-utils-commons-bridge/ plexus-utils-commons-bridge/src/main/java/org/codehaus/plexus/util/ plexus-utils-tck/src

> +assertEquals("dGVzdA==", new Base64().encode("test".getBytes())); > > assertThat with the matchers is far nicer, but if you like keeping it > old-style I'm fine with that! > > I'm not used with matchers (maybe I should be deprecated and replaced by some nicolas-update-bridge), can you pl

Re: POM 4+ was Re: Moving forward with mixins

It doesn't seem so easy for me. If we deploy 4.0.0 only we'll never be able to reuse new POMs in the build process by inheritance for example. Thus always deploying .pom artifacts as 4.0.0 keeps the compatibility but won't allow us to evolve. The problem is how to depend and how to extend (without

Re: Anyone want to help?

ti., 24.05.2011 kl. 12.23 +0100, skrev Stephen Connolly: > The general consensus is that Martin is a bot. > > The idea is that we write tests that cover all the functionality of > plexus-utils (preference is to write tests without looking at the > plexus-utils code so that the tests are somewhat c

Re: POM 4+ was Re: Moving forward with mixins

> > I think doing some sort of on-the-fly translation into a 4.0.0 POM purely > to be deployed for backwards compat would be enough here...though we may > want to explore how we could make Maven smart enough to say, "I can't read > this POM, use a later version" or somesuch... > > Why only consider

Re: wagon-2.0 ?

You actually did an amazing work on surefire. So this would be on the list for another 'action week'. Quickly followed by a few weeks where we all concentrate to support Olivier for improving the new site plugin. This is also really crucial and would deserve a bit more love from us... LieGrue,

Re: wagon-2.0 ?

ti., 24.05.2011 kl. 15.12 +0100, skrev Mark Struberg: > I'd prefer to fix a few tons of old known issues first. But maybe some can go > hand in hand with implementing new cool functionality? > My first prio would of course be to get this up2date and making it > maintainable again. +1000 to this

Re: svn commit: r1127056 - in /maven/sandbox/trunk/plexus-utils-commons-bridge: ./ plexus-utils-commons-bridge/ plexus-utils-commons-bridge/src/main/java/org/codehaus/plexus/util/ plexus-utils-tck/src

On 24 May 2011 14:57, wrote: > Author: nicolas > Date: Tue May 24 13:57:35 2011 > New Revision: 1127056 > > URL: http://svn.apache.org/viewvc?rev=1127056&view=rev > Log: > TCK for Base64 > > Added: >     > maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-commons-bridge/src/main/java/o

Re: wagon-2.0 ?

On 5/24/11 10:12 AM, Mark Struberg wrote: I'd prefer to fix a few tons of old known issues first. But maybe some can go hand in hand with implementing new cool functionality? My first prio would of course be to get this up2date and making it maintainable again. Agreed. Just thinking out lou

Re: Moving forward with mixins

On 05/24/2011 01:30 AM, Brett Porter wrote: Some notes on how I think it should work: - templates should look like a normal POM (perhaps only differing in root element, and less strict validation requirements) [...] - any POM element is valid, other than , - templates need to be sourced fro

Re: wagon-2.0 ?

I'd prefer to fix a few tons of old known issues first. But maybe some can go hand in hand with implementing new cool functionality? My first prio would of course be to get this up2date and making it maintainable again. Thirst thing I like to do is to upgrade to junit-4.8.2 and activate your TC

Re: POM 4+ was Re: Moving forward with mixins

On 5/24/11 8:25 AM, Brian Fox wrote: 2011/5/24 Arnaud Héritier: Before talking about a specific change in the model like the addition of mixins (which may be cool but not critical) did we : - studied that we had everything necessary to manage new versions of POMs with something a little bit dy

Re: wagon-2.0 ?

+1 It would be great to breathe some new life into that project. Thanks for picking it up! As long as we're talking about possible improvements, I think it'd be worth keeping in mind support for different ways of downloading sets of files...things like "bulk" or concurrent downloads, to name

Re: Moving forward with mixins

Brett / Mark, This all sounds great! I'm already dreaming of ways I could use this functionality right now in my own builds... Personally, I'm much more in favor of having separate template files in the repository, since it helps keep the POMs associated with them lean, and since it'll make

Re: wagon-2.0 ?

+1 Emmanuel On Tue, May 24, 2011 at 10:39 AM, Mark Struberg wrote: > Hi folks! > > As expressed in http://jira.codehaus.org/browse/WAGON-329 > > What do you think of creating a maintenance branch for the current wagon > trunk (for (theoretically) being able to ship hot-fixes for mvn-2.0.x) and

Re: wagon-2.0 ?

I don't remember the issue number but for me the main issue with the default http wagon is that it isn't able to deploy large artifacts and for that we have to use the webdav wagon which isn't any more by default in the core and which creates some others side effects for exemple if you want to do a

Re: wagon-2.0 ?

actually I was trying to apply/merging in the patch from WAGON-314 yesterday. But then all the stuff fall appart on the first touch! So I ended up spending the whole afternoon (until 3 in the morning) to drop old stuff, upgrade test containers, etc only to get the tests running again. While doi

Re: POM 4+ was Re: Moving forward with mixins

On Tue, May 24, 2011 at 3:05 PM, Brett Porter wrote: > > On 24/05/2011, at 10:12 PM, Arnaud Héritier wrote: > > > Before talking about a specific change in the model like the addition of > > mixins (which may be cool but not critical) did we : > > - studied that we had everything necessary to man

Re: wagon-2.0 ?

On 05/24/2011 06:01 AM, Olivier Lamy wrote: Something else I think in a 2.0 version is : upgrading to Apache HttpClient 4.x is critical for the lightweight wagon, by the way. And if you are trying to drop dependencies, see my comment in

Re: POM 4+ was Re: Moving forward with mixins

On 24/05/2011, at 10:12 PM, Arnaud Héritier wrote: > Before talking about a specific change in the model like the addition of > mixins (which may be cool but not critical) did we : > - studied that we had everything necessary to manage new versions of POMs > with something a little bit dynamic in

Re: Anyone want to help?

Oups, moved to https://cwiki.apache.org/confluence/display/MAVEN/Plexus-utils+replacement 2011/5/24 Olivier Lamy > 2011/5/24 nicolas de loof : > >> > >> +1 and Nike it: Just do it(tm) > >> > > > > http://docs.codehaus.org/display/MAVENUSER/Plexus-utils+replacement > > > > Thanks. > But personna

Re: Moving forward with mixins

On 24/05/2011, at 7:22 PM, Maurizio Pillitu wrote: > Hi Mark, > > really interesting discussion indeed. > > I like very much your idea of including mixins within POM files; this > weekend I did some code (which is actually very very similar to your > description) and I ended up with something

Re: Anyone want to help?

2011/5/24 nicolas de loof : >> >> +1 and Nike it: Just do it(tm) >> > > http://docs.codehaus.org/display/MAVENUSER/Plexus-utils+replacement > Thanks. But personnally I would prefer we use Apache confluence : https://cwiki.apache.org/confluence/display/MAVEN . -- Olivier Lamy http://twitter.com/

Re: Anyone want to help?

> > +1 and Nike it: Just do it(tm) > http://docs.codehaus.org/display/MAVENUSER/Plexus-utils+replacement

Re: POM 4+ was Re: Moving forward with mixins

2011/5/24 Arnaud Héritier : > Before talking about a specific change in the model like the addition of > mixins (which may be cool but not critical) did we : > - studied that we had everything necessary to manage new versions of POMs > with something a little bit dynamic inside the core and all tha

POM 4+ was Re: Moving forward with mixins

Before talking about a specific change in the model like the addition of mixins (which may be cool but not critical) did we : - studied that we had everything necessary to manage new versions of POMs with something a little bit dynamic inside the core and all that is necessary on repositories side

Re: Moving forward with mixins

On 24/05/2011, at 7:09 PM, Mark Derricutt wrote: > Great to see this being discussed. > > > Initial thoughts that come to mind reading that you've got here ( which for > the most part all looks good ). Cool! > > You mentioned the possibility of having the templates inline, rather than > I w

Re: drop wagon-users list?

I just wanted to propose it for doxia as well. -Lukas Brett Porter wrote: I think we could do that for all the subprojects, given the low amount of traffic they get. On 24/05/2011, at 9:36 PM, Mark Struberg wrote: Hi! I was curious if someone still uses the wagon-usrs list. It is currentl

Re: drop wagon-users list?

I think we could do that for all the subprojects, given the low amount of traffic they get. On 24/05/2011, at 9:36 PM, Mark Struberg wrote: > Hi! > > I was curious if someone still uses the wagon-usrs list. > It is currently configured in wagons parent pom but I'd suggest to move this > to mav

drop wagon-users list?

Hi! I was curious if someone still uses the wagon-usrs list. It is currently configured in wagons parent pom but I'd suggest to move this to maven-users and maybe even consolidate the wagon-dev list which is barely used too... The traffic is almost zero.. I'd suggest to change the lists in JIRA

Re: Anyone want to help?

The general consensus is that Martin is a bot. The idea is that we write tests that cover all the functionality of plexus-utils (preference is to write tests without looking at the plexus-utils code so that the tests are somewhat clean-room, but there is no hard requirement in this case... the des

RE: Anyone want to help?

Hi Martin! The idea is about doing a misture between Test Driven Development and BlackBox Testing / Unit Testing. LieGrue, strub --- On Tue, 5/24/11, Martin Gainty wrote: > From: Martin Gainty > Subject: RE: Anyone want to help? > To: dev@maven.apache.org > Date: Tuesday, May 24, 2011, 10:29

Re: Anyone want to help?

On 24 May 2011 11:45, nicolas de loof wrote: > I'd be pleased to join, > (let's drop this dinosaur) > > Should we setup a wiki page to know who is working on wich part, let > contributors pick-up tasks, and trace progess ? +1 and Nike it: Just do it(tm) > Should we clone the svn repo to github /

Re: Anyone want to help?

I'd be pleased to join, (let's drop this dinosaur) Should we setup a wiki page to know who is working on wich part, let contributors pick-up tasks, and trace progess ? Should we clone the svn repo to github / apache extras so that non-apache contributors can help (I'm an optimistic naive guy :P)

RE: Anyone want to help?

isnt the job of the software engineer to write test-cases to prove their software works? Martin __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenge

Re: wagon-2.0 ?

sure, can you please file a wagon issue? We could also do some some taskforce hacking on. E.g. calling June 2011 as 'month of wagon' where we try to put a bit more focus on cleaning up single parts. This should of course be ending with a new wagon release at the end of the month. Or establish

Re: wagon-2.0 ?

Something else I think in a 2.0 version is : upgrading to Apache HttpClient 4.x (http://hc.apache.org/httpcomponents-client-ga/index.html) /Olivier 2011/5/24 Olivier Lamy : > 2011/5/24 Mark Struberg : >> Hi folks! >> >> As expressed in http://jira.codehaus.org/browse/WAGON-329 >> >> What do you

Re: wagon-2.0 ?

+1 !!! Den 24. mai 2011 kl. 11:37 skrev Brett Porter : > +1 > > IMO, have at it :) I'm happy to review after commit. > > On 24/05/2011, at 6:39 PM, Mark Struberg wrote: > >> Hi folks! >> >> As expressed in http://jira.codehaus.org/browse/WAGON-329 >> >> What do you think of creating a maintenance

Re: wagon-2.0 ?

+1 IMO, have at it :) I'm happy to review after commit. On 24/05/2011, at 6:39 PM, Mark Struberg wrote: > Hi folks! > > As expressed in http://jira.codehaus.org/browse/WAGON-329 > > What do you think of creating a maintenance branch for the current wagon > trunk (for (theoretically) being abl

Re: Anyone want to help?

I've also set up a Jenkins job to track this: https://builds.apache.org/hudson/view/M-R/view/Maven/job/maven-sandbox-plexus-utils-commons-bridge/ On 24 May 2011 10:28, Stephen Connolly wrote: > I'm working on providing a compatibility layer for plexus-utils that > uses the commons-* stuff to pro

Anyone want to help?

I'm working on providing a compatibility layer for plexus-utils that uses the commons-* stuff to provide the implementation. If anyone is interested in helping please shout out. Most of the work is actually writing the crazy test cases, everything else should be simple shims through to existing c

Re: Moving forward with mixins

Hi Mark, really interesting discussion indeed. I like very much your idea of including mixins within POM files; this weekend I did some code (which is actually very very similar to your description) and I ended up with something working. I've contributed my code to http://jira.codehaus.org/brows

Re: wagon-2.0 ?

+1 maybe give it v 2.2 so that it is clear that it is aligning with maven 2.2's jdk 1.5 req On 24 May 2011 09:39, Mark Struberg wrote: > Hi folks! > > As expressed in http://jira.codehaus.org/browse/WAGON-329 > > What do you think of creating a maintenance branch for the current wagon > trunk (

Re: wagon-2.0 ?

2011/5/24 Mark Struberg : > Hi folks! > > As expressed in http://jira.codehaus.org/browse/WAGON-329 > > What do you think of creating a maintenance branch for the current wagon > trunk (for (theoretically) being able to ship hot-fixes for mvn-2.0.x) and > bump wagon to 1.1 or 2.0. +1 > > This new

Re: Moving forward with mixins

Great to see this being discussed. Initial thoughts that come to mind reading that you've got here ( which for the most part all looks good ). You mentioned the possibility of having the templates inline, rather than I was wondering if using to be consistent with and . If you have multiple

wagon-2.0 ?

Hi folks! As expressed in http://jira.codehaus.org/browse/WAGON-329 What do you think of creating a maintenance branch for the current wagon trunk (for (theoretically) being able to ship hot-fixes for mvn-2.0.x) and bump wagon to 1.1 or 2.0. This new version will use java5, drop lots of 5 yea

Re: Plugin dependencies bug

I've pulled all the version ranges out of the artefacts and I still can't release the plugin. I'm just firing up maven in debug again. But yeah, being able to have maven users use the latest version of easyb would really be nice. Richard On Tue, May 24, 2011 at 7:07 PM, Mark Derricutt wrote: >

Re: Plugin dependencies bug

Has there been any movement on this at all?Beyond the few messages here and only Richards comments on the JIRA ticket it doesn't look like anyways had a chance to look further into this. >From memory there's less than a handful of folk who know how the dependency resolution works, more so now