svn 1.7 compatibility

[wytten]

Hi,

Is this plugin compatible with svn 1.7, we're getting the following
exception:

[INFO] --- maven-svn-revision-number-plugin:1.7:revision (default) @
claimsui --
[INFO] inspecting C:\workspace\claims_trunk\claimsweb\claimsui
[ERROR]
org.tmatesoft.svn.core.SVNException: svn: The path 'C:\workspace
\claims_trunk\cl
aimsweb\claimsui' appears to be part of Subversion 1.7 (SVNKit 1.4) or
greater
working copy rooted at 'C:\workspace\claims_trunk\claimsweb'.
Please upgrade your Subversion (SVNKit) client to use this working
copy.

Thanks!

[Oleg Estekhin]

Hi,

no, it is not yet compatible with svn 1.7 out of the box. The plugin depends
on SVNKit for all svn-related operations, and the latest official release of
SVNKit does not yet support svn 1.7.

But you can force the plugin to use an 1.7-compatible snapshot of the SVNKit
as described in the
http://code.google.com/p/maven-svn-revision-number-plugin/issues/detail?id=10
. You will have to modify your pom and depend on a snapshot artifact - if it
is not acceptable then you will have to wait for the official SVNKit 1.7
release and then wait for me to update the plugin.

-----Исходное сообщение-----
From: wytten
Sent: Monday, December 05, 2011 6:09 PM
To: maven-svn-revision-number-plugin
Subject: svn 1.7 compatibility

[Oleg Estekhin]

I have three news, at least one of which is good =)

1) I have released a new version of the plugin linked with the svnkit:
1.7.0-alpha1.
This version will be able to retrieve status/revision information from
the svn-1.7 working copies out of the box.

The full GAV of that version is com.google.code.maven-svn-revision-
number-plugin:svn-revision-number-maven-plugin:1.8-SVN7.

2) The artifactId of that new version has changed. The Apache/Maven
guidelines reserve plugin names in the form of maven-something-plugin
for their own usage and require all third-party plugins to use some
other naming scheme, for example something-maven-plugin. Therefore,
the plugin now has the following name:

groupId: com.google.code.maven-svn-revision-number-plugin - unchanged
to increase the chances of error when someone types old groupId and
new artifactId by hand =(
artifactId: svn-revision-number-maven-plugin - changed from the maven-
s-r-n-plugin format to the s-r-n-maven-plugin format.

The version of this release is 1.8-SVN7, to further the problems with
renaming. I am sorry.

All future releases of this plugin will be under this new name:
com.google.code.maven-svn-revision-number-plugin:svn-revision-number-
maven-plugin. The version number will return to digits only (without
SVN7 suffix) when the corresponding SVNKit will be oficially released.
Technically after the artifactId change i can start version numbers
again from 1.0, but that will probably be too harsh to the plugin
users, so the artifactId changes, but version continues from the
previous numbers.

3) In order to use this version you will have to add an additional
pluginRepository in your pom:

<repositories>
<repository>
<id>maven-svn-revision-number-plugin.googlecode.com</id>
<url>http://maven-svn-revision-number-
plugin.googlecode.com/svn/m2/releases/</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>maven-svn-revision-number-plugin.googlecode.com</id>
<url>http://maven-svn-revision-number-
plugin.googlecode.com/svn/m2/releases/</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
This should be rechecked, and i will include the 100% correct code in
the upcoming wiki page about svn-1.7 support.

And the plugin declaration itself:
<plugin>
<groupId>com.google.code.maven-svn-revision-number-
plugin</groupId>
<artifactId>svn-revision-number-maven-plugin</
artifactId>
<version>1.8-SVN7</version>
<executions>
<execution>
<goals>
<goal>revision</goal>
</goals>
</execution>
</executions>
<configuration>
<!-- put your configurations here -->
</configuration>
</plugin>

I can't release the plugin to the Maven Central until the maven
Central contains all my dependencies, namely svnkit:1.7.0. I hope that
it will be in the central shortly after it is oficially released, so
shortly after that i will be able to release a s-r-n-m-p version that
will work without the need to declare additional repositories. Until
then if you need to work with svn-1.7 and want to use this plugin -
there is little choice: either use "new" com.google.code.maven-svn-
revision-number-plugin:svn-revision-number-maven-plugin:1.8-SVN7 and
declare my repositories (actually, as you can see from the url, they
are hosted inside the same googecode svn as the plugin source), or
stick with "old" google.code.maven-svn-revision-number-plugin:maven-
svn-revision-number-plugin:1.7 but force it to depend on svnkit:1.7.0-
alpha1 or svnkit:1.7.0-SNAPSHOT and declare tmatesoft (creators of
SVNKit) repositories as described in
http://code.google.com/p/maven-svn-revision-number-plugin/issues/detail?id=10.
Either way requires additional repositories in your pom. Either way
works with svn-1.7 working copies.

The autogenerated documentation at
http://maven-svn-revision-number-plugin.googlecode.com/svn/site/index.html
will not be updated and will stay at "old" google.code.maven-svn-
revision-number-plugin:maven-svn-revision-number-plugin:1.7 version.
The documentation will be updated after one of the following:
- svnkit:1.7.0 will go both official and available from the maven
central - this is the best case scenario, when i just merge the
current svn7 branch back to the trunk, revert repositories-related
stuff back to maven central, and release a new plugin version to the
maven central.
- svnkit:1.7.0 will go official, but will be available only from the
tmatesoft repositories (at it is now). I will not be able to release a
new plugin version to the maven central because of the additional
repositories, so i will have to stick with googlecode-based
repositories. In that case i will have to release a new version inside
the googlecode and to update the documentation with all that
repositories-related stuff.

