You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Carlos Rovira <ca...@apache.org> on 2019/11/15 12:45:33 UTC
Apache Royale Maven improvements, fixes and reproducible builds PR by
Chris Dutz
Hi,
this days Chris Dutz has had the deference and detail of working on
improving Apache Royale Maven build by simplifying the scripts so we all
have less headaches with all this stuff that he knows and master so well.
I want to give a big thanks to Chris for investing his time in working on
this huge improvement that for sure will help all us when building royale
in the daily basis and as well when having to make a new release.
So Chris created 3 PRs that are for each repo to test.
I already tested it and simplify all greatly.
Here the recipe for building everything including tests and UI tests and so
on:
#!/bin/bash
*export* FLASHPLAYER_DEBUGGER="/Users/christofer.dutz/Devtools/Adobe/Flash/FlashPlayer-32.0/Flash
Player.app/Contents/MacOS/Flash Player Debugger"
*cd* royale-compiler
./mvnw install -s settings-template.xml
*cd* ../royale-typedefs
./mvnw install -s settings-template.xml
*cd* ../royale-asjs
./mvnw install -s settings-template.xml -P
with-examples,with-distribution,with-ui-testsuite,option-with-swf
-Dwebdriver.gecko.driver=/Users/christofer.dutz/Downloads/geckodriver
*cd* ..
you can use mvn or mvnw that will install Maven if you don't have any
installed :)
You probably need to adjust the paths to the FLASHPLAYER_DEBUGGER as well
as for the geckodriver
(If you don’t want to execute the Selenium UI tests in Firefox, just omit
the “with-ui-testsuite” profile)
(Noting that I should add a Firefox detection to my prerequisite check)
You should not need to have FLASHPLAYERGLOBAL_HOME and
FLASHPLAYERGLOBAL_VERSION
The profiles:
- *with-examples*: Well it builds the examples too
- *with-distribution*: It lets the build also build the distribution
(this part is still incomplete, since like today, it does not generate a
valid SDK, but I'll work on this with Chris this next week).
- *option-with-swf*: It also makes each module build the swf version
- *with-ui-testsuite*: It also builds the testsuite modules and runs the
integration-tests
This PRs also introduces many fixes like a SASS new version that handles
memory better (that was causing all process to hang when launching all in
one single instruction due to memory leaks). Please revise the PRs to read
about all the list of improvements in this update.
So If nobody opposite, I'd like to merge this improvement in the next hours.
Thanks! :)
--
Carlos Rovira
http://about.me/carlosrovira
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Carlos Rovira <ca...@apache.org>.
Piotr,
I think I can comment more on that: There is a “mvn release:branch” goal
that takes care of the branching and updating of the versions automatically.
When executing this, it creates a branch from the current version and then
updates develop to the next development version.
Usually you only need so send the vote email… but usually that’s a mail the
RM writes manually, but we can automate.
Staging the Maven artifacts is a completely automated process … the source
bundles have to be staged in SVN manually, but that’s also something
usually the RM does.
One thing Chris commented me is that release build doesn’t do, is update
the version of the Ant build. It seems as if the build.properties needs to
be updated. While it is possible to build something that does this, perhaps
it would be better to use Ant to extract the version from the pom.xml:
https://stackoverflow.com/questions/47274747/ant-xpath-support
Here we could use the xmltask to extract the version from the root poms.
Then no manual update will be required and also you could build without
requiring Maven.
HTH
Carlos
El dom., 17 nov. 2019 a las 18:49, Carlos Rovira (<ca...@apache.org>)
escribió:
> Hi Piotr,
>
> we can plug into the release process whatever we want. I think we need to
> ensure main process is right, and then other things can be plugged in. I
> think tags are habitual part of a release and then emails can be done too.
>
> El dom., 17 nov. 2019 a las 16:23, Piotr Zarzycki (<
> piotrzarzycki21@gmail.com>) escribió:
>
>> Carlos,
>>
>> Release steps provides also couple of more very useful stuff. Like
>> creating
>> branches on git, sending emails. - I hope your plan is to preserve all of
>> that.
>>
>> niedz., 17 lis 2019 o 16:16 Carlos Rovira <ca...@apache.org>
>> napisał(a):
>>
>> > Thanks Piotr,
>> >
>> > first I want to wait for Alex response. If he agree that releasing with
>> > Maven is all we need, then I think the process is just focus on complete
>> > maven distribution and then I'll do a 0.9.7 release to prove all is ok
>> and
>> > we are in the good track.
>> >
>> > Crossing fingers, since that would mean we get streamlined the process
>> with
>> > all the benefits that will mean for all of us and our users :)
>> >
>> > Thanks
>> >
>> > El dom., 17 nov. 2019 a las 16:03, Piotr Zarzycki (<
>> > piotrzarzycki21@gmail.com>) escribió:
>> >
>> > > Cool. Good luck! - I look forward to that option working as in Ant.
>> > >
>> > > Try release process first before you will be too far and we end up
>> again
>> > > with inability to release sdk for half a year.
>> > >
>> > > niedz., 17 lis 2019 o 15:58 Carlos Rovira <ca...@apache.org>
>> > > napisał(a):
>> > >
>> > > > Hi Piotr,
>> > > >
>> > > > in the first email of this thread I exposed that "with-distribution"
>> > > > profile was the only thing still not completed (is doing the exact
>> same
>> > > > process as pre changes), but this coming week is one of the thing
>> in my
>> > > > priority since with that complete we will finish maven completely.
>> > > >
>> > > > So yes, still we can't build SDK with maven but hope to solve this
>> in
>> > > > around a week with Chris help.
>> > > >
>> > > > Thanks
>> > > >
>> > > >
>> > > > El dom., 17 nov. 2019 a las 15:32, Piotr Zarzycki (<
>> > > > piotrzarzycki21@gmail.com>) escribió:
>> > > >
>> > > > > Hi Carlos,
>> > > > >
>> > > > > Comments inline.
>> > > > >
>> > > > > niedz., 17 lis 2019 o 12:43 Carlos Rovira <
>> carlosrovira@apache.org>
>> > > > > napisał(a):
>> > > > >
>> > > > > > Hi Alex,
>> > > > > >
>> > > > > > first of all I understand completely your concerns about this
>> > changes
>> > > > > since
>> > > > > > I now the time and work it cost to you. At the time you worked
>> on
>> > > this
>> > > > > > there was not all this new maven enhancements that allow us to
>> > > simplify
>> > > > > > things. I strongly believe that all this changes can carry us a
>> > less
>> > > > > > painful build and release process if we (mostly I, supported by
>> > > Chris)
>> > > > > can
>> > > > > > overcome the CI changes to work with the new changes. All this
>> will
>> > > > ease
>> > > > > > things for people coming that should be other priority for us. I
>> > > think
>> > > > > this
>> > > > > > is the main barrier for newcomers and making thing ultra easy
>> can
>> > > allow
>> > > > > > more people coming to Royale. This is all a bet, that we think
>> can
>> > > > reach
>> > > > > a
>> > > > > > good point. We we need to solve things in chunks if we want to
>> > > succeed.
>> > > > > >
>> > > > > > But, I want to state clearly here, that if you finally don't
>> see a
>> > > good
>> > > > > end
>> > > > > > for this, you can veto this change and we can roll back to the
>> > > previous
>> > > > > > process. I think we can reach to simplify all and make releases
>> > more
>> > > > easy
>> > > > > > to do, but it will imply in some parts changes that we need to
>> > agree
>> > > > that
>> > > > > > can be done. For all this we need to try to be open mind.
>> > > > > >
>> > > > > > So instead of trying to expose ways to solve concrete parts
>> already
>> > > > > > exposed, I want to ask about how we can simplify the release
>> > process:
>> > > > > >
>> > > > > > We have Maven and ANT as first citizens for build process, so
>> users
>> > > can
>> > > > > use
>> > > > > > what they want. But my question here's, do we need to use both
>> in
>> > the
>> > > > > > release process? From what I understand Apache only requires us
>> to
>> > > use
>> > > > > one
>> > > > > > of them for releasing process. So we could just rely on the
>> maven
>> > > > process
>> > > > > > that are just few lines (already posted early in this thread).
>> Copy
>> > > > here
>> > > > > to
>> > > > > > notice the simplicity:
>> > > > > >
>> > > > > > Ideally releasing a part of Royale is just a 2-3 step process:
>> > > > > >
>> > > > > > - royale-compiler:
>> > > > > > - mvn release:prepare -DautoversionSubmodules=true
>> > > > > > - mvn release:perform
>> > > > > > - royale-typedefs:
>> > > > > > - update the pom.xml: royale.compiler.version to the new
>> > > released
>> > > > > > version
>> > > > > > - mvn release:prepare -DautoversionSubmodules=true
>> > > > > > - mvn release:perform
>> > > > > > - royale-asjs:
>> > > > > > - update the pom.xml: royale.compiler.version and
>> > > > > > royale.typedefs.version to the new released version
>> > > > > > - mvn release:prepare -DautoversionSubmodules=true
>> > > > > > - mvn release:perform
>> > > > > >
>> > > > > >
>> > > > > > In doing in this way, we'll streamline the release process and
>> will
>> > > not
>> > > > > > need to do anything more. Just that few lines. And that means
>> > > hopefully
>> > > > > > make our release process a more tiny process in time to all of
>> us,
>> > > > while
>> > > > > > users that wants to build with ANT can do it without problem.
>> Can
>> > we
>> > > > > agree
>> > > > > > with this? Let me know if I'm wrong with this. Notice that my
>> focus
>> > > is
>> > > > to
>> > > > > > try to get to the easiest way possible to build and release we
>> can
>> > > get.
>> > > > > >
>> > > > > >
>> > > > > Does this few lines build IDE artifacts ?
>> > > > >
>> > > > >
>> > > > > > To not create a very long thread. I'll left this here so we can
>> see
>> > > > what
>> > > > > > you guys think about it.
>> > > > > >
>> > > > > > Thanks in advance
>> > > > > >
>> > > > > > Carlos
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > El dom., 17 nov. 2019 a las 0:06, Alex Harui
>> > > (<aharui@adobe.com.invalid
>> > > > > >)
>> > > > > > escribió:
>> > > > > >
>> > > > > > > I'm pretty sure I added JGIT in order to do the release on
>> the CI
>> > > > > server.
>> > > > > > > See change 1aa2b16 in royale-compiler on Feb 11, 2019. The
>> > reason
>> > > > the
>> > > > > CI
>> > > > > > > needs JGIT is because the regular Maven git support seemed to
>> > > expect
>> > > > > that
>> > > > > > > you had a private key registered since most folks run the
>> release
>> > > > > plugin
>> > > > > > on
>> > > > > > > their private computer. JGIT allowed specification of
>> username
>> > > > without
>> > > > > > > password for commits.
>> > > > > > >
>> > > > > > > The Royale compiler is also required to parse the time stamps
>> in
>> > > > order
>> > > > > to
>> > > > > > > inject them into the SWFs and SWCs. So I am hopeful that
>> didn't
>> > > > break,
>> > > > > > but
>> > > > > > > if it did, you know where to look. Also the release steps on
>> CI
>> > > > expect
>> > > > > > the
>> > > > > > > timestamp to be given by the RM so it can be used in Ant as
>> well.
>> > > > So I
>> > > > > > am
>> > > > > > > concerned about that as well. But maybe it will work or you
>> will
>> > > fix
>> > > > > it.
>> > > > > > > I don't care as long as it doesn't cost me time. But as RM
>> you
>> > are
>> > > > > > > responsible for the Ant artifacts as well. The timestamp must
>> > also
>> > > > be
>> > > > > > > handed to the voters as well in order for them to reproduce
>> the
>> > > same
>> > > > > > > binaries.
>> > > > > > >
>> > > > > > > My experience was that zlika was very responsive to fixing an
>> > > issue.
>> > > > > I'm
>> > > > > > > not sure if Maven has picked up all of the zlika changes, but
>> if
>> > > not,
>> > > > > > then
>> > > > > > > one of the artifacts will not reproduce. When I offered a
>> patch
>> > to
>> > > > > > Maven,
>> > > > > > > I was told I had to go figure out their test harnesses and
>> build
>> > a
>> > > > set
>> > > > > of
>> > > > > > > test cases, which I still haven't found time to do. Again,
>> if it
>> > > all
>> > > > > > ends
>> > > > > > > up working and doesn't cost me time, it doesn't matter which
>> > plugin
>> > > > we
>> > > > > > use.
>> > > > > > >
>> > > > > > > My 2 cents,
>> > > > > > > -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>*
>> > >
>> >
>> >
>> > --
>> > 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
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Carlos Rovira <ca...@apache.org>.
Hi Piotr,
we can plug into the release process whatever we want. I think we need to
ensure main process is right, and then other things can be plugged in. I
think tags are habitual part of a release and then emails can be done too.
El dom., 17 nov. 2019 a las 16:23, Piotr Zarzycki (<
piotrzarzycki21@gmail.com>) escribió:
> Carlos,
>
> Release steps provides also couple of more very useful stuff. Like creating
> branches on git, sending emails. - I hope your plan is to preserve all of
> that.
>
> niedz., 17 lis 2019 o 16:16 Carlos Rovira <ca...@apache.org>
> napisał(a):
>
> > Thanks Piotr,
> >
> > first I want to wait for Alex response. If he agree that releasing with
> > Maven is all we need, then I think the process is just focus on complete
> > maven distribution and then I'll do a 0.9.7 release to prove all is ok
> and
> > we are in the good track.
> >
> > Crossing fingers, since that would mean we get streamlined the process
> with
> > all the benefits that will mean for all of us and our users :)
> >
> > Thanks
> >
> > El dom., 17 nov. 2019 a las 16:03, Piotr Zarzycki (<
> > piotrzarzycki21@gmail.com>) escribió:
> >
> > > Cool. Good luck! - I look forward to that option working as in Ant.
> > >
> > > Try release process first before you will be too far and we end up
> again
> > > with inability to release sdk for half a year.
> > >
> > > niedz., 17 lis 2019 o 15:58 Carlos Rovira <ca...@apache.org>
> > > napisał(a):
> > >
> > > > Hi Piotr,
> > > >
> > > > in the first email of this thread I exposed that "with-distribution"
> > > > profile was the only thing still not completed (is doing the exact
> same
> > > > process as pre changes), but this coming week is one of the thing in
> my
> > > > priority since with that complete we will finish maven completely.
> > > >
> > > > So yes, still we can't build SDK with maven but hope to solve this in
> > > > around a week with Chris help.
> > > >
> > > > Thanks
> > > >
> > > >
> > > > El dom., 17 nov. 2019 a las 15:32, Piotr Zarzycki (<
> > > > piotrzarzycki21@gmail.com>) escribió:
> > > >
> > > > > Hi Carlos,
> > > > >
> > > > > Comments inline.
> > > > >
> > > > > niedz., 17 lis 2019 o 12:43 Carlos Rovira <carlosrovira@apache.org
> >
> > > > > napisał(a):
> > > > >
> > > > > > Hi Alex,
> > > > > >
> > > > > > first of all I understand completely your concerns about this
> > changes
> > > > > since
> > > > > > I now the time and work it cost to you. At the time you worked on
> > > this
> > > > > > there was not all this new maven enhancements that allow us to
> > > simplify
> > > > > > things. I strongly believe that all this changes can carry us a
> > less
> > > > > > painful build and release process if we (mostly I, supported by
> > > Chris)
> > > > > can
> > > > > > overcome the CI changes to work with the new changes. All this
> will
> > > > ease
> > > > > > things for people coming that should be other priority for us. I
> > > think
> > > > > this
> > > > > > is the main barrier for newcomers and making thing ultra easy can
> > > allow
> > > > > > more people coming to Royale. This is all a bet, that we think
> can
> > > > reach
> > > > > a
> > > > > > good point. We we need to solve things in chunks if we want to
> > > succeed.
> > > > > >
> > > > > > But, I want to state clearly here, that if you finally don't see
> a
> > > good
> > > > > end
> > > > > > for this, you can veto this change and we can roll back to the
> > > previous
> > > > > > process. I think we can reach to simplify all and make releases
> > more
> > > > easy
> > > > > > to do, but it will imply in some parts changes that we need to
> > agree
> > > > that
> > > > > > can be done. For all this we need to try to be open mind.
> > > > > >
> > > > > > So instead of trying to expose ways to solve concrete parts
> already
> > > > > > exposed, I want to ask about how we can simplify the release
> > process:
> > > > > >
> > > > > > We have Maven and ANT as first citizens for build process, so
> users
> > > can
> > > > > use
> > > > > > what they want. But my question here's, do we need to use both in
> > the
> > > > > > release process? From what I understand Apache only requires us
> to
> > > use
> > > > > one
> > > > > > of them for releasing process. So we could just rely on the maven
> > > > process
> > > > > > that are just few lines (already posted early in this thread).
> Copy
> > > > here
> > > > > to
> > > > > > notice the simplicity:
> > > > > >
> > > > > > Ideally releasing a part of Royale is just a 2-3 step process:
> > > > > >
> > > > > > - royale-compiler:
> > > > > > - mvn release:prepare -DautoversionSubmodules=true
> > > > > > - mvn release:perform
> > > > > > - royale-typedefs:
> > > > > > - update the pom.xml: royale.compiler.version to the new
> > > released
> > > > > > version
> > > > > > - mvn release:prepare -DautoversionSubmodules=true
> > > > > > - mvn release:perform
> > > > > > - royale-asjs:
> > > > > > - update the pom.xml: royale.compiler.version and
> > > > > > royale.typedefs.version to the new released version
> > > > > > - mvn release:prepare -DautoversionSubmodules=true
> > > > > > - mvn release:perform
> > > > > >
> > > > > >
> > > > > > In doing in this way, we'll streamline the release process and
> will
> > > not
> > > > > > need to do anything more. Just that few lines. And that means
> > > hopefully
> > > > > > make our release process a more tiny process in time to all of
> us,
> > > > while
> > > > > > users that wants to build with ANT can do it without problem. Can
> > we
> > > > > agree
> > > > > > with this? Let me know if I'm wrong with this. Notice that my
> focus
> > > is
> > > > to
> > > > > > try to get to the easiest way possible to build and release we
> can
> > > get.
> > > > > >
> > > > > >
> > > > > Does this few lines build IDE artifacts ?
> > > > >
> > > > >
> > > > > > To not create a very long thread. I'll left this here so we can
> see
> > > > what
> > > > > > you guys think about it.
> > > > > >
> > > > > > Thanks in advance
> > > > > >
> > > > > > Carlos
> > > > > >
> > > > > >
> > > > > >
> > > > > > El dom., 17 nov. 2019 a las 0:06, Alex Harui
> > > (<aharui@adobe.com.invalid
> > > > > >)
> > > > > > escribió:
> > > > > >
> > > > > > > I'm pretty sure I added JGIT in order to do the release on the
> CI
> > > > > server.
> > > > > > > See change 1aa2b16 in royale-compiler on Feb 11, 2019. The
> > reason
> > > > the
> > > > > CI
> > > > > > > needs JGIT is because the regular Maven git support seemed to
> > > expect
> > > > > that
> > > > > > > you had a private key registered since most folks run the
> release
> > > > > plugin
> > > > > > on
> > > > > > > their private computer. JGIT allowed specification of username
> > > > without
> > > > > > > password for commits.
> > > > > > >
> > > > > > > The Royale compiler is also required to parse the time stamps
> in
> > > > order
> > > > > to
> > > > > > > inject them into the SWFs and SWCs. So I am hopeful that
> didn't
> > > > break,
> > > > > > but
> > > > > > > if it did, you know where to look. Also the release steps on
> CI
> > > > expect
> > > > > > the
> > > > > > > timestamp to be given by the RM so it can be used in Ant as
> well.
> > > > So I
> > > > > > am
> > > > > > > concerned about that as well. But maybe it will work or you
> will
> > > fix
> > > > > it.
> > > > > > > I don't care as long as it doesn't cost me time. But as RM you
> > are
> > > > > > > responsible for the Ant artifacts as well. The timestamp must
> > also
> > > > be
> > > > > > > handed to the voters as well in order for them to reproduce the
> > > same
> > > > > > > binaries.
> > > > > > >
> > > > > > > My experience was that zlika was very responsive to fixing an
> > > issue.
> > > > > I'm
> > > > > > > not sure if Maven has picked up all of the zlika changes, but
> if
> > > not,
> > > > > > then
> > > > > > > one of the artifacts will not reproduce. When I offered a
> patch
> > to
> > > > > > Maven,
> > > > > > > I was told I had to go figure out their test harnesses and
> build
> > a
> > > > set
> > > > > of
> > > > > > > test cases, which I still haven't found time to do. Again, if
> it
> > > all
> > > > > > ends
> > > > > > > up working and doesn't cost me time, it doesn't matter which
> > plugin
> > > > we
> > > > > > use.
> > > > > > >
> > > > > > > My 2 cents,
> > > > > > > -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>*
> > >
> >
> >
> > --
> > 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
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Piotr Zarzycki <pi...@gmail.com>.
Carlos,
Release steps provides also couple of more very useful stuff. Like creating
branches on git, sending emails. - I hope your plan is to preserve all of
that.
niedz., 17 lis 2019 o 16:16 Carlos Rovira <ca...@apache.org>
napisał(a):
> Thanks Piotr,
>
> first I want to wait for Alex response. If he agree that releasing with
> Maven is all we need, then I think the process is just focus on complete
> maven distribution and then I'll do a 0.9.7 release to prove all is ok and
> we are in the good track.
>
> Crossing fingers, since that would mean we get streamlined the process with
> all the benefits that will mean for all of us and our users :)
>
> Thanks
>
> El dom., 17 nov. 2019 a las 16:03, Piotr Zarzycki (<
> piotrzarzycki21@gmail.com>) escribió:
>
> > Cool. Good luck! - I look forward to that option working as in Ant.
> >
> > Try release process first before you will be too far and we end up again
> > with inability to release sdk for half a year.
> >
> > niedz., 17 lis 2019 o 15:58 Carlos Rovira <ca...@apache.org>
> > napisał(a):
> >
> > > Hi Piotr,
> > >
> > > in the first email of this thread I exposed that "with-distribution"
> > > profile was the only thing still not completed (is doing the exact same
> > > process as pre changes), but this coming week is one of the thing in my
> > > priority since with that complete we will finish maven completely.
> > >
> > > So yes, still we can't build SDK with maven but hope to solve this in
> > > around a week with Chris help.
> > >
> > > Thanks
> > >
> > >
> > > El dom., 17 nov. 2019 a las 15:32, Piotr Zarzycki (<
> > > piotrzarzycki21@gmail.com>) escribió:
> > >
> > > > Hi Carlos,
> > > >
> > > > Comments inline.
> > > >
> > > > niedz., 17 lis 2019 o 12:43 Carlos Rovira <ca...@apache.org>
> > > > napisał(a):
> > > >
> > > > > Hi Alex,
> > > > >
> > > > > first of all I understand completely your concerns about this
> changes
> > > > since
> > > > > I now the time and work it cost to you. At the time you worked on
> > this
> > > > > there was not all this new maven enhancements that allow us to
> > simplify
> > > > > things. I strongly believe that all this changes can carry us a
> less
> > > > > painful build and release process if we (mostly I, supported by
> > Chris)
> > > > can
> > > > > overcome the CI changes to work with the new changes. All this will
> > > ease
> > > > > things for people coming that should be other priority for us. I
> > think
> > > > this
> > > > > is the main barrier for newcomers and making thing ultra easy can
> > allow
> > > > > more people coming to Royale. This is all a bet, that we think can
> > > reach
> > > > a
> > > > > good point. We we need to solve things in chunks if we want to
> > succeed.
> > > > >
> > > > > But, I want to state clearly here, that if you finally don't see a
> > good
> > > > end
> > > > > for this, you can veto this change and we can roll back to the
> > previous
> > > > > process. I think we can reach to simplify all and make releases
> more
> > > easy
> > > > > to do, but it will imply in some parts changes that we need to
> agree
> > > that
> > > > > can be done. For all this we need to try to be open mind.
> > > > >
> > > > > So instead of trying to expose ways to solve concrete parts already
> > > > > exposed, I want to ask about how we can simplify the release
> process:
> > > > >
> > > > > We have Maven and ANT as first citizens for build process, so users
> > can
> > > > use
> > > > > what they want. But my question here's, do we need to use both in
> the
> > > > > release process? From what I understand Apache only requires us to
> > use
> > > > one
> > > > > of them for releasing process. So we could just rely on the maven
> > > process
> > > > > that are just few lines (already posted early in this thread). Copy
> > > here
> > > > to
> > > > > notice the simplicity:
> > > > >
> > > > > Ideally releasing a part of Royale is just a 2-3 step process:
> > > > >
> > > > > - royale-compiler:
> > > > > - mvn release:prepare -DautoversionSubmodules=true
> > > > > - mvn release:perform
> > > > > - royale-typedefs:
> > > > > - update the pom.xml: royale.compiler.version to the new
> > released
> > > > > version
> > > > > - mvn release:prepare -DautoversionSubmodules=true
> > > > > - mvn release:perform
> > > > > - royale-asjs:
> > > > > - update the pom.xml: royale.compiler.version and
> > > > > royale.typedefs.version to the new released version
> > > > > - mvn release:prepare -DautoversionSubmodules=true
> > > > > - mvn release:perform
> > > > >
> > > > >
> > > > > In doing in this way, we'll streamline the release process and will
> > not
> > > > > need to do anything more. Just that few lines. And that means
> > hopefully
> > > > > make our release process a more tiny process in time to all of us,
> > > while
> > > > > users that wants to build with ANT can do it without problem. Can
> we
> > > > agree
> > > > > with this? Let me know if I'm wrong with this. Notice that my focus
> > is
> > > to
> > > > > try to get to the easiest way possible to build and release we can
> > get.
> > > > >
> > > > >
> > > > Does this few lines build IDE artifacts ?
> > > >
> > > >
> > > > > To not create a very long thread. I'll left this here so we can see
> > > what
> > > > > you guys think about it.
> > > > >
> > > > > Thanks in advance
> > > > >
> > > > > Carlos
> > > > >
> > > > >
> > > > >
> > > > > El dom., 17 nov. 2019 a las 0:06, Alex Harui
> > (<aharui@adobe.com.invalid
> > > > >)
> > > > > escribió:
> > > > >
> > > > > > I'm pretty sure I added JGIT in order to do the release on the CI
> > > > server.
> > > > > > See change 1aa2b16 in royale-compiler on Feb 11, 2019. The
> reason
> > > the
> > > > CI
> > > > > > needs JGIT is because the regular Maven git support seemed to
> > expect
> > > > that
> > > > > > you had a private key registered since most folks run the release
> > > > plugin
> > > > > on
> > > > > > their private computer. JGIT allowed specification of username
> > > without
> > > > > > password for commits.
> > > > > >
> > > > > > The Royale compiler is also required to parse the time stamps in
> > > order
> > > > to
> > > > > > inject them into the SWFs and SWCs. So I am hopeful that didn't
> > > break,
> > > > > but
> > > > > > if it did, you know where to look. Also the release steps on CI
> > > expect
> > > > > the
> > > > > > timestamp to be given by the RM so it can be used in Ant as well.
> > > So I
> > > > > am
> > > > > > concerned about that as well. But maybe it will work or you will
> > fix
> > > > it.
> > > > > > I don't care as long as it doesn't cost me time. But as RM you
> are
> > > > > > responsible for the Ant artifacts as well. The timestamp must
> also
> > > be
> > > > > > handed to the voters as well in order for them to reproduce the
> > same
> > > > > > binaries.
> > > > > >
> > > > > > My experience was that zlika was very responsive to fixing an
> > issue.
> > > > I'm
> > > > > > not sure if Maven has picked up all of the zlika changes, but if
> > not,
> > > > > then
> > > > > > one of the artifacts will not reproduce. When I offered a patch
> to
> > > > > Maven,
> > > > > > I was told I had to go figure out their test harnesses and build
> a
> > > set
> > > > of
> > > > > > test cases, which I still haven't found time to do. Again, if it
> > all
> > > > > ends
> > > > > > up working and doesn't cost me time, it doesn't matter which
> plugin
> > > we
> > > > > use.
> > > > > >
> > > > > > My 2 cents,
> > > > > > -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>*
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Carlos Rovira <ca...@apache.org>.
Thanks Piotr,
first I want to wait for Alex response. If he agree that releasing with
Maven is all we need, then I think the process is just focus on complete
maven distribution and then I'll do a 0.9.7 release to prove all is ok and
we are in the good track.
Crossing fingers, since that would mean we get streamlined the process with
all the benefits that will mean for all of us and our users :)
Thanks
El dom., 17 nov. 2019 a las 16:03, Piotr Zarzycki (<
piotrzarzycki21@gmail.com>) escribió:
> Cool. Good luck! - I look forward to that option working as in Ant.
>
> Try release process first before you will be too far and we end up again
> with inability to release sdk for half a year.
>
> niedz., 17 lis 2019 o 15:58 Carlos Rovira <ca...@apache.org>
> napisał(a):
>
> > Hi Piotr,
> >
> > in the first email of this thread I exposed that "with-distribution"
> > profile was the only thing still not completed (is doing the exact same
> > process as pre changes), but this coming week is one of the thing in my
> > priority since with that complete we will finish maven completely.
> >
> > So yes, still we can't build SDK with maven but hope to solve this in
> > around a week with Chris help.
> >
> > Thanks
> >
> >
> > El dom., 17 nov. 2019 a las 15:32, Piotr Zarzycki (<
> > piotrzarzycki21@gmail.com>) escribió:
> >
> > > Hi Carlos,
> > >
> > > Comments inline.
> > >
> > > niedz., 17 lis 2019 o 12:43 Carlos Rovira <ca...@apache.org>
> > > napisał(a):
> > >
> > > > Hi Alex,
> > > >
> > > > first of all I understand completely your concerns about this changes
> > > since
> > > > I now the time and work it cost to you. At the time you worked on
> this
> > > > there was not all this new maven enhancements that allow us to
> simplify
> > > > things. I strongly believe that all this changes can carry us a less
> > > > painful build and release process if we (mostly I, supported by
> Chris)
> > > can
> > > > overcome the CI changes to work with the new changes. All this will
> > ease
> > > > things for people coming that should be other priority for us. I
> think
> > > this
> > > > is the main barrier for newcomers and making thing ultra easy can
> allow
> > > > more people coming to Royale. This is all a bet, that we think can
> > reach
> > > a
> > > > good point. We we need to solve things in chunks if we want to
> succeed.
> > > >
> > > > But, I want to state clearly here, that if you finally don't see a
> good
> > > end
> > > > for this, you can veto this change and we can roll back to the
> previous
> > > > process. I think we can reach to simplify all and make releases more
> > easy
> > > > to do, but it will imply in some parts changes that we need to agree
> > that
> > > > can be done. For all this we need to try to be open mind.
> > > >
> > > > So instead of trying to expose ways to solve concrete parts already
> > > > exposed, I want to ask about how we can simplify the release process:
> > > >
> > > > We have Maven and ANT as first citizens for build process, so users
> can
> > > use
> > > > what they want. But my question here's, do we need to use both in the
> > > > release process? From what I understand Apache only requires us to
> use
> > > one
> > > > of them for releasing process. So we could just rely on the maven
> > process
> > > > that are just few lines (already posted early in this thread). Copy
> > here
> > > to
> > > > notice the simplicity:
> > > >
> > > > Ideally releasing a part of Royale is just a 2-3 step process:
> > > >
> > > > - royale-compiler:
> > > > - mvn release:prepare -DautoversionSubmodules=true
> > > > - mvn release:perform
> > > > - royale-typedefs:
> > > > - update the pom.xml: royale.compiler.version to the new
> released
> > > > version
> > > > - mvn release:prepare -DautoversionSubmodules=true
> > > > - mvn release:perform
> > > > - royale-asjs:
> > > > - update the pom.xml: royale.compiler.version and
> > > > royale.typedefs.version to the new released version
> > > > - mvn release:prepare -DautoversionSubmodules=true
> > > > - mvn release:perform
> > > >
> > > >
> > > > In doing in this way, we'll streamline the release process and will
> not
> > > > need to do anything more. Just that few lines. And that means
> hopefully
> > > > make our release process a more tiny process in time to all of us,
> > while
> > > > users that wants to build with ANT can do it without problem. Can we
> > > agree
> > > > with this? Let me know if I'm wrong with this. Notice that my focus
> is
> > to
> > > > try to get to the easiest way possible to build and release we can
> get.
> > > >
> > > >
> > > Does this few lines build IDE artifacts ?
> > >
> > >
> > > > To not create a very long thread. I'll left this here so we can see
> > what
> > > > you guys think about it.
> > > >
> > > > Thanks in advance
> > > >
> > > > Carlos
> > > >
> > > >
> > > >
> > > > El dom., 17 nov. 2019 a las 0:06, Alex Harui
> (<aharui@adobe.com.invalid
> > > >)
> > > > escribió:
> > > >
> > > > > I'm pretty sure I added JGIT in order to do the release on the CI
> > > server.
> > > > > See change 1aa2b16 in royale-compiler on Feb 11, 2019. The reason
> > the
> > > CI
> > > > > needs JGIT is because the regular Maven git support seemed to
> expect
> > > that
> > > > > you had a private key registered since most folks run the release
> > > plugin
> > > > on
> > > > > their private computer. JGIT allowed specification of username
> > without
> > > > > password for commits.
> > > > >
> > > > > The Royale compiler is also required to parse the time stamps in
> > order
> > > to
> > > > > inject them into the SWFs and SWCs. So I am hopeful that didn't
> > break,
> > > > but
> > > > > if it did, you know where to look. Also the release steps on CI
> > expect
> > > > the
> > > > > timestamp to be given by the RM so it can be used in Ant as well.
> > So I
> > > > am
> > > > > concerned about that as well. But maybe it will work or you will
> fix
> > > it.
> > > > > I don't care as long as it doesn't cost me time. But as RM you are
> > > > > responsible for the Ant artifacts as well. The timestamp must also
> > be
> > > > > handed to the voters as well in order for them to reproduce the
> same
> > > > > binaries.
> > > > >
> > > > > My experience was that zlika was very responsive to fixing an
> issue.
> > > I'm
> > > > > not sure if Maven has picked up all of the zlika changes, but if
> not,
> > > > then
> > > > > one of the artifacts will not reproduce. When I offered a patch to
> > > > Maven,
> > > > > I was told I had to go figure out their test harnesses and build a
> > set
> > > of
> > > > > test cases, which I still haven't found time to do. Again, if it
> all
> > > > ends
> > > > > up working and doesn't cost me time, it doesn't matter which plugin
> > we
> > > > use.
> > > > >
> > > > > My 2 cents,
> > > > > -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>*
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Piotr Zarzycki <pi...@gmail.com>.
Cool. Good luck! - I look forward to that option working as in Ant.
Try release process first before you will be too far and we end up again
with inability to release sdk for half a year.
niedz., 17 lis 2019 o 15:58 Carlos Rovira <ca...@apache.org>
napisał(a):
> Hi Piotr,
>
> in the first email of this thread I exposed that "with-distribution"
> profile was the only thing still not completed (is doing the exact same
> process as pre changes), but this coming week is one of the thing in my
> priority since with that complete we will finish maven completely.
>
> So yes, still we can't build SDK with maven but hope to solve this in
> around a week with Chris help.
>
> Thanks
>
>
> El dom., 17 nov. 2019 a las 15:32, Piotr Zarzycki (<
> piotrzarzycki21@gmail.com>) escribió:
>
> > Hi Carlos,
> >
> > Comments inline.
> >
> > niedz., 17 lis 2019 o 12:43 Carlos Rovira <ca...@apache.org>
> > napisał(a):
> >
> > > Hi Alex,
> > >
> > > first of all I understand completely your concerns about this changes
> > since
> > > I now the time and work it cost to you. At the time you worked on this
> > > there was not all this new maven enhancements that allow us to simplify
> > > things. I strongly believe that all this changes can carry us a less
> > > painful build and release process if we (mostly I, supported by Chris)
> > can
> > > overcome the CI changes to work with the new changes. All this will
> ease
> > > things for people coming that should be other priority for us. I think
> > this
> > > is the main barrier for newcomers and making thing ultra easy can allow
> > > more people coming to Royale. This is all a bet, that we think can
> reach
> > a
> > > good point. We we need to solve things in chunks if we want to succeed.
> > >
> > > But, I want to state clearly here, that if you finally don't see a good
> > end
> > > for this, you can veto this change and we can roll back to the previous
> > > process. I think we can reach to simplify all and make releases more
> easy
> > > to do, but it will imply in some parts changes that we need to agree
> that
> > > can be done. For all this we need to try to be open mind.
> > >
> > > So instead of trying to expose ways to solve concrete parts already
> > > exposed, I want to ask about how we can simplify the release process:
> > >
> > > We have Maven and ANT as first citizens for build process, so users can
> > use
> > > what they want. But my question here's, do we need to use both in the
> > > release process? From what I understand Apache only requires us to use
> > one
> > > of them for releasing process. So we could just rely on the maven
> process
> > > that are just few lines (already posted early in this thread). Copy
> here
> > to
> > > notice the simplicity:
> > >
> > > Ideally releasing a part of Royale is just a 2-3 step process:
> > >
> > > - royale-compiler:
> > > - mvn release:prepare -DautoversionSubmodules=true
> > > - mvn release:perform
> > > - royale-typedefs:
> > > - update the pom.xml: royale.compiler.version to the new released
> > > version
> > > - mvn release:prepare -DautoversionSubmodules=true
> > > - mvn release:perform
> > > - royale-asjs:
> > > - update the pom.xml: royale.compiler.version and
> > > royale.typedefs.version to the new released version
> > > - mvn release:prepare -DautoversionSubmodules=true
> > > - mvn release:perform
> > >
> > >
> > > In doing in this way, we'll streamline the release process and will not
> > > need to do anything more. Just that few lines. And that means hopefully
> > > make our release process a more tiny process in time to all of us,
> while
> > > users that wants to build with ANT can do it without problem. Can we
> > agree
> > > with this? Let me know if I'm wrong with this. Notice that my focus is
> to
> > > try to get to the easiest way possible to build and release we can get.
> > >
> > >
> > Does this few lines build IDE artifacts ?
> >
> >
> > > To not create a very long thread. I'll left this here so we can see
> what
> > > you guys think about it.
> > >
> > > Thanks in advance
> > >
> > > Carlos
> > >
> > >
> > >
> > > El dom., 17 nov. 2019 a las 0:06, Alex Harui (<aharui@adobe.com.invalid
> > >)
> > > escribió:
> > >
> > > > I'm pretty sure I added JGIT in order to do the release on the CI
> > server.
> > > > See change 1aa2b16 in royale-compiler on Feb 11, 2019. The reason
> the
> > CI
> > > > needs JGIT is because the regular Maven git support seemed to expect
> > that
> > > > you had a private key registered since most folks run the release
> > plugin
> > > on
> > > > their private computer. JGIT allowed specification of username
> without
> > > > password for commits.
> > > >
> > > > The Royale compiler is also required to parse the time stamps in
> order
> > to
> > > > inject them into the SWFs and SWCs. So I am hopeful that didn't
> break,
> > > but
> > > > if it did, you know where to look. Also the release steps on CI
> expect
> > > the
> > > > timestamp to be given by the RM so it can be used in Ant as well.
> So I
> > > am
> > > > concerned about that as well. But maybe it will work or you will fix
> > it.
> > > > I don't care as long as it doesn't cost me time. But as RM you are
> > > > responsible for the Ant artifacts as well. The timestamp must also
> be
> > > > handed to the voters as well in order for them to reproduce the same
> > > > binaries.
> > > >
> > > > My experience was that zlika was very responsive to fixing an issue.
> > I'm
> > > > not sure if Maven has picked up all of the zlika changes, but if not,
> > > then
> > > > one of the artifacts will not reproduce. When I offered a patch to
> > > Maven,
> > > > I was told I had to go figure out their test harnesses and build a
> set
> > of
> > > > test cases, which I still haven't found time to do. Again, if it all
> > > ends
> > > > up working and doesn't cost me time, it doesn't matter which plugin
> we
> > > use.
> > > >
> > > > My 2 cents,
> > > > -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>*
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Carlos Rovira <ca...@apache.org>.
Hi Piotr,
in the first email of this thread I exposed that "with-distribution"
profile was the only thing still not completed (is doing the exact same
process as pre changes), but this coming week is one of the thing in my
priority since with that complete we will finish maven completely.
So yes, still we can't build SDK with maven but hope to solve this in
around a week with Chris help.
Thanks
El dom., 17 nov. 2019 a las 15:32, Piotr Zarzycki (<
piotrzarzycki21@gmail.com>) escribió:
> Hi Carlos,
>
> Comments inline.
>
> niedz., 17 lis 2019 o 12:43 Carlos Rovira <ca...@apache.org>
> napisał(a):
>
> > Hi Alex,
> >
> > first of all I understand completely your concerns about this changes
> since
> > I now the time and work it cost to you. At the time you worked on this
> > there was not all this new maven enhancements that allow us to simplify
> > things. I strongly believe that all this changes can carry us a less
> > painful build and release process if we (mostly I, supported by Chris)
> can
> > overcome the CI changes to work with the new changes. All this will ease
> > things for people coming that should be other priority for us. I think
> this
> > is the main barrier for newcomers and making thing ultra easy can allow
> > more people coming to Royale. This is all a bet, that we think can reach
> a
> > good point. We we need to solve things in chunks if we want to succeed.
> >
> > But, I want to state clearly here, that if you finally don't see a good
> end
> > for this, you can veto this change and we can roll back to the previous
> > process. I think we can reach to simplify all and make releases more easy
> > to do, but it will imply in some parts changes that we need to agree that
> > can be done. For all this we need to try to be open mind.
> >
> > So instead of trying to expose ways to solve concrete parts already
> > exposed, I want to ask about how we can simplify the release process:
> >
> > We have Maven and ANT as first citizens for build process, so users can
> use
> > what they want. But my question here's, do we need to use both in the
> > release process? From what I understand Apache only requires us to use
> one
> > of them for releasing process. So we could just rely on the maven process
> > that are just few lines (already posted early in this thread). Copy here
> to
> > notice the simplicity:
> >
> > Ideally releasing a part of Royale is just a 2-3 step process:
> >
> > - royale-compiler:
> > - mvn release:prepare -DautoversionSubmodules=true
> > - mvn release:perform
> > - royale-typedefs:
> > - update the pom.xml: royale.compiler.version to the new released
> > version
> > - mvn release:prepare -DautoversionSubmodules=true
> > - mvn release:perform
> > - royale-asjs:
> > - update the pom.xml: royale.compiler.version and
> > royale.typedefs.version to the new released version
> > - mvn release:prepare -DautoversionSubmodules=true
> > - mvn release:perform
> >
> >
> > In doing in this way, we'll streamline the release process and will not
> > need to do anything more. Just that few lines. And that means hopefully
> > make our release process a more tiny process in time to all of us, while
> > users that wants to build with ANT can do it without problem. Can we
> agree
> > with this? Let me know if I'm wrong with this. Notice that my focus is to
> > try to get to the easiest way possible to build and release we can get.
> >
> >
> Does this few lines build IDE artifacts ?
>
>
> > To not create a very long thread. I'll left this here so we can see what
> > you guys think about it.
> >
> > Thanks in advance
> >
> > Carlos
> >
> >
> >
> > El dom., 17 nov. 2019 a las 0:06, Alex Harui (<aharui@adobe.com.invalid
> >)
> > escribió:
> >
> > > I'm pretty sure I added JGIT in order to do the release on the CI
> server.
> > > See change 1aa2b16 in royale-compiler on Feb 11, 2019. The reason the
> CI
> > > needs JGIT is because the regular Maven git support seemed to expect
> that
> > > you had a private key registered since most folks run the release
> plugin
> > on
> > > their private computer. JGIT allowed specification of username without
> > > password for commits.
> > >
> > > The Royale compiler is also required to parse the time stamps in order
> to
> > > inject them into the SWFs and SWCs. So I am hopeful that didn't break,
> > but
> > > if it did, you know where to look. Also the release steps on CI expect
> > the
> > > timestamp to be given by the RM so it can be used in Ant as well. So I
> > am
> > > concerned about that as well. But maybe it will work or you will fix
> it.
> > > I don't care as long as it doesn't cost me time. But as RM you are
> > > responsible for the Ant artifacts as well. The timestamp must also be
> > > handed to the voters as well in order for them to reproduce the same
> > > binaries.
> > >
> > > My experience was that zlika was very responsive to fixing an issue.
> I'm
> > > not sure if Maven has picked up all of the zlika changes, but if not,
> > then
> > > one of the artifacts will not reproduce. When I offered a patch to
> > Maven,
> > > I was told I had to go figure out their test harnesses and build a set
> of
> > > test cases, which I still haven't found time to do. Again, if it all
> > ends
> > > up working and doesn't cost me time, it doesn't matter which plugin we
> > use.
> > >
> > > My 2 cents,
> > > -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
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Piotr Zarzycki <pi...@gmail.com>.
Hi Carlos,
Comments inline.
niedz., 17 lis 2019 o 12:43 Carlos Rovira <ca...@apache.org>
napisał(a):
> Hi Alex,
>
> first of all I understand completely your concerns about this changes since
> I now the time and work it cost to you. At the time you worked on this
> there was not all this new maven enhancements that allow us to simplify
> things. I strongly believe that all this changes can carry us a less
> painful build and release process if we (mostly I, supported by Chris) can
> overcome the CI changes to work with the new changes. All this will ease
> things for people coming that should be other priority for us. I think this
> is the main barrier for newcomers and making thing ultra easy can allow
> more people coming to Royale. This is all a bet, that we think can reach a
> good point. We we need to solve things in chunks if we want to succeed.
>
> But, I want to state clearly here, that if you finally don't see a good end
> for this, you can veto this change and we can roll back to the previous
> process. I think we can reach to simplify all and make releases more easy
> to do, but it will imply in some parts changes that we need to agree that
> can be done. For all this we need to try to be open mind.
>
> So instead of trying to expose ways to solve concrete parts already
> exposed, I want to ask about how we can simplify the release process:
>
> We have Maven and ANT as first citizens for build process, so users can use
> what they want. But my question here's, do we need to use both in the
> release process? From what I understand Apache only requires us to use one
> of them for releasing process. So we could just rely on the maven process
> that are just few lines (already posted early in this thread). Copy here to
> notice the simplicity:
>
> Ideally releasing a part of Royale is just a 2-3 step process:
>
> - royale-compiler:
> - mvn release:prepare -DautoversionSubmodules=true
> - mvn release:perform
> - royale-typedefs:
> - update the pom.xml: royale.compiler.version to the new released
> version
> - mvn release:prepare -DautoversionSubmodules=true
> - mvn release:perform
> - royale-asjs:
> - update the pom.xml: royale.compiler.version and
> royale.typedefs.version to the new released version
> - mvn release:prepare -DautoversionSubmodules=true
> - mvn release:perform
>
>
> In doing in this way, we'll streamline the release process and will not
> need to do anything more. Just that few lines. And that means hopefully
> make our release process a more tiny process in time to all of us, while
> users that wants to build with ANT can do it without problem. Can we agree
> with this? Let me know if I'm wrong with this. Notice that my focus is to
> try to get to the easiest way possible to build and release we can get.
>
>
Does this few lines build IDE artifacts ?
> To not create a very long thread. I'll left this here so we can see what
> you guys think about it.
>
> Thanks in advance
>
> Carlos
>
>
>
> El dom., 17 nov. 2019 a las 0:06, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
> > I'm pretty sure I added JGIT in order to do the release on the CI server.
> > See change 1aa2b16 in royale-compiler on Feb 11, 2019. The reason the CI
> > needs JGIT is because the regular Maven git support seemed to expect that
> > you had a private key registered since most folks run the release plugin
> on
> > their private computer. JGIT allowed specification of username without
> > password for commits.
> >
> > The Royale compiler is also required to parse the time stamps in order to
> > inject them into the SWFs and SWCs. So I am hopeful that didn't break,
> but
> > if it did, you know where to look. Also the release steps on CI expect
> the
> > timestamp to be given by the RM so it can be used in Ant as well. So I
> am
> > concerned about that as well. But maybe it will work or you will fix it.
> > I don't care as long as it doesn't cost me time. But as RM you are
> > responsible for the Ant artifacts as well. The timestamp must also be
> > handed to the voters as well in order for them to reproduce the same
> > binaries.
> >
> > My experience was that zlika was very responsive to fixing an issue. I'm
> > not sure if Maven has picked up all of the zlika changes, but if not,
> then
> > one of the artifacts will not reproduce. When I offered a patch to
> Maven,
> > I was told I had to go figure out their test harnesses and build a set of
> > test cases, which I still haven't found time to do. Again, if it all
> ends
> > up working and doesn't cost me time, it doesn't matter which plugin we
> use.
> >
> > My 2 cents,
> > -Alex
> >
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Piotr Zarzycki <pi...@gmail.com>.
Carlos,
I lost at least 3 payed days on having Upload artifacts on Windows using
Maven and I have never successes with that. - It wasn't only me. -
Uploading problem didn't gone for sure. Last release is just a proof.
Anyway again I suggest you start learn how release process works, try and
than provide next PR or commits. And I agree with you on one of your email
that everything can be done trough Maven, but who is going to do that ? -
that is a bigger question. I can confirm that current release process is ok
and I'm able to release SDK in about 3-4h - why so much time, this is just
because building stuff takes some time - The rest of the things is
automated - please do not break that stuff, cause it would be a shame to
loose such a good process.
Thanks,
Piotr
pon., 18 lis 2019 o 16:56 Carlos Rovira <ca...@apache.org>
napisał(a):
> Hi,
>
> After the mavenizer is released there is no longer a need to use the
> settings-template.xml files at all and we can delete them. This is not
> related to the PRs, and is something we can do aside we need to revert the
> PRs or make other changes over it to improve what we have.
>
> The Maven build only uses one Environment Variable and that is identical to
> that of ANT providing the Gecko-Driver parameter is optional and adds tests
> not run in the ANT build.
>
> 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?
>
> 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.
>
> 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.
>
> As you saw already, with this changes it should be possible to come back to
> run the release on any private machine. This can be done (and is the
> preferred way to all of us and for Apache), but only if the things to do
> are relatively "compact" or reduced.
>
> The projects are configured, that in general specifying any profile for the
> release should no longer be required at all. The default should work and
> the release build auto-enables all required profiles.
>
> 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.
>
> 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.
>
> 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.
>
> Thanks
>
> Carlos
>
>
>
>
> El lun., 18 nov. 2019 a las 16:03, Carlos Rovira (<carlosrovira@apache.org
> >)
> escribió:
>
> > Hi Alex,
> >
> > right, I don't want to start a discussion about deprecating ANT. I like
> > Maven but I think neither Chris or I are wanting to remove ANT for
> > building. Just thought an option could be to not involve ANT in the
> release
> > process, but just in the users build process (that I thought is what we
> > really want to offer to our users), after analyzing how to simplify the
> > process. But if you consider we need to maintain ANT even in the release
> > process then we must all have in mind that we need to continue
> considering
> > it in the release process.
> >
> > I want to respond this first, since I have no more time right now. I'll
> > come back later to this discussion to see how we can proceed.
> >
> > Thanks
> >
> >
> > El lun., 18 nov. 2019 a las 10:49, Alex Harui (<aharui@adobe.com.invalid
> >)
> > escribió:
> >
> >> Fundamentally, I don't think we want to get rid of Ant or treat Ant as
> >> second-class. Some people still prefer Ant over Maven. We need to
> offer
> >> people choices. Not having a Maven-based release process (whatever that
> >> means) isn't the thing that new users are complaining about, IMO. You
> can
> >> try to approximate Ant-based testing with Maven, but the best test is
> >> simply to use Ant to build all of our code and examples.
> >>
> >> Of the 13 CI release steps, only one of them uses Ant. The first 11 are
> >> all about Maven. The reason there are 11 is in order to break up the
> steps
> >> to allow for building on a shared machine without credentials stored on
> >> them. That's because the two people who tried using a much simpler set
> of
> >> steps couldn't because of upload issues. It is the 11 Maven steps that
> are
> >> what broke in the 1 PR commit I reviewed so far. It has nothing to do
> with
> >> Ant. The current release process is not really Ant-based, IMO.
> >>
> >> You are welcome to work on a new release automation process, but If the
> >> voters on a release cannot use Ant to test/verify the release, then we
> >> won't know that Ant will work for the users. And if the invoker has to
> >> invoke Ant to test the Ant artifacts, then we still require Ant.
> >>
> >> IMO, the issues for building Maven snapshot artifacts are:
> >> 1) requiring settings-template.xml (this is apparently now fixed in the
> >> Flex release)
> >> 2) what environment variables are needed (this is apparently fixed in
> the
> >> PR)
> >> 3) the utils profile
> >>
> >> The issues for creating Maven release artifacts are:
> >> 3) the utils profile
> >> 4) the places we have to set-property
> >> 5) the upload failures
> >>
> >> It would be simpler to just be able to clone a repo, run maven
> >> release:branch, release:prepare, release:perform, then do the next repo,
> >> and the next. If this PR fixes that, that's super, because in the past
> we
> >> have invoke Maven in other ways to get the versions updated correctly by
> >> choosing the right profiles and set-property calls and that invites use
> of
> >> a batch script or Ant to automate that sequence. Then using Ant made it
> >> harder to re-start after an upload failure, so we changed to using the
> CI
> >> release steps.
> >>
> >> So if the PR has fixed all that, then maybe we can go back to using
> >> private computers to generate all of the artifacts. The CI release
> steps
> >> were set up so that people would not have to deal with various setup
> issues
> >> and try to dodge the upload issues. However, I think fixing the utils
> >> profile issue would require forking royale-compiler into two repos.
> Maybe
> >> forking royale-compiler is the right thing to do.
> >>
> >> In the end, though, you still need to clone several repos and invoke
> >> Maven at least 3 times for each repo to cut a release. I'm not a fan of
> >> using Maven as a scripting engine. Yes, I know you "can", but that
> doesn't
> >> mean you should. So, I think if we go back to building releases on
> private
> >> computers, Ant would still be the obvious way to invoke Maven 3 times on
> >> each repo in the right order.
> >>
> >> And, we must always ask whether this is really worth the effort. This
> >> thread started as making the Maven builds simpler which was great, but
> now
> >> it is starting to remind me of past discussions to make Maven primary
> >> which, IMO, has not been the best use of our time. You can be a fan of
> >> Maven all you want, just don't impose it on the rest of us. Ant and
> Maven
> >> are both useful tools and we should use them for what they do best and
> >> allow our users to choose. The RMs and voters will need to run both.
> But
> >> improvements to the Ant and Maven builds are definitely welcome, so
> thanks
> >> to Christofer for working on them.
> >>
> >> My 2 cents,
> >> -Alex
> >>
> >> On 11/18/19, 12:33 AM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> >>
> >> Hi Alex
> >>
> >> The Ant tasks are Java jar files, so the building has always been
> >> handled
> >> by the maven build.
> >> for testing, this is possible too as maven has the invoker plugin
> >> exactly
> >> for stuff like that.
> >> In order to actually test the tasks, some work is needed, but it's
> >> probably
> >> easier to do that than to fix the Ant based release process.
> >>
> >> Other option, that I'm starting to thing could be more appropriate:
> >> While
> >> we want people build with both Maven and ANT on its own, that does
> not
> >> necessarily imply to release with ANT too. The other posible option
> >> is to
> >> make release, that's a very concrete task to be only a task for
> >> maven, and
> >> people testing the RC must use Maven as part of the requirements to
> >> test
> >> the release. I think this should be something totally licit if we
> >> want to
> >> ease the problem and make others capable of doing this task in a
> more
> >> simplified process.
> >>
> >>
> >>
> >>
> >> El lun., 18 nov. 2019 a las 0:23, Alex Harui
> >> (<ah...@adobe.com.invalid>)
> >> escribió:
> >>
> >> > If you don't use Ant, how can you build and test the Ant tasks?
> >> >
> >> > -Alex
> >> >
> >> > On 11/17/19, 3:43 AM, "Carlos Rovira" <ca...@apache.org>
> >> wrote:
> >> >
> >> > Hi Alex,
> >> >
> >> > first of all I understand completely your concerns about this
> >> changes
> >> > since
> >> > I now the time and work it cost to you. At the time you worked
> >> on this
> >> > there was not all this new maven enhancements that allow us to
> >> simplify
> >> > things. I strongly believe that all this changes can carry us
> a
> >> less
> >> > painful build and release process if we (mostly I, supported
> by
> >> Chris)
> >> > can
> >> > overcome the CI changes to work with the new changes. All this
> >> will
> >> > ease
> >> > things for people coming that should be other priority for us.
> >> I think
> >> > this
> >> > is the main barrier for newcomers and making thing ultra easy
> >> can allow
> >> > more people coming to Royale. This is all a bet, that we think
> >> can
> >> > reach a
> >> > good point. We we need to solve things in chunks if we want to
> >> succeed.
> >> >
> >> > But, I want to state clearly here, that if you finally don't
> >> see a
> >> > good end
> >> > for this, you can veto this change and we can roll back to the
> >> previous
> >> > process. I think we can reach to simplify all and make
> releases
> >> more
> >> > easy
> >> > to do, but it will imply in some parts changes that we need to
> >> agree
> >> > that
> >> > can be done. For all this we need to try to be open mind.
> >> >
> >> > So instead of trying to expose ways to solve concrete parts
> >> already
> >> > exposed, I want to ask about how we can simplify the release
> >> process:
> >> >
> >> > We have Maven and ANT as first citizens for build process, so
> >> users
> >> > can use
> >> > what they want. But my question here's, do we need to use both
> >> in the
> >> > release process? From what I understand Apache only requires
> us
> >> to use
> >> > one
> >> > of them for releasing process. So we could just rely on the
> >> maven
> >> > process
> >> > that are just few lines (already posted early in this thread).
> >> Copy
> >> > here to
> >> > notice the simplicity:
> >> >
> >> > Ideally releasing a part of Royale is just a 2-3 step process:
> >> >
> >> > - royale-compiler:
> >> > - mvn release:prepare -DautoversionSubmodules=true
> >> > - mvn release:perform
> >> > - royale-typedefs:
> >> > - update the pom.xml: royale.compiler.version to the new
> >> released
> >> > version
> >> > - mvn release:prepare -DautoversionSubmodules=true
> >> > - mvn release:perform
> >> > - royale-asjs:
> >> > - update the pom.xml: royale.compiler.version and
> >> > royale.typedefs.version to the new released version
> >> > - mvn release:prepare -DautoversionSubmodules=true
> >> > - mvn release:perform
> >> >
> >> >
> >> > In doing in this way, we'll streamline the release process and
> >> will not
> >> > need to do anything more. Just that few lines. And that means
> >> hopefully
> >> > make our release process a more tiny process in time to all of
> >> us,
> >> > while
> >> > users that wants to build with ANT can do it without problem.
> >> Can we
> >> > agree
> >> > with this? Let me know if I'm wrong with this. Notice that my
> >> focus is
> >> > to
> >> > try to get to the easiest way possible to build and release we
> >> can get.
> >> >
> >> > To not create a very long thread. I'll left this here so we
> can
> >> see
> >> > what
> >> > you guys think about it.
> >> >
> >> > Thanks in advance
> >> >
> >> > Carlos
> >> >
> >> >
> >> >
> >> > El dom., 17 nov. 2019 a las 0:06, Alex Harui
> >> (<aharui@adobe.com.invalid
> >> > >)
> >> > escribió:
> >> >
> >> > > I'm pretty sure I added JGIT in order to do the release on
> >> the CI
> >> > server.
> >> > > See change 1aa2b16 in royale-compiler on Feb 11, 2019. The
> >> reason
> >> > the CI
> >> > > needs JGIT is because the regular Maven git support seemed
> to
> >> expect
> >> > that
> >> > > you had a private key registered since most folks run the
> >> release
> >> > plugin on
> >> > > their private computer. JGIT allowed specification of
> >> username
> >> > without
> >> > > password for commits.
> >> > >
> >> > > The Royale compiler is also required to parse the time
> stamps
> >> in
> >> > order to
> >> > > inject them into the SWFs and SWCs. So I am hopeful that
> >> didn't
> >> > break, but
> >> > > if it did, you know where to look. Also the release steps
> on
> >> CI
> >> > expect the
> >> > > timestamp to be given by the RM so it can be used in Ant as
> >> well.
> >> > So I am
> >> > > concerned about that as well. But maybe it will work or you
> >> will
> >> > fix it.
> >> > > I don't care as long as it doesn't cost me time. But as RM
> >> you are
> >> > > responsible for the Ant artifacts as well. The timestamp
> >> must also
> >> > be
> >> > > handed to the voters as well in order for them to reproduce
> >> the same
> >> > > binaries.
> >> > >
> >> > > My experience was that zlika was very responsive to fixing
> an
> >> > issue. I'm
> >> > > not sure if Maven has picked up all of the zlika changes,
> but
> >> if
> >> > not, then
> >> > > one of the artifacts will not reproduce. When I offered a
> >> patch to
> >> > Maven,
> >> > > I was told I had to go figure out their test harnesses and
> >> build a
> >> > set of
> >> > > test cases, which I still haven't found time to do. Again,
> >> if it
> >> > all ends
> >> > > up working and doesn't cost me time, it doesn't matter which
> >> plugin
> >> > we use.
> >> > >
> >> > > My 2 cents,
> >> > > -Alex
> >> > >
> >> > --
> >> > Carlos Rovira
> >> >
> >> >
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2a612acd9b9a446b56b508d76c01f460%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637096627978180111&sdata=TtLJ9PKWcFhxX7i0UNdSBhdV60IDl8fvIDNrXExgb%2Fk%3D&reserved=0
> >> >
> >> >
> >> >
> >>
> >> --
> >> Carlos Rovira
> >>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2a612acd9b9a446b56b508d76c01f460%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637096627978180111&sdata=TtLJ9PKWcFhxX7i0UNdSBhdV60IDl8fvIDNrXExgb%2Fk%3D&reserved=0
> >>
> >>
> >>
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
> >
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Piotr Zarzycki <pi...@gmail.com>.
Unfortunately I have no idea what you need to revert, cause you didn't try
release steps with Chris's PR. Maybe you won't have to do anything.
You may invest time and money into that and your changes and proposition
won't be accepted by community, so try to compose plan in parallel and
present it here, so discussion can continue. It is my suggestion.
Good luck with the changes!
wt., 19 lis 2019 o 17:30 Carlos Rovira <ca...@apache.org> napisał(a):
> Hi Piotr,
>
> if you refer to the plan will do, still didn't share. I want to go piece by
> piece to avoid talking of many things at the same time.
>
> I just talked with Chris, and I can revert his PRs, and then we'll
> re-revert again on his repo.
> Or we can left all as is and just restore JGit, if there's nothing more to
> do.
>
> I'll wait to hear from you and Alex to do this.
> Next with that solved, I'll propose a plan to do in Chris's royale fork. At
> that time what I want is people agree that in doing that and making it work
> we'll all be happy and will merge it since it will be something working
> when build and when release. That's the target.
>
> Thanks
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Carlos Rovira <ca...@apache.org>.
Greg,
thanks for letting us know, very appreciated
I think your support can be very useful as always.
Will let you know if you can help on any area :)
Thanks
Carlos
El mar., 19 nov. 2019 a las 20:23, Greg Dove (<gr...@gmail.com>)
escribió:
> Just chiming in from my perspective... I am definitely keen to help out
> with testing on the maven changes (I meant to say so earlier, I've been
> distracted, focused on other things recently, sorry).
> I think these changes make things a lot simpler and cleaner for maven. I
> see a lot less maven profiles now, which should be less daunting for
> someone new. And I can see more visual cues for things like skipped tests
> in the console output (windows) which I assume might be related to the
> changes.
>
> I used to be an ant user because it was what I knew, and I do still use ant
> elsewhere, but I would consider myself more of a maven person now for
> Flex/Royale, and that is only through exposure to it gained here.
>
> I don't know anything about the release steps, but I will try to learn how
> to test these and see if I can help with testing this also for maven
> changes.
>
> +2 cents:
> If supporting a range of build technologies for SDK users implies the need
> for using the same technologies to build the SDK artifacts/SDK themselves
> then obviously we need to continue to do that. But if it was not necessary,
> then I don't understand the argument that having multiple approaches to
> build the artifacts/working SDK is advantageous. I would expect that
> keeping this simple would be more appealing to new contributors, because
> the focus could be on the SDK itself and not on build variation maintenance
> across multiple ways to build. I can't imagine that if people are truly
> interested in contributing, that the choice of build technology is a hurdle
> to doing so. So long as the setup instructions are simple and it works,
> then people can largely ignore it (particularly if it is unfamiliar to
> them) and focus on the code (which is the point). That's kind of how I tend
> to approach any open source projects, but I make no claim that I am
> representative of others. I'm just throwing this out there as a thinking
> point, not a discussion point. For now I assume we have status quo on the
> ant and maven builds being equally important.
>
>
>
>
> On Wed, Nov 20, 2019 at 6:47 AM Carlos Rovira <ca...@apache.org>
> wrote:
>
> > Hi,
> >
> > ok. we can then avoid reverting. Maybe we can wait to restore JGit and
> > Wagon, since probably in the process we finally get to not need it
> anymore.
> >
> > I'll plan tomorrow with Chris and see what's the steps to do. Then I'll
> > share here to get consensus before starting to work on it. We need to be
> > safe that we're working on the right path.
> >
> > Thanks
> >
> >
> >
> >
> >
> >
> > El mar., 19 nov. 2019 a las 17:45, Alex Harui (<aharui@adobe.com.invalid
> >)
> > escribió:
> >
> > > I still haven't found time to review the many commits in these PRs as
> > > higher priority things keep coming up. I'm pretty sure JGit is an
> issue.
> > > I think Wagon as well. But there could be others.
> > >
> > > I don't think reverting is required if it is faster if Carlos and
> > > Christofer are going to take the time to test and fix the CI release
> > steps
> > > against these changes. That's because the nobody except the next RM is
> > > currently blocked by the changes. The net result of the CI steps
> should
> > be
> > > the same set of files in 0.9.6 with different version names. If you
> can
> > > figure out how to run against the 0.9.6 tag you should get the exact
> same
> > > binaries, but if you run against the head you'll have some differences
> > > against 0.9.6 but if you test local builds on Mac and Win you should
> find
> > > any other binary reproducibility issues that zlika fixed that Maven may
> > not
> > > have picked up.
> > >
> > > The argument about changes getting stale are a problem for anyone.
> > > Hopefully Christofer is working against a branch and not a fork, and
> the
> > > usual branch merging practices need to be used to resync before
> pushing.
> > >
> > > My 2 cents,
> > > -Alex
> > >
> > > On 11/19/19, 8:30 AM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> > >
> > > Hi Piotr,
> > >
> > > if you refer to the plan will do, still didn't share. I want to go
> > > piece by
> > > piece to avoid talking of many things at the same time.
> > >
> > > I just talked with Chris, and I can revert his PRs, and then we'll
> > > re-revert again on his repo.
> > > Or we can left all as is and just restore JGit, if there's nothing
> > > more to
> > > do.
> > >
> > > I'll wait to hear from you and Alex to do this.
> > > Next with that solved, I'll propose a plan to do in Chris's royale
> > > fork. At
> > > that time what I want is people agree that in doing that and making
> > it
> > > work
> > > we'll all be happy and will merge it since it will be something
> > working
> > > when build and when release. That's the target.
> > >
> > > Thanks
> > >
> > >
> > >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Greg Dove <gr...@gmail.com>.
Just chiming in from my perspective... I am definitely keen to help out
with testing on the maven changes (I meant to say so earlier, I've been
distracted, focused on other things recently, sorry).
I think these changes make things a lot simpler and cleaner for maven. I
see a lot less maven profiles now, which should be less daunting for
someone new. And I can see more visual cues for things like skipped tests
in the console output (windows) which I assume might be related to the
changes.
I used to be an ant user because it was what I knew, and I do still use ant
elsewhere, but I would consider myself more of a maven person now for
Flex/Royale, and that is only through exposure to it gained here.
I don't know anything about the release steps, but I will try to learn how
to test these and see if I can help with testing this also for maven
changes.
+2 cents:
If supporting a range of build technologies for SDK users implies the need
for using the same technologies to build the SDK artifacts/SDK themselves
then obviously we need to continue to do that. But if it was not necessary,
then I don't understand the argument that having multiple approaches to
build the artifacts/working SDK is advantageous. I would expect that
keeping this simple would be more appealing to new contributors, because
the focus could be on the SDK itself and not on build variation maintenance
across multiple ways to build. I can't imagine that if people are truly
interested in contributing, that the choice of build technology is a hurdle
to doing so. So long as the setup instructions are simple and it works,
then people can largely ignore it (particularly if it is unfamiliar to
them) and focus on the code (which is the point). That's kind of how I tend
to approach any open source projects, but I make no claim that I am
representative of others. I'm just throwing this out there as a thinking
point, not a discussion point. For now I assume we have status quo on the
ant and maven builds being equally important.
On Wed, Nov 20, 2019 at 6:47 AM Carlos Rovira <ca...@apache.org>
wrote:
> Hi,
>
> ok. we can then avoid reverting. Maybe we can wait to restore JGit and
> Wagon, since probably in the process we finally get to not need it anymore.
>
> I'll plan tomorrow with Chris and see what's the steps to do. Then I'll
> share here to get consensus before starting to work on it. We need to be
> safe that we're working on the right path.
>
> Thanks
>
>
>
>
>
>
> El mar., 19 nov. 2019 a las 17:45, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
> > I still haven't found time to review the many commits in these PRs as
> > higher priority things keep coming up. I'm pretty sure JGit is an issue.
> > I think Wagon as well. But there could be others.
> >
> > I don't think reverting is required if it is faster if Carlos and
> > Christofer are going to take the time to test and fix the CI release
> steps
> > against these changes. That's because the nobody except the next RM is
> > currently blocked by the changes. The net result of the CI steps should
> be
> > the same set of files in 0.9.6 with different version names. If you can
> > figure out how to run against the 0.9.6 tag you should get the exact same
> > binaries, but if you run against the head you'll have some differences
> > against 0.9.6 but if you test local builds on Mac and Win you should find
> > any other binary reproducibility issues that zlika fixed that Maven may
> not
> > have picked up.
> >
> > The argument about changes getting stale are a problem for anyone.
> > Hopefully Christofer is working against a branch and not a fork, and the
> > usual branch merging practices need to be used to resync before pushing.
> >
> > My 2 cents,
> > -Alex
> >
> > On 11/19/19, 8:30 AM, "Carlos Rovira" <ca...@apache.org> wrote:
> >
> > Hi Piotr,
> >
> > if you refer to the plan will do, still didn't share. I want to go
> > piece by
> > piece to avoid talking of many things at the same time.
> >
> > I just talked with Chris, and I can revert his PRs, and then we'll
> > re-revert again on his repo.
> > Or we can left all as is and just restore JGit, if there's nothing
> > more to
> > do.
> >
> > I'll wait to hear from you and Alex to do this.
> > Next with that solved, I'll propose a plan to do in Chris's royale
> > fork. At
> > that time what I want is people agree that in doing that and making
> it
> > work
> > we'll all be happy and will merge it since it will be something
> working
> > when build and when release. That's the target.
> >
> > Thanks
> >
> >
> >
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Carlos Rovira <ca...@apache.org>.
Hi,
ok. we can then avoid reverting. Maybe we can wait to restore JGit and
Wagon, since probably in the process we finally get to not need it anymore.
I'll plan tomorrow with Chris and see what's the steps to do. Then I'll
share here to get consensus before starting to work on it. We need to be
safe that we're working on the right path.
Thanks
El mar., 19 nov. 2019 a las 17:45, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> I still haven't found time to review the many commits in these PRs as
> higher priority things keep coming up. I'm pretty sure JGit is an issue.
> I think Wagon as well. But there could be others.
>
> I don't think reverting is required if it is faster if Carlos and
> Christofer are going to take the time to test and fix the CI release steps
> against these changes. That's because the nobody except the next RM is
> currently blocked by the changes. The net result of the CI steps should be
> the same set of files in 0.9.6 with different version names. If you can
> figure out how to run against the 0.9.6 tag you should get the exact same
> binaries, but if you run against the head you'll have some differences
> against 0.9.6 but if you test local builds on Mac and Win you should find
> any other binary reproducibility issues that zlika fixed that Maven may not
> have picked up.
>
> The argument about changes getting stale are a problem for anyone.
> Hopefully Christofer is working against a branch and not a fork, and the
> usual branch merging practices need to be used to resync before pushing.
>
> My 2 cents,
> -Alex
>
> On 11/19/19, 8:30 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Piotr,
>
> if you refer to the plan will do, still didn't share. I want to go
> piece by
> piece to avoid talking of many things at the same time.
>
> I just talked with Chris, and I can revert his PRs, and then we'll
> re-revert again on his repo.
> Or we can left all as is and just restore JGit, if there's nothing
> more to
> do.
>
> I'll wait to hear from you and Alex to do this.
> Next with that solved, I'll propose a plan to do in Chris's royale
> fork. At
> that time what I want is people agree that in doing that and making it
> work
> we'll all be happy and will merge it since it will be something working
> when build and when release. That's the target.
>
> Thanks
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I still haven't found time to review the many commits in these PRs as higher priority things keep coming up. I'm pretty sure JGit is an issue. I think Wagon as well. But there could be others.
I don't think reverting is required if it is faster if Carlos and Christofer are going to take the time to test and fix the CI release steps against these changes. That's because the nobody except the next RM is currently blocked by the changes. The net result of the CI steps should be the same set of files in 0.9.6 with different version names. If you can figure out how to run against the 0.9.6 tag you should get the exact same binaries, but if you run against the head you'll have some differences against 0.9.6 but if you test local builds on Mac and Win you should find any other binary reproducibility issues that zlika fixed that Maven may not have picked up.
The argument about changes getting stale are a problem for anyone. Hopefully Christofer is working against a branch and not a fork, and the usual branch merging practices need to be used to resync before pushing.
My 2 cents,
-Alex
On 11/19/19, 8:30 AM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Piotr,
if you refer to the plan will do, still didn't share. I want to go piece by
piece to avoid talking of many things at the same time.
I just talked with Chris, and I can revert his PRs, and then we'll
re-revert again on his repo.
Or we can left all as is and just restore JGit, if there's nothing more to
do.
I'll wait to hear from you and Alex to do this.
Next with that solved, I'll propose a plan to do in Chris's royale fork. At
that time what I want is people agree that in doing that and making it work
we'll all be happy and will merge it since it will be something working
when build and when release. That's the target.
Thanks
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Carlos Rovira <ca...@apache.org>.
Hi Piotr,
if you refer to the plan will do, still didn't share. I want to go piece by
piece to avoid talking of many things at the same time.
I just talked with Chris, and I can revert his PRs, and then we'll
re-revert again on his repo.
Or we can left all as is and just restore JGit, if there's nothing more to
do.
I'll wait to hear from you and Alex to do this.
Next with that solved, I'll propose a plan to do in Chris's royale fork. At
that time what I want is people agree that in doing that and making it work
we'll all be happy and will merge it since it will be something working
when build and when release. That's the target.
Thanks
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Piotr Zarzycki <pi...@gmail.com>.
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 <ca...@apache.org> 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 (<ah...@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" <ca...@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
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Carlos Rovira <ca...@apache.org>.
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 (<ah...@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" <ca...@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
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ca...@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
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Carlos Rovira <ca...@apache.org>.
Hi,
After the mavenizer is released there is no longer a need to use the
settings-template.xml files at all and we can delete them. This is not
related to the PRs, and is something we can do aside we need to revert the
PRs or make other changes over it to improve what we have.
The Maven build only uses one Environment Variable and that is identical to
that of ANT providing the Gecko-Driver parameter is optional and adds tests
not run in the ANT build.
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?
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.
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.
As you saw already, with this changes it should be possible to come back to
run the release on any private machine. This can be done (and is the
preferred way to all of us and for Apache), but only if the things to do
are relatively "compact" or reduced.
The projects are configured, that in general specifying any profile for the
release should no longer be required at all. The default should work and
the release build auto-enables all required profiles.
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.
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.
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.
Thanks
Carlos
El lun., 18 nov. 2019 a las 16:03, Carlos Rovira (<ca...@apache.org>)
escribió:
> Hi Alex,
>
> right, I don't want to start a discussion about deprecating ANT. I like
> Maven but I think neither Chris or I are wanting to remove ANT for
> building. Just thought an option could be to not involve ANT in the release
> process, but just in the users build process (that I thought is what we
> really want to offer to our users), after analyzing how to simplify the
> process. But if you consider we need to maintain ANT even in the release
> process then we must all have in mind that we need to continue considering
> it in the release process.
>
> I want to respond this first, since I have no more time right now. I'll
> come back later to this discussion to see how we can proceed.
>
> Thanks
>
>
> El lun., 18 nov. 2019 a las 10:49, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
>> Fundamentally, I don't think we want to get rid of Ant or treat Ant as
>> second-class. Some people still prefer Ant over Maven. We need to offer
>> people choices. Not having a Maven-based release process (whatever that
>> means) isn't the thing that new users are complaining about, IMO. You can
>> try to approximate Ant-based testing with Maven, but the best test is
>> simply to use Ant to build all of our code and examples.
>>
>> Of the 13 CI release steps, only one of them uses Ant. The first 11 are
>> all about Maven. The reason there are 11 is in order to break up the steps
>> to allow for building on a shared machine without credentials stored on
>> them. That's because the two people who tried using a much simpler set of
>> steps couldn't because of upload issues. It is the 11 Maven steps that are
>> what broke in the 1 PR commit I reviewed so far. It has nothing to do with
>> Ant. The current release process is not really Ant-based, IMO.
>>
>> You are welcome to work on a new release automation process, but If the
>> voters on a release cannot use Ant to test/verify the release, then we
>> won't know that Ant will work for the users. And if the invoker has to
>> invoke Ant to test the Ant artifacts, then we still require Ant.
>>
>> IMO, the issues for building Maven snapshot artifacts are:
>> 1) requiring settings-template.xml (this is apparently now fixed in the
>> Flex release)
>> 2) what environment variables are needed (this is apparently fixed in the
>> PR)
>> 3) the utils profile
>>
>> The issues for creating Maven release artifacts are:
>> 3) the utils profile
>> 4) the places we have to set-property
>> 5) the upload failures
>>
>> It would be simpler to just be able to clone a repo, run maven
>> release:branch, release:prepare, release:perform, then do the next repo,
>> and the next. If this PR fixes that, that's super, because in the past we
>> have invoke Maven in other ways to get the versions updated correctly by
>> choosing the right profiles and set-property calls and that invites use of
>> a batch script or Ant to automate that sequence. Then using Ant made it
>> harder to re-start after an upload failure, so we changed to using the CI
>> release steps.
>>
>> So if the PR has fixed all that, then maybe we can go back to using
>> private computers to generate all of the artifacts. The CI release steps
>> were set up so that people would not have to deal with various setup issues
>> and try to dodge the upload issues. However, I think fixing the utils
>> profile issue would require forking royale-compiler into two repos. Maybe
>> forking royale-compiler is the right thing to do.
>>
>> In the end, though, you still need to clone several repos and invoke
>> Maven at least 3 times for each repo to cut a release. I'm not a fan of
>> using Maven as a scripting engine. Yes, I know you "can", but that doesn't
>> mean you should. So, I think if we go back to building releases on private
>> computers, Ant would still be the obvious way to invoke Maven 3 times on
>> each repo in the right order.
>>
>> And, we must always ask whether this is really worth the effort. This
>> thread started as making the Maven builds simpler which was great, but now
>> it is starting to remind me of past discussions to make Maven primary
>> which, IMO, has not been the best use of our time. You can be a fan of
>> Maven all you want, just don't impose it on the rest of us. Ant and Maven
>> are both useful tools and we should use them for what they do best and
>> allow our users to choose. The RMs and voters will need to run both. But
>> improvements to the Ant and Maven builds are definitely welcome, so thanks
>> to Christofer for working on them.
>>
>> My 2 cents,
>> -Alex
>>
>> On 11/18/19, 12:33 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>>
>> Hi Alex
>>
>> The Ant tasks are Java jar files, so the building has always been
>> handled
>> by the maven build.
>> for testing, this is possible too as maven has the invoker plugin
>> exactly
>> for stuff like that.
>> In order to actually test the tasks, some work is needed, but it's
>> probably
>> easier to do that than to fix the Ant based release process.
>>
>> Other option, that I'm starting to thing could be more appropriate:
>> While
>> we want people build with both Maven and ANT on its own, that does not
>> necessarily imply to release with ANT too. The other posible option
>> is to
>> make release, that's a very concrete task to be only a task for
>> maven, and
>> people testing the RC must use Maven as part of the requirements to
>> test
>> the release. I think this should be something totally licit if we
>> want to
>> ease the problem and make others capable of doing this task in a more
>> simplified process.
>>
>>
>>
>>
>> El lun., 18 nov. 2019 a las 0:23, Alex Harui
>> (<ah...@adobe.com.invalid>)
>> escribió:
>>
>> > If you don't use Ant, how can you build and test the Ant tasks?
>> >
>> > -Alex
>> >
>> > On 11/17/19, 3:43 AM, "Carlos Rovira" <ca...@apache.org>
>> wrote:
>> >
>> > Hi Alex,
>> >
>> > first of all I understand completely your concerns about this
>> changes
>> > since
>> > I now the time and work it cost to you. At the time you worked
>> on this
>> > there was not all this new maven enhancements that allow us to
>> simplify
>> > things. I strongly believe that all this changes can carry us a
>> less
>> > painful build and release process if we (mostly I, supported by
>> Chris)
>> > can
>> > overcome the CI changes to work with the new changes. All this
>> will
>> > ease
>> > things for people coming that should be other priority for us.
>> I think
>> > this
>> > is the main barrier for newcomers and making thing ultra easy
>> can allow
>> > more people coming to Royale. This is all a bet, that we think
>> can
>> > reach a
>> > good point. We we need to solve things in chunks if we want to
>> succeed.
>> >
>> > But, I want to state clearly here, that if you finally don't
>> see a
>> > good end
>> > for this, you can veto this change and we can roll back to the
>> previous
>> > process. I think we can reach to simplify all and make releases
>> more
>> > easy
>> > to do, but it will imply in some parts changes that we need to
>> agree
>> > that
>> > can be done. For all this we need to try to be open mind.
>> >
>> > So instead of trying to expose ways to solve concrete parts
>> already
>> > exposed, I want to ask about how we can simplify the release
>> process:
>> >
>> > We have Maven and ANT as first citizens for build process, so
>> users
>> > can use
>> > what they want. But my question here's, do we need to use both
>> in the
>> > release process? From what I understand Apache only requires us
>> to use
>> > one
>> > of them for releasing process. So we could just rely on the
>> maven
>> > process
>> > that are just few lines (already posted early in this thread).
>> Copy
>> > here to
>> > notice the simplicity:
>> >
>> > Ideally releasing a part of Royale is just a 2-3 step process:
>> >
>> > - royale-compiler:
>> > - mvn release:prepare -DautoversionSubmodules=true
>> > - mvn release:perform
>> > - royale-typedefs:
>> > - update the pom.xml: royale.compiler.version to the new
>> released
>> > version
>> > - mvn release:prepare -DautoversionSubmodules=true
>> > - mvn release:perform
>> > - royale-asjs:
>> > - update the pom.xml: royale.compiler.version and
>> > royale.typedefs.version to the new released version
>> > - mvn release:prepare -DautoversionSubmodules=true
>> > - mvn release:perform
>> >
>> >
>> > In doing in this way, we'll streamline the release process and
>> will not
>> > need to do anything more. Just that few lines. And that means
>> hopefully
>> > make our release process a more tiny process in time to all of
>> us,
>> > while
>> > users that wants to build with ANT can do it without problem.
>> Can we
>> > agree
>> > with this? Let me know if I'm wrong with this. Notice that my
>> focus is
>> > to
>> > try to get to the easiest way possible to build and release we
>> can get.
>> >
>> > To not create a very long thread. I'll left this here so we can
>> see
>> > what
>> > you guys think about it.
>> >
>> > Thanks in advance
>> >
>> > Carlos
>> >
>> >
>> >
>> > El dom., 17 nov. 2019 a las 0:06, Alex Harui
>> (<aharui@adobe.com.invalid
>> > >)
>> > escribió:
>> >
>> > > I'm pretty sure I added JGIT in order to do the release on
>> the CI
>> > server.
>> > > See change 1aa2b16 in royale-compiler on Feb 11, 2019. The
>> reason
>> > the CI
>> > > needs JGIT is because the regular Maven git support seemed to
>> expect
>> > that
>> > > you had a private key registered since most folks run the
>> release
>> > plugin on
>> > > their private computer. JGIT allowed specification of
>> username
>> > without
>> > > password for commits.
>> > >
>> > > The Royale compiler is also required to parse the time stamps
>> in
>> > order to
>> > > inject them into the SWFs and SWCs. So I am hopeful that
>> didn't
>> > break, but
>> > > if it did, you know where to look. Also the release steps on
>> CI
>> > expect the
>> > > timestamp to be given by the RM so it can be used in Ant as
>> well.
>> > So I am
>> > > concerned about that as well. But maybe it will work or you
>> will
>> > fix it.
>> > > I don't care as long as it doesn't cost me time. But as RM
>> you are
>> > > responsible for the Ant artifacts as well. The timestamp
>> must also
>> > be
>> > > handed to the voters as well in order for them to reproduce
>> the same
>> > > binaries.
>> > >
>> > > My experience was that zlika was very responsive to fixing an
>> > issue. I'm
>> > > not sure if Maven has picked up all of the zlika changes, but
>> if
>> > not, then
>> > > one of the artifacts will not reproduce. When I offered a
>> patch to
>> > Maven,
>> > > I was told I had to go figure out their test harnesses and
>> build a
>> > set of
>> > > test cases, which I still haven't found time to do. Again,
>> if it
>> > all ends
>> > > up working and doesn't cost me time, it doesn't matter which
>> plugin
>> > we use.
>> > >
>> > > My 2 cents,
>> > > -Alex
>> > >
>> > --
>> > Carlos Rovira
>> >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2a612acd9b9a446b56b508d76c01f460%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637096627978180111&sdata=TtLJ9PKWcFhxX7i0UNdSBhdV60IDl8fvIDNrXExgb%2Fk%3D&reserved=0
>> >
>> >
>> >
>>
>> --
>> Carlos Rovira
>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2a612acd9b9a446b56b508d76c01f460%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637096627978180111&sdata=TtLJ9PKWcFhxX7i0UNdSBhdV60IDl8fvIDNrXExgb%2Fk%3D&reserved=0
>>
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Harbs <ha...@gmail.com>.
If we’re supporting both ant and maven (and I think we should), building both should be part of a release.
My $0.02,
Harbs
> On Nov 18, 2019, at 5:03 PM, Carlos Rovira <ca...@apache.org> wrote:
>
> Hi Alex,
>
> right, I don't want to start a discussion about deprecating ANT. I like
> Maven but I think neither Chris or I are wanting to remove ANT for
> building. Just thought an option could be to not involve ANT in the release
> process, but just in the users build process (that I thought is what we
> really want to offer to our users), after analyzing how to simplify the
> process. But if you consider we need to maintain ANT even in the release
> process then we must all have in mind that we need to continue considering
> it in the release process.
>
> I want to respond this first, since I have no more time right now. I'll
> come back later to this discussion to see how we can proceed.
>
> Thanks
>
>
> El lun., 18 nov. 2019 a las 10:49, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
>> Fundamentally, I don't think we want to get rid of Ant or treat Ant as
>> second-class. Some people still prefer Ant over Maven. We need to offer
>> people choices. Not having a Maven-based release process (whatever that
>> means) isn't the thing that new users are complaining about, IMO. You can
>> try to approximate Ant-based testing with Maven, but the best test is
>> simply to use Ant to build all of our code and examples.
>>
>> Of the 13 CI release steps, only one of them uses Ant. The first 11 are
>> all about Maven. The reason there are 11 is in order to break up the steps
>> to allow for building on a shared machine without credentials stored on
>> them. That's because the two people who tried using a much simpler set of
>> steps couldn't because of upload issues. It is the 11 Maven steps that are
>> what broke in the 1 PR commit I reviewed so far. It has nothing to do with
>> Ant. The current release process is not really Ant-based, IMO.
>>
>> You are welcome to work on a new release automation process, but If the
>> voters on a release cannot use Ant to test/verify the release, then we
>> won't know that Ant will work for the users. And if the invoker has to
>> invoke Ant to test the Ant artifacts, then we still require Ant.
>>
>> IMO, the issues for building Maven snapshot artifacts are:
>> 1) requiring settings-template.xml (this is apparently now fixed in the
>> Flex release)
>> 2) what environment variables are needed (this is apparently fixed in the
>> PR)
>> 3) the utils profile
>>
>> The issues for creating Maven release artifacts are:
>> 3) the utils profile
>> 4) the places we have to set-property
>> 5) the upload failures
>>
>> It would be simpler to just be able to clone a repo, run maven
>> release:branch, release:prepare, release:perform, then do the next repo,
>> and the next. If this PR fixes that, that's super, because in the past we
>> have invoke Maven in other ways to get the versions updated correctly by
>> choosing the right profiles and set-property calls and that invites use of
>> a batch script or Ant to automate that sequence. Then using Ant made it
>> harder to re-start after an upload failure, so we changed to using the CI
>> release steps.
>>
>> So if the PR has fixed all that, then maybe we can go back to using
>> private computers to generate all of the artifacts. The CI release steps
>> were set up so that people would not have to deal with various setup issues
>> and try to dodge the upload issues. However, I think fixing the utils
>> profile issue would require forking royale-compiler into two repos. Maybe
>> forking royale-compiler is the right thing to do.
>>
>> In the end, though, you still need to clone several repos and invoke Maven
>> at least 3 times for each repo to cut a release. I'm not a fan of using
>> Maven as a scripting engine. Yes, I know you "can", but that doesn't mean
>> you should. So, I think if we go back to building releases on private
>> computers, Ant would still be the obvious way to invoke Maven 3 times on
>> each repo in the right order.
>>
>> And, we must always ask whether this is really worth the effort. This
>> thread started as making the Maven builds simpler which was great, but now
>> it is starting to remind me of past discussions to make Maven primary
>> which, IMO, has not been the best use of our time. You can be a fan of
>> Maven all you want, just don't impose it on the rest of us. Ant and Maven
>> are both useful tools and we should use them for what they do best and
>> allow our users to choose. The RMs and voters will need to run both. But
>> improvements to the Ant and Maven builds are definitely welcome, so thanks
>> to Christofer for working on them.
>>
>> My 2 cents,
>> -Alex
>>
>> On 11/18/19, 12:33 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>>
>> Hi Alex
>>
>> The Ant tasks are Java jar files, so the building has always been
>> handled
>> by the maven build.
>> for testing, this is possible too as maven has the invoker plugin
>> exactly
>> for stuff like that.
>> In order to actually test the tasks, some work is needed, but it's
>> probably
>> easier to do that than to fix the Ant based release process.
>>
>> Other option, that I'm starting to thing could be more appropriate:
>> While
>> we want people build with both Maven and ANT on its own, that does not
>> necessarily imply to release with ANT too. The other posible option is
>> to
>> make release, that's a very concrete task to be only a task for maven,
>> and
>> people testing the RC must use Maven as part of the requirements to
>> test
>> the release. I think this should be something totally licit if we want
>> to
>> ease the problem and make others capable of doing this task in a more
>> simplified process.
>>
>>
>>
>>
>> El lun., 18 nov. 2019 a las 0:23, Alex Harui (<aharui@adobe.com.invalid
>>> )
>> escribió:
>>
>>> If you don't use Ant, how can you build and test the Ant tasks?
>>>
>>> -Alex
>>>
>>> On 11/17/19, 3:43 AM, "Carlos Rovira" <ca...@apache.org>
>> wrote:
>>>
>>> Hi Alex,
>>>
>>> first of all I understand completely your concerns about this
>> changes
>>> since
>>> I now the time and work it cost to you. At the time you worked
>> on this
>>> there was not all this new maven enhancements that allow us to
>> simplify
>>> things. I strongly believe that all this changes can carry us a
>> less
>>> painful build and release process if we (mostly I, supported by
>> Chris)
>>> can
>>> overcome the CI changes to work with the new changes. All this
>> will
>>> ease
>>> things for people coming that should be other priority for us. I
>> think
>>> this
>>> is the main barrier for newcomers and making thing ultra easy
>> can allow
>>> more people coming to Royale. This is all a bet, that we think
>> can
>>> reach a
>>> good point. We we need to solve things in chunks if we want to
>> succeed.
>>>
>>> But, I want to state clearly here, that if you finally don't see
>> a
>>> good end
>>> for this, you can veto this change and we can roll back to the
>> previous
>>> process. I think we can reach to simplify all and make releases
>> more
>>> easy
>>> to do, but it will imply in some parts changes that we need to
>> agree
>>> that
>>> can be done. For all this we need to try to be open mind.
>>>
>>> So instead of trying to expose ways to solve concrete parts
>> already
>>> exposed, I want to ask about how we can simplify the release
>> process:
>>>
>>> We have Maven and ANT as first citizens for build process, so
>> users
>>> can use
>>> what they want. But my question here's, do we need to use both
>> in the
>>> release process? From what I understand Apache only requires us
>> to use
>>> one
>>> of them for releasing process. So we could just rely on the maven
>>> process
>>> that are just few lines (already posted early in this thread).
>> Copy
>>> here to
>>> notice the simplicity:
>>>
>>> Ideally releasing a part of Royale is just a 2-3 step process:
>>>
>>> - royale-compiler:
>>> - mvn release:prepare -DautoversionSubmodules=true
>>> - mvn release:perform
>>> - royale-typedefs:
>>> - update the pom.xml: royale.compiler.version to the new
>> released
>>> version
>>> - mvn release:prepare -DautoversionSubmodules=true
>>> - mvn release:perform
>>> - royale-asjs:
>>> - update the pom.xml: royale.compiler.version and
>>> royale.typedefs.version to the new released version
>>> - mvn release:prepare -DautoversionSubmodules=true
>>> - mvn release:perform
>>>
>>>
>>> In doing in this way, we'll streamline the release process and
>> will not
>>> need to do anything more. Just that few lines. And that means
>> hopefully
>>> make our release process a more tiny process in time to all of
>> us,
>>> while
>>> users that wants to build with ANT can do it without problem.
>> Can we
>>> agree
>>> with this? Let me know if I'm wrong with this. Notice that my
>> focus is
>>> to
>>> try to get to the easiest way possible to build and release we
>> can get.
>>>
>>> To not create a very long thread. I'll left this here so we can
>> see
>>> what
>>> you guys think about it.
>>>
>>> Thanks in advance
>>>
>>> Carlos
>>>
>>>
>>>
>>> El dom., 17 nov. 2019 a las 0:06, Alex Harui
>> (<aharui@adobe.com.invalid
>>>> )
>>> escribió:
>>>
>>>> I'm pretty sure I added JGIT in order to do the release on the
>> CI
>>> server.
>>>> See change 1aa2b16 in royale-compiler on Feb 11, 2019. The
>> reason
>>> the CI
>>>> needs JGIT is because the regular Maven git support seemed to
>> expect
>>> that
>>>> you had a private key registered since most folks run the
>> release
>>> plugin on
>>>> their private computer. JGIT allowed specification of username
>>> without
>>>> password for commits.
>>>>
>>>> The Royale compiler is also required to parse the time stamps
>> in
>>> order to
>>>> inject them into the SWFs and SWCs. So I am hopeful that
>> didn't
>>> break, but
>>>> if it did, you know where to look. Also the release steps on
>> CI
>>> expect the
>>>> timestamp to be given by the RM so it can be used in Ant as
>> well.
>>> So I am
>>>> concerned about that as well. But maybe it will work or you
>> will
>>> fix it.
>>>> I don't care as long as it doesn't cost me time. But as RM
>> you are
>>>> responsible for the Ant artifacts as well. The timestamp must
>> also
>>> be
>>>> handed to the voters as well in order for them to reproduce
>> the same
>>>> binaries.
>>>>
>>>> My experience was that zlika was very responsive to fixing an
>>> issue. I'm
>>>> not sure if Maven has picked up all of the zlika changes, but
>> if
>>> not, then
>>>> one of the artifacts will not reproduce. When I offered a
>> patch to
>>> Maven,
>>>> I was told I had to go figure out their test harnesses and
>> build a
>>> set of
>>>> test cases, which I still haven't found time to do. Again, if
>> it
>>> all ends
>>>> up working and doesn't cost me time, it doesn't matter which
>> plugin
>>> we use.
>>>>
>>>> My 2 cents,
>>>> -Alex
>>>>
>>> --
>>> Carlos Rovira
>>>
>>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2a612acd9b9a446b56b508d76c01f460%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637096627978180111&sdata=TtLJ9PKWcFhxX7i0UNdSBhdV60IDl8fvIDNrXExgb%2Fk%3D&reserved=0
>>>
>>>
>>>
>>
>> --
>> Carlos Rovira
>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2a612acd9b9a446b56b508d76c01f460%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637096627978180111&sdata=TtLJ9PKWcFhxX7i0UNdSBhdV60IDl8fvIDNrXExgb%2Fk%3D&reserved=0
>>
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
right, I don't want to start a discussion about deprecating ANT. I like
Maven but I think neither Chris or I are wanting to remove ANT for
building. Just thought an option could be to not involve ANT in the release
process, but just in the users build process (that I thought is what we
really want to offer to our users), after analyzing how to simplify the
process. But if you consider we need to maintain ANT even in the release
process then we must all have in mind that we need to continue considering
it in the release process.
I want to respond this first, since I have no more time right now. I'll
come back later to this discussion to see how we can proceed.
Thanks
El lun., 18 nov. 2019 a las 10:49, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Fundamentally, I don't think we want to get rid of Ant or treat Ant as
> second-class. Some people still prefer Ant over Maven. We need to offer
> people choices. Not having a Maven-based release process (whatever that
> means) isn't the thing that new users are complaining about, IMO. You can
> try to approximate Ant-based testing with Maven, but the best test is
> simply to use Ant to build all of our code and examples.
>
> Of the 13 CI release steps, only one of them uses Ant. The first 11 are
> all about Maven. The reason there are 11 is in order to break up the steps
> to allow for building on a shared machine without credentials stored on
> them. That's because the two people who tried using a much simpler set of
> steps couldn't because of upload issues. It is the 11 Maven steps that are
> what broke in the 1 PR commit I reviewed so far. It has nothing to do with
> Ant. The current release process is not really Ant-based, IMO.
>
> You are welcome to work on a new release automation process, but If the
> voters on a release cannot use Ant to test/verify the release, then we
> won't know that Ant will work for the users. And if the invoker has to
> invoke Ant to test the Ant artifacts, then we still require Ant.
>
> IMO, the issues for building Maven snapshot artifacts are:
> 1) requiring settings-template.xml (this is apparently now fixed in the
> Flex release)
> 2) what environment variables are needed (this is apparently fixed in the
> PR)
> 3) the utils profile
>
> The issues for creating Maven release artifacts are:
> 3) the utils profile
> 4) the places we have to set-property
> 5) the upload failures
>
> It would be simpler to just be able to clone a repo, run maven
> release:branch, release:prepare, release:perform, then do the next repo,
> and the next. If this PR fixes that, that's super, because in the past we
> have invoke Maven in other ways to get the versions updated correctly by
> choosing the right profiles and set-property calls and that invites use of
> a batch script or Ant to automate that sequence. Then using Ant made it
> harder to re-start after an upload failure, so we changed to using the CI
> release steps.
>
> So if the PR has fixed all that, then maybe we can go back to using
> private computers to generate all of the artifacts. The CI release steps
> were set up so that people would not have to deal with various setup issues
> and try to dodge the upload issues. However, I think fixing the utils
> profile issue would require forking royale-compiler into two repos. Maybe
> forking royale-compiler is the right thing to do.
>
> In the end, though, you still need to clone several repos and invoke Maven
> at least 3 times for each repo to cut a release. I'm not a fan of using
> Maven as a scripting engine. Yes, I know you "can", but that doesn't mean
> you should. So, I think if we go back to building releases on private
> computers, Ant would still be the obvious way to invoke Maven 3 times on
> each repo in the right order.
>
> And, we must always ask whether this is really worth the effort. This
> thread started as making the Maven builds simpler which was great, but now
> it is starting to remind me of past discussions to make Maven primary
> which, IMO, has not been the best use of our time. You can be a fan of
> Maven all you want, just don't impose it on the rest of us. Ant and Maven
> are both useful tools and we should use them for what they do best and
> allow our users to choose. The RMs and voters will need to run both. But
> improvements to the Ant and Maven builds are definitely welcome, so thanks
> to Christofer for working on them.
>
> My 2 cents,
> -Alex
>
> On 11/18/19, 12:33 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex
>
> The Ant tasks are Java jar files, so the building has always been
> handled
> by the maven build.
> for testing, this is possible too as maven has the invoker plugin
> exactly
> for stuff like that.
> In order to actually test the tasks, some work is needed, but it's
> probably
> easier to do that than to fix the Ant based release process.
>
> Other option, that I'm starting to thing could be more appropriate:
> While
> we want people build with both Maven and ANT on its own, that does not
> necessarily imply to release with ANT too. The other posible option is
> to
> make release, that's a very concrete task to be only a task for maven,
> and
> people testing the RC must use Maven as part of the requirements to
> test
> the release. I think this should be something totally licit if we want
> to
> ease the problem and make others capable of doing this task in a more
> simplified process.
>
>
>
>
> El lun., 18 nov. 2019 a las 0:23, Alex Harui (<aharui@adobe.com.invalid
> >)
> escribió:
>
> > If you don't use Ant, how can you build and test the Ant tasks?
> >
> > -Alex
> >
> > On 11/17/19, 3:43 AM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> >
> > Hi Alex,
> >
> > first of all I understand completely your concerns about this
> changes
> > since
> > I now the time and work it cost to you. At the time you worked
> on this
> > there was not all this new maven enhancements that allow us to
> simplify
> > things. I strongly believe that all this changes can carry us a
> less
> > painful build and release process if we (mostly I, supported by
> Chris)
> > can
> > overcome the CI changes to work with the new changes. All this
> will
> > ease
> > things for people coming that should be other priority for us. I
> think
> > this
> > is the main barrier for newcomers and making thing ultra easy
> can allow
> > more people coming to Royale. This is all a bet, that we think
> can
> > reach a
> > good point. We we need to solve things in chunks if we want to
> succeed.
> >
> > But, I want to state clearly here, that if you finally don't see
> a
> > good end
> > for this, you can veto this change and we can roll back to the
> previous
> > process. I think we can reach to simplify all and make releases
> more
> > easy
> > to do, but it will imply in some parts changes that we need to
> agree
> > that
> > can be done. For all this we need to try to be open mind.
> >
> > So instead of trying to expose ways to solve concrete parts
> already
> > exposed, I want to ask about how we can simplify the release
> process:
> >
> > We have Maven and ANT as first citizens for build process, so
> users
> > can use
> > what they want. But my question here's, do we need to use both
> in the
> > release process? From what I understand Apache only requires us
> to use
> > one
> > of them for releasing process. So we could just rely on the maven
> > process
> > that are just few lines (already posted early in this thread).
> Copy
> > here to
> > notice the simplicity:
> >
> > Ideally releasing a part of Royale is just a 2-3 step process:
> >
> > - royale-compiler:
> > - mvn release:prepare -DautoversionSubmodules=true
> > - mvn release:perform
> > - royale-typedefs:
> > - update the pom.xml: royale.compiler.version to the new
> released
> > version
> > - mvn release:prepare -DautoversionSubmodules=true
> > - mvn release:perform
> > - royale-asjs:
> > - update the pom.xml: royale.compiler.version and
> > royale.typedefs.version to the new released version
> > - mvn release:prepare -DautoversionSubmodules=true
> > - mvn release:perform
> >
> >
> > In doing in this way, we'll streamline the release process and
> will not
> > need to do anything more. Just that few lines. And that means
> hopefully
> > make our release process a more tiny process in time to all of
> us,
> > while
> > users that wants to build with ANT can do it without problem.
> Can we
> > agree
> > with this? Let me know if I'm wrong with this. Notice that my
> focus is
> > to
> > try to get to the easiest way possible to build and release we
> can get.
> >
> > To not create a very long thread. I'll left this here so we can
> see
> > what
> > you guys think about it.
> >
> > Thanks in advance
> >
> > Carlos
> >
> >
> >
> > El dom., 17 nov. 2019 a las 0:06, Alex Harui
> (<aharui@adobe.com.invalid
> > >)
> > escribió:
> >
> > > I'm pretty sure I added JGIT in order to do the release on the
> CI
> > server.
> > > See change 1aa2b16 in royale-compiler on Feb 11, 2019. The
> reason
> > the CI
> > > needs JGIT is because the regular Maven git support seemed to
> expect
> > that
> > > you had a private key registered since most folks run the
> release
> > plugin on
> > > their private computer. JGIT allowed specification of username
> > without
> > > password for commits.
> > >
> > > The Royale compiler is also required to parse the time stamps
> in
> > order to
> > > inject them into the SWFs and SWCs. So I am hopeful that
> didn't
> > break, but
> > > if it did, you know where to look. Also the release steps on
> CI
> > expect the
> > > timestamp to be given by the RM so it can be used in Ant as
> well.
> > So I am
> > > concerned about that as well. But maybe it will work or you
> will
> > fix it.
> > > I don't care as long as it doesn't cost me time. But as RM
> you are
> > > responsible for the Ant artifacts as well. The timestamp must
> also
> > be
> > > handed to the voters as well in order for them to reproduce
> the same
> > > binaries.
> > >
> > > My experience was that zlika was very responsive to fixing an
> > issue. I'm
> > > not sure if Maven has picked up all of the zlika changes, but
> if
> > not, then
> > > one of the artifacts will not reproduce. When I offered a
> patch to
> > Maven,
> > > I was told I had to go figure out their test harnesses and
> build a
> > set of
> > > test cases, which I still haven't found time to do. Again, if
> it
> > all ends
> > > up working and doesn't cost me time, it doesn't matter which
> plugin
> > we use.
> > >
> > > My 2 cents,
> > > -Alex
> > >
> > --
> > Carlos Rovira
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2a612acd9b9a446b56b508d76c01f460%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637096627978180111&sdata=TtLJ9PKWcFhxX7i0UNdSBhdV60IDl8fvIDNrXExgb%2Fk%3D&reserved=0
> >
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2a612acd9b9a446b56b508d76c01f460%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637096627978180111&sdata=TtLJ9PKWcFhxX7i0UNdSBhdV60IDl8fvIDNrXExgb%2Fk%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Piotr Zarzycki <pi...@gmail.com>.
Hi Alex,
It is the 11 Maven steps that are what broke in the 1 PR commit I reviewed
> so far.
Are you saying that we have now 11 steps broken ? Am I understanding this
correctly ?
Thanks,
Piotr
pon., 18 lis 2019 o 10:49 Alex Harui <ah...@adobe.com.invalid> napisał(a):
> Fundamentally, I don't think we want to get rid of Ant or treat Ant as
> second-class. Some people still prefer Ant over Maven. We need to offer
> people choices. Not having a Maven-based release process (whatever that
> means) isn't the thing that new users are complaining about, IMO. You can
> try to approximate Ant-based testing with Maven, but the best test is
> simply to use Ant to build all of our code and examples.
>
> Of the 13 CI release steps, only one of them uses Ant. The first 11 are
> all about Maven. The reason there are 11 is in order to break up the steps
> to allow for building on a shared machine without credentials stored on
> them. That's because the two people who tried using a much simpler set of
> steps couldn't because of upload issues. It is the 11 Maven steps that are
> what broke in the 1 PR commit I reviewed so far. It has nothing to do with
> Ant. The current release process is not really Ant-based, IMO.
>
> You are welcome to work on a new release automation process, but If the
> voters on a release cannot use Ant to test/verify the release, then we
> won't know that Ant will work for the users. And if the invoker has to
> invoke Ant to test the Ant artifacts, then we still require Ant.
>
> IMO, the issues for building Maven snapshot artifacts are:
> 1) requiring settings-template.xml (this is apparently now fixed in the
> Flex release)
> 2) what environment variables are needed (this is apparently fixed in the
> PR)
> 3) the utils profile
>
> The issues for creating Maven release artifacts are:
> 3) the utils profile
> 4) the places we have to set-property
> 5) the upload failures
>
> It would be simpler to just be able to clone a repo, run maven
> release:branch, release:prepare, release:perform, then do the next repo,
> and the next. If this PR fixes that, that's super, because in the past we
> have invoke Maven in other ways to get the versions updated correctly by
> choosing the right profiles and set-property calls and that invites use of
> a batch script or Ant to automate that sequence. Then using Ant made it
> harder to re-start after an upload failure, so we changed to using the CI
> release steps.
>
> So if the PR has fixed all that, then maybe we can go back to using
> private computers to generate all of the artifacts. The CI release steps
> were set up so that people would not have to deal with various setup issues
> and try to dodge the upload issues. However, I think fixing the utils
> profile issue would require forking royale-compiler into two repos. Maybe
> forking royale-compiler is the right thing to do.
>
> In the end, though, you still need to clone several repos and invoke Maven
> at least 3 times for each repo to cut a release. I'm not a fan of using
> Maven as a scripting engine. Yes, I know you "can", but that doesn't mean
> you should. So, I think if we go back to building releases on private
> computers, Ant would still be the obvious way to invoke Maven 3 times on
> each repo in the right order.
>
> And, we must always ask whether this is really worth the effort. This
> thread started as making the Maven builds simpler which was great, but now
> it is starting to remind me of past discussions to make Maven primary
> which, IMO, has not been the best use of our time. You can be a fan of
> Maven all you want, just don't impose it on the rest of us. Ant and Maven
> are both useful tools and we should use them for what they do best and
> allow our users to choose. The RMs and voters will need to run both. But
> improvements to the Ant and Maven builds are definitely welcome, so thanks
> to Christofer for working on them.
>
> My 2 cents,
> -Alex
>
> On 11/18/19, 12:33 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex
>
> The Ant tasks are Java jar files, so the building has always been
> handled
> by the maven build.
> for testing, this is possible too as maven has the invoker plugin
> exactly
> for stuff like that.
> In order to actually test the tasks, some work is needed, but it's
> probably
> easier to do that than to fix the Ant based release process.
>
> Other option, that I'm starting to thing could be more appropriate:
> While
> we want people build with both Maven and ANT on its own, that does not
> necessarily imply to release with ANT too. The other posible option is
> to
> make release, that's a very concrete task to be only a task for maven,
> and
> people testing the RC must use Maven as part of the requirements to
> test
> the release. I think this should be something totally licit if we want
> to
> ease the problem and make others capable of doing this task in a more
> simplified process.
>
>
>
>
> El lun., 18 nov. 2019 a las 0:23, Alex Harui (<aharui@adobe.com.invalid
> >)
> escribió:
>
> > If you don't use Ant, how can you build and test the Ant tasks?
> >
> > -Alex
> >
> > On 11/17/19, 3:43 AM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> >
> > Hi Alex,
> >
> > first of all I understand completely your concerns about this
> changes
> > since
> > I now the time and work it cost to you. At the time you worked
> on this
> > there was not all this new maven enhancements that allow us to
> simplify
> > things. I strongly believe that all this changes can carry us a
> less
> > painful build and release process if we (mostly I, supported by
> Chris)
> > can
> > overcome the CI changes to work with the new changes. All this
> will
> > ease
> > things for people coming that should be other priority for us. I
> think
> > this
> > is the main barrier for newcomers and making thing ultra easy
> can allow
> > more people coming to Royale. This is all a bet, that we think
> can
> > reach a
> > good point. We we need to solve things in chunks if we want to
> succeed.
> >
> > But, I want to state clearly here, that if you finally don't see
> a
> > good end
> > for this, you can veto this change and we can roll back to the
> previous
> > process. I think we can reach to simplify all and make releases
> more
> > easy
> > to do, but it will imply in some parts changes that we need to
> agree
> > that
> > can be done. For all this we need to try to be open mind.
> >
> > So instead of trying to expose ways to solve concrete parts
> already
> > exposed, I want to ask about how we can simplify the release
> process:
> >
> > We have Maven and ANT as first citizens for build process, so
> users
> > can use
> > what they want. But my question here's, do we need to use both
> in the
> > release process? From what I understand Apache only requires us
> to use
> > one
> > of them for releasing process. So we could just rely on the maven
> > process
> > that are just few lines (already posted early in this thread).
> Copy
> > here to
> > notice the simplicity:
> >
> > Ideally releasing a part of Royale is just a 2-3 step process:
> >
> > - royale-compiler:
> > - mvn release:prepare -DautoversionSubmodules=true
> > - mvn release:perform
> > - royale-typedefs:
> > - update the pom.xml: royale.compiler.version to the new
> released
> > version
> > - mvn release:prepare -DautoversionSubmodules=true
> > - mvn release:perform
> > - royale-asjs:
> > - update the pom.xml: royale.compiler.version and
> > royale.typedefs.version to the new released version
> > - mvn release:prepare -DautoversionSubmodules=true
> > - mvn release:perform
> >
> >
> > In doing in this way, we'll streamline the release process and
> will not
> > need to do anything more. Just that few lines. And that means
> hopefully
> > make our release process a more tiny process in time to all of
> us,
> > while
> > users that wants to build with ANT can do it without problem.
> Can we
> > agree
> > with this? Let me know if I'm wrong with this. Notice that my
> focus is
> > to
> > try to get to the easiest way possible to build and release we
> can get.
> >
> > To not create a very long thread. I'll left this here so we can
> see
> > what
> > you guys think about it.
> >
> > Thanks in advance
> >
> > Carlos
> >
> >
> >
> > El dom., 17 nov. 2019 a las 0:06, Alex Harui
> (<aharui@adobe.com.invalid
> > >)
> > escribió:
> >
> > > I'm pretty sure I added JGIT in order to do the release on the
> CI
> > server.
> > > See change 1aa2b16 in royale-compiler on Feb 11, 2019. The
> reason
> > the CI
> > > needs JGIT is because the regular Maven git support seemed to
> expect
> > that
> > > you had a private key registered since most folks run the
> release
> > plugin on
> > > their private computer. JGIT allowed specification of username
> > without
> > > password for commits.
> > >
> > > The Royale compiler is also required to parse the time stamps
> in
> > order to
> > > inject them into the SWFs and SWCs. So I am hopeful that
> didn't
> > break, but
> > > if it did, you know where to look. Also the release steps on
> CI
> > expect the
> > > timestamp to be given by the RM so it can be used in Ant as
> well.
> > So I am
> > > concerned about that as well. But maybe it will work or you
> will
> > fix it.
> > > I don't care as long as it doesn't cost me time. But as RM
> you are
> > > responsible for the Ant artifacts as well. The timestamp must
> also
> > be
> > > handed to the voters as well in order for them to reproduce
> the same
> > > binaries.
> > >
> > > My experience was that zlika was very responsive to fixing an
> > issue. I'm
> > > not sure if Maven has picked up all of the zlika changes, but
> if
> > not, then
> > > one of the artifacts will not reproduce. When I offered a
> patch to
> > Maven,
> > > I was told I had to go figure out their test harnesses and
> build a
> > set of
> > > test cases, which I still haven't found time to do. Again, if
> it
> > all ends
> > > up working and doesn't cost me time, it doesn't matter which
> plugin
> > we use.
> > >
> > > My 2 cents,
> > > -Alex
> > >
> > --
> > Carlos Rovira
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2a612acd9b9a446b56b508d76c01f460%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637096627978180111&sdata=TtLJ9PKWcFhxX7i0UNdSBhdV60IDl8fvIDNrXExgb%2Fk%3D&reserved=0
> >
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2a612acd9b9a446b56b508d76c01f460%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637096627978180111&sdata=TtLJ9PKWcFhxX7i0UNdSBhdV60IDl8fvIDNrXExgb%2Fk%3D&reserved=0
>
>
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Fundamentally, I don't think we want to get rid of Ant or treat Ant as second-class. Some people still prefer Ant over Maven. We need to offer people choices. Not having a Maven-based release process (whatever that means) isn't the thing that new users are complaining about, IMO. You can try to approximate Ant-based testing with Maven, but the best test is simply to use Ant to build all of our code and examples.
Of the 13 CI release steps, only one of them uses Ant. The first 11 are all about Maven. The reason there are 11 is in order to break up the steps to allow for building on a shared machine without credentials stored on them. That's because the two people who tried using a much simpler set of steps couldn't because of upload issues. It is the 11 Maven steps that are what broke in the 1 PR commit I reviewed so far. It has nothing to do with Ant. The current release process is not really Ant-based, IMO.
You are welcome to work on a new release automation process, but If the voters on a release cannot use Ant to test/verify the release, then we won't know that Ant will work for the users. And if the invoker has to invoke Ant to test the Ant artifacts, then we still require Ant.
IMO, the issues for building Maven snapshot artifacts are:
1) requiring settings-template.xml (this is apparently now fixed in the Flex release)
2) what environment variables are needed (this is apparently fixed in the PR)
3) the utils profile
The issues for creating Maven release artifacts are:
3) the utils profile
4) the places we have to set-property
5) the upload failures
It would be simpler to just be able to clone a repo, run maven release:branch, release:prepare, release:perform, then do the next repo, and the next. If this PR fixes that, that's super, because in the past we have invoke Maven in other ways to get the versions updated correctly by choosing the right profiles and set-property calls and that invites use of a batch script or Ant to automate that sequence. Then using Ant made it harder to re-start after an upload failure, so we changed to using the CI release steps.
So if the PR has fixed all that, then maybe we can go back to using private computers to generate all of the artifacts. The CI release steps were set up so that people would not have to deal with various setup issues and try to dodge the upload issues. However, I think fixing the utils profile issue would require forking royale-compiler into two repos. Maybe forking royale-compiler is the right thing to do.
In the end, though, you still need to clone several repos and invoke Maven at least 3 times for each repo to cut a release. I'm not a fan of using Maven as a scripting engine. Yes, I know you "can", but that doesn't mean you should. So, I think if we go back to building releases on private computers, Ant would still be the obvious way to invoke Maven 3 times on each repo in the right order.
And, we must always ask whether this is really worth the effort. This thread started as making the Maven builds simpler which was great, but now it is starting to remind me of past discussions to make Maven primary which, IMO, has not been the best use of our time. You can be a fan of Maven all you want, just don't impose it on the rest of us. Ant and Maven are both useful tools and we should use them for what they do best and allow our users to choose. The RMs and voters will need to run both. But improvements to the Ant and Maven builds are definitely welcome, so thanks to Christofer for working on them.
My 2 cents,
-Alex
On 11/18/19, 12:33 AM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex
The Ant tasks are Java jar files, so the building has always been handled
by the maven build.
for testing, this is possible too as maven has the invoker plugin exactly
for stuff like that.
In order to actually test the tasks, some work is needed, but it's probably
easier to do that than to fix the Ant based release process.
Other option, that I'm starting to thing could be more appropriate: While
we want people build with both Maven and ANT on its own, that does not
necessarily imply to release with ANT too. The other posible option is to
make release, that's a very concrete task to be only a task for maven, and
people testing the RC must use Maven as part of the requirements to test
the release. I think this should be something totally licit if we want to
ease the problem and make others capable of doing this task in a more
simplified process.
El lun., 18 nov. 2019 a las 0:23, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> If you don't use Ant, how can you build and test the Ant tasks?
>
> -Alex
>
> On 11/17/19, 3:43 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex,
>
> first of all I understand completely your concerns about this changes
> since
> I now the time and work it cost to you. At the time you worked on this
> there was not all this new maven enhancements that allow us to simplify
> things. I strongly believe that all this changes can carry us a less
> painful build and release process if we (mostly I, supported by Chris)
> can
> overcome the CI changes to work with the new changes. All this will
> ease
> things for people coming that should be other priority for us. I think
> this
> is the main barrier for newcomers and making thing ultra easy can allow
> more people coming to Royale. This is all a bet, that we think can
> reach a
> good point. We we need to solve things in chunks if we want to succeed.
>
> But, I want to state clearly here, that if you finally don't see a
> good end
> for this, you can veto this change and we can roll back to the previous
> process. I think we can reach to simplify all and make releases more
> easy
> to do, but it will imply in some parts changes that we need to agree
> that
> can be done. For all this we need to try to be open mind.
>
> So instead of trying to expose ways to solve concrete parts already
> exposed, I want to ask about how we can simplify the release process:
>
> We have Maven and ANT as first citizens for build process, so users
> can use
> what they want. But my question here's, do we need to use both in the
> release process? From what I understand Apache only requires us to use
> one
> of them for releasing process. So we could just rely on the maven
> process
> that are just few lines (already posted early in this thread). Copy
> here to
> notice the simplicity:
>
> Ideally releasing a part of Royale is just a 2-3 step process:
>
> - royale-compiler:
> - mvn release:prepare -DautoversionSubmodules=true
> - mvn release:perform
> - royale-typedefs:
> - update the pom.xml: royale.compiler.version to the new released
> version
> - mvn release:prepare -DautoversionSubmodules=true
> - mvn release:perform
> - royale-asjs:
> - update the pom.xml: royale.compiler.version and
> royale.typedefs.version to the new released version
> - mvn release:prepare -DautoversionSubmodules=true
> - mvn release:perform
>
>
> In doing in this way, we'll streamline the release process and will not
> need to do anything more. Just that few lines. And that means hopefully
> make our release process a more tiny process in time to all of us,
> while
> users that wants to build with ANT can do it without problem. Can we
> agree
> with this? Let me know if I'm wrong with this. Notice that my focus is
> to
> try to get to the easiest way possible to build and release we can get.
>
> To not create a very long thread. I'll left this here so we can see
> what
> you guys think about it.
>
> Thanks in advance
>
> Carlos
>
>
>
> El dom., 17 nov. 2019 a las 0:06, Alex Harui (<aharui@adobe.com.invalid
> >)
> escribió:
>
> > I'm pretty sure I added JGIT in order to do the release on the CI
> server.
> > See change 1aa2b16 in royale-compiler on Feb 11, 2019. The reason
> the CI
> > needs JGIT is because the regular Maven git support seemed to expect
> that
> > you had a private key registered since most folks run the release
> plugin on
> > their private computer. JGIT allowed specification of username
> without
> > password for commits.
> >
> > The Royale compiler is also required to parse the time stamps in
> order to
> > inject them into the SWFs and SWCs. So I am hopeful that didn't
> break, but
> > if it did, you know where to look. Also the release steps on CI
> expect the
> > timestamp to be given by the RM so it can be used in Ant as well.
> So I am
> > concerned about that as well. But maybe it will work or you will
> fix it.
> > I don't care as long as it doesn't cost me time. But as RM you are
> > responsible for the Ant artifacts as well. The timestamp must also
> be
> > handed to the voters as well in order for them to reproduce the same
> > binaries.
> >
> > My experience was that zlika was very responsive to fixing an
> issue. I'm
> > not sure if Maven has picked up all of the zlika changes, but if
> not, then
> > one of the artifacts will not reproduce. When I offered a patch to
> Maven,
> > I was told I had to go figure out their test harnesses and build a
> set of
> > test cases, which I still haven't found time to do. Again, if it
> all ends
> > up working and doesn't cost me time, it doesn't matter which plugin
> we use.
> >
> > My 2 cents,
> > -Alex
> >
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2a612acd9b9a446b56b508d76c01f460%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637096627978180111&sdata=TtLJ9PKWcFhxX7i0UNdSBhdV60IDl8fvIDNrXExgb%2Fk%3D&reserved=0
>
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2a612acd9b9a446b56b508d76c01f460%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637096627978180111&sdata=TtLJ9PKWcFhxX7i0UNdSBhdV60IDl8fvIDNrXExgb%2Fk%3D&reserved=0
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex
The Ant tasks are Java jar files, so the building has always been handled
by the maven build.
for testing, this is possible too as maven has the invoker plugin exactly
for stuff like that.
In order to actually test the tasks, some work is needed, but it's probably
easier to do that than to fix the Ant based release process.
Other option, that I'm starting to thing could be more appropriate: While
we want people build with both Maven and ANT on its own, that does not
necessarily imply to release with ANT too. The other posible option is to
make release, that's a very concrete task to be only a task for maven, and
people testing the RC must use Maven as part of the requirements to test
the release. I think this should be something totally licit if we want to
ease the problem and make others capable of doing this task in a more
simplified process.
El lun., 18 nov. 2019 a las 0:23, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> If you don't use Ant, how can you build and test the Ant tasks?
>
> -Alex
>
> On 11/17/19, 3:43 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex,
>
> first of all I understand completely your concerns about this changes
> since
> I now the time and work it cost to you. At the time you worked on this
> there was not all this new maven enhancements that allow us to simplify
> things. I strongly believe that all this changes can carry us a less
> painful build and release process if we (mostly I, supported by Chris)
> can
> overcome the CI changes to work with the new changes. All this will
> ease
> things for people coming that should be other priority for us. I think
> this
> is the main barrier for newcomers and making thing ultra easy can allow
> more people coming to Royale. This is all a bet, that we think can
> reach a
> good point. We we need to solve things in chunks if we want to succeed.
>
> But, I want to state clearly here, that if you finally don't see a
> good end
> for this, you can veto this change and we can roll back to the previous
> process. I think we can reach to simplify all and make releases more
> easy
> to do, but it will imply in some parts changes that we need to agree
> that
> can be done. For all this we need to try to be open mind.
>
> So instead of trying to expose ways to solve concrete parts already
> exposed, I want to ask about how we can simplify the release process:
>
> We have Maven and ANT as first citizens for build process, so users
> can use
> what they want. But my question here's, do we need to use both in the
> release process? From what I understand Apache only requires us to use
> one
> of them for releasing process. So we could just rely on the maven
> process
> that are just few lines (already posted early in this thread). Copy
> here to
> notice the simplicity:
>
> Ideally releasing a part of Royale is just a 2-3 step process:
>
> - royale-compiler:
> - mvn release:prepare -DautoversionSubmodules=true
> - mvn release:perform
> - royale-typedefs:
> - update the pom.xml: royale.compiler.version to the new released
> version
> - mvn release:prepare -DautoversionSubmodules=true
> - mvn release:perform
> - royale-asjs:
> - update the pom.xml: royale.compiler.version and
> royale.typedefs.version to the new released version
> - mvn release:prepare -DautoversionSubmodules=true
> - mvn release:perform
>
>
> In doing in this way, we'll streamline the release process and will not
> need to do anything more. Just that few lines. And that means hopefully
> make our release process a more tiny process in time to all of us,
> while
> users that wants to build with ANT can do it without problem. Can we
> agree
> with this? Let me know if I'm wrong with this. Notice that my focus is
> to
> try to get to the easiest way possible to build and release we can get.
>
> To not create a very long thread. I'll left this here so we can see
> what
> you guys think about it.
>
> Thanks in advance
>
> Carlos
>
>
>
> El dom., 17 nov. 2019 a las 0:06, Alex Harui (<aharui@adobe.com.invalid
> >)
> escribió:
>
> > I'm pretty sure I added JGIT in order to do the release on the CI
> server.
> > See change 1aa2b16 in royale-compiler on Feb 11, 2019. The reason
> the CI
> > needs JGIT is because the regular Maven git support seemed to expect
> that
> > you had a private key registered since most folks run the release
> plugin on
> > their private computer. JGIT allowed specification of username
> without
> > password for commits.
> >
> > The Royale compiler is also required to parse the time stamps in
> order to
> > inject them into the SWFs and SWCs. So I am hopeful that didn't
> break, but
> > if it did, you know where to look. Also the release steps on CI
> expect the
> > timestamp to be given by the RM so it can be used in Ant as well.
> So I am
> > concerned about that as well. But maybe it will work or you will
> fix it.
> > I don't care as long as it doesn't cost me time. But as RM you are
> > responsible for the Ant artifacts as well. The timestamp must also
> be
> > handed to the voters as well in order for them to reproduce the same
> > binaries.
> >
> > My experience was that zlika was very responsive to fixing an
> issue. I'm
> > not sure if Maven has picked up all of the zlika changes, but if
> not, then
> > one of the artifacts will not reproduce. When I offered a patch to
> Maven,
> > I was told I had to go figure out their test harnesses and build a
> set of
> > test cases, which I still haven't found time to do. Again, if it
> all ends
> > up working and doesn't cost me time, it doesn't matter which plugin
> we use.
> >
> > My 2 cents,
> > -Alex
> >
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C142b2a01c6644fc64ae708d76b53553d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637095877977257465&sdata=w%2F6BZDCNaHtC7Y3NgEgSon4iLs1JjDcWuXjbKkxaZpM%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Alex Harui <ah...@adobe.com.INVALID>.
If you don't use Ant, how can you build and test the Ant tasks?
-Alex
On 11/17/19, 3:43 AM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex,
first of all I understand completely your concerns about this changes since
I now the time and work it cost to you. At the time you worked on this
there was not all this new maven enhancements that allow us to simplify
things. I strongly believe that all this changes can carry us a less
painful build and release process if we (mostly I, supported by Chris) can
overcome the CI changes to work with the new changes. All this will ease
things for people coming that should be other priority for us. I think this
is the main barrier for newcomers and making thing ultra easy can allow
more people coming to Royale. This is all a bet, that we think can reach a
good point. We we need to solve things in chunks if we want to succeed.
But, I want to state clearly here, that if you finally don't see a good end
for this, you can veto this change and we can roll back to the previous
process. I think we can reach to simplify all and make releases more easy
to do, but it will imply in some parts changes that we need to agree that
can be done. For all this we need to try to be open mind.
So instead of trying to expose ways to solve concrete parts already
exposed, I want to ask about how we can simplify the release process:
We have Maven and ANT as first citizens for build process, so users can use
what they want. But my question here's, do we need to use both in the
release process? From what I understand Apache only requires us to use one
of them for releasing process. So we could just rely on the maven process
that are just few lines (already posted early in this thread). Copy here to
notice the simplicity:
Ideally releasing a part of Royale is just a 2-3 step process:
- royale-compiler:
- mvn release:prepare -DautoversionSubmodules=true
- mvn release:perform
- royale-typedefs:
- update the pom.xml: royale.compiler.version to the new released
version
- mvn release:prepare -DautoversionSubmodules=true
- mvn release:perform
- royale-asjs:
- update the pom.xml: royale.compiler.version and
royale.typedefs.version to the new released version
- mvn release:prepare -DautoversionSubmodules=true
- mvn release:perform
In doing in this way, we'll streamline the release process and will not
need to do anything more. Just that few lines. And that means hopefully
make our release process a more tiny process in time to all of us, while
users that wants to build with ANT can do it without problem. Can we agree
with this? Let me know if I'm wrong with this. Notice that my focus is to
try to get to the easiest way possible to build and release we can get.
To not create a very long thread. I'll left this here so we can see what
you guys think about it.
Thanks in advance
Carlos
El dom., 17 nov. 2019 a las 0:06, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> I'm pretty sure I added JGIT in order to do the release on the CI server.
> See change 1aa2b16 in royale-compiler on Feb 11, 2019. The reason the CI
> needs JGIT is because the regular Maven git support seemed to expect that
> you had a private key registered since most folks run the release plugin on
> their private computer. JGIT allowed specification of username without
> password for commits.
>
> The Royale compiler is also required to parse the time stamps in order to
> inject them into the SWFs and SWCs. So I am hopeful that didn't break, but
> if it did, you know where to look. Also the release steps on CI expect the
> timestamp to be given by the RM so it can be used in Ant as well. So I am
> concerned about that as well. But maybe it will work or you will fix it.
> I don't care as long as it doesn't cost me time. But as RM you are
> responsible for the Ant artifacts as well. The timestamp must also be
> handed to the voters as well in order for them to reproduce the same
> binaries.
>
> My experience was that zlika was very responsive to fixing an issue. I'm
> not sure if Maven has picked up all of the zlika changes, but if not, then
> one of the artifacts will not reproduce. When I offered a patch to Maven,
> I was told I had to go figure out their test harnesses and build a set of
> test cases, which I still haven't found time to do. Again, if it all ends
> up working and doesn't cost me time, it doesn't matter which plugin we use.
>
> My 2 cents,
> -Alex
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C142b2a01c6644fc64ae708d76b53553d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637095877977257465&sdata=w%2F6BZDCNaHtC7Y3NgEgSon4iLs1JjDcWuXjbKkxaZpM%3D&reserved=0
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
first of all I understand completely your concerns about this changes since
I now the time and work it cost to you. At the time you worked on this
there was not all this new maven enhancements that allow us to simplify
things. I strongly believe that all this changes can carry us a less
painful build and release process if we (mostly I, supported by Chris) can
overcome the CI changes to work with the new changes. All this will ease
things for people coming that should be other priority for us. I think this
is the main barrier for newcomers and making thing ultra easy can allow
more people coming to Royale. This is all a bet, that we think can reach a
good point. We we need to solve things in chunks if we want to succeed.
But, I want to state clearly here, that if you finally don't see a good end
for this, you can veto this change and we can roll back to the previous
process. I think we can reach to simplify all and make releases more easy
to do, but it will imply in some parts changes that we need to agree that
can be done. For all this we need to try to be open mind.
So instead of trying to expose ways to solve concrete parts already
exposed, I want to ask about how we can simplify the release process:
We have Maven and ANT as first citizens for build process, so users can use
what they want. But my question here's, do we need to use both in the
release process? From what I understand Apache only requires us to use one
of them for releasing process. So we could just rely on the maven process
that are just few lines (already posted early in this thread). Copy here to
notice the simplicity:
Ideally releasing a part of Royale is just a 2-3 step process:
- royale-compiler:
- mvn release:prepare -DautoversionSubmodules=true
- mvn release:perform
- royale-typedefs:
- update the pom.xml: royale.compiler.version to the new released
version
- mvn release:prepare -DautoversionSubmodules=true
- mvn release:perform
- royale-asjs:
- update the pom.xml: royale.compiler.version and
royale.typedefs.version to the new released version
- mvn release:prepare -DautoversionSubmodules=true
- mvn release:perform
In doing in this way, we'll streamline the release process and will not
need to do anything more. Just that few lines. And that means hopefully
make our release process a more tiny process in time to all of us, while
users that wants to build with ANT can do it without problem. Can we agree
with this? Let me know if I'm wrong with this. Notice that my focus is to
try to get to the easiest way possible to build and release we can get.
To not create a very long thread. I'll left this here so we can see what
you guys think about it.
Thanks in advance
Carlos
El dom., 17 nov. 2019 a las 0:06, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> I'm pretty sure I added JGIT in order to do the release on the CI server.
> See change 1aa2b16 in royale-compiler on Feb 11, 2019. The reason the CI
> needs JGIT is because the regular Maven git support seemed to expect that
> you had a private key registered since most folks run the release plugin on
> their private computer. JGIT allowed specification of username without
> password for commits.
>
> The Royale compiler is also required to parse the time stamps in order to
> inject them into the SWFs and SWCs. So I am hopeful that didn't break, but
> if it did, you know where to look. Also the release steps on CI expect the
> timestamp to be given by the RM so it can be used in Ant as well. So I am
> concerned about that as well. But maybe it will work or you will fix it.
> I don't care as long as it doesn't cost me time. But as RM you are
> responsible for the Ant artifacts as well. The timestamp must also be
> handed to the voters as well in order for them to reproduce the same
> binaries.
>
> My experience was that zlika was very responsive to fixing an issue. I'm
> not sure if Maven has picked up all of the zlika changes, but if not, then
> one of the artifacts will not reproduce. When I offered a patch to Maven,
> I was told I had to go figure out their test harnesses and build a set of
> test cases, which I still haven't found time to do. Again, if it all ends
> up working and doesn't cost me time, it doesn't matter which plugin we use.
>
> My 2 cents,
> -Alex
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I'm pretty sure I added JGIT in order to do the release on the CI server. See change 1aa2b16 in royale-compiler on Feb 11, 2019. The reason the CI needs JGIT is because the regular Maven git support seemed to expect that you had a private key registered since most folks run the release plugin on their private computer. JGIT allowed specification of username without password for commits.
The Royale compiler is also required to parse the time stamps in order to inject them into the SWFs and SWCs. So I am hopeful that didn't break, but if it did, you know where to look. Also the release steps on CI expect the timestamp to be given by the RM so it can be used in Ant as well. So I am concerned about that as well. But maybe it will work or you will fix it. I don't care as long as it doesn't cost me time. But as RM you are responsible for the Ant artifacts as well. The timestamp must also be handed to the voters as well in order for them to reproduce the same binaries.
My experience was that zlika was very responsive to fixing an issue. I'm not sure if Maven has picked up all of the zlika changes, but if not, then one of the artifacts will not reproduce. When I offered a patch to Maven, I was told I had to go figure out their test harnesses and build a set of test cases, which I still haven't found time to do. Again, if it all ends up working and doesn't cost me time, it doesn't matter which plugin we use.
My 2 cents,
-Alex
On 11/16/19, 7:05 AM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Piotr,
thanks, I'll do my best to try to fix CI issues. I count with you and Alex.
About things Alex comment:
Chris removed JGit because he had to add that when initially setting up the
Maven build (Sort of 4-5 years ago) , git support was very simple and
broken.
The release plugin has matured that GIT now is a first class citizen. He
removed all the plugins, executions and configuration options that are no
longer needed in order to simplify things.
So we were suffering a lot due to things that was not completely done or
that currently are obsolete, so all the changes will use current official
maven ways to solve things. I think is worth it to check whatever problem
it could arise so saving headaches for the future since we'll be in the
"right paths". So, it seems that we don’t need JGIT to do a release, and
removing a piece to do the same seems always a good way to go since we
simplify things in the process :).
Regarding the timestamps … Chris had a look at what was happening inside
before changing things … the original provided a timestamp string together
with the format for being parsed.
In the plugin itself it uses the format and the string to parse to a
standard Date object. The release plugin now should automatically add a
timestamp in a pre-defined property (project.build.outputTimestamp) into
the pom as part of the release process, which is then removed again when
changing the poms the second time to the next development version.
So only if you checkout the git revision tagged with the release, this
property is included and only if this is included the reproducible builds
kick in (Doesn’t make sense to make reproducible snapshot versions).
He adjusted
the plugin configuration to use that format and property instead of the old
ones. In the plugin both are converted to a normal Java Date object … so
nothing should be changed.
About current reproducible builds, are using an external plugin to patch
the jars generated by the build to be reproducible (io.github.zlika:
reproducible-build-maven-plugin) after they have been built by the normal
plugins. Chris changed to the official reproducible-build support which are
directly supported by the maven core team. That seems a better future path
to use official maven supported way right?.
Thanks
El sáb., 16 nov. 2019 a las 12:19, Piotr Zarzycki (<
piotrzarzycki21@gmail.com>) escribió:
> Hi Carlos,
>
> In my opinion you should try to do whole release process without merging
> PRs. - as an exercise. Next having all knowledge merge PRs if they are
> touching release process and start exercising again.
>
> You did that too early.
>
> We will see how much more time will you have to spend on this, because if
> that.
>
> Let me know if you need assistance. We can have call and try to go with
> stuff.
>
> Thanks,
> Piotr
>
>
>
>
>
> On Sat, Nov 16, 2019, 10:47 AM Carlos Rovira <ca...@apache.org>
> wrote:
>
> > Hi Alex,
> >
> > ok I think is a good idea. I'll merge it now, so we can try the following
> > days and see any issue it can arise.
> > Thanks
> >
> > Carlos
> >
> >
> >
> > El sáb., 16 nov. 2019 a las 0:29, Alex Harui (<aharui@adobe.com.invalid
> >)
> > escribió:
> >
> > > Well, you can always merge the PR and see if anything blows up and
> revert
> > > if it does. The only things I saw so far will affect the release steps
> > but
> > > probably not the nightly builds.
> > >
> > > -Alex
> > >
> > > On 11/15/19, 12:21 PM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> > >
> > > Hi Alex,
> > >
> > > El vie., 15 nov. 2019 a las 20:48, Alex Harui
> > > (<ah...@adobe.com.invalid>)
> > > escribió:
> > >
> > > > Hi Carlos,
> > > >
> > > > If/When you decide to merge these PRs, please make sure you have
> > > reserved
> > > > time to fix anything it breaks in CI.
> > > >
> > >
> > > Let me know if the following plan would fit your expectations:
> > >
> > > 1) If nobody find any problem with the actual PRs in the next few
> > > days, I
> > > can merge it.
> > > 2) Plan a release between Dec, 10-15th with me as RM. Since I'm new
> > to
> > > the
> > > process, I think as happened with Piotr, I'll need help from Piotr
> > and
> > > you
> > > to be able to do it.
> > > 3) Fix any issue we find, and even try to see if we the new
> > > improvements
> > > can add up to simplify the current process
> > >
> > >
> > > >
> > > > I thought we already had made the changes to build with Maven
> > without
> > > > Flash.
> > > >
> > >
> > > The new process simplifies it so newcomers (and all of us) benefits
> > > from
> > > having less prerequisites in his machine (like less env vars
> required
> > > for
> > > example) so we should expect more people be successful to get
> royale
> > > build
> > > without problems in the process, also instructions to build are
> > > simplified.
> > > We don't need to do different instructions anymore for a clean
> > > environment
> > > and post first build, what seems to me a huge improvement. Also we
> > use
> > > the
> > > new maven reproducible builds that are supported in the build
> system
> > > from
> > > some weeks now.
> > >
> > > I think this is our main objetive as a project to simplify as
> > possible
> > > to
> > > make it more accesible for newcomers.
> > >
> > >
> > > >
> > > > I have some missing DG features to implement for Alina before I
> can
> > > find
> > > > time to review the PR commits because they are big so might be
> > > several days.
> > > >
> > >
> > > ok, let me know if you want me to wait to merge to your reviews.
> The
> > > problem of this is that the PRs could turn invalid and Chris could
> > not
> > > be
> > > available at that time and that could make this effort to be lost.
> So
> > > that
> > > could complicate this merge. My opinion is that if some of us test
> > the
> > > PRs
> > > and get it working we should not stop the merge to be done, and
> then
> > > over
> > > this changes we can go over the new 0.9.7 release in 2-3 weeks
> fixing
> > > any
> > > CI issue we can find we me as RM and releasing a 0.9.7 in the
> process
> > > too.
> > >
> > > Let me know what you think.
> > >
> > > Thanks
> > >
> > > Carlos
> > >
> > >
> > >
> > >
> > > >
> > > > -Alex
> > > >
> > > > On 11/15/19, 11:43 AM, "Carlos Rovira" <ca...@apache.org>
> > > wrote:
> > > >
> > > > Hi Alex,
> > > >
> > > > my plan was to be a RM at some point, so maybe this is a good
> > > time to
> > > > do it.
> > > > I think we all agree that improvements and fixes will need
> > other
> > > ones
> > > > in
> > > > the CI release steps. Can be improvements without touching
> that
> > > part
> > > > too I
> > > > think all the improvements are worth it the changes to CI
> > > process. I
> > > > expect
> > > > mostly it will be simplified since now the maven process is
> > > lighter.
> > > > We have currently 2 clients migrating from Flex so maybe I'll
> > > need some
> > > > weeks to mange it, but I could start a 0.9.7 at some point
> > during
> > > > December.
> > > > Let me know what you think.
> > > >
> > > > btw, something important to pay attention that I think didn't
> > > describe
> > > > well. enough in my previous emails: One of the changes was to
> > > allow to
> > > > build the compiler too without the need to have any Flash
> stuff
> > > by not
> > > > enabling the “option-with-swf” profile. So in general it
> should
> > > be
> > > > possible
> > > > to build Royale completely without any Flash third party
> stuff
> > > and to
> > > > build
> > > > it completely with all tests if you enable the
> > “option-with-swf”
> > > > dependency.
> > > >
> > > >
> > > > El vie., 15 nov. 2019 a las 19:38, Alex Harui
> > > > (<ah...@adobe.com.invalid>)
> > > > escribió:
> > > >
> > > > > The second commit I looked at is also huge so I will not be
> > > able to
> > > > review
> > > > > it or any others right now.
> > > > >
> > > > > The things I remember wondering about in the first commit I
> > > reviewed
> > > > is:
> > > > > 1) changing of the timestamp options that ensured SWFs are
> > > > reproducible
> > > > > 2) removal of JGit which is needed by the CI release steps.
> > > > >
> > > > > Maybe they are restored in other commits.
> > > > >
> > > > > -Alex
> > > > >
> > > > > On 11/15/19, 10:32 AM, "Alex Harui"
> <aharui@adobe.com.INVALID
> > >
> > > > wrote:
> > > > >
> > > > > I've only reviewed one commit in one PR so far, but I
> > > think it
> > > > will
> > > > > break the CI release steps.
> > > > >
> > > > > Also, IMO, 0.9.6 has reproducible Maven artifacts.
> > > > >
> > > > > Improvements and fixes are welcome. Who is going to
> > > verify that
> > > > the
> > > > > CI release steps continue to work after these changes?
> > > > >
> > > > > -Alex
> > > > >
> > > > > On 11/15/19, 9:52 AM, "Carlos Rovira" <
> > > carlosrovira@apache.org>
> > > > wrote:
> > > > >
> > > > > To all, about reproducible builds:
> > > > >
> > > > >
> > > > > possibly the most interesting thing of all this
> > changes
> > > > might be
> > > > > that now
> > > > > we should allow releasing Royale via Maven with the
> > > ability
> > > > of
> > > > > creating
> > > > > reproducible builds.
> > > > >
> > > > > Ideally releasing a part of Royale is just a 2-3
> step
> > > > process:
> > > > >
> > > > >
> > > > >
> > > > > - royale-compiler:
> > > > > - mvn release:prepare
> > > -DautoversionSubmodules=true
> > > > > - mvn release:perform
> > > > > - royale-typedefs:
> > > > > - update the pom.xml: royale.compiler.version
> > to
> > > the
> > > > new
> > > > > released
> > > > > version
> > > > > - mvn release:prepare
> > > -DautoversionSubmodules=true
> > > > > - mvn release:perform
> > > > > - royale-asjs:
> > > > > - update the pom.xml: royale.compiler.version
> > and
> > > > > royale.typedefs.version to the new released
> > > version
> > > > > - mvn release:prepare
> > > -DautoversionSubmodules=true
> > > > > - mvn release:perform
> > > > >
> > > > >
> > > > > This combined with all the past effort done by Alex
> > and
> > > > Piotr,
> > > > > should lower
> > > > > the suffering of doing a release :)
> > > > >
> > > > > Carlos
> > > > >
> > > > >
> > > > >
> > > > > El vie., 15 nov. 2019 a las 15:46, Carlos Rovira (<
> > > > > carlosrovira@apache.org>)
> > > > > escribió:
> > > > >
> > > > > > Great you like it Harbs! :)
> > > > > >
> > > > > > I forgot to mention that another effort in
> parallel
> > > is to
> > > > > release v1.0.0
> > > > > > of "flex-sdk-converter-maven-extension" (located
> in
> > > Apache
> > > > Flex
> > > > > utilities
> > > > > > repo),
> > > > > > so we can remove the need to add "-s
> > > > settings-template.xml" to
> > > > > each line,
> > > > > > what will improve event more the build process by
> > > reducing
> > > > > verbosity :)
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > El vie., 15 nov. 2019 a las 14:03, Harbs (<
> > > > harbs.lists@gmail.com
> > > > > >)
> > > > > > escribió:
> > > > > >
> > > > > >> If it all works, sounds great to me! :-) (I’m
> not
> > > going
> > > > to be
> > > > > able to
> > > > > >> test until sometime next week, but don’t wait
> for
> > > me.)
> > > > > >>
> > > > > >> Thanks to Chris for working on this!
> > > > > >>
> > > > > >> Harbs
> > > > > >>
> > > > > >> > On Nov 15, 2019, at 2:45 PM, Carlos Rovira <
> > > > > carlosrovira@apache.org>
> > > > > >> wrote:
> > > > > >> >
> > > > > >> > Hi,
> > > > > >> >
> > > > > >> > this days Chris Dutz has had the deference and
> > > detail of
> > > > > working on
> > > > > >> > improving Apache Royale Maven build by
> > > simplifying the
> > > > > scripts so we all
> > > > > >> > have less headaches with all this stuff that
> he
> > > knows
> > > > and
> > > > > master so
> > > > > >> well.
> > > > > >> > I want to give a big thanks to Chris for
> > > investing his
> > > > time
> > > > > in working
> > > > > >> on
> > > > > >> > this huge improvement that for sure will help
> > all
> > > us
> > > > when
> > > > > building
> > > > > >> royale
> > > > > >> > in the daily basis and as well when having to
> > > make a new
> > > > > release.
> > > > > >> >
> > > > > >> > So Chris created 3 PRs that are for each repo
> to
> > > test.
> > > > > >> >
> > > > > >> > I already tested it and simplify all greatly.
> > > > > >> >
> > > > > >> > Here the recipe for building everything
> > including
> > > tests
> > > > and
> > > > > UI tests
> > > > > >> and so
> > > > > >> > on:
> > > > > >> >
> > > > > >> > #!/bin/bash
> > > > > >> >
> > > > > >> > *export*
> > > > > >>
> > > > >
> > > >
> > >
> >
> FLASHPLAYER_DEBUGGER="/Users/christofer.dutz/Devtools/Adobe/Flash/FlashPlayer-32.0/Flash
> > > > > >> > Player.app/Contents/MacOS/Flash Player
> Debugger"
> > > > > >> >
> > > > > >> > *cd* royale-compiler
> > > > > >> >
> > > > > >> > ./mvnw install -s settings-template.xml
> > > > > >> >
> > > > > >> > *cd* ../royale-typedefs
> > > > > >> >
> > > > > >> > ./mvnw install -s settings-template.xml
> > > > > >> >
> > > > > >> > *cd* ../royale-asjs
> > > > > >> >
> > > > > >> > ./mvnw install -s settings-template.xml -P
> > > > > >> >
> > > > >
> > > with-examples,with-distribution,with-ui-testsuite,option-with-swf
> > > > > >> >
> > > > >
> > > -Dwebdriver.gecko.driver=/Users/christofer.dutz/Downloads/geckodriver
> > > > > >> >
> > > > > >> > *cd* ..
> > > > > >> >
> > > > > >> >
> > > > > >> > you can use mvn or mvnw that will install
> Maven
> > > if you
> > > > don't
> > > > > have any
> > > > > >> > installed :)
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > You probably need to adjust the paths to the
> > > > > FLASHPLAYER_DEBUGGER as
> > > > > >> well
> > > > > >> > as for the geckodriver
> > > > > >> >
> > > > > >> > (If you don’t want to execute the Selenium UI
> > > tests in
> > > > > Firefox, just
> > > > > >> omit
> > > > > >> > the “with-ui-testsuite” profile)
> > > > > >> >
> > > > > >> > (Noting that I should add a Firefox detection
> to
> > > my
> > > > > prerequisite check)
> > > > > >> >
> > > > > >> >
> > > > > >> > You should not need to have
> > > FLASHPLAYERGLOBAL_HOME and
> > > > > >> > FLASHPLAYERGLOBAL_VERSION
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > The profiles:
> > > > > >> >
> > > > > >> > - *with-examples*: Well it builds the
> examples
> > > too
> > > > > >> > - *with-distribution*: It lets the build
> also
> > > build
> > > > the
> > > > > distribution
> > > > > >> > (this part is still incomplete, since like
> > > today, it
> > > > does
> > > > > not
> > > > > >> generate a
> > > > > >> > valid SDK, but I'll work on this with Chris
> > > this next
> > > > week).
> > > > > >> > - *option-with-swf*: It also makes each
> module
> > > build
> > > > the
> > > > > swf version
> > > > > >> > - *with-ui-testsuite*: It also builds the
> > > testsuite
> > > > modules
> > > > > and runs
> > > > > >> the
> > > > > >> > integration-tests
> > > > > >> >
> > > > > >> >
> > > > > >> > This PRs also introduces many fixes like a
> SASS
> > > new
> > > > version
> > > > > that handles
> > > > > >> > memory better (that was causing all process to
> > > hang when
> > > > > launching all
> > > > > >> in
> > > > > >> > one single instruction due to memory leaks).
> > > Please
> > > > revise
> > > > > the PRs to
> > > > > >> read
> > > > > >> > about all the list of improvements in this
> > update.
> > > > > >> >
> > > > > >> > So If nobody opposite, I'd like to merge this
> > > > improvement in
> > > > > the next
> > > > > >> hours.
> > > > > >> >
> > > > > >> > Thanks! :)
> > > > > >> >
> > > > > >> > --
> > > > > >> > Carlos Rovira
> > > > > >> >
> > > > >
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cd6455b436de448b92d0e08d76aa67746%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637095135541215620&sdata=bRx%2BAyUd42ybJT4nCDoqP2WITg4eMKbGmLOgahcCJuQ%3D&reserved=0
> > > > > >>
> > > > > >>
> > > > > >
> > > > > > --
> > > > > > Carlos Rovira
> > > > > >
> > > > >
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cd6455b436de448b92d0e08d76aa67746%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637095135541225620&sdata=YMQRWnTNMvJjLLWUNd0vqxtOW9hpyk%2FyybylF6jO6jM%3D&reserved=0
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Carlos Rovira
> > > > >
> > > > >
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cd6455b436de448b92d0e08d76aa67746%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637095135541225620&sdata=YMQRWnTNMvJjLLWUNd0vqxtOW9hpyk%2FyybylF6jO6jM%3D&reserved=0
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Carlos Rovira
> > > >
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cd6455b436de448b92d0e08d76aa67746%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637095135541225620&sdata=YMQRWnTNMvJjLLWUNd0vqxtOW9hpyk%2FyybylF6jO6jM%3D&reserved=0
> > > >
> > > >
> > > >
> > >
> > > --
> > > Carlos Rovira
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cd6455b436de448b92d0e08d76aa67746%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637095135541225620&sdata=YMQRWnTNMvJjLLWUNd0vqxtOW9hpyk%2FyybylF6jO6jM%3D&reserved=0
> > >
> > >
> > >
> >
> > --
> > Carlos Rovira
> > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cd6455b436de448b92d0e08d76aa67746%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637095135541225620&sdata=YMQRWnTNMvJjLLWUNd0vqxtOW9hpyk%2FyybylF6jO6jM%3D&reserved=0
> >
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cd6455b436de448b92d0e08d76aa67746%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637095135541225620&sdata=YMQRWnTNMvJjLLWUNd0vqxtOW9hpyk%2FyybylF6jO6jM%3D&reserved=0
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Carlos Rovira <ca...@apache.org>.
Hi Piotr,
thanks, I'll do my best to try to fix CI issues. I count with you and Alex.
About things Alex comment:
Chris removed JGit because he had to add that when initially setting up the
Maven build (Sort of 4-5 years ago) , git support was very simple and
broken.
The release plugin has matured that GIT now is a first class citizen. He
removed all the plugins, executions and configuration options that are no
longer needed in order to simplify things.
So we were suffering a lot due to things that was not completely done or
that currently are obsolete, so all the changes will use current official
maven ways to solve things. I think is worth it to check whatever problem
it could arise so saving headaches for the future since we'll be in the
"right paths". So, it seems that we don’t need JGIT to do a release, and
removing a piece to do the same seems always a good way to go since we
simplify things in the process :).
Regarding the timestamps … Chris had a look at what was happening inside
before changing things … the original provided a timestamp string together
with the format for being parsed.
In the plugin itself it uses the format and the string to parse to a
standard Date object. The release plugin now should automatically add a
timestamp in a pre-defined property (project.build.outputTimestamp) into
the pom as part of the release process, which is then removed again when
changing the poms the second time to the next development version.
So only if you checkout the git revision tagged with the release, this
property is included and only if this is included the reproducible builds
kick in (Doesn’t make sense to make reproducible snapshot versions).
He adjusted
the plugin configuration to use that format and property instead of the old
ones. In the plugin both are converted to a normal Java Date object … so
nothing should be changed.
About current reproducible builds, are using an external plugin to patch
the jars generated by the build to be reproducible (io.github.zlika:
reproducible-build-maven-plugin) after they have been built by the normal
plugins. Chris changed to the official reproducible-build support which are
directly supported by the maven core team. That seems a better future path
to use official maven supported way right?.
Thanks
El sáb., 16 nov. 2019 a las 12:19, Piotr Zarzycki (<
piotrzarzycki21@gmail.com>) escribió:
> Hi Carlos,
>
> In my opinion you should try to do whole release process without merging
> PRs. - as an exercise. Next having all knowledge merge PRs if they are
> touching release process and start exercising again.
>
> You did that too early.
>
> We will see how much more time will you have to spend on this, because if
> that.
>
> Let me know if you need assistance. We can have call and try to go with
> stuff.
>
> Thanks,
> Piotr
>
>
>
>
>
> On Sat, Nov 16, 2019, 10:47 AM Carlos Rovira <ca...@apache.org>
> wrote:
>
> > Hi Alex,
> >
> > ok I think is a good idea. I'll merge it now, so we can try the following
> > days and see any issue it can arise.
> > Thanks
> >
> > Carlos
> >
> >
> >
> > El sáb., 16 nov. 2019 a las 0:29, Alex Harui (<aharui@adobe.com.invalid
> >)
> > escribió:
> >
> > > Well, you can always merge the PR and see if anything blows up and
> revert
> > > if it does. The only things I saw so far will affect the release steps
> > but
> > > probably not the nightly builds.
> > >
> > > -Alex
> > >
> > > On 11/15/19, 12:21 PM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> > >
> > > Hi Alex,
> > >
> > > El vie., 15 nov. 2019 a las 20:48, Alex Harui
> > > (<ah...@adobe.com.invalid>)
> > > escribió:
> > >
> > > > Hi Carlos,
> > > >
> > > > If/When you decide to merge these PRs, please make sure you have
> > > reserved
> > > > time to fix anything it breaks in CI.
> > > >
> > >
> > > Let me know if the following plan would fit your expectations:
> > >
> > > 1) If nobody find any problem with the actual PRs in the next few
> > > days, I
> > > can merge it.
> > > 2) Plan a release between Dec, 10-15th with me as RM. Since I'm new
> > to
> > > the
> > > process, I think as happened with Piotr, I'll need help from Piotr
> > and
> > > you
> > > to be able to do it.
> > > 3) Fix any issue we find, and even try to see if we the new
> > > improvements
> > > can add up to simplify the current process
> > >
> > >
> > > >
> > > > I thought we already had made the changes to build with Maven
> > without
> > > > Flash.
> > > >
> > >
> > > The new process simplifies it so newcomers (and all of us) benefits
> > > from
> > > having less prerequisites in his machine (like less env vars
> required
> > > for
> > > example) so we should expect more people be successful to get
> royale
> > > build
> > > without problems in the process, also instructions to build are
> > > simplified.
> > > We don't need to do different instructions anymore for a clean
> > > environment
> > > and post first build, what seems to me a huge improvement. Also we
> > use
> > > the
> > > new maven reproducible builds that are supported in the build
> system
> > > from
> > > some weeks now.
> > >
> > > I think this is our main objetive as a project to simplify as
> > possible
> > > to
> > > make it more accesible for newcomers.
> > >
> > >
> > > >
> > > > I have some missing DG features to implement for Alina before I
> can
> > > find
> > > > time to review the PR commits because they are big so might be
> > > several days.
> > > >
> > >
> > > ok, let me know if you want me to wait to merge to your reviews.
> The
> > > problem of this is that the PRs could turn invalid and Chris could
> > not
> > > be
> > > available at that time and that could make this effort to be lost.
> So
> > > that
> > > could complicate this merge. My opinion is that if some of us test
> > the
> > > PRs
> > > and get it working we should not stop the merge to be done, and
> then
> > > over
> > > this changes we can go over the new 0.9.7 release in 2-3 weeks
> fixing
> > > any
> > > CI issue we can find we me as RM and releasing a 0.9.7 in the
> process
> > > too.
> > >
> > > Let me know what you think.
> > >
> > > Thanks
> > >
> > > Carlos
> > >
> > >
> > >
> > >
> > > >
> > > > -Alex
> > > >
> > > > On 11/15/19, 11:43 AM, "Carlos Rovira" <ca...@apache.org>
> > > wrote:
> > > >
> > > > Hi Alex,
> > > >
> > > > my plan was to be a RM at some point, so maybe this is a good
> > > time to
> > > > do it.
> > > > I think we all agree that improvements and fixes will need
> > other
> > > ones
> > > > in
> > > > the CI release steps. Can be improvements without touching
> that
> > > part
> > > > too I
> > > > think all the improvements are worth it the changes to CI
> > > process. I
> > > > expect
> > > > mostly it will be simplified since now the maven process is
> > > lighter.
> > > > We have currently 2 clients migrating from Flex so maybe I'll
> > > need some
> > > > weeks to mange it, but I could start a 0.9.7 at some point
> > during
> > > > December.
> > > > Let me know what you think.
> > > >
> > > > btw, something important to pay attention that I think didn't
> > > describe
> > > > well. enough in my previous emails: One of the changes was to
> > > allow to
> > > > build the compiler too without the need to have any Flash
> stuff
> > > by not
> > > > enabling the “option-with-swf” profile. So in general it
> should
> > > be
> > > > possible
> > > > to build Royale completely without any Flash third party
> stuff
> > > and to
> > > > build
> > > > it completely with all tests if you enable the
> > “option-with-swf”
> > > > dependency.
> > > >
> > > >
> > > > El vie., 15 nov. 2019 a las 19:38, Alex Harui
> > > > (<ah...@adobe.com.invalid>)
> > > > escribió:
> > > >
> > > > > The second commit I looked at is also huge so I will not be
> > > able to
> > > > review
> > > > > it or any others right now.
> > > > >
> > > > > The things I remember wondering about in the first commit I
> > > reviewed
> > > > is:
> > > > > 1) changing of the timestamp options that ensured SWFs are
> > > > reproducible
> > > > > 2) removal of JGit which is needed by the CI release steps.
> > > > >
> > > > > Maybe they are restored in other commits.
> > > > >
> > > > > -Alex
> > > > >
> > > > > On 11/15/19, 10:32 AM, "Alex Harui"
> <aharui@adobe.com.INVALID
> > >
> > > > wrote:
> > > > >
> > > > > I've only reviewed one commit in one PR so far, but I
> > > think it
> > > > will
> > > > > break the CI release steps.
> > > > >
> > > > > Also, IMO, 0.9.6 has reproducible Maven artifacts.
> > > > >
> > > > > Improvements and fixes are welcome. Who is going to
> > > verify that
> > > > the
> > > > > CI release steps continue to work after these changes?
> > > > >
> > > > > -Alex
> > > > >
> > > > > On 11/15/19, 9:52 AM, "Carlos Rovira" <
> > > carlosrovira@apache.org>
> > > > wrote:
> > > > >
> > > > > To all, about reproducible builds:
> > > > >
> > > > >
> > > > > possibly the most interesting thing of all this
> > changes
> > > > might be
> > > > > that now
> > > > > we should allow releasing Royale via Maven with the
> > > ability
> > > > of
> > > > > creating
> > > > > reproducible builds.
> > > > >
> > > > > Ideally releasing a part of Royale is just a 2-3
> step
> > > > process:
> > > > >
> > > > >
> > > > >
> > > > > - royale-compiler:
> > > > > - mvn release:prepare
> > > -DautoversionSubmodules=true
> > > > > - mvn release:perform
> > > > > - royale-typedefs:
> > > > > - update the pom.xml: royale.compiler.version
> > to
> > > the
> > > > new
> > > > > released
> > > > > version
> > > > > - mvn release:prepare
> > > -DautoversionSubmodules=true
> > > > > - mvn release:perform
> > > > > - royale-asjs:
> > > > > - update the pom.xml: royale.compiler.version
> > and
> > > > > royale.typedefs.version to the new released
> > > version
> > > > > - mvn release:prepare
> > > -DautoversionSubmodules=true
> > > > > - mvn release:perform
> > > > >
> > > > >
> > > > > This combined with all the past effort done by Alex
> > and
> > > > Piotr,
> > > > > should lower
> > > > > the suffering of doing a release :)
> > > > >
> > > > > Carlos
> > > > >
> > > > >
> > > > >
> > > > > El vie., 15 nov. 2019 a las 15:46, Carlos Rovira (<
> > > > > carlosrovira@apache.org>)
> > > > > escribió:
> > > > >
> > > > > > Great you like it Harbs! :)
> > > > > >
> > > > > > I forgot to mention that another effort in
> parallel
> > > is to
> > > > > release v1.0.0
> > > > > > of "flex-sdk-converter-maven-extension" (located
> in
> > > Apache
> > > > Flex
> > > > > utilities
> > > > > > repo),
> > > > > > so we can remove the need to add "-s
> > > > settings-template.xml" to
> > > > > each line,
> > > > > > what will improve event more the build process by
> > > reducing
> > > > > verbosity :)
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > El vie., 15 nov. 2019 a las 14:03, Harbs (<
> > > > harbs.lists@gmail.com
> > > > > >)
> > > > > > escribió:
> > > > > >
> > > > > >> If it all works, sounds great to me! :-) (I’m
> not
> > > going
> > > > to be
> > > > > able to
> > > > > >> test until sometime next week, but don’t wait
> for
> > > me.)
> > > > > >>
> > > > > >> Thanks to Chris for working on this!
> > > > > >>
> > > > > >> Harbs
> > > > > >>
> > > > > >> > On Nov 15, 2019, at 2:45 PM, Carlos Rovira <
> > > > > carlosrovira@apache.org>
> > > > > >> wrote:
> > > > > >> >
> > > > > >> > Hi,
> > > > > >> >
> > > > > >> > this days Chris Dutz has had the deference and
> > > detail of
> > > > > working on
> > > > > >> > improving Apache Royale Maven build by
> > > simplifying the
> > > > > scripts so we all
> > > > > >> > have less headaches with all this stuff that
> he
> > > knows
> > > > and
> > > > > master so
> > > > > >> well.
> > > > > >> > I want to give a big thanks to Chris for
> > > investing his
> > > > time
> > > > > in working
> > > > > >> on
> > > > > >> > this huge improvement that for sure will help
> > all
> > > us
> > > > when
> > > > > building
> > > > > >> royale
> > > > > >> > in the daily basis and as well when having to
> > > make a new
> > > > > release.
> > > > > >> >
> > > > > >> > So Chris created 3 PRs that are for each repo
> to
> > > test.
> > > > > >> >
> > > > > >> > I already tested it and simplify all greatly.
> > > > > >> >
> > > > > >> > Here the recipe for building everything
> > including
> > > tests
> > > > and
> > > > > UI tests
> > > > > >> and so
> > > > > >> > on:
> > > > > >> >
> > > > > >> > #!/bin/bash
> > > > > >> >
> > > > > >> > *export*
> > > > > >>
> > > > >
> > > >
> > >
> >
> FLASHPLAYER_DEBUGGER="/Users/christofer.dutz/Devtools/Adobe/Flash/FlashPlayer-32.0/Flash
> > > > > >> > Player.app/Contents/MacOS/Flash Player
> Debugger"
> > > > > >> >
> > > > > >> > *cd* royale-compiler
> > > > > >> >
> > > > > >> > ./mvnw install -s settings-template.xml
> > > > > >> >
> > > > > >> > *cd* ../royale-typedefs
> > > > > >> >
> > > > > >> > ./mvnw install -s settings-template.xml
> > > > > >> >
> > > > > >> > *cd* ../royale-asjs
> > > > > >> >
> > > > > >> > ./mvnw install -s settings-template.xml -P
> > > > > >> >
> > > > >
> > > with-examples,with-distribution,with-ui-testsuite,option-with-swf
> > > > > >> >
> > > > >
> > > -Dwebdriver.gecko.driver=/Users/christofer.dutz/Downloads/geckodriver
> > > > > >> >
> > > > > >> > *cd* ..
> > > > > >> >
> > > > > >> >
> > > > > >> > you can use mvn or mvnw that will install
> Maven
> > > if you
> > > > don't
> > > > > have any
> > > > > >> > installed :)
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > You probably need to adjust the paths to the
> > > > > FLASHPLAYER_DEBUGGER as
> > > > > >> well
> > > > > >> > as for the geckodriver
> > > > > >> >
> > > > > >> > (If you don’t want to execute the Selenium UI
> > > tests in
> > > > > Firefox, just
> > > > > >> omit
> > > > > >> > the “with-ui-testsuite” profile)
> > > > > >> >
> > > > > >> > (Noting that I should add a Firefox detection
> to
> > > my
> > > > > prerequisite check)
> > > > > >> >
> > > > > >> >
> > > > > >> > You should not need to have
> > > FLASHPLAYERGLOBAL_HOME and
> > > > > >> > FLASHPLAYERGLOBAL_VERSION
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > The profiles:
> > > > > >> >
> > > > > >> > - *with-examples*: Well it builds the
> examples
> > > too
> > > > > >> > - *with-distribution*: It lets the build
> also
> > > build
> > > > the
> > > > > distribution
> > > > > >> > (this part is still incomplete, since like
> > > today, it
> > > > does
> > > > > not
> > > > > >> generate a
> > > > > >> > valid SDK, but I'll work on this with Chris
> > > this next
> > > > week).
> > > > > >> > - *option-with-swf*: It also makes each
> module
> > > build
> > > > the
> > > > > swf version
> > > > > >> > - *with-ui-testsuite*: It also builds the
> > > testsuite
> > > > modules
> > > > > and runs
> > > > > >> the
> > > > > >> > integration-tests
> > > > > >> >
> > > > > >> >
> > > > > >> > This PRs also introduces many fixes like a
> SASS
> > > new
> > > > version
> > > > > that handles
> > > > > >> > memory better (that was causing all process to
> > > hang when
> > > > > launching all
> > > > > >> in
> > > > > >> > one single instruction due to memory leaks).
> > > Please
> > > > revise
> > > > > the PRs to
> > > > > >> read
> > > > > >> > about all the list of improvements in this
> > update.
> > > > > >> >
> > > > > >> > So If nobody opposite, I'd like to merge this
> > > > improvement in
> > > > > the next
> > > > > >> hours.
> > > > > >> >
> > > > > >> > Thanks! :)
> > > > > >> >
> > > > > >> > --
> > > > > >> > Carlos Rovira
> > > > > >> >
> > > > >
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1fffda5fc31746cda1ae08d76a09751d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094461160068663&sdata=elGX%2F3esJ4w2l1Z7HhNwhVa7pLsxUxFvCvUZgkhDikk%3D&reserved=0
> > > > > >>
> > > > > >>
> > > > > >
> > > > > > --
> > > > > > Carlos Rovira
> > > > > >
> > > > >
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1fffda5fc31746cda1ae08d76a09751d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094461160068663&sdata=elGX%2F3esJ4w2l1Z7HhNwhVa7pLsxUxFvCvUZgkhDikk%3D&reserved=0
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Carlos Rovira
> > > > >
> > > > >
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1fffda5fc31746cda1ae08d76a09751d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094461160068663&sdata=elGX%2F3esJ4w2l1Z7HhNwhVa7pLsxUxFvCvUZgkhDikk%3D&reserved=0
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Carlos Rovira
> > > >
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1fffda5fc31746cda1ae08d76a09751d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094461160078661&sdata=I7F8lDNwEwxGriYNa6%2F447Q1YuOra0nihw1GL%2FBMbT8%3D&reserved=0
> > > >
> > > >
> > > >
> > >
> > > --
> > > Carlos Rovira
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1fffda5fc31746cda1ae08d76a09751d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094461160078661&sdata=I7F8lDNwEwxGriYNa6%2F447Q1YuOra0nihw1GL%2FBMbT8%3D&reserved=0
> > >
> > >
> > >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Piotr Zarzycki <pi...@gmail.com>.
Hi Carlos,
In my opinion you should try to do whole release process without merging
PRs. - as an exercise. Next having all knowledge merge PRs if they are
touching release process and start exercising again.
You did that too early.
We will see how much more time will you have to spend on this, because if
that.
Let me know if you need assistance. We can have call and try to go with
stuff.
Thanks,
Piotr
On Sat, Nov 16, 2019, 10:47 AM Carlos Rovira <ca...@apache.org>
wrote:
> Hi Alex,
>
> ok I think is a good idea. I'll merge it now, so we can try the following
> days and see any issue it can arise.
> Thanks
>
> Carlos
>
>
>
> El sáb., 16 nov. 2019 a las 0:29, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
> > Well, you can always merge the PR and see if anything blows up and revert
> > if it does. The only things I saw so far will affect the release steps
> but
> > probably not the nightly builds.
> >
> > -Alex
> >
> > On 11/15/19, 12:21 PM, "Carlos Rovira" <ca...@apache.org> wrote:
> >
> > Hi Alex,
> >
> > El vie., 15 nov. 2019 a las 20:48, Alex Harui
> > (<ah...@adobe.com.invalid>)
> > escribió:
> >
> > > Hi Carlos,
> > >
> > > If/When you decide to merge these PRs, please make sure you have
> > reserved
> > > time to fix anything it breaks in CI.
> > >
> >
> > Let me know if the following plan would fit your expectations:
> >
> > 1) If nobody find any problem with the actual PRs in the next few
> > days, I
> > can merge it.
> > 2) Plan a release between Dec, 10-15th with me as RM. Since I'm new
> to
> > the
> > process, I think as happened with Piotr, I'll need help from Piotr
> and
> > you
> > to be able to do it.
> > 3) Fix any issue we find, and even try to see if we the new
> > improvements
> > can add up to simplify the current process
> >
> >
> > >
> > > I thought we already had made the changes to build with Maven
> without
> > > Flash.
> > >
> >
> > The new process simplifies it so newcomers (and all of us) benefits
> > from
> > having less prerequisites in his machine (like less env vars required
> > for
> > example) so we should expect more people be successful to get royale
> > build
> > without problems in the process, also instructions to build are
> > simplified.
> > We don't need to do different instructions anymore for a clean
> > environment
> > and post first build, what seems to me a huge improvement. Also we
> use
> > the
> > new maven reproducible builds that are supported in the build system
> > from
> > some weeks now.
> >
> > I think this is our main objetive as a project to simplify as
> possible
> > to
> > make it more accesible for newcomers.
> >
> >
> > >
> > > I have some missing DG features to implement for Alina before I can
> > find
> > > time to review the PR commits because they are big so might be
> > several days.
> > >
> >
> > ok, let me know if you want me to wait to merge to your reviews. The
> > problem of this is that the PRs could turn invalid and Chris could
> not
> > be
> > available at that time and that could make this effort to be lost. So
> > that
> > could complicate this merge. My opinion is that if some of us test
> the
> > PRs
> > and get it working we should not stop the merge to be done, and then
> > over
> > this changes we can go over the new 0.9.7 release in 2-3 weeks fixing
> > any
> > CI issue we can find we me as RM and releasing a 0.9.7 in the process
> > too.
> >
> > Let me know what you think.
> >
> > Thanks
> >
> > Carlos
> >
> >
> >
> >
> > >
> > > -Alex
> > >
> > > On 11/15/19, 11:43 AM, "Carlos Rovira" <ca...@apache.org>
> > wrote:
> > >
> > > Hi Alex,
> > >
> > > my plan was to be a RM at some point, so maybe this is a good
> > time to
> > > do it.
> > > I think we all agree that improvements and fixes will need
> other
> > ones
> > > in
> > > the CI release steps. Can be improvements without touching that
> > part
> > > too I
> > > think all the improvements are worth it the changes to CI
> > process. I
> > > expect
> > > mostly it will be simplified since now the maven process is
> > lighter.
> > > We have currently 2 clients migrating from Flex so maybe I'll
> > need some
> > > weeks to mange it, but I could start a 0.9.7 at some point
> during
> > > December.
> > > Let me know what you think.
> > >
> > > btw, something important to pay attention that I think didn't
> > describe
> > > well. enough in my previous emails: One of the changes was to
> > allow to
> > > build the compiler too without the need to have any Flash stuff
> > by not
> > > enabling the “option-with-swf” profile. So in general it should
> > be
> > > possible
> > > to build Royale completely without any Flash third party stuff
> > and to
> > > build
> > > it completely with all tests if you enable the
> “option-with-swf”
> > > dependency.
> > >
> > >
> > > El vie., 15 nov. 2019 a las 19:38, Alex Harui
> > > (<ah...@adobe.com.invalid>)
> > > escribió:
> > >
> > > > The second commit I looked at is also huge so I will not be
> > able to
> > > review
> > > > it or any others right now.
> > > >
> > > > The things I remember wondering about in the first commit I
> > reviewed
> > > is:
> > > > 1) changing of the timestamp options that ensured SWFs are
> > > reproducible
> > > > 2) removal of JGit which is needed by the CI release steps.
> > > >
> > > > Maybe they are restored in other commits.
> > > >
> > > > -Alex
> > > >
> > > > On 11/15/19, 10:32 AM, "Alex Harui" <aharui@adobe.com.INVALID
> >
> > > wrote:
> > > >
> > > > I've only reviewed one commit in one PR so far, but I
> > think it
> > > will
> > > > break the CI release steps.
> > > >
> > > > Also, IMO, 0.9.6 has reproducible Maven artifacts.
> > > >
> > > > Improvements and fixes are welcome. Who is going to
> > verify that
> > > the
> > > > CI release steps continue to work after these changes?
> > > >
> > > > -Alex
> > > >
> > > > On 11/15/19, 9:52 AM, "Carlos Rovira" <
> > carlosrovira@apache.org>
> > > wrote:
> > > >
> > > > To all, about reproducible builds:
> > > >
> > > >
> > > > possibly the most interesting thing of all this
> changes
> > > might be
> > > > that now
> > > > we should allow releasing Royale via Maven with the
> > ability
> > > of
> > > > creating
> > > > reproducible builds.
> > > >
> > > > Ideally releasing a part of Royale is just a 2-3 step
> > > process:
> > > >
> > > >
> > > >
> > > > - royale-compiler:
> > > > - mvn release:prepare
> > -DautoversionSubmodules=true
> > > > - mvn release:perform
> > > > - royale-typedefs:
> > > > - update the pom.xml: royale.compiler.version
> to
> > the
> > > new
> > > > released
> > > > version
> > > > - mvn release:prepare
> > -DautoversionSubmodules=true
> > > > - mvn release:perform
> > > > - royale-asjs:
> > > > - update the pom.xml: royale.compiler.version
> and
> > > > royale.typedefs.version to the new released
> > version
> > > > - mvn release:prepare
> > -DautoversionSubmodules=true
> > > > - mvn release:perform
> > > >
> > > >
> > > > This combined with all the past effort done by Alex
> and
> > > Piotr,
> > > > should lower
> > > > the suffering of doing a release :)
> > > >
> > > > Carlos
> > > >
> > > >
> > > >
> > > > El vie., 15 nov. 2019 a las 15:46, Carlos Rovira (<
> > > > carlosrovira@apache.org>)
> > > > escribió:
> > > >
> > > > > Great you like it Harbs! :)
> > > > >
> > > > > I forgot to mention that another effort in parallel
> > is to
> > > > release v1.0.0
> > > > > of "flex-sdk-converter-maven-extension" (located in
> > Apache
> > > Flex
> > > > utilities
> > > > > repo),
> > > > > so we can remove the need to add "-s
> > > settings-template.xml" to
> > > > each line,
> > > > > what will improve event more the build process by
> > reducing
> > > > verbosity :)
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > El vie., 15 nov. 2019 a las 14:03, Harbs (<
> > > harbs.lists@gmail.com
> > > > >)
> > > > > escribió:
> > > > >
> > > > >> If it all works, sounds great to me! :-) (I’m not
> > going
> > > to be
> > > > able to
> > > > >> test until sometime next week, but don’t wait for
> > me.)
> > > > >>
> > > > >> Thanks to Chris for working on this!
> > > > >>
> > > > >> Harbs
> > > > >>
> > > > >> > On Nov 15, 2019, at 2:45 PM, Carlos Rovira <
> > > > carlosrovira@apache.org>
> > > > >> wrote:
> > > > >> >
> > > > >> > Hi,
> > > > >> >
> > > > >> > this days Chris Dutz has had the deference and
> > detail of
> > > > working on
> > > > >> > improving Apache Royale Maven build by
> > simplifying the
> > > > scripts so we all
> > > > >> > have less headaches with all this stuff that he
> > knows
> > > and
> > > > master so
> > > > >> well.
> > > > >> > I want to give a big thanks to Chris for
> > investing his
> > > time
> > > > in working
> > > > >> on
> > > > >> > this huge improvement that for sure will help
> all
> > us
> > > when
> > > > building
> > > > >> royale
> > > > >> > in the daily basis and as well when having to
> > make a new
> > > > release.
> > > > >> >
> > > > >> > So Chris created 3 PRs that are for each repo to
> > test.
> > > > >> >
> > > > >> > I already tested it and simplify all greatly.
> > > > >> >
> > > > >> > Here the recipe for building everything
> including
> > tests
> > > and
> > > > UI tests
> > > > >> and so
> > > > >> > on:
> > > > >> >
> > > > >> > #!/bin/bash
> > > > >> >
> > > > >> > *export*
> > > > >>
> > > >
> > >
> >
> FLASHPLAYER_DEBUGGER="/Users/christofer.dutz/Devtools/Adobe/Flash/FlashPlayer-32.0/Flash
> > > > >> > Player.app/Contents/MacOS/Flash Player Debugger"
> > > > >> >
> > > > >> > *cd* royale-compiler
> > > > >> >
> > > > >> > ./mvnw install -s settings-template.xml
> > > > >> >
> > > > >> > *cd* ../royale-typedefs
> > > > >> >
> > > > >> > ./mvnw install -s settings-template.xml
> > > > >> >
> > > > >> > *cd* ../royale-asjs
> > > > >> >
> > > > >> > ./mvnw install -s settings-template.xml -P
> > > > >> >
> > > >
> > with-examples,with-distribution,with-ui-testsuite,option-with-swf
> > > > >> >
> > > >
> > -Dwebdriver.gecko.driver=/Users/christofer.dutz/Downloads/geckodriver
> > > > >> >
> > > > >> > *cd* ..
> > > > >> >
> > > > >> >
> > > > >> > you can use mvn or mvnw that will install Maven
> > if you
> > > don't
> > > > have any
> > > > >> > installed :)
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > You probably need to adjust the paths to the
> > > > FLASHPLAYER_DEBUGGER as
> > > > >> well
> > > > >> > as for the geckodriver
> > > > >> >
> > > > >> > (If you don’t want to execute the Selenium UI
> > tests in
> > > > Firefox, just
> > > > >> omit
> > > > >> > the “with-ui-testsuite” profile)
> > > > >> >
> > > > >> > (Noting that I should add a Firefox detection to
> > my
> > > > prerequisite check)
> > > > >> >
> > > > >> >
> > > > >> > You should not need to have
> > FLASHPLAYERGLOBAL_HOME and
> > > > >> > FLASHPLAYERGLOBAL_VERSION
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > The profiles:
> > > > >> >
> > > > >> > - *with-examples*: Well it builds the examples
> > too
> > > > >> > - *with-distribution*: It lets the build also
> > build
> > > the
> > > > distribution
> > > > >> > (this part is still incomplete, since like
> > today, it
> > > does
> > > > not
> > > > >> generate a
> > > > >> > valid SDK, but I'll work on this with Chris
> > this next
> > > week).
> > > > >> > - *option-with-swf*: It also makes each module
> > build
> > > the
> > > > swf version
> > > > >> > - *with-ui-testsuite*: It also builds the
> > testsuite
> > > modules
> > > > and runs
> > > > >> the
> > > > >> > integration-tests
> > > > >> >
> > > > >> >
> > > > >> > This PRs also introduces many fixes like a SASS
> > new
> > > version
> > > > that handles
> > > > >> > memory better (that was causing all process to
> > hang when
> > > > launching all
> > > > >> in
> > > > >> > one single instruction due to memory leaks).
> > Please
> > > revise
> > > > the PRs to
> > > > >> read
> > > > >> > about all the list of improvements in this
> update.
> > > > >> >
> > > > >> > So If nobody opposite, I'd like to merge this
> > > improvement in
> > > > the next
> > > > >> hours.
> > > > >> >
> > > > >> > Thanks! :)
> > > > >> >
> > > > >> > --
> > > > >> > Carlos Rovira
> > > > >> >
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1fffda5fc31746cda1ae08d76a09751d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094461160068663&sdata=elGX%2F3esJ4w2l1Z7HhNwhVa7pLsxUxFvCvUZgkhDikk%3D&reserved=0
> > > > >>
> > > > >>
> > > > >
> > > > > --
> > > > > Carlos Rovira
> > > > >
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1fffda5fc31746cda1ae08d76a09751d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094461160068663&sdata=elGX%2F3esJ4w2l1Z7HhNwhVa7pLsxUxFvCvUZgkhDikk%3D&reserved=0
> > > > >
> > > > >
> > > >
> > > > --
> > > > Carlos Rovira
> > > >
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1fffda5fc31746cda1ae08d76a09751d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094461160068663&sdata=elGX%2F3esJ4w2l1Z7HhNwhVa7pLsxUxFvCvUZgkhDikk%3D&reserved=0
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > --
> > > Carlos Rovira
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1fffda5fc31746cda1ae08d76a09751d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094461160078661&sdata=I7F8lDNwEwxGriYNa6%2F447Q1YuOra0nihw1GL%2FBMbT8%3D&reserved=0
> > >
> > >
> > >
> >
> > --
> > Carlos Rovira
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1fffda5fc31746cda1ae08d76a09751d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094461160078661&sdata=I7F8lDNwEwxGriYNa6%2F447Q1YuOra0nihw1GL%2FBMbT8%3D&reserved=0
> >
> >
> >
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
ok I think is a good idea. I'll merge it now, so we can try the following
days and see any issue it can arise.
Thanks
Carlos
El sáb., 16 nov. 2019 a las 0:29, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Well, you can always merge the PR and see if anything blows up and revert
> if it does. The only things I saw so far will affect the release steps but
> probably not the nightly builds.
>
> -Alex
>
> On 11/15/19, 12:21 PM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex,
>
> El vie., 15 nov. 2019 a las 20:48, Alex Harui
> (<ah...@adobe.com.invalid>)
> escribió:
>
> > Hi Carlos,
> >
> > If/When you decide to merge these PRs, please make sure you have
> reserved
> > time to fix anything it breaks in CI.
> >
>
> Let me know if the following plan would fit your expectations:
>
> 1) If nobody find any problem with the actual PRs in the next few
> days, I
> can merge it.
> 2) Plan a release between Dec, 10-15th with me as RM. Since I'm new to
> the
> process, I think as happened with Piotr, I'll need help from Piotr and
> you
> to be able to do it.
> 3) Fix any issue we find, and even try to see if we the new
> improvements
> can add up to simplify the current process
>
>
> >
> > I thought we already had made the changes to build with Maven without
> > Flash.
> >
>
> The new process simplifies it so newcomers (and all of us) benefits
> from
> having less prerequisites in his machine (like less env vars required
> for
> example) so we should expect more people be successful to get royale
> build
> without problems in the process, also instructions to build are
> simplified.
> We don't need to do different instructions anymore for a clean
> environment
> and post first build, what seems to me a huge improvement. Also we use
> the
> new maven reproducible builds that are supported in the build system
> from
> some weeks now.
>
> I think this is our main objetive as a project to simplify as possible
> to
> make it more accesible for newcomers.
>
>
> >
> > I have some missing DG features to implement for Alina before I can
> find
> > time to review the PR commits because they are big so might be
> several days.
> >
>
> ok, let me know if you want me to wait to merge to your reviews. The
> problem of this is that the PRs could turn invalid and Chris could not
> be
> available at that time and that could make this effort to be lost. So
> that
> could complicate this merge. My opinion is that if some of us test the
> PRs
> and get it working we should not stop the merge to be done, and then
> over
> this changes we can go over the new 0.9.7 release in 2-3 weeks fixing
> any
> CI issue we can find we me as RM and releasing a 0.9.7 in the process
> too.
>
> Let me know what you think.
>
> Thanks
>
> Carlos
>
>
>
>
> >
> > -Alex
> >
> > On 11/15/19, 11:43 AM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> >
> > Hi Alex,
> >
> > my plan was to be a RM at some point, so maybe this is a good
> time to
> > do it.
> > I think we all agree that improvements and fixes will need other
> ones
> > in
> > the CI release steps. Can be improvements without touching that
> part
> > too I
> > think all the improvements are worth it the changes to CI
> process. I
> > expect
> > mostly it will be simplified since now the maven process is
> lighter.
> > We have currently 2 clients migrating from Flex so maybe I'll
> need some
> > weeks to mange it, but I could start a 0.9.7 at some point during
> > December.
> > Let me know what you think.
> >
> > btw, something important to pay attention that I think didn't
> describe
> > well. enough in my previous emails: One of the changes was to
> allow to
> > build the compiler too without the need to have any Flash stuff
> by not
> > enabling the “option-with-swf” profile. So in general it should
> be
> > possible
> > to build Royale completely without any Flash third party stuff
> and to
> > build
> > it completely with all tests if you enable the “option-with-swf”
> > dependency.
> >
> >
> > El vie., 15 nov. 2019 a las 19:38, Alex Harui
> > (<ah...@adobe.com.invalid>)
> > escribió:
> >
> > > The second commit I looked at is also huge so I will not be
> able to
> > review
> > > it or any others right now.
> > >
> > > The things I remember wondering about in the first commit I
> reviewed
> > is:
> > > 1) changing of the timestamp options that ensured SWFs are
> > reproducible
> > > 2) removal of JGit which is needed by the CI release steps.
> > >
> > > Maybe they are restored in other commits.
> > >
> > > -Alex
> > >
> > > On 11/15/19, 10:32 AM, "Alex Harui" <ah...@adobe.com.INVALID>
> > wrote:
> > >
> > > I've only reviewed one commit in one PR so far, but I
> think it
> > will
> > > break the CI release steps.
> > >
> > > Also, IMO, 0.9.6 has reproducible Maven artifacts.
> > >
> > > Improvements and fixes are welcome. Who is going to
> verify that
> > the
> > > CI release steps continue to work after these changes?
> > >
> > > -Alex
> > >
> > > On 11/15/19, 9:52 AM, "Carlos Rovira" <
> carlosrovira@apache.org>
> > wrote:
> > >
> > > To all, about reproducible builds:
> > >
> > >
> > > possibly the most interesting thing of all this changes
> > might be
> > > that now
> > > we should allow releasing Royale via Maven with the
> ability
> > of
> > > creating
> > > reproducible builds.
> > >
> > > Ideally releasing a part of Royale is just a 2-3 step
> > process:
> > >
> > >
> > >
> > > - royale-compiler:
> > > - mvn release:prepare
> -DautoversionSubmodules=true
> > > - mvn release:perform
> > > - royale-typedefs:
> > > - update the pom.xml: royale.compiler.version to
> the
> > new
> > > released
> > > version
> > > - mvn release:prepare
> -DautoversionSubmodules=true
> > > - mvn release:perform
> > > - royale-asjs:
> > > - update the pom.xml: royale.compiler.version and
> > > royale.typedefs.version to the new released
> version
> > > - mvn release:prepare
> -DautoversionSubmodules=true
> > > - mvn release:perform
> > >
> > >
> > > This combined with all the past effort done by Alex and
> > Piotr,
> > > should lower
> > > the suffering of doing a release :)
> > >
> > > Carlos
> > >
> > >
> > >
> > > El vie., 15 nov. 2019 a las 15:46, Carlos Rovira (<
> > > carlosrovira@apache.org>)
> > > escribió:
> > >
> > > > Great you like it Harbs! :)
> > > >
> > > > I forgot to mention that another effort in parallel
> is to
> > > release v1.0.0
> > > > of "flex-sdk-converter-maven-extension" (located in
> Apache
> > Flex
> > > utilities
> > > > repo),
> > > > so we can remove the need to add "-s
> > settings-template.xml" to
> > > each line,
> > > > what will improve event more the build process by
> reducing
> > > verbosity :)
> > > >
> > > >
> > > >
> > > >
> > > > El vie., 15 nov. 2019 a las 14:03, Harbs (<
> > harbs.lists@gmail.com
> > > >)
> > > > escribió:
> > > >
> > > >> If it all works, sounds great to me! :-) (I’m not
> going
> > to be
> > > able to
> > > >> test until sometime next week, but don’t wait for
> me.)
> > > >>
> > > >> Thanks to Chris for working on this!
> > > >>
> > > >> Harbs
> > > >>
> > > >> > On Nov 15, 2019, at 2:45 PM, Carlos Rovira <
> > > carlosrovira@apache.org>
> > > >> wrote:
> > > >> >
> > > >> > Hi,
> > > >> >
> > > >> > this days Chris Dutz has had the deference and
> detail of
> > > working on
> > > >> > improving Apache Royale Maven build by
> simplifying the
> > > scripts so we all
> > > >> > have less headaches with all this stuff that he
> knows
> > and
> > > master so
> > > >> well.
> > > >> > I want to give a big thanks to Chris for
> investing his
> > time
> > > in working
> > > >> on
> > > >> > this huge improvement that for sure will help all
> us
> > when
> > > building
> > > >> royale
> > > >> > in the daily basis and as well when having to
> make a new
> > > release.
> > > >> >
> > > >> > So Chris created 3 PRs that are for each repo to
> test.
> > > >> >
> > > >> > I already tested it and simplify all greatly.
> > > >> >
> > > >> > Here the recipe for building everything including
> tests
> > and
> > > UI tests
> > > >> and so
> > > >> > on:
> > > >> >
> > > >> > #!/bin/bash
> > > >> >
> > > >> > *export*
> > > >>
> > >
> >
> FLASHPLAYER_DEBUGGER="/Users/christofer.dutz/Devtools/Adobe/Flash/FlashPlayer-32.0/Flash
> > > >> > Player.app/Contents/MacOS/Flash Player Debugger"
> > > >> >
> > > >> > *cd* royale-compiler
> > > >> >
> > > >> > ./mvnw install -s settings-template.xml
> > > >> >
> > > >> > *cd* ../royale-typedefs
> > > >> >
> > > >> > ./mvnw install -s settings-template.xml
> > > >> >
> > > >> > *cd* ../royale-asjs
> > > >> >
> > > >> > ./mvnw install -s settings-template.xml -P
> > > >> >
> > >
> with-examples,with-distribution,with-ui-testsuite,option-with-swf
> > > >> >
> > >
> -Dwebdriver.gecko.driver=/Users/christofer.dutz/Downloads/geckodriver
> > > >> >
> > > >> > *cd* ..
> > > >> >
> > > >> >
> > > >> > you can use mvn or mvnw that will install Maven
> if you
> > don't
> > > have any
> > > >> > installed :)
> > > >> >
> > > >> >
> > > >> >
> > > >> > You probably need to adjust the paths to the
> > > FLASHPLAYER_DEBUGGER as
> > > >> well
> > > >> > as for the geckodriver
> > > >> >
> > > >> > (If you don’t want to execute the Selenium UI
> tests in
> > > Firefox, just
> > > >> omit
> > > >> > the “with-ui-testsuite” profile)
> > > >> >
> > > >> > (Noting that I should add a Firefox detection to
> my
> > > prerequisite check)
> > > >> >
> > > >> >
> > > >> > You should not need to have
> FLASHPLAYERGLOBAL_HOME and
> > > >> > FLASHPLAYERGLOBAL_VERSION
> > > >> >
> > > >> >
> > > >> >
> > > >> > The profiles:
> > > >> >
> > > >> > - *with-examples*: Well it builds the examples
> too
> > > >> > - *with-distribution*: It lets the build also
> build
> > the
> > > distribution
> > > >> > (this part is still incomplete, since like
> today, it
> > does
> > > not
> > > >> generate a
> > > >> > valid SDK, but I'll work on this with Chris
> this next
> > week).
> > > >> > - *option-with-swf*: It also makes each module
> build
> > the
> > > swf version
> > > >> > - *with-ui-testsuite*: It also builds the
> testsuite
> > modules
> > > and runs
> > > >> the
> > > >> > integration-tests
> > > >> >
> > > >> >
> > > >> > This PRs also introduces many fixes like a SASS
> new
> > version
> > > that handles
> > > >> > memory better (that was causing all process to
> hang when
> > > launching all
> > > >> in
> > > >> > one single instruction due to memory leaks).
> Please
> > revise
> > > the PRs to
> > > >> read
> > > >> > about all the list of improvements in this update.
> > > >> >
> > > >> > So If nobody opposite, I'd like to merge this
> > improvement in
> > > the next
> > > >> hours.
> > > >> >
> > > >> > Thanks! :)
> > > >> >
> > > >> > --
> > > >> > Carlos Rovira
> > > >> >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1fffda5fc31746cda1ae08d76a09751d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094461160068663&sdata=elGX%2F3esJ4w2l1Z7HhNwhVa7pLsxUxFvCvUZgkhDikk%3D&reserved=0
> > > >>
> > > >>
> > > >
> > > > --
> > > > Carlos Rovira
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1fffda5fc31746cda1ae08d76a09751d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094461160068663&sdata=elGX%2F3esJ4w2l1Z7HhNwhVa7pLsxUxFvCvUZgkhDikk%3D&reserved=0
> > > >
> > > >
> > >
> > > --
> > > Carlos Rovira
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1fffda5fc31746cda1ae08d76a09751d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094461160068663&sdata=elGX%2F3esJ4w2l1Z7HhNwhVa7pLsxUxFvCvUZgkhDikk%3D&reserved=0
> > >
> > >
> > >
> > >
> > >
> >
> > --
> > Carlos Rovira
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1fffda5fc31746cda1ae08d76a09751d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094461160078661&sdata=I7F8lDNwEwxGriYNa6%2F447Q1YuOra0nihw1GL%2FBMbT8%3D&reserved=0
> >
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1fffda5fc31746cda1ae08d76a09751d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094461160078661&sdata=I7F8lDNwEwxGriYNa6%2F447Q1YuOra0nihw1GL%2FBMbT8%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Well, you can always merge the PR and see if anything blows up and revert if it does. The only things I saw so far will affect the release steps but probably not the nightly builds.
-Alex
On 11/15/19, 12:21 PM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex,
El vie., 15 nov. 2019 a las 20:48, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Hi Carlos,
>
> If/When you decide to merge these PRs, please make sure you have reserved
> time to fix anything it breaks in CI.
>
Let me know if the following plan would fit your expectations:
1) If nobody find any problem with the actual PRs in the next few days, I
can merge it.
2) Plan a release between Dec, 10-15th with me as RM. Since I'm new to the
process, I think as happened with Piotr, I'll need help from Piotr and you
to be able to do it.
3) Fix any issue we find, and even try to see if we the new improvements
can add up to simplify the current process
>
> I thought we already had made the changes to build with Maven without
> Flash.
>
The new process simplifies it so newcomers (and all of us) benefits from
having less prerequisites in his machine (like less env vars required for
example) so we should expect more people be successful to get royale build
without problems in the process, also instructions to build are simplified.
We don't need to do different instructions anymore for a clean environment
and post first build, what seems to me a huge improvement. Also we use the
new maven reproducible builds that are supported in the build system from
some weeks now.
I think this is our main objetive as a project to simplify as possible to
make it more accesible for newcomers.
>
> I have some missing DG features to implement for Alina before I can find
> time to review the PR commits because they are big so might be several days.
>
ok, let me know if you want me to wait to merge to your reviews. The
problem of this is that the PRs could turn invalid and Chris could not be
available at that time and that could make this effort to be lost. So that
could complicate this merge. My opinion is that if some of us test the PRs
and get it working we should not stop the merge to be done, and then over
this changes we can go over the new 0.9.7 release in 2-3 weeks fixing any
CI issue we can find we me as RM and releasing a 0.9.7 in the process too.
Let me know what you think.
Thanks
Carlos
>
> -Alex
>
> On 11/15/19, 11:43 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex,
>
> my plan was to be a RM at some point, so maybe this is a good time to
> do it.
> I think we all agree that improvements and fixes will need other ones
> in
> the CI release steps. Can be improvements without touching that part
> too I
> think all the improvements are worth it the changes to CI process. I
> expect
> mostly it will be simplified since now the maven process is lighter.
> We have currently 2 clients migrating from Flex so maybe I'll need some
> weeks to mange it, but I could start a 0.9.7 at some point during
> December.
> Let me know what you think.
>
> btw, something important to pay attention that I think didn't describe
> well. enough in my previous emails: One of the changes was to allow to
> build the compiler too without the need to have any Flash stuff by not
> enabling the “option-with-swf” profile. So in general it should be
> possible
> to build Royale completely without any Flash third party stuff and to
> build
> it completely with all tests if you enable the “option-with-swf”
> dependency.
>
>
> El vie., 15 nov. 2019 a las 19:38, Alex Harui
> (<ah...@adobe.com.invalid>)
> escribió:
>
> > The second commit I looked at is also huge so I will not be able to
> review
> > it or any others right now.
> >
> > The things I remember wondering about in the first commit I reviewed
> is:
> > 1) changing of the timestamp options that ensured SWFs are
> reproducible
> > 2) removal of JGit which is needed by the CI release steps.
> >
> > Maybe they are restored in other commits.
> >
> > -Alex
> >
> > On 11/15/19, 10:32 AM, "Alex Harui" <ah...@adobe.com.INVALID>
> wrote:
> >
> > I've only reviewed one commit in one PR so far, but I think it
> will
> > break the CI release steps.
> >
> > Also, IMO, 0.9.6 has reproducible Maven artifacts.
> >
> > Improvements and fixes are welcome. Who is going to verify that
> the
> > CI release steps continue to work after these changes?
> >
> > -Alex
> >
> > On 11/15/19, 9:52 AM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> >
> > To all, about reproducible builds:
> >
> >
> > possibly the most interesting thing of all this changes
> might be
> > that now
> > we should allow releasing Royale via Maven with the ability
> of
> > creating
> > reproducible builds.
> >
> > Ideally releasing a part of Royale is just a 2-3 step
> process:
> >
> >
> >
> > - royale-compiler:
> > - mvn release:prepare -DautoversionSubmodules=true
> > - mvn release:perform
> > - royale-typedefs:
> > - update the pom.xml: royale.compiler.version to the
> new
> > released
> > version
> > - mvn release:prepare -DautoversionSubmodules=true
> > - mvn release:perform
> > - royale-asjs:
> > - update the pom.xml: royale.compiler.version and
> > royale.typedefs.version to the new released version
> > - mvn release:prepare -DautoversionSubmodules=true
> > - mvn release:perform
> >
> >
> > This combined with all the past effort done by Alex and
> Piotr,
> > should lower
> > the suffering of doing a release :)
> >
> > Carlos
> >
> >
> >
> > El vie., 15 nov. 2019 a las 15:46, Carlos Rovira (<
> > carlosrovira@apache.org>)
> > escribió:
> >
> > > Great you like it Harbs! :)
> > >
> > > I forgot to mention that another effort in parallel is to
> > release v1.0.0
> > > of "flex-sdk-converter-maven-extension" (located in Apache
> Flex
> > utilities
> > > repo),
> > > so we can remove the need to add "-s
> settings-template.xml" to
> > each line,
> > > what will improve event more the build process by reducing
> > verbosity :)
> > >
> > >
> > >
> > >
> > > El vie., 15 nov. 2019 a las 14:03, Harbs (<
> harbs.lists@gmail.com
> > >)
> > > escribió:
> > >
> > >> If it all works, sounds great to me! :-) (I’m not going
> to be
> > able to
> > >> test until sometime next week, but don’t wait for me.)
> > >>
> > >> Thanks to Chris for working on this!
> > >>
> > >> Harbs
> > >>
> > >> > On Nov 15, 2019, at 2:45 PM, Carlos Rovira <
> > carlosrovira@apache.org>
> > >> wrote:
> > >> >
> > >> > Hi,
> > >> >
> > >> > this days Chris Dutz has had the deference and detail of
> > working on
> > >> > improving Apache Royale Maven build by simplifying the
> > scripts so we all
> > >> > have less headaches with all this stuff that he knows
> and
> > master so
> > >> well.
> > >> > I want to give a big thanks to Chris for investing his
> time
> > in working
> > >> on
> > >> > this huge improvement that for sure will help all us
> when
> > building
> > >> royale
> > >> > in the daily basis and as well when having to make a new
> > release.
> > >> >
> > >> > So Chris created 3 PRs that are for each repo to test.
> > >> >
> > >> > I already tested it and simplify all greatly.
> > >> >
> > >> > Here the recipe for building everything including tests
> and
> > UI tests
> > >> and so
> > >> > on:
> > >> >
> > >> > #!/bin/bash
> > >> >
> > >> > *export*
> > >>
> >
> FLASHPLAYER_DEBUGGER="/Users/christofer.dutz/Devtools/Adobe/Flash/FlashPlayer-32.0/Flash
> > >> > Player.app/Contents/MacOS/Flash Player Debugger"
> > >> >
> > >> > *cd* royale-compiler
> > >> >
> > >> > ./mvnw install -s settings-template.xml
> > >> >
> > >> > *cd* ../royale-typedefs
> > >> >
> > >> > ./mvnw install -s settings-template.xml
> > >> >
> > >> > *cd* ../royale-asjs
> > >> >
> > >> > ./mvnw install -s settings-template.xml -P
> > >> >
> > with-examples,with-distribution,with-ui-testsuite,option-with-swf
> > >> >
> > -Dwebdriver.gecko.driver=/Users/christofer.dutz/Downloads/geckodriver
> > >> >
> > >> > *cd* ..
> > >> >
> > >> >
> > >> > you can use mvn or mvnw that will install Maven if you
> don't
> > have any
> > >> > installed :)
> > >> >
> > >> >
> > >> >
> > >> > You probably need to adjust the paths to the
> > FLASHPLAYER_DEBUGGER as
> > >> well
> > >> > as for the geckodriver
> > >> >
> > >> > (If you don’t want to execute the Selenium UI tests in
> > Firefox, just
> > >> omit
> > >> > the “with-ui-testsuite” profile)
> > >> >
> > >> > (Noting that I should add a Firefox detection to my
> > prerequisite check)
> > >> >
> > >> >
> > >> > You should not need to have FLASHPLAYERGLOBAL_HOME and
> > >> > FLASHPLAYERGLOBAL_VERSION
> > >> >
> > >> >
> > >> >
> > >> > The profiles:
> > >> >
> > >> > - *with-examples*: Well it builds the examples too
> > >> > - *with-distribution*: It lets the build also build
> the
> > distribution
> > >> > (this part is still incomplete, since like today, it
> does
> > not
> > >> generate a
> > >> > valid SDK, but I'll work on this with Chris this next
> week).
> > >> > - *option-with-swf*: It also makes each module build
> the
> > swf version
> > >> > - *with-ui-testsuite*: It also builds the testsuite
> modules
> > and runs
> > >> the
> > >> > integration-tests
> > >> >
> > >> >
> > >> > This PRs also introduces many fixes like a SASS new
> version
> > that handles
> > >> > memory better (that was causing all process to hang when
> > launching all
> > >> in
> > >> > one single instruction due to memory leaks). Please
> revise
> > the PRs to
> > >> read
> > >> > about all the list of improvements in this update.
> > >> >
> > >> > So If nobody opposite, I'd like to merge this
> improvement in
> > the next
> > >> hours.
> > >> >
> > >> > Thanks! :)
> > >> >
> > >> > --
> > >> > Carlos Rovira
> > >> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1fffda5fc31746cda1ae08d76a09751d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094461160068663&sdata=elGX%2F3esJ4w2l1Z7HhNwhVa7pLsxUxFvCvUZgkhDikk%3D&reserved=0
> > >>
> > >>
> > >
> > > --
> > > Carlos Rovira
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1fffda5fc31746cda1ae08d76a09751d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094461160068663&sdata=elGX%2F3esJ4w2l1Z7HhNwhVa7pLsxUxFvCvUZgkhDikk%3D&reserved=0
> > >
> > >
> >
> > --
> > Carlos Rovira
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1fffda5fc31746cda1ae08d76a09751d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094461160068663&sdata=elGX%2F3esJ4w2l1Z7HhNwhVa7pLsxUxFvCvUZgkhDikk%3D&reserved=0
> >
> >
> >
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1fffda5fc31746cda1ae08d76a09751d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094461160078661&sdata=I7F8lDNwEwxGriYNa6%2F447Q1YuOra0nihw1GL%2FBMbT8%3D&reserved=0
>
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1fffda5fc31746cda1ae08d76a09751d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094461160078661&sdata=I7F8lDNwEwxGriYNa6%2F447Q1YuOra0nihw1GL%2FBMbT8%3D&reserved=0
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
El vie., 15 nov. 2019 a las 20:48, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Hi Carlos,
>
> If/When you decide to merge these PRs, please make sure you have reserved
> time to fix anything it breaks in CI.
>
Let me know if the following plan would fit your expectations:
1) If nobody find any problem with the actual PRs in the next few days, I
can merge it.
2) Plan a release between Dec, 10-15th with me as RM. Since I'm new to the
process, I think as happened with Piotr, I'll need help from Piotr and you
to be able to do it.
3) Fix any issue we find, and even try to see if we the new improvements
can add up to simplify the current process
>
> I thought we already had made the changes to build with Maven without
> Flash.
>
The new process simplifies it so newcomers (and all of us) benefits from
having less prerequisites in his machine (like less env vars required for
example) so we should expect more people be successful to get royale build
without problems in the process, also instructions to build are simplified.
We don't need to do different instructions anymore for a clean environment
and post first build, what seems to me a huge improvement. Also we use the
new maven reproducible builds that are supported in the build system from
some weeks now.
I think this is our main objetive as a project to simplify as possible to
make it more accesible for newcomers.
>
> I have some missing DG features to implement for Alina before I can find
> time to review the PR commits because they are big so might be several days.
>
ok, let me know if you want me to wait to merge to your reviews. The
problem of this is that the PRs could turn invalid and Chris could not be
available at that time and that could make this effort to be lost. So that
could complicate this merge. My opinion is that if some of us test the PRs
and get it working we should not stop the merge to be done, and then over
this changes we can go over the new 0.9.7 release in 2-3 weeks fixing any
CI issue we can find we me as RM and releasing a 0.9.7 in the process too.
Let me know what you think.
Thanks
Carlos
>
> -Alex
>
> On 11/15/19, 11:43 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex,
>
> my plan was to be a RM at some point, so maybe this is a good time to
> do it.
> I think we all agree that improvements and fixes will need other ones
> in
> the CI release steps. Can be improvements without touching that part
> too I
> think all the improvements are worth it the changes to CI process. I
> expect
> mostly it will be simplified since now the maven process is lighter.
> We have currently 2 clients migrating from Flex so maybe I'll need some
> weeks to mange it, but I could start a 0.9.7 at some point during
> December.
> Let me know what you think.
>
> btw, something important to pay attention that I think didn't describe
> well. enough in my previous emails: One of the changes was to allow to
> build the compiler too without the need to have any Flash stuff by not
> enabling the “option-with-swf” profile. So in general it should be
> possible
> to build Royale completely without any Flash third party stuff and to
> build
> it completely with all tests if you enable the “option-with-swf”
> dependency.
>
>
> El vie., 15 nov. 2019 a las 19:38, Alex Harui
> (<ah...@adobe.com.invalid>)
> escribió:
>
> > The second commit I looked at is also huge so I will not be able to
> review
> > it or any others right now.
> >
> > The things I remember wondering about in the first commit I reviewed
> is:
> > 1) changing of the timestamp options that ensured SWFs are
> reproducible
> > 2) removal of JGit which is needed by the CI release steps.
> >
> > Maybe they are restored in other commits.
> >
> > -Alex
> >
> > On 11/15/19, 10:32 AM, "Alex Harui" <ah...@adobe.com.INVALID>
> wrote:
> >
> > I've only reviewed one commit in one PR so far, but I think it
> will
> > break the CI release steps.
> >
> > Also, IMO, 0.9.6 has reproducible Maven artifacts.
> >
> > Improvements and fixes are welcome. Who is going to verify that
> the
> > CI release steps continue to work after these changes?
> >
> > -Alex
> >
> > On 11/15/19, 9:52 AM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> >
> > To all, about reproducible builds:
> >
> >
> > possibly the most interesting thing of all this changes
> might be
> > that now
> > we should allow releasing Royale via Maven with the ability
> of
> > creating
> > reproducible builds.
> >
> > Ideally releasing a part of Royale is just a 2-3 step
> process:
> >
> >
> >
> > - royale-compiler:
> > - mvn release:prepare -DautoversionSubmodules=true
> > - mvn release:perform
> > - royale-typedefs:
> > - update the pom.xml: royale.compiler.version to the
> new
> > released
> > version
> > - mvn release:prepare -DautoversionSubmodules=true
> > - mvn release:perform
> > - royale-asjs:
> > - update the pom.xml: royale.compiler.version and
> > royale.typedefs.version to the new released version
> > - mvn release:prepare -DautoversionSubmodules=true
> > - mvn release:perform
> >
> >
> > This combined with all the past effort done by Alex and
> Piotr,
> > should lower
> > the suffering of doing a release :)
> >
> > Carlos
> >
> >
> >
> > El vie., 15 nov. 2019 a las 15:46, Carlos Rovira (<
> > carlosrovira@apache.org>)
> > escribió:
> >
> > > Great you like it Harbs! :)
> > >
> > > I forgot to mention that another effort in parallel is to
> > release v1.0.0
> > > of "flex-sdk-converter-maven-extension" (located in Apache
> Flex
> > utilities
> > > repo),
> > > so we can remove the need to add "-s
> settings-template.xml" to
> > each line,
> > > what will improve event more the build process by reducing
> > verbosity :)
> > >
> > >
> > >
> > >
> > > El vie., 15 nov. 2019 a las 14:03, Harbs (<
> harbs.lists@gmail.com
> > >)
> > > escribió:
> > >
> > >> If it all works, sounds great to me! :-) (I’m not going
> to be
> > able to
> > >> test until sometime next week, but don’t wait for me.)
> > >>
> > >> Thanks to Chris for working on this!
> > >>
> > >> Harbs
> > >>
> > >> > On Nov 15, 2019, at 2:45 PM, Carlos Rovira <
> > carlosrovira@apache.org>
> > >> wrote:
> > >> >
> > >> > Hi,
> > >> >
> > >> > this days Chris Dutz has had the deference and detail of
> > working on
> > >> > improving Apache Royale Maven build by simplifying the
> > scripts so we all
> > >> > have less headaches with all this stuff that he knows
> and
> > master so
> > >> well.
> > >> > I want to give a big thanks to Chris for investing his
> time
> > in working
> > >> on
> > >> > this huge improvement that for sure will help all us
> when
> > building
> > >> royale
> > >> > in the daily basis and as well when having to make a new
> > release.
> > >> >
> > >> > So Chris created 3 PRs that are for each repo to test.
> > >> >
> > >> > I already tested it and simplify all greatly.
> > >> >
> > >> > Here the recipe for building everything including tests
> and
> > UI tests
> > >> and so
> > >> > on:
> > >> >
> > >> > #!/bin/bash
> > >> >
> > >> > *export*
> > >>
> >
> FLASHPLAYER_DEBUGGER="/Users/christofer.dutz/Devtools/Adobe/Flash/FlashPlayer-32.0/Flash
> > >> > Player.app/Contents/MacOS/Flash Player Debugger"
> > >> >
> > >> > *cd* royale-compiler
> > >> >
> > >> > ./mvnw install -s settings-template.xml
> > >> >
> > >> > *cd* ../royale-typedefs
> > >> >
> > >> > ./mvnw install -s settings-template.xml
> > >> >
> > >> > *cd* ../royale-asjs
> > >> >
> > >> > ./mvnw install -s settings-template.xml -P
> > >> >
> > with-examples,with-distribution,with-ui-testsuite,option-with-swf
> > >> >
> > -Dwebdriver.gecko.driver=/Users/christofer.dutz/Downloads/geckodriver
> > >> >
> > >> > *cd* ..
> > >> >
> > >> >
> > >> > you can use mvn or mvnw that will install Maven if you
> don't
> > have any
> > >> > installed :)
> > >> >
> > >> >
> > >> >
> > >> > You probably need to adjust the paths to the
> > FLASHPLAYER_DEBUGGER as
> > >> well
> > >> > as for the geckodriver
> > >> >
> > >> > (If you don’t want to execute the Selenium UI tests in
> > Firefox, just
> > >> omit
> > >> > the “with-ui-testsuite” profile)
> > >> >
> > >> > (Noting that I should add a Firefox detection to my
> > prerequisite check)
> > >> >
> > >> >
> > >> > You should not need to have FLASHPLAYERGLOBAL_HOME and
> > >> > FLASHPLAYERGLOBAL_VERSION
> > >> >
> > >> >
> > >> >
> > >> > The profiles:
> > >> >
> > >> > - *with-examples*: Well it builds the examples too
> > >> > - *with-distribution*: It lets the build also build
> the
> > distribution
> > >> > (this part is still incomplete, since like today, it
> does
> > not
> > >> generate a
> > >> > valid SDK, but I'll work on this with Chris this next
> week).
> > >> > - *option-with-swf*: It also makes each module build
> the
> > swf version
> > >> > - *with-ui-testsuite*: It also builds the testsuite
> modules
> > and runs
> > >> the
> > >> > integration-tests
> > >> >
> > >> >
> > >> > This PRs also introduces many fixes like a SASS new
> version
> > that handles
> > >> > memory better (that was causing all process to hang when
> > launching all
> > >> in
> > >> > one single instruction due to memory leaks). Please
> revise
> > the PRs to
> > >> read
> > >> > about all the list of improvements in this update.
> > >> >
> > >> > So If nobody opposite, I'd like to merge this
> improvement in
> > the next
> > >> hours.
> > >> >
> > >> > Thanks! :)
> > >> >
> > >> > --
> > >> > Carlos Rovira
> > >> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9b44bb63e1554ae8cb4508d76a041002%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094437994238672&sdata=YfvlKUhe2ROsEgCCLlOs1sUP73wNVdFYJcvvBT7iuJs%3D&reserved=0
> > >>
> > >>
> > >
> > > --
> > > Carlos Rovira
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9b44bb63e1554ae8cb4508d76a041002%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094437994238672&sdata=YfvlKUhe2ROsEgCCLlOs1sUP73wNVdFYJcvvBT7iuJs%3D&reserved=0
> > >
> > >
> >
> > --
> > Carlos Rovira
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9b44bb63e1554ae8cb4508d76a041002%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094437994238672&sdata=YfvlKUhe2ROsEgCCLlOs1sUP73wNVdFYJcvvBT7iuJs%3D&reserved=0
> >
> >
> >
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9b44bb63e1554ae8cb4508d76a041002%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094437994248665&sdata=H%2Fsk6jcsrPsT%2FLQ7esrUKafJXU2SjbQh3iti8IkX%2Fes%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi Carlos,
If/When you decide to merge these PRs, please make sure you have reserved time to fix anything it breaks in CI.
I thought we already had made the changes to build with Maven without Flash.
I have some missing DG features to implement for Alina before I can find time to review the PR commits because they are big so might be several days.
-Alex
On 11/15/19, 11:43 AM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex,
my plan was to be a RM at some point, so maybe this is a good time to do it.
I think we all agree that improvements and fixes will need other ones in
the CI release steps. Can be improvements without touching that part too I
think all the improvements are worth it the changes to CI process. I expect
mostly it will be simplified since now the maven process is lighter.
We have currently 2 clients migrating from Flex so maybe I'll need some
weeks to mange it, but I could start a 0.9.7 at some point during December.
Let me know what you think.
btw, something important to pay attention that I think didn't describe
well. enough in my previous emails: One of the changes was to allow to
build the compiler too without the need to have any Flash stuff by not
enabling the “option-with-swf” profile. So in general it should be possible
to build Royale completely without any Flash third party stuff and to build
it completely with all tests if you enable the “option-with-swf” dependency.
El vie., 15 nov. 2019 a las 19:38, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> The second commit I looked at is also huge so I will not be able to review
> it or any others right now.
>
> The things I remember wondering about in the first commit I reviewed is:
> 1) changing of the timestamp options that ensured SWFs are reproducible
> 2) removal of JGit which is needed by the CI release steps.
>
> Maybe they are restored in other commits.
>
> -Alex
>
> On 11/15/19, 10:32 AM, "Alex Harui" <ah...@adobe.com.INVALID> wrote:
>
> I've only reviewed one commit in one PR so far, but I think it will
> break the CI release steps.
>
> Also, IMO, 0.9.6 has reproducible Maven artifacts.
>
> Improvements and fixes are welcome. Who is going to verify that the
> CI release steps continue to work after these changes?
>
> -Alex
>
> On 11/15/19, 9:52 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> To all, about reproducible builds:
>
>
> possibly the most interesting thing of all this changes might be
> that now
> we should allow releasing Royale via Maven with the ability of
> creating
> reproducible builds.
>
> Ideally releasing a part of Royale is just a 2-3 step process:
>
>
>
> - royale-compiler:
> - mvn release:prepare -DautoversionSubmodules=true
> - mvn release:perform
> - royale-typedefs:
> - update the pom.xml: royale.compiler.version to the new
> released
> version
> - mvn release:prepare -DautoversionSubmodules=true
> - mvn release:perform
> - royale-asjs:
> - update the pom.xml: royale.compiler.version and
> royale.typedefs.version to the new released version
> - mvn release:prepare -DautoversionSubmodules=true
> - mvn release:perform
>
>
> This combined with all the past effort done by Alex and Piotr,
> should lower
> the suffering of doing a release :)
>
> Carlos
>
>
>
> El vie., 15 nov. 2019 a las 15:46, Carlos Rovira (<
> carlosrovira@apache.org>)
> escribió:
>
> > Great you like it Harbs! :)
> >
> > I forgot to mention that another effort in parallel is to
> release v1.0.0
> > of "flex-sdk-converter-maven-extension" (located in Apache Flex
> utilities
> > repo),
> > so we can remove the need to add "-s settings-template.xml" to
> each line,
> > what will improve event more the build process by reducing
> verbosity :)
> >
> >
> >
> >
> > El vie., 15 nov. 2019 a las 14:03, Harbs (<harbs.lists@gmail.com
> >)
> > escribió:
> >
> >> If it all works, sounds great to me! :-) (I’m not going to be
> able to
> >> test until sometime next week, but don’t wait for me.)
> >>
> >> Thanks to Chris for working on this!
> >>
> >> Harbs
> >>
> >> > On Nov 15, 2019, at 2:45 PM, Carlos Rovira <
> carlosrovira@apache.org>
> >> wrote:
> >> >
> >> > Hi,
> >> >
> >> > this days Chris Dutz has had the deference and detail of
> working on
> >> > improving Apache Royale Maven build by simplifying the
> scripts so we all
> >> > have less headaches with all this stuff that he knows and
> master so
> >> well.
> >> > I want to give a big thanks to Chris for investing his time
> in working
> >> on
> >> > this huge improvement that for sure will help all us when
> building
> >> royale
> >> > in the daily basis and as well when having to make a new
> release.
> >> >
> >> > So Chris created 3 PRs that are for each repo to test.
> >> >
> >> > I already tested it and simplify all greatly.
> >> >
> >> > Here the recipe for building everything including tests and
> UI tests
> >> and so
> >> > on:
> >> >
> >> > #!/bin/bash
> >> >
> >> > *export*
> >>
> FLASHPLAYER_DEBUGGER="/Users/christofer.dutz/Devtools/Adobe/Flash/FlashPlayer-32.0/Flash
> >> > Player.app/Contents/MacOS/Flash Player Debugger"
> >> >
> >> > *cd* royale-compiler
> >> >
> >> > ./mvnw install -s settings-template.xml
> >> >
> >> > *cd* ../royale-typedefs
> >> >
> >> > ./mvnw install -s settings-template.xml
> >> >
> >> > *cd* ../royale-asjs
> >> >
> >> > ./mvnw install -s settings-template.xml -P
> >> >
> with-examples,with-distribution,with-ui-testsuite,option-with-swf
> >> >
> -Dwebdriver.gecko.driver=/Users/christofer.dutz/Downloads/geckodriver
> >> >
> >> > *cd* ..
> >> >
> >> >
> >> > you can use mvn or mvnw that will install Maven if you don't
> have any
> >> > installed :)
> >> >
> >> >
> >> >
> >> > You probably need to adjust the paths to the
> FLASHPLAYER_DEBUGGER as
> >> well
> >> > as for the geckodriver
> >> >
> >> > (If you don’t want to execute the Selenium UI tests in
> Firefox, just
> >> omit
> >> > the “with-ui-testsuite” profile)
> >> >
> >> > (Noting that I should add a Firefox detection to my
> prerequisite check)
> >> >
> >> >
> >> > You should not need to have FLASHPLAYERGLOBAL_HOME and
> >> > FLASHPLAYERGLOBAL_VERSION
> >> >
> >> >
> >> >
> >> > The profiles:
> >> >
> >> > - *with-examples*: Well it builds the examples too
> >> > - *with-distribution*: It lets the build also build the
> distribution
> >> > (this part is still incomplete, since like today, it does
> not
> >> generate a
> >> > valid SDK, but I'll work on this with Chris this next week).
> >> > - *option-with-swf*: It also makes each module build the
> swf version
> >> > - *with-ui-testsuite*: It also builds the testsuite modules
> and runs
> >> the
> >> > integration-tests
> >> >
> >> >
> >> > This PRs also introduces many fixes like a SASS new version
> that handles
> >> > memory better (that was causing all process to hang when
> launching all
> >> in
> >> > one single instruction due to memory leaks). Please revise
> the PRs to
> >> read
> >> > about all the list of improvements in this update.
> >> >
> >> > So If nobody opposite, I'd like to merge this improvement in
> the next
> >> hours.
> >> >
> >> > Thanks! :)
> >> >
> >> > --
> >> > Carlos Rovira
> >> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9b44bb63e1554ae8cb4508d76a041002%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094437994238672&sdata=YfvlKUhe2ROsEgCCLlOs1sUP73wNVdFYJcvvBT7iuJs%3D&reserved=0
> >>
> >>
> >
> > --
> > Carlos Rovira
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9b44bb63e1554ae8cb4508d76a041002%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094437994238672&sdata=YfvlKUhe2ROsEgCCLlOs1sUP73wNVdFYJcvvBT7iuJs%3D&reserved=0
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9b44bb63e1554ae8cb4508d76a041002%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094437994238672&sdata=YfvlKUhe2ROsEgCCLlOs1sUP73wNVdFYJcvvBT7iuJs%3D&reserved=0
>
>
>
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9b44bb63e1554ae8cb4508d76a041002%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094437994248665&sdata=H%2Fsk6jcsrPsT%2FLQ7esrUKafJXU2SjbQh3iti8IkX%2Fes%3D&reserved=0
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
my plan was to be a RM at some point, so maybe this is a good time to do it.
I think we all agree that improvements and fixes will need other ones in
the CI release steps. Can be improvements without touching that part too I
think all the improvements are worth it the changes to CI process. I expect
mostly it will be simplified since now the maven process is lighter.
We have currently 2 clients migrating from Flex so maybe I'll need some
weeks to mange it, but I could start a 0.9.7 at some point during December.
Let me know what you think.
btw, something important to pay attention that I think didn't describe
well. enough in my previous emails: One of the changes was to allow to
build the compiler too without the need to have any Flash stuff by not
enabling the “option-with-swf” profile. So in general it should be possible
to build Royale completely without any Flash third party stuff and to build
it completely with all tests if you enable the “option-with-swf” dependency.
El vie., 15 nov. 2019 a las 19:38, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> The second commit I looked at is also huge so I will not be able to review
> it or any others right now.
>
> The things I remember wondering about in the first commit I reviewed is:
> 1) changing of the timestamp options that ensured SWFs are reproducible
> 2) removal of JGit which is needed by the CI release steps.
>
> Maybe they are restored in other commits.
>
> -Alex
>
> On 11/15/19, 10:32 AM, "Alex Harui" <ah...@adobe.com.INVALID> wrote:
>
> I've only reviewed one commit in one PR so far, but I think it will
> break the CI release steps.
>
> Also, IMO, 0.9.6 has reproducible Maven artifacts.
>
> Improvements and fixes are welcome. Who is going to verify that the
> CI release steps continue to work after these changes?
>
> -Alex
>
> On 11/15/19, 9:52 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> To all, about reproducible builds:
>
>
> possibly the most interesting thing of all this changes might be
> that now
> we should allow releasing Royale via Maven with the ability of
> creating
> reproducible builds.
>
> Ideally releasing a part of Royale is just a 2-3 step process:
>
>
>
> - royale-compiler:
> - mvn release:prepare -DautoversionSubmodules=true
> - mvn release:perform
> - royale-typedefs:
> - update the pom.xml: royale.compiler.version to the new
> released
> version
> - mvn release:prepare -DautoversionSubmodules=true
> - mvn release:perform
> - royale-asjs:
> - update the pom.xml: royale.compiler.version and
> royale.typedefs.version to the new released version
> - mvn release:prepare -DautoversionSubmodules=true
> - mvn release:perform
>
>
> This combined with all the past effort done by Alex and Piotr,
> should lower
> the suffering of doing a release :)
>
> Carlos
>
>
>
> El vie., 15 nov. 2019 a las 15:46, Carlos Rovira (<
> carlosrovira@apache.org>)
> escribió:
>
> > Great you like it Harbs! :)
> >
> > I forgot to mention that another effort in parallel is to
> release v1.0.0
> > of "flex-sdk-converter-maven-extension" (located in Apache Flex
> utilities
> > repo),
> > so we can remove the need to add "-s settings-template.xml" to
> each line,
> > what will improve event more the build process by reducing
> verbosity :)
> >
> >
> >
> >
> > El vie., 15 nov. 2019 a las 14:03, Harbs (<harbs.lists@gmail.com
> >)
> > escribió:
> >
> >> If it all works, sounds great to me! :-) (I’m not going to be
> able to
> >> test until sometime next week, but don’t wait for me.)
> >>
> >> Thanks to Chris for working on this!
> >>
> >> Harbs
> >>
> >> > On Nov 15, 2019, at 2:45 PM, Carlos Rovira <
> carlosrovira@apache.org>
> >> wrote:
> >> >
> >> > Hi,
> >> >
> >> > this days Chris Dutz has had the deference and detail of
> working on
> >> > improving Apache Royale Maven build by simplifying the
> scripts so we all
> >> > have less headaches with all this stuff that he knows and
> master so
> >> well.
> >> > I want to give a big thanks to Chris for investing his time
> in working
> >> on
> >> > this huge improvement that for sure will help all us when
> building
> >> royale
> >> > in the daily basis and as well when having to make a new
> release.
> >> >
> >> > So Chris created 3 PRs that are for each repo to test.
> >> >
> >> > I already tested it and simplify all greatly.
> >> >
> >> > Here the recipe for building everything including tests and
> UI tests
> >> and so
> >> > on:
> >> >
> >> > #!/bin/bash
> >> >
> >> > *export*
> >>
> FLASHPLAYER_DEBUGGER="/Users/christofer.dutz/Devtools/Adobe/Flash/FlashPlayer-32.0/Flash
> >> > Player.app/Contents/MacOS/Flash Player Debugger"
> >> >
> >> > *cd* royale-compiler
> >> >
> >> > ./mvnw install -s settings-template.xml
> >> >
> >> > *cd* ../royale-typedefs
> >> >
> >> > ./mvnw install -s settings-template.xml
> >> >
> >> > *cd* ../royale-asjs
> >> >
> >> > ./mvnw install -s settings-template.xml -P
> >> >
> with-examples,with-distribution,with-ui-testsuite,option-with-swf
> >> >
> -Dwebdriver.gecko.driver=/Users/christofer.dutz/Downloads/geckodriver
> >> >
> >> > *cd* ..
> >> >
> >> >
> >> > you can use mvn or mvnw that will install Maven if you don't
> have any
> >> > installed :)
> >> >
> >> >
> >> >
> >> > You probably need to adjust the paths to the
> FLASHPLAYER_DEBUGGER as
> >> well
> >> > as for the geckodriver
> >> >
> >> > (If you don’t want to execute the Selenium UI tests in
> Firefox, just
> >> omit
> >> > the “with-ui-testsuite” profile)
> >> >
> >> > (Noting that I should add a Firefox detection to my
> prerequisite check)
> >> >
> >> >
> >> > You should not need to have FLASHPLAYERGLOBAL_HOME and
> >> > FLASHPLAYERGLOBAL_VERSION
> >> >
> >> >
> >> >
> >> > The profiles:
> >> >
> >> > - *with-examples*: Well it builds the examples too
> >> > - *with-distribution*: It lets the build also build the
> distribution
> >> > (this part is still incomplete, since like today, it does
> not
> >> generate a
> >> > valid SDK, but I'll work on this with Chris this next week).
> >> > - *option-with-swf*: It also makes each module build the
> swf version
> >> > - *with-ui-testsuite*: It also builds the testsuite modules
> and runs
> >> the
> >> > integration-tests
> >> >
> >> >
> >> > This PRs also introduces many fixes like a SASS new version
> that handles
> >> > memory better (that was causing all process to hang when
> launching all
> >> in
> >> > one single instruction due to memory leaks). Please revise
> the PRs to
> >> read
> >> > about all the list of improvements in this update.
> >> >
> >> > So If nobody opposite, I'd like to merge this improvement in
> the next
> >> hours.
> >> >
> >> > Thanks! :)
> >> >
> >> > --
> >> > Carlos Rovira
> >> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1e5ebf7f7aa2429853a608d769fa242f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094395389616999&sdata=Pa3PfYoV1iaz4sh3Ucyo5%2FEiJvQYj3pcyFgwYTXnjCE%3D&reserved=0
> >>
> >>
> >
> > --
> > Carlos Rovira
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1e5ebf7f7aa2429853a608d769fa242f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094395389616999&sdata=Pa3PfYoV1iaz4sh3Ucyo5%2FEiJvQYj3pcyFgwYTXnjCE%3D&reserved=0
> >
> >
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1e5ebf7f7aa2429853a608d769fa242f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094395389616999&sdata=Pa3PfYoV1iaz4sh3Ucyo5%2FEiJvQYj3pcyFgwYTXnjCE%3D&reserved=0
>
>
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Alex Harui <ah...@adobe.com.INVALID>.
The second commit I looked at is also huge so I will not be able to review it or any others right now.
The things I remember wondering about in the first commit I reviewed is:
1) changing of the timestamp options that ensured SWFs are reproducible
2) removal of JGit which is needed by the CI release steps.
Maybe they are restored in other commits.
-Alex
On 11/15/19, 10:32 AM, "Alex Harui" <ah...@adobe.com.INVALID> wrote:
I've only reviewed one commit in one PR so far, but I think it will break the CI release steps.
Also, IMO, 0.9.6 has reproducible Maven artifacts.
Improvements and fixes are welcome. Who is going to verify that the CI release steps continue to work after these changes?
-Alex
On 11/15/19, 9:52 AM, "Carlos Rovira" <ca...@apache.org> wrote:
To all, about reproducible builds:
possibly the most interesting thing of all this changes might be that now
we should allow releasing Royale via Maven with the ability of creating
reproducible builds.
Ideally releasing a part of Royale is just a 2-3 step process:
- royale-compiler:
- mvn release:prepare -DautoversionSubmodules=true
- mvn release:perform
- royale-typedefs:
- update the pom.xml: royale.compiler.version to the new released
version
- mvn release:prepare -DautoversionSubmodules=true
- mvn release:perform
- royale-asjs:
- update the pom.xml: royale.compiler.version and
royale.typedefs.version to the new released version
- mvn release:prepare -DautoversionSubmodules=true
- mvn release:perform
This combined with all the past effort done by Alex and Piotr, should lower
the suffering of doing a release :)
Carlos
El vie., 15 nov. 2019 a las 15:46, Carlos Rovira (<ca...@apache.org>)
escribió:
> Great you like it Harbs! :)
>
> I forgot to mention that another effort in parallel is to release v1.0.0
> of "flex-sdk-converter-maven-extension" (located in Apache Flex utilities
> repo),
> so we can remove the need to add "-s settings-template.xml" to each line,
> what will improve event more the build process by reducing verbosity :)
>
>
>
>
> El vie., 15 nov. 2019 a las 14:03, Harbs (<ha...@gmail.com>)
> escribió:
>
>> If it all works, sounds great to me! :-) (I’m not going to be able to
>> test until sometime next week, but don’t wait for me.)
>>
>> Thanks to Chris for working on this!
>>
>> Harbs
>>
>> > On Nov 15, 2019, at 2:45 PM, Carlos Rovira <ca...@apache.org>
>> wrote:
>> >
>> > Hi,
>> >
>> > this days Chris Dutz has had the deference and detail of working on
>> > improving Apache Royale Maven build by simplifying the scripts so we all
>> > have less headaches with all this stuff that he knows and master so
>> well.
>> > I want to give a big thanks to Chris for investing his time in working
>> on
>> > this huge improvement that for sure will help all us when building
>> royale
>> > in the daily basis and as well when having to make a new release.
>> >
>> > So Chris created 3 PRs that are for each repo to test.
>> >
>> > I already tested it and simplify all greatly.
>> >
>> > Here the recipe for building everything including tests and UI tests
>> and so
>> > on:
>> >
>> > #!/bin/bash
>> >
>> > *export*
>> FLASHPLAYER_DEBUGGER="/Users/christofer.dutz/Devtools/Adobe/Flash/FlashPlayer-32.0/Flash
>> > Player.app/Contents/MacOS/Flash Player Debugger"
>> >
>> > *cd* royale-compiler
>> >
>> > ./mvnw install -s settings-template.xml
>> >
>> > *cd* ../royale-typedefs
>> >
>> > ./mvnw install -s settings-template.xml
>> >
>> > *cd* ../royale-asjs
>> >
>> > ./mvnw install -s settings-template.xml -P
>> > with-examples,with-distribution,with-ui-testsuite,option-with-swf
>> > -Dwebdriver.gecko.driver=/Users/christofer.dutz/Downloads/geckodriver
>> >
>> > *cd* ..
>> >
>> >
>> > you can use mvn or mvnw that will install Maven if you don't have any
>> > installed :)
>> >
>> >
>> >
>> > You probably need to adjust the paths to the FLASHPLAYER_DEBUGGER as
>> well
>> > as for the geckodriver
>> >
>> > (If you don’t want to execute the Selenium UI tests in Firefox, just
>> omit
>> > the “with-ui-testsuite” profile)
>> >
>> > (Noting that I should add a Firefox detection to my prerequisite check)
>> >
>> >
>> > You should not need to have FLASHPLAYERGLOBAL_HOME and
>> > FLASHPLAYERGLOBAL_VERSION
>> >
>> >
>> >
>> > The profiles:
>> >
>> > - *with-examples*: Well it builds the examples too
>> > - *with-distribution*: It lets the build also build the distribution
>> > (this part is still incomplete, since like today, it does not
>> generate a
>> > valid SDK, but I'll work on this with Chris this next week).
>> > - *option-with-swf*: It also makes each module build the swf version
>> > - *with-ui-testsuite*: It also builds the testsuite modules and runs
>> the
>> > integration-tests
>> >
>> >
>> > This PRs also introduces many fixes like a SASS new version that handles
>> > memory better (that was causing all process to hang when launching all
>> in
>> > one single instruction due to memory leaks). Please revise the PRs to
>> read
>> > about all the list of improvements in this update.
>> >
>> > So If nobody opposite, I'd like to merge this improvement in the next
>> hours.
>> >
>> > Thanks! :)
>> >
>> > --
>> > Carlos Rovira
>> > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1e5ebf7f7aa2429853a608d769fa242f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094395389616999&sdata=Pa3PfYoV1iaz4sh3Ucyo5%2FEiJvQYj3pcyFgwYTXnjCE%3D&reserved=0
>>
>>
>
> --
> Carlos Rovira
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1e5ebf7f7aa2429853a608d769fa242f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094395389616999&sdata=Pa3PfYoV1iaz4sh3Ucyo5%2FEiJvQYj3pcyFgwYTXnjCE%3D&reserved=0
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1e5ebf7f7aa2429853a608d769fa242f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094395389616999&sdata=Pa3PfYoV1iaz4sh3Ucyo5%2FEiJvQYj3pcyFgwYTXnjCE%3D&reserved=0
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I've only reviewed one commit in one PR so far, but I think it will break the CI release steps.
Also, IMO, 0.9.6 has reproducible Maven artifacts.
Improvements and fixes are welcome. Who is going to verify that the CI release steps continue to work after these changes?
-Alex
On 11/15/19, 9:52 AM, "Carlos Rovira" <ca...@apache.org> wrote:
To all, about reproducible builds:
possibly the most interesting thing of all this changes might be that now
we should allow releasing Royale via Maven with the ability of creating
reproducible builds.
Ideally releasing a part of Royale is just a 2-3 step process:
- royale-compiler:
- mvn release:prepare -DautoversionSubmodules=true
- mvn release:perform
- royale-typedefs:
- update the pom.xml: royale.compiler.version to the new released
version
- mvn release:prepare -DautoversionSubmodules=true
- mvn release:perform
- royale-asjs:
- update the pom.xml: royale.compiler.version and
royale.typedefs.version to the new released version
- mvn release:prepare -DautoversionSubmodules=true
- mvn release:perform
This combined with all the past effort done by Alex and Piotr, should lower
the suffering of doing a release :)
Carlos
El vie., 15 nov. 2019 a las 15:46, Carlos Rovira (<ca...@apache.org>)
escribió:
> Great you like it Harbs! :)
>
> I forgot to mention that another effort in parallel is to release v1.0.0
> of "flex-sdk-converter-maven-extension" (located in Apache Flex utilities
> repo),
> so we can remove the need to add "-s settings-template.xml" to each line,
> what will improve event more the build process by reducing verbosity :)
>
>
>
>
> El vie., 15 nov. 2019 a las 14:03, Harbs (<ha...@gmail.com>)
> escribió:
>
>> If it all works, sounds great to me! :-) (I’m not going to be able to
>> test until sometime next week, but don’t wait for me.)
>>
>> Thanks to Chris for working on this!
>>
>> Harbs
>>
>> > On Nov 15, 2019, at 2:45 PM, Carlos Rovira <ca...@apache.org>
>> wrote:
>> >
>> > Hi,
>> >
>> > this days Chris Dutz has had the deference and detail of working on
>> > improving Apache Royale Maven build by simplifying the scripts so we all
>> > have less headaches with all this stuff that he knows and master so
>> well.
>> > I want to give a big thanks to Chris for investing his time in working
>> on
>> > this huge improvement that for sure will help all us when building
>> royale
>> > in the daily basis and as well when having to make a new release.
>> >
>> > So Chris created 3 PRs that are for each repo to test.
>> >
>> > I already tested it and simplify all greatly.
>> >
>> > Here the recipe for building everything including tests and UI tests
>> and so
>> > on:
>> >
>> > #!/bin/bash
>> >
>> > *export*
>> FLASHPLAYER_DEBUGGER="/Users/christofer.dutz/Devtools/Adobe/Flash/FlashPlayer-32.0/Flash
>> > Player.app/Contents/MacOS/Flash Player Debugger"
>> >
>> > *cd* royale-compiler
>> >
>> > ./mvnw install -s settings-template.xml
>> >
>> > *cd* ../royale-typedefs
>> >
>> > ./mvnw install -s settings-template.xml
>> >
>> > *cd* ../royale-asjs
>> >
>> > ./mvnw install -s settings-template.xml -P
>> > with-examples,with-distribution,with-ui-testsuite,option-with-swf
>> > -Dwebdriver.gecko.driver=/Users/christofer.dutz/Downloads/geckodriver
>> >
>> > *cd* ..
>> >
>> >
>> > you can use mvn or mvnw that will install Maven if you don't have any
>> > installed :)
>> >
>> >
>> >
>> > You probably need to adjust the paths to the FLASHPLAYER_DEBUGGER as
>> well
>> > as for the geckodriver
>> >
>> > (If you don’t want to execute the Selenium UI tests in Firefox, just
>> omit
>> > the “with-ui-testsuite” profile)
>> >
>> > (Noting that I should add a Firefox detection to my prerequisite check)
>> >
>> >
>> > You should not need to have FLASHPLAYERGLOBAL_HOME and
>> > FLASHPLAYERGLOBAL_VERSION
>> >
>> >
>> >
>> > The profiles:
>> >
>> > - *with-examples*: Well it builds the examples too
>> > - *with-distribution*: It lets the build also build the distribution
>> > (this part is still incomplete, since like today, it does not
>> generate a
>> > valid SDK, but I'll work on this with Chris this next week).
>> > - *option-with-swf*: It also makes each module build the swf version
>> > - *with-ui-testsuite*: It also builds the testsuite modules and runs
>> the
>> > integration-tests
>> >
>> >
>> > This PRs also introduces many fixes like a SASS new version that handles
>> > memory better (that was causing all process to hang when launching all
>> in
>> > one single instruction due to memory leaks). Please revise the PRs to
>> read
>> > about all the list of improvements in this update.
>> >
>> > So If nobody opposite, I'd like to merge this improvement in the next
>> hours.
>> >
>> > Thanks! :)
>> >
>> > --
>> > Carlos Rovira
>> > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C24ca878323424bb2578408d769f49839%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094371553758823&sdata=bA6JfyW7wQe%2F3sKjmrfVCD7h9olphjcH8DdlbY0oNUg%3D&reserved=0
>>
>>
>
> --
> Carlos Rovira
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C24ca878323424bb2578408d769f49839%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094371553758823&sdata=bA6JfyW7wQe%2F3sKjmrfVCD7h9olphjcH8DdlbY0oNUg%3D&reserved=0
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C24ca878323424bb2578408d769f49839%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637094371553758823&sdata=bA6JfyW7wQe%2F3sKjmrfVCD7h9olphjcH8DdlbY0oNUg%3D&reserved=0
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Carlos Rovira <ca...@apache.org>.
To all, about reproducible builds:
possibly the most interesting thing of all this changes might be that now
we should allow releasing Royale via Maven with the ability of creating
reproducible builds.
Ideally releasing a part of Royale is just a 2-3 step process:
- royale-compiler:
- mvn release:prepare -DautoversionSubmodules=true
- mvn release:perform
- royale-typedefs:
- update the pom.xml: royale.compiler.version to the new released
version
- mvn release:prepare -DautoversionSubmodules=true
- mvn release:perform
- royale-asjs:
- update the pom.xml: royale.compiler.version and
royale.typedefs.version to the new released version
- mvn release:prepare -DautoversionSubmodules=true
- mvn release:perform
This combined with all the past effort done by Alex and Piotr, should lower
the suffering of doing a release :)
Carlos
El vie., 15 nov. 2019 a las 15:46, Carlos Rovira (<ca...@apache.org>)
escribió:
> Great you like it Harbs! :)
>
> I forgot to mention that another effort in parallel is to release v1.0.0
> of "flex-sdk-converter-maven-extension" (located in Apache Flex utilities
> repo),
> so we can remove the need to add "-s settings-template.xml" to each line,
> what will improve event more the build process by reducing verbosity :)
>
>
>
>
> El vie., 15 nov. 2019 a las 14:03, Harbs (<ha...@gmail.com>)
> escribió:
>
>> If it all works, sounds great to me! :-) (I’m not going to be able to
>> test until sometime next week, but don’t wait for me.)
>>
>> Thanks to Chris for working on this!
>>
>> Harbs
>>
>> > On Nov 15, 2019, at 2:45 PM, Carlos Rovira <ca...@apache.org>
>> wrote:
>> >
>> > Hi,
>> >
>> > this days Chris Dutz has had the deference and detail of working on
>> > improving Apache Royale Maven build by simplifying the scripts so we all
>> > have less headaches with all this stuff that he knows and master so
>> well.
>> > I want to give a big thanks to Chris for investing his time in working
>> on
>> > this huge improvement that for sure will help all us when building
>> royale
>> > in the daily basis and as well when having to make a new release.
>> >
>> > So Chris created 3 PRs that are for each repo to test.
>> >
>> > I already tested it and simplify all greatly.
>> >
>> > Here the recipe for building everything including tests and UI tests
>> and so
>> > on:
>> >
>> > #!/bin/bash
>> >
>> > *export*
>> FLASHPLAYER_DEBUGGER="/Users/christofer.dutz/Devtools/Adobe/Flash/FlashPlayer-32.0/Flash
>> > Player.app/Contents/MacOS/Flash Player Debugger"
>> >
>> > *cd* royale-compiler
>> >
>> > ./mvnw install -s settings-template.xml
>> >
>> > *cd* ../royale-typedefs
>> >
>> > ./mvnw install -s settings-template.xml
>> >
>> > *cd* ../royale-asjs
>> >
>> > ./mvnw install -s settings-template.xml -P
>> > with-examples,with-distribution,with-ui-testsuite,option-with-swf
>> > -Dwebdriver.gecko.driver=/Users/christofer.dutz/Downloads/geckodriver
>> >
>> > *cd* ..
>> >
>> >
>> > you can use mvn or mvnw that will install Maven if you don't have any
>> > installed :)
>> >
>> >
>> >
>> > You probably need to adjust the paths to the FLASHPLAYER_DEBUGGER as
>> well
>> > as for the geckodriver
>> >
>> > (If you don’t want to execute the Selenium UI tests in Firefox, just
>> omit
>> > the “with-ui-testsuite” profile)
>> >
>> > (Noting that I should add a Firefox detection to my prerequisite check)
>> >
>> >
>> > You should not need to have FLASHPLAYERGLOBAL_HOME and
>> > FLASHPLAYERGLOBAL_VERSION
>> >
>> >
>> >
>> > The profiles:
>> >
>> > - *with-examples*: Well it builds the examples too
>> > - *with-distribution*: It lets the build also build the distribution
>> > (this part is still incomplete, since like today, it does not
>> generate a
>> > valid SDK, but I'll work on this with Chris this next week).
>> > - *option-with-swf*: It also makes each module build the swf version
>> > - *with-ui-testsuite*: It also builds the testsuite modules and runs
>> the
>> > integration-tests
>> >
>> >
>> > This PRs also introduces many fixes like a SASS new version that handles
>> > memory better (that was causing all process to hang when launching all
>> in
>> > one single instruction due to memory leaks). Please revise the PRs to
>> read
>> > about all the list of improvements in this update.
>> >
>> > So If nobody opposite, I'd like to merge this improvement in the next
>> hours.
>> >
>> > Thanks! :)
>> >
>> > --
>> > Carlos Rovira
>> > http://about.me/carlosrovira
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Carlos Rovira <ca...@apache.org>.
Great you like it Harbs! :)
I forgot to mention that another effort in parallel is to release v1.0.0 of
"flex-sdk-converter-maven-extension" (located in Apache Flex utilities
repo),
so we can remove the need to add "-s settings-template.xml" to each line,
what will improve event more the build process by reducing verbosity :)
El vie., 15 nov. 2019 a las 14:03, Harbs (<ha...@gmail.com>) escribió:
> If it all works, sounds great to me! :-) (I’m not going to be able to test
> until sometime next week, but don’t wait for me.)
>
> Thanks to Chris for working on this!
>
> Harbs
>
> > On Nov 15, 2019, at 2:45 PM, Carlos Rovira <ca...@apache.org>
> wrote:
> >
> > Hi,
> >
> > this days Chris Dutz has had the deference and detail of working on
> > improving Apache Royale Maven build by simplifying the scripts so we all
> > have less headaches with all this stuff that he knows and master so well.
> > I want to give a big thanks to Chris for investing his time in working on
> > this huge improvement that for sure will help all us when building royale
> > in the daily basis and as well when having to make a new release.
> >
> > So Chris created 3 PRs that are for each repo to test.
> >
> > I already tested it and simplify all greatly.
> >
> > Here the recipe for building everything including tests and UI tests and
> so
> > on:
> >
> > #!/bin/bash
> >
> > *export*
> FLASHPLAYER_DEBUGGER="/Users/christofer.dutz/Devtools/Adobe/Flash/FlashPlayer-32.0/Flash
> > Player.app/Contents/MacOS/Flash Player Debugger"
> >
> > *cd* royale-compiler
> >
> > ./mvnw install -s settings-template.xml
> >
> > *cd* ../royale-typedefs
> >
> > ./mvnw install -s settings-template.xml
> >
> > *cd* ../royale-asjs
> >
> > ./mvnw install -s settings-template.xml -P
> > with-examples,with-distribution,with-ui-testsuite,option-with-swf
> > -Dwebdriver.gecko.driver=/Users/christofer.dutz/Downloads/geckodriver
> >
> > *cd* ..
> >
> >
> > you can use mvn or mvnw that will install Maven if you don't have any
> > installed :)
> >
> >
> >
> > You probably need to adjust the paths to the FLASHPLAYER_DEBUGGER as well
> > as for the geckodriver
> >
> > (If you don’t want to execute the Selenium UI tests in Firefox, just omit
> > the “with-ui-testsuite” profile)
> >
> > (Noting that I should add a Firefox detection to my prerequisite check)
> >
> >
> > You should not need to have FLASHPLAYERGLOBAL_HOME and
> > FLASHPLAYERGLOBAL_VERSION
> >
> >
> >
> > The profiles:
> >
> > - *with-examples*: Well it builds the examples too
> > - *with-distribution*: It lets the build also build the distribution
> > (this part is still incomplete, since like today, it does not generate
> a
> > valid SDK, but I'll work on this with Chris this next week).
> > - *option-with-swf*: It also makes each module build the swf version
> > - *with-ui-testsuite*: It also builds the testsuite modules and runs
> the
> > integration-tests
> >
> >
> > This PRs also introduces many fixes like a SASS new version that handles
> > memory better (that was causing all process to hang when launching all in
> > one single instruction due to memory leaks). Please revise the PRs to
> read
> > about all the list of improvements in this update.
> >
> > So If nobody opposite, I'd like to merge this improvement in the next
> hours.
> >
> > Thanks! :)
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Apache Royale Maven improvements, fixes and reproducible builds
PR by Chris Dutz
Posted by Harbs <ha...@gmail.com>.
If it all works, sounds great to me! :-) (I’m not going to be able to test until sometime next week, but don’t wait for me.)
Thanks to Chris for working on this!
Harbs
> On Nov 15, 2019, at 2:45 PM, Carlos Rovira <ca...@apache.org> wrote:
>
> Hi,
>
> this days Chris Dutz has had the deference and detail of working on
> improving Apache Royale Maven build by simplifying the scripts so we all
> have less headaches with all this stuff that he knows and master so well.
> I want to give a big thanks to Chris for investing his time in working on
> this huge improvement that for sure will help all us when building royale
> in the daily basis and as well when having to make a new release.
>
> So Chris created 3 PRs that are for each repo to test.
>
> I already tested it and simplify all greatly.
>
> Here the recipe for building everything including tests and UI tests and so
> on:
>
> #!/bin/bash
>
> *export* FLASHPLAYER_DEBUGGER="/Users/christofer.dutz/Devtools/Adobe/Flash/FlashPlayer-32.0/Flash
> Player.app/Contents/MacOS/Flash Player Debugger"
>
> *cd* royale-compiler
>
> ./mvnw install -s settings-template.xml
>
> *cd* ../royale-typedefs
>
> ./mvnw install -s settings-template.xml
>
> *cd* ../royale-asjs
>
> ./mvnw install -s settings-template.xml -P
> with-examples,with-distribution,with-ui-testsuite,option-with-swf
> -Dwebdriver.gecko.driver=/Users/christofer.dutz/Downloads/geckodriver
>
> *cd* ..
>
>
> you can use mvn or mvnw that will install Maven if you don't have any
> installed :)
>
>
>
> You probably need to adjust the paths to the FLASHPLAYER_DEBUGGER as well
> as for the geckodriver
>
> (If you don’t want to execute the Selenium UI tests in Firefox, just omit
> the “with-ui-testsuite” profile)
>
> (Noting that I should add a Firefox detection to my prerequisite check)
>
>
> You should not need to have FLASHPLAYERGLOBAL_HOME and
> FLASHPLAYERGLOBAL_VERSION
>
>
>
> The profiles:
>
> - *with-examples*: Well it builds the examples too
> - *with-distribution*: It lets the build also build the distribution
> (this part is still incomplete, since like today, it does not generate a
> valid SDK, but I'll work on this with Chris this next week).
> - *option-with-swf*: It also makes each module build the swf version
> - *with-ui-testsuite*: It also builds the testsuite modules and runs the
> integration-tests
>
>
> This PRs also introduces many fixes like a SASS new version that handles
> memory better (that was causing all process to hang when launching all in
> one single instruction due to memory leaks). Please revise the PRs to read
> about all the list of improvements in this update.
>
> So If nobody opposite, I'd like to merge this improvement in the next hours.
>
> Thanks! :)
>
> --
> Carlos Rovira
> http://about.me/carlosrovira