[ANN] SVNKit now in central Maven repository.

[Alexander Kitaev-3]

Dear Friends,

Good news! :)

We've set up our maven repository and today it has been synchronized
with the central Maven repository, so that SVNKit 1.3.1 and SQLJet 1.0.0
now available both from our repository and from the central one.

SVNKit/SQLJet Maven Repository: http://maven.svnkit.com/maven2/
Central Maven Repository: http://repo2.maven.org/maven2/

SVNKit:

Group ID: org.tmatesoft.svnkit
Artifact ID: svnkit
Version: 1.3.1

SQLJet:

Group ID: org.tmatesoft.sqljet
Artifact ID: sqljet
Version: 1.0.0

There are also JNA and Trilead artifacts in our repository.

From now on, each time we release SVNKit or SQLJet, we first update our
repository with new artifacts, and then our repository automatically
synchronized with the central Maven repository.

--
Alexander Kitaev,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!
http://sqljet.com/ - Java SQLite Library!

---------------------------------------------------------------------
To unsubscribe, e-mail: svnkit-users-unsubscribe@...
For additional commands, e-mail: svnkit-users-help@...

[XMaNIaC]

Really, really good news. Thank you!

Regards

On Fri, Oct 2, 2009 at 6:23 PM, Alexander Kitaev <Alexander.Kitaev@...> wrote:

Dear Friends,

Good news! :)

We've set up our maven repository and today it has been synchronized
with the central Maven repository, so that SVNKit 1.3.1 and SQLJet 1.0.0
now available both from our repository and from the central one.

SVNKit/SQLJet Maven Repository: http://maven.svnkit.com/maven2/
Central Maven Repository: http://repo2.maven.org/maven2/

SVNKit:

Group ID: org.tmatesoft.svnkit
Artifact ID: svnkit
Version: 1.3.1

SQLJet:

Group ID: org.tmatesoft.sqljet
Artifact ID: sqljet
Version: 1.0.0

There are also JNA and Trilead artifacts in our repository.

From now on, each time we release SVNKit or SQLJet, we first update our
repository with new artifacts, and then our repository automatically
synchronized with the central Maven repository.

--
Alexander Kitaev,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!
http://sqljet.com/ - Java SQLite Library!

---------------------------------------------------------------------
To unsubscribe, e-mail: svnkit-users-unsubscribe@...
For additional commands, e-mail: svnkit-users-help@...

[Karl Heinz Marbaise]

Hi there,

just a question about the current 1.3.1 Release....

May be i oversight it but it seemed to be that the 1.3.1 release needs
to have Java 1.6 at least whereas svnkit 1.2.3 used Java 1.5 ?

I can't find it in the changelog ?

If it is correct is it possible to create a Java 1.5 Release (I know 1.5
has it EOLT reached...) ?

Kind regards
Karl Heinz Marbaise
--
SoftwareEntwicklung Beratung Schulung    Tel.: [phone] / 415 893
Dipl.Ing.(FH) Karl Heinz Marbaise        ICQ#: 135949029
Hauptstrasse 177                         USt.IdNr: DE191347579
52146 Würselen                           http://www.soebes.de

---------------------------------------------------------------------
To unsubscribe, e-mail: svnkit-users-unsubscribe@...
For additional commands, e-mail: svnkit-users-help@...

[Alexander Sinyushkin]

Hello Karl,

Why did you decide that 1.3.1 required jdk6?

----
Alexander Sinyushkin,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!
http://sqljet.com/ - Java SQLite Library!



Karl Heinz Marbaise wrote:

> Hi there,
>
> just a question about the current 1.3.1 Release....
>
> May be i oversight it but it seemed to be that the 1.3.1 release needs
> to have Java 1.6 at least whereas svnkit 1.2.3 used Java 1.5 ?
>
> I can't find it in the changelog ?
>
> If it is correct is it possible to create a Java 1.5 Release (I know
> 1.5 has it EOLT reached...) ?
>
> Kind regards
> Karl Heinz Marbaise

