ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toni Menzel <t...@okidokiteam.com>
Subject Re: Status Mavenization of ACE
Date Fri, 11 Dec 2009 14:16:44 GMT
On Fri, Dec 11, 2009 at 3:01 PM, Marcel Offermans <
marcel.offermans@luminis.nl> 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
toni@okidokiteam.com
http://www.ops4j.org     - New Energy for OSS Communities - Open
Participation Software.

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