dev@glassfish.java.net

Re: Stop repackaging Grizzly to support OSGi

From: Sahoo <Sahoo_at_Sun.COM>
Date: Fri, 16 Jan 2009 10:30:29 +0530

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?
Secondly, even if you faced issues with java.net, you should just try to
push the binary again.

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.
> 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.

Thanks,
Sahoo