And you are going to have the exact same set of issues as with profiles.
Maven 3 does not re-interpolate the poms of dependencies IIRC... or at
least it is not supposed to... so you only get to control the variables
from the parent pom and any inherited dependencies/dependencyManagement not
from the transitive dependencies of your pom
On 1 July 2014 10:42, Christofer Dutz <christofer.d...@c-ware.de> wrote:
> Hey ... now that looks promissing :-)
>
> I'll give that a spin as soon as I have time.
>
> I didn't know that you could use variables in the scope (But I think
> that's just some old info probably stored in my brain ages ago).
>
> Chris
>
>
> ________________________________________
> Von: Jörg Schaible <joerg.schai...@gmx.de>
> Gesendet: Sonntag, 29. Juni 2014 15:16
> An: users@maven.apache.org
> Betreff: Re: AW: AW: Artifact with different sets of dependencies switched
> by profiles
>
> Hi Christoper,
>
> Christofer Dutz wrote:
>
> > Hi Ron,
> >
> > I think you got what I'm trying to do a little wrong. It's not two
> > different set of dependencies, it's two different ways of linking the
> same
> > set of libraries. If I were to translate this into java, imagine that the
> > default way an application was built would be to include all Classes
> > needed by the application to be bundled in the application Jar (The
> > classes not needed aren't included). Now in modular applications I am
> able
> > to switch to something exactly the same as in Java ... no code is
> included
> > in the Application jar, but the referenced libraries are deployed in
> > parallel to the application jar, so the JVM can pull them in as needed
> (In
> > Flex this type is called rsl (runtime shared library).
> >
> > So in principal I have the same set of dependencies, but in the
> > rsl-linking type these dependencies have an additional "scope=rsl"
> > setting. Up until now there was only one pom with the default set of
> > dependencies. If the users wanted to utilize rsl linking they would have
> > to manually add each dependency and set that's scope to rsl. I would like
> > to make it easier for users to switch.
> >
> > So the profiles is bad, the pom with classifier doesn't work ... I would
> > really like to avoid to have something like an "flramework" artifact and
> > one "framework-rsl" for the rsl linking.
>
> What's the default value for the scope? "compile"? Then you can do all you
> need with properties. You might use a profile, but it is not necessary:
>
> Declare your dependencies just like before (either in depMgmt or directly):
>
> ============== %< =================
> <dependency>
> <groupId>org.apache.flex.framework</groupId>
> <artifactId>spark</artifactId>
> <version>4.12.1.20140427</version>
> <type>swc</type>
> <scope>${flexmojo.scope}</scope>
> </dependency>
> ...
> <properties>
> <flexmojo.scope>compile</flexmojo.scope>
> </properties>
> ============== %< =================
>
> Then you can simply redefine "flexmojo.scope" from command line. This will
> also affect inherited dependencies, if they are declared in the same way in
> the repository or if you delcare them in a common parent with a
> dependencyManagement section. You might even overwrite the property in a
> profile:
>
> ============== %< =================
> <profile>
> <id>rsl</id>
> <properties>
> <flexmojo.scope>rsl</flexmojo.scope>
> </properties>
> <profile>
> ============== %< =================
>
> Unfortunately, I don't know nothing about flexmojo. If it works like in the
> world of C where I can use the same libraries (.lib files) to link an
> application either static or dynamically (then requiring runtime libs as
> well), then it is possible to do this. Therefore is is fine for an project
> creating such an application at the end of a build chain.
>
> However, if the libraries differ if build with rsl or not, then you will
> create a very bad user experience, because - just as Stephen already said -
> the build process will use whatever it finds in the local repository, it
> cannot separate between artifacts built with rsl or without. Your users
> might get a wild mix during build time.
>
> Cheers,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
