incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Om <bigosma...@gmail.com>
Subject Re: [Discussion] Implementing a dedicated maven-flex-plugin
Date Wed, 07 Nov 2012 23:45:29 GMT
On Wed, Nov 7, 2012 at 3:40 PM, Dasa Paddock <dpaddock@esri.com> wrote:

> This is the repo that's been getting updates:
> https://github.com/apache/flex-sdk
>
>
You are right.  And to be precise, it is the develop branch where stuff
gets checked in: https://github.com/apache/flex-sdk/tree/develop

And it does not support pull requests.


>  On Nov 7, 2012, at 3:32 PM, Om <bigosmallm@gmail.com> wrote:
>
> > On Wed, Nov 7, 2012 at 3:29 PM, Eugene Krevenets (aka Hyzhak) <
> > hyzhak@yandex.com> wrote:
> >
> >> It's good news. Where you plan to share New Maven Plugin sources? As i
> >> mentioned before, it's better be a github, because it's easy to pull
> >> request to it. Thank you for your contribution to community.
> >>
> >>
> > It would be best if the source code is directly contributed to the main
> > Apache Flex repo.
> >
> > There is a github mirror for Apache Flex here:
> > https://github.com/apache/flex for those who are interested in using
> > github.
> >
> > Thanks,
> > Om
> >
> >
> >
> >> 07.11.2012, 20:32, "christofer.dutz@c-ware.de" <
> christofer.dutz@c-ware.de
> >>> :
> >>> Hi,
> >>>
> >>> as most of you probably know, I'm currently working on a tool to
> >> generate Mavenized FDKs. In parallel I am adjusting Flexmojos to support
> >> the new Apache FDKs so people can build Flex applications using Maven.
> >>>
> >>> So far so good. After finishing the Generator and adjusting Flexmojos
> to
> >> all of my changes, the last step was to generate the 4.8 FDK using the
> >> maven group id org.apache.flex instead of com.adobe.flex.
> >>>
> >>> Now this introduced MAJOR problems. Currently you could use Flexmojos
> >> with 4.8, if you compile the entire Plugin against the group id of
> apache
> >> or you could use the adobe fdks after compiling it against the adobe
> group
> >> id.
> >>> The main reason is that otherwise Maven imports two versions of the
> jars
> >> (the one of the FDK you want and the one Flexmojos was compiled
> against).
> >>>
> >>> Sorting this out would be a total nightmare as there are really magical
> >> hacks working inside the build which cause any change in the scopes of
> >> dependencies to blow everything up.
> >>> I guess this is because Flexmojos includes insanely much code for
> >> supporting legacy FDKs (back to 2.0 FDKs) and a ton of different tools
> for
> >> different parts of the build lifecycle.
> >>>
> >>> My question now would be if it would not be better to officially leave
> >> Flexmojos to be compiled against com.adobe.flex and to include an
> option in
> >> the generator to generate the Apache FDKs to the Adobe namespace and to
> let
> >> users be happy with that and use it.
> >>>
> >>> In parallel I would volunteer to start work on a new plugin aimed at
> >> apache flex, but leaving away support of the Adobe FDKs. I would
> suggest to
> >> concentrate on the main path, supporting only apache fdks, only flexunit
> >> 4.1 for unit-testing, only the newest granite code generator and so on.
> In
> >> this case this should be a manageable task, even if it will take a
> while.
> >> As soon as the Version 1.0 is out we could start extending this to
> support
> >> more stuff our users would need. I think continuing to add more and more
> >> code to Flexmojos will only make it an unmaintainable monster whith all
> the
> >> problems comming from that.
> >>>
> >>> As I mentioned, I would volunteer to start such a thing and I think
> >> using Flexmojos as an inspiration on how to possibly implement something
> >> like that it should be manageable.
> >>>
> >>> What do you think?
> >>>
> >>> Chris
> >>
> >> --
> >> Best regards.
> >>
> >> Eugene Krevenets. Software Engineer of Realaxy.
> >>
> >> Blog: http://anykeytocreate.blogspot.com
> >> Code: http://hyzhak.github.com
> >> linkedIn: http://me.linkedin.com/in/eugenekrevenets
> >>
>
>

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