b non-free
- dget
http://mentors.debian.net/debian/pool/main/l/libxdoclet-java/libxdoclet-java_1.2.3-4.dsc
I would be glad if someone uploaded this package for me.
Kind regards
Florian Grandel
--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe&quo
net/debian/pool/main/l/libxjavadoc-java/libxjavadoc-java_1.1-4.dsc
I would be glad if someone uploaded this package for me.
Kind regards
Florian Grandel
--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
I would be glad if someone uploaded this package for me.
Kind regards
Florian Grandel
--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hi Johan,
I wonder what the right way of building the classpath from a list of
packages is? I see that there are symlinks in /usr/share/java/ and it
seems I have to hardcode paths to these?
please have a look at the debian-java mailing list archives. You'll see
that the classpath topic has be
Hi Philipp,
Sorry, but 2.5.139 already violates this rule. The following .jar-files
marked with * don't have a source in Debian (as far as I know), + is an
older version of the one in Debian.
If this is the case then the package seems to violate DFSG (see [0]) and
should be included into the
Hi Kalle,
Kalle Kivimaa schrieb:
You can either modify the .orig.tar.gz not to include the jars, or,
IMO a better choice, modify the building process to use the Debian
provided jars. I personally prefer keeping the orig.tar.gz as close to
the original as possible (for JSPWiki all the Debian pack
Hi Onkar,
Onkar Shinde schrieb:
If there is no policy about this then I guess this good time to have one.
Because I am always told (in #ubuntu-motu) to keep the orig.tar.gz as
close as possible to upstream tarball and hence use clean target to
delete jar files.
I am still learning lot of things
Hi Philipp,
I now ask myself, when and were should I replace those libraries:
1. Only in the final debian/jspwiki/ tree (but build with the original
.jar files)
2. Each time during the debian/rules run
3. Once in the .orig.tar.gz (the download is only availabe as .zip)
I think Debian policy
Hi again,
The JPackage people have the following solution: They include the JBoss
patches into their source and produce two independent non-conflicting
binary packages from the same source package:
- one unpatched for general use (that goes into /usr/share/java) and
- one for jbossas (which go
Hi everybody,
in jbossas we have got lots of jars that are built from source by the
JBoss people upstream with patches applied to them. So they are nearly
the same as the ones we have in our own packages except for the patches
which are needed for the jars to work with jbossas.
The JPackage
Hi Manuel,
Manuel Prinz schrieb:
2. The commons-math tarball ships three jars containing the class files,
source files and documentation, respectively. Is it OK to just put them
in the Debian package (as they are) or should I extract the source and
rebuild a Debian source package from that? (The
Hi Matthew,
Matthew Johnson schrieb:
It's unclear to me what they want to be configured at runtime by
changing the classpath.
I'll ask them and report back.
I talked about the classpath issue with the jpackage guys. We didn't go
into detailed arguments as it is a minor policy issue that do
Hi Eric,
One more thought: did you check that the logic is the same between
Matthew's javahelper and your tool? Is code sharing an option?
The worse that could happen to packagers would be different results from
those two tools; I can already imagine the mess... ;-)
No. I have not compared the
Hi Eric, Matthew and Manuel,
thanks for your hints and for reviewing the package so quickly!
Manuel, I already made the changes you proposed. All of them were really
reasonable. I had to add -regextype ... to get rid of the backslashes in
find.. Single quotes alone wouldn't have done the job I
Hi java maintainers,
I have just created a package for the jaranalyzer tool [1]. This is a
tool that analyses and nicely displays dependencies between jars in a
given directory (either with graphviz as a .png image or as an xml
file). See readme.txt/man page for details.
I do not have a webs
Hi Matthew,
I have further researched this problem. To me it seems a (not too
trivial) bug in jh_manifest. See
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489214. Maybe better to
discuss the topic there to keep this list clean...
Cheers,
Florian
--
To UNSUBSCRIBE, email to [EMAIL PRO
Hi Matthew,
I am currently trying to use your jh_manifest script. I have the
following problem however:
The standard ant jar task creates a manifest with an empty line at the
end. If I apply jh_manifest this empty line remains untouched and leads
to the following MANIFEST.MF (jh_manifest add
Hi Ralf,
Creating different JAR contents than upstream only leads to user
irritation. Disk space is relativly cheap today so that should not be an
issue.
I also think that disk space is not the main issue. When I asked my
question I was more thinking about maintainability (jars with the same
Hi Matthew,
Matthew Johnson schrieb:
Ah, hmm, I think it only looks in /usr/share/java, since this was a tool
for Debian, and thats where all our jars are stored.
I forgot to mention that I modified your script to look into "my"
directory. This is a very simple modification and makes your scr
Hi Matthew,
Matthew Johnson schrieb:
It's unclear to me what they want to be configured at runtime by
changing the classpath.
I'll ask them and report back.
Wrapper scripts without classpath manifest items also result in
large classpaths containing items you shouldn't have to know about (you
Hi Java developers,
One problem that I haven't solved so far is how to get the classpath
into the MANIFEST file as was proposed earlier in this thread.
As you may have remarked from my earlier posts I am working with the
JPackage guys recently. Their "recommendation to Java developers"
argum
Hi Michael,
Michael Koch schrieb:
I would do it as upstream does it. This doesnt confuse users as that is
what they know from upstream. We had enough problems when our jars were
too mich different from upstream in the past.
Thank you very much for your opinion. That's what I was thinking as we
Hi Java-Experts,
just a quick question: In building JBoss I encounter a lot of jars that
do (partially) overlap. I didn't find anything about how to deal with
this in the Java or Debian policy. (Hope I am not just missing something!)
To give two representative examples:
client and server app
Hi Richard,
Right now I see that hibernate is available as a library package that
has put jars in /usr/share/java. If I depend on these jars and write a
unit test I discover that there are more dependencies, I need some of
the apache commons libraries and the log4j library, but I can't see
those
Hi guys,
I am currently in the process of integrating a few java applications
into a custom application stack. I have been using Debian/Ubuntu for
quite some time. That's why I thought that dpkg could be a nice
framework to do the integration. I also hoped that by sticking to a
widely used standa
25 matches
Mail list logo
