I’m sorry, but these repeated attempts to try to use Maven too much just make me very upset. This was a concern of mine when two people who have never produced a release went off to refactor the process. There is theory and reality. The reality is that Maven cannot and should not be used to streamline our release process because:
- We've learned over the years that RMs have trouble getting set up correctly. - We've learned over the years that RMs have trouble uploading Maven artifacts to repository.a.o. - We should know that the only way to validate the Ant Task in the release artifacts is to use Ant to verify it. Those are the three main reasons there are multiple release steps on the CI server. I am hopeful that the new Maven builds can cut down on one or two steps, or maybe just make those steps more straightforward, but the process simply cannot just run Maven's release steps on the RM's local computer. It must run on the CI server, and that requires stopping from time to time to verify and sign stuff. A fourth reason was that the Ant script had proven to be able to build an IDE-compatible artifact. I am not 100% convinced that the Maven distribution build can exactly replicate that artifact. But again, if an Ant user wants to use Ant to create artifacts for some IDE to test local changes, then we need to prove in each release that Ant can produce that set of artifacts for the IDE. So now that Maven can supposedly do the same, it actually adds more work to the verification process. The Maven artifacts for an IDE will need to be compared against the Ant-produced artifacts for an IDE. In short, we should use Maven to produce Maven artifacts, and Ant to produce Ant artifacts so that the RM is verifying the artifacts long before the voters have to. And make it all work on a CI server so that RM's don't have to deal with system setup, and not have upload issues blow up the process. I also am not a fan of using Maven to do scripting, especially if it involves custom mojos/plugins. That's what scripting tools like Ant are for. The goal should be to make the release system maintainable by everyone, not just by experts in Maven. Similarly, the Ant steps do not use custom plugins/tasks for the same reason. Use Maven to build the Maven artifacts. Use Ant to build the Ant artifacts and sequence the steps. Use the CI server. Verify and sign locally. These are the requirements. It was all working and we could have released every month. I think it is your responsibility to make it work again within those constraints. My 2 cents, -Alex On 3/17/20, 8:48 AM, "Carlos Rovira" <[email protected]> wrote: Hi this morning in the slack Apache Royale official channel Chris Dutz asked about plans for release 0.9.7. If you see Greg and I help him to create an Apache Royale interface for pulling data from a Consumer in an IoT Apache PLC4X app. Something very cool :). He published a tweet with a video showing it. So regarding the release, I explain that I spent many days some months ago trying to fix the CI release steps to release, but I was unable to do it. I think making changes to the Maven o Ant make the 13 steps very fragile and difficult to fix. And we need to evolve continually Maven and Ant, so that means a huge task that will require an huge amount of time that almost nobody here has. So I must say that although the work done on that front was amazing and huge maybe we need to streamline it to an standard. I know is difficult, but although we had many expectations put on the 13 step release process, after try it seems that we finally are not getting what we wanted, that is streamline the release process. This is one of the critical points that hold us to release 1.0, since not having an easy way to release means as we push 1.0 and people tries us, we'll need to be faster on releasing, and we can't wait 6 month or a year, since that we'll mean user will not want that kind of release cycle. So here is my proposal to work on a release process that allow us to release more often and more easily. Hope you all can consider it: First: We all know we want build with ANT and MAVEN. And when I refer to "all" I really mean "all". Although I'm a Maven advocate, I really appreciate the point to have ANT on place so having 2 build systems that completely works mean advantage. In fact although I use maven I build with both system daily. Second: Build does not mean Release. I think other times we discussed Release as a way to impose Maven over Ant. Or maybe that was the perception for others, but not my intention (and maybe not the intention of others). But that's not the objective. Release [1] means to us just "publication outside the development community, defined as individuals actively participating in development or following the dev list." That means that we don't need to release using Maven and Ant at the same time, we can streamline greatly the process to just releasing with Maven so we can ensure a simple process the same as any other Apache project. It means that people trying the release need to check it with Maven, but community users can continue using ANT or Maven to build or even just download the SDK and use it on his IDE of choice and don't use ANT or Maven at all. Third: The fact is the rest of projects I know all use releases and CI based on Maven, and that should point us that maybe we're trying to force something that is not standard in our industry, so if we want to make it more reliable and easy process, is normal to embrace how others are doing, since that does not mean we're throwing away a build system, since per previous point we don't want to remove ANT. Finally, Chris and I offer our time to make the easiest release process we can that let all of us release easily and often (maybe each 1-2 month?) Thanks [1] https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=8gWY67nvYiUF7svzTN2bychZHMGeqMGu0vtQHyEO85s%3D&reserved=0 -- Carlos Rovira https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=y5ueVlWqrKYSx6dGpiOr3ytI1w%2Bg%2FNRE051IlACZ2EU%3D&reserved=0
