from:"Paul Benedict $JIRA$"

[jira] Created: (MNG-3368) Printing version (-v argument) should not stop lifecycle execution

2008-01-18 Thread Paul Benedict (JIRA)

Printing version (-v argument) should not stop lifecycle execution
--

 Key: MNG-3368
 URL: http://jira.codehaus.org/browse/MNG-3368
 Project: Maven 2
  Issue Type: Bug
  Components: Bootstrap  Build, Command Line
Affects Versions: 2.0.8
Reporter: Paul Benedict


I wanted to always print the Maven version when I build, but unfortunately 
Maven immediately quits after outputting the version. This option should not 
quit when a lifecycle is also specified. Example: mvn -v install

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3368) Printing version (-v argument) should not stop lifecycle execution

2008-02-01 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122063
 ] 

Paul Benedict commented on MNG-3368:


I believe the fix is easy. Two use cases have to be supported:
1) If --version and no phase specified, then print version and quit. This 
prevents the You must specify at least one goal message.
2) If --version and phase(s) specified, then print version and continue.

The change needs to be made in org.apache.maven.cli.MavenCli

Line 142 has this:
if ( commandLine.hasOption( CLIManager.VERSION ) )
{
showVersion();
if ( // *** Add second condition ) {
  return 0;
}
}



 Printing version (-v argument) should not stop lifecycle execution
 --

 Key: MNG-3368
 URL: http://jira.codehaus.org/browse/MNG-3368
 Project: Maven 2
  Issue Type: Bug
  Components: Bootstrap  Build, Command Line
Affects Versions: 2.0.8
Reporter: Paul Benedict

 I wanted to always print the Maven version when I build, but unfortunately 
 Maven immediately quits after outputting the version. This option should not 
 quit when a lifecycle is also specified. Example: mvn -v install

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3395) Default core plugin versions in the superpom.

2008-02-28 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125527
 ] 

Paul Benedict commented on MNG-3395:


Brian, when this is complete, please update the documentation to publicly 
reveal the versions. The information would probably be most appropriate as a 
table in the release notes page.

 Default core plugin versions in the superpom.
 -

 Key: MNG-3395
 URL: http://jira.codehaus.org/browse/MNG-3395
 Project: Maven 2
  Issue Type: Improvement
  Components: Artifacts and Repositories
Affects Versions: 2.0.8
Reporter: Brian Fox
Assignee: Brian Fox
 Fix For: 2.0.9


 We should define the plugin versions for core and other common plugins (the 
 apache plugins is a good place to start) in the super pom in 2.0.x to help 
 with stability.
 See here for more info.
 http://www.nabble.com/Plugin-Versions-in-the-Super-pom-to15367074s177.html#a15367074

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3395) Default core plugin versions in the superpom.

2008-03-09 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126624
 ] 

Paul Benedict commented on MNG-3395:


I'd also like to see added:
maven-archetype-plugin
maven-resources-plugin
maven-help-plugin


 Default core plugin versions in the superpom.
 -

 Key: MNG-3395
 URL: http://jira.codehaus.org/browse/MNG-3395
 Project: Maven 2
  Issue Type: Improvement
  Components: Artifacts and Repositories
Affects Versions: 2.0.8
Reporter: Brian Fox
Assignee: Brian Fox
 Fix For: 2.0.9

 Attachments: default-plugin-versions.patch


 We should define the plugin versions for core and other common plugins (the 
 apache plugins is a good place to start) in the super pom in 2.0.x to help 
 with stability.
 See here for more info.
 http://www.nabble.com/Plugin-Versions-in-the-Super-pom-to15367074s177.html#a15367074

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3395) Default core plugin versions in the superpom.

2008-03-09 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126635
 ] 

Paul Benedict commented on MNG-3395:


Brian, you were right about resources plugin. I missed it because it wasn't in 
alphabetical order.

 Default core plugin versions in the superpom.
 -

 Key: MNG-3395
 URL: http://jira.codehaus.org/browse/MNG-3395
 Project: Maven 2
  Issue Type: Improvement
  Components: Artifacts and Repositories
Affects Versions: 2.0.8
Reporter: Brian Fox
Assignee: Brian Fox
 Fix For: 2.0.9

 Attachments: default-plugin-versions.patch


 We should define the plugin versions for core and other common plugins (the 
 apache plugins is a good place to start) in the super pom in 2.0.x to help 
 with stability.
 See here for more info.
 http://www.nabble.com/Plugin-Versions-in-the-Super-pom-to15367074s177.html#a15367074

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Issue Comment Edited: (MNG-2807) ciManagement from parent is not merging with children

2008-03-09 Thread Paul Benedict (JIRA)

[
http://jira.codehaus.org/browse/MNG-2807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124607
]

paul4christ79 edited comment on MNG-2807 at 3/9/08 10:00 PM:
-

This would greatly help when submodules are ran by different developers. The
software engineers can be placed in the parent POM, and additional developers
notified via the children POM. In the company I work for, we aren't allowed to
have custom mailing lists -- so we have to list people (i.e., developers)
individually in the POM. A pain, yes, but if this element was inheritable, it
would be easier to deal with our constraint.

was (Author: paul4christ79):
This would greatly help when submodules are ran by different developers.
The software engineers can be placed in the parent POM, and additional
developers notified via the children POM.

ciManagement from parent is not merging with children
-

Key: MNG-2807
URL: http://jira.codehaus.org/browse/MNG-2807
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 2.0.4
Environment: linux jdk1.5.0_10 amd64
Reporter: Kelly Davis
Fix For: Reviewed Pending Version Assignment

If I define the following in my parent pom:
ciManagement
systemcontinuum/system
urlhttp://blah/url
/ciManagement
and then in the child pom I have the following:
ciManagement
notifier
typemail/type
configuration
addressblah/address
/configuration
/notifier
/ciManagement
The ciManagement for the effective pom lacks the system and url properties
from the parent pom. Seems like it should be merging them but isn't. This
would helpful for reducing code duplication.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-2433) Maven looks for snapshots in offline mode

2008-03-10 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126730
 ] 

Paul Benedict commented on MNG-2433:


