Hi Carlos, Which email specify what are you trying to actually do ? - can you share exact link to archive, so you do not have to repeat. How this influences steps on CI server ?
Thanks, Piotr wt., 19 lis 2019 o 16:13 Carlos Rovira <[email protected]> napisał(a): > 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 (<[email protected]>) > 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" <[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 > > > > > > > > -- > Carlos Rovira > http://about.me/carlosrovira > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