---------------------------------------------------------------------
To unsubscribe, e-mail: svnkit-users-unsubscribe@...
For additional commands, e-mail: svnkit-users-help@...

[Alexander Kitaev-3]

Hello Karl,

Thank you for reporting this issue - we made a mistake by building jars
for Maven repository with JDK 1.6. We'll redeploy jars ASAP.

As for SVNKit - it is 1.4 compatible (with some features working only
with 1.5) and recommended JVM to run is 1.6 - with that version you'll
get the best performance.

Thanks,
Alexander Kitaev,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!
http://sqljet.com/ - Java SQLite Library!

Karl Heinz Marbaise wrote:

> Hi there,
>
> just a question about the current 1.3.1 Release....
>
> May be i oversight it but it seemed to be that the 1.3.1 release needs
> to have Java 1.6 at least whereas svnkit 1.2.3 used Java 1.5 ?
>
> I can't find it in the changelog ?
>
> If it is correct is it possible to create a Java 1.5 Release (I know 1.5
> has it EOLT reached...) ?
>
> Kind regards
> Karl Heinz Marbaise

---------------------------------------------------------------------
To unsubscribe, e-mail: svnkit-users-unsubscribe@...
For additional commands, e-mail: svnkit-users-help@...

[Karl Heinz Marbaise]

Hi Alexander,

> Hello Karl,
>
> Why did you decide that 1.3.1 required jdk6?
cause i tested it by changing the dependency of my project and the
result was the following:

/Users/km/workspace/supose/src/main/java/com/soebes/supose/scan/ScanRepositoryBaseLogEntry.java:[30,-1]
cannot access org.tmatesoft.svn.core.SVNLogEntry
bad class file:
/Users/km/.m2/repository/org/tmatesoft/svnkit/svnkit/1.3.1/svnkit-1.3.1.jar(org/tmatesoft/svn/core/SVNLogEntry.class)
class file has wrong version 50.0, should be 49.0

So this will give me a hint that i need to have Java 1.6 at least...

Kind regards
Karl Heinz Marbaise
--
SoftwareEntwicklung Beratung Schulung    Tel.: [phone] / 415 893
Dipl.Ing.(FH) Karl Heinz Marbaise        ICQ#: 135949029
Hauptstrasse 177                         USt.IdNr: DE191347579
52146 Würselen                           http://www.soebes.de

---------------------------------------------------------------------
To unsubscribe, e-mail: svnkit-users-unsubscribe@...
For additional commands, e-mail: svnkit-users-help@...

[Alexander Sinyushkin]

Hello Karl,

We've rebuilt the binaries (SVNKit with jdk1.4, SQLJet with jdk 1.5) and
put them into our maven repository.
Please, check out the latest binaries.

Thank you for your report!

----
Alexander Sinyushkin,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!
http://sqljet.com/ - Java SQLite Library!



Karl Heinz Marbaise wrote:

> Hi Alexander,
>
>> Hello Karl,
>>
>> Why did you decide that 1.3.1 required jdk6?
> cause i tested it by changing the dependency of my project and the
> result was the following:
>
> /Users/km/workspace/supose/src/main/java/com/soebes/supose/scan/ScanRepositoryBaseLogEntry.java:[30,-1]
> cannot access org.tmatesoft.svn.core.SVNLogEntry
> bad class file:
> /Users/km/.m2/repository/org/tmatesoft/svnkit/svnkit/1.3.1/svnkit-1.3.1.jar(org/tmatesoft/svn/core/SVNLogEntry.class)
>
> class file has wrong version 50.0, should be 49.0
>
> So this will give me a hint that i need to have Java 1.6 at least...
>
> Kind regards
> Karl Heinz Marbaise

---------------------------------------------------------------------
To unsubscribe, e-mail: svnkit-users-unsubscribe@...
For additional commands, e-mail: svnkit-users-help@...

[Oleg Estekhin]

