redo of the OSGi packaging poms?

[Marshall Schor <ms...@schor.com>]

Leaving aside the question of whether or not to ship OSGi versions of add-on
annotators for the moment :-),

I'm thinking of redoing the pom structure for this, in order to eliminate the
possibility of Licenses, Notices, and dependencies getting "out of sync" between
the ogsi versions and the non-osgi versions.

To do this, I would do the following:

1) remove the addons-osgi and all of its subprojects.

2) add a new packaging type to the set of things we produce - currently we
produce things like Jars and PEAR packagings.  The OSGi packaging would be an
additional kind.

It would use the identical LICENSE and NOTICE files, and the same dependencies.

Now, I know that some of the OSGi packagings have *different* dependencies - but
it seems to me this is likely some kind of error - I can't think of a reason why
they would need to be different!

This would shrink the source footprint and make future maintenance easier (only
need to update things in one place).

Is there a reason to keep the separate OSGi source pom structures, that I'm
missing?  What do others think of this proposal?

-Marshall

Re: redo of the OSGi packaging poms?

[florent andré <fl...@4sengines.com>]

I don't have strong position on this proposal.
If it's simplify the code maintenance, I'm ok.
It's will just reduce the visibility of this packaging so will have to 
document it a little bit more.

Another point : there is also the uimaj/uimaj-ep-* stuff in this case...

++

On 07/25/2011 07:09 PM, Marshall Schor wrote:
> Leaving aside the question of whether or not to ship OSGi versions of add-on
> annotators for the moment :-),
>
> I'm thinking of redoing the pom structure for this, in order to eliminate the
> possibility of Licenses, Notices, and dependencies getting "out of sync" between
> the ogsi versions and the non-osgi versions.
>
> To do this, I would do the following:
>
> 1) remove the addons-osgi and all of its subprojects.
>
> 2) add a new packaging type to the set of things we produce - currently we
> produce things like Jars and PEAR packagings.  The OSGi packaging would be an
> additional kind.
>
> It would use the identical LICENSE and NOTICE files, and the same dependencies.
>
> Now, I know that some of the OSGi packagings have *different* dependencies - but
> it seems to me this is likely some kind of error - I can't think of a reason why
> they would need to be different!
>
> This would shrink the source footprint and make future maintenance easier (only
> need to update things in one place).
>
> Is there a reason to keep the separate OSGi source pom structures, that I'm
> missing?  What do others think of this proposal?
>
> -Marshall

Re: redo of the OSGi packaging poms?

[Marshall Schor <ms...@schor.com>]

I think I've got the BSFAnnotator "converted" to this new approach.

I'll put in a Jira and get the rest done, probably tomorrow.

These will be built without the extra dependencies (that is, the osgi versions
will have the same dependencies as the non-osgi versions).  If the extra
dependencies are "required" to get things started in Felix, it would be good to
figure out more about that - perhaps marking some things as optional would allow
starting?

Also, these will be built without embedding uima-ep-runtime inside every bundle.

So, this approach will need to be tested.

It was interesting re-reading that previous thread discussing OSGi and UIMA.  It
seems that without Eclipse-buddy approaches, the framework, when given a (for
example) name of an annotator class to load, would want to have some mechanism
to use OSGi facilities to get that class loaded, and get a reference to it, when
that class belongs to another "bundle".  Until we have that kind of facility, it
seems we'll need Eclipse-buddy loading or making annotator bundles "fragments"
of the uima-ep-runtime bundle (or some other innovative approach :-) )

-Marshall

On 7/25/2011 5:39 PM, Tommaso Teofili wrote:
> 2011/7/25 Marshall Schor <ms...@schor.com>
>
>> Leaving aside the question of whether or not to ship OSGi versions of
>> add-on
>> annotators for the moment :-),
>>
>> I'm thinking of redoing the pom structure for this, in order to eliminate
>> the
>> possibility of Licenses, Notices, and dependencies getting "out of sync"
>> between
>> the ogsi versions and the non-osgi versions.
>>
> I agree this should be unified.
>
>
>> To do this, I would do the following:
>>
>> 1) remove the addons-osgi and all of its subprojects.
>>
>> 2) add a new packaging type to the set of things we produce - currently we
>> produce things like Jars and PEAR packagings.  The OSGi packaging would be
>> an
>> additional kind.
>>
> so this would impact existing projects' POMs right?
> I proposed such a change some time ago which I think would be less hard to
> maintain [1].
>
>
>> It would use the identical LICENSE and NOTICE files, and the same
>> dependencies.
>>
>> Now, I know that some of the OSGi packagings have *different* dependencies
>> - but
>> it seems to me this is likely some kind of error - I can't think of a
>> reason why
>> they would need to be different!
>>
> for some of those additional dependencies they just came from trying to
> start them within a clean Apache Felix installation.
>
>
>> This would shrink the source footprint and make future maintenance easier
>> (only
>> need to update things in one place).
>>
>> Is there a reason to keep the separate OSGi source pom structures, that I'm
>> missing?  What do others think of this proposal?
>>
> I completely agree, +1.
> Tommaso
>
> [1] : http://markmail.org/message/4gtj6iwvjg3a6cvw
>
>
>> -Marshall
>>

Re: redo of the OSGi packaging poms?

[Tommaso Teofili <to...@gmail.com>]

2011/7/25 Marshall Schor <ms...@schor.com>

> Leaving aside the question of whether or not to ship OSGi versions of
> add-on
> annotators for the moment :-),
>
> I'm thinking of redoing the pom structure for this, in order to eliminate
> the
> possibility of Licenses, Notices, and dependencies getting "out of sync"
> between
> the ogsi versions and the non-osgi versions.
>

I agree this should be unified.


>
> To do this, I would do the following:
>
> 1) remove the addons-osgi and all of its subprojects.
>
> 2) add a new packaging type to the set of things we produce - currently we
> produce things like Jars and PEAR packagings.  The OSGi packaging would be
> an
> additional kind.
>

so this would impact existing projects' POMs right?
I proposed such a change some time ago which I think would be less hard to
maintain [1].


>
> It would use the identical LICENSE and NOTICE files, and the same
> dependencies.
>
> Now, I know that some of the OSGi packagings have *different* dependencies
> - but
> it seems to me this is likely some kind of error - I can't think of a
> reason why
> they would need to be different!
>

for some of those additional dependencies they just came from trying to
start them within a clean Apache Felix installation.


>
> This would shrink the source footprint and make future maintenance easier
> (only
> need to update things in one place).
>
> Is there a reason to keep the separate OSGi source pom structures, that I'm
> missing?  What do others think of this proposal?
>

I completely agree, +1.
Tommaso

[1] : http://markmail.org/message/4gtj6iwvjg3a6cvw


>
> -Marshall
>