JCommon and JFreeChart on Maven Repository is out of date

[ali65]

David,

Maven people gave you sane processes and working tools.

If it would be easy to give you tools and processes to your Ant to perform the same tasks what you can do with Maven, then they would have probably just built their system on top of Ant. They did not.

I don't see any problem with the "proposed solution" such as N projects leaving Ant and adopting Maven. It is not a problem, because this movement does not have to be synchronized movement: A Project which converts to Maven can still produce output for their consumers who might still be on Ant or other while integrating better with the other converts.

Al

[david.gilbert]

Maven people gave you sane processes and working tools.

OK, so let's continue with the manual upload process.

If it would be easy to give you tools and processes to your Ant to perform the same tasks what you can do with Maven, then they would have probably just built their system on top of Ant. They did not.

I'm not suggesting that Maven can't perform the JFreeChart build. I'm sure it is very capable of doing that. As is Ant. From what I know about Maven, it seems they are addressing a problem (dependency management) that Ant doesn't address directly. But JFreeChart doesn't have a dependency management problem to solve (it only uses one other library, JCommon) so Maven doesn't have an advantage over Ant in that respect, for us.

I don't see any problem with the "proposed solution" such as N projects leaving Ant and adopting Maven. It is not a problem, because this movement does not have to be synchronized movement: A Project which converts to Maven can still produce output for their consumers who might still be on Ant or other while integrating better with the other converts.

You're not convincing me. And I'm not even close to considering adopting Maven, so you might want to give some consideration to alternative solutions, the most obvious being getting the Maven people to streamline their upload process so that people aren't put off keeping the repository up-to-date.

[ali65]

Dave,

I have found a project with some hybrid solution, where the project uses Ant but its build generates output to Maven.
Maybe this is what you want.

You can look at its Maven POM file here:
https://jna.dev.java.net/source/browse/ ... ml?rev=827

Ant building script here:
https://jna.dev.java.net/source/browse/ ... ml?rev=827

You cannot copy it exactly as it is (I meant the Maven repo upload part) because this JNA lib project uploads to java.net Maven repo.
Maybe just the addresses need to be changed.

Maybe we find some similarly hybrid SourceForge project with working scripts to copy.
Does SourceForge provide you Maven repo? I think this is the key question.
If we find out how to upload to SourceForge repo, syncing it to Maven central will be a piece of cake.

Cheers,
Albert

[ali65]

Dave

I was so excited about that finding that I forgot to argue:
1. I never considered a Manual upload process to be sane. Sane is when you automate anything what can easily be automated. (I thought using Maven).
2. I did not say the dependency management is a problem of a library provider. It is a problem of the application builder who builds with many libraries. Those people benefit from using Maven, and also benefit if the library provider uses Maven. (Let me not explain why, when the Maven book can explain it so nicely).

Al

[RichardWest]

You're not convincing me.

I concur; the argument would be better made when shown and not when told.

1. I never considered a Manual upload process to be sane. Sane is when you automate anything what can easily be automated. (I thought using Maven).

Working with JFreeChart is automated: update from the SVN repository and build with Ant or download the prebuilt JAR files.

2. I did not say the dependency management is a problem of a library provider. It is a problem of the application builder who builds with many libraries. Those people benefit from using Maven, and also benefit if the library provider uses Maven. (Let me not explain why, when the Maven book can explain it so nicely).

I use multiple libraries from multiple sources in my program. I just include all the JAR files in my classpath. JFreeChart and JCommon are just two of those files.

[ali65]

Dear Richard West,

1. This is a contradiction:

Working with JFreeChart is automated

I just include all the JAR files in my classpath

Maven automatically includes the required JAR files in your classpath!

2. Because you are not having the problem currently, which problem could be solved by the dependency management of Maven, it does not mean that the problem does not exist. It is a potential problem for you, it is a current problem for others:
http://agilesoftwaredevelopment.com/blo ... s-jar-hell
You can google "jar hell", or this article:
http://en.wikipedia.org/wiki/Classloader
has a good definition of it.

Cheers
Al

[matinh]

Hi!

I am a maven user and a JFreeChart user. When I want to upgrade JFreeChart to a version not yet in the official repository, I usually take the required JARs and deploy them to my internal repository manager (apache archiva). As using a repository manager is suggested anyway, this is not a big problem. So the need for getting recent JFreeChart version into central is IMHO not as high as it seems.