I will create a wiki page on 1.7 support with the text based on this
message, but the "official" plugin and documentation for a moment
stays at "old" 1.7 version, which does not support svn-1.7 but which
is available from the maven central without any restrictions.

[wytten]

Thanks very much! We can probably wait until the new version hits
Maven Central.

> SVNKit) repositories as described inhttp://code.google.com/p/maven-svn-revision-number-plugin/issues/deta....

> Either way requires additional repositories in your pom. Either way
> works with svn-1.7 working copies.
>

> The autogenerated documentation athttp://maven-svn-revision-number-plugin.googlecode.com/svn/site/index...

[Chris W]

Hi. I think it's great that we now have svnkit-1.7.0-alpha1. Unfortunately, it's still linked to sqljet-1.1.0-SNAPSHOT, which makes this plugin unstable. The revision plugin suddenly stopped working for me due to a broken sqljet. I wonder if there is a way to get a more stable set of dependencies for this plugin.

java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:881)
at org.tmatesoft.sqljet.core.internal.fs.SqlJetFile.lock(SqlJetFile.java:502)
at org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.waitOnLock(SqlJetPager.java:2518)
at org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.sharedLock(SqlJetPager.java:1233)
at org.tmatesoft.sqljet.core.internal.pager.SqlJetPager.acquirePage(SqlJetPager.java:1019)
at org.tmatesoft.sqljet.core.internal.btree.SqlJetBtreeShared.getPage(SqlJetBtreeShared.java:339)
at org.tmatesoft.sqljet.core.internal.btree.SqlJetBtree.lockBtree(SqlJetBtree.java:703)
at org.tmatesoft.sqljet.core.internal.btree.SqlJetBtree.beginTrans(SqlJetBtree.java:890)
at org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.doBeginTransaction(SqlJetEngine.java:495)
at org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.access$100(SqlJetEngine.java:53)
at org.tmatesoft.sqljet.core.table.engine.SqlJetEngine$5.runSynchronized(SqlJetEngine.java:409)
at org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.runSynchronized(SqlJetEngine.java:217)
at org.tmatesoft.sqljet.core.table.engine.SqlJetEngine.beginTransaction(SqlJetEngine.java:405)
at org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.beginTransaction(SVNSqlJetDb.java:167)
at org.tmatesoft.svn.core.internal.db.SVNSqlJetDb.runTransaction(SVNSqlJetDb.java:205)
at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.readChildren(SVNWCDb.java:2454)
at org.tmatesoft.svn.core.internal.wc17.SVNStatusEditor17.getDirStatus(SVNStatusEditor17.java:606)
at org.tmatesoft.svn.core.internal.wc17.SVNStatusEditor17.getDirStatus(SVNStatusEditor17.java:653)
at org.tmatesoft.svn.core.internal.wc17.SVNStatusEditor17.getDirStatus(SVNStatusEditor17.java:653)
at org.tmatesoft.svn.core.internal.wc17.SVNStatusEditor17.getDirStatus(SVNStatusEditor17.java:653)
at org.tmatesoft.svn.core.internal.wc17.SVNStatusEditor17.getDirStatus(SVNStatusEditor17.java:653)
at org.tmatesoft.svn.core.internal.wc17.SVNStatusEditor17.getDirStatus(SVNStatusEditor17.java:653)
at org.tmatesoft.svn.core.internal.wc17.SVNStatusEditor17.getDirStatus(SVNStatusEditor17.java:653)
at org.tmatesoft.svn.core.internal.wc17.SVNStatusEditor17.getDirStatus(SVNStatusEditor17.java:653)
at org.tmatesoft.svn.core.internal.wc17.SVNStatusEditor17.walkStatus(SVNStatusEditor17.java:581)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgGetStatus.run(SvnNgGetStatus.java:137)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgGetStatus.run(SvnNgGetStatus.java:41)
at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:16)
at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:398)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:160)
at org.tmatesoft.svn.core.wc.SVNStatusClient.doStatus(SVNStatusClient.java:370)
at oe.maven.plugins.revision.RevisionMojo.createVersionedEntryProperties(RevisionMojo.java:209)
at oe.maven.plugins.revision.RevisionMojo.getEntryProperties(RevisionMojo.java:174)
at oe.maven.plugins.revision.RevisionMojo.execute(RevisionMojo.java:155)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
... 20 more

[Oleg Estekhin]

Maybe bleeding edge snapshots have this issue fixed. The 1.7.0-alpha1 was released on December 6, and the latest snapshot at http://maven.tmatesoft.com/content/repositories/snapshots/org/tmatesoft/svnkit/svnkit/1.7.0-SNAPSHOT/  has the December, 16 timestamp. sqljet snapshots seem to be updated at the date too.

 

I have created the wiki page (http://code.google.com/p/maven-svn-revision-number-plugin/wiki/svn7 ) with instructions on how to use svnkit snapshots at the cost of adding additional repositories, but at the moment it the unavoidable evil. Of course, both “old” m-s-r-n-p:1.7” and “new” "s-r-n-m-p:1.8-SVN7 can be forced to use the svnkit snapshot, it is just a matter of the number of additional repositories you will have to declare.

 

By the way, did you report that exception in the sqljet? TMate Software issue tracker is at http://issues.tmatesoft.com/issues  and it supports openid login so it is pretty easy to get inside and report stuff.

[Chris W]

Actually, it's the bleeding edge sqljet-1.1.0-SNAPSHOT released today that is causing the problem. This combination was working fine until today. Unfortunately, the nature of snapshots is that things can randomly and unpredictably break due to new bugs, depending on when Maven decides to refresh its plugin dependencies. I have reported this exception to tmatesoft. Thanks for mentioning the openid login.