cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nate Gordon <>
Subject Re: [PROPOSAL] Remove SNAPSHOT from versioning and keep tags on the release branch
Date Mon, 27 Oct 2014 16:14:33 GMT
Sorry for not responding sooner, I took a few days off to lay 300 sqft of

I have a local Artifactory server that I'm publishing to based on builds
that are triggered from key branches in the ACS repo. I'm not using
something that is publicly available. For CCP, it is primarily the same
codebase, so we rely on that to have a single version of our plugins that
works for both.

For the reasons why dropping -SNAPSHOT is desired, I don't see git history
divergence being an actual problem. Every maven project has this exact
setup. The deb/rpm issue is more valid, but I feel is a solvable problem
without dropping -SNAPSHOT.

On Fri, Oct 24, 2014 at 12:29 AM, Rohit Yadav <>

> Hi Nate,
> > On 24-Oct-2014, at 2:28 am, Nate Gordon <> wrote:
> >
> > The jars are used when developing plugins outside of the core repo. My
> > company develops plugins which are self contained jars for our customers.
> > We do this without modifying the core code so that we aren't forking ACS
> in
> > the process and to support CCP.
> Interesting use-case, how do you get the jars? From which maven repository?
> Of the main sources of publicly published jars, I cannot find any
> CloudStack projects or jars (for all official releases);
> In case of ACS, how do you get the jars if you’re not using a published
> repo and extracting jars from it?
> In case of CCP, they are not opensource (or that their changes/interfaces
> are documented) or publish jars on a some maven repository (not to mention
> they use the same artifact ID etc), so the only way to get CCP’s jars is to
> get a package tarball, extract the debs/rpms and get the jars.
> If in future we decide to do something like publish jars on a public maven
> repository for GA releases, then we can consider adding -SNAPSHOT otherwise
> I would encourage pragmatism over a pedantic approach. By not keeping
> -SNAPSHOT, we reduce the git history divergence and deb/rpm build issues we
> see too often.
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +91 88 262 30892 |
> Blog: | Twitter: @_bhaisaab
> Find out more about ShapeBlue and our range of CloudStack related services
> IaaS Cloud Design & Build<
> CSForge – rapid IaaS deployment framework<>
> CloudStack Consulting<>
> CloudStack Infrastructure Support<
> CloudStack Bootcamp Training Courses<
> 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.


*Nate Gordon*Director of Technology | Appcore - the business of cloud

Office +1.800.735.7104  |  Direct +1.515.612.7787  |


The information in this message is intended for the named recipients only.
It may contain information that is privileged, confidential or otherwise
protected from disclosure. If you are not the intended recipient, you are
hereby notified that any disclosure, copying, distribution, or the taking
of any action in reliance on the contents of this message is strictly
prohibited. If you have received this e-mail in error, do not print it or
disseminate it or its contents. In such event, please notify the sender by
return e-mail and delete the e-mail file immediately thereafter. Thank you.

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