Do you not have 2.2-SNAPSHOT already present on your system? I imagine that if 
it isn't there the first time, it cannot possibly build with a plugin that's 
absent. That is different than trying to update a plugin that already is 
installed.

 Maven looks for snapshots in offline mode
 -

 Key: MNG-2433
 URL: http://jira.codehaus.org/browse/MNG-2433
 Project: Maven 2
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 2.0.5
Reporter: Carsten Ziegeler
Assignee: Jason van Zyl
Priority: Critical
 Fix For: 2.0.6


 It seems that sometimes Maven2 is looking for snapshots in offline mode (this 
 happens for example in the Cocoon project). here is an output that might help:
 :\dev\workspace\cocoon-2.2\core\cocoon-webappmvn -o -Dmaven.test.skip=true 
 coc
 oon:deploy
 [INFO]
 NOTE: Maven is executing in offline mode. Any artifacts not already in your 
 loca
 l
 repository will be inaccessible.
 [INFO] Scanning for projects...
 [INFO] Searching repository for plugin with prefix: 'cocoon'.
 [INFO] org.apache.maven.plugins: checking for updates from snapshots
 [INFO] org.apache.maven.plugins: checking for updates from mortbay-repo
 [INFO] org.codehaus.mojo: checking for updates from snapshots
 [INFO] org.codehaus.mojo: checking for updates from mortbay-repo
 [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
 checkin
 g for updates from snapshots
 [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
 checkin
 g for updates from mortbay-repo
 [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
 checkin
 g for updates from central
 [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
 checkin
 g for updates from apache.snapshot
 [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
 checkin
 g for updates from apache-cvs
 [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: 
 checkin
 g for updates from apache.snapshots
 [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
 updat
 es from snapshots
 [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
 updat
 es from mortbay-repo
 [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
 updat
 es from central
 [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
 updat
 es from apache.snapshot
 [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
 updat
 es from apache-cvs
 [INFO] snapshot org.apache.cocoon:cocoon-deployer:1-SNAPSHOT: checking for 
 updat
 es from apache.snapshots
 [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
 for
 updates from snapshots
 [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
 for
 updates from mortbay-repo
 [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
 for
 updates from central
 [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
 for
 updates from apache.snapshot
 [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
 for
 updates from apache-cvs
 [INFO] snapshot org.apache.cocoon:cocoon-tools-modules:1-SNAPSHOT: checking 
 for
 updates from apache.snapshots
 [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
 from s
 napshots
 [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
 from m
 ortbay-repo
 [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
 from c
 entral
 [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
 from a
 pache.snapshot
 [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
 from a
 pache-cvs
 [INFO] snapshot org.apache.cocoon:cocoon:1-SNAPSHOT: checking for updates 
 from a
 pache.snapshots

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3430) Toolchain doesn't match Toolchain extensions

2008-03-10 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126764
 ] 

Paul Benedict commented on MNG-3430:


Affects version is 2.0.9 -- should Fix Version also be 2.0.9 not 2.0.x?

 Toolchain doesn't match Toolchain extensions
 

 Key: MNG-3430
 URL: http://jira.codehaus.org/browse/MNG-3430
 Project: Maven 2
  Issue Type: Bug
Affects Versions: 2.0.9
Reporter: Shane Isbell
Assignee: Milos Kleint
Priority: Minor
 Fix For: 2.0.x, 2.1-alpha-1


 Toolchain uses null key within storing toolchains in Maven Session, which 
 causes extensions not to match.
 Specifically, this problem occurs in the 
 DefaultToolchainManager.storeToolchainToBuildContext method.  When storing 
 into context
 context.put( getStorageKey( toolchain.getType() ), toolchain.getModel() );
 toolchain.getType() always returns null. Using toolchain.getModel().getType() 
 will return the correct type and fix the problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-1832) built-in property containing current timestamp

2008-03-11 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126893
 ] 

Paul Benedict commented on MNG-1832:


Unfortunately, the buildnumber plugin works only with SVN. Maven supports a 
greater breadth of SCM implementations, which I believe should be considered 
here.

 built-in property containing current timestamp
 --

 Key: MNG-1832
 URL: http://jira.codehaus.org/browse/MNG-1832
 Project: Maven 2
  Issue Type: New Feature
Affects Versions: 2.0.1
Reporter: Michal Stochmialek
 Attachments: maven-archiver_pomDelete.patch, 
 maven-core_defaultExpressions.patch


 Current timestamp (time or date) is often used while filtering resources or 
 creating manifest in ant builds. There is no equivalent in maven.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (SUREFIRE-471) Infinite loop when ERROR is detected

2008-03-11 Thread Paul Benedict (JIRA)

Infinite loop when ERROR is detected

Key: SUREFIRE-471
URL: http://jira.codehaus.org/browse/SUREFIRE-471
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.4.2
Environment: Windows XP, Maven 2.0.8, Spring 1.2.8, JDK 1.6
Reporter: Paul Benedict

I can't supply a test case, but I will try to describe in detail exactly what
occurs so you can reproduce it:

My hibernate integration tests are in a separate profile named itest. My
integration tests load Hibernate via Spring. I had a Hibernate mapping
configuration error in which my set element was missing its key element.
Now usually a mapping error causes the testing to immediately quit, but here it
didn't. Instead it reported the error and reran the whole phase again, and
again, etc.

set name=items inverse=true
one-to-many class=x.y.z.MyObject /
/set

My debug output:
[DEBUG] Using JVM: D:\jdk1.6.0_01\jre\bin\java
[INFO] Surefire report directory: D:\workspace\myproject\target\surefire-reports
Forking command line: cmd.exe /X /C 'D:\jdk1.6.0_01\jre\bin\java -jar
c:\temp\surefirebooter4340.jar c:\temp\surefire4338tmp c:\temp\surefire4339tmp'
.. test output.
31876 [main] ERROR org.hibernate.util.XMLHelper - Error parsing XML: XML
InputStream(23) The content of element type set must match
(meta*,subselect?,cache?,synchronize*,comment?,key,(element|one-to-many|many-to-many|composite-element|many-to-any),loader?,sql-insert?,sql-update?,sql-delete?,sql-delete-all?,filter*)
.. test output..
..repeat.

[jira] Commented: (MNG-3330) reporting plugin poms are retrieved from the wrong repository

2008-03-12 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126973
 ] 

Paul Benedict commented on MNG-3330:


John, can I recommend you keep this open and bump to 2.0.10? It will keep it on 
the radar for verification. If it truly can't be produced, then it should get a 
Cannot Reproduce state.

 reporting plugin poms are retrieved from the wrong repository
 -

 Key: MNG-3330
 URL: http://jira.codehaus.org/browse/MNG-3330
 Project: Maven 2
  Issue Type: Bug
Affects Versions: 2.0.8
Reporter: Dan Fabulich
Assignee: John Casey
 Fix For: 2.0.9

 Attachments: maven-test-report-plugin.zip


 Pull the staged 2.4 into your local repo, and run surefire-report:report-only 
 on a POM configured to use 2.4.  The build will fail.  Try again, this time 
 running mvn 
 org.apache.maven.plugins:maven-surefire-report-plugin:2.4:report-only
 -
 this realm = 
 app0.child-container[org.apache.maven.plugins:maven-surefire-report-plugin]
 urls[0] = 
 file:/c:/weirdlocalrepo/org/apache/maven/plugins/maven-surefire-report-plugin/2.4/maven-surefire-report-plugin-2.4.jar
 urls[1] = 
 file:/c:/weirdlocalrepo/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
 Number of imports: 4
 import: [EMAIL PROTECTED]
 import: [EMAIL PROTECTED]
 import: [EMAIL PROTECTED]
 import: [EMAIL PROTECTED]
 this realm = plexus.core
 urls[0] = file:/C:/devtools/maven-2.0.7/lib/maven-core-2.0.7-uber.jar
 Number of imports: 4
 import: [EMAIL PROTECTED]
 import: [EMAIL PROTECTED]
 import: [EMAIL PROTECTED]
 import: [EMAIL PROTECTED]
 -
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Internal error in the plugin manager executing goal 
 'org.apache.maven.plugins:maven-surefire-report-plugin:2.4:report-only': 
 Unable to find the mojo 
 'org.apache.maven.plugins:maven-surefire-report-plugin:2.4:report-only' in 
 the p
 lugin 'org.apache.maven.plugins:maven-surefire-report-plugin'
 org/apache/maven/reporting/AbstractMavenReport

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (SUREFIRE-471) Infinite loop when ERROR is detected

2008-03-12 Thread Paul Benedict (JIRA)

[
http://jira.codehaus.org/browse/SUREFIRE-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126976
]

Paul Benedict commented on SUREFIRE-471:

Because I can reproduce this consistently, I will provide an example project
for testing.

Infinite loop when ERROR is detected

I can't supply a test case, but I will try to describe in detail exactly what
occurs so you can reproduce it:
My hibernate integration tests are in a separate profile named itest. My
integration tests load Hibernate via Spring. I had a Hibernate mapping
configuration error in which my set element was missing its key element.
Now usually a mapping error causes the testing to immediately quit, but here
it didn't. Instead it reported the error and reran the whole phase again, and
again, etc.
set name=items inverse=true
one-to-many class=x.y.z.MyObject /
/set
My debug output:
[DEBUG] Using JVM: D:\jdk1.6.0_01\jre\bin\java
[INFO] Surefire report directory:
D:\workspace\myproject\target\surefire-reports
Forking command line: cmd.exe /X /C 'D:\jdk1.6.0_01\jre\bin\java -jar
c:\temp\surefirebooter4340.jar c:\temp\surefire4338tmp
c:\temp\surefire4339tmp'
.. test output.
31876 [main] ERROR org.hibernate.util.XMLHelper - Error parsing XML: XML
InputStream(23) The content of element type set must match
(meta*,subselect?,cache?,synchronize*,comment?,key,(element|one-to-many|many-to-many|composite-element|many-to-any),loader?,sql-insert?,sql-update?,sql-delete?,sql-delete-all?,filter*)
.. test output..
..repeat.

[jira] Commented: (MNG-3370) Fail build on circular dependencies

2008-03-13 Thread Paul Benedict (JIRA)

[
http://jira.codehaus.org/browse/MNG-3370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127113
]

Paul Benedict commented on MNG-3370:

If A depends on B and B depends on A, I don't see why the build should fail.
You need both A and B on your classpath to compile. Circular dependencies can
be solved by putting in place holders (i.e., proxies) and then making a second
pass to clean them up. So I think the logging should switch from DEBUG to WARN,
but definitely be resolved.

Fail build on circular dependencies
---

Key: MNG-3370
URL: http://jira.codehaus.org/browse/MNG-3370
Project: Maven 2
Issue Type: Improvement
Components: Artifacts and Repositories
Affects Versions: 2.0.8
Reporter: Mark Hobson

Currently circular dependencies are merely logged at debug level and not
generally reported to the user. The general consensus is that circular
dependencies are bad, so I believe that they should be reported as early on
as possible. Previously the repository's low quality metadata was cited as a
reason not to fail the build, but I would have thought such issues should
have been rectified by now.
Ideally we would throw a CyclicDependencyException in
DefaultArtifactCollector. If this is deemed too invasive, then we should at
least increase the log level in DebugResolutionListener to warning.

[jira] Created: (MNG-3462) Settings: Proceeding slash should be removed from URLs

2008-03-13 Thread Paul Benedict (JIRA)

Settings: Proceeding slash should be removed from URLs
--

 Key: MNG-3462
 URL: http://jira.codehaus.org/browse/MNG-3462
 Project: Maven 2
  Issue Type: Improvement
  Components: Bootstrap  Build, Settings
Affects Versions: 2.0.8
Reporter: Paul Benedict
Priority: Minor


When repositories and mirrors have their URL end with a slash, you will see a 
double-slash in the URL.

Example configuration:
  mirrors
mirror
  idmergere/id
  mirrorOfcentral/mirrorOf
  nameMergere/name
  urlhttp://repo.mergere.com/maven2//url
/mirror
  /mirrors

Output:
mvn help:effective-pom
Downloading: 
http://repo.mergere.com/maven2//org/apache/maven/plugins/maven-help-plugin/2.0.1/maven-help-plugin-2.0.1.pom
1K downloaded
Downloading: 
http://repo.mergere.com/maven2//org/apache/maven/plugins/maven-help-plugin/2.0.1/maven-help-plugin-2.0.1.jar
19K downloaded

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MENFORCER-39) Allow simplified range checking

2008-03-13 Thread Paul Benedict (JIRA)

Allow simplified range checking
---

 Key: MENFORCER-39
 URL: http://jira.codehaus.org/browse/MENFORCER-39
 Project: Maven 2.x Enforcer Plugin
  Issue Type: Improvement
  Components: Standard Rules
Affects Versions: 1.0-alpha-3, 1.0
Reporter: Paul Benedict
Assignee: Brian Fox
Priority: Minor


The rule [1.0.0,) means at least 1.0.0 inclusive and anything greater. The 
comma should be optional for single-value ranges. It can be inferred simply 
from the brackets and braces what the intention is. So [1.0.0) should also be 
a valid version range.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3395) Default core plugin versions in the superpom.

2008-03-17 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127546
 ] 

Paul Benedict commented on MNG-3395:


Clean can really affect builds. Especially because Windows holds locks on 
directories that are opened in other processes. The latest version of the 
clean plugin can deal with this.

 Default core plugin versions in the superpom.
 -

 Key: MNG-3395
 URL: http://jira.codehaus.org/browse/MNG-3395
 Project: Maven 2
  Issue Type: Improvement
  Components: Artifacts and Repositories
Affects Versions: 2.0.8
Reporter: Brian Fox
Assignee: Brian Fox
 Fix For: 2.0.9

 Attachments: default-plugin-versions.patch, 
 default-plugin-versions.patch


 We should define the plugin versions for core and other common plugins (the 
 apache plugins is a good place to start) in the super pom in 2.0.x to help 
 with stability.
 See here for more info.
 http://www.nabble.com/Plugin-Versions-in-the-Super-pom-to15367074s177.html#a15367074

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3468) FileSet needs a toString() method to properly print in debug mode

2008-03-18 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_127851
 ] 

Paul Benedict commented on MNG-3468:


Please update these 3 related tickets to 2.0.9 so they get on the release notes.

 FileSet needs a toString() method to properly print in debug mode
 -

 Key: MNG-3468
 URL: http://jira.codehaus.org/browse/MNG-3468
 Project: Maven 2
  Issue Type: Improvement
Affects Versions: 2.0.8
Reporter: Wayne Fay
Assignee: Brian Fox
 Fix For: 2.0.10

 Attachments: fileset.patch


 It would be nice if FileSet had a toString() method so it would print 
 something intelligent rather than simply a memory location in debug mode. 
 Before this change, it prints like: 
 [EMAIL PROTECTED]
 With this patch, it prints like (assuming you accept my PatternSet patch):
 FileSet {directory: src/main/resources, PatternSet [includes: {}, excludes: 
 {}]}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3426) regression : dependency in plugin configuration doesn't override plugin classpath

2008-03-20 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_128108
 ] 

Paul Benedict commented on MNG-3426:


I know MNG-3473 was reverted, but why since 2.0.9 is all about increasing 
stability? It seems, in my opinion, that these two should be solved together. 
If this is about timing, I don't see a critical need to push out 2.0.9 soon. 
Just my 2 cents.

 regression : dependency in plugin configuration doesn't override plugin 
 classpath
 ---

 Key: MNG-3426
 URL: http://jira.codehaus.org/browse/MNG-3426
 Project: Maven 2
  Issue Type: Bug
  Components: Plugin API
Affects Versions: 2.0.8
Reporter: nicolas de loof
Assignee: nicolas de loof
Priority: Critical
 Fix For: 2.0.9


 Many maven plugins are wrapper around other tools. The plugin is designed for 
 a version of the tool, and in many case user will want to use a specific 
 version without having to patch the plugin. The dependency element on 
 plugin configuration is a common way to do this, by overriding the plugin POM 
 dependency with another version. 
 plugin
artifactIdcastor-maven-plugin/artifactId
dependencies
dependency
 groupIdorg.codehaus.castor/groupId
 artifactIdcastor/artifactId
 versionVERSION OF CASTOR I WANT TO USE FOR CODE 
 GENERATION/version
/dependency
/dependencies
 /plugin
 This used to work with maven  2.0.8
 In maven 2.0.8, this doesn't work anymore as the dependency set in plugin 
 configuration is added to plugin classpath, as a duplicate for the one 
 declared by the plugin but LATER in the classpath (but I may be wrong on this 
 analysis).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3385) PluginManagement does not work for report-plugins

2008-03-24 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=128433#action_128433
 ] 

Paul Benedict commented on MNG-3385:


Wny not just pluginManagement inside of reporting?

 PluginManagement does not work for report-plugins
 -

 Key: MNG-3385
 URL: http://jira.codehaus.org/browse/MNG-3385
 Project: Maven 2
  Issue Type: Bug
Affects Versions: 2.0.8
Reporter: Andreas Höhmann
 Fix For: 2.1


  build
...
 /pluginManagement
plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-pmd-plugin/artifactId
   version2.2/version
 /plugin
   /plugins
 /pluginManagement
...
   /build
   reporting
 plugins  
plugin
  artifactIdmaven-pmd-plugin/artifactId
/plugin
 /plugins
   /reporting  
 mvn site ... use pmd-2.4-SNAPSHOT instead of the defined 2.2 ... why?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3385) PluginManagement does not work for report-plugins

2008-03-24 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=128490#action_128490
 ] 

Paul Benedict commented on MNG-3385:


I fell into this trap myself. Last week, I defined my reporting plugin versions 
in my build's pluginManagement section, just to find out it has no effect on 
the site generation. This to me is definitively a high-priority issue since I 
cannot dictate the report versions to use without actually specifying the 
reports themselves.

 PluginManagement does not work for report-plugins
 -

 Key: MNG-3385
 URL: http://jira.codehaus.org/browse/MNG-3385
 Project: Maven 2
  Issue Type: Bug
Affects Versions: 2.0.8
Reporter: Andreas Höhmann
 Fix For: 2.1


  build
...
 /pluginManagement
plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-pmd-plugin/artifactId
   version2.2/version
 /plugin
   /plugins
 /pluginManagement
...
   /build
   reporting
 plugins  
plugin
  artifactIdmaven-pmd-plugin/artifactId
/plugin
 /plugins
   /reporting  
 mvn site ... use pmd-2.4-SNAPSHOT instead of the defined 2.2 ... why?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-2562) expose current time as a property for POM interpolation

2008-04-15 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=130889#action_130889
 ] 

Paul Benedict commented on MNG-2562:


Can property names include colons? I am referring to last example.

 expose current time as a property for POM interpolation
 ---

 Key: MNG-2562
 URL: http://jira.codehaus.org/browse/MNG-2562
 Project: Maven 2
  Issue Type: New Feature
  Components: Inheritance and Interpolation
Reporter: Brett Porter
 Fix For: 2.0.10


 it is useful to have the current time, for example to write out a manifest 
 entry for the build time or to filter into another file.
 I'm not sure of the best way to make the format of the time configurable - 
 perhaps another POM element/property.
 See the related issue for a current example of how this can be done, but it 
 would be nice to have a built-in.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3509) Make mvn -v output locale/encoding

2008-04-18 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=131298#action_131298
 ] 

Paul Benedict commented on MNG-3509:


I am concerned about the kind of non-Maven properties outputed with the 
version. It sounds like it could grow pretty big based on feature requests. Why 
not just provide an extended debug option that dumps all the JVM properties?

 Make mvn -v output locale/encoding
 

 Key: MNG-3509
 URL: http://jira.codehaus.org/browse/MNG-3509
 Project: Maven 2
  Issue Type: Improvement
  Components: Command Line
Affects Versions: 2.0.8
Reporter: Benjamin Bentmann
Assignee: Herve Boutemy
Priority: Minor
 Fix For: 2.0.10

 Attachments: locale-output.patch


 Printing a platform's locale and file encoding might be worth to add when 
 Maven is requested to show version information since these parameters can 
 affect text/string handling code.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3509) Make mvn -v output locale/encoding

2008-04-19 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=131382#action_131382
 ] 

Paul Benedict commented on MNG-3509:


What about an option that accepts an ANT pattern matching expression  to match 
against system property names? Then you could give up on the feature requests 
and let the user filter himself: mvn -v -Zjava.locale.*,com.ibm.* (where -Z is 
the placeholder for a new option).

 Make mvn -v output locale/encoding
 

 Key: MNG-3509
 URL: http://jira.codehaus.org/browse/MNG-3509
 Project: Maven 2
  Issue Type: Improvement
  Components: Command Line
Affects Versions: 2.0.8
Reporter: Benjamin Bentmann
Assignee: Herve Boutemy
Priority: Minor
 Fix For: 2.0.10

 Attachments: locale-output.patch


 Printing a platform's locale and file encoding might be worth to add when 
 Maven is requested to show version information since these parameters can 
 affect text/string handling code.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Issue Comment Edited: (MNG-3509) Make mvn -v output locale/encoding

2008-04-19 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=131382#action_131382
 ] 

paul4christ79 edited comment on MNG-3509 at 4/19/08 2:24 AM:
-

What about an option that accepts an ANT pattern matching expression  to match 
against system property names? Then you could give up on the feature requests 
and let the user filter himself: {noformat}mvn -v 
-Zjava.locale.*,com.ibm.*{noformat} where -Z is the placeholder for a new 
option.

  was (Author: paul4christ79):
What about an option that accepts an ANT pattern matching expression  to 
match against system property names? Then you could give up on the feature 
requests and let the user filter himself: mvn -v -Zjava.locale.*,com.ibm.* 
(where -Z is the placeholder for a new option).
  
 Make mvn -v output locale/encoding
 

 Key: MNG-3509
 URL: http://jira.codehaus.org/browse/MNG-3509
 Project: Maven 2
  Issue Type: Improvement
  Components: Command Line
Affects Versions: 2.0.8
Reporter: Benjamin Bentmann
Assignee: Herve Boutemy
Priority: Minor
 Fix For: 2.0.10

 Attachments: locale-output.patch


 Printing a platform's locale and file encoding might be worth to add when 
 Maven is requested to show version information since these parameters can 
 affect text/string handling code.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Issue Comment Edited: (MNG-3509) Make mvn -v output locale/encoding

2008-04-19 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=131382#action_131382
 ] 

paul4christ79 edited comment on MNG-3509 at 4/19/08 7:06 AM:
-

What about an option that accepts a simple wildcard expression  to match 
against system property names? Then you could give up on the feature requests 
and let the user filter himself: {noformat}mvn -v 
-Zjava.locale.*,com.ibm.*{noformat} where -Z is the placeholder for a new 
option.

  was (Author: paul4christ79):
What about an option that accepts an ANT pattern matching expression  to 
match against system property names? Then you could give up on the feature 
requests and let the user filter himself: {noformat}mvn -v 
-Zjava.locale.*,com.ibm.*{noformat} where -Z is the placeholder for a new 
option.
  
 Make mvn -v output locale/encoding
 

 Key: MNG-3509
 URL: http://jira.codehaus.org/browse/MNG-3509
 Project: Maven 2
  Issue Type: Improvement
  Components: Command Line
Affects Versions: 2.0.8
Reporter: Benjamin Bentmann
Assignee: Herve Boutemy
Priority: Minor
 Fix For: 2.0.10

 Attachments: locale-output.patch


 Printing a platform's locale and file encoding might be worth to add when 
 Maven is requested to show version information since these parameters can 
 affect text/string handling code.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3545) Option -P-profile overridden if profile is activebyDefault

2008-05-01 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133229#action_133229
 ] 

Paul Benedict commented on MNG-3545:


I hope + (or nothing at all) means activate, and - means deactivate.

 Option -P-profile overridden if profile is activebyDefault
 --

 Key: MNG-3545
 URL: http://jira.codehaus.org/browse/MNG-3545
 Project: Maven 2
  Issue Type: Bug
  Components: Profiles
Affects Versions: 2.0.9
Reporter: David Bernhard
Assignee: Paul Gier
Priority: Minor
 Fix For: 2.0.10

 Attachments: maven-profile-bug.zip, MNG-3545-profiles.patch


 In maven 2.0.9, deactivating a profile foo that is declared and marked 
 activeByDefault in the local POM does not work, as in 
 DefaultProfileManager.java:227 all activeByDefault profiles are added if no 
 profile is explicitly given (-Pbar).
 In the attached zip, run 
  mvn -P-foo help:active-profiles
 and note that foo *is* active.
 The patch fixes these issues by checking all default-activated profiles 
 against the exclusions list when they are added by default.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Issue Comment Edited: (MNG-3545) Option -P-profile overridden if profile is activebyDefault

2008-05-01 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133229#action_133229
 ] 

paul4christ79 edited comment on MNG-3545 at 5/1/08 12:34 PM:
-

I hope + (or nothing at all) means activate, and - means deactivate. It's just 
natural to understand the minus sign as subtraction, in which you are taking 
away something that already exists.

  was (Author: paul4christ79):
