On Jan 16, 2009, at 9:45 AM, Jeanfrancois Arcand wrote:
>
>
> 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 :-)
and changing the artifacts made things worse so 2 lessons :
1. use our mechanism, it's basically equivalent to what you are doing
with an intermediate step. the synchronization to java.net is using
rsync which is more reliable than basic mvn deploy. I think Jane or
Harsha can help you with that.
2. never republish a versioned artifacts with some changes.
thanks, jerome
>
>
> 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
>>>> >
>>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>