Justin Edelson wrote:
On 3/18/10 3:55 PM, Ron Wheeler wrote:
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.
But in neither of these cases was the question "should I be doing this?"
It was "I need to do this. Tell me how do I do it."
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.
Except that Wayne's wrong about this :) Management buy-in doesn't mean shit.
Thats why it might take a long time to come to a consensus. That should
not stop work on other use cases.
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".
I don't agree that this is what's going on here.
You could be right. I am reading in a bit into the reason that someone
would need 2 source directories in a POM.
There was not much detail given as to why but I have never seen any of
the more experience folks here recommend that as a solution to any
development strategy issue.
I am jumping to the conclusion that they really have 2 projects and so on.
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."
Seriously?
Yes. Very.
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.
But IMHO you should be using Git instead of Subversion and STS doesn't
have enough management tools to support a large-scale rollout. Are we
actually going to be able to reach consensus on those things?
I would have no objection to the inclusion of Git in this "Best
Practice". I have not used it but I have heard good things about it.
I am not sure that a 5 man team would be doing a large roll out.
There would have to be another Best Practice for that.
I am sure that this "Best Practice" could also be extended to include
the use of other IDEs without seriously affecting the methodology.
It might require one or 2 pages of addenda to cover minor setup changes
but I suspect that it would not affect the POM structure at all.
In all seriousness, you should publish this as "Ron's Best Practices".
If you put something up on Lulu or whatever, I would read it and I would
probably recommend it to others. There isn't enough documentation about
Maven; I just don't think the community can produce the type of
documentation you're describing.
Justin
"Ron's Best Practices" would have to be "Ron's Best Practice"
I can only make suggestion about what I have learned in my own
experience. I have not done a large scale roll-out. I have a small team.
For example, I do not need many of the features of Nexus Professional
but that does not mean that some of the people starting out with there
first project will not have a larger team and a more demanding
management structure,
I am not even sure if I am doing everything properly with Maven and
Eclipse yet.
I am sure that a lot of the people in this forum could walk into my
office and improve things a lot, with ideas and tools that I don't even
know about.
It is that expertise that I would like to see captured in a "Best
Practices" set so that the next guys don't take 2 years to get where I
am, spending time cleaning up POMs and libraries that could have been
done much better when we started with Maven, if only someone had laid it
out clearly.
Our builds worked but we did not get a lot of the advantages and control
that we have now.
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]
