Hi Bram, Yes, I am struggling too with setting up a dev environment using the AMS and AMA. For that reason I am currently still using the old fileinstall strategy, which is much easier and quicker for development. So before fileinstall support is dropped, I really would like to see the dev tools in place. I really would like to see dev tools on the short term roadmap. I do reckon the problems described below, but instead of describing the tools I need, I would like to express it in use cases:
1) Setup default dev environment/AMS prefilling First of all, I would like to have some kind of tool that sets up an AMS prefilled with features and distributions. Distributions for example would be a 'demo-auth' containing platform+auth bundles and a 'demo-opensocial' containing platform+auth+opensocial bundles. 2) Version support With the AMS prefilling I would also like to have several versions in there, so 'demo-auth-0.3.0' and 'demo-auth-0.4.0' for example. This would allow me to compare the current with the previous version, for example for performance analysis or checking if certain bugs were already present in the previous versions. For development this would be a nice to have, but not strictly necessary. I can imagine that this is more important for production environment (test version upgrade on test nodes before deploying it to the production nodes). 3) Updating bundles Now after the initial prefilling, it should be possible to update the bundles with a single maven command. Right now, when using the maven bundle plugin the old version is not removed from the AMS (see AMDATUMNGMNT-8) so you will end up soon with a cluttered AMS and will need to start all over. There should be a mechanism to indicate what artifacts/features should be updated automatically. If multiple versions as in 2) are supported, a new 0.3.0-SNAPSHOT should not overwrite a 0.2.1 version of the same bundle used by another feature. 4) Updating config schema Updating configuration files (schema, not values) should work like updating bundles, with a single maven command. 5) Changing config values In 0.2.1 you could simply edit the .cfg files on disk or change the value in the Felix web console to change a configuration property like the port number of the http service. This should be supported in 1.0, without the need of writing a client invoking the REST service to create a tag for each editable property. Right now config values are very hard to edit. 6) Adding/removing tenants In 1.0 adding a tenant is very complex. To add a tenant, you should add a .tenant file for the new tenant but also create a new metatype config file for each config that is tenant aware. With the subprojects auth and opensocial installed, you would need to create and edit 4 additional files for each tenant. If we would refactor Cassandra to follow this 'official' approach, we would have 4 more. And if we are running a cluster of three Cassandra nodes, multiply by 3. Additional tenant specific config files may be added for project specific implementations, so in the future it might be necessary to create, edit and upload dozens of files (each of them with a new, unique, filename) to the AMS, just to create a single tenant. This is not only a lot of (manual) work, but also very error-prone. So I would like to see some dev tool that supports adding and removing a tenant automatically. Regards, Ivo -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Bram de Kruijff Sent: donderdag 24 mei 2012 16:09 To: [email protected]; [email protected] Subject: [Amdatu-developers] Amdatu Provisioning and development best practices Hi all, with provisioning in place in I know some people, like me, are struggeling with setting up a nice development environment. We have some tools in place, but I feel we can do better. Here are just some thought ideas and things I have encountered sofar. I'd really like to hear your feedback and ideas. 1) AMS boostrap One of the first things you want to do is setting up an AMS with the Amdatu Platform ready to deploy. To do so you need all processors, bundles and configurations uploaded, associated into features, and distributions. You can do it by hand using webui or create a client to do so. The former gets tiring pretty fast, so I've seen people creating shell scripts, amdatu-maven-plugin import/export models, ace-client based importers Drawback is that everybody is creating and maintaining their own populatiosn/solutions, having to update/upgrade/debug them every time something changes etc. Could we come up with a generic workable solution of most common cases? I want to say "Use the Amdatu Web feature [1,2)", but obviously "Exclude the JSP support". IMHO that should be supported in a way you can automate it as well as do in an eclipse kind of UI dialog. It could be a way to declarative define features/profiles you find in pax/p2/eclipse. I think it would not be far off from the current export/import of artifacts, features and their associations using resolvable uris and common handlers (eg. http/mvn). 2) Development cycle Once you have a populated AMS the next thing a developer wants to do is setting up an efficient development cycle. Our maven-plugin brings some relief but there are some issues here. Eg. the plugin has some timestamp support, but when developing the list of artifacts in the webui quickly become unmanageable. Should we drop and create here? Or find a way to trigger updates with an in place file? This is even more challenging for non-bundle artifacts as the AMS does not support auto-version update on these like it does on bundles. So you could still use the timestamping on files here, but you must then register is under a new name an update the associations with the feature to point to the new configuration artifact. Again, versioning support and/or in place updates would probably make life a lot easier.. Eg. What if we created some kind of (optional) "maven-repository-connector" for artifacts that would sit in the AMS and manage the client artifacts based on observing the repository? It could use the standard versions snapshot logic to (periodically) check for updates. This could also support versioning on non-bundle artifacts (like) config and bridge it to the ACE model that does not support it. Thoughts.. :) I'd love to get some input and ideas. grz Bram _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
