On Jan 16, 2009, at 2:20 AM, Oleksiy Stashok wrote:
>
> On Jan 16, 2009, at 6:00 , Sahoo wrote:
>
>> Oleksiy Stashok wrote:
>>> Hi Harsha,
>>>> Simple.. Alexey didn't bump up the version when he integrated
>>>> Grizzly 1.9.3 . Is that correct Alexey? (The fact that 1.9.3
>>>> grizzly-utils jar existed before 13th Jan tells me that. ).Nexus
>>>> fetches artifacts only once and caches them. If there is already
>>>> one available with same version, in the cache, it would get the
>>>> same old unless a dependent made a request for the next version
>>>> of the artifact/jar/resource.
>>> Think it's correct. The reason I didn't bumped new version,
>>> because when I deploy Grizzly artifacts to maven, very often I see
>>> problem with java.net, when it reports, that connection could not
>>> be established. And I can not be sure, if all or half of Grizzly
>>> modules were deployed.
>> Are you using different techniques that regular GlassFish jobs? How
>> come GlassFish hudson jobs don't see such java.net issues?
> I think because Glassfish doesn't deploy artifacts to java.net, but
> internal maven repository. I observe problem with maven deployment
> on Grizzly hudson jobs too.
nothing prevents you from doing the same thing, our maven repo is
synchronized with the external world, it's not like we are hiding our
binaries.
> It looks like this:
>>>>>> altDeploymentRepository = null
>>>>>> Uploading: java-net:/maven2-repository/trunk/www/repository//
>>>>>> trunk/www/repository/com/sun/grizzly/samples/grizzly-comet-chat-
>>>>>> iframe/1.9.4/grizzly-comet-chat-iframe-1.9.4.war
>>>>>> [INFO] Retrieving previous metadata from java.net-m2-repository
>>>>>> [INFO] Uploading repository metadata for: 'artifact
>>>>>> com.sun.grizzly.samples:grizzly-comet-chat-iframe'
>>>>>> [INFO] Uploading project information for grizzly-comet-chat-
>>>>>> iframe 1.9.4
>>>>>> [INFO]
>>>>>> ------------------------------------------------------------------------
>>>>>> [ERROR] BUILD ERROR
>>>>>> [INFO]
>>>>>> ------------------------------------------------------------------------
>>>>>> [INFO] Error installing artifact's metadata: Error while
>>>>>> deploying metadata: Connection failed: Unable to connect to https://svn.dev.java.net/svn/maven2-repository/trunk/www/repository/
>>>>>>
>>>>>> svn: The specified baseline is not the latest baseline, so it
>>>>>> may not be checked out.
>>>>>> svn: CHECKOUT of '/svn/maven2-repository/!svn/bln/269968': 409
>>>>>> Conflict (https://svn.dev.java.net)
>>>>>> [INFO]
>>>>>> ------------------------------------------------------------------------
>>>>>> [INFO] For more information, run Maven with the -e switch
>>>> May be Jane / Terena could help Grizzly jars get published?
>>>
>>> Actually after many retry it eventually works. But that's painful
>>> to upload up to 6 times the jars just because of this exception.
>>> Now 1.9.4 was finally uploaded :-)
>
>
>> More over, to know whether your binary has reached the repo or not,
>> go to the repo directly and see if it is there or not.
> I understand that, but Grizzly has 20+ modules and having in mind
> how fast java.net is and that artifacts appear there with lag - I
> can spend just hour to understand what was deployed and what wasn't.
but don't you see it from the build-error like the one you have
above ? I mean somehow the failure to upload is not silent so why
don't you catch it while doing the mvn deploy ?
>
>>> So when I started to deploy Grizzly 1.9.3, it failed, meantime I
>>> made additional "last fixes" and keep redeploying the artifacts
>>> until succeeded.
>> That's the problem. What justifies making "last fixes?" It appears
>> to me that your release process needs to be looked at.
> Agree. This was our mistake.
yes, once you have turned to crank on a version, if anything happens,
fixes, wrong upload, you name it, you *must* bump up the version
otherwise you inflict a lot of pain to everyone.
In the meantime, I will talk with Jane and Kohsuke, I think that
through branching and some hudson support we could automate some
safeguarding around binary integrations.
jerome
>
> WBR,
> Alexey.
>
>>
>>
>> Thanks,
>> Sahoo
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>