On the other hand, the long term goal should definitely be to get new versions of JFreeChart uploaded to the central repository automatically. However, I'm completely with David and wouldn't switch my build system just to support uploading a JAR to a server (I like maven and wouldn't switch to ant just to support a single use-case). As David already pointed out, other projects have the same problem as well and a discussion with a hopefully good solution was just going on the other day on the maven-users list. The proposed solution was to use Sonatype's free OSS Repository Hosting service.

After the initial setup uploading a new version would just be a matter of executing

Code: Select all

mvn deploy:deploy-file -Durl=http://oss.sonatype.org/content/repositories/jfree -Dfile=jcommon.jar -DpomFile=jcommon.pom
mvn deploy:deploy-file -Durl=http://oss.sonatype.org/content/repositories/jfree -Dfile=jfreechart.jar -DpomFile=jfreechart.pom

Would this be an option for JFreeChart?

hth,
- martin

PS: Creating a valid Maven 2 pom.xml file is on my TODO list a wrote in another thread.

[ali65]

There is one reason why creating Maven repositories from non-Maven project will not work on the long term.
The non-Maven project's build system does not use the Project Object Model meta information for building the project.
Therefore nothing guaranties that within this database the dependency information will be correct.
Exceptions are those projects which have no dependencies. Not even jFreeChart can be put into this category.

I am not Maven-fanatic in a way that I would not accept a Maven alternative for resolving the problems what Maven was designed for, bur show me one alternative. Just pretending that the problems don't exist is not my way of solving.

[ali65]

David,
Yesterday I finally decided to create a new Maven project and copy paste all JFreeChart sources (checked out from svn/cvs).
Less time was spent fixing the problems with the Maven building process than trying to convince you to use Maven.
(Needed to move out the Test classes to the test dir, and the properties files to the resources dir to make it work).
I am so sorry I did not do it earlier.
The mavenized jfreechart soon to be found on a public server. (After some cleanup).
LGPL.

[RichardWest]

Less time was spent fixing the problems with the Maven building process than trying to convince you to use Maven.

I think David and I both implied that would be the case. Thank you for doing the leg work. Are you also volunteering to maintain the repository?

[ali65]

Source repository (SVN server) is probably going to be maintained by Kenai,
there I can get one account setup easier (faster) than anywhere else.
http://kenai.com/

Server which will store the produced artifacts will be maintained by Sonatype.
This is place is close to the fire.
https://docs.sonatype.com/display/NX/OS ... ry+Hosting

If you need, I will also try to assist you to get the project to Maven Central repo:
http://www.sonatype.com/people/2009/06/ ... epository/

I can transfer source updates from original SourceForge SVN/CVS to the new location at the beginning, later I would not mind if someone takes it from there.

[david.gilbert]

I can transfer source updates from original SourceForge SVN/CVS to the new location at the beginning, later I would not mind if someone takes it from there.

Surely you're not also suggesting that we drop SourceForge in order to get one jar file into the Maven repository? You are crazy.

I am going to follow up the approach suggested by 'matinh' above, which sounds like the most practical and efficient solution that's within our control.

[ali65]

David,

I did not suggest you to leave SourceForge, however after my experience with the performance what they provided to me any time I used them, I have reasons to do so.
I meant Kenai allows me to have an SVN server really quick. How could I show you otherwise the mavenized project and all the steps what was needed to make it?

I am suggesting you to bring your project to Maven not that single jar file (which is not single, but double).

If you want to see something really crazy from me:

*the jFreeChart logo

[david.gilbert]

I meant Kenai allows me to have an SVN server really quick. How could I show you otherwise the mavenized project and all the steps what was needed to make it?

A diff file perhaps? Or a zip file containing the modified project, along with a description of what you changed and why? I think launching a new project on an external service in order to get a Subversion server in order to show me the changes you've made is overcomplicating things a little.

In any case, I think we've established that we're not going to work well together so I'd recommend that you save yourself some time and call it a day. I sense that you are a "last word" kind of guy, so I'm going to let you have the last word. I promise to read it, and I promise not to reply.

If you want to see something really crazy from me:

*the jFreeChart logo

These days, having paid a graphic designer to create something more conventional, we use this for the logo:



But I still love the mountain gorilla. I took that picture myself, in Zaire (as it was known then) in 1995...great trip, great times! Thanks for jogging my memory.

So long 'ali65'...

[ali65]

C'est la vie.

I'd recommend that you save yourself some time and call it a day. I sense that you are a "last word" kind of guy, so I'm going to let you have the last word. I promise to read it, and I promise not to reply.