Build failed in Jenkins: POI-DSL-OpenJDK #365

[Apache Jenkins Server]

See 


Changes:

[centic] Fix some IntelliJ warnings in XDGF area

--
[...truncated 409.64 KB...]
 [java] Inner class org.apache.poi.sl.TestOleShape$Api.class not included
 [java] Inner class org.apache.poi.sl.TestOleShape$1.class not included
 [java] Class org.apache.poi.benchmark.generated.AddImageBench_jmhType does 
not derive from TestCase and does not have a @Test annotation
 [java] Inner class org.apache.poi.TestPOIXMLDocument$UncaughtHandler.class 
not included
 [java] Inner class org.apache.poi.TestPOIXMLDocument$1.class not included
 [java] Inner class org.apache.poi.xslf.usermodel.TestXMLSlideShow$1.class 
not included
 [java] Inner class 
org.apache.poi.xslf.usermodel.TestXMLSlideShow$BufAccessBAOS.class not included
 [java] Inner class 
org.apache.poi.xssf.usermodel.TestMatrixFormulasFromXMLSpreadsheet$1.class not 
included
 [java] Inner class 
org.apache.poi.xssf.usermodel.TestMatrixFormulasFromXMLSpreadsheet$Navigator.class
 not included
 [java] Inner class org.apache.poi.dev.TestOOXMLLister$1.class not included
 [java] Inner class org.apache.poi.dev.TestOOXMLPrettyPrint$1.class not 
included
 [java] Found 227 classes
 [java] SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
 [java] SLF4J: Defaulting to no-operation (NOP) logger implementation
 [java] SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for 
further details.
 [java] 
..I.I.II...I..I.I...II.I..I..I.I...III.I..I...I...I.II..II...I.II.I.I..II.I...I..II...I...I...IIII.
 [java] Time: 127.017
 [java] 
 [java] OK (2378 tests)
 [java] 
 [java] Copying classes to 

 [java] Copying .xsb resources

compile-all:

compile-version:
 [copy] Copying 1 file to 

[javac] Compiling 1 source file to 

   [delete] Deleting: 


-manifest:

jar:
  [jar] Building jar: 

  [jar] Building jar: 

Build failed in Jenkins: POI-DSL-API-Check #275

[Apache Jenkins Server]

See 

--
Started by an SCM change
[EnvInject] - Loading node environment variables.
[EnvInject] - Preparing an environment for the build.
[EnvInject] - Keeping Jenkins system variables.
[EnvInject] - Keeping Jenkins build variables.
[EnvInject] - Injecting as environment variables the properties content 
LANG=en_US.UTF-8

[EnvInject] - Variables injected successfully.
[EnvInject] - Injecting contributions.
Building remotely on H22 (ubuntu xenial) in workspace 

java.io.IOException: Failed to mkdirs: 

at hudson.FilePath.mkdirs(FilePath.java:1170)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1200)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1724)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:421)
Retrying after 10 seconds
java.io.IOException: Failed to mkdirs: 

at hudson.FilePath.mkdirs(FilePath.java:1170)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1200)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1724)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:421)
Retrying after 10 seconds
java.io.IOException: Failed to mkdirs: 

at hudson.FilePath.mkdirs(FilePath.java:1170)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1200)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1724)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:421)
Retrying after 10 seconds
java.io.IOException: Failed to mkdirs: 

at hudson.FilePath.mkdirs(FilePath.java:1170)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1200)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1724)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:421)
Archiving artifacts
ERROR: Build step failed with exception
Also:   hudson.remoting.Channel$CallSiteStackTrace: Remote call to H22
at 
hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1693)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:310)
at hudson.remoting.Channel.call(Channel.java:908)
at hudson.FilePath.act(FilePath.java:986)
at hudson.FilePath.act(FilePath.java:975)
at 
hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:243)
at 
hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:81)
at 
hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:690)
at hudson.model.Build$BuildExecution.post2(Build.java:186)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:635)
at hudson.model.Run.execute(Run.java:1749)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
  

Re: Timeline for 4.0.0 release

[Alain FAGOT BÉAREZ]

Hi all,

There is one branch that I would like to finish before release 4.0.0 since it 
would make the implementation of XDDF more sound. But as these are on the @Beta 
side, I can understand it is no blocker.

https://github.com/cuali/poi/branches

Best regards,
Alain FAGOT BÉAREZ 

⁣


 Originale Nachricht 
Von: "pj.fanning" 
Gesendet: Mon Feb 12 16:09:51 GMT-03:00 2018
An: dev@poi.apache.org
Betreff: Timeline for 4.0.0 release

