ODF Toolkit
  1. ODF Toolkit
  2. ODFTOOLKIT-1

ODFDOM JAR should be accessible on common Maven repository servers

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: simple-odfdom-0.8
    • Fix Version/s: odfdom-0.8.7
    • Component/s: java
    • Labels:
      None
    • Environment:
      Operating System: All
      Platform: All

      Description

      The overall goal is to get the same feature set as with Ant before using Maven.

      We should try to stick with Maven's default structure:
      http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

      Maven is a declarative tool, adapting the conventions keep our settings small and give other Maven users an easy understanding of our structure.

      Furthermore the codegen directory should be an own external Maven plug-in being called relaxng2template only being used, when the code will be generated.
      Yet uncertain when this and the performance test will taken place in the Maven life cycle and if at all in general.

      1. ASF.LICENSE.NOT.GRANTED--resource_move.patch
        35 kB
        Svante Schubert
      2. ASF.LICENSE.NOT.GRANTED--resource_cleanup
        27 kB
        Benson Margulies
      3. ASF.LICENSE.NOT.GRANTED--maven-patches.zip
        72 kB
        Svante Schubert
      4. ASF.LICENSE.NOT.GRANTED--codegen.rearrange
        276 kB
        Benson Margulies
      5. ASF.LICENSE.NOT.GRANTED--codegen.rearrange
        973 kB
        Benson Margulies
      6. ASF.LICENSE.NOT.GRANTED--bug5-nexus.patch
        6 kB
        Svante Schubert
      7. ASF.LICENSE.NOT.GRANTED--adapt-developer+schema2template.zip
        6 kB
        bluezio2
      8. ASF.LICENSE.NOT.GRANTED--adapt-all.zip
        9 kB
        bluezio2

        Issue Links

          Activity

          Hide
          bluezio2 added a comment -

          Hi Svante,

          (In reply to comment #26)
          > On the other hand if you got Nexus UI, it would be great if you could remove
          > those SNAPSHOTs as I fear they might be mistaken as the latest.

          They mean the Web interface, I think. You just have to log into oss.sonatype.org with the Sonatype JIRA username and password.

          Anyway, it's good to know snapshots are so easy to remove. Following the instructions in your link, I have removed the 0.9-SNAPSHOT versions from the Sonatype repository.

          Enjoy your weekend as well,
          Antonio

          Show
          bluezio2 added a comment - Hi Svante, (In reply to comment #26) > On the other hand if you got Nexus UI, it would be great if you could remove > those SNAPSHOTs as I fear they might be mistaken as the latest. They mean the Web interface, I think. You just have to log into oss.sonatype.org with the Sonatype JIRA username and password. Anyway, it's good to know snapshots are so easy to remove. Following the instructions in your link, I have removed the 0.9-SNAPSHOT versions from the Sonatype repository. Enjoy your weekend as well, Antonio
          Hide
          Svante Schubert added a comment -

          When I read correctly:
          https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-7a.2.PublishSnapshots

          I just have to deploy at least 5 new snapshots after the last 0.9 and in 15 days the 0.9 SNAPSHOTs will be removed, or I have to deploy Nexus UI and remove it easily.
          As the Nexus UI is not a quick task, I just wait 15 days.

          On the other hand if you got Nexus UI, it would be great if you could remove those SNAPSHOTs as I fear they might be mistaken as the latest.

          Have a nice week-end,
          Svante

          Show
          Svante Schubert added a comment - When I read correctly: https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-7a.2.PublishSnapshots I just have to deploy at least 5 new snapshots after the last 0.9 and in 15 days the 0.9 SNAPSHOTs will be removed, or I have to deploy Nexus UI and remove it easily. As the Nexus UI is not a quick task, I just wait 15 days. On the other hand if you got Nexus UI, it would be great if you could remove those SNAPSHOTs as I fear they might be mistaken as the latest. Have a nice week-end, Svante
          Hide
          bluezio2 added a comment -

          Hi Svante,

          (In reply to comment #24)
          > One thing puzzles me, is there a way to get rid of the previous test
          > 0.9-SNAPSHOT at
          > https://oss.sonatype.org/content/repositories/snapshots/org/odftoolkit/odfdom-java/0.9-SNAPSHOT/
          > and
          > https://oss.sonatype.org/content/groups/public/org/odftoolkit/odfdom-java/
          >
          > The versioning has changed, we plan to iterate with 0.8.x until the API is
          > stable and let the 0.9 become a beta for a stable API.

          As far as I know, I'm afraid there isn't. Once you deploy a SNAPSHOT, it's usually there until you replace it with a SNAPSHOT or a release with an equal or greater version. It should just cleanly go away when you do release 0.9.

          You're welcome,
          Antonio

          Show
          bluezio2 added a comment - Hi Svante, (In reply to comment #24) > One thing puzzles me, is there a way to get rid of the previous test > 0.9-SNAPSHOT at > https://oss.sonatype.org/content/repositories/snapshots/org/odftoolkit/odfdom-java/0.9-SNAPSHOT/ > and > https://oss.sonatype.org/content/groups/public/org/odftoolkit/odfdom-java/ > > The versioning has changed, we plan to iterate with 0.8.x until the API is > stable and let the 0.9 become a beta for a stable API. As far as I know, I'm afraid there isn't. Once you deploy a SNAPSHOT, it's usually there until you replace it with a SNAPSHOT or a release with an equal or greater version. It should just cleanly go away when you do release 0.9. You're welcome, Antonio
          Hide
          Svante Schubert added a comment -

          Hi Antonio,

          I finally finished my testing with Maven and it looks quite good.

          Realized that a SNAPSHOT release were uploaded without source JAR due to a misplaced source-plugin settings in pom.xml
          But the latest look good:
          https://oss.sonatype.org/content/repositories/snapshots/org/odftoolkit/odfdom-java/0.8.7-SNAPSHOT/

          One thing puzzles me, is there a way to get rid of the previous test 0.9-SNAPSHOT at
          https://oss.sonatype.org/content/repositories/snapshots/org/odftoolkit/odfdom-java/0.9-SNAPSHOT/
          and
          https://oss.sonatype.org/content/groups/public/org/odftoolkit/odfdom-java/

          The versioning has changed, we plan to iterate with 0.8.x until the API is stable and let the 0.9 become a beta for a stable API.

          Thanks in advance,
          Svante

          Show
          Svante Schubert added a comment - Hi Antonio, I finally finished my testing with Maven and it looks quite good. Realized that a SNAPSHOT release were uploaded without source JAR due to a misplaced source-plugin settings in pom.xml But the latest look good: https://oss.sonatype.org/content/repositories/snapshots/org/odftoolkit/odfdom-java/0.8.7-SNAPSHOT/ One thing puzzles me, is there a way to get rid of the previous test 0.9-SNAPSHOT at https://oss.sonatype.org/content/repositories/snapshots/org/odftoolkit/odfdom-java/0.9-SNAPSHOT/ and https://oss.sonatype.org/content/groups/public/org/odftoolkit/odfdom-java/ The versioning has changed, we plan to iterate with 0.8.x until the API is stable and let the 0.9 become a beta for a stable API. Thanks in advance, Svante
          Hide
          Svante Schubert added a comment -

          Closing the issue, if there is any problem, please reopen this issue.

          Cheers,
          Svante

          Show
          Svante Schubert added a comment - Closing the issue, if there is any problem, please reopen this issue. Cheers, Svante
          Hide
          Svante Schubert added a comment -

          Hi Antonio,

          thanks for your help. I have not uploaded a new patch, but tested today some slightly changed pom.xml to upload 0.8.7-SNAPSHOT releases for

          odfdom~taglets
          odfdom~schema2template
          odfdom~developer

          I even tested a full 0.8.7 release with the taglets repository using the Maven release plugin:
          odfdom~taglets

          Therefore instead of new patches, I will upload the latest version to the repository, so you might see if this already fulfils your needs.

          PS: The major difference from your patch was that I removed all repositories from all pom.xml, I read finally all your references you sent me like:
          http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/

          Show
          Svante Schubert added a comment - Hi Antonio, thanks for your help. I have not uploaded a new patch, but tested today some slightly changed pom.xml to upload 0.8.7-SNAPSHOT releases for odfdom~taglets odfdom~schema2template odfdom~developer I even tested a full 0.8.7 release with the taglets repository using the Maven release plugin: odfdom~taglets Therefore instead of new patches, I will upload the latest version to the repository, so you might see if this already fulfils your needs. PS: The major difference from your patch was that I removed all repositories from all pom.xml, I read finally all your references you sent me like: http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/
          Hide
          bluezio2 added a comment -

          Hi Svante,

          (In reply to comment #20)
          > thanks for the information, you provided.

          You're welcome .

          > I did indeed only a deploy to the local SVN repository first, to test if this
          > would work. Thinking about it, perhaps we should drop those and use in the
          > future only the Sonatype OSS repository to avoid duplicate/inconsistent data,
          > or do you see an advantage in keeping both?

          Well, everyone with commit access can deploy artifacts to the SVN repository, but only you and I can deploy to the Sonatype repository. However, if someone wants to try an artifact, all they have to do is install the artifact to their local repository ("mvn install"). I don't really think it's needed anymore: I just kept it to ensure a smooth transition.

          > Even the Sonar repository has to provided, is there no default repository?
          > In this case every Maven user have to manually update their settings.xml,
          > which is not really a usability advantage.

          It is a bit cumbersome, but thankfully it is only required for SNAPSHOT versions. Releases are automatically synced to Maven central, so they are available for everyone out of the box.

          > Therefore after your reply, perhaps the adaption of pom.xml to drop the old SVN
          > at all, I will start testing to deploy SNAPSHOTS to Sonar Rep for all our three
          > repositories, so it is likely that the deploy of the release 0.8.7 runs smooth.

          Sounds good. If you need any help, just ask .

          Regards,
          Antonio

          Show
          bluezio2 added a comment - Hi Svante, (In reply to comment #20) > thanks for the information, you provided. You're welcome . > I did indeed only a deploy to the local SVN repository first, to test if this > would work. Thinking about it, perhaps we should drop those and use in the > future only the Sonatype OSS repository to avoid duplicate/inconsistent data, > or do you see an advantage in keeping both? Well, everyone with commit access can deploy artifacts to the SVN repository, but only you and I can deploy to the Sonatype repository. However, if someone wants to try an artifact, all they have to do is install the artifact to their local repository ("mvn install"). I don't really think it's needed anymore: I just kept it to ensure a smooth transition. > Even the Sonar repository has to provided, is there no default repository? > In this case every Maven user have to manually update their settings.xml, > which is not really a usability advantage. It is a bit cumbersome, but thankfully it is only required for SNAPSHOT versions. Releases are automatically synced to Maven central, so they are available for everyone out of the box. > Therefore after your reply, perhaps the adaption of pom.xml to drop the old SVN > at all, I will start testing to deploy SNAPSHOTS to Sonar Rep for all our three > repositories, so it is likely that the deploy of the release 0.8.7 runs smooth. Sounds good. If you need any help, just ask . Regards, Antonio
          Hide
          Svante Schubert added a comment -

          Hi Antonio,

          thanks for the information, you provided.
          My answers below:

          (In reply to comment #19)
          >
          > > TESTING:
          > > To be able to test, I have first uploaded 0.8.7-SNAPSHOT from taglets and
          > > schema2template. This seems to work fine.
          >
          > Sorry, but I can't find any 0.8.7-SNAPSHOT artifact when searching for our
          > groupId (org.odftoolkit) at oss.sonatype.org. I suspect that you have run "mvn
          > deploy" instead of "mvn -P sonatype deploy", as suggested in the POMs. The
          > first command deploys to the old SVN-based Maven repository (just as a
          > transitional measure), while the second one signs the artifacts (Maven Central
          > sync requirement, sorry) and deploys them to the OSS Sonatype server.

          I did indeed only a deploy to the local SVN repository first, to test if this would work. Thinking about it, perhaps we should drop those and use in the future only the Sonatype OSS repository to avoid duplicate/inconsistent data, or do you see an advantage in keeping both?

          > You will
          > need a GPG keypair in order to deploy to the OSS Sonatype server. Please see
          > this webpage for instructions:
          >
          > http://www.sonatype.com/people/2010/01/how-to-generate-pgp-signatures-with-maven/
          >
          Thanks for the hint, I will take care of that.

          > The POMs do not contain any <repository> or <pluginRepository> elements now,
          > since they are deprecated and will be soon forbidden for any artifact being
          > synced into Maven Central. To make Maven aware of the OSS Sonatype repository,
          > you must add the appropriate <repository> and <pluginRepository> entries to
          > your Maven settings.xml file, like this:
          >
          > <settings>
          > ...
          > <repositories>
          > ...
          >
          Even the Sonar repository has to provided, is there no default repository?
          In this case every Maven user have to manually update their settings.xml, which is not really a usability advantage.

          Therefore after your reply, perhaps the adaption of pom.xml to drop the old SVN at all, I will start testing to deploy SNAPSHOTS to Sonar Rep for all our three repositories, so it is likely that the deploy of the release 0.8.7 runs smooth.

          Thanks,
          Antonio

          Show
          Svante Schubert added a comment - Hi Antonio, thanks for the information, you provided. My answers below: (In reply to comment #19) > > > TESTING: > > To be able to test, I have first uploaded 0.8.7-SNAPSHOT from taglets and > > schema2template. This seems to work fine. > > Sorry, but I can't find any 0.8.7-SNAPSHOT artifact when searching for our > groupId (org.odftoolkit) at oss.sonatype.org. I suspect that you have run "mvn > deploy" instead of "mvn -P sonatype deploy", as suggested in the POMs. The > first command deploys to the old SVN-based Maven repository (just as a > transitional measure), while the second one signs the artifacts (Maven Central > sync requirement, sorry) and deploys them to the OSS Sonatype server. I did indeed only a deploy to the local SVN repository first, to test if this would work. Thinking about it, perhaps we should drop those and use in the future only the Sonatype OSS repository to avoid duplicate/inconsistent data, or do you see an advantage in keeping both? > You will > need a GPG keypair in order to deploy to the OSS Sonatype server. Please see > this webpage for instructions: > > http://www.sonatype.com/people/2010/01/how-to-generate-pgp-signatures-with-maven/ > Thanks for the hint, I will take care of that. > The POMs do not contain any <repository> or <pluginRepository> elements now, > since they are deprecated and will be soon forbidden for any artifact being > synced into Maven Central. To make Maven aware of the OSS Sonatype repository, > you must add the appropriate <repository> and <pluginRepository> entries to > your Maven settings.xml file, like this: > > <settings> > ... > <repositories> > ... > Even the Sonar repository has to provided, is there no default repository? In this case every Maven user have to manually update their settings.xml, which is not really a usability advantage. Therefore after your reply, perhaps the adaption of pom.xml to drop the old SVN at all, I will start testing to deploy SNAPSHOTS to Sonar Rep for all our three repositories, so it is likely that the deploy of the release 0.8.7 runs smooth. Thanks, Antonio
          Hide
          bluezio2 added a comment -

          Hi Svante,

          (In reply to comment #17)
          > One note ahead: I noticed that you reordered several elements of the pom.xml.
          > As the ordering might be a matter of taste, I try to stick on the given order
          > of the reference pom.xml:
          > http://maven.apache.org/pom.html
          > Hopefully to cover most tastes.

          You're right, that's much better.

          > TESTING:
          > To be able to test, I have first uploaded 0.8.7-SNAPSHOT from taglets and
          > schema2template. This seems to work fine.

          Sorry, but I can't find any 0.8.7-SNAPSHOT artifact when searching for our groupId (org.odftoolkit) at oss.sonatype.org. I suspect that you have run "mvn deploy" instead of "mvn -P sonatype deploy", as suggested in the POMs. The first command deploys to the old SVN-based Maven repository (just as a transitional measure), while the second one signs the artifacts (Maven Central sync requirement, sorry) and deploys them to the OSS Sonatype server. You will need a GPG keypair in order to deploy to the OSS Sonatype server. Please see this webpage for instructions:

          http://www.sonatype.com/people/2010/01/how-to-generate-pgp-signatures-with-maven/

          The POMs do not contain any <repository> or <pluginRepository> elements now, since they are deprecated and will be soon forbidden for any artifact being synced into Maven Central. To make Maven aware of the OSS Sonatype repository, you must add the appropriate <repository> and <pluginRepository> entries to your Maven settings.xml file, like this:

          <settings>
          ...
          <repositories>
          ...
          <repository>
          <id>sonatype-public</id>
          <url>https://oss.sonatype.org/content/groups/public</url>
          <snapshots><enabled>true</enabled></snapshots>
          <releases><enabled>true</enabled></releases>
          </repository>
          ...
          </repositories>
          <pluginRepositories>
          ...
          <pluginRepository>
          <id>sonatype-public</id>
          <url>https://oss.sonatype.org/content/groups/public</url>
          <snapshots><enabled>true</enabled></snapshots>
          <releases><enabled>true</enabled></releases>
          </pluginRepository>
          ...
          </pluginRepositories>
          </settings>

          > Any clue?

          It's only a matter of deploying to the Sonatype OSS repository and setting up your settings.xml. The artifacts were being deployed to the wrong repository and Maven was not told to look for artifacts about the Sonatype OSS repository.

          > Would be great if you could glimpse over the changes ones again as a final
          > check.

          I have looked at the patches and they look good .

          You're welcome,
          Antonio

          Show
          bluezio2 added a comment - Hi Svante, (In reply to comment #17) > One note ahead: I noticed that you reordered several elements of the pom.xml. > As the ordering might be a matter of taste, I try to stick on the given order > of the reference pom.xml: > http://maven.apache.org/pom.html > Hopefully to cover most tastes. You're right, that's much better. > TESTING: > To be able to test, I have first uploaded 0.8.7-SNAPSHOT from taglets and > schema2template. This seems to work fine. Sorry, but I can't find any 0.8.7-SNAPSHOT artifact when searching for our groupId (org.odftoolkit) at oss.sonatype.org. I suspect that you have run "mvn deploy" instead of "mvn -P sonatype deploy", as suggested in the POMs. The first command deploys to the old SVN-based Maven repository (just as a transitional measure), while the second one signs the artifacts (Maven Central sync requirement, sorry) and deploys them to the OSS Sonatype server. You will need a GPG keypair in order to deploy to the OSS Sonatype server. Please see this webpage for instructions: http://www.sonatype.com/people/2010/01/how-to-generate-pgp-signatures-with-maven/ The POMs do not contain any <repository> or <pluginRepository> elements now, since they are deprecated and will be soon forbidden for any artifact being synced into Maven Central. To make Maven aware of the OSS Sonatype repository, you must add the appropriate <repository> and <pluginRepository> entries to your Maven settings.xml file, like this: <settings> ... <repositories> ... <repository> <id>sonatype-public</id> <url> https://oss.sonatype.org/content/groups/public </url> <snapshots><enabled>true</enabled></snapshots> <releases><enabled>true</enabled></releases> </repository> ... </repositories> <pluginRepositories> ... <pluginRepository> <id>sonatype-public</id> <url> https://oss.sonatype.org/content/groups/public </url> <snapshots><enabled>true</enabled></snapshots> <releases><enabled>true</enabled></releases> </pluginRepository> ... </pluginRepositories> </settings> > Any clue? It's only a matter of deploying to the Sonatype OSS repository and setting up your settings.xml. The artifacts were being deployed to the wrong repository and Maven was not told to look for artifacts about the Sonatype OSS repository. > Would be great if you could glimpse over the changes ones again as a final > check. I have looked at the patches and they look good . You're welcome, Antonio
          Hide
          Svante Schubert added a comment -

          Created an attachment (id=447)
          ZIP with a patch for each active odfdom repository (taglets, schema2template and odfdom)

          Hi Antonio,

          attached the ZIP with three patches to review.
          The fourth patch is a combined patch for ODFDOM including as well the two previous patches of ODFTOOLKIT-43 for ODFDOM.

          The single ODFDOM patch is only for optical review and might give complications as it is as well based on those none master repository patches.

          Thanks,
          Svante

          Show
          Svante Schubert added a comment - Created an attachment (id=447) ZIP with a patch for each active odfdom repository (taglets, schema2template and odfdom) Hi Antonio, attached the ZIP with three patches to review. The fourth patch is a combined patch for ODFDOM including as well the two previous patches of ODFTOOLKIT-43 for ODFDOM. The single ODFDOM patch is only for optical review and might give complications as it is as well based on those none master repository patches. Thanks, Svante
          Hide
          Svante Schubert added a comment -

          Hi Antonio,

          all other problems for the next release have been finally fixed (hopefully) and the patches are now under review.

          Therefore I have integrated your patches to the repositories of

          odfdom~taglets
          odfdom~schema2template
          odfdom~developer

          For the latter odfdom~developer I been added the changes not on the latest public version, but based on two patches attached to bug66, which are yet under review and not pushed, but everything is bundled in a single patch in the attached ZIP and stand-alone only the pom.xml related part.

          One note ahead: I noticed that you reordered several elements of the pom.xml.
          As the ordering might be a matter of taste, I try to stick on the given order of the reference pom.xml:
          http://maven.apache.org/pom.html
          Hopefully to cover most tastes.

          TESTING:
          To be able to test, I have first uploaded 0.8.7-SNAPSHOT from taglets and schema2template. This seems to work fine.

          I adapted the pom.xml of odfdom~developer in a way to use those 0.8.7-SNAPSHOTs.

          The taglets are used to exchange template-strings with hyperlink references to the ODF specification in the JavaDoc.
          Therefore a "mvn javadoc:javadoc" should work and the created javadoc documentation, should reference to attribute, elements and datatypes.
          Strangely, I get the error message that no 0.8.7-SNAPSHOT of taglets can be found. Did I lost some change of yours?

          The schema2template codegeneration is used via "mvn -P codegen" and works fine for me using JDK5, again the taglets artifact could not be found.

          Reason: Unable to download the artifact from any repository
          org.odftoolkit:taglets:pom:0.8.7-SNAPSHOT

          Any clue?

          Would be great if you could glimpse over the changes ones again as a final check.

          Thanks in advance,
          Svante

          Show
          Svante Schubert added a comment - Hi Antonio, all other problems for the next release have been finally fixed (hopefully) and the patches are now under review. Therefore I have integrated your patches to the repositories of odfdom~taglets odfdom~schema2template odfdom~developer For the latter odfdom~developer I been added the changes not on the latest public version, but based on two patches attached to bug66, which are yet under review and not pushed, but everything is bundled in a single patch in the attached ZIP and stand-alone only the pom.xml related part. One note ahead: I noticed that you reordered several elements of the pom.xml. As the ordering might be a matter of taste, I try to stick on the given order of the reference pom.xml: http://maven.apache.org/pom.html Hopefully to cover most tastes. TESTING: To be able to test, I have first uploaded 0.8.7-SNAPSHOT from taglets and schema2template. This seems to work fine. I adapted the pom.xml of odfdom~developer in a way to use those 0.8.7-SNAPSHOTs. The taglets are used to exchange template-strings with hyperlink references to the ODF specification in the JavaDoc. Therefore a "mvn javadoc:javadoc" should work and the created javadoc documentation, should reference to attribute, elements and datatypes. Strangely, I get the error message that no 0.8.7-SNAPSHOT of taglets can be found. Did I lost some change of yours? The schema2template codegeneration is used via "mvn -P codegen" and works fine for me using JDK5, again the taglets artifact could not be found. Reason: Unable to download the artifact from any repository org.odftoolkit:taglets:pom:0.8.7-SNAPSHOT Any clue? Would be great if you could glimpse over the changes ones again as a final check. Thanks in advance, Svante
          Hide
          bluezio2 added a comment -

          Sounds good to me . If you need any help, just ask.

          Show
          bluezio2 added a comment - Sounds good to me . If you need any help, just ask.
          Hide
          Svante Schubert added a comment -

          Hi Antonio,

          I reviewed your issue and it looks very good.

          The reason why it is not yet integrated is, that I would like to finally test the patch by uploading a full release version - the upcoming 0.8.7 release - to the sonatype repository.

          Assigned the issue therefore to myself.

          My current plan is to integrate this patch at the end for 0.8.7, which might be this week, but depends on the progress of issue 91, 161 and 219. But I am still optimistic..

          PS: Testing it with a snapshot does not work, as IBM based its Simple API on the last snapshot and I do not want to risk to exchange it accidentally.

          Regards,
          Svante

          Show
          Svante Schubert added a comment - Hi Antonio, I reviewed your issue and it looks very good. The reason why it is not yet integrated is, that I would like to finally test the patch by uploading a full release version - the upcoming 0.8.7 release - to the sonatype repository. Assigned the issue therefore to myself. My current plan is to integrate this patch at the end for 0.8.7, which might be this week, but depends on the progress of issue 91, 161 and 219. But I am still optimistic.. PS: Testing it with a snapshot does not work, as IBM based its Simple API on the last snapshot and I do not want to risk to exchange it accidentally. Regards, Svante
          Hide
          bluezio2 added a comment -

          Svante, did you find time to review the patch?

          Show
          bluezio2 added a comment - Svante, did you find time to review the patch?
          Hide
          bluezio2 added a comment -

          Created an attachment (id=423)
          Patch which adapts the three repositories

          Since odfdom~taglets was simpler than I thought, I adapted it right away. I have deployed and promoted version 0.8.5, with which we build odfdom-java now. It should be available in Central soon.

          I think the POMs could be further simplified if we had a common parent POM, but I don't know where I should put it and how to name it.

          By the way: Maven Central does not host snapshots, but the OSS Sonatype repository does. I suggest that developers add something like this to their ~/.m2/settings.xml, to use the snapshots deployed to the Sonatype Nexus space:

          <profiles>
          <profile>
          <id>default</id>
          <activation>
          <activeByDefault>true</activeByDefault>
          </activation>
          <repositories>
          <repository>
          <id>sonatype-public-snapshots</id>
          <url>https://oss.sonatype.org/content/groups/public-snapshots/</url>
          <snapshots><enabled>true</enabled></snapshots>
          </repository>
          </repositories>
          <pluginRepositories>
          <pluginRepository>
          <id>sonatype-public-snapshots</id>
          <url>https://oss.sonatype.org/content/groups/public-snapshots/</url>
          <snapshots><enabled>true</enabled></snapshots>
          </pluginRepository>
          </pluginRepositories>
          </profile>
          </profiles>

          Show
          bluezio2 added a comment - Created an attachment (id=423) Patch which adapts the three repositories Since odfdom~taglets was simpler than I thought, I adapted it right away. I have deployed and promoted version 0.8.5, with which we build odfdom-java now. It should be available in Central soon. I think the POMs could be further simplified if we had a common parent POM, but I don't know where I should put it and how to name it. By the way: Maven Central does not host snapshots, but the OSS Sonatype repository does. I suggest that developers add something like this to their ~/.m2/settings.xml, to use the snapshots deployed to the Sonatype Nexus space: <profiles> <profile> <id>default</id> <activation> <activeByDefault>true</activeByDefault> </activation> <repositories> <repository> <id>sonatype-public-snapshots</id> <url> https://oss.sonatype.org/content/groups/public-snapshots/ </url> <snapshots><enabled>true</enabled></snapshots> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>sonatype-public-snapshots</id> <url> https://oss.sonatype.org/content/groups/public-snapshots/ </url> <snapshots><enabled>true</enabled></snapshots> </pluginRepository> </pluginRepositories> </profile> </profiles>
          Hide
          bluezio2 added a comment -

          Oh, by the way: the new patches use <uniqueVersion>true</uniqueVersion> for the snapshot repositories, so we get timestamps whenever we deploy a -SNAPSHOT version to the SVN or the Sonatype snapshot repositories.

          Show
          bluezio2 added a comment - Oh, by the way: the new patches use <uniqueVersion>true</uniqueVersion> for the snapshot repositories, so we get timestamps whenever we deploy a -SNAPSHOT version to the SVN or the Sonatype snapshot repositories.
          Hide
          bluezio2 added a comment -

          Created an attachment (id=422)
          Revised patches for adapting odfdom~developer and odfdom~schema2template

          I have revised the patches so using both the old (SVN-based) and the new (Sonatype OSS-based) repositories is easier.

          Both for odfdom~developer and odfdom~schema2template, deploying to Sonatype now consists of:

          mvn -P sonatype deploy

          For deploying to the usual SVN repository, just use "mvn deploy". The sonatype profile requires GPG signing, which is needed for Maven Central sync to work.

          I have cleaned up the POMs for odfdom~schema2template, using the aggregate POM as the parent POM for schema2template and schema2template-maven-plugin. That way, we can reuse some information which is required for Maven Central and we can simplify the POMs.

          I have deployed and promoted release 0.8.6 of the odfdom~schema2template artifacts to Sonatype. They should reach Central in a few hours. "mvn -P codegen" seems to work just fine that way.

          Svante, could you have a look at the patches? If you're OK with them, I'll follow the same approach with the ~taglets repository.

          Show
          bluezio2 added a comment - Created an attachment (id=422) Revised patches for adapting odfdom~developer and odfdom~schema2template I have revised the patches so using both the old (SVN-based) and the new (Sonatype OSS-based) repositories is easier. Both for odfdom~developer and odfdom~schema2template, deploying to Sonatype now consists of: mvn -P sonatype deploy For deploying to the usual SVN repository, just use "mvn deploy". The sonatype profile requires GPG signing, which is needed for Maven Central sync to work. I have cleaned up the POMs for odfdom~schema2template, using the aggregate POM as the parent POM for schema2template and schema2template-maven-plugin. That way, we can reuse some information which is required for Maven Central and we can simplify the POMs. I have deployed and promoted release 0.8.6 of the odfdom~schema2template artifacts to Sonatype. They should reach Central in a few hours. "mvn -P codegen" seems to work just fine that way. Svante, could you have a look at the patches? If you're OK with them, I'll follow the same approach with the ~taglets repository.
          Hide
          Svante Schubert added a comment -

          Hi Antonio,

          as you stated before, it seems on the public repository they keep a minimum of 5 snapshots, while removing snapshots older than 15 days:

          https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-7a.2.PublishSnapshots

          You wrote:
          "I've had a look at their Snapshots group and it does look like the snapshots get their correct timestamps. We just have to be careful and ensure that <uniqueVersion> is set to true for the <snapshotRepository> in the <distributionManagement> section of the POM."

          I suggest, we enable the <uniqueVersion> as well with this patch.

          PS: Added a patch within http://odftoolkit.org/bugzilla/show_bug.cgi?id=242 to disable a test that fails on some platforms and this issue #5 dependent of #242.

          Best Regards,
          Svante

          Show
          Svante Schubert added a comment - Hi Antonio, as you stated before, it seems on the public repository they keep a minimum of 5 snapshots, while removing snapshots older than 15 days: https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-7a.2.PublishSnapshots You wrote: "I've had a look at their Snapshots group and it does look like the snapshots get their correct timestamps. We just have to be careful and ensure that <uniqueVersion> is set to true for the <snapshotRepository> in the <distributionManagement> section of the POM." I suggest, we enable the <uniqueVersion> as well with this patch. PS: Added a patch within http://odftoolkit.org/bugzilla/show_bug.cgi?id=242 to disable a test that fails on some platforms and this issue #5 dependent of #242. Best Regards, Svante
          Hide
          bluezio2 added a comment -

          Hi Svante,

          You can keep the <distributionManagement> if you want to keep the old SVN-based repository for the time being. It's not a problem for Maven Central, and you can just point to a different repository when performing the deployment. Like this:

          mvn clean deploy -DaltDeploymentRepository=sonatype-nexus-staging::default::https://oss.sonatype.org/service/local/staging/deploy/maven2

          You'll need to add a <server> entry with the sonatype-nexus-staging <id> to your settings.xml file with your Sonatype JIRA credentials. You will also need to generate your own GPG key and distribute it to hkp://pgp.mit.edu (see [1]). Basically, we need to sign with GPG all artifacts, to help protect them from file corruption and attackers. It doesn't really matter if it's your key or mine.

          I'll have a look at those issues as soon as I can .

          [1]: https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven

          Regards,
          Antonio

          Show
          bluezio2 added a comment - Hi Svante, You can keep the <distributionManagement> if you want to keep the old SVN-based repository for the time being. It's not a problem for Maven Central, and you can just point to a different repository when performing the deployment. Like this: mvn clean deploy -DaltDeploymentRepository=sonatype-nexus-staging::default:: https://oss.sonatype.org/service/local/staging/deploy/maven2 You'll need to add a <server> entry with the sonatype-nexus-staging <id> to your settings.xml file with your Sonatype JIRA credentials. You will also need to generate your own GPG key and distribute it to hkp://pgp.mit.edu (see [1] ). Basically, we need to sign with GPG all artifacts, to help protect them from file corruption and attackers. It doesn't really matter if it's your key or mine. I'll have a look at those issues as soon as I can . [1] : https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven Regards, Antonio
          Hide
          Svante Schubert added a comment -

          Created an attachment (id=418)
          ADAPT POM TO DEPLOY ODFDOM-JAVA TO SONATYPE OSS NEXUS SERVER

          I have applied the patches from the odfdom dev list

          http://odftoolkit.org/projects/odfdom/lists/dev/archive/2010-11/message/5

          to the latest revision and combined them to a single patch.

          It seems we can neglect as well the following from the pom.xml.

          <distributionManagement><!-- where outcome is being delivered -->
          <repository>
          <id>odfdom-releases</id>
          <name>ODFDOM Release</name>
          <url>svn:https://odftoolkit.org/svn/odfdom~maven2/release/</url>
          <uniqueVersion>false</uniqueVersion>
          </repository>
          <snapshotRepository>
          <id>odfdom-snapshots</id>
          <name>ODFDOM Snapshot</name>
          <url>svn:https://odftoolkit.org/svn/odfdom~maven2/snapshot/</url>
          <uniqueVersion>false</uniqueVersion>
          </snapshotRepository>
          </distributionManagement>

          But the above neglection is not yet included in the patch.

          I only did some minor formatting changes:
          1) use TABS instead spaces and
          2) adapted the order according to the reference pom
          http://maven.apache.org/pom.html

          What is left to do:
          What causes problems is that for javadoc and ODFDOM source code generation we are dependent of two repositories that are not on the SONATYPE OSS NEXUS, neither.

          The Maven repositories are at:
          https://hg.odftoolkit.org/hg/odfdom~schema2template
          https://hg.odftoolkit.org/hg/odfdom~taglets

          The code generation via "mvn -P codegen" will not work with SONATYPE OSS NEXUS only, see
          http://odftoolkit.org/projects/odfdom/pages/Development#Maven

          We should move the schema2template as well to SONARTYPE and if it is not possible to integrate odfdom~taglets within ODFDOM bring it to SONATYPE as well.

          Regards,
          Svante

          Show
          Svante Schubert added a comment - Created an attachment (id=418) ADAPT POM TO DEPLOY ODFDOM-JAVA TO SONATYPE OSS NEXUS SERVER I have applied the patches from the odfdom dev list http://odftoolkit.org/projects/odfdom/lists/dev/archive/2010-11/message/5 to the latest revision and combined them to a single patch. It seems we can neglect as well the following from the pom.xml. <distributionManagement><!-- where outcome is being delivered --> <repository> <id>odfdom-releases</id> <name>ODFDOM Release</name> <url>svn: https://odftoolkit.org/svn/odfdom~maven2/release/ </url> <uniqueVersion>false</uniqueVersion> </repository> <snapshotRepository> <id>odfdom-snapshots</id> <name>ODFDOM Snapshot</name> <url>svn: https://odftoolkit.org/svn/odfdom~maven2/snapshot/ </url> <uniqueVersion>false</uniqueVersion> </snapshotRepository> </distributionManagement> But the above neglection is not yet included in the patch. I only did some minor formatting changes: 1) use TABS instead spaces and 2) adapted the order according to the reference pom http://maven.apache.org/pom.html What is left to do: What causes problems is that for javadoc and ODFDOM source code generation we are dependent of two repositories that are not on the SONATYPE OSS NEXUS, neither. The Maven repositories are at: https://hg.odftoolkit.org/hg/odfdom~schema2template https://hg.odftoolkit.org/hg/odfdom~taglets The code generation via "mvn -P codegen" will not work with SONATYPE OSS NEXUS only, see http://odftoolkit.org/projects/odfdom/pages/Development#Maven We should move the schema2template as well to SONARTYPE and if it is not possible to integrate odfdom~taglets within ODFDOM bring it to SONATYPE as well. Regards, Svante
          Hide
          Svante Schubert added a comment -

          Renamed issue to remainign task, moved issue to myself and going to ask back at the Kenai Team about a status.
          -Svante

          Show
          Svante Schubert added a comment - Renamed issue to remainign task, moved issue to myself and going to ask back at the Kenai Team about a status. -Svante
          Hide
          Svante Schubert added a comment -

          Steffen, could you please ask the Kenai team, if ODFDOM could receive a Hudson server? For Maven repository support and nightly (or patch-upload driven) builds.

          Thanks,
          Svante

          Show
          Svante Schubert added a comment - Steffen, could you please ask the Kenai team, if ODFDOM could receive a Hudson server? For Maven repository support and nightly (or patch-upload driven) builds. Thanks, Svante
          Hide
          Svante Schubert added a comment -

          Thanks to all your dedicated work on the Maven feature, Benson.

          To get the Maven feature run smoothly (getting ODFDOM and its dependent component as relaxng2template) into a Maven repository, Steffen will take care of it and will try to get Kenai/Odftoolkit.org enhancments to get things going.

          • Svante
          Show
          Svante Schubert added a comment - Thanks to all your dedicated work on the Maven feature, Benson. To get the Maven feature run smoothly (getting ODFDOM and its dependent component as relaxng2template) into a Maven repository, Steffen will take care of it and will try to get Kenai/Odftoolkit.org enhancments to get things going. Svante
          Hide
          Svante Schubert added a comment -

          Created an attachment (id=4)
          Move of resource directory via 'hg mv java/resource/* resource'

          After applying your patch, I still had the binary files.
          I used 'hg mv java/resource/* resource' and exported the patch from Netbeans using
          menu 'Versioning -> Exporting Uncomitted Changes...'

          Show
          Svante Schubert added a comment - Created an attachment (id=4) Move of resource directory via 'hg mv java/resource/* resource' After applying your patch, I still had the binary files. I used 'hg mv java/resource/* resource' and exported the patch from Netbeans using menu 'Versioning -> Exporting Uncomitted Changes...'
          Hide
          Benson Margulies added a comment -

          Created an attachment (id=3)
          Cleaning up resource pathnames

          Show
          Benson Margulies added a comment - Created an attachment (id=3) Cleaning up resource pathnames
          Hide
          Benson Margulies added a comment -

          Created an attachment (id=2)
          More complete change set

          Here's a more complete version: it pushes the templates themselves into the core directory so that someone could have a core tree without anything else.

          Show
          Benson Margulies added a comment - Created an attachment (id=2) More complete change set Here's a more complete version: it pushes the templates themselves into the core directory so that someone could have a core tree without anything else.
          Hide
          Benson Margulies added a comment -

          Created an attachment (id=1)
          Disconnect codegen projects from DOM proper

          Show
          Benson Margulies added a comment - Created an attachment (id=1) Disconnect codegen projects from DOM proper

            People

            • Assignee:
              bluezio2
              Reporter:
              Svante Schubert
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development