> Ideally it wouldn't matter if you build it with Ant or Maven.

As I understand it, the scenario is that a developer makes a change and needs 
to package that change into a zip in order to see it in his/her IDE. In order 
to do that s/he will need to run some Ant scripts. How does the RM verify that 
these scripts work? I may be missing something…


Am 31.03.20, 17:59 schrieb "Yishay Weiss" <yishayj...@hotmail.com>:


    > - Some tooling could be added to validate artifacts created by any form 
of distribution with ones built by Ant

    If I understand Alex’s concern correctly he wants Ant users to see their 
Royale changes in any IDE. Is this tooling supposed to help with that?


    Am 31.03.20, 07:48 schrieb "Piotr Zarzycki" <piotrzarzyck...@gmail.com>:

        Hi Chris,

        Last comment from Alex explain exactly what release process has to do
        additional. - Did your document explanation included that step? Reading 
it
        I feel it includes, but I would like to make sure.

        Thanks,
        Piotr

        On Tue, Mar 31, 2020, 6:34 AM Alex Harui <aha...@adobe.com.invalid> 
wrote:

        >
        > 
https://lists.apache.org/thread.html/r6412a8240c1b690603d2ddd12b578ddfc3dc8436c24b15174a18fe74%40%3Cdev.royale.apache.org%3E
        >
        > A "build" (running 'ant main')  produces jars and swcs but does not 
create
        > the same output as 'ant release' which produces tar.gz and .zip 
files.  The
        > release artifacts are used in many IDEs and in NPM.  So, IMO, in the
        > creating of the release artifacts, the RM should ensure that it is 
possible
        > to create the tar.gz and .zip files via Ant, and to create at 
minimum, the
        > Maven jars and swcs and hopefully a working equivalent of the tar.gz 
and
        > .zip via Maven using the "distribution" profile.  A working 
"distribution"
        > profile did not exist in the past so it is a nice-to-have and not a
        > regression if the distribution profile's tar.gz and .zip has 
problems.  It
        > would be a regression if it turned out the build.xml files in the 
release
        > could not build the tar.gz and .zip correctly.
        >
        > The only way I can think of to validate that the build.xml files will 
do
        > the right thing is to actually run "ant release" at some point in the
        > release process.  In which case, you might as well use the resulting
        > artifacts.
        >
        > My 2 cents,
        > -Alex
        >
        > On 3/30/20, 12:11 PM, "Yishay Weiss" <yishayj...@hotmail.com> wrote:
        >
        >     > Ant artifacts are reproducible by running the Ant scripts.   
Again,
        > the scenario is that if an Ant user wants to try a local change in an 
IDE
        > or NPM we want >to ensure that they can run the Ant "release" target 
and
        > get the tar.gz or .zip they need.
        >
        >     “Again” suggests you’ve already given an explanation, but I 
couldn’t
        > find it. Can you expand on this scenario? If this is the only 
difference
        > you and Chris have I think it’s worth focusing on it.
        >
        >     On 3/30/20, 2:17 AM, "Carlos Rovira" <carlosrov...@apache.org> 
wrote:
        >
        >         Hi Chris,
        >
        >         thanks. I revise and for me is totally fine :)
        >
        >
        >         El lun., 30 mar. 2020 a las 9:33, Harbs 
(<harbs.li...@gmail.com>)
        > escribió:
        >
        >         > Thanks for that. The Google Doc is a great initiative!
        >         >
        >         > Harbs
        >         >
        >         > > On Mar 30, 2020, at 10:26 AM, Christofer Dutz <
        > christofer.d...@c-ware.de>
        >         > wrote:
        >         > >
        >         > > Hi all,
        >         > >
        >         > > as the discussion has gone back to: “the release should 
be as
        > in the 13
        >         > steps”, I’d like to re-focus on the probably more important
        > parts:
        >         > >
        >         > > I already started writing up a list of requirements and
        > options to
        >         > achieve them:
        >         > >
        >         >
        > 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1kMlNfgVVAtTBNb57Qe88-d0vbM-HdohgQFqWCBr-cAg%2Fedit%23&amp;data=02%7C01%7Caharui%40adobe.com%7Cb9e4d4ca20864eabf7a608d7d4de296d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637211922954783626&amp;sdata=wykDg%2FGYXXpYQk2RE2Und%2BxZ7Qzr7lDXhInGuhgA4Xc%3D&amp;reserved=0
        >         > <
        >         >
        > 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1kMlNfgVVAtTBNb57Qe88-d0vbM-HdohgQFqWCBr-cAg%2Fedit&amp;data=02%7C01%7Caharui%40adobe.com%7Cb9e4d4ca20864eabf7a608d7d4de296d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637211922954793626&amp;sdata=DsQpQRNkDnek03Iulknv2TFkE3fIRtdN%2BdB8WsaUyII%3D&amp;reserved=0
        >         > >
        >         > > Feel free to continue.
        >         > >
        >         > > Will not participate in the other discussion as it’s 
showing a
        > typical
        >         > pattern of progressional-degradation, and continuing that 
thread
        > will not
        >         > bring the project forward.
        >         > >
        >         > > Chris
        >         > >
        >         >
        >         >
        >
        >         --
        >         Carlos Rovira
        >
        > 
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7Cb9e4d4ca20864eabf7a608d7d4de296d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637211922954793626&amp;sdata=sZswsDv3TrjgbiXy0uIZ1RiysV91lpeaFMZvEFRR0lg%3D&amp;reserved=0
        >
        >
        >
        >
        >



From: Christofer Dutz<mailto:christofer.d...@c-ware.de>
Sent: Tuesday, March 31, 2020 7:52 PM
Subject: Re: [DISCUSS] Coming back to collect requirements for the release 
process


