You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Carlos Rovira <ca...@codeoscopic.com> on 2012/05/24 16:01:03 UTC
Apache Flex structure to be BMS compliant (was Re: Library Versions
used in Flex SDK)
> be a good thing for the people maintaining Flex to also maintain its
Metadata
So putting the metadata into the Apache Flex SVN repo would be a good
start?
Chris,
I understand that Marvin gave you the built instructions and xml files to
create a mavenized Flex SDK or that you can talk with him to get it from
first hand. Moreover, if you was working with all SDKs as you report, you
already know all about this process.
That process could give us the keys to rethink all Apache Flex SDK
structure to be BMS (Build Management System) compliant. (Regarding the
instructions, if you can't get it I can provide you with the files I used
in my company and some instructions, although there's some places out there
where you can find it.)
I think that we need to create the needed pom(s) (in the maven case, I
don't know yet how gradle works) for the new refactorized flex sdks in
order to create the artifacts. The last point to take into account would be
to talk with apache maven project to publish in maven central repository
the flex sdk artifacts. (Maybe I'm wrong in some step since I never do
something like this... thiese are theoreticaly the steps to follow).
In this way we could have all artifacts directly available when a new flex
sdk was released in a maven central repository.
AW: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by "christofer.dutz@c-ware.de" <ch...@c-ware.de>.
Well I dind't ask Marvin for the code of his tool, as this usually was usually a question where he got pretty mad pretty fast ;-) ... I ended up creating my own Tool and while I was at it, I did some optimizations to the way the artifacts were structured and how the poms were generated. I think it will be best for me to finish this tool and then to give it to you. Then you could start generating your own SDKs and have it generate the metadata.
Chris
-----Ursprüngliche Nachricht-----
Von: carlos.rovira@gmail.com [mailto:carlos.rovira@gmail.com] Im Auftrag von Carlos Rovira
Gesendet: Donnerstag, 24. Mai 2012 16:01
An: flex-dev@incubator.apache.org
Betreff: Apache Flex structure to be BMS compliant (was Re: Library Versions used in Flex SDK)
> be a good thing for the people maintaining Flex to also maintain its
Metadata
So putting the metadata into the Apache Flex SVN repo would be a good start?
Chris,
I understand that Marvin gave you the built instructions and xml files to create a mavenized Flex SDK or that you can talk with him to get it from first hand. Moreover, if you was working with all SDKs as you report, you already know all about this process.
That process could give us the keys to rethink all Apache Flex SDK structure to be BMS (Build Management System) compliant. (Regarding the instructions, if you can't get it I can provide you with the files I used in my company and some instructions, although there's some places out there where you can find it.)
I think that we need to create the needed pom(s) (in the maven case, I don't know yet how gradle works) for the new refactorized flex sdks in order to create the artifacts. The last point to take into account would be to talk with apache maven project to publish in maven central repository the flex sdk artifacts. (Maybe I'm wrong in some step since I never do something like this... thiese are theoreticaly the steps to follow).
In this way we could have all artifacts directly available when a new flex sdk was released in a maven central repository.
Re: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Carol,
that's right, but I think that Fb and IntelliJ (the tools) should be to
serve the technology (Flex) and not the inverse, isn't it?
..this like java projects (both in Eclipse and Intellij) that are maven
driven.
2012/5/24 Carol Frampton <cf...@adobe.com>
> Just be aware that if you are talking about moving directories around will
> quite likely break Apache Flex working with Flash Builder and/or IntelliJ.
>
> Carol
>
> On 5/24/12 10 :01AM, "Carlos Rovira" <ca...@codeoscopic.com>
> wrote:
>
> >> be a good thing for the people maintaining Flex to also maintain its
> >Metadata
> >So putting the metadata into the Apache Flex SVN repo would be a good
> >start?
> >
> >Chris,
> >
> >I understand that Marvin gave you the built instructions and xml files to
> >create a mavenized Flex SDK or that you can talk with him to get it from
> >first hand. Moreover, if you was working with all SDKs as you report, you
> >already know all about this process.
> >
> >That process could give us the keys to rethink all Apache Flex SDK
> >structure to be BMS (Build Management System) compliant. (Regarding the
> >instructions, if you can't get it I can provide you with the files I used
> >in my company and some instructions, although there's some places out
> >there
> >where you can find it.)
> >
> >I think that we need to create the needed pom(s) (in the maven case, I
> >don't know yet how gradle works) for the new refactorized flex sdks in
> >order to create the artifacts. The last point to take into account would
> >be
> >to talk with apache maven project to publish in maven central repository
> >the flex sdk artifacts. (Maybe I'm wrong in some step since I never do
> >something like this... thiese are theoreticaly the steps to follow).
> >
> >In this way we could have all artifacts directly available when a new flex
> >sdk was released in a maven central repository.
>
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
Re: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by Rick Winscot <ri...@gmail.com>.
I agree with Om as well... we've resorted to driving the compiler directly via Groovy... and it's swell!
R
On Thursday, May 24, 2012 at 2:39 PM, Om wrote:
> >
> > 1) maintain the structure and use a tool (like you did) to transform the
> > sdk to maven compliant sdk.
> >
> > 2) change sdk structure to get directly a maven compliant sdk
> >
> > IMHO the best way should be 2), since now is the right time to make
> > changes. Maybe just as soon as Apache Flex 4.8 sdk will be released, right?
> >
> > Tools should change to make Apache Flex SDK compliant.
>
> I respectfully disagree. I think (1) is the way to go. This gives us
> (Flex SDK team) the freedom to maintain whatever structure we want. If
> some of us want to make it Maven compliant, they should write a tool to
> create a Maven-specific directory structure and maintain it either part of
> Apache Flex or outside of Apache Flex.
>
> Maven is not the only build management system we want to support. Lots of
> folks use Ant, GradleFx, custom build scripts, etc. If we favor Maven,
> then it is not fair for the other tools.
>
> Breaking existing tools like Flash Builder, IntelliJ just to make Maven
> work is not the best idea. We are at a very delicate point in terms of end
> users' confidence and trust. Lets not break the camel's back.
>
> Thanks,
> Om
>
>
Re: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by Jonathan Campos <jo...@gmail.com>.
On Thu, May 24, 2012 at 2:41 PM, Michael A. Labriola <
labriola@digitalprimates.net> wrote:
> So, you think Adobe will refactor Flash Builder to make us happy? What
> about the thousands of copies in use already that people won't pay to
> update and won't work with a refactored sdk?
Get out of my head.
I think that even a day of coding may be too much effort to expect from
some groups. Such as the before mentioned.
--
Jonathan Campos
Re: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Oh yes! thanks Alex, I forgot that completely
2012/5/25 Alex Harui <ah...@adobe.com>
>
>
>
> On 5/25/12 3:31 AM, "Carlos Rovira" <ca...@codeoscopic.com> wrote:
>
> >
> > PD: one more thing, I saw that some versions has an A or an B at the end
> of
> > the build number...what are this letters and what means? I suppose that
> > this is something that not came from Adobe and something related to the
> > flexmojos packaging, isn't it?
> >
> >
> With the security fix, all previous Adobe Flex SDKs got A or B suffixes. B
> was used for a couple of versions that already had A hotfixes.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
AW: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by "christofer.dutz@c-ware.de" <ch...@c-ware.de>.
Well I wouldn't deploy them quite yet ... I think It would be great to sort out some issues first.
1. I would like to have the libs deployed with the correct version numbers (currently commented out) because the way the Flexmojos versions were deployed you could not load the rsls and signed rsls from adobe that way (ther was no osmf-4.5.1...).
2. I think my structure might sill need some fine-tuning (I actually don't use the AIR sdk or the Android stuff, so I don't know if my deployment descriptors make sense the way I generated them.
Just to mention the basic concepts I used in my deployment descriptors:
- The flex sdk is deployed in the group "com.adobe.flex.framework"
- I have one artifact "com.adobe.flex:framework" which contains a dependencyManagement section defining the versions of artifacts the flex framework it belongs to have (This way you can import the dependencyManagement stuff)
- I have a common-framework artifact which contains dependencies to most of the flex stuff
- I hace a flex-framework which actually contains a dependency to common-framework and the newest playerglobal that was found in the sdk (Would it make sense to use the minimum instead?)
- I haven't created an "air-framework" as I actually don't know what I would have to add to this.
- Still need an "automation-framework" (Don't know if this makes sense)
- Still need a "mobile-framework" (Don't know if this makes sense)
Chris
-----Ursprüngliche Nachricht-----
Von: carlos.rovira@gmail.com [mailto:carlos.rovira@gmail.com] Im Auftrag von Carlos Rovira
Gesendet: Freitag, 25. Mai 2012 12:32
An: flex-dev@incubator.apache.org
Betreff: Re: Apache Flex structure to be BMS compliant (was Re: Library Versions used in Flex SDK)
Hi Chris,
great work and effort so far. I think is a great way to handle the actual situation, and in the meanwhile would be very helpful to deploy new flex sdks (4.6 from Adobe, 4.8 from Apache) to a maven repository.
But we should not lost the target and see that this is a palliative solution until the structural refactor could take place and make things direct and easier. What do you think about it?
btw, have you tried to package Adobe Flex 4.6.0.23201 with your tool and deploy to a maven repository (local or remote)?
C.
PD: one more thing, I saw that some versions has an A or an B at the end of the build number...what are this letters and what means? I suppose that this is something that not came from Adobe and something related to the flexmojos packaging, isn't it?
2012/5/25 christofer.dutz@c-ware.de <ch...@c-ware.de>
> There actually are no things preventing us from converting Flex into a
> mavenized form. There are only some ugly parts that I thought would be
> cool to resolve. Most of them relate to hacked versions of standard libs.
>
> I think the structural changes I was talking about could be performed
> at deployment time.
>
> Fact is that there are some core-flex libraries, that flex and air
> need ... lets call them flex-core.
> Then there are libs for air and libs for flex only ... then there is a
> set of libs for automation and one set for mobile devices ... I would
> like to have them deployed separately in individual maven groups.
>
> Curently I am deploying them allmost the way they are bundled in the
> SDKs but am generating some pom-artifacts doing the grouping.
>
> Ive attached my unfinished converter project to this mail (Hopefully
> it's not stripped out). If it is and you would like me to send you a copy ...
> please contact me directly and I'll send it to you.
>
> What it does, is it looks at a directory containing a set of SDKs and
> processes each of them to the output directory. Both directories have
> to be provided as parameters to the main class. Inside each SDK it
> deploys everything in the SDKs lib directory as a compiler bundle, and
> everything inside the frameworks/libs as Flex sdk (Except the playerglobal).
>
> In the compiler it generates checksums of every jar and does a search
> on Maven central to see if the artifact is allready deployed. If it
> is, it uses that artifact instead of re-deploying it.
>
> In the Frameworks part it has a look at the rsls first, because these
> have a version and uses this version to deploy the libs (osmf and
> textLayout tend to have a different versioning scheme). Currently I
> commented this out and am deploying all swcs with the fixed version
> number of the sdk, because I haven't fixed Flexmojos to use a dynamic
> framework-swc version, but I'm working on this.
>
> I have tested building my Applications using Flexmojos 5.1 and Flex
> SDK 4.5.1.21328A and it worked great. Think I might still have to do
> some fine-tuning, but I think it would be better to hand this over to
> you and only participate in the fine-tuning.
>
> Chris
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Alex Harui [mailto:aharui@adobe.com]
> Gesendet: Donnerstag, 24. Mai 2012 22:46
> An: flex-dev@incubator.apache.org
> Betreff: Re: Apache Flex structure to be BMS compliant (was Re:
> Library Versions used in Flex SDK)
>
>
>
>
> On 5/24/12 12:50 PM, "Carlos Rovira" <ca...@codeoscopic.com>
> wrote:
>
> > I think IntelliJ will update quickly since they are
> > "maven-gradle-whatever-bms-oriented".
> > Flash Builder never took into account BMS, but they will update due
> > that technology requeriments....or are you saying that they will
> > abandon Flex development?
> Adobe is improving the next release of Flash Builder to be a bit more
> configurable so it can work with Apache Flex SDKs. After that, it is
> a business decision as to whether Adobe will do any further work if
> the Apache Flex SDK evolves in a way that is incompatible.
>
> If other tool vendors are more willing to make changes and therefore
> provide a more compelling tool than Adobe, then we'll see folks move
> in that direction, and then we'll see if Adobe chooses to compete or not.
> >
> > moreover...are you saying that we must stay with what we have now?
> > so...that's what we can expect for the future of flex? stay with the
> > same problems we ever had during all years? What kind of changes can
> > we
> expect?
> > only cosmetic changes?
> We have to consider factors when proposing changes like installed
> base, what our users know and expect. But I think we can make some
> big changes over time.
> >
> > Michel, you and Alex were talking about agresive changes in the
> SDK...i.e:
> > a completely new set of flex components and arqutecture, isn't
> > it?...so changes like that will not obligate Adobe to update Fb in
> > order to make it Apache Flex compliant?
> Flash Builder is not obligated to update to handle changes to the
> Apache Flex SDK. One thing we need to do is get some momentum so that
> there is a compelling market that would incite Adobe to want to update
> FB so it can extract revenue from customer upgrades. But if some
> other tool vendor ends up creating a better tool and everyone starts
> using it and makes FB a thing of the past, that's fine with me.
>
> Most important to me is that we have to solve the important problems.
> Maven integration is the top vote getter at Adobe JIRA by far. It is
> time to make adjustments to Apache Flex to make Maven work, but we
> want to do so without breaking everyone else's workflow.
>
> We have been forced by legal reasons to change the package structure.
> Apache Flex releases cannot look like the tree of files you get from Adobe.
> And since we're doing that, it is time to consider any changes to make
> Maven easier to support. But we are not asking the tool vendors to
> change with us.
> Instead, we are providing scripts to repackage the files from the
> various sources into something the tools can use.
>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com> Avd. del General Perón, 32 Planta 10, Puertas P-Q
28020 Madrid
Re: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by Alex Harui <ah...@adobe.com>.
On 5/25/12 3:31 AM, "Carlos Rovira" <ca...@codeoscopic.com> wrote:
>
> PD: one more thing, I saw that some versions has an A or an B at the end of
> the build number...what are this letters and what means? I suppose that
> this is something that not came from Adobe and something related to the
> flexmojos packaging, isn't it?
>
>
With the security fix, all previous Adobe Flex SDKs got A or B suffixes. B
was used for a couple of versions that already had A hotfixes.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Chris,
great work and effort so far. I think is a great way to handle the actual
situation, and in the meanwhile would be very helpful to deploy new flex
sdks (4.6 from Adobe, 4.8 from Apache) to a maven repository.
But we should not lost the target and see that this is a palliative
solution until the structural refactor could take place and make things
direct and easier. What do you think about it?
btw, have you tried to package Adobe Flex 4.6.0.23201 with your tool and
deploy to a maven repository (local or remote)?
C.
PD: one more thing, I saw that some versions has an A or an B at the end of
the build number...what are this letters and what means? I suppose that
this is something that not came from Adobe and something related to the
flexmojos packaging, isn't it?
2012/5/25 christofer.dutz@c-ware.de <ch...@c-ware.de>
> There actually are no things preventing us from converting Flex into a
> mavenized form. There are only some ugly parts that I thought would be cool
> to resolve. Most of them relate to hacked versions of standard libs.
>
> I think the structural changes I was talking about could be performed at
> deployment time.
>
> Fact is that there are some core-flex libraries, that flex and air need
> ... lets call them flex-core.
> Then there are libs for air and libs for flex only ... then there is a set
> of libs for automation and one set for mobile devices ... I would like to
> have them deployed separately in individual maven groups.
>
> Curently I am deploying them allmost the way they are bundled in the SDKs
> but am generating some pom-artifacts doing the grouping.
>
> Ive attached my unfinished converter project to this mail (Hopefully it's
> not stripped out). If it is and you would like me to send you a copy ...
> please contact me directly and I'll send it to you.
>
> What it does, is it looks at a directory containing a set of SDKs and
> processes each of them to the output directory. Both directories have to be
> provided as parameters to the main class. Inside each SDK it deploys
> everything in the SDKs lib directory as a compiler bundle, and everything
> inside the frameworks/libs as Flex sdk (Except the playerglobal).
>
> In the compiler it generates checksums of every jar and does a search on
> Maven central to see if the artifact is allready deployed. If it is, it
> uses that artifact instead of re-deploying it.
>
> In the Frameworks part it has a look at the rsls first, because these have
> a version and uses this version to deploy the libs (osmf and textLayout
> tend to have a different versioning scheme). Currently I commented this out
> and am deploying all swcs with the fixed version number of the sdk, because
> I haven't fixed Flexmojos to use a dynamic framework-swc version, but I'm
> working on this.
>
> I have tested building my Applications using Flexmojos 5.1 and Flex SDK
> 4.5.1.21328A and it worked great. Think I might still have to do some
> fine-tuning, but I think it would be better to hand this over to you and
> only participate in the fine-tuning.
>
> Chris
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Alex Harui [mailto:aharui@adobe.com]
> Gesendet: Donnerstag, 24. Mai 2012 22:46
> An: flex-dev@incubator.apache.org
> Betreff: Re: Apache Flex structure to be BMS compliant (was Re: Library
> Versions used in Flex SDK)
>
>
>
>
> On 5/24/12 12:50 PM, "Carlos Rovira" <ca...@codeoscopic.com>
> wrote:
>
> > I think IntelliJ will update quickly since they are
> > "maven-gradle-whatever-bms-oriented".
> > Flash Builder never took into account BMS, but they will update due
> > that technology requeriments....or are you saying that they will
> > abandon Flex development?
> Adobe is improving the next release of Flash Builder to be a bit more
> configurable so it can work with Apache Flex SDKs. After that, it is a
> business decision as to whether Adobe will do any further work if the
> Apache Flex SDK evolves in a way that is incompatible.
>
> If other tool vendors are more willing to make changes and therefore
> provide a more compelling tool than Adobe, then we'll see folks move in
> that direction, and then we'll see if Adobe chooses to compete or not.
> >
> > moreover...are you saying that we must stay with what we have now?
> > so...that's what we can expect for the future of flex? stay with the
> > same problems we ever had during all years? What kind of changes can we
> expect?
> > only cosmetic changes?
> We have to consider factors when proposing changes like installed base,
> what our users know and expect. But I think we can make some big changes
> over time.
> >
> > Michel, you and Alex were talking about agresive changes in the
> SDK...i.e:
> > a completely new set of flex components and arqutecture, isn't
> > it?...so changes like that will not obligate Adobe to update Fb in
> > order to make it Apache Flex compliant?
> Flash Builder is not obligated to update to handle changes to the Apache
> Flex SDK. One thing we need to do is get some momentum so that there is a
> compelling market that would incite Adobe to want to update FB so it can
> extract revenue from customer upgrades. But if some other tool vendor ends
> up creating a better tool and everyone starts using it and makes FB a thing
> of the past, that's fine with me.
>
> Most important to me is that we have to solve the important problems.
> Maven integration is the top vote getter at Adobe JIRA by far. It is time
> to make adjustments to Apache Flex to make Maven work, but we want to do so
> without breaking everyone else's workflow.
>
> We have been forced by legal reasons to change the package structure.
> Apache Flex releases cannot look like the tree of files you get from Adobe.
> And since we're doing that, it is time to consider any changes to make
> Maven easier to support. But we are not asking the tool vendors to change
> with us.
> Instead, we are providing scripts to repackage the files from the various
> sources into something the tools can use.
>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
AW: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by "christofer.dutz@c-ware.de" <ch...@c-ware.de>.
There actually are no things preventing us from converting Flex into a mavenized form. There are only some ugly parts that I thought would be cool to resolve. Most of them relate to hacked versions of standard libs.
I think the structural changes I was talking about could be performed at deployment time.
Fact is that there are some core-flex libraries, that flex and air need ... lets call them flex-core.
Then there are libs for air and libs for flex only ... then there is a set of libs for automation and one set for mobile devices ... I would like to have them deployed separately in individual maven groups.
Curently I am deploying them allmost the way they are bundled in the SDKs but am generating some pom-artifacts doing the grouping.
Ive attached my unfinished converter project to this mail (Hopefully it's not stripped out). If it is and you would like me to send you a copy ... please contact me directly and I'll send it to you.
What it does, is it looks at a directory containing a set of SDKs and processes each of them to the output directory. Both directories have to be provided as parameters to the main class. Inside each SDK it deploys everything in the SDKs lib directory as a compiler bundle, and everything inside the frameworks/libs as Flex sdk (Except the playerglobal).
In the compiler it generates checksums of every jar and does a search on Maven central to see if the artifact is allready deployed. If it is, it uses that artifact instead of re-deploying it.
In the Frameworks part it has a look at the rsls first, because these have a version and uses this version to deploy the libs (osmf and textLayout tend to have a different versioning scheme). Currently I commented this out and am deploying all swcs with the fixed version number of the sdk, because I haven't fixed Flexmojos to use a dynamic framework-swc version, but I'm working on this.
I have tested building my Applications using Flexmojos 5.1 and Flex SDK 4.5.1.21328A and it worked great. Think I might still have to do some fine-tuning, but I think it would be better to hand this over to you and only participate in the fine-tuning.
Chris
-----Ursprüngliche Nachricht-----
Von: Alex Harui [mailto:aharui@adobe.com]
Gesendet: Donnerstag, 24. Mai 2012 22:46
An: flex-dev@incubator.apache.org
Betreff: Re: Apache Flex structure to be BMS compliant (was Re: Library Versions used in Flex SDK)
On 5/24/12 12:50 PM, "Carlos Rovira" <ca...@codeoscopic.com> wrote:
> I think IntelliJ will update quickly since they are
> "maven-gradle-whatever-bms-oriented".
> Flash Builder never took into account BMS, but they will update due
> that technology requeriments....or are you saying that they will
> abandon Flex development?
Adobe is improving the next release of Flash Builder to be a bit more configurable so it can work with Apache Flex SDKs. After that, it is a business decision as to whether Adobe will do any further work if the Apache Flex SDK evolves in a way that is incompatible.
If other tool vendors are more willing to make changes and therefore provide a more compelling tool than Adobe, then we'll see folks move in that direction, and then we'll see if Adobe chooses to compete or not.
>
> moreover...are you saying that we must stay with what we have now?
> so...that's what we can expect for the future of flex? stay with the
> same problems we ever had during all years? What kind of changes can we expect?
> only cosmetic changes?
We have to consider factors when proposing changes like installed base, what our users know and expect. But I think we can make some big changes over time.
>
> Michel, you and Alex were talking about agresive changes in the SDK...i.e:
> a completely new set of flex components and arqutecture, isn't
> it?...so changes like that will not obligate Adobe to update Fb in
> order to make it Apache Flex compliant?
Flash Builder is not obligated to update to handle changes to the Apache Flex SDK. One thing we need to do is get some momentum so that there is a compelling market that would incite Adobe to want to update FB so it can extract revenue from customer upgrades. But if some other tool vendor ends up creating a better tool and everyone starts using it and makes FB a thing of the past, that's fine with me.
Most important to me is that we have to solve the important problems. Maven integration is the top vote getter at Adobe JIRA by far. It is time to make adjustments to Apache Flex to make Maven work, but we want to do so without breaking everyone else's workflow.
We have been forced by legal reasons to change the package structure.
Apache Flex releases cannot look like the tree of files you get from Adobe.
And since we're doing that, it is time to consider any changes to make Maven easier to support. But we are not asking the tool vendors to change with us.
Instead, we are providing scripts to repackage the files from the various sources into something the tools can use.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Alex I completely agree with you. Adobe will make its business decisions
based on profit. Is a business and is like things should be driven by its
own nature.
Here we are targeting the best evolution for Flex and like Alex said BSM
(specialy maven) are top on the list. This is in fact what are making flex
not evolve as expect.
Let's make flex maven (and other BSMs) compatible and people will continue
using it since there's no better solution to build RIA applications on the
market and will play with the rest of technologies in that projects and
with the normalized ways for enterprises of build software.
Tools (and vendors) are to serve technology and users, not the inverse. If
people need maven and a well designed structure, people will support the
effort and will claim for this kind of changes, then Adobe, IDEA, FDT and
whatever other vendor that would like to continue selling upgrades will be
forced to be competitive, or throw the towel.
Right now a 4.8 version is needed with parity with with Adobe flex sdk 4.6.
After this happen, still many people will continue using Adobe flex sdk
4.5.1.21328. Why? because it will continue to be the latest flex sdk
mavenized and deployed and available to build systems with flex, java and
other technologies with maven.
2012/5/24 Alex Harui <ah...@adobe.com>
>
>
>
> On 5/24/12 12:50 PM, "Carlos Rovira" <ca...@codeoscopic.com>
> wrote:
>
> > I think IntelliJ will update quickly since they are
> > "maven-gradle-whatever-bms-oriented".
> > Flash Builder never took into account BMS, but they will update due that
> > technology requeriments....or are you saying that they will abandon Flex
> > development?
> Adobe is improving the next release of Flash Builder to be a bit more
> configurable so it can work with Apache Flex SDKs. After that, it is a
> business decision as to whether Adobe will do any further work if the
> Apache
> Flex SDK evolves in a way that is incompatible.
>
> If other tool vendors are more willing to make changes and therefore
> provide
> a more compelling tool than Adobe, then we'll see folks move in that
> direction, and then we'll see if Adobe chooses to compete or not.
> >
> > moreover...are you saying that we must stay with what we have now?
> > so...that's what we can expect for the future of flex? stay with the same
> > problems we ever had during all years? What kind of changes can we
> expect?
> > only cosmetic changes?
> We have to consider factors when proposing changes like installed base,
> what
> our users know and expect. But I think we can make some big changes over
> time.
> >
> > Michel, you and Alex were talking about agresive changes in the
> SDK...i.e:
> > a completely new set of flex components and arqutecture, isn't it?...so
> > changes like that will not obligate Adobe to update Fb in order to make
> it
> > Apache Flex compliant?
> Flash Builder is not obligated to update to handle changes to the Apache
> Flex SDK. One thing we need to do is get some momentum so that there is a
> compelling market that would incite Adobe to want to update FB so it can
> extract revenue from customer upgrades. But if some other tool vendor ends
> up creating a better tool and everyone starts using it and makes FB a thing
> of the past, that's fine with me.
>
> Most important to me is that we have to solve the important problems.
> Maven
> integration is the top vote getter at Adobe JIRA by far. It is time to
> make
> adjustments to Apache Flex to make Maven work, but we want to do so without
> breaking everyone else's workflow.
>
> We have been forced by legal reasons to change the package structure.
> Apache Flex releases cannot look like the tree of files you get from Adobe.
> And since we're doing that, it is time to consider any changes to make
> Maven
> easier to support. But we are not asking the tool vendors to change with
> us.
> Instead, we are providing scripts to repackage the files from the various
> sources into something the tools can use.
>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
RE: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>I think there's a misundertood. copying from my mail at 16:22 : "Maybe just as soon as Apache Flex 4.8 sdk will be released, right?". So it's right to wait until 4.9. We all agree with parity release is the best to start.
My mistake. I missed that sentence
Re: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
"This was supposed to be a parity release. I think we shouldn't change
something major in a parity release."
I think there's a misundertood. copying from my mail at 16:22 : "Maybe just
as soon as Apache Flex 4.8 sdk will be released, right?". So it's right to
wait until 4.9. We all agree with parity release is the best to start.
2012/5/24 Michael A. Labriola <la...@digitalprimates.net>
> >Flash Builder never took into account BMS, but they will update due that
> technology requeriments....or are you saying that they will abandon Flex
> development?
>
> I am saying they will provide us exactly what we have right now, maybe
> with a few bug fixes. I am also saying that users who have Flash Builder 4
> aren't going to invest in a new IDE right now when most companies still
> doing Flex are in a 'wait and see' mode.
>
> >moreover...are you saying that we must stay with what we have now?
>
> This was supposed to be a parity release. I think we shouldn't change
> something major in a parity release.
>
> >so...that's what we can expect for the future of flex? stay with the same
> problems we ever had during all years? What kind of changes can we expect?
> only cosmetic changes?
>
> Nope, however, I do think there are a lot more than cosmetic changes that
> can be done before we have to break IDE compatibility. I think we are free
> to evolve forward as we see fit, but we also need to understand that doing
> so will invariably mean that, at some point, Flash Builder won't work with
> this SDK. That may be just fine once people have bought into the idea of
> Apache Flex being viable. I think it's an awful idea to ask people to
> invest more money when they aren't sure of its long-term viability.
>
> >Michel, you and Alex were talking about agresive changes in the
> SDK...i.e: a completely new set of flex components and arqutecture, isn't
> it?...
> >so changes like that will not obligate Adobe to update Fb in order to
> make it Apache Flex compliant?
>
> Let me be 100% perfectly clear on my opinion. No matter what Adobe has
> told you, there is no chance (IMO) that they are going to spend serious
> money reworking Flash Builder to ensure it works with a radically different
> SDK structure. I can't see this happening. I am sure they will do the work
> to test and make minor changes to ensure compatibility for a while. Maybe I
> am wrong but I don't think so.
>
> The changes I was planning on making were intentionally geared toward
> ensuring that existing projects still continue to function in existing
> versions of Flash Builder. My hope was that people like IntelliJ would
> support our more advanced features and hence become the clear choice, but
> that we wouldn't break things for existing users.
>
> Mike
>
>
>
>
> 2012/5/24 Michael A. Labriola <la...@digitalprimates.net>
>
> > >I think the tool refactors implied in tools like Fb or Intellij will
> > >be
> > of low impact and should not be a problem to stop evolution, since is
> > re-structure of the sdk to be a more standard piece of software...
> > maybe I'm talking from a >feeling that this not should be a huge
> showstopper.
> >
> > So, you think Adobe will refactor Flash Builder to make us happy? What
> > about the thousands of copies in use already that people won't pay to
> > update and won't work with a refactored sdk?
> >
> >
> >
>
>
> --
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F: +34 912 35 57 77
> <http://www.codeoscopic.com>
> CODEOSCOPIC S.A. <http://www.codeoscopic.com> Avd. del General Perón, 32
> Planta 10, Puertas P-Q
> 28020 Madrid
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
RE: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>Flash Builder never took into account BMS, but they will update due that technology requeriments....or are you saying that they will abandon Flex development?
I am saying they will provide us exactly what we have right now, maybe with a few bug fixes. I am also saying that users who have Flash Builder 4 aren't going to invest in a new IDE right now when most companies still doing Flex are in a 'wait and see' mode.
>moreover...are you saying that we must stay with what we have now?
This was supposed to be a parity release. I think we shouldn't change something major in a parity release.
>so...that's what we can expect for the future of flex? stay with the same problems we ever had during all years? What kind of changes can we expect? only cosmetic changes?
Nope, however, I do think there are a lot more than cosmetic changes that can be done before we have to break IDE compatibility. I think we are free to evolve forward as we see fit, but we also need to understand that doing so will invariably mean that, at some point, Flash Builder won't work with this SDK. That may be just fine once people have bought into the idea of Apache Flex being viable. I think it's an awful idea to ask people to invest more money when they aren't sure of its long-term viability.
>Michel, you and Alex were talking about agresive changes in the SDK...i.e: a completely new set of flex components and arqutecture, isn't it?...
>so changes like that will not obligate Adobe to update Fb in order to make it Apache Flex compliant?
Let me be 100% perfectly clear on my opinion. No matter what Adobe has told you, there is no chance (IMO) that they are going to spend serious money reworking Flash Builder to ensure it works with a radically different SDK structure. I can't see this happening. I am sure they will do the work to test and make minor changes to ensure compatibility for a while. Maybe I am wrong but I don't think so.
The changes I was planning on making were intentionally geared toward ensuring that existing projects still continue to function in existing versions of Flash Builder. My hope was that people like IntelliJ would support our more advanced features and hence become the clear choice, but that we wouldn't break things for existing users.
Mike
2012/5/24 Michael A. Labriola <la...@digitalprimates.net>
> >I think the tool refactors implied in tools like Fb or Intellij will
> >be
> of low impact and should not be a problem to stop evolution, since is
> re-structure of the sdk to be a more standard piece of software...
> maybe I'm talking from a >feeling that this not should be a huge showstopper.
>
> So, you think Adobe will refactor Flash Builder to make us happy? What
> about the thousands of copies in use already that people won't pay to
> update and won't work with a refactored sdk?
>
>
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com> Avd. del General Perón, 32 Planta 10, Puertas P-Q
28020 Madrid
Re: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Christofer,
I think that what you are referring is a rethink from Adobe about how much
sense has to have developer tools into a creative suite (from the Fb stand
point since Fc really has been discontinued). Nothing to do about the
effort behind the tool (Fb).
As Alex said, Adobe is working in take Apache Flex into account and that
means a new release cycle. They will do as best as they can in order to get
a competitive Fb. But this is something we don't have to worry about. They
are a business and for that reason we are today here in Apache. They will
move based in business strategies that could be comprensible by us...or
not... what is clear to me is that we have a need and our responsability
here is to solve that need. And that Adobe has its own needs and are belong
to them to solve them. Normaly they will serve their users if they want to
maintain the sales, and this means to go with the flow, in this specific
case the flow marked by Apache Flex.
2012/5/25 christofer.dutz@c-ware.de <ch...@c-ware.de>
> It seems that the new Creative Suite Web Premium followup ships without
> Catalyst and FlashBuilder ... I think that is a pretty good statement
> towards how much effort Adobe will be putting into maintaining those tools.
>
> Chris
>
> -----Ursprüngliche Nachricht-----
> Von: carlos.rovira@gmail.com [mailto:carlos.rovira@gmail.com] Im Auftrag
> von Carlos Rovira
> Gesendet: Donnerstag, 24. Mai 2012 21:50
> An: flex-dev@incubator.apache.org
> Betreff: Re: Apache Flex structure to be BMS compliant (was Re: Library
> Versions used in Flex SDK)
>
> I think IntelliJ will update quickly since they are
> "maven-gradle-whatever-bms-oriented".
> Flash Builder never took into account BMS, but they will update due that
> technology requeriments....or are you saying that they will abandon Flex
> development?
>
> moreover...are you saying that we must stay with what we have now?
> so...that's what we can expect for the future of flex? stay with the same
> problems we ever had during all years? What kind of changes can we expect?
> only cosmetic changes?
>
> Michel, you and Alex were talking about agresive changes in the SDK...i.e:
> a completely new set of flex components and arqutecture, isn't it?...so
> changes like that will not obligate Adobe to update Fb in order to make it
> Apache Flex compliant?
>
>
>
> 2012/5/24 Michael A. Labriola <la...@digitalprimates.net>
>
> > >I think the tool refactors implied in tools like Fb or Intellij will
> > >be
> > of low impact and should not be a problem to stop evolution, since is
> > re-structure of the sdk to be a more standard piece of software...
> > maybe I'm talking from a >feeling that this not should be a huge
> showstopper.
> >
> > So, you think Adobe will refactor Flash Builder to make us happy? What
> > about the thousands of copies in use already that people won't pay to
> > update and won't work with a refactored sdk?
> >
> >
> >
>
>
> --
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F: +34 912 35 57 77
> <http://www.codeoscopic.com>
> CODEOSCOPIC S.A. <http://www.codeoscopic.com> Avd. del General Perón, 32
> Planta 10, Puertas P-Q
> 28020 Madrid
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
AW: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by "christofer.dutz@c-ware.de" <ch...@c-ware.de>.
It seems that the new Creative Suite Web Premium followup ships without Catalyst and FlashBuilder ... I think that is a pretty good statement towards how much effort Adobe will be putting into maintaining those tools.
Chris
-----Ursprüngliche Nachricht-----
Von: carlos.rovira@gmail.com [mailto:carlos.rovira@gmail.com] Im Auftrag von Carlos Rovira
Gesendet: Donnerstag, 24. Mai 2012 21:50
An: flex-dev@incubator.apache.org
Betreff: Re: Apache Flex structure to be BMS compliant (was Re: Library Versions used in Flex SDK)
I think IntelliJ will update quickly since they are "maven-gradle-whatever-bms-oriented".
Flash Builder never took into account BMS, but they will update due that technology requeriments....or are you saying that they will abandon Flex development?
moreover...are you saying that we must stay with what we have now?
so...that's what we can expect for the future of flex? stay with the same problems we ever had during all years? What kind of changes can we expect?
only cosmetic changes?
Michel, you and Alex were talking about agresive changes in the SDK...i.e:
a completely new set of flex components and arqutecture, isn't it?...so changes like that will not obligate Adobe to update Fb in order to make it Apache Flex compliant?
2012/5/24 Michael A. Labriola <la...@digitalprimates.net>
> >I think the tool refactors implied in tools like Fb or Intellij will
> >be
> of low impact and should not be a problem to stop evolution, since is
> re-structure of the sdk to be a more standard piece of software...
> maybe I'm talking from a >feeling that this not should be a huge showstopper.
>
> So, you think Adobe will refactor Flash Builder to make us happy? What
> about the thousands of copies in use already that people won't pay to
> update and won't work with a refactored sdk?
>
>
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com> Avd. del General Perón, 32 Planta 10, Puertas P-Q
28020 Madrid
Re: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by Alex Harui <ah...@adobe.com>.
On 5/24/12 12:50 PM, "Carlos Rovira" <ca...@codeoscopic.com> wrote:
> I think IntelliJ will update quickly since they are
> "maven-gradle-whatever-bms-oriented".
> Flash Builder never took into account BMS, but they will update due that
> technology requeriments....or are you saying that they will abandon Flex
> development?
Adobe is improving the next release of Flash Builder to be a bit more
configurable so it can work with Apache Flex SDKs. After that, it is a
business decision as to whether Adobe will do any further work if the Apache
Flex SDK evolves in a way that is incompatible.
If other tool vendors are more willing to make changes and therefore provide
a more compelling tool than Adobe, then we'll see folks move in that
direction, and then we'll see if Adobe chooses to compete or not.
>
> moreover...are you saying that we must stay with what we have now?
> so...that's what we can expect for the future of flex? stay with the same
> problems we ever had during all years? What kind of changes can we expect?
> only cosmetic changes?
We have to consider factors when proposing changes like installed base, what
our users know and expect. But I think we can make some big changes over
time.
>
> Michel, you and Alex were talking about agresive changes in the SDK...i.e:
> a completely new set of flex components and arqutecture, isn't it?...so
> changes like that will not obligate Adobe to update Fb in order to make it
> Apache Flex compliant?
Flash Builder is not obligated to update to handle changes to the Apache
Flex SDK. One thing we need to do is get some momentum so that there is a
compelling market that would incite Adobe to want to update FB so it can
extract revenue from customer upgrades. But if some other tool vendor ends
up creating a better tool and everyone starts using it and makes FB a thing
of the past, that's fine with me.
Most important to me is that we have to solve the important problems. Maven
integration is the top vote getter at Adobe JIRA by far. It is time to make
adjustments to Apache Flex to make Maven work, but we want to do so without
breaking everyone else's workflow.
We have been forced by legal reasons to change the package structure.
Apache Flex releases cannot look like the tree of files you get from Adobe.
And since we're doing that, it is time to consider any changes to make Maven
easier to support. But we are not asking the tool vendors to change with us.
Instead, we are providing scripts to repackage the files from the various
sources into something the tools can use.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Jonathan,
as I stated before I will do something like that in 4.9 since 4.8 is
already defined to be 1 : 1 with Adobe Flex SDK to get a start point. So I
think we all agree with that.
2012/5/24 Jonathan Campos <jo...@gmail.com>
> On Thu, May 24, 2012 at 2:50 PM, Carlos Rovira <
> carlos.rovira@codeoscopic.com> wrote:
>
> > moreover...are you saying that we must stay with what we have now?
> > so...that's what we can expect for the future of flex? stay with the same
> > problems we ever had during all years? What kind of changes can we
> expect?
> > only cosmetic changes?
> >
>
> My only argument is to not try to make these changes during any of the
> current branches. To expect any of the tools companies to change their
> release cycles to output a patch that fixes the Flex framework integration
> would be expecting way too much.
>
> In the next framework rounds we can make many more of these changes and
> tools companies will have the time to plan the change.
>
> My 2 cents.
>
> --
> Jonathan Campos
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
Re: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by Jonathan Campos <jo...@gmail.com>.
On Thu, May 24, 2012 at 2:50 PM, Carlos Rovira <
carlos.rovira@codeoscopic.com> wrote:
> moreover...are you saying that we must stay with what we have now?
> so...that's what we can expect for the future of flex? stay with the same
> problems we ever had during all years? What kind of changes can we expect?
> only cosmetic changes?
>
My only argument is to not try to make these changes during any of the
current branches. To expect any of the tools companies to change their
release cycles to output a patch that fixes the Flex framework integration
would be expecting way too much.
In the next framework rounds we can make many more of these changes and
tools companies will have the time to plan the change.
My 2 cents.
--
Jonathan Campos
Re: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
I think IntelliJ will update quickly since they are
"maven-gradle-whatever-bms-oriented".
Flash Builder never took into account BMS, but they will update due that
technology requeriments....or are you saying that they will abandon Flex
development?
moreover...are you saying that we must stay with what we have now?
so...that's what we can expect for the future of flex? stay with the same
problems we ever had during all years? What kind of changes can we expect?
only cosmetic changes?
Michel, you and Alex were talking about agresive changes in the SDK...i.e:
a completely new set of flex components and arqutecture, isn't it?...so
changes like that will not obligate Adobe to update Fb in order to make it
Apache Flex compliant?
2012/5/24 Michael A. Labriola <la...@digitalprimates.net>
> >I think the tool refactors implied in tools like Fb or Intellij will be
> of low impact and should not be a problem to stop evolution, since is
> re-structure of the sdk to be a more standard piece of software... maybe
> I'm talking from a >feeling that this not should be a huge showstopper.
>
> So, you think Adobe will refactor Flash Builder to make us happy? What
> about the thousands of copies in use already that people won't pay to
> update and won't work with a refactored sdk?
>
>
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
RE: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>I think the tool refactors implied in tools like Fb or Intellij will be of low impact and should not be a problem to stop evolution, since is re-structure of the sdk to be a more standard piece of software... maybe I'm talking from a >feeling that this not should be a huge showstopper.
So, you think Adobe will refactor Flash Builder to make us happy? What about the thousands of copies in use already that people won't pay to update and won't work with a refactored sdk?
Re: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by Om <bi...@gmail.com>.
>
> I think the tool refactors implied in tools like Fb or Intellij will be of
> low impact and should not be a problem to stop evolution, since is
> re-structure of the sdk to be a more standard piece of software... maybe
> I'm talking from a feeling that this not should be a huge showstopper.
>
What about existing Flash Builder or IntelliJ installations, i.e. users who
are using these IDEs and are awaiting new Flex SDK releases?
On Thu, May 24, 2012 at 12:38 PM, Carlos Rovira <
carlos.rovira@codeoscopic.com> wrote:
> First, I'm not saying we must change structure to make Flex SDK
> only-maven-compliant. I'm saying that we need some refactoring to be
> compliant with all BMS (not only maven). Think in some java project that
> could be build using ANT, Maven, Gradle and so on... ¿ok?
>
> Second, we are dragging lots of problems cause no changes were made before.
> We are here to evolve the SDK to be better and that requires changes that
> make more powerful the SDK (in this case to buy build more easily and by
> more build systems).
>
> I think the tool refactors implied in tools like Fb or Intellij will be of
> low impact and should not be a problem to stop evolution, since is
> re-structure of the sdk to be a more standard piece of software... maybe
> I'm talking from a feeling that this not should be a huge showstopper.
>
> I think this will be lots more benefitial than the possible derivated
> problems that could generate.
>
>
> 2012/5/24 Jonathan Campos <jo...@gmail.com>
>
> > On Thu, May 24, 2012 at 1:39 PM, Om <bi...@gmail.com> wrote:
> >
> > > Breaking existing tools like Flash Builder, IntelliJ just to make Maven
> > > work is not the best idea. We are at a very delicate point in terms of
> > end
> > > users' confidence and trust. Lets not break the camel's back.
> > >
> >
> > I 100% agree with Om. We don't want to get into the (very) bad habit of
> > "we're going to make a change and you need to move with us". Tool
> > developers don't like that very much. I think the fewer waves we make to
> > the ecosystem during the 4.x branch the better.
> >
> > --
> > Jonathan Campos
> >
>
>
>
> --
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F: +34 912 35 57 77
> <http://www.codeoscopic.com>
> CODEOSCOPIC S.A. <http://www.codeoscopic.com>
> Avd. del General Perón, 32
> Planta 10, Puertas P-Q
> 28020 Madrid
>
Re: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
First, I'm not saying we must change structure to make Flex SDK
only-maven-compliant. I'm saying that we need some refactoring to be
compliant with all BMS (not only maven). Think in some java project that
could be build using ANT, Maven, Gradle and so on... ¿ok?
Second, we are dragging lots of problems cause no changes were made before.
We are here to evolve the SDK to be better and that requires changes that
make more powerful the SDK (in this case to buy build more easily and by
more build systems).
I think the tool refactors implied in tools like Fb or Intellij will be of
low impact and should not be a problem to stop evolution, since is
re-structure of the sdk to be a more standard piece of software... maybe
I'm talking from a feeling that this not should be a huge showstopper.
I think this will be lots more benefitial than the possible derivated
problems that could generate.
2012/5/24 Jonathan Campos <jo...@gmail.com>
> On Thu, May 24, 2012 at 1:39 PM, Om <bi...@gmail.com> wrote:
>
> > Breaking existing tools like Flash Builder, IntelliJ just to make Maven
> > work is not the best idea. We are at a very delicate point in terms of
> end
> > users' confidence and trust. Lets not break the camel's back.
> >
>
> I 100% agree with Om. We don't want to get into the (very) bad habit of
> "we're going to make a change and you need to move with us". Tool
> developers don't like that very much. I think the fewer waves we make to
> the ecosystem during the 4.x branch the better.
>
> --
> Jonathan Campos
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
Re: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by Jonathan Campos <jo...@gmail.com>.
On Thu, May 24, 2012 at 1:39 PM, Om <bi...@gmail.com> wrote:
> Breaking existing tools like Flash Builder, IntelliJ just to make Maven
> work is not the best idea. We are at a very delicate point in terms of end
> users' confidence and trust. Lets not break the camel's back.
>
I 100% agree with Om. We don't want to get into the (very) bad habit of
"we're going to make a change and you need to move with us". Tool
developers don't like that very much. I think the fewer waves we make to
the ecosystem during the 4.x branch the better.
--
Jonathan Campos
Re: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by Om <bi...@gmail.com>.
>
> 1) maintain the structure and use a tool (like you did) to transform the
> sdk to maven compliant sdk.
>
> 2) change sdk structure to get directly a maven compliant sdk
>
> IMHO the best way should be 2), since now is the right time to make
> changes. Maybe just as soon as Apache Flex 4.8 sdk will be released, right?
>
> Tools should change to make Apache Flex SDK compliant.
>
I respectfully disagree. I think (1) is the way to go. This gives us
(Flex SDK team) the freedom to maintain whatever structure we want. If
some of us want to make it Maven compliant, they should write a tool to
create a Maven-specific directory structure and maintain it either part of
Apache Flex or outside of Apache Flex.
Maven is not the only build management system we want to support. Lots of
folks use Ant, GradleFx, custom build scripts, etc. If we favor Maven,
then it is not fair for the other tools.
Breaking existing tools like Flash Builder, IntelliJ just to make Maven
work is not the best idea. We are at a very delicate point in terms of end
users' confidence and trust. Lets not break the camel's back.
Thanks,
Om
Re: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Chris,
I think we actually are talking about two ways:
1) maintain the structure and use a tool (like you did) to transform the
sdk to maven compliant sdk.
2) change sdk structure to get directly a maven compliant sdk
IMHO the best way should be 2), since now is the right time to make
changes. Maybe just as soon as Apache Flex 4.8 sdk will be released, right?
Tools should change to make Apache Flex SDK compliant.
2012/5/24 christofer.dutz@c-ware.de <ch...@c-ware.de>
> I wasn't talking about changing the SDK structure in the installable SDK
> version which Flash Builder would use. I was more talking about deploying a
> mavenized version in Maven Central. This should not have any effect on
> Flash Builder. But as I understood there allready are incompatabilities, as
> the playerglobals can no longer be shipped with the SDK.
>
> Chris
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Carol Frampton [mailto:cframpto@adobe.com]
> Gesendet: Donnerstag, 24. Mai 2012 16:07
> An: flex-dev@incubator.apache.org
> Betreff: Re: Apache Flex structure to be BMS compliant (was Re: Library
> Versions used in Flex SDK)
>
> Just be aware that if you are talking about moving directories around will
> quite likely break Apache Flex working with Flash Builder and/or IntelliJ.
>
> Carol
>
> On 5/24/12 10 :01AM, "Carlos Rovira" <ca...@codeoscopic.com>
> wrote:
>
> >> be a good thing for the people maintaining Flex to also maintain its
> >Metadata
> >So putting the metadata into the Apache Flex SVN repo would be a good
> >start?
> >
> >Chris,
> >
> >I understand that Marvin gave you the built instructions and xml files
> >to create a mavenized Flex SDK or that you can talk with him to get it
> >from first hand. Moreover, if you was working with all SDKs as you
> >report, you already know all about this process.
> >
> >That process could give us the keys to rethink all Apache Flex SDK
> >structure to be BMS (Build Management System) compliant. (Regarding the
> >instructions, if you can't get it I can provide you with the files I
> >used in my company and some instructions, although there's some places
> >out there where you can find it.)
> >
> >I think that we need to create the needed pom(s) (in the maven case, I
> >don't know yet how gradle works) for the new refactorized flex sdks in
> >order to create the artifacts. The last point to take into account
> >would be to talk with apache maven project to publish in maven central
> >repository the flex sdk artifacts. (Maybe I'm wrong in some step since
> >I never do something like this... thiese are theoreticaly the steps to
> >follow).
> >
> >In this way we could have all artifacts directly available when a new
> >flex sdk was released in a maven central repository.
>
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
AW: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by "christofer.dutz@c-ware.de" <ch...@c-ware.de>.
I wasn't talking about changing the SDK structure in the installable SDK version which Flash Builder would use. I was more talking about deploying a mavenized version in Maven Central. This should not have any effect on Flash Builder. But as I understood there allready are incompatabilities, as the playerglobals can no longer be shipped with the SDK.
Chris
-----Ursprüngliche Nachricht-----
Von: Carol Frampton [mailto:cframpto@adobe.com]
Gesendet: Donnerstag, 24. Mai 2012 16:07
An: flex-dev@incubator.apache.org
Betreff: Re: Apache Flex structure to be BMS compliant (was Re: Library Versions used in Flex SDK)
Just be aware that if you are talking about moving directories around will quite likely break Apache Flex working with Flash Builder and/or IntelliJ.
Carol
On 5/24/12 10 :01AM, "Carlos Rovira" <ca...@codeoscopic.com> wrote:
>> be a good thing for the people maintaining Flex to also maintain its
>Metadata
>So putting the metadata into the Apache Flex SVN repo would be a good
>start?
>
>Chris,
>
>I understand that Marvin gave you the built instructions and xml files
>to create a mavenized Flex SDK or that you can talk with him to get it
>from first hand. Moreover, if you was working with all SDKs as you
>report, you already know all about this process.
>
>That process could give us the keys to rethink all Apache Flex SDK
>structure to be BMS (Build Management System) compliant. (Regarding the
>instructions, if you can't get it I can provide you with the files I
>used in my company and some instructions, although there's some places
>out there where you can find it.)
>
>I think that we need to create the needed pom(s) (in the maven case, I
>don't know yet how gradle works) for the new refactorized flex sdks in
>order to create the artifacts. The last point to take into account
>would be to talk with apache maven project to publish in maven central
>repository the flex sdk artifacts. (Maybe I'm wrong in some step since
>I never do something like this... thiese are theoreticaly the steps to
>follow).
>
>In this way we could have all artifacts directly available when a new
>flex sdk was released in a maven central repository.
Re: Apache Flex structure to be BMS compliant (was Re: Library
Versions used in Flex SDK)
Posted by Carol Frampton <cf...@adobe.com>.
Just be aware that if you are talking about moving directories around will
quite likely break Apache Flex working with Flash Builder and/or IntelliJ.
Carol
On 5/24/12 10 :01AM, "Carlos Rovira" <ca...@codeoscopic.com> wrote:
>> be a good thing for the people maintaining Flex to also maintain its
>Metadata
>So putting the metadata into the Apache Flex SVN repo would be a good
>start?
>
>Chris,
>
>I understand that Marvin gave you the built instructions and xml files to
>create a mavenized Flex SDK or that you can talk with him to get it from
>first hand. Moreover, if you was working with all SDKs as you report, you
>already know all about this process.
>
>That process could give us the keys to rethink all Apache Flex SDK
>structure to be BMS (Build Management System) compliant. (Regarding the
>instructions, if you can't get it I can provide you with the files I used
>in my company and some instructions, although there's some places out
>there
>where you can find it.)
>
>I think that we need to create the needed pom(s) (in the maven case, I
>don't know yet how gradle works) for the new refactorized flex sdks in
>order to create the artifacts. The last point to take into account would
>be
>to talk with apache maven project to publish in maven central repository
>the flex sdk artifacts. (Maybe I'm wrong in some step since I never do
>something like this... thiese are theoreticaly the steps to follow).
>
>In this way we could have all artifacts directly available when a new flex
>sdk was released in a maven central repository.