Hi Chris, I understand you aren’t suggesting a switch to Maven, but my understanding of your proposal to use aether is that it would still require that folks learn something about pom.xml in order to change the downloads for the ant build, and require that folks get an external jar of ant tasks.
Let’s see what other folks have to say, but I recall some folks not liking external ant tasks in our ant builds. Is there something fundamentally wrong with the Get task or is there another option where we standardize our download.xml files to be more data-driven? -Alex On 12/13/14, 4:35 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: >Hi Alex, > >I'm not suggesting to switch to Maven ... all I was suggesting was to use >the part of Maven that deals with the downloading and resolving of >artifacts using maven and to keep the rest of the build. Could probably >be as easy as replacing the download.xml to not manually download the >artifacts using get. > >A real switch to Maven would definitely by my favorite solution, but I >know that Maven tends to look like magic for outsiders and I don't want >to make things harder for you. (Even if I think that a maven build would >actually be a lot simpler than the Ant one) > >Chris > >________________________________________ >Von: Alex Harui <aha...@adobe.com> >Gesendet: Freitag, 12. Dezember 2014 19:01 >An: dev@flex.apache.org >Betreff: Re: AW: Proposal for cleaning up the downloading of dependencies > >I’m all for making things easier to work with and more reliable. Maven is >still a foreign language to me. Maybe I haven’t found the right document, >but it seems harder to learn because it is higher-level. > >IMO, sometimes you choose different tools for professionals vs tools for >volunteers. One of the reasons FalconJX was created and FalconJS was >abandoned was because FalconJS used the JBurg BURM which, while an >extremely powerful and interesting concept, was considered too hard to >learn by the volunteers who wanted to work on cross-compiling and a >simpler mechanism was created instead. At Adobe, engineers were paid full >time to learn how the BURM worked. Our volunteers don’t have that kind of >time. Sometimes I feel like Maven is a tool for people who do builds as a >profession, and Ant is the tool for the volunteers. > >Another possible factor is that Ant supposedly comes with Linux or we >count on most Linux folks having it because there is no Apache Flex >Installer for Linux. Will most Linux folks also have aether or Maven? > >Interestingly, the list of Apache compatible licenses only lists the >Eclipse Distribution License and not the Eclipse Public License but that >probably doesn’t really matter. The fact is the installers have set a >precedent of making you accept every non-AL license, even the >Apache-compatible ones, so we’d have to add another checkbox for aether. > >Honestly, I’m not really opposed to trying aether or switching to Maven if >that’s what the community wants. I’m sure I can learn how they work. But >short of that, is there something you, I or another volunteer can do to >make it easier for you and others to contribute? Would it be worth >investing in standardizing the download scripts and other Ant patterns? >Does anybody want to take that on? I’d probably volunteer to spend >several days on standardizing all of our current Ant script if I could >guarantee that enough new people would step up to be release managers >since that would save me time in the end. > >-Alex > >On 12/12/14, 9:03 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: > >>Well actually my suggestion has nothing to do with the flex-tool-api. >>It's just, that in my impression the manual way of downloading stuff from >>lots of places manually tends to break. We don't seem to have two >>projects dealing with the download of dependencies the same way. A lot of >>the solutions do stuff like check the md5 checksum when downloading, but >>not verify them when using them. So if for example we were to update to >>libx in version 1.2.3 from libx version 1.2.2 the build script would not >>detect this. >> >>I just want to make things simpler and more reliable. Currently there >>seem to be issues with the ssl handshake of ant get requests on some >>windows machines. Now we have to start fixing all of this whenever it >>breaks. >> >>The second thing is that we use third party libs and if we want to >>publish maven artifacts we should use the officially available versions >>of the libs. >> >>Aether is a core part of Maven and is distributed under the Eclipse >>Public License ... I doubt there should be any trouble with this. >> >>It's just that my main area of business is making builds more reliable >>and I thought that I'd share some stuff I found out to make our lives >>with Flex a little easier. >> >>I for my part would contribute a lot more, if the build of most of the >>tools wouldn't be such a nightmare to dig though. >> >>Chris >> >>________________________________________ >>Von: Alex Harui <aha...@adobe.com> >>Gesendet: Freitag, 12. Dezember 2014 17:34 >>An: dev@flex.apache.org >>Betreff: RE: Proposal for cleaning up the downloading of dependencies >> >>Hi Chris, >> >>Way back there were a lot of folks who didn't want Flex Ant scripts to >>use external tasks. In fact, I just went through and removed the BlazeDS >>Ant script's dependency on antcontrib. So it would be interesting to see >>whether folks want to learn how pom.xml files work and have this extra >>dependency. >> >>Also some of the install scripts like the one for Falcon use the >>download.xml files, so I think that would mean that folks would have to >>download aether or the install script has to download it and warn folks >>it has a different license. Does aether also require any downloading of >>Maven jars? >> >>Is the main issue with the flex-tool-api download that we just didn't >>have the URL set correctly? Once we get it right it should work >>reliably, no? If your main point is to download as many dependencies >>from maven central instead of archive.a.o, I'd be ok with changing the >>URLs we are currently using in our get tasks to point to maven central. >> >>-Alex >> >>________________________________________ >>From: Christofer Dutz [christofer.d...@c-ware.de] >>Sent: Friday, December 12, 2014 5:19 AM >>To: dev@flex.apache.org >>Subject: Proposal for cleaning up the downloading of dependencies >> >>Hi, >> >> >>I am currently unable to participate on this list the same way I was used >>to for the last months. But the project I am currently working on is >>migrating an insanely large and complex Ant build to maven. For this we >>are implementing several steps. One I think could really be benefitial to >>the Flex project. >> >> >>Currently we download third party libs using "get" (See other problem >>thread in paralell). A lot of projects in the Ant world use Ivy for this. >>But still with Ivy we were having great problems. I managed to switch my >>customers build to using Aether-Ant-Tasks and to use Aether (The part of >>Maven for downloading and dependency resolution and deployment) for >>resolving the dependencies. >> >> >>Currently I have added one pom.xml to each module, in which I define the >>dependencies of that module using normal Maven dependencies. In the ant >>build all I have to do, is to call the "aether:resolve" task to resolve >>all the dependencies defined in the pom.xml I pass in as an argument. >>Then all is downloaded correctly and copied to a lib-directory that I >>specify. >> >> >>If we were to adapt this pattern (I be we can't for all deps - such as >>playerglobal, but for most of them). As a result we would make sure the >>build uses artifacts that maven would too, we wouldn't have to rely that >>much on maintaining a large set of external sites and we would get maven >>artifacts almost for free. >> >> >>What do you think? I'm not talking about switching to Maven, just to use >>pars of maven for handling the downloading of most of the artifacts we >>rely on. >> >> >>Chris >
