Being new, I don't expect to have any weight in the decision. Just providing you with some input based on many years managing Ivy and Maven libraries, and dozens of distributed Java projects.
The format
productname-1.2.3.zip
is most common and works great for real releases, as opposed to snapshots (i.e., anything that doesn't justify a point release). Whereas dates are extremely useful for snapshots, the critical thing for a public distribution is the exact version number. If I tell somebody to pick up version 6.9.0c, I don't want them to be distracted with a date.
Dates also can be troublesome for the following reasons. The filenames should sort correctly (for directory listing purposes, scripting, and for tools like Maven and Ivy to distinguish the latest version). This means you need to use digits, not letters like "jan". To sort right, you need start with most significant like 20080514. Things get much longer than people like to type if you add delimiters, like productname-11.12.03a-2008-04-11.tar.bz2. "04-11" is ambiguous because it means Apr. 11 or Nov. 04, depending on your locale. If you abbreviate "2008" to "08", things become even more ambiguous.
There is a lot of variability about both capitalization, and whether to use hyphen, underscore, or nothing to delimit the base name from the version. I prefer the most common…
All lowercase (if product name must be delimited internally, then use - or camelback)
Hyphens to delimit major parts (product name from version, or if need to distinguish another "type" of version)
(I don't like typing _)
. for normal versions (and for file-type suffix).
jme-1.2.3.zip (jme-1.02.03 is ok with me, but non-standard)
jme-xml-4.5.6-SNAPSHOT20080609.tar.gz (longer than I prefer, but makes it very clear that it isn't a vetted distro).
It all makes sense
Just need the cooperation from the developers to communicate new releases, perhaps to branch the sources too in cvs
blaine said:
Being new, I don't expect to have any weight in the decision. Just providing you with some input based on many years managing Ivy and Maven libraries, and dozens of distributed Java projects.
It would be nice if jME would use Maven2 for builds and releases. I use Maven2 on all my projects and it makes life a lot easier.
–note: I have as much say about jme as, well, any other forum warrior… lots of opinions, and only mine count 
your preference for maven is noted. I disagree… for no other reason than I don't like maven.
realistically though, as long as there is a downloadable release, its ok… and preferably an all dependencies release as well.
Automagic dependency management is nice… but jme doesn't have a dependency stack the same way that… say… anything vaguely useful from the apache group does.
mostly I object to its trying to connect to the internet & get the latest version of a library by default. It needs to be optional, not automagic.
also, a 2.X (or 2.X.x) stamped release is fine - I don't need to know when it was compiled, just what version it is.
And finally, when I do use jme, it comes from cvs (1.x)… looking forwards to setting up 2.x project later on.
I hope I'm not annoying by giving too many details, but here are a couple more things you should at least think about at the same time.
-
Standard full distro releases (i.e. non-snapshot, full *.zip*/*.tar.*, not *.jar) use a top directory mirroring the exact distro file name, without the type extension. E.g. distro file jme-1.2.3b4.zip would hold "jme-1-2.3b4/build.xml", not "jme/build.xml". I'm just reporting what the great majority of well-established open source products do. The main benefit is, users can install multiple versions with no concern about clobbering, and each will be very clearly and consistently labelled... plus it follows open source tradition. I don't know whether you would want to do this with the 2.x series, but you probably don't want to make a change of this scope in the 1.x series. FYI, this is very easy to automate with Ant zipfilesets.
-
At least for personal builds, snapshot builds often need more than one revision per day. Just need to append more digits or numbers to the snapshot date, like basename-1.2.3.4-SNAPSHOT20080515c.jar.
-
Snapshot releases do often sort to higher priority than the following point release. basename-1.2.3.4-SNAPSHOT20080515a.jar would be for work preceding basename-1.2.3.4.jar. I.e., they are named for the point release they are working towards. If snapshots are checked into a public repository (they usually are not), you need to make settings (like Ivy's "status") so people don't get SNAPSHOTs by default.
Re. Maven.
Maven has a lot of great features, but (contrary to its design goals), it is invasive in that you reap the benefits only if you have everything set up how Maven wants it set up by default. This is much more of a big deal for J2EE apps, where it takes heavy customization if you don't want to use annotations (there are several use cases where you should not). They are keen on specific doc systems, verbose directory structures, and other things. If you want to do something else, you very often get forced into heavy customization which detracts from the original goals.
There are probably other readers of this forum who have started out a Java project using Maven, then realized after about a week that it takes more trouble to accommodate all of Maven's preferences, than are made up for by the consistency and automation benefits.
On the other hand, if you happen to want to set up everything how Maven wants you to set it up, use Maven's preferred tools, etc., it really does deliver on consistency and automation.
We really should invest more time into a proper build process and release procedures, but until now nobody did. I have set up a Maven 2 pom and it's building on an integration server, but that's all. Neither releases nor nightly builds are done with maven… nightly builds are user managed (theprism, right?) and releases were done by Mojomonk and later by Renanse. If someone else volunteers to straighten things (theprism again? :), or blaine?) that'd be great.
Points we had until now:
- version numbers in released files
- unified build process
more?
My opinion:
- sure
- maven2 only
-> Problem: libraries don't have poms, everyone needs to install them in the m2 repository manually 
irrisor said:
nightly builds are user managed (theprism, right?)
Had cruisecontrol working a while back but disabled it as I couldnt figure how to schedule it to once a day and kept eating bandwidth ??
So am currently manually doing it once a night. Must delve back into cruisecontrol sometime
What concerns me is coordiantion in releases. How with maven or other systems can the build get automated so that new versions are created etc. the developer may know that the relase is ready to be rolled up to the next version, how will the deployer ?? .Is this something that could be done in Ant say.
I think the main problem (to be honest), is that hardly anyone uses the releases. jME is still developed at such a pace that you'll be quite far behind the rest of the community if you use those jars.
Did anyone here ever use them for anything?
(to which I should add, that might change in the future so thinking about this surely isn't a bad idea)
If you don't go with Maven, I highly suggest Ivy. Much smaller scope than Maven, but much less obtrusive, and it's just so much more efficient and scalable to encapsulate library dependencies into text files instead of storing jar files in CVS or Svn. Both Maven and Ivy have the same benefits in this respect.
BTW, one of the few areas I have never hit with Ivy, and one of many areas I haven't hit with Maven, is managing native libraries (.so and *.dll) with these tools. It's likely that they accommodate this, but just wanted to say that I don't personally know.
irrisor said:
2. maven2 only :) -> Problem: libraries don't have poms, everyone needs to install them in the m2 repository manually :(
Are you talking about jME libraries that don't have poms or other libraries that jME is dependent on?
blaine said:
Maven has a lot of great features, but (contrary to its design goals), it is invasive in that you reap the benefits only if you have everything set up how Maven wants it set up by default.
I agree that Maven forces you to have you projects set up in a certain way. But that makes projects consistent, and I think consistency in this case is a good thing.
JMe doesn't have a complex project structure, so it wouldn't take a lot of time to make maven-ready.
I have never used Ivy, so I don't know how it compares to Maven2, maybe it's the better choice in this case.
I can offer my help with making jME maven ready, if that is the way to go.
rvanrijn said:
irrisor said:
2. maven2 only :) -> Problem: libraries don't have poms, everyone needs to install them in the m2 repository manually :(
Are you talking about jME libraries that don't have poms or other libraries that jME is dependent on?
I talk about lwjgl, openal, jinput, jorbis and jogg (libs required for jME)
rvanrijn said:
I can offer my help with making jME maven ready, if that is the way to go.
jME has a pom.xml and can already be built with maven 2.
irrisor said:
jME has a pom.xml and can already be built with maven 2.
I know it can be built with maven 2, but I meant going beyond just being able to build with maven 2. You could release snapshot versions from nightly builds and versioned releases. You can use many different maven plugins to check code quality and test coverage.
rvanrijn said:
I know it can be built with maven 2, but I meant going beyond just being able to build with maven 2. You could release snapshot versions from nightly builds and versioned releases. You can use many different maven plugins to check code quality and test coverage.
ok, I would not call that maven-ready in this case :)
irrisor said:
ok, I would not call that maven-ready in this case :)
You're right, that was a bad choice of words :|
Here are a friend of China?
Where to find the jME 2.0 release files ?
There's nothing on Google Code …
i don't think there will be a down loadable release anytime soon (it would be outdated 2 days later), you have to get the code through svn.
jme 2.0 is still in its early development phase (though as stable as jme 1.0).
How about resuming this discussion now? It’s been nearly 2 months since jME 2.0 was “still in its early development phase”. Any chance we say it’s in its later development stages now, like a Release Candidate 1 for instance? And if that’s the case, a downloadable version should not be out of the question either.