Hi Greg, ok! I thought there was something more involved. About understanding better how things work in maven plugin and know the reasons I think it could be good to ask Chris Dutz about it, since he can give us the clues about all of that.
Thanks! El mié., 24 jul. 2019 a las 22:50, Greg Dove (<[email protected]>) escribió: > Hi Carlos, > > Just to clarify: I had wondered whether there were inconsistencies in the > framework so I checked more on that before adding my previous post in this > thread. > It seems that > <forceSwcExternalLibraryPath>true</forceSwcExternalLibraryPath> was > achieving a similar result to using 'provided' for the (inter)dependencies > inside each framework project, so my concerns were not valid. > > When I look inside royale-maven-plugin, I do see some minor differences > with respect to "runtime" specifically but tbh I would need to spend more > time to understand why it is doing what it does with a combination of > classifier and scope checks specifically for "runtime" and not "provided". > Other than those differences, I think "runtime" and "provided" do seem to > be treated the same. > > > > > On Thu, Jul 25, 2019 at 5:36 AM Carlos Rovira <[email protected]> > wrote: > > > Hi, > > > > if I understand correctly, both "runtime" and "provided" are right now > > equal for the compiler, right? I'm ok to understand conceptually > > "runtime" and "provided" as Greg says. At least for now, although if we > can > > inform the compiler to differentiate as well would be great. > > > > In the other hand, flemojos seems to me more natural ("merged", > > "external",...) since is what we use to manage in Flex days and in > > FlashBuilder, > > but don't know if is worth it to go to that kind of names, or better go > to > > the standard maven names. If it was easy to add flemojos names, I'd > choose > > those, but since there's many things to do, maybe we can stick with what > we > > have. > > > > In the other hand, thanks to Greg, we have this config solved in our real > > App now. But I think in the process of doing this fix I think Greg saw > some > > issues > > at framework level for maven. Hope Greg can expose it better if that's > the > > case, since maybe I'm wrong. > > > > thanks > > > > > > > > > > El mié., 24 jul. 2019 a las 2:15, Greg Dove (<[email protected]>) > > escribió: > > > > > Just to add to the discussion on the 'provided' vs. 'runtime' scopes... > > > I'm not really sure what scope name should be used for what, but here's > > > what I have assumed: > > > 'runtime' is for 'native' libs where the runtime provides the api > surface > > > that is represented by the swc. (playerglobal/ js-typedefs examples) > > > 'provided' is for dependencies that are pre-compiled swc dependencies, > > > where the dependency is expected to provided when the application is > > built > > > (in this case I have assumed it is explicitly listed as a dependency > for > > > the application build). > > > > > > I think these are different to what used to be the case with FlexMojos > > (see > > > 'Scope options in Flexmojos' [1]) > > > Also it seems that we don't do any of this in the framework project > level > > > poms, so I assume > > > that <forceSwcExternalLibraryPath>true</forceSwcExternalLibraryPath> at > > > frameworks/projects/pom.xml is a 'brute-force' override, simulating > > > <scope>provided</provided> for each of the child framework projects' > swc > > > dependencies, and avoiding them being merged in for each of the > framework > > > swcs. I assume this might be another difference from [1] also, but I'm > > not > > > really sure as my only exposure to maven has been since FlexJS/Royale. > > > > > > > > > 1. > > > > https://www.adobe.com/devnet/flex/articles/flex-maven-flexmojos-pt3.html > > > > > > > > > > > > -- > > Carlos Rovira > > http://about.me/carlosrovira > > > -- Carlos Rovira http://about.me/carlosrovira
