maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <>
Subject Re: Unpacking jars into target/classes
Date Thu, 07 Mar 2013 13:28:46 GMT
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 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 
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 
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.


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<
>> 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:
> For additional commands, e-mail:

Ron Wheeler
Artifact Software Inc
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message