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. So while Apache doesn't ship shared library jars for ACS, there are those of use who do use them in that manner through our own repositories. It has also been discussed in the past that it would be beneficial to have API jars that are publicly downloadable for the specific purpose of building plugins without having to have a local build of ACS.
I also second Hugo's comments. I'm not a maven user in my day job (woot gradle!), and he has done a far better job than I articulating the difficulties encountered with maven and dropping the -SNAPSHOT identifier. There is a very real possibility of accidentally building ACS with mixed code and having a very hard time figuring out why something doesn't work. It is even more dangerous with the final release builds potentially getting non-release code by way of the build system. If non-GA releases will still get some identifier in the rpm/deb package naming, why do something different than -SNAPSHOT?. It seems like we are throwing out the baby with the bath water. So again, I only say -1 on this because I'm willing to put the effort in to make this work how we would like it to while still maintaining the -SNAPSHOT concept. But to do that I need a better description of what doesn't work today. If someone gives me detailed notes, a JIRA issue, diagrams on a paper airplane, I'll commit the time to fix it. I've spent a lot of quality time in the deep dark bowels of rpm specs and build engineering. I'm sure it can be done. Thanks, -Nate On Thu, Oct 23, 2014 at 5:16 AM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > 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. > -- *Nate Gordon*Director of Technology | Appcore - the business of cloud computing® Office +1.800.735.7104 | Direct +1.515.612.7787 nate.gor...@appcore.com | www.appcore.com ---------------------------------------------------------------------- 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.
