Hi, After the mavenizer is released there is no longer a need to use the settings-template.xml files at all and we can delete them. This is not related to the PRs, and is something we can do aside we need to revert the PRs or make other changes over it to improve what we have.
The Maven build only uses one Environment Variable and that is identical to that of ANT providing the Gecko-Driver parameter is optional and adds tests not run in the ANT build. There is no need to release the utils jars at all right? We released that once and these versions should be used. Chris explicitly made them so stripped down that they only need to be released once. If however something is changed with them, then a separate release will be required, but this should actually not be the case. If someday that happen we can target that isolate case right? Can we agree with this? The proposal wouldn’t eliminate ANT from the equation. Users can use a Maven built distribution and this should be almost bit-identical to the one built by ANT. So people wanting to test the Maven built release with Ant, all they have to do is to simply download the bin distribution and run the ANT scripts the way they would with an ANT built release. The properties have to be updated manually (royale.compiler.version and royale.typedefs.version) but that’s actually a clean thing to do. It can start to complicate if we update outside projects as part of the release process. It would be possible, however that would add additional constraints to the setup (fixed directory structure for the 2 other repos). Possible and if this should be automated Chris and I would volunteer to work on this. As you saw already, with this changes it should be possible to come back to run the release on any private machine. This can be done (and is the preferred way to all of us and for Apache), but only if the things to do are relatively "compact" or reduced. The projects are configured, that in general specifying any profile for the release should no longer be required at all. The default should work and the release build auto-enables all required profiles. Chris comment me that uploading of maven artifacts just works on all project we saw at Apache and releasing a larger number of artifacts don’t have problems. Seems there were issues with Apache’s Nexus system in the past but for the past years this has actually worked really well, maybe that uploading problem is gone for us too, if not we should try to understand why is happening that in this concrete project. The Maven release plugin was built to automate releasing Maven projects. It’s the default way to do things in the Maven world and the one supported and 100% Apache compatible way to do it. So we should not have problems in that point anymore, if not maybe we have some collateral problem affecting that part. I think we should try to bring all this positive points to be more healthy as an open source project that makes use possible to release frequently and by many PMC members. Thanks Carlos El lun., 18 nov. 2019 a las 16:03, Carlos Rovira (<[email protected]>) escribió: > 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 > > -- Carlos Rovira http://about.me/carlosrovira
