[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue with publishing maven artefacts locally

Scott and Garret, thank you for a fix, it works fine for me now.

Ismael, this is very good question. I think we still don’t have a determinate way of installing custom artifacts and using them for testing with custom pipelines. I’d very appreciate if someone could share their experience with that.

On 13 Dec 2018, at 00:26, Chamikara Jayalath <chamikara@xxxxxxxxxx> wrote:

Not exactly sure if this is the reason but I noticed that Ismaël's command above result in a beam-sdks-java-core-2.10.0-20181212.232426-1.jar instead of a beam-sdks-java-core-2.10.0-SNAPSHOT.jar.

- Cham

On Wed, Dec 12, 2018 at 1:16 PM Ismaël Mejía <iemejia@xxxxxxxxx> wrote:
Thanks Garrett for the quick fix. I just tested and it is working now.

I found a second issue (not related to Garrett's PR, it was the reason
why I detected that local artifacts were not updated in our jenkins
(in the other thread).

To validate that our daily snapshots don't break existing code we have
a maven project that takes these snapshots from the apache repository.
In maven speak:

            <name>Apache Development Snapshot Repository</name>

If we do 'mvn clean verify' in our project, it brings the SNAPSHOTS from Apache.

Now if locally I fix something in Beam and deploy locally via:

    ./gradlew -Ppublishing --no-parallel
-PdistMgmtSnapshotsUrl=file:///home/ismael/.m2/repository -p
sdks/java/core publish -x spotlessCheck -x test -x rat

It puts the generated more recent jars in the .m2 directory.
However if you re execute the maven project, it detects and imports
still the old jars.

I think that something is missing in the way we are generating the
files for the .m2 directory via publishing.
But I don't really understand clearly the way SNAPSHOT resolution works.
Anyone has any idea or can contribute a fix for this one?


ps. if someone wants to check this out of the box you can reproduce
the case by building this project (same case):

On Wed, Dec 12, 2018 at 8:55 PM Garrett Jones <garrettjones@xxxxxxxxxx> wrote:
> Nevermind, I found a much easier fix (delete two characters):
> On Wed, Dec 12, 2018 at 11:03 AM Garrett Jones <garrettjones@xxxxxxxxxx> wrote:
>> I'm inclined to undo a particular modification I made in my PR and re-duplicate the repositories declaration between the Gradle plugin and the new BOM module. Scott, what do you think?
>> On Wed, Dec 12, 2018 at 11:00 AM Scott Wegner <scott@xxxxxxxxxx> wrote:
>>> Thanks for pointing this out Alexy. This seems like we unintentionally broke something in PR#7197 [1]
>>> +Garrett Jones, who authored the change. Garrett can you help investigate?
>>> I went to check to see if we have any existing Jenkins jobs that would've caught this break. It seems the beam_Release_Gradle_NightlySnapshot job [2] has been failing for the last 10 days. Has anybody looked into this?
>>> [1]
>>> [2]
>>> On Wed, Dec 12, 2018 at 5:57 AM Alexey Romanenko <> wrote:
>>>> Hi all,
>>>> I used to publish maven artefacts into local repository using this kind of command for example:
>>>> ./gradlew -Ppublishing --no-parallel -PdistMgmtSnapshotsUrl=file:///path/to/.m2/repository/ -p sdks/java/io/kafka/ publish
>>>> It worked fine till today. Seems like (according to "git bisect”) this recent commit [1] introduced new functionality and now it fails with an error:
>>>> * What went wrong:
>>>> A problem occurred configuring project ':beam-sdks-java-io-kafka'.
>>>> > Exception thrown while executing model rule: PublishingPluginRules#publishing(ExtensionContainer)
>>>>    > Cannot set the value of read-only property 'repositories' for object of type org.gradle.api.publish.internal.DeferredConfigurablePublishingExtension.
>>>> Does anyone know if this is a bug or I should use another command for the same purposes?
>>>> [1]
>>> --
>>> Got feedback?