Bug#775010: libmaven-archiver-java: please allow pom.properties' date to be deterministic

2015-01-10 Thread Chris West
Yeah, DEB_BUILD_DATE makes me less uneasy, too.

I've updated the patch to replace the line.  This assumes
that it is present; would be great if this kind of thing
was specified.  It's hard to verify the assumption as the
date comes out in locale format.

From 4462124973f36a06d2e8695f789c4bc5beb8eaff Mon Sep 17 00:00:00 2001
From: Chris West (Faux) g...@goeswhere.com
Date: Sat, 10 Jan 2015 16:48:22 +
Subject: [PATCH] honour DEB_BUILD_DATE when generating pom.properties (lines)

---
 .../apache/maven/archiver/PomPropertiesUtil.java   | 70 +-
 .../maven/archiver/PomPropertiesUtilTest.java  | 24 
 2 files changed, 93 insertions(+), 1 deletion(-)
 create mode 100644 src/test/java/org/apache/maven/archiver/PomPropertiesUtilTest.java

diff --git a/src/main/java/org/apache/maven/archiver/PomPropertiesUtil.java b/src/main/java/org/apache/maven/archiver/PomPropertiesUtil.java
index 5e0a41b..e294419 100644
--- a/src/main/java/org/apache/maven/archiver/PomPropertiesUtil.java
+++ b/src/main/java/org/apache/maven/archiver/PomPropertiesUtil.java
@@ -19,13 +19,21 @@ package org.apache.maven.archiver;
  * under the License.
  */
 
+import java.io.BufferedWriter;
 import java.io.File;
 import java.io.FileInputStream;
 import java.io.FileOutputStream;
 import java.io.IOException;
 import java.io.InputStream;
 import java.io.OutputStream;
+import java.io.OutputStreamWriter;
+import java.io.StringWriter;
+import java.text.ParseException;
+import java.text.SimpleDateFormat;
+import java.util.Arrays;
+import java.util.Date;
 import java.util.Properties;
+import java.util.regex.Pattern;
 
 import org.apache.maven.project.MavenProject;
 import org.codehaus.plexus.archiver.Archiver;
@@ -85,7 +93,7 @@ public class PomPropertiesUtil
 OutputStream os = new FileOutputStream( outputFile );
 try
 {
-properties.store( os, GENERATED_BY_MAVEN );
+storeWithCustomTimestamp( properties, os, GENERATED_BY_MAVEN );
 os.close(); // stream is flushed but not closed by Properties.store()
 os = null;
 }
@@ -95,6 +103,66 @@ public class PomPropertiesUtil
 }
 }
 
+private static Date findBuildDate() {
+final String envName = DEB_BUILD_DATE;
+final String envVariable = System.getenv(envName);
+if (null == envVariable) {
+return null;
+}
+
+try {
+return new SimpleDateFormat(EEE, dd MMM  HH:mm:ss zzz).parse(envVariable);
+} catch (ParseException e) {
+throw new IllegalStateException(maven-archiver:  + envName +  not in recognised format, e);
+}
+}
+
+/**
+ * Replace the date in the file with the specified date, and sort the properties
+ *
+ * @param lines line 1: comment, line 2: date, line 3 onwards: properties
+ */
+static void mangle(String[] lines, Date buildDate) {
+lines[1] = # + buildDate.toString();
+Arrays.sort(lines, 2, lines.length);
+}
+
+private void storeWithCustomTimestamp(Properties properties, OutputStream os, String comment) throws IOException {
+final String[] lines = propertyFileLines(properties, comment);
+
+final Date buildDate = findBuildDate();
+if (null != buildDate) {
+mangle(lines, buildDate);
+}
+
+writeLines(os, lines);
+}
+
+private static String[] propertyFileLines(Properties properties, String comment) throws IOException {
+final StringWriter stringWriter = new StringWriter();
+try {
+properties.store(stringWriter, comment);
+} finally {
+stringWriter.close();
+}
+
+return stringWriter.toString()
+.split(Pattern.quote(System.getProperty(line.separator)));
+}
+
+private static void writeLines(OutputStream os, String[] lines) throws IOException {
+final BufferedWriter writer = new BufferedWriter(new OutputStreamWriter(os, ISO-8859-1));
+try {
+for (String line : lines) {
+writer.write(line);
+writer.newLine();
+}
+} finally {
+writer.flush();
+writer.close();
+}
+}
+
 /**
  * Creates the pom.properties file.
  */
