Note on what I just said. Even though to me it would be ideal as I described it, now I'm thinking about a little bit more, I wonder if it could work every time, I remember for 'included', at time I wasn't able to use it because of some package/name collisions, the compiler was complaining and I had to change my plan, so I wonder if others types of issues could occur changing the linkage the library creator has set. Do you think it is something crazy to have a flag in FM to resolve the transitive deps "as is" or force them as declared by the end user ?
Thanks Frédéric THOMAS > From: webdoubl...@hotmail.com > To: dev@flex.apache.org > Subject: RE: AW: Flex resolution of transitive dependencies > Date: Tue, 10 Feb 2015 10:14:41 +0000 > > Hi Chris, > So, to me the optimal usage would be to translate the transitive dependencies > scopes as set in the user pom dependencies declaration, eg. If my dependency > declares my lib as RSL, I want all transitive dependencies be declared as > such, idem for included, compile, provided and test (can't remember either I > did any usage of runtime with Flex). > If I want another form of linkage for a given transitive dependency, I use > the exclude tag from the its parent (the one I declared) and declare apart > (in my pom) this transitive dependency with the linkage I want (this extra > top declaration must win in term of version, classifier and scope relative to > the transitive one). > Note: theme has not been mention and is a flexmojo linkage only and therefore > has no equivalent for the compiler but if you want fix the way the > resolution is done, I guess you should check it still work as expected in > case it has transitive dependencies too, right ? > Is it the same usage for you too ? > > Thanks, > Frédéric THOMAS > > > From: christofer.d...@c-ware.de > > To: dev@flex.apache.org > > Subject: AW: Flex resolution of transitive dependencies > > Date: Mon, 9 Feb 2015 18:23:01 +0000 > > > > Hi Guys ;-) > > > > Ok ... let me explain a little more in detail :-) > > > > In Flex we have different scopes in which we link other libraries: > > - compile (the default linking that included only the classes actually > > referenced) > > - rsl (which doesn't include a single class but references them externally) > > - included (which includes all of the classes in the other library) > > - provided (don't include anything, but expect it to be there ... usually > > this is the playerglobal and airglobal) > > - runtime (well ... haven't come across this ;-) ) > > - test (dependency only used by test-classes ... things like FlexUnit etc. ) > > > > In maven you define the dependencies for each artifact. If for example Lib > > A references Lib B and you include a compile dependency to Lib A in your > > project, you also get a transitive compile dependency to Lib B without > > explicitly asking for it. > > > > Same with a test-scoped dependency, but with the difference that Maven adds > > all compile dependencies of the referenced test-lib as test scoped > > dependencies. Immagine a mock framework referencing other libs. So if you > > add a test-dependency to this mock lib, you also add the dependencies of > > this mock lib to the test classpath. > > > > So far so good for the scopes defined in maven. Unfortunately we also have > > "include" and "rsl" (I'll ignore caching as we no longer have this). Maven > > sort of drops the ball here as the scopes are no Maven scopes. So I need to > > manually set the scopes correctly. > > > > In the matrix on the Wiki page in the left column I have the scope of the > > dependency and in the other columns I define the scope I should translate > > transitive dependencies to. So for example if I have a "rsl" dependency on > > Lib A and Lib a defines a "compile" dependency to Lib B, then this > > dependency should be added as "rsl" dependency too. If I have a "compile" > > dependency to Lib A and that has a "rsl" dependency to Lib B, then I should > > add an "rsl" dependency to Lib B and so on ... is this a little more clear > > now? > > > > I guess you have to get used to thinking maven as with Ant you usually > > throw everything into the same pot ... eclipse doesn't even distinguish > > between a compile and a test classpath :-( > > > > Chris > > > > > > > > -----Ursprüngliche Nachricht----- > > Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com] > > Gesendet: Montag, 9. Februar 2015 17:34 > > An: dev@flex.apache.org > > Betreff: RE: Flex resolution of transitive dependencies > > > > Hi Chris, > > I guess this non-terminated sentence from the wiki doesn't help to > > understand what you are asking :-)Can you elaborate ? > > "Left column of this table is the scope of the dependency, the other > > columns define the" > > > > Frédéric THOMAS > > > > > From: christofer.d...@c-ware.de > > > To: dev@flex.apache.org > > > Subject: Flex resolution of transitive dependencies > > > Date: Sun, 8 Feb 2015 12:33:18 +0000 > > > > > > Since Maven 3.1 a bug has been fixed that we were relying on for building > > > Flex applications. This caused any transitive dependencies of "rsl", > > > "cache" and "included" scoped dependencies to be omitted from the build. > > > I am currently extending FlexMojos to manually handle the flex scopes. > > > But I am not quite sure about all scenarios. I created a wiki page with a > > > table containig the scopes. The ones I'm quite sure about are bold and > > > blue, the ones I'm not sure about are orange. > > > > > > https://cwiki.apache.org/confluence/display/FLEX/Flex+Maven+Dependency+Resolution > > > > > > It would be good if you guys could waste some of your brain CPU cycles to > > > evaluate this table. I would then implement the manual resolution. > > > > > > Chris > > >
