Well first of all ... my desire to keep AMF is not because of having to change the backend but because I don't want to throw overboard one of the greatest benefits of Flex when it comes to Server-Client communication.
Well if you just look at the as3commons-logging package: org.swizframework:swizframework:1.2 org.spicefactory:spicelib-flex:2.4.0 org.seasar:yui:fx3-fp9-1.1.0 com.pblabs:pushbuttonengine:r1103 com.furusystems:dconsole:v2r203 org:log5f:1.0.55 nl.base42:LogMeister:1.8.2 org.asaplibrary:asaplibrary:20110705_rev309 org.maashaack:system.logging:5005 jp.progression:progression:4 org.osflash:thunderbolt:2.3 com.asfusion:mate:0.9.1 com.hexagonstar:alcon:3.1.4 com.carlcaldern.arthropod:arthropod:1.0.0 com.junkbytes:console:2.52 org.mockito:mockito:1.4M5 And that's just one of the 20 Modules as3commons consist of. And I left away air, osmf, etc in that list as I think these are the ones we know :-) I would rather opt for taking, what's good, giving it a new package name and omitting stuff none needs. Moving the other stuff to some sort of attic where we could easily integrate it back if people are requesting it to be supported. I think after Adobe announced giving up on Flex about 80% of the frameworks died and only a hand full of great ones survived. I'm not planning on keeping zombies alive, that none need, but would gladly help keep the maintain the good ones. Chris ________________________________________ Von: Alex Harui <aha...@adobe.com> Gesendet: Sonntag, 6. Dezember 2015 06:25 An: dev@flex.apache.org Betreff: Re: [DISCUSS] Adopting AS3Commons I'm not a fan of changing the package names. Already this week we heard folks wanting AMF because they don't want to change their backend, and I've heard several folks wanting a more Spark-like API surface for FlexJS. My new mantra for 2016 is to try to not make more work for folks who are migrating their code. What do we really gain by changing package names and making folks alter their code? Would we also switch out mx and spark for org.apache.flex? I suppose we could bundle AS3Commons with the SDK, but keep in mind that I think we want to make as much of AS3Commons work for FlexJS as well. @Chris and/or Christophe, what other libraries is AS3Commons dependent on that we need to be concerned about? Thanks, -Alex From: jude <flexcapaci...@gmail.com<mailto:flexcapaci...@gmail.com>> Reply-To: "dev@flex.apache.org<mailto:dev@flex.apache.org>" <dev@flex.apache.org<mailto:dev@flex.apache.org>> Date: Saturday, December 5, 2015 at 8:30 PM To: "dev@flex.apache.org<mailto:dev@flex.apache.org>" <dev@flex.apache.org<mailto:dev@flex.apache.org>> Subject: Re: [DISCUSS] Adopting AS3Commons If someone will help me with that I'll do it. What I'm thinking is when you create a new Flex project you get all of the SWC's by default. So in this case we have something like this: [Inline image 1] We need to add the new components set in there, the as3commons in there and the other packages we have but aren't including. Some of the new Spark components should be put into the Spark project folders. "But they may not be perfect!" Put. them. in. People will finally find them for once, then use them, then we can get some bug reports and fix things as they come up. PUT THEM IN. It may make one tough release but we'll be working towards a feature complete spark release and we'll successfully have integrated an external project (as3commons) into the main project. On Sat, Dec 5, 2015 at 12:33 AM, OmPrakash Muppirala <bigosma...@gmail.com<mailto:bigosma...@gmail.com>> wrote: Hey, you committer ;-) You have all the power to drag those components and put them in. I like your idea. Thanks, Om On Sat, Dec 5, 2015 at 12:27 AM, jude <flexcapaci...@gmail.com<mailto:flexcapaci...@gmail.com>> wrote: > Since Flex was open sourced it's felt like to me it's stagnated. We had all > of these new components donated or proposed to be donated proposed to be > worked on and I haven't seen any of them. I think it's because it's in some > white board somewhere. I hate that. Put them in the main branch. Put it in. > Then we can see them in code completion. Then we can start getting bug > reports as their being used. > > Put as3commons into our.main.branch.utils. If that's org.apache.utils then > fine. I also figure if someone is upgrading their SDK and we've renamed the > package then there is no conflict. They can remove the link to > as3commons.swc and all the API's will cause errors. Then they just go in > and use the new packages. > > > On Fri, Dec 4, 2015 at 1:36 PM, Michael Schmalle < > teotigraphix...@gmail.com<mailto:teotigraphix...@gmail.com>> > wrote: > > > IIRC most of the projects have some pretty thorough unit tests as well. > > > > Mike > > > > On Fri, Dec 4, 2015 at 2:14 PM, jude > > <flexcapaci...@gmail.com<mailto:flexcapaci...@gmail.com>> wrote: > > > > > +1 for renaming it. make it part of the main package. that way we have > to > > > commit to it. if we put it off to the side there's more "it's a side > > > project. we don't need to maintain it." > > > > > > On Fri, Dec 4, 2015 at 10:26 AM, Kessler CTR Mark J < > > > mark.kessler....@usmc.mil<mailto:mark.kessler....@usmc.mil>> wrote: > > > > > > > Good point, we should keep it the same then. However if we do have > to > > > > reorganize it in the future, we can go over options then. > > > > > > > > -Mark > > > > > > > > -----Original Message----- > > > > From: Alex Harui [mailto:aha...@adobe.com<mailto:aha...@adobe.com>] > > > > Sent: Friday, December 04, 2015 10:52 AM > > > > To: dev@flex.apache.org<mailto:dev@flex.apache.org> > > > > Subject: Re: [DISCUSS] Adopting AS3Commons > > > > > > > > > > > > I'd either leave it as is: org.as3commons > > > > Or add apache: org.apache.as3commons > > > > Or add apache.flex: org.apache.flex.as3commons > > > > Or hint at Apache Commons: org.apache.commons.as3 > > > > > > > > There is backward compatibility to be considered, so if we rename the > > > > packages folks would have to change their source code to use it, so > I'd > > > > probably lean towards leaving it as is. > > > > > > > > -Alex > > > > > > > > > > > > > >
