You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Martin Heidegger <mh...@leichtgewicht.at> on 2012/03/15 03:56:46 UTC
[RT] Repositories & Artifacts
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
[2]
http://maven.apache.org/guides/mini/guide-central-repository-upload.html#Approved_Repository_Hosting
[3] http://www.apache.org/dev/repository-faq.html
[4]
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
[6] http://ant.apache.org/ivy/history/latest-milestone/ivyfile.html
[7] http://code.google.com/p/ivyroundup/
[8]
http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/How-to-make-deb-packages/
[9] http://haxe.org/doc/haxelib/using_haxelib
[10] http://flexmojos.sonatype.org/index.html
[11] http://repository.sonatype.org/content/groups/flexgroup/
Re: [RT] Repositories & Artifacts
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 15/03/2012 14:17, Yennick Trevels wrote:
> 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.
I do not bother so much about the strictness, i bother about the user
experience you
get at sonatype:
Read a complex document hidden in a wiki hidden under a tiny link...
Create a Jira bug entry with general data...
... wait ...
... (hope that no other took that path) ...
Get familiar with a complex gui.
And all that to provide a 2k file that is written in 10 minutes. With a
bit focus on
user experience this could be done in the same time with verification
and publication while actually
learning something ... its 2012 ...
> 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
> Sonatype.
Actually FlexUnit was about to be contributed to Apache, takes a little
longer :)
Mockolate would be more important, and it has quite a few dependencies.
> 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.
Ant is just fine for me.
yours
Martin.
Re: [RT] Repositories & Artifacts
Posted by Yennick Trevels <ye...@gmail.com>.
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
Sonatype.
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/>
>