On 15/10/2010 5:38 AM, Brian Smith wrote:
I really fail at understanding the XML rage. Yeah it's verbose. How's that
a problem? We've had tools with auto complete, auto format and syntax
highlighting for well over a decade, we also now have fairly robust GUIs
too. If you're hand editing a 2000 line xml file in a green screen terminal
you're doing the equivalent of using an abacus and I'm afraid you're not the
user new tools ought to be aimed at.
+1
XML has a huge ubiquity value. It might not be the *best* tool for the job
for each individual user but it's the only one that is widely enough
understood to not put an additional learning burden on the user. When I
learned Maven I had to grok concepts like dependencyManagement and plugins
and phases. I didn't have to learn XML, I already knew it. If Maven POMs
were written in Python or A.N.Other language/markup I'd have to learn that
too. There are many useful libraries that make it easier to produce GUI
tools on top of XML that don't exist for alternatives, so we'd have less
tooling for POMs. Tooling and minimising the learning required are good
things.
+1
The _actual_ problem I see is the lack of "best practise" use for plugins
off the beaten track. The documentation is usually fairly good at telling
you how to make a plugin do something, it's less than brilliant at
recommending best practises and unless it's one of the mainstream ones
covered by the sonatype book it's hard to find. I've found the best thing
to do in those cases is go look at large, open source projects and see how
they do it. Ken's original problem in this thread (and the others he's been
getting help with on the scala list) are _nothing_ to do with XML, that is
just the target of frustration. They would have happened regardless of the
language for POM specification.
Moving any mention of custom plug-ins to another Apache project might be
the best favour that the developers could do for Maven.
Maven is incredibly flexible but it will build almost anything that I
can think of with 3 or 4 standard plug-ins.
We build a portal with over 60 projects with 3 Maven plug-ins that come
out of the box.
Our application includes a few web service, lots of portlets, and some
standalone batch jobs and some library aggregation projects.
We use Nexus, Eclipse/STS and Subversion. as supporting tools.
We do not use CI which seems to be a lot more trouble than it is worth
and from the chatter here seems to encourage overly coupled application
design, bad QC and overly complex workflows but I might just be getting
the "worst CI practices" rather than good examples of CI "Best Practice".
For us, Maven's killed about 12,000 lines of ant legacy built up over a few
years, and also done a drive by on a couple of dozen ivy files, replacing
them with one medium size POM declaring dependency versions, a dozen small
ones declaring dependencies, and a bunch of minimal ones - all with NO
bespoke build instructions in. Using nexus has killed the need to maintain
an internal ivy repository which was a real pain in the rear, and we can now
easily share deliverables with the other couple of hundred developers we
have working in the same technologies around the globe. It's been very
painless by comparison to what we were doing before and well worth the
switchover.
Regards
Brian
We started with Maven so we did not have legacy stuff to get rid of.
This is a complex pom for us since it uses a plug-in to build an
executable jar and most do not so, so as Brian said, do not need a build
section at all.
To set up a new project, one only needs to change the artifact-id,
change the versions where needed and remove the entire <build/> section
if one is not building a standalone executable.
The POM for a webservice is only slightly different in that it has to
build the client library as well as the service endpoint.
This POM will include about 50 third party libraries(Hibernate, Spring,
Mysql, Apache Commons, CXF, etc.) plus the client side access to our
web services as well as the API and core libraries that provide access
to the database and utilities.
It is being built to run with most of the code being at 1.9.1 (current
approved versions of the third party libraries) but the lms-libraries
are at 1.11.1-SNAPSHOT to get the current development version of the
database APIs and implementation and utilities.
We are careful with upwards compatibility and build aggregation projects
for libraries to make it easier for project developers to get the
right/approved stuff without worrying about the details.
People do not deploy SNAPSHOTS to the Nexus archive without being
prepared to stand behind their testing of the SNAPSHOT and to take the
heat for deploying broken SNAPSHOTS.
<project xmlns="http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
<parent>
<artifactId>lms-pom-master</artifactId>
<groupId>com.xxx.com.lms</groupId>
<version>1.9.1</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>com.xxx.com.lms</groupId>
<artifactId>lms-contractrenew-batch</artifactId>
<packaging>jar</packaging>
<version>1.11.1-SNAPSHOT</version>
<name>Contract Auto Renew Application</name>
<description>Contract Auto Renew Application</description>
<prerequisites>
<maven>2.0.4</maven>
</prerequisites>
<build>
<sourceDirectory>src</sourceDirectory>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptors>
<descriptor>jar-with-dependencies-assembly.xml</descriptor>
</descriptors>
<archive>
<manifest>
<mainClass>com.xxx.lms.contractrenew.main.ContractRenewBatchMain</mainClass>
<packageName>com.xxx.lms.contractrenew.main</packageName>
</manifest>
<manifestEntries>
<mode>development</mode>
<url>${pom.url}</url>
</manifestEntries>
</archive>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>attached</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>com.xxx.com.lms</groupId>
<artifactId>lms-pom-lms-libraries</artifactId>
<version>1.11.1-SNAPSHOT</version>
<type>pom</type>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>com.xxx.lms</groupId>
<artifactId>lms-pom-spring-hibernate-mysql-tomcat</artifactId>
<version>${lms-project.version}</version>
<type>pom</type>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>com.xxx.lms</groupId>
<artifactId>lms-pom-shared</artifactId>
<version>${lms-project.version}</version>
<type>pom</type>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
On 15 October 2010 08:56,<[email protected]> wrote:
On Fri, Oct 15, 2010 3:00 am, Jason van Zyl wrote:
>> A fact to note though is that I've asked over 2k people over the last
two years at talks and in any average crowd the people who care to have a
different format or DSL is around 3%.
And I one of them :-) I always havent been a friend of XML and I happy to
see the possibilities maven3 offers (although I prefer using gradle -
bygones)
What I'm wondering most is - why the heck do you write to the maven
mailinglist how you dislike maven ? Is your intention to convince people
that they are doing bad stuff over the last xxx years ? Is it just pure
boredness ?
I dont like Ruby or Clojure - what is the reason to bother the ruby/clojure
mailing list that their syntax is apparently horrible ?
Sorry - I dont get it... If you dont like maven - dont use it... there are
tons of alternatives around.
Or what point do I miss here ?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
