SubEtha SMTP, Maven and a Community Repository
We'd been using Dumbster to run some email integration tests. I've used it before, and it gets the job done. However, when running the overnight timed build (to drive out problems, we run the build repeatedly overnight), the email integration tests would occasionally lock up, never exit, and cause the build to run forever. A few logging statements drove out the source of the problem -- the Dumbster.start() method was going away and not coming back.
I'd previously seen the suggestion that SubEtha's Wiser was as capable and better code (less flaky, fewer problems) so I quickly swapped out Dumbster for SubEtha. Or, so I hoped. The swap was pretty easy, the hard part was getting a Maven-ready version of Dumbster with:
- A versioned JAR: Grab the JAR from the download, upload it to our local repository, give it a group id and a version number (org/subethamail/subethasmtp/2.0.1/subethasmtp-2.0.1.jar).
- A versioned JAR of sources: ZIP the source directory starting with the top-level package, rename it to a JAR, upload it to the local repository with the same group and artifact id as well as a version number (org/subethamail/subethasmtp/2.0.1/subethasmtp-2.0.1-sources.jar).
- A POM listing the transitive dependencies: Create a POM, check all the dependencies in the lib directory, look up each to find out the appropriate artifact and group identifier, spend a little time evaluating the smallest set of dependencies that are necessary (if one includes another, such as was true for parts of Mina), then upload that as the POM (org/subethamail/subethasmtp/2.0.1/subethasmtp-2.0.1.pom).
Since I'd already done the work, I posted my work to the subetha issue tracker in the hopes that they'd adopt it. No such luck. Their response:
That's great and all, but I don't really care about Maven, nor do I really want to add or maintain a pom.xml in the project. Sorry.
I admit, if I weren't using Maven on my project, the idea of keeping a POM up to date and uploading it to a remote repository would seem like a pain, and I've seen that attitude before. That said, if you want your project to be adopted by people, this is one way to ease the transition for some group of users, so it's unfortunate that projects take this stance.
A Community Repository
With that in mind, it'd be great if there were a public community repository for Maven which was like the public repository, but held artifacts for projects that were unwilling to supply them, but willing for someone else to maven-ize their project. Members of the community who'd created a Maven-enabled version for their own use could post their version for others to pick up.
This could be as simple as a second public repository which could be added, or perhaps even simpler, a top-level folder in the Maven public repo called unofficial where unofficial artifacts could be posted. The latter would ensure that Maven users would be fairly clear up front that they were pulling in an unofficial artifact, by virtue of the group id.
The primary danger in this approach is that people would fail to respect the license terms of software -- by packaging a piece of software for Maven, you may be considering redistributing it, and you'd have to be careful, as some software projects might not wish to have this happen.
As long as it were possible to have one's project removed from the repository and if the community tried to respect the desires of those projects, this still seems like it could be a very helpful addition.
4 comments:
The Central repository doesn't care if you use Maven or not, so dismissing the integration off hand is unfortunate. My response is here.
Would you pay a fee to use such a repository?
One where non-maven projects have proper poms maintained and keep up with the correct Maven practices.
Just think how nice it would be for a set of Hibernate poms that actually listed the optional dependencies rather than bringing everything in.
I love how you didn't quote my name in the response. At least give credit where credit is due. =)
To reply to your posting, it isn't that I don't want the project adopted by people. You have made an assumption based on my response, that is inaccurate. To clarify...
It is that forcing people into adopting a technology just because you happen to use that technology isn't fair either. There really needs to be an easy way for Maven to integrate with projects that don't adopt it, instead of this brute force, "your an ass if you don't use Maven" attitude that the Maven community is pushing on people (and bloggers like you are extolling in their blogs). In this way, Maven has become a religious argument and I don't play those games.
With regards to gaining a large user base as the goal of all OSS projects. Honestly, that isn't my goal. I've created enough projects with enough users (I co-founded the Apache Jakarta project) that having a big roll call just isn't thrilling anymore. It is sad to me that that is what OSS has turned into. A big fat popularity contest. I care more about creating easy to use quality software that just works. SubEtha SMTP is exactly that regardless of how many people use it. It suites my needs and you are welcome to enjoy it if you like.
In response to Brian, I don't care about the central repository either. I don't use it. I don't need it. Again, don't try to force me into your way of doing things, I don't like it.
jon scott stevens:
Hey, wasn't trying to point fingers at anyone in particular -- was focusing on the content rather than the author, but sure, feel free to self-identify. :)
I agree that'd it'd be nice for Maven users to find a way to integrate projects that don't specifically desire to integrate with Maven -- that was the main thrust of this post, I think.
If I came across as offering a "You're an ass if you don't use Maven" viewpoint, that's not what I intended.
It would make my life, and the life of other Maven users easier if projects published their artifacts in the Maven repository. It'd be convenient, and convenience can drive adoption. That said, I accept that driving adoption may not be the goal for all projects, which you're saying is true for you.
And, heck, despite all the above, I'm using SubEtha SMTP, and I've published it to the Central repo for others, so it all has a happy ending, as far as I'm concerned. It was more painful than I'd like, to get there, but it was worth it to have an email testing framework that was less flaky than Dumbster for us.
Post a Comment