The JNA library has long ago changed its maven groupId to net.java.dev.jna. The Maven Central contains some recent JNA releases under this group and the Java.ner maven repository (http://download.java.net/maven/2) contains JNA releases under this groupId starting from 3.0.3 (the latest is 3.2.3).

Even if you don't need the latest JNA version you should at least change the dependency groupId to the correct one.

[Alexander Sinyushkin]

Hello Oleg,

Thank you for your notice. We'll fix it ASAP.

----
Alexander Sinyushkin,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!
http://sqljet.com/ - Java SQLite Library!



Oleg Estekhin wrote:
> The JNA library has long ago changed its maven groupId to net.java.dev.jna.
> The Maven Central contains some recent JNA releases under this group and the
> Java.ner maven repository (http://download.java.net/maven/2) contains JNA
> releases under this groupId starting from 3.0.3 (the latest is 3.2.3).
>
> Even if you don't need the latest JNA version you should at least change the
> dependency groupId to the correct one.
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: svnkit-users-unsubscribe@...
For additional commands, e-mail: svnkit-users-help@...

[Oleg Estekhin]

Hello, the 1.3.1-1 version is little bit better from the maven point of view, but there still some problems =).

1) Dependency on JNA

The group id is correct now, but there is a problem with the version. The Maven Central Repository is not perfect, and in this particular case it does not contain some metadata for the JNA artifact. Namely, the maven-metadata.xml is missing in the http://repo2.maven.org/maven2/net/java/dev/jna/jna/, but this file is required to resolve the range dependencies. This missing file, of course, is not your fault, but this situation leads to the fact that maven is unable to resolve the [3.1.0,3.2.2] version range when using only Maven Central Repository.

Additionally the current trend, i believe, is not to use version ranges. Version range used for the project dependency leads to some ambiguity when building and testing the project and this is considered "not good".
The project should specify exact versions of all its dependencies which leads to the very exact dependency graph and exact reproducibility because this version of the project will always use the same versions of dependencies that were used at the time of building that version even if newer ones are available. The newer project version can (and probably should) bump its dependencies to the most recent versions available at the moment but again it should specify the version numbers exactly.

So, please use the strict version for the JNA dependency (at the moment 3.2.2 would be good because it is present in the maven central).

2) Dependency on trilead-ssh

Judging from the Trilead site (http://www.trilead.com/SSH_Library/) they will not develop Java trilead-ssh library anymore, so the build 213 is probably the last official version. The svnkit was using the patched b213 for a long time, and it seems that you will have to use this patched version for some more time until you will find a suitable replacement (JSch maybe?).

Check the second FAQ item named "I have a patched version of the foo project developed at foo.com, what groupId should I use?" at http://maven.apache.org/guides/mini/guide-central-repository-upload.html.

It recommends to use your own group id to clearly distinguish the patched/modified version from the original library. Therefore the groupId of the patched trilead-ssh should be org.tmatesoft.svnkit (or org.tmatesoft.trilead or org.tmatesoft.svnkit.trilead).

3) The 1.3.1-1 does not specify JNA and trilead (and sqljet) dependencies as optional. Is this an oversight or this intentional?

The conclusion:
1) The JNA and trilead-ssh entries in the dependencies section in the svnkit pom should look like this:
  <dependency>
    <groupId>net.java.dev.jna</groupId>
    <artifactId>jna</artifactId>
    <version>3.2.2</version>
    <optional>true</optional>
  </dependency>
  <dependency>
    <groupId>org.tmatesoft.svnkit</groupId>
    <artifactId>trilead-ssh2</artifactId>
    <version>build213-svnkit-1.3-patch</version>
    <optional>true</optional>
  </dependency>

The sqljet dependency probably should be made optional too.

2) The groupId in the pom file for the trilead-ssh artifact should be changed accordingly.

[Alexander Sinyushkin]

Hello Oleg,

Thank you very much for your feedback and help, we do really appreciate it!

