Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of olegsivokon@gmail.com
 designates 209.85.210.175 as permitted sender)
Received-SPF: pass (google.com: domain of olegsivokon@gmail.com designates
 10.43.44.69 as permitted sender) client-ip=10.43.44.69;
MIME-Version: 1.0
In-Reply-To: 
 <CAH12+xPXoRaf92MjfKwBK1yLdFHyQFyOM7NpjHnCG9QU=2JkAA@mail.gmail.com>
References: 
 <801328109.52828.1326900520179.JavaMail.tomcat@hel.zones.apache.org>
	<1313060619.27805.1330434349083.JavaMail.tomcat@hel.zones.apache.org>
	<CAMFKFRiA6EA__=wmNz52gqgziJY7aP+d1ez+X_hwRgOb0fmJLA@mail.gmail.com>
	<CAJQBtgmcW5n1Uk6qwAo_06srfOc7bT1LznXMeJLzhXFUUvXUJA@mail.gmail.com>
	<CAH12+xPXoRaf92MjfKwBK1yLdFHyQFyOM7NpjHnCG9QU=2JkAA@mail.gmail.com>
Date: Wed, 29 Feb 2012 23:45:13 +0200
Message-ID: 
 <CAJQBtg=LZ=s_AGm79KtSxKVbe6T0tF0DriQmYh1wk0bhThpa6g@mail.gmail.com>
Subject: Re: [jira] [Commented] (FLEX-8) Make SDK build with Maven/Flexmojos
 and deploy release and snapshot artifacts to the Apache Maven repository
From: Left Right <olegsivokon@gmail.com>
To: flex-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=bcaec52e5f892832a304ba2142f8

--bcaec52e5f892832a304ba2142f8
Content-Type: text/plain; charset=ISO-8859-1

 I'm sorry to be dragged again into this discussion.

No, the man is the "judge", so far I could figure. In any case, the idea
the comic was trying to convey was that if you measure by an inappropriate
measurement tool, then the result will be random, or, as in that case,
biased, because the tool was chosen specifically to favor one of the
candidates.

And so it is with this debate: some argue for the change because they would
benefit from it, and put their benefit as the reason to justify the change.
What I'm saying is that so far there are also disadvantages that come with
the change, I'll not favor it, especially since I'll gain absolutely
nothing.

Under disadvantages I count:

- a viper nest of dependencies, which today may be handled by hand, but are
under total control of the project owners. Once it goes by the Maven rules,
you will have to adjust to whatever other repositories provide (that has
been referred to earlier as "non standard version of package X" being used
in the SDK code. Which is non-standard from the standpoint of whoever uses
Maven repositories, but there's no real standard, and, in fact, if there
were changes, they might have had a reason. But even if not, then the idea
of denying oneself the ability to have a local patch in the future doesn't
sound promising.

- an extremely buggy and inflexible tool, which Maven build certainly is.
(not the Maven itself, but the build written w/o an ability to debug it,
while being limited to a very narrow spectrum of functions will certainly
be buggy and inflexible). Maven cannot even do arithmetics on it's own.
Neither it can print messages during the build, it has nothing to backup
boolean logic, no abstraction of file system and many-many more limitations
which will result in eventually adopting some other tool to compensate for
disabilities. And so, while the build will be done mainly by Maven, it'll
be plagued by shell scripts, and, almost certainly Ant droplets all over
the place.

- a tool difficult to install and use. All in comparison, but installing
Ant is really easier, and the use is more straight-forward. Especially, in
the light of the above - the build wouldn't only require Maven, it will,
most certainly require Ant, but probably it won't stop there (as SDK builds
in the past did make use of shell scripts).

- Maven belongs exclusively to the Java "ecosystem", which means that very
little code from other language, including AS3 can be obtained as a Maven
artifact. Certain communities don't have any habit of using it, and will
not likely switch to using it upon request. So, for instance, it's hard to
imagine someone who's developing AS3+PHP, AS3+Python, AS3+.NET etc, who'd
be happy to add a monumental complicated system to their project, while all
they need is one or two SWCs.

- Maven is a "selfish" way to go about building your projects. It's either
you play by the rules, or you are out of the game. For instance, Maven
artifacts require certain structure. As it was noted before, for example,
they require that there be a MD5 checksum provided with the binaries. This
may be OK for people who are used to it, but a complete majority of those
writing in languages other then Java are unaware of such requirements.
Eventually they may provide hashes, but not necessarily in the format that
Maven expects it to be.

So, back to my point. It may seem natural for someone that Maven should be
used for everything, if "everything" to them is enterprise Java, and they
are unaware of anything else. But enterprise Java is not enough of an
authority to impose it's will on everyone else.

Best.

wvxvw

--bcaec52e5f892832a304ba2142f8--