docx4j 2.7.0 soon!

[jason]

I'm planning to release docx4j 2.7.0 soon.

The main reason for doing so is to have a release which is compatible with JAXB RI 2.2.3, but there are also a number of other bug fixes / enhancements.

Question: are there any burning issues which need to be addressed first? Any contributions planned but not yet made?

http://dev.plutext.org/docx4j/docx4j-ni ... 110416.jar is a recent nightly, for anyone who wants to try their code against it. There is one backwards-incompatible change: the sdt getSdtContent methods now return ContentAccessor interface. For more on that interface, see "The ContentAccessor interface" in http://dev.plutext.org/svn/docx4j/trunk ... arted.html

Depending on responses to this thread, I'll produce a 2.7.0-beta, and following that 2.7.0 proper.

cheers .. Jason

[davebrown]

Great news, Jason. Please see my patches just posted. It would be great if you could have a look at those pre-2.7.0.

As far as compatibility, I've been working off of trunk snapshots, and so I've adapted to the ContentAccessor change already.

[marcel]

1) When releasing, could you include the sources and javadocs when deploying to the m2 repo?
E.g. do a

Code: Select all

mvn javadoc:jar source:jar deploy

when deploying to http://dev.plutext.org/svn/docx4j/trunk ... cx4j/x.x.x?

2) In the Maven POM: Could you put the repository into a by-default active profile?
This 'maven pattern' avoids some issues when one is behind a http proxy or using a maven proxy.

Something like this:

Code: Select all

...
<profiles>
  <profile>
    <id>docx4j-repositories</id>
    <repositories>...</repositories>
    <pluginRepositories>...</pluginRepositories>
    <activation>
      <file>
        <missing>AFileWhichDoesNotExist.WeNeedThisProfileAlways</missing>
      </file>
    </activation>
  </profile>
</profiles>
...


The trick is the auto activation: when included as a dependency in another project, the profile is not active (and therefore will not slow down the other project as Maven will in this case not fetch from the remote docx4j repo). It will only active by default for docx4j development.

In other words, maven projects using docx4j can control which repo they'll use for fetching docx4j and can use a maven proxy.

Looking forward to 2.7.0,
Marcel

[jason]

Thanks Marcel; there have been a few other suggestions re mvn improvements. I'll incorporate them and then make a post asking those like you who know more about mvn than I to validate the result.