We are planning on providing extensive documentation on how to work with this new setup. In fact, like Paul says, we already have experience using this setup in other open source and commercial projects. For example, you can take a look at the Amdatu project, for which we provide lots of examples and some videos to get you started:
* Setting up the IDE: http://amdatu.org/howto/ide.html * Creating a web application: http://amdatu.org/howto/createwebapp.html * Cloud deployment (actually talks about using Apache ACE): http://amdatu.org/howto/clouddeployment.html And a primer on modularity: http://amdatu.org/howto/whymodularity.html Greetings, Marcel On Jul 13, 2012, at 13:00 PM, Carsten Ziegeler wrote: > 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 > >
