Re: Debian featuring http://java.sun.com/products/jimi/ ?
Steffen Moeller wrote: Hello, I know I should make this a RFP, but I am a bit lost about what the perfect package name would possibly be. A program that I am interested to package comes with the jimi.jar. Is there a way to have this Java Image I/O Debianised? Many thanks and regards Steffen Hi Steffan, Isn't the license for JIMI too prohibitive? For instance: The Software may contain source code which is provided for reference purposes only, and may not be modified (except for the purpose of correcting errors) or redistributed. ... distribute the Software complete and unmodified (except for error corrections), only as part of, and for the sole purpose of running, your Java applet or application (Program) into which the Software is incorporated There's lots of that sort of stuff, and it looks to me as though we couldn't even distribute a binary blob in non-free. It might be worth contacting SUN to see if they would re-license it (assuming they own the copyright). (I've copied this reply to debian-java by the way, as that list has more readers). Cheers, Paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#486938: maven2.jar seems to be missing classes from org.apache.maven:maven-toolchain
package: maven2 owner: [EMAIL PROTECTED] thanks Hi Alexander, Thanks for your report. I'll investigate further later this week. Cheers, Paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#481571: Confirmed - need to add manifest
tags 481571 +confirmed Thanks for the report. Yes, we need to add an explicit manifest. Upstream's looks like: Main-Class: org.w3c.tidy.Tidy Name: org/w3c/tidy/Tidy.class Java-Bean: True Thanks, Paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: tomcat5.5 5.5.26-1 testing and unstable
John Davos wrote: Good Day All, I installed tomcat5.5.26-1on testing and unstable and the startup script (/etc/init.d/tomcat5.5) doesn't start tomcat and exits without output in the log or at console. I started with a fresh install of debian testing I know this method of starting tomcat works with tomcat5.5.20-2etch2 there are too many differences that I can't decipher between the startup scripts of the two versions for me to fix it myself. Any info or suggestions would be greatly appreciated, thank you for your time and effort! This sounds like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477363. If you have a look at that bug report, someone has suggested a patch as follows: fixed the bug by adding an appropriate entry for commons-logging-api.jar to the CLASSPATH of jsvc. Hence I changed line 122 of /etc/init.d/tomcat5.5 to: JSVC_CLASSPATH=/usr/share/java/commons-daemon.jar: $CATALINA_HOME/bin/bootstrap.jar: $CATALINA_HOME/bin/commons-logging-api.jar (Linebreaks added for the sake of clarity. In the original file this is all on one line, with no whitespace in between.) I expect that's the problem here, but please let us know if not. ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#474908: [Fwd: [ cdk-Bugs-1938953 ] Build fails with new JavaCC beta - MakeJavafilesFiles]
It's now been fixed upstream as well. Original Message Subject: [ cdk-Bugs-1938953 ] Build fails with new JavaCC beta - MakeJavafilesFiles From:SourceForge.net [EMAIL PROTECTED] Date:Mon, April 21, 2008 21:16 To: [EMAIL PROTECTED] -- Bugs item #1938953, was opened at 2008-04-09 23:20 Message generated for change (Settings changed) made by egonw You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=120024aid=1938953group_id=20024 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: build.xml Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Paul Cager (paulcager) Assigned to: Egon Willighagen (egonw) Summary: Build fails with new JavaCC beta - MakeJavafilesFiles Initial Comment: The new version of JavaCC (not yet released, but available from JavaCC's CVS) generates code with comments of the form: /** Token Manager. */ Unfortunately MakeJavafilesFiles.java doesn't handle this type of comment - if the comment starts with /** it only looks for **/ as a comment terminator (if it is a single-line comment). I have attached a patch I use in the Debian build to fix MakeJavafilesFiles.java (although you may want to fix it in a more robust way). (If you need the newer version of JavaCC I would be happy to send you the jar). Thanks. -- Comment By: Egon Willighagen (egonw) Date: 2008-04-21 22:15 Message: Logged In: YES user_id=25678 Originator: NO Hi Paul, at some point I've looked for a good Java source parser that also parser JavaDoc, but never found a free tool for that. No idea, why it specifically looks for **/... I'll apply the patch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=120024aid=1938953group_id=20024 ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#474908: cdk: FTBFS: NomParserTokenManager cannot be resolved to a type
Michael Koch wrote: On Mon, Apr 07, 2008 at 10:33:32PM +0200, Lucas Nussbaum wrote: Package: cdk Version: 1:1.0.2-1 Severity: serious User: [EMAIL PROTECTED] Usertags: qa-ftbfs-20080407 qa-ftbfs Justification: FTBFS on i386 ... This broken with the last javacc update. Teh Nom*.java classes are generated from NomParser.jj. Paul can you please take a look at this? Thanks for finding this problem, Lucas. cdk looks to have an interesting build system - it compiles a Java program (MakeJavafilesFiles.java) which is then used to copy the source files into a build directory. But MakeJavafilesFiles spits out the error message Something wrong with the Java source file: src/org/openscience/cdk/iupac/parser/NomParserTokenManager.java. The reason is because JavaCC is generating comments such as: /** Token Manager. */ CDK's MakeJavafilesFiles program looks at program sources to detect special @cdk.set tags in them. But there is a bug in the part of MakeJavafilesFiles that is meant to recognise comments - it doesn't recognise the comment terminator */ if the comment was introduced with /** on the same line. I'll probably patch cdk so that it recognises */ in this context, but also fix JavaCC upstream (change the comment terminator to be **/). Thanks, Paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#473954: Missing build-depends
It looks as though libcommons-cli-java needs to build-depend on ant-optional. I was surprised it didn't fail with pbuilder - does pbuilder still install Recommends:? I'll prepare a fix. ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#466860: Your Debian Bug Report re Maven2
Thank you for your bug report, and I agree that it should be severity=important. I'd prefer lenny to go out without Maven rather than with this bug. This problem (and http://bugs.debian.org/458895) happen because Debian's version of Maven uses version 1.1 of Apache's commons-cli library, whereas upstream's Maven uses version 1.0. Version 1.1 has introduced significantly different behaviour around the handling of repeated arguments (such as: -Dsome.option=0 -Dsomething.else=1). The fix for 458895 allowed multiple -D args, as in: mvn -e archetype:create -DgroupId=org.x.y -DartifactId=z -DarchetypeArtifactId=maven-archetype-j2ee-simple But then commons-cli assumes that everything after the first -D is another -D, which is why this fails: mvn -Dsome.option=0 install Unless I am missing something obvious, commons-cli 1.1 is rather broken and can't support the syntax Maven requires. I'll look more deeply into commons-cli's code this week to see what we should do. Thanks, Paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#466860: Your Debian Bug Report re Maven2
Michael Koch wrote: If we can't work around this we will need to upload a commons-cli-1.0 package just for maven2. Would not be nice but a workaround. Hi Michael, It's good to have that option as a backup. Currently commons-cli 1.1 silently discards all but the first instance of any option (it throws an exception internally, which is then caught but discarded). I can't imagine anything deliberately depending on this behaviour, so I feel it should be safe to patch it. Once I'm more certain I'll clone the bug (as I'll have to revert the original Maven2 patch). It looks as though upstream accept that this behaviour is buggy (https://issues.apache.org/jira/browse/CLI-137). It's as much a question of what the code *should* be doing. Thanks, Paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#458895: maven2: commons-cli.jar is the culprit
Paul Cager wrote: Mike Paul wrote: Package: maven2 Version: 2.0.8-3 Followup-For: Bug #458895 [...] It turns out that /usr/share/maven2/lib/commons-cli.jar is the one that makes the difference: if I copy that jar into a freshly-unpacked copy of Apache's Maven distribution, the problem occurs there too. [...] It would seem that this behaviour relies on Maven using an old version of commons-cli. I'll investigate further. [...] I've not had time to fix this problem yet, so I thought I'd just let you know what's happening. The problem happens because of a change introduced in commons-cli 1.1, which is described in http://issues.apache.org/jira/browse/CLI-137 Although the change has destroyed backwards compatibility (and I don't like that), the new behaviour agrees with cli's API specification. So I think we should call this a bug in Maven which just happens to be harmless with cli version 1.0. I'll prepare a new revision of the maven2 Debian package with Maven's calls to commons.cli patched, and send the bug upstream to the Maven developers (although they still use cli version 1.0). It'll probably take a few days as I want to give it a good test. Thanks, Paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#458895: maven2: commons-cli.jar is the culprit
Mike Paul wrote: Package: maven2 Version: 2.0.8-3 Followup-For: Bug #458895 [...] It turns out that /usr/share/maven2/lib/commons-cli.jar is the one that makes the difference: if I copy that jar into a freshly-unpacked copy of Apache's Maven distribution, the problem occurs there too. Thanks for investigating this so thoroughly, and sorry I have not had more time to look at it myself. It's a bit odd. At first I thought it must be a bug in the Debian packaging of commons-cli, but I downloaded the official Apache jar from http://mirrors.dedipower.com/ftp.apache.org/commons/cli/binaries/commons-cli-1.1.tar.gz and that exhibits the same failure. If you download the jar from Maven's repo (http://repo1.maven.org/maven2/commons-cli/commons-cli/1.0/commons-cli-1.0.jar) then it all works. It would seem that this behaviour relies on Maven using an old version of commons-cli. I'll investigate further. [...] ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#458895: maven2: Creating empty project with artifacts fails
Valliet Emmanuel wrote: Package: maven2 Version: 2.0.8-3 Severity: normal Hi, I installed the maven2 debian package, and tried to make an empty j2ee package using the artifacts, and it failed: [EMAIL PROTECTED]:~/devel/java/sources$ mvn -e archetype:create -DgroupId=org.homelinux.beap -DartifactId=manu -DarchetypeArtifactId=maven-archetype-j2ee-simple + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'archetype'. [INFO] org.apache.maven.plugins: checking for updates from central [INFO] org.codehaus.mojo: checking for updates from central [INFO] artifact org.apache.maven.plugins:maven-archetype-plugin: checking for updates from central Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-archetype-plugin/1.0-alpha-7/maven-archetype-plugin-1.0-alpha-7.pom 4K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/archetype/maven-archetype/1.0-alpha-7/maven-archetype-1.0-alpha-7.pom 3K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/archetype/maven-archetype-parent/2/maven-archetype-parent-2.pom 2K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-parent/5/maven-parent-5.pom 14K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/apache/3/apache-3.pom 3K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-archetype-plugin/1.0-alpha-7/maven-archetype-plugin-1.0-alpha-7.jar 12K downloaded [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Invalid task 'artifactId=manu': you must specify a valid lifecycle phase, or a goal in the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal [INFO] [INFO] Trace [...] Cheers, Valliet Emmanuel Hi, Thanks for your report and your initial investigations. I can reproduce this error in a clean chroot, but not on my standard desktop (which is confusing!). I'll have a more detailed look at it soon. Thanks, Paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: /usr/share/java as maven repository?
On Sat, December 22, 2007 21:03, Marcus Better wrote: Paul Cager wrote: E.g. the POM could require JUnit-3.8.1 but Debian has packaged version 3.8.2. In this case we would set up a link in the temporary Maven repository: debian/.m2/repository/.../junit-3.8.1.jar - /usr/share/java/junit.jar - /usr/share/java/junit-3.8.2.jar We should check that the Debian version is not *older* than the version required by the POM, but we are still relying on releases being backwards compatible. Any comments? This is a recipe for disaster since the dependencies will likely break ABI at some point. Then our package will FTBFS if we are lucky, or build and run with the wrong version and give very interesting bugs later on. (On the other hand it's similar to what we already do...) Yes, I would generally agree with that. [...] In other words we should try to solve the library versioning problem first, and only then try to build packages with Maven. Now there I'm afraid I have to disagree. Newer library versions that are not backwards-compatible will affect packages built using ant in just the same way as packages built using Maven. I'm not sure what advantage we would gain by precluding the use of Maven in package builds - or have I misunderstood you? Thanks, Paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: /usr/share/java as maven repository?
On Wed, December 19, 2007 17:52, Dalibor Topic wrote: Arnaud Vandyck wrote: Many thanks for the clarifications. So if we are talking about refactoring /usr/share/java, let's do it in some sort of Debian way. We'll write a wrapper around different build system to let them understand our layout. (is it what you meant?) I hope that wrapping the build systems themselves won't be necessary. It may be easier to 'setUp' and 'tearDown' virtual repositories based on our own binaries in /usr/share/java and automatically generated metadata from debian's metadata about the packages using some kind of a debhelper_maven script or something like that. I'd imagine something like this: 1. for the package build, you'd call debhelper_maven 2. (setUp) it would look at the dependency information of the package, and for each dependency generate a POM file on the fly from the debian package metadata, 3. (build) then call maven with the freshly generated pom repository to do its build work, 4. (tearDown) then tear down the POM repository, i.e. remove POMs, unregister them from Maven, etc. That sounds good. There's still a few things bothering me - anyone got any ideas on the following? Offline Mode + Repository = When building a Debian package I expect we'll be running Maven with the offline flag, so I believe we'll have to set up the temporary repository in the local cache, e.g. debian/.m2/repository (and provide a localRepository setting). Or is there a better way? Versions The POMs will refer to an explicit version of a dependency, e.g. junit-3.8.1, and its unlikely we'd have exactly the right version in /usr/share/java (the Maven build of jetty, for instance, downloaded two different versions of junit). I guess we will have to fake it and pretend our jar is the correct version. E.g. the POM could require JUnit-3.8.1 but Debian has packaged version 3.8.2. In this case we would set up a link in the temporary Maven repository: debian/.m2/repository/.../junit-3.8.1.jar - /usr/share/java/junit.jar - /usr/share/java/junit-3.8.2.jar We should check that the Debian version is not *older* than the version required by the POM, but we are still relying on releases being backwards compatible. Any comments? Mapping Maven Artifacts to Our Jar Names Any ideas how we'd generate the list of jars to copy into our temporary repository? I think most of the time a simple naming convention is good enough (e.g. artifact junit maps onto /usr/share/java/junit.jar). But I think we also need to allow the packager to override the default - for example if Debian has packaged two ABI-incompatible versions of a jar, or used non-standard jar names. I guess that *indirect* dependencies wouldn't be set up in the temporary maven repository - we'd just add them to the classpath as we do for ant builds. Would this work? I can't see an alternative here, as we wouldn't have the dependencies' POMs. The No-Dependencies Alternative = Alternatively we could add *all* required jars to the classpath (same as we do now for ant builds), and remove all dependencies from the POM(s). I think that would work, but haven't tested it. Instead of modifying the POM(s) we could write a Maven plugin so that Maven ignores any dependencies - I'm not sure how easy that would be. Then I believe we would only need to put the plugins (e.g. maven-compiler-plugin) in the temporary repository. Replace maven POM above with a different system, but the steps would be virtually the same. Pros: * builds are reproducible consistent within the Debian system * Debian's metadata is used throughout the build system, i.e. no metadata skew * could be separated from user's own build system repository, so no 'your jars are messing with my jars' conflicts Cons: * someone would need to implement it and see if the pros actually hold. :) cheers, dalibor topic ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: /usr/share/java as maven repository?
Marcus Better wrote: Arnaud Vandyck wrote: What about a maven plugin that leave the jar in /usr/share/java, but register the jar. if mvn present: mvn install -DgroupId=... -DversionId=... -DartifactId=... /usr/share/java/my.jar If it's meant to be run in postinst then Maven might not be installed yet. But I wonder how we are going to handle versioned dependencies. Maven projects tend to specify exact version numbers, right? That could be a real headache. I don't think we can ignore the version number, but we cannot use it as a hard dependency either. Cheers, Marcus The install:install-file plugin does almost what Arnaud suggests: http://maven.apache.org/guides/mini/guide-installing-3rd-party-jars.html mvn install:install-file -Dfile=path-to-file -DgroupId=group-id \ -DartifactId=artifact-id -Dversion=version \ -Dpackaging=packaging But I wonder just how important it is to have a system-wide local repo? It would certainly reduce the number of Jars an end-user needed to download (clearly a good thing), but it seems like a lot of work (for us). ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: /usr/share/java as maven repository?
Dalibor Topic wrote: Paul Cager wrote: Marcus Better wrote: Arnaud Vandyck wrote: What about a maven plugin that leave the jar in /usr/share/java, but register the jar. if mvn present: mvn install -DgroupId=... -DversionId=... -DartifactId=... /usr/share/java/my.jar If it's meant to be run in postinst then Maven might not be installed yet. But I wonder how we are going to handle versioned dependencies. Maven projects tend to specify exact version numbers, right? That could be a real headache. I don't think we can ignore the version number, but we cannot use it as a hard dependency either. Cheers, Marcus The install:install-file plugin does almost what Arnaud suggests: http://maven.apache.org/guides/mini/guide-installing-3rd-party-jars.html mvn install:install-file -Dfile=path-to-file -DgroupId=group-id \ -DartifactId=artifact-id -Dversion=version \ -Dpackaging=packaging But I wonder just how important it is to have a system-wide local repo? It would certainly reduce the number of Jars an end-user needed to download (clearly a good thing), but it seems like a lot of work (for us). I assume it's going to be a necessity for us for reproducible offline maven builds to inform maven about our own jars. cheers, dalibor topic Yes, I'd agree with that. When using maven as part of a Debian package build, you'd need to use install:install-file or similar to create a (presumably temporary) maven repo from the jars in /usr/share/java. Or, more efficiently, we could just set up symlinks. What I'm not so sure about is exporting the jars in /usr/share/java as a Maven repo to *end users*. I can see it would be a useful way to reduce network traffic (especially on multi-user systems), but it seems like a lot of additional complexity and work for a relatively small gain. The system admin could always set up a Maven-Proxy (http://maven-proxy.codehaus.org/). Just my opinion, of course, but I think there's a lot of things that should be higher priority. Thanks, Paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#454077: maven2: maven-eclipse-plugin does not exist
On Mon, December 3, 2007 01:48, Amelia A Lewis wrote: [. . .] Note that the first attempt to invoke eclipse:eclipse used this command line (as advised in hudson build notes): mvn -o -DdownloadSources=true eclipse:eclipse Yes, they advise offline mode. It appears that this may create the directory with inadequate stuff, because once I delete the directory and run the command without -o, it succeeds. Problem solved. Good. Im glad youve solved it. Thank you for your time, and please excuse my verbosity. I recommend: 1) close this bug with no action; it resulted from wrongheaded directions supplied by a mavenized project over which Debian has no influence; 2) note the behavior, in case future bug reports show similar symptoms: if a user reports an error of this sort, suggest that they try deleting the problem directory in their repository, and that they verify that they're not running in offline mode (even if the project suggests doing so; hudson suggests mvn install and then mvn -o -DdownloadSources=true eclipse:eclipse, but since the maven-eclipse-plugin isn't installed by mvn install, the offline invocation appears to be the thing that stuffs up the repository completely). Or, to shorten the suggestion: ask anyone reporting similar behavior to check the content of the directory corresponding to the 'not found' dependency; if it contains only *.xml without *.pom/*.jar (or a version subdirectory), delete the directory from the repo and reinvoke with all possible offline flags turned off. Thanks Ill do that. ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#454087: maven2: New upstream version (2.0.8) released.
Package: maven2 Version: 2.0.7-2 Severity: wishlist 2.0.8 was released on 27-Nov-07 ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: Joining the team
Tiago Saboga wrote: Hi! I have finished the packaging of omegat [1] and libhtmlparser-java [2] and I think it would be better to join the java packaging team. What's the way to go? Should I just upload to mentors and ask here for a sponsor? Thanks, Tiago Saboga. [1] - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448867 [2] - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448872 Hi Tiago, Good to hear from you! I'm not a DD, so I can't offer to create an account for you or sponsor your uploads, I'm afraid. One of the pkg-java admins should get in touch with you soon. In the mean time I think it would be a good idea to upload your packages to mentors.d.n and send the location of the .dsc files to [EMAIL PROTECTED] By the way, have you already created an account on alioth.debian.net (you will need one to get svn access)? Thanks, Paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#449188: Confirmed: missing from wagon-ssh-common.jar
tags 449188 +confirmed thanks Thanks for the report. org/apache/maven/wagon/providers/ssh/knownhost/ is present in upstream's wagon-ssh-common-1.0-beta-2.jar but not in Debian's. I'll fix it and check for other missing packages. Thanks, Paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: [EMAIL PROTECTED]: javacc help needed]
Rene Engelhard wrote: Gar. Double typo... - Forwarded message from Rene Engelhard [EMAIL PROTECTED] - Date: Sun, 4 Nov 2007 17:28:34 +0100 From: Rene Engelhard [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: javacc help needed Organization: The Debian Project User-Agent: Mutt/1.5.17 (2007-11-01) Hi, the recently accepted flutejava and flute-1.3-jfree packages use a javacc generated parser - but they currently ship one pre-generated which is not really the ideal way. I don't feel comfortable uploading those to unstable with a parser not being able to rebuilt/fixed if needed; this in turn holds some packages up from being uploaded to unstable which in turn hold up OpenOffice.org 2.3.x being uploaded to unstable.. :/ When removing the generated files, re-building the parser and trying the build it fails, though (not at the 6 ;) ) when trying to build the stuff: http://zyklop.dyndns.org/~rene/flute-1.3-jfree_20061107-2_amd64.build http://zyklop.dyndns.org/~rene/flutejava_1.3-3_amd64.build which both boil to Unhandled exception type ParseException. Is there anyone javacc-knowledgeable who wants to look and tell me what I am/upstream is doing wrong and how to regenerate the parser? (apt-get source flutejava/flute-1.3-jfree; look for FIXME ;) ) Regards, Rene At first sight it looks as though upstream have provided their own ParseException class, replacing the one that JavaCC would normally generate. This sort of thing is not that unusual with JavaCC, as JavaCC doesn't provide easy ways for developers to specify base classes for Token, SimpleNode, ParseException etc (some of that will change in JavaCC 4.1). I'll have a closer look later on. Thanks, Paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#445006: maven2: Selects first JRE found, ignoring alternatives (pending upload).
tags 445006 +pending thanks The fix I previously suggested for this bug would not work with java-gcj, due to the different ways the Java packages are set up in the alternatives system. E.g. /usr/bin/java - /etc/alternatives/java - /usr/lib/jvm/java-1.5.0-sun/jre/bin/java /usr/bin/java - /etc/alternatives/java - /usr/lib/jvm/java-gcj/bin/java - /usr/bin/gij-4.2 I've modified the solution slightly to follow each individual symlink (starting from the file returned by `which java`) until we find a directory somewhere within the /usr/lib/jvm tree. At this point we can correctly set up JAVA_HOME. If no JAVA_HOME has been found then I assume it is a user-installed JRE and set JAVA_HOME appropriately. I've tested it using java-6-sun, java-gcj, and a JDK installed under $HOME. If you've any comments or corrections I would be pleased to hear them. The full version of the patch can be found in http://svn.debian.org/wsvn/pkg-java/trunk/maven2/debian/patches/mvn-cmd.patch?op=filerev=0sc=0 Thanks, Paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#445006: maven2: Selects first JRE found, ignoring alternatives
Michael Koch wrote: On Tue, Oct 02, 2007 at 06:37:55PM +0200, Krzysztof Sobolewski wrote: Package: maven2 Version: 2.0.7-1 Severity: normal I have two Java packages installed: sun-java5-jre and sun-java6-jre. The latter is selected as /usr/bin/java by update-java-alternatives. Now when Maven starts, it tries to select $JAVA_HOME by looking into places where it might find Java (/usr/lib/jvm), apparently giving priority to Sun packages. Unfortunately, in my case, it selects java-1.5.0-sun, because it comes up first. This is mostly fine, but creates problems when, for example, I'm compiling a program that uses newer APIs. The start script should probably first try to determine where /usr/bin/java (or even `which java`) comes from. The problem is that in the past not all JVM implementations worked for all usecases. That is why we implemented a way to guess a working JVM. This is wrong when new runtimes come up or change directories where they are installed. Using /usr/bin/java would probably work for Maven but /usr is no suitable setting for JAVA_HOME. I dont really know what a good solution might be here. Probably its using /usr as JAVA_HOME and /usr/bin/java as Java virtual machine and let the local admin decide which runtime to use. What are the opinion of others about this? Cheers, Michael At the very least mvn should select later Sun runtimes in preference to older ones. For the benefit of other users looking at this bug log, I'd better point out that you can explicitly set JAVA_HOME and mvn will not override the setting. E.g. export JAVA_HOME=$HOME/jdk1.6 mvn install I've done some experimenting with maven, leaving JAVA_HOME blank but setting JAVACMD=/usr/bin/java. You can certainly compile assemble maven with that configuration, but I suppose there might be some plugin that depends on JAVA_HOME. What about if we follow this algorithm to determine JAVA_HOME (assuming it is not already set)? (1) Keep following the symbolic link /usr/bin/java until you get to a plain file. (2) Traverse up the directory tree until you are in a directory where there is a lib/tools.jar file. (3) If step (2) fails, then try traversing up the tree until you find a directory with a bin subdirectory. E.g. if /usr/bin/java - /etc/alternatives/java and /etc/alternatives/java - /usr/lib/jvm/java-6-sun/jre/bin/java set JAVA_HOME=/usr/lib/jvm/java-6-sun ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#432540: tagging 432540, tagging 305325, tagging 433350, tagging 434316
Lucas Nussbaum wrote: On 21/08/07 at 22:24 +0100, Paul Cager wrote: # Automatically generated email from bts, devscripts version 2.10.6 tags 432540 + pending tags 305325 + pending tags 433350 + pending tags 434316 + pending Hi, This has been pending for more than a month. Is your upload blocked by something else? Hi Lucas, Thanks for the reminder. I tagged the bugs as pending to show they are fixed in svn, but the package still needs some more work before it can be uploaded. The Java policy now is to use gcj rather than kaffe, but unfortunately this means ant's native2ascii task is no longer supported. I'm working on it, but my Debian time is a bit restricted at the moment (due to a rather nasty virus - and not the computer kind!) Paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: Bug#441640: wagon: FTBFS: The import com.jcraft cannot be resolved
Lucas Nussbaum wrote: Package: wagon version: 1.0-beta-2-1 Severity: serious User: [EMAIL PROTECTED] Usertags: qa-ftbfs-20070905 qa-ftbfs Justification: FTBFS on i386 Hi, During a rebuild of all packages in sid, your package failed to build on i386. [...] The full build log is available from http://people.debian.org/~lucas/logs/2007/09/05 It looks as though the build used the old jsch: Get:99 http://idpot.grenoble.grid5000.fr sid/main libjsch-java 0.1.34-1 [170kB] This version of jsch had a duff symlink pointing to the old (now non-existent) jsch-0.1.28.jar. It builds OK in pbuilder with the new jsch (0.1.34ds1-1) which entered unstable just after this FTBFS, so I'm closing the bug. ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#434316: Location of (new) checkstyle dtd and xsl files.
Using locations: /usr/share/checkstyle/dtd /usr/share/checkstyle/xsl seems to fit in with what other packages do. Unless anyone can think of better locations, that's what I'll implement. Thanks, Paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
[Fwd: Re: [pkg-java] r3873 - in trunk/maven2/debian: . patches]
Woops - meant to send this to the list... Original Message Subject: Re: [pkg-java] r3873 - in trunk/maven2/debian: . patches Date: Thu, 19 Jul 2007 20:23:25 +0100 From: Paul Cager [EMAIL PROTECTED] To: Trygve Laugstøl [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] Trygve Laugstøl wrote: [EMAIL PROTECTED] wrote: Added: trunk/maven2/debian/patches/mvn-cmd.patch === --- trunk/maven2/debian/patches/mvn-cmd.patch (rev 0) +++ trunk/maven2/debian/patches/mvn-cmd.patch2007-07-17 22:19:21 UTC (rev 3873) @@ -0,0 +1,18 @@ +diff -Nur maven/maven-core/src/bin/mvn maven.new/maven-core/src/bin/mvn +--- maven/maven-core/src/bin/mvn2007-03-25 06:06:10.0 +0100 maven.new/maven-core/src/bin/mvn2007-07-17 22:44:52.0 +0100 +@@ -37,6 +37,14 @@ + # + + ++if [ -z $M2_HOME ] ; then ++ M2_HOME=/usr/share/maven2 ++fi ++ ++if [ -z $JAVA_HOME ] ; then ++ JAVA_HOME=/usr ++fi That one is most likely not going to work as /usr isn't a standard Java home. Maven assumes it can find tools.jar under $JAVA_HOME/lib/tools.jar IIRC. I'll investigate it. It was copied directly from Michael's maven2-binary package. Paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: plexus-i18n_1.0-beta-6-1_i386.changes REJECTED
Joerg Jaspert wrote: Hi Maintainer, rejected, i cant find the license info in the tarball. The only thing i find is one file that contains Apache 1.1, nothing else, and that was a file from the testsuite. Please talk with upstream to enhance this and then reupload. Thanks. Woops - why didn't I notice that? I'll sort it out with upstream. ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#433350: checkstyle: New upstream version available
Package: checkstyle Severity: wishlist Release 4.3 Fixed Bugs: * The StrictDuplicateCode check didn't report correct results when multiple duplicate code regions were overlapping. (bug 1564465) * Fixed NPE in FallThrough check (bug 1472228) * Fixed typo in Command Line example (bug 1464595) * RegexpHeader check now correctly report problematic line in file with regexps for header (bug 1455575) * Fixed small problem in usage checks (patch 1498920). Thanks to Chris Povirk (cpovirk) for submitting the patch. * Fixed incorrect french translation (bug 1611403). Thanks to Fabien Bergeret for providing the correct value. New features: * Major performance improvements in the StrictDuplicateCode check, especially for large projects. Also, false alarms are no longer possible. * New CrossLanguageRegexpHeader check that allows checking file headers for other languages than Java. * Applied patch 1586411 from Dennis Lundberg (dennislundberg) to add Maven POM files to the build. Release 4.2 New features: * NoWhitespaceAfter check now accepts TYPECAST token to check is there is no whitespace after typecast. (rfe 1248106). * IllegalType can be configured to accept some abstract classes which matches to regexp of illegal type names (property legalAbstractClassNames, rfe 953266). Thanks to Paul Guyot (pguyot) for submitting patch. * TrailingComment now can be configured to accept some trailing comments (such as NOI18N) (property legalComment, rfe 1385344). * Added WriteTag check which outputs a JavaDoc tag as information (patch 902110) Thanks to Daniel Grenner (dgrenner) for contribution. * Support for suppressing audit events based on an identifier that is assigned to individual modules/checks. This allows for suppressing at a finer level than the check class name. See SuppressionFilter documentation for more. * Added the style sheet checkstyle-frames.xsl, thanks to Paul King. (Bug 1385095). * Applied patch (1505376) by Clint Stotesbery to support the suppressLoadErrors property for AbstractTypeAwareCheck (RFE 1491630). * Upgraded to ANTLR 2.7.6. * GUI now displays a TextArea with the contents of the file parsed. Based on patch from sermojohn (RFE 1499180). Fixed Bugs: * First attempt to fix 192 (RightCurlyCheck misbehaves for LIT_CATCH). The check has been rewritten to check rcurly after finally and else. Current behavior is incompatible with previous one. * Fixed problem in type aware checks with loading inner-classes which were referenced as outer_class_name.inner_class_name (bug 1379666, modules JavadocMethod and RedundantThrows). * Fix UTF-8 encoding error in XMLLogger. (bug 1369589). * The new property logLoadErrors of the JavaDocMethod check now allows controlling the behaviour when checkstyle cannot load a class that is referenced in javadoc (bug 1422462). * Tighten up the allowed use of the [EMAIL PROTECTED] tag. * Stop creating duplicate regular expression patterns. ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#432540: checkstyle: FTBFS: Illegal class or package name '/usr/lib/kaffe/pthreads/jre/lib/glibj.zip:/usr/lib/kaffe/pthreads/lib/tools.jar'
Michael Koch wrote: On Tue, Jul 10, 2007 at 12:08:49PM +, Lucas Nussbaum wrote: BUILD FAILED /build/user/checkstyle-4.1+dfsg/build.xml:220: Javadoc returned 5 at org.apache.tools.ant.taskdefs.Javadoc.execute (Javadoc.java:2077) at org.apache.tools.ant.UnknownElement.execute (UnknownElement.java:288) at java.lang.reflect.Method.invoke0 (Method.java) at java.lang.reflect.Method.invoke (Method.java:255) at org.apache.tools.ant.dispatch.DispatchUtils.execute (DispatchUtils.java:105) at org.apache.tools.ant.Task.perform (Task.java:348) at org.apache.tools.ant.Target.execute (Target.java:357) at org.apache.tools.ant.Target.performTasks (Target.java:385) at org.apache.tools.ant.Project.executeSortedTargets (Project.java:1329) at org.apache.tools.ant.Project.executeTarget (Project.java:1298) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets (DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets (Project.java:1181) at org.apache.tools.ant.Main.runBuild (Main.java:698) at org.apache.tools.ant.Main.startAnt (Main.java:199) at org.apache.tools.ant.Main.start (Main.java:161) at org.apache.tools.ant.Main.main (Main.java:250) This is a regression from ant 1.6.5 - 1.7.0. It builds fine with old ant packages. I'm looking into a solution. Cheers, Michael checkstyle has other build problems, though, and I think this would be a good time to revamp it. ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
libjcalendar-java - package ownership.
Hi Eric, Can I just check that you intended to donate libjcalendar-java to the pkg-java team? It's in the svn but never made it into an upload. If that's OK then I will merge Torsten's NMU into svn and produce a new upload to record the pkg-java maintainer. Thanks, Paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: Licensing Doxia for Debian
On Tue, June 19, 2007 1:02 am, Paul Cager wrote: Hi Jason, Sorry to bother you again, but you are also listed as the Project Lead for Doxia. I'm intending to package Doxia for the Debian distribution, but noticed that some source files do not have any copyright or license information within them. Would it be possible to fix this? As before I'd be happy to help if there is anything I could do. Thanks, Paul These files have no copyright statement or license declaration: doxia-sink-api/src/main/java/org/codehaus/doxia/sink/Sink.java doxia-core/src/main/java/org/apache/maven/doxia/module/confluence/parser/table/TableRowBlock.java doxia-core/src/main/java/org/apache/maven/doxia/module/confluence/parser/SectionBlock.java doxia-core/src/main/java/org/apache/maven/doxia/module/common/ByLineReaderSource.java doxia-core/src/main/java/org/apache/maven/doxia/module/common/ByLineSource.java These files have Copyright (c) 2005 Your Corporation. All Rights Reserved with no license declaration: doxia-core/src/main/java/org/apache/maven/doxia/module/confluence/parser/SectionBlockParser.java doxia-core/src/main/java/org/apache/maven/doxia/module/confluence/parser/VerbatimBlock.java doxia-core/src/main/java/org/apache/maven/doxia/module/confluence/parser/VerbatimBlockParser.java doxia-core/src/main/java/org/apache/maven/doxia/module/confluence/parser/TextBlock.java For information, I have created a JIRA issue for this: http://jira.codehaus.org/browse/DOXIA-126 Thanks, Paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: Licensing plexus-velocity.
On Sat, June 16, 2007 11:27 am, Paul Cager wrote: Hi Jason, I'm intending to package plexus-velocity for the Debian distribution, but noticed that the source files do not have any license information within them. Would it be possible to fix it? Can I help in any way? Thanks, Paul i have raised a JIRA issue for this problem: http://jira.codehaus.org/browse/PLX-342 ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: Licensing Doxia for Debian
On Mon, July 2, 2007 3:59 pm, Paul Cager wrote: On Tue, June 19, 2007 1:02 am, Paul Cager wrote: I'm intending to package Doxia for the Debian distribution, but noticed that some source files do not have any copyright or license information within them. These files have no copyright statement or license declaration: [...] These files have Copyright (c) 2005 Your Corporation. All Rights Reserved with no license declaration: [...] For information, I have created a JIRA issue for this: http://jira.codehaus.org/browse/DOXIA-126 This problem has already been fixed by upstream, but not yet released: http://svn.apache.org/viewvc?view=revrevision=496703 I think this should be enough to satisfy the ftp-masters. ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: Licensing plexus-velocity.
Jason van Zyl wrote: It's all ASL licensed if not marked as such. On 2 Jul 07, at 8:06 AM 2 Jul 07, Paul Cager wrote: On Sat, June 16, 2007 11:27 am, Paul Cager wrote: Hi Jason, I'm intending to package plexus-velocity for the Debian distribution, but noticed that the source files do not have any license information within them. Would it be possible to fix it? Can I help in any way? Provide patches that make the files look like this: http://svn.codehaus.org/plexus/plexus-containers/trunk/plexus-container-default/src/main/java/org/codehaus/plexus/DefaultComponentLookupManager.java Jason, Thanks for the advice. I have attached a patch to the JIRA issue: http://jira.codehaus.org/secure/attachment/28239/PLX-342.patch Thanks, Paul Or, I'll give you temporary access to fix whatever files you find need fixing. I don't have time change this stuff right now, but I'll eventually get there as I will propose to move Plexus to Apache at some point in the near future. Thanks, Paul i have raised a JIRA issue for this problem: http://jira.codehaus.org/browse/PLX-342 Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Licensing Doxia for Debian
Hi Jason, Sorry to bother you again, but you are also listed as the Project Lead for Doxia. I'm intending to package Doxia for the Debian distribution, but noticed that some source files do not have any copyright or license information within them. Would it be possible to fix this? As before I'd be happy to help if there is anything I could do. Thanks, Paul These files have no copyright statement or license declaration: doxia-sink-api/src/main/java/org/codehaus/doxia/sink/Sink.java doxia-core/src/main/java/org/apache/maven/doxia/module/confluence/parser/table/TableRowBlock.java doxia-core/src/main/java/org/apache/maven/doxia/module/confluence/parser/SectionBlock.java doxia-core/src/main/java/org/apache/maven/doxia/module/common/ByLineReaderSource.java doxia-core/src/main/java/org/apache/maven/doxia/module/common/ByLineSource.java These files have Copyright (c) 2005 Your Corporation. All Rights Reserved with no license declaration: doxia-core/src/main/java/org/apache/maven/doxia/module/confluence/parser/SectionBlockParser.java doxia-core/src/main/java/org/apache/maven/doxia/module/confluence/parser/VerbatimBlock.java doxia-core/src/main/java/org/apache/maven/doxia/module/confluence/parser/VerbatimBlockParser.java doxia-core/src/main/java/org/apache/maven/doxia/module/confluence/parser/TextBlock.java ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Licensing plexus-velocity.
Hi Jason, I'm intending to package plexus-velocity for the Debian distribution, but noticed that the source files do not have any license information within them. Would it be possible to fix it? Can I help in any way? Thanks, Paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
maven-ant-helper ready for upload?
Hi Trygve, Is your maven-ant-helper ready to be uploaded to the new queue now? If so would you like me to ask Michael if he's available to look at it? Thanks, paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: [pkg-java] r3601 - trunk/maven2/debian
On Wed, June 6, 2007 1:36 pm, Trygve Laugstøl wrote: -maven2 (2.0.6-1) unstable; urgency=low +maven2 (2.0.6-0.1) unstable; urgency=low Why 0.1 and not 1 as the other packages are using? Just a reminder (to myself as much as anyone else) that it is definitely, absolutely, postively not finished yet. ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#389887: More information required.
tags 389887 + moreinfo thanks Regarding your Debian bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389887 I am not sure if I understand the problem you are reporting. If you want to include a Jar on your classpath you must user the filename of the Jar itself, not just the owning directory, e.g. java -cp /usr/share/java/foo.jar your.package.YourClassName Please can you give me some examples of failing Java source and command line invocation? Thanks, Paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: maven2 in svn
On Wed, May 30, 2007 8:19 am, Trygve Laugstøl wrote: Paul Cager wrote: Paul Cager wrote: On Mon, May 28, 2007 10:59 am, Trygve Laugstøl wrote: Paul Cager wrote: By the way, I've hit a few problems with maven-ant-helper. Do you mind if I commit a few changes? Sure, go ahead. We're a team after all :) Just make sure you apply the patch I submitted last night as that fixes a few issues. I'd forgotten about the maven-ant-helper patches. I'll apply them and see if the problems go away. Trygve, I've now committed your patch to svn, and it fixes the problems I were experiencing. I made one small tweak - changing plexus-utils.jar to libplexus-utils.jar (we should add another symlink next time we upload plexus-utils). I though that it was supposed to be plexus-utils.jar and that the libplexus-utils source package should go away? Yes it should be plexus-utils.jar. I changed it just as a temporary measure until the libplexus-utils package could be fixed. Its rather complicated, and it's all my fault! Let me explain: I created svn directory plexus-utils not realising there was already an old libplexus-utils svn directory (and package in main). When I realised my mistake I started to edit libplexus-utils instead. But I forgot to delete plexus-utils. I introduced a bug in libplexus-utils such that the Jar is named libplexus-utils.jar. You then edited svn plexus-utils, changing release (1.4.1+svn6048-1) to (1.4.1-1). So I guess we should: * Copy your changes from plexus-utils to libplexus-utils. * Delete the plexus-utils svn directory. There's one more problem: we'll have to convince dak that your package is newer than the one already in unstable. I'm not sure of the best way to do this: * Use an epoch (and be stuck with it forever). * Fiddle the version number to (e.g.) 1.4.1.1debian * Create a separate source package, maven-plexus-utils. * Change the package so that the orig tarball contains 2 versions of the code, and creates two versions of the Jar (yuk). Any ideas? ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: maven2 in svn
Paul Cager wrote: On Mon, May 28, 2007 10:59 am, Trygve Laugstøl wrote: Paul Cager wrote: By the way, I've hit a few problems with maven-ant-helper. Do you mind if I commit a few changes? Sure, go ahead. We're a team after all :) Just make sure you apply the patch I submitted last night as that fixes a few issues. I'd forgotten about the maven-ant-helper patches. I'll apply them and see if the problems go away. Trygve, I've now committed your patch to svn, and it fixes the problems I were experiencing. I made one small tweak - changing plexus-utils.jar to libplexus-utils.jar (we should add another symlink next time we upload plexus-utils). Thanks, Paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: maven2 in svn
Trygve Laugstøl wrote: Trygve Laugstøl wrote: Numbers of errors with the correct plexus-container-default (1.0-alpha-9-stable-1) is now 14 and they are all related to Doxia or plexus component factories. Do you have an updated package for modello (in particular one that builds the generated-sources) or did you use an upstream binary? I'll update my version if not. Possibly modello is one we'll *have* to bootstrap. Are there still problems using the modern Plexus components? Doxia should be fairly simple to package and possibly the component factories too. The factories might also just be dropped for now, Maven 2 will build most stuff without them. So I couldn't resist and started packaging Doxia. Doxia is missing two components: plexus-i18n and plexus-velocity which should be fairly trivial to package with maven-ant-helper. Don't you *ever* sleep? I had already filed ITPs for plexus-velocity and component-factories, but if you'd like to take over please feel free to do so. I've attached the doxia build (can you commit that for me Paul?) and a maven-ant-helper diff. I think Vladimir is part way through packaging doxia. Maybe you two could combine efforts? By the way, I've hit a few problems with maven-ant-helper. Do you mind if I commit a few changes? Thanks, Paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
maven2 in svn
I've created a maven2/debian directory in the project's svn. Of course we are far from being able to compile it, let alone upload a package. But at least it should gives us something to aim for. Number of build errors is currently hovering around 50. Watch this space... ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#421428: ITP: commons-openpgp -- a common and simple Java interface for generating and verifying OpenPGP signatures
Package: wnpp Severity: wishlist Owner: Paul Cager [EMAIL PROTECTED] * Package name: commons-openpgp Version : svn 533437 Upstream Author : Brett Porter, Stefan Bodewig * URL : http://jakarta.apache.org/commons/sandbox/openpgp/index.html * License : Apache V2 Programming Lang: Java Description : a common and simple Java interface for generating and verifying OpenPGP signatures Commons OpenPGP was started to produce a common and simple interface for generating and verifying OpenPGP signatures. Currently implemented using BouncyCastle, it is intended to allow pluggable providers so that alternate open source and commercial providers can be used. The library was started by Maven and Ant committers to enable the use of OpenPGP from these tools. Currently, Maven uses it in its development version to sign libraries released to the repository. ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#341405: Proposed fix
This happens because the default URL for the help file is /index.html (in default.properties). This will obviously not work. I'll attempt to improve the situation when I package the new upstream version (2.6). ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#341430: JTA - ssh documentation.
I found it quite difficult to locate this information on javassh.org's web site. The command line required is of the form: java -jar jta26.jar -plugins Status,Socket,SSH,Terminal hostname 22 (or you can use an equivalent config file). I'll update the package's description and README when I next upload it. ___ pkg-java-maintainers mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#353586: ant-bootstrap.jar failure
EspeonEefi wrote:
reopen 353586
severity 353586 minor
thanks
I can reproduce this error using the attached very simple build.xml and
HelloWorld java program. Indeed, ant by default still automatically
adds /usr/share/ant/lib/ant-bootstrap.jar to the classpath. Note, though
that the warning occurs only when the -Xlint compilerarg is passed to
javac, and the warnings don't make anything fail, so I've downgraded the
severity of this bug to minor.
Just as a refresher, the output that ant build gives is
Buildfile: build.xml
build:
[javac] Compiling 1 source file
[javac] warning: [path] bad path element
/usr/share/ant/lib/xml-apis.jar: no such file or directory
[javac] warning: [path] bad path element
/usr/share/ant/lib/xercesImpl.jar: no such file or directory
[javac] warning: [path] bad path element /usr/share/ant/lib/xalan.jar:
no such file or directory
[javac] 3 warnings
BUILD SUCCESSFUL
Total time: 2 seconds
Some Googling turns up that the above warnings may be a result of
extraneous things in the Class-Path attribute in the
META-INF/MANIFEST.MF file of a JAR. Indeed, when I
unjar /usr/share/ant/lib/ant-bootstrap.jar, I find in
META-INF/MANIFEST.MF the line
Class-Path: ant.jar xml-apis.jar xercesImpl.jar xalan.jar
Now, according to the documentation for the JAR file format [1], the
Class-Path attribute specifies the relative URLs of the extensions or
libraries that this application or extension needs. This is why javac
is looking for xml-apis.jar, xercesImpl.jar, and xalan.jar
in /usr/share/ant/lib/ (the same directory as ant-bootstrap.jar) and not
in /usr/share/java/, where at least xercesImpl.jar lives. (Given that
ant now uses Xerces and not Xalan, it's interesting that xml-apis.jar
and xalan.jar still show up in this Class-Path line.)
[1] http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Main%20Attributes
Thus, this is indeed a bug in ant that the Class-Path attribute in
MANIFEST.MF in ant-bootstrap.jar is referencing non-existent jars.
public class HelloWorld {
public static void main(String[] args) {
System.out.println(Hello, world!);
}
}
Thank you for investigating this further. Yes, you are quite right -
bootstrap.jar is in /usr/share/ant/lib/ and *will* be included in the
class path.
Looking at the Apache binary download (of 1.7), I see that the bootstrap
Jar is normally in the etc directory, and the Debian packaging moves
it to /usr/share/ant/lib/. I am not sure this is the correct place for
the bootstrap Jar to live (but I agree that etc isn't the correct
place either). In fact, do we need to deliver it at all in the binary
deb package?
Maybe this bug can be fixed when the next upstream version is packaged?
Thanks,
Paul
___
pkg-java-maintainers mailing list
pkg-java-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#397045: ant - java-gcj-compat-dev as dependency
Michael Koch wrote: On Sun, Mar 04, 2007 at 01:35:12AM +, Paul Cager wrote: Currently: Depends: java-gcj-compat | java-virtual-machine, java-gcj-compat | java1-runtime | java2-runtime, libxerces2-java Recommends: ant-optional, jikes | java-compiler Should ant Depend or Suggest the compiler packages? I'd say Depend, but I suppose its not an absolute dependency - you could have a buildfile that doesn't call javac. Recommends is the right thing. Its no hard dependency but its the used/needed in most cases. Recommends are installe by default by aptitude and synaptic but you can choose to deinstall or not install at all the compiler. IMO that bug should just be closed as people need to be aware what they break when they dont install the Recommends. From the Debian Policy 7.2: Recommends This declares a strong, but not absolute, dependency. The Recommends field should list packages that would be found together with this one in all but unusual installations. Cheers, Michael I must learn not to write these things late at night - where I'd written Suggest, I meant Recommend. apt-get won't, of course, install the recommended packages, but I don't think I can put up any strong defence for Depends, which is defined in the policy as: required ... to provide a significant amount of functionality I admit defeat and agree it should be Recommends. The warning message unable to locate tools.jar is a bit cryptic, but it should be followed later by an error Unable to find a javac compiler. Is there anything else we could do to make it more obvious to the user that he/she needs to install a compiler? Amend the package's description maybe? Expand the Debian Java FAQ? ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#397045: ant - java-gcj-compat-dev as dependency
Currently: Depends: java-gcj-compat | java-virtual-machine, java-gcj-compat | java1-runtime | java2-runtime, libxerces2-java Recommends: ant-optional, jikes | java-compiler Should ant Depend or Suggest the compiler packages? I'd say Depend, but I suppose its not an absolute dependency - you could have a buildfile that doesn't call javac. ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#411929: RFP: imagefilters-java -- manipulation and filtering of images in Java
Package: wnpp Severity: wishlist * Package name: imagefilters-java Version : 2.0.235 Upstream Author : Jerry Huxtable * URL : http://www.jhlabs.com/ip/filters/index.html * License : Apache 2.0 Programming Lang: Java Description : manipulation and filtering of images in Java A large number of Java Image filters which are all standard Java BufferedImageOps and can be plugged directly into existing programs. . Many of these filters are useful in applications such as games where images need to be generated on the fly, or where it's quicker to generate them rather than downloading them. For instance, it's quicker to download one image and rotate it several times than to download several separate images. . Another use for the filters is in animation. For example animating the Water Ripple filter can produce a nice rippling effect. Some of the filters have a time parameter for this purpose. . All of the filters are designed to work with TYPE_INT_ARGB images. ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#410283: RFP: jtb -- a syntax tree builder to be used with the Java Compiler Compiler (JavaCC) parser generator
Package: wnpp Severity: wishlist * Package name: jtb Version : 1.3.2 Upstream Author : Wanjun Wang [EMAIL PROTECTED] and others * URL : http://compilers.cs.ucla.edu/jtb/ * License : BSD Programming Lang: Java Description : a syntax tree builder for JavaCC JTB is a syntax tree builder to be used with the Java Compiler Compiler (JavaCC) parser generator. It takes a plain JavaCC grammar file as input and automatically generates the following: * A set of syntax tree classes based on the productions in the grammar, utilizing the Visitor design pattern. * Two interfaces: Visitor and GJVisitor. Two depth-first visitors: DepthFirstVisitor and GJDepthFirst, whose default methods simply visit the children of the current node. * A JavaCC grammar jtb.out.jj with the proper annotations to build the syntax tree during parsing. New visitors, which subclass DepthFirstVisitor or GJDepthFirst, can then override the default methods and perform various operations on and manipulate the generated syntax tree. ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#276302: JavaCC and bootstrap/javacc.jar
Hi, In CVS, bootstrap/javacc.jar has all of the old COM.sun.labs classes within it (instead of the org.javacc ones). This causes a slight problem with the packaging of JavaCC I am doing for Debian, as the Sun classes do not have a free license. How would people feel if I were to replace CVS's bootstrap/javacc.jar with one generated by the 4.0 code (and made corresponding changes to build.xmls)? I've checked that it still builds and passes its unit tests with a 4.0 Jar (well, it would be rather worrying if it didn't!) Thanks, Paul ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Tagsoup package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have imported the tagsoup package into svn. I had created this package before I became a member of pkg-java, so the version on packages.debian.org still has me as the maintainer. I've _not_ prepared a new upload just to fix this, but I have edited debian/control in svn to reflect the new team ownership. Thanks, Paul -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFsLWZLSXFtdTZVSURApXdAJwLS8BcFvuAKIKpXz/dzmzGDbcLigCeOYxM YGLnn+U5cUhra21QNU/glw0= =lMnk -END PGP SIGNATURE- ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#276302: JavaCC Licensing - now a pure BSD license.
The authors of JavaCC have now re-licensed the JavaCC code under a pure BSD license (http://www.opensource.org/licenses/bsd-license.html). This should clear up the doubts some organisations have had regarding the Nuclear and Weapons clauses in the original license, and the export restrictions imposed therein. Many thanks to the following authors who gave their permission for the relicensing: Sun Microsystems Inc, Sreenivasa Viswanadha and Kees Jan Koster. The updated source code has now been committed to the JavaCC CVS repository. ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#276302: [Fwd: Re: Sun License for JavaCC]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It looks as though upstream will be changing JavaCC to a pure BSD license, or (if we can't wait) we have been granted permission to patch the source ourselves. - Original Message Subject: Re: Sun License for JavaCC Date: Fri, 01 Dec 2006 17:42:28 -0600 From: Tom Marble [EMAIL PROTECTED] To: Paul Cager [EMAIL PROTECTED] CC: Simon Phipps [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Paul: I'm fairly familiar with debian-legal and you are right -- they will not accept this kind of license. I have inspected the code and found that the top level LICENSE file has this (non standard language) from stock BSD: http://www.opensource.org/licenses/bsd-license.html And several of the source files have incorrect and/or incomplete copyright blocks. We have approval from Sun Legal to fix these problems. Correct copyright license block would be following the OSI template (above URL) with the values: OWNER = Sun Microsystems, Inc. ORGANIZATION = Sun Microsystems, Inc. YEAR = 2006 You may make these changes as a downstream delta patch. Thank you for packaging JavaCC for Debian!!! Sreeni: Please fix the JavaCC code (upstream) with these copyright and license fixes as well. Warmest Regards, - --Tom Paul Cager wrote: Simon, As you can see below, Michael Van De Vanter felt you might be able to help me with a problem Debian Linux has encountered with the licensing of the JavaCC product. Would you mind having a look at my explanation of the problem, below, and let me know your views on the matter? Many thanks, Paul Cager Michael Van De Vanter wrote: Paul, My understanding is that your concerns can be addressed by Sun. Please contact Simon Phipps of our Open Source office to get this resolved, and cc Tom Marble and Barton George. Feel free to drop me off the conversation. There's probably little further value I can add unless historical questions arise concerning the technology or my original efforts to push it into Open Source. Fortunately, it is much easier now. Michael V. Michael L. Van De Vanter, Ph.D.Email: [EMAIL PROTECTED] Sun Microsystems Inc. Tel: +1 650 786-8864 16 Network Circle, UMPK16-304 IM: [EMAIL PROTECTED] Menlo Park, CA 94025 USA Skype: michaelvandevanter http://homepage.mac.com/mlvdv/home.html On Nov 30, 2006, at 3:05 PM, Paul Cager wrote: Michael, I am writing to you as you were the author of the original announcement that JavaCC was to be made Open Source under a BSD license (http://www.experimentalstuff.com/Technologies/JavaCC/announce.html). A long time ago, I know, but as Sun still holds the copyright on JavaCC, Sreeni co (at java.dev.net) would not be able to help. I apologise for taking up your time. A question has been raised in the Debian Linux distribution about JavaCC's license (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=276302 for the full story). As you might know, Debian has a very strict definition of Free Software, and software which doesn't meet this definition cannot become part of the main distribution. Although JavaCC is released using the BSD license, there are a couple of non-free restrictions in the LICENSE file and copyright statements at the head of the source files. The license file ends with: You acknowledge that this software is not designed, licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility. This is probably incompatible with one of Debian's guidelines: The license must not restrict anyone from making use of the program in a specific field of endeavor. So my questions: 1) Does Sun still require these non-standard clauses in the license (compared to the plain BSD license)? 2) If not, could Sun authorise the current maintainer of JavaCC (Sreeni) to remove them from the current source code? Once again, apologies for taking up your time. Thanks, Paul Cager. - -- _ [EMAIL PROTECTED] (952) 832-4123 Senior Java Performance Engineer Sun Microsystems, Inc. http://blogs.sun.com/tmarbleWhat do you want from Java Libre? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFcMaFLSXFtdTZVSURAiYcAKCR1mW91pKZh/eEdxbF75OezafVBwCfVtGn 4EXuC//3OGTf2mvgFhW2RCA= =Prkz -END PGP SIGNATURE- signature.asc Description: PGP signature ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#276302: New upstream release and license debate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've had a look at the new upstream release (4.0), and it's still not clear if it is DFSG compliant. The website[1] explicitly states that the license is Berkeley Software Distribution (BSD) License. In an answer to a query the author (Sreenivas Viswanadha) states that the entire javacc distribution, including the example grammars comes under BSD license[2]. The LICENSE file in the distribution is the standard BSD license, but with the following paragraph added at the end: You acknowledge that this software is not designed, licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility. Most of the source files contain a copyright declaration ending with: Nuclear, missile, chemical biological weapons or nuclear maritime end uses or end users, whether direct or indirect, are strictly prohibited. Export or reexport to countries subject to U.S. embargo or to entities identified on U.S. export exclusion lists, including, but not limited to, the denied persons and specially designated nationals lists is strictly prohibited. I guess that the author intends it to be truly free software, but hasn't removed all of the licensing cruft left over from its time as a proprietary Sun product - assuming he is legally entitled to do so. I'll send him an email about it. [1] https://javacc.dev.java.net/ [2] https://javacc.dev.java.net/servlets/ReadMsg?listName=usersmsgNo=919 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFbrVfLSXFtdTZVSURAqJfAJ4pndKy8aPbvLgHDwF0d4QB+QqY7ACfcSZD oOYJBxDpAPrLYvgcE6B29e0= =A9+8 -END PGP SIGNATURE- ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Request to join Debian Java Packaging Project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Please can I apply to join the Java Packaging Project. I've opened an account on alioth (paulcager-guest), and I'm subscribed to pkg-java-maintainers. A little about myself, by way of introduction... I work as a Java developer for a big UK bank. Working in a large corporation has, if anything, confirmed my enthusiasm for Free Software. I've been a Debian user for a little over a year now (having migrated from Mandrake). I'm new to Debian packaging, although I have adopted the java2html package and created the tagsoup package (thanks for all your help, Marcus!). I'd like to get involved with some of the work you do here. My main interests are in parsers and compilers, such as JavaCC, BCEL, BeanShell, checkstyle, commons-el, rhino etc. Thanks for your time, Paul -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFbgPrLSXFtdTZVSURAhGTAJ9j/tp0HPvvpV8B96SokLiv1MAk6QCaApG6 EMZ4iYc933XcM3Ze2/TPzac= =/UQx -END PGP SIGNATURE- ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
