On 21/09/2010 6:51 AM, Michael McCallum wrote:
On Monday 20 September 2010 21:50:30 Perez Ronen wrote:
1) Do you agree with me that the SNAPSHOT way is better?
No you can achieve the same and more with releases and version ranges.
2) Can you give your reasons of why this is better?
When integrating artifacts against a snapshot its meaningless just like giving
a tester snapshots is meaningless the result is not deterministic.
By specifying a range you are defining a constrained but flexible relationship
which can be checked.
For example this works fine
War 1 depends on B 1.1-SNAPSHOT and C 1.1-SNAPSHOT
B depends on A 1.1-SNAPSHOT
C depends on A 1.1-SNAPSHOT
But what if you have many wars
War 2 depends on B 2.1-SNAPSHOT and C 3.1-SNAPSHOT
B 2.1-SNAPSHOT depends on A 2.1-SNAPSHOT
C 3.1-SNAPSHOT depends on A 3.1-SNAPSHOT
might give you 3.1-SNAPSHOT or 2.1-SNAPSHOT
when really it should be an error.
I use
War 2 depends on B [2,3) and C [3,4)
with B 2.1-SNAPSHOT depends on A [2,3)
and C 3.1-SNAPSHOT depends on A [3,4)
gives you a conflict someone tried to merge 2 incompatible versions of A i.e.
line 2 and line 3.
I'm not sure why more people don't suffer these headaches, maybe they don't
have large enough projects or enough deliverables. Most of the projects I work
on delivery several wars with many shared artifacts.
We have 60 projects that make up a portal application with 30+ WARs.
We carefully manage dependencies so that if a third party library ABC
depends on log4j 1.0.1 and another DEF depends on log4j 1.1 we exclude
the log4j in our dependency of ABC and DEF and create a master library
JAR that includes the log4j version 1.1.1 so that we know that we are
only using version 1.1.1 and make ABC and DEF depend on our library.
This also moves the choice of library out of the hands of individual
programmers and makes it a team responsibility.
We have about 10+ library JARS to group third party libraries and our
own shared utilities.
If thats not enough consider, one of the biggest hassles I used to have on
projects was people checking in broken code, that would stop other developers
from working. With snapshot dependencies you have exactly the same problem but
worse as you don't need to update or you do. Finding a stable combination of
snapshots and updated working copies is hard and prone to error.
We do not encourage people to deploy broken artifacts into the
repository as SNAPSHOTS.
They can commit to the SVN repo but not deploy to Nexus.
No artifacts are built using libraries from the SVN except the one that
you are working on.
If you require that a developer release artifacts before you see their changes
1) if it breaks you just change your deps to use the previous version till they
fix it
2) people are not afraid to commit code as someone has to release an artifact
before its shared
3) continuous integration tools can check the head to head and head to latest
releases for each artifact
This goes away.
To steal from John von Neumann "Anyone who uses Maven without a
repository is in a state of sin".
Ron
Thanks,
Ronen.
________________________________
"This e-mail message may contain confidential, commercial or privileged information
that constitutes proprietary information of Comverse Technology or its subsidiaries. If
you are not the intended recipient of this message, you are hereby notified that any
review, use or distribution of this information is absolutely prohibited and we request
that you delete all copies and contact us by e-mailing to: [email protected]. Thank
You."
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
