Early Access Program (EAP) for Bamboo Server and Data Center 9.0 platform release, that we have previously informed you about, is now available. You can download the binaries here.
This Early Access Program release contains the full scope of breaking changes in Bamboo 9.0. Please find all of them listed here.
Thanks for the info! @MartynaWojtas
Was removing this method on purpose? (9.0.0-rc1)
value getRuntimeArtifactIds is not a member of object com.atlassian.bamboo.plugin.ArtifactDownloaderTaskConfigurationHelper
What should be used instead?
Thanks, Markus
Yes, it is intentional change. We have modified the ArtifactDefinition object to support multiple copy patterns and coding artifact transfer data as map of strings wasnât maintainable to begin with. You should now use RequestedArtifacts object instead.
Hereâs an example of plugin change: atlassian / bamboo-scp-plugin / commit / 5f9124c525b1 â Bitbucket
Thanks a lot for the quick response and the example. 
Will check it.
@mgardias - can you clarify the involved version range(s) for this change, i.e. from which version onward can we use the new RequstedArtifacts object approach?
Itâs only available in 9.0
Let me add some more background to this: in 9.0 we are adding a feature to have multiple copy patterns as well as exclusion patterns in ArtifactDefinition. This requires that new data to be represented in runtime data of ArtifactDownloaderTask. This used to be done as Map<String, String>, which is brittle and error prone. Keeping the old âAPIâ could result is unexpected behaviour as the underlying data would change but Map<String, String> is still a Map<String, String>.
Having that in mind I decided to change the way we transfer this data into more future-proof and maintainable way: using actual objects. That unfortunately means breaking backward compatibility, but, as I wrote above, backward compatibility would be questionable anyway if we kept the old API and one could easily miss the change at compile time.
Thanks for the explanation.
Is that change documented somewhere?
Has Bamboo something similar to: https://developer.atlassian.com/server/bitbucket/reference/api-changelog/?
That would be very helpful for app developers.
Thatâs helpful feedback - thank you! Weâve added the information about this change to this document, so all the important information on 9.0 is in one place: Preparing for Bamboo 9.0 | Bamboo Data Center and Server 9.1 | Atlassian Documentation
That is fully understandable, though it implies that we have to either add some OSGi/reflection âmagicâ to our app, or switch to building and shipping separate binaries for the 8.x/9.x Bamboo targets.
There is no problem doing that in principle, and we have done both in the past for different apps - however, it would be nice to have some more prominent warning and a bit more lead time for such breaking changes in the future (even now, the information added for this to Preparing for Bamboo 9.0 reads more like a ânew/extended featureâ to adapt to and does not exactly emphasize the breaking nature of this change).
Thank you for your feedback! We will adjust the documentation to make sure the breaking nature of this change is highlighted. One of the reasons we do EAPs is that we can never be 100% sure about the nature and impact of certain changes. This one, theoretically, shouldnât have been breaking as it wasnât technically an API change. However, it turned out that in practice it was a breaking change. And I donât mean it as an excuse, because I wholeheartedly agree that we should always try to improve our process in order to deliver best quality (be it product or its documentation). Itâs just that certain problems are not obvious and this was one of them. If that would be helpful we could extend the EAP duration for the next platform release.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.