Jerome Dochez wrote:
>
> 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 <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 ?
This is what we are doing. But at the end we ends up with released
version deployed almost 6 times depending on where it fail. So now I
need to write a script to make sure this stupid upload doesn't fail, and
if it fail, have to cut another release, advertise it, then try again.
This is just a non sense to waste time like that :-)
>
>>
>>>> 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.
Yes, we learned the lesson. java.net is just crappy when trying to
upload :-)
A+
--Jeanfrancois
>
> 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
>>> <mailto:dev-unsubscribe_at_glassfish.dev.java.net>
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>> <mailto:dev-help_at_glassfish.dev.java.net>
>>>
>>
>