maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Gudian <andreas.gud...@gmail.com>
Subject Re: Unpacking jars into target/classes
Date Thu, 07 Mar 2013 12:05:48 GMT
Am Donnerstag, 7. März 2013 schrieb Joachim Durchholz :

> Warning: Just philosophy here.
> I AM trying to restrict myself to things I haven't said before. Some
> amount of repetition is inevitable, and this kind of discussion is nearing
> the point of diminishing returns, so I'm trying to cut down on this kind of
> discussion.
>
> Am 07.03.2013 10:57, schrieb Baptiste MATHUS:
>
>> I'm having a hard time understanding why you keep being unwilling to use
>> Maven conventions but keep using it at the same time.
>>
>
> Hello? Because it has been advertised to me as "THE build tool that will
> solve my problems"? And maybe because switching build tool in mid-flight is
> a daunting task?
>
> I'm here because I'm locked in, not because I think Maven is great.
>
>  Maven is the opinionated build tool. Using its conventions is almost
>> compulsory. Maven is all about conventions and making build standard
>> across
>> projects.
>>
>
> Problem with Maven is that its conventions are too restrictive. Maven
> works well as long as you are 100% inside its mental model of how a build
> should be set up; the problem is that as soon as you (need to) work outside
> that box, Maven will break down, horribly.
> Overly terse documentation makes it worse because that makes it hard to
> decide whether the reason for some problem is because some option wasn't
> properly set, or whether the plugin simply can't do what one wants. That's
> making for a lot of frustrating dead-end exploration.
>
>  If you want full scripting features and design the build the exact way you
>> want,
>>
>
> That's not really what I want.
> I want a declarative specification so the tool can decide what build steps
> to run.
> I want full scripting only for the individual build steps. This probably
> means an obligation to specify the declarative metadata so the tool can set
> up its build plan. Plus this probably also means that people will need a
> way to test whether their metadata are correct, since otherwise people will
> get subtle errors into the build plan.


Then the ant-plugin should help you. Eclipse might have a harder time in
that case, though.



>
> I also want Eclipse integration, so build configuration doesn't need to be
> specified redundantly.
> This is usually done via a plugin that configures Eclipse projects,
> restricting further what can and what cannot work as build script (or
> requires another layer of metadata so the plugin knows what to do; m2e's
> lifecycle mapping complications are a good example how complicated this
> problem is.)
> (Substitute the IDE of your choice for Eclipse if you want.)
>
> > then have a look at gradle. Or ant+ivy might make you happy.
>
> I'm not sure whether Gradle fits the bill. Given the complexities
> involved, there's a high risk that it won't.
> There's also that advice for any tool is invariably biased, so I also risk
> acting on inappropriate advice. I've been bitten by this time after time,
> Maven is just the last
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message