There is a difference between something working and being bit-identical.

But regarding seeing your changes in any IDE. Ideally it wouldn't matter if you 
build it with Ant or Maven.
Right now the Maven distribution seems to work in the IDEs it was tested with 
... so ... yes.

So if you develop, it shouldn't matter if you build with Ant or Maven

Chris





Am 31.03.20, 17:59 schrieb "Yishay Weiss" <yishayj...@hotmail.com>:


    > - Some tooling could be added to validate artifacts created by any form 
of distribution with ones built by Ant

    If I understand Alex’s concern correctly he wants Ant users to see their 
Royale changes in any IDE. Is this tooling supposed to help with that?


    Am 31.03.20, 07:48 schrieb "Piotr Zarzycki" <piotrzarzyck...@gmail.com>:

        Hi Chris,

        Last comment from Alex explain exactly what release process has to do
        additional. - Did your document explanation included that step? Reading 
it
        I feel it includes, but I would like to make sure.

        Thanks,
        Piotr

        On Tue, Mar 31, 2020, 6:34 AM Alex Harui <aha...@adobe.com.invalid> 
wrote:

        >
        > 
https://lists.apache.org/thread.html/r6412a8240c1b690603d2ddd12b578ddfc3dc8436c24b15174a18fe74%40%3Cdev.royale.apache.org%3E
        >
        > A "build" (running 'ant main')  produces jars and swcs but does not 
create
        > the same output as 'ant release' which produces tar.gz and .zip 
files.  The
        > release artifacts are used in many IDEs and in NPM.  So, IMO, in the
        > creating of the release artifacts, the RM should ensure that it is 
possible
        > to create the tar.gz and .zip files via Ant, and to create at 
minimum, the
        > Maven jars and swcs and hopefully a working equivalent of the tar.gz 
and
        > .zip via Maven using the "distribution" profile.  A working 
"distribution"
        > profile did not exist in the past so it is a nice-to-have and not a
        > regression if the distribution profile's tar.gz and .zip has 
problems.  It
        > would be a regression if it turned out the build.xml files in the 
release
        > could not build the tar.gz and .zip correctly.
        >
        > The only way I can think of to validate that the build.xml files will 
do
        > the right thing is to actually run "ant release" at some point in the
        > release process.  In which case, you might as well use the resulting
        > artifacts.
        >
        > My 2 cents,
        > -Alex
        >
        > On 3/30/20, 12:11 PM, "Yishay Weiss" <yishayj...@hotmail.com> wrote:
        >
        >     > Ant artifacts are reproducible by running the Ant scripts.   
Again,
        > the scenario is that if an Ant user wants to try a local change in an 
IDE
        > or NPM we want >to ensure that they can run the Ant "release" target 
and
        > get the tar.gz or .zip they need.
        >
        >     “Again” suggests you’ve already given an explanation, but I 
couldn’t
        > find it. Can you expand on this scenario? If this is the only 
difference
        > you and Chris have I think it’s worth focusing on it.
        >
        >     On 3/30/20, 2:17 AM, "Carlos Rovira" <carlosrov...@apache.org> 
wrote:
        >
        >         Hi Chris,
        >
        >         thanks. I revise and for me is totally fine :)
        >
        >
        >         El lun., 30 mar. 2020 a las 9:33, Harbs 
(<harbs.li...@gmail.com>)
        > escribió:
        >
        >         > Thanks for that. The Google Doc is a great initiative!
        >         >
        >         > Harbs
        >         >
        >         > > On Mar 30, 2020, at 10:26 AM, Christofer Dutz <
        > christofer.d...@c-ware.de>
        >         > wrote:
        >         > >
        >         > > Hi all,
        >         > >
        >         > > as the discussion has gone back to: “the release should 
be as
        > in the 13
        >         > steps”, I’d like to re-focus on the probably more important
        > parts:
        >         > >
        >         > > I already started writing up a list of requirements and
        > options to
        >         > achieve them:
        >         > >
        >         >
        > 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1kMlNfgVVAtTBNb57Qe88-d0vbM-HdohgQFqWCBr-cAg%2Fedit%23&amp;data=02%7C01%7Caharui%40adobe.com%7Cb9e4d4ca20864eabf7a608d7d4de296d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637211922954783626&amp;sdata=wykDg%2FGYXXpYQk2RE2Und%2BxZ7Qzr7lDXhInGuhgA4Xc%3D&amp;reserved=0
        >         > <
        >         >
        > 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1kMlNfgVVAtTBNb57Qe88-d0vbM-HdohgQFqWCBr-cAg%2Fedit&amp;data=02%7C01%7Caharui%40adobe.com%7Cb9e4d4ca20864eabf7a608d7d4de296d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637211922954793626&amp;sdata=DsQpQRNkDnek03Iulknv2TFkE3fIRtdN%2BdB8WsaUyII%3D&amp;reserved=0
        >         > >
        >         > > Feel free to continue.
        >         > >
        >         > > Will not participate in the other discussion as it’s 
showing a
        > typical
        >         > pattern of progressional-degradation, and continuing that 
thread
        > will not
        >         > bring the project forward.
        >         > >
        >         > > Chris
        >         > >
        >         >
        >         >
        >
        >         --
        >         Carlos Rovira
        >
        > 
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7Cb9e4d4ca20864eabf7a608d7d4de296d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637211922954793626&amp;sdata=sZswsDv3TrjgbiXy0uIZ1RiysV91lpeaFMZvEFRR0lg%3D&amp;reserved=0
        >
        >
        >
        >
        >




Reply via email to