" maybe an additional repo can be setup which includes the existing ones as submodules "
that is what I interpreted the proposal to be. The advantage for maven is the possibility to do the same as 'ant all' by using the 'shell' repo. On Wed, Dec 4, 2019 at 7:33 AM Harbs <[email protected]> wrote: > Submodules doesn’t seem to have a good name: > https://medium.com/@porteneuve/mastering-git-submodules-34c65e940407 < > https://medium.com/@porteneuve/mastering-git-submodules-34c65e940407> > > I don’t really see a need to use submodules if we’re compiling with ant > (or likely other tools). I don’t know what it fixes for Maven, but maybe an > additional repo can be setup which includes the existing ones as submodules > and can optionally be used for compiling. > > Does that make sense? Dunno… ;-) > > Harbs > > > On Dec 3, 2019, at 8:16 PM, Alex Harui <[email protected]> wrote: > > > > I didn't know about "git submodules" and didn't see it referenced in the > proposal. I saw "one repository" in the subject. That sounds disruptive > and I am concerned about scaling. > > > > I read a quick intro on "git submodules" and it sounds like we could add > another repository as you propose. That might be worth a try. > > > > -Alex > > > > On 12/3/19, 10:01 AM, "Greg Dove" <[email protected] <mailto: > [email protected]>> wrote: > > > > ' IMO, it sounds very disruptive to try to collapse 3 repos into 1. ' > > > > I did not interpret it that way, at least not for now anyway. It > sounds > > like just making a 'light' repo that has the existing repos as git > > submodules. > > That to me actually sounds like an easy way to handle more (than 3) > repos > > if it is necessary. > > But maybe I missed something in my understanding... > > > > > > > > > > > > On Wed, Dec 4, 2019 at 6:20 AM Alex Harui <[email protected]> > wrote: > > > >> IMO, it sounds very disruptive to try to collapse 3 repos into 1. > >> Honestly, I'd rather we make sure our processes can handle more than 3 > >> repos someday. If the project grows, we may want to release things on > >> different schedules. IOW, I think we should be thinking about more > smaller > >> releases instead of one big one. And doing more separation makes sure > we > >> don't accidentally create dependencies we don't want, like having the > >> compiler generate a certain kind of output. > >> > >> I am not a Maven expert, but my impression is that separating the utils > >> out to a 4th repo would simply the process of building everything to a > >> series of "mvn clean install" and we wouldn't have to deal with > profiles. > >> > >> Another place we use profiles is to cut down on build time by not > bullding > >> examples and distribution unless you ask for it. We could move those > >> profiles to their own repos if needed. > >> > >> If Maven is lacking a scripting feature that makes it easier to pull > down > >> repos or source packages and build them in sequence, then that might be > a > >> plugin that Maven should add or we could add in yet another repo. > >> > >> When we start doing "tricks" to make Maven build Royale, it means to me > >> that we aren't really using Maven as intended. Maven itself seems to > be a > >> project split across many repos. We "should" be able to manage our code > >> across many repos as well. > >> > >> My 2 cents, > >> -Alex > >> > >> On 12/3/19, 7:38 AM, "Carlos Rovira" <[email protected]> wrote: > >> > >> Hi, > >> > >> this days I stop my CI work due to some things. I was doing at the > same > >> time needed work for a client in implementing Jewel DataGrid and > >> ButtonBar. > >> I'm progressing in those components and hope to contribute soon as > >> they are > >> ok in API terms and looking good. > >> > >> Btw, Chris Dutz was helping me on CI but he was thinking that most of > >> our > >> complexity could gone if we have just one repo with submodules. He's > >> working on that doing some refactoring that hopefully can be > >> contributed > >> soon. > >> > >> In doing that we'll get building with just one "mvn install", while > we > >> can > >> continue building each submodule as we do now. That will mean to > >> request an > >> "apache-royale" repository. > >> > >> Beign said that the technical tasks are: > >> > >> - Split up the royale-maven-plugin into 3 modules: > >> - the maven plugin (released separately together with the > >> api/model), > >> - a plugin api/model and > >> - a compiler implementation (released with the project) > >> - Add a “provided” dependency to the compiler implementation to > >> every > >> js/swf module (will to that by adding a global dependency in the > >> root) > >> - Add the 4th git repo which includes the 3 parts as submodules > and > >> also > >> contains a pom.xml which adds the 3 modules to the reactor > >> > >> The maven plugin is a super basic plugin, that does nothing else than > >> look > >> for an implementation of a compiler on the classpath and to relay to > >> that. > >> Therefore it should be possible to release this once and not for > every > >> release. > >> > >> > >> With this generally all modules can be built in one execution of “mvn > >> install” or "mvnw install" (if user does not have maven already > >> installed) > >> in the new root pom level. > >> > >> > >> The general trick is that the maven plugin doesn’t have a fixed > >> dependency > >> on the compiler, it loads the compiler implementation at runtime from > >> the > >> project’s dependencies. > >> > >> This dependency was what was preventing us from building (and > >> especially > >> releasing) all 3 together: > >> > >> - Maven builds a reactor first for that it resolves the plugins > and > >> their dependency > >> - As the plugin currently is part of the build of the typedefs and > >> the > >> framework when doing a release this plugin does not yet exist and > >> the build > >> will fail. > >> - With this change the plugin and all of its dependencies (none) > are > >> resolvable and we’re able to build and release. > >> > >> > >> > >> The only reason we will not be able to release the triple-project is > >> that > >> the release prepare goal can’t handle these sub-modules. > >> > >> > >> > >> However if all modules were really merged into one … that would > >> absolutely > >> be possible. > >> > >> > >> > >> Chris also noticed that the Ant compiler configs changed quite a bit > >> and am > >> currently cleaning up in the different compiler mojos. For every type > >> of > >> compilation we’ll have 2 config templates: a js version and a swf > >> version. > >> > >> > >> So I want first to share this work here to start giving exposure > (Chris > >> hopefully will have it in the next few days, while I end with Jewel > >> components). > >> > >> I think it will be another good improvement to continue > simplification > >> if > >> nobody objects nothing to it. That will mean that CI will benefit > from > >> that simplification as well the release process, so better for me to > >> save > >> that work hours for this new enhancement, instead of doing that work > >> now > >> and rework again in few days. > >> > >> > >> Let me know what you think all about it > >> > >> > >> Thanks! > >> > >> > >> > >> > >> -- > >> Carlos Rovira > >> > >> > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cdf9cbbe86efc44dbd51908d7781abfcb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637109928592939165&sdata=%2BsaBwuOBwyrrLZiEq2adpMgijGGMvrNw1Y6FwjRYGvk%3D&reserved=0 > < > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cdf9cbbe86efc44dbd51908d7781abfcb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637109928592939165&sdata=%2BsaBwuOBwyrrLZiEq2adpMgijGGMvrNw1Y6FwjRYGvk%3D&reserved=0 > > >
