Oh yes, and for option 2 you don't really want to put the team namespace in the
group part, otherwise tools like Gradle won't tell you if you're using two
different packages of, say, boost; and then you may end up with DLLs being
overwritten at deploy time.
Hugh Greene, Senior Software Developer
Toshiba Medical Visualization Systems Europe, Ltd
Bonnington Bond, 2 Anderson Place, Edinburgh EH6 5NP, UK
Tel + 44 (0)131 472 4792 / Fax + 44 (0) 131 472 4799
http://www.tmvse.com / mailto:hgre...@tmvse.com
DISCLAIMER
Unless indicated otherwise, the information contained in this message is
privileged and confidential, and is intended only for the use of the
addressee(s) named above and others who have been specifically authorized to
receive it. If you are not the intended recipient, you are hereby notified that
any dissemination, distribution or copying of this message and/or attachments
is strictly prohibited. The company accepts no liability for any damage caused
by any virus transmitted by this email. Furthermore, the company does not
warrant a proper and complete transmission of this information, nor does it
accept liability for any delays. If you have received this message in error,
please contact the sender and delete the message.
From: Greene, Hugh [mailto:hgre...@tmvse.com]
Sent: 07 June 2016 18:04
To: artifactory-users@lists.sourceforge.net
Subject: [Artifactory-users] (Re-)Packaging third-party files, and avoiding
name clashes between teams
Hi all,
I'm looking for any opinions or experience on how to deal with an issue about
organising multiple teams which may be packaging and publishing third-party
modules into Artifactory.
We use Artifactory for C++ projects as well as Java-land projects. For those,
we publish and consume zipped pre-built binaries of various packages, from our
own company, other companies in the same group, and third parties. There's no
suitable public repo of pre-built C++ modules, really, which is why we package
them up for our own use.
At some sites, each team is free to package up and publish whatever they like,
and promote it into a shared repo when they're ready to release something which
depends on it. For example, someone might make a module with coordinate
"org.boost:boost:1.2.3".
Currently, there's nothing to stop multiple teams making different packagings
of the same module, and publishing them to different repos with the same module
coordinate. We would only find out about the clash when some team tried to
promote their module version and found they couldn't overwrite what was there.
This isn't a problem for teams' own modules, because they'll be namespaced
appropriately. So far we've avoided problems with good communication, but I'd
like something more reliable.
I have two possible ideas, neither great, so I'm looking for other ideas.
1. Some kind of central control software, e.g., you have to pre-register a
module coordinate and you get a one-use token to publish it, with Artifactory
plugins enforcing that. This sounds unwieldy and expensive.
2. Just add the team namespace into the module group or - perhaps more
usefully - into the module version (so that you'll find out if two teams are
using a different packaging of the same thing ... assuming they used the same
"group:name" string ...).
Thoughts gratefully received :-)
Hugh Greene, Senior Software Developer
Toshiba Medical Visualization Systems Europe, Ltd
Bonnington Bond, 2 Anderson Place, Edinburgh EH6 5NP, UK
Tel + 44 (0)131 472 4792 / Fax + 44 (0) 131 472 4799
http://www.tmvse.com / mailto:hgre...@tmvse.com
DISCLAIMER
Unless indicated otherwise, the information contained in this message is
privileged and confidential, and is intended only for the use of the
addressee(s) named above and others who have been specifically authorized to
receive it. If you are not the intended recipient, you are hereby notified that
any dissemination, distribution or copying of this message and/or attachments
is strictly prohibited. The company accepts no liability for any damage caused
by any virus transmitted by this email. Furthermore, the company does not
warrant a proper and complete transmission of this information, nor does it
accept liability for any delays. If you have received this message in error,
please contact the sender and delete the message.
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Artifactory-users mailing list
Artifactory-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/artifactory-users
