[gentoo-dev] New eclass to support java-virtuals

2007-09-20 Thread Alistair Bush 
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?
--- gentoo/cvs/gentoo-x86/eclass/java-utils-2.eclass2007-08-05 
20:17:05.0 +1200
+++ gentoo/overlays/java-virtuals/eclass/java-utils-2.eclass2007-09-12 
22:23:53.0 +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
-

Re: [gentoo-dev] New eclass to support java-virtuals

2007-09-20 Thread Donnie Berkholz 
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 ()?

 - # 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.

 - # 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.

 + # 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
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] New eclass to support java-virtuals

2007-09-20 Thread Alistair Bush 


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' ':')\
 +

Re: [gentoo-dev] New eclass to support java-virtuals

2007-09-20 Thread Donnie Berkholz 
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
-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] New eclass to support java-virtuals

2007-09-20 Thread Alistair Bush 


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
-- 
[EMAIL PROTECTED] mailing list