[gentoo-java] javatoolkit: new project layout

[gentoo-java] javatoolkit: new project layout

[Alistair Bush]

This email is to garner some discussion on my new project layout for
javatoolkit.

** Background **
Currently, javatoolkit installs *.py[c] files into /usr/share this is
actually against policy.  So after looking at the current javatoolkit
project layout, which is a collection of separate sub-projects, I
decided to branch and cleanup javatoolkit.

** New Project Layout **

"Root" contains the normal collection of files (AUTHORS, CHANGELOG,
README, ETC).  There are now no sub-project equivalents of these files

There are (or will be) the following directories

src/
src/py (python files, xml-rewrite-3.py, class-version-verify.py, etc,etc)
src/py/javatoolkit (all python classes located somewhere in this module)
src/java (java source)
src/man (man pages)
test/

currently (seeing that there is only python stuff) the root directory
contains a python setup.py file to do the install work.

** Current State **

At the moment the layout is pretty much complete.  I have had to split
some files to remove their classes into separate files (to stop pyc and
pyo files being located in /usr/bin) and I have not tested those yet.
Also I have ignored the files that seem to currently play no part in a
normal install (bsfix contains 1 java file for example, tho we don't
install it).  There also seem to be some bsfix test cases, which I
haven't migrated, yet.

All old projects are located in src/obsolete so I can finish that off
latter. This will be deleted.

You can browse the repo here
http://overlays.gentoo.org/proj/java/browser/projects/javatoolkit/branches/layout_refactor_branch

and there is a svn ebuild in java-exp (not keyworded)

Anyway, anyone have any problems, ideas etc etc

Thanks

Alistair
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] javatoolkit: new project layout

[Fabian Groffen]

On 06-01-2008 01:16:16 +1300, Alistair Bush wrote:
> This email is to garner some discussion on my new project layout for
> javatoolkit.
[snip]
> You can browse the repo here
> http://overlays.gentoo.org/proj/java/browser/projects/javatoolkit/branches/layout_refactor_branch

While you're at it, would it be possible to make javatoolkit a little
bit easier for use prefix folks to maintain?  We're happily running Java
in our prefixes so any cooperation here would be greatly appreciated.

We currently apply this patch:
http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/dev-java/javatoolkit/files/0.2.0-prefix.patch
(trac is a bit picky about it, so please look at the plain text version
of it)

As you can see, Prefix is mainly concerned with shebangs (/usr/bin/env
python should work for everyone just fine), and with adding the offset
prefix in the installation paths.  I understand that not every path can
be dropped, but it would be great if the make stuff could be simplified,
by e.g. having a variable for the prefix (defaulting to /usr) such that
we could just simply only patch that one, instead of every place, as in
the patch.

Thanks,


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] javatoolkit: new project layout

[Alistair Bush]

Fabian Groffen wrote:
> On 06-01-2008 01:16:16 +1300, Alistair Bush wrote:
>> This email is to garner some discussion on my new project layout for
>> javatoolkit.
> [snip]
>> You can browse the repo here
>> http://overlays.gentoo.org/proj/java/browser/projects/javatoolkit/branches/layout_refactor_branch
> 
> While you're at it, would it be possible to make javatoolkit a little
> bit easier for use prefix folks to maintain?  We're happily running Java
> in our prefixes so any cooperation here would be greatly appreciated.
> 
> We currently apply this patch:
> http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/dev-java/javatoolkit/files/0.2.0-prefix.patch
> (trac is a bit picky about it, so please look at the plain text version
> of it)
> 
> As you can see, Prefix is mainly concerned with shebangs (/usr/bin/env
> python should work for everyone just fine), and with adding the offset
> prefix in the installation paths.  I understand that not every path can
> be dropped, but it would be great if the make stuff could be simplified,
> by e.g. having a variable for the prefix (defaulting to /usr) such that
> we could just simply only patch that one, instead of every place, as in
> the patch.
> 
> Thanks,
> 
> 

I believe (and hope) that the distutils src_install() will handle this.
 Basically setup.py has a --root="${D}" option

as in here

