[jira] Created: (FELIX-2329) Improve the URL handling in features-maven-plugin regarding the add-features-to-repo goal
Improve the URL handling in features-maven-plugin regarding the add-features-to-repo goal - Key: FELIX-2329 URL: https://issues.apache.org/jira/browse/FELIX-2329 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf-1.4.0 Reporter: Bengt Rodehav Presently the fatures-maven-plugin cannot handle URL's starting with anything else than mvn: and wrap:. As long as mvn: exists later on in the URL, the protocols before mvn: could be skipped since they are not used for the add-features-to-repo goal. E g the following bundle definition should be possible to handle: bundleipojo:mvn:com.acme/artifact/1.0/bundle A similar problem arises when references (beginning with #) and parameters/queries (beginning with ?) are appended to the URL. E g the following bundle definition should be possible to handle: bundlewar:mvn:com.acme/war-artifact/1.0/war?Webapp-Context=my_context/bundle -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2329) Improve the URL handling in features-maven-plugin regarding the add-features-to-repo goal
[ https://issues.apache.org/jira/browse/FELIX-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12865049#action_12865049 ] Bengt Rodehav commented on FELIX-2329: -- Attached to this issue is a modified version of AddFeaturesToRepoMojo.java. I added two configuration parameters: - skipNonMavenProtocols: Setting this to true (false is default) causes the plugin to look for the first occurence of mvn: and start passing the url from there. This enables url's like bundleipojo:mvn:com.acme/artifact/1.0/bundle. - skipUrlParameters: Setting this to true (false is default) causes the plugin to truncate the url if a # or a ? is encountered. This enables url's like: bundlewar:mvn:com.acme/war-artifact/1.0/war?Webapp-Context=my_context/bundle I haven't contributed to Apache before so you might want to check the code extra carefully. Note that I haven't modified ValidateFeaturesMojo.java. I understand that it implements the validate-features goal. Does it need to be changed too? I haven't used it so I wouldn't know. Anyway, the attached version solves the problems I've had so far. Improve the URL handling in features-maven-plugin regarding the add-features-to-repo goal - Key: FELIX-2329 URL: https://issues.apache.org/jira/browse/FELIX-2329 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf-1.4.0 Reporter: Bengt Rodehav Presently the fatures-maven-plugin cannot handle URL's starting with anything else than mvn: and wrap:. As long as mvn: exists later on in the URL, the protocols before mvn: could be skipped since they are not used for the add-features-to-repo goal. E g the following bundle definition should be possible to handle: bundleipojo:mvn:com.acme/artifact/1.0/bundle A similar problem arises when references (beginning with #) and parameters/queries (beginning with ?) are appended to the URL. E g the following bundle definition should be possible to handle: bundlewar:mvn:com.acme/war-artifact/1.0/war?Webapp-Context=my_context/bundle -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2329) Improve the URL handling in features-maven-plugin regarding the add-features-to-repo goal
[ https://issues.apache.org/jira/browse/FELIX-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bengt Rodehav updated FELIX-2329: - Attachment: AddFeaturesToRepoMojo.java Improve the URL handling in features-maven-plugin regarding the add-features-to-repo goal - Key: FELIX-2329 URL: https://issues.apache.org/jira/browse/FELIX-2329 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf-1.4.0 Reporter: Bengt Rodehav Attachments: AddFeaturesToRepoMojo.java Presently the fatures-maven-plugin cannot handle URL's starting with anything else than mvn: and wrap:. As long as mvn: exists later on in the URL, the protocols before mvn: could be skipped since they are not used for the add-features-to-repo goal. E g the following bundle definition should be possible to handle: bundleipojo:mvn:com.acme/artifact/1.0/bundle A similar problem arises when references (beginning with #) and parameters/queries (beginning with ?) are appended to the URL. E g the following bundle definition should be possible to handle: bundlewar:mvn:com.acme/war-artifact/1.0/war?Webapp-Context=my_context/bundle -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2329) Improve the URL handling in features-maven-plugin regarding the add-features-to-repo goal
[ https://issues.apache.org/jira/browse/FELIX-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12865050#action_12865050 ] Guillaume Nodet commented on FELIX-2329: COuld you please attach a diff file instead of the complete source file ? It makes things way easier to review. In this case, it could be done, when when the changes impact several files, it can become very difficult. Improve the URL handling in features-maven-plugin regarding the add-features-to-repo goal - Key: FELIX-2329 URL: https://issues.apache.org/jira/browse/FELIX-2329 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf-1.4.0 Reporter: Bengt Rodehav Attachments: AddFeaturesToRepoMojo.java Presently the fatures-maven-plugin cannot handle URL's starting with anything else than mvn: and wrap:. As long as mvn: exists later on in the URL, the protocols before mvn: could be skipped since they are not used for the add-features-to-repo goal. E g the following bundle definition should be possible to handle: bundleipojo:mvn:com.acme/artifact/1.0/bundle A similar problem arises when references (beginning with #) and parameters/queries (beginning with ?) are appended to the URL. E g the following bundle definition should be possible to handle: bundlewar:mvn:com.acme/war-artifact/1.0/war?Webapp-Context=my_context/bundle -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2329) Improve the URL handling in features-maven-plugin regarding the add-features-to-repo goal
[ https://issues.apache.org/jira/browse/FELIX-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bengt Rodehav updated FELIX-2329: - Attachment: AddFeaturesToRepoMojo.diff Diff file containing the changes made to AddFeaturesToRepoMojo.java. Improve the URL handling in features-maven-plugin regarding the add-features-to-repo goal - Key: FELIX-2329 URL: https://issues.apache.org/jira/browse/FELIX-2329 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf-1.4.0 Reporter: Bengt Rodehav Attachments: AddFeaturesToRepoMojo.diff, AddFeaturesToRepoMojo.java Presently the fatures-maven-plugin cannot handle URL's starting with anything else than mvn: and wrap:. As long as mvn: exists later on in the URL, the protocols before mvn: could be skipped since they are not used for the add-features-to-repo goal. E g the following bundle definition should be possible to handle: bundleipojo:mvn:com.acme/artifact/1.0/bundle A similar problem arises when references (beginning with #) and parameters/queries (beginning with ?) are appended to the URL. E g the following bundle definition should be possible to handle: bundlewar:mvn:com.acme/war-artifact/1.0/war?Webapp-Context=my_context/bundle -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: Tools to determine correct package version?
I routinely separate API from IPML period;
An API is strictly package based;
An IMPL is strictly service based;
When the API is broken ('er not backwards compatible), I bump the major number;
Thusly, the IMPL version numbering follows suit;
I've never had a problem with bnd or unit testing or run time wiring following
this simple practice; I can get away with simple junit/jmock/hamcrest-matchers
for just about anything/everything;
And I don't even need any maven at all, period, for anything; I have never been
in any situation where I've ever felt I would need a maven;
Reminder: once a bundle is built, it NEVER has to be rebuilt, EVER; Once built,
it's dependencies are STRICTLY run time; Simply put, if you do not have a
guarantee for api breakage (you don't have a design-by-contract API), then you
wire to a specific version only; By standard practice, my contract API is
simply bump the major number if you break the API;
Now if only OSGi supported versioning of services... but you can simply put the
major number in your service name;
As for repositories... deep breath... maven has F'd this simple concept up
too... All you need is to browse the APIs and their contract specification;
Then you pull down the API bundle and the impl bundle(s) depending on what
features they provide;
And, if an API changes, you MUST bring a human in the loop; You do NOT
routinely just bring some latest component down and rerun some test and think
you're done; That is SO WRONG on every level;
TGIF
From: David Jencks
Sent: Thu 5/6/2010 5:20 PM
To: dev@felix.apache.org
Subject: Re: Tools to determine correct package version?
On May 6, 2010, at 11:25 AM, David Bosschaert wrote:
Here's a really short summary of some of the content...
* Let's say you have an interface X version 1.2 that you modify to
include a new method. This would break backwards compatibility for
people who implement this interface. Whether this will bump the
version to 1.3 or 2.0 depends on who typically implements this
interface:
+ If the interface is normally implemented by framework implementors
(including compendium spec implementors), the version should bump to
1.3. This is because the new interface is still compatible with users
of it.
+ If the interface is normally implemented by user bundles, the
version should bump to 2.0 as the change is likely to change user
builds.
Maybe I misunderstand this, but I thought that recent bnd's (not yet in
maven-bundle-plugin despite my best efforts) were based on the idea that
you'd bump the version to 1.3, and
- using bundles would import with a version range of [1.2,2)
- implementing bundles would import with a version range of [1.2,1.3)
True, but the missing piece of information here is that using bundles
sometimes also implement an interface (the Whiteboard Pattern). Take
for example the Configuration Admin Service org.osgi.service.cm
package version 1.3. In there you find a ConfigurationAdmin interface
which is implemented by framework/spec implementors, while its
ManagedService is implemented by users. Hence adding a method to the
ConfigurationAdmin interface will only change the version of the
package to 1.4. But adding a method to ManagedService will change it
to 2.0
I can see a couple possible ways around this:
1. Claim that this package was not designed properly and should be 2 packages,
one containing ConfigurationAdmin and one containing ManagedService which can
then be versioned independently
2. Refine ones understanding of package versions for implementors so that major
version bump means we took some methods/interfaces out and minor version
means we added some new methods which seems to be what Peter's version
policies imply.
(2) seems more reasonable to me, but I'm at the point where I need a bunch of
simple concrete examples I can look at to believe anything in this area.
thanks
david jencks
Best regards,
David
[ANNOUNCE] Welcome Jamie Goodyear in the Felix team.
The Felix PMC has voted Jamie Goodyear as a committer. Welcome on board Jamie ! -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Assigned: (FELIX-2280) To much code duplication in DefaultJDBCLock, OracleJDBCLock and MySQLJDBCLock
[ https://issues.apache.org/jira/browse/FELIX-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie goodyear reassigned FELIX-2280: - Assignee: Jamie goodyear To much code duplication in DefaultJDBCLock, OracleJDBCLock and MySQLJDBCLock - Key: FELIX-2280 URL: https://issues.apache.org/jira/browse/FELIX-2280 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf-1.4.0 Environment: All Reporter: Christian Müller Assignee: Jamie goodyear Attachments: FELIX-2280.patch, FELIX-2280.patch, FELIX-2280.patch, FELIX-2280.patch org.apache.felix.karaf.main.DefaultJDBCLock, org.apache.felix.karaf.main.MySQLJDBCLock and org.apache.felix.karaf.main.OracleJDBCLock has to much code duplications. I propose a solution like in ActiveMQ [package org.apache.activemq.store.jdbc.adapter|http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/store/jdbc/adapter/]. And we should implement some unit tests for it. If it's fine for you, I will try to improve this part of karaf and provide a patch for it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (FELIX-2280) To much code duplication in DefaultJDBCLock, OracleJDBCLock and MySQLJDBCLock
[ https://issues.apache.org/jira/browse/FELIX-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-2280 started by Jamie goodyear. To much code duplication in DefaultJDBCLock, OracleJDBCLock and MySQLJDBCLock - Key: FELIX-2280 URL: https://issues.apache.org/jira/browse/FELIX-2280 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf-1.4.0 Environment: All Reporter: Christian Müller Assignee: Jamie goodyear Attachments: FELIX-2280.patch, FELIX-2280.patch, FELIX-2280.patch, FELIX-2280.patch org.apache.felix.karaf.main.DefaultJDBCLock, org.apache.felix.karaf.main.MySQLJDBCLock and org.apache.felix.karaf.main.OracleJDBCLock has to much code duplications. I propose a solution like in ActiveMQ [package org.apache.activemq.store.jdbc.adapter|http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/store/jdbc/adapter/]. And we should implement some unit tests for it. If it's fine for you, I will try to improve this part of karaf and provide a patch for it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Maven groupId question
On 5/6/10 17:21, Chris Custine wrote: All joking aside, the best place to search for an artifact now is the sonatype Nexus instance which has a complete index of all of maven central. I recommend the GAV search page which also gives you a formatted dependency declaration string for your project: https://repository.sonatype.org/index.html#nexus-search;gav~ Right, I just assumed people would browse using some nice web UI, not trolling the server disk layout. :-) - richard https://repository.sonatype.org/index.html#nexus-search;gav~Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Felix :: http://felix.apache.org Apache Directory Server :: http://directory.apache.org On Thu, May 6, 2010 at 2:52 PM, Guo Dumrdu...@gmail.com wrote: On Thu, May 6, 2010 at 2:21 PM, Richard S. Hallhe...@ungoverned.org wrote: I'm sure there is something wrong with my dev workflow, but I spend a fair amount of time each day browsing maven repositories. I call it Maven spelunking ;-) I guess you are just weird. ;-) Not every day for me. But it's the first place to check when I need a new jar dependency. -Guo
Re: [ANNOUNCE] Welcome Jamie Goodyear in the Felix team.
On 07.05.2010 13:46, Guillaume Nodet wrote: The Felix PMC has voted Jamie Goodyear as a committer. Welcome on board Jamie ! Welcome and Congratulations. Regards Felix
[jira] Updated: (FELIX-2328) [gogo] tidy-up runtime to remove optional code etc
[ https://issues.apache.org/jira/browse/FELIX-2328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall updated FELIX-2328: --- Fix Version/s: gogo-0.6.0 [gogo] tidy-up runtime to remove optional code etc -- Key: FELIX-2328 URL: https://issues.apache.org/jira/browse/FELIX-2328 Project: Felix Issue Type: Improvement Components: Gogo Reporter: Derek Baum Assignee: Derek Baum Priority: Minor Fix For: gogo-0.6.0 now that gogo is going to be the default framework shell, we should tidy-up the runtime component to ensure it is the minimum necessary to implement RFC-147. Currently the runtime also registers many commands, most of which are trivial and should instead be added by the user of the runtime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (FELIX-995) JRE packages are exported with wrong version
[ https://issues.apache.org/jira/browse/FELIX-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall reopened FELIX-995: --- Need to account for ordering of JRE versions. JRE packages are exported with wrong version Key: FELIX-995 URL: https://issues.apache.org/jira/browse/FELIX-995 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-1.4.1 Environment: generic Reporter: Sahoo Assignee: Richard S. Hall Fix For: framework-3.0.0 Felix 1.4.1 exports JRE packages with a version equals to the JRE version. e.g., if I am using Java SE 6, then all packages are exported with version=1.6. This is incorrect. Most of the packages are versioned as per the JSRs they are defined by. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-995) JRE packages are exported with wrong version
[ https://issues.apache.org/jira/browse/FELIX-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall resolved FELIX-995. --- Resolution: Fixed Ok, as crazy as it is, I've modified the JRE package version numbering scheme to enable proper sort order of versions so you can technically use them for version ranges and backwards compatibility. The new scheme is like this: 1_006_JavaSE I put the version first and add some zeroes. I didn't use any zeroes in the major number because I assume we won't live that long. JRE packages are exported with wrong version Key: FELIX-995 URL: https://issues.apache.org/jira/browse/FELIX-995 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-1.4.1 Environment: generic Reporter: Sahoo Assignee: Richard S. Hall Fix For: framework-3.0.0 Felix 1.4.1 exports JRE packages with a version equals to the JRE version. e.g., if I am using Java SE 6, then all packages are exported with version=1.6. This is incorrect. Most of the packages are versioned as per the JSRs they are defined by. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2330) Uninstall, refresh, and resolve osgi shell commands do not support multiple bundle ids
Uninstall, refresh, and resolve osgi shell commands do not support multiple bundle ids -- Key: FELIX-2330 URL: https://issues.apache.org/jira/browse/FELIX-2330 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf 1.6.0 Reporter: Jarek Gawor Fix For: karaf 1.6.0 The uninstall, refresh, and resolve osgi shell commands do not support multiple bundle ids. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2330) Uninstall, refresh, and resolve osgi shell commands do not support multiple bundle ids
[ https://issues.apache.org/jira/browse/FELIX-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated FELIX-2330: --- Attachment: FELIX-2330.patch Updates to uninstall, refresh, and resolve osgi shell commands to work with multiple bundles. Uninstall, refresh, and resolve osgi shell commands do not support multiple bundle ids -- Key: FELIX-2330 URL: https://issues.apache.org/jira/browse/FELIX-2330 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf 1.6.0 Reporter: Jarek Gawor Fix For: karaf 1.6.0 Attachments: FELIX-2330.patch The uninstall, refresh, and resolve osgi shell commands do not support multiple bundle ids. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
