search

bytedeco / javacpp-presets

The missing Java distribution of native C++ libraries
Other
2.67k stars 741 forks source link

presets version spec needed in parent #25

Open jjYBdx4IL opened 10 years ago

jjYBdx4IL commented 10 years ago

My tests submodule in javacpp-presets needs to reference the correct preset generated during the current build. Keeping the versions specs in sync manually within the same project does not make much sense.

Proposal: define the opencv, ffmpeg etc. artifact versions in a parent pom.xml. Or even use 0.9 instead of 2.4.9-0.9 -- that way one could simply write ${project.version}.

https://github.com/jjYBdx4IL/javacpp-presets/blob/master/tests/pom.xml :

                                <groupId>org.bytedeco.javacpp-presets</groupId>
                                <artifactId>opencv</artifactId>
                                <version>2.4.9-${project.parent.version}</version>
                                <classifier>${platform}</classifier>
                                <type>jar</type>

Much nicer would be:

                                <groupId>org.bytedeco.javacpp-presets</groupId>
                                <artifactId>opencv</artifactId>
                                <version>${project.version}</version>
                                <classifier>${platform}</classifier>
                                <type>jar</type>

:-))

saudet commented 10 years ago

And what should we do when the upstream project gets upgraded, but not JavaCPP?

jjYBdx4IL commented 10 years ago

The version spec for external dependencies is part of JavaCPP Presets. When you change them, JavaCPP Presets changes, ie. 0.9 -> 0.9.1. Put the external versions into the README by using placeholders:

This release contains ffmpeg-${ffmpeg.version}, ....
saudet commented 10 years ago

Ok, do you have an example of that somewhere?

jjYBdx4IL commented 10 years ago

Hmmm. What's your usual way to release new libs? Do you release single libs?

saudet commented 10 years ago

It might happen, but that's not the point. I would like to know how we could put variables like that in README files and how that would interact with GitHub.

jjYBdx4IL commented 10 years ago

You can use the properties-maven-plugin (see http://mojo.codehaus.org/properties-maven-plugin/) to load variables into maven from a plain properties file. Maven's resource filtering may then be used to replace variables in READMEs etc.

saudet commented 10 years ago

Yes, I see that, thank you, but do you know of any project on GitHub that uses that to create README.md files, for example?

jjYBdx4IL commented 9 years ago

I don't think there is a nice solution to include the version numbers in the top README.md. The only elegant solution that comes to my mind, is to put the version numbers into a properties file and link that file in the README.md.

saudet commented 9 years ago

That's also the impression I get, it's just not obvious how to integrate a solution like that in this project. We'd have to think about it a bit more. Do you know of a blog post or something that explains everything? Or would you have a more concrete proposal to make?

jjYBdx4IL commented 9 years ago

http://portofino.manydesigns.com/en/docs/portofino3/tutorials/using-maven-profiles-and-resource-filtering

<- around the "Resource filtering" heading. (ignore the profiles stuff)

saudet commented 9 years ago

So, are you proposing to put all the README.md files in ./src/main/ somewhere and have them processed and copied in the root directory next to the pom.xml file on some profile or something? Do you have a branch with an example that works?

saudet commented 9 years ago

BTW, this still sounds like a nice idea. I would be really happy to have more things automated, so please do contribute a working example!