OK. So it shouldn’t be disruptive to an existing workflow which uses the three 
separate repos. I don’t see a downside if it’s helpful for Maven.

Harbs

> On Dec 3, 2019, at 8:39 PM, Greg Dove <[email protected]> wrote:
> 
> " 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] 
> <mailto:[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> <
>> 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]> <mailto:
>> [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] 
>>> <mailto:[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] 
>>>> <mailto:[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&amp;data=02%7C01%7Caharui%40adobe.com%7Cdf9cbbe86efc44dbd51908d7781abfcb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637109928592939165&amp;sdata=%2BsaBwuOBwyrrLZiEq2adpMgijGGMvrNw1Y6FwjRYGvk%3D&amp;reserved=0
>>  
>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7Cdf9cbbe86efc44dbd51908d7781abfcb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637109928592939165&amp;sdata=%2BsaBwuOBwyrrLZiEq2adpMgijGGMvrNw1Y6FwjRYGvk%3D&amp;reserved=0>
>> <
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7Cdf9cbbe86efc44dbd51908d7781abfcb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637109928592939165&amp;sdata=%2BsaBwuOBwyrrLZiEq2adpMgijGGMvrNw1Y6FwjRYGvk%3D&amp;reserved=0
>>  
>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7Cdf9cbbe86efc44dbd51908d7781abfcb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637109928592939165&amp;sdata=%2BsaBwuOBwyrrLZiEq2adpMgijGGMvrNw1Y6FwjRYGvk%3D&amp;reserved=0>

Reply via email to