royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <>
Subject Re: [DISCUSS] project vs. product name vs artifact names
Date Mon, 02 Oct 2017 17:25:05 GMT
I changed the subject so sorry if this appears like a new thread.

Let's be a bit more explicit and see if that helps.  After getting the
packaging to start to work, I've changed my thoughts a bit.  I actually
think I agree with Carlos and Erik.

I am proposing that we post two different bundles on the
Apache mirrors, which is our main distribution channel.  We will only post
one source artifact because the build script can generate both bundles
based on environment variables.  We will also post dozens of Jars and SWCs
to Maven Central.  And I think we will have an NPM distribution as well.
For the purposes of this discussion, wherever you see .zip, also assume we
are providing a .tar.gz file as well.

Because we will only have one source artifact, we will call for a vote on
a product named: "Apache Royale x.y.z".  The source artifact will be

We will provide convenience binaries for IDE users.  They will be called: (has SWCs for SWF and requires

And: (can be unzipped and used as-is)

If we create other targets in the future, hopefully we will still only
have one source artifact and, for a webasm target the binary artifact
would be called.

I believe this conforms to Apache conventions about artifact names.  We
could call the "flexjs" artifact:

But I am mindful of Justin Hill's desire to keep FlexJS in the name

Meanwhile, everything that goes up on Maven will be under the group id:

  org.apache.royale.compiler (for compiler jars)
  org.apache.royale.typedefs (for typedefs SWCs)
  org.apache.royale.framework (for framework SWCs)

Note that in Apache FlexJS 0.8.0, we used the group ids:


So there is a project.productname pattern today, but I am proposing that
we don't need a separate product name because the IDE products primarily
differ by which SWCs go in the binary artifacts (there might be a
different default config.xml file too), and Maven users pick their
"product" by choosing which archetype they start with and/or what SWCs
they depend on.

Maven artifact names also include a classifier for the target platform.
For example, in the last release, Apache FlexJS posted to Maven Central:


I am proposing we keep that classifier pattern as we can probably use a
classifier for WebASM some day as in:


Last is NPM.  I don't know NPM that well, so this could certainly be
wrong.  But I think today, you can install Apache FlexJS 0.8.0 by doing:

  npm install flexjs -g

If we are going to use NPM to install the equivalent of the proposed then I think that should be called
royale-flexjs in NPM as well so you would type:

  npm install royale-flexjs -g

And if you can use NPM to get the equivalent of that would be done via:

  npm install royale-js -g

But I don't know how many folks will need to do that if you can just unzip and use it.  Not sure if we need to make
something available just by typing:

  npm install royale -g



On 10/2/17, 3:25 AM, " on behalf of Carlos Rovira"
< on behalf of> wrote:

>my opinion on this regard is that having many sub names (aka product
>and packages will only confuse people coming to Royale.
>As well, I think we already manage outputs via compiler params to dictate
>if we want to target one or more outputs.
>So I'll be more happy with only one name and only one package that could
>output JS, WASM, SWF, ....)
>People coming from Flex will find us and will know we can be their
>Meanwhile people that search for a frontend tech, will come to read about
>Angular, React, ...and hope in some time Royale. We don't
>want those people be contaminated for old Flash or Flex that could make
>them not choose us for something is not relevant to us.
>So I think we should always look forward and as we decided to remove "JS",
>we should as well not have a "FlexJS" version inside
>That's my 2ctn
>2017-10-02 11:25 GMT+02:00 Erik de Bruin <>:
>> Hi,
>> With the renaming effort planned to start right after the 'packaging'
>> branch lands, I think it makes sense to discuss and vote on the naming
>> the product(s) of this project.
>> Buried in another thread Alex remarked the following, which I think is
>> excellent suggestion:
>> "When we were discussing this earlier, we were discussing two
>> IDE-friendly release
>> artifacts, one designed for folks migrating from Apache Flex and another
>> for folks not interested in SWF.  In the packaging branch I have most of
>> that working.
>> We were discussing calling the migration package 'FlexJS' and the other
>> Royale or RoyaleJS.  The latter is considered by some folks to mean
>> for JS".  The package names would be apache-royale-flexjs-<version> and
>> maybe apache-royale-royalejs-<version>. The project name would
>> be Royale but I think we want to have artifacts that denote target
>> markets."
>> A strong case has been made to leave off the "JS" off all but the
>> legacy/migration package, which makes sense to me as well.
>> I think there are plans to have this project create multiple product
>> one that does AS3->WebAssembly), so I do not think that we should name
>> current product 'Royale'. It will be increasingly confusing to have a
>> product with the same name as the project and then have other products
>> the same project with totally different names. I suggest we come up
>>with a
>> naming convention that will reflect the functionality of the various
>> products and their link to the project. E.g. (off the top of my head,
>> to show what I mean): royale-as-js, royale-as-wasm, etc.
>> What do you think?
>> EdB
>> --
>> Ix Multimedia Software
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>> T. 06-51952295
>> I. 
>Carlos Rovira
>Director General
>M: +34 607 22 60 05
>Conocenos Avant2 en 1 minuto!
>Este mensaje se dirige exclusivamente a su destinatario y puede contener
>información privilegiada o confidencial. Si ha recibido este mensaje por
>error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
>proceda a su destrucción.
>De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
>S.A. La finalidad de dicho tratamiento es facilitar la prestación del
>servicio o información solicitados, teniendo usted derecho de acceso,
>rectificación, cancelación y oposición de sus datos dirigiéndose a
>oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación

View raw message