Hi Alex,

In general there should be nothing preventing Maven to use the SWCs built by 
ant too.

The additional stuff I mentioned is in the Jars, not the SWCs (perhaps in the 
JS SWCs) and in these there is just a copy of the pom and the values of any 
property during execution. 

Both are not used or needed by any program I know of. Just consider them 
Meta-Data.

They are mainly used for tools like Nexus to know where to put them and if you 
were to sort of find a jar in some directory know how to reproduce it.

Chris

Am 21.03.20, 16:46 schrieb "Alex Harui" <[email protected]>:

    
    
    On 3/21/20, 8:19 AM, "Christofer Dutz" <[email protected]> wrote:
    
        Well in theory the jars in the compiler built by Maven should also work 
with Ant 
        and the other way around and also should it be possible to use the SWCs 
build by Maven with Ant.
    
    Did you mean "It should be possible to use the SWCs built by Ant with 
Maven"?   That's true, but the Ant scripts do not do that currently and I see 
no reason to have them do that, because as you mention below, Maven puts more 
stuff in and around the jars/swcs.  It is easier for Ant to call Maven to do 
that.
        
        For example if I build the distribution with maven and use that in an 
IDE I have seen the IDEs use the Ant targets (which were built with Maven) with 
the SWCs (which were also built by maven) without any problems.
        
        We need to ensure the files are "reasonably equal" (it doesn't break 
anything for ANT if the jars of the Maven build have additional static stuff in 
"META-INF" package, but the interesting stuff like all the class files and 
resources should be identical)
    
    Agreed.  Bonus points if the RM verification has a smart compare of the 
Jars and SWCs (by unpacking them and comparing the actual class files or SWFs.)
        
        Chris
        
        Am 21.03.20, 16:08 schrieb "Alex Harui" <[email protected]>:
        
            That's a good starting point, but I don't like the "should".  I 
think it is a "must", otherwise, we can release broken functionality.
            
            The Ant release artifacts must be reproducible by Ant and the Maven 
release artifacts must be reproducible by Maven.  It isn't sufficient to say 
that the "build" works in the released sources.  Release artifacts are more 
than just the build output.  Ant or Maven users may need to test a binary 
release artifacts/package with their local changes, not just the individual 
jars/swcs.
            
            To be picky, only the Maven artifacts need to be usable by Maven, 
and only the Ant artifacts need to be usable by Ant, although I'm assuming 
that's what you meant.
            
            HTH,
            -Alex
            
            On 3/21/20, 2:20 AM, "Christofer Dutz" <[email protected]> 
wrote:
            
                Hi all,
                
                I would like to use this thread to collect some requirements 
for the release process.
                Also would I like to ask you not to formulate things like “The 
release artifacts must be built with X” but rather “The release artifacts 
should be usable by X” cause that’s what really matters. I hope you get what I 
mean.
                
                So far I have this:
                
                  *   The release artifacts should be usable by Maven
                  *   The release artifacts should be usable by Ant
                  *   The release should include tests, which ensure the 
correct function of the royale-maven-plugin
                  *   The release should include tests which ensure the correct 
function of the Ant targets
                  *   It should be possible to verify a release by comparing 
it’s binary artifacts for equality (reproducible builds)
                  *   It should be ensured a release candidate builds correctly 
with Ant and with Maven
                  *   The release process should ideally work on any machine
                
                Did I miss something?
                
                
                Chris
                
            
            
        
        
    
    

Reply via email to