Hi Alex, It is the 11 Maven steps that are what broke in the 1 PR commit I reviewed > so far.
Are you saying that we have now 11 steps broken ? Am I understanding this correctly ? Thanks, Piotr pon., 18 lis 2019 o 10:49 Alex Harui <[email protected]> napisał(a): > 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 > > > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