I hope + (or nothing at all) means activate, and - means deactivate.
  
 Option -P-profile overridden if profile is activebyDefault
 --

 Key: MNG-3545
 URL: http://jira.codehaus.org/browse/MNG-3545
 Project: Maven 2
  Issue Type: Bug
  Components: Profiles
Affects Versions: 2.0.9
Reporter: David Bernhard
Assignee: Paul Gier
Priority: Minor
 Fix For: 2.0.10

 Attachments: maven-profile-bug.zip, MNG-3545-profiles.patch


 In maven 2.0.9, deactivating a profile foo that is declared and marked 
 activeByDefault in the local POM does not work, as in 
 DefaultProfileManager.java:227 all activeByDefault profiles are added if no 
 profile is explicitly given (-Pbar).
 In the attached zip, run 
  mvn -P-foo help:active-profiles
 and note that foo *is* active.
 The patch fixes these issues by checking all default-activated profiles 
 against the exclusions list when they are added by default.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3268) Command line doesn't handle multiple -P correctly

2008-05-02 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133371#action_133371
 ] 

Paul Benedict commented on MNG-3268:


It appears this patch also fixes MNG-3545

 Command line doesn't handle multiple -P correctly
 -

 Key: MNG-3268
 URL: http://jira.codehaus.org/browse/MNG-3268
 Project: Maven 2
  Issue Type: Improvement
  Components: Command Line
Affects Versions: 2.0.7
Reporter: Henri Tremblay
Assignee: Paul Gier
 Fix For: 2.0.10, 2.1-alpha-1

 Attachments: MNG-3268-maven-core.patch


 It is currently not possible to have more than one -P on the same command 
 line. Only the first specified profile is considered.
 So if you do
 mvn -Pmain -Ptest
 only the main profile will be taken into account.
 This may sound enough but it's not when your maven call is wrapped into a 
 batch file. Let's say you have a batch doing the compilation of a given 
 module:
 a.bat
 -
 mvn install -Pmymodule %*
 -
 and you want to pass a special integration tests profile you would do:
 a.bat -Pintegration-tests
 But that won't work since you are not allowed to have two -P.
 To merge them in DOS shell is quite a pain in the ***

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MAVENUPLOAD-1968) JDom 1.1 is out

2008-05-08 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=134076#action_134076
 ] 

Paul Benedict commented on MAVENUPLOAD-1968:


Can this be reopened? Yes, it's currently incomplete, but leave it open until 
the request is complete, please. JDOM 1.1 is still not in the central 
repository and it was released Nov 2007. 

 JDom 1.1 is out
 ---

 Key: MAVENUPLOAD-1968
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1968
 Project: maven-upload-requests
  Issue Type: New Feature
Reporter: Mirko Steinle
Assignee: Carlos Sanchez

 Hello!
 JDom has released a major version (1.1) last november. Could you please 
 upload it?
 All files can be found at http://www.jdom.org/
 Thank you very much.
 Mirko
 P.S. I am only a user of JDom, but I guess the team won't have anything 
 against seeing their latest release uploaded...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3550) Support more prerequisites like compiler version

2008-05-14 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=134884#action_134884
 ] 

Paul Benedict commented on MNG-3550:


How is this feature affected by the introduction of tool chains (specifies 
version compiler) or the enforcer plugin? It seems there is definite overlap 
here.

 Support more prerequisites like compiler version
 

 Key: MNG-3550
 URL: http://jira.codehaus.org/browse/MNG-3550
 Project: Maven 2
  Issue Type: Improvement
  Components: POM
Reporter: Vincent Siveton
Priority: Minor
 Fix For: 2.1-alpha-1


 It should be useful if the prerequisites/ tag could support more 
 informations than the maven version. I could imagine something like:
 {noformat}
 project
 ...
   prerequisites
 maven2.0.6/maven
 compiler1.5/compiler
 memory512m/memory
 diskSpace100m/diskSpace
   /prerequisites
 ...
 /project
 {noformat}
 See the concrete use case in the Maven Plugin Plugin report:
 http://maven.apache.org/plugins/maven-plugin-plugin/plugin-info.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3550) Support more prerequisites like compiler version

2008-05-15 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=134954#action_134954
 ] 

Paul Benedict commented on MNG-3550:


Mark as WONTFIX?

 Support more prerequisites like compiler version
 

 Key: MNG-3550
 URL: http://jira.codehaus.org/browse/MNG-3550
 Project: Maven 2
  Issue Type: Improvement
  Components: POM
Reporter: Vincent Siveton
Priority: Minor
 Fix For: 2.1-alpha-1


 It should be useful if the prerequisites/ tag could support more 
 informations than the maven version. I could imagine something like:
 {noformat}
 project
 ...
   prerequisites
 maven2.0.6/maven
 compiler1.5/compiler
 memory512m/memory
 diskSpace100m/diskSpace
   /prerequisites
 ...
 /project
 {noformat}
 See the concrete use case in the Maven Plugin Plugin report:
 http://maven.apache.org/plugins/maven-plugin-plugin/plugin-info.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3550) Support more prerequisites like compiler version

2008-05-15 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=134965#action_134965
 ] 

Paul Benedict commented on MNG-3550:


Vincent, I think the answer would be ToolChains.

 Support more prerequisites like compiler version
 

 Key: MNG-3550
 URL: http://jira.codehaus.org/browse/MNG-3550
 Project: Maven 2
  Issue Type: Improvement
  Components: POM
Reporter: Vincent Siveton
Priority: Minor
 Fix For: 2.1-alpha-1


 It should be useful if the prerequisites/ tag could support more 
 informations than the maven version. I could imagine something like:
 {noformat}
 project
 ...
   prerequisites
 maven2.0.6/maven
 compiler1.5/compiler
 memory512m/memory
 diskSpace100m/diskSpace
   /prerequisites
 ...
 /project
 {noformat}
 See the concrete use case in the Maven Plugin Plugin report:
 http://maven.apache.org/plugins/maven-plugin-plugin/plugin-info.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3571) Allow use of ! when deactivating profiles

2008-05-16 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=135146#action_135146
 ] 

Paul Benedict commented on MNG-3571:


So which is it? MNG-3545 comments say it is plus and minus. This issue says 
exclamation mark.

 Allow use of ! when deactivating profiles
 -

 Key: MNG-3571
 URL: http://jira.codehaus.org/browse/MNG-3571
 Project: Maven 2
  Issue Type: Improvement
  Components: Command Line
Reporter: Paul Gier
Assignee: Paul Gier
Priority: Minor
 Fix For: 2.0.10, 2.1-alpha-1


 The current syntax for deactivating a profile from the command line is:
 {{mvn -P-myProfile}}
 It would be more intuitive if the exclamation point could be used in addition 
 to the dash.
 {{mvn -P!myProfile}}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MENFORCER-39) Allow simplified range checking

2008-05-16 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MENFORCER-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=135170#action_135170
 ] 

Paul Benedict commented on MENFORCER-39:


Any reason why you don't want to simplify it? I must admit, [1.0.0,) is just an 
elongated way of specifying a version number in a natural fashion.

 Allow simplified range checking
 ---

 Key: MENFORCER-39
 URL: http://jira.codehaus.org/browse/MENFORCER-39
 Project: Maven 2.x Enforcer Plugin
  Issue Type: Improvement
  Components: Standard Rules
Affects Versions: 1.0-alpha-3, 1.0
Reporter: Paul Benedict
Assignee: Brian Fox
Priority: Minor

 The rule [1.0.0,) means at least 1.0.0 inclusive and anything greater. The 
 comma should be optional for single-value ranges. It can be inferred simply 
 from the brackets and braces what the intention is. So [1.0.0) should also 
 be a valid version range.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3571) Allow use of ! when deactivating profiles

2008-05-18 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=135299#action_135299
 ] 

Paul Benedict commented on MNG-3571:


Was there also a commit to update any documentation using the 
exclamation/plus/minus syntax?

 Allow use of ! when deactivating profiles
 -

 Key: MNG-3571
 URL: http://jira.codehaus.org/browse/MNG-3571
 Project: Maven 2
  Issue Type: Improvement
  Components: Command Line
Reporter: Paul Gier
Assignee: Paul Gier
Priority: Minor
 Fix For: 2.0.10, 2.1-alpha-1


 The current syntax for deactivating a profile from the command line is:
 {{mvn -P-myProfile}}
 It would be more intuitive if the exclamation point could be used in addition 
 to the dash.
 {{mvn -P!myProfile}}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3598) trivial patch to enable custom depepndeny resolution mechanism

2008-05-28 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=136555#action_136555
 ] 

Paul Benedict commented on MNG-3598:


Unless you actually want those methods overridden (have a particular use case 
in mind?), they should be marked as final.

 trivial patch to enable custom depepndeny resolution mechanism
 --

 Key: MNG-3598
 URL: http://jira.codehaus.org/browse/MNG-3598
 Project: Maven 2
  Issue Type: Improvement
Affects Versions: 2.1
Reporter: Igor Fedorenko
Assignee: Jason van Zyl
 Attachments: tychohacks.diff


 In order to make OSGi dependency information available during maven build, 
 Tyhco needs a way to participate in how Maven reads and resolves project 
 dependencies. Maven 2.1 almost provides this capabilities, except for 
 unfortunate private modifier. Attached is a trivial patch that allows 
 subclasses override relevant methods.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3368) Printing version (-v argument) should not stop lifecycle execution

2008-06-25 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=139604#action_139604
 ] 

Paul Benedict commented on MNG-3368:


I would be satisfied with -showversion, if Maven developers must keep the 
current semantics of -version

 Printing version (-v argument) should not stop lifecycle execution
 --

 Key: MNG-3368
 URL: http://jira.codehaus.org/browse/MNG-3368
 Project: Maven 2
  Issue Type: Bug
  Components: Bootstrap  Build, Command Line
Affects Versions: 2.0.8
Reporter: Paul Benedict
Assignee: John Casey
 Fix For: 2.0.10


 I wanted to always print the Maven version when I build, but unfortunately 
 Maven immediately quits after outputting the version. This option should not 
 quit when a lifecycle is also specified. Example: mvn -v install

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-2562) expose current time as a property for POM interpolation

2008-06-25 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=139612#action_139612
 ] 

Paul Benedict commented on MNG-2562:


If this is fixed, can someone comment on the resolution? What was chosen?

 expose current time as a property for POM interpolation
 ---

 Key: MNG-2562
 URL: http://jira.codehaus.org/browse/MNG-2562
 Project: Maven 2
  Issue Type: New Feature
  Components: Inheritance and Interpolation
Reporter: Brett Porter
Assignee: John Casey
 Fix For: 2.0.10


 it is useful to have the current time, for example to write out a manifest 
 entry for the build time or to filter into another file.
 I'm not sure of the best way to make the format of the time configurable - 
 perhaps another POM element/property.
 See the related issue for a current example of how this can be done, but it 
 would be nice to have a built-in.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3566) Phase prepare-package not available

2008-06-28 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=139897#action_139897
 ] 

Paul Benedict commented on MNG-3566:


+1 with Wendy's comment. Also, I find it extreme for Maven to add lifecycle 
phases within a point release. Are we sure that's what we want to do? 

 Phase prepare-package not available
 ---

 Key: MNG-3566
 URL: http://jira.codehaus.org/browse/MNG-3566
 Project: Maven 2
  Issue Type: Bug
  Components: Plugins and Lifecycle
Affects Versions: 2.0.9
Reporter: Joerg Schaible
 Fix For: 2.0.10


 The default lifecycle contains a phase prepare-package (according to 
 http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html).
  This is not available for M209, the component.xml in maven-core misses this 
 phase for the 2.0.x series.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MCLEAN-34) NPE when forcing delete of directory

2008-06-30 Thread Paul Benedict (JIRA)

NPE when forcing delete of directory


 Key: MCLEAN-34
 URL: http://jira.codehaus.org/browse/MCLEAN-34
 Project: Maven 2.x Clean Plugin
  Issue Type: Bug
Affects Versions: 2.2
 Environment: Maven 2.0.9, JDK 1.6.05
Reporter: Paul Benedict


I ran clean site:site and ended up with this error.

[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] null
[INFO] 
[INFO] Trace
java.lang.NullPointerException
at 
org.codehaus.plexus.util.FileUtils.cleanDirectory(FileUtils.java:1263)
at 
org.codehaus.plexus.util.FileUtils.deleteDirectory(FileUtils.java:1224)
at org.codehaus.plexus.util.FileUtils.forceDelete(FileUtils.java:1087)
at 
org.apache.maven.shared.model.fileset.util.FileSetManager.delete(FileSetManager.java:618)
at 
org.apache.maven.shared.model.fileset.util.FileSetManager.removeDir(FileSetManager.java:594)
at 
org.apache.maven.shared.model.fileset.util.FileSetManager.removeDir(FileSetManager.java:574)
at 
org.apache.maven.shared.model.fileset.util.FileSetManager.removeDir(FileSetManager.java:574)
at 
org.apache.maven.shared.model.fileset.util.FileSetManager.removeDir(FileSetManager.java:574)
at 
org.apache.maven.shared.model.fileset.util.FileSetManager.removeDir(FileSetManager.java:574)
at 
org.apache.maven.shared.model.fileset.util.FileSetManager.removeDir(FileSetManager.java:574)
at 
org.apache.maven.shared.model.fileset.util.FileSetManager.removeDir(FileSetManager.java:574)
at 
org.apache.maven.shared.model.fileset.util.FileSetManager.removeDir(FileSetManager.java:574)
at 
org.apache.maven.shared.model.fileset.util.FileSetManager.delete(FileSetManager.java:309)
at 
org.apache.maven.plugin.clean.CleanMojo.removeDirectory(CleanMojo.java:261)
at org.apache.maven.plugin.clean.CleanMojo.execute(CleanMojo.java:173)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
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] 
[INFO] Total time: 20 seconds
[INFO] Finished at: Mon Jun 30 22:00:11 CDT 2008
[INFO] Final Memory: 4M/9M
[INFO] 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3511) Review fix for MNG-2166

2008-07-08 Thread Paul Benedict (JIRA)

[
http://jira.codehaus.org/browse/MNG-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=141161#action_141161
]

Paul Benedict commented on MNG-3511:

Is the output in a message resource so it can be localized?

Review fix for MNG-2166
---

Key: MNG-3511
URL: http://jira.codehaus.org/browse/MNG-3511
Project: Maven 2
Issue Type: Improvement
Components: Command Line
Affects Versions: 2.0.8
Reporter: Benjamin Bentmann
Assignee: John Casey
Priority: Minor
Fix For: 2.0.10, 2.1-alpha-1

Attachments: no-goal-help.patch

As requested by Brett in MNG-3276, here a new issue. My relevant comment over
at the other issue:
I still consider the output from Maven quite unhelpful in this case. Please
consider that Maven is just a tool/utility for developers and hence not
everybody out there will spend time to get through the documentation. Some
peoply simply want to use Maven, not understand how it works.
The Ant scripts that I am trying to replace in our organization all provided
some help about the current project and the available targets using the echo
task when the default target was executed. This allowed newbies to quickly
figure out how to perform build steps without ever reading the Ant manual.
Surely, once you know Maven's lifecycle you never need such help targets but
especially old Ant geeks need some easy way of migrating into Maven land.
The attached patch should provide the following console output:
{noformat}
[INFO] Scanning for projects...
[INFO]

[ERROR] BUILD FAILURE
[INFO]

[INFO]
You must specify at least one goal or lifecycle phase to perform build steps.
The following list illustrates some commonly used build commands:
mvn clean
Deletes any build output (e.g. class files or JARs).
mvn test
Runs the unit tests for the project.
mvn install
Copies the project artifacts into your local repository.
mvn deploy
Copies the project artifacts into the remote repository.
mvn site
Creates project documentation (e.g. reports or Javadoc).
Please see
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
for a complete description of available lifecycle phases.
Use mvn -? to show general usage information about Maven's command line.
[INFO]

