(Re-)Packaging third-party files, and avoiding name clashes between teams

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

(Re-)Packaging third-party files, and avoiding name clashes between teams

HughG_TMVSE

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 / [hidden email]

 

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
______________________________________________________________________

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
Reply | Threaded
Open this post in threaded view
|

Re: (Re-)Packaging third-party files, and avoiding name clashes between teams

HughG_TMVSE

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 / [hidden email]

 

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:[hidden email]]
Sent: 07 June 2016 18:04
To: [hidden email]
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 / [hidden email]

 

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users