distutils_src_install() {

	# need this for python-2.5 + setuptools in cases where
	# a package uses distutils but does not install anything
	# in site-packages. (eg. dev-java/java-config-2.x)
	# - liquidx (14/08/2006)
	pylibdir="$(${python} -c 'from distutils.sysconfig import
get_python_lib; print get_python_lib()')"
	[ -n "${pylibdir}" ] && dodir "${pylibdir}"

	if has_version ">=dev-lang/python-2.3"; then
		${python} setup.py install --root=${D} --no-compile "$@" || die
	else
		${python} setup.py install --root=${D} "$@" || die
	fi

	DDOCS="CHANGELOG KNOWN_BUGS MAINTAINERS PKG-INFO CONTRIBUTORS TODO NEWS"
	DDOCS="${DDOCS} Change* MANIFEST* README* AUTHORS"

	for doc in ${DDOCS}; do
		[ -s "$doc" ] && dodoc $doc
	done

	[ -n "${DOCS}" ] && dodoc ${DOCS}
}


Is this acceptable?
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] javatoolkit: new project layout

[Fabian Groffen]

On 06-01-2008 10:29:29 +1300, Alistair Bush wrote:
[snip prefix cooperation question]
> I believe (and hope) that the distutils src_install() will handle this.
>  Basically setup.py has a --root="${D}" option
> 
> as in here
> 
> distutils_src_install() {
[snip]
> }
> 
> Is this acceptable?

Yes pretty much.

The distutils.eclass has already been ported to prefix, and works as far
as I'm aware.  That said, if it goes through the eclass, the
installation aspect would be fine.  Thanks a lot for that!

I see you already use /usr/bin/env python in all the python files that I
quickly checked, so that looks very promissing!

About this line:
  sys.path.insert(0, "/usr/share/javatoolkit/pym")
(found in buildparser, but I believe it's in more files)

would it be possible to do it like we do it in Portage?

 sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(os.path.  realpath(__file__))), "pym"))

that would do the "magic" for prefix as well as that it makes
development for you a bit easier maybe.

The globs in findclass I guess we'll have to patch in the prefix case,
though I'm wondering if that doesn't need ROOT support anyway?
If you'd really want to make be happy you'd do a
  try:
    from portage.const import EPREFIX
  catch ImportError:
    EPREFIX = ''

  pkg = glob.glob(EPREFIX + '/usr/share/*/package.env')


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-java@lists.gentoo.org mailing list

Re: [gentoo-java] javatoolkit: new project layout

[Petteri Räty]

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

Fabian Groffen kirjoitti:
> 
> would it be possible to do it like we do it in Portage?
> 
>  sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(os.path.  realpath(__file__))), "pym"))
> 

Or we could just depend on a new enough Portage where just import 
portage works. This probably works in prefix too?

> 
> The globs in findclass I guess we'll have to patch in the prefix case,
> though I'm wondering if that doesn't need ROOT support anyway?
> If you'd really want to make be happy you'd do a
>   try:
>     from portage.const import EPREFIX
>   catch ImportError:
>     EPREFIX = ''
> 
>   pkg = glob.glob(EPREFIX + '/usr/share/*/package.env')
> 

Well you build against the stuff in / so ROOT should not be used I think.

Regards,
Petteri


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

Re: [gentoo-java] javatoolkit: new project layout

[Fabian Groffen]

On 07-01-2008 22:29:46 +0200, Petteri Räty wrote:
> Fabian Groffen kirjoitti:
>>
>> would it be possible to do it like we do it in Portage?
>>
>>  sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(os.path.  realpath(__file__))), "pym"))
>>
>
> Or we could just depend on a new enough Portage where just import portage 
> works. This probably works in prefix too?

Well... one can only do "import portage" if one's really sure one uses a
Gentoo patched python.  (Admittedly this is in general the case.)
Portage code itself uses a guard to extend the python path in case the
import fails.

However, doing "import portage" slows you down a lot, so if you don't
really need it, I would disadvice to do it.

