El mié, 15-04-2009 a las 15:57 +0200, Chris Chabot escribió: > On Wed, Apr 15, 2009 at 3:28 PM, Vincent Siveton > <vincent.sive...@gmail.com>wrote: > > > 2009/4/15 Chris Chabot <chab...@google.com>: > > >> I spoke yesterday with Chris about the make-release.sh: this script > > >> won't work on my ubuntu box :( > > > > > > > > > Vincent I thought the fix was simple enough: > > > > Yes yes the fix was working perfectly :) > > > > > Saying that "it won't work on ubuntu" is a slight over-exaggeration in my > > > opinion :) > > > > Sorry if I offend you, my point was that the out-of-box script needs > > to be changed depending the platform used for the compilation. > > > > No worries, no offense of any kind is involved! I'm merely trying to say > that a sh shell is by far more pervasive then a java & maven combo, perhaps > I should've framed that differently :) > > The problem is that 'bash' isn't defined by the FHS (Filesystem Hierarchy > Standard) on linux, the solution is to, instead of depending on a fixed path > (#!/bin/bash), I should either a) change it to #!`which bash`, which will > expand to the location of bash, or b) change the script to use #!/bin/sh, > which is present on pretty much any *nix platform we care about (*bsd, > linux, mac, solaris, etc); So I'm likely to pick option b here. >
In my ubuntu boxes bash is in /bin/bash, as it should. :) I'm not sure what the problem was. If it was the ubuntu-server flavor, it is quite minimalistic as it installs (not even python, for instance), so it might have been missing bash, and having other shell. > However sh will be installed on pretty much anywhere (except for win, who'd > have to install cygwin) and the same can't be said for java and maven, which > won't be present on most of the boxes that will be running php-shindig.... > after all, if they had a complete java stack and maven installed that would > imply their likely a java shop and they would thus more likely be using > java-shindig :) > ubuntu needs frequently wiping of the java packages and install of the sun jdk for some applications to run correctly, in my experience. I lost some time fighting against openjdk and icedtea recently to be forced to install sun-java6-jdk finally to run some legacy java apps. Regards Santiago > > > > (i did make a mental note I should probably use /bin/sh though since > > > according to the FHS that should always be available, but i'll have to > > > validate that the script works the same on sh first before i can switch > > that > > > over) > > > > > > Using Maven will be more platform independent, but Chris underlines me > > >> that the Maven assembly generates a different layout than the > > >> make-release.sh. > > >> So I modified the Maven files in r765148 to be align with this script. > > >> > > >> @Chris, could you review the generated and confirm that it is the wanted > > >> layout? > > >> > > > > > > > > > I also commented that I think this is a "When you have a hammer, > > everything > > > looks like a nail" type of solution. > > > > > > Most people who use PHP probably won't have a lot of java and maven > > > knowledge, and are even likely not to even have a working java binary > > > installed, let alone feeling like installing maven and downloading many > > Mb's > > > of dependencies and we really shouldn't force that down people's throats, > > > not if those tens of megabytes, and different-environment dependencies > > are > > > just to solve something that can also be done with 20 lines of shell > > script. > > > That just sounds like a solution looking for a problem :) > > > > > > Keep in mind that this script could be used to create a > > release-type-layout > > > of the directory structure and configuration files by anyone who uses > > > php-shindig, so the usage of it is far wider then just once to generate a > > > release tarbal, as such the whole java / mvn dep could only be worth it > > from > > > a php perspective if it offered significant benefits over shell script > > (or > > > even php based) one.. > > > > I guess only Shindig devs could use this script to make a release and > > (I hope) everybody here has a minimum knowledge of java/maven :) > > If someone want to make a fork of PHP Shindig, he will probably create > > its own script to make its release. > > > > The script file works perfectly but it is platform dependent which is > > IMHO bad. > > > I can't agree with that argumentation. the sh shell is part of *every* unix > like instalation, where as maven is something people will have to download > the correct latest version of and install by hand; The statement that a > shell script using sh is platform dependent goes against decades of history > (sh has been a standard part and default shell of most unix systems since > it's inception in 1977) > > The only thing that somehow gave you that impression is that ubuntu (and > probably debian too by extend) have their bash shell in the /usr/bin dir, > and not in /bin... thats the *only* thing, and that can very easily be fixed > by using either `which bash` or using sh instead of bash. > > The nice thing of having a standard script is that if some OSS project > includes php-shindig (which quite a few do already), they can use that > standard script to wrangle the svn checkout to a standard layout that they > can include (and without the whole java tree). Depending on java + maven is > as un-natural to them as using a PHP tool for java packaging would be :) > > > > > We need 2 release managers to create artifacts, and I dont > > think it is the way to go. > > If Maven is too bigger, WDYT to use ant? It will be easy to integrate > > it in the release process. > > > I think the whole premise of using a java packaging tool for php is akin to > the hammer -> nail analogy... I see no problems with a release manager > running one shell script to create the php-shindig tar&zip archives, and I > think most everybody here would be comfortable with that, right? > > > > Do we want to centralize build under Maven, for all languages > > supported and for making release? > > > > Pros: > 1) Unified release procedure for both languages > (I'm not including 'platform independence here, since to me introducing > java+maven deps into the php world is a much bigger restriction then > depending on the sh shell) > > Cons: > 1) Unmaintainable by the php dev's > 2) Un-usable for 3rd party projects who don't have java/maven/etc but want > to do svn snapshots > 3) Using an overly complex solution for something that has a simple solution > available already > > So far based on the above +/- list my preference so far is to use the shell > script
