Hi Hugo, > On 23-Oct-2014, at 3:03 pm, Hugo Trippaers <h...@trippaers.nl> wrote: > > Snapshots are an integral part of maven building the project. A snapshot is > mavens way of telling that a particular release is still in development and > causes different behavior in how it resolves artifacts. For a developer > working only local the problem could be minimal and in case of problems he > could wipe his .m2 directory. However for people using centralized maven > repositories it could cause unintended behavior if snapshot is dropped as > maven states that repositories should never replace an artifact that is > pushed as a release artifact (without -SNAPSHOT).
What you’ve shared would only apply for reusable artifacts such as library packages. AFAIK none of the CloudStack artifacts are shipped as libraries or consumed by other JVM based apps (at least no public use-case known yet). It’s only CloudStack’s submodules or plugin that consume other CloudStack artifacts such as cloud-api or cloud-utils are practically used by all other CloudStack modules. > The net result of this could be that developers are recompiling a build, but > actually running/testing a completely different version because the > repository was not refreshed because a release version already exists. I > would propose to keep the -SNAPSHOT until we have a version that we actually > want to release to the public. Personally i would even be in favor of naming > a RC something like 4.4.99-SNAPSHOT until we push the final build, but that > would interfere with the way we sign and mark releases. For developers - you’re right, that you may be compiling/running with different jars. But, then again if we keep -SNAPSHOT, as branches change often with bugfixes etc we don’t really rely on any central maven repository because the same logic applies there (the installed -SNAPSHOT jar differs from the one in the maven repo etc). This is why we do a clean install when building, for example in j.bac.o or locally when we build a mvn clean install is most common way of building CloudStack AFAIK. For users - AFAIK, there is no public use-case where someone’s installing the jar artifacts from (any central/public) Maven repository. CloudStack is most commonly shipped as APT/YUM repository and consumed. Other than this I know CCP ships as a tarball containing debs/rpms with a install.sh script. Comment, advise? With the above cases, do you think it is unnecessary to keep -SNAPSHOT in pom.xmls? Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
