Ok ... as it sort of feels silly to not respond to this list, but read it ... here goes ;-)
Shouldn't the metric be: "does it bring the project forward?" and less "how much time did it cost to get here?" In PLC4X I recently deleted code that took me more than 3/4 of a year to write in more than full-time work. No commit felt better as it improved things greatly and what we replaced it with, was a giant leap for the project. So if you folks could explain what the refactoring I did some time ago broke ... And perhaps let me explain the reason for doing it in the first place: I really loved and still love the productivity I had with Apache Flex. I was consumed with counting and shifting bits, however knowing I need a frontend eventually. I was hoping that Royale was going to be that option. However I did notice with worries how long it took to get new releases out the door and hearing rumors about how many people invested so much time and some still failed. So I offered my assistance and had a look at the build. Being an expert in this particular area, I did notice some configuration "problems" or "misconfigurations", which I fixed. Usually if you need something special for some reason it's a good practice to write a comment to it in order for the person viewing the code to know the implications and reasoning behind this. You can't expect every newcomer to parse the last few years of discussions before contributing. Another reason was that I remembered that one of the "objections" to Maven was, that Maven couldn't do reproducible builds. So as the latest versions of the core maven plugins were updated to support this, I thought, perhaps this way we could get a stable release process. From a Maven point of view the updated Maven build is now rock-solid. Releasing it would require two timely separated sessions and 3 commands in total and would be done on the developer machine. 1) Create the release branch 2) Prepare and do the release The issues you folks were having ... I can't really confirm them ... Just to day I did a check of how many Apache project use which build tool. The result was that 61,9% use Maven (4,2% use Ant) ... if Maven really was that broken, I guess we would be hearing a lot more from the other projects. And I am not hearing any complaints at all. If the distributions are currently not 100% match of the Ant ones, I would like to help to make them one. Just tell me what the difference is and it'll be done in no-time. However it's hard to fix something you don't know what's broken. Also do I not quite understand why a jar used in Ant has to be built by Ant ... in general the jars should be identical. I know that maven saves some additional information in the pom (Actually storing the pom and the values properties had when it was built in the jar, which I think is a great thing for reproducibility). Perhaps disabling this could make them identical. And as soon as that's the case, I don't really see the point in building them twice. Do you agree? And no worries, I am not interested in joining the project again ... I want to help the project be able to get releases out because I would like to use them. After that's done I'm happy to disappear again, if you wish that I do. So far all the projects I have helped with their builds are firing out releases like machine-guns ... let me help you folks do so too. Chris Am 18.03.20, 12:43 schrieb "Piotr Zarzycki" <[email protected]>: Btw. I truly doubt that it would be bigger than time which was invested in building this whole release process. śr., 18 mar 2020 o 12:41 Piotr Zarzycki <[email protected]> napisał(a): > Carlos, > > Why it is so huge effort ? What was broken so much that you are talking > about huge effort ? > > śr., 18 mar 2020 o 12:37 Carlos Rovira <[email protected]> > napisał(a): > >> Hi Piotr, >> >> as I responded before, I think that will be a huge task, in effort and >> time, and a task that can be easily broken again as any other one >> introduces new changes, what is something will happen for sure as we >> evolve. So what I'm offering is my time to be used in a way that can allow >> us to have a more reliable workflow. If I work on trying to fix as it's >> now, I probably will not succeed since I already tried for several hours >> and days (you can check emails around 19 or 20th Nov I think), and nothing >> of my tries could make a difference. Instead, I'm think taking a big >> different approach can make a difference. I can be wrong, but in that >> case, >> we'll know for sure that the way to go is the current one. >> >> >> El mié., 18 mar. 2020 a las 12:05, Piotr Zarzycki (< >> [email protected]>) escribió: >> >> > Carlos, >> > >> > In the other ways you are not going to fix current steps and release new >> > version of SDK ? >> > >> > >> > >> > śr., 18 mar 2020 o 10:39 Carlos Rovira <[email protected]> >> > napisał(a): >> > >> > > Hi all and thanks for your responses: >> > > >> > > @greg, yes the plan I point is to do research to try a new way and see >> > > where we go. At the end, we don't get it, it will be our >> responsibility >> > and >> > > our time. >> > > >> > > @yishay, I think you state a concrete but very real issue. I think the >> > work >> > > done by Alex was amazing (no doubt here), but I'm afraid, as much as >> it >> > > pains me to say it, that it does not solve the problem you state and >> the >> > > proof is that only Piotr tried to use the process and it was not easy >> and >> > > then when fixing other things, it has broken with some ease. >> > > >> > > @om, as I said in the initial email. There's no war anymore between >> Maven >> > > and ANT. We all want both, and I'm using both when developing Royale >> to >> > > test. As well I continually know more about how things are done in >> Maven. >> > > My position is just that we need to separate concerns. One thing is to >> > have >> > > both systems for developers and user to use (Maven and ANT), but my >> point >> > > is that Releasing should just involve Maven, since is more suite for >> > > releasing at Apache and CIs, and ensure Ant continue working as >> expected. >> > > So no one wants one over the other, or remove one of them. That's not >> the >> > > problem anymore. >> > > >> > > @piotr, I think your experience is very important, since you were the >> > only >> > > one that do the full process. My guess is that removing ANT from the >> > > release process will remove completely all the pain with such complex >> > > process and we all be able release from our own machines without >> having >> > > problems with complex task, uploading artifacts to a.o and more. We >> just >> > > need to ensure ANT still can be build exactly as before, and continue >> to >> > > produce the same. >> > > >> > > So in the end, we can stick with the old process, or try another >> > different >> > > approach to it build over standards. That means Chris and I will be >> using >> > > our times not yours. If we succeed, your test of the new approach will >> > need >> > > to ensure all the prerequisites and be lot more simpler. If we don't >> get >> > to >> > > that and fail in the process, just announce here and we can continue >> in >> > the >> > > old process. >> > > >> > > That's my proposal (that will need to be consensuated first here and >> then >> > > with Chris) >> > > >> > > Thanks >> > > >> > > >> > > >> > > >> > > >> > > El mié., 18 mar. 2020 a las 8:14, Alex Harui >> (<[email protected] >> > >) >> > > escribió: >> > > >> > > > >> > > > >> > > > On 3/17/20, 11:37 PM, "OmPrakash Muppirala" <[email protected]> >> > > wrote: >> > > > >> > > > My 2 cents: >> > > > >> > > > I don't think we need to go back to the Ant vs Maven discussion. >> > If >> > > > the >> > > > Maven build/stage/release scripts works flawlessly, an Ant task >> can >> > > > simply >> > > > call it. There is no reason both cannot be worked on >> continuously. >> > > > In the >> > > > same way, if Maven users want, they can call Ant scripts as >> needed. >> > > > >> > > > Why do both camps want the other way to go away? >> > > > >> > > > I don't want one to go away. I want to use Maven for what it is >> good >> > for >> > > > and Ant for what it is good for. >> > > > >> > > > For example, we also publish to NPM as part of the release. >> There >> > is >> > > a >> > > > node.js script that gets called from the Ant script during the >> > > release >> > > > process. The node.js script is a black box as far as the Ant >> > script >> > > is >> > > > concerned. >> > > > >> > > > That said, Carlos if you think you can get a release done with >> just >> > > > Maven, >> > > > please go ahead and give it a shot. From what I remember, the >> > Maven >> > > > part >> > > > of the build/release was the issue and not the Ant portions. We >> > all >> > > > would >> > > > love to see improvements there. >> > > > >> > > > Alex, you say that Carlos did not work in the trenches during >> the >> > > > release >> > > > process, but are objecting (I think, if I understand your email >> > > > correctly) >> > > > to him wanting to work now. That seem contradictory, IMHO. >> > > > >> > > > I'm saying that if Carlos/Chris go back to the Maven Release Plugin >> > > > process, it will likely bring us back to the same problems we >> created >> > the >> > > > CI steps to work around. So why go through all of that again? >> > > > >> > > > Like Piotr just posted, Carlos should get in the trenches and get >> the >> > CI >> > > > steps to work with the new Maven poms. Not acknowledging that >> there >> > > have >> > > > been past problems using the process they propose is going to >> result in >> > > > more time wasted. >> > > > >> > > > -Alex >> > > > >> > > > >> > > > >> > > > >> > > >> > > -- >> > > Carlos Rovira >> > > http://about.me/carlosrovira >> > > >> > >> > >> > -- >> > >> > Piotr Zarzycki >> > >> > Patreon: *https://www.patreon.com/piotrzarzycki >> > <https://www.patreon.com/piotrzarzycki>* >> > >> >> >> -- >> Carlos Rovira >> http://about.me/carlosrovira >> > > > -- > > Piotr Zarzycki > > Patreon: *https://www.patreon.com/piotrzarzycki > <https://www.patreon.com/piotrzarzycki>* > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
