ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Status Mavenization of ACE
Date Fri, 11 Dec 2009 14:15:08 GMT
Thanks Toni,

I'm beginning to make some tests now too.

Regards
JB

Toni Menzel wrote:
> fixed.
> 
> On Fri, Dec 11, 2009 at 3:07 PM, Toni Menzel <toni@okidokiteam.com> wrote:
> 
>> my fault. i did a renaming and.. well did not clean my own repo to try.
>> thanks. willl fix asap.
>> (..impl does not exist anymore)
>>
>>
>> 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.
>>>
>>> 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
View raw message