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:

    <repositories>
        <repository>
            <id>snapshots</id>
            <name>Apache Development Snapshot Repository</name>
            
<url>https://repository.apache.org/content/repositories/snapshots/</url>
            <releases>
                <enabled>false</enabled>
            </releases>
            <snapshots>
                <enabled>true</enabled>
            </snapshots>
        </repository>
    </repositories>

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?

Thanks.

ps. if someone wants to check this out of the box you can reproduce
the case by building this project (same case):
https://github.com/jbonofre/beam-samples/

On Wed, Dec 12, 2018 at 8:55 PM Garrett Jones <garrettjo...@google.com> wrote:
>
> Nevermind, I found a much easier fix (delete two characters): 
> https://github.com/apache/beam/pull/7265
>
>
> On Wed, Dec 12, 2018 at 11:03 AM Garrett Jones <garrettjo...@google.com> 
> 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 <sc...@apache.org> 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] https://github.com/apache/beam/pull/7197
>>> [2] https://builds.apache.org/job/beam_Release_Gradle_NightlySnapshot/
>>>
>>> On Wed, Dec 12, 2018 at 5:57 AM Alexey Romanenko <aromanenko....@gmail.com> 
>>> 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] 
>>>> https://github.com/apache/beam/commit/bfd1be9ae22d1ae7e732f590c448e9e5ed2894b9
>>>
>>>
>>>
>>> --
>>>
>>>
>>>
>>>
>>> Got feedback? tinyurl.com/swegner-feedback

Reply via email to