[FFe] Sync libmaven packages from Debian unstable

[Artur Rona]

libmaven-antrun-plugin-java 1.3-1
libmaven-assembly-plugin-java 2.2~beta4-1
libmaven-clean-plugin-java 2.3-3
libmaven-common-artifact-filters-java 1.1-2
libmaven-compiler-plugin-java 2.0.2-4
libmaven-dependency-analyzer-java 1.1-2
libmaven-dependency-plugin-java 2.1-2
libmaven-dependency-tree-java 1.2-2
libmaven-docck-plugin-java 1.0-1
libmaven-doxia-tools-java 1.0.2-2
libmaven-ear-plugin-java 2.3.2-1
libmaven-ejb-plugin-java 2.2-1
libmaven-file-management-java 1.2.1-2
libmaven-filtering-java 1.0~beta-2-4
libmaven-install-plugin-java 2.3-2
libmaven-invoker-java 2.0.10-2
libmaven-invoker-plugin-java 1.3-2
libmaven-jar-plugin-java 2.2-4
libmaven-javadoc-plugin-java 2.5-1
libmaven-plugin-testing-java 1.2-2
libmaven-plugin-tools-java 2.5-2
libmaven-reporting-impl-java 2.0.4.1-4
libmaven-repository-builder-java 1.0~alpha2-1
libmaven-resources-plugin-java 2.3-5
libmaven-scm-java 1.2-2
libmaven-scm-java-doc 1.2-2
libmaven-shade-plugin-java 1.2.1-2
libmaven-shared-io-java 1.1-3
libmaven-site-plugin-java 2.0-2
libmaven-verifier-java 1.0-1
libmaven-war-plugin-java 2.1~beta1-1
libmaven2-core-java 2.2.1-1
libmaven2-core-java-doc 2.2.1-1

Packages needs to sync maven 2.2.1 from Debian unstable. It's FFe request. See bug #416312 and comment 4 there: "suggest to give this a very high priority since the current Maven version in Ubuntu is too old to be usable for anything serious (too many bugs) and this one fixes it all up. It is also already packaged in Debian so should be relatively easy to move over."

[Ilmari Vacklin (wolverian)]

I subscribed motu-releases, since maven2 is in universe, as per https://wiki.ubuntu.com/FreezeExceptionProcess#General%20Instructions

[StefanPotyra (sistpoty)]

What tesing have you done?

What about rdepends?

[Artur Rona (ari-tczew)]

Sorry, but it's too much packages to testing. I don't know what about rdepends.

[StefanPotyra (sistpoty)]

rdepends are reverse dependencies, i.e. packages that depend on maven2 (or other binary packages from the affected source packages). You can find out with apt-cache rdepends <binarypackage>.

At this point in the cycle, I'd very much like to see the packages tested.

[Iulian Udrea (iulian)]

I've just changed the status to Incomplete. Please provide the requested information.

[StefanPotyra (sistpoty)]

Artur, how about you upload it to a PPA and ask the subscribers of bug #416312 to perform some testing?

[Artur Rona (ari-tczew)]

@Stefan
Do you know a script for mass-synchronization in relation: unstable -> ppa ? I'm looking for that, because as you see, libmaven packages is very much.

[StefanPotyra (sistpoty)]

No, I don't have such a script.

[Alvin Thompson (alvint-deactivatedaccount)]

The new version of libplexus is not compatable with Maven 2.0.9, so Maven does not work at all. This is a blocker bug, not a wishlist item. Please change.

[Alvin Thompson (alvint-deactivatedaccount)]

* compatible*

[Artur Rona (ari-tczew)]

@Alvin,
we are testing maven 2.2.1 from Debian unstable. You did test on 2.0.9. which is already in karmic. But OK, soon I'll forward packages to my-ppa and you'll can test maven 2.2.1 with rdepends.

[Alvin Thompson (alvint-deactivatedaccount)]

