and no manual mavenizing? ApacheCon is coming :) On 18 October 2014 01:20, Christofer Dutz <christofer.d...@c-ware.de> wrote:
> Ok ... to make this short ... adding a "-rb" to the end of the artifact > name would sort of let the number of artifact directories explode. > That's why I implemented this feature wuth the ".rb" suffix on the > groupId. If Flexmojos, The Testsuite and my projects build with this > option, I guess Flexmojos 7.1.0 is allmost ready to go :-) > > Chris > > -----Ursprüngliche Nachricht----- > Von: Christofer Dutz [mailto:christofer.d...@c-ware.de] > Gesendet: Freitag, 17. Oktober 2014 18:35 > An: 'dev@flex.apache.org' > Betreff: Changes to the mavenizer > > Hi, > > ok while there was only one test failling with Maven 3.1 it was a nasty > one and it took me about 12 Hours of debugging to track it down in total :( > Maven 3.1 seems to be doing a lot more validation than 3.0. Currently I > have the pom, swc, swf and all the rb.swc files in one artifact. Then I > sort of have a dependency of an artifact to itself, but with a different > type. This far Maven seems to be fine with it. Now as soon as I want to use > RSL linking, I have one dependency with scope "rsl" and the same with > "compile". Now it tries to resolve the problem, but as "rsl" is unknown to > Maven, it defaults to "runtime", which breaks the flex build. > > It seems the only option we have is to separate the artifact and it's > resource bundles into two different artifacts. Now there would be differnt > options for this: > > > - Generate them to a different groupId releative to the artifact > itself (so for org.apache.flex.framework:framework:{version}:swc this would > be org.apache.flex.framework.rb:framework:{version}:swc) > > - Generate them to a different artifactId by appending "-rb" to > the artifact (Or whatever would be the consense) (so for > org.apache.flex.framework:framework:{version}:swc this would be > org.apache.flex.framework:framework-rb:{version}:swc) > > What do you think? > > I'm really glad we haven't released anything yet ... this change would > have been a real PITA to work around :) > > But the good thing ist hat besides having to re-deploy the FDKs there > shouldn't be any impact on existing builds as the resources were allready > pulled in automatically. > > Chris > -- WBR Maxim aka solomax
