Mavenize

[David Kocher]

Is there any interst that the project would have a POM and the directory structure being changed to standard Maven layout?

-
David

[Jon Stevens]

I'm a huge maven hater and would be totally against this. =)

jon

[dkocher]

Can you shed some light on what exactly makes you oppose Maven that
much?

[Jon Stevens]

a) it is confusing and difficult.
b) it is poorly documented.
c) the xml dsl sucks.
d) the forced (aka: suggested) directory layout is stupid.
e) it is slow.
f) it has fundamental design issues for anything other than a simple
jar file generator.
g) it doesn't gain you _anything_ that ant already provides.
h) the central repository is a joke. i could upload a sardine.jar
there that had security backdoors and no one would be the wiser.
i) anytime maven doesn't do something the way you want to do it, you
have to jump through massive hoops.
j) it doesn't guarantee that your build today will work tomorrow... or
10 years from now.

Any one of those is a deal breaker.

You can also do your own searches... look for "why maven sucks":

http://www.google.com/search?q=why+maven+sucks

ex: http://betarelease.github.com/2009/06/01/top-ten-reasons-why-maven-sucks.html

If find this discussion really silly because it should be more like...
"how come you can't see that maven sucks?"

I'm not saying that ant is the end all best tool out there either...
but even after all these years, it is certainly better than maven.

jon

[tchize]

I don't care if you build your project using maven or ant, or as an
eclipse project, or a Makefile or using a vodoo doll.
Am a huge maven fan and ant hater, I find ant complex and confusing
and maven very easy to use ;)

As long as Sardine stays available as a maven library and has correct
declared and maintained dependencies am ok with whatever decision you
take :)

[Ondra Žižka]

a) Maven has bad learning curve, that's true. But once you invest in
it, you'll get the benefits of standardized build process.
b) Here and there, with complex projects, you may find a spot which is
poorly documented. But for simple project like Sardine, everything it
will ever need is documented well.
c) I agree, but there are not much options - XML has great support in
many IDE's and it's simplicity allows further integration with many
many tools. Also allows editing of project through XSLT which is
great.
d) Not forced - you can change project dir layout to whatever you
like. Plus, it's not stupid - it's created for mid-sized projects
which mostly use this scheme anyway.
e) Maven 3 is a lost faster than Maven 2. But true, it's slower than
Ant. But `make` is faster than Ant and you don't use it :)
f) Many huge companies are migrating to Maven due to both technical
and "social" reasons - like JBoss. I think their (our) engineers
wouldn't go that way if it was so unsuable.
g) It allows you grasping an unknown project much faster. That's it's
main purpose, afterall.
h) I am not aware of this, so I can't comment.
i) Well, that's true, and I hate this too, indeed. But it's getting
better (mostly through new plugins contributed by community).
j) It does, under certain conditions: You have your own repository,
you set plugin versions exactly, and you check thirdparty checksums.
If you put as much effort to Maven build process as you do with Ant,
then it's not hard to get 100% reproducible build. Ask JBoss
productization teams for more info.

Anyway, I don't want to advocate Maven; My main idea here is, that
there's no reason not to do Sardine build in Maven.

[Ondra Žižka]

I suggest that we create a pom.xml in a root dir of the project,
alongside Ant. It will allow building with Maven, and will not affect
anything else. Especially, it will not prevent using Ant.

[David Kocher]

I don't think maintaining two builds is any fun.

[David Kocher]

Also aside from technical points we could gain the support of Mirko Friedenhagen to commit direclty to our repository instead of [1]. I think more people maintaining the code is a plus.

-
David

[1] https://github.com/mfriedenhagen/sardine

[Jon Stevens]

On Tue, Jul 5, 2011 at 8:29 AM, David Kocher <dko...@sudo.ch> wrote:

I don't think maintaining two builds is any fun.

I concur.

When Maven gets the ability to take a .zip file from a website, extract the right jar file and host it in some magical repository somewhere... that will be the point it is a useful tool.

