Thiessen, Todd (Todd) wrote:
Interesting.
Much of what you say I think is already documented. For example the definitive
guide explains quite well that by convention Maven supports one artifact per
project. It also contains many if not most of the best practices that users
often ask on this list how to circumvent.
But I know what you are getting at. This best practices guide would be a short
summary of statements you find in books like the Definitive Guide, Better
Builds with Maven and many of the blogs on the Sonatype web site. But the guide
would need to at least reference why these practices are in fact best
practices. What are the consequences of not following a best practice?
In many cases, these explanations would be short but in others it wouldn't. This could
make the best practices document turn into a fairly large beast that just re-iterated
what is already in other documents. This duplication can be a pain to manage. As the
"true" documents change over time, the best practices document would have to
change also. Just one more document to update and keep in sync. Who will want to do that?
I would hope that the Best Pratices would link to other documents for
most of the details. There is no need to get too redundant in this day
of easy hyperlinks
I don't want to rain on your idea too much, since I think it does have a lot of
merit. However, I also am not fully bought into it.
As a final note, the best practices guide should NOT say what repository manager or SCM
one should use. That isn't a space I think Maven should get into. I think it is valid to
say that its a best practice that a repo manager is used, but to get into which one is
"best". Same with SCM. It also shouldn't say which which libraries to use.
Those can be completely different depending on the project.
I agree with this with the caviate that the Best Practice needs to be
specific about some things and I would want to have a paragraph
discussing the differences in the Best practice that is caused by
choosing one SCM over another. "If you use Eclipse and Subversion then
you need to do the following but if you use Git then you need to do this
other thing."
The specification of the use case also has an impact on the Best
Practice. If the use case is "We have a Subversion SCM and use Eclipse
STS as our IDE and do not have a Maven repository", it will be different
than "We are considering either Git or Subversion as our SCM and are
using Netbeans as or IDE". A lot will be the same in terms of strategy
but the details and reference links will be different.
There is a "s" in "Best Practices" for a reason.
It could perhaps list certain libraries and discuss the pros/cons of each, but
again, this can change over time and isn't really a best practice.
It also could perhaps state which SCMs Maven currently works with, which would help
someone looking into Maven to decide if they wanted to use it. But again, this kind of
information is hard to keep up to date and isn't really a "Best Practices"
thing.
This is the kind of info that a Best Practice links to rather than
documents.
-----Original Message-----
From: Ron Wheeler [mailto:[email protected]]
Sent: Thursday, March 18, 2010 3:55 PM
To: Maven Users List
Subject: Re: Dealing with artifacts that have been moved - What to do?
Wayne Fay wrote:
- unambiguous - no "you might do this or mayby that" just "if your
situation is this and you want the best development
environment do exactly this".
But notice some recent questions on the list...
- how to compile from multiple source directories
- migrating a large ant build to maven without any power to
reorg the
files/projects
- etc
It seems pretty rare that someone is looking for what you are
proposing to create...
My suspicion is that these are caused by not following the
"Best Practice" for Maven.
Under what circumstance would you recommend to a user that
they set up a project that required 2 source directories?
In the end, I suspect that they really have 2 (or more)
projects with 1 source directory each with dependencies between them.
Once they "Mavenize" their project structure, they will find
that they do not need these gymnastics.
Migration is always tough and may be one of the last "Best
Practices" to emerge.
Your suggestion, if I recall correctly was to not try to
Mavenize in the face of an entrenched Ant lobby until you had
established a high level buy-in. That in itself could be the
root of a "Best Practice" that is less about Maven technical
issues and more about how to plan and organize a large scale
methodology upgrade and how to justify the investment to
management and the rest of the team.
The fact that a number of people are not looking for the
right things is due to a certain extent to the power and
flexibility of Maven and the lack of a set of "Best Practices".
Maven is one of those tools that really needs a warning note
"Just because Maven can do it, does not mean that you should do it."
How many Maven project structures and development
methodologies are radically different but equally recommended
can you come up with for a small team of less than 5
developers that are developing a webapp in Java with Spring
on Eclipse or Netbeans for deployment on Tomcat, Glassfish or
Websphere?
How difficult would it be to get a consensus on which one of
your suggestions is the "best".
How hard would it be to get agreement on what is the criteria
for "best".
Just for a starting point, in my opinion, the best practice
for the above situation would suggest that the project needs
a subversion repository, a Nexus community version
repository, the Spring STS version of Eclipse, a master POM
for the project, a set of library POMs for the shared code
and utilities, and a single project POM to build the WAR
file. Lots of details to flesh out but they would fit on 1
page with a few pages of POMs, settings and misc. xml samples
attached.
How many variants would that "Best Practice" need to satisfy
90% of the target use cases.
Ron
PS- Who is producing and assuming ongoing responsibility
for this BPG?
The community.
Sounds like the Maven User Wiki is a fine place to start. I started
the document [1] for "the community" to add/edit as it deems useful.
[1]
http://docs.codehaus.org/display/MAVENUSER/Maven+Best+Practice+Guide
Wayne
---------------------------------------------------------------------
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]
