As I have close to zero experience with bndtools, I trust you guys :) But looks good to me in general...
Regards Carsten 2012/7/13 Paul Bakker <paul.bak...@luminis.eu>: > I agree that it's fine to have a different view during development and > deployment. In BndTools the mapping is still pretty clear anyway, because the > sub-bnd files map directly to bundles. It's not strictly necessary to merge > projects into one, you could just use working sets to achieve the same view, > but merging them has the extra benefit that there is less configuration for > the build path. > > +1 for merging, and +1 for the proposed list of projects :-) > > Paul > > On Jul 13, 2012, at 1:31 , Marcel Offermans wrote: > >> The migration to Bndtools is coming along nicely. Both the server and target >> are running, and we have all unit and integration tests working. One of the >> next steps is to provide a better overview in Eclipse by merging some >> related bundles into one project. The rationale is that at development time, >> we want to provide a "development view" of the project that helps developers >> when they're working on the codebase. In my opinion, and according to the >> "4+1 view" [1], this does not necessarly mean that this "development view" >> is the same as the "deployment view". In other words, there is no need to >> maintain a 1 on 1 mapping between a project in the development view and a >> bundle in the deployment view. >> >> Therefore we (I worked on this list with Jan Willem) propose to merge some >> of the projects to go from about 90 to about 30 projects (which gives a >> better overview in Eclipse). You should read this list as follows. The first >> line is the project name, any next (indented) line is a project that is >> merged into this new one. So for example, looking at the first one, we >> propose to make an "org.apache.ace.authentication" project that contains 5 >> existing projects. Sometimes in the process, we need to rename or move some >> packages, and things like that we indicate with an "->" arrow plus a new >> name or destination. >> >> org.apache.ace.authentication >> org.apache.ace.authentication -> .impl >> org.apache.ace.authentication.api >> org.apache.ace.authentication.processor.basicauth >> org.apache.ace.authentication.processor.clientcert >> org.apache.ace.authentication.processor.password >> >> org.apache.ace.authentication.itest >> >> org.apache.ace.configurator >> org.apache.ace.configurator -> .impl >> org.apache.ace.configurator.serveruseradmin >> org.apache.ace.configurator.useradmin.task >> >> org.apache.ace.configurator.useradmin.itest >> >> org.apache.ace.connectionfactory >> >> org.apache.ace.consolelogger >> >> org.apache.ace.deployment.provider >> org.apache.ace.deployment.provider.api >> org.apache.ace.deployment.provider.base >> org.apache.ace.deployment.provider.filebased -> @sandbox >> org.apache.ace.deployment.provider.repositorybased >> org.apache.ace.deployment.servlet -> provider.servlet >> org.apache.ace.deployment.streamgenerator -> provider.streamgenerator >> org.apache.ace.deployment.verifier -> provider.verifier >> org.apache.ace.deployment.verifier.ui -> provider.verifier.ui >> >> org.apache.ace.deployment.itest >> >> org.apache.ace.http.redirector >> org.apache.ace.httplistener -> @deprecated, replace it by the Felix >> Whiteboard >> >> org.apache.ace.http.itest -> @deprecated as well, see above >> >> org.apache.ace.integrationtests -> removed >> >> org.apache.ace.itest -> org.apache.ace.test, merge with util-test project >> >> org.apache.ace.location.upnp -> @sandbox, nice example but not necessarily >> something we want to ship >> >> org.apache.ace.log.server >> org.apache.ace.log.servlet -> log.server.servlet >> org.apache.ace.log.task -> log.server.task >> org.apache.ace.server.log.store -> log.server.store >> org.apache.ace.server.log.ui -> log.server.ui >> >> org.apache.ace.log.itest -> log.server.itest >> >> org.apache.ace.nodelauncher >> org.apache.ace.nodelauncher.amazon >> org.apache.ace.nodelauncher.api >> org.apache.ace.nodelauncher.ui >> >> org.apache.ace.processlauncher -> add main() method to make it standalone >> >> org.apache.ace.range.api >> >> org.apache.ace.repository >> org.apache.ace.repository.api >> org.apache.ace.repository.ext >> org.apache.ace.repository.impl >> org.apache.ace.repository.servlet >> org.apache.ace.repository.task >> >> org.apache.ace.repository.itest >> >> org.apache.ace.resourceprocessor.useradmin -> split off to a resource >> processor (can be moved to sandbox and one for the configurator) >> >> org.apache.ace.server.action -> remove!! >> org.apache.ace.server.action.popupmessage -> remove!! >> >> org.apache.ace.util, split off test to org.apache.(i)test and embed other >> classes in other bundles. >> >> org.apache.ace.webui.vaadin >> org.apache.ace.webui.vaadin -> .impl >> org.apache.ace.target.mgmt.ui -> webui.vaadin.target.ui ofzo >> org.apache.ace.tageditor -> webui.vaadin.tageditor >> >> >> org.apache.ace.obr >> org.apache.ace.obr.metadata >> org.apache.ace.obr.servlet >> org.apache.ace.obr.storage >> >> >> >> org.apache.ace.client.automation >> >> org.apache.ace.client.repository >> org.apache.ace.client.repository.api >> org.apache.ace.client.repository.helper.base >> org.apache.ace.client.repository.helper.bundle >> org.apache.ace.client.repository.helper.configuration >> org.apache.ace.client.repository.helper.user >> org.apache.ace.client.repository.impl >> >> org.apache.ace.client.repository.itest >> >> org.apache.ace.client.rest >> >> >> org.apache.ace.managementagent >> >> org.apache.ace.launcher >> >> org.apache.ace.discovery >> org.apache.ace.discovery.api >> org.apache.ace.discovery.property >> org.apache.ace.discovery.upnp -> @sandbox >> >> org.apache.ace.identification >> org.apache.ace.identification.api >> org.apache.ace.identification.ifconfig -> @sandbox >> org.apache.ace.identification.property >> >> org.apache.ace.log >> >> org.apache.ace.log.target >> org.apache.ace.gateway.log -> rename: log.target, split log and task >> org.apache.ace.gateway.log.store -> rename: log.target.store >> org.apache.ace.log.listener -> log.target.listener >> >> org.apache.ace.scheduler >> org.apache.ace.scheduler -> .impl >> org.apache.ace.scheduler.api >> >> org.apache.ace.deployment.target >> org.apache.ace.deployment.api -> target.api >> org.apache.ace.deployment.deploymentadmin -> target.deploymentadmin >> org.apache.ace.deployment.task -> target.task >> org.apache.ace.deployment.task.base -> target.task.base >> >> >> Greetings, Marcel >> >> [1] http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf >> > > -- Carsten Ziegeler cziege...@apache.org
