Hi Cosma,
yes you are right. The Downloader only downloads the artifacts for the current
operating-system. But for example older Adobe FDKs had the following structure:
{root}/runtimes/air
{root}/runtimes/air/android
{root}/runtimes/air/mac
{root}/runtimes/air/win
{root}/runtimes/player/10.2/
{root}/runtimes/player/10.2/lnx
{root}/runtimes/player/10.2/mac
{root}/runtimes/player/10.2/win
Even if I didn't implement packaging of android, I think you get the Idea of
what directory structure the mavenizer expects.
Eventually it could be an option to have some Advanced Settings in the SDK
Download Tool to "also download other os runtimes". Then the Mavenizer would
also package these.
Chris
-----Ursprüngliche Nachricht-----
Von: Cosma Colanicchia [mailto:cosma...@gmail.com]
Gesendet: Dienstag, 19. November 2013 21:27
An: Apache Flex Developers ML
Betreff: Re: Questions about current mavenizer status
@Christofer
Thanks for the info, just some questions: when you say “win” directory, are you
referring to the subfolders in runtimes/air and runtimes/air-captive?
The SDK produced by the installer correctly contains the “mac” runtimes, if I
understand correctly I should be able to add the corresponding “win”
folders (borrowing them from an SDK prepared by the installer on a Windows
machine?) and the mavenizer should pick up them producing artifacts usable from
win and mac, am I right? I see that the bin directory already contains windows
batch file as well as bash scripts, so it should already be cross-platform in
this respect.
I’ll also try the in-vm deployer and let you know.
@Om
After a first look, it seems ok and very similar to the README.txt contents.
Maybe we could add some detail about the AIR SDK requirement (that is actually
not required with the latest Apache Flex releases), and some words about the
effect of running it from a specific platform (mac/win). This is not a problem
with the installer itself (it is meant to prepare an SDK for the user on its
environment), but generally the artifacts are prepared and deployed in order to
be used by other developers, so we should probably warn users about this.
If we want to help out new users, we could try to provide a streamlined,
step-by-step guide referred to the latest Apache Flex version, along with a
convenience link to a compiled jar of the mavenizer tool and maybe a bash/batch
wrapper file. On the other hand, this could be totally avoided if we plan to go
ahead in managing the mavenizer from the installer.
2013/11/19 OmPrakash Muppirala <bigosma...@gmail.com>
> On Tue, Nov 19, 2013 at 11:47 AM, christofer.d...@c-ware.de <
> christofer.d...@c-ware.de> wrote:
>
> > Hi Cosma,
> >
> > as Toni already confirmed, the mavenizer is currently the easiest
> > way to create maven artifacts from a Flex SDK you downloaded using
> > the
> Downloader.
> > The Mavenizer doesn't actually require the Air SDK, the problem was,
> > that the Mavenizer is able to mavenize any Flex SDK starting from
> > Adobe Flex 2 up to 4.11. In order to be able to User newer Air
> > versions with older
> FDKs
> > I added the ability to mavenize the Air SDKs separately.
> >
> > I think I remember creating all the runtime archives for any
> > platform (Flashplayer or Air Runtime) found in the Flex SDK or the
> > Air SDK. So if the SDK contains a "win" dir, it creates the windows
> > archive, if lnx the ones for Linus and mac the ones for Macs.
> >
> > When deploying to your local maven repository, I would suggest to
> > give my new deployer a testdrive. It should be noticeably faster
> > with deploying
> the
> > artifacts. (SDKInVMDeployer).
> >
> > Please don’t start that dreaded "deploy flex to a public repo"-thread ...
> > the discussion always tends to explode in tons of emails and then
> suddenly
> > ends nowhere, so I have given up on this. I think the FDK Downloader
> > + Mavenizer path being the least complicated path. All others will
> definitely
> > end in a support-mayhem because from my experience on the Flexmojos
> > Mailinglist (when it still existed) was that people don't read
> > documentation ;-)
> >
> > Chris
> >
> >
> Cosma/Toni/Chris,
>
> Can you please make sure that the info discussed in this thread is
> consistent with what is described here [1] If not, can one of you
> please update the wiki? This is very valuable info for others who
> want to go the mavenizer route, so please help keep the docs
> upto-date.
>
> Thanks,
> Om
>
> [1]
> https://cwiki.apache.org/confluence/display/FLEX/Apache+Flex+SDK+Maven
> izer
>
>
>
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Cosma Colanicchia [mailto:cosma...@gmail.com]
> > Gesendet: Dienstag, 19. November 2013 18:26
> > An: Apache Flex Developers ML
> > Betreff: Questions about current mavenizer status
> >
> > Hi there,
> >
> > I’m in the process of trying of rolling out Apache Flex 4.11
> > internally for the other employees of my company, and I need to
> > deploy the related artifacts to the company Maven repo.
> >
> > AFAIK, the only way to do this for 4.11 is by mavenizing/deploying a
> > downloaded FDK, is this right? I was following the other thread
> > about storing ready-to-use artifacts in some public repository, but
> > this path doesn’t seem ready yet (BTW, is there something I could do
> > to help in
> this
> > effort?)
> >
> > I managed to successfully build and mavenize the FDK from develop
> > branch in some months ago, but I still have some questions:
> >
> > Q1 - I’m going to try running the mavenizer/deployer tools on the
> > output of the Apache Flex Installer in order to mavenize the
> > released 4.11 FDK,
> is
> > this the intended way of using it?
> >
> > Q2 - the mavenizer requires the AIR runtime in a separate directory...
> but
> > the installer output should already have integrated it in the FDK,
> > should provide it separately anyway?
> >
> > Q3 - is the FDK produced by the installer cross-platform? This time
> > I’m using a Mac to run the installer, so it has probably downloaded
> > the Mac version of the AIR SDK.. does this mean that, when
> > mavenizing this SDK,
> the
> > Windows binaries (e.g. adt command line tool) won’t be included in
> > the
> SDK
> > artifacts and the SDK won’t be fully compatible with developers on
> Windows
> > machines?
> >
> >
> > Thank you for any help
> > Cosma
> >
>
