Carlos, I lost at least 3 payed days on having Upload artifacts on Windows using Maven and I have never successes with that. - It wasn't only me. - Uploading problem didn't gone for sure. Last release is just a proof.
Anyway again I suggest you start learn how release process works, try and than provide next PR or commits. And I agree with you on one of your email that everything can be done trough Maven, but who is going to do that ? - that is a bigger question. I can confirm that current release process is ok and I'm able to release SDK in about 3-4h - why so much time, this is just because building stuff takes some time - The rest of the things is automated - please do not break that stuff, cause it would be a shame to loose such a good process. Thanks, Piotr pon., 18 lis 2019 o 16:56 Carlos Rovira <[email protected]> napisał(a): > 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 > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