p.s. How do you feel about the board of apache throwing all the sonatype employees off the Maven PMC for acting like asshats?

jon

[David Kocher]

On 05.07.2011, at 17:33, Jon Stevens wrote:

> On Tue, Jul 5, 2011 at 8:29 AM, David Kocher <dko...@sudo.ch> wrote:
>
>> I don't think maintaining two builds is any fun.
>>
>
> I concur.
>
> When Maven gets the ability to take a .zip file from a website, extract the
> right jar file and host it in some magical repository somewhere... that will
> be the point it is a useful tool.

What use case is that?

> p.s. How do you feel about the board of apache throwing all the sonatype
> employees off the Maven PMC for acting like asshats?

Does this affect Sardine in any way if using Maven or not?

>
> jon

[Jon Stevens]

On Tue, Jul 5, 2011 at 11:31 AM, David Kocher <dko...@sudo.ch> wrote:

> When Maven gets the ability to take a .zip file from a website, extract the
> right jar file and host it in some magical repository somewhere... that will
> be the point it is a useful tool.

What use case is that?

The whole reason why maven weenies whine about using maven is so that they can add it to their pom.xml dependencies easily. If Maven could deal with getting jars from more than just the main repo's (or have the main repo's import jars from .zip files), then this problem would be solved and nobody would care what built it, just so long as they can download it.

 

> p.s. How do you feel about the board of apache throwing all the sonatype
> employees off the Maven PMC for acting like asshats?

Does this affect Sardine in any way if using Maven or not?

It affects the maven community, yes. The only people contributing to maven are sonatype employees. If they decide one day that they want to change something that breaks things (or start charging to use maven), then they have every right to do that. I prefer to depend on truly open projects.

jon

 

 

[David Kocher]

On 05.07.2011, at 21:30, Jon Stevens wrote:

>>> p.s. How do you feel about the board of apache throwing all the sonatype
>>> employees off the Maven PMC for acting like asshats?
>>
>> Does this affect Sardine in any way if using Maven or not?
>
>
> It affects the maven community, yes. The only people contributing to maven
> are sonatype employees. If they decide one day that they want to change
> something that breaks things (or start charging to use maven), then they
> have every right to do that. I prefer to depend on truly open projects.

There would be a fork on day one I suppose. See Hudson/Jenkins for reference.

[Jon Stevens]

On Tue, Jul 5, 2011 at 12:34 PM, David Kocher <dko...@sudo.ch> wrote:

There would be a fork on day one I suppose. See Hudson/Jenkins for reference.

Exactly, and you know who is behind that bullshit? Sonatype as well.

jon

[David Kocher]

On 05.07.2011, at 21:30, Jon Stevens wrote:

> On Tue, Jul 5, 2011 at 11:31 AM, David Kocher <dko...@sudo.ch> wrote:
>
>>> When Maven gets the ability to take a .zip file from a website, extract
>> the
>>> right jar file and host it in some magical repository somewhere... that
>> will
>>> be the point it is a useful tool.
>>
>> What use case is that?
>
>
> The whole reason why maven weenies whine about using maven is so that they
> can add it to their pom.xml dependencies easily. If Maven could deal with
> getting jars from more than just the main repo's (or have the main repo's
> import jars from .zip files), then this problem would be solved and nobody
> would care what built it, just so long as they can download it.

I do like that feature as well. I don't know of any limitation in Maven to rely solely on the central repository. We are perfectly fine setting up our own repo in the SVN if we wanted to do so and not rely on central.

[Jon Stevens]

I do like that feature as well. I don't know of any limitation in Maven to rely solely on the central repository. We are perfectly fine setting up our own repo in the SVN if we wanted to do so and not rely on central.

We already have one setup. It is just a pain in the ass to remember to have to update it. The update process is effectively the one that I just described... grab the .zip, expand and upload the jar into svn. The people who run these central maven repo's should just fix this issue... its been going on for what, 10 years now?

jon

[Mirko Friedenhagen]

