|
|
|
|
I'm migrating from an httpd-based Ivy repository to Artifactory. When I try to publish one of my artifacts I consistently get an error "impossible to publish artifacts for com.foo#foo-api;1.0.0-201002021203: java.io.IOException: destination file exists and overwrite == false". After the error, the Artifactory repository contains the jar file but not the ivy.xml.
This used to work with our httpd repsitory. We've elected to publish with overwrite set to false; we're not using SNAPSHOT versions, always unique versions. (That's why we have the timestamp on the development release.)
Any suggestions? Rich
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
|
|
Administrator
|
Hi Rich,
When using Ivy with a URL resolver to publish, Ivy sends a HEAD request to check if the remote file exists. Artifactory returns 200 to this query when the remote Ivy file is already there, which, if 'overwrite==false', causes Ivy to return the overwrite error you are getting.
Is it possible that in your previous setup HEAD requests return a different result?
Yoav On Tue, Feb 2, 2010 at 8:23 PM, Steele, Richard <[hidden email]> wrote:
I'm migrating from an httpd-based Ivy repository to Artifactory. When I try to publish one of my artifacts I consistently get an error "impossible to publish artifacts for com.foo#foo-api;1.0.0-201002021203: java.io.IOException: destination file exists and overwrite == false". After the error, the Artifactory repository contains the jar file but not the ivy.xml.
This used to work with our httpd repsitory.
We've elected to publish with overwrite set to false; we're not using SNAPSHOT versions, always unique versions. (That's why we have the timestamp on the development release.)
Any suggestions?
Rich
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
|
|
|
First of all, some confusion on my part: we're publishing using SSH, not httpd. Sorry! I used tcpmon to capture the interaction between Ivy and Artifactory while publishing my artifact. What I see is: Ivy: HEAD /artifactory/prerelease/com.xxx/ant-build-tools/1.0.0-201002101037/jar/ant-build-tools-1.0.0-201002101037.jar HTTP/1.1
Artifactory: HTTP/1.1 404 File not found. Ivy: PUT /artifactory/prerelease/com.xxx/ant-build-tools/1.0.0-201002101037/jar/ant-build-tools-1.0.0-201002101037.jar HTTP/1.1 Artifactory: HTTP/1.1 200 OK Ivy: HEAD /artifactory/prerelease/com.xxx/ant-build-tools/1.0.0-201002101037/jar/ant-build-tools-1.0.0-201002101037.jar.sha1 HTTP/1.1
Artifactory: HTTP/1.1 200 OK At this point the publish fails. Does Artifactory automatically compute the sha1 of the artifact? If so, then this explains the behavior I'm seeing. Is there a way to turn this feature off?
Thanks, Rich On Thu, Feb 4, 2010 at 2:02 PM, Yoav Landman <[hidden email]> wrote:
Hi Rich,
When using Ivy with a URL resolver to publish, Ivy sends a HEAD request to check if the remote file exists. Artifactory returns 200 to this query when the remote Ivy file is already there, which, if 'overwrite==false', causes Ivy to return the overwrite error you are getting.
Is it possible that in your previous setup HEAD requests return a different result?
Yoav
On Tue, Feb 2, 2010 at 8:23 PM, Steele, Richard <[hidden email]> wrote:
I'm migrating from an httpd-based Ivy repository to Artifactory. When I try to publish one of my artifacts I consistently get an error "impossible to publish artifacts for com.foo#foo-api;1.0.0-201002021203: java.io.IOException: destination file exists and overwrite == false". After the error, the Artifactory repository contains the jar file but not the ivy.xml.
This used to work with our httpd repsitory.
We've elected to publish with overwrite set to false; we're not using SNAPSHOT versions, always unique versions. (That's why we have the timestamp on the development release.)
Any suggestions?
Rich
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
|
|
|
OK, I see. Yes - Artifactory is doing checksum computation automatically. The reason is that computing the checksum only on the client-side is suitable for "passive" repositories, where the repository has to fully trust the client-side checksum, regardless of the final content that was received and stored on the repository-side. Therefore overwrite=true is currently required.
What we will do is add an option in Artifactory to verify the client-side checksum against the calculated checksum on the stored item instead of returning 200 automatically. We'll try to push it for the next minor release.
Thanks for reporting this,
Yoav On Wed, Feb 10, 2010 at 5:43 PM, Steele, Richard <[hidden email]> wrote:
First of all, some confusion on my part: we're publishing using SSH, not httpd. Sorry!
I used tcpmon to capture the interaction between Ivy and Artifactory while publishing my artifact. What I see is:
Ivy: HEAD /artifactory/prerelease/com.xxx/ant-build-tools/1.0.0-201002101037/jar/ant-build-tools-1.0.0-201002101037.jar HTTP/1.1
Artifactory: HTTP/1.1 404 File not found.
Ivy: PUT /artifactory/prerelease/com.xxx/ant-build-tools/1.0.0-201002101037/jar/ant-build-tools-1.0.0-201002101037.jar HTTP/1.1
Artifactory: HTTP/1.1 200 OK
Ivy: HEAD /artifactory/prerelease/com.xxx/ant-build-tools/1.0.0-201002101037/jar/ant-build-tools-1.0.0-201002101037.jar.sha1 HTTP/1.1
Artifactory: HTTP/1.1 200 OK
At this point the publish fails.
Does Artifactory automatically compute the sha1 of the artifact? If so, then this explains the behavior I'm seeing. Is there a way to turn this feature off?
Thanks,
RichOn Thu, Feb 4, 2010 at 2:02 PM, Yoav Landman <[hidden email]> wrote:
Hi Rich,
When using Ivy with a URL resolver to publish, Ivy sends a HEAD request to check if the remote file exists. Artifactory returns 200 to this query when the remote Ivy file is already there, which, if 'overwrite==false', causes Ivy to return the overwrite error you are getting.
Is it possible that in your previous setup HEAD requests return a different result?
Yoav
On Tue, Feb 2, 2010 at 8:23 PM, Steele, Richard <[hidden email]> wrote:
I'm migrating from an httpd-based Ivy repository to Artifactory. When I try to publish one of my artifacts I consistently get an error "impossible to publish artifacts for com.foo#foo-api;1.0.0-201002021203: java.io.IOException: destination file exists and overwrite == false". After the error, the Artifactory repository contains the jar file but not the ivy.xml.
This used to work with our httpd repsitory.
We've elected to publish with overwrite set to false; we're not using SNAPSHOT versions, always unique versions. (That's why we have the timestamp on the development release.)
Any suggestions?
Rich
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
|
|
|
Do you want me to write up an issue for this? On Sun, Feb 14, 2010 at 7:33 AM, Yoav Landman <[hidden email]> wrote:
OK, I see. Yes - Artifactory is doing checksum computation automatically. The reason is that computing the checksum only on the client-side is suitable for "passive" repositories, where the repository has to fully trust the client-side checksum, regardless of the final content that was received and stored on the repository-side. Therefore overwrite=true is currently required.
What we will do is add an option in Artifactory to verify the client-side checksum against the calculated checksum on the stored item instead of returning 200 automatically. We'll try to push it for the next minor release.
Thanks for reporting this,
Yoav On Wed, Feb 10, 2010 at 5:43 PM, Steele, Richard <[hidden email]> wrote:
First of all, some confusion on my part: we're publishing using SSH, not httpd. Sorry!
I used tcpmon to capture the interaction between Ivy and Artifactory while publishing my artifact. What I see is:
Ivy: HEAD /artifactory/prerelease/com.xxx/ant-build-tools/1.0.0-201002101037/jar/ant-build-tools-1.0.0-201002101037.jar HTTP/1.1
Artifactory: HTTP/1.1 404 File not found. Ivy: PUT /artifactory/prerelease/com.xxx/ant-build-tools/1.0.0-201002101037/jar/ant-build-tools-1.0.0-201002101037.jar HTTP/1.1 Artifactory: HTTP/1.1 200 OK Ivy: HEAD /artifactory/prerelease/com.xxx/ant-build-tools/1.0.0-201002101037/jar/ant-build-tools-1.0.0-201002101037.jar.sha1 HTTP/1.1
Artifactory: HTTP/1.1 200 OK At this point the publish fails. Does Artifactory automatically compute the sha1 of the artifact? If so, then this explains the behavior I'm seeing. Is there a way to turn this feature off?
Thanks, Rich On Thu, Feb 4, 2010 at 2:02 PM, Yoav Landman <[hidden email]> wrote:
Hi Rich,
When using Ivy with a URL resolver to publish, Ivy sends a HEAD request to check if the remote file exists. Artifactory returns 200 to this query when the remote Ivy file is already there, which, if 'overwrite==false', causes Ivy to return the overwrite error you are getting.
Is it possible that in your previous setup HEAD requests return a different result?
Yoav
On Tue, Feb 2, 2010 at 8:23 PM, Steele, Richard <[hidden email]> wrote:
I'm migrating from an httpd-based Ivy repository to Artifactory. When I try to publish one of my artifacts I consistently get an error "impossible to publish artifacts for com.foo#foo-api;1.0.0-201002021203: java.io.IOException: destination file exists and overwrite == false". After the error, the Artifactory repository contains the jar file but not the ivy.xml.
This used to work with our httpd repsitory.
We've elected to publish with overwrite set to false; we're not using SNAPSHOT versions, always unique versions. (That's why we have the timestamp on the development release.)
Any suggestions?
Rich
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
|
|
|
No need - I already did, but forgot to update with an issue reference. Here it is: http://issues.jfrog.org/jira/browse/RTFACT-2816
On Wed, Feb 17, 2010 at 6:35 PM, Steele, Richard <[hidden email]> wrote:
Do you want me to write up an issue for this?On Sun, Feb 14, 2010 at 7:33 AM, Yoav Landman <[hidden email]> wrote:
OK, I see. Yes - Artifactory is doing checksum computation automatically. The reason is that computing the checksum only on the client-side is suitable for "passive" repositories, where the repository has to fully trust the client-side checksum, regardless of the final content that was received and stored on the repository-side. Therefore overwrite=true is currently required.
What we will do is add an option in Artifactory to verify the client-side checksum against the calculated checksum on the stored item instead of returning 200 automatically. We'll try to push it for the next minor release.
Thanks for reporting this,
Yoav On Wed, Feb 10, 2010 at 5:43 PM, Steele, Richard <[hidden email]> wrote:
First of all, some confusion on my part: we're publishing using SSH, not httpd. Sorry!
I used tcpmon to capture the interaction between Ivy and Artifactory while publishing my artifact. What I see is:
Ivy: HEAD /artifactory/prerelease/com.xxx/ant-build-tools/1.0.0-201002101037/jar/ant-build-tools-1.0.0-201002101037.jar HTTP/1.1
Artifactory: HTTP/1.1 404 File not found. Ivy: PUT /artifactory/prerelease/com.xxx/ant-build-tools/1.0.0-201002101037/jar/ant-build-tools-1.0.0-201002101037.jar HTTP/1.1 Artifactory: HTTP/1.1 200 OK Ivy: HEAD /artifactory/prerelease/com.xxx/ant-build-tools/1.0.0-201002101037/jar/ant-build-tools-1.0.0-201002101037.jar.sha1 HTTP/1.1
Artifactory: HTTP/1.1 200 OK At this point the publish fails. Does Artifactory automatically compute the sha1 of the artifact? If so, then this explains the behavior I'm seeing. Is there a way to turn this feature off?
Thanks, Rich On Thu, Feb 4, 2010 at 2:02 PM, Yoav Landman <[hidden email]> wrote:
Hi Rich,
When using Ivy with a URL resolver to publish, Ivy sends a HEAD request to check if the remote file exists. Artifactory returns 200 to this query when the remote Ivy file is already there, which, if 'overwrite==false', causes Ivy to return the overwrite error you are getting.
Is it possible that in your previous setup HEAD requests return a different result?
Yoav
On Tue, Feb 2, 2010 at 8:23 PM, Steele, Richard <[hidden email]> wrote:
I'm migrating from an httpd-based Ivy repository to Artifactory. When I try to publish one of my artifacts I consistently get an error "impossible to publish artifacts for com.foo#foo-api;1.0.0-201002021203: java.io.IOException: destination file exists and overwrite == false". After the error, the Artifactory repository contains the jar file but not the ivy.xml.
This used to work with our httpd repsitory.
We've elected to publish with overwrite set to false; we're not using SNAPSHOT versions, always unique versions. (That's why we have the timestamp on the development release.)
Any suggestions?
Rich
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
|
|
|
Thank you, I look forward to trying out the fix. On Wed, Feb 17, 2010 at 5:07 PM, Yoav Landman <[hidden email]> wrote:
No need - I already did, but forgot to update with an issue reference. Here it is: http://issues.jfrog.org/jira/browse/RTFACT-2816
On Wed, Feb 17, 2010 at 6:35 PM, Steele, Richard <[hidden email]> wrote:
Do you want me to write up an issue for this?On Sun, Feb 14, 2010 at 7:33 AM, Yoav Landman <[hidden email]> wrote:
OK, I see. Yes - Artifactory is doing checksum computation automatically. The reason is that computing the checksum only on the client-side is suitable for "passive" repositories, where the repository has to fully trust the client-side checksum, regardless of the final content that was received and stored on the repository-side. Therefore overwrite=true is currently required.
What we will do is add an option in Artifactory to verify the client-side checksum against the calculated checksum on the stored item instead of returning 200 automatically. We'll try to push it for the next minor release.
Thanks for reporting this,
Yoav On Wed, Feb 10, 2010 at 5:43 PM, Steele, Richard <[hidden email]> wrote:
First of all, some confusion on my part: we're publishing using SSH, not httpd. Sorry!
I used tcpmon to capture the interaction between Ivy and Artifactory while publishing my artifact. What I see is:
Ivy: HEAD /artifactory/prerelease/com.xxx/ant-build-tools/1.0.0-201002101037/jar/ant-build-tools-1.0.0-201002101037.jar HTTP/1.1
Artifactory: HTTP/1.1 404 File not found. Ivy: PUT /artifactory/prerelease/com.xxx/ant-build-tools/1.0.0-201002101037/jar/ant-build-tools-1.0.0-201002101037.jar HTTP/1.1 Artifactory: HTTP/1.1 200 OK Ivy: HEAD /artifactory/prerelease/com.xxx/ant-build-tools/1.0.0-201002101037/jar/ant-build-tools-1.0.0-201002101037.jar.sha1 HTTP/1.1
Artifactory: HTTP/1.1 200 OK At this point the publish fails. Does Artifactory automatically compute the sha1 of the artifact? If so, then this explains the behavior I'm seeing. Is there a way to turn this feature off?
Thanks, Rich On Thu, Feb 4, 2010 at 2:02 PM, Yoav Landman <[hidden email]> wrote:
Hi Rich,
When using Ivy with a URL resolver to publish, Ivy sends a HEAD request to check if the remote file exists. Artifactory returns 200 to this query when the remote Ivy file is already there, which, if 'overwrite==false', causes Ivy to return the overwrite error you are getting.
Is it possible that in your previous setup HEAD requests return a different result?
Yoav
On Tue, Feb 2, 2010 at 8:23 PM, Steele, Richard <[hidden email]> wrote:
I'm migrating from an httpd-based Ivy repository to Artifactory. When I try to publish one of my artifacts I consistently get an error "impossible to publish artifacts for com.foo#foo-api;1.0.0-201002021203: java.io.IOException: destination file exists and overwrite == false". After the error, the Artifactory repository contains the jar file but not the ivy.xml.
This used to work with our httpd repsitory.
We've elected to publish with overwrite set to false; we're not using SNAPSHOT versions, always unique versions. (That's why we have the timestamp on the development release.)
Any suggestions?
Rich
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev_______________________________________________
Artifactory-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
|
|
Locked
