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]
