zafarkhaja / jsemver

Java implementation of the SemVer Specification
MIT License
429 stars 82 forks source link

Ability to convert version range strings? #22

Closed lsanders closed 5 months ago

lsanders commented 8 years ago

I realize this is probably outside the original use case for Expressions, but I thought I'd mention it. I'd really like to use this library to normalize the various version range formats. Any thoughts on that? Thanks.

zafarkhaja commented 8 years ago

Sounds interesting but I'm not sure I understand exactly what you mean. Could you please provide an example?

I'm planning to do something which I think might be similar to what you're suggesting. I was thinking about providing different Expression parsers through library extensions for different expression formats such as the one we have now in jsemver, maven and/or node-semver. So, for example, >=1.0 & <2 and [1.0, 2) would compile to the identical range.

lsanders commented 8 years ago

Thanks for the response Zafar. And for the great library.

Specifically, I want to be able to take a list of components that have node-semver dependency ranges. It looks like your external DSL supports all the common formats. I have a need to convert those to a normalized format - specifically a filter string to be used in an ldap query:

(&(version >= 1.0.0)(!(version >= 2.0.0))) (which is equivalent to "[1.0.0,2.0.0)" in maven/osgi format)

I'm sure that the ldap query string is pretty ridiculous for most people, but I could see a need to de-sugar to at least a maven like range or an expressive semver string >= 1.0.0 <2.0.0

Expression's internal representation is at least normalized and could then be converted to some other output format, but obviously the internal representation isn't directly usable. And since I'm not a parsing expert, I'm not sure what the best approach to take to get to something like this?

zafarkhaja commented 8 years ago

Sorry for the delay Larry and thank you for using jsemver and taking your time to contribute.

I believe that what you propose is pretty much doable. The good news is that converting one DSL to another should be straightforward provided that we have a parser for the one we're converting from, which we do and you don't have to parse anything on your own. It's not completely node-semver compliant but as you say it supports the common notations, such as tildes, carets, wildcards, etc. An expression is parsed into AST which is the internal representation of the expression which you can then convert to a required format using the Visitor design pattern. The bad news is that it wasn't meant for this; the AST classes are package private meaning you can't use them in your code, just not yet.

I'm planning on some changes to the library's structure for the 1.0.0 release namely moving the expression parser stuff to its own package and this will allow you to use the AST directly. In the meantime, you can fork it and adapt to your needs.

I'm not closing this issue as I'm definitely planning to implement this kind of logic.

Hope this helps and let me know if you need any further help.

abersnaze commented 6 years ago

I'm looking for a way to convert an Expression AST into a query rather than just filtering all the rows on the client.

zafarkhaja commented 5 months ago

Closing this issue in favor of #70, the progress can be followed from there.

P.S. To be honest, I'm not sure I'll be able to pull this off, but I'm gonna try.