Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 116876 - dev-java/xins-1.3.0.ebuild (New Package)
Summary: dev-java/xins-1.3.0.ebuild (New Package)
Status: RESOLVED LATER
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High enhancement
Assignee: Default Assignee for New Packages
URL: http://xins.sourceforge.net/
Whiteboard:
Keywords: EBUILD
: 116880 (view as bug list)
Depends on: 116489
Blocks:
  Show dependency tree
 
Reported: 2005-12-27 06:41 UTC by Ernst de Haan
Modified: 2006-07-19 12:56 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Ebuild file for 1.3.0 (on the Stable branch 1.3.x) (xins-1.3.0.ebuild,1.92 KB, text/plain)
2005-12-27 06:43 UTC, Ernst de Haan
Details
Patch file for the 'xins' shell script; to be placed under files/ (xins-script.patch,563 bytes, patch)
2005-12-27 06:43 UTC, Ernst de Haan
Details | Diff
Ebuild file for 1.4.0_alpha1 (on the Development branch 1.4.x) (xins-1.4.0_alpha1.ebuild,2.01 KB, text/plain)
2005-12-27 07:28 UTC, Ernst de Haan
Details
Ebuild file for 1.3.0 (on the Stable branch 1.3.x) (v2) (xins-1.3.0.ebuild,1.84 KB, text/plain)
2005-12-27 07:37 UTC, Ernst de Haan
Details
Ebuild file for 1.4.0_alpha1 (on the Development branch 1.4.x) (v2) (xins-1.4.0_alpha1.ebuild,1.93 KB, text/plain)
2005-12-27 07:39 UTC, Ernst de Haan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ernst de Haan 2005-12-27 06:41:29 UTC
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
Comment 1 Ernst de Haan 2005-12-27 06:42:11 UTC
This Ebuild requires 'xmlenc' to be installed.
Comment 2 Ernst de Haan 2005-12-27 06:43:22 UTC
Created attachment 75600 [details]
Ebuild file for 1.3.0 (on the Stable branch 1.3.x)
Comment 3 Ernst de Haan 2005-12-27 06:43:52 UTC
Created attachment 75601 [details, diff]
Patch file for the 'xins' shell script; to be placed under files/
Comment 4 Carsten Lohrke (RETIRED) gentoo-dev 2005-12-27 07:20:47 UTC
- The ebuild header is invalid
Comment 5 Carsten Lohrke (RETIRED) gentoo-dev 2005-12-27 07:20:47 UTC
- 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
Comment 6 Carsten Lohrke (RETIRED) gentoo-dev 2005-12-27 07:22:29 UTC
*** Bug 116880 has been marked as a duplicate of this bug. ***
Comment 7 Ernst de Haan 2005-12-27 07:28:50 UTC
Created attachment 75603 [details]
Ebuild file for 1.4.0_alpha1 (on the Development branch 1.4.x)
Comment 8 Ernst de Haan 2005-12-27 07:35:56 UTC
- 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).
Comment 9 Ernst de Haan 2005-12-27 07:37:46 UTC
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.
Comment 10 Ernst de Haan 2005-12-27 07:39:14 UTC
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.
Comment 11 Petteri Räty (RETIRED) gentoo-dev 2006-01-04 13:12:45 UTC
(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
Comment 12 Petteri Räty (RETIRED) gentoo-dev 2006-01-05 10:56:52 UTC
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
Comment 13 Petteri Räty (RETIRED) gentoo-dev 2006-01-05 11:22:15 UTC
Hmm. Sorry it seems you use ant to run this stuff. Never seen such behaviour before.
Comment 14 Petteri Räty (RETIRED) gentoo-dev 2006-01-05 11:33:34 UTC
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.
Comment 15 Ernst de Haan 2006-01-05 13:20:53 UTC
(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.
Comment 16 Ernst de Haan 2006-01-05 13:30:33 UTC
(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).
Comment 17 Ernst de Haan 2006-07-19 12:56:27 UTC
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.