Re: AW: Those @#*$^ Environment Variables

2015-11-16 Thread Alex Harui
On 11/16/15, 1:30 AM, "Christofer Dutz" wrote: > >2. The Problem with a dual approach of ANT and Maven is that Maven uses >convention over configuration, this means that it is possible to setup a >maven build for the current project structure, but it's quite a >configuration effort. If however w

RE: Those @#*$^ Environment Variables

2015-11-16 Thread Kessler CTR Mark J
Alex Harui [mailto:aha...@adobe.com] Sent: Monday, November 16, 2015 1:45 PM To: dev@flex.apache.org Subject: Re: Those @#*$^ Environment Variables On 11/16/15, 9:36 AM, "Kessler CTR Mark J" wrote: >Well for one of my dev machines, we've removed all the source, build >file

Re: Those @#*$^ Environment Variables

2015-11-16 Thread Alex Harui
On 11/16/15, 9:36 AM, "Kessler CTR Mark J" wrote: >Well for one of my dev machines, we've removed all the source, build >files, property files, samples, and templates out of the folders. >Multiple SDK's stored in a shared parent folder. The sdk folders are >labeled things like "Flex 4.14.1

RE: Those @#*$^ Environment Variables

2015-11-16 Thread Kessler CTR Mark J
the RSLs and also affect our shared modules in use. -Mark -Original Message- From: Alex Harui [mailto:aha...@adobe.com] Sent: Monday, November 16, 2015 11:14 AM To: dev@flex.apache.org Subject: Re: Those @#*$^ Environment Variables On 11/16/15, 5:23 AM, "Kessler CTR Mark J" w

Re: Those @#*$^ Environment Variables

2015-11-16 Thread Alex Harui
On 11/16/15, 5:23 AM, "Kessler CTR Mark J" wrote: > >One my ideas for improvement would be to change the way we do binary >packages. The strip out everything from the binary package except the >bare bones of what is required. So just keep it the libraries, asdocs, >licenses, notices and su

RE: Those @#*$^ Environment Variables

2015-11-16 Thread Kessler CTR Mark J
I use the environmental variables. Especially when I synch sdk/air/global files between development machines. My main work development machine is on a private network. Each of my machines are setup with different paths and have slightly different environments. Using scripts to setup t

Re: Those @#*$^ Environment Variables

2015-11-16 Thread Justin Mclean
Hi, > 5. You don't "have to" take a course to use Maven ... I bet 99% of the Maven > users have never taken a course, it's just an offer from my side to help > others get up to speed. That’s 100% correct I’ve made binding votes on lots (50+?) of releases just knowing the basics. i.e. “mvn comp

Re: Those @#*$^ Environment Variables

2015-11-16 Thread Harbs
Not sure if it’s useful yet, but apparently Windows 10 has “OneGet” which is supposed to fill the same need. There’s currently Chocolatey as well. I’m not sure how either one measures up. Some more reading:[3] [1]https://github.com/oneget/oneget [2]https://chocolatey.org/ [3]http://www.hanselman

AW: Those @#*$^ Environment Variables

2015-11-16 Thread Christofer Dutz
uot; take a course to use Maven ... I bet 99% of the Maven users have never taken a course, it's just an offer from my side to help others get up to speed. Chris Von: omup...@gmail.com im Auftrag von OmPrakash Muppirala Gesendet: Montag, 16. Novem

Re: Those @#*$^ Environment Variables

2015-11-16 Thread OmPrakash Muppirala
Ah okay. PC guy here :-) On Mon, Nov 16, 2015 at 1:05 AM, Harbs wrote: > “brew” is the command for Homebrew which is a Mac package manager similar > to apt-get on Linux. The other popular one is MacPorts. I have both > installed, but I tend to use Homebrew. > > Here’s some interesting reading o

Re: Those @#*$^ Environment Variables

