Mailing-List: contact dev-help@royale.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@royale.apache.org
MIME-Version: 1.0
References: <D646E326.AF3D7%aharui@adobe.com>
In-Reply-To: <D646E326.AF3D7%aharui@adobe.com>
From: Piotr Zarzycki <piotrzarzycki21@gmail.com>
Date: Sat, 02 Dec 2017 12:00:34 +0000
Message-ID: <CAP37iKG86+e6O5Rg0PLARDvbpcReT0oMvUMc7ZjR8zTGjOySnw@mail.gmail.com>
Subject: Re: Repos and Releases
To: dev@royale.apache.org
Content-Type: multipart/alternative; boundary="089e08286d003956c9055f5a3c2a"
archived-at: Sat, 02 Dec 2017 12:01:01 -0000

--089e08286d003956c9055f5a3c2a
Content-Type: text/plain; charset="UTF-8"

Hi Alex,

Comments inline.

On Fri, Dec 1, 2017, 19:45 Alex Harui <aharui@adobe.com.invalid> wrote:

> Hi,
>
> The CI servers are reporting that the feature/rename branch is building
> and passing tests.  Theoretically, this means that there is a way to build
> the compiler, typedefs and framework without any Adobe code (Flash
> playerglobal.swc or AIR SDK), and without a Flex SDK.  I think we need
> some volunteers to try it to make sure there aren't places that still
> require Flash/Flex/AIR.
>
> The goal of this effort was not only to prove independence from the Adobe
> code, but also to make it easier for folks to get started with
> contributing to Royale.  In theory, you don't need any environment
> variables any more for both the Ant and Maven builds.  You should be able
> to clone the repos and run Ant or Maven in each of the repos.
>

Thank you!!!

There are still a few rough spots with Maven.  I think I finally found out
> why we have to do two Maven runs in the royale-compiler repo.  There is
> this issue [1] that the Maven folks say they won't fix that affects us
> (and other users).  We use our own plugins in building the compiler and
> those plugins have to be built separately before the main Maven build.
>
> We could move the plugin code to a separate repo and do a quick and
> separate release of the two plugin artifacts, but I am tempted to just
> leave the Maven build as is and require the two Maven runs for the first
> Royale release.  In subsequent releases, if we don't change the code in
> the plugins (and they probably won't change), folks won't need to run
> Maven twice because the future builds will use the plugins from the first
> Royale release.  I think we can be "brave" and give those two plugins
> 1.0.0 version numbers.
>

I'm for leaving as is that one and give as you sugested version 1.0.0.

Also some parts of the Maven build (mostly the examples) still have a
> dependency on Flash/AIR.  I left that in for now because I think for most
> folks, Maven will automatically bring down the Flash/AIR artifacts.
> Otherwise, I think we have to set up profiles for building the
> Flash/AIR-dependent artifacts, which I think is doable, I just don't know
> if it is worth it.
>

I think it won't bring up automatically that dependencies in following
case. If user download binary package, go to examples folder and try build
some example by Maven with targets=SWF,JSRoyale. Only build of framework
itself can initially download playerglobal. If I'm right ofcourse - even
with that I don't see too big issue. Let's not spend on that time.

The last thing to consider is what our source release packaging should
> look like.  In the past, we've done things like tuck a copy of
> flex-typedefs into a subfolder in the flex-falcon package.  In an earlier
> thread, folks said they'd prefer a single release package instead of a
> separate compiler package.  However, I would rather not try to stuff the
> compiler source into a subfolder of the asjs sources and get all of that
> to build.  Maven knows how to create source packages per repo.  It might
> be possible to create an aggregator project in yet another repo, but I'm
> not sure I want to spend the time to figure that out.  It might mean that
> this aggregator repo could launch Maven in all of the other repos which
> some folks have asked for.  But I think that the fastest way to get a
> release out is to have the Ant build aggregate the 3 repos just like if
> you zipped the parent folder of royale-compiler, royale-typedefs and
> royale-asjs.
>

Agree with that also. Let's not complicate. Ant agregate all three repos
and Maven can do stuff as is. In case of maven theoretically it's enough if
you have asjs repo cause the rest one will be downloaded.

Then, I think the release process is:
> 1) start the Maven release process on each repo
> 2) take the tags generated by Maven release process and have Ant use those
> tags to build the source package that we vote on.
> 3) voters would unzip the source package and run Maven in each of the 3
> subfolders or run "ant all" from the royale-asjs folder to build all of
> the sources.
>

Huge +1. Maven help us to simplify start of release. Can we have step by
step described on our wiki if someone will perform as RM? Maven have that
described maybe would be good move that one from confluence or at least
have link in the instruction.


> One issue with this kind of release packaging is that the IDE package is
> in a subfolder.  So, when you unzip the binary package, you don't point
> your IDE to the binary package, but rather, to the royale-asjs folder
> inside it.
>

For me it is something natural.

Anyway, I know that a lot of things to think about.  I'm going to poke at
> the code a bit more to make sure things are working and look into merging
> feature/rename into develop.
>

Let's merge it as fast as we can. I would also see in the develop Harbs
changes with namespaces before release, after your merge.


> Thoughts?
> -Alex
>
> [1] https://issues.apache.org/jira/browse/MNG-1911


Thanks,
Piotr

>
>

--089e08286d003956c9055f5a3c2a--