It's over 5 months since the POI 3.17 release.
I'm wondering if we should be thinking about about releasing 4.0.0.
Is there anything that is in progress that we should consider waiting for?



--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: Timeline for 4.0.0 release

[Dominik Stadler]

The only thing that comes to my mind is the updated XmlBeans release which
I would love to resolve for 4.0.0. Unfortunately I can't spend enough time
on POI lately to make progress on this topic :( Anybody else who wants to
take it up?

Thanks... Dominik.

On Mon, Feb 12, 2018 at 8:09 PM, pj.fanning  wrote:

> It's over 5 months since the POI 3.17 release.
> I'm wondering if we should be thinking about about releasing 4.0.0.
> Is there anything that is in progress that we should consider waiting for?
>
>
>
> --
> Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

RE: Timeline for 4.0.0 release

[Murphy, Mark]

I know we said that 4.0.0 will start using semantic versioning, but we never 
really discussed release schedules. It was mentioned, but no one ever said yea 
or nay. Are we all still trying to digest what semantic versioning means to 
POI? This still has a feeling of flying by the seat of our pants.

As I see it there are a few options:
1. Use semver project wide with a single version number, with minor releases 
whenever we feel it is necessary, and major releases whenever we feel it is 
necessary to break compatibility for something. Break fix support only for 
current release.

2. Use semver project in a scheduled manner with predictable periodic minor and 
major releases. Support for current release only.

3. Same as #2 with additional bug fix support for a predictable long term 
support release.

4. Repackage to CORE, SS, WP, etc with each package having an independent beta 
version number until it is deemed stable (for now I would call CORE and SS 
stable, and everything else beta). Then use option 1, 2, or 3 above.

I personally would prefer #4 with option 1 or 3. Shifting to POI 4.0 will 
signal that we are doing something different, and would be easier to sell, but 
more work to complete. Or maybe 4.0 is the shift to semver, and 5.0 could be 
repackaging if we want to go down that path, but the reason for repackaging in 
this way is to allow for drawing and WP and Visio API's to remain designated as 
beta and thus allow breaking changes until we get to a stable state. It would 
also give us a built in way to add more pieces if desired and not have the user 
confuse a new package as stable because it has a stable version number. The 
reason to repackage now rather than wait till a future major release is that 
some packages would shift from stable to beta version numbers. I see that as 
potentially confusing.

-Original Message-
From: pj.fanning [mailto:fannin...@yahoo.com] 
Sent: Monday, February 12, 2018 2:10 PM
To: dev@poi.apache.org
Subject: Timeline for 4.0.0 release

It's over 5 months since the POI 3.17 release.
I'm wondering if we should be thinking about about releasing 4.0.0.
Is there anything that is in progress that we should consider waiting for?



--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, 
e-mail: dev-h...@poi.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[GitHub] poi pull request #85: prototype for low memory footprint shared string table

[pjfanning]

Github user pjfanning closed the pull request at:

https://github.com/apache/poi/pull/85


---

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Timeline for 4.0.0 release

[pj.fanning]

It's over 5 months since the POI 3.17 release.
I'm wondering if we should be thinking about about releasing 4.0.0.
Is there anything that is in progress that we should consider waiting for?



--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[Bug 62098] exceptions while updating xlsx-file

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=62098

Nick Burch  changed:

   What|Removed |Added

 OS||All
 Status|NEW |NEEDINFO

--- Comment #1 from Nick Burch  ---
There doesn't seem to be any Apache POI code involved in your stacktrace.
Therefore, it rather seems to be a bug in your code...

Can you write a short junit unit test case (or similar standalone program)
which shows the issue to be in POI?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[Bug 62098] New: exceptions while updating xlsx-file

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=62098

Bug ID: 62098
   Summary: exceptions while updating xlsx-file
   Product: POI
   Version: 3.17-FINAL
  Hardware: PC
Status: NEW
  Severity: normal
  Priority: P2
 Component: XSSF
  Assignee: dev@poi.apache.org
  Reporter: markusc...@gmail.com
  Target Milestone: ---

Created attachment 35728
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=35728=edit
test-File like the original

code that causes the bug:

public void dateiSpeichern(){




try (FileOutputStream outPutStream = new
FileOutputStream(actualFile)){


System.out.println("File: "+actualFile);
System.out.println("Sheet:
"+actualSheet.getSheetName());

//Daten abspeichern
Header header=actualSheet.getHeader();
header.setLeft(jtaZeitraum.getText());
header.setCenter(jtaAnschrift.getText());;
header.setRight(jtaVonBis.getText());

for(int i=0; i

Re: adding dependencies on h2 and mockito

[Dominik Stadler]

Sorry this got a bit burried because it was sent under the "h2 and mockito
dependencies" topic.

I think vsdump is used for .vsd files (old binary format), not for .vsdx
files. New newer format is actually a zip-file, so you can open it with a
zip-utility and look at the files in there.

We have a utility OOXMLPrettyPrint in the POI sources which can reformat
the XML files in the .vsdx so that they are easier to read.

For useful tests, I think it would be best to focus on the overall
reading/writing of data at first, e.g. start with a test for XDGFDocument
to ensure the code can properly open and write documents. Then XDGFSheet is
the next class which provides basic functionality and the actual contents
of the Visio document like cells, sections and stylesheets. Having useful
tests for those two would be a good start already!

Dominik.

On Sun, Jan 28, 2018 at 7:21 PM, leebanga lee  wrote:

> Hi Dominik,
>
> From what I can see within the xdgf package there are two tests. I also
> observed that mocks are not used within the project.
> I was unable to get vsdump program in order to check the structure of the
> sample file "test_text_extraction.vsdx". How can get it ? I have been able
> to run the tests and they both passed but I am unable to find one of the
> text that was used in the assertion. I also want to ask about the scope of
> what has been done in order not to write test aimlessly. I think it would
> be better to write test for the usecases that has been considered for
> development till date.
>
> Regards,
> Lukman.
>
>
>
> On Fri, Jan 26, 2018 at 1:06 PM, Murphy, Mark 
> wrote:
>
> > Could the functionality be written to use H2 if it exists in the
> > classpath, but stick with the current process if it does not?
> >
> > -Original Message-
> > From: Dominik Stadler [mailto:dominik.stad...@gmx.at]
> > Sent: Friday, January 26, 2018 5:10 AM
> > To: POI Developers List 
> > Subject: Re: adding dependencies on h2 and mockito
> >
> > Hi,
> >
> > Mockito for testing is fine for me, H2 as requirement for everybody
> sounds
> > a bit heavy, would we still keep it optional unless somebody actually
> uses
> > this functionality? I.e. if you have Maven/Gradle dependencies it
> wouldn't
> > be dragged in by default?
> >
> > Thanks... Dominik.
> >
> > On Fri, Jan 26, 2018 at 9:03 AM, pj.fanning  wrote:
> >
> > > Are there any objections to me adding dependencies on h2 jar
> > > dependency for
> > > https://github.com/apache/poi/pull/85 and a test dependency on
> mockito?
> > > I think mockito would be useful for allowing us to test edge cases.
> > > An example is  https://svn.apache.org/viewvc?
> > > view=revision=1822253
> > > where creating an XSLFTextRun with a null Font Size is not
> > straightforward.
> > > With mockito, it is very easy to produce such an instance.
> > >
> > >
> > >
> > > --
> > > Sent from:
> > > http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional
> > > commands, e-mail: dev-h...@poi.apache.org
> > >
> > >
> >
>

Re: Maven Build Failure

[Dominik Stadler]

Hi,

Probably some problem with the temp-folder under target/tmp, either it did
not exist or was removed by a concurrently running unit-test (not sure if
Maven will run more than one at a time...), we could add a mkdirs() in the
setup-method in this test to lower the chances of running into this problem.

Dominik.

On Sun, Feb 11, 2018 at 10:46 PM, Mark Murphy  wrote:

> What causes this in the Maven build?
>
>
> javax.imageio.IIOException: Can't create cache file!
> at org.apache.poi.hslf.usermodel.TestPicture.macImages(
> TestPicture.java:150)
> Caused by: java.nio.file.NoSuchFileException:
> target/tmp/imageio3327126342253604027.tmp
> at org.apache.poi.hslf.usermodel.TestPicture.macImages(
> TestPicture.java:150)
>

[Bug 59623] Threshold lines(Target values) cannot be created in all chart types in word, excel and ppt

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=59623

Alain Fagot Bearez  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #3 from Alain Fagot Bearez  ---
Despite not having a one-method solution for this, all underlying constructs
are available. The recently introduced package XDDF offers bar charts (where an
option is given to set the direction to columns) and scatter charts to draw the
line.

I suppose you could write an example using these resources as part of our
ongoing documentation effort.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[Bug 57369] Provide functions to change major and minor unit for XSSFChartAxis

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=57369

Alain Fagot Bearez  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEEDINFO|RESOLVED

--- Comment #3 from Alain Fagot Bearez  ---
New functions are provided as of r1823963

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[GitHub] poi pull request #100: [bug-57369] support for major and minor unit on XDDFC...

[Alain-Bearez]

Github user Alain-Bearez closed the pull request at:

https://github.com/apache/poi/pull/100


---

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org