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 <[email protected]> Gesendet: Freitag, 12. Dezember 2014 17:34 An: [email protected] 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 [[email protected]] Sent: Friday, December 12, 2014 5:19 AM To: [email protected] 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
