Hi, I'm thinking that we're investing many time in emailing what was not our purpose. I'm planing with Chris to work on his fork and continue from there to address the CI problems, if you're ok with that. Always based on a plan shared here, so in doing that and working as expected, we all we have the evidence that all build and release as expected.
I was planing as well to revert PRs, but Chris told me that will be a problem on his side to track the right state. So seems we just need to recover JGIT. Should that be sufficient? If not let me know if you consider other thing we need to restore. Lest's first concrete what we need to return to a safe state and then will share the plan to do in the fork ok? Thanks El lun., 18 nov. 2019 a las 19:47, Alex Harui (<aha...@adobe.com.invalid>) escribió: > 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" <carlosrov...@apache.org> 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 > > > -- Carlos Rovira http://about.me/carlosrovira