[INFO] For more information, run Maven with the -e switch
[INFO]

[INFO] Total time: 1 second
[INFO] Finished at: Mon Oct 22 20:48:42 EDT 2007
[INFO] Final Memory: 1M/4M
[INFO]

{noformat}
This output is intended to show further comon use-cases than just install.
Besides, the user is pointed to a concrete URL with helpful information for
his actual need (personally, I consider pointing people at home pages as
helpful as telling to use Google... information should be found, not searched)

[jira] Commented: (MNG-3673) Upgrade plugin versions in super-POM where appropriate

2008-07-22 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=142793#action_142793
 ] 

Paul Benedict commented on MNG-3673:


Should the maven-shade-plugin get a standard version? It sounds reasonable, 
imo, based on how critical it is to Maven itself.

 Upgrade plugin versions in super-POM where appropriate
 --

 Key: MNG-3673
 URL: http://jira.codehaus.org/browse/MNG-3673
 Project: Maven 2
  Issue Type: Improvement
  Components: Plugins and Lifecycle
Affects Versions: 2.0.10
Reporter: John Casey
Assignee: John Casey
 Fix For: 2.0.10


 Use this issue to record which plugins were changed, and which version was 
 used for each.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-2739) Repository entries are not validated and NPE will occur

2008-07-27 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=143243#action_143243
 ] 

Paul Benedict commented on MNG-2739:


My first question is whether id and url are required elements? If so, why 
isn't the pull parser validating the syntax?

 Repository entries are not validated and NPE will occur
 ---

 Key: MNG-2739
 URL: http://jira.codehaus.org/browse/MNG-2739
 Project: Maven 2
  Issue Type: Bug
  Components: Artifacts and Repositories
Reporter: Jason van Zyl
Assignee: John Casey
 Fix For: 2.0.10, 2.1-alpha-1


 Using something like the following has no id and an incorrect file url:
 profile
   idcbuilds/id
   repositories
 repository
   
 url/Users/jvanzyl/js/org/codehaus/mojo/trunk/mojo/mojo-sandbox/c-builds/test-cpkg/m2-repo/url
 /repository
   /repositories
 /profile
 java.lang.NullPointerException
 at 
 org.apache.maven.wagon.repository.Repository.hashCode(Repository.java:239)
 at java.util.HashMap.hash(HashMap.java:264)
 at java.util.HashMap.put(HashMap.java:382)
 at java.util.HashSet.add(HashSet.java:194)
 at 
 org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:665)
 at 
 org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:416)
 at 
 org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:192)
 at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515)
 at 
 org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447)
 at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
 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: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)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MSITE-346) Allow site.xml to be optional

2008-07-31 Thread Paul Benedict (JIRA)

Allow site.xml to be optional
-

 Key: MSITE-346
 URL: http://jira.codehaus.org/browse/MSITE-346
 Project: Maven 2.x Site Plugin
  Issue Type: Improvement
Reporter: Paul Benedict


I want to use the Maven Site Plugin to produce, package, and deploy a typical 
Apache-hosted website. I do not need any content generation or skinning. 
Everything that I need would reside in /src/main/resources.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MECLIPSE-475) Container mispelling

2008-08-05 Thread Paul Benedict (JIRA)

Container mispelling


 Key: MECLIPSE-475
 URL: http://jira.codehaus.org/browse/MECLIPSE-475
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
  Components: Core : Workspace settings
Affects Versions: 2.5
Reporter: Paul Benedict
Priority: Trivial


[INFO] [eclipse:eclipse]
[INFO] Not running eclipse plugin goal for pom project
[INFO] Using as WTP server : null
[INFO] Adding default classpath contaigner: 
org.eclipse.jdt.launching.JRE_CONTAINER

Container has a 'g' in it!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-553) Secure Storage of Server Passwords

2008-08-15 Thread Paul Benedict (JIRA)

[
http://jira.codehaus.org/browse/MNG-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=145141#action_145141
]

Paul Benedict commented on MNG-553:
---

I think we should go for the full kitchen sink solution. We shouldn't invite
something new, but should provide adapters to datastores. Just do what Spring
(Acegi) Security did, which is provide a simple API to be implemented by anyone
who wants to write in a provider NT authentication, LDAP, DB2, etc.

Secure Storage of Server Passwords
--

Key: MNG-553
URL: http://jira.codehaus.org/browse/MNG-553
Project: Maven 2
Issue Type: Improvement
Components: Settings
Affects Versions: 2.0-alpha-3
Environment: Although it may not be relevant since this is a general
improvement issue, Windows XP, JDK 1.4.1.
Reporter: J. Michael McGarr
Assignee: Brett Porter
Priority: Critical
Fix For: 3.0

This was a question pose to the Maven User's Group and it was suggested I add
it here.
It would be benefitial to provide a more secure means of storing password's
to the servers listed in the .m2/settings.xml. They are currently being
stored as plain text and could definately be considered a security breach.
Numerous organizations would undoubtedly considered this an unacceptable
security risk, and this could prevent widespread adoption of Maven2.
I would suggest leaving an option to encrypt the password into the settings
file (more secure, but not foolproof) or even requiring the password to be
manually provided per build (would prevent automation of builds). I am sure
that there is a secure solution to this problem and it should be part of the
2.0 release.

[jira] Issue Comment Edited: (MNG-553) Secure Storage of Server Passwords

2008-08-15 Thread Paul Benedict (JIRA)

[
http://jira.codehaus.org/browse/MNG-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=145141#action_145141
]

paul4christ79 edited comment on MNG-553 at 8/15/08 5:45 AM:

I think we should go for the full kitchen sink solution. We shouldn't invent
something new, but should provide adapters to datastores. Just do what Spring
(Acegi) Security did, which is provide a simple API to be implemented by anyone
who wants to write in a provider NT authentication, LDAP, DB2, etc.

was (Author: paul4christ79):
I think we should go for the full kitchen sink solution. We shouldn't
invite something new, but should provide adapters to datastores. Just do what
Spring (Acegi) Security did, which is provide a simple API to be implemented by
anyone who wants to write in a provider NT authentication, LDAP, DB2, etc.

Secure Storage of Server Passwords
--

[jira] Commented: (MNG-1832) built-in property containing current timestamp

2008-08-20 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=145596#action_145596
 ] 

Paul Benedict commented on MNG-1832:


See MNG-3718 on how it was implemented.

 built-in property containing current timestamp
 --

 Key: MNG-1832
 URL: http://jira.codehaus.org/browse/MNG-1832
 Project: Maven 2
  Issue Type: New Feature
Affects Versions: 2.0.1
Reporter: Michal Stochmialek
 Attachments: maven-archiver_pomDelete.patch, 
 maven-core_defaultExpressions.patch


 Current timestamp (time or date) is often used while filtering resources or 
 creating manifest in ant builds. There is no equivalent in maven.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MNG-3723) ${project.basedir} is not interpolated

2008-08-21 Thread Paul Benedict (JIRA)

${project.basedir} is not interpolated
--

 Key: MNG-3723
 URL: http://jira.codehaus.org/browse/MNG-3723
 Project: Maven 2
  Issue Type: Bug
  Components: Inheritance and Interpolation
Affects Versions: 2.0.10
 Environment: Maven 2.0.10-RC8, JDK 1.6.0._06, maven-eclipse-plugin 2.4
Reporter: Paul Benedict
Priority: Critical


Here is what I did. I do not know if all the steps are necessary to reproduce 
the bug, but the bug is reproducible:

1. Check out a multi-level project
2. Install the parent with -N
3. Go into one of the children projects and then run eclipse:eclipse
4. You will see a folder named ${project.basedir} when execution is finished.

Works fine in 2.0.9 and fails with 2.0.10. This is definitely a regression.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-1944) cyclic dependencies causes maven to not include all transitive dependencies

2008-08-21 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=145677#action_145677
 ] 

Paul Benedict commented on MNG-1944:


Can an option flag be set to fail the build on a cycle?

 cyclic dependencies causes maven to not include all transitive dependencies
 ---

 Key: MNG-1944
 URL: http://jira.codehaus.org/browse/MNG-1944
 Project: Maven 2
  Issue Type: Bug
  Components: POM
Affects Versions: 2.0.1
Reporter: Brian Fox
Priority: Critical
 Fix For: 3.0

 Attachments: MNG-1944.patch


 Try including dom4j 1.5.2 and see what dependencies are resolved. dom4j 
 depends on jaxen, which depends on dom4j. When maven sees the cyclic 
 dependency, it stops processing the jaxen dependency. This leaves everything 
 else jaxen depends on not included in the final artifact list. This is mvn -x 
 output:
  dom4j:dom4j:jar:1.5.2 (selected for compile)
 [DEBUG] stax:stax-api:jar:1.0 (selected for compile)
 [DEBUG] pull-parser:pull-parser:jar:2 (selected for compile)
 [DEBUG] jaxme:jaxme-api:jar:0.3 (selected for compile)
 [WARNING]
   This artifact has been relocated to xml-apis:xml-apis:1.0.b2.
 [DEBUG] xml-apis:xml-apis:jar:1.0.b2 (selected for compile)
 [DEBUG] msv:xsdlib:jar:20030807 (selected for compile)
 [DEBUG] xpp3:xpp3:jar:1.1.3.3 (selected for compile)
 [DEBUG] dom4j:dom4j:jar:1.5.2 (removed - causes a cycle in the
 graph)
 [DEBUG] jaxen:jaxen:jar:1.1-beta-4 (selected for compile)
 [DEBUG] msv:relaxngDatatype:jar:20030807 (selected for compile)
 Notice that xerces and xom and everything else jaxen depends on isn't 
 included.
 Taking dom4j out of the jaxen pom locally causes everything to be included:
 [DEBUG] com.stchome.maven.mojo:helloUser:jar:1.0-SNAPSHOT (selected for null)
 [DEBUG]   dom4j:dom4j:jar:1.5.2 (selected for compile)
 [DEBUG] stax:stax-api:jar:1.0 (selected for compile)
 [DEBUG] pull-parser:pull-parser:jar:2 (selected for compile)
 [DEBUG] jaxme:jaxme-api:jar:0.3 (selected for compile)
 [WARNING] 
   This artifact has been relocated to xml-apis:xml-apis:1.0.b2.
 [DEBUG] xml-apis:xml-apis:jar:1.0.b2 (selected for compile)
 [DEBUG] msv:xsdlib:jar:20030807 (selected for compile)
 [DEBUG] xpp3:xpp3:jar:1.1.3.3 (selected for compile)
 [DEBUG] jaxen:jaxen:jar:1.1-beta-4 (selected for compile)
 [DEBUG]   jdom:jdom:jar:b10 (selected for compile)
 [DEBUG]   xom:xom:jar:1.0b3 (selected for compile)
 [DEBUG] xerces:xmlParserAPIs:jar:2.6.1 (selected for compile)
 [DEBUG] xerces:xercesImpl:jar:2.2.1 (selected for compile)
 [DEBUG] xalan:xalan:jar:2.6.0 (selected for compile)
 [WARNING] 
   This artifact has been relocated to xml-apis:xml-apis:1.0.b2.
 [DEBUG]   xml-apis:xml-apis:jar:1.0.b2 (selected for compile)
 [WARNING] 
   This artifact has been relocated to com.ibm.icu:icu4j:2.6.1.
 [DEBUG] com.ibm.icu:icu4j:jar:2.6.1 (selected for compile)
 [WARNING] 
   This artifact has been relocated to javax.servlet:servlet-api:2.4.
 [DEBUG] javax.servlet:servlet-api:jar:2.4 (selected for compile)
 [WARNING] 
   This artifact has been relocated to org.ccil.cowan.tagsoup:tagsoup:0.9.7.
 [DEBUG] org.ccil.cowan.tagsoup:tagsoup:jar:0.9.7 (selected for 
 compile)
 [DEBUG]   xerces:xmlParserAPIs:jar:2.6.1 (removed - nearer found: 2.6.2)
 [DEBUG]   xerces:xmlParserAPIs:jar:2.6.2 (selected for compile)
 [DEBUG]   xerces:xercesImpl:jar:2.2.1 (removed - nearer found: 2.6.2)
 [DEBUG]   xerces:xercesImpl:jar:2.6.2 (selected for compile)
 [DEBUG] msv:relaxngDatatype:jar:20030807 (selected for compile)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-2576) Make Like Reactor Mode

2008-08-22 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=145786#action_145786
 ] 

Paul Benedict commented on MNG-2576:


To be inline with the issue management that marks issues for branch/head as 
2.0.x and 2.1.x, is this something that is also being slated for 3.0? If so, 
please add the version.

 Make Like Reactor Mode
 --

 Key: MNG-2576
 URL: http://jira.codehaus.org/browse/MNG-2576
 Project: Maven 2
  Issue Type: New Feature
  Components: Command Line, Reactor and workspace
Reporter: Kenney Westerhof
Assignee: Dan Fabulich
 Fix For: 2.1.0


 Add a commandline option to enable maven to expand the reactor scope to find 
 projects that are dependencies
 of the projects currently in the reactor, and add them.
 Currently only the current project and child projects are included in the 
 reactor search. I'm proposing
 to add a commandline switch that lets maven check parent directories to find 
 the root of the project tree,
 and then do a normal reactor scan, only adding projects that would normally 
 not be added if they're needed
 as dependencies of the projects that would normally be built.
 Here's a sample project tree:
 * root
 ** p1
 *** c1 (depends on p2)
 ** p2 (depends on c2)
 ** p3
 *** c2
 And a sample algorithm:
 - When building c1, the reactor would contain [c1].
 - Maven would check p1, then root, etc, using the parent tags (without the 
 versions!)
   to see if the project is still in the current reactor.
 - It would then create a second list of projects (reactor2) containing ALL 
 projects, using the newly discovered root: [root, p1, c2, p2].
 - remove all projects from reactor2 contained in reactor: reactor2 = [root, 
 p1, p2]
 - resolve all direct dependencies for all projects in reactor in reactor2 and 
 add them to reactor, taking versions into account: reactor = [p2, c1]
 - repeat previous step until all projects have their dependencies resolved 
 from reactor 2. first iteration would yield reactor = [c2, p2, c1],
   next iteration would stop since c1 doesn't have any dependencies present in 
 reactor2.
 This would ensure that when some local project's sources have changed, 
 they'll be incorporated
 in the build, regardless of where you build. So you don't have to do a 
 reactor build each time you change more
 than 1 project, and you don't have to remember which projects you changed and 
 build them in the correct order
 yourself, manually.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MNG-3586) jaxws mojo wsgen failure with maven 3.0

