flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yennick Trevels <yennick.trev...@gmail.com>
Subject Re: [RT] Repositories & Artifacts
Date Thu, 15 Mar 2012 05:17:57 GMT
While Sonatype may have a pretty strict requirement regarding project
dependencies, it's also a good thing because it makes sure that all the
dependencies can be found on the Maven Central repository. Maven Central is
also the default repository for Maven, so the user doesn't have to specify
an extra repository.
Even if we choose to not deploy to Sonatype we should make sure that all
the Flex dependencies (like Mockolate, FlexUnit) are available on an
official repository somewhere. FlexUnit shouldn't be a problem anymore
since I recently completed the build script to deploy its artifacts to

For deployment to these repositories I'd use Ant since the rest of the Flex
build script is already in Ant. FlexUnit also uses Ant for this and it's
working fine.

On Thu, Mar 15, 2012 at 3:56 AM, Martin Heidegger <mh@leichtgewicht.at>wrote:

> Hello List,
> Today I am working on Gradle(Fx) & Maven integration for a test project of
> mine. It is my first trip in these fields
> so I might tell you things you already know. However: I think It is
> important to gain a little overview:
> A "repository" refers to a online storage (url) of released files (if we
> build flex for example). All those repositories
> I will mention are able to deal with *dependencies* that means that the
> project can refer to other projects that
> need to be downloaded as well.
> The project descriptors that are hosted in a repository usually have
> following specifications:
>   groupId (example: "org.apache.flex") the overview of the project that
> releases the project
>   artifactId (example: "compiler") the installable component
>   version (example: "4.8") Version of the project
>   description (example: "The flex compiler") Just some text to make
> listing easier
> I took a look into following repository systems:
>   Maven
>     Maven hosts artifacts[1] in ".pom" files in maven repositories[2]. It
> is relatively easy for apache projects to get hosted[3] (as I am not
>     a member-I can not really initiate anything in this direction). Other
> projects would need to be hosted at Sonatype.
>     The process for hosting at Sonatype is pretty convoluted: There is a
> 11-step-guide [4] available that explains that.
>     This is important because projects Flex needs like Mockolate and
> eventually FlexUnit (or others in future) would need
>     to be found in a repository as well.
> <rant>Maven manages to explain all complexity at once (more confused than
> enlightened after reading the docs).
>     "easing in" seems to be a term they do not understand.</rant>
>   IVY [4]
>     Additionally to supporting maven repositories, Ivy has its own
> non-central repository system[5] that is easier to use
>     than Maven (imho).  IVY files[6] also allow additionally to setting
> conflicting projects or projects that shouldn't be used.
>     There is a general purpose public repository called "ivyroundup"[7].
>   Debian Packages
>     Its sort of an exotic thought but basically the same things are
> already being dealt with quite effectively and a lot more general
>     with debian packages (.deb files). Indeed it works a lot faster than
> Maven in my experience and it has a more general
>     approach. Of course they are platform specific but I guess every linux
> dev would jump in the air and kiss us if we would
>     provide them. I have found quite a clean explanation here [8]. My
> thinking is like: It would be possible to deploy flex to
>     debian packages and create a Gradle/Maven/etc. plugin that uses those
> packages.
>  haXe
>     haXe has its own, rather comfortable, repository system that is
> accessible via the haxelib command[9]. As haxe is able to
>     compile from swc's it is possible to somewhat host the flex swc's
> there. Not sure if that is an reasonable approach.
> I do not think that the Maven repository system is good for the flex/as3
> community because it is rather difficult for developers
> to get started. For example: I am an as3 developer and I want to publish
> my project on maven somewhere its quite a bit of stressful work.
> However: I guess minds are already made up about maven so:
>  Mojos for Flex
>    FlexMojos[10] already offers maven artifacts(data) and mojos (plugin)
> at its repository[11]. This means they actually mirror Flex
>    releases there. Aside from the fact that it doesn't look "official" at
> all, there are two obvious problems with that
>       1) It takes some while after an release until its hosted
>       2) Other systems like Gradle/Ivy have to be sure that this system
> offers everything
>    For making this nice of course the build script needs to be modified to
> push artifacts to the apache repository[3]. Those artifacts
>    would somehow needed to be structured:
>        groupId: org.apache.flex
>        artifacts:
>            (binary and ant task)
>              asc: The actionscript compiler
>              mxmlc: The mxml compiler
>              compc: The component(swc) compiler
>              asdoc: the asdoc generator
>            (subtypes for swc/source/documentation/**translation(each
> language)):
>              framework: the core framework
>              spark: the spark components
>              halo: the halo theme
>              mx: the mx components
>              (... etc. for all the other as3/mxml projects)
>  I _think_ it would be best if *each* artifact would get its own version
> number (as it would allow a better separation of the dependencies).
> From here on I think some decisions would need to be made:
>   1) Where does apache flex deploy to?
>   2) How detailed should it be.
>   3) What will it use to do those deployment?
> Please let me know if I understood something entirely wrong.
> yours
> Martin.
> FYI: Gradle is a *lot* easier to get into than Maven (as3 developers
> should love it) but GradleFX is certainly not as mature as FlexMojos but
> I can see it catching up soon.
> [1] http://maven.apache.org/pom.**html <http://maven.apache.org/pom.html>
> [2] http://maven.apache.org/**guides/mini/guide-central-**
> repository-upload.html#**Approved_Repository_Hosting<http://maven.apache.org/guides/mini/guide-central-repository-upload.html#Approved_Repository_Hosting>
> [3] http://www.apache.org/dev/**repository-faq.html<http://www.apache.org/dev/repository-faq.html>
> [4] https://docs.sonatype.org/**display/Repository/Sonatype+**
> OSS+Maven+Repository+Usage+**Guide#**SonatypeOSSMavenRepositoryUsag**
> eGuide-11.**WhatDoPeopleThinkAboutOSSRH<https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-11.WhatDoPeopleThinkAboutOSSRH>
> [5] http://ant.apache.org/ivy/**history/latest-milestone/**
> resolver/url.html<http://ant.apache.org/ivy/history/latest-milestone/resolver/url.html>
> [6] http://ant.apache.org/ivy/**history/latest-milestone/**ivyfile.html<http://ant.apache.org/ivy/history/latest-milestone/ivyfile.html>
> [7] http://code.google.com/p/**ivyroundup/<http://code.google.com/p/ivyroundup/>
> [8] http://www.linuxfordevices.**com/c/a/Linux-For-Devices-**
> Articles/How-to-make-deb-**packages/<http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/How-to-make-deb-packages/>
> [9] http://haxe.org/doc/haxelib/**using_haxelib<http://haxe.org/doc/haxelib/using_haxelib>
> [10] http://flexmojos.sonatype.org/**index.html<http://flexmojos.sonatype.org/index.html>
> [11] http://repository.sonatype.**org/content/groups/flexgroup/<http://repository.sonatype.org/content/groups/flexgroup/>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message