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 <[email protected]>
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 (<[email protected]>)
> 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" <[email protected]> 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
>

Reply via email to