Well, there used to be just two repos. I don't think it was me that wanted a flex-typedefs repo. Re-organizing repos is painful and I'm not sure I see the value in doing it. Small separate pieces always seems to be a better idea than big monolithic things.
My 2 cents, -Alex On 2/8/17, 2:22 AM, "Christofer Dutz" <[email protected]> wrote: >Having all three parts in one repo is a thing I would like to support. >But I guess Alex had objections because he wanted to be able to release >compiler, tpyedefs and framework independently (I don’t think we should >be doing such a thing in the future). Especially when it comes to >branching and the “Jenkinsfile” support would be a lot easier with that. > >As I said there is a way to do a “one command builds all”, but it’s not >trivial to setup and requires misusing the maven-invoker-plugin. > >And I just gave my fake-pom a try and indeed the build fails with totally >strange errors which seem to relate to the jars being replaced underneath >the running VM. > >Chris > >Am 08.02.17, 11:10 schrieb "[email protected] im Auftrag von Carlos >Rovira" <[email protected] im Auftrag von [email protected]>: > > Thanks Chris, > > this is not critical right now but want to discuss with you in order >to > have some sort of roadmap in our head for things we want to get. > > Thanks! :) > > > 2017-02-08 10:58 GMT+01:00 Christofer Dutz ><[email protected]>: > > > 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. > > > > > > > > > -- > Carlos Rovira > http://about.me/carlosrovira > >