I meant that the Maven that is currently in Karmic (2.0.9) does is completely broken (does not work at all with the synced version of libplexus). In this case Maven must be synced with libplexus in order for Maven to work. Since libplexus has already been synced, syncing the Maven package is no longer optional (unless having a Maven package in Karmic that doesn't work is considered acceptable). Therefore this can't be considered a wishlist item on Karmic.

[Alvin Thompson (alvint-deactivatedaccount)]

The other alternative would be to slot the old versions of Maven's dependencies.

[Chris (chris-yourdreamnet)]

Following Sync guidelines:

Source package name: maven2
Sync version: 2.2.1-1
Sync from: Debian sid experimental
Changelog since current version:

 maven2 (2.2.1-1) unstable; urgency=low

   * New upstream release (Closes: #542546)
   * Update download url for debian/watch and debian/orig-tar.sh
   * Update Standards-Version to 3.8.3
      - add debian/README.source
   * Fix bash completion to keep working after single options such
     as --offline or -Dmaven.test.skip=true
   * Ensure that all classes are compiled for Java 1.5 (Closes: #542162)

 -- Ludovic Claude <email address hidden> Thu, 03 Sep 2009 20:42:38 +0100
maven2 (2.2.0-2) unstable; urgency=low

   * Upload to unstable.

 -- Torsten Werner <email address hidden> Fri, 14 Aug 2009 14:59:25 +0200
maven2 (2.2.0-1) experimental; urgency=low

   * New upstream version
   * Added myself to Uploaders.
   * Change section to java, bump Standards-Version to 3.8.1
   * Add a Build-Depends-Indep dependency on maven-repo-helper
   * Move ant to Build-Depends (needed for clean target)
   * Add dependency on java runtimes for the maven2 binary.
   * Change the dependency on java-gcj to default-jdk (Closes: #526295)
   * Update watch and added orig-tar.sh to download the sources,
     get-orig-source in rules now uses uscan
   * Use quilt to manage the patches, add a patch to use the upstream
     build.xml as the build file, disabling all dependency downloading from it
   * Split the package in 2 parts: maven2-core contains all libraries,
     this package contains only the uber jar and the scripts
   * Updated the build to use Maven and its plugins to bootstrap itself,
     based on a patched version of the build.xml boostrap script provided
     with Maven. In particular, it now generates properly the shaded uber-jar,
     this will avoid potential class versionning conflicts for the shared
     libraries used in the plugins.
   * Added Build-Depends-Indep on libmaven-clean-plugin-java,
     libmaven-compiler-plugin-java, libmaven-install-plugin-java,
     libmaven-jar-plugin-java, libmaven-resources-plugin-java,
     libmaven-shade-plugin-java and add a Recommends on those libraries.
   * Remove debian/META-INF as this information is now generated by the build.
   * Improve command line completion.

 -- Ludovic Claude <email address hidden> Mon, 02 Mar 2009 15:04:20 +0000

No Ubuntu changes made to Debian package therefore no changes to be dropped.

Installed locally from Debian repo successfully. Testing proves no bugs in normal operation, significant improvement to current state of inoperable.

[Alvin Thompson (alvint-deactivatedaccount)]

great! perhaps we can get this 'wishlist' item added then.... :)

[Fabrice Coutadeur (fabricesp)]

Putting back as new, so that MOTU Release can check the FFe.

[Fabrice Coutadeur (fabricesp)]

Wrong: the information requested by the MOTU Release team has not been provided.
Setting back to incomplete

[Fabrice Coutadeur (fabricesp)]

Hi,

Also, I tried earlier in the cycle to get the maven package in a good shape, and this is the mail exchange I had with ttx:
fabrice wrote:

> > As spoken in irc, I've been trying to get the maven packages in a good
> > shape. You can see in my ppa (1), the actual status of the 'required'
> > packages to build (or try to build) the maven packages, at least the
> > maven-plugin-tools one.

Hey Fabrice,

Thanks for your efforts on this. From a release schedule perspective, we
are one week before Karmic feature freeze and adding support now for a
new build system (and syncing 21 packages in the process) is not a good
idea. Furthermore from a Ubuntu server perspective, we are looking for
some stability in the Java infrastructure as we do last-minute
pre-freeze work on adding new software that depends on it. FWIW, we are
considering a Java library update freeze for the next cycle (that would
occur roughly one month before feature freeze) to enforce this required
stability.

That's why I recommended keeping all the new maven goodness out of
karmic and let it mature in Debian unstable, so that it's ready for the
karmic+1 sync/merge period.

The interest of having maven support is to enable packaging stuff that
depends on maven, which won't be done for karmic anyway. It sounds right
to enable the stack at the very beginning of the karmic+1 cycle to
potentially allow for maven-based packaging during that cycle.

> > For the moment, I have 21 packages, but as Onkar told me, we shouldn't
> > sync for the moment packages outside the 'maven' world that uses
> > maven-repo-helper:

Yes, that's what I told Onkar: I don't really mind syncing new packages
since they won't interfere with anything (even if I fail to see a good
reason to do so one week before featurefreeze)...

> > [...]
> > As you can see, 6 packages are required for the moment, to have a chance
> > to build maven-plugin-tools (and still misses some, as it still FTBFS
> > for the moment).
> >
> > So my question is: is it worth trying to sync all the maven packages, as
> > they will FTBFS without that at least 6 non maven packages? Or there is
> > some magic that can be applied to the packages that required this ones
> > so that they can build without the updated version of this 6 packages?
> > Or the maven packages will stays as-is?

...but if there is no point in syncing this part without also updating
the non-maven packages, or worse, if it creates FTBFS in the process,
then I don't see why we would sync it incompletely. And I would just
concentrate on testing it/improving it in unstable in the next months
and make sure it's ready for sync at the opening of karmic+1.

-- Thierry Carrez Ubuntu server team

[Manfred Moser (mosabua)]

As a Java developer that uses Maven professionally and develops on Ubuntu every day I would strongly suggest to upgrade Maven. Otherwise I would actually remove Maven2 as a package since that would at least force users to install from the upstream tar and use the latest one instead of using the old 2.0.9 release and suffer from some of the severe problems with it that are actually really hard to find sometimes.

[Manfred Moser (mosabua)]

Oh and btw. I have been routinely using the Debian packages in production on Ubuntu for a while and had no problems whatsoever.

[Martin Meyer (elreydetodo)]

I hate to repeat things and sound like a screaming lunatic, but this is the argument for syncing maven NOW instead of AFTER release:

YOU CANNOT RUN THE MAVEN INCLUDED IN KARMIC.

This package is BROKEN. If you do not either sync from debian or revert libplexus there will be NO use for having a maven2 package in Karmic at all - you might as well just drop the package entirely rather than give the false impression that you have an (old but working) version in the software repo.

[Scott Kitterman (kitterman)]

What we really need is for someone who is familiar with Maven to assess the
current situation and give us a good plan forward.

[Artur Rona (ari-tczew)]

Please updating bug description for packages which are needed to get into karmic.

[Scott Kitterman (kitterman)]

On Sun, 04 Oct 2009 01:53:09 -0000 Manfred Moser <email address hidden>
wrote:
>Oh and btw. I have been routinely using the Debian packages in
>production on Ubuntu for a while and had no problems whatsoever.
>

Which packages and what versions?

[Manfred Moser (mosabua)]

Maven 2.2.1 from the debian sid/squeeze repo as packaged as 2.2.1-1 at the moment. See http://packages.debian.org/sid/maven2. I follow the list <email address hidden> to see what updates are coming and in update from these repos.

[Manfred Moser (mosabua)]

Oh and Scott. I agree with Martin .. if the package stays as is it is not usable at all and should actually be removed and people should use the upstream install instead. That would be a sad state of affairs..

[Scott Kitterman (kitterman)]

Right. No one wants to leave it broken, the problem is none of the Ubuntu
devs involved in this conversation use it, so it isn't always clear to us
the path forward.

[Alvin Thompson (alvint-deactivatedaccount)]

Well put Martin! For a while there I thought everyone had gone nuts. I know no one wants extra work this close to a release but there are a lot of people (myself included) who depend on Maven.

[Scott Kitterman (kitterman)]

So we have a bit of a problem. I did take a look at this and maven2 now needs libmaven-clean-plugin-java to build. Unfortunately, the source for this package (maven-clean-plugin) also build depends on libmaven-clean-plugin-java, so there is no way to build it without manual bootstrapping. I'll ask a buildd admin about doing it, but no guarantees.

[LumpyCustard (orangelumpycustard)]

Thanks for looking at this Scott :)

I use this package for work, and so does everyone else in my team - it's integral to our work, so having this not working in Karmic would be rather frustrating to say the least.

Usually I wouldn't post a message like this, but given the importance of this package, I feel it's reasonable.

[Scott Kitterman (kitterman)]

Lamont is working on bootstrapping now.

[Matthias Klose (doko)]

we'll need to build things from source, how about this one: http://bugs.debian.org/545631 ? needed for the initial bootstrap?

[Matthias Klose (doko)]

declining the syncs/merges for ant, commons-httpclient, junit, libgoogle-collections-java, which would pull in maven2 into main.
I don't mind any other outstanding syncs which would make it easier to build maven2 in lucid, plus keeping it out of main.

[Matthias Klose (doko)]

question for lucid: how to build maven2 without the updated ant, commons-httpclient, junit, libgoogle-collections-java packages?

[Craig (candrews-integralblue)]

I'm seeing some less than ideal comments here. Does this all mean that the release team has given up on Maven working in Karmic?

[Martin Meyer (elreydetodo)]

If you are not going to sync maven & family for Karmic then you MUST remove the maven2 package from the apt repository entirely.

The only thing worse than a really old version in the repo is a really old version that doesn't actually work when you install it!

[Armando Di Cianno (armando-goodship)]

I stumbled upon this issue last night when trying out Lift / Scala, and the getting started guide has an example using maven. Installed it, immediate failure when I tried to run. The program crashes and described in this and related bugs, because of libraries being out of sync with maven2.

This is pretty much unacceptable. I would suggest getting a working version into Karmic, but if you really must, completely remove maven. It'll save people a lot of time, so they won't even try to debug the crashing.

Thanks.

[Alvin Thompson (alvint-deactivatedaccount)]

I agree with comment #37. Also, during the upgrade process from earlier versions of Ubuntu you must warn people (before they commit to the upgrade) that maven will no longer work.

[Alvin Thompson (alvint-deactivatedaccount)]

Bug #417164 and Bug #416312 explain why Maven no longer works.

[Alvin Thompson (alvint-deactivatedaccount)]

Whoops, wrong bug report...

[Pascal T (pascal-thivent)]

I was really hoping to get the latest version of maven2 in Karmic as it might be the last release of maven's 2.x branch (pretty stable now) and the last chance to include it. Indeed, maven3 is coming and including maven2 in Karmic+1 will thus be pretty useless. On top of that, this will lead to upgrading hell again (I bet maven 3.x will be released more frequently than every 6 months) so we'll end up with an almost immediate obsolete versions. And because maven2 is **unusable** right now, it should just be removed. Very bad news for Java users on Karmic. Sadly, +1 with comment #37.

[Nicolas Dumoulin (nicolas-dumoulin)]

I use daily maven2, and I agree that a solution should be found urgently: fix or remove, but decide what to do.

For instance, I keep the old version of plexus (libplexus-container-default-java_1.0-alpha-9-stable-1-2_all.deb) and all is working fine.
I haven't understand why this new version of libplexus is needed ?

[Artur Rona (ari-tczew)]

For questions about getting maven2 into karmic, go to Matthias Klose (doko).
Workaround is install maven2 from ppa:
https://launchpad.net/~uninea/+archive/java
Please test it and give feedback.

[Matthias Klose (doko)]

Artur, some questions:

 - many of the packages from your archive are already in karmic:
   as source packages which need to be built. Do you have a list of
   souce packages which are not yet in karmic, but need to get
  imported from unstable?

- How did you build these packages? We have to rebuild all packages
  entering into ubuntu, and the difficulty is to get it right. which
  exact steps did you make to build these?

I'll try to look at the building stuff this weekend, but would like to save some time if you already did figure out the above.

Thanks, Matthias

[Artur Rona (ari-tczew)]

Dnia 2009-10-16, pią o godzinie 09:22 +0000, Matthias Klose pisze:
> Artur, some questions:
>
> - many of the packages from your archive are already in karmic:
> as source packages which need to be built. Do you have a list of
> souce packages which are not yet in karmic, but need to get
> imported from unstable?
>
Here is.
[debian_unstable-package-name] [version]
libmaven-antrun-plugin-java 1.3-1
libmaven-assembly-plugin-java 2.2~beta4-1
libmaven-common-artifact-filters-java 1.1-2
libmaven-compiler-plugin-java 2.0.2-4
libmaven-dependency-analyzer-java 1.1-2
libmaven-dependency-plugin-java 2.1-2
libmaven-dependency-tree-java 1.2-2
libmaven-docck-plugin-java 1.0-1
libmaven-doxia-tools-java 1.0.2-2
libmaven-ear-plugin-java 2.3.2-1
libmaven-ejb-plugin-java 2.2-1
libmaven-file-management-java 1.2.1-2
libmaven-filtering-java 1.0~beta-2-4
libmaven-install-plugin-java 2.3-2
libmaven-invoker-java 2.0.10-2
libmaven-invoker-plugin-java 1.3-2
libmaven-jar-plugin-java 2.2-4
libmaven-javadoc-plugin-java 2.5-1
libmaven-plugin-testing-java 1.2-2
libmaven-plugin-tools-java 2.5-2
libmaven-reporting-impl-java 2.0.4.1-4
libmaven-repository-builder-java 1.0~alpha2-1
libmaven-resources-plugin-java 2.3-5
libmaven-scm-java 1.2-2
libmaven-scm-java-doc 1.2-2
libmaven-shade-plugin-java 1.2.1-2
libmaven-shared-io-java 1.1-3
libmaven-site-plugin-java 2.0-2
libmaven-verifier-java 1.0-1
libmaven-war-plugin-java 2.1~beta1-1
libmaven2-core-java 2.2.1-1
libmaven2-core-java-doc 2.2.1-1
libmaven-clean-plugin-java 2.3-3
maven-debian-helper
libplexus-sec-dispatcher-java
libplexus-cdc-java
libplexus-maven-plugin-java

> - How did you build these packages? We have to rebuild all packages
> entering into ubuntu, and the difficulty is to get it right. which
> exact steps did you make to build these?
FYI: If you think that uninea is my ppa, you're wrong.
Procedure:
1) Download .orig.tar.gz, .diff.gz, .dsc from Debian's ftp
2) dpkg-source -x *.dsc and go to new created folder
3) Edit debian/changelog - prepare to upload into my-ppa
4) Looking at builder on my-ppa.
If any package got FTBFS and if reason is missing any package, I'm
looking into debian/control for field called "Build-Depends-Indep" then
again go to packages.debian.org and repeat procedure.

