Re: Unable to resolve artifact: Unable to get dependency information

[Sofiane Bendoukha]

Sorry for the delay,

I wanted to execute mvn dependency:tree but I figured out that I am
working only with ant and I don't have a POM file.




On 24.07.2014 17:30, Jeremy Daggett wrote:
> Hmm, I wonder if there is some transitive dependency in your project
> that requires 0.10.1-SNAPSHOT. Can you please run and send the output
> of “mvn dependency:tree”? Thx!
>
> /jd
>
> From: Chris Custine  >
> Reply-To: "user@jclouds.apache.org "
> mailto:user@jclouds.apache.org>>
> Date: Wednesday, July 23, 2014 at 6:06 PM
> To: "user@jclouds.apache.org "
> mailto:user@jclouds.apache.org>>, Sofiane
> Bendoukha mailto:saw...@hotmail.com>>
> Subject: Re: Unable to resolve artifact: Unable to get dependency
> information
>
> Thats strange indeed. I am using maven 3.2.2 and I can’t reproduce
> this issue even intentionally. Maybe try a newer version of maven in
> the 3.2.x range?
>
> -- 
> Chris Custine
>
>
> On July 23, 2014 at 5:22:33 PM, Sofiane Bendoukha (saw...@hotmail.com
> ) wrote:
>
>> I am using Apache Maven 3.0.5.
>> On 23.07.2014 20:33, Chris Custine wrote:
>>> I’m not sure where the sshj 0.10.1-SNAPSHOT is coming from because
>>> it is not specified in jclouds, but in general, the error you are
>>> receiving about unbounded range for jdk version in the sshj pom.xml
>>> comes from using maven 2. If you run maven 3+ you should not receive
>>> that error, but jclouds will have compilation issues with sshj
>>> 0.10.1-SNAPSHOT.
>>>
>>> HTH
>>>
>>> -- 
>>> Chris Custine
>>>
>>>
>>> On July 23, 2014 at 9:51:47 AM, Sofiane Soulfly (saw...@hotmail.com
>>> ) wrote:
>>>
 Thank you Jeremy,

 I am using ant to install JClouds, exactly I followed the section
 "Download the binaries".

 Just for information everything was working until yesterday.

 Regards,

 Sofiane.

 Am 23.07.2014 17:29, schrieb Jeremy Daggett:
 > Hi Sofiane!
 >
 > Do you have the "net.schmizz:sshj:jar:0.10.1-SNAPSHOT² artifact
 somewhere
 > in one of your poms? The jclouds-sshj driver depends on version 0.8.1
 > [1], so could you please let us know? Thanks.
 >
 > /jd
 >
 > [1]
 https://github.com/jclouds/jclouds/blob/1.7.x/drivers/sshj/pom.xml
 >
 > On 7/22/14, 6:17 PM, "Sofiane Bendoukha"  wrote:
 >
 >> Hello everybody,
 >>
 >> why I am getting the following error? can someone help?
 >>
 >> Unable to resolve artifact: Unable to get dependency
 information: Unable
 >> to read the metadata file for artifact 'net.schmizz:sshj:jar':
 Invalid
 >> JDK version in profile 'doclint-java8-disable': Unbounded range:
 [1.8,
 >> for project net.schmizz:sshj
 >> net.schmizz:sshj:jar:0.10.1-SNAPSHOT
 >>
 > >from the specified remote repositories:
 >> apache.snapshots (http://repository.apache.org/snapshots),
 >> central (http://repo1.maven.org/maven2),
 >> sonatype-nexus-snapshots
 >> (https://oss.sonatype.org/content/repositories/snapshots),
 >> apache-snapshots
 >> (https://repository.apache.org/content/repositories/snapshots),
 >> jclouds-sona-snapshots-nexus
 >> (https://oss.sonatype.org/content/repositories/snapshots)
 >>
 >> Path to dependency:
 >> 1) org.apache.maven:super-pom:pom:2.0
 >> 2) org.apache.jclouds.driver:jclouds-sshj:jar:1.7.2
 >> 3) com.jcraft:jsch.agentproxy.sshj:jar:0.0.7
 >>
 >> Thanks,
 >>
 >> Sofiane.
 >>
 >
 >

>>

Re: How to write a Blob using an OutputStream?

[Adrian Cole]

Looks fine, I might switch to composition, but that's just a style nit. Ex.

PutOnCloseOutputStream extends FilterOutputString {
  private final okio.Buffer buffer = new okio.Buffer();
  ...

  PutOnCloseOutputStream(…){
super(buffer.outputStream());
…
  }

  @Override public void close() throws IOException {
// put buffer.inputStream() with length buffer.size()

  }

}

On Tue, Aug 5, 2014 at 4:27 PM, Steve Kingsland
 wrote:
> This wasn't terribly complicated to handle using a ByteArrayOutputStream,
> once I fixed the callers to not closeQuietly()...
>
> Here's the calling code, that has to return an OutputStream:
>
> public OutputStream getOutputStream(String containerName, String
> resourceName) throws IOException {
> return new
> JcloudsObjectWritingByteArrayOutputStream(this.blobStoreContext.getBlobStore(),
> containerName, resourceName);
> }
>
> And here's what JcloudsObjectWritingByteArrayOutputStream looks like (it's a
> bit long, so I put it in a gist):
> https://gist.github.com/skingsland/d2341cd52cd36c6cbb6f
>
> It's working ok with filesystem and in-memory object stores, but I'm running
> into some (apparently-unrelated) errors with the particular object store I'm
> trying to use (Ceph via S3 API). I'll save those for another email...
>
> I'd love to hear feedback on this approach. And thanks everyone for your
> help!
>
>
>
> Steve Kingsland
>
>
> Senior Software Engineer
>
> Opower
>
>
> We’re hiring! See jobs here
>
>
>
> On Tue, Aug 5, 2014 at 5:52 PM, Adrian Cole  wrote:
>>
>> jclouds currently doesn't have a direct path to the outputstream (or
>> channel), and even if it did, things mentioned by gaul would still be
>> true (ex. may need content-length up front).
>>
>> jclouds doesn't have a direct path to becoming netty, so I wouldn't
>> get too excited about full-bore async. Chunking, multipart, etc. over
>> streams are very possible, though.
>>
>> Personally, I'd recommend using something like okio buffer (or some
>> other buffer) and making that easier to work with (if it isn't
>> already). https://github.com/square/okio
>>
>> Hope this helps,
>> -A
>>
>> On Tue, Aug 5, 2014 at 2:33 PM, Zack Shoylev 
>> wrote:
>> > With buffered streams, for example, close() causes buffers to be flushed
>> > (which is technically what you are doing).
>> > So yes, you can get some serious exceptions when closing.
>> >
>> > 
>> > From: Steve Kingsland [steve.kingsl...@opower.com]
>> > Sent: Tuesday, August 05, 2014 9:06 AM
>> >
>> > To: user@jclouds.apache.org
>> > Subject: Re: How to write a Blob using an OutputStream?
>> >
>> > org.apache.commons.io.output.ByteArrayOutputStream sounds like a nice
>> > improvement over java.io.ByteArrayOutputStream (at least for my
>> > purposes),
>> > thanks Zack!
>> >
>> > The problem I'm running into is actually with the caller's
>> > Closeables.closeQuietly(documentOutputStream); call. That catches any
>> > IOException that's thrown from close() and logs it, instead of throwing
>> > it.
>> > That won't work for me, since I won't know if there was an error writing
>> > to
>> > the blob store until close() is called on my OutputStream. I can of
>> > course
>> > change the caller to use different error-handling for closing the
>> > stream,
>> > but it makes me wonder if using the close() method to upload the blob is
>> > the
>> > right approach. If you're given an OutputStream to write to, you'd
>> > expect
>> > the real errors to come from the write() methods, and not the close()
>> > method, right?
>> >
>> >
>> > Steve Kingsland
>> >
>> >
>> > Senior Software Engineer
>> >
>> > Opower
>> >
>> >
>> > We’re hiring! See jobs here
>> >
>> >
>> >
>> > On Tue, Aug 5, 2014 at 7:21 AM, Zack Shoylev
>> > 
>> > wrote:
>> >>
>> >> Your code seems fine. I have used
>> >>
>> >> http://commons.apache.org/proper/commons-io/apidocs/org/apache/commons/io/output/ByteArrayOutputStream.html
>> >> in the past to convert between stream types, but it seems like it
>> >> doesn't
>> >> match your case very well.
>> >>
>> >> Note you might have to do writeBytesToBlob() before super.close(), but
>> >> you
>> >> can test that.
>> >>
>> >> Let us know how it turns out!
>> >> 
>> >> From: Steve Kingsland [steve.kingsl...@opower.com]
>> >> Sent: Monday, August 04, 2014 9:22 PM
>> >> To: user@jclouds.apache.org
>> >> Subject: Re: How to write a Blob using an OutputStream?
>> >>
>> >> OK, then it appears that my calling code (which would be difficult and
>> >> risky to change) is incompatible with jclouds' BlobStore API: my caller
>> >> wants to obtain an OutputStream for writing to the blob store, and
>> >> jclouds
>> >> wants to obtain an InputStream for reading the blob's content that
>> >> should be
>> >> written. Therefore, my only solution is to buffer the blob data, either
>> >> in
>> >> memory or on disk, before uploading it to the blob store.
>> >>
>> >> Given that the documents I'm trying to write to