1) The reason why we decided to use a range instead of an exact version
number
is that the official 1.3.1 release was shipped with JNA ver. 3.1.0, but
there is no
this version under that groupId you wrote us about. Though SVNKit can
work with version 3.2.2 as
well (trunk already uses 3.2.2). I think we'll have to force SVNKit
1.3.1-2 maven artifact (though it's still the same 1.3.1)
 depend on this newer version of JNA, I see no other way to fix the problem.

2) Some time ago we used JSCH as an ssh provider, but we had to decide
in Trilead's (first it was Ganymed) favour
because we have had many troubles with JSCH. But still, I agree with
your remarks on changing the groupId of our patched
Trilead version.

3) Yes, I removed the optional=true flag as I noticed that in this case
when building an application  depending on SVNKit
with maven, optional dependencies of SVNKit do not get checked out from
the repository (even if they are not present in
the local one) and this may lead to performance slow down as JNA
provides faster platform dependent system calls,
SqlJet enables representation cache support for FSFS layer with post-1.6
repositories, and without the Trilead
svn+ssh:// would not work in SVNKit. (If I'm not right regarding
checking out optional dependencies, you are welcome to
correct me).

I'll take all the notices into consideration and publish 1.3.1-2 ASAP.

Thank you,

----
Alexander Sinyushkin,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!
http://sqljet.com/ - Java SQLite Library!



Oleg Estekhin wrote:

> Hello, the 1.3.1-1 version is little bit better from the maven point of view,
> but there still some problems =).
>
> 1) Dependency on JNA
>
> The group id is correct now, but there is a problem with the version. The
> Maven Central Repository is not perfect, and in this particular case it does
> not contain some metadata for the JNA artifact. Namely, the
> maven-metadata.xml is missing in the
> http://repo2.maven.org/maven2/net/java/dev/jna/jna/, but this file is
> required to resolve the range dependencies. This missing file, of course, is
> not your fault, but this situation leads to the fact that maven is unable to
> resolve the [3.1.0,3.2.2] version range when using only Maven Central
> Repository.
>
> Additionally the current trend, i believe, is not to use version ranges.
> Version range used for the project dependency leads to some ambiguity when
> building and testing the project and this is considered "not good".
> The project should specify exact versions of all its dependencies which
> leads to the very exact dependency graph and exact reproducibility because
> this version of the project will always use the same versions of
> dependencies that were used at the time of building that version even if
> newer ones are available. The newer project version can (and probably
> should) bump its dependencies to the most recent versions available at the
> moment but again it should specify the version numbers exactly.
>
> So, please use the strict version for the JNA dependency (at the moment
> 3.2.2 would be good because it is present in the maven central).
>
> 2) Dependency on trilead-ssh
>
> Judging from the Trilead site (http://www.trilead.com/SSH_Library/) they
> will not develop Java trilead-ssh library anymore, so the build 213 is
> probably the last official version. The svnkit was using the patched b213
> for a long time, and it seems that you will have to use this patched version
> for some more time until you will find a suitable replacement (JSch maybe?).
>
> Check the second FAQ item named "I have a patched version of the foo project
> developed at foo.com, what groupId should I use?" at
> http://maven.apache.org/guides/mini/guide-central-repository-upload.html.
>
> It recommends to use your own group id to clearly distinguish the
> patched/modified version from the original library. Therefore the groupId of
> the patched trilead-ssh should be org.tmatesoft.svnkit (or
> org.tmatesoft.trilead or org.tmatesoft.svnkit.trilead).
>
> 3) The 1.3.1-1 does not specify JNA and trilead (and sqljet) dependencies as
> optional. Is this an oversight or this intentional?
>
> The conclusion:
> 1) The JNA and trilead-ssh entries in the dependencies section in the svnkit
> pom should look like this:
>   <dependency>
>     <groupId>net.java.dev.jna</groupId>
>     <artifactId>jna</artifactId>
>     <version>3.2.2</version>
>     <optional>true</optional>
>   </dependency>
>   <dependency>
>     <groupId>org.tmatesoft.svnkit</groupId>
>     <artifactId>trilead-ssh2</artifactId>
>     <version>build213-svnkit-1.3-patch</version>
>     <optional>true</optional>
>   </dependency>
>
> The sqljet dependency probably should be made optional too.
>
> 2) The groupId in the pom file for the trilead-ssh artifact should be
> changed accordingly.

