for version 1.3.1 here is the module.xml the only change is on line 6 with the addition of this property:

<property name="quickfixj.version" value="1.3.1" />

the core/build.xml the changes here are in the jar target

The all-in-one is probably a good idea.

Currently, just picking out one FIX version plus the core does not work since the DefaultMessageFactory
depends on all FIX versions.

I use a lot of open source products and my impression is that it's more common to not have the version numbers in the filename. I personally see advantages and disadvantages to both approaches and I don't have a strong personal preference. However, I probably won't change the current approach unless I'm convinced there is a clear benefit to the renaming.

In case you didn't know, you can determine the version of a quickfix-core.jar by executing it (e.g. "java -jar quickfix-core.jar").

I don't have a problem creating a quickfixj-all.jar.

As Joerg mentioned, there are issues with the message version dependencies. I think the issue DefaultMessageFactory can be solved by doing lazy creation of the version-specific message factories. The MessageCracker is another issue. However, this has been documented in other JIRA issues.

i am glad we agree on the all-in-one jar. you can see my creation of the all-in-one jar in the build.xml attached. if you like it, you may use it.

the advantages of the naming that i see are:

• no extra step before knowing the version
• the java -jar approach was introduced recently so it wont work for all and it not a 'standard' approach for finding out the version

the disadvantages that i see are:

• people used to current files names will have to get used to another version
• the java -jar works only for the quickfixj-core jar and not he message jars
• if i download 2 versions of quickfixJ, the message-version-specific jars are named similarly and the only difference is an md5hash

i would also like to add that directory that the tar-gz (or zip) that is created from the sourceforge download should also have a version number in it so as to distinguish between version numbers.

I'd vote for having a version in the jar file as well.
We actually end up hosting all the QFJ jars on our Maven repository at http://repo.marketcetera.org/maven/quickfixj/ . Maven assumes that the jars have the version in them, so I would think most open-source projects are moving towards the "version-in-name" convention in the future.

Saqib, if you are using Maven, you can access QFJ off the Marketcetera repo if you follow the Maven instructions from http://www.quickfixj.org/quickfixj/usermanual/installation.html#build

Note that the docs are slightly outdated, you can grab versions 1.3.1 from there now.

+1 for adding version to the jar name. It's a simple way to make version management of dependencies easier.

OK, I'll add the version numbers to the JAR file as well. I've scheduled this for 1.3.2. Thanks for the comments.

just want to add that we should also put a version number in the dir that gets un(g)ziped from the sourceforge download. for example

quickfixj-1.3.1-bin.tar.gz should untar/gunzip to a directory called 'quickfixj-1.3.1' and not 'quickfixj'

do you want a patch for this for the current trunk version of QuickfixJ? or for any of the branches?

A patch against the trunk or just the modified file (I can diff it myself) would be great. Thanks.

my apologies for the delay... i just got some time on hands and i will endeavour to get you the modified files this week.

here is a patch against the current trunk for this issue. i hope it is to your satisfaction. the files in question are:

$ svn status
M core/build.xml
M examples/build.xml
M build.xml