Ok ... and what exactly is the difference to what you describe from simply using Maven to build a Flex application? From what I get from your whishlist, It sort of gives you everything you want. And it does this really nicely and the solution is somewhat finished allready.
Chris -----Ursprüngliche Nachricht----- Von: Yi Tan [mailto:ta...@smartgf.com] Gesendet: Freitag, 13. Juli 2012 15:49 An: flex-dev@incubator.apache.org Betreff: Re: Suggestion : Adopt a package manager like Ruby Gems for Flex as a first class citizen of the SDK Hi all, I've been following this maillist for months. I seldom post, because my English is self-taught. I try my best to express myself simple and clearly. This post does make me feel a bit sad when seeing 6 of 12 replies against adopting a package manager in Flex. Programming has already become a social activity. In a community with decent tools, programmers share, learn with each other and eventually be able to make better software in much less time. This is the trend I really hope Flex/ActionScript could catch up with, because the major part of my daily job is coding in AS. /* 1. Why a package manager matters */ A real story: we are working on a game app by using AIR for iOS. To reduce memory consumption, I need something can make skinnable interface from little bitmaps snippets (oh, no Flex framework, it's too enterprise to be fit in real-world apps). So I googeled and found a few scale bitmap AS classes. After comparing them, I chose ByteArray.org's one ( http://www.bytearray.org/?p=118) . A few days after using that class, I found it is not well-thought, there was no need to duplicate the original bitmap data. So I wrote my own. The funny thing was when I am about to push my version of ScaleBitmap onto github. I found there is a newer version of ByteArray.org's already on github and it did exactly the same thing as I did :( (http://www.bytearray.org/?p=1206). Because that blog post is newer, it ranked lower in google search result, and I missed it. So I wasted half day building a same thing and writing test cases for it. If flex has a decent package manager, programmer can share and maintain code libraries in a centralized-managed place. And that will also be the best place for all AS programmers to find out is there already some smart guys done what I'm going to do. /* 2. Why Ruby, Python, JS, Perl... whatever script language need */ The answer is so obvious: AVM can not do that job. AVM is designed to performer heavy multimedia tasks under limited resources. It is the best in that filed, but it's not a general purpose VM. There is no CLI, no REPL, no script ability in AVM. So when you need something that can talk in command line on-the-fly, you have to look on other scriptable virtual machine, and thus other languages. For this point, I would recommend nodejs. It's built on V8 engine, reads javascript, which is familiar to ActionScript 2, and npm is just so easy to use: http://npmjs.org/ Also for Ruby-friendly people, coffee-script is awesome. /* 3. What a decent package manager should be */ at least: - It should let people publish their libs in a few simple steps - It should let people search other people's libs in a few simple steps - It should let lib owners maintain there libs in a very easy way - It will be great if it can be integrated with github Regards, ty On Fri, Jul 13, 2012 at 4:46 PM, John Fletcher <fletch...@gmail.com> wrote: > 2012/7/12 Jeffry Houser <jef...@dot-com-it.com>: > > It does not affect my point. But, as I understood it; most people > > use > Ruby > > today for the server-side of a web site (or other application). > > Probably true. It's most commonly used with Rails, which is a > server-side framework built on top of Ruby. > > > I can > > install any given application server on my local machine, that > > doesn't > make > > it less of a server.. > > True. But in this case we're only talking about the part that really > isn't a server. It's like depending on Java, as opposed to depending > on Tomcat (a server technology built with Java). > > But this is all academic. I think most agree with you that we don't > want to introduce other dependencies. But if someone could write this > tool in ActionScript (not sure if that's feasible) then you would > probably have a lot of support on your hands. > > John >
