public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] New eclass osgi.eclass
@ 2007-12-05  9:26 Alistair Bush
  2007-12-05 18:04 ` Donnie Berkholz
  2007-12-06  6:35 ` [gentoo-dev] " Steve Long
  0 siblings, 2 replies; 8+ messages in thread
From: Alistair Bush @ 2007-12-05  9:26 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]

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

[-- Attachment #2: osgi.eclass --]
[-- Type: text/plain, Size: 10146 bytes --]

# 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}"
}

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-dev] New eclass osgi.eclass
  2007-12-05  9:26 [gentoo-dev] New eclass osgi.eclass Alistair Bush
@ 2007-12-05 18:04 ` Donnie Berkholz
  2007-12-05 18:44   ` Petteri Räty
  2007-12-06  6:35 ` [gentoo-dev] " Steve Long
  1 sibling, 1 reply; 8+ messages in thread
From: Donnie Berkholz @ 2007-12-05 18:04 UTC (permalink / raw
  To: gentoo-dev

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



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-dev] New eclass osgi.eclass
  2007-12-05 18:04 ` Donnie Berkholz
@ 2007-12-05 18:44   ` Petteri Räty
  0 siblings, 0 replies; 8+ messages in thread
From: Petteri Räty @ 2007-12-05 18:44 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 557 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [gentoo-dev]  Re: New eclass osgi.eclass
  2007-12-05  9:26 [gentoo-dev] New eclass osgi.eclass Alistair Bush
  2007-12-05 18:04 ` Donnie Berkholz
@ 2007-12-06  6:35 ` Steve Long
  2007-12-06 12:11   ` Petteri Räty
  1 sibling, 1 reply; 8+ messages in thread
From: Steve Long @ 2007-12-06  6:35 UTC (permalink / raw
  To: gentoo-dev

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



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-dev]  Re: New eclass osgi.eclass
  2007-12-06  6:35 ` [gentoo-dev] " Steve Long
@ 2007-12-06 12:11   ` Petteri Räty
  2007-12-07 14:20     ` Jean-Noël Rivasseau
  0 siblings, 1 reply; 8+ messages in thread
From: Petteri Räty @ 2007-12-06 12:11 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 3099 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-dev] Re: New eclass osgi.eclass
  2007-12-06 12:11   ` Petteri Räty
@ 2007-12-07 14:20     ` Jean-Noël Rivasseau
  2007-12-07 16:25       ` Petteri Räty
  0 siblings, 1 reply; 8+ messages in thread
From: Jean-Noël Rivasseau @ 2007-12-07 14:20 UTC (permalink / raw
  To: gentoo-dev

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 3996 bytes --]

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
>
>
>
éí¢‡^¾\a§¶Š(®	šŠX§‚X¬

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-dev] Re: New eclass osgi.eclass
  2007-12-07 14:20     ` Jean-Noël Rivasseau
@ 2007-12-07 16:25       ` Petteri Räty
  2007-12-20 10:27         ` Jean-Noël Rivasseau
  0 siblings, 1 reply; 8+ messages in thread
From: Petteri Räty @ 2007-12-07 16:25 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 480 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [gentoo-dev] Re: New eclass osgi.eclass
  2007-12-07 16:25       ` Petteri Räty