> I'll try to look at the building stuff this weekend, but would like to
> save some time if you already did figure out the above.
You can ask me on #ubuntu-motu for more questions.

[Steve Langasek (vorlon)]

These tasks are all duplicates of bug #446263, which has been fixed.

[Artur Rona (ari-tczew)]

maven2-core still FTBFS. From buildlog (ppa):
BUILD FAILED
/build/buildd/maven2-core-2.2.1/debian/build.xml:98: The following error occurred while executing this line:
/build/buildd/maven2-core-2.2.1/debian/build.xml:22: The following error occurred while executing this line:
/usr/share/maven-ant-helper/maven-build.xml:295: Compile failed; see the compiler error output for details.

[Matthias Klose (doko)]

leaving the Ubuntu CoC a bit alone ... I'm a bit pissed about comments like "maven2-core *still* FTBFS", "agreements on a solution", "must be synced", "using Maven professionally", and so on. If you cannot maintain maven or give substantial feedback to get to a solution, then please don't rely on it. The eucalyptus team had a very good reason to rewrite the build scripts to just use ant. And I do see this as a very good reason not to include maven in lucid/main.

[Alvin Thompson (alvint-deactivatedaccount)]

Mathias, I'm not sure I understand your comment. Isn't it the maintainer's job to maintain Maven? By your logic, if I don't know enough about the trip computer in my car to maintain it, I shouldn't rely on my car?

