Re: Preflight and the 1.7 release
Hi, Andreas Lehmkuehler andr...@lehmi.de hat am 24. Mai 2012 um 23:01 geschrieben: Hi, Am 23.05.2012 23:17, schrieb Jukka Zitting: Hi, On Wed, May 23, 2012 at 11:03 PM, Leleu Ericeric.leleu@gmail.com wrote: 1 - Postpone the release until an unknown date. -1 We have code in other parts of PDFBox that should already be released. 2 - Make the 1.7 release excluding the preflight module (and XMPBox ?) from the reactor pom. A Warning in the README.txt explains why the module isn't deployed in 1.7. Sounds like a reasonable solution as preflight wasn't yet included in 1.6 so we're not taking anything away. Sounds easy but I'm experiencing am issue. If I exclude the preflight module the rat exlusion filter in preflight/pom.xml is disabled which leads to a build error as the main rat-check complains about 2 (binary) files without proper license. Any idea on how to disable the rat plugin on the commandline so that I don't have to alter the pom configuration? I'll continue tomorrow I just added the files in question temporarily to the exclusion filter in the parent pom. I somehow mixed up the version numbers when creating the branch. I reverted those changes. Sorry, for the inconvienience. I'm going to continue the release in the evening in aprox. 10 hours for now. BR, Andreas Lehmkühler
Re: Preflight and the 1.7 release
Hi, Am 23.05.2012 23:17, schrieb Jukka Zitting: Hi, On Wed, May 23, 2012 at 11:03 PM, Leleu Ericeric.leleu@gmail.com wrote: 1 - Postpone the release until an unknown date. -1 We have code in other parts of PDFBox that should already be released. 2 - Make the 1.7 release excluding the preflight module (and XMPBox ?) from the reactor pom. A Warning in the README.txt explains why the module isn't deployed in 1.7. Sounds like a reasonable solution as preflight wasn't yet included in 1.6 so we're not taking anything away. Sounds easy but I'm experiencing am issue. If I exclude the preflight module the rat exlusion filter in preflight/pom.xml is disabled which leads to a build error as the main rat-check complains about 2 (binary) files without proper license. Any idea on how to disable the rat plugin on the commandline so that I don't have to alter the pom configuration? I'll continue tomorrow BR, Andreas Lehmkühler
Re: Preflight and the 1.7 release
Hi, either way (excluding preflight or including it with warning) nothing prevents us from releasing a 1.8 release in a not so long time frame with the main addition a ready and usable preflight (and maybe first test version of new parser). Timo Am 23.05.2012 01:22, schrieb Ian Holsman: you could always put a big warning in the README, and mark xmpbox/preflight as deprecated. that should be sufficient for people not to use it while you work on doing the modification for 1.8. On May 23, 2012, at 7:11 AM, Guillaume Bailleul wrote: Hi, I agree with Andreas on that point : we should not release a code that will be dead soon. preflight (and xmpbox) has never been released. So, in my opinion, PDFBox 1.7 can be released without preflight... it bothers me for a project but I think it is the best thing to do. There is more than one issue linked with that: * Eric's new version will change the interface * xmpbox and jempbox should be merged (or at least one should desappear). The schedule with these modification is not compatible with 1.7 release. Guillaume On Tue, May 22, 2012 at 9:19 PM, Leleu Ericeric.leleu@gmail.com wrote: Hi, 2012/5/22 Andreas Lehmkuehlerandr...@lehmi.de Hi, Am 21.05.2012 20:38, schrieb Leleu Eric: Hi, I discussed with Guillaume about the Preflight refactoring and we have some questions about le preflight module and the next release. Hmmm, last minute timing I planned to cut the release now. I'm sorry :( The new preflight implementation will be more flexible and configurable. But it will have significant impact on the current implementation. (New interface, new way to load/validate the pdf...) Due to the 1.7 release that is coming soon, we would like to know how we should commit the preflight modifications without breaking the 1.7 release. Here is 3 possibilities : 1 - Exclude the preflight module from the release and work with the current code without compatibility with the old version. Any suggestions how to do that easily? I was thinking to comment the preflight declaration in the pdfbox-reactor pom file. Doing this, the source code will be present in the tagged version, but they will not have preflight jar in the repository with the version 1.7. It's may not be the best way to achieve that but it is probably the easiest way... 2 - Include the preflight module in the 1.7 release, the new implementation will be create in new packages. They will have no more modifications of the old implementation that will be marked as deprecated. Expect bug fix nothing will be done on old version, only new implementation will be improved (new configuration capabilities, new validation format...). Old version will be definitely removed in a further release (1.8 or 2.0 ?) 3 - Include the preflight module unchanged and release it. The new validation tool will be done in a new module (Present only in the 2.0 branch ?). They will have no more modifications of the old module that will be marked as deprecated. Expect bug fix nothing will be done on old version. Only new module will evolve (new configuration capabilities, new validation format...). I don't like the idea of releasing code for the first time which is already meant to be dead. What is your opinion about that ? IMHO, as there wasn't any Apache release of preflight the cleanest way would be to replace the old implementation using the new one. But there are some questions: - Is the new implementation completed? If not, when do you expect to be ready? No, it isn't. Hopefully I will finish the refactoring at the end of June (but without guaranty), so it will be quite late for the 1.7 release. :( - Is the new implementation a full replacement of the old one ? No, I thought that around 50% of the code will be reused. Depending on your answers and other opinions we might postpone the release for a couple of weeks. If you have any questions, do not hesitate. Don't hesitate to answer fast ;-) One more time, I'm really sorry to delay the pdfbox release. BR, Eric BR Andreas Lehmkühler BR, Eric -- Timo Boehme OntoChem GmbH H.-Damerow-Str. 4 06120 Halle/Saale T: +49 345 4780474 F: +49 345 4780471 timo.boe...@ontochem.com _ OntoChem GmbH Geschäftsführer: Dr. Lutz Weber Sitz: Halle / Saale Registergericht: Stendal Registernummer: HRB 215461 _
Re: Preflight and the 1.7 release
Hi, It seems that we have few choices : 1 - Postpone the release until an unknown date. 2 - Make the 1.7 release excluding the preflight module (and XMPBox ?) from the reactor pom. A Warning in the README.txt explains why the module isn't deployed in 1.7. 3 - Make the 1.7 release including preflight (and XMPBox?) with a specific version like 1.7-incubating. In addition, a warning in the README.txt explains that this module can evolve significantly. 4 - Make the 1.7 release with a warning in the README.txt For the three last options, all the code of the new preflight version will be done in a new package hierarchy. Both preflight versions will be fully independent. In version 1.8, Old version will be annoted as deprecated. In version 2.0, Old version will be removed. No choice is clearly satisfying but the best thing to do is probably the first one. If we can't wait, the clearest option for users is probably the third (incubating version of preflight (and may be XMPBox) ). What is your opinion ? BR, Eric 2012/5/23 Timo Boehme timo.boe...@ontochem.com Hi, either way (excluding preflight or including it with warning) nothing prevents us from releasing a 1.8 release in a not so long time frame with the main addition a ready and usable preflight (and maybe first test version of new parser). Timo Am 23.05.2012 01:22, schrieb Ian Holsman: you could always put a big warning in the README, and mark xmpbox/preflight as deprecated. that should be sufficient for people not to use it while you work on doing the modification for 1.8. On May 23, 2012, at 7:11 AM, Guillaume Bailleul wrote: Hi, I agree with Andreas on that point : we should not release a code that will be dead soon. preflight (and xmpbox) has never been released. So, in my opinion, PDFBox 1.7 can be released without preflight... it bothers me for a project but I think it is the best thing to do. There is more than one issue linked with that: * Eric's new version will change the interface * xmpbox and jempbox should be merged (or at least one should desappear). The schedule with these modification is not compatible with 1.7 release. Guillaume On Tue, May 22, 2012 at 9:19 PM, Leleu Ericeric.leleu@gmail.com wrote: Hi, 2012/5/22 Andreas Lehmkuehlerandr...@lehmi.de Hi, Am 21.05.2012 20:38, schrieb Leleu Eric: Hi, I discussed with Guillaume about the Preflight refactoring and we have some questions about le preflight module and the next release. Hmmm, last minute timing I planned to cut the release now. I'm sorry :( The new preflight implementation will be more flexible and configurable. But it will have significant impact on the current implementation. (New interface, new way to load/validate the pdf...) Due to the 1.7 release that is coming soon, we would like to know how we should commit the preflight modifications without breaking the 1.7 release. Here is 3 possibilities : 1 - Exclude the preflight module from the release and work with the current code without compatibility with the old version. Any suggestions how to do that easily? I was thinking to comment the preflight declaration in the pdfbox-reactor pom file. Doing this, the source code will be present in the tagged version, but they will not have preflight jar in the repository with the version 1.7. It's may not be the best way to achieve that but it is probably the easiest way... 2 - Include the preflight module in the 1.7 release, the new implementation will be create in new packages. They will have no more modifications of the old implementation that will be marked as deprecated. Expect bug fix nothing will be done on old version, only new implementation will be improved (new configuration capabilities, new validation format...). Old version will be definitely removed in a further release (1.8 or 2.0 ?) 3 - Include the preflight module unchanged and release it. The new validation tool will be done in a new module (Present only in the 2.0 branch ?). They will have no more modifications of the old module that will be marked as deprecated. Expect bug fix nothing will be done on old version. Only new module will evolve (new configuration capabilities, new validation format...). I don't like the idea of releasing code for the first time which is already meant to be dead. What is your opinion about that ? IMHO, as there wasn't any Apache release of preflight the cleanest way would be to replace the old implementation using the new one. But there are some questions: - Is the new implementation completed? If not, when do you expect to be ready? No, it isn't. Hopefully I will finish the refactoring at the end of June (but without guaranty), so it will be quite late for the 1.7 release. :( - Is the new implementation a full replacement of the old one ? No, I thought that around 50% of the code will be reused
Re: Preflight and the 1.7 release
Hi, On Wed, May 23, 2012 at 11:03 PM, Leleu Eric eric.leleu@gmail.com wrote: 1 - Postpone the release until an unknown date. -1 We have code in other parts of PDFBox that should already be released. 2 - Make the 1.7 release excluding the preflight module (and XMPBox ?) from the reactor pom. A Warning in the README.txt explains why the module isn't deployed in 1.7. Sounds like a reasonable solution as preflight wasn't yet included in 1.6 so we're not taking anything away. The note in README and/or release notes can refer to the new component(s) as a technology preview that's still being worked on and thus doesn't yet come with the usual stability and backwards compatibility guarantees. BR, Jukka Zitting
Re: Preflight and the 1.7 release
Hi, I would also vote for releasing 1.7 now and excluding the preflight module in this release. Best regards, Timo Jukka Zitting jukka.zitt...@gmail.com hat am 23. Mai 2012 um 23:17 geschrieben: On Wed, May 23, 2012 at 11:03 PM, Leleu Eric eric.leleu@gmail.com wrote: 1 - Postpone the release until an unknown date. -1 We have code in other parts of PDFBox that should already be released. 2 - Make the 1.7 release excluding the preflight module (and XMPBox ?) from the reactor pom. A Warning in the README.txt explains why the module isn't deployed in 1.7. Sounds like a reasonable solution as preflight wasn't yet included in 1.6 so we're not taking anything away. The note in README and/or release notes can refer to the new component(s) as a technology preview that's still being worked on and thus doesn't yet come with the usual stability and backwards compatibility guarantees. BR, Jukka Zitting
Re: Preflight and the 1.7 release
Hi, +1 for releasing 1.7 now without preflight and xmpbox I like the idea of not waiting so long before the 1.8 version with : * preflight * new parser * merged xmpbox and jempbox. BR, Guillaume On Thu, May 24, 2012 at 12:33 AM, timo.boe...@ontochem.com timo.boe...@ontochem.com wrote: Hi, I would also vote for releasing 1.7 now and excluding the preflight module in this release. Best regards, Timo Jukka Zitting jukka.zitt...@gmail.com hat am 23. Mai 2012 um 23:17 geschrieben: On Wed, May 23, 2012 at 11:03 PM, Leleu Eric eric.leleu@gmail.com wrote: 1 - Postpone the release until an unknown date. -1 We have code in other parts of PDFBox that should already be released. 2 - Make the 1.7 release excluding the preflight module (and XMPBox ?) from the reactor pom. A Warning in the README.txt explains why the module isn't deployed in 1.7. Sounds like a reasonable solution as preflight wasn't yet included in 1.6 so we're not taking anything away. The note in README and/or release notes can refer to the new component(s) as a technology preview that's still being worked on and thus doesn't yet come with the usual stability and backwards compatibility guarantees. BR, Jukka Zitting
Re: Preflight and the 1.7 release
Hi, Am 21.05.2012 20:38, schrieb Leleu Eric: Hi, I discussed with Guillaume about the Preflight refactoring and we have some questions about le preflight module and the next release. Hmmm, last minute timing I planned to cut the release now. The new preflight implementation will be more flexible and configurable. But it will have significant impact on the current implementation. (New interface, new way to load/validate the pdf...) Due to the 1.7 release that is coming soon, we would like to know how we should commit the preflight modifications without breaking the 1.7 release. Here is 3 possibilities : 1 - Exclude the preflight module from the release and work with the current code without compatibility with the old version. Any suggestions how to do that easily? 2 - Include the preflight module in the 1.7 release, the new implementation will be create in new packages. They will have no more modifications of the old implementation that will be marked as deprecated. Expect bug fix nothing will be done on old version, only new implementation will be improved (new configuration capabilities, new validation format...). Old version will be definitely removed in a further release (1.8 or 2.0 ?) 3 - Include the preflight module unchanged and release it. The new validation tool will be done in a new module (Present only in the 2.0 branch ?). They will have no more modifications of the old module that will be marked as deprecated. Expect bug fix nothing will be done on old version. Only new module will evolve (new configuration capabilities, new validation format...). I don't like the idea of releasing code for the first time which is already meant to be dead. What is your opinion about that ? IMHO, as there wasn't any Apache release of preflight the cleanest way would be to replace the old implementation using the new one. But there are some questions: - Is the new implementation completed? If not, when do you expect to be ready? - Is the new implementation a full replacement of the old one? Depending on your answers and other opinions we might postpone the release for a couple of weeks. If you have any questions, do not hesitate. Don't hesitate to answer fast ;-) BR, Eric BR Andreas Lehmkühler
Re: Preflight and the 1.7 release
Hi, I agree with Andreas on that point : we should not release a code that will be dead soon. preflight (and xmpbox) has never been released. So, in my opinion, PDFBox 1.7 can be released without preflight... it bothers me for a project but I think it is the best thing to do. There is more than one issue linked with that: * Eric's new version will change the interface * xmpbox and jempbox should be merged (or at least one should desappear). The schedule with these modification is not compatible with 1.7 release. Guillaume On Tue, May 22, 2012 at 9:19 PM, Leleu Eric eric.leleu@gmail.com wrote: Hi, 2012/5/22 Andreas Lehmkuehler andr...@lehmi.de Hi, Am 21.05.2012 20:38, schrieb Leleu Eric: Hi, I discussed with Guillaume about the Preflight refactoring and we have some questions about le preflight module and the next release. Hmmm, last minute timing I planned to cut the release now. I'm sorry :( The new preflight implementation will be more flexible and configurable. But it will have significant impact on the current implementation. (New interface, new way to load/validate the pdf...) Due to the 1.7 release that is coming soon, we would like to know how we should commit the preflight modifications without breaking the 1.7 release. Here is 3 possibilities : 1 - Exclude the preflight module from the release and work with the current code without compatibility with the old version. Any suggestions how to do that easily? I was thinking to comment the preflight declaration in the pdfbox-reactor pom file. Doing this, the source code will be present in the tagged version, but they will not have preflight jar in the repository with the version 1.7. It's may not be the best way to achieve that but it is probably the easiest way... 2 - Include the preflight module in the 1.7 release, the new implementation will be create in new packages. They will have no more modifications of the old implementation that will be marked as deprecated. Expect bug fix nothing will be done on old version, only new implementation will be improved (new configuration capabilities, new validation format...). Old version will be definitely removed in a further release (1.8 or 2.0 ?) 3 - Include the preflight module unchanged and release it. The new validation tool will be done in a new module (Present only in the 2.0 branch ?). They will have no more modifications of the old module that will be marked as deprecated. Expect bug fix nothing will be done on old version. Only new module will evolve (new configuration capabilities, new validation format...). I don't like the idea of releasing code for the first time which is already meant to be dead. What is your opinion about that ? IMHO, as there wasn't any Apache release of preflight the cleanest way would be to replace the old implementation using the new one. But there are some questions: - Is the new implementation completed? If not, when do you expect to be ready? No, it isn't. Hopefully I will finish the refactoring at the end of June (but without guaranty), so it will be quite late for the 1.7 release. :( - Is the new implementation a full replacement of the old one ? No, I thought that around 50% of the code will be reused. Depending on your answers and other opinions we might postpone the release for a couple of weeks. If you have any questions, do not hesitate. Don't hesitate to answer fast ;-) One more time, I'm really sorry to delay the pdfbox release. BR, Eric BR Andreas Lehmkühler BR, Eric
Re: Preflight and the 1.7 release
you could always put a big warning in the README, and mark xmpbox/preflight as deprecated. that should be sufficient for people not to use it while you work on doing the modification for 1.8. On May 23, 2012, at 7:11 AM, Guillaume Bailleul wrote: Hi, I agree with Andreas on that point : we should not release a code that will be dead soon. preflight (and xmpbox) has never been released. So, in my opinion, PDFBox 1.7 can be released without preflight... it bothers me for a project but I think it is the best thing to do. There is more than one issue linked with that: * Eric's new version will change the interface * xmpbox and jempbox should be merged (or at least one should desappear). The schedule with these modification is not compatible with 1.7 release. Guillaume On Tue, May 22, 2012 at 9:19 PM, Leleu Eric eric.leleu@gmail.com wrote: Hi, 2012/5/22 Andreas Lehmkuehler andr...@lehmi.de Hi, Am 21.05.2012 20:38, schrieb Leleu Eric: Hi, I discussed with Guillaume about the Preflight refactoring and we have some questions about le preflight module and the next release. Hmmm, last minute timing I planned to cut the release now. I'm sorry :( The new preflight implementation will be more flexible and configurable. But it will have significant impact on the current implementation. (New interface, new way to load/validate the pdf...) Due to the 1.7 release that is coming soon, we would like to know how we should commit the preflight modifications without breaking the 1.7 release. Here is 3 possibilities : 1 - Exclude the preflight module from the release and work with the current code without compatibility with the old version. Any suggestions how to do that easily? I was thinking to comment the preflight declaration in the pdfbox-reactor pom file. Doing this, the source code will be present in the tagged version, but they will not have preflight jar in the repository with the version 1.7. It's may not be the best way to achieve that but it is probably the easiest way... 2 - Include the preflight module in the 1.7 release, the new implementation will be create in new packages. They will have no more modifications of the old implementation that will be marked as deprecated. Expect bug fix nothing will be done on old version, only new implementation will be improved (new configuration capabilities, new validation format...). Old version will be definitely removed in a further release (1.8 or 2.0 ?) 3 - Include the preflight module unchanged and release it. The new validation tool will be done in a new module (Present only in the 2.0 branch ?). They will have no more modifications of the old module that will be marked as deprecated. Expect bug fix nothing will be done on old version. Only new module will evolve (new configuration capabilities, new validation format...). I don't like the idea of releasing code for the first time which is already meant to be dead. What is your opinion about that ? IMHO, as there wasn't any Apache release of preflight the cleanest way would be to replace the old implementation using the new one. But there are some questions: - Is the new implementation completed? If not, when do you expect to be ready? No, it isn't. Hopefully I will finish the refactoring at the end of June (but without guaranty), so it will be quite late for the 1.7 release. :( - Is the new implementation a full replacement of the old one ? No, I thought that around 50% of the code will be reused. Depending on your answers and other opinions we might postpone the release for a couple of weeks. If you have any questions, do not hesitate. Don't hesitate to answer fast ;-) One more time, I'm really sorry to delay the pdfbox release. BR, Eric BR Andreas Lehmkühler BR, Eric
Preflight and the 1.7 release
Hi, I discussed with Guillaume about the Preflight refactoring and we have some questions about le preflight module and the next release. The new preflight implementation will be more flexible and configurable. But it will have significant impact on the current implementation. (New interface, new way to load/validate the pdf...) Due to the 1.7 release that is coming soon, we would like to know how we should commit the preflight modifications without breaking the 1.7 release. Here is 3 possibilities : 1 - Exclude the preflight module from the release and work with the current code without compatibility with the old version. 2 - Include the preflight module in the 1.7 release, the new implementation will be create in new packages. They will have no more modifications of the old implementation that will be marked as deprecated. Expect bug fix nothing will be done on old version, only new implementation will be improved (new configuration capabilities, new validation format...). Old version will be definitely removed in a further release (1.8 or 2.0 ?) 3 - Include the preflight module unchanged and release it. The new validation tool will be done in a new module (Present only in the 2.0 branch ?). They will have no more modifications of the old module that will be marked as deprecated. Expect bug fix nothing will be done on old version. Only new module will evolve (new configuration capabilities, new validation format...). What is your opinion about that ? If you have any questions, do not hesitate. BR, Eric