On Tue, Jul 5, 2011 at 21:30, Jon Stevens <latc...@gmail.com> wrote:
>
>
> On Tue, Jul 5, 2011 at 11:31 AM, David Kocher <dko...@sudo.ch> wrote:
>>
>> > When Maven gets the ability to take a .zip file from a website, extract
>> > the
>> > right jar file and host it in some magical repository somewhere... that
>> > will
>> > be the point it is a useful tool.
>>
>> What use case is that?
>
> The whole reason why maven weenies whine about using maven is so that they
> can add it to their pom.xml dependencies easily. If Maven could deal with
> getting jars from more than just the main repo's (or have the main repo's
> import jars from .zip files), then this problem would be solved and nobody
> would care what built it, just so long as they can download it.

Hello,

I think this might be easily done using a repository element in the
pom. See https://github.com/mfriedenhagen/sardine/blob/master/pom.xml#L304.
As there is a bug in httpclient-4.1.1 affecting compression
(https://issues.apache.org/jira/browse/HTTPCLIENT-1075), I build the
4.1.2-SNAPSHOT version
(http://huschteguzzel.de/hudson/job/httpclient-4.1.x/) and have
Jenkins serve the artifacts from this build via a plugin
(http://huschteguzzel.de/hudson/plugin/repository/project/httpclient-4.1.x/LastSuccessful/repository/).
And there are google code projects which use SVN as a repository
(http://code.google.com/p/selenium/source/browse/#svn%2Frepository%2Forg%2Fseleniumhq%2Fselenium%253Fstate%253Dclosed).
I even encountered one, which uses github for the sources and
google-code SVN for repositories only.

Best Regards
Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/

[David Kocher]

You misunderstood. I mean maintaining our own repository with all dependencies and reference it in the POM which has precedence over central.

[Jon Stevens]

Ah. How is that any different than /lib? The only thing lacking is dependency tracking which I'll argue is a non-issue. Especially for a project this size.

Jon

Missplet on my ipone

[David Kocher]

This is proposed as a way to not rely on the central repository if that is what you fear.

My pro argument beside the technical ones mentioned before in this thread for Maven is to make it easy for third parties to use Sardine. Maven is the de-facto standard (as much as I hate to use the word "standard" as a synonym for market leader) for that. And we should care about this, as easier integration drives adoption. More users means more bugs reported, contributors and improving the feedback cycle in general. Therfore improving Sardine itself. Size matters for open source.

-
David

[Jon Stevens]

The use of ant doesn't hold back the project from being used. The build and deployment model for this project works just fine. You check the project out of svn, type 'ant' and it just works.

I'm not -1 on including a pom.xml. I'm not -1 on including sardine in the central repos. I'm not -1 on creating a repo in svn for sardine.

The only thing I'm -1 on is making it the primary build mechanism. I will always prefer something other than Maven. There is no discussion that will convince me otherwise. Just because others choose to use a horribly broken tool doesn't mean I should to. I don't buy the argument that it is a 'standard' because I know enough people who won't use Maven either.

Think of it this way, I created this project because *all* of the other webdav clients were piles of crap and I wanted something that works better. Like always, I put my code where my mouth is. I wasn't just resolute to use some other library because it was convenient.

I currently work in a company with 30+ developers distributed all over the world. We have gigs of source code, 100+ jars in the lib directory, 20+ projects and 20+ branches working in a 3 week iterative release cycle. We use the same exact mechanism I use in sardine for building everything here at work. It works great and everyone is happy. All people have to do is check a branch out of svn, type 'ant .eclipse' and it creates all of our Eclipse project files in less than a minute and a new developer is up and running writing code in 10 minutes. Not only that, but the build files are easy to understand and anyone can figure out the entire build system in a matter of minutes. You are going to have a very hard time convincing me that Maven can do this better.

Q: How do you express in Maven lingo that commons-codec 1.4 conflicts with jasypt 1.6? A: You can't without some serious hackery.

cheers,

jon