Hi, @David, +1 all other basically have said what I think about it :)
@Harald, I might shed some light about the 1.2.x line It was introduced because Toni started to work on the aether stuff around the 1.3 release and this introduced some serious issues in the beginning to Karaf. That's why I added the 1.2.x line for working with the Karaf 2.2.x line. This results in a need for the 1.2.x line for all Karaf 2.2.x maintenance releases but for Karaf 3.0 we are free to go for a 1.3.x, 1.4.x or what ever we are going to release next :) Regards, Achim 2012/1/10 Harald Wellmann <[email protected]> > +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 > -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/>
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
