public inbox for gentoo-java@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-java] New eclass to support java-virtuals
@ 2007-09-20 11:20 Alistair Bush
  2007-09-20 11:37 ` Petteri Räty
       [not found] ` <20070920174407.GN31094@supernova>
  0 siblings, 2 replies; 5+ messages in thread
From: Alistair Bush @ 2007-09-20 11:20 UTC (permalink / raw
  To: gentoo-dev; +Cc: gentoo-java

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

I would like to commit a new java eclass within the next week.

This eclass is designed to support the functionality that Betelgeuse
outlined within a previous post.[1]

As you will be able to see, this eclass is very simple and only uses
functionality that will be provided by the java-utils-2.eclass (see the
attached patch )

Basically all the happens is that a file is created under
/usr/share/java-config-2/virtuals/
that contains (at present) 3 variables.  This file is then read by our
java-config-2 application.


The eclass is currently implemented within the java-virtuals overlay for
those who are interested

https://overlays.gentoo.org/svn/proj/java/java-virtuals/


Any suggestions, improvements and of course approvals will be gladly
accepted

Go the All Blacks!!

Alistair


[1] http://thread.gmane.org/gmane.linux.gentoo.devel/48932/focus=48933

On Sun, 29 Apr 2007 17:00:09 +0200, Petteri Räty wrote:

> We want to implement virtuals for Java at some point and for that we
> need to know the package that provides the virtual because some virtuals
> can be provided by the JDK or normal packages and this affects the JDK
> selection at build time. One option is to call into Portage to find this
> out, but of course Paludis and Pkgcore people most likely don't like
> this approach. One thing that comes to mind is to allow for virtuals to
> install files so we can install the provider information in a format
> easy for us. We need the information in format ${PN}-${SLOT} because
> that's the way we install in /usr/share. So do you think it's ok for
> virtuals to install files (we can of course call the category
> java-virtual/ too), should we call Portage code, or do you have an
> another idea?

[-- Attachment #2: java-utils-2.eclass.patch --]
[-- Type: text/plain, Size: 5873 bytes --]

--- gentoo/cvs/gentoo-x86/eclass/java-utils-2.eclass	2007-08-05 20:17:05.000000000 +1200
+++ gentoo/overlays/java-virtuals/eclass/java-utils-2.eclass	2007-09-12 22:23:53.000000000 +1200
@@ -2196,6 +2286,8 @@
 	JAVA_PKG_SHAREPATH="${DESTTREE}/share/${JAVA_PKG_NAME}"
 	JAVA_PKG_SOURCESPATH="${JAVA_PKG_SHAREPATH}/sources/"
 	JAVA_PKG_ENV="${D}${JAVA_PKG_SHAREPATH}/package.env"
+	JAVA_PKG_VIRTUALS_PATH="${DESTTREE}/share/java-config-2/virtuals"
+	JAVA_PKG_VIRTUAL_PROVIDER="${D}/${JAVA_PKG_VIRTUALS_PATH}/${JAVA_PKG_NAME}"
 
 	[[ -z "${JAVA_PKG_JARDEST}" ]] && JAVA_PKG_JARDEST="${JAVA_PKG_SHAREPATH}/lib"
 	[[ -z "${JAVA_PKG_LIBDEST}" ]] && JAVA_PKG_LIBDEST="${DESTTREE}/$(get_libdir)/${JAVA_PKG_NAME}"
@@ -2220,58 +2312,71 @@
 java-pkg_do_write_() {
 	debug-print-function ${FUNCNAME} $*
 	java-pkg_init_paths_
-	# Create directory for package.env
-	dodir "${JAVA_PKG_SHAREPATH}"
-	if [[ -n "${JAVA_PKG_CLASSPATH}" || -n "${JAVA_PKG_LIBRARY}" || -f \
-			"${JAVA_PKG_DEPEND_FILE}" || -f \
-			"${JAVA_PKG_OPTIONAL_DEPEND_FILE}" ]]; then
-		# Create package.env
-		(
-			echo "DESCRIPTION=\"${DESCRIPTION}\""
-			echo "GENERATION=\"2\""
-
-			[[ -n "${JAVA_PKG_CLASSPATH}" ]] && echo "CLASSPATH=\"${JAVA_PKG_CLASSPATH}\""
-			[[ -n "${JAVA_PKG_LIBRARY}" ]] && echo "LIBRARY_PATH=\"${JAVA_PKG_LIBRARY}\""
-			[[ -n "${JAVA_PROVIDE}" ]] && echo "PROVIDES=\"${JAVA_PROVIDE}\""
-			[[ -f "${JAVA_PKG_DEPEND_FILE}" ]] \
-				&& echo "DEPEND=\"$(cat "${JAVA_PKG_DEPEND_FILE}" | uniq | tr '\n' ':')\""
-			[[ -f "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" ]] \
-				&& echo "OPTIONAL_DEPEND=\"$(cat "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" | uniq | tr '\n' ':')\""
-			echo "VM=\"$(echo ${RDEPEND} ${DEPEND} | sed -e 's/ /\n/g' | sed -n -e '/virtual\/\(jre\|jdk\)/ { p;q }')\"" # TODO cleanup !
-		) > "${JAVA_PKG_ENV}"
-
-		# register target/source
-		local target="$(java-pkg_get-target)"
-		local source="$(java-pkg_get-source)"
-		[[ -n ${target} ]] && echo "TARGET=\"${target}\"" >> "${JAVA_PKG_ENV}"
-		[[ -n ${source} ]] && echo "SOURCE=\"${source}\"" >> "${JAVA_PKG_ENV}"
-
-		# register javadoc info
-		[[ -n ${JAVADOC_PATH} ]] && echo "JAVADOC_PATH=\"${JAVADOC_PATH}\"" \
-			>> ${JAVA_PKG_ENV}
-		# register source archives
-		[[ -n ${JAVA_SOURCES} ]] && echo "JAVA_SOURCES=\"${JAVA_SOURCES}\"" \
-			>> ${JAVA_PKG_ENV}
-
-
-		echo "MERGE_VM=\"${GENTOO_VM}\"" >> "${JAVA_PKG_ENV}"
-		[[ -n ${GENTOO_COMPILER} ]] && echo "MERGE_COMPILER=\"${GENTOO_COMPILER}\"" >> "${JAVA_PKG_ENV}"
-
-		# extra env variables
-		if [[ -n "${JAVA_PKG_EXTRA_ENV_VARS}" ]]; then
-			cat "${JAVA_PKG_EXTRA_ENV}" >> "${JAVA_PKG_ENV}" || die
-			# nested echo to remove leading/trailing spaces
-			echo "ENV_VARS=\"$(echo ${JAVA_PKG_EXTRA_ENV_VARS})\"" \
-				>> "${JAVA_PKG_ENV}" || die
-		fi
-
-		# Strip unnecessary leading and trailing colons
-		# TODO try to cleanup if possible
-		sed -e "s/=\":/=\"/" -e "s/:\"$/\"/" -i "${JAVA_PKG_ENV}" || die "Did you forget to call java_init ?"
+	
+	if [[ $1 != provider ]]; then
+		# Create directory for package.env
+		dodir "${JAVA_PKG_SHAREPATH}"
+		if [[ -n "${JAVA_PKG_CLASSPATH}" || -n "${JAVA_PKG_LIBRARY}" || -f \
+				"${JAVA_PKG_DEPEND_FILE}" || -f \
+				"${JAVA_PKG_OPTIONAL_DEPEND_FILE}" ]]; then
+			# Create package.env
+			(
+				echo "DESCRIPTION=\"${DESCRIPTION}\""
+				echo "GENERATION=\"2\""
+
+				[[ -n "${JAVA_PKG_CLASSPATH}" ]] && echo "CLASSPATH=\"${JAVA_PKG_CLASSPATH}\""
+				[[ -n "${JAVA_PKG_LIBRARY}" ]] && echo "LIBRARY_PATH=\"${JAVA_PKG_LIBRARY}\""
+				[[ -n "${JAVA_PROVIDE}" ]] && echo "PROVIDES=\"${JAVA_PROVIDE}\""
+				[[ -f "${JAVA_PKG_DEPEND_FILE}" ]] \
+					&& echo "DEPEND=\"$(cat "${JAVA_PKG_DEPEND_FILE}" | uniq | tr '\n' ':')\""
+				[[ -f "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" ]] \
+					&& echo "OPTIONAL_DEPEND=\"$(cat "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" | uniq | tr '\n' ':')\""
+				echo "VM=\"$(echo ${RDEPEND} ${DEPEND} | sed -e 's/ /\n/g' | sed -n -e '/virtual\/\(jre\|jdk\)/ { p;q }')\"" # TODO cleanup !
+			) > "${JAVA_PKG_ENV}"
+
+			# register target/source
+			local target="$(java-pkg_get-target)"
+			local source="$(java-pkg_get-source)"
+			[[ -n ${target} ]] && echo "TARGET=\"${target}\"" >> "${JAVA_PKG_ENV}"
+			[[ -n ${source} ]] && echo "SOURCE=\"${source}\"" >> "${JAVA_PKG_ENV}"
+
+			# register javadoc info
+			[[ -n ${JAVADOC_PATH} ]] && echo "JAVADOC_PATH=\"${JAVADOC_PATH}\"" \
+				>> ${JAVA_PKG_ENV}
+			# register source archives
+			[[ -n ${JAVA_SOURCES} ]] && echo "JAVA_SOURCES=\"${JAVA_SOURCES}\"" \
+				>> ${JAVA_PKG_ENV}
+
+
+			echo "MERGE_VM=\"${GENTOO_VM}\"" >> "${JAVA_PKG_ENV}"
+			[[ -n ${GENTOO_COMPILER} ]] && echo "MERGE_COMPILER=\"${GENTOO_COMPILER}\"" >> "${JAVA_PKG_ENV}"
+
+			# extra env variables
+			if [[ -n "${JAVA_PKG_EXTRA_ENV_VARS}" ]]; then
+				cat "${JAVA_PKG_EXTRA_ENV}" >> "${JAVA_PKG_ENV}" || die
+				# nested echo to remove leading/trailing spaces
+				echo "ENV_VARS=\"$(echo ${JAVA_PKG_EXTRA_ENV_VARS})\"" \
+					>> "${JAVA_PKG_ENV}" || die
+			fi
+
+			# Strip unnecessary leading and trailing colons
+			# TODO try to cleanup if possible
+			sed -e "s/=\":/=\"/" -e "s/:\"$/\"/" -i "${JAVA_PKG_ENV}" || die "Did you forget to call java_init ?"
+		else
+			debug-print "JAVA_PKG_CLASSPATH, JAVA_PKG_LIBRARY, JAVA_PKG_DEPEND_FILE"
+			debug-print "or JAVA_PKG_OPTIONAL_DEPEND_FILE not defined so can't"
+			debug-print "write package.env."
+		fi
 	else
-		debug-print "JAVA_PKG_CLASSPATH, JAVA_PKG_LIBRARY, JAVA_PKG_DEPEND_FILE"
-		debug-print "or JAVA_PKG_OPTIONAL_DEPEND_FILE not defined so can't"
-		debug-print "write package.env."
+		dodir "${JAVA_PKG_VIRTUALS_PATH}"
+
+		echo "PROVIDERS=\"${JAVA_VIRTUAL_PROVIDES}\"" \
+				>> ${JAVA_PKG_VIRTUAL_PROVIDER}
+		echo "VM=\"${JAVA_VIRTUAL_VM}\"" \
+				>> ${JAVA_PKG_VIRTUAL_PROVIDER}
+
+		echo "VM_CLASSPATH=\"${JAVA_VIRTUAL_VM_CLASSPATH}\"" \
+				>> ${JAVA_PKG_VIRTUAL_PROVIDER} 
 	fi
 }
 

[-- Attachment #3: java-virtuals-2.eclass --]
[-- Type: text/plain, Size: 410 bytes --]

# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# Original Author: Alistair John Bush <ali_bush@gentoo.org>
# Purpose: 	To provide a default (and only) src_install function
# 			for ebuilds in the java-virtuals category.

inherit java-utils-2

EXPORT_FUNCTIONS src_install

java-virtuals-2_src_install() {
	java-pkg_do_write_ provider
}

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

* Re: [gentoo-java] New eclass to support java-virtuals
  2007-09-20 11:20 [gentoo-java] New eclass to support java-virtuals Alistair Bush
@ 2007-09-20 11:37 ` Petteri Räty
  2007-09-20 11:50   ` Alistair Bush
       [not found] ` <20070920174407.GN31094@supernova>
  1 sibling, 1 reply; 5+ messages in thread
From: Petteri Räty @ 2007-09-20 11:37 UTC (permalink / raw
  To: Alistair Bush; +Cc: gentoo-dev, gentoo-java

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

Alistair Bush kirjoitti:
> I would like to commit a new java eclass within the next week.
> 
> This eclass is designed to support the functionality that Betelgeuse
> outlined within a previous post.[1]
> 
> As you will be able to see, this eclass is very simple and only uses
> functionality that will be provided by the java-utils-2.eclass (see the
> attached patch )
> 
> Basically all the happens is that a file is created under
> /usr/share/java-config-2/virtuals/
> that contains (at present) 3 variables.  This file is then read by our
> java-config-2 application.
> 
> 
> The eclass is currently implemented within the java-virtuals overlay for
> those who are interested
> 
> https://overlays.gentoo.org/svn/proj/java/java-virtuals/
> 
> 
> Any suggestions, improvements and of course approvals will be gladly
> accepted
> 
> Go the All Blacks!!
> 
> Alistair
> 

https://overlays.gentoo.org/svn/proj/java/java-virtuals/java-virtuals/javamail/javamail-1.0.ebuild

Is the JAVA_VIRTUAL variable there some old leftover? I don't see it
used anywhere and it's quite useless as you could use hasq
java-virtuals-2 ${INHERIT} any way.

Regards,
Petteri


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

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

* Re: [gentoo-java] New eclass to support java-virtuals
  2007-09-20 11:37 ` Petteri Räty
@ 2007-09-20 11:50   ` Alistair Bush
  0 siblings, 0 replies; 5+ messages in thread
From: Alistair Bush @ 2007-09-20 11:50 UTC (permalink / raw
  To: Petteri Räty; +Cc: gentoo-java, gentoo-dev



Petteri Räty wrote:
> Alistair Bush kirjoitti:
>> I would like to commit a new java eclass within the next week.
>>
>> This eclass is designed to support the functionality that Betelgeuse
>> outlined within a previous post.[1]
>>
>> As you will be able to see, this eclass is very simple and only uses
>> functionality that will be provided by the java-utils-2.eclass (see the
>> attached patch )
>>
>> Basically all the happens is that a file is created under
>> /usr/share/java-config-2/virtuals/
>> that contains (at present) 3 variables.  This file is then read by our
>> java-config-2 application.
>>
>>
>> The eclass is currently implemented within the java-virtuals overlay for
>> those who are interested
>>
>> https://overlays.gentoo.org/svn/proj/java/java-virtuals/
>>
>>
>> Any suggestions, improvements and of course approvals will be gladly
>> accepted
>>
>> Go the All Blacks!!
>>
>> Alistair
>>
> 
> https://overlays.gentoo.org/svn/proj/java/java-virtuals/java-virtuals/javamail/javamail-1.0.ebuild
> 
> Is the JAVA_VIRTUAL variable there some old leftover? I don't see it
> used anywhere and it's quite useless as you could use hasq
> java-virtuals-2 ${INHERIT} any way.
> 
> Regards,
> Petteri
> 

Yes that is a old variable. Please ignore it.
-- 
gentoo-java@gentoo.org mailing list



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

* [gentoo-java] Re: [gentoo-dev] New eclass to support java-virtuals
       [not found] ` <20070920174407.GN31094@supernova>
@ 2007-09-20 18:58   ` Alistair Bush
       [not found]     ` <20070920190909.GP31094@supernova>
  0 siblings, 1 reply; 5+ messages in thread
From: Alistair Bush @ 2007-09-20 18:58 UTC (permalink / raw
  To: gentoo-dev; +Cc: Donnie Berkholz, gentoo-java



Donnie Berkholz wrote:
> On 23:20 Thu 20 Sep     , Alistair Bush wrote:
>> -		# Create package.env
>> -		(
>> -			echo "DESCRIPTION=\"${DESCRIPTION}\""
>> -			echo "GENERATION=\"2\""
>> -
>> -			[[ -n "${JAVA_PKG_CLASSPATH}" ]] && echo "CLASSPATH=\"${JAVA_PKG_CLASSPATH}\""
>> -			[[ -n "${JAVA_PKG_LIBRARY}" ]] && echo "LIBRARY_PATH=\"${JAVA_PKG_LIBRARY}\""
>> -			[[ -n "${JAVA_PROVIDE}" ]] && echo "PROVIDES=\"${JAVA_PROVIDE}\""
>> -			[[ -f "${JAVA_PKG_DEPEND_FILE}" ]] \
>> -				&& echo "DEPEND=\"$(cat "${JAVA_PKG_DEPEND_FILE}" | uniq | tr '\n' ':')\""
>> -			[[ -f "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" ]] \
>> -				&& echo "OPTIONAL_DEPEND=\"$(cat "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" | uniq | tr '\n' ':')\""
>> -			echo "VM=\"$(echo ${RDEPEND} ${DEPEND} | sed -e 's/ /\n/g' | sed -n -e '/virtual\/\(jre\|jdk\)/ { p;q }')\"" # TODO cleanup !
>> -		) > "${JAVA_PKG_ENV}"
> 
> Why not use a code block {} instead of a subshell ()?

You would have to ask the original author about that, but point taken.

> 
>> -		# register target/source
>> -		local target="$(java-pkg_get-target)"
>> -		local source="$(java-pkg_get-source)"
>> -		[[ -n ${target} ]] && echo "TARGET=\"${target}\"" >> "${JAVA_PKG_ENV}"
>> -		[[ -n ${source} ]] && echo "SOURCE=\"${source}\"" >> "${JAVA_PKG_ENV}"
>> -
>> -		# register javadoc info
>> -		[[ -n ${JAVADOC_PATH} ]] && echo "JAVADOC_PATH=\"${JAVADOC_PATH}\"" \
>> -			>> ${JAVA_PKG_ENV}
>> -		# register source archives
>> -		[[ -n ${JAVA_SOURCES} ]] && echo "JAVA_SOURCES=\"${JAVA_SOURCES}\"" \
>> -			>> ${JAVA_PKG_ENV}
>> -
>> -
>> -		echo "MERGE_VM=\"${GENTOO_VM}\"" >> "${JAVA_PKG_ENV}"
>> -		[[ -n ${GENTOO_COMPILER} ]] && echo "MERGE_COMPILER=\"${GENTOO_COMPILER}\"" >> "${JAVA_PKG_ENV}"
> 
> I don't understand why all these things are done down here instead of in the 
> same code block as $JAVA_PKG_ENV is created.

That to is also historical, and i'm less inclined to changed it. I've
already broken the tree once with a eclass change, breaking this would
completely break java support.  It could be updated as part of our
general QA, but I believe that it should be done separately, and not
bundled in with the changes i've made.

> 
>> -		# Strip unnecessary leading and trailing colons
>> -		# TODO try to cleanup if possible
>> -		sed -e "s/=\":/=\"/" -e "s/:\"$/\"/" -i "${JAVA_PKG_ENV}" || die "Did you forget to call java_init ?"
>> +	
>> +	if [[ $1 != provider ]]; then
> 
> Could you explain what the next section is supposed to do, as opposed to 
> the above section? Are they expected to be mutually exclusive? The 
> comments suggest so, since both have a 'Create package.env'. But the 
> tests suggest otherwise, since it's not an if...else pair.

normally java-pkg_do_write_ is called to write the package.env out, as
can be seen, and is the default behavior for the function.  What I am
adding is the ability to _do_write of a "[virtual|provider].env" file.
While at present it only contains 3 variables, I see no reason why
eventually it will not include other vars that are shared between the
package.env and "virtual.env" ( e.g DESCRIPTION )

Therefore this change can be summarized as

+ if [[ $1 != provider ]]; then
	#Do the default package.env behaviour
+ else
+	#Create a "virtual.env" file. This will only be invoked by
+	#ebuilds that inherit java-virtuals.eclass
+ fi

I could very well reflactor the java-pkg_do_write_ function back to its
current state and create a new function java-pkg_do_write_virtual to be
called by java-virtuals-2.eclass.

The documentation could (and will) be updated to more correctly reflect
whats happening.


> 
>> +		# Create directory for package.env
>> +		dodir "${JAVA_PKG_SHAREPATH}"
>> +		if [[ -n "${JAVA_PKG_CLASSPATH}" || -n "${JAVA_PKG_LIBRARY}" || -f \
>> +				"${JAVA_PKG_DEPEND_FILE}" || -f \
>> +				"${JAVA_PKG_OPTIONAL_DEPEND_FILE}" ]]; then
>> +			# Create package.env
>> +			(
>> +				echo "DESCRIPTION=\"${DESCRIPTION}\""
>> +				echo "GENERATION=\"2\""
>> +
>> +				[[ -n "${JAVA_PKG_CLASSPATH}" ]] && echo "CLASSPATH=\"${JAVA_PKG_CLASSPATH}\""
>> +				[[ -n "${JAVA_PKG_LIBRARY}" ]] && echo "LIBRARY_PATH=\"${JAVA_PKG_LIBRARY}\""
>> +				[[ -n "${JAVA_PROVIDE}" ]] && echo "PROVIDES=\"${JAVA_PROVIDE}\""
>> +				[[ -f "${JAVA_PKG_DEPEND_FILE}" ]] \
>> +					&& echo "DEPEND=\"$(cat "${JAVA_PKG_DEPEND_FILE}" | uniq | tr '\n' ':')\""
>> +				[[ -f "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" ]] \
>> +					&& echo "OPTIONAL_DEPEND=\"$(cat "${JAVA_PKG_OPTIONAL_DEPEND_FILE}" | uniq | tr '\n' ':')\""
>> +				echo "VM=\"$(echo ${RDEPEND} ${DEPEND} | sed -e 's/ /\n/g' | sed -n -e '/virtual\/\(jre\|jdk\)/ { p;q }')\"" # TODO cleanup !
>> +			) > "${JAVA_PKG_ENV}"
> 
> Thanks,
> Donnie
-- 
gentoo-java@gentoo.org mailing list



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

* [gentoo-java] Re: [gentoo-dev] New eclass to support java-virtuals
       [not found]     ` <20070920190909.GP31094@supernova>
@ 2007-09-21  5:28       ` Alistair Bush
  0 siblings, 0 replies; 5+ messages in thread
From: Alistair Bush @ 2007-09-21  5:28 UTC (permalink / raw
  To: gentoo-dev, Donnie Berkholz, gentoo-java



Donnie Berkholz wrote:
> On 06:58 Fri 21 Sep     , Alistair Bush wrote:
>> normally java-pkg_do_write_ is called to write the package.env out, as
>> can be seen, and is the default behavior for the function.  What I am
>> adding is the ability to _do_write of a "[virtual|provider].env" file.
>> While at present it only contains 3 variables, I see no reason why
>> eventually it will not include other vars that are shared between the
>> package.env and "virtual.env" ( e.g DESCRIPTION )
>>
>> Therefore this change can be summarized as
>>
>> + if [[ $1 != provider ]]; then
>> 	#Do the default package.env behaviour
>> + else
>> +	#Create a "virtual.env" file. This will only be invoked by
>> +	#ebuilds that inherit java-virtuals.eclass
>> + fi
>>
>> I could very well reflactor the java-pkg_do_write_ function back to its
>> current state and create a new function java-pkg_do_write_virtual to be
>> called by java-virtuals-2.eclass.
>>
>> The documentation could (and will) be updated to more correctly reflect
>> whats happening.
> 
> I'm concerned about code duplication, because that's what it looks like. 
> Refactoring might be a good idea.
> 
> Thanks,
> Donnie

Ok, thanks for the input Donnie. I will refactor it before goes into the
tree.

Any more input ppl?

Thanks

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



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

end of thread, other threads:[~2007-09-21  5:42 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-09-20 11:20 [gentoo-java] New eclass to support java-virtuals Alistair Bush
2007-09-20 11:37 ` Petteri Räty
2007-09-20 11:50   ` Alistair Bush
     [not found] ` <20070920174407.GN31094@supernova>
2007-09-20 18:58   ` [gentoo-java] Re: [gentoo-dev] " Alistair Bush
     [not found]     ` <20070920190909.GP31094@supernova>
2007-09-21  5:28       ` Alistair Bush

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