I think it's fine, although I cannot help you with the maven issue... -- Manuel Santillán <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] Enviado el: lunes, 17 de julio de 2006 16:00 Para: [email protected] 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 <[EMAIL PROTECTED]> >> 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:[EMAIL PROTECTED] Enviado el: martes, 11 >> de julio de 2006 17:42 >> Para: [email protected] >> 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 >> [EMAIL PROTECTED] >> Office: +1 407 849 9117 Mobile: +1 386 848 3788 >> >> >> >> "Richard S. Hall" <[EMAIL PROTECTED]> 07/11/2006 10:30 AM >> Please respond to >> [email protected] >> >> >> To >> [email protected] >> 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 >>> >>> >> >> >> >> >
