Just to make sure I understand, I think there are 3 sets of things involved:
Mojo: A Maven extension that makes Maven understand something besides JARs Artifacts: Jars and in our case SWCs Mavenizer: A thing that takes pieces of the Flex SDK¹s and makes them useable in Maven. IMO, you can change anything in the Flex SDK as long as it doesn¹t have major impact on compile-time or run-time performance or ANT-script build times. AIUI, the mavenizer exists in part because Adobe used to ship an SDK and was unwilling to make it more Maven-compatible. Apache Flex can and should make changes to its packaging so the mavenizer isn¹t needed (or at least, less needed). -Alex On 10/5/14, 8:14 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: >After adding the maven tasks to falcon, I started adding the same to the >sdk itself. >Guess I'll start adding the deployment of the compiler artifacts and then >continue with the framework. >I think manually constructing and deploying the artifacts will give us a >lot more control over what's done and how everything is structured. >Having to specialize the mavenizer more and more sort of doesn't feel >right. > >Chris > > >-----Ursprüngliche Nachricht----- >Von: Christofer Dutz [mailto:christofer.d...@c-ware.de] >Gesendet: Samstag, 4. Oktober 2014 21:03 >An: dev@flex.apache.org >Betreff: AW: How to handle the groupIds of the default and falcon compiler > >No ... not exactly. > >Currently the org.apache.flex:compiler artifact is of type "pom" and >hereby doesn't have any library behind it. All it does is to transitively >pull in all the jars in the lib dir of the FDK. In Falcon there is >actually only one jar containing the entire compiler so I created it as a >"jar" artifact with dependencies. After finding out that all the other >jars don't make sense in a maven environment as they are empty with a >simple METAINF file pointing to a class in the main jar. So eventually >with the old compiler this is similar and I would adjust the generated >poms accordingly. This would however introduce something people allready >using Flex in Flexmojos would have to change. But thinking about it ... >we haven't released anything yet so it's not yet really official. I thing >tweaking a little is absolutely legitimate. > >Chris > > > >-----Ursprüngliche Nachricht----- >Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com] >Gesendet: Samstag, 4. Oktober 2014 18:27 >An: dev@flex.apache.org >Betreff: RE: How to handle the groupIds of the default and falcon compiler > >The 2 solution seems more logical to me, can you see a drawback ? > >> Another thing I will probalby change in the mavenizer is not to >generate a pom-typed compiler artifact, but to have the jar containing >the compiler become the root and I add all the dependencies tot hat. >Do you mean its pom.xml in a subfolder of the META-INF directory ? that's >just the way it should be IMO. > >Frédéric THOMAS > >> From: christofer.d...@c-ware.de >> To: dev@flex.apache.org >> Subject: How to handle the groupIds of the default and falcon compiler >> Date: Sat, 4 Oct 2014 16:09:50 +0000 >> >> Hi guys, >> >> sorry for all the flexmojos & maven spam recently, but I'm trying to >> get some things finished ;-| >> >> Usually we had all the compiler artifacts deployed with the group-id >> "org.apache.flex:compiler" and all oft he artifacts it needed were in >> "org.apache.flex.compiler:xxx" (The root artifact had a groupId >> without the "compiler" at the end) >> >> Now at first I had Falcon generated to the same group id, but had the >>root-object be "org.apache.flex.compiler:falcon-compiler" >> >> To me it sort of doesn't feel quite right and I would like to sort this >>out. So I have different suggestions: >> >> >> 1. I leave the old structure unchanged, and deploy falcon to >>"org.apache.flex:falcon-compiler" and all it's dependencies to >>"org.apache.flex.falcon-compiler:xxx" >> >> 2. I change the pom-artifact for the old compiler to >>"org.apache.flex.compiler:compiler", leave the rest unchanged and deploy >>falcon to "org.apache.flex.compiler:falcon-compiler" >> >> 3. Some other idea one of you might come up with :) >> >> So what do you think? >> >> Another thing I will probalby change in the mavenizer is not to >>generate a pom-typed compiler artifact, but to have the jar containing >>the compiler become the root and I add all the dependencies tot hat. >> >> So I hope I didn't confuse you ... don't want to decide stuff like this >>on my own. >> >> Chris >