>> The globs in findclass I guess we'll have to patch in the prefix case,
>> though I'm wondering if that doesn't need ROOT support anyway?
>> If you'd really want to make be happy you'd do a
>>   try:
>>     from portage.const import EPREFIX
>>   catch ImportError:
>>     EPREFIX = ''
>>
>>   pkg = glob.glob(EPREFIX + '/usr/share/*/package.env')
>
> Well you build against the stuff in / so ROOT should not be used I think.

I'm not sure how much root support works in Java.  I just imagined that
you'd run the tool on a chroot or something.


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-java@lists.gentoo.org mailing list

Re: [gentoo-java] javatoolkit: new project layout

[Petteri Räty]

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

Fabian Groffen kirjoitti:
> On 07-01-2008 22:29:46 +0200, Petteri Räty wrote:
>> Fabian Groffen kirjoitti:
>>> would it be possible to do it like we do it in Portage?
>>>
>>>  sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(os.path.  realpath(__file__))), "pym"))
>>>
>> Or we could just depend on a new enough Portage where just import portage 
>> works. This probably works in prefix too?
> 
> Well... one can only do "import portage" if one's really sure one uses a
> Gentoo patched python.  (Admittedly this is in general the case.)
> Portage code itself uses a guard to extend the python path in case the
> import fails.
> 
> However, doing "import portage" slows you down a lot, so if you don't
> really need it, I would disadvice to do it.
> 
>>> The globs in findclass I guess we'll have to patch in the prefix case,
>>> though I'm wondering if that doesn't need ROOT support anyway?
>>> If you'd really want to make be happy you'd do a
>>>   try:
>>>     from portage.const import EPREFIX
>>>   catch ImportError:
>>>     EPREFIX = ''
>>>
>>>   pkg = glob.glob(EPREFIX + '/usr/share/*/package.env')
>> Well you build against the stuff in / so ROOT should not be used I think.
> 
> I'm not sure how much root support works in Java.  I just imagined that
> you'd run the tool on a chroot or something.
> 

Yeah but in chroot you would of course use /

Regards,
Petteri


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

Re: [gentoo-java] javatoolkit: new project layout

[Fabian Groffen]

On 08-01-2008 01:33:33 +0200, Petteri Räty wrote:
>> I'm not sure how much root support works in Java.  I just imagined that
>> you'd run the tool on a chroot or something.
>
> Yeah but in chroot you would of course use /

To populate your chroot from outside your chroot I meant.  It's like
having portage maintain your chroot, without it being installed in your
chroot.  Nevermind though.


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-java@lists.gentoo.org mailing list

Re: [gentoo-java] javatoolkit: new project layout

[Alistair Bush]

Fabian Groffen wrote:
> On 06-01-2008 10:29:29 +1300, Alistair Bush wrote:
> [snip prefix cooperation question]
>> I believe (and hope) that the distutils src_install() will handle this.
>>  Basically setup.py has a --root="${D}" option
>>
>> as in here
>>
>> distutils_src_install() {
> [snip]
>> }
>>
>> Is this acceptable?
> 
> Yes pretty much.
> 
> The distutils.eclass has already been ported to prefix, and works as far
> as I'm aware.  That said, if it goes through the eclass, the
> installation aspect would be fine.  Thanks a lot for that!
> 
> I see you already use /usr/bin/env python in all the python files that I
> quickly checked, so that looks very promissing!
> 
> About this line:
>   sys.path.insert(0, "/usr/share/javatoolkit/pym")
> (found in buildparser, but I believe it's in more files)
> 
> would it be possible to do it like we do it in Portage?
> 
>  sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(os.path.  realpath(__file__))), "pym"))
> 
> that would do the "magic" for prefix as well as that it makes
> development for you a bit easier maybe.
> 

How about we just remove it,  my plan was to have all modules in
site_packages, which negates this?
-- 
gentoo-java@lists.gentoo.org mailing list

Re: [gentoo-java] javatoolkit: new project layout

[Fabian Groffen]

On 08-01-2008 19:13:53 +1300, Alistair Bush wrote:
> > would it be possible to do it like we do it in Portage?
> > 
> >  sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(os.path.  realpath(__file__))), "pym"))
> > 
> > that would do the "magic" for prefix as well as that it makes
> > development for you a bit easier maybe.
> > 
> 
> How about we just remove it,  my plan was to have all modules in
> site_packages, which negates this?

