Recently I am starting a new project and wanted to use the Zay-ES contribution library… However, I find that it is still not mavenized and hosted on Google Code! That makes it harder to access and use it. Are there plans on moving the contributions repo to GitHub? (That’s just a matter of pressing one single button, provided by Google, and should be done anyway if JME is to maintain the repo availability)…
And what about making the libraries available as maven artifacts from the already existing JME repository?
Really, starting each new project with JME, I often struggle much with setting it up… I do lots of small research and sketch projects and setting up a new Gradle or plain Maven project is very painful each time… Now JME has its own maven repo, so why not make all of the related libraries available there?
We want to move the whole contrib repo at once, and it seems it’s not just a one button click (didn’t look into it myself, just reporting what other members of the team experienced).
But this will be done, yes.
Also, I tried that button myself, there is a simple form to fill and then it literally takes a couple of minutes and you get the email from Google like “Your repo had been exported fine! Thank you, we hope you never come back!” and your new project is on github.
Idk if it will be something different for that particular repo though…
Yes but the idea is to have a separated repo for each contrib subproject, like github://jmecontrib/zay-es for example.
Hitting the button would just create a jmonkeyplatform-contributions repo with all sub projects stuffed into the same repo.
So we may have to clone each project locally and push them on guthub. At least that’s my understanding.
Export it all into one github project - fork that project into several - remove unrelated code. Preserves history and shouldn’t take that much time I think.
Yes, I agree that this is not a one-click action, as I thought of it before, but actually even the worst scenario of creating a separate repo for each project the way Nehon originally pointed out won’t take more than 30 minutes… and what you’re saying could make it even faster.
Every project gets all history in this case which is undesirable because then every repo is a FULL DUPLICATE of every other one. GIT has the entire history downloaded when you clone a repo so a small project like Zay-ES would end up being a gigabyte or so of unrelated history.
I already worked out a process to do this by exporting the whole thing to SVN and then using the more powerful SVN tools to split it up. It just has to be done and coordinate with users, etc…
Worst case, google code becomes read only in July and then it will be easy to move because it affects no one.
It does take a lot longer than 30 minutes, actually… and there is a certain amount of by-hand work that needs to be done per project. I’ve already mirrored the whole SVN repo locally sometime back and can simply update when it comes time. So at least the largest single time sink is done.
The rest is about 5-15 minutes per project (estimate) depending on the size of the project.
Harder than what? Using git vs. svn can’t be the issue here I suppose.
Well thats your choice, I would have guessed you’re using maven or gradle to avoid problems… In the SDK its just a few clicks to create a new project and import a plugin library.
But anyway, especially with maven I see people spending much more time on setting up their projects and walking around asking people for maven artifacts than actually coding. In the worst case even use outdated library versions just because they find a maven artifact somewhere… In the time you wrote this post for example you could have easily downloaded the Zay-ES jar and added it to your project. Just sayin’
Because that means work. You also need additional metadata (version, package names etc etc). The planned new plugin repo will have that data and when its completed far enough to create SDK plugins we’ll probably add maven exports too at some point.
I would love to have separate Maven artifacts for each contribution project - it will help others to use your code (if you want others to use your code). Handle separate jar files is a pain, and that’s why they invented Maven.
I see… so you want to preserve the history during the transition from the single repo to multiple per-project repos? Just out of interest, also - what work do you think you’d do per each repo?
So, I got home and being inspired by yours and Nehon statement of the challenge, created a script that takes all the contribution repo, creates a dedicated project on github for each of them, inits a git repo, commits the first commit and pushes it. It took me somewhat more that one hour, basically to figure out some things about git. So, now this is a pretty easy task that I can accomplish in a few keypresses (providing I’ve got GitHub ssh setup and created an API token, that takes a couple of minutes more). Here you can see, it started creating the repos, I have stopped it while it was pushing collada-support. So, here we are. Does not save the history though, but then, it is not really important and btw the history is still there in SVN…
If you are interested, we can employ this script to port the project to separate projects on GitHub. Maybe I can also add to it the feature of creating maven artifact data for every project…
HISTORY IS CRITICAL. It is the one critical requirement. If we can’t diff against history in the same tree then don’t bother with said solution.
Plus, I’ve already solved this problem. GIT won’t do it. You need to do it with SVN because it’s more powerful here. GIT assumes you will never want to do this because it’s “not the GIT way”… even though it’s useful to do sometimes. In fact, if I had to split up a GIT repo I’d probably move it to SVN first.
The machine that has the scripts to do this is offline at the moment but the general process is:
-pull a full copy of the complete SVN repo as a local mirror
-do a full svndump of the repo
-use svndumpfilter to filter out specific projects into their own dump files.
-create separate SVN projects
-load the dumps into separate projects
-load svn projects into GIT
All history is maintained and projects only have their own history and not everyone’s history.
So, you have already implemented the scripts? I’m not sure how you can move history from SVN to Git though… don’t they have completely different formats? Or maybe you plan to leave it SVN… ?
That’s how you move from SVN to GIT. (Note: even the button to do it automatically will keep all of the history… the problem is it keeps ALL of the history for ALL projects.)
Yes, I understand what you’re saying… I’ve been struggling with maven much and arguing with people… well… finally my tooling forced me to switch to maven. And, actually, now the only trouble that I have is when something I need is not available through maven… this usually happens to programs that are no longer maintained or which were not yet mavenized… There is some inner barrier to mavenizing your project, I know. After mavenizing like 10 of my projects I can say, I have stopped pumping into that barrier. Yes it takes some time at first, but then it just works. So I understand what you’re saying since I’ve been saying the same words many times to other people. Now I am in agnostic position, but in fact, I start out each of my projects either as a maven or gradle one…
I also know that JMonkeyEngine SDK is a very cool thing, it has many super-useful tools, but mostly I am forced into using JMonkeyEngine as a library, so I cannot always get all the pleasure provided by JMonkeyEngine SDK
