This thread has jumped the shark. I recommend letting it drown. On Wed, Oct 13, 2010 at 3:44 PM, Jason Chaffee <[email protected]> wrote: > I agree with how things seem to run differently on cmd-line, vs. eclipse, vs. > Hudson. I can be extremely frustrating. > > However, maven does take a "convention over configuration" approach to things > for the most part. Many times the problems people encounter are not > following the convention and they are trying to configure maven to do > something that isn't a best practice. > > -----Original Message----- > From: Leon Rosenberg [mailto:[email protected]] > Sent: Wednesday, October 13, 2010 11:52 AM > To: Maven Users List > Subject: Re: maven is a swamp > > On Wed, Oct 13, 2010 at 5:31 AM, Brian Topping <[email protected]> wrote: >> >> On Oct 12, 2010, at 10:01 PM, Martin Gainty wrote: >> >>> Suprisingly maven is not the first programming language to use XML >> >> This is worth clarifying. What makes Maven unique, and I believe >> groundbreaking, is that the POM is declarative, not procedural. It is not a >> programming language in the traditional sense. There are many examples of >> procedural languages written in XML, and many agree they are painful to use. >> That's why the one that was used in Maven 1.x is notably absent from Maven >> 2.x > > Many traditional programming languages are declarative and not > procedural or are based on declarative concepts, most of the time the > declarative nature of such languages proved itself problematic. > But seriously is there a comparison matrix somewhere which compares > ant+ivy vs maven? As an ant+ivy user I have recently tried out maven > (yes, i hand-wrote poms for about 15 projects) which mostly depend on > each other, I got them all published in nexus etc. I must say that I'm > pretty shaken how unreliable maven build are. > With ant it either works or not. If it works, it works everywhere, in > console, in eclipse in hudson. With maven, I got plenty of builds that > run in console but not in eclipse, or in eclipse but not in hudson, or > in hudson but not in console. Besides that I haven't found anything in > maven that isn't present in ant somehow, except for parent-poms, but > they got added to the recent ivy release so they don't count anymore > ;-) > > I find it pretty hard to maintain versions with maven. Do I have to > make them all depend on RELEASE version of each other? Distinct > versions of each other? SNAPSHOTS? I started with snapshot, but I > couldn't publish a second version without republishing everything, so > I consider this bad idea... > > regards > Leon > > P.S. Is there a documentation somewhere which really describes which > lifecycle phase is meant for what? > > . >> >> Once you get used to the paradigm shift and get used to it, it becomes >> remarkably easy to look at any build and find what it is doing. While many >> systems (like Ivy) have started using Maven's central repository, if they >> use procedural descriptions of a build, they are missing the vision that >> Maven has. >> >> Personally, I find it frustrating to have to dissect an Ant build to figure >> out what's going on. A Maven build is validated against a schema, and >> finding what I am looking for is predictable and quick. It's also fast to >> write, since most IDEs can do type-completion with a schema declaration, and >> many have been augmented to read plugin.xml files inside plugins to do type >> completion of plugin configuration as well. >> >> Lastly, having a validated structure for the build allows IDEs to import the >> POM directly, and because the Plugin interface is so simple, it's easy for >> IDEs to integrate against plugins. In my experience, this level of >> integration is unique to Maven. >> >> Hope you stick with it. Maven will really grow on you, as it has with a >> huge number of folks over the last few years. >> >> Brian >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