If it is in standard python locations, then it works well for everybody,
yes.  Much appreciated if you would do so.  Thanks!


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-java@lists.gentoo.org mailing list

Re: [gentoo-java] javatoolkit: new project layout

[Alistair Bush]

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

Ok here are 2 patches to support the moving of javatoolkit

currently I have tested them on 1!! package!!  so surely they are tree
ready :)

What do you think of them?  Some parts are getting a bit messy but im
unsure of how they could be cleaned up without breaking backwards comp.

Alistair

ps, im just about to do a re-emerge-everything-java.sh, we will see how
it goes

pss.  Have I missed anything?

[-- Attachment #2: javatoolkit_java-ant-2.eclass.patch --]
[-- Type: text/plain, Size: 3177 bytes --]

--- java-ant-2.eclass.orig	2008-01-03 16:31:16.000000000 +1300
+++ java-ant-2.eclass	2008-01-09 21:31:17.000000000 +1300
@@ -224,7 +224,16 @@
 	else
 		local files
 
-		[[ -x "/usr/bin/xml-rewrite-2.py" ]] && local using_new="true"
+		local using_new=""
+		local xml_rewrite_2="/usr/$(get_libdir)/javatoolkit/bin/xml-rewrite-2.py"
+		if [[ -x "${xml_rewrite_2}" ]]; then
+			using_new="true"
+		else
+			xml_rewrite_2="/usr/bin/xml-rewrite-2.py"
+			if [[ -x "${xml_rewrite_2}" ]]; then
+				using_new="true"
+			fi
+		fi
 
 		for file in "${@}"; do
 			debug-print "${FUNCNAME}: ${file}"
@@ -243,10 +252,10 @@
 				echo "Rewriting $file (using xml-rewrite.py)"
 				# Doing this twice because otherwise the source attributes would
 				# get added to target tags too and javadoc does not like target
-				xml-rewrite.py -f "${file}" \
+				eval ${xml-rewrite.py} -f "${file}" \
 					-c -e ${JAVA_PKG_BSFIX_SOURCE_TAGS// / -e } \
 					-a source -v ${want_source} || _bsfix_die "xml-rewrite failed: ${file}"
-				xml-rewrite.py -f "${file}" \
+				eval ${xml-rewrite.py} -f "${file}" \
 					-c -e ${JAVA_PKG_BSFIX_TARGET_TAGS// / -e } \
 					-a target -v ${want_target} || _bsfix_die "xml-rewrite failed: ${file}"
 			fi
@@ -259,21 +268,25 @@
 			fi
 
 			# for javadoc target and all in one pass, we need the new rewriter.
-			local rewriter3="/usr/share/javatoolkit/xml-rewrite-3.py"
+			local rewriter3="/usr/$(get_libdir)}/javatoolkit/bin/xml-rewrite-3.py"
+			if [[ ! -f ${rewriter3} ]]; then
+				rewriter3="/usr/bin/xml-rewrite-3.py"
+			fi
+
 			if [[ ! -f ${rewriter3} ]]; then
 				debug-print "Using second generation rewriter"
 				eval echo "Rewriting source attributes" ${output}
-				eval xml-rewrite-2.py ${files} \
+				eval ${xml_rewrite_2} ${files} \
 					-c -e ${JAVA_PKG_BSFIX_SOURCE_TAGS// / -e } \
 					-a source -v ${want_source} ${output} || _bsfix_die "xml-rewrite2 failed: ${file}"
 
 				eval echo "Rewriting target attributes" ${output}
-				eval xml-rewrite-2.py ${files} \
+				eval ${xml_rewrite_2} ${files} \
 					-c -e ${JAVA_PKG_BSFIX_TARGET_TAGS// / -e } \
 					-a target -v ${want_target} ${output} || _bsfix_die "xml-rewrite2 failed: ${file}"
 
 				eval echo "Rewriting nowarn attributes" ${output}
-				eval xml-rewrite-2.py ${files} \
+				eval ${xml_rewrite_2} ${files} \
 					-c -e ${JAVA_PKG_BSFIX_TARGET_TAGS// / -e } \
 					-a nowarn -v yes ${output} || _bsfix_die "xml-rewrite2 failed: ${file}"
 			else
@@ -410,10 +423,17 @@
 # ------------------------------------------------------------------------------
 java-ant_xml-rewrite() {
 	local bindir="${ROOT}/usr/bin/"
+	local newbindir="${ROOT}/usr/$(get_libdir)/javatoolkit/bin"
 	local gen2="${bindir}/xml-rewrite-2.py"
+	local gen2_1="${newbindir}/xml-rewrite-2.py"
 	local gen1="${bindir}/xml-rewrite.py"
-	if [[ -x "${gen2}" ]]; then
+	local gen1_1="${newbindir}/xml-rewrite.py"
+	if [[ -x "${gen2_1}" ]]; then
+		${gen2_1} "${@}" || die "${gen2_1} failed"
+	elif [[ -x "${gen2}" ]]; then
 		${gen2} "${@}" || die "${gen2} failed"
+	elif [[ -x "${gen1_1}" ]]; then
+		${gen1_1} "${@}"
 	elif [[ -x "${gen1}" ]]; then
 		${gen1} "${@}" || die "${gen1} failed"
 	else

[-- Attachment #3: javatoolkit_java-utils-2.eclass.patch --]
[-- Type: text/plain, Size: 961 bytes --]

--- java-utils-2.eclass.orig	2008-01-09 21:34:56.000000000 +1300
+++ java-utils-2.eclass	2008-01-09 21:41:54.000000000 +1300
@@ -2606,15 +2606,19 @@
 # ------------------------------------------------------------------------------
 java-pkg_verify-classes() {
 	#$(find ${D} -type f -name '*.jar' -o -name '*.class')
+	local verifier="/usr/$(get_libdir)/javatoolkit/bin/class-version-verify.py"
+	if [[ ! -x "${verifier}" ]]; then
+		verifier="/usr/bin/class-version-verify.py"
+	fi
 	local target=$(java-pkg_get-target)
 	local result
 	local log="${T}/class-version-verify.log"
 	if [[ -n "${1}" ]]; then
-		class-version-verify.py -v -t ${target} "${1}" > "${log}"
+		eval ${verifier} -v -t ${target} "${1}" > "${log}"
 		result=$?
 	else
 		ebegin "Verifying java class versions (target: ${target})"
-		class-version-verify.py -v -t ${target} -r "${D}" > "${log}"
+		eval ${verifier} -v -t ${target} -r "${D}" > "${log}"
 		result=$?
 		eend ${result}
 	fi

Re: [gentoo-java] javatoolkit: new project layout

[Alistair Bush]

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

Even I can see the problem with the last java-ant-2.eclass patch....

no changes to java-utils-2 patch,  just here for completeness.

Alistair Bush wrote:
> Ok here are 2 patches to support the moving of javatoolkit
> 
> currently I have tested them on 1!! package!!  so surely they are tree
> ready :)
> 
> What do you think of them?  Some parts are getting a bit messy but im
> unsure of how they could be cleaned up without breaking backwards comp.
> 
> Alistair
> 
> ps, im just about to do a re-emerge-everything-java.sh, we will see how
> it goes
> 
> pss.  Have I missed anything?
> 

[-- Attachment #2: javatoolkit_java-ant-2.eclass.patch --]
[-- Type: text/plain, Size: 3381 bytes --]

--- java-ant-2.eclass.orig	2008-01-03 16:31:16.000000000 +1300
+++ java-ant-2.eclass	2008-01-09 22:01:53.000000000 +1300
@@ -224,7 +224,16 @@
 	else
 		local files
 
-		[[ -x "/usr/bin/xml-rewrite-2.py" ]] && local using_new="true"
+		local using_new=""
+		local xml_rewrite_2="/usr/$(get_libdir)/javatoolkit/bin/xml-rewrite-2.py"
+		if [[ -x "${xml_rewrite_2}" ]]; then
+			using_new="true"
+		else
+			xml_rewrite_2="/usr/bin/xml-rewrite-2.py"
+			if [[ -x "${xml_rewrite_2}" ]]; then
+				using_new="true"
+			fi
+		fi
 
 		for file in "${@}"; do
 			debug-print "${FUNCNAME}: ${file}"
@@ -241,12 +250,17 @@
 
 			if [[ -z "${using_new}" ]]; then
 				echo "Rewriting $file (using xml-rewrite.py)"
+
+				local xml_rewrite="/usr/$(get_libdir)/javatoolkit/bin/xml-rewrite.py"
+				if [[ ! -x "${xml_rewrite}" ]]; then
+					xml_rewrite="/usr/bin/xml-rewrite.py"
+				fi
 				# Doing this twice because otherwise the source attributes would
 				# get added to target tags too and javadoc does not like target
-				xml-rewrite.py -f "${file}" \
+				eval ${xml-rewrite} -f "${file}" \
 					-c -e ${JAVA_PKG_BSFIX_SOURCE_TAGS// / -e } \
 					-a source -v ${want_source} || _bsfix_die "xml-rewrite failed: ${file}"
-				xml-rewrite.py -f "${file}" \
+				eval ${xml-rewrite} -f "${file}" \
 					-c -e ${JAVA_PKG_BSFIX_TARGET_TAGS// / -e } \
 					-a target -v ${want_target} || _bsfix_die "xml-rewrite failed: ${file}"
 			fi
@@ -259,21 +273,25 @@
 			fi
 
 			# for javadoc target and all in one pass, we need the new rewriter.
-			local rewriter3="/usr/share/javatoolkit/xml-rewrite-3.py"
+			local rewriter3="/usr/$(get_libdir)}/javatoolkit/bin/xml-rewrite-3.py"
+			if [[ ! -f ${rewriter3} ]]; then
+				rewriter3="/usr/bin/xml-rewrite-3.py"
+			fi
+
 			if [[ ! -f ${rewriter3} ]]; then
 				debug-print "Using second generation rewriter"
 				eval echo "Rewriting source attributes" ${output}
-				eval xml-rewrite-2.py ${files} \
+				eval ${xml_rewrite_2} ${files} \
 					-c -e ${JAVA_PKG_BSFIX_SOURCE_TAGS// / -e } \
 					-a source -v ${want_source} ${output} || _bsfix_die "xml-rewrite2 failed: ${file}"
 
 				eval echo "Rewriting target attributes" ${output}
-				eval xml-rewrite-2.py ${files} \
+				eval ${xml_rewrite_2} ${files} \
 					-c -e ${JAVA_PKG_BSFIX_TARGET_TAGS// / -e } \
 					-a target -v ${want_target} ${output} || _bsfix_die "xml-rewrite2 failed: ${file}"
 
 				eval echo "Rewriting nowarn attributes" ${output}
-				eval xml-rewrite-2.py ${files} \
+				eval ${xml_rewrite_2} ${files} \
 					-c -e ${JAVA_PKG_BSFIX_TARGET_TAGS// / -e } \
 					-a nowarn -v yes ${output} || _bsfix_die "xml-rewrite2 failed: ${file}"
 			else
@@ -410,10 +428,17 @@
 # ------------------------------------------------------------------------------
 java-ant_xml-rewrite() {
 	local bindir="${ROOT}/usr/bin/"
+	local newbindir="${ROOT}/usr/$(get_libdir)/javatoolkit/bin"
 	local gen2="${bindir}/xml-rewrite-2.py"
+	local gen2_1="${newbindir}/xml-rewrite-2.py"
 	local gen1="${bindir}/xml-rewrite.py"
-	if [[ -x "${gen2}" ]]; then
+	local gen1_1="${newbindir}/xml-rewrite.py"
+	if [[ -x "${gen2_1}" ]]; then
+		${gen2_1} "${@}" || die "${gen2_1} failed"
+	elif [[ -x "${gen2}" ]]; then
 		${gen2} "${@}" || die "${gen2} failed"
+	elif [[ -x "${gen1_1}" ]]; then
+		${gen1_1} "${@}"
 	elif [[ -x "${gen1}" ]]; then
 		${gen1} "${@}" || die "${gen1} failed"
 	else

[-- Attachment #3: javatoolkit_java-utils-2.eclass.patch --]
[-- Type: text/plain, Size: 961 bytes --]

--- java-utils-2.eclass.orig	2008-01-09 21:34:56.000000000 +1300
+++ java-utils-2.eclass	2008-01-09 21:41:54.000000000 +1300
@@ -2606,15 +2606,19 @@
 # ------------------------------------------------------------------------------
 java-pkg_verify-classes() {
 	#$(find ${D} -type f -name '*.jar' -o -name '*.class')
+	local verifier="/usr/$(get_libdir)/javatoolkit/bin/class-version-verify.py"
+	if [[ ! -x "${verifier}" ]]; then
+		verifier="/usr/bin/class-version-verify.py"
+	fi
 	local target=$(java-pkg_get-target)
 	local result
 	local log="${T}/class-version-verify.log"
 	if [[ -n "${1}" ]]; then
-		class-version-verify.py -v -t ${target} "${1}" > "${log}"
+		eval ${verifier} -v -t ${target} "${1}" > "${log}"
 		result=$?
 	else
 		ebegin "Verifying java class versions (target: ${target})"
-		class-version-verify.py -v -t ${target} -r "${D}" > "${log}"
+		eval ${verifier} -v -t ${target} -r "${D}" > "${log}"
 		result=$?
 		eend ${result}
 	fi

Re: [gentoo-java] javatoolkit: new project layout

[Alistair Bush]

Ok, so the following ebuilds currently call xml-rewrite directly.  So
what is the solution for these?

is it too add our directory to the path?  are we allowed to "fiddle"
with PATH in eclasses?

egrep "xml-rewrite" */*/*.ebuild

dev-java/avalon-logkit/avalon-logkit-2.1-r1.ebuild
dev-java/avalon-logkit/avalon-logkit-2.1-r2.ebuild
dev-java/commons-io/commons-io-1.3.2.ebuild
dev-java/jempbox/jempbox-0.2.0.ebuild
dev-java/jgoodies-animation/jgoodies-animation-1.2.0.ebuild
dev-java/jgoodies-binding/jgoodies-binding-1.1.2.ebuild
dev-java/log4j/log4j-1.2.14-r1.ebuild
dev-java/log4j/log4j-1.2.14-r2.ebuild
dev-java/xml-writer/xml-writer-0.2.ebuild
dev-java/xpp2/xpp2-2.1.10-r1.ebuild
dev-java/xpp2/xpp2-2.1.10-r1.ebuild
-- 
gentoo-java@lists.gentoo.org mailing list

Re: [gentoo-java] javatoolkit: new project layout

[Vlastimil Babka]

Alistair Bush wrote:
> Ok, so the following ebuilds currently call xml-rewrite directly.  So
> what is the solution for these?

I'd say a public wrapper function (isn't there such already?) and change 
the ebuilds.

Caster
-- 
gentoo-java@lists.gentoo.org mailing list

Re: [gentoo-java] javatoolkit: new project layout

[Petteri Räty]

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

Alistair Bush kirjoitti:
> Ok, so the following ebuilds currently call xml-rewrite directly.  So
> what is the solution for these?
> 

betelgeuse@pena ~ $ qgrep -He "xml-rewrite.*py"
dev-java/jgoodies-binding/jgoodies-binding-1.1.2.ebuild: 
xml-rewrite.py -f build.xml -d -e javac -a bootclasspath \
dev-java/log4j/log4j-1.2.14-r1.ebuild:  xml-rewrite.py -f build.xml -c 
-e available -a ignoresystemclasses -v "true"
dev-java/log4j/log4j-1.2.14-r2.ebuild:  xml-rewrite.py -f build.xml -c 
-e available -a ignoresystemclasses -v "true"
dev-java/xpp2/xpp2-2.1.10-r1.ebuild:    xml-rewrite.py -f build.xml -e 
javac -a classpath -i 7 -c -v \
dev-java/xpp2/xpp2-2.1.10-r1.ebuild:    xml-rewrite.py -f build.xml -e 
javac -a classpath -i 8 -c -v \

Use java-ant_xml-rewrite


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

Re: [gentoo-java] javatoolkit: new project layout

[Vlastimil Babka]

Alistair Bush wrote:
> This email is to garner some discussion on my new project layout for
> javatoolkit.

Good idea.

AFAIK we sometimes ago also discussed that the stuff used only in 
ebuilds should probably go away from /usr/bin... what user needs to run 
xml-rewrite.py?

Also I just noticed, what is the 'bsfix' command for? Currently I get this:

# bsfix
Exception in thread "main" java.lang.NoClassDefFoundError: JXSLT

my version is 0.2.0-r5 from java-overlay

VB
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] javatoolkit: new project layout

[Alistair Bush]

Vlastimil Babka wrote:
> Alistair Bush wrote:
>> This email is to garner some discussion on my new project layout for
>> javatoolkit.
> 
> Good idea.
> 
> AFAIK we sometimes ago also discussed that the stuff used only in
> ebuilds should probably go away from /usr/bin... what user needs to run
> xml-rewrite.py?

Any idea's where?  Just a additional note,  as my changes have moved the
location of the xml-rewrite-3.py file, there will be a eclass patch at
some point :)

> 
> Also I just noticed, what is the 'bsfix' command for? Currently I get this:
> 
> # bsfix
> Exception in thread "main" java.lang.NoClassDefFoundError: JXSLT
> 
> my version is 0.2.0-r5 from java-overlay
> 
> VB

Well, so it is installed!  Having a brief look at the java code and
accompanying build-xml-source-target.xslt file, it looks like an
application that adds source and target attributes to javac, xjavac,
javac.preset and javadoc elements.  Well actually to be more general it
seems to apply any xslt to a xml file....

Seeing that it doesn't work, no one must be using it...
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] javatoolkit: new project layout

[Alistair Bush]

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

Please find attached a patch to java-ant-2.eclass to support the moving
of xml-rewrite-3.py, obviously we will figure out exactly where we are
moving it too before I apply this.

[-- Attachment #2: xml-rewriter-3-move.patch --]
[-- Type: text/plain, Size: 547 bytes --]

--- java-ant-2.eclass.orig	2008-01-03 16:31:16.000000000 +1300
+++ java-ant-2.eclass	2008-01-06 12:03:41.000000000 +1300
@@ -261,6 +261,10 @@
 			# for javadoc target and all in one pass, we need the new rewriter.
 			local rewriter3="/usr/share/javatoolkit/xml-rewrite-3.py"
 			if [[ ! -f ${rewriter3} ]]; then
+				rewriter3="/usr/bin/xml-rewrite-3.py"
+			fi
+
+			if [[ ! -f ${rewriter3} ]]; then
 				debug-print "Using second generation rewriter"
 				eval echo "Rewriting source attributes" ${output}
 				eval xml-rewrite-2.py ${files} \

Re: [gentoo-java] javatoolkit: new project layout

[Vlastimil Babka]

Alistair Bush wrote:
> Please find attached a patch to java-ant-2.eclass to support the moving
> of xml-rewrite-3.py, obviously we will figure out exactly where we are
> moving it too before I apply this.

I'd say /usr/$libdir/javatoolkit/bin as this location scheme is used by 
other packages (gentoolkit...) but I dunno what's "right".

VB


-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] javatoolkit: new project layout

[Petteri Räty]

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

Vlastimil Babka kirjoitti:
> Alistair Bush wrote:
>> Please find attached a patch to java-ant-2.eclass to support the moving
>> of xml-rewrite-3.py, obviously we will figure out exactly where we are
>> moving it too before I apply this.
> 
> I'd say /usr/$libdir/javatoolkit/bin as this location scheme is used by 
> other packages (gentoolkit...) but I dunno what's "right".
> 
> VB
> 

That works for me.

Regards,
Petteri


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