It does seem that you are describing the way SNAPSHOTS work.
Can you identify any particular problem in your environment that
prevents you from working according to the Best Practices that thousands
of organizations are following?
I can not see from anything that you have described so far that is abnormal.
We have 70 projects that make up a large LMS and it depends on 60+ third
party libraries and most of the war files include dependencies on our
utilities and web services.
We do not use CI but dozens of regulars here do and can help make that
work correctly.
Can you give a short description of the issues that made you abandon
SNAPSHOTS?
Ron
On 01/02/2011 9:22 AM, Mate Varga wrote:
What assumptions do I break except the immutability of an artifact with a
specific version? (Which is only broken locally, and mvn should not really
know about it, and it should not affect anything as mvn does not copy local
artifacts anywhere.)
Well, then the easiest thing is to explain what I'd like to do -- and maybe
there's some other way to achieve it.
(let's assume we have 3 projects, A, B, C,D; A depends on B, B depends on C
and A depends on D
- we don't have major / minor versions at all -- we do not want and we do
not need a separate release procedure. Every successful CI build is
considered to be a new version. Obviously, successful CI builds should be
handled as snapshots, but if project B has been successfully built in the
CI, then each following build of A should be using that version. Therefore
the version numbers should be incremented automatically (CI build number
could be used for that)
- developers should be able to modify and build project B locally, and then
modify and build A (and A should use B which was built locally)
Currently, what I do is
- have two profiles, a 'local' and a 'CI', which are activated automatically
depending on the environment
- after successful CI builds, artifacts are deployed to the repo manager
(this works perfectly)
- locally built artifacts have version no. 99999999
- if an internal project references another internal project, then it refers
to its 'LATEST' version
Are there other ways to achieve similar results? Please do not criticize the
way we do releases, as this is 'given', and it's the result of the
environment we work in. We cannot have major/minor releases, nor can we
manually version each release. I'd be very happy if there were a proper way
to do what we're doing in a bit hacky way now.
Thanks,
Mate
On Tue, Feb 1, 2011 at 1:22 PM, Stephen Connolly<
[email protected]> wrote:
ugh this is just so wrong I don't know where to start.
please consider using SNAPSHOTS as they are the correct way
LATEST and RELEASE do not mean what you think they mean, and they have been
deprecated. their use is no longer supported.
maven makes assumptions about non-SNAPSHOT versions which you are breaking
behind its back.
there be dragons here
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 1 Feb 2011 11:13, "Mate Varga"<[email protected]> wrote:
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
