ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <marcel.offerm...@luminis.nl>
Subject Re: Status Mavenization of ACE
Date Fri, 11 Dec 2009 14:01:53 GMT
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.

Greetings, Marcel


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message