New eclass osgi.eclass
 

On behalf of Elvanor ( a in the process New Developer ) I would like to
present the osgi.eclass.

What is OSGi, well....

Copied directly from wikipedia [1]

"The Framework implements a complete and dynamic component model,
something that is missing in standalone Java/VM environments.
Applications or components (coming in the form of bundles for
deployment) can be remotely installed, started, stopped, updated and
uninstalled without requiring a reboot; management of Java
packages/classes is specified in great detail. Life cycle management is
done via APIs which allow for remote downloading of management policies.
The service registry allows bundles to detect the addition of new
services, or the removal of services, and adapt accordingly."

Basically and for all the purposes that you will care about, the eclass
adds information to a jar's Manifest file that can then be used by the
OSGi framework ( aka currently eclipse ). Without this functionality we
will not be able to use system jars for our eclipse package.

you may find an example ebuild that uses the osgi class at
http://overlays.gentoo.org/svn/proj/java/java-experimental/dev-java/swt/swt-3.3-r1.ebuild

and the eclass is attached and located at
http://overlays.gentoo.org/svn/proj/java/java-experimental/eclass/osgi.eclass

Im sure Elvanor can't wait for you constructive feedback on his eclass
and depending on your feedback the eclass will enter the tree this weekend.

ali_bush


[1] http://en.wikipedia.org/wiki/OSGi
# Base eclass for Java packages that needs to be OSGi compliant
#
# Copyright (c) 2007, Jean-Noël Rivasseau <elvanor@gmail.com>
# Copyright (c) 2007, Gentoo Foundation
#
# Licensed under the GNU General Public License, v2
#
# $Header: /var/cvsroot/gentoo-x86/eclass/java-utils-2.eclass,v 1.92 2007/08/05 08:17:05 betelgeuse Exp $

# -----------------------------------------------------------------------------
# @eclass-begin
# @eclass-shortdesc Java OSGi eclass
# @eclass-maintainer java@gentoo.org
#
# This eclass provides functionality which is used by
# packages that need to be OSGi compliant. This means
# that the generated jars will have special headers in their manifests.
# Currently this is used only by Eclipse-3.3 - later
# we could extend this so that Gentoo Java system would be
# fully OSGi compliant.
#
# -----------------------------------------------------------------------------

inherit java-utils-2

# We define _OSGI_T so that it does not contain a slash at the end.
# According to Paludis guys, there is currently a proposal for EAPIs that
# would require all variables to end with a slash.

_OSGI_T="${T/%//}"

# -----------------------------------------------------------------------------
# @ebuild-function _java-pkg_osgi-plugin
#
# This is an internal function, not to be called directly.
#
# @example
# _java-pkg_osgi-plugin "JSch"
#
# @param $1 - bundle name
#
# ------------------------------------------------------------------------------

_java-pkg_osgi-plugin() {
# We hardcode Gentoo as the vendor name

cat > "${_OSGI_T}/tmp_jar/plugin.properties" <<-EOF
bundleName=${1}
vendorName=Gentoo
EOF
}

# -----------------------------------------------------------------------------
# @ebuild-function _java-pkg_osgijar
#
# This is an internal function, not to be called directly.
#
# @example
# _java-pkg_osgijar "dist/${PN}.jar" "com.jcraft.jsch" "com.jcraft.jsch, com.jcraft.jsch.jce;x-internal:=true" "JSch"
#
# @param $1 - name of jar to repackage with OSGi
# @param $2 - bundle symbolic name
# @param $3 - export-package-header
# @param $4 - bundle name
#
# ------------------------------------------------------------------------------