@ 2007-12-20 10:27         ` Jean-Noël Rivasseau
  0 siblings, 0 replies; 8+ messages in thread
From: Jean-Noël Rivasseau @ 2007-12-20 10:27 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 351 bytes --]

Hello all,

I have a new version of the eclass ready, with much of the remarks
addressed. It now goes by the name java-osgi and in the new form,
should be ready to enter the tree.

I fixed the performance problem I mentionned earlier, cleaned up the
eclass API, and simplified the code almost everywhere.

Waiting for your feedback.

Cheers

Elvanör

[-- Attachment #2: java-osgi.eclass --]
[-- Type: application/octet-stream, Size: 9673 bytes --]

# 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-osgi_plugin
#
# This is an internal function, not to be called directly.
#
# @example
#	_java-osgi_plugin "JSch"
#
# @param $1 - bundle name
#
# ------------------------------------------------------------------------------

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

_java-osgi_makejar() {
	debug-print-function ${FUNCNAME} "$@"

	(( ${#} < 4 )) && die "Four arguments are needed for java-osgi_dojar-fromfile()"

	local absoluteJarPath="$(readlink -f ${1})"
	local jarName="$(basename $1)"

	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"

	cd "${_OSGI_T}/tmp_jar" && jar xf "${1}" && cd - > /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: ${4}
	EOF

	_java-osgi_plugin "${3}"

	jar cfm "${_OSGI_T}/osgi/${jarName}" "${_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-osgi_dojar
#
# 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-osgi_dojar "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 - bundle name
# @param $4 - export-package-header
#
# ------------------------------------------------------------------------------

java-osgi_dojar() {
	debug-print-function ${FUNCNAME} "$@"
	local jarName="$(basename ${1})"
	_java-osgi_makejar "$@"
	java-pkg_dojar "${_OSGI_T}/osgi/${jarName}"
}

# -----------------------------------------------------------------------------
# @ebuild-function java-osgi_newjar
#
# 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-osgi_newjar "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 - bundle name
# @param $5 - export-package header
#
# ------------------------------------------------------------------------------

java-osgi_newjar() {
	debug-print-function ${FUNCNAME} "$@"
	local jarName="$(basename $1)"

	if (( ${#} > 4 )); then
		_java-osgi_makejar "${1}" "${3}" "${4}"
		java-pkg_newjar "${_OSGI_T}/osgi/${jarName}" "${2}"
	else
		_java-osgi_makejar "$@"
		java-pkg_newjar "${_OSGI_T}/osgi/${jarName}"
	fi
}

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

_java-osgi_makejar-fromfile() {
	debug-print-function ${FUNCNAME} "$@"

	((${#} < 4)) && die "Four arguments are needed for _java-osgi_makejar-fromfile()"

	local absoluteJarPath="$(readlink -f ${1})"
	local jarName="$(basename ${1})"
	
	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"

	cd "${_OSGI_T}/tmp_jar" && jar xf "${absoluteJarPath}" && cd - > /dev/null \
		|| die "Unable to uncompress correctly the original jar"

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

	# We automatically change the version if automatic version rewriting is on
					
	if (( ${4} )); then
		cat "${2}" | sed "s/Bundle-Version:.*/Bundle-Version: ${PV}/" > \
			"${_OSGI_T}/tmp_jar/META-INF/MANIFEST.MF"
	else
		cat "${2}" > "${_OSGI_T}/tmp_jar/META-INF/MANIFEST.MF"
	fi

	_java-osgi_plugin "${3}"

	jar cfm "${_OSGI_T}/osgi/${jarName}" "${_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-osgi_newjar-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 --no-auto-version option is given.
# It will call java-pkg_newjar at the end.
#
# @example
#	java-osgi_newjar-fromfile "dist/${PN}.jar" "${FILESDIR}/MANIFEST.MF" "Standard Widget Toolkit for GTK 2.0"
#
# @param $opt
#	--no-auto-version - This option disables automatic rewriting of the 
#		version in the Manifest file#
# @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
#
# ------------------------------------------------------------------------------

java-osgi_newjar-fromfile() {
	debug-print-function ${FUNCNAME} "$@"
	local versionRewriting=1

	if [[ "${1}" == "--no-auto-version" ]]; then
		versionRewriting=0
		shift
	fi
	local jarName="$(basename ${1})"
	
	if (( ${#} > 3 )); then
		_java-osgi_makejar-fromfile "${1}" "${3}" "${4}" "${versionRewriting}"
		java-pkg_newjar "${_OSGI_T}/osgi/${jarName}" "${2}"
	else
		_java-osgi_makejar-fromfile "$@" "${versionRewriting}"
		java-pkg_newjar "${_OSGI_T}/osgi/${jarName}"
	fi
}

# -----------------------------------------------------------------------------
# @ebuild-function java-osgi_dojar-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 --no-auto-version option is given.
# It will call java-pkg_dojar at the end.
#
# @example
#	java-osgi_dojar-fromfile "dist/${PN}.jar" "${FILESDIR}/MANIFEST.MF" "Standard Widget Toolkit for GTK 2.0"
#
# @param $opt
#	--no-auto-version - This option disables automatic rewriting of the 
#		version in the Manifest file
# @param $1 - name of jar to repackage with OSGi
# @param $2 - path to the Manifest file
# @param $3 - bundle name
#
# ------------------------------------------------------------------------------

java-osgi_dojar-fromfile() {
	debug-print-function ${FUNCNAME} "$@"
	local versionRewriting=1

	if [[ "${1}" == "--no-auto-version" ]]; then
		versionRewriting=0
		shift
	fi
	local jarName="$(basename ${1})"
	
	_java-osgi_makejar-fromfile "$@" "${versionRewriting}"
	java-pkg_dojar "${_OSGI_T}/osgi/${jarName}"
}

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2007-12-20 10:34 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-12-05  9:26 [gentoo-dev] New eclass osgi.eclass Alistair Bush
2007-12-05 18:04 ` Donnie Berkholz
2007-12-05 18:44   ` Petteri Räty
2007-12-06  6:35 ` [gentoo-dev] " Steve Long
2007-12-06 12:11   ` Petteri Räty
2007-12-07 14:20     ` Jean-Noël Rivasseau
2007-12-07 16:25       ` Petteri Räty
2007-12-20 10:27         ` Jean-Noël Rivasseau

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox