incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Francis Buhler <davidbuh...@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
Date Wed, 29 Feb 2012 21:58:00 GMT
We seem to be caught in a build-quagmire.

Should we put the build-tool decision up to a vote, or will we wait to see
what people accomplish with the various build tools and then decide?

On Wed, Feb 29, 2012 at 4:45 PM, Left Right <olegsivokon@gmail.com> wrote:

>  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
>

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