2007/12/29, Michael Koch [EMAIL PROTECTED]:
On Sat, Dec 29, 2007 at 11:35:54PM +0100, Marcus Better wrote:
Dalibor Topic wrote:
I'm not sure if our ideas are really opposed:
Certainly not, I'm all for doing rebuilds of reverse dependencies if
possible. So do you have any plans on how
Dalibor Topic wrote:
I'm not sure if our ideas are really opposed:
Certainly not, I'm all for doing rebuilds of reverse dependencies if
possible. So do you have any plans on how to implement this? Should the
rebuilding be done before uploading a new version, or will that take too
long? Or should
On Sat, Dec 29, 2007 at 11:35:54PM +0100, Marcus Better wrote:
Dalibor Topic wrote:
I'm not sure if our ideas are really opposed:
Certainly not, I'm all for doing rebuilds of reverse dependencies if
possible. So do you have any plans on how to implement this? Should the
rebuilding be done
Marcus Better wrote:
Most of the Debian library packaging guide [1] applies to Java libraries
too. It seems to me that this problem has been ignored for Java libs just
because Java doesn't automatically force us to deal with it, like SONAMEs
do to some extent.
I'm not sure if our ideas are
On Sat, December 22, 2007 21:03, Marcus Better wrote:
Paul Cager wrote:
E.g. the POM could require JUnit-3.8.1 but Debian has packaged version
3.8.2. In this case we would set up a link in the temporary Maven
repository:
debian/.m2/repository/.../junit-3.8.1.jar - /usr/share/java/junit.jar
Marcus Better wrote:
Dalibor Topic wrote:
It seems to me that we must keep track of ABI compatibility. This is a
bit complicated, but it's our job if we want to be a well-integrated
distribution. In other words we should try to solve the library
versioning problem first, and only then try
Paul Cager wrote:
In other words we should try to solve the library versioning
problem first, and only then try to build packages with Maven.
Now there I'm afraid I have to disagree. Newer library versions that are
not backwards-compatible will affect packages built using ant in just the
Dalibor Topic wrote:
I had in mind a stricter definition that takes semantics into account.
For example if a method breaks its contract by changing its behaviour
then it may be a new ABI, even if the method signature is the same.
Is it possible to derive such information automatically?
Marcus Better wrote:
Paul Cager wrote:
E.g. the POM could require JUnit-3.8.1 but Debian has packaged version
3.8.2. In this case we would set up a link in the temporary Maven
repository:
debian/.m2/repository/.../junit-3.8.1.jar - /usr/share/java/junit.jar
-
Dalibor Topic wrote:
It seems to me that we must keep track of ABI compatibility. This is a
bit complicated, but it's our job if we want to be a well-integrated
distribution. In other words we should try to solve the library
versioning problem first, and only then try to build packages with
[EMAIL PROTECTED] wrote:
I totally agree with all your points. It would however be great to
have this as a goal in mind and work towards it in parallel as you
suggested. We are thinking along the same lines.
Great. Do you want to take a shot at making Wagon grok Debian packages /
On Saturday December 22 2007, Dalibor Topic wrote:
[EMAIL PROTECTED] wrote:
I totally agree with all your points. It would however be great
to have this as a goal in mind and work towards it in parallel as
you suggested. We are thinking along the same lines.
Great. Do you want to take a
Manfred Moser wrote:
On Saturday December 22 2007, Dalibor Topic wrote:
[EMAIL PROTECTED] wrote:
I totally agree with all your points. It would however be great
to have this as a goal in mind and work towards it in parallel as
you suggested. We are thinking along the same lines.
Great. Do
Paul Cager wrote:
E.g. the POM could require JUnit-3.8.1 but Debian has packaged version
3.8.2. In this case we would set up a link in the temporary Maven
repository:
debian/.m2/repository/.../junit-3.8.1.jar - /usr/share/java/junit.jar
- /usr/share/java/junit-3.8.2.jar
We should check
On Wed, December 19, 2007 17:52, Dalibor Topic wrote:
Arnaud Vandyck wrote:
Many thanks for the clarifications.
So if we are talking about refactoring /usr/share/java, let's do it in
some sort of Debian way. We'll write a wrapper around different build
system to let them understand our
Hi!
I have been following this thread with much interest since I am using
Maven commercially on a daily basis and have been doing so for a while.
Here are some ideas regarding Pauls questions..
Quoting Paul Cager [EMAIL PROTECTED]:
That sounds good. There's still a few things bothering me
[EMAIL PROTECTED] wrote:
I think using Maven with a Debian internal and cleaned up repository
that only contains debian compliant packages and the fixes to make the
build of any debian package work is the better approach. It is also
more useful for the bigger community since this debian
Quoting Dalibor Topic [EMAIL PROTECTED]:
[EMAIL PROTECTED] wrote:
I think using Maven with a Debian internal and cleaned up
repository that only contains debian compliant packages and the
fixes to make the build of any debian package work is the better
approach. It is also more
2007/12/18, Marcus Better [EMAIL PROTECTED]:
Arnaud Vandyck wrote:
if mvn present:
mvn install -DgroupId=... -DversionId=... -DartifactId=...
/usr/share/java/my.jar
If it's meant to be run in postinst then Maven might not be installed yet.
Yes, I was thinking about putting the code in
2007/12/18, Paul Cager [EMAIL PROTECTED]:
Arnaud Vandyck wrote:
if mvn present:
mvn install -DgroupId=... -DversionId=... -DartifactId=...
/usr/share/java/my.jar
The install:install-file plugin does almost what Arnaud suggests:
2007/12/19, Dalibor Topic [EMAIL PROTECTED]:
Paul Cager wrote:
The install:install-file plugin does almost what Arnaud suggests:
[...]
But I wonder just how important it is to have a system-wide local repo?
It would certainly reduce the number of Jars an end-user needed to
download
Am Mittwoch, 19. Dezember 2007 11:01:11 schrieb Arnaud Vandyck:
1° To build software in Debian: we need to tell maven how and where to
find jars (and aliases: I think of other version numbers)
2° For our users: here, there are three ways of doing it:
a) open a hole to possibly non-free
Arnaud Vandyck wrote:
To simplify things a bit I would suggest to
convert /usr/share/java to something maven understands as repository instead
of creating another repo.
Maybe we can think about refactoring /usr/share/java, but why do we
use the maven layout. I did not fully understand
Many thanks for the clarifications.
So if we are talking about refactoring /usr/share/java, let's do it in
some sort of Debian way. We'll write a wrapper around different build
system to let them understand our layout. (is it what you meant?)
;-)
2007/12/19, Dalibor Topic [EMAIL PROTECTED]:
Arnaud Vandyck wrote:
Many thanks for the clarifications.
So if we are talking about refactoring /usr/share/java, let's do it in
some sort of Debian way. We'll write a wrapper around different build
system to let them understand our layout. (is it what you meant?)
I hope that wrapping the
Arnaud Vandyck wrote:
What about a maven plugin that leave the jar in /usr/share/java, but
register the jar.
if mvn present:
mvn install -DgroupId=... -DversionId=... -DartifactId=...
/usr/share/java/my.jar
and we could have maven to use /var/lib/maven2 or /var/lib/m2
then, when you
Arnaud Vandyck wrote:
What about a maven plugin that leave the jar in /usr/share/java, but
register the jar.
if mvn present:
mvn install -DgroupId=... -DversionId=... -DartifactId=...
/usr/share/java/my.jar
If it's meant to be run in postinst then Maven might not be installed yet.
But
Marcus Better wrote:
Arnaud Vandyck wrote:
What about a maven plugin that leave the jar in /usr/share/java, but
register the jar.
if mvn present:
mvn install -DgroupId=... -DversionId=... -DartifactId=...
/usr/share/java/my.jar
If it's meant to be run in postinst then Maven might not
Paul Cager wrote:
Marcus Better wrote:
Arnaud Vandyck wrote:
What about a maven plugin that leave the jar in /usr/share/java, but
register the jar.
if mvn present:
mvn install -DgroupId=... -DversionId=... -DartifactId=...
/usr/share/java/my.jar
If it's meant to be run in postinst then
Dalibor Topic wrote:
Paul Cager wrote:
Marcus Better wrote:
Arnaud Vandyck wrote:
What about a maven plugin that leave the jar in /usr/share/java, but
register the jar.
if mvn present:
mvn install -DgroupId=... -DversionId=... -DartifactId=...
/usr/share/java/my.jar
If it's meant to
On Wed, Sep 05, 2007 at 02:06:04AM +0200, Steffen Moeller wrote:
Dear all,
would it be reasonable to transform the /usr/share/java directory into
something that may also function as an internal Maven repository?
http://maven.apache.org/guides/introduction/introduction-to-repositories.html
Dear all,
would it be reasonable to transform the /usr/share/java directory into
something that may also function as an internal Maven repository?
http://maven.apache.org/guides/introduction/introduction-to-repositories.html
It would allow us to store multiple versions of a jar on the same
32 matches
Mail list logo
