Our team would like to use an Infinispan client in an ASP.NET core DOCKER environment. The last version seems to be an 8.3.0-Alpha1 version on Nuget.org, which is almost 2 years old. Are there any plans to get this into a release version and make it current?
I've assembled two new .nupkg Hotrod clients for Fedora31 and Windows10-VS14.
They're based on the 8.3.1.Final version released on the Infinispan web site.
Packages contain native libraries, please consider to build it by yourself following the readme if you need a different build for your specific platform.
For more info, meet the Infinispan Team at infinispan.zulipchat.com
Related
I need to build my project with Worklight version 6.1.0.02.20141216-0421, but I didn't find it. Please who has this version ?
If you absolutely must have this specific build, you can find it here if you use Worklight Consumer Edition, or here if you use Worklight Enterprise Edition, if you are an IBM customer with a valid support entitlement.
However, if there isn't a very specific reason that you absolutely must have this specific build, I strongly agree with Idan's answer that you should use the most recent iFix build available on IBM Fix Central. As of right now, the latest build contains fixes for 93 separate APARs that are not contained in the build you are asking about (from more than 2 years ago).
That is an extremely old build and unless this build was an official iFix release - it will no longer exist. So, if you are an IBM customer you can look for this build number in the IBM Fix Central website.
Note however that you should always use the latest available iFix release... and not a build from more than two years ago, especially for production. If you will request official support, you will be told to use the latest build.
What are the differences between aspnetcidev and aspnetvnext?
I see that aspnetcidev says "quick builds", but what does this mean?
Jan 29, 2016 edit:
This information is now part of the ASP.NET wiki: https://github.com/aspnet/Home/wiki/NuGet-feeds
The ASP.NET build system uses 3 myget feeds for each branch + nuget.org.
aspnetvolatile<branch> (aspnetvolatiledev/aspnetvolatilerelease)
aspnetci<branch> (aspnetcidev/aspnetcirelease)
aspnetvnext (dev branch)/aspnetrelease (release branch)
After each repo under github.com/aspnet builds successfully, each package produced by it is pushed to the corresponding volatile feed.
After the graph of repos is build, we trigger the Coherence build. This build verifies that the packages have matching versions and their references are correct (that they are coherent). Then, it pushes them to aspnetci<branch>.
Once the Coherence build passes, we run all our tests on the packages in the aspnetci<branch> feed. If the tests pass, we sign the packages and ship them to aspnetvnext or aspnetrelease
So the differences are:
aspnetvolatile<branch>
latest packages
possible not coherent
not tested
not signed
updated on every checkin
mostly used to diagnose build failure
aspnetci<branch>
possible not latest
coherent
not tested
not signed
updated when all repos build successfully
used by our build system
aspnetvnext/ (aspnetrelease|nuget.org)
possible not latest
coherent
signed
tested
updated when everything works
used for stable packages
Once the aspnetcirelease feed is stable, we push the packages from it to nuget.org.
Unless you work on developing new features for ASP.NET, I recommend that you use aspnetvnext (for dev bits) or nuget.org (for release bits). The release feed (aspnetrelease) is just a staging feed and it's not always in a good shape.
Edit:
I think it's easier to understand from a table:
I'm abrade that you can get the exact answer on the question only from Microsoft. You can open https://www.myget.org/gallery and filter for "aspnet" for example and will find many other repositories published for different teams.
For me more interesting is the information displayed by .NET Version Manager: dnvm (without parameters):
Thus, for me, the source https://www.myget.org/F/aspnetvnext/api/v2/ (or https://www.myget.org/F/aspnetvnext/api/v3/index.json) is the "official" place for the night builds of ASP.NET 5.
On the other side by filtering of https://www.myget.org/gallery "aspnet" you can see that aspnetvnext contains more distinct packages as aspnetcidev.
It's clear that both repositories probably contains different set of packages.
One important example where the repository https://www.myget.org/gallery/aspnetcidev be used is the new .NET Command Line Interface (.NET CLI) which you find on GitHub here. The new dotnet utility uses https://www.myget.org/F/aspnetcidev/api/v3/index.json together with many other sources in https://github.com/dotnet/cli/blob/master/NuGet.Config.
I suppose that AspNetCIDev is the repository of packages required for .NET CLI. It's the utility, which should replace dnx and dnu in RC2 of ASP.NET 5. See the post, this one and some other.
I need to migrate my application to WAS 6.1 to WAS 8.5.5. I would need list of things to be taken care before migration and what are all the major changes involved.
I googled and sufficient informations I couldnt get. Can some one please help me on this ?
One thing to do is to setup an eclipse with IBM WebSphere Application Server Migration Toolkit and then import your application source code (you may even analyse your binaries with Migration Toolkit for Application Binaries) in the workspace.
You then run Software Analyzer and select the Websphere Migration rules.
I want to upgrade Glassfish without internet connection. But I have already downloaded the latest version.
I have done the following steps,
For eg. galssfish-3.0 is the older version and glassfish-3.1 is the newer version.
Step: 1
I just copied the glassfish-3.0/glassfish/domains/domain1 and pasted in glassfish-3.1/glassfish/domains
Step: 2
In glassfish-3.1/bin ./asadmin i just give the command asadmin> start-domain --upgrade
then i checked the version asadmin> version the ouput was
Version = GlassFish Server Open Source Edition 3.1.1 (build 12)
Command version executed successfully.
Is this correct or I need to follow some other ways to achieve this? If wrong Please guide me the right way.
Can anyone help me?
Thanks in advance,
Gnik
Regarding the Oracle GlassFish Server 3.1 Upgrade Guide you did it right.
There are some hints in this guide for the migration of deployed applications:
Application archives (EAR files) and component archives (JAR, WAR, and
RAR files) that are deployed in the source server do not require any
modification to run on Oracle GlassFish Server 3.1. Components that
may have incompatibilities are deployed on GlassFish Server 3.1 with
the compatibility property set to v2 and will run without change on
GlassFish Server 3.1. You may, however, want to consider modifying the
applications to conform to Java EE 6 requirements.
...
Applications and components that are deployed in the source server are
deployed on the target server during the upgrade. Applications that do
not deploy successfully on the target server must be deployed manually
on the target server by the user.
If a domain contains information about a deployed application and the
installed application components do not agree with the configuration
information, the configuration is migrated unchanged, without any
attempt to reconfigure the incorrect configurations.
You should read through the guide carefully and check your deployed applications for any errors / exceptions during server startup or manual redeployment.
Some time ago I made an update as described in the update guide from 3.0 to 3.1.1 and cannot remember any bigger problems.
I downloaded the nservicebus 3 sample projects and noticed that there were missing dependencies (for example nservicebus.hosting.azure.dll and others).
Do I really need to download and build the trunk to get these dlls? I also noticed that they are not available via nuget either.
Looks like this was resolved with the NSB 3.0.3 release.