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