2008-08-24 Thread Paul Benedict (JIRA)


 [ 
http://jira.codehaus.org/browse/MNG-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-3586:
---

Summary: jaxws mojo wsgen failure with maven 3.0  (was: jaxws mojo wsgen 
failure with maven 2.1 )

 jaxws mojo wsgen failure with maven 3.0
 ---

 Key: MNG-3586
 URL: http://jira.codehaus.org/browse/MNG-3586
 Project: Maven 2
  Issue Type: Bug
  Components: Embedding
Affects Versions: 3.0
 Environment: Windows XP / Java 5 or 6
Reporter: Henri Gomez
Assignee: Brett Porter
 Fix For: 3.0-alpha-1

 Attachments: pom.xml, sample-wsgen-fixed.zip, sample-wsgen.zip


 I can build jar projects using the jaxws wsgen mojo (1.9) under maven
 2.0.x but it failed under m2eclipse (0.9.3) when using maven 2.1
 embedded (it works if I switch m2eclipse to use the maven 2.0.9 on my
 system).
 I tried with various JVM (Sun and IBM 5 and 6) but still got the
 problem with maven 2.1 embedded (maven 2.1-620417 and 2.1-655675):
 error is :
 From file: C:\workspace\xxx-er-go\pom.xml
 Reason: Failed to execute wsgen
 java.lang.NoClassDefFoundError: com/sun/mirror/apt/AnnotationProcessorFactory
   at java.lang.ClassLoader.defineClass1(Native Method)
   at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
   at 
 java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
   at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
   at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
   at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
   at 
 org.codehaus.plexus.classworlds.realm.ClassRealm.loadRealmClass(ClassRealm.java:174)
   at 
 org.codehaus.plexus.classworlds.strategy.DefaultStrategy.loadClass(DefaultStrategy.java:67)
   at 
 org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:201)
   at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
   at com.sun.tools.ws.WsGen.doMain(WsGen.java:69)
   at 
 org.codehaus.mojo.jaxws.AbstractWsGenMojo.execute(AbstractWsGenMojo.java:91)
   at org.codehaus.mojo.jaxws.MainWsGenMojo.execute(MainWsGenMojo.java:14)
   at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:577)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149)
   at 
 org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223)
   at 
 org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1)
   at 
 org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:903)
   at 
 org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304)
   at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1)
   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:63)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:52)
 Any idea or fixes ?
 my pom.xml wsgen is standard :
   build
   plugins
   plugin
   artifactIdmaven-compiler-plugin/artifactId
   configuration
   source1.5/source
   target1.5/target
   /configuration
   executions
   execution
   idcompile/id
   goals
   goalcompile/goal
   /goals
   phaseinitialize/phase
   /execution
   /executions
   /plugin
   !-- We need JAX-WS support for Annotation processing 
 --
   !-- NB: wsgen can handle only one SEI at a
 time so we define an
 execution by SEI

[jira] Commented: (MNG-3724) ExecutionProject not getting updated compile/test-compile/script roots in RC10

2008-08-25 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=145886#action_145886
 ] 

Paul Benedict commented on MNG-3724:


Is this issue missing a Fix Version of 2.0.10?

 ExecutionProject not getting updated compile/test-compile/script roots in RC10
 --

 Key: MNG-3724
 URL: http://jira.codehaus.org/browse/MNG-3724
 Project: Maven 2
  Issue Type: Bug
Affects Versions: 2.0.10
Reporter: John Casey
Assignee: John Casey



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MNG-3683) [regression] Help plugin does not work

2008-08-25 Thread Paul Benedict (JIRA)


 [ 
http://jira.codehaus.org/browse/MNG-3683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-3683:
---

Summary: [regression] Help plugin does not work  (was: help plugin does not 
work under Maven 2.1)

 [regression] Help plugin does not work
 --

 Key: MNG-3683
 URL: http://jira.codehaus.org/browse/MNG-3683
 Project: Maven 2
  Issue Type: Bug
  Components: Plugin Requests
Affects Versions: 3.0-alpha-1
Reporter: Brett Porter
 Fix For: 3.0-alpha-1


 The following command:
 mvn help:describe -Dplugin=site
 Gives the error:
 [ERROR] 
 Maven encountered an error while configuring one of the mojos for your build.
 Mojo:
 Group-Id: org.apache.maven.plugins
 Artifact-Id: maven-help-plugin
 Version: 2.0.2
 Mojo: describe
 brought in via: Direct invocation
 While building project:
 Group-Id: org.apache.continuum
 Artifact-Id: continuum-docs
 Version: 1.2-SNAPSHOT
 From file: /Users/brett/scm/continuum/continuum/continuum-docs/pom.xml
 Here is the configuration it attempted to apply to the mojo:configuration
   artifactId${artifactId}/artifactId
   full${full}/full
   groupId${groupId}/groupId
   localRepository${localRepository}/localRepository
   medium${medium}/medium
   mojo${mojo}/mojo
   output${output}/output
   plugin${plugin}/plugin
   project${project}/project
   session${session}/session
   settings${settings}/settings
   version${version}/version
 /configuration
 Error 
 message:org.codehaus.plexus.component.configurator.ComponentConfigurationException:
  Invalid parameter supplied while setting '[EMAIL PROTECTED]' to 
 org.apache.maven.plugins.help.DescribeMojo.setMojo( java.lang.Class )

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MNG-3686) [regression] Can't build Wagon webdav provider

2008-08-25 Thread Paul Benedict (JIRA)


 [ 
http://jira.codehaus.org/browse/MNG-3686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-3686:
---

Summary: [regression] Can't build Wagon webdav provider  (was: [regression] 
can't build Wagon webdav provider with Maven 2.1)

 [regression] Can't build Wagon webdav provider
 --

 Key: MNG-3686
 URL: http://jira.codehaus.org/browse/MNG-3686
 Project: Maven 2
  Issue Type: Bug
Affects Versions: 3.0-alpha-1
Reporter: Brett Porter
 Fix For: 3.0-alpha-1


 Wagon trunk r680097 fails to build in the webdav module when built with mvn 
 -Dmaven.test.skip=true from the top level due to:
 Exception in thread main java.lang.NoClassDefFoundError: 
 org/apache/commons/httpclient/methods/RequestEntity
   at java.lang.Class.getDeclaredConstructors0(Native Method)
   at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357)
   at java.lang.Class.getConstructors(Class.java:1446)
   at 
 com.thoughtworks.qdox.JavaDocBuilder.createBinaryClass(JavaDocBuilder.java:183)
   at 
 com.thoughtworks.qdox.JavaDocBuilder.getClassByName(JavaDocBuilder.java:119)
   at 
 com.thoughtworks.qdox.model.ClassLibrary.getClassByName(ClassLibrary.java:37)
   at com.thoughtworks.qdox.model.Type.getJavaClass(Type.java:98)
   at 
 com.thoughtworks.qdox.model.JavaClass.getSuperJavaClass(JavaClass.java:86)
   at 
 org.codehaus.plexus.cdc.gleaner.QDoxComponentGleaner.findRequirements(QDoxComponentGleaner.java:343)
   at 
 org.codehaus.plexus.cdc.gleaner.QDoxComponentGleaner.glean(QDoxComponentGleaner.java:193)
   at 
 org.codehaus.plexus.maven.plugin.SourceComponentDescriptorExtractor.extract(SourceComponentDescriptorExtractor.java:100)
   at 
 org.codehaus.plexus.maven.plugin.SourceComponentDescriptorExtractor.extract(SourceComponentDescriptorExtractor.java:74)
   at 
 org.codehaus.plexus.maven.plugin.AbstractDescriptorMojo.generateDescriptor(AbstractDescriptorMojo.java:131)
   at 
 org.codehaus.plexus.maven.plugin.PlexusDescriptorMojo.execute(PlexusDescriptorMojo.java:60)
   at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:638)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:521)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:288)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:214)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:172)
   at 
 org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223)
   at 
 org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:303)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1)
   at 
 org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:904)
   at 
 org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:303)
   at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1)
   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:63)
   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:585)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408)
   at 
 org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MNG-3663) IT 0088 failing on Windows

2008-08-25 Thread Paul Benedict (JIRA)


 [ 
http://jira.codehaus.org/browse/MNG-3663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-3663:
---

Summary: IT 0088 failing on Windows  (was: IT 0088 failing for Maven 
2.1-SNAPSHOT on Windows)

 IT 0088 failing on Windows
 --

 Key: MNG-3663
 URL: http://jira.codehaus.org/browse/MNG-3663
 Project: Maven 2
  Issue Type: Bug
  Components: IT Failures
Affects Versions: 3.0-alpha-1
 Environment: Windows, Maven 2.1-SNAPSHOT
Reporter: Benjamin Bentmann
Priority: Minor
 Fix For: 3.0-alpha-1

 Attachments: org.apache.maven.it0088.PomInterpolationTest.txt, 
 test.properties


 Running the [Hudson 
 bundle|http://www.nabble.com/Re%3A-Community-Help-with-Maven-ITs-p18415443.html]
  on Windows delivers:
 {noformat}
 Tests in error: 
   
 testitMNG3380(org.apache.maven.integrationtests.MavenITmng3380ManagedRelocatedTransdepsTest)
   testit0088(org.apache.maven.integrationtests.MavenIT0088Test)
 Tests run: 166, Failures: 0, Errors: 2, Skipped: 0
 {noformat}
 As the attached test results show, the interpolation of 
 {{${project.build.directory}}} does not return a path with normalized file 
 separators.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MNG-3366) Site generation is totally messed up

2008-08-25 Thread Paul Benedict (JIRA)


 [ 
http://jira.codehaus.org/browse/MNG-3366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-3366:
---

Summary: Site generation is totally messed up  (was: site generation in 2.1 
is totally messed up)

 Site generation is totally messed up
 

 Key: MNG-3366
 URL: http://jira.codehaus.org/browse/MNG-3366
 Project: Maven 2
  Issue Type: Bug
  Components: Sites  Reporting
Affects Versions: 3.0-alpha-1
Reporter: Brian Fox
 Fix For: 3.0-alpha-1


 I tried generating the enforcer site with 2.1 and i get essentially empty 
 pages after lots of warning.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MNG-2878) [regression] NPE when running Checkstyle

2008-08-25 Thread Paul Benedict (JIRA)


 [ 
http://jira.codehaus.org/browse/MNG-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-2878:
---

Summary: [regression] NPE when running Checkstyle  (was: NPE when run with 
Maven 2.1-SNAPSHOT)

 [regression] NPE when running Checkstyle
 

 Key: MNG-2878
 URL: http://jira.codehaus.org/browse/MNG-2878
 Project: Maven 2
  Issue Type: Bug
  Components: Sites  Reporting
Affects Versions: 3.0-alpha-1
 Environment: Maven 2.1 built from trunk on 15 March 2007, 10:00AM
 Checkstyle plugin built from trunk on 15 March 2007, 11:20
Reporter: Vincent Massol
Assignee: John Casey
 Fix For: 3.0-alpha-1


 I get:
 {code}
 [INFO] An error has occurred in Checkstyle report generation.
 [INFO] 
 
 [INFO] Trace
 org.apache.maven.lifecycle.LifecycleExecutionException: An error has occurred 
 in Checkstyle report generation.
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:524)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:862)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:699)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:470)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:440)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:419)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:271)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:238)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:146)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:303)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
 at 
 org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:907)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:369)
 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:585)
 at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
 at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
 at 
 org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408)
 at 
 org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
 Caused by: org.apache.maven.plugin.MojoExecutionException: An error has 
 occurred in Checkstyle report generation.
 at 
 org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:79)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:598)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:499)
 ... 20 more
 Caused by: java.lang.NullPointerException
 at java.io.Reader.init(Reader.java:61)
 at java.io.InputStreamReader.init(InputStreamReader.java:55)
 at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:248)
 at org.codehaus.plexus.util.IOUtil.toString(IOUtil.java:307)
 at org.codehaus.plexus.util.IOUtil.toString(IOUtil.java:295)
 at 
 org.apache.maven.reporting.AbstractMavenReport.getSiteDescriptor(AbstractMavenReport.java:134)
 at 
 org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:70)
 ... 22 more
 {code}
 The POM I used:
 {code}
   build
 plugins
   plugin
 !-- Apply the Checkstyle configurations defined in the top level 
 pom.xml file --
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-checkstyle-plugin/artifactId
 dependencies
   dependency
 groupIdcom.xpn.xwiki/groupId
 artifactIdxwiki-build-verifications/artifactId
 version1.0-SNAPSHOT/version
   /dependency
 /dependencies
 configuration
   includes
   **/Api.java,
   **/xmlrpc/Attachment.java,
   **/xmlrpc/SpaceSummary.java,
   **/ViewAction.java,
   **/ZipExplorer*.java,

[jira] Updated: (MNG-3219) Create a CLIRR/JarDiff setup for 2.0.x and 3.0.x

2008-08-25 Thread Paul Benedict (JIRA)


 [ 
http://jira.codehaus.org/browse/MNG-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-3219:
---

Summary: Create a CLIRR/JarDiff setup for 2.0.x and 3.0.x  (was: Create a 
CLIRR/JarDiff setup for 2.0.x and 2.1.x)

 Create a CLIRR/JarDiff setup for 2.0.x and 3.0.x
 

 Key: MNG-3219
 URL: http://jira.codehaus.org/browse/MNG-3219
 Project: Maven 2
  Issue Type: New Feature
  Components: Bootstrap  Build
Reporter: Jason van Zyl
Assignee: John Casey
 Fix For: 2.0.10, 3.0-alpha-1


 It may not only be for the core but also the plugin tools that have been 
 separated.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MNG-3281) Revisit backwards compat of extensions (IT 0114)

2008-08-25 Thread Paul Benedict (JIRA)


 [ 
http://jira.codehaus.org/browse/MNG-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-3281:
---

Summary: Revisit backwards compat of extensions (IT 0114)  (was: revisit 
backwards compat of extensions in 2.1 (IT 0114))

 Revisit backwards compat of extensions (IT 0114)
 

 Key: MNG-3281
 URL: http://jira.codehaus.org/browse/MNG-3281
 Project: Maven 2
  Issue Type: Bug
Affects Versions: 3.0-alpha-1
Reporter: Brett Porter
 Fix For: 3.0-alpha-1


 currently, it 0114 doesn't pass due to the removal of extension support
 we need to either:
 - restore some form of backwards compat by loading the extension into the 
 expected place
 - provide a graceful failure instead

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MWAR-167) Final manifest not written to exploded location

2008-09-01 Thread Paul Benedict (JIRA)

Final manifest not written to exploded location
---

 Key: MWAR-167
 URL: http://jira.codehaus.org/browse/MWAR-167
 Project: Maven 2.x War Plugin
  Issue Type: Bug
Affects Versions: 2.1-alpha-1
Reporter: Paul Benedict
Priority: Minor


When I open up my generated WAR file, the Manifest file contains all the 
entries I specified. This is correct. However, when I look into the exploded 
location, it's just the file I had in my project to begin with.

The exploded Manifest should be updated with the final contents.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MENFORCER-50) Version rule with dashes are not inspected correctly

2008-09-01 Thread Paul Benedict (JIRA)

Version rule with dashes are not inspected correctly


 Key: MENFORCER-50
 URL: http://jira.codehaus.org/browse/MENFORCER-50
 Project: Maven 2.x Enforcer Plugin
  Issue Type: Bug
  Components: Standard Rules
Affects Versions: 1.0-alpha-3
Reporter: Paul Benedict
Assignee: Brian Fox


I know it's possible to say [2.0,) for anything within the 2.0 series.

The same was not possible with the latest Maven 2.1 release:
[2.1.0-M1,) does not pass for version 2.1.0-M1-RC12

I should be accepting anything within the M1 build range. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3738) Maven Update Depenedency!

2008-09-02 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=146690#action_146690
 ] 

Paul Benedict commented on MNG-3738:


If possible, switch the resolution to INVALID so it doesn't show up in the JIRA 
release notes.

 Maven Update Depenedency!
 -

 Key: MNG-3738
 URL: http://jira.codehaus.org/browse/MNG-3738
 Project: Maven 2
  Issue Type: Task
  Components: Artifacts and Repositories
Affects Versions: 2.0.9
Reporter: prashant p
Assignee: Wendy Smoak
Priority: Blocker

 Hi ,
   We are facing issue with maven update dependency.When multiple depevlopers 
 run maven ,it takes hours of time in updating dependency from artifactory 
 located in remote.Is it because of  network issue causing this slow.I tried 
 to change nonProxyHostslocalhost/nonProxyHosts in setting.xml.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3738) Maven Update Depenedency!

