You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Richard Eckart de Castilho <re...@apache.org> on 2014/09/25 20:47:31 UTC
Re: svn commit: r1627582 - in /uima/uimaj/trunk/uima-docbook-references/src/docbook: images/references/ref.json/ images/references/ref.json/FScollections.png images/references/ref.json/big_picture2.png images/references/ref.json/image_source.odg ref.json.xml
On 25.09.2014, at 20:27, schor@apache.org wrote:
> + <para>Starting with version 2.6.1, JSON style serialization for CASs and UIMA descriptions is supported via an
> + optional add-on, <code>uimaj-json</code>.
I noticed that you have moved the JSON code to the addons now. Since we have developed a habit of no longer releasing the addons, I wonder if locating the new module next to the other UIMAJ SDK modules. When I spoke out in favor of having JSON support in its own module, I was indeed thinking of leaving it as a separate module in the SDK and version it along with the other SDK modules.
Are you planning on moving it to the SDK once read support has been added or were you thinking of leaving it in the addons?
Cheers,
- Richard
Re: svn commit: r1627582 - in /uima/uimaj/trunk/uima-docbook-references/src/docbook:
images/references/ref.json/ images/references/ref.json/FScollections.png
images/references/ref.json/big_picture2.png images/references/ref.json/image_source.odg
ref.json.xml
Posted by Marshall Schor <ms...@schor.com>.
On 9/25/2014 3:55 PM, Richard Eckart de Castilho wrote:
> I think that the jackson-core jar should not be forced upon consumers of the
> uimaj-core jar and neither users should be forced to resort to exclusions to
> get rid of it. Hence, I suggested to move it to a separate module.
+1, this is now done. The uimaj-core has no dependency on jackson-core.
>
> I think it's fine for developers to get the jackson-core jar via the normal
> dependency management.
>
> If we want to make the JSON a truly optional part of the build, then its
> <module> declaration in the UIMA SDK parent pom can be moved to a profile.
> If the profile is activated, it is part of the build, otherwise no
> Whether we enable or disable the profile by default, I don't care. We should
> enable it for our own releases and on Jenkins. Having it enabled by default
> would make it more convenient for us. Downstream consumers that do not have
> the jackson-core jar in their repositories could conveniently disable the
> profile (e.g. mvn -P!enable-json-support clean install)
>
> Sounds good?
+ 1. I'll change it to what you suggest, and thank you for the suggestions!
-Marshall
>
> Cheers,
>
> -- Richard
>
> On 25.09.2014, at 21:48, Marshall Schor <ms...@schor.com> wrote:
>
>> Hi,
>>
>> Good points, Richard. I had not thought deeply about this.
>>
>> The POM for this is borrowing the versions and the parent pom from the
>> uimaj-parent, so it would be versioned with that.
>>
>> Thinking out loud:
>>
>> If we moved it to be under uimaj node in svn, but didn't include it as a
>> <module>, it could at least have its parent-pom relative path set reasonably.
>>
>> If we also included it as a <module> in the main uimaj code, and included it
>> (but not its dependency - jackson-core) in the binary build for uimaj, then it
>> would automatically build and get released with uimaj, but users would need to
>> separately download jackson-core jar (or use maven, etc.).
>>
>> -- This would require "developers" or "build-from-source" people to let
>> maven get the jackson-core jar into their maven repo, though, in order to "build".
>>
>> I think things would go smoother, if it was part of uimaj, except for having
>> developers / build-from-source people have to get the jackson-core jar.
>>
>> Or, do you think it is OK to have the binary "convenience" build also include
>> the jackson-core jar? (It's Apache v2 licensed). In which case the convenience
>> build is even more convenient :-) And I could get rid some some boilerplate
>> junk in the other project needed for managing it as a separate build.
>>
>> WDYT?
>>
>> -Marshall
>>
>> On 9/25/2014 2:47 PM, Richard Eckart de Castilho wrote:
>>> On 25.09.2014, at 20:27, schor@apache.org wrote:
>>>
>>>> + <para>Starting with version 2.6.1, JSON style serialization for CASs and UIMA descriptions is supported via an
>>>> + optional add-on, <code>uimaj-json</code>.
>>> I noticed that you have moved the JSON code to the addons now. Since we have developed a habit of no longer releasing the addons, I wonder if locating the new module next to the other UIMAJ SDK modules. When I spoke out in favor of having JSON support in its own module, I was indeed thinking of leaving it as a separate module in the SDK and version it along with the other SDK modules.
>>>
>>> Are you planning on moving it to the SDK once read support has been added or were you thinking of leaving it in the addons?
>>>
>>> Cheers,
>>>
>>> - Richard
>>>
>
>
Re: svn commit: r1627582 - in /uima/uimaj/trunk/uima-docbook-references/src/docbook: images/references/ref.json/ images/references/ref.json/FScollections.png images/references/ref.json/big_picture2.png images/references/ref.json/image_source.odg ref.json.xml
Posted by Richard Eckart de Castilho <re...@apache.org>.
I think that the jackson-core jar should not be forced upon consumers of the
uimaj-core jar and neither users should be forced to resort to exclusions to
get rid of it. Hence, I suggested to move it to a separate module.
I think it's fine for developers to get the jackson-core jar via the normal
dependency management.
If we want to make the JSON a truly optional part of the build, then its
<module> declaration in the UIMA SDK parent pom can be moved to a profile.
If the profile is activated, it is part of the build, otherwise not.
Whether we enable or disable the profile by default, I don't care. We should
enable it for our own releases and on Jenkins. Having it enabled by default
would make it more convenient for us. Downstream consumers that do not have
the jackson-core jar in their repositories could conveniently disable the
profile (e.g. mvn -P!enable-json-support clean install).
Sounds good?
Cheers,
-- Richard
On 25.09.2014, at 21:48, Marshall Schor <ms...@schor.com> wrote:
> Hi,
>
> Good points, Richard. I had not thought deeply about this.
>
> The POM for this is borrowing the versions and the parent pom from the
> uimaj-parent, so it would be versioned with that.
>
> Thinking out loud:
>
> If we moved it to be under uimaj node in svn, but didn't include it as a
> <module>, it could at least have its parent-pom relative path set reasonably.
>
> If we also included it as a <module> in the main uimaj code, and included it
> (but not its dependency - jackson-core) in the binary build for uimaj, then it
> would automatically build and get released with uimaj, but users would need to
> separately download jackson-core jar (or use maven, etc.).
>
> -- This would require "developers" or "build-from-source" people to let
> maven get the jackson-core jar into their maven repo, though, in order to "build".
>
> I think things would go smoother, if it was part of uimaj, except for having
> developers / build-from-source people have to get the jackson-core jar.
>
> Or, do you think it is OK to have the binary "convenience" build also include
> the jackson-core jar? (It's Apache v2 licensed). In which case the convenience
> build is even more convenient :-) And I could get rid some some boilerplate
> junk in the other project needed for managing it as a separate build.
>
> WDYT?
>
> -Marshall
>
> On 9/25/2014 2:47 PM, Richard Eckart de Castilho wrote:
>> On 25.09.2014, at 20:27, schor@apache.org wrote:
>>
>>> + <para>Starting with version 2.6.1, JSON style serialization for CASs and UIMA descriptions is supported via an
>>> + optional add-on, <code>uimaj-json</code>.
>> I noticed that you have moved the JSON code to the addons now. Since we have developed a habit of no longer releasing the addons, I wonder if locating the new module next to the other UIMAJ SDK modules. When I spoke out in favor of having JSON support in its own module, I was indeed thinking of leaving it as a separate module in the SDK and version it along with the other SDK modules.
>>
>> Are you planning on moving it to the SDK once read support has been added or were you thinking of leaving it in the addons?
>>
>> Cheers,
>>
>> - Richard
>>
>
Re: svn commit: r1627582 - in /uima/uimaj/trunk/uima-docbook-references/src/docbook:
images/references/ref.json/ images/references/ref.json/FScollections.png
images/references/ref.json/big_picture2.png images/references/ref.json/image_source.odg
ref.json.xml
Posted by Marshall Schor <ms...@schor.com>.
Hi,
Good points, Richard. I had not thought deeply about this.
The POM for this is borrowing the versions and the parent pom from the
uimaj-parent, so it would be versioned with that.
Thinking out loud:
If we moved it to be under uimaj node in svn, but didn't include it as a
<module>, it could at least have its parent-pom relative path set reasonably.
If we also included it as a <module> in the main uimaj code, and included it
(but not its dependency - jackson-core) in the binary build for uimaj, then it
would automatically build and get released with uimaj, but users would need to
separately download jackson-core jar (or use maven, etc.).
-- This would require "developers" or "build-from-source" people to let
maven get the jackson-core jar into their maven repo, though, in order to "build".
I think things would go smoother, if it was part of uimaj, except for having
developers / build-from-source people have to get the jackson-core jar.
Or, do you think it is OK to have the binary "convenience" build also include
the jackson-core jar? (It's Apache v2 licensed). In which case the convenience
build is even more convenient :-) And I could get rid some some boilerplate
junk in the other project needed for managing it as a separate build.
WDYT?
-Marshall
On 9/25/2014 2:47 PM, Richard Eckart de Castilho wrote:
> On 25.09.2014, at 20:27, schor@apache.org wrote:
>
>> + <para>Starting with version 2.6.1, JSON style serialization for CASs and UIMA descriptions is supported via an
>> + optional add-on, <code>uimaj-json</code>.
> I noticed that you have moved the JSON code to the addons now. Since we have developed a habit of no longer releasing the addons, I wonder if locating the new module next to the other UIMAJ SDK modules. When I spoke out in favor of having JSON support in its own module, I was indeed thinking of leaving it as a separate module in the SDK and version it along with the other SDK modules.
>
> Are you planning on moving it to the SDK once read support has been added or were you thinking of leaving it in the addons?
>
> Cheers,
>
> - Richard
>