If we’re supporting both ant and maven (and I think we should), building both should be part of a release.
My $0.02, Harbs > On Nov 18, 2019, at 5:03 PM, Carlos Rovira <[email protected]> wrote: > > Hi Alex, > > right, I don't want to start a discussion about deprecating ANT. I like > Maven but I think neither Chris or I are wanting to remove ANT for > building. Just thought an option could be to not involve ANT in the release > process, but just in the users build process (that I thought is what we > really want to offer to our users), after analyzing how to simplify the > process. But if you consider we need to maintain ANT even in the release > process then we must all have in mind that we need to continue considering > it in the release process. > > I want to respond this first, since I have no more time right now. I'll > come back later to this discussion to see how we can proceed. > > Thanks > > > El lun., 18 nov. 2019 a las 10:49, Alex Harui (<[email protected]>) > escribió: > >> Fundamentally, I don't think we want to get rid of Ant or treat Ant as >> second-class. Some people still prefer Ant over Maven. We need to offer >> people choices. Not having a Maven-based release process (whatever that >> means) isn't the thing that new users are complaining about, IMO. You can >> try to approximate Ant-based testing with Maven, but the best test is >> simply to use Ant to build all of our code and examples. >> >> Of the 13 CI release steps, only one of them uses Ant. The first 11 are >> all about Maven. The reason there are 11 is in order to break up the steps >> to allow for building on a shared machine without credentials stored on >> them. That's because the two people who tried using a much simpler set of >> steps couldn't because of upload issues. It is the 11 Maven steps that are >> what broke in the 1 PR commit I reviewed so far. It has nothing to do with >> Ant. The current release process is not really Ant-based, IMO. >> >> You are welcome to work on a new release automation process, but If the >> voters on a release cannot use Ant to test/verify the release, then we >> won't know that Ant will work for the users. And if the invoker has to >> invoke Ant to test the Ant artifacts, then we still require Ant. >> >> IMO, the issues for building Maven snapshot artifacts are: >> 1) requiring settings-template.xml (this is apparently now fixed in the >> Flex release) >> 2) what environment variables are needed (this is apparently fixed in the >> PR) >> 3) the utils profile >> >> The issues for creating Maven release artifacts are: >> 3) the utils profile >> 4) the places we have to set-property >> 5) the upload failures >> >> It would be simpler to just be able to clone a repo, run maven >> release:branch, release:prepare, release:perform, then do the next repo, >> and the next. If this PR fixes that, that's super, because in the past we >> have invoke Maven in other ways to get the versions updated correctly by >> choosing the right profiles and set-property calls and that invites use of >> a batch script or Ant to automate that sequence. Then using Ant made it >> harder to re-start after an upload failure, so we changed to using the CI >> release steps. >> >> So if the PR has fixed all that, then maybe we can go back to using >> private computers to generate all of the artifacts. The CI release steps >> were set up so that people would not have to deal with various setup issues >> and try to dodge the upload issues. However, I think fixing the utils >> profile issue would require forking royale-compiler into two repos. Maybe >> forking royale-compiler is the right thing to do. >> >> In the end, though, you still need to clone several repos and invoke Maven >> at least 3 times for each repo to cut a release. I'm not a fan of using >> Maven as a scripting engine. Yes, I know you "can", but that doesn't mean >> you should. So, I think if we go back to building releases on private >> computers, Ant would still be the obvious way to invoke Maven 3 times on >> each repo in the right order. >> >> And, we must always ask whether this is really worth the effort. This >> thread started as making the Maven builds simpler which was great, but now >> it is starting to remind me of past discussions to make Maven primary >> which, IMO, has not been the best use of our time. You can be a fan of >> Maven all you want, just don't impose it on the rest of us. Ant and Maven >> are both useful tools and we should use them for what they do best and >> allow our users to choose. The RMs and voters will need to run both. But >> improvements to the Ant and Maven builds are definitely welcome, so thanks >> to Christofer for working on them. >> >> My 2 cents, >> -Alex >> >> On 11/18/19, 12:33 AM, "Carlos Rovira" <[email protected]> wrote: >> >> Hi Alex >> >> The Ant tasks are Java jar files, so the building has always been >> handled >> by the maven build. >> for testing, this is possible too as maven has the invoker plugin >> exactly >> for stuff like that. >> In order to actually test the tasks, some work is needed, but it's >> probably >> easier to do that than to fix the Ant based release process. >> >> Other option, that I'm starting to thing could be more appropriate: >> While >> we want people build with both Maven and ANT on its own, that does not >> necessarily imply to release with ANT too. The other posible option is >> to >> make release, that's a very concrete task to be only a task for maven, >> and >> people testing the RC must use Maven as part of the requirements to >> test >> the release. I think this should be something totally licit if we want >> to >> ease the problem and make others capable of doing this task in a more >> simplified process. >> >> >> >> >> El lun., 18 nov. 2019 a las 0:23, Alex Harui (<[email protected] >>> ) >> escribió: >> >>> If you don't use Ant, how can you build and test the Ant tasks? >>> >>> -Alex >>> >>> On 11/17/19, 3:43 AM, "Carlos Rovira" <[email protected]> >> wrote: >>> >>> Hi Alex, >>> >>> first of all I understand completely your concerns about this >> changes >>> since >>> I now the time and work it cost to you. At the time you worked >> on this >>> there was not all this new maven enhancements that allow us to >> simplify >>> things. I strongly believe that all this changes can carry us a >> less >>> painful build and release process if we (mostly I, supported by >> Chris) >>> can >>> overcome the CI changes to work with the new changes. All this >> will >>> ease >>> things for people coming that should be other priority for us. I >> think >>> this >>> is the main barrier for newcomers and making thing ultra easy >> can allow >>> more people coming to Royale. This is all a bet, that we think >> can >>> reach a >>> good point. We we need to solve things in chunks if we want to >> succeed. >>> >>> But, I want to state clearly here, that if you finally don't see >> a >>> good end >>> for this, you can veto this change and we can roll back to the >> previous >>> process. I think we can reach to simplify all and make releases >> more >>> easy >>> to do, but it will imply in some parts changes that we need to >> agree >>> that >>> can be done. For all this we need to try to be open mind. >>> >>> So instead of trying to expose ways to solve concrete parts >> already >>> exposed, I want to ask about how we can simplify the release >> process: >>> >>> We have Maven and ANT as first citizens for build process, so >> users >>> can use >>> what they want. But my question here's, do we need to use both >> in the >>> release process? From what I understand Apache only requires us >> to use >>> one >>> of them for releasing process. So we could just rely on the maven >>> process >>> that are just few lines (already posted early in this thread). >> Copy >>> here to >>> notice the simplicity: >>> >>> Ideally releasing a part of Royale is just a 2-3 step process: >>> >>> - royale-compiler: >>> - mvn release:prepare -DautoversionSubmodules=true >>> - mvn release:perform >>> - royale-typedefs: >>> - update the pom.xml: royale.compiler.version to the new >> released >>> version >>> - mvn release:prepare -DautoversionSubmodules=true >>> - mvn release:perform >>> - royale-asjs: >>> - update the pom.xml: royale.compiler.version and >>> royale.typedefs.version to the new released version >>> - mvn release:prepare -DautoversionSubmodules=true >>> - mvn release:perform >>> >>> >>> In doing in this way, we'll streamline the release process and >> will not >>> need to do anything more. Just that few lines. And that means >> hopefully >>> make our release process a more tiny process in time to all of >> us, >>> while >>> users that wants to build with ANT can do it without problem. >> Can we >>> agree >>> with this? Let me know if I'm wrong with this. Notice that my >> focus is >>> to >>> try to get to the easiest way possible to build and release we >> can get. >>> >>> To not create a very long thread. I'll left this here so we can >> see >>> what >>> you guys think about it. >>> >>> Thanks in advance >>> >>> Carlos >>> >>> >>> >>> El dom., 17 nov. 2019 a las 0:06, Alex Harui >> (<[email protected] >>>> ) >>> escribió: >>> >>>> I'm pretty sure I added JGIT in order to do the release on the >> CI >>> server. >>>> See change 1aa2b16 in royale-compiler on Feb 11, 2019. The >> reason >>> the CI >>>> needs JGIT is because the regular Maven git support seemed to >> expect >>> that >>>> you had a private key registered since most folks run the >> release >>> plugin on >>>> their private computer. JGIT allowed specification of username >>> without >>>> password for commits. >>>> >>>> The Royale compiler is also required to parse the time stamps >> in >>> order to >>>> inject them into the SWFs and SWCs. So I am hopeful that >> didn't >>> break, but >>>> if it did, you know where to look. Also the release steps on >> CI >>> expect the >>>> timestamp to be given by the RM so it can be used in Ant as >> well. >>> So I am >>>> concerned about that as well. But maybe it will work or you >> will >>> fix it. >>>> I don't care as long as it doesn't cost me time. But as RM >> you are >>>> responsible for the Ant artifacts as well. The timestamp must >> also >>> be >>>> handed to the voters as well in order for them to reproduce >> the same >>>> binaries. >>>> >>>> My experience was that zlika was very responsive to fixing an >>> issue. I'm >>>> not sure if Maven has picked up all of the zlika changes, but >> if >>> not, then >>>> one of the artifacts will not reproduce. When I offered a >> patch to >>> Maven, >>>> I was told I had to go figure out their test harnesses and >> build a >>> set of >>>> test cases, which I still haven't found time to do. Again, if >> it >>> all ends >>>> up working and doesn't cost me time, it doesn't matter which >> plugin >>> we use. >>>> >>>> My 2 cents, >>>> -Alex >>>> >>> -- >>> Carlos Rovira >>> >>> >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2a612acd9b9a446b56b508d76c01f460%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637096627978180111&sdata=TtLJ9PKWcFhxX7i0UNdSBhdV60IDl8fvIDNrXExgb%2Fk%3D&reserved=0 >>> >>> >>> >> >> -- >> Carlos Rovira >> >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2a612acd9b9a446b56b508d76c01f460%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637096627978180111&sdata=TtLJ9PKWcFhxX7i0UNdSBhdV60IDl8fvIDNrXExgb%2Fk%3D&reserved=0 >> >> >> > > -- > Carlos Rovira > http://about.me/carlosrovira
