Re: [jboss-dev] Why Maven sucks (part 1)
Adrian Brock wrote:
On Mon, 2008-04-21 at 13:47 -0500, Paul Gier wrote:
> Carlo de Wolf wrote:
>> Paul Gier wrote:
>>> Carlo de Wolf wrote:
>>>
>>>> Now if it was a tool focussed on dependency management (like Ivy) it
>>>> would have solved the real problem: snapshots. So let's do an
example:
>>>> - as trunk -> ejb3-core-0.1-SNAPSHOT ->
>>>> ejb3-interceptors-0.13-0-SNAPSHOT -> aop-2.1-SNAPSHOT (for the
example)
>>>> If I happen to deploy a new snapshot of aop, it'll break AS build.
>>>> Why: ejb3-core is not compatible and Maven blindly loads it up. This
>>>> is not possible in Ivy, it's snapshot repository looks like:
>>>> - as trunk -> ejb3-core-0.1-20080421 ->
>>>> ejb3-interceptors-0.13.0-20080421 -> aop-2.1-20080420.
>>>> If I happen to deploy a new snapshot of aop you get and I run a
>>>> nightly build on ejb3 you get:
>>>> - as trunk -> ejb3-core-0.1-20080421 ->
>>>> ejb3-interceptors-0.13.0-20080421 -> aop-2.1-20080420
>>>> - ejb3-interceptors-0.13-0-20080422 -> aop-2.1-20080422
>>>> Since ejb3-core didn't properly build there is no new snapshot for it
>>>> and AS build is unaffected.
>>>> Combine this with unit tests and you got a pretty stable setup.
>>>>
>>> We can do this using maven also. If you want to tie the build to a
>>> specific snapshot, just put the full snapshot version in the
>>> dependency. So for example, ejb3-interceptors you could put version
>>> "0.13.0-20080417.210958-18". And maven will keep using that
snapshot
>>> build until you change the dependency. The -SNAPSHOT convention is
>>> just for convenience if you just want to build with the latest until a
>>> release comes out.
>> It must be automated. Whenever someone does a mvn deploy, the pom.xml
>> should be replaced by one not containing any snapshots, but only full
>> versions.
>>
> Just so it's clear what you are asking for, you want dependencies with
> (-SNAPSHOT) to be replaced with the specific snapshot version (-timstamp-build)
> during deployment? I could probably add this as an option to the deploy plugin,
> but I don't know if this would solve the problem.
>
It wouldn't. The whole point of getting rid of snapshots is so you can
reproduce the build with a tagged release.
My mistake, we're mixing two issues here:
- stability of the build
- reproducibility of the build
I completely agree that any real release must be reproducible, but is it
feasible to do release for every little nitbit? I say no.
People need to stop being lazy and create proper releases.
SNAPSHOTS are only useful when you want to know whether a new release
will work another project.
e.g. before I release the next version of jboss-vfs, I create a SNAPSHOT
in my *local* repository and update the jbossas build to use it.
If it works, I do a proper release (NOT a mvn deploy of the SNAPSHOT)
for others to use.
That's really bad. So if it works on your machine, it's gold? (We know
it is, but that's not good enough on my machine. ;-) )
We must have a stable integration build on a QA machine before we can
declare something releasable.
Also I can't wait for confirmation of integration because it takes 12+
hours to run the suites necessary. So whenever a component passes it's
unit tests, it's ready for integration and we should push it in the repo.
The real question is how can we get a stable integration build. Suppose
we were to use version ranges:
- as trunk
-> ejb3-core-[1.0,2.0) -> ejb3-interceptor-[1.0,2.0) -> aop-[1.0,2.0)
-> aop-[1.0,2.0)
The repository should be (reproducible):
- ejb3-core-1.0-1 -> ejb3-interceptors-1.0-1 -> aop-1.0-1
Now we get aop-1.1, we (automatically) run integration builds, ejb3-core
fails and we get:
- ejb3-core-1.0-1 -> ejb3-interceptors-1.0-1 -> aop-1.0-1
- ejb3-interceptors-1.0-2 -> aop-1.1-1
Now what should AS trunk build look like. According to Maven:
- as trunk
- ejb3-core-1.0-1 -> ejb3-interceptors-1.0-1 -> aop-1.0-1
- aop-1.1-1
Clearly this will break, because we've spotted regression in ejb3-core.
So it should be:
- as trunk
- ejb3-core-1.0-1 -> ejb3-interceptors-1.0-1 -> aop-1.0-1
- aop-1.0-1
with a nice friendly warning message that aop-1.1-1 has been held back,
because of ejb3-core (or it should fail outright).
Carlo