[
https://issues.apache.org/jira/browse/JCRVLT-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648435#comment-17648435
]
Hans-Peter Stoerr commented on JCRVLT-672:
------------------------------------------
[~kwin] I just realized: the sanity check code that checks whether there is a
already a newer package installed so that the installation of a (sub-)package
should be skipped is also in file-vault:
[https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.6.6/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/JcrPackageImpl.java#L473]
That's likely the code that'll refuse that installation in AEM, too, right? So
the PR [https://github.com/apache/jackrabbit-filevault/pull/260] will certainly
improve that much, but I'm still a bit worried about the whole issue, as I
think that sanity check is too broad.
The point where that problem hit me recently was: I was working on an
application that had loads of packages (50 or something) that were contained as
subpackages in one package. From some 1.2.3-SNAPSHOT we went on to install
release 1.2.3 , and because of that wrong comparison none of the subpackages
were actually installed. We had to do a manual cleanup of all servers before we
could install the release. Well, that exact problem would be solved with this
PR, but I still think that [check with
.compareTo|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.6.6/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/JcrPackageImpl.java#L473]
is not quite appropriate. It makes sense to refuse automatic installation of
earlier versions (in the sense of 1.2.2 on top of 1.2.3) since the developers
certainly thought about forward migration 1.2.2->1.2.3 but likely not about
backward migration 1.2.3->1.2.2, but should that apply to different
pre-releases, too? You might have installed 1.2.3-rc1 , then fix something and
want to have a 1.2.3-SNAPSHOT for a while, and then want to install 1.2.3-rc2
for a final test. Or use entirely different pre-release markers that collide
with the maven "is newer" semantics. But to compare there with
Version.compareTo here prevents that - I'd rather suggest just compare the
numerical versions and ignore everything that comes after the dash. What do you
think?
> Provide a Version comparison function for "is newer" checks
> -----------------------------------------------------------
>
> Key: JCRVLT-672
> URL: https://issues.apache.org/jira/browse/JCRVLT-672
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Affects Versions: 3.6.6
> Reporter: Hans-Peter Stoerr
> Assignee: Konrad Windszus
> Priority: Minor
>
> I suggest to add a function to org.apache.jackrabbit.vault.packaging.Version
> that provides a sensible partial ordering for checking whether one package is
> newer than another.
> Background:
> [org.apache.jackrabbit.vault.packaging.Version#compareTo|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.6.6/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/Version.java#L157]
> provides a nice function to sort package versions e.g. for the purpose of
> displaying them in a predictable order that is close to the probable
> timeline. But sometimes you want an "is newer than" relationship - e.g. for a
> sanity check during package installation that you don't install an older over
> a newer package. As far as I know, Adobe AEM is actually (ab-)using that
> compareTo function for that purpose. That is a problem, because if you deploy
> e.g. 1.2.3-SNAPSHOT for a while on a server and then create a release 1.2.3,
> it'll refuse automatic installation because it wrongly thinks 1.2.3-SNAPSHOT
> is newer than 1.2.3.
> Now, obviously you cannot fix that AEM problem here, but you could provide a
> function at Version for future use, that would be a nicely useable "is newer
> than" relationship for that purpose, and add a comment warning people not to
> use Version.compareTo for such a sanity check. That'd be nice for AEM usage,
> but also for other package managers, like our [Composum package
> manager|https://www.composum.com/home/nodes/pckgmgr.html?pages.locale=de].
> While the ordering of the numerical prefix (which is also implemented by
> Version.compareTo) is pretty widely used, there is no widely used ordering
> for the suffixes - they could be anything like -SNAPSHOT, -SNAPSHOT-12, -rc1,
> -alpha, -testing and whatnot. So it's not possible to give a full order for
> that purpose. My suggestion is to provide a partial ordering based on the
> numerical prefix, but to ignore the suffix completely. Perhaps provide a
> function Version.compareNumericPrefix ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