---------------------------------------------------------------------
To unsubscribe, e-mail: svnkit-users-unsubscribe@...
For additional commands, e-mail: svnkit-users-help@...

[Oleg Estekhin]

Hello Alexander.

Regarding optional dependencies - they are indeed not transitive. If, for example, JNA is specified as optional in the SVNKit pom and the project P uses the SVNKit then P will not automatically get the JNA dependency. If P needs the JNA-dependent SVNKit functionality (using the system subversion configuration area for example) then P will have to specify both SVNKit and JNA dependencies in its pom explicitly.

If JNA is not optional in the SVNkit pom, than P will automatically get the dependency on JNA (and the appropriate functionality) but if P for some reasons do not need it that it can simply exclude it in its pom (using http://maven.apache.org/pom.html#Exclusions).

The same goes for Trilead and SqlJet dependencies.

From my point of view (maven-svn-wagon and maven-svn-revision-number-plugin) the JNA is essential and should be non-optional, but i can live without Trilead and SqlJet. I suppose other SVNKit users will have other considerations for "essential". I searched for "<groupId>org.tmatesoft.svnkit</groupId>" in the Google code search (http://www.google.com/codesearch?q=%3CgroupId%3Eorg.tmatesoft.svnkit%3C%2FgroupId%3E&hl=en&btnG=Search+Code) and looked for other dependencies in the found poms. It seems most SVNkit users are either unaware of the optional dependencies and advantages they provide or really-really don't need them. I am betting on former so it would be good if apart from configuring maven dependencies you will provide a document (easy to find wiki-page or a faq) that explains these SVNkit dependencies and what kind of features they enable.

[Alexander Sinyushkin]

Hello Oleg,

Yes, I agree that publishing such an article on our wiki web site really
makes sense,
we'll do that soon. Meanwhile we decided to roll out new maven artifacts
with
new 1.3.2 coming. That will happen this week, I think.

Regards,

----
Alexander Sinyushkin,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!
http://sqljet.com/ - Java SQLite Library!



Oleg Estekhin wrote:

> Hello Alexander.
>
> Regarding optional dependencies - they are indeed not transitive. If, for
> example, JNA is specified as optional in the SVNKit pom and the project P
> uses the SVNKit then P will not automatically get the JNA dependency. If P
> needs the JNA-dependent SVNKit functionality (using the system subversion
> configuration area for example) then P will have to specify both SVNKit and
> JNA dependencies in its pom explicitly.
>
> If JNA is not optional in the SVNkit pom, than P will automatically get the
> dependency on JNA (and the appropriate functionality) but if P for some
> reasons do not need it that it can simply exclude it in its pom (using
> http://maven.apache.org/pom.html#Exclusions).
>
> The same goes for Trilead and SqlJet dependencies.
>
> >From my point of view ( http://code.google.com/p/maven-svn-wagon
> maven-svn-wagon  and
> http://code.google.com/p/maven-svn-revision-number-plugin
> maven-svn-revision-number-plugin ) the JNA is essential and should be
> non-optional, but i can live without Trilead and SqlJet. I suppose other
> SVNKit users will have other considerations for "essential". I searched for
> "<groupId>org.tmatesoft.svnkit</groupId>" in the Google code search
> (http://www.google.com/codesearch?q=%3CgroupId%3Eorg.tmatesoft.svnkit%3C%2FgroupId%3E&hl=en&btnG=Search+Code)
> and looked for other dependencies in the found poms. It seems most SVNkit
> users are either unaware of the optional dependencies and advantages they
> provide or really-really don't need them. I am betting on former so it would
> be good if apart from configuring maven dependencies you will provide a
> document (easy to find wiki-page or a faq) that explains these SVNkit
> dependencies and what kind of features they enable.

---------------------------------------------------------------------
To unsubscribe, e-mail: svnkit-users-unsubscribe@...
For additional commands, e-mail: svnkit-users-help@...