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
