Re: SCR Ant Task Download link is broken
I'Ve copied the missing artifacts to the dist directory - they should be available in two hours (after the sync) Regards Carsten 2011/12/13 Carsten Ziegeler : > Thanks for reporting - actually there are several newer artifacts > missing. I'll have a look > > Carsten > > 2011/12/9 Daniel Kuffner : >> Hi, >> >> Just want to note that the SCR Ant Task downloadlink is broken: >> http://felix.apache.org/site/downloads.cgi >> >> regards, >> Daniel > > > > -- > Carsten Ziegeler > cziege...@apache.org -- Carsten Ziegeler cziege...@apache.org
[jira] [Commented] (FELIX-3269) maven SCR plugin @Property is not properly parsed.
[ https://issues.apache.org/jira/browse/FELIX-3269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13169144#comment-13169144 ] Felix Meschberger commented on FELIX-3269: -- Thanks for your report. I would assume that this issue should be "solving itself" with FELIX-3247. > maven SCR plugin @Property is not properly parsed. > -- > > Key: FELIX-3269 > URL: https://issues.apache.org/jira/browse/FELIX-3269 > Project: Felix > Issue Type: Bug > Components: Maven SCR Plugin >Affects Versions: maven-scr-plugin-1.7.4 > Environment: Ubuntu linux 11.10, amd64, Java 1.6 - seems to be a > parser issue. >Reporter: Francisco Olarte > > When parsing the following property annotations: > - > // > @Property(value = "127.0.0.1" // > , label = "Server host" // > , description = "IP address of host to connect to." // > ) > final static String HOST = "host"; > // > @Property(intValue = 5000 // > , label = "Yate server port" // > , description = "Port number to connect to, <=0 to disable this server." > // > ) > final static String PORT = "port"; > // > @Property(value = "" // > , label = "Server name" // > , description = "Name for this server." // > ) > final static String NAME = "name"; > // > @Property(value = "ALL" // > , label = "Server purpose" // > , description = "What this served is going to be used for, used to filter > them." // > ) > - > The metatype.xml is incorrectly generated ( extra chars from the source > picked up into attribut name of AD element for port: > - > description="Conexiones a los servidores de yate."> > description="IP address of host to connect to."/> > > description="Name for this server."/> > description="What this served is going to be used for, used to filter them."/> > > > Notice it only happens in the non-string property, even if I use the same > comment pattern as the others. I think this is related to a previously > reported ( by me ) bug: https://issues.apache.org/jira/browse/FELIX-3234 and > due to the SCR plugin reparsing the source code ( I suppose there is a reason > for not going to the .class file to pick up annotations ). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Felix iPOJO Manipulator version 1.8.2
+1 Regards Felix Am 06.12.2011 um 18:52 schrieb Clement Escoffier: > Hi, > > It's time to cut a release of the iPOJO Manipulator project (1.8.2). > > The release is a bit different this time, has I've released a couple of > artifacts in once (we have aggregated all manipulator front-end in one Maven > reactor), so this releases contains: > * org.apache.felix.ipojo.metadata 1.6.0 > * org.apache.felix.ipojo.manipulator 1.8.2 > * maven-ipojo-plugin 1.8.2 > * ipojo-ant-task 1.8.2 > * bnd-ipojo-plugin 1.8.2 (new module) > * manipulator-project (1.8.2) > > (the changelog is included below) > > Staging repository: > https://repository.apache.org/content/repositories/orgapachefelix-294/ > > You can use this UNIX script to download the release and verify the > signatures: > http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh > > Usage: > sh check_staged_release.sh 294 /tmp/felix-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) > > This vote will be open for 72 hours (at least). > > Regards, > > Clement > > Changelog: > ** Bug >* [FELIX-2825] - The maven-ipojo-plugin does not replace component classes > in WAR files >* [FELIX-2829] - The maven-ipojo-plugin archetype descriptor is not conform >* [FELIX-2833] - The maven-ipojo-plugin does not support manipulating > artifact with a classifier >* [FELIX-3012] - "Duplicate name&signature" problem >* [FELIX-3098] - iPOJO new manipulator crashes when using a custom reporter >* [FELIX-3145] - VerifyError on Java 7 >* [FELIX-3249] - iPOJO Bnd Plugin do not write all the metadatas in the > manifest > > ** Improvement >* [FELIX-3017] - The manipulator should return the original class if it's > already manipulated >* [FELIX-3078] - Introduce resource abstraction in the iPOJO manipulator >* [FELIX-3079] - Adapt the Ant task and the maven plugin to use the new > manipulator capabilities >* [FELIX-3080] - Implement a BND plugin for iPOJO >* [FELIX-3131] - Elements and attributes should conserve the insertion > order >* [FELIX-3204] - @Temporal should handle instantiation-time properties >* [FELIX-3244] - Manipulator : DefaultManifestBuilder should be more > extensible
Re: [VOTE] Release Felix iPOJO Manipulator version 1.8.2
+1 regards, Karl On Tue, Dec 13, 2011 at 7:21 PM, Richard S. Hall wrote: > +1 > > Some minor issues: > > * Not all sources JARs have the DEPS file, but some do. > * bnd-ipojo-plugin doesn't have a DEPS file at all. > * It doesn't seem like you should repeat the change log from the > manipulator back end in each manipulator front end, rather you > should just have a single change in them saying something like > "Upgraded to manipulator 1.8.2". We do something like this for Main > which integrates Framework. Occasionally we have real change log > entries for Main, but most of the time it just says "Updated to > latest framework". > * It also seems like you want your manipulator-project to be more > differentiated from your manipulator, since the former is just a > project pom. For example, its DEPS file says it includes third-party > software, but it doesn't really...the manipulator does. > > -> richard > > > > On 12/6/11 12:52 , Clement Escoffier wrote: >> >> Hi, >> >> It's time to cut a release of the iPOJO Manipulator project (1.8.2). >> >> The release is a bit different this time, has I've released a couple of >> artifacts in once (we have aggregated all manipulator front-end in one Maven >> reactor), so this releases contains: >> * org.apache.felix.ipojo.metadata 1.6.0 >> * org.apache.felix.ipojo.manipulator 1.8.2 >> * maven-ipojo-plugin 1.8.2 >> * ipojo-ant-task 1.8.2 >> * bnd-ipojo-plugin 1.8.2 (new module) >> * manipulator-project (1.8.2) >> >> (the changelog is included below) >> >> Staging repository: >> https://repository.apache.org/content/repositories/orgapachefelix-294/ >> >> You can use this UNIX script to download the release and verify the >> signatures: >> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh >> >> Usage: >> sh check_staged_release.sh 294 /tmp/felix-staging >> >> Please vote to approve this release: >> >> [ ] +1 Approve the release >> [ ] -1 Veto the release (please provide specific comments) >> >> This vote will be open for 72 hours (at least). >> >> Regards, >> >> Clement >> >> Changelog: >> ** Bug >> * [FELIX-2825] - The maven-ipojo-plugin does not replace component >> classes in WAR files >> * [FELIX-2829] - The maven-ipojo-plugin archetype descriptor is not >> conform >> * [FELIX-2833] - The maven-ipojo-plugin does not support manipulating >> artifact with a classifier >> * [FELIX-3012] - "Duplicate name&signature" problem >> * [FELIX-3098] - iPOJO new manipulator crashes when using a custom >> reporter >> * [FELIX-3145] - VerifyError on Java 7 >> * [FELIX-3249] - iPOJO Bnd Plugin do not write all the metadatas in >> the manifest >> >> ** Improvement >> * [FELIX-3017] - The manipulator should return the original class if >> it's already manipulated >> * [FELIX-3078] - Introduce resource abstraction in the iPOJO >> manipulator >> * [FELIX-3079] - Adapt the Ant task and the maven plugin to use the >> new manipulator capabilities >> * [FELIX-3080] - Implement a BND plugin for iPOJO >> * [FELIX-3131] - Elements and attributes should conserve the insertion >> order >> * [FELIX-3204] - @Temporal should handle instantiation-time properties >> * [FELIX-3244] - Manipulator : DefaultManifestBuilder should be more >> extensible -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls
[jira] [Resolved] (FELIX-3270) Deployment admin incorrectly takes snapshots of bundle data areas
[ https://issues.apache.org/jira/browse/FELIX-3270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Offermans resolved FELIX-3270. - Resolution: Fixed Fixed. > Deployment admin incorrectly takes snapshots of bundle data areas > - > > Key: FELIX-3270 > URL: https://issues.apache.org/jira/browse/FELIX-3270 > Project: Felix > Issue Type: Bug > Components: Deployment Admin >Affects Versions: deploymentadmin-0.9.0 >Reporter: Marcel Offermans >Assignee: Marcel Offermans > > The deployment admin implementation relies on a SnapshotCommand to make > snapshots of bundle data areas. However, dus to a mistake in the store() > method, these snapshots don't work. The method incorrectly invokes > storeRecursive(). We actually ran into this issue because we saw an update > deployment fail (hanging in this method because it managed to create an > infinity copy). > storeRecursive(target, ... -> storeRecursive(source, ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FELIX-3270) Deployment admin incorrectly takes snapshots of bundle data areas
[ https://issues.apache.org/jira/browse/FELIX-3270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Offermans reassigned FELIX-3270: --- Assignee: Marcel Offermans > Deployment admin incorrectly takes snapshots of bundle data areas > - > > Key: FELIX-3270 > URL: https://issues.apache.org/jira/browse/FELIX-3270 > Project: Felix > Issue Type: Bug > Components: Deployment Admin >Affects Versions: deploymentadmin-0.9.0 >Reporter: Marcel Offermans >Assignee: Marcel Offermans > > The deployment admin implementation relies on a SnapshotCommand to make > snapshots of bundle data areas. However, dus to a mistake in the store() > method, these snapshots don't work. The method incorrectly invokes > storeRecursive(). We actually ran into this issue because we saw an update > deployment fail (hanging in this method because it managed to create an > infinity copy). > storeRecursive(target, ... -> storeRecursive(source, ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3270) Deployment admin incorrectly takes snapshots of bundle data areas
Deployment admin incorrectly takes snapshots of bundle data areas - Key: FELIX-3270 URL: https://issues.apache.org/jira/browse/FELIX-3270 Project: Felix Issue Type: Bug Components: Deployment Admin Affects Versions: deploymentadmin-0.9.0 Reporter: Marcel Offermans The deployment admin implementation relies on a SnapshotCommand to make snapshots of bundle data areas. However, dus to a mistake in the store() method, these snapshots don't work. The method incorrectly invokes storeRecursive(). We actually ran into this issue because we saw an update deployment fail (hanging in this method because it managed to create an infinity copy). storeRecursive(target, ... -> storeRecursive(source, ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Dependency manager feature suggestion: Allow passing resource attributes to resource adapters
Hello Xander, On Dec 13, 2011, at 10:29 AM, Xander Uiterlinden wrote: > Currently we're using the dependency manager in our project. A feature we > extensively use is the resource adapter. > The resource adapter service gets access to a resource through the > abstraction of a URL. This is a nice abstraction > but raises challenges whenever an implementation requires more properties > of the resource, e.g. the last modification date > or the encoding. > > At the moment we're working our way around it by creating implementing a > custom URLHandler. > > It would be nicer if the resource adapter could be provided with a set of > optional properties. My suggestion would > be to extend the added(URL resource) method of the ResourceHandler with an > additional argument holding a > untyped set of properties. When provided these will be injected into the > resource adapter implementation. Interesting thought. I guess you could compare these properties to the ones you can specify when you register a service. Thinking along, you could also use these to provide a more precise filter condition for the ResourceHandlers you register. I can see how this could speed things up. Greetings, Marcel
Re: [VOTE] Release Felix iPOJO Manipulator version 1.8.2
+1 Some minor issues: * Not all sources JARs have the DEPS file, but some do. * bnd-ipojo-plugin doesn't have a DEPS file at all. * It doesn't seem like you should repeat the change log from the manipulator back end in each manipulator front end, rather you should just have a single change in them saying something like "Upgraded to manipulator 1.8.2". We do something like this for Main which integrates Framework. Occasionally we have real change log entries for Main, but most of the time it just says "Updated to latest framework". * It also seems like you want your manipulator-project to be more differentiated from your manipulator, since the former is just a project pom. For example, its DEPS file says it includes third-party software, but it doesn't really...the manipulator does. -> richard On 12/6/11 12:52 , Clement Escoffier wrote: Hi, It's time to cut a release of the iPOJO Manipulator project (1.8.2). The release is a bit different this time, has I've released a couple of artifacts in once (we have aggregated all manipulator front-end in one Maven reactor), so this releases contains: * org.apache.felix.ipojo.metadata 1.6.0 * org.apache.felix.ipojo.manipulator 1.8.2 * maven-ipojo-plugin 1.8.2 * ipojo-ant-task 1.8.2 * bnd-ipojo-plugin 1.8.2 (new module) * manipulator-project (1.8.2) (the changelog is included below) Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-294/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 294 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours (at least). Regards, Clement Changelog: ** Bug * [FELIX-2825] - The maven-ipojo-plugin does not replace component classes in WAR files * [FELIX-2829] - The maven-ipojo-plugin archetype descriptor is not conform * [FELIX-2833] - The maven-ipojo-plugin does not support manipulating artifact with a classifier * [FELIX-3012] - "Duplicate name&signature" problem * [FELIX-3098] - iPOJO new manipulator crashes when using a custom reporter * [FELIX-3145] - VerifyError on Java 7 * [FELIX-3249] - iPOJO Bnd Plugin do not write all the metadatas in the manifest ** Improvement * [FELIX-3017] - The manipulator should return the original class if it's already manipulated * [FELIX-3078] - Introduce resource abstraction in the iPOJO manipulator * [FELIX-3079] - Adapt the Ant task and the maven plugin to use the new manipulator capabilities * [FELIX-3080] - Implement a BND plugin for iPOJO * [FELIX-3131] - Elements and attributes should conserve the insertion order * [FELIX-3204] - @Temporal should handle instantiation-time properties * [FELIX-3244] - Manipulator : DefaultManifestBuilder should be more extensible
[jira] [Commented] (FELIX-3267) Unable to resolve cause wired to two revisions of same bundle
[
https://issues.apache.org/jira/browse/FELIX-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13168524#comment-13168524
]
Richard S. Hall commented on FELIX-3267:
Try setting the felix.log.level property in conf/config.properties to 4, which
will also print out intermediate resolver errors and post those back here if
they are different than the above error.
This will likely be difficult to determine what's going on if there is no way
to reproduce.
> Unable to resolve cause wired to two revisions of same bundle
> -
>
> Key: FELIX-3267
> URL: https://issues.apache.org/jira/browse/FELIX-3267
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.2
> Environment: Felix Framework 4.0.2
> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.7.0_01
> Java home: c:\Program Files\Java\jdk1.7.0_01\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7" version: "6.1" arch: "amd64" Family: "windows"
>Reporter: Bram de Kruijff
> Attachments: jaxrs-exporter-MANIFEST.MF, jaxrs-importer-MANIFEST.MF
>
>
> Ran into the issue below where the resolver fails to resolve (or at least
> choose) from two revisions of javax.ws.rs from the same exporting bundle. I
> can not readily reproduce it, but the message clearly show it happened.
> Quickly talked it over with Karl and decided to log the issue here:
> Two things to note are:
> 1) The bundles get updates (during) framework startup from fileinstall (maybe
> some kind of race condition).
> 2) The bundle exporting the packages has a cyclic package thing going on
> (attached manifests)
> {quote}
> org.osgi.framework.BundleException: Uses constraint violation. Unable
> to resolve bundle revision org.amdatu.web.rest.wink [21.1] because it
> is exposed to package 'javax.ws.rs' from bundle revisions
> org.amdatu.web.rest.jaxrs [18.1] and org.amdatu.web.rest.jaxrs [18.0]
> via two dependency chains.
> Chain 1:
> org.amdatu.web.rest.wink [21.1]
>import:
> (&(osgi.wiring.package=javax.ws.rs)(version>=1.1.0)(!(version>=2.0.0)))
> |
>export: osgi.wiring.package=javax.ws.rs
> org.amdatu.web.rest.jaxrs [18.1]
> Chain 2:
> org.amdatu.web.rest.wink [21.1]
>import:
> (&(osgi.wiring.package=javax.ws.rs.ext)(version>=1.1.0)(!(version>=2.0.0)))
> |
>export: osgi.wiring.package=javax.ws.rs.ext; uses:=javax.ws.rs
>export: osgi.wiring.package=javax.ws.rs
> org.amdatu.web.rest.jaxrs [18.0]
> -> refresh
> {quote}
> http://www.mail-archive.com/users@felix.apache.org/msg11524.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3269) maven SCR plugin @Property is not properly parsed.
maven SCR plugin @Property is not properly parsed. -- Key: FELIX-3269 URL: https://issues.apache.org/jira/browse/FELIX-3269 Project: Felix Issue Type: Bug Components: Maven SCR Plugin Affects Versions: maven-scr-plugin-1.7.4 Environment: Ubuntu linux 11.10, amd64, Java 1.6 - seems to be a parser issue. Reporter: Francisco Olarte When parsing the following property annotations: - // @Property(value = "127.0.0.1" // , label = "Server host" // , description = "IP address of host to connect to." // ) final static String HOST = "host"; // @Property(intValue = 5000 // , label = "Yate server port" // , description = "Port number to connect to, <=0 to disable this server." // ) final static String PORT = "port"; // @Property(value = "" // , label = "Server name" // , description = "Name for this server." // ) final static String NAME = "name"; // @Property(value = "ALL" // , label = "Server purpose" // , description = "What this served is going to be used for, used to filter them." // ) - The metatype.xml is incorrectly generated ( extra chars from the source picked up into attribut name of AD element for port: - Notice it only happens in the non-string property, even if I use the same comment pattern as the others. I think this is related to a previously reported ( by me ) bug: https://issues.apache.org/jira/browse/FELIX-3234 and due to the SCR plugin reparsing the source code ( I suppose there is a reason for not going to the .class file to pick up annotations ). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: SCR Ant Task Download link is broken
Thanks for reporting - actually there are several newer artifacts missing. I'll have a look Carsten 2011/12/9 Daniel Kuffner : > Hi, > > Just want to note that the SCR Ant Task downloadlink is broken: > http://felix.apache.org/site/downloads.cgi > > regards, > Daniel -- Carsten Ziegeler cziege...@apache.org
[jira] [Created] (FELIX-3268) Cannot build webconsole and webconsole-plugins with JDK 7
Cannot build webconsole and webconsole-plugins with JDK 7 - Key: FELIX-3268 URL: https://issues.apache.org/jira/browse/FELIX-3268 Project: Felix Issue Type: Bug Components: Web Console Environment: Debian unstable x86_64, JDK 7 from http://jdk7.java.net/download.html, Maven 3.0.3 Reporter: Lionel Debroux A search in JIRA returned no match for "native2ascii" and no relevant match for "native", so I'm creating an issue. When trying to build Felix SVN HEAD with JDK 7, the build process stops when it fails to invoke native2ascii in webconsole. It seems that there was a change between JDK 6 and JDK 7, and the 1.0-alpha-1 version of org.codehaus.mojo:native2ascii-maven-plugin in multiple POMs cannot handle it. However, version 1.0-beta-1 (I obtained that version number by removing the "version" parameter entirely) can cope with JDK 7. The patch below fixes the build problem in webconsole & webconsole-plugins: diff --git a/webconsole-plugins/deppack/pom.xml b/webconsole-plugins/deppack/pom.xml index 0c764e6..e576a57 100644 --- a/webconsole-plugins/deppack/pom.xml +++ b/webconsole-plugins/deppack/pom.xml @@ -40,7 +40,7 @@ org.codehaus.mojo native2ascii-maven-plugin - 1.0-alpha-1 + 1.0-beta-1 diff --git a/webconsole-plugins/ds/pom.xml b/webconsole-plugins/ds/pom.xml index 40a3224..338f306 100644 --- a/webconsole-plugins/ds/pom.xml +++ b/webconsole-plugins/ds/pom.xml @@ -40,7 +40,7 @@ org.codehaus.mojo native2ascii-maven-plugin -1.0-alpha-1 +1.0-beta-1 diff --git a/webconsole-plugins/event/pom.xml b/webconsole-plugins/event/pom.xml index b257032..2375eab 100644 --- a/webconsole-plugins/event/pom.xml +++ b/webconsole-plugins/event/pom.xml @@ -48,7 +48,7 @@ org.codehaus.mojo native2ascii-maven-plugin -1.0-alpha-1 +1.0-beta-1 diff --git a/webconsole-plugins/obr/pom.xml b/webconsole-plugins/obr/pom.xml index c4a88f2..3854ca3 100644 --- a/webconsole-plugins/obr/pom.xml +++ b/webconsole-plugins/obr/pom.xml @@ -40,7 +40,7 @@ org.codehaus.mojo native2ascii-maven-plugin - 1.0-alpha-1 + 1.0-beta-1 diff --git a/webconsole-plugins/shell/pom.xml b/webconsole-plugins/shell/pom.xml index 661d3cd..7f1b428 100644 --- a/webconsole-plugins/shell/pom.xml +++ b/webconsole-plugins/shell/pom.xml @@ -40,7 +40,7 @@ org.codehaus.mojo native2ascii-maven-plugin - 1.0-alpha-1 + 1.0-beta-1 diff --git a/webconsole-plugins/upnp/pom.xml b/webconsole-plugins/upnp/pom.xml index 413da08..bb091a4 100644 --- a/webconsole-plugins/upnp/pom.xml +++ b/webconsole-plugins/upnp/pom.xml @@ -48,7 +48,7 @@ org.codehaus.mojo native2ascii-maven-plugin -1.0-alpha-1 +1.0-beta-1 diff --git a/webconsole/pom.xml b/webconsole/pom.xml index bf4e1cb..b9f0db2 100644 --- a/webconsole/pom.xml +++ b/webconsole/pom.xml @@ -69,7 +69,7 @@ org.codehaus.mojo native2ascii-maven-plugin -1.0-alpha-1 +1.0-beta-1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Fwd: Dependency manager feature suggestion: Allow passing resource attributes to resource adapters
Hi all, I'm afraid I sent this message to the wrong list in the first attempt. Please find my feature suggestion below and let me know what you think. -- Forwarded message -- From: Xander Uiterlinden Date: 2011/12/13 Subject: Dependency manager feature suggestion: Allow passing resource attributes to resource adapters To: dev-h...@felix.apache.org Hi all, Currently we're using the dependency manager in our project. A feature we extensively use is the resource adapter. The resource adapter service gets access to a resource through the abstraction of a URL. This is a nice abstraction but raises challenges whenever an implementation requires more properties of the resource, e.g. the last modification date or the encoding. At the moment we're working our way around it by creating implementing a custom URLHandler. It would be nicer if the resource adapter could be provided with a set of optional properties. My suggestion would be to extend the added(URL resource) method of the ResourceHandler with an additional argument holding a untyped set of properties. When provided these will be injected into the resource adapter implementation. Please let me know what you think. Cheers, Xander Uiterlinden