_java-pkg_osgijar() {
debug-print-function ${FUNCNAME} $*
[[ ${#} -lt 4 ]] && die "At least four arguments needed"

mkdir "${_OSGI_T}/tmp_jar" || die "Unable to create directory ${_OSGI_T}/tmp_jar"
[[ -d "${_OSGI_T}/osgi" ]] || mkdir "${_OSGI_T}/osgi" || die "Unable to create directory ${_OSGI_T}/osgi"

local jar_name="$(basename $1)"
cp "$1" "${_OSGI_T}/tmp_jar" && pushd "${_OSGI_T}/tmp_jar" > /dev/null
jar xf "${jar_name}" && rm "${jar_name}" && popd > /dev/null || die "Unable to uncompress correctly the original jar"

cat > "${_OSGI_T}/tmp_jar/META-INF/MANIFEST.MF" <<-EOF
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: %bundleName
Bundle-Vendor: %vendorName
Bundle-Localization: plugin
Bundle-SymbolicName: ${2}
Bundle-Version: ${PV}
Export-Package: ${3}
EOF

_java-pkg_osgi-plugin ${4}

jar cfm "${_OSGI_T}/osgi/${jar_name}" "${_OSGI_T}/tmp_jar/META-INF/MANIFEST.MF"
-C "${_OSGI_T}/tmp_jar/" . > /dev/null || die "Unable to recreate the OSGi compliant jar"
rm -rf "${_OSGI_T}/tmp_jar"
}

# -----------------------------------------------------------------------------
# @ebuild-function java-pkg_doosgijar
#
# Rewrites a jar, and produce an OSGi compliant jar from arguments given on the command line.
# The arguments given correspond to the minimal set of headers
# that must be present on a Manifest file of an OSGi package.
# If you need more headers, you should use the *-fromfile functions below,
# that create the Manifest from a file.
# It will call java-pkg_dojar at the end.
#
# @example
# java-pkg_doosgijar "dist/${PN}.jar" "com.jcraft.jsch" "com.jcraft.jsch, com.jcraft.jsch.jce;x-internal:=true" "JSch"
#
# @param $1 - name of jar to repackage with OSGi
# @param $2 - bundle symbolic name
# @param $3 - export-package-header
# @param $4 - bundle name
#
# ------------------------------------------------------------------------------

java-pkg_doosgijar() {
debug-print-function ${FUNCNAME} $*
local jar_name="$(basename $1)"
_java-pkg_osgijar "$@"
java-pkg_dojar "${_OSGI_T}/osgi/${jar_name}"
}

# -----------------------------------------------------------------------------
# @ebuild-function java-pkg_newosgijar
#
# Rewrites a jar, and produce an OSGi compliant jar.
# The arguments given correspond to the minimal set of headers
# that must be present on a Manifest file of an OSGi package.
# If you need more headers, you should use the *-fromfile functions below,
# that create the Manifest from a file.
# It will call java-pkg_newjar at the end.
#
# @example
# java-pkg_newosgijar "dist/${PN}.jar" "com.jcraft.jsch" "com.jcraft.jsch, com.jcraft.jsch.jce;x-internal:=true" "JSch"
#
# @param $1 - name of jar to repackage with OSGi
# @param $2 (optional) - name of the target jar. It will default to package name if not specified.
# @param $3 - bundle symbolic name
# @param $4 - export-package-header
# @param $5 - bundle name
#
# ------------------------------------------------------------------------------

java-pkg_newosgijar() {
debug-print-function ${FUNCNAME} $*
local jar_name="$(basename $1)"

if [[ ${#} > 4 ]]; then
local newName="$2"
local arguments=("$@")
unset arguments[1]
_java-pkg_osgijar "${arguments[@]}"
java-pkg_newjar "${_OSGI_T}/osgi/${jar_name}" "${newName}"
else
_java-pkg_osgijar "$@"
java-pkg_newjar "${_OSGI_T}/osgi/${jar_name}"
fi
}

# -----------------------------------------------------------------------------
# @ebuild-function _java-pkg_osgijar-fromfile
#
# This is an internal function, not to be called directly.
#
# @example
# _java-pkg_osgijar-fromfile "dist/${PN}.jar" "${FILESDIR}/MANIFEST.MF" "JSch" --noversion
#
# @param $1 - name of jar to repackage with OSGi
# @param $2 - path to the Manifest file
# @param $3 - bundle name
# --noversion This option disables automatic rewriting of the version in the Manifest file
#
# ------------------------------------------------------------------------------

_java-pkg_osgijar-fromfile() {
debug-print-function ${FUNCNAME} $*
local counter=0
local noversion=0

while [[ -n "${1}" ]]; do
if [[ "${1}" == "--noversion" ]]; then
noversion=1
else
arguments[${counter}]="${1}"
((++counter))
fi
shift 1
done

((${#arguments[@]} < 3)) && die "At least three arguments (not counting --noversion) are needed for java-pkg_osgijar-fromfile()"

mkdir "${_OSGI_T}/tmp_jar" || die "Unable to create directory ${_OSGI_T}/tmp_jar"
[[ -d "${_OSGI_T}/osgi" ]] || mkdir "${_OSGI_T}/osgi" || die "Unable to create directory ${_OSGI_T}/osgi"

local jar_name="$(basename ${arguments[0]})"
cp "${arguments[0]}" "${_OSGI_T}/tmp_jar" && pushd "${_OSGI_T}/tmp_jar" > /dev/null
jar xf "${jar_name}" && rm "${jar_name}" && popd > /dev/null || die "Unable to uncompress correctly the original jar"

# We automatically change the version unless --noversion is present

[[ -e "${arguments[1]}" ]] || die "Manifest file ${arguments[1]} not found"

if [[ "${noversion}" == 1 ]]; then
cat "${arguments[1]}" > "${_OSGI_T}/tmp_jar/META-INF/MANIFEST.MF"
else
cat "${arguments[1]}" | sed "s/Bundle-Version:.*/Bundle-Version: ${PV}/" >
"${_OSGI_T}/tmp_jar/META-INF/MANIFEST.MF"
fi

_java-pkg_osgi-plugin "${arguments[2]}"

jar cfm "${_OSGI_T}/osgi/${jar_name}" "${_OSGI_T}/tmp_jar/META-INF/MANIFEST.MF"
-C "${_OSGI_T}/tmp_jar/" . > /dev/null || die "Unable to recreate the OSGi compliant jar"
rm -rf "${_OSGI_T}/tmp_jar"
}

# -----------------------------------------------------------------------------
# @ebuild-function java-pkg_newosgijar-fromfile()
#
# This function produces an OSGi compliant jar from a given manifest file.
# The Manifest Bundle-Version header will be replaced by the current version
# of the package, unless the --noversion argument is given.
# It will call java-pkg_newjar at the end.
#
# @example
# java-pkg_newosgijar "dist/${PN}.jar" "${FILESDIR}/MANIFEST.MF" "Standard Widget Toolkit for GTK 2.0"
#
# @param $1 - name of jar to repackage with OSGi
# @param $2 (optional) - name of the target jar. It will default to package name if not specified.
# @param $3 - path to the Manifest file
# @param $4 - bundle name
# --noversion This option disables automatic rewriting of the version in the Manifest file
#
# ------------------------------------------------------------------------------

java-pkg_newosgijar-fromfile() {
debug-print-function ${FUNCNAME} $*
local jar_name="$(basename $1)"
if [[ ${#} > 3 ]]; then
local newName="$2"
local arguments=("$@")
unset arguments[1]
_java-pkg_osgijar-fromfile "${arguments[@]}"
java-pkg_newjar "${_OSGI_T}/osgi/${jar_name}" "${newName}"
else
_java-pkg_osgijar-fromfile "$@"
java-pkg_newjar "${_OSGI_T}/osgi/${jar_name}"
fi
}

# -----------------------------------------------------------------------------
# @ebuild-function java-pkg_doosgijar-fromfile()
#
# This function produces an OSGi compliant jar from a given manifestfile.
# The Manifest Bundle-Version header will be replaced by the current version
# of the package, unless the --noversion argument is given.
# It will call java-pkg_dojar at the end.
#
# @example
# java-pkg_doosgijar "dist/${PN}.jar" "${FILESDIR}/MANIFEST.MF" "Standard Widget Toolkit for GTK 2.0"
#
# @param $1 - name of jar to repackage with OSGi
# @param $2 - path to the Manifest file
# @param $3 - bundle name
# --noversion This option disables automatic rewriting of the version in the Manifest file
#
# ------------------------------------------------------------------------------

java-pkg_doosgijar-fromfile() {
debug-print-function ${FUNCNAME} $*
local jar_name="$(basename $1)"
_java-pkg_osgijar-fromfile "$@"
java-pkg_dojar "${_OSGI_T}/osgi/${jar_name}"
}

New eclass osgi.eclass
 

On 22:26 Wed 05 Dec , Alistair Bush wrote:
> # @ebuild-function _java-pkg_osgi-plugin

I just picked this one at random, although my question applies to the
whole eclass. Why is everything tagged with a "java-pkg_" prefix?

Thanks,
Donnie
--
gentoo-dev@gentoo.org mailing list

New eclass osgi.eclass
 

Donnie Berkholz kirjoitti:
> On 22:26 Wed 05 Dec , Alistair Bush wrote:
>> # @ebuild-function _java-pkg_osgi-plugin
>
> I just picked this one at random, although my question applies to the
> whole eclass. Why is everything tagged with a "java-pkg_" prefix?
>
> Thanks,
> Donnie

Probably used the same prefix as the traditional java stuff but yes
these should use the osgi prefix. I was also thinking whether we should
be naming this java-osgi as we already have java-ant instead of ant etc.

Regards,
Petteri

Regards,
Petteri

New eclass osgi.eclass
 

Alistair Bush wrote:
> Im sure Elvanor can't wait for you constructive feedback on his eclass
> and depending on your feedback the eclass will enter the tree this
> weekend.
>
A couple of very minor performance points, which I think are more
significant in eclasses. Firstly the basename thing Donnie pointed out
before:
> > local feedfile=$(basename "${src}")
> You could do this in pure bash, although it doesn't really matter:
> local feedfile=${src##*/}

[[ ${#} -lt 4 ]] && die "At least four arguments needed"
Arithmetic context is quicker for this:
(($#<4)) && die "At least four arguments needed"
although in this case, _java-pkg_osgijar(), it looks it requires exactly 4:
(($#==4)) || die 'Four arguments needed'

You have a couple of functions that take, say, 4 or 5 arguments. It would be
more robust to use a case, eg:
case $# in
5)..;;
4)..;;
*) die "Incorrect use of $FUNCNAME";;
esac
..than if (($#>4)); then ..; else .. ;fi

_java-pkg_osgi-plugin ${4} # this should be quoted (_java-pkg_osgijar)

With regard to:
debug-print-function ${FUNCNAME} $*
if you want debug-print-function to get the arguments correctly, use "$@"
not $* (cf 'Special Parameters' in man bash for a proper explanation: this
applies to all arrays. http://wooledge.org/mywiki/BashFAQ/073 shows how to
manipulate all members of an array, eg to add a prefix.)

This use of counter in _java-pkg_osgijar-fromfile is odd:
while [[ -n "${1}" ]]; do
# while [[ $1 ]] or while (($#)) also work
if [[ "${1}" == "--noversion" ]]; then
noversion=1
else
arguments[${counter}]="${1}"
((++counter))
fi
shift 1 # just shift?
done

((${#arguments[@]} < 3)) && die "At least three arguments (not
counting --noversion) are needed for java-pkg_osgijar-fromfile()"

You can either just add to the array with: arguments+=("$1")
or add using the counter: arguments[counter++]="$1"
and then check: ((counter < 3)) && die ..

Arithmetic context[1] applies in array indexes, so you don't need to use a $
for variables and you can post/pre-incr etc there.
Yuu can also use it for C-style flags, with 0 as false and non-zero true:
if [[ "${noversion}" == 1 ]];
can be
if ((noversion));

This is handy since unset variables evaluate as zero, which is false inside
((..)), so a simple flag=1 is all that's needed, ie you don't have to set a
default, although ofc it's more robust to do so, especially for functions.
declare -i flag=0 # makes a local var which can only have integer values
assigned (setting it to string typically evaluates to zero; arithmetic
context is used for all assignments, so a string which happens to be a
variable with an integer will return that value.)

[1] http://wooledge.org/mywiki/ArithmeticExpression


--
gentoo-dev@gentoo.org mailing list

New eclass osgi.eclass
 

Steve Long kirjoitti:
> Alistair Bush wrote:
>> Im sure Elvanor can't wait for you constructive feedback on his eclass
>> and depending on your feedback the eclass will enter the tree this
>> weekend.
>>
> A couple of very minor performance points, which I think are more
> significant in eclasses. Firstly the basename thing Donnie pointed out
> before:

Well usually you don't noticy any differences. In global scope things
could have some effect of course.

>
> You have a couple of functions that take, say, 4 or 5 arguments. It would be
> more robust to use a case, eg:
> case $# in
> 5)..;;
> 4)..;;
> *) die "Incorrect use of $FUNCNAME";;
> esac
> ..than if (($#>4)); then ..; else .. ;fi
>

Well imho they are equivalent and eclass maintainers should go with what
they prefer.

>
> With regard to:
> debug-print-function ${FUNCNAME} $*
> if you want debug-print-function to get the arguments correctly, use "$@"
> not $* (cf 'Special Parameters' in man bash for a proper explanation: this
> applies to all arrays. http://wooledge.org/mywiki/BashFAQ/073 shows how to
> manipulate all members of an array, eg to add a prefix.)

Doesn't matter as arguments are just written to a file and for some
reason this form is used all over the base in eclasses but shouldn't
hurt to use "${@}" with new code.

>
> This use of counter in _java-pkg_osgijar-fromfile is odd:
> while [[ -n "${1}" ]]; do
> # while [[ $1 ]] or while (($#)) also work
> if [[ "${1}" == "--noversion" ]]; then
> noversion=1
> else
> arguments[${counter}]="${1}"
> ((++counter))
> fi
> shift 1 # just shift?
> done
>
> ((${#arguments[@]} < 3)) && die "At least three arguments (not
> counting --noversion) are needed for java-pkg_osgijar-fromfile()"
>
> You can either just add to the array with: arguments+=("$1")
> or add using the counter: arguments[counter++]="$1"
> and then check: ((counter < 3)) && die ..
>
> Arithmetic context[1] applies in array indexes, so you don't need to use a $
> for variables and you can post/pre-incr etc there.
> Yuu can also use it for C-style flags, with 0 as false and non-zero true:
> if [[ "${noversion}" == 1 ]];
> can be
> if ((noversion));
>
> This is handy since unset variables evaluate as zero, which is false inside
> ((..)), so a simple flag=1 is all that's needed, ie you don't have to set a
> default, although ofc it's more robust to do so, especially for functions.
> declare -i flag=0 # makes a local var which can only have integer values
> assigned (setting it to string typically evaluates to zero; arithmetic
> context is used for all assignments, so a string which happens to be a
> variable with an integer will return that value.)
>
> [1] http://wooledge.org/mywiki/ArithmeticExpression
>

We really don't need to create the arguments array at all. We could just
check if ${1} is --noversion and then use shift. After that we can use
the positional arguments as usual so instead of ${arguments[0]} we can
use just ${1}.

Regards,
Petteri

New eclass osgi.eclass
 

Thanks all for this feedback. I think this is sufficient to warrant
some modifications as suggested, and I propose to postpone the
inclusion in tree a little bit.

Regarding performance, there is an important point to note as IMHO it
is much more penalizing than using basename or such.

The fact that I use the jar utility to unzip a file, combined with the
fact that jar does not have an option to specify a destination
directory, is troublesome. I have to copy the .jar file to the
destination directory and then remove it. This .jar file can be
several MBs of course.

Initially I was using zip but I replaced it with jar in order to avoid
a dependency on zip. But maybe it's not worth the performance penalty.

Regards,

Elvanör


On Dec 6, 2007 1:11 PM, Petteri Räty <betelgeuse@gentoo.org> wrote:
> Steve Long kirjoitti:
> > Alistair Bush wrote:
> >> Im sure Elvanor can't wait for you constructive feedback on his eclass
> >> and depending on your feedback the eclass will enter the tree this
> >> weekend.
> >>
> > A couple of very minor performance points, which I think are more
> > significant in eclasses. Firstly the basename thing Donnie pointed out
> > before:
>
> Well usually you don't noticy any differences. In global scope things
> could have some effect of course.
>
> >
> > You have a couple of functions that take, say, 4 or 5 arguments. It would be
> > more robust to use a case, eg:
> > case $# in
> > 5)..;;
> > 4)..;;
> > *) die "Incorrect use of $FUNCNAME";;
> > esac
> > ..than if (($#>4)); then ..; else .. ;fi
> >
>
> Well imho they are equivalent and eclass maintainers should go with what
> they prefer.
>
> >
> > With regard to:
> > debug-print-function ${FUNCNAME} $*
> > if you want debug-print-function to get the arguments correctly, use "$@"
> > not $* (cf 'Special Parameters' in man bash for a proper explanation: this
> > applies to all arrays. http://wooledge.org/mywiki/BashFAQ/073 shows how to
> > manipulate all members of an array, eg to add a prefix.)
>
> Doesn't matter as arguments are just written to a file and for some
> reason this form is used all over the base in eclasses but shouldn't
> hurt to use "${@}" with new code.
>
>
> >
> > This use of counter in _java-pkg_osgijar-fromfile is odd:
> > while [[ -n "${1}" ]]; do
> > # while [[ $1 ]] or while (($#)) also work
> > if [[ "${1}" == "--noversion" ]]; then
> > noversion=1
> > else
> > arguments[${counter}]="${1}"
> > ((++counter))
> > fi
> > shift 1 # just shift?
> > done
> >
> > ((${#arguments[@]} < 3)) && die "At least three arguments (not
> > counting --noversion) are needed for java-pkg_osgijar-fromfile()"
> >
> > You can either just add to the array with: arguments+=("$1")
> > or add using the counter: arguments[counter++]="$1"
> > and then check: ((counter < 3)) && die ..
> >
> > Arithmetic context[1] applies in array indexes, so you don't need to use a $
> > for variables and you can post/pre-incr etc there.
> > Yuu can also use it for C-style flags, with 0 as false and non-zero true:
> > if [[ "${noversion}" == 1 ]];
> > can be
> > if ((noversion));
> >
> > This is handy since unset variables evaluate as zero, which is false inside
> > ((..)), so a simple flag=1 is all that's needed, ie you don't have to set a
> > default, although ofc it's more robust to do so, especially for functions.
> > declare -i flag=0 # makes a local var which can only have integer values
> > assigned (setting it to string typically evaluates to zero; arithmetic
> > context is used for all assignments, so a string which happens to be a
> > variable with an integer will return that value.)
> >
> > [1] http://wooledge.org/mywiki/ArithmeticExpression
> >
>
> We really don't need to create the arguments array at all. We could just
> check if ${1} is --noversion and then use shift. After that we can use
> the positional arguments as usual so instead of ${arguments[0]} we can
> use just ${1}.
>
> Regards,
> Petteri
>
>
>
���^����(� ��X��X�

New eclass osgi.eclass
 

Jean-Noël Rivasseau kirjoitti:
>
> The fact that I use the jar utility to unzip a file, combined with the
> fact that jar does not have an option to specify a destination
> directory, is troublesome. I have to copy the .jar file to the
> destination directory and then remove it. This .jar file can be
> several MBs of course.
>

The jar utility supports writing to standard output and you can just use
normal output redirection. See man jar.

Regards,
Petteri