You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by Leleu Eric <er...@gmail.com> on 2012/05/21 20:38:04 UTC
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
Re: Preflight and the 1.7 release
Posted by Andreas Lehmkühler <an...@lehmi.de>.
Hi,
Andreas Lehmkuehler <an...@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 Eric<er...@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
Posted by Andreas Lehmkuehler <an...@lehmi.de>.
Hi,
Am 23.05.2012 23:17, schrieb Jukka Zitting:
> Hi,
>
> On Wed, May 23, 2012 at 11:03 PM, Leleu Eric<er...@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
Posted by Guillaume Bailleul <gb...@gmail.com>.
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.boehme@ontochem.com
<ti...@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 <ju...@gmail.com> hat am 23. Mai 2012 um 23:17
> geschrieben:
>> On Wed, May 23, 2012 at 11:03 PM, Leleu Eric <er...@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
Posted by "timo.boehme@ontochem.com" <ti...@ontochem.com>.
Hi,
I would also vote for releasing 1.7 now and excluding the preflight module
in this release.
Best regards,
Timo
Jukka Zitting <ju...@gmail.com> hat am 23. Mai 2012 um 23:17
geschrieben:
> On Wed, May 23, 2012 at 11:03 PM, Leleu Eric <er...@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
Posted by Andreas Lehmkuehler <an...@lehmi.de>.
Hi,
Am 23.05.2012 23:17, schrieb Jukka Zitting:
> Hi,
>
> On Wed, May 23, 2012 at 11:03 PM, Leleu Eric<er...@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.
OK, so it seems that we have lazy consensus about the content of the next
release. :-)
I'm going to cut the release today in evening, that's about 12 hours for now.
I'll exclude both preflight packages and add a note to the README and release notes.
> BR,
>
> Jukka Zitting
Thanks for your input!!
BR
Andreas Lehmkühler
Re: Preflight and the 1.7 release
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, May 23, 2012 at 11:03 PM, Leleu Eric <er...@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
Posted by Leleu Eric <er...@gmail.com>.
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 <ti...@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 Eric<er...@gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> 2012/5/22 Andreas Lehmkuehler<an...@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.boehme@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
Posted by Timo Boehme <ti...@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 Eric<er...@gmail.com> wrote:
>>> Hi,
>>>
>>> 2012/5/22 Andreas Lehmkuehler<an...@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.boehme@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
Posted by Ian Holsman <kr...@gmail.com>.
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 <er...@gmail.com> wrote:
>> Hi,
>>
>> 2012/5/22 Andreas Lehmkuehler <an...@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
Posted by Guillaume Bailleul <gb...@gmail.com>.
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 <er...@gmail.com> wrote:
> Hi,
>
> 2012/5/22 Andreas Lehmkuehler <an...@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
Posted by Leleu Eric <er...@gmail.com>.
Hi,
2012/5/22 Andreas Lehmkuehler <an...@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
Posted by Andreas Lehmkuehler <an...@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.
> 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