2008-09-02 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=146724#action_146724
 ] 

Paul Benedict commented on MNG-3738:


I don't have access to change states. Sorry, I wish I did.

 Maven Update Depenedency!
 -

 Key: MNG-3738
 URL: http://jira.codehaus.org/browse/MNG-3738
 Project: Maven 2
  Issue Type: Task
  Components: Artifacts and Repositories
Affects Versions: 2.0.9
Reporter: prashant p
Assignee: Wendy Smoak
Priority: Blocker

 Hi ,
   We are facing issue with maven update dependency.When multiple depevlopers 
 run maven ,it takes hours of time in updating dependency from artifactory 
 located in remote.Is it because of  network issue causing this slow.I tried 
 to change nonProxyHostslocalhost/nonProxyHosts in setting.xml.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MENFORCER-50) Version rule with dashes are not inspected correctly

2008-09-03 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MENFORCER-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=146929#action_146929
 ] 

Paul Benedict commented on MENFORCER-50:


Why can't this be slated for an enhancement? Eventually, I am sure there will 
be an opportunity to fix this.

 Version rule with dashes are not inspected correctly
 

 Key: MENFORCER-50
 URL: http://jira.codehaus.org/browse/MENFORCER-50
 Project: Maven 2.x Enforcer Plugin
  Issue Type: Bug
  Components: Standard Rules
Affects Versions: 1.0-alpha-3
Reporter: Paul Benedict
Assignee: Brian Fox

 I know it's possible to say [2.0,) for anything within the 2.0 series.
 The same was not possible with the latest Maven 2.1 release:
 [2.1.0-M1,) does not pass for version 2.1.0-M1-RC12
 I should be accepting anything within the M1 build range. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3746) POM properties do not override default system properties during POM interpolation

2008-09-08 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=147368#action_147368
 ] 

Paul Benedict commented on MNG-3746:


I am not quite sure what the correct solution is. Obviously, properties like 
java.version are really important, and if they can be overridden, that might 
lead to some unpredictable expectations.

I'd rather Maven err if such properties like java.* exist. However, if it is 
pre-existing behavior, maybe it's worth continuing but I must admit I feel 
that my code was inappropriate to use that property namespace.

 POM properties do not override default system properties during POM 
 interpolation
 -

 Key: MNG-3746
 URL: http://jira.codehaus.org/browse/MNG-3746
 Project: Maven 2
  Issue Type: Bug
  Components: Inheritance and Interpolation
Affects Versions: 2.1.0-M1
Reporter: John Casey
Assignee: John Casey
Priority: Blocker
 Fix For: 2.1.0-M1


 From Paul Benedict, on the maven dev list:
 {noformat}
 My issue might be related to MNG-3535.
 I defined this property:
 java.version1.6/java.version
 And used it in my compiler plugin:
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-compiler-plugin/artifactId
   configuration
 source${java.version}/source
 target${java.version}/target
   /configuration
 /plugin
 I know this use to work before 2.0.10, but now it does not.
 [INFO] Compilation failure
 Failure executing javac, but could not parse the error:
 javac: invalid target release: 1.6.0_06
 Usage: javac options source files
 use -help for a list of possible options
 The error here is that ${java.version} is not the value I specified,
 but one that already exists.
 Paul
 {noformat}
 I've replicated the problem in a separate test mock-up project.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MAVENUPLOAD-1968) JDom 1.1 is out

2008-09-21 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=148665#action_148665
 ] 

Paul Benedict commented on MAVENUPLOAD-1968:


Is this going to proceed?

 JDom 1.1 is out
 ---

 Key: MAVENUPLOAD-1968
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1968
 Project: Maven Upload Requests
  Issue Type: New Feature
Reporter: Mirko Steinle
Assignee: Carlos Sanchez
 Attachments: jdom-1.1-bundle.jar, pom-relocation.xml


 Hello!
 JDom has released a major version (1.1) last november. Could you please 
 upload it?
 All files can be found at http://www.jdom.org/
 Thank you very much.
 Mirko
 P.S. I am only a user of JDom, but I guess the team won't have anything 
 against seeing their latest release uploaded...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MSITE-645) Menu no longer accepts href attribute

2012-06-22 Thread Paul Benedict (JIRA)

Paul Benedict created MSITE-645:
---

 Summary: Menu no longer accepts href attribute
 Key: MSITE-645
 URL: https://jira.codehaus.org/browse/MSITE-645
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
  Components: documentation
Affects Versions: 3.1
Reporter: Paul Benedict


Section Including Generated Content:
http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html

I used the example:
{noformat}
menu name=Foo href=foo.html /
{noformat}

Error reported:
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-site-plugin:3.1:site (default-cli) on project 
leave: SiteToolException: Error parsing site descriptor: Unknown attribute 
'href' for tag 'menu' (position: START_TAG seen ...body\r\nmenu 
name=Foo href=foo.html /... @3:40) - [Help 1]

Either the documentation is wrong or the site schema has changed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MJAVADOC-348) Update javaApiLinks links

2012-07-27 Thread Paul Benedict (JIRA)

Paul Benedict created MJAVADOC-348:
--

 Summary: Update javaApiLinks links
 Key: MJAVADOC-348
 URL: https://jira.codehaus.org/browse/MJAVADOC-348
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Improvement
Reporter: Paul Benedict
Priority: Minor


Oracle has moved their API documentation from download.oracle.com to 
docs.oracle.com

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MJAVADOC-348) Update javaApiLinks links

2012-07-28 Thread Paul Benedict (JIRA)


[ 
https://jira.codehaus.org/browse/MJAVADOC-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=304898#comment-304898
 ] 

Paul Benedict commented on MJAVADOC-348:


Both code and docs need to be updated.

 Update javaApiLinks links
 ---

 Key: MJAVADOC-348
 URL: https://jira.codehaus.org/browse/MJAVADOC-348
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Improvement
Reporter: Paul Benedict
Priority: Minor

 Oracle has moved their API documentation from download.oracle.com to 
 docs.oracle.com

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-5102) Mixin POM fragments

2012-08-01 Thread Paul Benedict (JIRA)


[ 
https://jira.codehaus.org/browse/MNG-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305201#comment-305201
 ] 

Paul Benedict commented on MNG-5102:


Was this issue created before import scope was introduced? Because that's how 
you can define a POM for particular types of projects (see issue description) 
and then add those dependencies to your project. I would say the import scope 
is the Mixin you want.

 Mixin POM fragments
 ---

 Key: MNG-5102
 URL: https://jira.codehaus.org/browse/MNG-5102
 Project: Maven 2  3
  Issue Type: Wish
  Components: POM
Affects Versions: 2.2.1
Reporter: Anthony Whitford
 Fix For: 3.1

 Attachments: maven-tiles.zip


 I am looking for a way to _mixin_ POM fragments into POMs.  Note that this 
 idea is beyond parent pom inheritance because all projects inherit from a 
 corporate parent pom.  The problem that I am running into is that the 
 corporate parent pom is turning into an _everything but the kitchen sink_ 
 POM and I'd like to dissect it into POM fragments relevant for individual 
 modules.
 For example, I would like to have mixins for:
 * Java projects (that include static code analysis plugins, javadoc, etc.)
 * JPA projects (that include DDL generation)
 * Flex projects (that include flexmojos, asdoc, etc.)
 * Scala projects (that include the maven-scala-compiler plugin, scaladoc, 
 etc.)
 * JavaScript projects (that include build plugins like 
 maven-yuicompressor-plugin with jslint and compress goals)
 Hopefully, you get the idea.  Without the ability to factor pom logic, we are 
 left with two symptoms:
 # copy/paste duplication
 # complex _it does it all_ parent poms (which slow down builds because more 
 plugins are loaded even though they might not do anything material)
 Note that a project may include multiple mixins as I could have a project 
 that contains Java code, Scala code, and JavaScript.
 Another idea is that the mixins could be parameterized, so that the ultimate 
 pom can be customized based on the parameters (like tokens).
 I recall reading about Mixins coming in Maven 3.1, but could not find any 
 such issue to watch, so am creating one.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-5102) Mixin POM fragments

2012-08-01 Thread Paul Benedict (JIRA)


[ 
https://jira.codehaus.org/browse/MNG-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=305201#comment-305201
 ] 

Paul Benedict edited comment on MNG-5102 at 8/1/12 1:38 PM:


Use import scope; that's how you can define a POM for particular types of 
projects (see issue description) and then add those dependencies to your 
project. I would say the import scope is the Mixin you want.

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

  was (Author: paul4christ79):
Was this issue created before import scope was introduced? Because that's 
how you can define a POM for particular types of projects (see issue 
description) and then add those dependencies to your project. I would say the 
import scope is the Mixin you want.
  
 Mixin POM fragments
 ---

 Key: MNG-5102
 URL: https://jira.codehaus.org/browse/MNG-5102
 Project: Maven 2  3
  Issue Type: Wish
  Components: POM
Affects Versions: 2.2.1
Reporter: Anthony Whitford
 Fix For: 3.1

 Attachments: maven-tiles.zip


 I am looking for a way to _mixin_ POM fragments into POMs.  Note that this 
 idea is beyond parent pom inheritance because all projects inherit from a 
 corporate parent pom.  The problem that I am running into is that the 
 corporate parent pom is turning into an _everything but the kitchen sink_ 
 POM and I'd like to dissect it into POM fragments relevant for individual 
 modules.
 For example, I would like to have mixins for:
 * Java projects (that include static code analysis plugins, javadoc, etc.)
 * JPA projects (that include DDL generation)
 * Flex projects (that include flexmojos, asdoc, etc.)
 * Scala projects (that include the maven-scala-compiler plugin, scaladoc, 
 etc.)
 * JavaScript projects (that include build plugins like 
 maven-yuicompressor-plugin with jslint and compress goals)
 Hopefully, you get the idea.  Without the ability to factor pom logic, we are 
 left with two symptoms:
 # copy/paste duplication
 # complex _it does it all_ parent poms (which slow down builds because more 
 plugins are loaded even though they might not do anything material)
 Note that a project may include multiple mixins as I could have a project 
 that contains Java code, Scala code, and JavaScript.
 Another idea is that the mixins could be parameterized, so that the ultimate 
 pom can be customized based on the parameters (like tokens).
 I recall reading about Mixins coming in Maven 3.1, but could not find any 
 such issue to watch, so am creating one.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-5085) Add a CLI option to ignore missing modules

2012-08-13 Thread Paul Benedict (JIRA)


[ 
https://jira.codehaus.org/browse/MNG-5085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306095#comment-306095
 ] 

Paul Benedict commented on MNG-5085:


Ivan, I don't think this option is really necessary for Maven. Based on your 
description, your issue seems purely process related. Your developers should be 
able to check out parts of the tree as necessary but you want to have the rest 
of tree already deployed to your corporate repository. Regarding building the 
whole thing, that's really a task for a tool like Hudson. 

 Add a CLI option to ignore missing modules
 --

 Key: MNG-5085
 URL: https://jira.codehaus.org/browse/MNG-5085
 Project: Maven 2  3
  Issue Type: Improvement
  Components: Reactor and workspace
Reporter: Stephan Pauxberger

 Using SVN for a rather big project, we tend to use SVN sparse checkouts, i.e. 
 we do not checkout the whole project. Example:
 Full Project (as in Repository):
 Parent
   pom.xml (contains A and B as modules)
   -- A
  pom.xml
   -- B
  pom.xml
 Now, do a checkout (svn co xxx --depth children; svn update --set-depth 
 inifity A)
 Working Copy:
 Parent
   pom.xml (contains A and B as modules)
   -- A
  pom.xml
   -- B (no pom!!, since we only did a sparse checkout)
 Now, this setup is not buildable, since maven complains (rightfully) about a 
 missing pom for B. 
 What I propose is an option to change this behaviour with a command-line 
 option (-imm, --ignore-missing-modules) that would simply ignore missing 
 modules during pom resolution.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-5085) Add a CLI option to ignore missing modules

2012-08-16 Thread Paul Benedict (JIRA)


[ 
https://jira.codehaus.org/browse/MNG-5085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306366#comment-306366
 ] 

Paul Benedict commented on MNG-5085:


Ivan, have you considered private branches for your developers? It is a great 
help on large projects because large projects cannot tolerate work that isn't 
ready for integration. This will then allow Hudson to build the whole thing 
and test/demo.

 Add a CLI option to ignore missing modules
 --

 Key: MNG-5085
 URL: https://jira.codehaus.org/browse/MNG-5085
 Project: Maven 2  3
  Issue Type: Improvement
  Components: Reactor and workspace
Reporter: Stephan Pauxberger

 Using SVN for a rather big project, we tend to use SVN sparse checkouts, i.e. 
 we do not checkout the whole project. Example:
 Full Project (as in Repository):
 Parent
   pom.xml (contains A and B as modules)
   -- A
  pom.xml
   -- B
  pom.xml
 Now, do a checkout (svn co xxx --depth children; svn update --set-depth 
 inifity A)
 Working Copy:
 Parent
   pom.xml (contains A and B as modules)
   -- A
  pom.xml
   -- B (no pom!!, since we only did a sparse checkout)
 Now, this setup is not buildable, since maven complains (rightfully) about a 
 missing pom for B. 
 What I propose is an option to change this behaviour with a command-line 
 option (-imm, --ignore-missing-modules) that would simply ignore missing 
 modules during pom resolution.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-5331) JavaFX should be added to compilation classpath

2012-08-20 Thread Paul Benedict (JIRA)


[ 
https://jira.codehaus.org/browse/MNG-5331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306573#comment-306573
 ] 

Paul Benedict commented on MNG-5331:


It's my understanding JavaFX is bundled in Oracle's distribution out of 
convenience/marketing. However, JavaFX is not part of the JDK. If you need 
JavaFX at compile time, you can easily add that dependency to your project.

 JavaFX should be added to compilation classpath
 ---

 Key: MNG-5331
 URL: https://jira.codehaus.org/browse/MNG-5331
 Project: Maven 2  3
  Issue Type: Bug
Reporter: Konstantin Solomatov

 Since JDK 1.7, JavaFX is part of JRE and JDK. However, Maven doesn't include 
 them into classpath automatically.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-5331) JavaFX should be added to compilation classpath

2012-08-20 Thread Paul Benedict (JIRA)


[ 
https://jira.codehaus.org/browse/MNG-5331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306573#comment-306573
 ] 

Paul Benedict edited comment on MNG-5331 at 8/20/12 11:00 AM:
--

It's my understanding JavaFX is bundled in Oracle's distribution out of 
convenience/marketing. However, JavaFX is not officially part of Java SE. If 
you need JavaFX at compile time, you can easily add that dependency to your 
project.

  was (Author: paul4christ79):
It's my understanding JavaFX is bundled in Oracle's distribution out of 
convenience/marketing. However, JavaFX is not part of the JDK. If you need 
JavaFX at compile time, you can easily add that dependency to your project.
  
 JavaFX should be added to compilation classpath
 ---

 Key: MNG-5331
 URL: https://jira.codehaus.org/browse/MNG-5331
 Project: Maven 2  3
  Issue Type: Bug
Reporter: Konstantin Solomatov

 Since JDK 1.7, JavaFX is part of JRE and JDK. However, Maven doesn't include 
 them into classpath automatically.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-5331) JavaFX should be added to compilation classpath

2012-08-20 Thread Paul Benedict (JIRA)


[ 
https://jira.codehaus.org/browse/MNG-5331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306584#comment-306584
 ] 

Paul Benedict commented on MNG-5331:


