Hi Carlos, No unfortunately this applies to all builds (Or at least it should). So, if for example you created a pom.xml in the common root of all three checked out repos and add each repo as a “module” inside that. When running “mvn clean install” on that pom, you should probably get some serious problems. For this workflow to work the compiler and maven plugin need to be in a separate maven run than where it’s used (typedef and framework). Putting typedef and framework into one build however shouldn’t be any problem at all.
I’ll add them to my list and hopefully can find some time soon. Unfortunately for the project I currently have a project that requires me to do work for my customer. That’s sort of new to me. Usually I could spend my time at the customer to do Flex stuff as he could not provide me with work fast enough ;-) Chris Am 08.02.17, 09:55 schrieb "[email protected] im Auftrag von Carlos Rovira" <[email protected] im Auftrag von [email protected]>: Hi Chris 2017-02-08 9:15 GMT+01:00 Christofer Dutz <[email protected]>: > Hi Carlos, > > Well bringing all three repos into one would be a cool thing and shouldn’t > have too big implications. > One problem I have observed to have increased greatly in the last few > months (Don’t know what changed though). > If I build jars that are required as/in plugins in other parts of the > build, maven now fails deterministically. A year ago I was using the same > Maven version but I got random failures at about 10% of my builds. Now I > get failures at 100%. I don’t know if it’s changes to the Java VM or the > OS. But I get loads of ClassNotFoundExceptions because the classloader > thinks a jar is empty if it is replaced during the builds. > > I just had to refactor Flexmojos build into a plugin and framework build > (the same way I split up FlexJS) to be able to build at all. > > Currently I’m thinking of highjacking the maven-invoker-plugin to run all > three builds separately (I’m using the invoker plugin in the > framework/testsuite module. > If I understand right, the problem you state is when building in Jenkins? running maven in local works flawlessly :) I was imagining that some kind of parent container (i.e: "flexjs") that holds the other three repos (i.e "modules" would do the magic, so when you pass maven in "flexjs" you build the child in order (since they will be listed in the modules pom section in the right order) > > Regarding a fourth type of archetype … I agree … and while at it, I think > a fifth containing a typedef would be good too. Archetypes are easy to > create. Just have a look at the existing ones. But I’d be happy to help if > you are stuck. > > Chris, I prefer that you hold the torch of this since I have the following tasks in my TODO list: - SwizJS swc - AMFJS swc - Component Set design for Express. and can't accept more load. Many things todo and so many time ;) Could you create both archetypes? Thanks for your help Carlos > Chris > > > Am 07.02.17, 20:41 schrieb "[email protected] im Auftrag von Carlos > Rovira" <[email protected] im Auftrag von [email protected]>: > > Hi Chris, > > just want to ask you about: > > 1.- What about to create a Maven Archetype to setup a library project > (SWC)? I think this is missed and is needed as with others > > 2.- I think you talked in the past about to group the 3 maven repos > into > one build (although still being able to build it separately). It seems > to > me that this should not be very difficult right? > Or maybe there's something implied that makes it not possible? > > Thanks > > > -- > Carlos Rovira > http://about.me/carlosrovira > > > -- Carlos Rovira Director General M: +34 607 22 60 05 http://www.codeoscopic.com http://www.avant2.es Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC S.A. La finalidad de dicho tratamiento es facilitar la prestación del servicio o información solicitados, teniendo usted derecho de acceso, rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación necesaria.
