Re: remote resource problem (was: Practice of releasing small changes before incorporation into a build)
I wasn't able to reproduce the problem. I think I'll just update the parent to alpha-5, check again, then call the release tomorrow. - Brett On 19/06/2007, at 11:39 AM, Jason van Zyl wrote: On 18 Jun 07, at 5:57 PM 18 Jun 07, Brett Porter wrote: Jason, How did you experience this problem with the RR plugin so I can verify it is fixed in a later version? Try building the embedder module in trunk. That's where it failed for me. - Brett On 18/06/2007, at 11:51 AM, Brett Porter wrote: You're right, it's pinned to alpha-2 but 5 is out. Jason - how do I reproduce the error if I want to check it? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: remote resource problem (was: Practice of releasing small changes before incorporation into a build)
On 18 Jun 07, at 11:19 PM 18 Jun 07, Brett Porter wrote: I wasn't able to reproduce the problem. I think I'll just update the parent to alpha-5, check again, then call the release tomorrow. When you update I'll try again as well. - Brett On 19/06/2007, at 11:39 AM, Jason van Zyl wrote: On 18 Jun 07, at 5:57 PM 18 Jun 07, Brett Porter wrote: Jason, How did you experience this problem with the RR plugin so I can verify it is fixed in a later version? Try building the embedder module in trunk. That's where it failed for me. - Brett On 18/06/2007, at 11:51 AM, Brett Porter wrote: You're right, it's pinned to alpha-2 but 5 is out. Jason - how do I reproduce the error if I want to check it? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-dependency-tree changes for 1.1
Hi Joakim, On 19/06/07, Joakim Erdfelt [EMAIL PROTECTED] wrote: Note, Archiva couldn't use the DependencyTree component, as it made assumptions about repository access, availability, search order, and layout that simply were not true. (actually, this is a problem mostly in maven/components, but it still affected Archiva). So, we wrote our own dependency graph / tree routines. It's more flexible, more reliable, faster, uses less memory, and more accurate than the ones in maven components (and the shared dependency tree component too). I even utilized a local version of select classes from plexus-graph (that Jason wants to eventually use for dependency management). Check it out: archiva-dependency-graph [snip] Ah thanks, I wasn't aware of that - I had assumed archiva used dependency-tree, although I haven't got around to looking at archiva yet. That certainly looks like the kind of code I was heading towards - I'll have a proper look and get back to you. I'm just wondering how it could be more accurate than the resolution process that Maven core uses itself? I welcome you to look at it as a potential PoC for dependency handling in maven 2.1. It needs better non-javadoc documentation, but that'll come. Cool. Jason was talking about committing some artifact resolution code this weekend, so hopefully we can start to converge these efforts towards 2.1. BTW. I wrote a VersionComparator that uses logic version sorting too in Archiva. I didn't realize it was a tough thing to do, until I read Kenney's email about versioning http://www.nabble.com/versioning-tf2842865s177.html#a7938087. Check it out: VersionComparator.java https://svn.apache.org/repos/asf/maven/archiva/trunk/archiva-base/archiva-common/src/main/java/org/apache/maven/archiva/common/utils/VersionComparator.java Nice, I'd definitely like to see Kenney's versioning become the default. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding wildcards to IncludesArtifactFilter
Hi Brian, On 18/06/07, Brian E. Fox [EMAIL PROTECTED] wrote: I'm pretty sure I just wrapped the core artifactsFilter impl so that I could deal with the collection. In any case that I can, I try to use the core functionality but sometimes I wrap it to do any additional work needed. This was done mainly because mdep started out at Mojo and I didn't have Karma to influence core. Looking at o.a.m.plugin.dependency.utils.filters, only ScopeFilter delegates to ScopeArtifactFilter from maven-artifact. It's not a problem, it's just that I needed to delegate to an arbitrary ArtifactFilter. Maybe it'd be worth refactoring these filters into ArtifactFilters and moving them into maven-common-artifact-filters in future. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DefaultArtifactCollector event change
On 18/06/07, Jason van Zyl [EMAIL PROTECTED] wrote: As long as you run all the ITs and make sure they work before committing. Running the unit tests is not enough unfortunately. Sure, will do thanks. And I'm still trying to get all the getting prepared for 2.1 before I start fleshing out any specs. But the artifact resolution in 2.0.x is fundamentally wrong in not making a graph of the metadata before the artifacts are materialized so don't be overly surprised if much of the structure there gets wiped out in 2.1. Yep, I figured this would be happening in 2.1. I'm currently targeting 2.0.x but am interested in any work moving this forward. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding wildcards to IncludesArtifactFilter
I've added the new filters to maven-common-artifact-filters as per John's suggestion in MNG-2621. Let me know if there's any probs. Mark On 18/06/07, Mark Hobson [EMAIL PROTECTED] wrote: Hi John, On 16/06/07, John Casey [EMAIL PROTECTED] wrote: Just another pointer to add. I've put together some wildcard filtering support for the assembly plugin, and factored it into a separate library so I could share it with the maven-repository- builder project. These wildcard-enabled filters are by no means perfect, but if you're interested in taking a look, they're in maven- common-artifact-filters under maven/shared. I put them here so we could re-release them independently of Maven, should the need arise. Ah ha, this looks more like what I'm after. I dropped these alternative implementations into my dependency tree changes and they seem to work okay. They're a little less strict that the version I attached to MNG-2621 - in my implementation wildcards can't span id segments (groupId, artifactId, etc), and individual segments can be referred to explicity (e.g. ::jar for type). Have a look at the testcase in the patch and see if you think it's worth merging into your filters: http://jira.codehaus.org/secure/attachment/27995/MNG-2621.patch I'll move to using maven-common-artifact-filters for the time being so we can concentrate the work there. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r546719 - /maven/core-integration-testing/trunk/core-integration-tests/src/test/java/org/apache/maven/integrationtests/MavenIT0002Test.java
On 15/06/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 15/06/07, Jason van Zyl [EMAIL PROTECTED] wrote: If you install the artifacts you'll be fine. The invoker plugin broke which is why they are not installed. You can't simply run the ITs, you must install the plugins and artifacts that are used as part of the ITs. As I go through and find them I update them, but there is still a mixture of some old in there. Ideally the goal is to be able to start with nothing, install the artifacts required for running the ITs, and then run the ITs. So if you see things that aren't updated then fix them. This should ultimately become self-contained: http://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/ Without any requirement for anything to be installed in a remote repository. See the IT problem notes for details. Right. Should the rest of it0002 not be aligned with the new group id too? Yes, just align them if you see they are wrong. I'm still unsure quite how it0002 is meant to pass without core-integration-testing-support being deployed to the remote repo under the new groupId. I run: core-integration-testing/core-integration-testing-support/build.sh core-integration-testing/run-its.sh And it0002 fails since it cannot download org.apache.maven.its:maven-core-it-support:jar:1.0. This is understandable since the test deletes the copy in the local repo installed by build.sh, and then expects it to be downloaded from the remote repo which doesn't exist: http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/its/ Should we not redeploy core-integration-testing-support to the remote repo? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r546719 - /maven/core-integration-testing/trunk/core-integration-tests/src/test/java/org/apache/maven/integrationtests/MavenIT0002Test.java
On 19 Jun 07, at 6:20 AM 19 Jun 07, Mark Hobson wrote: On 15/06/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 15/06/07, Jason van Zyl [EMAIL PROTECTED] wrote: If you install the artifacts you'll be fine. The invoker plugin broke which is why they are not installed. You can't simply run the ITs, you must install the plugins and artifacts that are used as part of the ITs. As I go through and find them I update them, but there is still a mixture of some old in there. Ideally the goal is to be able to start with nothing, install the artifacts required for running the ITs, and then run the ITs. So if you see things that aren't updated then fix them. This should ultimately become self-contained: http://svn.apache.org/repos/asf/maven/core-integration-testing/ trunk/ Without any requirement for anything to be installed in a remote repository. See the IT problem notes for details. Right. Should the rest of it0002 not be aligned with the new group id too? Yes, just align them if you see they are wrong. I'm still unsure quite how it0002 is meant to pass without core-integration-testing-support being deployed to the remote repo under the new groupId. I run: You have to run the outter build first and what we want ultimately is use a test remote repository before the ITs run. We have a problem with them being coupled to the real central. The ITs should ultimately be completely self contained. So that's what I'm moving toward so there are for certain some inconsistencies while I move that way. Anything you see like that the plan is to start from nothing, populate the test remote repository with the IT plugins and artifacts and then run the ITs. The old versions of the ITs artifacts were deployed to central and the new ones I did not so you're going to find some glitches. The overriding concern is the make it self contained. To use a file based remote repository first, then the next stage would be to use the ITs with a test web-based repository, then FTP ... you see where I'm going. Get the base ITs going and then test all our transports, test all our SCM providers ... Take a look at the notes in the IT directory. We have production plugins coupled with many ITs and in each of those listed cases test plugins should be made. Specific tests of a give plugin should be ITs in that particular plugin. I'm sure you're going to find some problems but that's the general plan. So even if you sketch out a bash/ruby script to setup the test repo before running that's the kind of work we need to get done. core-integration-testing/core-integration-testing-support/build.sh core-integration-testing/run-its.sh And it0002 fails since it cannot download org.apache.maven.its:maven-core-it-support:jar:1.0. This is understandable since the test deletes the copy in the local repo installed by build.sh, and then expects it to be downloaded from the remote repo which doesn't exist: http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/maven/its/ Should we not redeploy core-integration-testing-support to the remote repo? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
what mailing list does jira notify on? I cannot remember.
Sorry, I just realized that in my recent email shuffling, I lost one of the mailing lists. Which one does JIRA send notifications on? Is there a list of the maven MLs somewhere? -j -- John Casey --- Maven Developer (http://maven.apache.org) --- Blog: http://www.ejlife.net/blogs/buildchimp
Re: DefaultArtifactCollector event change
Jason van Zyl wrote: On 18 Jun 07, at 10:43 PM 18 Jun 07, Ralph Goers wrote: Jason van Zyl wrote: And I'm still trying to get all the getting prepared for 2.1 before I start fleshing out any specs. But the artifact resolution in 2.0.x is fundamentally wrong in not making a graph of the metadata before the artifacts are materialized so don't be overly surprised if much of the structure there gets wiped out in 2.1. You and I discussed this before. Has any of the code been written to do this? While I have to agree that not creating the graph before processing has fundamental problems, I'm also concerned about what kind of performance impact this might have. I do, but as I told brett (who also asked) what I have is an implementation that is agnostic to policy. What that means is that the spec is required and we need to work on that first. I'm just swamped with client work, the release and generally trying to clean up the wiki and jira but i'll make an attempt this weekend to drop some code. That's cool, that it's agnostic to policy, That way we can apply the policy afterwards and show what the policy in effect does. We can also have a mojo apply several policies, producing several output graphs/trees to illustrate the differences, or we can split off the policies into smaller pieces so we can sequentially apply them - one for scope filtering, one for depMgt application, one for transitive deps maybe, one for snapshot handling, one for including optional dependencies based on code requirements (maybe), one for conflict resolution (latest/oldest for 2 nodes at the same depth). We can even flatten the structure so that we only have 1 version of a dep left in the module hierarchy in the reactor, or let each module use whatever version their subscope tells them to use (so versions can differ per module). I think having something policy-agnostic and filtering it out later is the best way to go - divide and conquer. So what you have doesn't necesarily need the spec applied to - we may just need to add another processing step after it that implements the spec. Whenever we change/improve the spec, it'll be an easy adjustment since it's not hardcoded in the dep resoluion, and we can simply apply different strategies for different versions of the poms/maven versions. -- Kenney Ralph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r546719 - /maven/core-integration-testing/trunk/core-integration-tests/src/test/java/org/apache/maven/integrationtests/MavenIT0002Test.java
On 19/06/07, Jason van Zyl [EMAIL PROTECTED] wrote: You have to run the outter build first and what we want ultimately is use a test remote repository before the ITs run. We have a problem with them being coupled to the real central. The ITs should ultimately be completely self contained. So that's what I'm moving toward so there are for certain some inconsistencies while I move that way. Anything you see like that the plan is to start from nothing, populate the test remote repository with the IT plugins and artifacts and then run the ITs. The old versions of the ITs artifacts were deployed to central and the new ones I did not so you're going to find some glitches. The overriding concern is the make it self contained. To use a file based remote repository first, then the next stage would be to use the ITs with a test web-based repository, then FTP ... you see where I'm going. Get the base ITs going and then test all our transports, test all our SCM providers ... Take a look at the notes in the IT directory. We have production plugins coupled with many ITs and in each of those listed cases test plugins should be made. Specific tests of a give plugin should be ITs in that particular plugin. I'm sure you're going to find some problems but that's the general plan. So even if you sketch out a bash/ruby script to setup the test repo before running that's the kind of work we need to get done. Okay, I can see the direction you're heading towards with making the ITs self-contained, I just wanted to make sure it wasn't failing due to my local set up. I can live with a failing it0002 for now. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: what mailing list does jira notify on? I cannot remember.
nm, found it on: http://people.apache.org/~coar/mlists.html#maven.apache.org ta, -john On 6/19/07, John Casey [EMAIL PROTECTED] wrote: Sorry, I just realized that in my recent email shuffling, I lost one of the mailing lists. Which one does JIRA send notifications on? Is there a list of the maven MLs somewhere? -j -- John Casey --- Maven Developer (http://maven.apache.org) --- Blog: http://www.ejlife.net/blogs/buildchimp -- John Casey --- Maven Developer (http://maven.apache.org) --- Blog: http://www.ejlife.net/blogs/buildchimp
Re: what mailing list does jira notify on? I cannot remember.
John Casey wrote: Sorry, I just realized that in my recent email shuffling, I lost one of the mailing lists. Which one does JIRA send notifications on? Is there a list of the maven MLs somewhere? -j [EMAIL PROTECTED] -- Kenney - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: what mailing list does jira notify on? I cannot remember.
On 19/06/07, John Casey [EMAIL PROTECTED] wrote: Sorry, I just realized that in my recent email shuffling, I lost one of the mailing lists. Which one does JIRA send notifications on? [EMAIL PROTECTED] Is there a list of the maven MLs somewhere? Yep, http://maven.apache.org/mail-lists.html :) Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: what mailing list does jira notify on? I cannot remember.
sorry for the knee-jerk email. :-) I'll spend more time thinking next time -j On 6/19/07, Mark Hobson [EMAIL PROTECTED] wrote: On 19/06/07, John Casey [EMAIL PROTECTED] wrote: Sorry, I just realized that in my recent email shuffling, I lost one of the mailing lists. Which one does JIRA send notifications on? [EMAIL PROTECTED] Is there a list of the maven MLs somewhere? Yep, http://maven.apache.org/mail-lists.html :) Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey --- Maven Developer (http://maven.apache.org) --- Blog: http://www.ejlife.net/blogs/buildchimp
Re: maven-dependency-tree changes for 1.1
On 6/19/07, Mark Hobson [EMAIL PROTECTED] wrote: Hi Joakim, On 19/06/07, Joakim Erdfelt [EMAIL PROTECTED] wrote: Note, Archiva couldn't use the DependencyTree component, as it made assumptions about repository access, availability, search order, and layout that simply were not true. (actually, this is a problem mostly in maven/components, but it still affected Archiva). So, we wrote our own dependency graph / tree routines. It's more flexible, more reliable, faster, uses less memory, and more accurate than the ones in maven components (and the shared dependency tree component too). I even utilized a local version of select classes from plexus-graph (that Jason wants to eventually use for dependency management). Check it out: archiva-dependency-graph [snip] Ah thanks, I wasn't aware of that - I had assumed archiva used dependency-tree, although I haven't got around to looking at archiva yet. That certainly looks like the kind of code I was heading towards - I'll have a proper look and get back to you. I'm just wondering how it could be more accurate than the resolution process that Maven core uses itself? what would be the point of having a different resolution than the one maven uses? If I see a dependency graph different of what maven uses it would be really confusing other than that let's just choose one of the libraries and deprecate the other one to avoid splitting the work I welcome you to look at it as a potential PoC for dependency handling in maven 2.1. It needs better non-javadoc documentation, but that'll come. Cool. Jason was talking about committing some artifact resolution code this weekend, so hopefully we can start to converge these efforts towards 2.1. BTW. I wrote a VersionComparator that uses logic version sorting too in Archiva. I didn't realize it was a tough thing to do, until I read Kenney's email about versioning http://www.nabble.com/versioning-tf2842865s177.html#a7938087. Check it out: VersionComparator.java https://svn.apache.org/repos/asf/maven/archiva/trunk/archiva-base/archiva-common/src/main/java/org/apache/maven/archiva/common/utils/VersionComparator.java Nice, I'd definitely like to see Kenney's versioning become the default. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven plugin dependency problem
Hello, I'm currently developping a Maven plugin, and I have a problem if I use it in command line (but if I use it in a project, It works fine). I've got 'Failed to resolve artifact' error. So I execute it with : mvn install:install-file homega.tools:obrPlugin:repository -Dfile= org.apache.felix.ipojo-0.7.1-incubator-SNAPSHOT.jar -DartifactId=ipojo -DgroupId=org.apache.felix -Dversion=0.7.1-incubator-SNAPSHOT-Dpackaging=jar In fact the specified file (here: org.apache.felix.ipojo-0.7.1-incubator-SNAPSHOT.jar) will be installed with groupId, artifactId and version given, then my plugin will be executed. So Maven tries to download all the dependencies used by my plugin, but instead of using the version and groupId specified in my plugin pom.xmlfile, it changes this two fields by groupId and version specified in command line. this is a part of my plugin pom.xml file: ... dependency groupIdorg.apache.felix/groupId artifactIdorg.osgi.core/artifactId version0.9.0-incubator-SNAPSHOT/version scopeprovided/scope /dependency ... and the result of an execution: C:\projet\Stagemvn install:install-file homega.tools:obrPlugin:repository-Dfile= org.apache.felix.ipojo-0.7.1 -incubator-SNAPSHOT.jar -DartifactId=ipojo -DgroupId=test -Dversion=0.7.7-Dpackaging=jar [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'install'. [INFO] [INFO] Building Unnamed - tools:ipojo:jar:0.7.1 [INFO]task-segment: [install:install-file] (aggregator-style) [INFO] [INFO] [install:install-file] [INFO] Installing C:\projet\Stage\org.apache.felix.ipojo- 0.7.1-incubator-SNAPSHOT.jar to C:\projet\Stage\mvn_r epo\test\ipojo\0.7.7\ipojo-0.7.7.jar [INFO] [INFO] Building Unnamed - tools:ipojo:jar:0.7.1 [INFO]task-segment: [homega.tools:obrPlugin:repository] [INFO] Downloading: http://repo1.maven.org/maven2/test/org.osgi.core/0.7.7/org.osgi.core-0.7.7.pom Downloading: http://repo1.maven.org/maven2/test/org.osgi.core/0.7.7/org.osgi.core-0.7.7.pom Downloading: http://repo1.maven.org/maven2/test/org.apache.felix.shell/0.7.7/org.apache.felix.shell-0.7.7.pom Downloading: http://repo1.maven.org/maven2/test/org.apache.felix.shell/0.7.7/org.apache.felix.shell-0.7.7.pom Downloading: http://repo1.maven.org/maven2/test/org.osgi.core/0.7.7/org.osgi.core-0.7.7.jar Downloading: http://repo1.maven.org/maven2/test/org.apache.felix.shell/0.7.7/org.apache.felix.shell-0.7.7.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) test:org.osgi.core:jar:0.7.7 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=test -DartifactId=org.osgi.core \ -Dversion=0.7.7 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) homega.tools:obrPlugin:maven-plugin:1.0.0 2) org.apache.felix:org.apache.felix.shell:jar:0.9.0-incubator-SNAPSHOT 3) test:org.osgi.core:jar:0.7.7 2) test:org.apache.felix.shell:jar:0.7.7 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=test -DartifactId= org.apache.felix.shell \ -Dversion=0.7.7 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) homega.tools:obrPlugin:maven-plugin:1.0.0 2) org.apache.felix:org.apache.felix.bundlerepository:jar:0.9.0-incubator-SNAPSHOT 3) test:org.apache.felix.shell:jar:0.7.7 -- 2 required artifacts are missing. But if I install my file in the same groupId and version than the dependencies (ie: org.apache.felix, 0.9.0-incubator-SNAPSHOT), it works fine. example: C:\projet\Stagemvn install:install-file homega.tools:obrPlugin:repository-Dfile= org.apache.felix.ipojo-0.7.1 -incubator-SNAPSHOT.jar -DartifactId=ipojo -DgroupId=org.apache.felix-Dversion= 0.9.0-incubator-SNAPSHOT -Dpac kaging=jar [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'install'. [INFO] [INFO] Building Unnamed - tools:ipojo:jar:0.7.1 [INFO]task-segment: [install:install-file] (aggregator-style) [INFO] [INFO] [install:install-file] [INFO] Installing C:\projet\Stage\org.apache.felix.ipojo- 0.7.1-incubator-SNAPSHOT.jar to C:\projet\Stage\mvn_r epo\org\apache\felix\ipojo\0.9.0-incubator-SNAPSHOT\ipojo- 0.9.0-incubator-SNAPSHOT.jar [INFO]
Re: maven-dependency-tree changes for 1.1
On 19/06/07, Carlos Sanchez [EMAIL PROTECTED] wrote: On 6/19/07, Mark Hobson [EMAIL PROTECTED] wrote: Ah thanks, I wasn't aware of that - I had assumed archiva used dependency-tree, although I haven't got around to looking at archiva yet. That certainly looks like the kind of code I was heading towards - I'll have a proper look and get back to you. I'm just wondering how it could be more accurate than the resolution process that Maven core uses itself? what would be the point of having a different resolution than the one maven uses? If I see a dependency graph different of what maven uses it would be really confusing I agree, this is what I was trying to say. other than that let's just choose one of the libraries and deprecate the other one to avoid splitting the work archiva-dependency-graph appears to be quite tied in to archiva itself, so I'm not sure how easy it'd be to move away from that. The situation so far appears to be: - maven-dependency-tree uses the 2.0.x core APIs to build the same tree as Maven actually uses - archiva-dependency-graph is a good proof-of-concept of how graph-based resolution could be implemented in 2.1, although is currently quite tied to archiva itself - Jason has some code for graph-based resolution in 2.1, which will supersede and replace the need for maven-dependency-tree I believe maven-dependency-tree is still relevant for 2.0.x and I will continue to work on it since that's the version I'm targeting. Once the spec and implementation is done for 2.1, it should be very easy to move these diagnostic tools over to use that instead. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-dependency-tree changes for 1.1
The list of resolved dependencies is equivalent to what maven has. And speaking of different resolutions, even now, maven 2.0.5 and 2.0.6 resolve differently. In my tests 2.0.6 does a worse job choosing the 'latest' version of a dep when in conflict, maven 2.0.5 picks correctly. When I say more accurate it doesn't mean that the it has a different list of deps, just more accurate as to where they come from. A good example of this is direct dependencies that arrive in via Parent pom. Under maven 2.0.5, they show as direct deps, under maven 2.0.6 it shows up as transitive (seems to only occure if that same dep shows up as a transitive dep later on) The implementation on archiva side shows it as direct (which it should be). Hence more accurate. Not different. I've also seen maven choose different deps during a conflict based on the order of the deps in the dependency list. A common one i keep hitting is the xml-apis version, maven 2.0.6 chooses (incorrectly) the 1.0.x series, when in the same tree 1.3.x series is available (and usually closer to the project than the 1.0.x series). If you perform the dependency-tree lookup using a plugin or report, you can get different results than if you run it standalone (not within the maven execution environment). I suspect that this is due to the existence of the maven core components within the $M2_HOME/lib that overrides whatever version you specify in the plugin. In short. The archiva one is consistent to compile / test scoped deps that maven client uses for the same project. I even created an archivadev:create-dependency-tests plugin to take the shared-dependency-tree results of the project, and generate testcases that ensure an identical resolution of artifacts. - Joakim Erdfelt Carlos Sanchez wrote: On 6/19/07, Mark Hobson [EMAIL PROTECTED] wrote: Hi Joakim, On 19/06/07, Joakim Erdfelt [EMAIL PROTECTED] wrote: Note, Archiva couldn't use the DependencyTree component, as it made assumptions about repository access, availability, search order, and layout that simply were not true. (actually, this is a problem mostly in maven/components, but it still affected Archiva). So, we wrote our own dependency graph / tree routines. It's more flexible, more reliable, faster, uses less memory, and more accurate than the ones in maven components (and the shared dependency tree component too). I even utilized a local version of select classes from plexus-graph (that Jason wants to eventually use for dependency management). Check it out: archiva-dependency-graph [snip] Ah thanks, I wasn't aware of that - I had assumed archiva used dependency-tree, although I haven't got around to looking at archiva yet. That certainly looks like the kind of code I was heading towards - I'll have a proper look and get back to you. I'm just wondering how it could be more accurate than the resolution process that Maven core uses itself? what would be the point of having a different resolution than the one maven uses? If I see a dependency graph different of what maven uses it would be really confusing other than that let's just choose one of the libraries and deprecate the other one to avoid splitting the work I welcome you to look at it as a potential PoC for dependency handling in maven 2.1. It needs better non-javadoc documentation, but that'll come. Cool. Jason was talking about committing some artifact resolution code this weekend, so hopefully we can start to converge these efforts towards 2.1. BTW. I wrote a VersionComparator that uses logic version sorting too in Archiva. I didn't realize it was a tough thing to do, until I read Kenney's email about versioning http://www.nabble.com/versioning-tf2842865s177.html#a7938087. Check it out: VersionComparator.java https://svn.apache.org/repos/asf/maven/archiva/trunk/archiva-base/archiva-common/src/main/java/org/apache/maven/archiva/common/utils/VersionComparator.java Nice, I'd definitely like to see Kenney's versioning become the default. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-dependency-tree changes for 1.1
Mark Hobson wrote: On 19/06/07, Carlos Sanchez [EMAIL PROTECTED] wrote: On 6/19/07, Mark Hobson [EMAIL PROTECTED] wrote: Ah thanks, I wasn't aware of that - I had assumed archiva used dependency-tree, although I haven't got around to looking at archiva yet. That certainly looks like the kind of code I was heading towards - I'll have a proper look and get back to you. I'm just wondering how it could be more accurate than the resolution process that Maven core uses itself? what would be the point of having a different resolution than the one maven uses? If I see a dependency graph different of what maven uses it would be really confusing I agree, this is what I was trying to say. I chose to ensure consistency with maven itself. It is not nearly as confusing as it is now. other than that let's just choose one of the libraries and deprecate the other one to avoid splitting the work archiva-dependency-graph appears to be quite tied in to archiva itself, so I'm not sure how easy it'd be to move away from that. The situation so far appears to be: - maven-dependency-tree uses the 2.0.x core APIs to build the same tree as Maven actually uses - archiva-dependency-graph is a good proof-of-concept of how graph-based resolution could be implemented in 2.1, although is currently quite tied to archiva itself There are few decisions here in archiva. 1) The need to resolve project models differently. Archiva doesn't have a local repository, it has many managed repos. Archiva doesn't communicate with a remote repository unless directed to do so because of a client request. Archiva set up a ProjectModelResolver interface with a ProjectModelResolverStack to allow for control over the project resolution process. Currently, archiva does resolution via the ProjectModelResolverStack, which specifies the order ... from DB/jpox, then managed repos, then a dummy model. This resolver stack also has a listener setup that allows for just in time persistence of newly discovered models. Very nice. 2) The choice of persistence engine (jpox) and insistence on using modello by other devs meant I couldn't use the maven/components model. 3) The model read / write via xpp3 was a PITA. Archiva uses a proper SAX/DOM (and can even get around the mess that trygvis's name causes. ;-) Archiva also uses xpath to load 3.0.0 and 4.0.0 into the same persisted model, making serving them out to m1 or m2 clients trivial. I want to see maven 2.1 fixed in regards to project model resolution. The current mess in maven/components is completely unusable within archiva. If that occurs, then the rest of the dependency graph resolution bits will fall into line easily. (It did for archiva.) - Jason has some code for graph-based resolution in 2.1, which will supersede and replace the need for maven-dependency-tree I based the archiva-dependency-graph entirely off of discussions with jason about how to do the dependency resolution bits. I intentionally decoupled as much as I could to make the porting out of archiva easier. I believe maven-dependency-tree is still relevant for 2.0.x and I will continue to work on it since that's the version I'm targeting. Once the spec and implementation is done for 2.1, it should be very easy to move these diagnostic tools over to use that instead. - Joakim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven 2.0.7 (take 2)
+1 How can I not vote +1? After all, according to the META-INF/MANIFEST.MF in the maven-core-2.0.7-uber.jar I built it. Niggle: It still feels wrong to have the maven-core-2.0.7-uber.jar have a LICENSE.txt in it's root that says it's a GPL'd application. - Joakim Jason van Zyl wrote: Hi, The release notes are here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=13138 The tag is here: http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.7/ Staging repository: http://people.apache.org/~jvanzyl/maven-2.0.7-staging-repository/ And the distros you are interested in are here: http://people.apache.org/~jvanzyl/maven-2.0.7/ Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Joakim Erdfelt [EMAIL PROTECTED] Open Source Software (OSS) Developer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven 2.0.7 (take 2)
+1 Arnaud On 19/06/07, Joakim Erdfelt [EMAIL PROTECTED] wrote: +1 How can I not vote +1? After all, according to the META-INF/MANIFEST.MF in the maven-core-2.0.7-uber.jar I built it. Niggle: It still feels wrong to have the maven-core-2.0.7-uber.jar have a LICENSE.txt in it's root that says it's a GPL'd application. - Joakim Jason van Zyl wrote: Hi, The release notes are here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=13138 The tag is here: http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.7/ Staging repository: http://people.apache.org/~jvanzyl/maven-2.0.7-staging-repository/ And the distros you are interested in are here: http://people.apache.org/~jvanzyl/maven-2.0.7/ Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Joakim Erdfelt [EMAIL PROTECTED] Open Source Software (OSS) Developer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - [EMAIL PROTECTED] www.octo.com | blog.octo.com .. ASF - [EMAIL PROTECTED] www.apache.org | maven.apache.org ...
Re: Planning for 1.0-alpha-2
There are a few proxy related bugs left to work out in 1.0-alpha-2, I'd like to get a functional proxying working for the 1.0-alpha-2 release. I think this weekend might be doable. But that depends on the help testing the bug fixes. - Joakim Wendy Smoak wrote: How does the weekend of June 23rd sound for another Archiva alpha release? Joakim, are you already planning to do one before then? Any thoughts on how many of the 110 issues marked for 1.0-alpha-2 in jira could actually make it in that two-week time frame? Thanks, Wendy
Re: svn commit: r546719 - /maven/core-integration-testing/trunk/core-integration-tests/src/test/java/org/apache/maven/integrationtests/MavenIT0002Test.java
On 19 Jun 07, at 8:39 AM 19 Jun 07, Mark Hobson wrote: On 19/06/07, Jason van Zyl [EMAIL PROTECTED] wrote: You have to run the outter build first and what we want ultimately is use a test remote repository before the ITs run. We have a problem with them being coupled to the real central. The ITs should ultimately be completely self contained. So that's what I'm moving toward so there are for certain some inconsistencies while I move that way. Anything you see like that the plan is to start from nothing, populate the test remote repository with the IT plugins and artifacts and then run the ITs. The old versions of the ITs artifacts were deployed to central and the new ones I did not so you're going to find some glitches. The overriding concern is the make it self contained. To use a file based remote repository first, then the next stage would be to use the ITs with a test web-based repository, then FTP ... you see where I'm going. Get the base ITs going and then test all our transports, test all our SCM providers ... Take a look at the notes in the IT directory. We have production plugins coupled with many ITs and in each of those listed cases test plugins should be made. Specific tests of a give plugin should be ITs in that particular plugin. I'm sure you're going to find some problems but that's the general plan. So even if you sketch out a bash/ruby script to setup the test repo before running that's the kind of work we need to get done. Okay, I can see the direction you're heading towards with making the ITs self-contained, I just wanted to make sure it wasn't failing due to my local set up. I can live with a failing it0002 for now. If you do mvn install in the parent IT directory all the plugins and artifacts required will be installed and the ITs will pass. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Upload request (cannot submit via Jira)
Hi, I'd like to ask for the upload of http://people.apache.org/~jochen/rat-lib-0.5.1-bundle.jar I was, of course, trying to submit this via Jira, but after submitting the request, Jira always replies with an error message like Errors * Error instantiating webwork.multipart.parser.class: com.atlassian.jira.web.JiraMultipartRequestWrapper(original message: null) You have not selected a valid project to create an issue in. I seem to have a lot of issues with Codehaus' Jira these days. :-( Thanks, Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven 2.0.7 (take 2)
+1 On 6/19/07, Arnaud HERITIER [EMAIL PROTECTED] wrote: +1 Arnaud On 19/06/07, Joakim Erdfelt [EMAIL PROTECTED] wrote: +1 How can I not vote +1? After all, according to the META-INF/MANIFEST.MF in the maven-core-2.0.7-uber.jar I built it. Niggle: It still feels wrong to have the maven-core-2.0.7-uber.jar have a LICENSE.txt in it's root that says it's a GPL'd application. - Joakim Jason van Zyl wrote: Hi, The release notes are here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=13138 The tag is here: http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.7/ Staging repository: http://people.apache.org/~jvanzyl/maven-2.0.7-staging-repository/ And the distros you are interested in are here: http://people.apache.org/~jvanzyl/maven-2.0.7/ Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Joakim Erdfelt [EMAIL PROTECTED] Open Source Software (OSS) Developer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - [EMAIL PROTECTED] www.octo.com | blog.octo.com .. ASF - [EMAIL PROTECTED] www.apache.org | maven.apache.org ... -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Planning for 1.0-alpha-2
Hi Joakim, which proxy related bugs do you think of? I've tested Archiva proxying for some days, and it works pretty good for me. I mean, if we'd have to release alpha-2, I wouldn't say no. :-) Fabrice. On 6/19/07, Joakim Erdfelt [EMAIL PROTECTED] wrote: There are a few proxy related bugs left to work out in 1.0-alpha-2, I'd like to get a functional proxying working for the 1.0-alpha-2 release. I think this weekend might be doable. But that depends on the help testing the bug fixes. - Joakim Wendy Smoak wrote: How does the weekend of June 23rd sound for another Archiva alpha release? Joakim, are you already planning to do one before then? Any thoughts on how many of the 110 issues marked for 1.0-alpha-2 in jira could actually make it in that two-week time frame? Thanks, Wendy
Re: [VOTE] Release Maven 2.0.7 (take 2)
+1 (non-binding) successful on Mac for large reactor build of 20+ subprojects, plus a bunch of plugin projects. On Jun 19, 2007, at 5:33 PM, Jesse McConnell wrote: +1 On 6/19/07, Arnaud HERITIER [EMAIL PROTECTED] wrote: +1 Arnaud On 19/06/07, Joakim Erdfelt [EMAIL PROTECTED] wrote: +1 How can I not vote +1? After all, according to the META-INF/ MANIFEST.MF in the maven-core-2.0.7-uber.jar I built it. Niggle: It still feels wrong to have the maven-core-2.0.7- uber.jar have a LICENSE.txt in it's root that says it's a GPL'd application. - Joakim Jason van Zyl wrote: Hi, The release notes are here: http://jira.codehaus.org/secure/ReleaseNote.jspa? projectId=10500styleName=Htmlversion=13138 The tag is here: http://svn.apache.org/repos/asf/maven/components/tags/ maven-2.0.7/ Staging repository: http://people.apache.org/~jvanzyl/maven-2.0.7-staging-repository/ And the distros you are interested in are here: http://people.apache.org/~jvanzyl/maven-2.0.7/ Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Joakim Erdfelt [EMAIL PROTECTED] Open Source Software (OSS) Developer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - [EMAIL PROTECTED] www.octo.com | blog.octo.com .. ASF - [EMAIL PROTECTED] www.apache.org | maven.apache.org ... -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release Maven 2.0.7 (take 2)
+1 tested ok on my builds. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Sunday, June 17, 2007 11:47 AM To: Maven Developers List Subject: [VOTE] Release Maven 2.0.7 (take 2) Hi, The release notes are here: http://jira.codehaus.org/secure/ReleaseNote.jspa? projectId=10500styleName=Htmlversion=13138 The tag is here: http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.7/ Staging repository: http://people.apache.org/~jvanzyl/maven-2.0.7-staging-repository/ And the distros you are interested in are here: http://people.apache.org/~jvanzyl/maven-2.0.7/ Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven 2.0.7 (take 2)
+1 fixes my issues On 17 Jun 2007, at 18:47, Jason van Zyl wrote: Hi, The release notes are here: http://jira.codehaus.org/secure/ReleaseNote.jspa? projectId=10500styleName=Htmlversion=13138 The tag is here: http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.7/ Staging repository: http://people.apache.org/~jvanzyl/maven-2.0.7-staging-repository/ And the distros you are interested in are here: http://people.apache.org/~jvanzyl/maven-2.0.7/ Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven 2.0.7 (take 2)
Good, it's looking like this puppy will go out tomorrow morning. On 17 Jun 07, at 10:47 AM 17 Jun 07, Jason van Zyl wrote: Hi, The release notes are here: http://jira.codehaus.org/secure/ReleaseNote.jspa? projectId=10500styleName=Htmlversion=13138 The tag is here: http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.7/ Staging repository: http://people.apache.org/~jvanzyl/maven-2.0.7-staging-repository/ And the distros you are interested in are here: http://people.apache.org/~jvanzyl/maven-2.0.7/ Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Reminder to vote for 2.0.8 issues
Just a reminder for anyone lurking who wants issues addressed in 2.0.8 to vote for issues in JIRA. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Reminder to vote for 2.0.8 issues
I'd like to see about getting 2.0.x up to a newer container. Not only would this fix my plexus thousands of warnings issue, but more importantly it would get some more synergy between 2.0 and 2.1 especially as it relates to various plexus components. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 19, 2007 6:47 PM To: Maven Developers List Subject: Reminder to vote for 2.0.8 issues Just a reminder for anyone lurking who wants issues addressed in 2.0.8 to vote for issues in JIRA. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reminder to vote for 2.0.8 issues
On 19 Jun 07, at 6:26 PM 19 Jun 07, Brian E. Fox wrote: I'd like to see about getting 2.0.x up to a newer container. Not only would this fix my plexus thousands of warnings issue, but more importantly it would get some more synergy between 2.0 and 2.1 especially as it relates to various plexus components. This is probably a good idea, but I'm not sure how easy it's going to be. There is a drastic change in the way Classworlds works and this affects component factories and thus all Ant related things: ant- based plugins and the ant-run plugin. We could attempt it and put out some candidates out very early to see if there are any problems as the testing of Ant related goodies is a little weak. I also know of a couple backward compat problems with signatures of component discoverers which will cause a problem but as soon as you switch containers and try to build you would find them. We can attempt it, and you'll know soon enough if it's feasible. I agree that it would be nice to do and would smooth the transition to 2.1 it's just a matter of getting enough feedback and adding some better Ant-related tests. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 19, 2007 6:47 PM To: Maven Developers List Subject: Reminder to vote for 2.0.8 issues Just a reminder for anyone lurking who wants issues addressed in 2.0.8 to vote for issues in JIRA. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
.isSnapshot changes version
I discovered http://jira.codehaus.org/browse/MNG-2961 while working on mdep a while back. It should be an easy fix but I'm pondering what the least intrusive fix is. Clearly calling a Boolean method shouldn't result in a change to some other variable so we should do something. Changing it to always returns xxx-SNAPSHOT as it does after calling isSnapshot has the potential to break things depending on existing behavior. The cleanest way forward is most likely to not have isSnapshot modify the version, and to create a new method that returns xxx-SNAPSHOT and leave getBaseVersion to return just the xxx-timestamp. (not sure what this method would be called...getNonResolvedBaseVersion) WDYT?
Testing maven-artifact-manager patches
Hi, I'd like to test a patch for the maven-artifact-manager. My first though was to simply build Maven 2.0.7 from source, but that fails. Is there any other possibility to test my patch? Thanks, Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Testing maven-artifact-manager patches
On 19 Jun 07, at 8:52 PM 19 Jun 07, Jochen Wiedmann wrote: Hi, I'd like to test a patch for the maven-artifact-manager. My first though was to simply build Maven 2.0.7 from source, but that fails. Is there any other possibility to test my patch? What was the failure, I just built the release and the tag should work fine. Thanks, Jochen -- Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
