| [jetty-dev] lobby of setuid support |
I would like to lobby to bring back my refactor of the jetty setuid build from the jetty7 @ codehaus days. I think it was organized much easier for people and allowed for releasing of os specific setuid bundles... I'll walk through the setup by pointing to pom.xmls http://repo2.maven.org/maven2/org/mortbay/jetty/jetty-setuid-parent/7.0.0.pre5/jetty-setuid-parent-7.0.0.pre5.pom This was the top level pom, and it brought in two modules, the setuid java and the source modules...these are shared across architectures and are always in the build. Then there are a few profiles, one for each operating system that we could build setuid for that brings in a module for that build...there are no compile options or other uglies in this pom, it is totally structural and simply 'does the right thing' based on the environment your running in. http://repo2.maven.org/maven2/org/mortbay/jetty/jetty-setuid-java/7.0.0.pre5/jetty-setuid-java-7.0.0.pre5.pom http://repo2.maven.org/maven2/org/mortbay/jetty/jetty-setuid-source/7.0.0.pre5/jetty-setuid-source-7.0.0.pre5.pom These are the two default modules used by all operating systems...the source that get compiled for each OS exists in one place and each of the OS specific modules grabs it from the source artifact, lays it on disk in its project and then compiles that. http://repo2.maven.org/maven2/org/mortbay/jetty/libsetuid-linux/7.0.0pre1/libsetuid-linux-7.0.0pre1.pom http://repo2.maven.org/maven2/org/mortbay/jetty/libsetuid-macosx/7.0.0.pre5/libsetuid-macosx-7.0.0.pre5.pom These are two of the 4 or 5 possible published setuid bundles, these actually compile for the target operating system and each pom contains the particular incantations needed to build correctly on that operating system....when you run the release on a linux box then the libsetuid-linux so is produces as a part of the build and loaded up...but if you want a macosx setuid bundle published then you just need to checkout the release tag on a mac and deploy the libsetuid-macosx bundle...or sunos or whatever...no more clashing of binary types, etc..It also isolates compile options and all that mess into OS specific poms making things a lot clearer. In a nutshell, I think this setup is much more adaptable to the needs of users that use the setuid functionality and allows for anyone to easily contribute a new os support for setuid moving forward. thoughts? jesse -- jesse mcconnell jesse.mcconnell@xxxxxxxxx