2015-11-16 Thread Harbs
“brew” is the command for Homebrew which is a Mac package manager similar to apt-get on Linux. The other popular one is MacPorts. I have both installed, but I tend to use Homebrew. Here’s some interesting reading on them.[1] Homebrew has had recipes for every package I’ve needed. [1]http://app

Re: Those @#*$^ Environment Variables

2015-11-16 Thread Justin Mclean
Hi, > Do you see any conflicts with ASF policy if our Maven scripts bring down > Adobe artifacts? No issues there I believe. If they not bundled then we’re not distributing them so there's no issue. It’s more to do with Adobe policy rather than Apache. > Apparently, I don’t have brew installed.

Re: Those @#*$^ Environment Variables

2015-11-15 Thread OmPrakash Muppirala
On Sun, Nov 15, 2015 at 11:22 PM, Alex Harui wrote: > Instead of replying individually to all of these posts, let me see if I > can summarize my thoughts here: > > For sure, we should try Maven. I think the main questions, since there’s > been so much emphasis lately on making it easier for new

Re: Those @#*$^ Environment Variables

2015-11-15 Thread Alex Harui
Instead of replying individually to all of these posts, let me see if I can summarize my thoughts here: For sure, we should try Maven. I think the main questions, since there’s been so much emphasis lately on making it easier for new contributors to contribute are: 1) I think it will take weeks

Re: Those @#*$^ Environment Variables

2015-11-15 Thread Justin Mclean
Hi, > I could ask my boss, if I could give such a course ... probably as a remote > course (But If you're somewhere near Frankfurt, we could eventually have some > offline-attendants). Timezones permitting I’ll be up for that. Justin

Re: Those @#*$^ Environment Variables

2015-11-15 Thread Justin Mclean
Hi, > Similarly, we could have Maven binaries packaged with the src and binary > releases. This eliminates the need for sdk devs and end users to have > maven installed. We could add that to the binary release but not the source release, you can’t have jars in a source release. Previous vers

Re: AW: Those @#*$^ Environment Variables

2015-11-15 Thread OmPrakash Muppirala
ve some offline-attendants). > > Probably instead of having 2-2 full days, we could do a set of 4-6 > evenings (in europe) or mornings (in the us) > > Chris > > > > -Ursprüngliche Nachricht- > Von: Harbs [mailto:harbs.li...@gmail.com] > Gesendet: Sonntag, 15.

AW: Those @#*$^ Environment Variables

2015-11-15 Thread Christofer Dutz
13:46 An: dev@flex.apache.org Betreff: Re: Those @#*$^ Environment Variables I think I'm in the "let's try Maven" camp as well. I think it's safe to say that ant is not a clear good fit. Yes. It works, but a lot of us have had trouble with it. Like Om, I don't see

Re: Those @#*$^ Environment Variables

2015-11-15 Thread Harbs
I think I’m in the “let’s try Maven” camp as well. I think it’s safe to say that ant is not a clear good fit. Yes. It works, but a lot of us have had trouble with it. Like Om, I don’t see a difference between requiring ant and requiring maven. The one time I did try Maven to build something, it

AW: Those @#*$^ Environment Variables

2015-11-14 Thread Christofer Dutz
want without requiring us to setup all sorts of "Those @#*$^ Environment Variables" (Especially on CI environments) Yeah ... I know ... that's a lot of work, but hey ... you want to stick to Ant ... Maven automates a lot of the stuff you want to ensure. I guess noone ever check

Re: Those @#*$^ Environment Variables

2015-11-13 Thread OmPrakash Muppirala
After reading your email, I am more convinced that Maven is the way to go. Sure we can use any other tool or build our own, but I don't see why. Maven seems to be a very good fit. There is a common misconception that Maven is just a build tool. It is in fact a project management tool + a build t

Those @#*$^ Environment Variables

2015-11-13 Thread Alex Harui
Hi, Folks are still getting tripped up trying to get prerequisite build tools set up and ready to go. Let’s use this thread to figure out a better solution. I know Chris is going to say “Maven” and I support that, but I still think we can’t require everyone to go to Maven. Some history: There