FW: maven-2.0.6 throws NPE in surefire
-Original Message-
From: Jason Chaffee [mailto:[EMAIL PROTECTED]
Sent: Sunday, April 01, 2007 1:06 PM
To: Maven Users List
Subject: maven-2.0.6 throws NPE in surefire
This works fine in maven-2.0.5.
I have the following surefire configuration:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
configuration
forkModeonce/forkMode
argLine-javaagent:${project.build.directory}/test-lib/aspectjweaver.ja
r -Xmx256m/argLine
/configuration
/plugin
I get this error in 2.0.6
[INFO] [surefire:test]
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at
org.apache.maven.artifact.DefaultArtifact.getSelectedVersion(DefaultA
rtifact.java:582)
at
org.apache.maven.plugin.surefire.SurefirePlugin.constructSurefireBoot
er(SurefirePlugin.java:490)
at
org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugi
n.java:391)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:143)
at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
-
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: [ANN] Maven 2.0.6 Released
Congrats and thanks to all the people working on it! Especially MGN-1577 ... - Jörg Jason van Zyl wrote on Sunday, April 01, 2007 3:01 PM: The Apache Maven team would like to announce the availability of Maven 2.0.6. We have closed out 22 issues for this release and the upgrade from 2.0.5 should be pain free. We corrected a major flaw in the artifact resolution mechanism and we cannot find any problems but information about the change can be found here: http://maven.apache.org/plugins/maven-dependency-plugin/examples/ preparing-dependencies.html You can find the binaries here: http://maven.apache.org/download.html You can find the release notes here: http://maven.apache.org/release-notes.html You can find the roadmap here: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=truepid=10500fixfor=13010sorter/field=issuekeysorter/ order=DESC Thanks, The Apache Maven Team - 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: [m2] findbugs xml parser
any news ? one question, why the ifndbugs-maven-plugin generate its own xml instead of let findbugs do the job ? Garvin LeClaire-2 wrote: Which version of the Findbugs plugin are you using? Are you able to send me the findbugs.xml file? -- Regards, Garvin LeClaire [EMAIL PROTECTED] On 3/28/07, dvicente [EMAIL PROTECTED] wrote: Hi, for my dashboard-maven-plugin, i want to parse the xml result file of findbugs. Does anyone know if exist a parser in the API to retreive all objects structure without to parse the file as a simple xml file ? the findbugs-maven-plugin generate xml file in wrong format . it generates messages as Error analyzing public void init where init is a method and do a parseException. Does anyone know to correct that ? -- View this message in context: http://www.nabble.com/-m2--findbugs-xml-parser-tf3479394s177.html#a9710627 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-m2--findbugs-xml-parser-tf3479394s177.html#a9788933 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Maven 2.0.6 Released
On 4/1/07, Jason van Zyl [EMAIL PROTECTED] wrote: The Apache Maven team would like to announce the availability of Maven 2.0.6. We have closed out 22 issues for this release and the upgrade from 2.0.5 should be pain free. We corrected a major flaw in the artifact resolution mechanism and we cannot find any problems but information about the change can be found here: Just gave this a try and got the following error: [INFO] Building wumpus Web Application [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:164) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:75) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] findbugs xml parser
Try the 1.1-SNAPSHOT as I know it works. I cannot remember if I fixed this for 1.0.0. I did not use Findbugs xml because of the way the original Maven 2 plugin was started. It was easier to write one and I have more options for adding more wirter the way it is currently written. I was the one who wrote the original xml reporter for FindBugs when I worked on the Maven 1 plugin. -- Regards, Garvin LeClaire [EMAIL PROTECTED] On 4/2/07, dvicente [EMAIL PROTECTED] wrote: any news ? one question, why the ifndbugs-maven-plugin generate its own xml instead of let findbugs do the job ? Garvin LeClaire-2 wrote: Which version of the Findbugs plugin are you using? Are you able to send me the findbugs.xml file? -- Regards, Garvin LeClaire [EMAIL PROTECTED] On 3/28/07, dvicente [EMAIL PROTECTED] wrote: Hi, for my dashboard-maven-plugin, i want to parse the xml result file of findbugs. Does anyone know if exist a parser in the API to retreive all objects structure without to parse the file as a simple xml file ? the findbugs-maven-plugin generate xml file in wrong format . it generates messages as Error analyzing public void init where init is a method and do a parseException. Does anyone know to correct that ? -- View this message in context: http://www.nabble.com/-m2--findbugs-xml-parser-tf3479394s177.html#a9710627 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-m2--findbugs-xml-parser-tf3479394s177.html#a9788933 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] findbugs xml parser
How can i create a simple parser of the xml result file which can use the findbugs API or it's already exist ? For the dashboard plugin, i must read this xml result file to aggregate some generic indicators or try to compute statistics on it as bugs distribution by type etc ... Thanks for your help David Garvin LeClaire-2 wrote: Try the 1.1-SNAPSHOT as I know it works. I cannot remember if I fixed this for 1.0.0. I did not use Findbugs xml because of the way the original Maven 2 plugin was started. It was easier to write one and I have more options for adding more wirter the way it is currently written. I was the one who wrote the original xml reporter for FindBugs when I worked on the Maven 1 plugin. -- Regards, Garvin LeClaire [EMAIL PROTECTED] On 4/2/07, dvicente [EMAIL PROTECTED] wrote: any news ? one question, why the ifndbugs-maven-plugin generate its own xml instead of let findbugs do the job ? Garvin LeClaire-2 wrote: Which version of the Findbugs plugin are you using? Are you able to send me the findbugs.xml file? -- Regards, Garvin LeClaire [EMAIL PROTECTED] On 3/28/07, dvicente [EMAIL PROTECTED] wrote: Hi, for my dashboard-maven-plugin, i want to parse the xml result file of findbugs. Does anyone know if exist a parser in the API to retreive all objects structure without to parse the file as a simple xml file ? the findbugs-maven-plugin generate xml file in wrong format . it generates messages as Error analyzing public void init where init is a method and do a parseException. Does anyone know to correct that ? -- View this message in context: http://www.nabble.com/-m2--findbugs-xml-parser-tf3479394s177.html#a9710627 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-m2--findbugs-xml-parser-tf3479394s177.html#a9788933 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-m2--findbugs-xml-parser-tf3479394s177.html#a9789529 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] findbugs xml parser
I know the qalab plugin does this. I was thinking of creating a reporter that would put information into a database to report history. I am travelling this week and have limited time to work on anything. If you would like to follow up next week we could discuss this further. I think a Doxia extension for the database writer could benefit othr plugins also. -- Regards, Garvin LeClaire [EMAIL PROTECTED] On 4/2/07, dvicente [EMAIL PROTECTED] wrote: How can i create a simple parser of the xml result file which can use the findbugs API or it's already exist ? For the dashboard plugin, i must read this xml result file to aggregate some generic indicators or try to compute statistics on it as bugs distribution by type etc ... Thanks for your help David Garvin LeClaire-2 wrote: Try the 1.1-SNAPSHOT as I know it works. I cannot remember if I fixed this for 1.0.0. I did not use Findbugs xml because of the way the original Maven 2 plugin was started. It was easier to write one and I have more options for adding more wirter the way it is currently written. I was the one who wrote the original xml reporter for FindBugs when I worked on the Maven 1 plugin. -- Regards, Garvin LeClaire [EMAIL PROTECTED] On 4/2/07, dvicente [EMAIL PROTECTED] wrote: any news ? one question, why the ifndbugs-maven-plugin generate its own xml instead of let findbugs do the job ? Garvin LeClaire-2 wrote: Which version of the Findbugs plugin are you using? Are you able to send me the findbugs.xml file? -- Regards, Garvin LeClaire [EMAIL PROTECTED] On 3/28/07, dvicente [EMAIL PROTECTED] wrote: Hi, for my dashboard-maven-plugin, i want to parse the xml result file of findbugs. Does anyone know if exist a parser in the API to retreive all objects structure without to parse the file as a simple xml file ? the findbugs-maven-plugin generate xml file in wrong format . it generates messages as Error analyzing public void init where init is a method and do a parseException. Does anyone know to correct that ? -- View this message in context: http://www.nabble.com/-m2--findbugs-xml-parser-tf3479394s177.html#a9710627 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-m2--findbugs-xml-parser-tf3479394s177.html#a9788933 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-m2--findbugs-xml-parser-tf3479394s177.html#a9789529 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] findbugs xml parser
ok we keep in touch for the next week. i'm also working on database support for my dashboard plugin and i'm very interested by this Garvin LeClaire-2 wrote: I know the qalab plugin does this. I was thinking of creating a reporter that would put information into a database to report history. I am travelling this week and have limited time to work on anything. If you would like to follow up next week we could discuss this further. I think a Doxia extension for the database writer could benefit othr plugins also. -- Regards, Garvin LeClaire [EMAIL PROTECTED] On 4/2/07, dvicente [EMAIL PROTECTED] wrote: How can i create a simple parser of the xml result file which can use the findbugs API or it's already exist ? For the dashboard plugin, i must read this xml result file to aggregate some generic indicators or try to compute statistics on it as bugs distribution by type etc ... Thanks for your help David Garvin LeClaire-2 wrote: Try the 1.1-SNAPSHOT as I know it works. I cannot remember if I fixed this for 1.0.0. I did not use Findbugs xml because of the way the original Maven 2 plugin was started. It was easier to write one and I have more options for adding more wirter the way it is currently written. I was the one who wrote the original xml reporter for FindBugs when I worked on the Maven 1 plugin. -- Regards, Garvin LeClaire [EMAIL PROTECTED] On 4/2/07, dvicente [EMAIL PROTECTED] wrote: any news ? one question, why the ifndbugs-maven-plugin generate its own xml instead of let findbugs do the job ? Garvin LeClaire-2 wrote: Which version of the Findbugs plugin are you using? Are you able to send me the findbugs.xml file? -- Regards, Garvin LeClaire [EMAIL PROTECTED] On 3/28/07, dvicente [EMAIL PROTECTED] wrote: Hi, for my dashboard-maven-plugin, i want to parse the xml result file of findbugs. Does anyone know if exist a parser in the API to retreive all objects structure without to parse the file as a simple xml file ? the findbugs-maven-plugin generate xml file in wrong format . it generates messages as Error analyzing public void init where init is a method and do a parseException. Does anyone know to correct that ? -- View this message in context: http://www.nabble.com/-m2--findbugs-xml-parser-tf3479394s177.html#a9710627 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-m2--findbugs-xml-parser-tf3479394s177.html#a9788933 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-m2--findbugs-xml-parser-tf3479394s177.html#a9789529 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-m2--findbugs-xml-parser-tf3479394s177.html#a9789866 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Regression: (was: [ANN] Maven 2.0.6 Released)
A dependencyManagement section overwrites the scope of the currently built artifact (MNG-2919) ... :-/ Heads-up: 2.0.6 is listed in JIRA still as unreleased ... ;-) Jason van Zyl wrote on Sunday, April 01, 2007 3:01 PM: The Apache Maven team would like to announce the availability of Maven 2.0.6. We have closed out 22 issues for this release and the upgrade from 2.0.5 should be pain free. We corrected a major flaw in the artifact resolution mechanism and we cannot find any problems but information about the change can be found here: http://maven.apache.org/plugins/maven-dependency-plugin/examples/ preparing-dependencies.html You can find the binaries here: http://maven.apache.org/download.html You can find the release notes here: http://maven.apache.org/release-notes.html You can find the roadmap here: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=truepid=10500fixfor=13010sorter/field=issuekeysorter/ order=DESC Thanks, The Apache Maven Team - 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: site changes (was: svn commit: r524511)
On 1 Apr 07, at 7:35 PM 1 Apr 07, Brett Porter wrote:
I couldn't build a correct site out of the box with these changes,
due to:
- using the site plugin latest release (which is the default), I
get ${currentVersion} and other stuff showing up as text
- I tried to build the site plugin snapshot, but it doesn't compile
due to out of date doxia snapshots
I'm now adding the site plugin snapshot to the site pom and
deploying doxia snapshots.
I needed to deploy them, though CI should be taking care of this, and
another great reason to have the snapshot repositories in by default.
I should not, nor should anyone else, have to worry about this. Now
when they are released we would have to remove those repositories to
be accurate. This is a perfect example of why providing more defaults
and fewer types of repositories is good. This just shouldn't happen
with CI running and snapshot infrastructure. It's part of daily
development using and not using snapshots.
Jason.
- Brett
On 01/04/2007, at 12:20 PM, [EMAIL PROTECTED] wrote:
Author: jvanzyl
Date: Sat Mar 31 19:20:35 2007
New Revision: 524511
URL: http://svn.apache.org/viewvc?view=revrev=524511
Log:
o udating the down and release notes pages for the release
Added:
maven/site/trunk/src/site/apt/download.apt
- copied, changed from r517783, maven/site/trunk/src/site/
apt/download.apt.template
Removed:
maven/site/trunk/src/site/apt/download.apt.template
Modified:
maven/site/trunk/pom.xml
maven/site/trunk/src/site/apt/pom.apt
maven/site/trunk/src/site/apt/what-is-maven.apt
Modified: maven/site/trunk/pom.xml
URL: http://svn.apache.org/viewvc/maven/site/trunk/pom.xml?
view=diffrev=524511r1=524510r2=524511
=
=
--- maven/site/trunk/pom.xml (original)
+++ maven/site/trunk/pom.xml Sat Mar 31 19:20:35 2007
@@ -1,16 +1,24 @@
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://
maven.apache.org/maven-v4_0_0.xsd
+ !--
parent
artifactIdmaven-parent/artifactId
groupIdorg.apache.maven/groupId
version5/version
relativePath../pom/maven/pom.xml/relativePath
/parent
+ --
+ groupIdorg.apache.maven/groupId
+ version1.0/version
modelVersion4.0.0/modelVersion
artifactIdmaven-site/artifactId
packagingpom/packaging
nameMaven Site/name
+ properties
+currentVersion2.0.6/currentVersion
+ /properties
+
reporting
excludeDefaultstrue/excludeDefaults
plugins
@@ -96,30 +104,4 @@
archivehttp://mail-archives.apache.org/mod_mbox/maven-
notifications//archive
/mailingList
/mailingLists
-
- !-- TODO: temporary, remove once site plugin can filter during
transformation --
- build
-plugins
- plugin
-artifactIdmaven-antrun-plugin/artifactId
-configuration
- tasks
-copy tofile=src/site/apt/download.apt file=src/
site/apt/download.apt.template overwrite=true
- filterset
-filter token=project.version value=2.0.5 /
- /filterset
-/copy
- /tasks
-/configuration
-executions
- execution
-goals
- goalrun/goal
-/goals
-phasepre-site/phase
- /execution
-/executions
- /plugin
-/plugins
- /build
/project
Copied: maven/site/trunk/src/site/apt/download.apt (from r517783,
maven/site/trunk/src/site/apt/download.apt.template)
URL: http://svn.apache.org/viewvc/maven/site/trunk/src/site/apt/
download.apt?view=diffrev=524511p1=maven/site/trunk/src/site/apt/
download.apt.templater1=517783p2=maven/site/trunk/src/site/apt/
download.aptr2=524511
=
=
--- maven/site/trunk/src/site/apt/download.apt.template (original)
+++ maven/site/trunk/src/site/apt/download.apt Sat Mar 31 19:20:35
2007
@@ -1,5 +1,5 @@
--
-Download Maven @project.version@
+Download Maven $project.version
--
Brett Porter
Jason van Zyl
@@ -7,25 +7,25 @@
4 October 2005
--
-Download Maven @project.version@
+Download Maven ${currentVersion}
Maven is distributed in several formats for your convenience.
You will be prompted for a mirror - if the file is not found on
yours, please be patient, as it may take 24
hours to reach all mirrors.
- Maven @project.version@ is distributed under the {{{http://
maven.apache.org/license.html} Apache License, version 2.0}}.
+ Maven ${currentVersion} is distributed under the {{{http://
maven.apache.org/license.html} Apache License, version 2.0}}.
We strongly encourage our users to configure a Maven
repository mirror closer to their location, please read {{{guides/
mini/guide-mirror-settings.html} How to Use Mirrors for
Repositories}}.
Re: Doxia and Site Plugin
On 1 Apr 07, at 8:05 PM 1 Apr 07, Brett Porter wrote:
What was the final verdict on the velocity processing?
Optional.
I can see this doesn't break a lot now because it's only
properties, but I know the next thing someone is going to ask for
is to filter ${project.*} which will break a bunch of docs. I'd
still prefer the user make a conscious decision to have a document
filtered (all they need to do is whack a .vm extension on the
document). I also note the current site has an ugly exception
during generation due to this, though it does handle the outcome
correctly.
Will the site plugin be another beta release? Looking at the
current JIRA, I think the 2.0 still represents a beta-quality
release, where 2.0.1 looks more like 2.0.
Probably should be alpha, another thing that jumped the gun but
another beta for sure.
Thinking ahead a little to that 2.0, I think there are a few more
things to consider.
Firstly, I think we need a 1.0 of doxia and sitetools first
(MSITE-101).
Yes, I was planning on releasing the dependencies of the site plugin
first.
The doxia svn arrangement is still not resolved IMO. I originally
thought you were going to put them under one trunk, not separate
ones. I don't mind them separate, as long as we are agreeing to
release them on different timescales, but if we are just going to
release them with the same version tracking each other every time
then I think it's pointless. If they are going to be released
separately, then the site tools need a new JIRA project. So one way
or the other something needs to be completed here.
They will definitely be released separately. Doxia with all the site
stuff out of it can be released pretty much now.
The following issues unscheduled seem important for a 1.0 doxia /
2.0 site plugin (just by glancing at subjects):
- DOXIA-92
- DOXIA-82
- DOXIA-91
- DOXIA-95
In addition to those currently scheduled for 2.0.1, I'd also add
(again, just by glancing at subjects):
- MSITE-218
- MSITE-130
- MSITE-141
- MSITE-47 / general improvement of error handling in doxia
- MSITE-135
- MSITE-163
- MSITE-170 (can probably be fixed by a velocity update to 1.5)
- MSITE-194
- MSITE-177
- MSITE-179
Should I update these issue's fix for version?
Sure, if you haven't I can pop those in there and I will work on what
I can. But I want to get the base doxia stuff out and people are
clamoring for the site plugin so getting what's out now is more
important but the time is consumed in running in all the older
containers to make sure things still work. Which is how I found the
container/api JAR problem.
Jason.
- Brett
On 02/04/2007, at 4:48 AM, Jason van Zyl wrote:
Hi,
As promised I'll get these out for release this week. I did find
a problem with new container components (doxia, i18n) running in
the older container so I have to fix that first later today and
then I will do the Doxia release process and then the site plugin
process. I know there are a couple issues left to fix with the
site plugin and I'll get those fixed.
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]
Re: Common base directory for staging releases
On 1 Apr 07, at 7:08 PM 1 Apr 07, Brett Porter wrote:
Sounds good to me.
Does the stage-plugin delete the staging repo after successfully
copying it?
No, I'm hesitant to erase it without having another stage of
verifying the contents on the other side so I left it for now.
Jason.
- Brett
On 02/04/2007, at 3:01 AM, Jason van Zyl wrote:
Hi,
I wanted to setup a common base directory for staging releases so
that each person doesn't have to change their setting each time
they stage, or use a -D parameter. I would just like to have a
commons base directory and then use information about the project
to construct the staging repository. How about:
http://people.apache.org/staging-repositories/${project}/
Then other projects can do the same, so ours would be:
http://people.apache.org/staging-repositories/maven/
And then we can just use something like this for each staging repo:
http://people.apache.org/staging-repositories/maven/${artifactId}-$
{version}
Once we figure this out then we can change the profile accordingly
so that the staging just works with little or no configuration
mucking.
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]
Re: Common base directory for staging releases
On 1 Apr 07, at 8:43 PM 1 Apr 07, Carlos Sanchez wrote:
It'd be better somewhere under http://people.apache.org/repo/
Why? The intention is for the developers and interested parties and
not attract average users. I don't think putting it with our regular
repositories would be good.
Jason.
On 4/1/07, Brett Porter [EMAIL PROTECTED] wrote:
Sounds good to me.
Does the stage-plugin delete the staging repo after successfully
copying it?
- Brett
On 02/04/2007, at 3:01 AM, Jason van Zyl wrote:
Hi,
I wanted to setup a common base directory for staging releases so
that each person doesn't have to change their setting each time
they stage, or use a -D parameter. I would just like to have a
commons base directory and then use information about the project
to construct the staging repository. How about:
http://people.apache.org/staging-repositories/${project}/
Then other projects can do the same, so ours would be:
http://people.apache.org/staging-repositories/maven/
And then we can just use something like this for each staging repo:
http://people.apache.org/staging-repositories/maven/${artifactId}-$
{version}
Once we figure this out then we can change the profile accordingly
so that the staging just works with little or no configuration
mucking.
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]
--
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Regression: (was: [ANN] Maven 2.0.6 Released)
On 2 Apr 07, at 8:46 AM 2 Apr 07, Jörg Schaible wrote: A dependencyManagement section overwrites the scope of the currently built artifact (MNG-2919) ... :-/ Assigned to 2.0.7, but it's biting you to work around the transitive compile scope effect. I'll make an IT with your sample or you can give it a whirl. Heads-up: 2.0.6 is listed in JIRA still as unreleased ... ;-) Thanks, fixed. Jason. Jason van Zyl wrote on Sunday, April 01, 2007 3:01 PM: The Apache Maven team would like to announce the availability of Maven 2.0.6. We have closed out 22 issues for this release and the upgrade from 2.0.5 should be pain free. We corrected a major flaw in the artifact resolution mechanism and we cannot find any problems but information about the change can be found here: http://maven.apache.org/plugins/maven-dependency-plugin/examples/ preparing-dependencies.html You can find the binaries here: http://maven.apache.org/download.html You can find the release notes here: http://maven.apache.org/release-notes.html You can find the roadmap here: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=truepid=10500fixfor=13010sorter/field=issuekeysorter/ order=DESC Thanks, The Apache Maven Team - 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: site changes (was: svn commit: r524511)
On 02/04/2007, at 11:04 PM, Jason van Zyl wrote:
On 1 Apr 07, at 7:35 PM 1 Apr 07, Brett Porter wrote:
I couldn't build a correct site out of the box with these changes,
due to:
- using the site plugin latest release (which is the default), I
get ${currentVersion} and other stuff showing up as text
- I tried to build the site plugin snapshot, but it doesn't
compile due to out of date doxia snapshots
I'm now adding the site plugin snapshot to the site pom and
deploying doxia snapshots.
I needed to deploy them, though CI should be taking care of this,
and another great reason to have the snapshot repositories in by
default. I should not, nor should anyone else, have to worry about
this.
I agree. I'll fire up the one on the zone again as soon as
continuum-1.1-alpha-1 is out.
Now when they are released we would have to remove those
repositories to be accurate.
Having a default repository won't help with this. You just won't be
able to do that for plugins until we fix the versioning aspect, and
after that declaring snapshot repos is harmless as they are only used
when requested (like the non-plugin ones in every asf release via the
parent pom)
This is a perfect example of why providing more defaults and fewer
types of repositories is good. This just shouldn't happen with CI
running and snapshot infrastructure. It's part of daily development
using and not using snapshots.
I agree, I was just letting you know what I'd done and why.
- Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Creating a schedule for releases
Hi, Taking the lead from the Mylar development team, whom I have a great deal of respect for, I would like to create a shared Google calendar where we can put some releases on schedules. I know at least for Maven itself, Doxia, Wagon and some plugins I'm working on I have a clear idea of when they will be released. But what the Mylar team does is work under the general Europa guidelines and they try and do releases every 6 weeks. So I'm not sure how the everything will be ultimately schedule but I would like to make a start at trying to provide some transparency as the Mylar team does. So the though was that we would have a calendar on Google where everyone on the PMC has access to the schedule (as it's a PMC person who has to do a release) and I'll start the by putting in the Maven releases. I planned 4 weeks between the last releases and it ended up being 6 so I'll shoot for that again, but even if we're off a bit it keeps the users informed and they will have a single place to look for planned releases dates. I would like to set this up asap. +1 Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Creating a schedule for releases
+1, I had a draft mail saying roughly the same thing. We will probably still need to be occasionally flexible depending on availability of people, too, but as we start whipping out non-alpha releases of some of the underlying stuff and increasing the general amount of testing, it'll be much easier to make a call to cut some things and release anyway since it will be stable already, right? :) - Brett On 02/04/2007, at 11:37 PM, Jason van Zyl wrote: Hi, Taking the lead from the Mylar development team, whom I have a great deal of respect for, I would like to create a shared Google calendar where we can put some releases on schedules. I know at least for Maven itself, Doxia, Wagon and some plugins I'm working on I have a clear idea of when they will be released. But what the Mylar team does is work under the general Europa guidelines and they try and do releases every 6 weeks. So I'm not sure how the everything will be ultimately schedule but I would like to make a start at trying to provide some transparency as the Mylar team does. So the though was that we would have a calendar on Google where everyone on the PMC has access to the schedule (as it's a PMC person who has to do a release) and I'll start the by putting in the Maven releases. I planned 4 weeks between the last releases and it ended up being 6 so I'll shoot for that again, but even if we're off a bit it keeps the users informed and they will have a single place to look for planned releases dates. I would like to set this up asap. +1 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]
RE: Creating a schedule for releases
+1. More info helps the users to plan and gives the devs something to work towards. I'd like to see some tentative plans for 2.1 also. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 9:38 AM To: Maven Developers List Subject: Creating a schedule for releases Hi, Taking the lead from the Mylar development team, whom I have a great deal of respect for, I would like to create a shared Google calendar where we can put some releases on schedules. I know at least for Maven itself, Doxia, Wagon and some plugins I'm working on I have a clear idea of when they will be released. But what the Mylar team does is work under the general Europa guidelines and they try and do releases every 6 weeks. So I'm not sure how the everything will be ultimately schedule but I would like to make a start at trying to provide some transparency as the Mylar team does. So the though was that we would have a calendar on Google where everyone on the PMC has access to the schedule (as it's a PMC person who has to do a release) and I'll start the by putting in the Maven releases. I planned 4 weeks between the last releases and it ended up being 6 so I'll shoot for that again, but even if we're off a bit it keeps the users informed and they will have a single place to look for planned releases dates. I would like to set this up asap. +1 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]
Re: Creating a schedule for releases
On 2 Apr 07, at 9:44 AM 2 Apr 07, Brett Porter wrote: +1, I had a draft mail saying roughly the same thing. We will probably still need to be occasionally flexible depending on availability of people, too, but as we start whipping out non- alpha releases of some of the underlying stuff and increasing the general amount of testing, it'll be much easier to make a call to cut some things and release anyway since it will be stable already, right? :) Mylar, and the rest of Europa projects, schedule releases but if they don't have anything to release they don't. But the projects that actually make their release dates are the ones people come to trust. Mylar is all volunteers (not even a company paying some of the bills until very recently) and they have managed to stick to this schedule. There is no reason why we shouldn't be able to do this. Jason. - Brett On 02/04/2007, at 11:37 PM, Jason van Zyl wrote: Hi, Taking the lead from the Mylar development team, whom I have a great deal of respect for, I would like to create a shared Google calendar where we can put some releases on schedules. I know at least for Maven itself, Doxia, Wagon and some plugins I'm working on I have a clear idea of when they will be released. But what the Mylar team does is work under the general Europa guidelines and they try and do releases every 6 weeks. So I'm not sure how the everything will be ultimately schedule but I would like to make a start at trying to provide some transparency as the Mylar team does. So the though was that we would have a calendar on Google where everyone on the PMC has access to the schedule (as it's a PMC person who has to do a release) and I'll start the by putting in the Maven releases. I planned 4 weeks between the last releases and it ended up being 6 so I'll shoot for that again, but even if we're off a bit it keeps the users informed and they will have a single place to look for planned releases dates. I would like to set this up asap. +1 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]
Re: Creating a schedule for releases
On 2 Apr 07, at 9:44 AM 2 Apr 07, Brian E. Fox wrote: +1. More info helps the users to plan and gives the devs something to work towards. I'd like to see some tentative plans for 2.1 also. 2.1-alpha-1 will go on the schedule, the issues are registered for it and John and I would like to cut the alpha in the coming week so we'll get wiki fleshed out with details of the issues listed in JIRA. Jason. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 9:38 AM To: Maven Developers List Subject: Creating a schedule for releases Hi, Taking the lead from the Mylar development team, whom I have a great deal of respect for, I would like to create a shared Google calendar where we can put some releases on schedules. I know at least for Maven itself, Doxia, Wagon and some plugins I'm working on I have a clear idea of when they will be released. But what the Mylar team does is work under the general Europa guidelines and they try and do releases every 6 weeks. So I'm not sure how the everything will be ultimately schedule but I would like to make a start at trying to provide some transparency as the Mylar team does. So the though was that we would have a calendar on Google where everyone on the PMC has access to the schedule (as it's a PMC person who has to do a release) and I'll start the by putting in the Maven releases. I planned 4 weeks between the last releases and it ended up being 6 so I'll shoot for that again, but even if we're off a bit it keeps the users informed and they will have a single place to look for planned releases dates. I would like to set this up asap. +1 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]
Re: Creating a schedule for releases
On 02/04/2007, at 11:55 PM, Jason van Zyl wrote: There is no reason why we shouldn't be able to do this. Totally agree. And drawing this information into a known, persistent, and up-to-date location can only help get more people involved. The most successful releases will come when 3, 4 or more people are popping in fixes in those 4-6 weeks. Just to highlight what I was getting at in the previous mail and the site mail earlier (though it probably goes without saying) - this will only be successful if everyone is also diligent about things like maintaining JIRA, CI (when it gets running again), testing, and some level of documentation throughout the whole release cycle. There's not much point cutting a release on time if it drops in stability or %complete in terms of tests or docs. That's all I was getting at. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Regression: (was: [ANN] Maven 2.0.6 Released)
Well, I have a got a weird case in MNG-2920. Can't figure out where it is coming from, but a simple test project is working fine with 2.0.5 while I'm getting a exception with 2.0.6. The forking command line for surefire booter seems to have changed between the 2 versions and the newer command line isn't working here (Windows XP). Has anyone experienced the same trouble? I hope it comes from using all of the most recent SNAPSHOT releases with 2.0.6, but I don't really see where this would come from. Help would be appreciated. Thanks folks! Denis. -Message d'origine- De : Jason van Zyl [mailto:[EMAIL PROTECTED] Envoyé : lundi 2 avril 2007 15:22 À : Maven Developers List Objet : Re: Regression: (was: [ANN] Maven 2.0.6 Released) On 2 Apr 07, at 8:46 AM 2 Apr 07, Jörg Schaible wrote: A dependencyManagement section overwrites the scope of the currently built artifact (MNG-2919) ... :-/ Assigned to 2.0.7, but it's biting you to work around the transitive compile scope effect. I'll make an IT with your sample or you can give it a whirl. Heads-up: 2.0.6 is listed in JIRA still as unreleased ... ;-) Thanks, fixed. Jason. Jason van Zyl wrote on Sunday, April 01, 2007 3:01 PM: The Apache Maven team would like to announce the availability of Maven 2.0.6. We have closed out 22 issues for this release and the upgrade from 2.0.5 should be pain free. We corrected a major flaw in the artifact resolution mechanism and we cannot find any problems but information about the change can be found here: http://maven.apache.org/plugins/maven-dependency-plugin/examples/ preparing-dependencies.html You can find the binaries here: http://maven.apache.org/download.html You can find the release notes here: http://maven.apache.org/release-notes.html You can find the roadmap here: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=truepid=10500fixfor=13010sorter/field=issuekeysorter/ order=DESC Thanks, The Apache Maven Team - 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: Creating a schedule for releases
+1 Emmanuel Jason van Zyl a écrit : Hi, Taking the lead from the Mylar development team, whom I have a great deal of respect for, I would like to create a shared Google calendar where we can put some releases on schedules. I know at least for Maven itself, Doxia, Wagon and some plugins I'm working on I have a clear idea of when they will be released. But what the Mylar team does is work under the general Europa guidelines and they try and do releases every 6 weeks. So I'm not sure how the everything will be ultimately schedule but I would like to make a start at trying to provide some transparency as the Mylar team does. So the though was that we would have a calendar on Google where everyone on the PMC has access to the schedule (as it's a PMC person who has to do a release) and I'll start the by putting in the Maven releases. I planned 4 weeks between the last releases and it ended up being 6 so I'll shoot for that again, but even if we're off a bit it keeps the users informed and they will have a single place to look for planned releases dates. I would like to set this up asap. +1 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]
RE: Regression: (was: [ANN] Maven 2.0.6 Released)
Another regression problem: XDoclet plugin is completly broken. The plugin itself was problematic anyway, since it depends on the o.a.m.p:maven-anrun-plugin:1.0 (as jar dependency!!!) that prevented the version 1.1 from antrun-plugin to work properly already with earlier Maven versions (MOJO-641). IIRC for M206 was something done with the classpaths of plugins in general ... and now the xdoclet-maven-plugin chokes directly (MOJO-618 - I don't know why ther OP did close this issue though, he clearly states himself that it's broken for M206). However, I got it running by creating my private version of the plugin, simply by removing the dep to the antrun plugin and copying that code (into a new package). That version runs fine. So the problem seems basically a result from this unfortunat dep to a different plugin instead of a shared component ... - Jörg Jörg Schaible wrote on Monday, April 02, 2007 2:46 PM: A dependencyManagement section overwrites the scope of the currently built artifact (MNG-2919) ... :-/ Heads-up: 2.0.6 is listed in JIRA still as unreleased ... ;-) Jason van Zyl wrote on Sunday, April 01, 2007 3:01 PM: The Apache Maven team would like to announce the availability of Maven 2.0.6. We have closed out 22 issues for this release and the upgrade from 2.0.5 should be pain free. We corrected a major flaw in the artifact resolution mechanism and we cannot find any problems but information about the change can be found here: http://maven.apache.org/plugins/maven-dependency-plugin/examples/ preparing-dependencies.html You can find the binaries here: http://maven.apache.org/download.html You can find the release notes here: http://maven.apache.org/release-notes.html You can find the roadmap here: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=truepid=10500fixfor=13010sorter/field=issuekeysorter/ order=DESC Thanks, The Apache Maven Team - 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: Creating a schedule for releases
After trying to schedule some stuff I noticed without different calendars the colour of everything is the same so I created separate calendars for the sub-projects and another for plugins so that folks can visually distinguish the releases. Jason. On 2 Apr 07, at 10:32 AM 2 Apr 07, Emmanuel Venisse wrote: +1 Emmanuel Jason van Zyl a écrit : Hi, Taking the lead from the Mylar development team, whom I have a great deal of respect for, I would like to create a shared Google calendar where we can put some releases on schedules. I know at least for Maven itself, Doxia, Wagon and some plugins I'm working on I have a clear idea of when they will be released. But what the Mylar team does is work under the general Europa guidelines and they try and do releases every 6 weeks. So I'm not sure how the everything will be ultimately schedule but I would like to make a start at trying to provide some transparency as the Mylar team does. So the though was that we would have a calendar on Google where everyone on the PMC has access to the schedule (as it's a PMC person who has to do a release) and I'll start the by putting in the Maven releases. I planned 4 weeks between the last releases and it ended up being 6 so I'll shoot for that again, but even if we're off a bit it keeps the users informed and they will have a single place to look for planned releases dates. I would like to set this up asap. +1 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]
Re: Creating a schedule for releases
On 2 Apr 07, at 12:00 PM 2 Apr 07, Joakim Erdfelt wrote: Looks like we'll need an new maven-ical-report for the site generation. To inject the schedule into the site, with links to the live-schedule. I think just pointing to the calendar will suffice. I think a lot of people will just end up subscribing to the feed. Jason. - Joakim Jason van Zyl wrote: On 2 Apr 07, at 9:44 AM 2 Apr 07, Brian E. Fox wrote: +1. More info helps the users to plan and gives the devs something to work towards. I'd like to see some tentative plans for 2.1 also. 2.1-alpha-1 will go on the schedule, the issues are registered for it and John and I would like to cut the alpha in the coming week so we'll get wiki fleshed out with details of the issues listed in JIRA. Jason. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 9:38 AM To: Maven Developers List Subject: Creating a schedule for releases Hi, Taking the lead from the Mylar development team, whom I have a great deal of respect for, I would like to create a shared Google calendar where we can put some releases on schedules. I know at least for Maven itself, Doxia, Wagon and some plugins I'm working on I have a clear idea of when they will be released. But what the Mylar team does is work under the general Europa guidelines and they try and do releases every 6 weeks. So I'm not sure how the everything will be ultimately schedule but I would like to make a start at trying to provide some transparency as the Mylar team does. So the though was that we would have a calendar on Google where everyone on the PMC has access to the schedule (as it's a PMC person who has to do a release) and I'll start the by putting in the Maven releases. I planned 4 weeks between the last releases and it ended up being 6 so I'll shoot for that again, but even if we're off a bit it keeps the users informed and they will have a single place to look for planned releases dates. I would like to set this up asap. +1 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Regression: (was: [ANN] Maven 2.0.6 Released)
Jörg Schaible wrote: Another regression problem: XDoclet plugin is completly broken. The plugin itself was problematic anyway, since it depends on the o.a.m.p:maven-anrun-plugin:1.0 (as jar dependency!!!) that prevented the version 1.1 from antrun-plugin to work properly already with earlier Maven versions (MOJO-641). IIRC for M206 was something done with the classpaths of plugins in general ... and now the xdoclet-maven-plugin chokes directly (MOJO-618 - I don't know why ther OP did close this issue though, he clearly states himself that it's broken for M206). xdoclet-maven-plugin is working fine for me with Maven 2.0.6. The error in MOJO-618 looks like a dependency misresolution - it's using ant-1.5.2 with ant-launcher-1.6.5. I've seen this happen with Maven 2.0.5, with POMs that add plugin dependencies (e.g., to add additional ant tasks). Max. signature.asc Description: OpenPGP digital signature
Re: Creating a schedule for releases
Looks like we'll need an new maven-ical-report for the site generation. To inject the schedule into the site, with links to the live-schedule. - Joakim Jason van Zyl wrote: On 2 Apr 07, at 9:44 AM 2 Apr 07, Brian E. Fox wrote: +1. More info helps the users to plan and gives the devs something to work towards. I'd like to see some tentative plans for 2.1 also. 2.1-alpha-1 will go on the schedule, the issues are registered for it and John and I would like to cut the alpha in the coming week so we'll get wiki fleshed out with details of the issues listed in JIRA. Jason. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 9:38 AM To: Maven Developers List Subject: Creating a schedule for releases Hi, Taking the lead from the Mylar development team, whom I have a great deal of respect for, I would like to create a shared Google calendar where we can put some releases on schedules. I know at least for Maven itself, Doxia, Wagon and some plugins I'm working on I have a clear idea of when they will be released. But what the Mylar team does is work under the general Europa guidelines and they try and do releases every 6 weeks. So I'm not sure how the everything will be ultimately schedule but I would like to make a start at trying to provide some transparency as the Mylar team does. So the though was that we would have a calendar on Google where everyone on the PMC has access to the schedule (as it's a PMC person who has to do a release) and I'll start the by putting in the Maven releases. I planned 4 weeks between the last releases and it ended up being 6 so I'll shoot for that again, but even if we're off a bit it keeps the users informed and they will have a single place to look for planned releases dates. I would like to set this up asap. +1 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: Common base directory for staging releases
that would be the same case as snapshots, and they are there too
On 4/2/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 1 Apr 07, at 8:43 PM 1 Apr 07, Carlos Sanchez wrote:
It'd be better somewhere under http://people.apache.org/repo/
Why? The intention is for the developers and interested parties and
not attract average users. I don't think putting it with our regular
repositories would be good.
Jason.
On 4/1/07, Brett Porter [EMAIL PROTECTED] wrote:
Sounds good to me.
Does the stage-plugin delete the staging repo after successfully
copying it?
- Brett
On 02/04/2007, at 3:01 AM, Jason van Zyl wrote:
Hi,
I wanted to setup a common base directory for staging releases so
that each person doesn't have to change their setting each time
they stage, or use a -D parameter. I would just like to have a
commons base directory and then use information about the project
to construct the staging repository. How about:
http://people.apache.org/staging-repositories/${project}/
Then other projects can do the same, so ours would be:
http://people.apache.org/staging-repositories/maven/
And then we can just use something like this for each staging repo:
http://people.apache.org/staging-repositories/maven/${artifactId}-$
{version}
Once we figure this out then we can change the profile accordingly
so that the staging just works with little or no configuration
mucking.
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]
--
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]
-
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]
Re: Regression: (was: [ANN] Maven 2.0.6 Released)
that's a problem with the surefire version you are using, i updated the jira On 4/2/07, Cabasson Denis [EMAIL PROTECTED] wrote: Well, I have a got a weird case in MNG-2920. Can't figure out where it is coming from, but a simple test project is working fine with 2.0.5 while I'm getting a exception with 2.0.6. The forking command line for surefire booter seems to have changed between the 2 versions and the newer command line isn't working here (Windows XP). Has anyone experienced the same trouble? I hope it comes from using all of the most recent SNAPSHOT releases with 2.0.6, but I don't really see where this would come from. Help would be appreciated. Thanks folks! Denis. -Message d'origine- De : Jason van Zyl [mailto:[EMAIL PROTECTED] Envoyé : lundi 2 avril 2007 15:22 À : Maven Developers List Objet : Re: Regression: (was: [ANN] Maven 2.0.6 Released) On 2 Apr 07, at 8:46 AM 2 Apr 07, Jörg Schaible wrote: A dependencyManagement section overwrites the scope of the currently built artifact (MNG-2919) ... :-/ Assigned to 2.0.7, but it's biting you to work around the transitive compile scope effect. I'll make an IT with your sample or you can give it a whirl. Heads-up: 2.0.6 is listed in JIRA still as unreleased ... ;-) Thanks, fixed. Jason. Jason van Zyl wrote on Sunday, April 01, 2007 3:01 PM: The Apache Maven team would like to announce the availability of Maven 2.0.6. We have closed out 22 issues for this release and the upgrade from 2.0.5 should be pain free. We corrected a major flaw in the artifact resolution mechanism and we cannot find any problems but information about the change can be found here: http://maven.apache.org/plugins/maven-dependency-plugin/examples/ preparing-dependencies.html You can find the binaries here: http://maven.apache.org/download.html You can find the release notes here: http://maven.apache.org/release-notes.html You can find the roadmap here: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=truepid=10500fixfor=13010sorter/field=issuekeysorter/ order=DESC Thanks, The Apache Maven Team - 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] -- 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]
Re: [ANN] Maven 2.0.6 Released
On 4/1/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 1 Apr 07, at 9:04 AM 1 Apr 07, Brett Porter wrote: Should this include the full change log like previous releases? I added a pointer to the roadmap, I don't think we need to entirely replicate the list produced by JIRA. But users should be able to navigate from the release notes to the full list of fixes. IMO, the list needs to be in svn (and I added it). JIRA issues can be reopened and edited, and may disappear from the generated list. And JIRA itself isn't guaranteed to live forever-- plain text in svn has a much longer lifespan. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Common base directory for staging releases
On 2 Apr 07, at 12:43 PM 2 Apr 07, Carlos Sanchez wrote:
that would be the same case as snapshots, and they are there too
No, they aren't. People are not expected to build against the staging
repositories. They do that with the snapshot repository, snapshots
are still generally consumable by average users.
Jason.
On 4/2/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 1 Apr 07, at 8:43 PM 1 Apr 07, Carlos Sanchez wrote:
It'd be better somewhere under http://people.apache.org/repo/
Why? The intention is for the developers and interested parties and
not attract average users. I don't think putting it with our regular
repositories would be good.
Jason.
On 4/1/07, Brett Porter [EMAIL PROTECTED] wrote:
Sounds good to me.
Does the stage-plugin delete the staging repo after successfully
copying it?
- Brett
On 02/04/2007, at 3:01 AM, Jason van Zyl wrote:
Hi,
I wanted to setup a common base directory for staging
releases so
that each person doesn't have to change their setting each time
they stage, or use a -D parameter. I would just like to have a
commons base directory and then use information about the
project
to construct the staging repository. How about:
http://people.apache.org/staging-repositories/${project}/
Then other projects can do the same, so ours would be:
http://people.apache.org/staging-repositories/maven/
And then we can just use something like this for each staging
repo:
http://people.apache.org/staging-repositories/maven/$
{artifactId}-$
{version}
Once we figure this out then we can change the profile
accordingly
so that the staging just works with little or no configuration
mucking.
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]
--
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]
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Maven 2.0.6 Released
On 2 Apr 07, at 1:01 PM 2 Apr 07, Wendy Smoak wrote: On 4/1/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 1 Apr 07, at 9:04 AM 1 Apr 07, Brett Porter wrote: Should this include the full change log like previous releases? I added a pointer to the roadmap, I don't think we need to entirely replicate the list produced by JIRA. But users should be able to navigate from the release notes to the full list of fixes. IMO, the list needs to be in svn (and I added it). JIRA issues can be reopened and edited, and may disappear from the generated list. So then the pointers to those issues are just as meaningless. If you don't retain some integrity in the issue management system then what's the point really? Just copying text around doesn't have much value. I don't think it happens that often that an issue is removed. If any text is going to be added it should be the changes text with full descriptions. I don't see much use in copying text out of JIRA. And JIRA itself isn't guaranteed to live forever-- plain text in svn has a much longer lifespan. So when they reference bad information in the site you're going to go back and edit it to make it correct again? Jason. -- Wendy - 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: [ANN] Maven 2.0.6 Released
On 4/2/07, Jason van Zyl [EMAIL PROTECTED] wrote: So when they reference bad information in the site you're going to go back and edit it to make it correct again? Huh? I want the release notes to be static. Not to change if something changes in JIRA, and not to disappear (404) if JIRA gets upgraded or goes away some day. I'll put the link back in, though... no reason we can't have both. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Maven 2.0.6 Released
Jason van Zyl wrote: On 2 Apr 07, at 1:01 PM 2 Apr 07, Wendy Smoak wrote: On 4/1/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 1 Apr 07, at 9:04 AM 1 Apr 07, Brett Porter wrote: Should this include the full change log like previous releases? I added a pointer to the roadmap, I don't think we need to entirely replicate the list produced by JIRA. But users should be able to navigate from the release notes to the full list of fixes. IMO, the list needs to be in svn (and I added it). JIRA issues can be reopened and edited, and may disappear from the generated list. So then the pointers to those issues are just as meaningless. If you don't retain some integrity in the issue management system then what's the point really? Just copying text around doesn't have much value. I don't think it happens that often that an issue is removed. If any text is going to be added it should be the changes text with full descriptions. I don't see much use in copying text out of JIRA. +1 for static release notes content. I think that if a jira issue gets re-opened, then the linked jira report will then be out of date. Also, if a reorganization of the jira occurs, the release information is lost too. Also, if jira isn't available, the release notes are also not available. I'm in favor of static release notes. - Joakim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FW: maven-2.0.6 throws NPE in surefire
Carlos, this seems to be the same issue with surefire forking and you
previously mentioned that it was because the wrong version of surefire
was being used. Which version should be used with 2.0.6?
-Original Message-
From: Jason Chaffee [mailto:[EMAIL PROTECTED]
Sent: Sunday, April 01, 2007 3:56 PM
To: Maven Users List
Subject: RE: maven-2.0.6 throws NPE in surefire
It is version 2.3 and the same version was used in both maven-2.0.5 and
maven-2.0.6. However, only maven-2.0.6 produces the NPE. Seems like
there was bug introduced in maven-2.0.6.
Also, I had a clean repo for each version of maven to make sure the
correct versions of the dependencies were being used by each version of
maven.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
Sanchez
Sent: Sunday, April 01, 2007 2:54 PM
To: Maven Users List
Subject: Re: maven-2.0.6 throws NPE in surefire
what version of maven-surefire-plugin?
try setting the version explicitly
On 4/1/07, Jason Chaffee [EMAIL PROTECTED] wrote:
This works fine in maven-2.0.5.
I have the following surefire configuration:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
configuration
forkModeonce/forkMode
argLine-javaagent:${project.build.directory}/test-lib/aspectjweaver.ja
r -Xmx256m/argLine
/configuration
/plugin
I get this error in 2.0.6
[INFO] [surefire:test]
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at
org.apache.maven.artifact.DefaultArtifact.getSelectedVersion(DefaultA
rtifact.java:582)
at
org.apache.maven.plugin.surefire.SurefirePlugin.constructSurefireBoot
er(SurefirePlugin.java:490)
at
org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugi
n.java:391)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:143)
at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
-
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]
-
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: [ANN] Maven 2.0.6 Released
Joakim Erdfelt a écrit : Jason van Zyl wrote: On 2 Apr 07, at 1:01 PM 2 Apr 07, Wendy Smoak wrote: On 4/1/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 1 Apr 07, at 9:04 AM 1 Apr 07, Brett Porter wrote: Should this include the full change log like previous releases? I added a pointer to the roadmap, I don't think we need to entirely replicate the list produced by JIRA. But users should be able to navigate from the release notes to the full list of fixes. IMO, the list needs to be in svn (and I added it). JIRA issues can be reopened and edited, and may disappear from the generated list. So then the pointers to those issues are just as meaningless. If you don't retain some integrity in the issue management system then what's the point really? Just copying text around doesn't have much value. I don't think it happens that often that an issue is removed. If any text is going to be added it should be the changes text with full descriptions. I don't see much use in copying text out of JIRA. +1 for static release notes content. I think that if a jira issue gets re-opened, then the linked jira report will then be out of date. Also, if a reorganization of the jira occurs, the release information is lost too. Also, if jira isn't available, the release notes are also not available. I'm in favor of static release notes. Me too. And we can generate it easily with swizzle. Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Maven 2.0.6 Released
On 2 Apr 07, at 2:03 PM 2 Apr 07, Emmanuel Venisse wrote: Joakim Erdfelt a écrit : Jason van Zyl wrote: On 2 Apr 07, at 1:01 PM 2 Apr 07, Wendy Smoak wrote: On 4/1/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 1 Apr 07, at 9:04 AM 1 Apr 07, Brett Porter wrote: Should this include the full change log like previous releases? I added a pointer to the roadmap, I don't think we need to entirely replicate the list produced by JIRA. But users should be able to navigate from the release notes to the full list of fixes. IMO, the list needs to be in svn (and I added it). JIRA issues can be reopened and edited, and may disappear from the generated list. So then the pointers to those issues are just as meaningless. If you don't retain some integrity in the issue management system then what's the point really? Just copying text around doesn't have much value. I don't think it happens that often that an issue is removed. If any text is going to be added it should be the changes text with full descriptions. I don't see much use in copying text out of JIRA. +1 for static release notes content. I think that if a jira issue gets re-opened, then the linked jira report will then be out of date. Also, if a reorganization of the jira occurs, the release information is lost too. Also, if jira isn't available, the release notes are also not available. I'm in favor of static release notes. Me too. And we can generate it easily with swizzle. Provide no human has to go scrape it out that would be fine. It just seems dumb to copy it from one system to another. One end or the the other is going to be inaccurate when people shuffle around issues. From the static document you will be pointing at information which is no longer there, or rearranged. In the a link to the dynamic view some issues would no longer be a part of the roadmap. How many issue have ever been reopened from a roadmap of a released? Five? And really, if an issues was reopened, moved to another fix version and actually corrected which view is more correct? I would say the dynamic one at any point in time. Jason. Emmanuel - 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 Ant Tasks 2.0.6
+1 On 4/1/07, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, The staging repository is here: http://people.apache.org/~jvanzyl/staging-repository/maven-ant- tasks-2.0.6/ The uber jar that people will want to try is here: http://people.apache.org/~jvanzyl/staging-repository/maven-ant- tasks-2.0.6/org/apache/maven/maven-ant-tasks/2.0.6/ Road map: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=truepid=11533fixfor=13351sorter/field=issuekeysorter/ order=DESC Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Eric Redmond http://codehaus.org/~eredmond
Re: [VOTE] Release Maven Ant Tasks 2.0.6
+1 Andy On 4/1/07, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, The staging repository is here: http://people.apache.org/~jvanzyl/staging-repository/maven-ant- tasks-2.0.6/ The uber jar that people will want to try is here: http://people.apache.org/~jvanzyl/staging-repository/maven-ant- tasks-2.0.6/org/apache/maven/maven-ant-tasks/2.0.6/ Road map: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=truepid=11533fixfor=13351sorter/field=issuekeysorter/ order=DESC 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]
Re: [VOTE] Release Maven Ant Tasks 2.0.6
+1 --jason On Apr 1, 2007, at 10:36 AM, Jason van Zyl wrote: Hi, The staging repository is here: http://people.apache.org/~jvanzyl/staging-repository/maven-ant- tasks-2.0.6/ The uber jar that people will want to try is here: http://people.apache.org/~jvanzyl/staging-repository/maven-ant- tasks-2.0.6/org/apache/maven/maven-ant-tasks/2.0.6/ Road map: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=truepid=11533fixfor=13351sorter/field=issuekeysorter/ order=DESC 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]
RE: Creating a schedule for releases
I know the calendar is already out there so this might be late info (I didn't think of it before), but I thought I'd point out that Jira has the ability to set release dates and there is a calendar portlet you can add to show them. It's probably less functionality than the google one, but it could also incorporate the releases of all plugins, including ones where the lead isn't on the PMC (if there are any). -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 12:08 PM To: Maven Developers List Subject: Re: Creating a schedule for releases On 2 Apr 07, at 12:00 PM 2 Apr 07, Joakim Erdfelt wrote: Looks like we'll need an new maven-ical-report for the site generation. To inject the schedule into the site, with links to the live-schedule. I think just pointing to the calendar will suffice. I think a lot of people will just end up subscribing to the feed. Jason. - Joakim Jason van Zyl wrote: On 2 Apr 07, at 9:44 AM 2 Apr 07, Brian E. Fox wrote: +1. More info helps the users to plan and gives the devs something to work towards. I'd like to see some tentative plans for 2.1 also. 2.1-alpha-1 will go on the schedule, the issues are registered for it and John and I would like to cut the alpha in the coming week so we'll get wiki fleshed out with details of the issues listed in JIRA. Jason. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 9:38 AM To: Maven Developers List Subject: Creating a schedule for releases Hi, Taking the lead from the Mylar development team, whom I have a great deal of respect for, I would like to create a shared Google calendar where we can put some releases on schedules. I know at least for Maven itself, Doxia, Wagon and some plugins I'm working on I have a clear idea of when they will be released. But what the Mylar team does is work under the general Europa guidelines and they try and do releases every 6 weeks. So I'm not sure how the everything will be ultimately schedule but I would like to make a start at trying to provide some transparency as the Mylar team does. So the though was that we would have a calendar on Google where everyone on the PMC has access to the schedule (as it's a PMC person who has to do a release) and I'll start the by putting in the Maven releases. I planned 4 weeks between the last releases and it ended up being 6 so I'll shoot for that again, but even if we're off a bit it keeps the users informed and they will have a single place to look for planned releases dates. I would like to set this up asap. +1 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] - 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]
maven-install-plugin :: Cannot override read-only parameter: artifactId ?
I all of a sudden started to see this today: snip [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error configuring: org.apache.maven.plugins:maven-install- plugin. Reason: ERROR: Cannot override read-only parameter: artifactId in goal: install:install-file /snip From what I can tell this is using maven-install-plugin 2.1. Anyone know whats going on? I get the same problem with Maven 2.0.5 and 2.0.6 :-( --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven Ant Tasks 2.0.6
+1 On 4/2/07, Jason Dillon [EMAIL PROTECTED] wrote: +1 --jason On Apr 1, 2007, at 10:36 AM, Jason van Zyl wrote: Hi, The staging repository is here: http://people.apache.org/~jvanzyl/staging-repository/maven-ant- tasks-2.0.6/ The uber jar that people will want to try is here: http://people.apache.org/~jvanzyl/staging-repository/maven-ant- tasks-2.0.6/org/apache/maven/maven-ant-tasks/2.0.6/ Road map: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=truepid=11533fixfor=13351sorter/field=issuekeysorter/ order=DESC 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]
2.0.6 download links broken
I published the site to update the release notes, and someone on irc pointed out that the download links are broken: http://maven.apache.org/download.html Any ideas? I just did 'mvn site' and 'mvn site:deploy'. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.0.6 download links broken
On 2 Apr 07, at 5:57 PM 2 Apr 07, Wendy Smoak wrote: I published the site to update the release notes, and someone on irc pointed out that the download links are broken: http://maven.apache.org/download.html Any ideas? I just did 'mvn site' and 'mvn site:deploy'. Requires trunk of the site plugin. jason. -- Wendy - 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: maven-install-plugin :: Cannot override read-only parameter: artifactId ?
I thought that had always been the case and was a known issue in the install plugin. On 03/04/2007, at 6:32 AM, Jason Dillon wrote: I all of a sudden started to see this today: snip [INFO] -- -- [ERROR] BUILD ERROR [INFO] -- -- [INFO] Error configuring: org.apache.maven.plugins:maven-install- plugin. Reason: ERROR: Cannot override read-only parameter: artifactId in goal: install:install-file /snip From what I can tell this is using maven-install-plugin 2.1. Anyone know whats going on? I get the same problem with Maven 2.0.5 and 2.0.6 :-( --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]
Re: maven-install-plugin :: Cannot override read-only parameter: artifactId ?
It was working for me for a while... then it stopped. I don't know why at all. This is install:install-file, not install:install, so you are expected to configure the artifactId. Its not marked as read- only. But I've not idea why it just started complaining to me about it... :-( --jason On Apr 2, 2007, at 4:44 PM, Brett Porter wrote: I thought that had always been the case and was a known issue in the install plugin. On 03/04/2007, at 6:32 AM, Jason Dillon wrote: I all of a sudden started to see this today: snip [INFO] - --- [ERROR] BUILD ERROR [INFO] - --- [INFO] Error configuring: org.apache.maven.plugins:maven-install- plugin. Reason: ERROR: Cannot override read-only parameter: artifactId in goal: install:install-file /snip From what I can tell this is using maven-install-plugin 2.1. Anyone know whats going on? I get the same problem with Maven 2.0.5 and 2.0.6 :-( --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]
Re: Doxia and Site Plugin
On 02/04/2007, at 11:12 PM, Jason van Zyl wrote:
On 1 Apr 07, at 8:05 PM 1 Apr 07, Brett Porter wrote:
What was the final verdict on the velocity processing?
Optional.
Is this documented on the plugin site somewhere? I wasn't able to
find it.
I can see this doesn't break a lot now because it's only
properties, but I know the next thing someone is going to ask for
is to filter ${project.*} which will break a bunch of docs. I'd
still prefer the user make a conscious decision to have a document
filtered (all they need to do is whack a .vm extension on the
document). I also note the current site has an ugly exception
during generation due to this, though it does handle the outcome
correctly.
Will the site plugin be another beta release? Looking at the
current JIRA, I think the 2.0 still represents a beta-quality
release, where 2.0.1 looks more like 2.0.
Probably should be alpha, another thing that jumped the gun but
another beta for sure.
Cool. I'll rename in JIRA.
Sure, if you haven't I can pop those in there and I will work on
what I can. But I want to get the base doxia stuff out and people
are clamoring for the site plugin so getting what's out now is more
important but the time is consumed in running in all the older
containers to make sure things still work. Which is how I found the
container/api JAR problem.
Ok, will do.
- Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [embedder] Retrieving available versions of an artifact
On 2 Apr 07, at 8:22 PM 2 Apr 07, Carlos Sanchez wrote:
I haven't found a direct way to retrieve the ArtifactMetadataSource
instance to retrieve the list of available versions in the repository,
I have to explicitly look it up in the plexus container.
Did I miss something? if not it would be useful to expose the
ArtifactMetadataSource or add a getAvailableVersions method to the
embedder
What's the full use case?
People typically use the search with the index to find all the
available versions to, say, select a specific version of commons-
logging. This is for the IDE and is specific to that environment.
The indexing API will be exposed in a package at Mevenide and not in
the embedder, but that is the way users have generally been seeing
all versions and that's how users interact with the artifact
selection process. It's far easier using the index which is 300k
zipped for the entire repository.
Jason.
public ListArtifactVersion getAvailableVersions(Artifact
artifact, ListArtifactRepository remoteRepositories,
ArtifactRepository localRepository)
{
ArtifactMetadataSource artifactMetadataSource =
(ArtifactMetadataSource) mavenEmbedder.getPlexusContainer().lookup(
ArtifactMetadataSource.ROLE);
return
artifactMetadataSource.retrieveAvailableVersions(artifact,
localRepository, remoteRepositories);
}
--
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Doxia and Site Plugin
On 2 Apr 07, at 8:37 PM 2 Apr 07, Brett Porter wrote:
On 02/04/2007, at 11:12 PM, Jason van Zyl wrote:
On 1 Apr 07, at 8:05 PM 1 Apr 07, Brett Porter wrote:
What was the final verdict on the velocity processing?
Optional.
Is this documented on the plugin site somewhere? I wasn't able to
find it.
It's not there as there are a few options that I'll offer as choices
and when we pick that's what will be documented.
Jason.
I can see this doesn't break a lot now because it's only
properties, but I know the next thing someone is going to ask for
is to filter ${project.*} which will break a bunch of docs. I'd
still prefer the user make a conscious decision to have a
document filtered (all they need to do is whack a .vm extension
on the document). I also note the current site has an ugly
exception during generation due to this, though it does handle
the outcome correctly.
Will the site plugin be another beta release? Looking at the
current JIRA, I think the 2.0 still represents a beta-quality
release, where 2.0.1 looks more like 2.0.
Probably should be alpha, another thing that jumped the gun but
another beta for sure.
Cool. I'll rename in JIRA.
Sure, if you haven't I can pop those in there and I will work on
what I can. But I want to get the base doxia stuff out and people
are clamoring for the site plugin so getting what's out now is
more important but the time is consumed in running in all the
older containers to make sure things still work. Which is how I
found the container/api JAR problem.
Ok, will do.
- Brett
-
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: Creating a schedule for releases
That sounds like a great idea...and one less place to visit. -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 3:23 PM To: Maven Developers List Subject: RE: Creating a schedule for releases I know the calendar is already out there so this might be late info (I didn't think of it before), but I thought I'd point out that Jira has the ability to set release dates and there is a calendar portlet you can add to show them. It's probably less functionality than the google one, but it could also incorporate the releases of all plugins, including ones where the lead isn't on the PMC (if there are any). -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 12:08 PM To: Maven Developers List Subject: Re: Creating a schedule for releases On 2 Apr 07, at 12:00 PM 2 Apr 07, Joakim Erdfelt wrote: Looks like we'll need an new maven-ical-report for the site generation. To inject the schedule into the site, with links to the live-schedule. I think just pointing to the calendar will suffice. I think a lot of people will just end up subscribing to the feed. Jason. - Joakim Jason van Zyl wrote: On 2 Apr 07, at 9:44 AM 2 Apr 07, Brian E. Fox wrote: +1. More info helps the users to plan and gives the devs something to work towards. I'd like to see some tentative plans for 2.1 also. 2.1-alpha-1 will go on the schedule, the issues are registered for it and John and I would like to cut the alpha in the coming week so we'll get wiki fleshed out with details of the issues listed in JIRA. Jason. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 9:38 AM To: Maven Developers List Subject: Creating a schedule for releases Hi, Taking the lead from the Mylar development team, whom I have a great deal of respect for, I would like to create a shared Google calendar where we can put some releases on schedules. I know at least for Maven itself, Doxia, Wagon and some plugins I'm working on I have a clear idea of when they will be released. But what the Mylar team does is work under the general Europa guidelines and they try and do releases every 6 weeks. So I'm not sure how the everything will be ultimately schedule but I would like to make a start at trying to provide some transparency as the Mylar team does. So the though was that we would have a calendar on Google where everyone on the PMC has access to the schedule (as it's a PMC person who has to do a release) and I'll start the by putting in the Maven releases. I planned 4 weeks between the last releases and it ended up being 6 so I'll shoot for that again, but even if we're off a bit it keeps the users informed and they will have a single place to look for planned releases dates. I would like to set this up asap. +1 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] - 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: 2.0.6 download links broken
On 4/2/07, Jason van Zyl [EMAIL PROTECTED] wrote: Requires trunk of the site plugin. Okay. I deployed another snapshot of the site plugin, it was only a couple of days old but before that, 'mvn site -U' didn't seem to work. I'm getting errors and stack traces from Velocity. Is there a way to tell it not to filter certain files? The files it's complaining about are release-notes.apt, guide-bash-m2-completion.apt. Since everything else is controlled by directory name and file extension, what about the suggestion (Brett's?) of using .vm for the files you want it to filter? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.0.6 download links broken
On 03/04/2007, at 12:17 PM, Wendy Smoak wrote: On 4/2/07, Jason van Zyl [EMAIL PROTECTED] wrote: Requires trunk of the site plugin. Okay. I deployed another snapshot of the site plugin, it was only a couple of days old but before that, 'mvn site -U' didn't seem to work. Hmm, I deployed one just yesterday specifically for this... I'm getting errors and stack traces from Velocity. Is there a way to tell it not to filter certain files? The files it's complaining about are release-notes.apt, guide-bash-m2-completion.apt. The second can be ignored. I don't know about the first - it must have been one of your additions. Since everything else is controlled by directory name and file extension, what about the suggestion (Brett's?) of using .vm for the files you want it to filter? I think Jason earlier said he's going to make a proposition or two for making it optional before the next release. I'll put it in JIRA now... ... http://jira.codehaus.org/browse/MSITE-223 Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven-enforcer-plugin
Ok, a little more refactoring. The Custom rules can now get to the ExpressionEvaluator so they can get pretty much anything a plugin could get. The sites are updated to contain info about the standard rules and the custom rule creation: http://maven.apache.org/plugins/maven-enforcer-plugin/ http://maven.apache.org/shared/maven-enforcer-rule-api/index.html I'll let this linger for a day or so and then call a vote if nothing turns up. Thanks, Brian -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Thursday, March 29, 2007 11:59 PM To: Maven Developers List Subject: RE: maven-enforcer-plugin I reimplemented the enforcer plugin along the lines of Jason D's idea[1] and I think this is a much more extensible solution. The rules now implement a common interface in shared/maven-enforcer-rule-api and users will be able to inject their own custom rules. By defining the interface external to the plugin, the Lint idea that JVZ put out[2] should be able to invoke these rules, as will IDEs. Please take a look at the site to see how the plugin works and provide any suggestions. I still need to document how to create your own rules and inject them, but I believe everything else is covered. A snapshot of 1.0-alpha-1 has also been deployed for testing. (I believe Geronimo is already using it) http://maven.apache.org/plugins/maven-enforcer-plugin (just deployed, may take a while to refresh) [1] http://www.nabble.com/maven-enforcer-plugin-tf3431452s177.html#a9565974 [2] http://www.nabble.com/Maven-Lint-tf3462956s177.html#a9661545 -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 20, 2007 12:05 AM To: Maven Developers List Subject: maven-enforcer-plugin There is a new plugin that I'd like to get some feedback on, particularly on non-windows os's and the unit tests. The maven-enforcer-plugin picks up where prerequisites leaves off and allows control over the maven, jdk and os versions of a build. This plugin was initially conceived here: http://www.nabble.com/Control-of-maven-using-prerequisites-tf3231437s177 .html#a8979318 And here: http://www.nabble.com/Why-is-prerequisites-not-inherited--tf3236197s177. html#a9016296 1.0-alpha-1-SNAPSHOT is deployed and the site is here: http://maven.apache.org/plugins/maven-enforcer-plugin/ (just deployed so give it a little bit to completely update) If all goes well and no major issues are uncovered, then I think it's ready for staging and a vote. Thanks, Brian - 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]
[Vote] Move plugin site.xml up to Maven or Shared
Currently only plugins get a nice looking skin that matches the main maven.apache.org page because the site.xml exists in the plugin project. Other things like shared get a homely looking default skin. I see two options here: 1. Move the site.xml up to the maven pom. This is preferred so that all submodules of maven can get the standard skin and override it if they choose. 2. Copy the site.xml over to the shared pom. This is less intrusive but doesn't cover all submodules that come along. Vote: [ X ] Move to Maven Pom [ ] Copy to shared Vote is open for 72 hrs.
Re: [Vote] Move plugin site.xml up to Maven or Shared
On 2 Apr 07, at 10:39 PM 2 Apr 07, Brian E. Fox wrote: Currently only plugins get a nice looking skin that matches the main maven.apache.org page because the site.xml exists in the plugin project. Other things like shared get a homely looking default skin. I see two options here: 1. Move the site.xml up to the maven pom. This is preferred so that all submodules of maven can get the standard skin and override it if they choose. +1 2. Copy the site.xml over to the shared pom. This is less intrusive but doesn't cover all submodules that come along. Vote: [ X ] Move to Maven Pom [ ] Copy to shared Vote is open for 72 hrs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven-install-plugin :: Cannot override read-only parameter: artifactId ?
Rahul was having this problem with the achetypeNG with groupId, even though the original archetype didn't have this problem. I seem to recall he figured it out, but not the solution. -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dillon Sent: Monday, April 02, 2007 8:11 PM To: Maven Developers List Subject: Re: maven-install-plugin :: Cannot override read-only parameter: artifactId ? It was working for me for a while... then it stopped. I don't know why at all. This is install:install-file, not install:install, so you are expected to configure the artifactId. Its not marked as read- only. But I've not idea why it just started complaining to me about it... :-( --jason On Apr 2, 2007, at 4:44 PM, Brett Porter wrote: I thought that had always been the case and was a known issue in the install plugin. On 03/04/2007, at 6:32 AM, Jason Dillon wrote: I all of a sudden started to see this today: snip [INFO] - --- [ERROR] BUILD ERROR [INFO] - --- [INFO] Error configuring: org.apache.maven.plugins:maven-install- plugin. Reason: ERROR: Cannot override read-only parameter: artifactId in goal: install:install-file /snip From what I can tell this is using maven-install-plugin 2.1. Anyone know whats going on? I get the same problem with Maven 2.0.5 and 2.0.6 :-( --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] Move plugin site.xml up to Maven or Shared
I'm in favour of 'moving' it up. I think you'll still need this site.xml though it'll be mostly empty (maybe add breadcrumbs?). The TODO's already in there tell that story. We'll also need to do a maven pom release after that change. - Brett On 03/04/2007, at 12:45 PM, Jason van Zyl wrote: On 2 Apr 07, at 10:39 PM 2 Apr 07, Brian E. Fox wrote: Currently only plugins get a nice looking skin that matches the main maven.apache.org page because the site.xml exists in the plugin project. Other things like shared get a homely looking default skin. I see two options here: 1. Move the site.xml up to the maven pom. This is preferred so that all submodules of maven can get the standard skin and override it if they choose. +1 2. Copy the site.xml over to the shared pom. This is less intrusive but doesn't cover all submodules that come along. Vote: [ X ] Move to Maven Pom [ ] Copy to shared Vote is open for 72 hrs. - 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] Move plugin site.xml up to Maven or Shared
+1 Move to Maven pom Brian E. Fox wrote: Currently only plugins get a nice looking skin that matches the main maven.apache.org page because the site.xml exists in the plugin project. Other things like shared get a homely looking default skin. I see two options here: 1. Move the site.xml up to the maven pom. This is preferred so that all submodules of maven can get the standard skin and override it if they choose. 2. Copy the site.xml over to the shared pom. This is less intrusive but doesn't cover all submodules that come along. Vote: [ X ] Move to Maven Pom [ ] Copy to shared Vote is open for 72 hrs. !DSPAM:602,4611be65165153095511399! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven Ant Tasks 2.0.6
+1 On 4/3/07, John Casey [EMAIL PROTECTED] wrote: +1 On 4/2/07, Jason Dillon [EMAIL PROTECTED] wrote: +1 --jason On Apr 1, 2007, at 10:36 AM, Jason van Zyl wrote: Hi, The staging repository is here: http://people.apache.org/~jvanzyl/staging-repository/maven-ant- tasks-2.0.6/ The uber jar that people will want to try is here: http://people.apache.org/~jvanzyl/staging-repository/maven-ant- tasks-2.0.6/org/apache/maven/maven-ant-tasks/2.0.6/ Road map: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=truepid=11533fixfor=13351sorter/field=issuekeysorter/ order=DESC 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]
OMG... mvn -X spits out soooooo much junk
I think its time for a --debug and --trace option to mvn... as mvn -X by itself spits out sooo much output that it is almost unusable. Certainly to get more information out of plugins that are executing its provides *way, way* to much information. For example, running `mvn -X -N` from the geronimo/server/trunk build, its spits out ~2500 lines. I'd really like to see the logging output in Maven have some finer controls. *most* of the time I just want debugging information from my plugins, including a brief overview of the artifact they came from, the arguments to the mojo and then the mojos log.debug() output. I don't care much the full tree of maven artifacts and all that other muck for most times I want to see debug information. I really think that mvn should have better cli configuration of the debug and warning levels which are enabled. Very simlar to how CC has the -W flag to enable sets of warnings, I think that mvn needs a flag to enable sets of warning and debug information. For example, this might show all the gory detail about artifacts: mvn --debug=artifacts Where this would only show the plugin invokation details: mvn --debug=plugin And default to the minimal: mvn --debug ^^^ is the same as mvn --debug=plugin * * * For those interested, the full ~2500 lines of mvn -X -N for sever/ trunk are here: http://rifers.org/paste/jdillon/show/4223 This is a big project... but I don't really need all of that output when I'm trying to debug plugin executions. Today I just wanted to make sure that the maven-enforcer-plugin was still working after the snapshot, since it now logs details to DEBUG instead of INFO. And I was appalled when I ran `mvn -X -N` from the top-level and go so much junk. I really would like to see this fixed... it would really help people to debug mvn issues. Sure there are times when you need the full output, maybe from `mvn --debug=all` but 90% of the time all that extra information just makes it hard to find the information you do care about. Please can we address this problem? --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: OMG... mvn -X spits out soooooo much junk
Looks like enforcer worked :-) -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dillon Sent: Monday, April 02, 2007 11:49 PM To: Maven Developers List Subject: OMG... mvn -X spits out soo much junk I think its time for a --debug and --trace option to mvn... as mvn -X by itself spits out sooo much output that it is almost unusable. Certainly to get more information out of plugins that are executing its provides *way, way* to much information. For example, running `mvn -X -N` from the geronimo/server/trunk build, its spits out ~2500 lines. I'd really like to see the logging output in Maven have some finer controls. *most* of the time I just want debugging information from my plugins, including a brief overview of the artifact they came from, the arguments to the mojo and then the mojos log.debug() output. I don't care much the full tree of maven artifacts and all that other muck for most times I want to see debug information. I really think that mvn should have better cli configuration of the debug and warning levels which are enabled. Very simlar to how CC has the -W flag to enable sets of warnings, I think that mvn needs a flag to enable sets of warning and debug information. For example, this might show all the gory detail about artifacts: mvn --debug=artifacts Where this would only show the plugin invokation details: mvn --debug=plugin And default to the minimal: mvn --debug ^^^ is the same as mvn --debug=plugin * * * For those interested, the full ~2500 lines of mvn -X -N for sever/ trunk are here: http://rifers.org/paste/jdillon/show/4223 This is a big project... but I don't really need all of that output when I'm trying to debug plugin executions. Today I just wanted to make sure that the maven-enforcer-plugin was still working after the snapshot, since it now logs details to DEBUG instead of INFO. And I was appalled when I ran `mvn -X -N` from the top-level and go so much junk. I really would like to see this fixed... it would really help people to debug mvn issues. Sure there are times when you need the full output, maybe from `mvn --debug=all` but 90% of the time all that extra information just makes it hard to find the information you do care about. Please can we address this problem? --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]
Re: OMG... mvn -X spits out soooooo much junk
Oh, ya... it works, I got distracted by my rant. Latest snapshot looks okay to me. --jason On Apr 2, 2007, at 8:59 PM, Brian E. Fox wrote: Looks like enforcer worked :-) -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dillon Sent: Monday, April 02, 2007 11:49 PM To: Maven Developers List Subject: OMG... mvn -X spits out soo much junk I think its time for a --debug and --trace option to mvn... as mvn -X by itself spits out sooo much output that it is almost unusable. Certainly to get more information out of plugins that are executing its provides *way, way* to much information. For example, running `mvn -X -N` from the geronimo/server/trunk build, its spits out ~2500 lines. I'd really like to see the logging output in Maven have some finer controls. *most* of the time I just want debugging information from my plugins, including a brief overview of the artifact they came from, the arguments to the mojo and then the mojos log.debug() output. I don't care much the full tree of maven artifacts and all that other muck for most times I want to see debug information. I really think that mvn should have better cli configuration of the debug and warning levels which are enabled. Very simlar to how CC has the -W flag to enable sets of warnings, I think that mvn needs a flag to enable sets of warning and debug information. For example, this might show all the gory detail about artifacts: mvn --debug=artifacts Where this would only show the plugin invokation details: mvn --debug=plugin And default to the minimal: mvn --debug ^^^ is the same as mvn --debug=plugin * * * For those interested, the full ~2500 lines of mvn -X -N for sever/ trunk are here: http://rifers.org/paste/jdillon/show/4223 This is a big project... but I don't really need all of that output when I'm trying to debug plugin executions. Today I just wanted to make sure that the maven-enforcer-plugin was still working after the snapshot, since it now logs details to DEBUG instead of INFO. And I was appalled when I ran `mvn -X -N` from the top-level and go so much junk. I really would like to see this fixed... it would really help people to debug mvn issues. Sure there are times when you need the full output, maybe from `mvn --debug=all` but 90% of the time all that extra information just makes it hard to find the information you do care about. Please can we address this problem? --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]
Re: maven-enforcer-plugin
On 4/3/07, Brian E. Fox [EMAIL PROTECTED] wrote: Ok, a little more refactoring. The Custom rules can now get to the ExpressionEvaluator so they can get pretty much anything a plugin could get. The sites are updated to contain info about the standard rules and the custom rule creation: http://maven.apache.org/plugins/maven-enforcer-plugin/ http://maven.apache.org/shared/maven-enforcer-rule-api/index.html I'll let this linger for a day or so and then call a vote if nothing turns up. - typo in the usage.html /requireMavenVesion - /requireMavenVersion - would there be a way to make sure the enforcer runs for every maven invocation, not just in the default lifecycle ? E.g. mvn site doesn't trigger the check. - finally do we want to provide a report? -- if so, we perhaps need to add a mechanism to allow the rule information to be displayed (visitor pattern for the rule? description in a particular place ? Auto-generated information ?) -- would there be a way to make this report part of the project information (not a 'usual' report)? J - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.0.6 download links broken
On 4/2/07, Brett Porter [EMAIL PROTECTED] wrote: I'm getting errors and stack traces from Velocity. Is there a way to tell it not to filter certain files? The files it's complaining about are release-notes.apt, guide-bash-m2-completion.apt. The second can be ignored. I don't know about the first - it must have been one of your additions. Yep, it's complaining about this line: * [MNG-2339] - $project.* are interpreted in the wrong place -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
