Re: Wiki page for requested packages
Quoting Bruno Dusausoy <[EMAIL PROTECTED]>: Hi all, We've put a page[1] on the Debian Wiki in order to gather the Java apps you want to be packaged. So please, feel free to add your request to the page. And of course, also feel free to help us make Java rocking on Debian ;) [1] http://wiki.debian.org/Java/RequestedPackages Thanks. I added SQuirrel SQL and JEdit. Two great apps I use nearly every day. manfred -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: maven2 for Debian
Quoting Marcus Better <[EMAIL PROTECTED]>: Another issue: Maven projects tend to specify exact version of their dependencies. For building Debian packages, we need to get Maven to use whatever version we have in Debian (and just make sure it's recent enough). Hi all! I apologize if the following questions and suggestion sound silly to you. I do not know that much about pacakging .. but I know a bit more about Java and Maven.. There is a problem with this approach that I do not understand how Debian packaging deals with anyway. In many Java projects I have seen it is quite important to use the exact version of the libraries. The Maven repository concept allows for a folder structure that keeps things together and allows different versions of the same libraries to live side by side peacefully. How does this work in Debian? From what I can tell looking at the Debian libraries for Java some use a version number and some don't. I think that should be changed so that all libraries have to have a version number in their file name and package names and allow mutliple versions to live peacefully side by side. Otherwise it will be near impossible to get a lot of different programs using the libraries without major headaches. Either from a QA and packaging perspective if we use other versions that upstream or otherwise from conflicts between differnet packages requiring different versions of libraries. As far as I can tell the problem exists because many libraries do dramatic changes to their API quite regularly .. manfred
Re: maven2 for Debian
Quoting Arnaud Vandyck <[EMAIL PROTECTED]>: On 3/5/07, Michael Koch <[EMAIL PROTECTED]> wrote: [...] I understand your point of view and respect it. But as we are responsible in some way of the software we package and distribute, we cannot distribute a software for Debian that could install non free software in all ~'s. Binary blobs are not non-free per so. If we would go your route we would have to disable download functionality in e.g. iceweasel as you are *able* to download non-free stuff with it. The download feature in Maven is no problem per se. We just need to figure out how we exactly handle non-installed dependencies. How was it build? What are the build/runtime dependencies? These sort of things will be a headache. Example: Hibernate have a dependency with transaction api you have to download to Sun website; Spring, Maven have dependencies against javamail, activation you have to download from Sun's website. And for the last two one, we have free implementations. Are these implementations in the maven repository so the user could use the free implementation or is (s)he obliged to use the Maven proprietary one? Tom Marble told me he'll work on that issue where a lot of Sun's libraries must be downloaded from Sun website with a click on the agreement, no source to build them and a non-free license (Sun binary...), but in the mean time, what do we do? There is a additional repositories that host that sort of stuff and a lot of other libraries. E.g. the java.net maven repo has a lot of the stuff you are talking about, the codehaus repo has a lot of other extensions. The packaging team should not worry about that. The maven user will with the pom for his own project. It is also common for maven users to create their own repository with their build artifact and other libraries that simply are not available anywhere in a repositoryt. it is quite simple to add one (as long as you dont worry about its dependencies...) Anyway.. from a user perspective I think it would be great if it just behaves like upstream and pumps stuff in ~/.m2 like normal. manfred
Re: maven2 for Debian
Quoting Michael Koch <[EMAIL PROTECTED]>: On Mon, Mar 05, 2007 at 04:27:04PM +0100, Marcus Better wrote: Arnaud Vandyck wrote: > I was not talking of the dependencies version problem for debian but > for someone using maven in debian with a debian repository ;-) I don't see the need for a special Debian-Maven repository. Me neither. I agree. I talked to Jazon van Zyl (Maven founder) recently at a java user group meeting and he told me that they do not really control the repository either. It is pretty much free for anybody to put stuff up there. Which explains the quality of some of the artifacts up there with broken poms and so on. Trying to control it initially proofed to be too much work. If the upstream projects does not control it I would suggest that Debian packaging not waste the time either. manfred -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: maven2 for Debian
Quoting Marcus Better <[EMAIL PROTECTED]>: [EMAIL PROTECTED] wrote: As far as I can tell the problem exists because many libraries do dramatic changes to their API quite regularly .. Major API changes may warrant having two different versions of a library in Debian. This happens from time to time. However if such changes happen very often it is a sign of an immature or badly designed library that perhaps shouldn't be in Debian in the first place. Hm... this might be the case. Or it might just mean that the project is very dynamic. How are you going to decide when too many changes are too many? How can you tell if the API changes affect the quality. Wouldn't it just be easier to use the same version as upstream so that you do not create additional work in terms of packaging, QA and so on as well as complexities for debugging. Wouldnt we also cause problems for upstream doing that since they might get bug reports from it. I think it would be better to just leave the version as is and accept that multiple version sit around on the file system. They don' cause any harm anyway. manfred
Re: maven2 for Debian
Quoting Michael Koch <[EMAIL PROTECTED]>: Debian always installs jars with ther version number. The files without version numbers are just symlinks to the latest version. Ah... thats good to know. Debian only packages one (the latest) version of a Java software. Everthing else would be a horror to support, security- and bloat-wise. I understand that for acutal programs. However can that work for libraries. You might have to perfectly fine and stable GUI programs. E.g. one using Java 1.4 features and another using brand spanking new Java 6 features and the share the need to the same library but in a VERY different version. Unless we somehow keep both libraries around you can not use both programs. We patch the Java software to all use the same version of a Java library. Wow.. from my refactoring experience in Java that should potentially be a LOT of work. Its a bit like redoing the whole upstream release and QA cycle. Hats off to you all. This is Debian handles it. And its the only possible way for Debian because of long release cycles with security support and all that. This means a lot of work. I dont think this can be the only option. Two very different version of a library can still be very stable and secure and useful for different programs. Is there any chance that this approach is being reconsidered? With Maven we will give the user the opportunity to be more uptodate with Java software installed side-by-side with Debian packages. Yeah.. but Maven does not do all the nice integration like executable in /usr/bin, desktop icons, version upgrade notification and so on. Packaging the applications is still the way to go as far as I understand to get it to the end user in a seamless way. manfred
Re: maven2 for Debian
Quoting Marcus Better <[EMAIL PROTECTED]>: [EMAIL PROTECTED] wrote: I think it would be better to just leave the version as is and accept that multiple version sit around on the file system. They don' cause any harm anyway. The Debian package will support this for _users_, it will work just like the upstream Maven. For Debian packaging work it is a different story, as Michael explained we cannot support a dozen versions of the same package as part of the Debian system. I don't think this will be a huge problem for us. Even dynamic projects don't make stable releases that often. Hm. what if there are two stable versions of a library that are incompatible and are used by two stable programs? Then we need different library version in the one system. E.g. JFreeChart had multiple stable releases that are incomaptible with each other for a long time and different programs were using different versions. JasperReports did the same. Manfred -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: maven2 for Debian
Quoting Michael Koch <[EMAIL PROTECTED]>: I dont think this can be the only option. Two very different version of a library can still be very stable and secure and useful for different programs. Is there any chance that this approach is being reconsidered? I dont think so. Every duplicated library can create duplicated work for the Debian security work. Consider some artificial java library which handles URLs and their content as an example. Due to a small bug in URL handling this library allows access to system restricted files. This library is now in 3 different versions in Debian. In a stable Debian release the Debian security team has to fix, test, upload 3 libraries instead of the only one we normally have in the archive. Think of a library that is 10 or 20 times in the archive. Debian is a free-time project. Even the security team does everything in their free-time. We should not put more burden on them then really needed. I understand that and I agree. However doesn't the change of library invalidate the upstream QA process that includes security and potentially is more extensive than the Debian one (at least it should be). If so .. how do you weigh the pros and cons? I think multiple versions of a library is sometimes necessary but should be limited to where it is necessary. Just my 2c as an apprentice... there is lots to learn for me ;-) manfred
Re: maven2 for Debian
Hi all! Different follow up on that package. I have installed it on Ubuntu Edgy and ran it through my build (large web application that uses a lot of Maven plug ins during the build) and all worked fine. I forward a "announcement" to the Maven user and Maven developers list. Lots of the people there Debian and Ubuntu users and are probably interested. http://www.nabble.com/Debian-package-of-Maven-2.0.5-tf3351107s177.html Thanks for the package. manfred -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: maven2 for Debian
Quoting Michael Koch <[EMAIL PROTECTED]>: And another thanks for all your input. This is really appreciated and discussion is needed. No problem. I am sticking around. I also joined the package maintainers list out of curiosity. I am in the process of learning how to create a binary package like you did for Maven. Is there some sort of source I can download and look at? I downloaded the stuff on your site. Can I use all that stuff there to somehow recreate the package to understand how it is done or is there stuff missing? Could I get that stuff? E.g. how do I get all the files you had to set up in /debian/ like rules and so on. Anyway... thanks for the discussion. Manfred -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: maven2 for Debian
Quoting Michael Koch <[EMAIL PROTECTED]>: deb-src http://people.debian.org/~mkoch/maven2/ ./ Then do apt-get update apt-get source maven2-binary This downloads the package sources for you and unpacks them. to build the package just do "debuild". This builds the whole package. Thanks Michael. I finally got around to trying that. Works fine apart from the signing process. To get more infos about creating debian packages please read http://www.debian.org/devel/. There is a lot of documentation about this. Most Debian Java packages use CDBS. The documentation for CDBS is mostly its source code. ;-) I will look at all that and try to create a package like that for some other software (probably Squirrel SQL) and probably bug you all with questions ;-) It will be a while though.. manfred -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JavaME on Debian?
Quoting David Herron <[EMAIL PROTECTED]>: W. Borgert wrote: Quoting Michael Koch <[EMAIL PROTECTED]>: Its possible. I do a lot of J2ME development at work on Debian. But there are no Debian packages for this, as all you need is not really redistributable. Like SUN WTK Emulator. And All other emulators are not available under Linux. (I know there is some old outdated emulator from Nokia for Linux) Thanks! It looks like the "Sun Java Wireless Toolkit 2.5 for CLDC" is only available as .exe for Windows. Not even Suns very own OSes are supported, or do I miss sth.? I hope, Sun will release those things at least in a way, that Debian can distribute it in non-free (better main, of course). Cheers, WB Have you browsed through the PhoneME project to see whether any of it is open source? https://phoneme.dev.java.net/ http://www.mobileandembedded.org/ I don't know why we only release the WTK for Windows. It may have to do with the device emulators that are included...?? Hm. I have not checked this out by as far as I know Netbeans comes with a Mobile Pack that includes all you need (including emulators). I have seen a demo of this on a Java Developer Day in Vancouver and as far as I recall it was running on Linux. manfred
maven 2.0.6
Hi! I am just wondering if Michael Koch or somebody else has any plan to update the Maven 2.0.5 binary deb package to 2.0.6? manfred -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A Java Packaging Wishlist
I will some more: - Support Maven builds and be able to read dependencies from the maven pom.xml file and translate them to the debian control file entries for dependencies and run dependencies. - have a sort of meta information for provides for the major versions of the JDK/JRE e.g. requires/provides java5-runtime, java6-runtime, java7-runtime, java5-developmentkit and so on - have a meta information appservers e.g. requires/provides javaee5-appserver potentially this could all be based on the JSR numbers where the different implementing packages include a provides - jsrxxx-implementation manfred Quoting Arnaud Vandyck <[EMAIL PROTECTED]>: Excellent proposal! On 5/22/07, Paul Cager <[EMAIL PROTECTED]> wrote: Late-night, random thoughts about what would be useful for us Debian Java packagers. Any comments? dh_installjars == A new debhelper command: * Installs Jars into usr/share/java directory, adding correct version number suffix (as parsed from the changelog). * Adds required symlink. * Arguments specify required Jars (with or without the version number suffix), or directories that will be scanned for Jars. * Can read a "jars" file to get the list of jars (in the same way dh_installdocs reads "docs"). If people think this is useful I might email Joey Hess to see if he would be likely to accept a patch. Cdbs Enhancements = * /usr/share/cdbs/1/rules/debhelper.mk to add call to dh_installjars. * Amend ant.mk / ant-vars.mk to install Javadocs in the correct place (dependent on setting a new DEB_ANT_xx variable). dh_make enhancements * When invoking dh_make (with cdbs option) in a directory with a build.xml, pkg-java "standard" rules/control files are created, including a separate "-doc" package etc. * When invoked with a pom.xml a pkg-java standard package is created, and the pom is parsed to fill out skeleton entries in control, copyright etc: - authors - licenses - download location / svn repos - dependencies -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Arnaud Vandyck -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A Java Packaging Wishlist
Quoting Arnaud Vandyck <[EMAIL PROTECTED]>: On 5/22/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: I will some more: - Support Maven builds and be able to read dependencies from the maven pom.xml file and translate them to the debian control file entries for dependencies and run dependencies. We must first have maven in main!.. That's not so easy ;-) I know. But work is being done on that. We might as well plan towards harnessing the power we gain as soon as it is in and we are able to use it. In the meantime Michael Koch provides a binary maven package that can be used for developing these features. manfred -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java policy and ABI changes
Quoting Andrew Haley <[EMAIL PROTECTED]>: Mike Hommey writes: > I have a java library package, called libmozillainterfaces-java, > that is provided by xulrunner. I'm currently working on a new > upstream release of xulrunner which changed the java interfaces: > some interfaces changed namespaces, so you have to do changes to > your source code, and xpcom initialization is not handled the same > way (you have to initialize the Mozilla instance before > initializing xpcom). > > Which means classes built with the older version won't build nor run > as is with the newer version. > > What should be done in such case, package-wise ? Change name ? Change > jar name ? Both ? Other ? Shoot the maintainers? Well, OK, that would be a little extreme, but urge the maintainers not to break binary compatibility. In my opinion, Java libraries without stable interfaces shouldn't be deployed in free OSes. If they are to be used, you're going to have to change the jar name, but even that may not work: if you use such a library Mozilla, some other version of the same package might be used by some other Java application running in the same process, and unless it's firewalled by some ClassLoader trickery it'll break. If that happens, some trickery like Jar Jar Links may be your only hope. Hm. All this is a bit extreme. Even the Linux kernel changes its API all the time and things are working okay. Especially with the use of the java classloaders the whole binary compatibility is a bit overrated IMHO. In Maven you can have all sorts of versions of the same jar in parallel and each application can use whichever it needs. I think one way or another it will be necessary to have different versions of various libraries in Debian in parallel. I do not think it will be possible to force all upstreams to always use the latest version (or most secure one or whatever.. how would you select anyway). Just my 2c (and definitely not more..) manfred
Re: Java policy and ABI changes
Quoting Marcus Better <[EMAIL PROTECTED]>: Andrew Haley wrote: In my opinion, Java libraries without stable interfaces shouldn't be deployed in free OSes. That's a nice goal but unfortunately the world is not so perfect, because users occasionally require new software with shiny new bells and whistles. Besides we cannot control upstream and prevent them from breaking ABI. As a distribution we need to find a balance between features and stability. I think the Java policy needs to be tweaked to allow for multiple versions of the same library. The problem is much easier than for C libraries, since we don't have a dynamic linker, so the user is responsible for adding the correct library to the classpath. I could not agree more. I assume you mean the packager needs to reference the right version of a library. We just need to make sure the different versions don't conflict, which usually means that both of them cannot install the generic symlink "/usr/share/java/foo.jar". It seems it would suffice to have the symlink created by postinst, which would point it at the latest installed version (similar to ldconfig). I actually have a question about that. What do we need the symlink without the version for. It actually looks dangerous to me to have that. An application could use the symlink and then another app gets updated which changes the symlink to a newer version with a different API. That would then actually break the first application. Why do we actually need the symlink and not just link to the correct version only. In terms of separating the artifacts i think an option would be to include the package structure and the version into directory structure so e.g. commons-cli could be located in org/apache/commons/cli/0.9 and in parallel have a org/apache/commons/cli/1.0 and so on. The jars could then be in /usr/share/java/org/apache/commons/cli/0.9. Note that this kind of reproduces the structure in Maven repositories with the advantage that Debian packagers could control that structure (whereas the Maven repo is a big tangled mess). Note that I'm not suggesting we should package several versions of libraries. That should be avoided, but when necessary there should be a way to do it. Would it be possible for one package to actually create different versions? Otherwise it would need to be possible to have different versions of the same package installed at the same time without file conflicts (which could be dealt with as suggested above). manfred
Re: Packaging solr:
Quoting Jan-Pascal van Best <[EMAIL PROTECTED]>: On Tue, June 5, 2007 16:31, Marcus Better wrote: That's what I thought, but what do we do about the 'moving target'-argument? You will have to check carefully that the dependencies are satisfied and monitor changes. Pretty much same as any other package. The difference is that solr has announced they will make use of nightly development snapshots of, especially, lucene. That means that it is possible that solr 1.2 would only compile and run against lucene-svn-20070613 or something like that (not the previous lucene-2.1, nor the upcoming lucene-2.2). It would also mean, if other projects did the same thing, that /usr/share/java would contain _several_ nightly snapshots of lucene, one for each project. If the only package ever making use of liblucene-2.2.0-svn20070613 is solr-1.2, then what is the advantage of that over having a local version of the library installed under /usr/share/solr/lib? IMHO both approaches violate the Debian Java Policy as it stands. Technically creating a separate lucene package at least theoretically allows other packages to use it. However depending on the dependency declaration on other packages either solr breaks (if a new package includes a dependency to a newer lucene package) or the other packages might not be installable because of a version conflict or be installable but not work (becasue of incompatible API). By having the library as part of solr in its own lib folder you at least have control and guarantee that solr will work. One way or another the issue of allowing multiple versions of a jar in the system to satisfy the upstream package requirements keeps coming up. Going forward I think we will have to find a way to allow this and come up with a good plan for it. If we decide not to support this we will either end up with lots of packages we will create a LOT more work for us, since it is pretty common in the java world to depend on specific versions. Luckily with the classpath thats not an issue. manfred
Re: Packaging solr:
Quoting Michael Koch <[EMAIL PROTECTED]>: On Tue, Jun 05, 2007 at 04:27:41PM +0200, Jan-Pascal van Best wrote: On Tue, June 5, 2007 16:08, Marcus Better wrote: > Jan-Pascal van Best wrote: >> What is the policy about this issue? > > It's generally not acceptable to duplicate code, so Debian versions of libraries should be used. That's what I thought, but what do we do about the 'moving target'-argument? Dont put it into Debian. We have enough problems with keeping some libs in different stable release versions in Debian. Thats certainly another option. You could just create a deb that violates the Debian Policy but is installable anyway. Problem might be that you have to have your own repo or some repo to host it at. You might be able to get it into Ubuntu. manfred -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GNU/Linux Java Policy and Packaging
Quoting Marcus Better <[EMAIL PROTECTED]>: Tom Marble wrote: Packaging - I think we need to add: * Library ABI handling and support for parallel installation of multiple versions (as discussed in another thread [1]). Marcus [1] http://thread.gmane.org/gmane.linux.debian.devel.java/6537 Thanks for mentioning it. I second that notion. manfred -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GNU/Linux Java Policy and Packaging
Quoting Petteri Räty <[EMAIL PROTECTED]>: [EMAIL PROTECTED] kirjoitti: Quoting Marcus Better <[EMAIL PROTECTED]>: Tom Marble wrote: Packaging - I think we need to add: * Library ABI handling and support for parallel installation of multiple versions (as discussed in another thread [1]). Marcus [1] http://thread.gmane.org/gmane.linux.debian.devel.java/6537 Thanks for mentioning it. I second that notion. manfred We solved this by installing to /usr/share/- where slot is roughly the ABI (we increase it every time a new version breaks something using the library). Very nice. So you actually allow a package to be installed in various version numbers in parallel? How do you handle man pages and all sorts of stuff like that (e.g. executable in /usr/bin has version number in command?) manfred
Re: GNU/Linux Java Policy and Packaging
Quoting Petteri Räty <[EMAIL PROTECTED]>: We solved this by installing to /usr/share/- where slot is roughly the ABI (we increase it every time a new version breaks something using the library). Very nice. So you actually allow a package to be installed in various version numbers in parallel? How do you handle man pages and all sorts of stuff like that (e.g. executable in /usr/bin has version number in command?) manfred It's not mandatory to install man pages on Gentoo but of course helpful for users. The thing is that besides the JDK itself I haven't see Java applications shipping man pages so far (reasons are easy to guess). As for the executable versioning, yes we version the executables if it's useful to install multiple versions at the same time. Most of the time it's only prudent to keep the executable in the latest version and libraries for the old versions. For example if the different versions use the same subdirectory in /home then it would be dangerous to let the user mix versions like that but in the case of for example Netbeans it's safe as the settings directory is versioned so there is for example: /usr/bin/netbeans-5.5 Cool... sounds very reasonable. Something like that should become part of the Debian Java Policy IMHO.. manfred
Re: News on the Maven front
This is great. One question I have is however what happens if a dependency is not packaged in debian as the flow shows but is required at runtime. Will it be included in the package or will it be ignored and therefore a potentially non functioning package produced. Another question... can we have this on a wiki somewhere? Would also be good for the ubuntu and other crowds that use the debian tool chain. manfred -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/3f8dfa4421ef0fc71be772f641ac8652.squir...@www.mosabuam.com
Re: How to apply maven build system
> Andreas Tille writes: > >> I'm actually not very keen on really using maven as long as I can get >> the package working at all - but I actually have no real clue what >> command line would trigger the build process (and upstream) seems to be >> dead. So in principle the most simple help would be a command line >> which builds the JAR. > > Would something as simple as: > > jar cf .jar *.class > > after compiling all the *.java files with javac be workable in this case? > Maven will of course work but it may introduce a fair bit of complexity. I just checked.. it wont be that simple since it depends at least on org.freehep.graphics2d.VectorGraphics manfred -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e78c6c36bd10992bf69d8e01f78c6fb2.squir...@www.mosabuam.com
Re: How to apply maven build system
Its gonna be more hazzle.There are references to these two classes import Time.TimeManager; import Process.Process; as well as to net.iharder.dnd.FileDrop(motif, new net.iharder.dnd.FileDrop.Listener You will have to find whatever the Time and Process libraries are...looks like a mess to me. manfred Here is a first cut of a pom file http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 patristic patristic 1.0.0-SNAPSHOT Patristic org.freehep freehep-graphics2d 2.1.3 >> Andreas Tille writes: >> >>> I'm actually not very keen on really using maven as long as I can get >>> the package working at all - but I actually have no real clue what >>> command line would trigger the build process (and upstream) seems to be >>> dead. So in principle the most simple help would be a command line >>> which builds the JAR. >> >> Would something as simple as: >> >> jar cf .jar *.class >> >> after compiling all the *.java files with javac be workable in this >> case? >> Maven will of course work but it may introduce a fair bit of complexity. > > I just checked.. it wont be that simple since it depends at least on > org.freehep.graphics2d.VectorGraphics > > manfred > -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/063b0c9b8769a01e502d331205773a58.squir...@www.mosabuam.com
Re: How to apply maven build system (Was: How to use Debian packaged freehep instead of upstream provided freehep.jar)
> Hi, > > inspired by some hints about Java packaging I tried another package. It > is called patristic[1] (just another biological phylogeny software). It > comes just with a directory full of *.java files and the binary download > just tells in what directory layout the classes should end up. Chances > to contact upstream seem low (Homepage mentioned on the scientific > publication page[2] is not available any more). So I decided to start > some maven training and did > > mvn archetype:generate -DgroupId=Patristic -DartifactId=patristic > -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false > > as it is suggested here[3] > >> Anyway, unfortunately, you still have to put hands on upstream's code, >> because maven requires the projects it's working on to have a specific >> directory structure. > > That's fine in the case of patristic - I'd need to repack the code in > any case - so why not applying the maven directory layout? > > I'm actually not very keen on really using maven as long as I can > get the package working at all - but I actually have no real clue > what command line would trigger the build process (and upstream) > seems to be dead. So in principle the most simple help would be > a command line which builds the JAR. Maven is the easiest way. Put all those files into the src/main/java folder of the created folder with the pom.xml file and run mvn clean install You should get a jar in the target folder. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/15e3da124802332c1b5a2dc868af8b67.squir...@www.mosabuam.com
Re: How to apply maven build system
> Giovanni Mascellani writes: > >> There's something funny about this command: I executed it and it had to >> download about 30 different files before being able to do something >> really dump (copy some simple templates in the working directory). > > Yeah, that's typical for Maven. It's absolutely amazing how much stuff it > downloads in order to do anything well... at least the initial download is small. Not like other dev tools that range in the GB for first download. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/15a697f1d0f0c82fcc47c56f0f22ffa0.squir...@www.mosabuam.com
Re: How to apply maven build system (Was: How to use Debian packaged freehep instead of upstream provided freehep.jar)
> BTW, working on this just made me notice that some new versions of > FreeHEP were released some months ago. These releases were deployed on > maven repositories, but I didn't notice them because they were not > deployed on the site where development happened before. This is one of > the many things I don't like of maven: it doesn't teach developers to > have clean and clear release cycle and habits (for instance, where to > publish the release), because the magic of maven will (try to) solve any > problem.. Hm.. I think the opposite is true. Release go to Maven central and not some website somewhere on the net. That way as a developer you dont have to worry about manually downloading from all over the place and monitoring sites all over the place. Maven encourages and supports proper process... but many people still just hack away.. manfred -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/f8941cb430fd76eceb35dbbd2e388a58.squir...@www.mosabuam.com
Re: DebConf11: Java Team Meeting and Eclipse Packaging BoF
On Tue, July 26, 2011 9:16 pm, Thomas Koch wrote: > Niels Thykier: >> I do not have a lot planned for these, so it would be great if you are >> armed with curiosity and questions. I am more than happy to give people >> a practical session on building eclipse for that BoF as well. > > Thank you for getting this scheduled! > > I'm still carrying around the idea of a Maven repository for Debian. > People > can upload their Maven packages to Debian's repository. Once a DD gives an > OK, > everything from there on until having the package in the archive could and > should be automated. > > I've no idea how we should manage otherwise to get a substantial amount of > java libraries packaged. Maybe Maven central could get another public section exposed by the infrastructure that only contains Debian approved artifacts. Have you talked to the Maven PMC and/or Sonatype about that? manfred http://www.simpligility.com -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/7ba635b8e0a480c68114f9027cd40473.squir...@www.mosabuam.com
Re: Maven 3.x in experimental
On 11-12-30 07:45 AM, Damien Raude-Morvan wrote: Hi Java team! Maven 3.x is now available in experimental in a new _maven_ debian package. You'll also need updated _maven2_ package (>= 2.2.1-11) to allow side-by-side installation (I'm using alternatives to allow user to choose between "mvn" cli tool). Please test and report any issue. I'm especially interrested in FTBFS w/ maven 3 or wrong plugin version. Roadmap (I'm looking for help here :) : - update toolchain (maven-ant-helper, maven-debian-helper) to allow packages to build with maven 3.x - update plugins to be in sync with upstream (maybe allowing multiple plugins version in archive... ?) That idea has been shot down many times in the past ... might not be worth to try for it again.. - made maven 3 default for wheezy (open question... AFAIK, Fedora already switched) Maven 3 is MUCH better than Maven 2 and I think it would be a great idea to make it the default replacing Maven 2 .. upstream has no development on Maven 2. manfred http://simpligility.com -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4efe98f8.2060...@mosabuam.com
Re: New work on java-package
On 12-03-19 09:51 AM, Andrew Haley wrote: On 03/19/2012 02:04 PM, Barry Hawkins wrote: For example, JetBrains IntelliJ IDEA, one of the main IDEs for Java development, still doesn't endorse the use of OpenJDK. If you download IDEA and launch it via a terminal, you will see the following warning: ~$ ./idea-IC-111.277/bin/idea.sh OpenJDK Runtime Environment (IcedTea6 1.11pre) (6b24~pre2-1) OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode) OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode) WARNING: You are launching IDE using OpenJDK Java runtime. THIS IS STRICTLY UNSUPPORTED DUE TO KNOWN PERFORMANCE AND GRAPHICS PROBLEMS! NOTE:If you have both Oracle (Sun) JDK and OpenJDK installed please validate either IDEA_JDK, JDK_HOME, or JAVA_HOME environment variable points to valid Oracle (Sun) JDK installation. See http://ow.ly/6TuKQ for more info on switching default JDK But that's their fault, not OpenJDK's; if there's actually anything wrong with OpenJDK that stops IDEA working, that would be another matter. I'd note that OpenJDK is the official Java SE 7 Reference Implementation, so if IntelliJ IDEA doesn't even work with the RI, it really is JetBrains' fault! Andrew. That is more of a warranty/support issue than anything else. I use it every day with OpenJDK and it works fine.. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f6773a9.2060...@mosabuam.com
Re: OT: Usage of language-specific package managers
nOn 12-03-23 05:41 AM, Matthias-Christian Ott wrote: On Fri, Mar 23, 2012 at 08:06:25AM -0400, Barry Hawkins wrote: On 3/23/12 6:47 AM, Matthias-Christian Ott wrote: Hi, I have been assigned to a legacy Java project, which uses several messed up Ant buildfiles. I'm going to replace or clean up the build system as part of project maintainance. I read that Maven (similar to other language-specific package management software) has been a problem for Debian for a long time and that Debian struggles with the general Java software packaging mentality which often ignores system wide package managers. One of the goals for the project is to make software packaging and distribution easier and automatic. Gentoo and Fedora seem to support Maven and Ant, but prefer Ant. Is that also true for Debian? If so, are there any preferred build target naming conventions, like [1]? Regards, Matthias-Christian [1] https://wiki.apache.org/ant/TheElementsOfAntStyle I can tell you that of all the projects I have worked with for years and all those my friends work with, I have yet to find anyone who uses the Maven that is packaged with a distribution. The common practice is to have Ant + Ivy, Maven, or Gradle + Ivy using a repository outside the OS package management system's own packages. Coupling a Java project to using the Java libraries packaged with the current version of your operating system's offerings is generally avoided, as you invariably need a library or a version of a library that is not available. This practice seems to be widespread, but I wonder what you do about security updates then. GNU/Linux distributions seem to either have enough man power and an organizational structure to do proper security updates or do rolling releases. If you hardcode the versions you can't do the later and it seems security updates aren't offered in the common Maven repositories. Thats not true at all. New versions get into the repositories all the time and you just upgrade the version and release a new build. You control it all rather than the distro that might have no idea about your application and therefore no idea if a different version of a library actually works. If you use Debian stable you have a long enough update cycle including security updates, so that should work once you packaged all your dependencies (the project I'm working on the dependency management consists putting years-old JAR files, some with unknown licensing status and origin, in directory). In the maven world you use a repository manager for all that during build time and you then ship the libraries as part of your software.. giving you complete control. Also the update cycle of Debian (or pretty much any distro actually) is way to slow and also too much out of reach to be able to control of the application developer to be able to control it in terms of QA cycle and much more.. If you want to support multiple operating systems and distributions, the required effort will of course increase linearly. Yes.. true.. But looking at other programming languages (Python, Ruby, Perl, Lua, Haskell, JavaScript etc.) these language-specific package managers seem to become some kind of a problem, because many people seem to care less about system wide package managers (perhaps because they don't have one, as with Windows and Mac OS X) and about the operating system and the installed software as an integrated whole. The problem is that system wide package manager are better but e.g. in the case of Maven often go against the ideas and work that upstream is doing and that can cause a big culture clash.. e.g. read for http://discursive.com/2012/03/15/the-debian-java-package-team-futility-defined/ or http://kohsuke.org/2012/03/16/debian-and-maven-a-crash-of-culture/ It applies to me too.. e.g. I use Maven commercially and train on it and I can not recommend the Debian packages because they are too divergent from upstream and actually break default Maven behaviour and make it impossible to support a Maven build across operating system because the Debian package is just too different. I understand the conundrum that applies to Debian in the sense that it needs to build from source and be offline.. but more and more that is unrealistic imho. It might be a great idea to provide a Maven package that is completely compatible as an alternative to the Debian internal one in some outside repo. Manfred http://simpligility.com
Re: FYI: Java cli option parsing in Debian
On Fri, May 18, 2012 12:29 am, Thomas Koch wrote: > Hi, > > I want to introduce a cli option parsing library for maven-debian-helper. > There a tons of such java libraries out there: > > http://jewelcli.lexicalscope.com/related.html > > Just FYI, I had a look, which of these we have in Debian: > > - libcommons-cli-java > - libjargs-java > - libjcommander-java > - libjoptsimple-java > - libgetopt-java > - libargs4j-java > - liboptions-java > > Sh...ugar.. I thought looking into what is packaged would make the choice > easier... > > rule outs: > > - libcommons-cli-java - I don't like Apache Commons stuff > - libargs4j-java - Is modelled after javac's broken options, not GNU style > - liboptions-java - AFAIK only used by one project > - libjargs-java - very low activity upstream, last release 2005? > - libgetopt-java - ancient (2000) Java style, only translation updates > since > then > > good: > > - libjcommander-java - active, documented, Git, Unit Tests > - libjoptsimple-java - active, Git, Unit Tests, Code Quality Tools, > POSIX/getopt style, documented > > Jcommander's documentation looks more inviting. So I'll start with that > one. > > Regards, > > Thomas Koch, http://www.koch.ro Good choice. I played with it before and it is quite nice. manfred -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5117dc98779d73b3d4ea17b38185ce27.squir...@www.mosabuam.com
Re: Frustration with trying to build Debian packages from Maven-based sources
Hi all, Some clarifications.. > Hi Emmanuel, > > I'm happy to find someone from the java side, especially from apache here > on a > debian list. Perhaps you could help us as an intermediator and raise > awareness > for the pain we have when dealing with java in general and often the ASF > in > special. > > Some points that come to my mind: > > - Dependencies with fixed versions instead of version ranges: We aim to > have one or a few versions of a software in the archive. This is going to be difficult to get projects to do that.. > - Use version numbers in a sane way: http://semver.org This is best practice in the Maven world as well. But not enforced or so and therefore often not really followed.. > - Correct license information. Difficult. In fact many components in the Central repo declare one version but source code scans have revealed different licenses in different files. This analysis is done on a regular base by Sonatype (who run the Central Repository) and exposed to Nexus users (which is a repository manager software used to host a repository yourself under your own control) . > - Release source tarballs, not only binaries to maven central. This has been a requirement for open source components in Central for years. You can find them with the -sources classifier in a jar file. E.g. looking at http://search.maven.org/#artifactdetails%7Ccom.google.inject%7Cguice%7C3.0%7Cjar you can find the java doc and source code for guice in guice-3.0-javadoc.jar and guice-3.0-sources.jar > - Sign your artifacts with gpg keys that are connected to the > web-of-trust. Signing is a requirement for deployment to Central. See https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide If there is interest in the debian community to have a controlled repository server running that only provides approved jars you could run Sonatype Professsional. As an open source project you could get a free license. If there is any interest in that please contact me at manf...@sonatype.com Manfred http://www.simpligility.com -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/42e65c03160afadb77a45d78c8a83897.squir...@www.mosabuam.com
Re: Frustration with trying to build Debian packages from Maven-based sources
> Le 18/03/2013 22:44, Manfred Moser a écrit : > >> If there is interest in the debian community to have a controlled >> repository server running that only provides approved jars you could run >> Sonatype Professsional. As an open source project you could get a free >> license. If there is any interest in that please contact me at >> manf...@sonatype.com > > I'm not sure using a closed source tool is allowed by the Debian rules. > Any plan to open source Nexus Pro? ;) No.. but you could use the Open Source version as well .. you would just have to manually procure it. manfred -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/d86e446396d93e7d106eff49e7da7e68.squir...@www.mosabuam.com
Re: Maven 2 vs Maven 3 plugins
> Le 29/05/2013 16:22, Manfred Moser a écrit : > >> Imho we should sort out all situations where people think they have to >> stick to Maven 2, migrate them and then deprecate support for Maven 2. > > I personally stick to Maven 2 because I need the uniqueVersion feature > that was removed from Maven 3. Can you clarify the details of what you mean with that? manfred -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ff8fa1599158ca65bd04fb438e88dfbb.squir...@www.mosabuam.com
Re: Maven 2 vs Maven 3 plugins
> Le 29/05/2013 16:46, Manfred Moser a écrit : > >> Can you clarify the details of what you mean with that? > > See: > https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-NonuniqueSnapshotDeployments > > I can no longer deploy non timestamped snapshots to my private > repository. I don't use a repository manager and timestamped snapshots > quickly become a maintenance issue because I have no process to remove > them automatically. What are you deploying to if you are not using a repo manager? And why not use e.g. Nexus and just have the snapshot cleanup task running? And apart from storage consumption.. is there any other problem? I would think that you should just fix this minor problem and upgrade .. manfred -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8961da0f54f23044cf28e1c7e96594f0.squir...@www.mosabuam.com
Re: Maven 2 vs Maven 3 plugins
> Hi all, > > There is an increasing number of Maven plugins that require Maven 3 and > can't be upgraded without breaking Maven 2. For example > maven-install-plugin 2.3 works with Maven 2 and Maven 3, but the version > 2.4 is for Maven 3 only. > > What's the proper way to handle this situation? Should we split these > plugins to satisfy each version of Maven? > > That would give: > * maven-install-plugin2.3: for Maven 2, doesn't install its jar in > /usr/share/java to avoid conflicts (I'm not sure it's needed anyway) > * maven-install-plugin: for Maven 3 > > What do you think? Imho we should sort out all situations where people think they have to stick to Maven 2, migrate them and then deprecate support for Maven 2. manfred -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/00d1012e5bfa3db6fa65b203584e478e.squir...@www.mosabuam.com
Re: Maven 2 vs Maven 3 plugins
> Le 29/05/2013 17:06, Manfred Moser a écrit : > >> What are you deploying to if you are not using a repo manager? > > I simply deploy to a remote server via SSH. The artifacts are served by > Apache. Ah... ouch. >> And why not use e.g. Nexus and just have the snapshot cleanup task >> running? > > Because so far I didn't need it. And I'd rather not have a daemon > running continuously and eating resources on my server just for cleaning > a few artifacts once a week. You mean like you have Apache running. Nexus is just a different webserver (well technically a servlet container - Eclipse Jetty) with a web app running. And it has built in support for cleaning up snapshots. I used to do what you are doing years ago and the step to using a repo server is really small in terms of setup but huge in terms of benefits you get. I would suggest to do that.. >> And apart from storage consumption.. is there any other problem? > > The last time I tried Maven 3 I didn't like the output, it looked less > readable to me. I just have to get used to it I guess. Considering that Maven 2 is not developed anymore and IDE integrations and others mostly use Maven 3 I think yes you should.. manfred -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1a3f9fbb3f3ada53f9316c3f3ea63d75.squir...@www.mosabuam.com
Re: maven2 for Debian
On Sunday March 4 2007 09:27, Michael Koch wrote: > I have built a preliminary Debian packages for Maven 2 for people > who need it or wanna look into Maven. I did this by using the > binary distribution from upstream. You can install it by adding > > deb http://people.debian.org/~mkoch/maven2/ ./ Hi Michael, This is great. I use Maven2 on a daily base as part of my job. I am running the upstream install in Ubuntu. I am going to give this a whirl next week. I would also be interested in binary derived packages of all sorts of other stuff. How hard is it to create a package like this? Are there any instructions somewhere? I think as a first entry point packages like this would be awesome. At least a lot better than no packages. Sort of related- another question. Couldn't we come up with some sort of Maven assembly plugin definition that would allow deb creation fairly easily? And another one ... would it make sense to get everything maven downloads when it runs through its dependency system in some location like /usr/share/java/maven2/repository so that it comes available for all users? Could this be expanded to be actually used as a packaging system? And a last one.. have you announced the package on the maven lists? manfred -- Manfred Moser Vancouver Island Java User Group http://www.mosabuam.com/vijug skype: mosabua http://www.linkedin.com/in/manfredmoser -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
JavaOne
Hi! Just wondering if anybody on the list will be at JavaOne next week and if there is some sort of meeting I could attend. I would love to meet some of you. I will certainly attend some of the OpenJDK, java packaging and other sessions, but a Debian specific informal meeting might be nice too. manfred -- Manfred Moser Vancouver Island Java User Group http://www.mosabuam.com/vijug skype: mosabua http://www.linkedin.com/in/manfredmoser -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JavaOne
On Friday May 4 2007, David Herron wrote: > Manfred Moser wrote: > > Hi! > > > > Just wondering if anybody on the list will be at JavaOne next > > week and if there is some sort of meeting I could attend. I would > > love to meet some of you. > > > > I will certainly attend some of the OpenJDK, java packaging and > > other sessions, but a Debian specific informal meeting might be > > nice too. > > > > manfred > > I'm going to be there... > > The session catalog is here: > http://www28.cplan.com/cc158/sessions_catalog.jsp > if you haven't seen it. There are several interesting sessions > lined up along the lines of your stated desires. There are several > sessions and BOF's about the OpenJDK project itself, and the > OpenJDK project will have a booth on the show floor. I'll be > spending a lot of my time in the booth, FWIW. > > The OpenJDK BOF is Tuesday night @ 8:00ish. > > - David Herron Thanks David. I have already planned my attendance out using the schedule builder and will be at a bunch of open source tracks. I will try to catch up with you on the OpenJDK booth. manfred -- Manfred Moser Vancouver Island Java User Group http://www.mosabuam.com/vijug skype: mosabua http://www.linkedin.com/in/manfredmoser -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A Java Packaging Wishlist
On Tuesday May 22 2007, Arnaud Vandyck wrote: > > In the meantime Michael Koch provides a binary maven package that > > can be used for developing these features. > > His work couldn't be used for that at the moment because the maven > binary package will never reach 'main' as is. And we can't relay on > contrib or non-free package to build all our packages. > > Anyway, it's a cool idea. Assuming that his binary package runs maven as distributed by upstream and the final debin package will do so as well, which was discussed as an aim at an earlier stage here as far as I understand it would actually be feasible to use the binary package for developing these processes now. Anyway.. just an idea. Integrating maven will include lots of other tasks like a debian build system private repository and so on. manfred -- Manfred Moser http://www.mosabuam.com skype: mosabua http://www.linkedin.com/in/manfredmoser -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A Java Packaging Wishlist
On Tuesday May 22 2007, Paul Cager wrote: > [EMAIL PROTECTED] wrote: > > I will some more: > > > > - Support Maven builds and be able to read dependencies from the > > maven pom.xml file and translate them to the debian control file > > entries for dependencies and run dependencies. > > The maven pom certainly contains lots of the information you need > to create a Debian package - dependencies, authors, licenses etc. > > By the way, I wasn't quite sure how you were suggesting this > information should be used: > > - at package *creation* time (i.e. when you first create the > debian/rules, debian/copyright files etc, possibly using dh_make) > > - at package *build* time (e.g. when you run debuild). > > I think using the information at package *creation* time is a good > idea; I listed a few ideas in my original email. The automatic > tools would create a skeleton packaging which could be amended by > the packager. That was mostly what I was thinking of. Potentially it could also be run on updates from upstream. That might be a bit harder. In an ideal world a java developer that has no idea about packaging could use some sort of maven plugin that actually uses all this and creates a debian package... that might be a hard level to get to though. > But I'm not so sure about dynamically generating dependency > information at package build time. Did you see the discussion > earlier this month about "java dependency substvars"? I missed that discussion. I do assume that with some sort of lookup list of "debian" approved/included dependencies even that might be possible. Certainly something to be considered as a second step once the creation time works ;-) -- Manfred Moser http://www.mosabuam.com skype: mosabua http://www.linkedin.com/in/manfredmoser -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting Maven Into Main - What Next?
On Friday May 25 2007, Paul Cager wrote: > Now that we are making progress with packaging Maven's .. Hi Paul and all, Just fyi I am an active Maven and long time Debian/Ubuntu user with very little packaging know how First I want to recommend two resources (both free) The books Better Builds with Maven http://www.mergere.com/m2book_download.jsp Maven: The Definitive Guide (1.0 Alpha 1) http://www.sonatype.com/book/index.html > * Create a local repository for Maven, e.g. > debian/.m2/repository. For each build-dependency create the > appropriate directory structure (e.g. > debian/.m2/repository/plexus/plexus-utils/1.0.2/). I would actually suggest to start building a debian build server internal maven repository. http://maven.apache.org/guides/introduction/introduction-to-repositories.html Together with a proxy (e.g. proximity .. also documented in the books) it can be ensured that a build is basically done without going out to the internet for any artifacts and it is guaranteed that only allowed internal artifacts are use. The repository should only contain packages that are in debian. Maven could actually deploy artifacts to the repo as part of the build process. For other builds it would be good if the packages can deploy to the repo as well. Than any maven build can just declare the right debian dependency. > * Copy (or symlink) the build-depends jars from /usr/share/java > to our repository. This should ensure that maven does not try to > download any dependencies. (I imagine maven also has an option to > inhibit downloads; it would be safest to set this, and/or set > http_proxy). Use of proxies is a bit documented here http://maven.apache.org/guides/mini/guide-proxies.html To run maven in offline mode there is a -o flag. > * Set "localRepository" to "debian/.m2/repository", and call > maven's bootstrap shell script. (this process is described in > http://maven.apache.org/guides/development/guide-building-m2.html) It might be a good idea to create a "company" pom for Debian that contains all settings and so on that apply to all Debian packages that are build with Maven. Otherwise a debian profile in a settings.xml could achieve similar things. I am sure the maven team could be of great help. I told Jason at Java One that the Debian team is packaging Maven and he was astonished and delighted. He or somebody else might be able to give a good tip here and there. I hope this helps a bit. manfred -- Manfred Moser http://www.mosabuam.com skype: mosabua http://www.linkedin.com/in/manfredmoser -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A Java Packaging Wishlist
On Saturday May 26 2007, Arnaud Vandyck wrote: > On 5/26/07, Trygve Laugstøl <[EMAIL PROTECTED]> wrote: > > Arnaud Vandyck wrote: > > > If we wanna use maven to build, we need maven in main. If we > > > want to extract metadata, we just need an xslt or some > > > perl/python/java/whatever xml parser. > > > > No you don't. I meant that you can use Maven to generate the > > files and include in debian/. That way you can leverage the > > project's meta-data and start working on integration Maven into > > the build process until it is properly into main and those files > > can be generated build-time. > > I don't like the idea of generating those files at build time. But > maybe I don't understand what you mean. Sorry to be unclear. I meant at the time when you are first assembling the package from the upstream source. The information in the pom can be used to derive a lot of data in the debian control files. In addition when another version is available from upstream the pom content can be verified back into the control files to do amendments. That wont be fully automatic of course. manfred -- Manfred Moser http://www.mosabuam.com skype: mosabua http://www.linkedin.com/in/manfredmoser
Re: Java policy and ABI changes
On Saturday May 26 2007, Andrew Haley wrote: > [EMAIL PROTECTED] writes: > > Hm. All this is a bit extreme. Even the Linux kernel changes its > > API all the time and things are working okay. > > This really is grossly unfair to the kernel deveopers, who go to > great lengths to avoid breaking the ABI. Would that Java package > mantainers were so careful. Sorry if I had the wrong impression and made a bit of an extreme statement. I certainly don't know enough about this and apologize. I do believe that API changes are necessary here and there and there are valid reasons to support the old and the new API at the same time. manfred -- Manfred Moser http://www.mosabuam.com skype: mosabua http://www.linkedin.com/in/manfredmoser -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting Maven Into Main - What Next?
On Friday May 25 2007, Paul Cager wrote: > I have practically no experience with Maven (yet!), so it's good to > meet someone who is active with it. Would you be interested in > getting involved with the testing of any packaging we produce? We'd > do some basic testing, of course, but it would be nice if there was > testing against "real world" projects. Yeah. For sure. I could at least build it against my project (large JEE project with lots of subprojects using all sorts of plugins). I am currently using the upstream version as well as Michael Kochs package. Both are fine. > Just to summarise what I understand to be plans for Maven: > > Firstly we want to package maven itself, so that users can > "aptitude install maven", aptitude install maven2 I assume... > and Maven will work just as though the > users had downloaded and installed it manually. > >> * Create a local repository for Maven, e.g. > >> debian/.m2/repository. For each build-dependency create the > >> appropriate directory structure (e.g. > >> debian/.m2/repository/plexus/plexus-utils/1.0.2/). > > > > I would actually suggest to start building a debian build server > > internal maven repository. > > Debian imposes quite strict (but sensible) rules on how its > packages can be built. One restriction is that the package must be > able to be built from source, without downloading anything (except > other packages from the Debian archive). This is the "desert island > test" [1], and probably disallows access to a standard maven > repository. This is why I am proposing creating a temporary local > repository (on the build machine) each time a package is built. I understand that restriction. I was actually proposing to create a debian private repo as part of the Debian archive into which all maven packages and dependencies go as well as into which all future packages can get their artifacts into and use others from there. I look forward to the progress. I wish I could help more but time is very short at the moment... at least I hope to be able to help by giving my input. manfred -- Manfred Moser http://www.mosabuam.com skype: mosabua http://www.linkedin.com/in/manfredmoser -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
