I'm not going to change anything in the build itself. All that will be added is a "maven.xml" ant script that would create and deploy artifacts from the result of a previous build. It's my goal to be able to setup a Jenkins job to auto deploy SNAPSHOT versions of Flex resources. And provide the targets for staging release versions when doing a RC.
Yesterday I invested several hours going through each class in the flex SDKs Java code going through the import statements and hereby finding out which module depends on what other artifacts (Maven is a lot stricter than usual ANT builds with a mixed up lib directory). While doing this it seems that quite some libs in the FDKs lib directory aren't really needed for using Flex, but more for building it. Then there is a set of artifacts not needed in maven (All the empty jars containing only a MANIFEST.MF file). So no worries, that my work would break anything. It will not have any effect on the current build. Chris ________________________________________ Von: Alex Harui <aha...@adobe.com> Gesendet: Montag, 6. Oktober 2014 06:36 An: dev@flex.apache.org Betreff: Re: AW: How to handle the groupIds of the default and falcon compiler 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 >
