Hi Harsha,
>>
>> There is a typo in my first e-mail. It should be Grizzly 1.9.3.
>> The culprit is that grizzly-utils-1.9.3.jar artifact on Nexus
>> repository (http://maven.glassfish.org/content/repositories/java.net2/com/sun/grizzly/grizzly-utils/1.9.3/
>> ) is not sync'd with the maven repository on http://download.java.net/maven/2/com/sun/grizzly/grizzly-utils/1.9.3
>> .
>>
>> The one on java.net has 17Jan while the one in Nexus repository has
>> 07Jan and the jar size is different as well.
>> If you manually download the artifact from java.net and replace the
>> one in your local repo that should fix the problem.
>> Or remove Nexus repo from pom.xml.
>>
>> Harsha, do you know why Nexus repo is not sync'd with
>> download.java.net?
> 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.
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. Unfortunately grizzly-utils was successfully deployed first
time, which I didn't expect. The update you see (13th Jan) I did
yesterday, just hoped that it will force maven to synchronize local
and global repositories.
Today we've integrated version 1.9.4, which will should fix that maven
conflict.
Thanks.
WBR,
Alexey.
>
> -hg
>>
>> Thanks,
>> Jane
>>
>>
>>
>> Jane Young wrote:
>>> Hi Alexey,
>>>
>>> I think there is an issue with Grizzly 1.9.4 but I can't figure
>>> out where the issue is.
>>> With a fresh build from the trunk, all the remote commands fail
>>> with the message:
>>>
>>> Error encountered when making remote call: Status: 404
>>>
>>> server.log does not display anything useful.
>>>
>>> I download the bits from Hudson but it seems to be working. Can
>>> you take a look by building a fresh build from the trunk?
>>> Several people have reported this issue. I'm also seeing the same
>>> issue.
>>> Can you take a look at your earliest convenience?
>>>
>>> Thanks,
>>> Jane
>>>
>>>> Today we've integrated Grizzly 1.9.3 [svn rev. 24270], which is
>>>> OSGi compliant, and made changes to related modules to depend
>>>> directly on Grizzly artifacts.
>>>> I've built Glassfish and run QL tests, they were fine, but if you
>>>> see any issue with specific module - please let me know.
>>>>
>>>> Thanks.
>>>>
>>>> WBR,
>>>> Alexey.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: 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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: 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
>