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 ()
escribió:
> Just chiming in from my perspective... I am definitely keen to
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
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
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
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
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
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 napisał(a):
> Hi,
>
> I'm thinking that we're investing many
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
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
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
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
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 wrote:
>
> Hi Alex,
>
> right, I don't want to start a discussion about deprecating ANT. I like
> Maven but I think neither
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
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 napisał(a):
> Fundamentally, I don't think we want to get
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
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
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" 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
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
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 (<
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
napisał(a):
> Thanks Piotr,
>
> first I want to wait for Alex response. If he agree that
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
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
napisał(a):
> Hi Piotr,
>
> in the first email of this thread I
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
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
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,
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" wrote:
Hi Alex,
El vie., 15 nov. 2019 a las 20:48,
Hi Alex,
El vie., 15 nov. 2019 a las 20:48, Alex Harui ()
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
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
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
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
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,
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:
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
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 wrote:
>
> Hi,
>
> this days Chris Dutz has had the deference and detail of
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
35 matches
Mail list logo
