Tens of thousands of developers use Maven every day.
They like the way that it works now and don't want it to change.
They build all kinds of projects - big ones, little ones, ones with lots
of third party dependencies and lots with just a few.
We have an LMS that we built with Maven - it has over 80 projects that
make up the artifacts required to provide all the functionality.
It leverages Spring, Hibernate, MySQL, JasperReports, CXF and Axis, JSF
and a few more outside technologies.
We have our virtual meeting registration portal takeawebinar.com that is
smaller with a similar set of technologies.
Our ADTransform only has 7 projects with JCR as its persistence
architecture but it includes the manual which is written using DITA and
assembled using a Maven plug-in that controls the Open-DITA tool kit.
I am also using Maven to assemble the study report that I am doing about
how to modernize the delivery of training to police management and
technical staff which is also being done in DITA.
Lots of people use Eclipse.
We use Eclipse/STS from Springsource since it gives us everything that
we need in one download.
I am currently using the latest Eclipse Juno M2 with the Springsource
Tool Kit added because there was a serious bug the the last Eclipse
release with XML and DITA is all XML. Springsource will only release a
new version when Eclipse releases the patched release this month.
I am the only one affected by this at Artifact.
We NEVER EVER use Maven from the command line.
Maven sits quietly in the background doing our builds without any fuss
or bother just by right-clicking on the POM and selecting the correct
option off the Run As menu
For a new person to modify a project, they only have to use Eclipse to
checkout the project, modify the code they want to changes, click on the
pom to build it, and run the tests and then synchronize to update their
changes in the SCM.
They do not need any other projects other than the one that they are
working on. No interproject dependencies are resolved within the Eclipse
workspace.
If they need to fix a module and a dependent library, they need to build
the dependent library first and at least "install" it.
Maven is not a deployment tool and we will probably use an installer
(izPack looks good) with Ant to build installers for the supported
architectures and configurations for ADTransform.
The other portals are hosted by us so we just copy the jars and wars
when we need to make a change.
Embarrassingly low tech!!! We only release new versions very
infrequently and bugs usually involve a single war file so it is not top
of mind at this point.
We have Nexus and in our 3rd party library repo, we have 8 artifacts
that are not available in Maven Central for various reasons(licensing,
unreleased versions, not mavenized, etc.).
We had to download them and manually install them in the repo.
We do not offer any artifacts from our repo to the public.
We have tried to explain Maven best practices and I believe that I
offered to show you how we use Eclipse.
The other people in this thread are the best Maven experts around . I am
just a keen user of Maven.
Maven is like a very large ocean liner and it will change direction very
slowly.
Paddling your canoe out in front and yelling "Turn, turn turn." at the
top of your lungs will only get you run over.
We are all on board and are yelling that you need to buy the ticket and
get on board where you will be warm and dry with a nice view or that you
should find another place to paddle.
Sitting where you are, is not going to make you happy and the good ship
Maven with it thousands of passengers is not going to turn in time to
save you.
Ron
On 07/03/2013 5:37 AM, Joachim Durchholz wrote:
Am 07.03.2013 10:00, schrieb Jörg Schaible:
Hi,
Joachim Durchholz wrote:
Am 07.03.2013 05:51, schrieb Matthew Adams:
Quick jist:
1. Use maven-install-plugin's
install-file<http://maven.apache.org/plugins/maven-install-
plugin/install-file-mojo.html>goal
to make maven artifacts out of the jars you intend to unpack, and do
it in any phase prior to process-classes (or do this first in the
process-classes phase).
The overall organisational project structure does not allow any central
servers beyond the SCM.
It would also be silly to redundantly store a perfectly stable jar in a
Maven repo just to make Maven happy.
But that's the point: Maven is all about conventions. It will not
help you a
lot in other regards - on purpose.
So if a tool doesn't what it should, that's just on purpose? Come on.
Oh, and conventions are useless unless applied to some domain, and
Maven does indeed have domains (dependency management, builds, build
stability).
Sorry to sound harsh, but "it's on purpose" is just a cheap cop-out.
> If you don't want to follow this
conventions, it is probably no the right tool for your job.
I claim that Maven's stance of essentially requiring a repository
manager needlessly complicates the build infrastructure.
Regards,
Jo
P.S.: Not that discussing Maven's philosophy helps my original problem
in any way... essentially you're saying "Maven can't do that and
that's okay", and I say "if Maven can't do that by design, then the
design of Maven is broken".
You consider my position baseless because, from your perspective, I
want the undesirable; I consider your position baseless because you're
putting some very abstract theory about what's desirable ahead of very
concrete and practical needs, and I consider theory useless if it
doesn't cover all bases.
Given that situation, I don't think it's going to be very fruitful to
discuss Maven's philosophy.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
