You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall" <he...@ungoverned.org> on 2006/06/20 14:47:20 UTC
[VOTE] artifactId/repository/JAR file naming
Currently, Felix uses the following groupId/artifactId naming policy:
* groupId = org.apache.felix
* artifactId = org.apache.felix.<unique-subproject-name>
The choice of artifactId rears its head in two places:
1. Sub-project directories in trunk are named after their artifactId.
2. Resulting build process JAR files are named after their artifactId.
As a result of these policies, we end up with redundant and really long
names all over the place.
The proposal on the table is to change the definition of artifactId to:
* artifactId = felix-<unique-subproject-name>
Which would result in names for trunk directories and JAR files like:
felix-framework, felix-http-jetty, and felix-upnp-sample-clock. (A
slight variant is to maintain using '.' rather than '-'.)
[ ] +1 In favor of the new naming scheme.
[ ] 0 Don't care.
[ ] -1 Opposed to the new naming scheme.
Re: [VOTE] artifactId/repository/JAR file naming
Posted by st...@insa-lyon.fr.
+1
with "-" option
/stephane
On Tue, Jun 20, 2006 at 08:47:20AM -0400, Richard S. Hall wrote:
> Currently, Felix uses the following groupId/artifactId naming policy:
>
> * groupId = org.apache.felix
> * artifactId = org.apache.felix.<unique-subproject-name>
>
> The choice of artifactId rears its head in two places:
>
> 1. Sub-project directories in trunk are named after their artifactId.
> 2. Resulting build process JAR files are named after their artifactId.
>
> As a result of these policies, we end up with redundant and really long
> names all over the place.
>
> The proposal on the table is to change the definition of artifactId to:
>
> * artifactId = felix-<unique-subproject-name>
>
> Which would result in names for trunk directories and JAR files like:
> felix-framework, felix-http-jetty, and felix-upnp-sample-clock. (A
> slight variant is to maintain using '.' rather than '-'.)
>
> [ ] +1 In favor of the new naming scheme.
> [ ] 0 Don't care.
> [ ] -1 Opposed to the new naming scheme.
--
Stephane Frenot - Associate professor |
CITI/INRIA Ares - INSA lyon | mailto:stephane.frenot@insa-lyon.fr
Bat. Léonard de Vinci | http://ares.insa-lyon.fr/~sfrenot/
21 av Jean Capelle | ICQ:643346 (et oui !)
69621 Villeurbanne Cedex | +33 472 436 422 / +33 617 671 714
----------------------------------------------------------------------------
Re: [VOTE] artifactId/repository/JAR file naming
Posted by Upayavira <uv...@odoko.co.uk>.
Richard S. Hall wrote:
> Currently, Felix uses the following groupId/artifactId naming policy:
>
> * groupId = org.apache.felix
> * artifactId = org.apache.felix.<unique-subproject-name>
>
> The choice of artifactId rears its head in two places:
>
> 1. Sub-project directories in trunk are named after their artifactId.
> 2. Resulting build process JAR files are named after their artifactId.
>
> As a result of these policies, we end up with redundant and really long
> names all over the place.
>
> The proposal on the table is to change the definition of artifactId to:
>
> * artifactId = felix-<unique-subproject-name>
>
> Which would result in names for trunk directories and JAR files like:
> felix-framework, felix-http-jetty, and felix-upnp-sample-clock. (A
> slight variant is to maintain using '.' rather than '-'.)
>
> [ ] +1 In favor of the new naming scheme.
> [ ] 0 Don't care.
> [ ] -1 Opposed to the new naming scheme.
+1 from Alex, who can't send mail at the moment.
Upayavira
Re: [VOTE] artifactId/repository/JAR file naming
Posted by Trustin Lee <tr...@gmail.com>.
On 6/20/06, Richard S. Hall <he...@ungoverned.org> wrote:
>
> [ X ] +1 In favor of the new naming scheme.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: [VOTE] artifactId/repository/JAR file naming
Posted by Timothy Bennett <ti...@gmail.com>.
On 6/20/06, Richard S. Hall <he...@ungoverned.org> wrote:
>
> [ X ] +1 In favor of the new naming scheme.
> [ ] 0 Don't care.
> [ ] -1 Opposed to the new naming scheme.
>
>
--
timothy
Re: [VOTE] artifactId/repository/JAR file naming
Posted by Manuel Santillán <sa...@dit.upm.es>.
Non-binding +1 for the felix-* policy, -1 for the felix.* variation.
Richard S. Hall wrote:
> Currently, Felix uses the following groupId/artifactId naming policy:
> ...
[ X ] +1 In favor of the new naming scheme.
[ ] 0 Don't care.
[ ] -1 Opposed to the new naming scheme.
--
Manuel Santillán <sa...@dit.upm.es>
http://www.dit.upm.es/santillan
Departamento de Ingeniería de Sistemas Telemáticos
Escuela Técnica Superior de Ingenieros de Telecomunicación
Universidad Politécnica de Madrid
Avda. Complutense, s/n
28040 Madrid SPAIN
Tel. +34 913367366 ext.3034
Re: [VOTE] artifactId/repository/JAR file naming
Posted by Enrique Rodriguez <en...@gmail.com>.
Richard S. Hall wrote:
> Currently, Felix uses the following groupId/artifactId naming policy:
...
[ X ] +1 In favor of the new naming scheme.
[ ] 0 Don't care.
[ ] -1 Opposed to the new naming scheme.
Enrique
Re: [VOTE] artifactId/repository/JAR file naming
Posted by Stefano Lenzi <ki...@interfree.it>.
[ ] +1 In favor of the new naming scheme.
[ X ] 0 Don't care.
[ ] -1 Opposed to the new naming scheme.
Stefano "Kismet" Lenzi
Re: [VOTE] artifactId/repository/JAR file naming
Posted by "Richard S. Hall" <he...@ungoverned.org>.
+1
Me too.
-> richard
Marcel Offermans wrote:
> +1
>
> In favor because it's shorter that way.
>
Re: [VOTE] artifactId/repository/JAR file naming
Posted by Marcel Offermans <ma...@luminis.nl>.
+1
In favor because it's shorter that way.
Re: [VOTE] artifactId/repository/JAR file naming
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 20 June 2006 20:47, Richard S. Hall wrote:
> [ x ] +1 In favor of the new naming scheme.
> [ ] 0 Don't care.
> [ ] -1 Opposed to the new naming scheme.
Niclas
Re: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Alex Karasulu wrote:
> Ditto. As an example (excuse the pun) I have massaged over the
> examples in the specified format with one addition. I have put all
> examples modules under the examples SVN directory:
>
> http://svn.apache.org/viewvc/incubator/felix/trunk/examples/
>
> Does this sound about right?
I know there has been some grumbling about doing this, so I think it is
a reasonable experiment to try.
-> richard
Re: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
Posted by Alex Karasulu <ao...@bellsouth.net>.
Marcel Offermans wrote:
> Hello Richard,
>
> On Jul 26, 2006, at 16:48 , Richard S. Hall wrote:
>
>> After messing with this some more, I believe the best approach is to
>> simply rename our directories to be subproject name and everything
>> else stays the same.
>>
>> This will clean up the trunk directory and will leave JAR file names
>> as fully qualified...and will allow the efficient use of property
>> substitution in the subproject pom files.
>>
>> I will start by simply renaming the shell bundle directories to
>> "shell", "shell.tui", "shell.gui", and "shell.gui.plugin" and
>> modifying the main pom file to reference these. Everything else will
>> stay the same.
>>
>> Hope that sounds good.
>
> Yes that sounds good to me! It solves our problem of long directory
> names and from what I understand still allows us to use fully qualified
> JAR names (and bunde symbolic names I assume)?!
Ditto. As an example (excuse the pun) I have massaged over the examples
in the specified format with one addition. I have put all examples
modules under the examples SVN directory:
http://svn.apache.org/viewvc/incubator/felix/trunk/examples/
Does this sound about right?
Alex
Re: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Marcel Offermans wrote:
> Yes that sounds good to me! It solves our problem of long directory
> names and from what I understand still allows us to use fully
> qualified JAR names (and bunde symbolic names I assume)?!
Yep.
So, I will try it and see how it works...it cannot be much worse than
the current situation.
-> richard
Re: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
Posted by Marcel Offermans <ma...@luminis.nl>.
Hello Richard,
On Jul 26, 2006, at 16:48 , Richard S. Hall wrote:
> After messing with this some more, I believe the best approach is
> to simply rename our directories to be subproject name and
> everything else stays the same.
>
> This will clean up the trunk directory and will leave JAR file
> names as fully qualified...and will allow the efficient use of
> property substitution in the subproject pom files.
>
> I will start by simply renaming the shell bundle directories to
> "shell", "shell.tui", "shell.gui", and "shell.gui.plugin" and
> modifying the main pom file to reference these. Everything else
> will stay the same.
>
> Hope that sounds good.
Yes that sounds good to me! It solves our problem of long directory
names and from what I understand still allows us to use fully
qualified JAR names (and bunde symbolic names I assume)?!
Greetings, Marcel
Re: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
Posted by "Richard S. Hall" <he...@ungoverned.org>.
After messing with this some more, I believe the best approach is to
simply rename our directories to be subproject name and everything else
stays the same.
This will clean up the trunk directory and will leave JAR file names as
fully qualified...and will allow the efficient use of property
substitution in the subproject pom files.
I will start by simply renaming the shell bundle directories to "shell",
"shell.tui", "shell.gui", and "shell.gui.plugin" and modifying the main
pom file to reference these. Everything else will stay the same.
Hope that sounds good.
-> richard
Richard S. Hall wrote:
> I think this approach works for subprojects with names like "shell",
> but what about ones with names like "shell tui"...we originally
> converted this to "shell.tui", but now we are saying it should be
> "shell-tui"...to actually have it be the package, we would need to go
> back to "shell.tui". So, we would end up with:
>
> ${groupId} = org.apache.felix
> ${package} = shell.tui
> ${artifactId} = felix-${package}
> ==> felix-shell.tui
> ${bundle-symbolicname} = ${groupId}.${package}
> ==> org.apache.felix.shell.tui
> ${exported-package} = ${groupId}.${package}
> ==> org.apache.felix.shell.tui
>
> This would lead to JAR names like: felix-shell.tui-0.8.0-SNAPSHOT.jar
>
> Are there any issues with this?
>
> -> richard
>
> santillan wrote:
>> BJ's idea sounds *almost* good to me. Maybe it doesn't make sense at
>> all,
>> but I'd rather not have *.felix.felix-* in the BSN, as I don't see
>> benefits
>> for the redundancy. How about using the package after the groupId for
>> the
>> BSN? Do you think that would be useful for soothing interop with the PDE
>> guys? It'd be something like:
>>
>> ${groupId} = org.apache.felix
>> ${package} = shell
>> ${artifactId} = felix-${package}
>> <!--${bundle-symbolicname} = ${groupId}.${artifactId}-->
>> ${bundle-symbolicname} = ${groupId}.${package}
>> ${exported-package} = ${groupId}.${package}
>>
>> --
>>
>> Manuel Santillán <sa...@dit.upm.es>
>> http://www.dit.upm.es/santillan
>> Departamento de Ingeniería de Sistemas Telemáticos Escuela Técnica
>> Superior de Ingenieros de Telecomunicación Universidad Politécnica de
>> Madrid Avda. Complutense, s/n 28040 Madrid SPAIN Tel. +34 913367366
>> ext.3034
>>
>>
>> -----Mensaje original-----
>> De: BJ Hargrave [mailto:hargrave@us.ibm.com] Enviado el: martes, 11
>> de julio de 2006 17:42
>> Para: felix-dev@incubator.apache.org
>> Asunto: Re: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
>>
>> I guess no one actually tried this out before voting?
>>
>> I suggest: * ${groupId}.${artifactId} ==>
>> org.apache.felix.felix-shell
>>
>> for BSN. It is simple and straight forward.
>>
>> How about something like:
>>
>> * ${groupId} = org.apache.felix
>> * ${package} = shell
>> * ${artifactId} = felix-${package}
>> * ${bundle-symbolicname} = ${groupId}.${artifactId}
>> * ${expored-package} = ${groupId}.${package}
>>
>>
>> BJ Hargrave
>> Senior Technical Staff Member, IBM
>> OSGi Fellow and CTO of the OSGi Alliance
>> hargrave@us.ibm.com
>> Office: +1 407 849 9117 Mobile: +1 386 848 3788
>>
>>
>>
>> "Richard S. Hall" <he...@ungoverned.org> 07/11/2006 10:30 AM
>> Please respond to
>> felix-dev@incubator.apache.org
>>
>>
>> To
>> felix-dev@incubator.apache.org
>> cc
>>
>> Subject
>> Re: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
>>
>>
>>
>>
>>
>>
>> A follow up on this topic.
>>
>> I was going to sit down and start renaming some of my subprojects
>> according to the new rules, but then I ran into some issues that I
>> felt I needed to discuss.
>>
>> First, I wanted to give people some warning that when I change the
>> name of the shell-related JAR files then this will effectively break
>> existing saved bundle profiles. What will actually happen is that all
>> existing profiles will get a new set of shell-related bundles
>> installed into them. This is only really problematic for the ShellTUI
>> bundle, since it uses stdin. The solution is to uninstall the old
>> shell bundles or to recreate your profiles. For the more adventurous,
>> you could go into the profile directory and edit the bundle.location
>> files of the shell-related bundles to match the new name, then you
>> won't get duplicates.
>>
>> Second, given the new naming scheme for artifactId, we do not really
>> have an obvious way to generate the bundle symbolic name. For
>> example, we will have this information:
>>
>> groupId = org.apache.felix
>> artifactId = felix-shell
>>
>> So, what should the bundle symbolic name for this bundle be?
>>
>> * ${groupId}.${artifactId} ==> org.apache.felix.felix-shell
>> * ${artifactId} ==> felix-shell
>> * f(${groupId},${artifactId}) ==> org.apache.felix.shell
>>
>> Any suggestions?
>>
>> I also see another minor downside with this approach in that I am not
>> able to use variable substitution as much in my pom file, e.g., since
>> the name of the artifactId was the same as the package I could use
>> variable substitution in my export-package header.
>>
>> -> richard
>>
>> Enrique Rodriguez wrote:
>>
>>> Richard S. Hall wrote:
>>>
>>>> Time to call this vote:
>>>>
>>>> * +1 votes - Marcel Offermans, Richard S. Hall, Stephane Frenot,
>>>> Trustin Lee, Niclas Hedhman, Enrique Rodriguez, Manuel Santillan,
>>>> Timothy Bennett, Alan D. Cabrera, and Alex Karasulu.
>>>> * 0 votes - Stefano Lenzi.
>>>> * -1 votes - None.
>>>>
>>>> So, I guess we can all rename our own subprojects for the time
>>>> being. Are there going to be any issues we need to consider before
>>>> starting the rename process? For example, I would guess that we
>>>> need to remove the existing artifacts from the snapshot repository,
>>>> no? Is there any thing else?
>>>>
>>> I think that's it. People should do full re-builds at the root of
>>> Felix. As you noted, the deploy repo should be manually purged and
>>> builds tested online.
>>>
>>> Enrique
>>>
>>>
>>
>>
>>
>>
>
RE: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
Posted by Manuel Santillan <sa...@dit.upm.es>.
I think it's fine, although I cannot help you with the maven issue...
--
Manuel Santillán <sa...@dit.upm.es>
http://www.dit.upm.es/santillan
Departamento de Ingeniería de Sistemas Telemáticos
Escuela Técnica Superior de Ingenieros de Telecomunicación
Universidad Politécnica de Madrid
Avda. Complutense, s/n
28040 Madrid SPAIN
Tel. +34 913367366 ext.3034
-----Mensaje original-----
De: Richard S. Hall [mailto:heavy@ungoverned.org]
Enviado el: lunes, 17 de julio de 2006 16:00
Para: felix-dev@incubator.apache.org
Asunto: Re: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
No one responded to this message.
I would like to start renaming some of the subprojects, so is the below
solution okay? In particular with respect to subprojects that will end
up having "." in their names?
If so, I have a maven question about how to achieve it. Does anyone know
the mechanism for adding our own properties to the pom file so that I
can reference it within the pom file (e.g., the "package" property in
the example below)? I did some quick searching of the maven docs, but
could not find anything helpful.
-> richard
Richard S. Hall wrote:
> I think this approach works for subprojects with names like "shell",
> but what about ones with names like "shell tui"...we originally
> converted this to "shell.tui", but now we are saying it should be
> "shell-tui"...to actually have it be the package, we would need to go
> back to "shell.tui". So, we would end up with:
>
> ${groupId} = org.apache.felix
> ${package} = shell.tui
> ${artifactId} = felix-${package}
> ==> felix-shell.tui
> ${bundle-symbolicname} = ${groupId}.${package}
> ==> org.apache.felix.shell.tui
> ${exported-package} = ${groupId}.${package}
> ==> org.apache.felix.shell.tui
>
> This would lead to JAR names like: felix-shell.tui-0.8.0-SNAPSHOT.jar
>
> Are there any issues with this?
>
> -> richard
>
> santillan wrote:
>> BJ's idea sounds *almost* good to me. Maybe it doesn't make sense at
>> all,
>> but I'd rather not have *.felix.felix-* in the BSN, as I don't see
>> benefits
>> for the redundancy. How about using the package after the groupId for
>> the
>> BSN? Do you think that would be useful for soothing interop with the PDE
>> guys? It'd be something like:
>>
>> ${groupId} = org.apache.felix
>> ${package} = shell
>> ${artifactId} = felix-${package}
>> <!--${bundle-symbolicname} = ${groupId}.${artifactId}-->
>> ${bundle-symbolicname} = ${groupId}.${package}
>> ${exported-package} = ${groupId}.${package}
>>
>> --
>>
>> Manuel Santillán <sa...@dit.upm.es>
>> http://www.dit.upm.es/santillan
>> Departamento de Ingeniería de Sistemas Telemáticos Escuela Técnica
>> Superior de Ingenieros de Telecomunicación Universidad Politécnica de
>> Madrid Avda. Complutense, s/n 28040 Madrid SPAIN Tel. +34 913367366
>> ext.3034
>>
>>
>> -----Mensaje original-----
>> De: BJ Hargrave [mailto:hargrave@us.ibm.com] Enviado el: martes, 11
>> de julio de 2006 17:42
>> Para: felix-dev@incubator.apache.org
>> Asunto: Re: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
>>
>> I guess no one actually tried this out before voting?
>>
>> I suggest: * ${groupId}.${artifactId} ==>
>> org.apache.felix.felix-shell
>>
>> for BSN. It is simple and straight forward.
>>
>> How about something like:
>>
>> * ${groupId} = org.apache.felix
>> * ${package} = shell
>> * ${artifactId} = felix-${package}
>> * ${bundle-symbolicname} = ${groupId}.${artifactId}
>> * ${expored-package} = ${groupId}.${package}
>>
>>
>> BJ Hargrave
>> Senior Technical Staff Member, IBM
>> OSGi Fellow and CTO of the OSGi Alliance
>> hargrave@us.ibm.com
>> Office: +1 407 849 9117 Mobile: +1 386 848 3788
>>
>>
>>
>> "Richard S. Hall" <he...@ungoverned.org> 07/11/2006 10:30 AM
>> Please respond to
>> felix-dev@incubator.apache.org
>>
>>
>> To
>> felix-dev@incubator.apache.org
>> cc
>>
>> Subject
>> Re: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
>>
>>
>>
>>
>>
>>
>> A follow up on this topic.
>>
>> I was going to sit down and start renaming some of my subprojects
>> according to the new rules, but then I ran into some issues that I
>> felt I needed to discuss.
>>
>> First, I wanted to give people some warning that when I change the
>> name of the shell-related JAR files then this will effectively break
>> existing saved bundle profiles. What will actually happen is that all
>> existing profiles will get a new set of shell-related bundles
>> installed into them. This is only really problematic for the ShellTUI
>> bundle, since it uses stdin. The solution is to uninstall the old
>> shell bundles or to recreate your profiles. For the more adventurous,
>> you could go into the profile directory and edit the bundle.location
>> files of the shell-related bundles to match the new name, then you
>> won't get duplicates.
>>
>> Second, given the new naming scheme for artifactId, we do not really
>> have an obvious way to generate the bundle symbolic name. For
>> example, we will have this information:
>>
>> groupId = org.apache.felix
>> artifactId = felix-shell
>>
>> So, what should the bundle symbolic name for this bundle be?
>>
>> * ${groupId}.${artifactId} ==> org.apache.felix.felix-shell
>> * ${artifactId} ==> felix-shell
>> * f(${groupId},${artifactId}) ==> org.apache.felix.shell
>>
>> Any suggestions?
>>
>> I also see another minor downside with this approach in that I am not
>> able to use variable substitution as much in my pom file, e.g., since
>> the name of the artifactId was the same as the package I could use
>> variable substitution in my export-package header.
>>
>> -> richard
>>
>> Enrique Rodriguez wrote:
>>
>>> Richard S. Hall wrote:
>>>
>>>> Time to call this vote:
>>>>
>>>> * +1 votes - Marcel Offermans, Richard S. Hall, Stephane Frenot,
>>>> Trustin Lee, Niclas Hedhman, Enrique Rodriguez, Manuel Santillan,
>>>> Timothy Bennett, Alan D. Cabrera, and Alex Karasulu.
>>>> * 0 votes - Stefano Lenzi.
>>>> * -1 votes - None.
>>>>
>>>> So, I guess we can all rename our own subprojects for the time
>>>> being. Are there going to be any issues we need to consider before
>>>> starting the rename process? For example, I would guess that we
>>>> need to remove the existing artifacts from the snapshot repository,
>>>> no? Is there any thing else?
>>>>
>>> I think that's it. People should do full re-builds at the root of
>>> Felix. As you noted, the deploy repo should be manually purged and
>>> builds tested online.
>>>
>>> Enrique
>>>
>>>
>>
>>
>>
>>
>
Re: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
Posted by "Richard S. Hall" <he...@ungoverned.org>.
No one responded to this message.
I would like to start renaming some of the subprojects, so is the below
solution okay? In particular with respect to subprojects that will end
up having "." in their names?
If so, I have a maven question about how to achieve it. Does anyone know
the mechanism for adding our own properties to the pom file so that I
can reference it within the pom file (e.g., the "package" property in
the example below)? I did some quick searching of the maven docs, but
could not find anything helpful.
-> richard
Richard S. Hall wrote:
> I think this approach works for subprojects with names like "shell",
> but what about ones with names like "shell tui"...we originally
> converted this to "shell.tui", but now we are saying it should be
> "shell-tui"...to actually have it be the package, we would need to go
> back to "shell.tui". So, we would end up with:
>
> ${groupId} = org.apache.felix
> ${package} = shell.tui
> ${artifactId} = felix-${package}
> ==> felix-shell.tui
> ${bundle-symbolicname} = ${groupId}.${package}
> ==> org.apache.felix.shell.tui
> ${exported-package} = ${groupId}.${package}
> ==> org.apache.felix.shell.tui
>
> This would lead to JAR names like: felix-shell.tui-0.8.0-SNAPSHOT.jar
>
> Are there any issues with this?
>
> -> richard
>
> santillan wrote:
>> BJ's idea sounds *almost* good to me. Maybe it doesn't make sense at
>> all,
>> but I'd rather not have *.felix.felix-* in the BSN, as I don't see
>> benefits
>> for the redundancy. How about using the package after the groupId for
>> the
>> BSN? Do you think that would be useful for soothing interop with the PDE
>> guys? It'd be something like:
>>
>> ${groupId} = org.apache.felix
>> ${package} = shell
>> ${artifactId} = felix-${package}
>> <!--${bundle-symbolicname} = ${groupId}.${artifactId}-->
>> ${bundle-symbolicname} = ${groupId}.${package}
>> ${exported-package} = ${groupId}.${package}
>>
>> --
>>
>> Manuel Santillán <sa...@dit.upm.es>
>> http://www.dit.upm.es/santillan
>> Departamento de Ingeniería de Sistemas Telemáticos Escuela Técnica
>> Superior de Ingenieros de Telecomunicación Universidad Politécnica de
>> Madrid Avda. Complutense, s/n 28040 Madrid SPAIN Tel. +34 913367366
>> ext.3034
>>
>>
>> -----Mensaje original-----
>> De: BJ Hargrave [mailto:hargrave@us.ibm.com] Enviado el: martes, 11
>> de julio de 2006 17:42
>> Para: felix-dev@incubator.apache.org
>> Asunto: Re: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
>>
>> I guess no one actually tried this out before voting?
>>
>> I suggest: * ${groupId}.${artifactId} ==>
>> org.apache.felix.felix-shell
>>
>> for BSN. It is simple and straight forward.
>>
>> How about something like:
>>
>> * ${groupId} = org.apache.felix
>> * ${package} = shell
>> * ${artifactId} = felix-${package}
>> * ${bundle-symbolicname} = ${groupId}.${artifactId}
>> * ${expored-package} = ${groupId}.${package}
>>
>>
>> BJ Hargrave
>> Senior Technical Staff Member, IBM
>> OSGi Fellow and CTO of the OSGi Alliance
>> hargrave@us.ibm.com
>> Office: +1 407 849 9117 Mobile: +1 386 848 3788
>>
>>
>>
>> "Richard S. Hall" <he...@ungoverned.org> 07/11/2006 10:30 AM
>> Please respond to
>> felix-dev@incubator.apache.org
>>
>>
>> To
>> felix-dev@incubator.apache.org
>> cc
>>
>> Subject
>> Re: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
>>
>>
>>
>>
>>
>>
>> A follow up on this topic.
>>
>> I was going to sit down and start renaming some of my subprojects
>> according to the new rules, but then I ran into some issues that I
>> felt I needed to discuss.
>>
>> First, I wanted to give people some warning that when I change the
>> name of the shell-related JAR files then this will effectively break
>> existing saved bundle profiles. What will actually happen is that all
>> existing profiles will get a new set of shell-related bundles
>> installed into them. This is only really problematic for the ShellTUI
>> bundle, since it uses stdin. The solution is to uninstall the old
>> shell bundles or to recreate your profiles. For the more adventurous,
>> you could go into the profile directory and edit the bundle.location
>> files of the shell-related bundles to match the new name, then you
>> won't get duplicates.
>>
>> Second, given the new naming scheme for artifactId, we do not really
>> have an obvious way to generate the bundle symbolic name. For
>> example, we will have this information:
>>
>> groupId = org.apache.felix
>> artifactId = felix-shell
>>
>> So, what should the bundle symbolic name for this bundle be?
>>
>> * ${groupId}.${artifactId} ==> org.apache.felix.felix-shell
>> * ${artifactId} ==> felix-shell
>> * f(${groupId},${artifactId}) ==> org.apache.felix.shell
>>
>> Any suggestions?
>>
>> I also see another minor downside with this approach in that I am not
>> able to use variable substitution as much in my pom file, e.g., since
>> the name of the artifactId was the same as the package I could use
>> variable substitution in my export-package header.
>>
>> -> richard
>>
>> Enrique Rodriguez wrote:
>>
>>> Richard S. Hall wrote:
>>>
>>>> Time to call this vote:
>>>>
>>>> * +1 votes - Marcel Offermans, Richard S. Hall, Stephane Frenot,
>>>> Trustin Lee, Niclas Hedhman, Enrique Rodriguez, Manuel Santillan,
>>>> Timothy Bennett, Alan D. Cabrera, and Alex Karasulu.
>>>> * 0 votes - Stefano Lenzi.
>>>> * -1 votes - None.
>>>>
>>>> So, I guess we can all rename our own subprojects for the time
>>>> being. Are there going to be any issues we need to consider before
>>>> starting the rename process? For example, I would guess that we
>>>> need to remove the existing artifacts from the snapshot repository,
>>>> no? Is there any thing else?
>>>>
>>> I think that's it. People should do full re-builds at the root of
>>> Felix. As you noted, the deploy repo should be manually purged and
>>> builds tested online.
>>>
>>> Enrique
>>>
>>>
>>
>>
>>
>>
>
Re: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
Posted by "Richard S. Hall" <he...@ungoverned.org>.
I think this approach works for subprojects with names like "shell", but
what about ones with names like "shell tui"...we originally converted
this to "shell.tui", but now we are saying it should be "shell-tui"...to
actually have it be the package, we would need to go back to
"shell.tui". So, we would end up with:
${groupId} = org.apache.felix
${package} = shell.tui
${artifactId} = felix-${package}
==> felix-shell.tui
${bundle-symbolicname} = ${groupId}.${package}
==> org.apache.felix.shell.tui
${exported-package} = ${groupId}.${package}
==> org.apache.felix.shell.tui
This would lead to JAR names like: felix-shell.tui-0.8.0-SNAPSHOT.jar
Are there any issues with this?
-> richard
santillan wrote:
> BJ's idea sounds *almost* good to me. Maybe it doesn't make sense at all,
> but I'd rather not have *.felix.felix-* in the BSN, as I don't see benefits
> for the redundancy. How about using the package after the groupId for the
> BSN? Do you think that would be useful for soothing interop with the PDE
> guys? It'd be something like:
>
> ${groupId} = org.apache.felix
> ${package} = shell
> ${artifactId} = felix-${package}
> <!--${bundle-symbolicname} = ${groupId}.${artifactId}-->
> ${bundle-symbolicname} = ${groupId}.${package}
> ${exported-package} = ${groupId}.${package}
>
> --
>
> Manuel Santillán <sa...@dit.upm.es>
> http://www.dit.upm.es/santillan
> Departamento de Ingeniería de Sistemas Telemáticos
> Escuela Técnica Superior de Ingenieros de Telecomunicación
> Universidad Politécnica de Madrid
> Avda. Complutense, s/n
> 28040 Madrid SPAIN
> Tel. +34 913367366 ext.3034
>
>
> -----Mensaje original-----
> De: BJ Hargrave [mailto:hargrave@us.ibm.com]
> Enviado el: martes, 11 de julio de 2006 17:42
> Para: felix-dev@incubator.apache.org
> Asunto: Re: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
>
> I guess no one actually tried this out before voting?
>
> I suggest: * ${groupId}.${artifactId} ==> org.apache.felix.felix-shell
>
> for BSN. It is simple and straight forward.
>
> How about something like:
>
> * ${groupId} = org.apache.felix
> * ${package} = shell
> * ${artifactId} = felix-${package}
> * ${bundle-symbolicname} = ${groupId}.${artifactId}
> * ${expored-package} = ${groupId}.${package}
>
>
> BJ Hargrave
> Senior Technical Staff Member, IBM
> OSGi Fellow and CTO of the OSGi Alliance
> hargrave@us.ibm.com
> Office: +1 407 849 9117 Mobile: +1 386 848 3788
>
>
>
> "Richard S. Hall" <he...@ungoverned.org>
> 07/11/2006 10:30 AM
> Please respond to
> felix-dev@incubator.apache.org
>
>
> To
> felix-dev@incubator.apache.org
> cc
>
> Subject
> Re: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
>
>
>
>
>
>
> A follow up on this topic.
>
> I was going to sit down and start renaming some of my subprojects
> according to the new rules, but then I ran into some issues that I felt
> I needed to discuss.
>
> First, I wanted to give people some warning that when I change the name
> of the shell-related JAR files then this will effectively break existing
> saved bundle profiles. What will actually happen is that all existing
> profiles will get a new set of shell-related bundles installed into
> them. This is only really problematic for the ShellTUI bundle, since it
> uses stdin. The solution is to uninstall the old shell bundles or to
> recreate your profiles. For the more adventurous, you could go into the
> profile directory and edit the bundle.location files of the
> shell-related bundles to match the new name, then you won't get
> duplicates.
>
> Second, given the new naming scheme for artifactId, we do not really
> have an obvious way to generate the bundle symbolic name. For example,
> we will have this information:
>
> groupId = org.apache.felix
> artifactId = felix-shell
>
> So, what should the bundle symbolic name for this bundle be?
>
> * ${groupId}.${artifactId} ==> org.apache.felix.felix-shell
> * ${artifactId} ==> felix-shell
> * f(${groupId},${artifactId}) ==> org.apache.felix.shell
>
> Any suggestions?
>
> I also see another minor downside with this approach in that I am not
> able to use variable substitution as much in my pom file, e.g., since
> the name of the artifactId was the same as the package I could use
> variable substitution in my export-package header.
>
> -> richard
>
> Enrique Rodriguez wrote:
>
>> Richard S. Hall wrote:
>>
>>> Time to call this vote:
>>>
>>> * +1 votes - Marcel Offermans, Richard S. Hall, Stephane Frenot,
>>> Trustin Lee, Niclas Hedhman, Enrique Rodriguez, Manuel Santillan,
>>> Timothy Bennett, Alan D. Cabrera, and Alex Karasulu.
>>> * 0 votes - Stefano Lenzi.
>>> * -1 votes - None.
>>>
>>> So, I guess we can all rename our own subprojects for the time being.
>>> Are there going to be any issues we need to consider before starting
>>> the rename process? For example, I would guess that we need to remove
>>> the existing artifacts from the snapshot repository, no? Is there any
>>> thing else?
>>>
>> I think that's it. People should do full re-builds at the root of
>> Felix. As you noted, the deploy repo should be manually purged and
>> builds tested online.
>>
>> Enrique
>>
>>
>
>
>
>
RE: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
Posted by BJ Hargrave <ha...@us.ibm.com>.
Yes. This is actually what I meant but my stupidity filter was off :-)
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
Office: +1 407 849 9117 Mobile: +1 386 848 3788
"santillan" <sa...@dit.upm.es>
07/11/2006 12:35 PM
Please respond to
felix-dev@incubator.apache.org
To
<fe...@incubator.apache.org>
cc
Subject
RE: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
BJ's idea sounds *almost* good to me. Maybe it doesn't make sense at all,
but I'd rather not have *.felix.felix-* in the BSN, as I don't see
benefits
for the redundancy. How about using the package after the groupId for the
BSN? Do you think that would be useful for soothing interop with the PDE
guys? It'd be something like:
${groupId} = org.apache.felix
${package} = shell
${artifactId} = felix-${package}
<!--${bundle-symbolicname} = ${groupId}.${artifactId}-->
${bundle-symbolicname} = ${groupId}.${package}
${exported-package} = ${groupId}.${package}
--
Manuel Santillán <sa...@dit.upm.es>
http://www.dit.upm.es/santillan
Departamento de Ingeniería de Sistemas Telemáticos
Escuela Técnica Superior de Ingenieros de Telecomunicación
Universidad Politécnica de Madrid
Avda. Complutense, s/n
28040 Madrid SPAIN
Tel. +34 913367366 ext.3034
-----Mensaje original-----
De: BJ Hargrave [mailto:hargrave@us.ibm.com]
Enviado el: martes, 11 de julio de 2006 17:42
Para: felix-dev@incubator.apache.org
Asunto: Re: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
I guess no one actually tried this out before voting?
I suggest: * ${groupId}.${artifactId} ==> org.apache.felix.felix-shell
for BSN. It is simple and straight forward.
How about something like:
* ${groupId} = org.apache.felix
* ${package} = shell
* ${artifactId} = felix-${package}
* ${bundle-symbolicname} = ${groupId}.${artifactId}
* ${expored-package} = ${groupId}.${package}
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
Office: +1 407 849 9117 Mobile: +1 386 848 3788
"Richard S. Hall" <he...@ungoverned.org>
07/11/2006 10:30 AM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Re: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
A follow up on this topic.
I was going to sit down and start renaming some of my subprojects
according to the new rules, but then I ran into some issues that I felt
I needed to discuss.
First, I wanted to give people some warning that when I change the name
of the shell-related JAR files then this will effectively break existing
saved bundle profiles. What will actually happen is that all existing
profiles will get a new set of shell-related bundles installed into
them. This is only really problematic for the ShellTUI bundle, since it
uses stdin. The solution is to uninstall the old shell bundles or to
recreate your profiles. For the more adventurous, you could go into the
profile directory and edit the bundle.location files of the
shell-related bundles to match the new name, then you won't get
duplicates.
Second, given the new naming scheme for artifactId, we do not really
have an obvious way to generate the bundle symbolic name. For example,
we will have this information:
groupId = org.apache.felix
artifactId = felix-shell
So, what should the bundle symbolic name for this bundle be?
* ${groupId}.${artifactId} ==> org.apache.felix.felix-shell
* ${artifactId} ==> felix-shell
* f(${groupId},${artifactId}) ==> org.apache.felix.shell
Any suggestions?
I also see another minor downside with this approach in that I am not
able to use variable substitution as much in my pom file, e.g., since
the name of the artifactId was the same as the package I could use
variable substitution in my export-package header.
-> richard
Enrique Rodriguez wrote:
> Richard S. Hall wrote:
>> Time to call this vote:
>>
>> * +1 votes - Marcel Offermans, Richard S. Hall, Stephane Frenot,
>> Trustin Lee, Niclas Hedhman, Enrique Rodriguez, Manuel Santillan,
>> Timothy Bennett, Alan D. Cabrera, and Alex Karasulu.
>> * 0 votes - Stefano Lenzi.
>> * -1 votes - None.
>>
>> So, I guess we can all rename our own subprojects for the time being.
>> Are there going to be any issues we need to consider before starting
>> the rename process? For example, I would guess that we need to remove
>> the existing artifacts from the snapshot repository, no? Is there any
>> thing else?
>
> I think that's it. People should do full re-builds at the root of
> Felix. As you noted, the deploy repo should be manually purged and
> builds tested online.
>
> Enrique
>
RE: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
Posted by santillan <sa...@dit.upm.es>.
BJ's idea sounds *almost* good to me. Maybe it doesn't make sense at all,
but I'd rather not have *.felix.felix-* in the BSN, as I don't see benefits
for the redundancy. How about using the package after the groupId for the
BSN? Do you think that would be useful for soothing interop with the PDE
guys? It'd be something like:
${groupId} = org.apache.felix
${package} = shell
${artifactId} = felix-${package}
<!--${bundle-symbolicname} = ${groupId}.${artifactId}-->
${bundle-symbolicname} = ${groupId}.${package}
${exported-package} = ${groupId}.${package}
--
Manuel Santillán <sa...@dit.upm.es>
http://www.dit.upm.es/santillan
Departamento de Ingeniería de Sistemas Telemáticos
Escuela Técnica Superior de Ingenieros de Telecomunicación
Universidad Politécnica de Madrid
Avda. Complutense, s/n
28040 Madrid SPAIN
Tel. +34 913367366 ext.3034
-----Mensaje original-----
De: BJ Hargrave [mailto:hargrave@us.ibm.com]
Enviado el: martes, 11 de julio de 2006 17:42
Para: felix-dev@incubator.apache.org
Asunto: Re: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
I guess no one actually tried this out before voting?
I suggest: * ${groupId}.${artifactId} ==> org.apache.felix.felix-shell
for BSN. It is simple and straight forward.
How about something like:
* ${groupId} = org.apache.felix
* ${package} = shell
* ${artifactId} = felix-${package}
* ${bundle-symbolicname} = ${groupId}.${artifactId}
* ${expored-package} = ${groupId}.${package}
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
Office: +1 407 849 9117 Mobile: +1 386 848 3788
"Richard S. Hall" <he...@ungoverned.org>
07/11/2006 10:30 AM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Re: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
A follow up on this topic.
I was going to sit down and start renaming some of my subprojects
according to the new rules, but then I ran into some issues that I felt
I needed to discuss.
First, I wanted to give people some warning that when I change the name
of the shell-related JAR files then this will effectively break existing
saved bundle profiles. What will actually happen is that all existing
profiles will get a new set of shell-related bundles installed into
them. This is only really problematic for the ShellTUI bundle, since it
uses stdin. The solution is to uninstall the old shell bundles or to
recreate your profiles. For the more adventurous, you could go into the
profile directory and edit the bundle.location files of the
shell-related bundles to match the new name, then you won't get
duplicates.
Second, given the new naming scheme for artifactId, we do not really
have an obvious way to generate the bundle symbolic name. For example,
we will have this information:
groupId = org.apache.felix
artifactId = felix-shell
So, what should the bundle symbolic name for this bundle be?
* ${groupId}.${artifactId} ==> org.apache.felix.felix-shell
* ${artifactId} ==> felix-shell
* f(${groupId},${artifactId}) ==> org.apache.felix.shell
Any suggestions?
I also see another minor downside with this approach in that I am not
able to use variable substitution as much in my pom file, e.g., since
the name of the artifactId was the same as the package I could use
variable substitution in my export-package header.
-> richard
Enrique Rodriguez wrote:
> Richard S. Hall wrote:
>> Time to call this vote:
>>
>> * +1 votes - Marcel Offermans, Richard S. Hall, Stephane Frenot,
>> Trustin Lee, Niclas Hedhman, Enrique Rodriguez, Manuel Santillan,
>> Timothy Bennett, Alan D. Cabrera, and Alex Karasulu.
>> * 0 votes - Stefano Lenzi.
>> * -1 votes - None.
>>
>> So, I guess we can all rename our own subprojects for the time being.
>> Are there going to be any issues we need to consider before starting
>> the rename process? For example, I would guess that we need to remove
>> the existing artifacts from the snapshot repository, no? Is there any
>> thing else?
>
> I think that's it. People should do full re-builds at the root of
> Felix. As you noted, the deploy repo should be manually purged and
> builds tested online.
>
> Enrique
>
Re: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
Posted by BJ Hargrave <ha...@us.ibm.com>.
I guess no one actually tried this out before voting?
I suggest: * ${groupId}.${artifactId} ==> org.apache.felix.felix-shell
for BSN. It is simple and straight forward.
How about something like:
* ${groupId} = org.apache.felix
* ${package} = shell
* ${artifactId} = felix-${package}
* ${bundle-symbolicname} = ${groupId}.${artifactId}
* ${expored-package} = ${groupId}.${package}
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
Office: +1 407 849 9117 Mobile: +1 386 848 3788
"Richard S. Hall" <he...@ungoverned.org>
07/11/2006 10:30 AM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Re: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
A follow up on this topic.
I was going to sit down and start renaming some of my subprojects
according to the new rules, but then I ran into some issues that I felt
I needed to discuss.
First, I wanted to give people some warning that when I change the name
of the shell-related JAR files then this will effectively break existing
saved bundle profiles. What will actually happen is that all existing
profiles will get a new set of shell-related bundles installed into
them. This is only really problematic for the ShellTUI bundle, since it
uses stdin. The solution is to uninstall the old shell bundles or to
recreate your profiles. For the more adventurous, you could go into the
profile directory and edit the bundle.location files of the
shell-related bundles to match the new name, then you won't get
duplicates.
Second, given the new naming scheme for artifactId, we do not really
have an obvious way to generate the bundle symbolic name. For example,
we will have this information:
groupId = org.apache.felix
artifactId = felix-shell
So, what should the bundle symbolic name for this bundle be?
* ${groupId}.${artifactId} ==> org.apache.felix.felix-shell
* ${artifactId} ==> felix-shell
* f(${groupId},${artifactId}) ==> org.apache.felix.shell
Any suggestions?
I also see another minor downside with this approach in that I am not
able to use variable substitution as much in my pom file, e.g., since
the name of the artifactId was the same as the package I could use
variable substitution in my export-package header.
-> richard
Enrique Rodriguez wrote:
> Richard S. Hall wrote:
>> Time to call this vote:
>>
>> * +1 votes - Marcel Offermans, Richard S. Hall, Stephane Frenot,
>> Trustin Lee, Niclas Hedhman, Enrique Rodriguez, Manuel Santillan,
>> Timothy Bennett, Alan D. Cabrera, and Alex Karasulu.
>> * 0 votes - Stefano Lenzi.
>> * -1 votes - None.
>>
>> So, I guess we can all rename our own subprojects for the time being.
>> Are there going to be any issues we need to consider before starting
>> the rename process? For example, I would guess that we need to remove
>> the existing artifacts from the snapshot repository, no? Is there any
>> thing else?
>
> I think that's it. People should do full re-builds at the root of
> Felix. As you noted, the deploy repo should be manually purged and
> builds tested online.
>
> Enrique
>
Re: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
Posted by "Richard S. Hall" <he...@ungoverned.org>.
A follow up on this topic.
I was going to sit down and start renaming some of my subprojects
according to the new rules, but then I ran into some issues that I felt
I needed to discuss.
First, I wanted to give people some warning that when I change the name
of the shell-related JAR files then this will effectively break existing
saved bundle profiles. What will actually happen is that all existing
profiles will get a new set of shell-related bundles installed into
them. This is only really problematic for the ShellTUI bundle, since it
uses stdin. The solution is to uninstall the old shell bundles or to
recreate your profiles. For the more adventurous, you could go into the
profile directory and edit the bundle.location files of the
shell-related bundles to match the new name, then you won't get duplicates.
Second, given the new naming scheme for artifactId, we do not really
have an obvious way to generate the bundle symbolic name. For example,
we will have this information:
groupId = org.apache.felix
artifactId = felix-shell
So, what should the bundle symbolic name for this bundle be?
* ${groupId}.${artifactId} ==> org.apache.felix.felix-shell
* ${artifactId} ==> felix-shell
* f(${groupId},${artifactId}) ==> org.apache.felix.shell
Any suggestions?
I also see another minor downside with this approach in that I am not
able to use variable substitution as much in my pom file, e.g., since
the name of the artifactId was the same as the package I could use
variable substitution in my export-package header.
-> richard
Enrique Rodriguez wrote:
> Richard S. Hall wrote:
>> Time to call this vote:
>>
>> * +1 votes - Marcel Offermans, Richard S. Hall, Stephane Frenot,
>> Trustin Lee, Niclas Hedhman, Enrique Rodriguez, Manuel Santillan,
>> Timothy Bennett, Alan D. Cabrera, and Alex Karasulu.
>> * 0 votes - Stefano Lenzi.
>> * -1 votes - None.
>>
>> So, I guess we can all rename our own subprojects for the time being.
>> Are there going to be any issues we need to consider before starting
>> the rename process? For example, I would guess that we need to remove
>> the existing artifacts from the snapshot repository, no? Is there any
>> thing else?
>
> I think that's it. People should do full re-builds at the root of
> Felix. As you noted, the deploy repo should be manually purged and
> builds tested online.
>
> Enrique
>
Re: [RESULT] Re: [VOTE] artifactId/repository/JAR file naming
Posted by Enrique Rodriguez <en...@gmail.com>.
Richard S. Hall wrote:
> Time to call this vote:
>
> * +1 votes - Marcel Offermans, Richard S. Hall, Stephane Frenot,
> Trustin Lee, Niclas Hedhman, Enrique Rodriguez, Manuel Santillan,
> Timothy Bennett, Alan D. Cabrera, and Alex Karasulu.
> * 0 votes - Stefano Lenzi.
> * -1 votes - None.
>
> So, I guess we can all rename our own subprojects for the time being.
> Are there going to be any issues we need to consider before starting the
> rename process? For example, I would guess that we need to remove the
> existing artifacts from the snapshot repository, no? Is there any thing
> else?
I think that's it. People should do full re-builds at the root of
Felix. As you noted, the deploy repo should be manually purged and
builds tested online.
Enrique
[RESULT] Re: [VOTE] artifactId/repository/JAR file naming
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Time to call this vote:
* +1 votes - Marcel Offermans, Richard S. Hall, Stephane Frenot,
Trustin Lee, Niclas Hedhman, Enrique Rodriguez, Manuel Santillan,
Timothy Bennett, Alan D. Cabrera, and Alex Karasulu.
* 0 votes - Stefano Lenzi.
* -1 votes - None.
So, I guess we can all rename our own subprojects for the time being.
Are there going to be any issues we need to consider before starting the
rename process? For example, I would guess that we need to remove the
existing artifacts from the snapshot repository, no? Is there any thing
else?
-> richard
Richard S. Hall wrote:
> Currently, Felix uses the following groupId/artifactId naming policy:
>
> * groupId = org.apache.felix
> * artifactId = org.apache.felix.<unique-subproject-name>
>
> The choice of artifactId rears its head in two places:
>
> 1. Sub-project directories in trunk are named after their artifactId.
> 2. Resulting build process JAR files are named after their artifactId.
>
> As a result of these policies, we end up with redundant and really
> long names all over the place.
>
> The proposal on the table is to change the definition of artifactId to:
>
> * artifactId = felix-<unique-subproject-name>
>
> Which would result in names for trunk directories and JAR files like:
> felix-framework, felix-http-jetty, and felix-upnp-sample-clock. (A
> slight variant is to maintain using '.' rather than '-'.)
>
> [ ] +1 In favor of the new naming scheme.
> [ ] 0 Don't care.
> [ ] -1 Opposed to the new naming scheme.
>
>
Re: [VOTE] artifactId/repository/JAR file naming
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Richard S. Hall wrote:
> Currently, Felix uses the following groupId/artifactId naming policy:
>
> * groupId = org.apache.felix
> * artifactId = org.apache.felix.<unique-subproject-name>
>
> The choice of artifactId rears its head in two places:
>
> 1. Sub-project directories in trunk are named after their artifactId.
> 2. Resulting build process JAR files are named after their artifactId.
>
> As a result of these policies, we end up with redundant and really
> long names all over the place.
>
> The proposal on the table is to change the definition of artifactId to:
>
> * artifactId = felix-<unique-subproject-name>
>
> Which would result in names for trunk directories and JAR files like:
> felix-framework, felix-http-jetty, and felix-upnp-sample-clock. (A
> slight variant is to maintain using '.' rather than '-'.)
>
> [ ] +1 In favor of the new naming scheme.
> [ ] 0 Don't care.
> [ ] -1 Opposed to the new naming scheme.
>
+1
BTW, IIUC, you need the '-' so that the subproject name doesn't get
confused w/ the version number.
Regards,
Alan