Also, I love Ubuntu and have been using it exclusively since Breezy, but it does have a bit of a reputation for having bugs that go unfixed (often for years) unless a critical mass of people are vocal enough about them. Clearly, maintainers are volunteers and don't have the time to fix every bug, and that's why I would think that comments such as the ones you mentioned are critical for helping you decide which get priority.

[Artur Rona (ari-tczew)]

Matthias, take it easy! I wrote only information from ppa, because there are rebuilt package automatically.

[Scott Kitterman (kitterman)]

I can sympathize with Doko's frustration. Personally, I find the "OMG,
kittens will die" comments from people not involved in Ubuntu development
very frustrating and demotivating. Personally, maven doesn't affect me at
all.

It'd be nice if more people who cared about Java were more involved. There
is a Java team in Ubuntu, but it's almost dead due to lack of
participation.

[Armando Di Cianno (armando-goodship)]

@Matthias and Scott

I can understand your frustration, as well -- I was an official developer for another distro circa 2003-2006. Dealing with emotions, "cares", and the people attached to them, via bug reports, can be difficult, and is almost always frustrating.

However, the statements made above are asinine. I'm simply *not* a Java developer, in a traditional way. I was a) Trying to use Maven with a Ruby (JRuby) application I've inherited, and b) I'm trying to get my feet wet with Scala (whos' tutorial references and uses Maven). While I'm slowly becoming accustomed to the complexity of launching, running, and maintaining Java applications, I personally only view Maven as a tool in my arsenal.

