After reading your email, I am more convinced that Maven is the way to go.
Sure we can use any other tool or build our own,  but I don't see why.
Maven seems to be a very good fit.  There is a common misconception that
Maven is just a build tool.  It is in fact a project management tool + a
build tool mixed in one [1]  A comprehensive project management tool is
what we need, as you very clearly laid out in your email.

More inline:

On Fri, Nov 13, 2015 at 10:01 PM, Alex Harui <aha...@adobe.com> wrote:

> Hi,
>
> Folks are still getting tripped up trying to get prerequisite build tools
> set up and ready to go.  Let’s use this thread to figure out a better
> solution.  I know Chris is going to say “Maven” and I support that, but I
> still think we can’t require everyone to go to Maven.
>


I don't see the distinction between requiring Apache Ant vs. requiring
Apache Maven.



>
>
> Anyway, back to environment variables.  I believe one of the requirements
> is to allow folks to choose different versions of the Adobe SDKs.  But do
> we need to allow tons of flexibility on where those Adobe files go?  Do we
> need to allow folks to keep more than one version around on their systems?
>

This is one of the core principles of Maven: convention over configuration'
[2]


>   Here are some ideas:
>
> 1) require that folks create an adobe folder in c:\ or HOMEPATH on Windows
> and HOME on Mac
>

Maven has a .m2 folder for this same purpose [3]


> 2) further require that the folder structure in the adobe folder is
> something like air/versionnumber and flash/versionnumber (e.g. air/4.0.
> The standalone debugger would go in flash/versionnumber as well.
>

Maven does this elegantly by using something called as Maven Co-ordinates
[4]


> 3) #2 allows folks to keep more than one version of an SDK on their
> machine.  But that pretty much means that you have to pass the version
> number you want to use to the build scripts.  If we only required an air
> and flash without version numbers, the scripts wouldn’t need to figure out
> what version to use.
>

With Maven you can have any number of versions of an artifact.  The
'version' is a parameter which is included in the maven co-ordinates to
locate a particular dependency.  [5]


> 4) create scripts that take a version number and create and populate the
> adobe folder.  I still would not fold these into the main build.xml.
> These scripts will have to ask folks to accept the Adobe licenses before
> downloading.
>

Maven automatically downloads an artifact to the
.m2/path/to/artifact/folder by default.  And I think Chris has already made
this license check gate work with FlexMojos (a Maven plugin for building
Flex apps)
Maven uses this local cache for all subsequent builds.  Unless we have a
dependency on a .SNAPSHOT version.  In that case, it periodically checks to
see if the snapshot has been refreshed.  The SNAPSHOT feature is useful for
inter-dependencies like the that exist between FlexJS and Falcon/FalconJX
where both are moving targets.


> 5) create something the Apache Flex Installer can install that populates
> the adobe folder
> 6) try to get our build scripts to find the air and flash SDKs from an
> installed Flex or FlexJS SDK.  The problem with that is the standalone
> debugger isn’t part of the install.
>
> In sum, if we can assume that the Adobe stuff is going to be in a few
> known places, we can hopefully eliminate most or all of the pain around
> this sort of thing and eliminate the requirement for environment variables.
>

Again, assuming 'something is somewhere' is a core tenet of Maven.  I
certainly wouldn't want to reinvent the wheel when a perfectly fine tool is
already available.

Finally, I don't think we need Adobe to mavenize any of their runtime
artifacts.  We can simply use a maven plugin to download the files from
their existing URLs [6]  Throw in the license check gate before running
this, and we should be good.

Thanks,
Om


> Thoughts?
> -Alex
>
>

[1]
http://books.sonatype.com/mvnref-book/reference/introduction-sect-whatIsMaven.html
[2]
http://books.sonatype.com/mvnref-book/reference/installation-sect-conventionConfiguration.html

[3] http://www.mkyong.com/maven/where-is-maven-local-repository/
[4] https://maven.apache.org/pom.html#Maven_Coordinates
[5]
http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-syntax.html
[6]
http://stackoverflow.com/questions/2741806/maven-downloading-files-from-url

Reply via email to