Reponding to this post inline. But first, some responses to other posts: @piotr, I have not reviewed all of the commits in the PRs, but the first one I looked at removed JGit and Wagon which are used by the release steps. Maybe they got restored in later commits. I don't know. But if they haven't, then yes, the release steps are currently broken, but it should just be a matter of re-adding those dependencies in the pom. I do think I saw that the names of profiles changed as well, so places in the Jenkins jobs where profile names are specified might need to be updated as well. And the format of the timestamp changed for reasons I'm still not sure of that will require updating the Jenkins jobs as well.
Harbs put it well, that we should use Maven for building Maven artifacts and Ant for building Ant artifacts, but I want to add something I've said before: If there was yet another popular build tool that would bring us more users (Grunt, Yeoman, etc), I would happily add that as well, so we should not be framing this discussing as Maven vs Ant. We are just providing support for build tools our users want to use. Also, after my inline reponses, I will put a initial list of some differences between Maven and Ant. Maybe if we collect these differences with an eye for including a third and fourth build tool, we will make the right plans for the future. Also, I'm able to respond quickly to this thread now because Alina and Serkan haven't asked for help yet, but they will take priority if they do. On 11/18/19, 7:56 AM, "Carlos Rovira" <[email protected]> wrote: Hi, Snip... 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? It is my understanding that to build the sources from a truly clean system that you must built the utils jars yourself. Especially if your are off-line or don't want Maven to pull the jars someone else built out of the SNAPSHOT or release Repos. Also note that we just made another release of utils jars in 0.9.6, so it wasn't one-and-done. It is a bit troubling to me that these changes are being proposed by people who have not actually been the RM for the artifacts they want to change the process for. I'm concerned that these suggestions don't fully handle the reality. 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. IMO, fans of Maven should consider deleting the attempt to build an SDK equivalent of Ant artifacts and leave that to Ant, and instead, help VSCode and Moonshine with their Maven project support. Back when we first did Maven support for FlexJS/Royale, we wanted to support legacy IDEs. I'm not sure that is as true today. Let the Ant build support the legacy IDEs and get the new IDEs to support Maven. 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. If you look through the build steps, I think you'll see that set-property is called more than once per repo and/or with a specific set of profiles. I'm not sure we are using those properties correctly. It might be that places that have specific versions need to use the properties instead, or the projects that have these properties set in the poms should be grabbing that property from the root pom. Snip... 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. If you look at emails from builds.a.o, a common reason the Maven build for royale-asjs fails these days is due to upload/download issues. 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. Maven's release process seems tuned to releasing a repo or folder. But we release a combination of repos for Ant users and to only have one source artifact to vote on. We don't currently vote on the Maven source artifacts, we only use Maven in the release to generate Maven binaries. 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. One thing you and/or Christofer might want to try is cloning the Jenkins jobs and start with the repos tagged as 0.9.6 and see if any new release process you want to try can in fact build the same binaries as we built in 0.9.6. That's one advantage of reproducible builds. We can completely validate that any changes to the build/release process did not affect the artifacts. As promised above, here are a few things I've thought of related to Maven and Ant and potentially other build tools 1) Number of steps and tools to build from a clean machine In theory, Ant's clean machine steps are (JS-only) a) clone royale-asjs b) run ant all However, I'm not sure that's still true. You might need to skip tests to get around the geckodriver requirement. I think Carlos has some way to clone and build each repo from Maven, but I don't think Maven makes it easy to clone one repo and thus clone the others. That's one thing Ant can get away with because it doesn't have a project==repo/folder model 2) A way to delete EVERYTHING and test from a clean machine In theory, as long as you aren't switching between JS-SWF and JS-Only, Ant users can run wipe-all, wipe, and super-clean in the 3 repos and are back to a clean machine. I'm not sure we've made it as easy to clean out the local Maven repo, so improvements there would be helpful in making sure we don't break building from a clean machine 3) A way to get Adobe and other external stuff With Ant, you can specify which version of the Adobe stuff to get. I'm not sure it is as easy to do that for Maven. 4) Support for new compiler configuration options Maybe we won't be adding new compiler options very often anymore, but this has been a pain point. I think the Ant tasks have support for all new compiler options, but the Maven compiler plugin does not. I was pondering if we needed some sort of build-time test to detect that the Ant and Maven support needs to be updated when a new compiler option is added and make it easier to add support in the Ant tasks and Maven plugin. 5) Changing the build options for a SWC This has been another pain point, IMO. If you add a new SWC or change the build options for a SWC, you have to make two sets of changes, one to the POM.xml and the other to the build.xml/-config.xml. And if we add another build tool, there will be 3 sets of changes. So I was also pondering a tool that would detect that things are out of sync. 6) Testing build changes For me, I have cloned each repo twice so I can have a Maven working copy and an Ant working copy. That way I don't have to kill time cleaning out all of one set of artifacts and running a full build of the other tool. This will also get worse with a third build tool. So separate copies works great for me until I have to push a commit that involves changing both builds. I usually push it, then rush over to the other working copy, pull it down, and fix the other build. I think there is a way in Git to sync across two working copies without pushing. If others want to work this way, we should figure out how to do it and document it. 7) Running Tests In Ant, it is simple enough to just create another Ant target to run integration tests across the 3 repos after all 3 are built. I'm not sure how to do that for Maven, so I think the Maven build isn't running all of the integration tests. 8) Number of Artifacts The Maven build takes much longer than the Ant build because Ant users don't need the Jewel themes packaged into artifacts. They can just point at the .CSS files. So it encourages me to develop in my Ant working copy first. If you've read all of this and have other pain points you can think of, please add them to this list. Maybe it will become more obvious what areas we need to consider, especially to support additional build tools in the future. I'm not sure what best practices are for Maven and combining multiple repos but it feels to me that is one area where our desire to have one combined source artifact makes using Maven more challenging. And the utils profile is another impedance. My 2 cents, -Alex
