+1 from me (with the same alternatives selected by Andreas). In addition, I'd like to point out (1) another problem related to Maven repository handling in Pax URL, and I think it would be useful (2) to clarify the meaning and purpose of the different Pax URL release lines.
(1) I recently wrote a regression test for Pax Exam to test the repository() option. I provisioned a bundle from a non-standard repository and expected the test to fail. To my surprise, the test passed, and I could not understand why. Using the debugger, I found out that Pax URL enables some non-standard repositories (including Spring EBR) by default. This is documented nowhere, and I think this is really confusing and dangerous. One of these repositories is something like oss.sonatype.org/paxrunner, and it's totally unclear to me what's in there and how that relates to Pax URL. All this looks to me like legacy from times when Pax Runner was the centre of the Pax Universe. As far as I can tell, http://team.ops4j.org/browse/PAXURL-92 was an attempt to introduce reasonable defaults, which was then reverted in http://team.ops4j.org/browse/PAXURL-95 because it broke someone's tests. My proposal: - The default resolution of the mvn: protocol handler should match the resolution you get from the Maven commandline as closely as possible. I.e. any repositories configured in settings.xml will be considered, and only these. Pax URL shall not use any "default" repositories of its own. - If the current (IMHO broken) behaviour is required for backward compatibility, we should define which older release lines support the old behaviour and which newer ones use standard Maven defaults. Which brings us to (2). There are two active branches in Git, url-1.2.x for Pax URL 1.2.x and master for Pax URL 1.3.x. The JIRA road map list 1.4.0 and 2.0.0 releases both of which have one fixed issue and some unresolved ones. Questions: - What's the difference between Pax URL 1.2.x and 1.3.x? - Which projects use 1.2.x and what's keeping them from upgrading to 1.3.x? - Is there really a need for more than 2 active branches (one for maintenance and one for development)? - What are the proposed incompatible features or changes for 1.4.x and 2.x? - Should the next release with David's changes be a 1.3.6 or a 1.4.0? In addition, I propose to drop the default repositories as discussed above, which is definitely an incompatible change deserving a 1.4.0 release version (probably not big enough for a 2.0.0, but I wouldn't mind that either). Which means that client projects relying on the old defaults should stick to the 1.2.x and 1.3.x release lines, whereas 1.4.x and greater will drop non-standard defaults. Best regards, Harald _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
