Re: [jetty-dev] lobby of setuid support

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

I think it got lost in the move to eclipse and when it was resurrected
it came from the one before my refactor of the build.

1) should be no changes to the source, however if per OS changes are
required then we can pull the source bundle and then apply a patch if
needed...and those changes are clearly localized to that artifact

2) i suspect it would be fine though we might need to be better about
doing this for different operating systems..

as it stands if I release from macosx we are publishing that to maven
central as jetty setuid support...if you look through many of the past
setuid releases there is a mixture of linux binaries and macosx
binaries under the same artifact...that was what my refactor of the
build was to avoid at the time

jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx



On Tue, Apr 13, 2010 at 09:59, Jan Bartel <janb@xxxxxxxxxxx> wrote:
> In principle I don't mind if we switch back to the way it was before.
> In fact I can't even recall the exact reasons why it was refactored?
>
> But I have 2 questions:
>
> 1. Does changing the name of the artifact that is produced require
>  any code changes (see SetUID.java code that searches for the library,
>  including by name)?
>
> 2. Does this have any impact on other distros that want to consume the .so?
>  For example, Hightide has a <profile> (which is the default) that picks
>  up the .so file. Any difficulties there?
>
> cheers
> Jan
>
> Jesse McConnell wrote:
>>
>> 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
>> _______________________________________________
>> jetty-dev mailing list
>> jetty-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>
> --
> Jan Bartel, Webtide LLC | janb@xxxxxxxxxxx | http://www.webtide.com
> _______________________________________________
> jetty-dev mailing list
> jetty-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>