On Fri, Dec 11, 2009 at 3:01 PM, Marcel Offermans < [email protected]> wrote:
> Hi all, > > This morning I tried a "fresh" Maven build (mvn clean install) and I > encountered an issue: > > Downloading: > http://repository.apache.org/snapshots/org/apache/ace/ace-repository-impl/0.8.0-SNAPSHOT/ace-repository-impl-0.8.0-SNAPSHOT.jar > [INFO] Unable to find resource > 'org.apache.ace:ace-repository-impl:jar:0.8.0-SNAPSHOT' in repository > apache.snapshots (http://repository.apache.org/snapshots) > [INFO] snapshot org.apache.ace:ace-log-store:0.8.0-SNAPSHOT: checking for > updates from apache.snapshots > [INFO] > ------------------------------------------------------------------------ > [ERROR] BUILD ERROR > [INFO] > ------------------------------------------------------------------------ > [INFO] Failed to resolve artifact. > > Missing: > ---------- > 1) org.apache.ace:ace-repository-impl:jar:0.8.0-SNAPSHOT > > Try downloading the file manually from the project website. > > Then, install it using the command: > mvn install:install-file -DgroupId=org.apache.ace > -DartifactId=ace-repository-impl -Dversion=0.8.0-SNAPSHOT -Dpackaging=jar > -Dfile=/path/to/file > > Alternatively, if you host your own repository you can deploy the file > there: > mvn deploy:deploy-file -DgroupId=org.apache.ace > -DartifactId=ace-repository-impl -Dversion=0.8.0-SNAPSHOT -Dpackaging=jar > -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] > > Path to dependency: > 1) org.apache.ace:ace-client-repository-impl:bundle:0.8.0-SNAPSHOT > 2) org.apache.ace:ace-repository-impl:jar:0.8.0-SNAPSHOT > > ---------- > 1 required artifact is missing. > > for artifact: > org.apache.ace:ace-client-repository-impl:bundle:0.8.0-SNAPSHOT > > from the specified remote repositories: > apache.snapshots (http://repository.apache.org/snapshots), > central (http://repo1.maven.org/maven2) > > On Dec 10, 2009, at 21:43 , Toni Menzel wrote: > > > Today i managed try out some thoughts on how to do the ACE Target story > > (used & loved in the ant build version). > > Basically those target definitions are sets of ace bundles and some extra > > components (like dependencymanager & configadmin etc.) > > The idea behind these targets is that they are indeed preconfigured sets of > artifacts (in this case bundles + configuration) that can be easily run. > Having a collection of these available really helps people get started > (after building they should be able to run, with one single command, a > server, a target, etc.). > > Eventually, the definition of what goes to a target is something we want to > be able to import into ACE too, so we can self-host our own targets. Having > such a definition in a format that works for Maven, Pax Runner and ACE would > be great. > > > Because this is also a very good way to test our bundles (using pax > exam), i > > was looking for a way to > > - reuse the maven infrastructure > > - reuse this definition as much as possible for different scenarios > > Agreed, doing integration tests means defining such targets and running > tests against them. To optimize the speed of such tests, one can decide to > define custom targets with just the right artifacts to run those tests. Here > I see a lot of synergy between Pax Exam, running tests and ACE, provisioning > the right artifacts. Running tests in a framework that keeps running but > simply gets reconfigured test after test is an interesting direction to go > in. > > > With this, i think it is pretty easy to continue stacking together the > > target definition(s), running "tests" (currently it just checks if every > > bundle resolves+starts), interpreting the possible error log and fix BND > > settings as appropriate. > > > One more word on the ace-target-devgateway stufff: > > currently there is just the bundlelist (in pom), but i am playing with > > embedding & extracting the default settings (as before in those "conf" > > folders) in them as well. Not sure how this turns out, yet. > > One direction we could explore here is to start using Auto Configuration > for this. Part of this specification is the XML format in which > configuration data is supplied. I think I even might still have some code > lying around to convert normal property files into this XML format. > > Yep, sounds like a good direction. Being able to start a default setup without preparing folders&files on disk is crucial i guess. (we already are independent thanks to CM, but we should also offer this next to the disk based config files right away.) > Greetings, Marcel > > -- Toni Menzel Independent Software Developer Professional Profile: http://okidokiteam.com [email protected] http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software.
