I have opened this discussion as a user feedback for developers of JaCoP. This library is really good, the authors made almost perfect work, but there are always some issues, that might be slightly better.
I also ask other users of JaCoP to share their opinion and ideas. Lets make it even better.
I have for now 3 proposals for authors:
1) I havent found a Maven repository. I think this project should have one, because many developers (including me) are using this project manager as a default choice (ant is for us pretty dead :-)).
2) slf4j instead of System.out.print. slf4j is probably the best choice for logging (its a facade for almost any logger, including siple print out). Let the users decide which level they want to print and where…
3) I have noticed the Switcher class. I think that it would be much easier to look for XML file on classpath, if it does not exist - the system would behave in default manner. If it exists it would change the configured behaviour.
I highly doubt that anyone, who wants to debug his program or JaCoP, would like to compile whole project from sources…
Thanks for your comments and suggestions. Please, note however that JaCoP is under development under last 10 years and some tools were not important or even not available at the time when we started the project. We are currently considering some of the suggestions you have mentioned. Logging is definitively one of the issues but it requires quite much "stupid" work which we want to avoid or spent more time on valuable parts of the project ;)
Maven is a good candidate to organize our project. We use ant since it was one of the best choices then. We might change to maven. It requires some reorganizations.
Anyway, I will soon add to svn build files for JaCoP and ExamplesJaCoP ;)
Thanks ones more,
Thank you for the feedback.
I was looking into logging recently. slr4j was one of the options, however since it is a facade then adding logging in this manner would require user to add at least one if not two jars to classpath. We noticed that many people just at the prospect of adding libraries to the path are already giving up trying the software. ;(. We decided to look into AspectJ and logging together and work on nonintrusive state-of-the-art logging. In this case, Switches file will disapear as well.
When it comes to Maven, I never had a need to use it. Kris is happy with ant so here we are behind software engineering state-of-the-art. I prefer to spend time of implementing new important articles than improving project management. This things change faster than I can keep up.
If you have time. I would be happy to work with you on logging (AspectJ and slf4j) to get it in the best possible shape. In case of Maven, you will have to contact Kris to see if he has time to work on Maven and if it is possible to help him with that.
2Kris: I am aware that JaCoP is pretty old library, and that on the road you had to make some compromises. But since the functionality seems to be almost complete (I know, this kind of sotware will be never complete), I think that it would be reasonable to get rid off some of these limitations and make JaCoP more user friendly :-).
2Radek: About your point with libraries. I think that Maven solves it completely. For sure, you will have some dependenicies in the future with any logging, even the aspectJ one.
What I really hate about ant are the libraries, I absolutely agree with you. But with Maven, its much more simple. In your JaCoP guide you will have section (actually only few lines) about what to do. It would state that the users should add to their pom.xml (configuration for maven) your repository (its simple directory structure, nothing special), for example these lines:
<id>JaCoP - snapshots</id>
Than you will simply state, that if the user wants to log via log4j, than he should use this dependency:
And that JaCoP maven artifact is this dependency:
<dependency> <!- This dependency will force client to download all transient (mandatory) dependencies ->
This is simple even for someone who had not know yesterday, that maven exists (for sure its more simple than adding the main library and 48 dependent libraries)… On your side it would take only creation of the appropriate directory structure somewhere and the pom.xml (it may have only few lines, because you dont have any dependencies now…)
I am not saying that its a must to use maven, but many developers (including me) use only Maven, and its pretty clumsy to add it only to your local repository (because no global exists)… For many others it may a good reason not to use JaCoP and use some other library….
I dont think that I have enough time to help you, because I am currently writing my masters thesis and I have a project of my own and I dont fully understand the inner parts of your code. Maybe next term I would have much more time to help you (I will probably try phd studies…but currently I dont even have proposed topic of the dissertation :-)).
…Especially the logging rewriting would be pretty time expensive (as Kris noticed).
One more thing, it may be controversial for you - licencing. The GPL based licences are really not popular among developers, because they are viral. Noone wants to publish their space program library for NASA under AGPL just because it uses JaCoP in some unimportant manner…
Also high percantage of users of JaCoP will never try to modify it, and if they would, they probably wont tell anyone (including you). If someone wants to share their opinion or improvements/bugfixes/patches, than he would do it even if the code was under BSD…
I think that this licence just slows down the community, because many people wont use JaCoP because of this licencing, but you gain very little in return…
Big projects a la Spring Framework or Hibernate are under LGPL (its not viral) and their community works perfectly and the libraries are better than gold-mine (fromt the financial perspective)…
Thanks for a long response and tips concerning Maven.
We offer JaCoP under dual licensing scheme. The companies may get non-free, still cheap, commercial license so virality of AGPL is not an issue. LGPL forces us to shift our business model to consulting one and it is not what we want to be doing for living, even if we do it from time to time to help our users. We like to spend most of our free time on keeping JaCoP up-to-date. You would be suprised how many interesting techniques are out there, this tool will never be finished ;).
Just a thought.
Do you guys think JaCoP needs a front end language? So instead of expressing variables, constraints, and objective functions in somehow harder to read Java code, the users can write them in a simpler (straightforward) and more friendly language?
JaCoP has already a **very** good front-end language, MiniZinc (http://www.g12.csse.unimelb.edu.au/minizinc/). You can download minizinc to flatzinc compiler and then use flatzinc files directly in JaCoP (JaCoP.fz.Fz2jacop). You must of course, use JaCoP library to fully use global constraints. For more information see README file in JaCoP.fz.
Minzinc has been used in solver competition where JaCoP got a second place.
I too find the current situation with JaCoP not ideal. If the licensing was LGPL or if the jar was available in maven then I could recommend JaCoP usage but it's not really viable at the moment. You don't need to switch from ant to publish your artifacts into a maven repo - there are Ant tasks in addition to the manual approach. You can also publish straight into the sourceforge files area (though that's probably easier with maven or gradle).
Dear Paul King,
Thank you for the post.
We will not make JaCoP LGPL. We will follow the strategy employed by neo4j (http://neo4j.org/).
We will publish maven artifacts. We are already using Maven internally when working on the version 4.0. This version has participated in the newest edition of Minizinc competition.
I myself have switched to Git. Therefore, there will be also github repository for JaCoP. It will be easier to request pull of your changes to JaCoP code that we can pull in if we like it.
If you have any other ideas please share it. We will look into them. It may take longer time than we would like to implement them but good ideas will be implemented (eventually).