System scope is not your only option. You can also install the JAR into your 
local repository.

 JavaFX should be added to compilation classpath
 ---

 Key: MNG-5331
 URL: https://jira.codehaus.org/browse/MNG-5331
 Project: Maven 2  3
  Issue Type: Bug
Reporter: Konstantin Solomatov

 Since JDK 1.7, JavaFX is part of JRE and JDK. However, Maven doesn't include 
 them into classpath automatically.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-5331) JavaFX should be added to compilation classpath

2012-08-20 Thread Paul Benedict (JIRA)


[ 
https://jira.codehaus.org/browse/MNG-5331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306588#comment-306588
 ] 

Paul Benedict commented on MNG-5331:


If you have many development and CI machines, I recommend you get a corporate 
repository. Tools like Nexus will allow you to publish the JavaFX dependency 
one time for everyone. Otherwise, yes, it's the responsibility of each builder 
to have the dependency. JavaFX is not unique in this regard. There are many 
license-restricted JARs that have this issue (like JavaBeans Activation 
Framework); you just need to learn the process for handling these cases.

I hope this link can help ease the pain a bit:
http://java.dzone.com/articles/install-javafx-runtime-local

 JavaFX should be added to compilation classpath
 ---

 Key: MNG-5331
 URL: https://jira.codehaus.org/browse/MNG-5331
 Project: Maven 2  3
  Issue Type: Bug
Reporter: Konstantin Solomatov

 Since JDK 1.7, JavaFX is part of JRE and JDK. However, Maven doesn't include 
 them into classpath automatically.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-5331) JavaFX should be added to compilation classpath

2012-08-21 Thread Paul Benedict (JIRA)


 [ 
https://jira.codehaus.org/browse/MNG-5331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-5331:
---

Issue Type: Wish  (was: Bug)

 JavaFX should be added to compilation classpath
 ---

 Key: MNG-5331
 URL: https://jira.codehaus.org/browse/MNG-5331
 Project: Maven 2  3
  Issue Type: Wish
Reporter: Konstantin Solomatov

 Since JDK 1.7, JavaFX is part of JRE and JDK. However, Maven doesn't include 
 them into classpath automatically.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-5085) Add a CLI option to ignore missing modules

2012-08-23 Thread Paul Benedict (JIRA)


[ 
https://jira.codehaus.org/browse/MNG-5085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=306921#comment-306921
 ] 

Paul Benedict commented on MNG-5085:


I stumbled upon an article today that tangentially regards this issue. It is 
mostly FUD but it also echos some of the recent sentiments here regarding the 
difficulty of modules/nesting. Just linking to it to help the discussion: 
http://buzdin.blogspot.com/2012/08/maven-modules-considered-harmful.html

 Add a CLI option to ignore missing modules
 --

 Key: MNG-5085
 URL: https://jira.codehaus.org/browse/MNG-5085
 Project: Maven 2  3
  Issue Type: Improvement
  Components: Reactor and workspace
Reporter: Stephan Pauxberger

 Using SVN for a rather big project, we tend to use SVN sparse checkouts, i.e. 
 we do not checkout the whole project. Example:
 Full Project (as in Repository):
 Parent
   pom.xml (contains A and B as modules)
   -- A
  pom.xml
   -- B
  pom.xml
 Now, do a checkout (svn co xxx --depth children; svn update --set-depth 
 inifity A)
 Working Copy:
 Parent
   pom.xml (contains A and B as modules)
   -- A
  pom.xml
   -- B (no pom!!, since we only did a sparse checkout)
 Now, this setup is not buildable, since maven complains (rightfully) about a 
 missing pom for B. 
 What I propose is an option to change this behaviour with a command-line 
 option (-imm, --ignore-missing-modules) that would simply ignore missing 
 modules during pom resolution.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-5337) Maven activation profile feature cannot differ jdk version with build number

2012-08-28 Thread Paul Benedict (JIRA)


[ 
https://jira.codehaus.org/browse/MNG-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=307282#comment-307282
 ] 

Paul Benedict commented on MNG-5337:


Makes sense to me. The code is already correctly parsing the the build number 
(after the dash) but it's being ignored because the proceeding code stops at 
the third component.

 Maven activation profile feature cannot differ jdk version with build number
 

 Key: MNG-5337
 URL: https://jira.codehaus.org/browse/MNG-5337
 Project: Maven 2  3
  Issue Type: Bug
Affects Versions: 3.0.5, 3.1
Reporter: Vladimir Kravets
Priority: Minor
 Attachments: fix_jdk_build_version_activator.diff


 Since Oracle can apply some major changes between builds we need to have 
 ability to detect build number from profile - activation - jdk tag
 By now using only first three components of jdk version. I propose to use 
 first 4 components of the version to be able to process it further.
 E.g. from ~1.6.0-30 classpath separator is ; instead of :. In 1.7.x also 
 using ;.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-2199) Version ranges not supported for parent artifacts

2012-09-18 Thread Paul Benedict (JIRA)


[ 
https://jira.codehaus.org/browse/MNG-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308865#comment-308865
 ] 

Paul Benedict commented on MNG-2199:


I don't think parent versions should act like dependency versions. The parent 
should be a known quantity and not subject to environmental changes.

 Version ranges not supported for parent artifacts
 -

 Key: MNG-2199
 URL: https://jira.codehaus.org/browse/MNG-2199
 Project: Maven 2  3
  Issue Type: Bug
  Components: Inheritance and Interpolation, POM, Reactor and workspace
Affects Versions: 2.0.3
Reporter: Christian Schulte
 Fix For: Issues to be reviewed for 3.x

 Attachments: MNG-2199.patch, MNG-2199.patch


 It would be great if Maven supports version ranges when specifying parent 
 artifacts in a multi-module build. Currently this does not work.
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, 2.0.1]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 2.0.1]/artifactId-[2.0, 2.0.1].pom
 Additionally it would be great if this
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, ${pom.version}]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 ${pom.version}]/artifactId-[2.0, ${pom.version}].pom
 would also work, if the version is specified in the same pom.xml which 
 defines this parent definition.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-2199) Version ranges not supported for parent artifacts

2012-09-18 Thread Paul Benedict (JIRA)


 [ 
https://jira.codehaus.org/browse/MNG-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-2199:
---

Issue Type: Wish  (was: Bug)

Changing issue type from Bug to Wish

 Version ranges not supported for parent artifacts
 -

 Key: MNG-2199
 URL: https://jira.codehaus.org/browse/MNG-2199
 Project: Maven 2  3
  Issue Type: Wish
  Components: Inheritance and Interpolation, POM, Reactor and workspace
Affects Versions: 2.0.3
Reporter: Christian Schulte
 Fix For: Issues to be reviewed for 3.x

 Attachments: MNG-2199.patch, MNG-2199.patch


 It would be great if Maven supports version ranges when specifying parent 
 artifacts in a multi-module build. Currently this does not work.
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, 2.0.1]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 2.0.1]/artifactId-[2.0, 2.0.1].pom
 Additionally it would be great if this
   parent
 artifactIdartifactId/artifactId
 groupIdgroupId/groupId
 version[2.0, ${pom.version}]/version
   /parent
 [INFO] Scanning for projects...
 Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0, 
 ${pom.version}]/artifactId-[2.0, ${pom.version}].pom
 would also work, if the version is specified in the same pom.xml which 
 defines this parent definition.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] (MNG-5376) Account for changes between the Apple and Oracle JDKs on OSX

2012-11-13 Thread Paul Benedict (JIRA)


[ 
https://jira.codehaus.org/browse/MNG-5376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=313484#comment-313484
 ] 

Paul Benedict commented on MNG-5376:


FWIW, I see the Eclipse IDE is working on the same problem: 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=368483

 Account for changes between the Apple and Oracle JDKs on OSX
 

 Key: MNG-5376
 URL: https://jira.codehaus.org/browse/MNG-5376
 Project: Maven 2  3
  Issue Type: Task
Reporter: Jason van Zyl
Assignee: Jason van Zyl
 Fix For: 3.1.0


 With the arrival of Java 7 on OSX the directory locations and naming has 
 changed. Some changes need to be made in the launch scripts to account for 
 the changes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MNG-3766) toolchains not found in extensions

2008-10-19 Thread Paul Benedict (JIRA)


 [ 
http://jira.codehaus.org/browse/MNG-3766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-3766:
---

Fix Version/s: 2.1.0-M2

 toolchains not found in extensions
 --

 Key: MNG-3766
 URL: http://jira.codehaus.org/browse/MNG-3766
 Project: Maven 2
  Issue Type: Bug
  Components: Settings
Affects Versions: 2.0.9, 2.1.0-M1
Reporter: Brett Porter
Assignee: Brett Porter
 Fix For: 2.0.10, 2.1.0-M2


 There's currently no way to plugin in new toolchains without placing them in 
 M2_HOME/lib. For wagons to be available in extensions, the extension manager 
 explicitly registers them - so I propose to do the same in 2.1.0-M2 for 
 toolchains, and only support the Java toolchains in 2.0.9.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3424) Respect ordering of elements as given in POM

2008-10-30 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=152493#action_152493
 ] 

Paul Benedict commented on MNG-3424:


What's the true fixed version here? The comment says it was pushed to 2.0.11, 
but fixed in 2.0.10

 Respect ordering of elements as given in POM
 

 Key: MNG-3424
 URL: http://jira.codehaus.org/browse/MNG-3424
 Project: Maven 2
  Issue Type: Improvement
Affects Versions: 2.0.8
Reporter: Benjamin Bentmann
Assignee: Brett Porter
Priority: Trivial
 Fix For: 2.0.10, 2.1.0-M2

 Attachments: retain-collection-order.patch


 Better safe than sorry suggests to keep the ordering of collections when 
 converting them into maps. It's hard to know when ordering is really 
 irrelevant and the penalty of using {{java.util.Linked*}} is usually 
 neglectable.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MRELEASE-383) svn inconsistent line ending style

2008-11-12 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MRELEASE-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=153944#action_153944
 ] 

Paul Benedict commented on MRELEASE-383:


This issue has bitten me too. I am unable to use the plugin with CDATA sections.

 svn inconsistent line ending style
 --

 Key: MRELEASE-383
 URL: http://jira.codehaus.org/browse/MRELEASE-383
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
Reporter: Barrie Treloar

 The problem occurs in the CDATA section of the maven-eclipse-plugin -
 when setting the contents of the .checkstyle file.
 {code:xml}
 pom.xml
 ...
plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-eclipse-plugin/artifactId
  configuration
downloadSourcestrue/downloadSources
additionalBuildcommands
  
 buildcommandcom.atlassw.tools.eclipse.checkstyle.CheckstyleBuilder/buildcommand
/additionalBuildcommands
additionalProjectnatures
  
 projectnaturecom.atlassw.tools.eclipse.checkstyle.CheckstyleNature/projectnature
/additionalProjectnatures
additionalConfig
  file
name.checkstyle/name
content
  ![CDATA[?xml version=1.0 encoding=UTF-8?
 fileset-config file-format-version=1.2.0 simple-config=true
fileset name=all enabled=true check-config-name=QifCon 
 local=false
file-match-pattern match-pattern=. include-pattern=true /
/fileset
 /fileset-config
 ]]
/content
  /file
/additionalConfig
  /configuration
/plugin
  /plugins
 {code}
 When this file is transformed the CDATA section has LF only.
 On windows it should have CR LF.
 I suspect because it uses \n instead of System.getProperty( line.separator );

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MWAR-33) jars with differents versions can be in WEB-INF/lib with war as dependencies

2008-11-14 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MWAR-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=154264#action_154264
 ] 

Paul Benedict commented on MWAR-33:
---

My project team gets hit by this at least twice a week. Please let's fix this.

 jars with differents versions can be in WEB-INF/lib with war as dependencies
 

 Key: MWAR-33
 URL: http://jira.codehaus.org/browse/MWAR-33
 Project: Maven 2.x War Plugin
  Issue Type: Bug
 Environment: all
Reporter: Olivier Lamy
Assignee: Stephane Nicoll
 Fix For: 2.1

   Original Estimate: 15 minutes
  Time Spent: 30 minutes
  Remaining Estimate: 0 minutes

 My pom has the following dependencies :
 - log4j:log4j:1.2.13
 - a war with log4j:log4j:1.2.11 included 
 Result the two jars are in WEB-INF/lib.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MWAR-60) Source Excludes are being applied to WAR file

2008-11-17 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MWAR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=154497#action_154497
 ] 

Paul Benedict commented on MWAR-60:
---

Are we sure this is fixed? I cannot get the WEB-INF directory in 
src/main/webapp to be excluded.

 Source Excludes are being applied to WAR file
 -

 Key: MWAR-60
 URL: http://jira.codehaus.org/browse/MWAR-60
 Project: Maven 2.x War Plugin
  Issue Type: Bug
Affects Versions: 2.0.2
 Environment: WinXP, jdk1.5.0_07, mvn 2.0.4
Reporter: Chuck Deal
Assignee: Stephane Nicoll
 Fix For: 2.1-alpha-2


 My scenario:
 I use Eclipse 3.1.1 to develop the web app.  I run Tomcat 5.5.17 with it's 
 docbase pointed at the source tree (/src/main/webapp).  As a result, I have 
 files that are required by Tomcat to run, but not to be included in the WAR.  
 Specifically, I have a WEB-INF folder with a classes directory that includes 
 classes that will actually be included in the WAR as a JAR (as well as a few 
 other things).  
 As you can see in the following plugin snippet, I specifically exclude the 
 WEB-INF folder from the source tree because all of its contents will be 
 gathered by the various stages of the build process (process-resources, etc) 
 and included in the WAR when it is exploded
 I had been using the following plugin snippet for generating my War (war 
 plugin 2.0)
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-war-plugin/artifactId
   version2.0/version
   configuration
 webXmltarget/jspweb.xml/webXml
 warNameaims/warName
 excludes**/*.jsp*, **/JasperReports/*.*, **/WEB-INF/**/*.*/excludes
   /configuration
 /plugin
 If you change the version from 2.0 to 2.0.1, you will no longer generate the 
 same WAR file!  Instead, v2.0.1 uses the source excludes and applies them to 
 the WAR construction as well.  This means that the exploded WEB-INF (the 
 correct one) is also removed from the WAR file.  
 I don't think that the source excludes should be applied to the WAR 
 construction, only to the stage where the source files are exploded (as in 
 v2.0)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Issue Comment Edited: (MWAR-33) jars with differents versions can be in WEB-INF/lib with war as dependencies

2008-11-17 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MWAR-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=154264#action_154264
 ] 

paul4christ79 edited comment on MWAR-33 at 11/17/08 1:07 PM:
-

My project team gets hit by this at least twice a week. But shouldn't MWAR-60 
have fixed this? It's caused by developer workspaces containing a different 
version in src/main/webapp/WEB-INF/lib but Maven pulling down a different 
version in the build process. If we could just exclude WEB-INF/classes and 
WEB-INF/lib, this problem would be history.

  was (Author: paul4christ79):
My project team gets hit by this at least twice a week. Please let's fix 
this.
  
 jars with differents versions can be in WEB-INF/lib with war as dependencies
 

 Key: MWAR-33
 URL: http://jira.codehaus.org/browse/MWAR-33
 Project: Maven 2.x War Plugin
  Issue Type: Bug
 Environment: all
Reporter: Olivier Lamy
Assignee: Stephane Nicoll
 Fix For: 2.1

   Original Estimate: 15 minutes
  Time Spent: 30 minutes
  Remaining Estimate: 0 minutes

 My pom has the following dependencies :
 - log4j:log4j:1.2.13
 - a war with log4j:log4j:1.2.11 included 
 Result the two jars are in WEB-INF/lib.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MWAR-60) Source Excludes are being applied to WAR file