Maven is (erroneously often times) compared to 'make', as it is frequently used similarly. Can you imagine if 'make' was broken? And would you demand that bug reporters were C language masters if they were reporting how a broken 'make' was affecting their application?

In other distros I've developed for, or simply used, I've never seen people /discouraged/ from reporting bugs, or extending reports, even if the additional information was "This is how it broke for me, and this is why I care / what I'm doing."

I'm *really* glad this bug is getting resolved. I'm sorry if my last comment wasn't especially helpful, however, I'd suggest offering critical commentary on what is helpful in a comment, instead of "complaining about complaint comments", so to speak. The statement from Scott that "I find the "OMG, kittens will die" comments from people not involved in Ubuntu development very frustrating and demotivating" is itself extremely demotivating, unprofessional, and rather /unkind/, and most certainly not something I expected from the Ubuntu developers and community.

Again, thanks for the work and fixes.

[Artur Rona (ari-tczew)]

maven2 (2.2.1-1) unstable; urgency=low

  * New upstream release (Closes: #542546)
  * Update download url for debian/watch and debian/orig-tar.sh
  * Update Standards-Version to 3.8.3
     - add debian/README.source
  * Fix bash completion to keep working after single options such
    as --offline or -Dmaven.test.skip=true
  * Ensure that all classes are compiled for Java 1.5 (Closes: #542162)

 -- Ludovic Claude <email address hidden> Thu, 03 Sep 2009 20:42:38 +0100

[Brian Burch (brian-pingtoo)]

I expect that I am being stupid, but please be patient!

I installed karmic and am in the process of trying to migrate all my development to it... I noticed maven was broken a month ago, but didn't have time to investigate and kept using my old hardy LTS system when necessary. I've now reached the point where maven2 was the ONLY thing left before I can switch over completely and get rid of the hardy system.

I wasn't surprised to find maven was still broken, because I expected it to be a problem with my own configuration. After careful problem determination and fixing what was wrong, maven still wouldn't run at all. I googled and was amazed to hit this bug - karmic was released in November and January is almost gone!

Now the stupid bit.... I think this bug report is telling me there is a fixed version, but synaptic is telling me I have the latest version 2.2.1-1 already installed and there are no alternatives available. Please explain to me: do I need to add another repository, and if yes, what is the APT line that identifies it?

I am happy to try using an unstable release of maven, because the current version is worthless... however, I don't want to risk trashing my existing karmic java development environment that has taken a month to get working properly!

[Matthias Klose (doko)]

please setup a chroot (or virtual machine) with current lucid, and try to reproduce this error, without installing anything from other archives/PPAs. See the wiki pages how to setup an ubuntu version in a chroot.

[Brian Burch (brian-pingtoo)]

Matthius - I think you are telling me to install the entire lucid system. Is that right? I think you suggested chroot or a VM as alternative platforms?

I already have a multi-boot system and have even converted to grub2 on my boot partition. I recently eliminated jaunty (hence my desire to eliminate hardy as well), so have some unallocated disk space. Wouldn't it be simpler for me to install lucid as a new bootable system?

If I'm installing a whole new distribution (I am not 100% sure this is what you mean), what is the point? Do you want me to test maven on lucid for your own reasons (I will help if I don't spend too much time)?

However, I want to run maven asap under karmic... I have a lot of non-standard packages because I run ubuntu studio (karmic) on my laptop and also use the same system for software development. What would I gain personally from testing maven under lucid?

[Matthias Klose (doko)]

On 21.01.2010 17:56, Brian Burch wrote:
> Matthius - I think you are telling me to install the entire lucid
> system. Is that right? I think you suggested chroot or a VM as
> alternative platforms?

https://help.ubuntu.com/community/DebootstrapChroot

> I already have a multi-boot system and have even converted to grub2 on
> my boot partition. I recently eliminated jaunty (hence my desire to
> eliminate hardy as well), so have some unallocated disk space. Wouldn't
> it be simpler for me to install lucid as a new bootable system?
>
> If I'm installing a whole new distribution (I am not 100% sure this is
> what you mean), what is the point? Do you want me to test maven on lucid
> for your own reasons (I will help if I don't spend too much time)?
>
> However, I want to run maven asap under karmic... I have a lot of non-
> standard packages because I run ubuntu studio (karmic) on my laptop and
> also use the same system for software development. What would I gain
> personally from testing maven under lucid?

I'm not interested in any setup which includes packages from a PPA or custom
built packages. If there is a problem, it should be fixed in lucid first, then
updated in karmic

[Brian Burch (brian-pingtoo)]

Sorry about the delay, Matthias. Thank you for the wiki link: I built the schroot lucid system relatively easily. I then hit a several of snags getting the system to work properly with me as a user (off topic: cryptfs, non-standard uid/gid for ldap, etc).

Currently, my /etc/apt/sources.list contains ONLY "deb http://archive.ubuntu.com/ubuntu lucid main". I found and successfully installed the ant and junit packages, but "aptitude search maven" only finds maven-ant-helper and maven-repo-helper. What repository should I add to pick up your latest lucid maven2 version, please?

[Matthias Klose (doko)]

the universe section needs to be added as well, also having the source sections doesn't hurt, so you are able to get the relevant source packages:

deb http://archive.ubuntu.com/ubuntu lucid main universe
deb-src http://archive.ubuntu.com/ubuntu lucid main universe

[Brian Burch (brian-pingtoo)]

Excellent news! I installed maven2 from the lucid universe repository. I then copied two sample maven-based projects to the new schrooted system. They both built and tested successfully. Because the original maven bug was so fundamental (it failed to run even without a maven project), I am happy to report the problem has been fixed on lucid.

Well done, Matthius. Thank you for your efforts and particularly for helping me with testing. I hope it won't be too long before the equivalent changes become available on karmic.

I can now convert my own projects to run temporarily under lucid and retire my old hardy system at last. Any further problems I might encounter when I convert these projects will not be relevant to this bug.

[Matthias Klose (doko)]

On 27.01.2010 18:25, Brian Burch wrote:
> I am happy to report the problem has been fixed on lucid.

> Well done, Matthius. Thank you for your efforts and particularly for
> helping me with testing. I hope it won't be too long before the
> equivalent changes become available on karmic.

well, then we have to find out which updates are needed for karmic. now that you
are used to setup a chroot, would it be possible to recheck this in a "clean"
karmic chroot? And then trying to find out which packages need to be fixed for
karmic. of course only if you want to see these bugs fixed in karmic.

[Matthias Klose (doko)]

On 27.01.2010 18:40, Matthias Klose wrote:
> On 27.01.2010 18:25, Brian Burch wrote:
>> I am happy to report the problem has been fixed on lucid.
>
>> Well done, Matthius. Thank you for your efforts and particularly for
>> helping me with testing. I hope it won't be too long before the
>> equivalent changes become available on karmic.
>
> well, then we have to find out which updates are needed for karmic. now that you
> are used to setup a chroot, would it be possible to recheck this in a "clean"
> karmic chroot? And then trying to find out which packages need to be fixed for
> karmic. of course only if you want to see these bugs fixed in karmic.

if you do that, be sure to add the karmic-updates and security lines into
/etc/apt/sources.list in your chroot (copying these lines from your karmic
installation).

[Brian Burch (brian-pingtoo)]

I will try to set the system up, but please don't expect to hear anything soon because I'll have poor internet access for a while.

[Brian Burch (brian-pingtoo)]

Installed karmic maven in fresh schroot system. Very slow where I am at the moment. Just a quick note to say it worked on my 1st sample project, which was a complete surprise! Will test some more...

[Brian Burch (brian-pingtoo)]

I think I understand my problem, and also have a bypass.

When I created the clean karmic maven schroot system, I was surprised to find that it responded OK to "mvn --help", because this simple command would always crash on my "production" karmic system.

I went back to my production karmic system - the help worked fine (it had failed every time before), and I could build my sample project. What had changed?

Scratching around, I checked an backup copy of the ~/.m2/ directory.... it was full of stuff that maven had cached. However my mysteriously working production system and my schroot karmic and lucid systems all had almost-empty contents for this directory.

I guess that I had previously created a corrupt maven cache by copying .m2 onto my "production" karmic system. Something (probably running maven when not connected to the internet) had cleaned it out. With an almost-empty .m2, maven could respond to help. The next time I built my sample project while onlne, it automatically downloaded the correct support files and the build worked.

I suggest that anyone suffering from this bug tries the following bypass:

1. rename ~/.m2/ to something else.
2. mvn --help

... then, if the help runs OK...
3. cd myProject
4. mvn clean install

I hope that works for you as well as it does for me!

[Brian Burch (brian-pingtoo)]

I have now built and tested several maven projects under all of my three systems: karmic production, minimal karmic schroot and lucid schroot.

All of them worked exactly as expected. As far as I am concerned, the latest maven2 distributions are acceptable. My evidence suggests that the original bug report (mvn --help crashes) should be closed. The most likely cause of the crashes is incompatible back-level ~/.m2/repository/ cache.

I do not think there is a strong case for the package installation script to wipe out the cache - unless this action is recommended by the maven development team. I will leave that issue for Matthius to make a decision.

Thanks for your help, Matthius! I am sorry that so many of us maven users doubted the quality of your package.