For two Bintray packages, we're publishing multiple artifacts in:
com.criteo.mediation.mopub:criteo-adapter and com.criteo.mediation.mopub:criteo-adapter-development for https://dl.bintray.com/criteo/mobile/com/criteo/mediation/mopub/
com.criteo.mediation.google:criteo-adapter and com.criteo.mediation.google:criteo-adapter-development for https://dl.bintray.com/criteo/mobile/com/criteo/mediation/google/
But only the two criteo-adapter-developmentartifacts are synchronized on JCenter:
https://jcenter.bintray.com/com/criteo/mediation/mopub/
https://jcenter.bintray.com/com/criteo/mediation/google/
The expectation is to get all artifacts to be synchronized.
We have another package with a similar setup that is working well currently: https://jcenter.bintray.com/com/criteo/publisher/
I saw other similar issues on SO such as Bintray does not sync one of the artifacts of the package to the jcenter, but unfortunately, there seems that we cannot take any action except posting a new SO question.
Please note that when you submit a JCenter inclusion request for a particular package, all the artifactIDs present under the groupID will be included in the JCenter. If you add additional artifactIDs under the groupID , which is already linked to JCenter , those artifactIDs will not be mirrored in JCenter because JCenter hosts Single path for a single package.
In your case for the package "publisher-sdk-mopub-adapters", there are two artifactIDs under the groupID com/criteo/mediation/mopub
criteo-adapter
criteo-adapter-development
Only the first artifactID criteo-adapter-development is included in JCenter, In order to add the other artifactID, create a new Bintray package and include all the files under the path GroupID+ artifactID i.e com/criteo/mediation/mopub/criteo-adapter-development so that the package will be hosted in JCenter under the path https://jcenter.bintray.com/com/criteo/mediation/mopub/
Related
Every example I've seen for Jenkins shared library setup on the web is based on Git/GitHub.
Can anyone help me with that using Subversion?
I've struggled a lot but could not figure out what should be specified as the Default version.
I've tried many different combinations of Project Repository Base, Include branches, Library Name and Default version but none worked.
Attached is the screenshot of my SVN repository setup. I know it's not as per the standards though, it should work somehow as it's just a demo project.
if your lib svn path is https://192.168.1.1:8443/svn/trunk/JenkinsLib, then Project Repository Base will be https://192.168.1.1:8443/svn/trunk/ and Default version is JenkinsLib.
While setting up the shared library in Configure System --> Global Pipeline libraries select Retrival Methond : Morden SCM and Source Code Management : Subversion like below picture :
and When you select Subversion it will ask you to choose subversion specific branching name like below:
I didn't want to tag a specific branch in SVN, so I just used a period (i.e. '.') in the DEFAULT VERSION field and that takes that HEAD of the repo.
The project repo base is just the svn:// path to your repo.
I hope that helps.
We have a maven package published to Bintray and linked to Jcenter.
In version 1.1.0 we've added a new artifact to the package: koptional-reactor-extensions, and uploaded release to Bintray.
All the artifacts are visible on Bintray without problems: https://dl.bintray.com/gojuno/maven/com/gojuno/koptional/
However Jcenter only shows artifacts that were already published and does not show koptional-reactor-extensions: https://jcenter.bintray.com/com/gojuno/koptional/
Neither Bintray's Gradle plugin nor Bintray web ui shows why it does not show up and how can we link new artifact to the Jcenter, this is very, very confusing.
P.S. Previously I was able to solve similar issue only by asking a question on StackOverflow so I'm doing it here again (I've also contacted Bintray through Inbox on website but with no luck).
And to be clear, I've never had such problems with oss.sonatype.org.
Thank you for your submitting this issue.
We have managed to resolve the issue you were experiencing.
The issue occurred due to the reason of artifactID that was not approved.
Usually in order to add packages to JCenter, we add only packages under 'groupID/groupID/artifactID'. Usually we approve only one path for package, but since we wanted to expedite the resolution for your issue we decided to approve the package with only groupID. (i.e /com/gojuno/koptional).
This means that all three artifactIDs (koptional, koptional-reactor-extensions, koptional-rxjava2-extensions) are now approved and synced to JCenter.
We hope this clarifies. Please let us know if you encounter any other issues.
Best Regards,
Yonatan Brand
JFrog Support
We've published a package with two artifacts in it (android and os) to Bintray: https://dl.bintray.com/gojuno/maven/com/gojuno/commander/
Then we've enabled sync with jcenter for this package, but only one of the artifacts is in sync (android is synched while os is not):
https://jcenter.bintray.com/com/gojuno/commander/
I contacted Bintray through Inbox on bintray.com, Contact Us on bintray.com, Email and Twitter and haven't received reply anywhere, this issue is blocking for the project.
I saw similar issue was resolved through StackOverflow Bintray and JCenter not in Sync, so this is my hope.
An inclusion to JCenter always uses an allocated path prefix to avoid accidental file overwrites by other users. However, the 'commander' package contains files with no common base path:
'/com/gojuno/commander/os' AND '/com/gojuno/commander/android'
The best practice we recommend is creating a new package and not creating more than one path prefix for a package. If you wish keep working like this, please note that you will have to submit an inclusion request for each path prefix.
As for now you may proceed working on the same groupID path prefix with your different sub-modules.
We hope this clarifies.
usually when changing the artifact path you won't be able to resolve your content through JCenter although it was previously included.
The reason for this is that the inclusion of your 'commander' package in JCenter is for the files’ path.
Therefore, it was originally included under the path prefix 'com/gojuno/commander/android/'.
However, we have re-linked your package on the GroupId level (com/gojuno/commander) so every sub-module of your 'commander' package, will be added automatically and be synced with JCenter.
We have a root POM in one of our project which more and more people consume. So we're now considering to extract this into a real parent POM (i.e. without <modules> and specific build commands).
Now the question is where should this new parent POM go? I see two options:
A new project
Into a folder parent/ inside of the framework project.
I looked at Maven and it uses a distinct project for the parent POM (here is the latest release).
But that means the relativePath is most often wrong (I really don't want developers to have to checkout the parent POM with this approach).
What are the differences/advantages/drawbacks of the two approaches?
The simple reason having a separate project for such company pom is based on the release cycle of such a pom cause it's different of all other projects/artifacts within the different projects. A release is necessary to have a released version which means a defined state of the company pom. This release is simply being deployed into your company repository manager and can be consumed by many projects. During the time updates are comming in like plugin updates etc. so you can decide making a new release of your company pom. And the different projects can decide to pick the update by simply changing the version or not.
I've added an svn:externals to my project, and it works great locally via TortoiseSVN. When I use Jenkins to pull from the same repository, it's not showing anything about the externals in the console output.
I read some other questions on here and I made sure my SVN version number in Jenkins was set to (1.6 externals to file) and restarted Jenkins. The problem is still occurring. Any ideas of something else I could set, or something I could use for troubleshooting? Thanks.
Oh, and the external directory is in the same repository, so I don't think it's an authentication issue as it builds fine without a reference to the external files.
I fixed this issue by selecting higher SVN Version Number on Jenkins 2.222.1.
Here is the procedure:
Manage Jenkins -> Configure System -> Subversion Workspace Version
Select at least v1.6. (The default one was 1.4 for me)
I may have had a very uncommon structure, but here's what worked for me...
First of all, here's the directory structure:
--Parent
----folder1
------subfolder1
------svnexternalfolder
----svnexternalfolder
As you can see, I had my svn external folder in two different levels of the project structure, but the Jenkins project was pointing directly at "folder1".
When first configured, it would never pull the files for my svn external folder (whether it was a full checkout, or svn update). This was configured with the svnexternals at the parent level.
My next try was to remove the svn externals at the parent, then specify just the higher location on the parent, then the lower location on folder1. This gave an error since the child svn directory had the same name as the other one.
So I flip-flopped the order of creating the svn external locations and did the child first (on "folder1"), then did the higher one on parent. Once I did that, everything started working.
Hope this helps someone else.
If you're curious about why I configured the directory structure this way, this was a PhoneGap project. apparently cordova/phonegap projects create their directory structures like this, the common folder beneath the parent is the "www" which houses all html, javascript, etc files, then those are also used under the platforms/ios, or platforms/android folders (in my example, I just called it folder1).