You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 14, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Jan 14, 2023. It is now read-only.
We currently have to fallback to old maven publishing using uploadArchives with android (see here, especially the comments section for reasons why it won't currently work).
This means we can't match what we are doing with rosjava, nor even think about debs for it yet. Debs are a no-show anyway because there is no easy way of installing the android sdk yet so that is not a great loss.
Still it would be good to get rosjava and rosandroid behaving the same way when publishing.
This issue is broader than that, since there are currently some inconsistencies that would be nice to improve:
The kinetic branch is using the maven-publish plug-in for the ros-java plug-in but the maven for the android plug-in. This causes projects to behave differently and use different deploy targets.
In addition, the master branch had been reverted back to use the maven plug-in for rosjava as well. @stonier mentions this has undesired implications but we are unsure what those may be. One possibility is problems creating debians with the maven plug-in, and that possibly due to the fact that the old maven plug-in always tries to deploy to maven local, which is not allowed on the build farm
The current target used for rosjava library artifacts is the un-intuitive publishMavenJavaPublicationToMavenRepository. Perhaps the easier publish could be used instead.
When this is tackled, also make sure to go through the templates, comments, existing code and documentation to make sure everything is updated to the resulting format.
online reports are mixed. I would guess that by now it must be fully supported.
My plan is, once I am done with a pass with everything working and all other important parts done to:
See if we can effectively switch to the publish
See if we can migrate the android plug-in to use this as well
Some updates. TL;DR: we still can't use maven-publish for the Android projects.
I asked the Android Gradle experts and they confirmed it is not yet working and that the maven-publish plug-in continues to be incubating despite a few years now having gone by.
Nonetheless, they also mentioned that there are upcoming updates both from the Gradle maven developers and from the Android Gradle developers which may mean that towards the middle of this year we may see updates on this front.
I also found a few hacks like this that try to put together the proper dependencies for an Android Library project manually, but my testing shows that this solution won't quite work for us, because it produces dependency versions in the pom.xml that don't mirror the range specifications of the project but instead use the versions resolved at build time, which is not exactly what we want.
On the positive side, I am almost sure that the publish target will work fine for us so I am in the process of testing using that on the build farm. If that works, I'll switch all projects to use that instead of the longer and difficult to remember Gradle target.
Aye, I've had problems with hacks before that don't resolve transitive dependencies in the pom.xml (mailing list archived message is here).
Just repeating what I had in the email so we have a reference here. The only thing that should be a concern is publishing to maven local would cause a problem:
Publish source generated artifacts to local
New shell, source /opt/ros/kinetic intending to use the binary maven repository
The maven local artifacts from the previous source workspace intrude...
From what I read in the maven-publish documentation, publish should be ok so long as the local repository isn't in the publishing.repositories container.
Activity
Fixed #1 - no supported devices on Google Play market
adamantivm commentedon Dec 26, 2016
This issue is broader than that, since there are currently some inconsistencies that would be nice to improve:
kineticbranch is using themaven-publishplug-in for the ros-java plug-in but themavenfor the android plug-in. This causes projects to behave differently and use different deploy targets.masterbranch had been reverted back to use themavenplug-in for rosjava as well. @stonier mentions this has undesired implications but we are unsure what those may be. One possibility is problems creating debians with themavenplug-in, and that possibly due to the fact that the oldmavenplug-in always tries to deploy to maven local, which is not allowed on the build farmpublishMavenJavaPublicationToMavenRepository. Perhaps the easierpublishcould be used instead.When this is tackled, also make sure to go through the templates, comments, existing code and documentation to make sure everything is updated to the resulting format.
stonier commentedon Dec 26, 2016
Does the new maven-publish plug-in work for android yet?
adamantivm commentedon Dec 26, 2016
online reports are mixed. I would guess that by now it must be fully supported.
My plan is, once I am done with a pass with everything working and all other important parts done to:
publishadamantivm commentedon Dec 28, 2016
Some updates. TL;DR: we still can't use maven-publish for the Android projects.
I asked the Android Gradle experts and they confirmed it is not yet working and that the maven-publish plug-in continues to be incubating despite a few years now having gone by.
Nonetheless, they also mentioned that there are upcoming updates both from the Gradle maven developers and from the Android Gradle developers which may mean that towards the middle of this year we may see updates on this front.
I also found a few hacks like this that try to put together the proper dependencies for an Android Library project manually, but my testing shows that this solution won't quite work for us, because it produces dependency versions in the pom.xml that don't mirror the range specifications of the project but instead use the versions resolved at build time, which is not exactly what we want.
On the positive side, I am almost sure that the
publishtarget will work fine for us so I am in the process of testing using that on the build farm. If that works, I'll switch all projects to use that instead of the longer and difficult to remember Gradle target.stonier commentedon Dec 29, 2016
Aye, I've had problems with hacks before that don't resolve transitive dependencies in the pom.xml (mailing list archived message is here).
Just repeating what I had in the email so we have a reference here. The only thing that should be a concern is publishing to maven local would cause a problem:
/opt/ros/kineticintending to use the binary maven repositoryFrom what I read in the maven-publish documentation,
publishshould be ok so long as the local repository isn't in thepublishing.repositoriescontainer.Merge pull request rosjava#1 from mojin-robotics/test_travis