Find attached xins-1.3.0.ebuild, along with a unified diff for the 'xins' shell script; to be placed under files/. XINS is an open-source Web Services technology, supporting SOAP, XML-RPC and REST. It consists mainly of an XML-based specification format and a Java-based implementation framework. From its specifications, XINS can generate HTML, WSDL, client-side code, server-side code and test forms. Users do not require knowledge of any complex formats, such as XML Schemas. Suggested category: dev-java/xins Ernst
This Ebuild requires 'xmlenc' to be installed.
Created attachment 75600 [details] Ebuild file for 1.3.0 (on the Stable branch 1.3.x)
Created attachment 75601 [details, diff] Patch file for the 'xins' shell script; to be placed under files/
- The ebuild header is invalid
- The ebuild header is invalid¹. - You should not use a bundled .jar file, but build from source². [1] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=3 [2] http://www.gentoo.org/proj/en/java/java-devel.xml
*** Bug 116880 has been marked as a duplicate of this bug. ***
Created attachment 75603 [details] Ebuild file for 1.4.0_alpha1 (on the Development branch 1.4.x)
- The ebuild header is invalid Why is it? Just because the $Header$ is filled in by CVS? If that's the case, I'll replace it, but it seems to be a bit over-the-top. CVS will automatically replace it. But I'll submit some new .ebuild files. - You should not use a bundled .jar file, but build from source Which is exactly what I did, as far as I'm aware. Which .jar file did I not build from source? Note that I did try to follow all available documentation, including the documents you pointed me at, along with http://dev.gentoo.org/~plasmaroo/devmanual/ebuild-writing/ (which is a very good read indeed).
Created attachment 75605 [details] Ebuild file for 1.3.0 (on the Stable branch 1.3.x) (v2) This one has "$Header: $" without the contents put in automatically by CVS.
Created attachment 75606 [details] Ebuild file for 1.4.0_alpha1 (on the Development branch 1.4.x) (v2) This one has "$Header: $" without the contents put in automatically by CVS.
(In reply to comment #8) > Created an attachment (id=75605) [edit] > Ebuild file for 1.3.0 (on the Stable branch 1.3.x) (v2) > > This one has "$Header: $" without the contents put in automatically by CVS. > DEPEND="${RDEPEND} sys-apps/sed sed is part of the system target and as such you don't need to depend on it http://dev.gentoo.org/~plasmaroo/devmanual//general-concepts/dependencies/ CLASSPATH=${classpath} ant ${antflags} || die "Processing of Ant build file failed." I would use an ant property if available in the build.xml file or ant -lib, which is available in the latest ant versions. if use doc; then mkdir -p htmldoc/api cp -R docs/javadoc/* htmldoc/api/ java-pkg_dohtml -r htmldoc/* fi This should do the same thing without the copy overhead: if use doc; then mv docs/javadoc docs/api || die "Renaming javadocs failed" java-pkg_dohtml -r docs/api fi
RDEPEND=">=virtual/jdk-1.4 >=dev-java/ant-core-1.6.2 The build seems to be needing extra ant tasks: /var/tmp/portage/xins-1.3.0/work/xins-1.3.0/build.xml:270: java.lang.ClassNotFoundException: org.apache.tools.ant.taskdefs.optional.TraXLiaison You should be depending on dev-java/ant when the build process uses extra tasks. ant-core is also not a runtime dependency so it should not be in RDEPEND
Hmm. Sorry it seems you use ant to run this stuff. Never seen such behaviour before.
1.3.0 added to experimental: https://svn.gentooexperimental.org/svn/java/gentoo-java-experimental/dev-java/xins dodir ${LI}/lib empty directories get cleaned up by portage. If this directory is meant to be installed as an empty directory, you should use keepdir: I was also thinking that maybe instead of patching the upstream wrapper script, we would a) just rewrite it or b) install a gentoo specific wrapper of the wrapper in /usr/bin that would just set XINS_HOME and call the upstream wrapper.
(In reply to comment #11) > The build seems to be needing extra ant tasks: > /var/tmp/portage/xins-1.3.0/work/xins-1.3.0/build.xml:270: > java.lang.ClassNotFoundException: > org.apache.tools.ant.taskdefs.optional.TraXLiaison > > You should be depending on dev-java/ant when the build process uses extra > tasks. OK. I didn't see this when testing it on my machine. Perhaps I had too many things installed already. I will be more careful in testing next time. > ant-core is also not a runtime dependency so it should not be in RDEPEND It is, as you already concluded. The 'xins' shell script uses XSLT to generate an Ant build file which then gets executed by Ant self.
(In reply to comment #13) > 1.3.0 added to experimental: > https://svn.gentooexperimental.org/svn/java/gentoo-java-experimental/dev-java/xins > > dodir ${LI}/lib > empty directories get cleaned up by portage. If this directory is meant to be > installed as an empty directory, you should use keepdir: > > I was also thinking that maybe instead of patching the upstream wrapper script, > we would a) just rewrite it or b) install a gentoo specific wrapper of the > wrapper in /usr/bin that would just set XINS_HOME and call the upstream > wrapper. Rewriting is indeed possible, but personally I prefer the current approach, with a minor patch. Although the script is small, quite some time went into testing and fine-tuning it. A new script will start it's own life and will need to be maintained separately. The chances of people feeling free to make liberal changes to it is bigger and initially it will not have been tested as thoroughly. So keeping the changes explicitly minimal and local is preferrable, IMHO. Having a Gentoo-specific wrapper for the original 'xins' script is also possible. Perhaps this is indeed better. Then we leave the original script completely untouched. The wrapper script would need to check to make sure XINS_HOME is not set yet, to avoid changing the behaviour of the current script (currently the user can override XINS_HOME).
I will need to update the 'stable' ebuild to the current stable version of XINS, 1.4.2. See http://xins.sourceforge.net/notes-1.4.2.html Also, I will need to update the 'unstable' ebuild to the current development version of XINS, which is 1.5.0-alpha3.