2008-11-18 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MWAR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=154605#action_154605
 ] 

Paul Benedict commented on MWAR-60:
---

For posterity, here is the solution. It turns out the trick is not specifying 
the ${basedir} at all in the excludes:
warSourceExcludesWEB-INF/classes/**,WEB-INF/lib/**/warSourceExcludes



 Source Excludes are being applied to WAR file
 -

 Key: MWAR-60
 URL: http://jira.codehaus.org/browse/MWAR-60
 Project: Maven 2.x War Plugin
  Issue Type: Bug
Affects Versions: 2.0.2
 Environment: WinXP, jdk1.5.0_07, mvn 2.0.4
Reporter: Chuck Deal
Assignee: Stephane Nicoll
 Fix For: 2.1-alpha-2


 My scenario:
 I use Eclipse 3.1.1 to develop the web app.  I run Tomcat 5.5.17 with it's 
 docbase pointed at the source tree (/src/main/webapp).  As a result, I have 
 files that are required by Tomcat to run, but not to be included in the WAR.  
 Specifically, I have a WEB-INF folder with a classes directory that includes 
 classes that will actually be included in the WAR as a JAR (as well as a few 
 other things).  
 As you can see in the following plugin snippet, I specifically exclude the 
 WEB-INF folder from the source tree because all of its contents will be 
 gathered by the various stages of the build process (process-resources, etc) 
 and included in the WAR when it is exploded
 I had been using the following plugin snippet for generating my War (war 
 plugin 2.0)
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-war-plugin/artifactId
   version2.0/version
   configuration
 webXmltarget/jspweb.xml/webXml
 warNameaims/warName
 excludes**/*.jsp*, **/JasperReports/*.*, **/WEB-INF/**/*.*/excludes
   /configuration
 /plugin
 If you change the version from 2.0 to 2.0.1, you will no longer generate the 
 same WAR file!  Instead, v2.0.1 uses the source excludes and applies them to 
 the WAR construction as well.  This means that the exploded WEB-INF (the 
 correct one) is also removed from the WAR file.  
 I don't think that the source excludes should be applied to the WAR 
 construction, only to the stage where the source files are exploded (as in 
 v2.0)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Issue Comment Edited: (MWAR-60) Source Excludes are being applied to WAR file

2008-11-18 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MWAR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=154605#action_154605
 ] 

paul4christ79 edited comment on MWAR-60 at 11/18/08 10:49 AM:
--

For posterity, here is the solution. It turns out the trick is not specifying 
the ${basedir} at all in the excludes:
{noformat}warSourceExcludesWEB-INF/classes/**,WEB-INF/lib/**/warSourceExcludes{noformat}



  was (Author: paul4christ79):
For posterity, here is the solution. It turns out the trick is not 
specifying the ${basedir} at all in the excludes:
warSourceExcludesWEB-INF/classes/**,WEB-INF/lib/**/warSourceExcludes


  
 Source Excludes are being applied to WAR file
 -

 Key: MWAR-60
 URL: http://jira.codehaus.org/browse/MWAR-60
 Project: Maven 2.x War Plugin
  Issue Type: Bug
Affects Versions: 2.0.2
 Environment: WinXP, jdk1.5.0_07, mvn 2.0.4
Reporter: Chuck Deal
Assignee: Stephane Nicoll
 Fix For: 2.1-alpha-2


 My scenario:
 I use Eclipse 3.1.1 to develop the web app.  I run Tomcat 5.5.17 with it's 
 docbase pointed at the source tree (/src/main/webapp).  As a result, I have 
 files that are required by Tomcat to run, but not to be included in the WAR.  
 Specifically, I have a WEB-INF folder with a classes directory that includes 
 classes that will actually be included in the WAR as a JAR (as well as a few 
 other things).  
 As you can see in the following plugin snippet, I specifically exclude the 
 WEB-INF folder from the source tree because all of its contents will be 
 gathered by the various stages of the build process (process-resources, etc) 
 and included in the WAR when it is exploded
 I had been using the following plugin snippet for generating my War (war 
 plugin 2.0)
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-war-plugin/artifactId
   version2.0/version
   configuration
 webXmltarget/jspweb.xml/webXml
 warNameaims/warName
 excludes**/*.jsp*, **/JasperReports/*.*, **/WEB-INF/**/*.*/excludes
   /configuration
 /plugin
 If you change the version from 2.0 to 2.0.1, you will no longer generate the 
 same WAR file!  Instead, v2.0.1 uses the source excludes and applies them to 
 the WAR construction as well.  This means that the exploded WEB-INF (the 
 correct one) is also removed from the WAR file.  
 I don't think that the source excludes should be applied to the WAR 
 construction, only to the stage where the source files are exploded (as in 
 v2.0)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3845) Unintended inheritance of parent elements overriden by children

2008-11-22 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=155059#action_155059
 ] 

Paul Benedict commented on MNG-3845:


You guys needs to add a new inherit attribute so MNG-2807 can be solved. In 
essence, we wanted to put our software engineers in the parent POM and inherit 
them in the children.

 Unintended inheritance of parent elements overriden by children
 ---

 Key: MNG-3845
 URL: http://jira.codehaus.org/browse/MNG-3845
 Project: Maven 2
  Issue Type: Bug
  Components: Inheritance and Interpolation
Affects Versions: 3.0-alpha-1
Reporter: Benjamin Bentmann
Assignee: Benjamin Bentmann
 Fix For: 3.0-alpha-1


 Parent POM snippet:
 {code:xml}
 ciManagement
   systemparent-ci/system
   urlhttp://parent.url/ci/url
   notifiers
 notifier
   typeirc/type
   sendOnErrortrue/sendOnError
   sendOnFailuretrue/sendOnFailure
   sendOnSuccessfalse/sendOnSuccess
   sendOnWarningfalse/sendOnWarning
   configuration
 addressirc://parent.url/#ci/address
   /configuration
 /notifier
   /notifiers
 /ciManagement
 {code}
 Child POM snippet:
 {code:xml}
 ciManagement
   systemchild-ci/system
   urlhttp://child.url/ci/url
 /ciManagement
 {code}
 Effective child POM:
 {code:xml}
 ciManagement
   systemchild-ci/system
   urlhttp://child.url/ci/url
   notifiers
 notifier
   typeirc/type
   sendOnErrortrue/sendOnError
   sendOnFailuretrue/sendOnFailure
   sendOnSuccessfalse/sendOnSuccess
   sendOnWarningfalse/sendOnWarning
   configuration
 addressirc://parent.url/#ci/address
   /configuration
 /notifier
   /notifiers
 /ciManagement
 {code}
 i.e. the notifiers are erroneously inherited although the child has specified 
 its own CI management. Happens to a couple of other elements like 
 {{distributionManagement}}, too. It appears the all-or-nothing style 
 inheritance present in Maven 2.x for certain elements is not properly 
 emulated on trunk.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MNG-3882) Prevent local repository from also being the remote repository

2008-12-01 Thread Paul Benedict (JIRA)

Prevent local repository from also being the remote repository
--

 Key: MNG-3882
 URL: http://jira.codehaus.org/browse/MNG-3882
 Project: Maven 2
  Issue Type: Bug
  Components: Settings
Affects Versions: 2.1.0-M1, 2.0.10, 3.0-alpha-1
Reporter: Paul Benedict


User list shows that the local repository can be specified as a remote 
repository. I've confirmed this is true. This is obviously a sore 
misconfiguration. Let's check that the values are never equal.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3882) Prevent local repository from also being the remote repository

2008-12-01 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=156078#action_156078
 ] 

Paul Benedict commented on MNG-3882:


I want to compare the values of the local repo path and the remote repo path. I 
can set both of them to a file system path. I can't remember if I can do it 
directly, or use the file:// protocol.

 Prevent local repository from also being the remote repository
 --

 Key: MNG-3882
 URL: http://jira.codehaus.org/browse/MNG-3882
 Project: Maven 2
  Issue Type: Bug
  Components: Settings
Affects Versions: 2.0.10, 2.1.0-M1, 3.0-alpha-1
Reporter: Paul Benedict

 User list shows that the local repository can be specified as a remote 
 repository. I've confirmed this is true. This is obviously a sore 
 misconfiguration. Let's check that the values are never equal.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3882) Prevent local repository from also being the remote repository

2008-12-01 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=156079#action_156079
 ] 

Paul Benedict commented on MNG-3882:


Okay. I have verified I can put in the same exact value for both. Neither of 
them are using a protocol -- just a file system path.

 Prevent local repository from also being the remote repository
 --

 Key: MNG-3882
 URL: http://jira.codehaus.org/browse/MNG-3882
 Project: Maven 2
  Issue Type: Bug
  Components: Settings
Affects Versions: 2.0.10, 2.1.0-M1, 3.0-alpha-1
Reporter: Paul Benedict

 User list shows that the local repository can be specified as a remote 
 repository. I've confirmed this is true. This is obviously a sore 
 misconfiguration. Let's check that the values are never equal.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3880) package phase devided into more specific phases

2008-12-02 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=156273#action_156273
 ] 

Paul Benedict commented on MNG-3880:


I don't think the solution is to have more phases. What about simply allowing a 
pre or post chain of behavior on each phase?

 package phase devided into more specific phases
 ---

 Key: MNG-3880
 URL: http://jira.codehaus.org/browse/MNG-3880
 Project: Maven 2
  Issue Type: Improvement
  Components: Plugins and Lifecycle
Affects Versions: 2.0.9
Reporter: Anders Kr. Andersen

 Currently the command mvn package will produce a zipped result file like 
 xx.war or xxx.jar
 So I belive it must always be...
 I suggest that the phase is devided into multiple pre phases like:
 package-copy   -- copies files to target/xxx-war (the prezipped 
 directory structure)
 package-manifest   -- generates the manifest to be packed into the zipped 
 result
 package-maven   -- generates the maven META-INF/maven files
 package-compress -- zips the  target/xxx-war into the file target/xxx-war.war
 The reasoning for these suggestions is that I had a situation where I had to 
 add more files into the unpacked result.
 This ended up more jobbi than I had thought because I had to manage the 
 manifest, maven and compress as well.
 Best regards
 /Anders
 PS: My sample is a Weblogic Integration Problem with task  
 weblogic.ant.taskdefs.build.AnnotationManifestTask
 The task will go through all classes and jars in the result and make a kind 
 of index and place the index into META-INF.
 My code got ugly
 I had to run the task yes, ofcause..
 But I had to do much more than I hoped.
 1) MANIFEST.MF  (maven generates it under the final ZIP process) I had to 
 steal it from mavens ZIP
 2) META-INF/maven/ (Maven also generates it under the final ZIP process). 
 I had to steal this as well
 3) the package phase will do the compress as well. I had to zip again !!! 
 (Maybe I could just update existing zip?, but i did not choose that)
 If I had multiple steps in the package phase I could have made this 
 customer-plugin easier...
 Here is the ugly code
 build-manifests moduleDir=${staging.dir}
  searchClasspathRef=annotation.manifest.search.path
  classpathRef=annotation.manifest.class.path
  verbose=false
  version=
  stagingDir=${project.build.directory}/manifest-work/
 
 unzip src=${staging.dir}.${project.packaging}
 dest=${staging.dir}
 patternset
 include name=META-INF/**/*.*/
 /patternset
 /unzip
 delete dir=${staging.dir}/WEB-INF/classes/META-INF/ /
 delete file=${staging.dir}.${project.packaging} /
 zip destfile=${staging.dir}.${project.packaging} encoding=UTF8 
 whenempty=create
 fileset dir=${staging.dir}/
 /zip
  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3811) Report plugins don't inherit configuration

2008-12-11 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=157812#action_157812
 ] 

Paul Benedict commented on MNG-3811:


I'd like to inherit the UmlGraphDoc doclet from a parent's configuration, but 
cannot do this bug.

 Report plugins don't inherit configuration
 --

 Key: MNG-3811
 URL: http://jira.codehaus.org/browse/MNG-3811
 Project: Maven 2
  Issue Type: Bug
  Components: POM
Affects Versions: 2.0.9, 2.0.11
 Environment: Ubuntu x64
 java version 1.6.0_0
 OpenJDK  Runtime Environment (build 1.6.0_0-b11)
 OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode)
Reporter: Nik Everett
Priority: Minor
 Attachments: bug.tar.gz, MNG-3811-maven-project.patch


 'm trying to set up reporting plugin inheritance and not having any luck.  
 I'm using Maven 2.0.9 on Java 1.6.0_07.  Here is my problem:
 parent/pom.xml has
   reporting
 plugins
   plugin
 artifactIdmaven-javadoc-plugin/artifactId
 configuration
   silenttrue/silent
   links
 linkparentLink/link
   /links
 /configuration
   /plugin
 /plugins
   /reporting
 child/pom.xml has
   reporting
 plugins
   plugin
 artifactIdmaven-javadoc-plugin/artifactId
 configuration
   links combine.children=append
 linkchildLink/link
   /links
 /configuration
   /plugin
 /plugins
   /reporting
 After installing the parent, mvn help:effective-pom for the child yeilds:
  reporting
 outputDirectorytarget/site/outputDirectory
 plugins
   plugin
 artifactIdmaven-javadoc-plugin/artifactId
 configuration
   links
 linkchildLink/link
   /links
 /configuration
   /plugin
 /plugins
   /reporting
 I expected it to look like:
  reporting
 outputDirectorytarget/site/outputDirectory
 plugins
   plugin
 artifactIdmaven-javadoc-plugin/artifactId
 configuration
   silenttrue/silent
   links
 linkparentLink/link
 linkchildLink/link
   /links
 /configuration
   /plugin
 /plugins
   /reporting
 I'd be happy to make a test case for this if someone would point me in the 
 right direction.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3882) Prevent local repository from also being the remote repository

2008-12-17 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158453#action_158453
 ] 

Paul Benedict commented on MNG-3882:


I can definitely create one. However, what is the use of making them the same? 
Is it just for what Wendy said above, and is that still safe? 

 Prevent local repository from also being the remote repository
 --

 Key: MNG-3882
 URL: http://jira.codehaus.org/browse/MNG-3882
 Project: Maven 2
  Issue Type: Bug
  Components: Settings
Affects Versions: 2.0.10, 2.1.0-M1, 3.0-alpha-1
Reporter: Paul Benedict
 Fix For: 2.0.x


 User list shows that the local repository can be specified as a remote 
 repository. I've confirmed this is true. This is obviously a sore 
 misconfiguration. Let's check that the values are never equal.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MNG-3000) Property substitution not possible in filter element if from profile

2008-12-18 Thread Paul Benedict (JIRA)


[ 
http://jira.codehaus.org/browse/MNG-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158608#action_158608
 ] 

Paul Benedict commented on MNG-3000:


Let me check if 2.0.10 still has the problem. 

 Property substitution not possible in filter element if from profile
 --

 Key: MNG-3000
 URL: http://jira.codehaus.org/browse/MNG-3000
 Project: Maven 2
  Issue Type: Bug
  Components: Bootstrap  Build
Affects Versions: 2.0.6
Reporter: Paul Benedict
Assignee: Brett Porter

 Based on a profile, I want to enable a property.
 profiles
   profile
 idmyprofile/id
 properties
   envdev/env
 /properties
   /profile
 /profiles
 And then use this property in a common filter path:
 build
   filters
 filtersrc/main/filters/${env}.properties/filter
   /filters
 /build
 The filter path only completes if I have a standalone properties element 
 outside of a profile. With that removed and a profile activated, the property 
 is not found.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

1 2 3 4 5 6 7 >

1 - 100 of 613 matches

Mail list logo