Sound like a plan. Release first, then 'rebuild'. Getting back to basics is always a good thing, clear out the crud that inevitably built up over the years at the previous owner, and start 'fresh'.
EdB On Sun, Dec 14, 2014 at 1:16 PM, Christofer Dutz <christofer.d...@c-ware.de> wrote: > How about re-organizing the code of the project? (But I would opt to do that > after a release) > Currently it seems as if the actual project is embedded in a wrapper of the > old build (which I didn't get to work) > I would like to move the "modules" content out to become the root, and to > move all the old stuff to some "attic" directory I don't want to delete it, > just want to park it so if users come with special needs, we can check what > we have to do to revive parts of the attic code. > > Chris > > -----Ursprüngliche Nachricht----- > Von: Alex Harui [mailto:aha...@adobe.com] > Gesendet: Sonntag, 14. Dezember 2014 08:15 > An: dev@flex.apache.org > Betreff: Re: BlazeDS not compiling for clean copy of SDK source > > > > On 12/13/14, 1:45 PM, "Gordon Smith" <gsmit...@hotmail.com> wrote: > >>> I get the following error on a clean copy of the SDK, when I do an >>>'ant release' ... But as soon as I did an 'ant' on 'flex-blazeds' and >>>then tried again, the problem went away ... >>> [javac] >>>/Users/erik/Documents/ApacheFlex/git/flexblazeds/modules/common/src/fl >>>ex/ >>>messaging/config/ApacheXPathClientConfigurationParser.java:19: >>> error: package org.apache.xpath does not exist >> >>I had the same problem. >> >>I don't think it should be a requirement to manually build flex-blazeds >>before building flex-sdk. If the SDK needs something in BlazeDS, >>BlazeDS should have an ant target that automatically builds that thing >>without error, and the ant script for flex-sdk should call that target. >>The README should explain that you must have source for both repos and >>that you have asset BLAZEDS_HOME to point to flex-blazeds in addition >>to setting FLEX_HOME to point to flex-sdk. (Bummer that this isn't >>called SDK_HOME, or that both aren't FLEX_SDK_HOME and >>FLEX_BLAZEDS_HOME.) >> >>The way that the build.xml for flex-sdk finds the flex-blazeds repo >>looks inconsistent. I see references to ${BLAZEDS_HOME}, but I don't >>have this set and the script didn't seem to complain. I also see >>references to ${FLEX_HOME}/../flex-blazeds and to >>${FLEX_HOME}/../blazeds. All references should go through BLAZEDS_HOME >>and an early check should fail if this isn't set. > > We can make changes, but IMO, flex-falcon relies on flex-sdk being built > first, so I thought that was fair precedence. For both the BlazeDS and TLF > dependencies, the flex-sdk script checks to see if you have the repos in a > few expected places so you don’t have to set up environment variables. We’ve > been doing this for TLF for some time now. > >> >>Is the dependency on BlazeDS something that got added recently? What >>does the SDK need from BlazeDS? > > Yes, the BlazeDS dependency was added a few days ago. Before then, the SDK > downloaded flex-messaging-common.jar from Adobe BlazeDS. We have now reduced > our Adobe proprietary dependencies to just the optional fontswf jars. OSMF > is under MPL, and AIR and Flash are considered build tools. > The flex-messaging-common.jar is only needed when specifying a > services-config in the MXMLC command line. No idea if this is supported in > Falcon. FlexJS currently doesn’t leverage it. > > -Alex > -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
