FWIW, "runtime" and "provided" are defined by Maven, not us.
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope

If the compiler currently treats them the same, there is no guarantee that it 
always will, so probably a good idea to choose the right scope when possible.  
I think you get validation warnings if you use other scopes.

HTH,
-Alex

On 7/24/19, 11:04 PM, "Carlos Rovira" <[email protected]> wrote:

    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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.adobe.com%2Fdevnet%2Fflex%2Farticles%2Fflex-maven-flexmojos-pt3.html&amp;data=02%7C01%7Caharui%40adobe.com%7C55fe406c5d014327a6ab08d710c5e216%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636996314399207285&amp;sdata=aN45RBB4qDpNC3hv6l8REsK8MrPg7rhGdNJ1O9YSU1g%3D&amp;reserved=0
    > > >
    > > >
    > > >
    > > > --
    > > Carlos Rovira
    > > 
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C55fe406c5d014327a6ab08d710c5e216%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636996314399207285&amp;sdata=oFSCR02tcBktUqN66pTw%2B549LpzG9Q1NK08erKayqMc%3D&amp;reserved=0
    > >
    >
    
    
    -- 
    Carlos Rovira
    
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C55fe406c5d014327a6ab08d710c5e216%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636996314399207285&amp;sdata=oFSCR02tcBktUqN66pTw%2B549LpzG9Q1NK08erKayqMc%3D&amp;reserved=0
    

Reply via email to