diff --git a/src/test/java/org/apache/maven/archiver/PomPropertiesUtilTest.java b/src/test/java/org/apache/maven/archiver/PomPropertiesUtilTest.java
new file mode 100644
index 000..b051b2d
--- /dev/null
+++ b/src/test/java/org/apache/maven/archiver/PomPropertiesUtilTest.java
@@ -0,0 +1,24 @@
+package org.apache.maven.archiver;
+
+import junit.framework.TestCase;
+
+import java.util.Arrays;
+import java.util.Date;
+
+import static org.apache.maven.archiver.PomPropertiesUtil.mangle;
+
+public class PomPropertiesUtilTest extends TestCase {
+
+public void testMangle() {
+final Date date = new Date(1);
+final String[] input = {#foo bar, # + new 

Re: Updating Eclipse

2015-01-10 Thread Niels Thykier
On 2015-01-09 20:21, Markus Koschany wrote:
 Hi Pascal,

 On 09.01.2015 19:43, Pascal Rapicault wrote:
 Hi,


Hi Pascal,

(NB: Please CC me explicit on replies as I am not subscribed to debian-java)

For reference, I am more than happy to provide advice and technical aid
where possible.  But I am not able to be a co-maintainer of eclipse.

 My name is Pascal Rapicault. I'm a long time committer on the Eclipse
 platform, and I've recently been tasked by Ericsson to:
 1 - bring new versions of Eclipse to debian
 2 - make sure the experience of using eclipse on debian is good (from an
 installation pov)
 3 - make sure the user can get multiple versions of Eclipse installed at
 the same time but not all merged (e.g. IDE for C/C++, IDE for Java, etc.)
 4 - find a way to streamline the push of Eclipse to debian
 
 Thank your for your interest in Eclipse and the state of Java packages
 in Debian. [...]
 

Indeed thanks for your interest.  And thanks to Ericsson as well. :)

 I recently worked on a mechanism that creates debian packages from an
 eclipse distro as a single package (all the jars and other files are in
 one package) and is also able to collect the dependencies on native
 packages. This works quite well since it makes it easy for the users to
 get a functional starting point (IDE for Java, IDE for C/C++) that they
 can customize, and allows multiple IDEs to be installed separately.

 Now a couple questions:
 - Would the package I describe above be suitable to be made available in
 the main debian repo? (I assume no, but I may as well check :))

I strongly suspect the answer to be no as well.  Debian is not really
that much into fat packages, static linking or the strictly equals
dependencies (outside binaries built from same source package).

 - What are the reasons why Eclipse is no longer updated, technical,
 political, volunteers?

I suspect mostly lacking volunteers willing to provide a debian package
under the technical and political requirements of Debian.

 - What are the requirements to package Eclipse for debian?

I believe Markus already touched on some of these.  I only have an
incomplete list.  None that some of my remarks / follow comments here
are based on my time as Debian maintainer of eclipse (mostly active
during 2009-2011ish). Anyhow:

 * DFSG compatible licenses.  Here Eclipse general excels with its IP
   and rigid handling of copyright/licenses.
 * Rebuild things from source.  Some of it works, except for the
   bootstrap problem.  Namely to compile eclipse you (used to?) require
   eclipse.
 * No / Avoid bundling of libraries and avoid static linking.
 * Rebuild everything *without internet*.  Mostly an issue with maven.
   In my time, Eclipse did not have an issue here, but I heard they
   considered moving to maven or so?
 * Debian generally tries to avoid = $version dependencies, which are
   fairly common in the Java world (if I am not mistaken).
 * The package must be policy compliant[1].  That is a long read, so
   I would not start here.  For reference, the current eclipse package
   is mostly good enough.
   - I would recommend getting a working compile first and then worry
 about policy compliance afterwards.

 - What are the most painful aspects of this process? 
 [...]

Again note that my remarks here are based from my experience and may
have changed since 2011.  Hopefully you will find it easier - your time
as Eclipse committer might make a lot of things easier for you.  Also
please note that some of these issues are not specific to Debian (e.g.
Fedora have similar concerns).

 * Eclipse upstream and Debian had different ideas on certain things
   like how much should be rebuilt from source.
   - Debian: Everything *must* be rebuildable and everything *should* be
 be rebuilt during a package build.
   - Eclipse: Automatic rebuilds are /sometimes/ an afterthought or not
 done at all (e.g. because they consume the official binaries of
 XYZ).
 * Providing patches to Eclipse upstream was generally difficult.  I
   suspect you will it a lot easier here, being already integrated
   upstream.
   - My problems were mostly I find a problem at X, where do I file a
 bug (i.e. which component maintains X)?
   - During most of my involvement, I had to rely on others having time
 to commit my patches.  I did manage to become a committer at some
 point, but at that time I had mostly burned out.
 * The bootstrap problem.  To have compile eclipse version X, you
   generally need(ed?) eclipse X to pre-build some build files.
   - Some people from Fedora started an eclipse-build project[2] to
 solve the bootstrap problem and ease automatic building of eclipse
 (from scratch).
   - The bootstrap problem is/was solved by pre-compiling some build
 scripts, which were used to bootstrap enough of eclipse for it to
 generate build scripts.  Here after everything is rebuilt just to
 prove everything is buildable.  This is the 

javatools 0.48 MIGRATED to testing

2015-01-10 Thread Debian testing watch
FYI: The status of the javatools source package
in Debian's testing distribution has changed.

  Previous version: 0.47
  Current version:  0.48

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.


Bug#775010: libmaven-archiver-java: please allow pom.properties' date to be deterministic

2015-01-10 Thread Emmanuel Bourg
Le 10/01/2015 17:54, Chris West a écrit :

 I've updated the patch to replace the line.  This assumes
 that it is present; would be great if this kind of thing
 was specified.  It's hard to verify the assumption as the
 date comes out in locale format.

Thank you for the update. It's safe to assume the date always follow the
comment specified, the Javadoc for the store() method states:

Next, a comment line is always written, consisting of an ASCII #
character, the current date and time (as if produced by the toString
method of Date for the current time), and a line separator as generated
by the Writer.

The call to Arrays.sort() isn't necessary but it doesn't hurt.

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.


Bug#773805: liblucene4-java: Incomplete poms installed in /usr/share/maven-repo

2015-01-10 Thread tony mancill
On 01/07/2015 10:41 PM, Niels Thykier wrote:
 On 2015-01-08 05:17, tony mancill wrote:
 [...]


 Hello Hilko, Emmanuel,

 I'm taking a look at this, but in the interest of the jessie release, I
 wanted to ask Emmanuel whether it would be okay to decrease the severity.

 We have a number of other packages with missing or incomplete poms, and
 propose that we discuss maven metadata for all Java library packages as
 a release goal for jessie + 1.

 Otherwise, the package will be removed soonish (February 5th).

 https://tracker.debian.org/pkg/lucene4

 Thanks,
 tony

 [...]
 
 Hi,
 
 If the bug is RC on its own, but you believe it is irrelevant for the
 Jessie release, the correct option would be to have it ignored (please
 file a bug against release.debian.org for that).
   Mind you, the assumption is that the bug is in fact RC.  If not, the
 release team will probably recommend downgrading it instead.
 
 If the bug only prevents new packages from being build (i.e. packages
 not already in Jessie/sid), it /sounds/ like it might not be RC after
 all (maybe important).  However, please keep in mind that my answer is
 solely based on the above mail.

Hi Niels,

Thank you for the guidance.  In the case of #773805 (maven pom), I do
believe that it's not RC from a severity standpoint.

I think #773829 might fall into the same category, although I do have a
patch and will be uploading a new package with just this build change
tomorrow morning.

Cheers,
tony




signature.asc
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Processed: tagging 773829, owner 773829

2015-01-10 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 tags 773829 + pending
Bug #773829 [src:lucene4] lucene4: JavaCC parsers are not generated during the 
build
Added tag(s) pending.
 owner 773829 tmanc...@debian.org
Bug #773829 [src:lucene4] lucene4: JavaCC parsers are not generated during the 
build
Owner recorded as tmanc...@debian.org.
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
773829: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773829
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.