Hi Holger,
1) There are two ways to maintain the same generated snapshot version for
series of deployed files:
1. Deploy the batches in the exact order of: artifact, POM, attached
artifacts (classifiers); The first ordinary artifact (with no classifier)
to be deployed after the latest POM will create a new "batch".
2. Deploy each item in the same batch together with a matrix
param<http://wiki.jfrog.org/confluence/display/RTF/Using+Properties+in+Deployment+and+Resolution>
of
the key "build.timestamp" and a value of a millisecond-based epoch
timestamp; Artifacts with same timestamp values will be associated under
the same "batch".
2)
- This is a result of the heuristics described in *1) 1.* Please notify
us if this continues to occur once you've got deployment sorted out.
- This shouldn't happen if the repository's configured with a Unique
snapshot policy and if the path of the deployed artifact adheres to the
Maven layout. Is there any way you can supply us with a sample project that
consistently reproduces this?
HTH,
Noam
On Wed, Feb 29, 2012 at 7:53 PM, holgerw <[email protected]> wrote:
> Hello.
>
> Besides a really good experience with Artifactory I have some problems with
> the REST API.
>
> 1) How to Deploy via REST API a jar and it's pom file? Doing it in two PUT
> requests, sequentially should generate different unique timestamps, in case
> of SNAPSHOTs. Is there some way to perform an atomic upload of both related
> files?
>
> 2) Using the REST API for jar deployment, I observe inconsistent behavior
> for the unique timestamp generation of SNAPSHOTs. My repository is
> configured to generate unique timestamps, with a history limit of 10
> versions. The artifactory version is 2.4.2.
> On two consecutive PUT requests (with an interval of some minutes), of one
> same JAR (same checksum, as the JAR has not been altered), I would expect
> to
> encounter two JARs in the repository, but the following two scenarios
> happen:
> a) HTTP PUT returns with status 201, but maintaing the same artifact name
> (same timestamp).
> b) Sometimes, the repository does not generate the timestamp at all, but
> saves the jar with SNAPSHOT name, besides correct version declaration in
> the
> pom.xml (<version>1.0-SNAPSHOT</version>).
>
> Could you, please, give any hint on how to solve these problems?
>
> Thank you really much.
>
> Holger.
>
> --
> View this message in context:
> http://forums.jfrog.org/Deploy-via-REST-API-tp7330104p7330104.html
> Sent from the Artifactory - Users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Artifactory-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/artifactory-users
>
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Artifactory-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
