Hey Tim,
Thanks for your repilies. I can't discuss on R7 as I'm not using it. I
can't also discuss your objections in a way other than "it depends". You
say that often more things gets exported than expected, but that's a
matter of developer awareness and not a pattern itself.
I could also argue about developer productivity with package-info and
additional annotations which bring just a burden and yet another piece
of metadata to be maintained in multiple places.
Kind regards,
Lukasz
On 15.06.2018 12:51, Tim Ward wrote:
> Hi Paul, Łukasz,
>
>>> /Could this be changed to use
>>> /
>>> /
>>> /
>>> /groupId + artifactId instead?
>>> /
>>> /
>>> /
>>> /Or is there a reason for not doing this?/
>
> The default package name in the templates is not set by enRoute, it is
> actually using the “default default” from the Maven archetype system. I
> don’t actually know whether it’s possible to change that default to a
> different dynamic value (i.e. one using placeholders).
>
> Can you raise this as an issue against the osgi/osgi.enroute project in
> GitHub so that it goes on the list of things to look at before 7.0.0 is
> released?
>
>> /A common pattern I used for maven based projects is:
>> symbolic name: ${groupId}.${artifactId}
>> /
>
> The enRoute project template does this.
>
>> /export package: !${groupId}.${artifactId}.internal.*,
>> ${groupId}.${artifactId}.*/
>
> This is bad practice as it frequently results in the export of packages
> that should not be exported. R7 has fixed this completely through the
> use of the @Export annotation (put it in your package-info.java along
> with your @Version annotation). It is therefore no longer necessary to
> use the Export-Package or -exportcontents instructions in projects. The
> enRoute project uses R7 and expects you to use the @Export annotation.
>
> Even in the absence of R7 you are much better off using:
>
> -exportcontents: ${packages;versioned}
>
> This way you only export packages that you have versioned, and therefore
> actively chose to export.
>
>
>> /bundle name: ${project.name}/
>
> This is the default for the bnd-maven-plugin, and therefore enRoute.
>
> Best Regards,
>
> Tim
>
> Sent from my iPhone
>
> On 15 Jun 2018, at 10:44, Łukasz Dywicki via osgi-dev
> <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>> wrote:
>
>> Hey Paul,
>> Its really up to a project and convention you take, enroute asumes org +
>> artifact but nothing prevents you from doing opposite.
>>
>> A common pattern I used for maven based projects is:
>> symbolic name: ${groupId}.${artifactId}
>> export package: !${groupId}.${artifactId}.internal.*,
>> ${groupId}.${artifactId}.*
>> bundle name: ${project.name}
>>
>> This allows to use compact artifact names while keeping some order of
>> things. When navigating over repository contents you can always be
>> certain that package org.code_house.foo.bar comes from
>> org.code_house.foo group and bar artifact.
>>
>> This, however differs from time to time and different projects take
>> their own path. For example karaf uses quite long and redundant artifact
>> names which overlap with module root package. It works quite well there.
>>
>> Each of above approaches have it pros and cons.
>>
>> Cheers,
>> Łukasz
>>
>> On 15.06.2018 02:40, Paul F Fraser via osgi-dev wrote:
>>> When creating new maven modules the default module package is set as
>>>
>>> org. + the artifactId
>>>
>>> Could this be changed to use
>>>
>>> groupId + artifactId instead?
>>>
>>> Or is there a reason for not doing this?
>>>
>>> Paul Fraser
>>>
>>>
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
