-
Notifications
You must be signed in to change notification settings - Fork 792
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(Java): add support for Java projects which use Maven or Gradle #591
base: master
Are you sure you want to change the base?
feat(Java): add support for Java projects which use Maven or Gradle #591
Conversation
f54b00d
to
7e85e22
Compare
7e85e22
to
8d68c46
Compare
39bf112
to
a6b423c
Compare
…dard-version into feat/add-java-maven-support
would be nice to change the regex to support
|
@hashd very good point - have updated the code now and tested it works. Thanks for the suggestion! |
Thanks for the PR. I'm also wondering if we should maintain these additional logic here? My preference is to make it pluggable so that the logics can live in any repo |
Yes this is exactly the conversation I want to check with you. Basically the effort required to support another language in most cases is trivial - regex against a file, replace a version. All of the great stuff in this library around managing the commits, the changelog, etc etc is universal. Now there is the approach of Something like a The only challenge will be making it work for a codebase which isn't already node.js. Because (for example) Java projects won't have a
Or something like this. Any thoughts on what might be the best way to go? |
Yep, would prefer a solution which avoids a package.json in a Java maven/gradle project |
Hi there, for the maven implementation, it may be safer to use maven version plugin instead of raw replacement. |
@uguy that would be a conventional way to do it in Java, but has the issue which is that it would require Maven to be installed on the machine this runs on. What's nice about this approach is that there is no need for the Java tooling to be present. Also if we call out to another process we need to check error codes etc etc, whereas this approach uses all of the existing mechanisms (you get the file as a string, manipulate it, that's it, the existing code paths take care of the rest). |
standard-version is exactly what I need, but for Java project (and in the future Lua projects for an PC game I'm modding). |
I'm more than happy to update the PR, and also to use |
…t/add-java-maven-support
Hello, I'm also very interested with this feature for java. I have this message : "Failed to read the tag in your pom file - is it present?" Another remark, it did not bump child module pom.xml, only the parent. |
Co-authored-by: Eemeli Aro <eemeli@gmail.com>
…andard-version into feat/add-java-maven-support
…dard-version into feat/add-java-maven-support
@eemeli sorry for the delay I've been slammed - The benefit is definitely more robust handling of XML so I think that outweighs the single consequence - it'll essentially 'standardise' your XML. Do you think this would be worth noting the in the docs? @UnleashSpirit I believe the current version will now fix your issue, would you mind letting me know? |
Im wondering if this variant can accommodate the usual maven extensions (ie qualifier/buildnumber) to semver? |
Good points @jeacott am happy to take any suggestions, basically as long as the project maintainers think the overall approach/feature is useful to have! |
@dwmkerr I try again just now Same result if And it still bumping only parent pom.xml and not module's one (or do I have to list them all in the command ? is yes, how ?) |
Hi, great work. I was wondering if there is anyway to create the tag of format |
Nevermind, I found the solution I had to pass |
Does this PR is still alive ? // updaters/types/pom.js
function getDocAndVersionNode(contents) {
const doc = new DOMParser().parseFromString(contents)
const nodes = doc.documentElement.childNodes
let parentNodes = null
for (let i = 0; i < nodes.length; ++i) {
const node = nodes[i]
if (node.nodeName === 'version') return { doc, node }
if (node.nodeName === 'parent') parentNodes = node.childNodes
}
// Maven sub-module
if (parentNodes) {
for (let i = 0; i < parentNodes.length; ++i) {
const node = parentNodes[i]
if (node.nodeName === 'version') return { doc, node }
}
}
return { doc }
} // .versionrc.json
{
"packageFiles": [
{ "filename": "pom.xml", "type": "pom" }
],
"bumpFiles": [
{ "filename": "pom.xml", "type": "pom" },
{ "filename": "module_a/pom.xml", "type": "pom" },
{ "filename": "module_b/pom.xml", "type": "pom" }
]
} |
@dwmkerr @UnleashSpirit The command |
But it brings maven cli dependency which we want to avoid ... |
Hi all - again I'm more than happy to update the PR from latest, I just want to get a steer from the project maintainers on whether this is likely to go in or whether they want to keep it separate, I'm fine either way just want to confirm before I update! |
It looks like it's been a minute on this, but I'd love to see java supported. Any updates? Anything I can do to help? |
Hi there! Since standard-version is deprecated, I've forked it here. I'm keen to bring in updaters for common frameworks to the fork, and I've proposed a guideline to do so in this RFC here - I was able to write the proposed guideline thanks in large part to the excellent discussion on this PR so far - thanks very much! Further discussion welcome on that RFC. if you're still interested in this feature, a PR against the fork would be very welcome. |
(I've also published a blog post on how to use this for Java here Supercharge your Java Projects with Conventional Commits, Semantic Versioning and Semantic Releases)
What is the problem this is addressing?
This project is amazing, I use it all the time both personally and professionally. However, I use more than just Node.js, and find myself missing
standard-version
in every other language. Although by default this project assume Node.js, 99.9% of the code is not Node specific. Creating the changelog, committing, checking for the changes, deciding how to bump, dry runs, etc etc.Although there does exist a mechanism to update files in a custom way with updaters, I think many people do not use this feature.
This small change means that with just a few extra lines, we can support Java projects out-of-the-box. That potentially adds a massive number of people who can use the library. It adds no new dependencies. If I search for 'standard version java' I find nothing relevant, there is no equivalent tool.
I'd love any feedback on this PR, this would help me enormously in my own projects, but I understand it somewhat muddies the API as you could do this with custom updaters.
This is also a non-breaking change and will not affect any existing projects or use cases.
Here are the changes:
Adds support for Java projects which use the 'Maven' build system, by simply setting the flags as below
In the Maven world, the
pom.xml
is basically yourpackage.json
.Adds support for Java projects which use the 'Gradle' build system, by simply setting the flags as below
Fixed a bug in
resolveUpdaterObjectFromArgument
which led to a cryptic error message in a failing testBefore:
After: