You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stanbol.apache.org by Olivier Grisel <ol...@ensta.org> on 2011/02/09 18:39:24 UTC
Package naming conventions
Hi all,
Standard java naming conventions state that all package names should
be lowercase. I think we should respect that in the Stanbol project.
For instance:
org.apache.stanbol.entityhub.yard.embeddedSolrProvider
should be either renamed to
org.apache.stanbol.entityhub.yard.embeddedsolrprovider
or even to just:
org.apache.stanbol.entityhub.yard.solr.embedded
--
Olivier
http://twitter.com/ogrisel - http://github.com/ogrisel
Re: Package naming conventions
Posted by Rupert Westenthaler <rw...@apache.org>.
Hi
Applied the necessary changes in revision #1069391.
For all that updated and build Stanbol since yesterday I recommend to delete the
- org.apache.stanbol.entityhub.yard.solr.provider
- org.apache.stanbol.entityhub.yard.solr.embedded
bundles from the local maven repository
best
Rupert Westenthaler
On Thu, Feb 10, 2011 at 10:29 AM, Olivier Grisel
<ol...@ensta.org> wrote:
> 2011/2/10 Rupert Westenthaler <rw...@apache.org>:
>> Points taken. Will make the necessary changes and commit it later today
>
> Thanks.
>
> --
> Olivier
> http://twitter.com/ogrisel - http://github.com/ogrisel
>
--
| Rupert Westenthaler rwesten@apache.org
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: Package naming conventions
Posted by Olivier Grisel <ol...@ensta.org>.
2011/2/10 Rupert Westenthaler <rw...@apache.org>:
> Points taken. Will make the necessary changes and commit it later today
Thanks.
--
Olivier
http://twitter.com/ogrisel - http://github.com/ogrisel
Re: Package naming conventions
Posted by Rupert Westenthaler <rw...@apache.org>.
Points taken. Will make the necessary changes and commit it later today
best
Rupert
On Thu, Feb 10, 2011 at 6:28 AM, Fabian Christ
<ch...@googlemail.com> wrote:
> Hi,
>
> I would also vote for option 2: The 3MB are not a problem since we do
> not have the requirement to minimize our package size. I would guess
> that If we want to start to minimize dependencies, there would be much
> more places in Stanbol to look at. That's why I would prefer to
> produce less bundles and accept the plus in size.
>
> - Fabian
>
> 2011/2/9 Olivier Grisel <ol...@ensta.org>:
>> 2011/2/9 Rupert Westenthaler <rw...@apache.org>:
>>>>
>>>> Both are alternative yard providers if I understand correctly. You can
>>>> either run solr using an external server or use the solr classes
>>>> inside the stanbol JVM.
>>>>
>>> In principle correct. However the SolrProvider is no Yard
>>> implementation. There is only a singe SolrYard implementation that
>>> requires a org.apache.solr.client.solrj.SolrServer instance. The
>>> SolrProvider is just responsible of providing this SolrServer
>>> instance.
>>>>
>>>> So we could have entityhub/yard/providers with solr and embeddedsolr
>>>> as subfolders instead. But I would rather have them all grouped
>>>> together in the same OSGi bundle unless Rupert has a technical reason
>>>> to avoid this.
>>>
>>> The embeddedSolrServer requires all the Solr and Lucene dependencies
>>> but Users that do not use an embedded Solr server do not need all this
>>> stuff (~3MB jar's).
>>>
>>> I would have preferred to keep all the stuff needed to use remote
>>> SolrServer within the SolrYard bundle and only move the
>>> EmbeddedSolrServer stuff to an own bundle, but that was not possible
>>> because of an cyclic build dependency (The unit tests of the SolrYard
>>> use an EmbeddedSolrServer and the EmbeddedSolrServer does implement
>>> the SolrProvider interface and would therefore has an dependency to
>>> the SolrYard bundle).
>>>
>>> So in my opinion there are only two possibilities:
>>> (1) creating three bundles (SolrYard, SolrProvider (interface
>>> definition and implementaion for remote SolrServer) and
>>> EmbeddedSolrProvider)
>>> (2) move everything into the SolrYard bundle (and add the ~3MB Solr
>>> and Lucene dependencies to it).
>>
>> I would rather vote for option 2: 3MB is small in comparison of the
>> size of a pre-filled yard index anyway that the user will have to
>> download anyway to make use of such an yard in practice.
>>
>> --
>> Olivier
>> http://twitter.com/ogrisel - http://github.com/ogrisel
>>
>
>
>
> --
> Fabian
>
--
| Rupert Westenthaler rwesten@apache.org
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: Package naming conventions
Posted by Fabian Christ <ch...@googlemail.com>.
Hi,
I would also vote for option 2: The 3MB are not a problem since we do
not have the requirement to minimize our package size. I would guess
that If we want to start to minimize dependencies, there would be much
more places in Stanbol to look at. That's why I would prefer to
produce less bundles and accept the plus in size.
- Fabian
2011/2/9 Olivier Grisel <ol...@ensta.org>:
> 2011/2/9 Rupert Westenthaler <rw...@apache.org>:
>>>
>>> Both are alternative yard providers if I understand correctly. You can
>>> either run solr using an external server or use the solr classes
>>> inside the stanbol JVM.
>>>
>> In principle correct. However the SolrProvider is no Yard
>> implementation. There is only a singe SolrYard implementation that
>> requires a org.apache.solr.client.solrj.SolrServer instance. The
>> SolrProvider is just responsible of providing this SolrServer
>> instance.
>>>
>>> So we could have entityhub/yard/providers with solr and embeddedsolr
>>> as subfolders instead. But I would rather have them all grouped
>>> together in the same OSGi bundle unless Rupert has a technical reason
>>> to avoid this.
>>
>> The embeddedSolrServer requires all the Solr and Lucene dependencies
>> but Users that do not use an embedded Solr server do not need all this
>> stuff (~3MB jar's).
>>
>> I would have preferred to keep all the stuff needed to use remote
>> SolrServer within the SolrYard bundle and only move the
>> EmbeddedSolrServer stuff to an own bundle, but that was not possible
>> because of an cyclic build dependency (The unit tests of the SolrYard
>> use an EmbeddedSolrServer and the EmbeddedSolrServer does implement
>> the SolrProvider interface and would therefore has an dependency to
>> the SolrYard bundle).
>>
>> So in my opinion there are only two possibilities:
>> (1) creating three bundles (SolrYard, SolrProvider (interface
>> definition and implementaion for remote SolrServer) and
>> EmbeddedSolrProvider)
>> (2) move everything into the SolrYard bundle (and add the ~3MB Solr
>> and Lucene dependencies to it).
>
> I would rather vote for option 2: 3MB is small in comparison of the
> size of a pre-filled yard index anyway that the user will have to
> download anyway to make use of such an yard in practice.
>
> --
> Olivier
> http://twitter.com/ogrisel - http://github.com/ogrisel
>
--
Fabian
Re: Package naming conventions
Posted by Olivier Grisel <ol...@ensta.org>.
2011/2/9 Rupert Westenthaler <rw...@apache.org>:
>>
>> Both are alternative yard providers if I understand correctly. You can
>> either run solr using an external server or use the solr classes
>> inside the stanbol JVM.
>>
> In principle correct. However the SolrProvider is no Yard
> implementation. There is only a singe SolrYard implementation that
> requires a org.apache.solr.client.solrj.SolrServer instance. The
> SolrProvider is just responsible of providing this SolrServer
> instance.
>>
>> So we could have entityhub/yard/providers with solr and embeddedsolr
>> as subfolders instead. But I would rather have them all grouped
>> together in the same OSGi bundle unless Rupert has a technical reason
>> to avoid this.
>
> The embeddedSolrServer requires all the Solr and Lucene dependencies
> but Users that do not use an embedded Solr server do not need all this
> stuff (~3MB jar's).
>
> I would have preferred to keep all the stuff needed to use remote
> SolrServer within the SolrYard bundle and only move the
> EmbeddedSolrServer stuff to an own bundle, but that was not possible
> because of an cyclic build dependency (The unit tests of the SolrYard
> use an EmbeddedSolrServer and the EmbeddedSolrServer does implement
> the SolrProvider interface and would therefore has an dependency to
> the SolrYard bundle).
>
> So in my opinion there are only two possibilities:
> (1) creating three bundles (SolrYard, SolrProvider (interface
> definition and implementaion for remote SolrServer) and
> EmbeddedSolrProvider)
> (2) move everything into the SolrYard bundle (and add the ~3MB Solr
> and Lucene dependencies to it).
I would rather vote for option 2: 3MB is small in comparison of the
size of a pre-filled yard index anyway that the user will have to
download anyway to make use of such an yard in practice.
--
Olivier
http://twitter.com/ogrisel - http://github.com/ogrisel
Re: Package naming conventions
Posted by Rupert Westenthaler <rw...@apache.org>.
>
> Both are alternative yard providers if I understand correctly. You can
> either run solr using an external server or use the solr classes
> inside the stanbol JVM.
>
In principle correct. However the SolrProvider is no Yard
implementation. There is only a singe SolrYard implementation that
requires a org.apache.solr.client.solrj.SolrServer instance. The
SolrProvider is just responsible of providing this SolrServer
instance.
>
> So we could have entityhub/yard/providers with solr and embeddedsolr
> as subfolders instead. But I would rather have them all grouped
> together in the same OSGi bundle unless Rupert has a technical reason
> to avoid this.
The embeddedSolrServer requires all the Solr and Lucene dependencies
but Users that do not use an embedded Solr server do not need all this
stuff (~3MB jar's).
I would have preferred to keep all the stuff needed to use remote
SolrServer within the SolrYard bundle and only move the
EmbeddedSolrServer stuff to an own bundle, but that was not possible
because of an cyclic build dependency (The unit tests of the SolrYard
use an EmbeddedSolrServer and the EmbeddedSolrServer does implement
the SolrProvider interface and would therefore has an dependency to
the SolrYard bundle).
So in my opinion there are only two possibilities:
(1) creating three bundles (SolrYard, SolrProvider (interface
definition and implementaion for remote SolrServer) and
EmbeddedSolrProvider)
(2) move everything into the SolrYard bundle (and add the ~3MB Solr
and Lucene dependencies to it).
best
Rupert
--
| Rupert Westenthaler rwesten@apache.org
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: Package naming conventions
Posted by Olivier Grisel <ol...@ensta.org>.
2011/2/9 Fabian Christ <ch...@googlemail.com>:
> Hi,
>
> 2011/2/9 Olivier Grisel <ol...@ensta.org>:
>> 2011/2/9 Rupert Westenthaler <ru...@gmail.com>:
>>> On Wed, Feb 9, 2011 at 6:54 PM, Olivier Grisel <ol...@ensta.org> wrote:
>>> WDYT of using "." notation to mark "helper" modules
>>> entityhub/yard/solr -> The SolrYard
>>> entityhub/yard/solr.provider -> Solr provider
>>> entityhub/yard/solr.embedded -> EmbeddedSolrServer
>
> Would this be a solution?
>
> entityhub/provider/solr
> entityhub/embed/solr
Both are alternative yard providers if I understand correctly. You can
either run solr using an external server or use the solr classes
inside the stanbol JVM.
So we could have entityhub/yard/providers with solr and embeddedsolr
as subfolders instead. But I would rather have them all grouped
together in the same OSGi bundle unless Rupert has a technical reason
to avoid this.
--
Olivier
http://twitter.com/ogrisel - http://github.com/ogrisel
Re: Package naming conventions
Posted by Fabian Christ <ch...@googlemail.com>.
Hi,
2011/2/9 Olivier Grisel <ol...@ensta.org>:
> 2011/2/9 Rupert Westenthaler <ru...@gmail.com>:
>> On Wed, Feb 9, 2011 at 6:54 PM, Olivier Grisel <ol...@ensta.org> wrote:
>> WDYT of using "." notation to mark "helper" modules
>> entityhub/yard/solr -> The SolrYard
>> entityhub/yard/solr.provider -> Solr provider
>> entityhub/yard/solr.embedded -> EmbeddedSolrServer
Would this be a solution?
entityhub/provider/solr
entityhub/embed/solr
> We should definitely avoid dots "." in folder names. It makes it
> confuses IDEs a lot when dealing with relative java package names. I
> would prefer "solrprovider" and "embeddedsolrprovider". Alternatively
> we can put both providers into the solr yard folder. No need for
> subpackages: can just use the OSGi configuration to switch from one
> provider impl to another.
>
> --
> Olivier
> http://twitter.com/ogrisel - http://github.com/ogrisel
>
+1 for not using dots
And if the above is not a solution then just put it in the yard/solr
package. I agree that there seems to be no real need for a subpackage.
- Fabian
--
Fabian
Re: Package naming conventions
Posted by Olivier Grisel <ol...@ensta.org>.
2011/2/9 Rupert Westenthaler <ru...@gmail.com>:
> On Wed, Feb 9, 2011 at 6:54 PM, Olivier Grisel <ol...@ensta.org> wrote:
>> Actually I made a mistake: the package names are already in lowercase.
> That actually true. However I have to admit that there are still some
> package names with upper case letter (e.g. [1]) that need to be
> changed.
>
>> However the project folders are not but I think it would be better if
>> they were consistent with package names. Eg:
>>
>> entityhub/yard/embeddedSolrProvider =>
>> entityhub/yard/embeddedsolr
>>
>> and
>>
>> entityhub/yard/solrProvider = > entityhub/yard/solr
>
>
> The fact that "entityhub/yard/solr" is already the name used for the
> module of the SolrYard was the reason why I called it solrProvider.
> Initially I have not liked the idea to put this two modules within
> "entityhub/yard" because they do not represent an Yard implementation
> but I could also not come up with a better fitting location and so I
> decided to give them rather long but clear names.
>
> WDYT of using "." notation to mark "helper" modules
> entityhub/yard/solr -> The SolrYard
> entityhub/yard/solr.provider -> Solr provider
> entityhub/yard/solr.embedded -> EmbeddedSolrServer
We should definitely avoid dots "." in folder names. It makes it
confuses IDEs a lot when dealing with relative java package names. I
would prefer "solrprovider" and "embeddedsolrprovider". Alternatively
we can put both providers into the solr yard folder. No need for
subpackages: can just use the OSGi configuration to switch from one
provider impl to another.
--
Olivier
http://twitter.com/ogrisel - http://github.com/ogrisel
Re: Package naming conventions
Posted by Rupert Westenthaler <ru...@gmail.com>.
On Wed, Feb 9, 2011 at 6:54 PM, Olivier Grisel <ol...@ensta.org> wrote:
> Actually I made a mistake: the package names are already in lowercase.
That actually true. However I have to admit that there are still some
package names with upper case letter (e.g. [1]) that need to be
changed.
> However the project folders are not but I think it would be better if
> they were consistent with package names. Eg:
>
> entityhub/yard/embeddedSolrProvider =>
> entityhub/yard/embeddedsolr
>
> and
>
> entityhub/yard/solrProvider = > entityhub/yard/solr
The fact that "entityhub/yard/solr" is already the name used for the
module of the SolrYard was the reason why I called it solrProvider.
Initially I have not liked the idea to put this two modules within
"entityhub/yard" because they do not represent an Yard implementation
but I could also not come up with a better fitting location and so I
decided to give them rather long but clear names.
WDYT of using "." notation to mark "helper" modules
entityhub/yard/solr -> The SolrYard
entityhub/yard/solr.provider -> Solr provider
entityhub/yard/solr.embedded -> EmbeddedSolrServer
best
Rupert Westenthaler
[1] http://svn.apache.org/repos/asf/incubator/stanbol/trunk/entityhub/yard/solr/src/main/java/org/apache/stanbol/entityhub/yard/solr/impl/constraintEncoders/
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: Package naming conventions
Posted by Olivier Grisel <ol...@ensta.org>.
Actually I made a mistake: the package names are already in lowercase.
However the project folders are not but I think it would be better if
they were consistent with package names. Eg:
entityhub/yard/embeddedSolrProvider =>
entityhub/yard/embeddedsolr
and
entityhub/yard/solrProvider = > entityhub/yard/solr
--
Olivier
http://twitter.com/ogrisel - http://github.com/ogrisel