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]> 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 > > >
