Matt: > It seems that this is carelessly discarding what is being practiced at a lot > of > sites, because you'd rather do it this way. Generally speaking, we make > the Hadoop Ecosystem easier to use by adhering to familiar usage, rather > than diverging. Please give reasons for the divergence.
Roman: > Basically there are 2 types of packages on any operating system -- the > ones that try to follow the rules of the underlying OS and the ones that > strive to be cross-platform at the expense of playing nice with an underlying > system. One type typically gets installed into all the right locations from > the FHS stand point and the other ones typically have a self-contained > trees down at /opt. Both are legitimate. HADOOP-6255 is neither. As a longtime Linux administrator and Hadoop user, I feel comfortable stating that Hadoop as distributed by Apache is not packaged to conform to OS conventions. From ad hoc directory layouts to reams of inscrutable XML configuration to start/stop scripts each with slightly different semantics (is it "hdfs namenode start" or "hdfs namenode" or "hbase master start" or "hbase master" or ...) to incompatible copies of core jars littering the classpath... frankly, more like the crazy cousin from the country who moves in with city relatives and unpacks all of their stuff in the living room. This is obviously a nonbinding but enthusiastic +1 for the approach I've seen here so far. One day I hope I no longer have to ls / find / grep all over the filesystem to extract unsuspecting dev teams from JAR hell, no matter if Apache Hadoop or Apache Pig or Apache Oozie or Apache HBase (guilty of the "Apache way" too) want to continue packaging all of their dependencies whatever they were at the time of 'mvn package' this week or that. Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
