[jira] Commented: (ARCHETYPE-46) maven-archetype-archetype archetype places archetype.xml in the wrong location

2007-07-26 Thread Denis Cabasson (JIRA)

[ 
http://jira.codehaus.org/browse/ARCHETYPE-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103335
 ] 

Denis Cabasson commented on ARCHETYPE-46:
-

After forcing to an updated version of archetype plugins (1.0-alpha-4) 
everything runs fine.

Juste wondering why I didn't get the more up-to-date version, but taht's 
another issue.

> maven-archetype-archetype archetype places archetype.xml in the wrong location
> --
>
> Key: ARCHETYPE-46
> URL: http://jira.codehaus.org/browse/ARCHETYPE-46
> Project: Maven Archetype
>  Issue Type: Bug
>  Components: Archetypes
>Affects Versions: 1.0-alpha-4
> Environment: all
>Reporter: Gregory Kick
> Attachments: ARCHETYPE-46-bug.txt
>
>
> the maven-archetype-archetype archetype places archetype.xml in 
> .../META-INF/maven/archetype.xml instead of .../META-INF/archetype.xml as 
> directed by http://maven.apache.org/guides/mini/guide-creating-archetypes.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] Created: (MANTTASKS-84) VersionMapper does not work on SNAPSHOT dependencies where uniqueVersion="true"

2007-07-26 Thread Herve Boutemy (JIRA)
VersionMapper does not work on SNAPSHOT dependencies where uniqueVersion="true"
---

 Key: MANTTASKS-84
 URL: http://jira.codehaus.org/browse/MANTTASKS-84
 Project: Maven 2.x Ant Tasks
  Issue Type: Bug
  Components: dependencies task
Affects Versions: 2.0.7
Reporter: Herve Boutemy


When a dependency is SNAPSHOT and uniqueVersion="true", the version is not 
removed from the filename, nor the directory if to="flatten"

for example, adding in test-deps target of sample.build.xml the following:
{code:xml}

  
  

{code}

creates 
/target/files/versionMapperFlatten/it/ant-tasks/snapshotUniqueTrue/2.0.7-SNAPSHOT/snapshotUniqueTrue-2.0.7-20070610.180356-1.jar
 where it should be /target/files/versionMapperFlatten/snapshotUniqueTrue.jar

-- 
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: (SCM-330) Bug when trying to commit a large number of source files using the SVN command line tool as a part of the Maven2 Release plugin

2007-07-26 Thread Jorgen Fastrup (JIRA)
Bug when trying to commit a large number of source files using the SVN command 
line tool as a part of the Maven2 Release plugin
---

 Key: SCM-330
 URL: http://jira.codehaus.org/browse/SCM-330
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-svn
Affects Versions: 1.0-beta-3
 Environment: Windows XP
Reporter: Jorgen Fastrup


The SVN command generated by the "createCommandLine" method in the 
SvnCheckInCommand class does not consider the maximum length of the generated 
"svn commit" command line imposed by Windows XP, see 
http://support.microsoft.com/kb/830473

If using the SCM-SVN provider implementation as a part of the Maven2 Release 
plugin on a windows XP platform and you are trying to commit a lot of modified 
pom.xml's the SCM-SVN provider implementation will fail since it does not 
consider the maximum length of the generated "svn commit" command line imposed 
by the underlying operating system.

We have implemented a temporary fix for this problem in the "createCommandLine" 
method of the SvnCheckInCommand class by simply removing the code line: 
SvnCommandLineUtils.addFiles( cl, fileSet.getFiles() );
from the "createCommandLine" method in release 1.0-beta-3.

When studying the implementation of the "createCommandLine" method in release 
1.0 it seems though this new release also has the same problem with handling 
"svn commit" command lines of great lengh.

Would it not be possible to have "createCommandLine" method simply generate an 
implicit "svn commit" command line and not generate an explicit "svn commit" as 
currently implemented ... in this way the length of the commandl ine will never 
exceed the limits imposed by say Windows XP ?

Regards
Jorgen Fastrup




-- 
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: (MEAR-73) Property to disable transitive dependencies resolving

2007-07-26 Thread Thomas Hart (JIRA)

[ 
http://jira.codehaus.org/browse/MEAR-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103336
 ] 

Thomas Hart commented on MEAR-73:
-

I check the dependency plugin, it doesn't work. Can i submit a patch, that 
excludes the code block above?

> Property to disable transitive dependencies resolving
> -
>
> Key: MEAR-73
> URL: http://jira.codehaus.org/browse/MEAR-73
> Project: Maven 2.x Ear Plugin
>  Issue Type: Improvement
>Reporter: Thomas Hart
>Assignee: Stephane Nicoll
>
> We have ears with a lot of modules. So the transitive dependencies are very 
> huge and to exclude all these with {{true}} is no 
> option. Also to mark these dependencies with optional is no way. It is 
> possible to create a new property for that?

-- 
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: (MANTTASKS-84) VersionMapper does not work on SNAPSHOT dependencies where uniqueVersion="true"

2007-07-26 Thread Herve Boutemy (JIRA)

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

Herve Boutemy updated MANTTASKS-84:
---

  Fix Version/s: 2.0.8
Patch Submitted: [Yes]

> VersionMapper does not work on SNAPSHOT dependencies where 
> uniqueVersion="true"
> ---
>
> Key: MANTTASKS-84
> URL: http://jira.codehaus.org/browse/MANTTASKS-84
> Project: Maven 2.x Ant Tasks
>  Issue Type: Bug
>  Components: dependencies task
>Affects Versions: 2.0.7
>Reporter: Herve Boutemy
> Fix For: 2.0.8
>
> Attachments: MANTTASKS-84.diff
>
>
> When a dependency is SNAPSHOT and uniqueVersion="true", the version is not 
> removed from the filename, nor the directory if to="flatten"
> for example, adding in test-deps target of sample.build.xml the following:
> {code:xml}
> 
>   
>classname="org.apache.maven.artifact.ant.VersionMapper"
>   from="${dependency.versions}" to="flatten" />
> 
> {code}
> creates 
> /target/files/versionMapperFlatten/it/ant-tasks/snapshotUniqueTrue/2.0.7-SNAPSHOT/snapshotUniqueTrue-2.0.7-20070610.180356-1.jar
>  where it should be /target/files/versionMapperFlatten/snapshotUniqueTrue.jar

-- 
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: (MANTTASKS-84) VersionMapper does not work on SNAPSHOT dependencies where uniqueVersion="true"

2007-07-26 Thread Herve Boutemy (JIRA)

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

Herve Boutemy updated MANTTASKS-84:
---

Attachment: MANTTASKS-84.diff

Here is a testcase and fix

> VersionMapper does not work on SNAPSHOT dependencies where 
> uniqueVersion="true"
> ---
>
> Key: MANTTASKS-84
> URL: http://jira.codehaus.org/browse/MANTTASKS-84
> Project: Maven 2.x Ant Tasks
>  Issue Type: Bug
>  Components: dependencies task
>Affects Versions: 2.0.7
>Reporter: Herve Boutemy
> Fix For: 2.0.8
>
> Attachments: MANTTASKS-84.diff
>
>
> When a dependency is SNAPSHOT and uniqueVersion="true", the version is not 
> removed from the filename, nor the directory if to="flatten"
> for example, adding in test-deps target of sample.build.xml the following:
> {code:xml}
> 
>   
>classname="org.apache.maven.artifact.ant.VersionMapper"
>   from="${dependency.versions}" to="flatten" />
> 
> {code}
> creates 
> /target/files/versionMapperFlatten/it/ant-tasks/snapshotUniqueTrue/2.0.7-SNAPSHOT/snapshotUniqueTrue-2.0.7-20070610.180356-1.jar
>  where it should be /target/files/versionMapperFlatten/snapshotUniqueTrue.jar

-- 
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: (CONTINUUM-971) Symbolic links are traversed on deletion

2007-07-26 Thread Stephan Heinze (JIRA)

[ 
http://jira.codehaus.org/browse/CONTINUUM-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103338
 ] 

Stephan Heinze commented on CONTINUUM-971:
--

Modified problem with version 1.1-beta-1:

Symbolic links cause 'clean-working-directory' to fail. See 
Exception-StackTrace below.
Project is a shell project (usual automake/autoconf/libtool C++ project). 
Symbol link points to a file that was removed by the clean-task itself .. 
inside the project.

org.codehaus.plexus.taskqueue.execution.TaskExecutionException: Error executing 
action 'clean-working-directory'
at 
org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:432)
at 
org.apache.maven.continuum.buildcontroller.DefaultBuildController.cleanWorkingDirectory(DefaultBuildController.java:361)
at 
org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:103)
at 
org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50)
at 
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116)
at 
edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
at 
edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
at 
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
at 
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.io.IOException: Directory 
/opt/continuum/working-directory/11/debug/xml/.libs unable to be deleted.
at 
org.codehaus.plexus.util.FileUtils.deleteDirectory(FileUtils.java:1390)
at org.codehaus.plexus.util.FileUtils.forceDelete(FileUtils.java:1215)
at 
org.codehaus.plexus.util.FileUtils.cleanDirectory(FileUtils.java:1429)
at 
org.codehaus.plexus.util.FileUtils.deleteDirectory(FileUtils.java:1386)
at org.codehaus.plexus.util.FileUtils.forceDelete(FileUtils.java:1215)
at 
org.codehaus.plexus.util.FileUtils.cleanDirectory(FileUtils.java:1429)
at 
org.codehaus.plexus.util.FileUtils.deleteDirectory(FileUtils.java:1386)
at org.codehaus.plexus.util.FileUtils.forceDelete(FileUtils.java:1215)
at 
org.codehaus.plexus.util.FileUtils.cleanDirectory(FileUtils.java:1429)
at 
org.apache.maven.continuum.core.action.CleanWorkingDirectoryAction.execute(CleanWorkingDirectoryAction.java:58)
at 
org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:406)
... 9 more

> Symbolic links are traversed on deletion
> 
>
> Key: CONTINUUM-971
> URL: http://jira.codehaus.org/browse/CONTINUUM-971
> Project: Continuum
>  Issue Type: Bug
>  Components: Environmental
>Affects Versions: 1.0.3
> Environment: Reproduced on Redhat Enterprise 4 but applicable to all 
> forms of UNIX
>Reporter: Uri Moszkowicz
>Priority: Critical
> Fix For: Future
>
>
> To reproduce:
> 1. Create a project that checks out files from some SCM
> 2. Create a build script that creates symbolic links outside of the checked 
> out project sandbox. This is often done to bring outside libraries into the 
> project.
> 3. Delete the created project from the Continuum website. Notice how all 
> kinds of files disappear from your file system!
> From looking at the release logs it looks like someone added follow symbolic 
> links as the default and mentioned that at some point in the future an option 
> should be added to disable this behavior. Following symbolic links is very 
> dangerous and if supported it should be disabled by default, not the reverse. 
> A warning should be posted in a visible place for the existing versions until 
> this can be fixed as it can result in significant data loss outside of the 
> Continuum program.

-- 
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: (SCM-331) bug found in StarteamUpdateCommand when doing a delete-local when a (view)label is used

2007-07-26 Thread Jan Edelbroek (JIRA)
bug found in StarteamUpdateCommand when doing a delete-local when a (view)label 
is used
---

 Key: SCM-331
 URL: http://jira.codehaus.org/browse/SCM-331
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-starteam
Affects Versions: 1.0-beta-3
Reporter: Jan Edelbroek


After a succesfull update the StarteamUpdateCommand fires a delete-local 
command.
The command string that is created for the stcmd is wrong when a (view)label is 
used.
stcmd delete-local -x -nologo -stop -p "[EMAIL 
PROTECTED]:port/Project/View/path" -fp path-to-working-directory -is "-cfgl " 
alpha-1-1 -filter N
As you can see, the -cfgl option is between quotes and there is also an 
additional space character.

The problem is in the StarteamUpdateCommand class file (also in the trunk 
version).
The following line in the createDeleteLocalCommand method
args.add( "-cfgl " );
should be replaced with
args.add( "-cfgl" );
thus leaving out the additional space character.

I can provide a patch when necessary.
See also SCM-309 in which i indicate that i have a patch ready to be able to 
use promotion states instead of view labels


-- 
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: (MANTTASKS-67) artifact:deploy - The name of deploying element in snapshot repository is wrong

2007-07-26 Thread Herve Boutemy (JIRA)

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

Herve Boutemy updated MANTTASKS-67:
---

Attachment: MANTTASKS-67.diff

> artifact:deploy - The name of deploying element in snapshot repository is 
> wrong
> ---
>
> Key: MANTTASKS-67
> URL: http://jira.codehaus.org/browse/MANTTASKS-67
> Project: Maven 2.x Ant Tasks
>  Issue Type: Bug
>  Components: deploy task
>Affects Versions: 2.0.6, 2.0.7
>Reporter: David N'DIAYE
> Fix For: 2.0.8
>
> Attachments: MANTTASKS-67.diff, testSnapshots.zip
>
>
> The zip file contains test with Ant.
> To launch it : ant test.
> I try to deploy a snapshot artifact in repository
> So, my pom.xml contains a version with the extension '-SNAPSHOT'
> And in my build file Ant i do this :
> 
>
>
>
> In the repository the name of the artifact is 
> --SNAPSHOT. instead of 
> --.--
> Another problem, i try to upload 2 attachments with my artifact (javadoc and 
> java-source), and the buildNumber in the meta-data.xml increment by 3 instead 
> of 1
> 
>
>
>
>
>
> You can test it with : ant testWithAttach

-- 
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: (MANTTASKS-67) artifact:deploy - The name of deploying element in snapshot repository is wrong

2007-07-26 Thread Herve Boutemy (JIRA)

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

Herve Boutemy updated MANTTASKS-67:
---

Attachment: (was: MANTTASKS-67.diff)

> artifact:deploy - The name of deploying element in snapshot repository is 
> wrong
> ---
>
> Key: MANTTASKS-67
> URL: http://jira.codehaus.org/browse/MANTTASKS-67
> Project: Maven 2.x Ant Tasks
>  Issue Type: Bug
>  Components: deploy task
>Affects Versions: 2.0.6, 2.0.7
>Reporter: David N'DIAYE
> Fix For: 2.0.8
>
> Attachments: MANTTASKS-67.diff, testSnapshots.zip
>
>
> The zip file contains test with Ant.
> To launch it : ant test.
> I try to deploy a snapshot artifact in repository
> So, my pom.xml contains a version with the extension '-SNAPSHOT'
> And in my build file Ant i do this :
> 
>
>
>
> In the repository the name of the artifact is 
> --SNAPSHOT. instead of 
> --.--
> Another problem, i try to upload 2 attachments with my artifact (javadoc and 
> java-source), and the buildNumber in the meta-data.xml increment by 3 instead 
> of 1
> 
>
>
>
>
>
> You can test it with : ant testWithAttach

-- 
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: (MASSEMBLY-228) UnpackOptions filtered does not work

2007-07-26 Thread Elid OR (JIRA)
UnpackOptions filtered does not work


 Key: MASSEMBLY-228
 URL: http://jira.codehaus.org/browse/MASSEMBLY-228
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.2-beta-1
 Environment: Windows XP with maven 2.0.7
Reporter: Elid OR


Here my configuration in my assembly descriptor file :

  

  true
  
true
  
  my-groupId:my-artifactId
  

And this correctly unpack my dependencies but it does not filter the token in 
it.

The token are put in a profile that a activate when build the 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: (MSITE-129) modules list empty if modules don't use this project as parent in reactor build

2007-07-26 Thread John Allen (JIRA)

[ 
http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103349
 ] 

John Allen commented on MSITE-129:
--

Matt,

In regards to your structure. We are a massive information services company and 
as such our 'apps' are produced by accounts and project teams in isolation of 
each other and with lifecycles measured in years and 10s of years and as such 
each one of our account/project 'apps' (itself consisting of multiple maven 
modules) needs its own 'management' POM to setup where its SVN, CI, issue 
tracker and distro management locations are, define plugin versions, and all 
that good stuff. The only way to do this and have it used by all of the apps 
modules is via inheritance. I guess I world is much more akin to a sourceforge 
in as much as although we're one company we have many very independent projects 
and the only way they can share their per-project settings amongst their 
modules is via inheritance.

Horses for courses really.

> modules list empty if modules don't use this project as parent in reactor 
> build
> ---
>
> Key: MSITE-129
> URL: http://jira.codehaus.org/browse/MSITE-129
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>Affects Versions: 2.0-beta-5
>Reporter: Kenney Westerhof
>Assignee: Kenney Westerhof
>Priority: Minor
> Fix For: 2.0-beta-7
>
>
> The code in the AbstractSiteRenderingMojo does the following:
> - if it's running in a reactor build (i.e. more than 1 project in the reactor 
> projects) it scans all
> projects to see if it's parent project equals the current project. If so, 
> it's marked as a module.
> - if it's running on a single project, the project.build.modules is consulted 
> and those modules
> are marked as modules.
> I've got a 'fake' root pom, for utility purposes: it lists all projects as 
> modules so that I can easily
> built everything and generate a site. However, this fake root pom is never 
> used as a parent - there's
> a /pom/pom.xml project for that.
> The result of this is that the modules list is empty.
> A workaround is to first run 'mvn site' and then 'mvn site -N'.
> I'm not sure what the correct solution should be - basically now 2 site 
> layouts are implemented:
> - a physical layout where the modules match the  section of the pom, 
> reflecting filesystem layout,
> - a project hierarchy layout based on 
> and one or the other is used depending on wheter the build contains more than 
> 1 project or not.
> My first feeling is that since the tag is called ${modules} (or  ref="modules"/>) that
> the site should use the , not the . 
> It should also take into consideration, that IF a reactor build is running, 
> it should only use the modules that are also
> in the reactor (so you can use -r -Dmaven.reactor.excludes=.. to generate a 
> site with not all projects in it).
> Thoughts?

-- 
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: (MSITE-132) Use instead of for directories

2007-07-26 Thread John Allen (JIRA)

[ 
http://jira.codehaus.org/browse/MSITE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103350
 ] 

John Allen commented on MSITE-132:
--

Jorg,

The logic of stage is fairly obvious. one is simulating the real world 
deployment, where projects and modules from the internet namespace are mapped 
to residing within a root node of a filesystem. Your expectation regarding what 
the site:stage plugin should do and how it should do it is wrong. Adjust your 
expectation and you will be happier.


> Use  instead of  for directories
> --
>
> Key: MSITE-132
> URL: http://jira.codehaus.org/browse/MSITE-132
> Project: Maven 2.x Site Plugin
>  Issue Type: Improvement
> Environment: maven-2.0.4 on any operating system with the latests 
> released plugins (after the doxia-1.0-alpha-8.pom bug)
>Reporter: Jörg Hohwiller
> Attachments: MSITE-132.patch
>
>
> The  of a project in the POM may contain characters that cause trouble 
> when used in directory names.
> E.g. my open-source project: 
> http://svn.projxpert.com/mmm/trunk/
> Uses names such as "MMM::Configuration". Now when I stage the site of the 
> entire project, the relative link "MMM::Configuration" causes mozilla to say 
> something like "Unknown protocol 'mmm:'".
> Could you please use the artefactId instead. 
> I think personally think that this is a lot better anyways.
> BTW - Thanks for your greate work. M2 is awesome!!!

-- 
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: (MDOCCK-2) Make errors more detailed

2007-07-26 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg updated MDOCCK-2:
-

Affects Version/s: 1.0-beta-1

> Make errors more detailed
> -
>
> Key: MDOCCK-2
> URL: http://jira.codehaus.org/browse/MDOCCK-2
> Project: Maven 2.x DOCCK Plugin
>  Issue Type: Improvement
>Affects Versions: 1.0-beta-1
> Environment: Maven 2.0.4
>Reporter: Jimisola Laursen
>Assignee: Dennis Lundberg
> Fix For: 1.0-beta-2
>
>
> It would be a big improvement if the plugin specifies the location of the 
> problem (i.e. pom.xml, site.xml etc) and not only what the problem is.
> Possibly include line number and/or path to element/tag.
> E.g. replace "[ERROR] Missing tag " with "[ERROR] pom.xml:20 
> Missing tag /".

-- 
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: (MCLOVER-80) aggregate is not respecting the true module hierarchy and creates merged databases containing non-sibling data

2007-07-26 Thread John Allen (JIRA)

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

John Allen updated MCLOVER-80:
--

Attachment: MCLOVER-80.diff

After discussion it appears that some people would like aggregate to include 
all the projects within the reactor, regardless of their inheritance 
relationship to the parent project (i.e. the existing behaviour) and others 
would like the inheritance hierarchy to be honoured in aggregation.

This latest patch supports both these configurations with the addition of a new 
configuration option 'aggregateOnlyChildren'.



> aggregate is not respecting the true module hierarchy and creates merged 
> databases containing non-sibling data
> --
>
> Key: MCLOVER-80
> URL: http://jira.codehaus.org/browse/MCLOVER-80
> Project: Maven 2.x Clover Plugin
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: John Allen
> Attachments: MCLOVER-80.diff, MCLOVER-80.diff, MCLOVER-80.diff, 
> MCLOVER-80.diff
>
>
> The reactor contains a very deep multi-project multi-module structure. We 
> would expect the aggregation to only go up the family tree and not pollute 
> across the ancestors.
> A-->B-->C-->D
> A-->B-->E
> A-->Q-->P-->R
> A-->Q-->P-->S
> We would expect A to contain all the merged data but not to find that in P we 
> have data from C and D.

-- 
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: (MPCLOVER-59) clover report does not include instrumented test lines of code with junit report included

2007-07-26 Thread Jeff Black (JIRA)
clover report does not include instrumented test lines of code with junit 
report included
-

 Key: MPCLOVER-59
 URL: http://jira.codehaus.org/browse/MPCLOVER-59
 Project: Maven 1.x Clover Plugin
  Issue Type: Bug
Affects Versions: 1.11.2
 Environment: windows XP/cygwin
maven 1.1
maven-junit-report-plugin 1.5.1
Reporter: Jeff Black


Running the clover report as the only project report to obtain source lines of 
code works with the property maven.clover.instrument.tests set = true.

However, if the project also specifies the junit report 
(maven-junit-report-plugin), then the clover report will not 
include test lines of code, even with the property 
maven.clover.instrument.tests=true.

I looked at the junit-report-plugin plugin.jelly, put nothing jumped out at me 
as being suspect along the lines of modifying maven.test.compile.src.set, for 
example.

This is can reproduced by adding the maven-junit-report-plugin 
to the existing clover plugin test case:
  testSiteReportAndGenerationOfDifferentFormats

-- 
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: (MSITE-129) modules list empty if modules don't use this project as parent in reactor build

2007-07-26 Thread John Allen (JIRA)

[ 
http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103404
 ] 

John Allen commented on MSITE-129:
--

Kenney, how can we go about dealing with these two cases? 

* A user wishes to have all the modules appear.

Okay so I guess with the tag being called  then this is what it 
was originally intended to do and the reactor based code should be changed to 
only find the modules from the reactor, not the inheriting projects (as it does 
at the moment). 

The benefits to using the reactor is that it's quick and the projects are fully 
interpolated. If there's no reactor we try and build the models from the 
fileystem module POMs. I'm not sure how interpolated they are, ie if the module 
has ${} values in it are they evaluated? (didnt used to be the case but could 
be now). If there are no filesystem modules available then it's a pure nasty 
hack of setting the module project's name and url to be the value found in the 
root project's  element, which for flat multimodule type 
scenarios will be "../somename" ( ! ) 

* A user wishes to have the children appear in the site, regardless of the 
modules.

This is what users like me want. I guess a configuration option could be used 
to distinguish this behaviour rather than a new site.xml element. Either way 
this is easy for the reactor based 'child project's find but for the mvn -N 
situations one would need to create all the module projects from their file 
system pom.xml files and then check if their parent clauses match the current 
project.

Actually that doesn't sound to be bad to me. Thoughts?



> modules list empty if modules don't use this project as parent in reactor 
> build
> ---
>
> Key: MSITE-129
> URL: http://jira.codehaus.org/browse/MSITE-129
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>Affects Versions: 2.0-beta-5
>Reporter: Kenney Westerhof
>Assignee: Kenney Westerhof
>Priority: Minor
> Fix For: 2.0-beta-7
>
>
> The code in the AbstractSiteRenderingMojo does the following:
> - if it's running in a reactor build (i.e. more than 1 project in the reactor 
> projects) it scans all
> projects to see if it's parent project equals the current project. If so, 
> it's marked as a module.
> - if it's running on a single project, the project.build.modules is consulted 
> and those modules
> are marked as modules.
> I've got a 'fake' root pom, for utility purposes: it lists all projects as 
> modules so that I can easily
> built everything and generate a site. However, this fake root pom is never 
> used as a parent - there's
> a /pom/pom.xml project for that.
> The result of this is that the modules list is empty.
> A workaround is to first run 'mvn site' and then 'mvn site -N'.
> I'm not sure what the correct solution should be - basically now 2 site 
> layouts are implemented:
> - a physical layout where the modules match the  section of the pom, 
> reflecting filesystem layout,
> - a project hierarchy layout based on 
> and one or the other is used depending on wheter the build contains more than 
> 1 project or not.
> My first feeling is that since the tag is called ${modules} (or  ref="modules"/>) that
> the site should use the , not the . 
> It should also take into consideration, that IF a reactor build is running, 
> it should only use the modules that are also
> in the reactor (so you can use -r -Dmaven.reactor.excludes=.. to generate a 
> site with not all projects in it).
> Thoughts?

-- 
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: (MEAR-73) Property to disable transitive dependencies resolving

2007-07-26 Thread Stephane Nicoll (JIRA)

[ 
http://jira.codehaus.org/browse/MEAR-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103399
 ] 

Stephane Nicoll commented on MEAR-73:
-

> I mean that the dependency:resolve with the property excludeTransitive don't 
> have any effects to the ear plugin.

Well I wonder *how* it could have any effect.

And your patch is plain wrong anyway: it works as a side effect. since you have 
a single dependency and non scope dependencies. Trust me, your simple project 
does not reflect how this plugin is used at all. 

> Property to disable transitive dependencies resolving
> -
>
> Key: MEAR-73
> URL: http://jira.codehaus.org/browse/MEAR-73
> Project: Maven 2.x Ear Plugin
>  Issue Type: Improvement
>Reporter: Thomas Hart
>Assignee: Stephane Nicoll
> Attachments: ear.jpg, patch.txt
>
>
> We have ears with a lot of modules. So the transitive dependencies are very 
> huge and to exclude all these with {{true}} is no 
> option. Also to mark these dependencies with optional is no way. It is 
> possible to create a new property for that?

-- 
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: (MEAR-73) Property to disable transitive dependencies resolving

2007-07-26 Thread Stephane Nicoll (JIRA)

[ 
http://jira.codehaus.org/browse/MEAR-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103400
 ] 

Stephane Nicoll commented on MEAR-73:
-

also note that you don't need the ejbModule entry at all. It's only used if you 
want to customize module's parameters (bundle file name, uri, etc)

> Property to disable transitive dependencies resolving
> -
>
> Key: MEAR-73
> URL: http://jira.codehaus.org/browse/MEAR-73
> Project: Maven 2.x Ear Plugin
>  Issue Type: Improvement
>Reporter: Thomas Hart
>Assignee: Stephane Nicoll
> Attachments: ear.jpg, patch.txt
>
>
> We have ears with a lot of modules. So the transitive dependencies are very 
> huge and to exclude all these with {{true}} is no 
> option. Also to mark these dependencies with optional is no way. It is 
> possible to create a new property for that?

-- 
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: (MCHANGELOG-70) Support a URL filter that enables JIRA/bugzilla/whatever IDs quoted in SCM message to be mapped to real URLs

2007-07-26 Thread John Allen (JIRA)
Support a URL filter that enables JIRA/bugzilla/whatever IDs quoted in SCM 
message to be mapped to real URLs


 Key: MCHANGELOG-70
 URL: http://jira.codehaus.org/browse/MCHANGELOG-70
 Project: Maven 2.x Changelog Plugin
  Issue Type: Improvement
Affects Versions: 2.1
Reporter: John Allen


Eclipse Mylyn, plus other good behaviours (see [JIRA Commit Acceptance 
Plugin|http://confluence.atlassian.com/display/JIRAEXT/Commit+Acceptance+Plugin])
 make it necessary to quote a task upon check-in. These task IDs can easily be 
mapped to URLs using simple regex pattern rules that can be defined in the  
plugin config.

-- 
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: (MCHANGELOG-69) Print developer names regardless of whether they're listed in the POM

2007-07-26 Thread John Allen (JIRA)
Print developer names regardless of whether they're listed in the POM
-

 Key: MCHANGELOG-69
 URL: http://jira.codehaus.org/browse/MCHANGELOG-69
 Project: Maven 2.x Changelog Plugin
  Issue Type: Improvement
Affects Versions: 2.1
 Environment: 2.2
Reporter: John Allen


It seems a waste to throw away good information from the SCM report just 
because a developer is not listed in the projects , 
lets just print the name from the SCM report (userid) if we cant find them in 
the 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] Created: (MIDEA-102) CLONE -still broken - Module filepath is generated incorrectly

2007-07-26 Thread Joern Huxhorn (JIRA)
CLONE -still broken - Module filepath is generated incorrectly
--

 Key: MIDEA-102
 URL: http://jira.codehaus.org/browse/MIDEA-102
 Project: Maven 2.x IDEA Plugin
  Issue Type: Bug
Affects Versions: 2.1
 Environment: $ mvn -v
Maven version: 2.0.7
Java version: 1.5.0_11
OS name: "windows xp" version: "5.1" arch: "x86"
cygwin
Reporter: Joern Huxhorn
Assignee: Dennis Lundberg
 Fix For: 2.2


I have a multi-module mvn project.

When I do an mvn idea:clean idea:idea, the following ProjectModuleManager 
snippet in the top level .ipr is generated:

 
 

  
  
  
  
  
  
  
  
  
  
 
  

The $PROJECT_DIR in this case is C:/dev/voca/gateway/.

But this path is being appended in a hard-coded fashion after the $PROJECT_DIR 
entry.

The symptom in Intellij is the following error message:

Cannot load module: File 
C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not exist
Would you like to remove the module from the project?

The workaround is to delete the extra appended file path from each module entry 
in the above mentioned snippet.


-- 
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: (CONTINUUM-1354) meta refresh causes build loop

2007-07-26 Thread Olivier Lamy (JIRA)

[ 
http://jira.codehaus.org/browse/CONTINUUM-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103419
 ] 

Olivier Lamy commented on CONTINUUM-1354:
-

read "the same project build have build enqueuing again" instead of "some 
project build have build enqueuing"

> meta refresh causes build loop
> --
>
> Key: CONTINUUM-1354
> URL: http://jira.codehaus.org/browse/CONTINUUM-1354
> Project: Continuum
>  Issue Type: Bug
>  Components: Web interface
>Affects Versions: 1.1-beta-1
> Environment: all
>Reporter: Olivier Lamy
>
> Simple scenario : 
> - edit a project group
> - force a project build with the link "Build Now"
> - go to drink some coffe (longer than 5 minutes)
> - some project build have build  enqueuing
> It due to the link 
> http://${ip}:${pwd}/continuum/buildProject.action?fromGroupPage=true&projectGroupId=15&projectId=79
> The meta refresh force the build.
> As some browser have the tabs, this can cause a lot of not needed builds .
> --
> Olivier
> PS :  I will provide a patch next week.

-- 
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] Closed: (MIDEA-102) CLONE -still broken - Module filepath is generated incorrectly

2007-07-26 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg closed MIDEA-102.
-

Resolution: Duplicate

The issue MIDEA-98 has been fixed and verified. It is only available in the the 
2.2-SNAPSHOT version. It is not fixed in version 2.1 of this plugin.

> CLONE -still broken - Module filepath is generated incorrectly
> --
>
> Key: MIDEA-102
> URL: http://jira.codehaus.org/browse/MIDEA-102
> Project: Maven 2.x IDEA Plugin
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: $ mvn -v
> Maven version: 2.0.7
> Java version: 1.5.0_11
> OS name: "windows xp" version: "5.1" arch: "x86"
> cygwin
>Reporter: Joern Huxhorn
>Assignee: Dennis Lundberg
> Fix For: 2.2
>
> Attachments: maven-idea-plugin-MIDEA-102.patch
>
>
> I have a multi-module mvn project.
> When I do an mvn idea:clean idea:idea, the following ProjectModuleManager 
> snippet in the top level .ipr is generated:
>  
>  
> 
>   
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/>
>  
>   
> The $PROJECT_DIR in this case is C:/dev/voca/gateway/.
> But this path is being appended in a hard-coded fashion after the 
> $PROJECT_DIR entry.
> The symptom in Intellij is the following error message:
> Cannot load module: File 
> C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not 
> exist
> Would you like to remove the module from the project?
> The workaround is to delete the extra appended file path from each module 
> entry in the above mentioned snippet.

-- 
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: (CONTINUUM-1354) meta refresh causes build loop

2007-07-26 Thread Olivier Lamy (JIRA)
meta refresh causes build loop
--

 Key: CONTINUUM-1354
 URL: http://jira.codehaus.org/browse/CONTINUUM-1354
 Project: Continuum
  Issue Type: Bug
  Components: Web interface
Affects Versions: 1.1-beta-1
 Environment: all
Reporter: Olivier Lamy


Simple scenario : 
- edit a project group
- force a project build with the link "Build Now"
- go to drink some coffe (longer than 5 minutes)
- some project build have build  enqueuing

It due to the link 
http://${ip}:${pwd}/continuum/buildProject.action?fromGroupPage=true&projectGroupId=15&projectId=79
The meta refresh force the build.
As some browser have the tabs, this can cause a lot of not needed builds .

--
Olivier
PS :  I will provide a patch next week.


-- 
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: (MIDEA-102) CLONE -still broken - Module filepath is generated incorrectly

2007-07-26 Thread Dennis Lundberg (JIRA)

[ 
http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103414
 ] 

Dennis Lundberg commented on MIDEA-102:
---

Which issue was this cloned from? Please create a link to it.

> CLONE -still broken - Module filepath is generated incorrectly
> --
>
> Key: MIDEA-102
> URL: http://jira.codehaus.org/browse/MIDEA-102
> Project: Maven 2.x IDEA Plugin
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: $ mvn -v
> Maven version: 2.0.7
> Java version: 1.5.0_11
> OS name: "windows xp" version: "5.1" arch: "x86"
> cygwin
>Reporter: Joern Huxhorn
>Assignee: Dennis Lundberg
> Fix For: 2.2
>
> Attachments: maven-idea-plugin-MIDEA-102.patch
>
>
> I have a multi-module mvn project.
> When I do an mvn idea:clean idea:idea, the following ProjectModuleManager 
> snippet in the top level .ipr is generated:
>  
>  
> 
>   
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/>
>  
>   
> The $PROJECT_DIR in this case is C:/dev/voca/gateway/.
> But this path is being appended in a hard-coded fashion after the 
> $PROJECT_DIR entry.
> The symptom in Intellij is the following error message:
> Cannot load module: File 
> C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not 
> exist
> Would you like to remove the module from the project?
> The workaround is to delete the extra appended file path from each module 
> entry in the above mentioned snippet.

-- 
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: (MIDEA-102) CLONE -still broken - Module filepath is generated incorrectly

2007-07-26 Thread Joern Huxhorn (JIRA)

[ 
http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103413
 ] 

Joern Huxhorn commented on MIDEA-102:
-

I'd also suggest to change
protected String toRelative( File basedir, String absolutePath )
to
static String toRelative( File basedir, String absolutePath )

and write some tests. I didn't want to change too much, though.

> CLONE -still broken - Module filepath is generated incorrectly
> --
>
> Key: MIDEA-102
> URL: http://jira.codehaus.org/browse/MIDEA-102
> Project: Maven 2.x IDEA Plugin
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: $ mvn -v
> Maven version: 2.0.7
> Java version: 1.5.0_11
> OS name: "windows xp" version: "5.1" arch: "x86"
> cygwin
>Reporter: Joern Huxhorn
>Assignee: Dennis Lundberg
> Fix For: 2.2
>
> Attachments: maven-idea-plugin-MIDEA-102.patch
>
>
> I have a multi-module mvn project.
> When I do an mvn idea:clean idea:idea, the following ProjectModuleManager 
> snippet in the top level .ipr is generated:
>  
>  
> 
>   
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/>
>  
>   
> The $PROJECT_DIR in this case is C:/dev/voca/gateway/.
> But this path is being appended in a hard-coded fashion after the 
> $PROJECT_DIR entry.
> The symptom in Intellij is the following error message:
> Cannot load module: File 
> C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not 
> exist
> Would you like to remove the module from the project?
> The workaround is to delete the extra appended file path from each module 
> entry in the above mentioned snippet.

-- 
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: (MCHANGELOG-71) Support a %REV% in displayFileDetailUrl in the same way we support %FILE

2007-07-26 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg updated MCHANGELOG-71:
--

Affects Version/s: (was: 2.2)

> Support a %REV% in displayFileDetailUrl in the same way we support %FILE
> 
>
> Key: MCHANGELOG-71
> URL: http://jira.codehaus.org/browse/MCHANGELOG-71
> Project: Maven 2.x Changelog Plugin
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: John Allen
>
> Reports are historical and by providing this we can keep the links to actual 
> revisions of the files.

-- 
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: (MCHANGELOG-68) testReadFile unit test timebased comparisons fail

2007-07-26 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg updated MCHANGELOG-68:
--

Affects Version/s: (was: 2.2)
   2.1

> testReadFile unit test timebased comparisons fail
> -
>
> Key: MCHANGELOG-68
> URL: http://jira.codehaus.org/browse/MCHANGELOG-68
> Project: Maven 2.x Changelog Plugin
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: 2.0.7
>Reporter: John Allen
>
> The unit tests in ChangeLogTest that test the changeset file for time 
> comparisons such as:
> {code}
> ChangeSet changeSet = (ChangeSet) changelogSets.getChangeSets().get( 
> 0 );
> Calendar cal = Calendar.getInstance(); // new cal with default TZ
> cal.set( 1977, 7, 6, 5, 30, 0); // expected date from 
> min-changelog.xml
> cal.set( Calendar.MILLISECOND, 0);
> assertEquals( "Test changelog 1 set 1 date/time", 
> cal.getTime().getTime(), changeSet.getDate().getTime() );
> {code}
> Fail on my UK GMT machine with trace:
> {code}
> junit.framework.AssertionFailedError: Test changelog 1 set 1 date/time 
> expected:<23967180> but was:<23968620>
>   at junit.framework.Assert.fail(Assert.java:47)
>   at junit.framework.Assert.failNotEquals(Assert.java:282)
>   at junit.framework.Assert.assertEquals(Assert.java:64)
>   at junit.framework.Assert.assertEquals(Assert.java:136)
>   at 
> org.apache.maven.plugin.changelog.ChangeLogTest.testReadFile(ChangeLogTest.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 junit.framework.TestCase.runTest(TestCase.java:154)
>   at junit.framework.TestCase.runBare(TestCase.java:127)
>   at junit.framework.TestResult$1.protect(TestResult.java:106)
>   at junit.framework.TestResult.runProtected(TestResult.java:124)
>   at junit.framework.TestResult.run(TestResult.java:109)
>   at junit.framework.TestCase.run(TestCase.java:118)
>   at 
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> {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] Closed: (MDOCCK-3) Various problems with the plugin

2007-07-26 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg closed MDOCCK-3.


   Resolution: Fixed
Fix Version/s: 1.0-beta-2

All the issues have now been resolved.

> Various problems with the plugin
> 
>
> Key: MDOCCK-3
> URL: http://jira.codehaus.org/browse/MDOCCK-3
> Project: Maven 2.x DOCCK Plugin
>  Issue Type: Improvement
>Affects Versions: 1.0-beta-1
> Environment: Maven 2.0.4
>Reporter: Jimisola Laursen
>Assignee: Dennis Lundberg
> Fix For: 1.0-beta-2
>
>
> P1. "[ERROR] Missing examples."
> Q1. What is actually missing? The directory? Files in that directory?
> Proposed solution: Provide a more detailed error message and document it. 
> Also, the SVN repo of DOCCK Plugin itself should act as a standard for 
> plugins so that plugin developers has an example to look at.
> P2. "[WARN]  license MIT license appears to have an invalid URL: 
> 'LICENSE.txt'. Error: no protocol: LICENSE.txt Trying to access it as a file 
> instead."
> Q2.  LICENSE.txt shows correctly in the generated site. The file is in the 
> same directory as the pom.xml. If I use file:// then I also get a warning 
> ("[WARN]  Non-HTTP license MIT license URL not verified."). Where shall the 
> file be placed and how should I specify the url?
> P3. "[ERROR] Cannot reach project site with URL: 
> 'http://mojo.codehaus.org/freemarker-maven-plugin'.
> [ERROR] Cannot reach scm with URL: 
> 'https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/freemarker-maven-plugin'.Error:
>  sun.security.validator.ValidatorException: PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target"
> Q3. The url 
> "https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/freemarker-maven-plugin";
>  works without any problems when I point to it in Firefox. What is the actual 
> problem?
> P4. "[ERROR] Missing base FAQ.(fml|html|xml|apt)."
> Q4. I have the file site/fml/FAQ.fml. It's added to site.xml and generates 
> correctly to html when generating the site. What is the actual 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] Issue Comment Edited: (MDOCCK-1) [plugins/docck] fail to run "org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Jdk14Logger does not implement Log"

2007-07-26 Thread Dennis Lundberg (JIRA)

[ 
http://jira.codehaus.org/browse/MDOCCK-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103391
 ] 

Dennis Lundberg edited comment on MDOCCK-1 at 7/26/07 1:33 PM:
---

This was fixed in beta-1.


 was:
This was fix in beta-1.

> [plugins/docck] fail to run 
> "org.apache.commons.logging.LogConfigurationException: Class 
> org.apache.commons.logging.impl.Jdk14Logger does not implement Log"
> 
>
> Key: MDOCCK-1
> URL: http://jira.codehaus.org/browse/MDOCCK-1
> Project: Maven 2.x DOCCK Plugin
>  Issue Type: Bug
> Environment: maven 2.0.4
>Reporter: Jerome Lacoste
>Assignee: Dennis Lundberg
> Fix For: 1.0-beta-1
>
> Attachments: mvn.log
>
>
> This happens when I try running it on the under the 
> mojo/webstart-maven-plugin/plugin directory

-- 
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: (MDOCCK-3) Various problems with the plugin

2007-07-26 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg updated MDOCCK-3:
-

 Assignee: Dennis Lundberg
Affects Version/s: 1.0-beta-1

> Various problems with the plugin
> 
>
> Key: MDOCCK-3
> URL: http://jira.codehaus.org/browse/MDOCCK-3
> Project: Maven 2.x DOCCK Plugin
>  Issue Type: Improvement
>Affects Versions: 1.0-beta-1
> Environment: Maven 2.0.4
>Reporter: Jimisola Laursen
>Assignee: Dennis Lundberg
> Fix For: 1.0-beta-2
>
>
> P1. "[ERROR] Missing examples."
> Q1. What is actually missing? The directory? Files in that directory?
> Proposed solution: Provide a more detailed error message and document it. 
> Also, the SVN repo of DOCCK Plugin itself should act as a standard for 
> plugins so that plugin developers has an example to look at.
> P2. "[WARN]  license MIT license appears to have an invalid URL: 
> 'LICENSE.txt'. Error: no protocol: LICENSE.txt Trying to access it as a file 
> instead."
> Q2.  LICENSE.txt shows correctly in the generated site. The file is in the 
> same directory as the pom.xml. If I use file:// then I also get a warning 
> ("[WARN]  Non-HTTP license MIT license URL not verified."). Where shall the 
> file be placed and how should I specify the url?
> P3. "[ERROR] Cannot reach project site with URL: 
> 'http://mojo.codehaus.org/freemarker-maven-plugin'.
> [ERROR] Cannot reach scm with URL: 
> 'https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/freemarker-maven-plugin'.Error:
>  sun.security.validator.ValidatorException: PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target"
> Q3. The url 
> "https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/freemarker-maven-plugin";
>  works without any problems when I point to it in Firefox. What is the actual 
> problem?
> P4. "[ERROR] Missing base FAQ.(fml|html|xml|apt)."
> Q4. I have the file site/fml/FAQ.fml. It's added to site.xml and generates 
> correctly to html when generating the site. What is the actual 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: (MEAR-73) Property to disable transitive dependencies resolving

2007-07-26 Thread Thomas Hart (JIRA)

[ 
http://jira.codehaus.org/browse/MEAR-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103389
 ] 

Thomas Hart commented on MEAR-73:
-

I mean that the 
[dependency:resolve|http://maven.apache.org/plugins/maven-dependency-plugin/resolve-mojo.html]
 with the property {{excludeTransitive}} don't have any effects to the ear 
plugin.

The patch works for me. The following pom.xml produces the right ear (see 
image). Only the {{dependencies}} are included *not* the transitive 
dependencies.
{code:xml}
...
 
org.apache.maven.plugins
maven-ear-plugin
2.3.1-SNAPSHOT

  true
  5
  lib
  

  suite4p.enabler.jb402
  suite4p.enabler.jb402.server

  
  
4
  

  

  
  
  

  suite4p.enabler.jb402
  suite4p.enabler.jb402.server
  ejb

  
{code}

> Property to disable transitive dependencies resolving
> -
>
> Key: MEAR-73
> URL: http://jira.codehaus.org/browse/MEAR-73
> Project: Maven 2.x Ear Plugin
>  Issue Type: Improvement
>Reporter: Thomas Hart
>Assignee: Stephane Nicoll
> Attachments: patch.txt
>
>
> We have ears with a lot of modules. So the transitive dependencies are very 
> huge and to exclude all these with {{true}} is no 
> option. Also to mark these dependencies with optional is no way. It is 
> possible to create a new property for that?

-- 
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: (MJAVADOC-137) javadoc:javadoc always runs as "aggregator"

2007-07-26 Thread John Allen (JIRA)

[ 
http://jira.codehaus.org/browse/MJAVADOC-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103388
 ] 

John Allen commented on MJAVADOC-137:
-

If you run the javadoc plugin as report then the @aggregator is ignored (see 
MNG-2184), I have removed the @aggregator from my local version of the plugin 
and it passes all its tests but i expect the JavadocJarMojo might suffer 
(haven't tested yet and i would have too look at the code some more). 
Personally I cant see why one would want any of the javadoc mojo's 
functionality to run as an aggregator. Note the 'aggregate' report mojo option 
is actually implemented inside the mojo, ie. the report exits if it's already 
been run in the reactor and aggregate is true.

> javadoc:javadoc always runs as "aggregator"
> ---
>
> Key: MJAVADOC-137
> URL: http://jira.codehaus.org/browse/MJAVADOC-137
> Project: Maven 2.x Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Peter Hendriks
>Priority: Critical
>
> In version 2.2, javadoc aggregation was configurable using the configuration 
> property "aggregate". In version 2.3, all javadoc goals got the @aggregator 
> attribute added to its mojos (through a change in 
> org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java), and the goals now 
> always run aggregated regardless of the configuration setting. This breaks 
> our build as we require non-aggregated javadoc execution in our multi-module 
> poms. Please fix this so this is once again configurable and backwards 
> compatible with previous versions of the javadoc plug-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: (MEAR-73) Property to disable transitive dependencies resolving

2007-07-26 Thread Stephane Nicoll (JIRA)

[ 
http://jira.codehaus.org/browse/MEAR-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103386
 ] 

Stephane Nicoll commented on MEAR-73:
-

no It won't do what you expect.

> Property to disable transitive dependencies resolving
> -
>
> Key: MEAR-73
> URL: http://jira.codehaus.org/browse/MEAR-73
> Project: Maven 2.x Ear Plugin
>  Issue Type: Improvement
>Reporter: Thomas Hart
>Assignee: Stephane Nicoll
> Attachments: patch.txt
>
>
> We have ears with a lot of modules. So the transitive dependencies are very 
> huge and to exclude all these with {{true}} is no 
> option. Also to mark these dependencies with optional is no way. It is 
> possible to create a new property for that?

-- 
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: (SCM-332) Perforce provider give one changeset entry for each file

2007-07-26 Thread Jean-Pierre Matsumoto (JIRA)
Perforce provider give one changeset entry for each file


 Key: SCM-332
 URL: http://jira.codehaus.org/browse/SCM-332
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-perforce
Affects Versions: 2.0
 Environment: MacOSX
Reporter: Jean-Pierre Matsumoto
 Attachments: p4-group_entries.patch

When I call mvn changelog:changelog on my Perforce project, I get one entry in 
changelog for each couple (changelist,file) instead of one entry for each 
changelist.

I have a patch to solve this bug. I group relevant entries.

I updated existing TestCase. And I tested on my project and the bug is solved 
with this patch.

-- 
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: (MSITE-132) Use instead of for directories

2007-07-26 Thread John Allen (JIRA)

[ 
http://jira.codehaus.org/browse/MSITE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103374
 ] 

John Allen commented on MSITE-132:
--

Guess I'm not explaining myself very well :) 

Re the name being used to create the path in the stage mojo when the POM has no 
distributionManagement section defined - that sounds like a mistake to me and 
thus my [comment to 
Denis|http://jira.codehaus.org/browse/MSITE-132#action_103351]. 

Additionally re Jorg's statements about what and how stage should work. It 
works based off maven's distributionManagement section to achieve the use case 
of 'mirroring' or staging a deployment to a local file-system location for 
local review before real deployment to the project's published location is 
performed. It does that just fine and is used by lots of users. Additionally, 
being a core plugin, it is designed to support the main Maven usage scenarios, 
if you don't do it that way, or want to do it another way, you are of course 
free to create your own plugin.

For a wider discussion about Maven's usage including it's plugins i recommend 
the [Maven Users Mailing List|http://www.nabble.com/Maven---Users-f178.html]

Lastly, I didn't write these plugins so have absolutely no say on their design 
but as an OSS project we can all contribute to Maven's improvement. Start on 
the mailing lists and see how others use it, you never know maybe everyone will 
agree and the core developers will consider a redesign.

> Use  instead of  for directories
> --
>
> Key: MSITE-132
> URL: http://jira.codehaus.org/browse/MSITE-132
> Project: Maven 2.x Site Plugin
>  Issue Type: Improvement
> Environment: maven-2.0.4 on any operating system with the latests 
> released plugins (after the doxia-1.0-alpha-8.pom bug)
>Reporter: Jörg Hohwiller
> Attachments: MSITE-132.patch
>
>
> The  of a project in the POM may contain characters that cause trouble 
> when used in directory names.
> E.g. my open-source project: 
> http://svn.projxpert.com/mmm/trunk/
> Uses names such as "MMM::Configuration". Now when I stage the site of the 
> entire project, the relative link "MMM::Configuration" causes mozilla to say 
> something like "Unknown protocol 'mmm:'".
> Could you please use the artefactId instead. 
> I think personally think that this is a lot better anyways.
> BTW - Thanks for your greate work. M2 is awesome!!!

-- 
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: (MAVENUPLOAD-1656) Netty2 1.9.2 Upload Request

2007-07-26 Thread Trustin Lee (JIRA)
Netty2 1.9.2 Upload Request
---

 Key: MAVENUPLOAD-1656
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1656
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Trustin Lee
 Attachments: netty2-1.9.2-bundle.jar

Netty2 is an event-driven NIO framework and the ancestor of Apache MINA.

Apache MINA provides a few utility classes for smooth migration from Netty2 to 
Apache MINA, and therefore one of the MINA submodules depends of Netty2.  And 
there are some people out there who uses Netty2 for historical reason.

-- 
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: (MEAR-73) Property to disable transitive dependencies resolving

2007-07-26 Thread Thomas Hart (JIRA)

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

Thomas Hart updated MEAR-73:


Attachment: patch.txt

> Property to disable transitive dependencies resolving
> -
>
> Key: MEAR-73
> URL: http://jira.codehaus.org/browse/MEAR-73
> Project: Maven 2.x Ear Plugin
>  Issue Type: Improvement
>Reporter: Thomas Hart
>Assignee: Stephane Nicoll
> Attachments: patch.txt
>
>
> We have ears with a lot of modules. So the transitive dependencies are very 
> huge and to exclude all these with {{true}} is no 
> option. Also to mark these dependencies with optional is no way. It is 
> possible to create a new property for that?

-- 
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: (MJAVADOC-137) javadoc:javadoc always runs as "aggregator"

2007-07-26 Thread Peter Hendriks (JIRA)
javadoc:javadoc always runs as "aggregator"
---

 Key: MJAVADOC-137
 URL: http://jira.codehaus.org/browse/MJAVADOC-137
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Peter Hendriks
Priority: Critical


In version 2.2, javadoc aggregation was configurable using the configuration 
property "aggregate". In version 2.3, all javadoc goals got the @aggregator 
attribute added to its mojos (through a change in 
org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java), and the goals now 
always run aggregated regardless of the configuration setting. This breaks our 
build as we require non-aggregated javadoc execution in our multi-module poms. 
Please fix this so this is once again configurable and backwards compatible 
with previous versions of the javadoc plug-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] Issue Comment Edited: (MNG-41) best practices: site management

2007-07-26 Thread John Allen (JIRA)

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

John Allen edited comment on MNG-41 at 7/26/07 6:54 AM:


I know I've been banging this drum from day one so I'm obviously off 'Maven 
message' in this regard but as far as i can see a maven site is just another 
type of artifact generated by a project. It has all the same aspects, couplings 
et al as the other products of a project and should not be seen as a convenient 
way to knock up your OSS web pages. 

Corporate use of a maven project site is to render the human readable view on 
the project's constructs (UML models, javadoc, analysis reports, and yes even 
user guides) and is thus directly coupled to the version that generated it. 
This then leads to POMs with project.urls and distro.site.urls like this:

{code}


projects.examples.site.deployment
Examples: Site Deployment


dav:https://maven.example.com/maven/site/${scm.repositoryName}/${project.groupId}/${project.artifactId}/${project.version}


${project.url}




http://projects.examples.com/${scm.repositoryName}/${project.groupId}/${project.artifactId}/${project.version}


{code}

Thus all our deployed sites attempt to maintain the rigour of a true version 
controlled namespace. 

How we then map to the 'latest' of these is another point, and again, one I 
have written about before; currently we do this, in the absence of real 
repository, with server side scripting (aka PHP hack) as there is no real 
'release' semantic and we can't really afford to go creating one at the moment.

Hope I'm not missing the point and slipping into rant mode (I'm in bed with 
flu!)

Re the staging - we don't currently do that in the same public way you have to. 
At the moment we simply 'export' the SNAPSHOTs and get internal peer review 
from those (version info is not lost on ours) and if we had to do 
release:prepare then i would have the distro locations to point to a real 
sandbox staging environment and get QA acceptance there before performing a 
real release. 


 was:
I know I've been banging this drum from day one so I'm obviously off 'Maven 
message' in this regard but as far as i can see a maven site is just another 
type of artifact generated by a project. It has all the same aspects, couplings 
et al as the other products of a project and should not be seen as a convenient 
way to knock up your OSS web pages. 

Corporate use of a maven project site is to render the human readable view on 
the project's constructs (UML models, javadoc, analysis reports, and yes even 
user guides) and is thus directly coupled to the version that generated it. 
This then leads to POMs with project.urls and distro.site.urls like this:

{code}


projects.examples.site.deployment
Examples: Site Deployment


dav:https://maven.example.com/maven/site/${scm.repositoryName}/${project.groupId}/${project.artifactId}/${project.version}


${project.url}




http://projects.examples.com/${scm.repositoryName}/${project.groupId}/${project.artifactId}/${project.version}


{code}

Thus all our deployed sites attempt to maintain the rigour of a true version 
controlled namespace. 

How we then map to the 'latest' of these is another point, and again, one I 
have written about before; currently we do this, in the absence of real 
repository, with server side scripting (aka PHP hack) as there is no real 
'release' semantic and we can't really afford to go creating one at the moment.

Hope I've not missing the point.

Re the staging - we don't currently do that in the same public way you have to. 
At the moment we simply 'export' the SNAPSHOTs and get internal peer review 
from those (version info is not lost on ours) and if we had to do 
release:prepare then i would have the distro locations to point to a real 
sandbox staging environment and get QA acceptance there before performing a 
real release. 

> best practices: site management
> ---
>
> Key: MNG-41
> URL: http://jira.codehaus.org/browse/MNG-41
> Project: Maven 2
>  Issue Type: Task
>  Components: Design, Patterns & Best Practices
>Reporter: Jason van Zyl
>Priority: Trivial
> Fix For: 2.1.x
>
>
> * How to deal with multiple versions of the site
> * How to deal with staging directories for the site (will require a change to 
> the POM)

-- 
This message is automatically generated by JIRA.
-
If you thi

[jira] Commented: (MNG-367) best practices: multi-user installation

2007-07-26 Thread John Allen (JIRA)

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

John Allen commented on MNG-367:


Re installers - We deploy our developers java environment via a nice looking 
NSIS installer (all built using m2 of course) Anyway, that puts in place the 
m2, then runs (optionally) the JDK, SVN, Tortoise installers and sets up a 
correct m2/conf/settings and $HOME/.m2 as well as defines MVN_OPTS to ensure 
the correct keystore info is passed to the JVM so that webdav deployments work. 
Not hard. And because of the per user env and HOME setup works for multiple 
users on the same box.



> best practices: multi-user installation
> ---
>
> Key: MNG-367
> URL: http://jira.codehaus.org/browse/MNG-367
> Project: Maven 2
>  Issue Type: Task
>  Components: Design, Patterns & Best Practices
>Reporter: Brett Porter
>Priority: Trivial
> Fix For: 2.1.x
>
>
> so we need to support:
> - read only install
> - setttings in the installation
> - works with just the m2 executable in the path (no M2_HOME setting)
> - possibility of a remote settings file for standalone installs, force a 
> regular (daily) check when online to push updates
> encourage:
> - storing of install on a shared, read only drive
> - possibly use a CVS checkout
> - may want to integrate with existing deployment policies (eg an MSI that can 
> be easily deployed)

-- 
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-311) Project build error null

2007-07-26 Thread Thomas Hart (JIRA)
Project build error null


 Key: MECLIPSE-311
 URL: http://jira.codehaus.org/browse/MECLIPSE-311
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
Reporter: Thomas Hart
Priority: Critical


In the problem view is a {{Project build error null}} entry for a pom.xml file. 
Also on the console i get the same message. I don't know why it happens. I have 
126 POM Files and sometimes some of these get this error message.

Plugin Version: 0.0.11.20070603-1200

-- 
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: (MSITE-159) Absolute URI rendered as relative URI if absolute URI related to domain of POM URI

2007-07-26 Thread John Allen (JIRA)

[ 
http://jira.codehaus.org/browse/MSITE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103352
 ] 

John Allen commented on MSITE-159:
--

I think something along the lines of 'convert URLs to relative URLs where 
possible' is sensible.

Note that even relatives can be converted into better relatives. i.e.

foo/bar/../../foo/bar/../ is the same as ..


> Absolute URI rendered as relative URI if absolute URI related to domain of 
> POM URI
> --
>
> Key: MSITE-159
> URL: http://jira.codehaus.org/browse/MSITE-159
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>Reporter: Ted Husted
>
> Under site-beta5 
> if the POM references a URI like 
>   http://struts.apache.org
> absolute URLs used in the site.xml file are converted to relative references. 
> For example a reference to to "http://struts.apache.org/1.x"; becomes "1.x",  
> and a reference to
> just "http://struts.apache.org"; becomes an empty string.  
> If the documentation is being used offline, there are many cases when we want 
> to refer people back to the website, to be sure the current information is 
> used. The best use case is a download page that determines the mirror via 
> CGI. 
> Another use case is referring to a sister site in the domain, that might 
> refer to another version. If used locally, the other site might not be in the 
> relative location. 
> Switching back to beta4 cures the behavior, and absolute URIs remain 
> absolute, as expected. 

-- 
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: (MSITE-129) modules list empty if modules don't use this project as parent in reactor build

2007-07-26 Thread Matt Read (JIRA)

[ 
http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103353
 ] 

Matt Read commented on MSITE-129:
-

Yep, horses for courses sounds about right. Certainly my example was fairly 
simple and there is a strong likelihood of some mix and matching of approaches 
when the hierarchies get deeper.

Both our examples seem to reinforce the notion that the site plug-in should 
represent both inheritance and composition relationships regardless of how they 
are being used.

> modules list empty if modules don't use this project as parent in reactor 
> build
> ---
>
> Key: MSITE-129
> URL: http://jira.codehaus.org/browse/MSITE-129
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>Affects Versions: 2.0-beta-5
>Reporter: Kenney Westerhof
>Assignee: Kenney Westerhof
>Priority: Minor
> Fix For: 2.0-beta-7
>
>
> The code in the AbstractSiteRenderingMojo does the following:
> - if it's running in a reactor build (i.e. more than 1 project in the reactor 
> projects) it scans all
> projects to see if it's parent project equals the current project. If so, 
> it's marked as a module.
> - if it's running on a single project, the project.build.modules is consulted 
> and those modules
> are marked as modules.
> I've got a 'fake' root pom, for utility purposes: it lists all projects as 
> modules so that I can easily
> built everything and generate a site. However, this fake root pom is never 
> used as a parent - there's
> a /pom/pom.xml project for that.
> The result of this is that the modules list is empty.
> A workaround is to first run 'mvn site' and then 'mvn site -N'.
> I'm not sure what the correct solution should be - basically now 2 site 
> layouts are implemented:
> - a physical layout where the modules match the  section of the pom, 
> reflecting filesystem layout,
> - a project hierarchy layout based on 
> and one or the other is used depending on wheter the build contains more than 
> 1 project or not.
> My first feeling is that since the tag is called ${modules} (or  ref="modules"/>) that
> the site should use the , not the . 
> It should also take into consideration, that IF a reactor build is running, 
> it should only use the modules that are also
> in the reactor (so you can use -r -Dmaven.reactor.excludes=.. to generate a 
> site with not all projects in it).
> Thoughts?

-- 
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-41) best practices: site management

2007-07-26 Thread John Allen (JIRA)

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

John Allen commented on MNG-41:
---

I know I've been banging this drum from day one so I'm obviously off 'Maven 
message' in this regard but as far as i can see a maven site is just another 
type of artifact generated by a project. It has all the same aspects, couplings 
et al as the other products of a project and should not be seen as a convenient 
way to knock up your OSS web pages. 

Corporate use of a maven project site is to render the human readable view on 
the project's constructs (UML models, javadoc, analysis reports, and yes even 
user guides) and is thus directly coupled to the version that generated it. 
This then leads to POMs with project.urls and distro.site.urls like this:

{code}


projects.examples.site.deployment
Examples: Site Deployment


dav:https://maven.example.com/maven/site/${scm.repositoryName}/${project.groupId}/${project.artifactId}/${project.version}


${project.url}




http://projects.examples.com/${scm.repositoryName}/${project.groupId}/${project.artifactId}/${project.version}


{code}

Thus all our deployed sites attempt to maintain the rigour of a true version 
controlled namespace. 

How we then map to the 'latest' of these is another point, and again, one I 
have written about before; currently we do this, in the absence of real 
repository, with server side scripting (aka PHP hack) as there is no real 
'release' semantic and we can't really afford to go creating one at the moment.

Hope I've not missing the point.

Re the staging - we don't currently do that in the same public way you have to. 
At the moment we simply 'export' the SNAPSHOTs and get internal peer review 
from those (version info is not lost on ours) and if we had to do 
release:prepare then i would have the distro locations to point to a real 
sandbox staging environment and get QA acceptance there before performing a 
real release. 

> best practices: site management
> ---
>
> Key: MNG-41
> URL: http://jira.codehaus.org/browse/MNG-41
> Project: Maven 2
>  Issue Type: Task
>  Components: Design, Patterns & Best Practices
>Reporter: Jason van Zyl
>Priority: Trivial
> Fix For: 2.1.x
>
>
> * How to deal with multiple versions of the site
> * How to deal with staging directories for the site (will require a change to 
> the POM)

-- 
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: (MANTTASKS-67) artifact:deploy - The name of deploying element in snapshot repository is wrong

2007-07-26 Thread Herve Boutemy (JIRA)

[ 
http://jira.codehaus.org/browse/MANTTASKS-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103314
 ] 

Herve Boutemy edited comment on MANTTASKS-67 at 7/26/07 2:01 AM:
-

Here is a fix for the attachment numbering problem.

For -SNAPSHOT vs .-, it's a question of supporting 
whether uniqueVersion="false" or uniqueVersion="true": such configuration 
support is a feature added in MANTTASKS-23


 was:
Here is a fix...

> artifact:deploy - The name of deploying element in snapshot repository is 
> wrong
> ---
>
> Key: MANTTASKS-67
> URL: http://jira.codehaus.org/browse/MANTTASKS-67
> Project: Maven 2.x Ant Tasks
>  Issue Type: Bug
>  Components: deploy task
>Affects Versions: 2.0.6, 2.0.7
>Reporter: David N'DIAYE
> Fix For: 2.0.8
>
> Attachments: MANTTASKS-67.diff, testSnapshots.zip
>
>
> The zip file contains test with Ant.
> To launch it : ant test.
> I try to deploy a snapshot artifact in repository
> So, my pom.xml contains a version with the extension '-SNAPSHOT'
> And in my build file Ant i do this :
> 
>
>
>
> In the repository the name of the artifact is 
> --SNAPSHOT. instead of 
> --.--
> Another problem, i try to upload 2 attachments with my artifact (javadoc and 
> java-source), and the buildNumber in the meta-data.xml increment by 3 instead 
> of 1
> 
>
>
>
>
>
> You can test it with : ant testWithAttach

-- 
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: (MRM-294) Repository purge feature for snapshots

2007-07-26 Thread Maria Odea Ching (JIRA)

[ 
http://jira.codehaus.org/browse/MRM-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103334
 ] 

Maria Odea Ching commented on MRM-294:
--

Thanks for your comments Barrie :)

Anyway, there was also a discussion regarding this issue and MRM-275 as well in 
the Archiva Dev List. I've summarized below what has been agreed upon in the 
thread. For reference purposes, the subject of the thread was "Repository purge 
(MRM-294 and MRM-275)". Please feel free to add more..

Summary:
1. Configuration will be for each repository - the repository purge will be 
implemented as a consumer, which will be executed during repository scanning. 
Configuration will be incorporated on the repository configuration page.
2. Repository purge is configurable in archiva.xml
3. Snapshot retention policies will also be for each repository.

For #3, these are the policies to be implemented:
a. any artifacts that are not in active development will be deleted entirely 
(eg, 1.0-SNAPSHOT when 1.0 is released)
b. time based** (e.g. any builds older than 1 month)
c. artifact count retention** (e.g. if user specified "5", then archiva would 
keep 5 in total of the latest.. like 1.1-20070506.121113-1, 
1.1-20070506.121113-2, 1.1-20070506.121113-3, 1.1-20070506.121113-4, 
1.1-20070506.121113-5 and NOT 1.1-SNAPSHOT, 1.2-SNAPSHOT, 1.3-SNAPSHOT, 
1.4-SNAPSHOT, 1.5-SNAPSHOT)

**user will have the option to choose from either of these two criteria



> Repository purge feature for snapshots
> --
>
> Key: MRM-294
> URL: http://jira.codehaus.org/browse/MRM-294
> Project: Archiva
>  Issue Type: New Feature
>Affects Versions: 1.0-alpha-1
>Reporter: Wendy Smoak
>Assignee: Maria Odea Ching
> Fix For: 1.0-beta-1
>
>
> We need a way to purge a repository of snapshots older than a certain date, 
> (optionally retaining the most recent one) and fixing the metadata.

-- 
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: (MANTTASKS-67) artifact:deploy - The name of deploying element in snapshot repository is wrong

2007-07-26 Thread Herve Boutemy (JIRA)

[ 
http://jira.codehaus.org/browse/MANTTASKS-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103314
 ] 

Herve Boutemy edited comment on MANTTASKS-67 at 7/26/07 2:02 AM:
-

Here is a fix for the attachment numbering problem.

For x-SNAPSHOT vs x-.-, it's a question of supporting 
whether uniqueVersion="false" or uniqueVersion="true": such configuration 
support is a feature added in MANTTASKS-23


 was:
Here is a fix for the attachment numbering problem.

For -SNAPSHOT vs .-, it's a question of supporting 
whether uniqueVersion="false" or uniqueVersion="true": such configuration 
support is a feature added in MANTTASKS-23

> artifact:deploy - The name of deploying element in snapshot repository is 
> wrong
> ---
>
> Key: MANTTASKS-67
> URL: http://jira.codehaus.org/browse/MANTTASKS-67
> Project: Maven 2.x Ant Tasks
>  Issue Type: Bug
>  Components: deploy task
>Affects Versions: 2.0.6, 2.0.7
>Reporter: David N'DIAYE
> Fix For: 2.0.8
>
> Attachments: MANTTASKS-67.diff, testSnapshots.zip
>
>
> The zip file contains test with Ant.
> To launch it : ant test.
> I try to deploy a snapshot artifact in repository
> So, my pom.xml contains a version with the extension '-SNAPSHOT'
> And in my build file Ant i do this :
> 
>
>
>
> In the repository the name of the artifact is 
> --SNAPSHOT. instead of 
> --.--
> Another problem, i try to upload 2 attachments with my artifact (javadoc and 
> java-source), and the buildNumber in the meta-data.xml increment by 3 instead 
> of 1
> 
>
>
>
>
>
> You can test it with : ant testWithAttach

-- 
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: (MJAVADOC-138) javadoc:test-javadoc failed if target/classes not already created

2007-07-26 Thread Vincent Siveton (JIRA)
javadoc:test-javadoc failed if target/classes not already created
-

 Key: MJAVADOC-138
 URL: http://jira.codehaus.org/browse/MJAVADOC-138
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Vincent Siveton


Using 
{noformat}
mvn clean javadoc:test-javadoc
{noformat}
it could produce unsuccessful build or warning (depending the javadoc version 
used, i.e 1.4 vs 1.5)

The options file contains:
{noformat}
-classpath '[SNIP]/target/classes;[SNIP]/target/tests-classes;...'
{noformat}

The explanation is that no target\classes was created before executing 
test-javadoc

-- 
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: (MCHANGELOG-68) testReadFile unit test timebased comparisons fail

2007-07-26 Thread Dennis Lundberg (JIRA)

[ 
http://jira.codehaus.org/browse/MCHANGELOG-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103418
 ] 

Dennis Lundberg commented on MCHANGELOG-68:
---

I can confirm that this is a bug. As a workaround you can set the timezone in 
your OS to GMT+1. I know, it's not pretty but it's a workaround.

> testReadFile unit test timebased comparisons fail
> -
>
> Key: MCHANGELOG-68
> URL: http://jira.codehaus.org/browse/MCHANGELOG-68
> Project: Maven 2.x Changelog Plugin
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: 2.0.7
>Reporter: John Allen
>
> The unit tests in ChangeLogTest that test the changeset file for time 
> comparisons such as:
> {code}
> ChangeSet changeSet = (ChangeSet) changelogSets.getChangeSets().get( 
> 0 );
> Calendar cal = Calendar.getInstance(); // new cal with default TZ
> cal.set( 1977, 7, 6, 5, 30, 0); // expected date from 
> min-changelog.xml
> cal.set( Calendar.MILLISECOND, 0);
> assertEquals( "Test changelog 1 set 1 date/time", 
> cal.getTime().getTime(), changeSet.getDate().getTime() );
> {code}
> Fail on my UK GMT machine with trace:
> {code}
> junit.framework.AssertionFailedError: Test changelog 1 set 1 date/time 
> expected:<23967180> but was:<23968620>
>   at junit.framework.Assert.fail(Assert.java:47)
>   at junit.framework.Assert.failNotEquals(Assert.java:282)
>   at junit.framework.Assert.assertEquals(Assert.java:64)
>   at junit.framework.Assert.assertEquals(Assert.java:136)
>   at 
> org.apache.maven.plugin.changelog.ChangeLogTest.testReadFile(ChangeLogTest.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 junit.framework.TestCase.runTest(TestCase.java:154)
>   at junit.framework.TestCase.runBare(TestCase.java:127)
>   at junit.framework.TestResult$1.protect(TestResult.java:106)
>   at junit.framework.TestResult.runProtected(TestResult.java:124)
>   at junit.framework.TestResult.run(TestResult.java:109)
>   at junit.framework.TestCase.run(TestCase.java:118)
>   at 
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
>   at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> {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] Updated: (MIDEA-102) CLONE -still broken - Module filepath is generated incorrectly

2007-07-26 Thread Joern Huxhorn (JIRA)

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

Joern Huxhorn updated MIDEA-102:


Attachment: maven-idea-plugin-MIDEA-102.patch

the problem still exists if the master-module is at the same level as the child 
module, e.g. C:\foo\master and C:\foo\child.

The attached patch fixes this problem.

> CLONE -still broken - Module filepath is generated incorrectly
> --
>
> Key: MIDEA-102
> URL: http://jira.codehaus.org/browse/MIDEA-102
> Project: Maven 2.x IDEA Plugin
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: $ mvn -v
> Maven version: 2.0.7
> Java version: 1.5.0_11
> OS name: "windows xp" version: "5.1" arch: "x86"
> cygwin
>Reporter: Joern Huxhorn
>Assignee: Dennis Lundberg
> Fix For: 2.2
>
> Attachments: maven-idea-plugin-MIDEA-102.patch
>
>
> I have a multi-module mvn project.
> When I do an mvn idea:clean idea:idea, the following ProjectModuleManager 
> snippet in the top level .ipr is generated:
>  
>  
> 
>   
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/>
>  
>   
> The $PROJECT_DIR in this case is C:/dev/voca/gateway/.
> But this path is being appended in a hard-coded fashion after the 
> $PROJECT_DIR entry.
> The symptom in Intellij is the following error message:
> Cannot load module: File 
> C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not 
> exist
> Would you like to remove the module from the project?
> The workaround is to delete the extra appended file path from each module 
> entry in the above mentioned snippet.

-- 
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: (MCHANGELOG-71) Support a %REV% in displayFileDetailUrl in the same way we support %FILE

2007-07-26 Thread John Allen (JIRA)
Support a %REV% in displayFileDetailUrl in the same way we support %FILE


 Key: MCHANGELOG-71
 URL: http://jira.codehaus.org/browse/MCHANGELOG-71
 Project: Maven 2.x Changelog Plugin
  Issue Type: Improvement
Affects Versions: 2.1, 2.2
Reporter: John Allen


Reports are historical and by providing this we can keep the links to actual 
revisions of the files.

-- 
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: (MCHANGELOG-68) testReadFile unit test timebased comparisons fail

2007-07-26 Thread John Allen (JIRA)
testReadFile unit test timebased comparisons fail
-

 Key: MCHANGELOG-68
 URL: http://jira.codehaus.org/browse/MCHANGELOG-68
 Project: Maven 2.x Changelog Plugin
  Issue Type: Bug
Affects Versions: 2.2
 Environment: 2.0.7
Reporter: John Allen


The unit tests in ChangeLogTest that test the changeset file for time 
comparisons such as:

{code}
ChangeSet changeSet = (ChangeSet) changelogSets.getChangeSets().get( 0 
);


Calendar cal = Calendar.getInstance(); // new cal with default TZ

cal.set( 1977, 7, 6, 5, 30, 0); // expected date from min-changelog.xml

cal.set( Calendar.MILLISECOND, 0);


assertEquals( "Test changelog 1 set 1 date/time", 
cal.getTime().getTime(), changeSet.getDate().getTime() );
{code}

Fail on my UK GMT machine with trace:

{code}
junit.framework.AssertionFailedError: Test changelog 1 set 1 date/time 
expected:<23967180> but was:<23968620>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:136)
at 
org.apache.maven.plugin.changelog.ChangeLogTest.testReadFile(ChangeLogTest.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 junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at 
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at 
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

{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: (MDOCCK-3) Various problems with the plugin

2007-07-26 Thread Dennis Lundberg (JIRA)

[ 
http://jira.codehaus.org/browse/MDOCCK-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103394
 ] 

Dennis Lundberg commented on MDOCCK-3:
--

I was wrong about 3 in my previous comment.

It was the scm URL 
https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/freemarker-maven-plugin 
that wasn't working. I have tried it now and I don't get the error that you 
got. I think it might have had something to do with a problem in the 
certificate chain for https.

> Various problems with the plugin
> 
>
> Key: MDOCCK-3
> URL: http://jira.codehaus.org/browse/MDOCCK-3
> Project: Maven 2.x DOCCK Plugin
>  Issue Type: Improvement
>Affects Versions: 1.0-beta-1
> Environment: Maven 2.0.4
>Reporter: Jimisola Laursen
> Fix For: 1.0-beta-2
>
>
> P1. "[ERROR] Missing examples."
> Q1. What is actually missing? The directory? Files in that directory?
> Proposed solution: Provide a more detailed error message and document it. 
> Also, the SVN repo of DOCCK Plugin itself should act as a standard for 
> plugins so that plugin developers has an example to look at.
> P2. "[WARN]  license MIT license appears to have an invalid URL: 
> 'LICENSE.txt'. Error: no protocol: LICENSE.txt Trying to access it as a file 
> instead."
> Q2.  LICENSE.txt shows correctly in the generated site. The file is in the 
> same directory as the pom.xml. If I use file:// then I also get a warning 
> ("[WARN]  Non-HTTP license MIT license URL not verified."). Where shall the 
> file be placed and how should I specify the url?
> P3. "[ERROR] Cannot reach project site with URL: 
> 'http://mojo.codehaus.org/freemarker-maven-plugin'.
> [ERROR] Cannot reach scm with URL: 
> 'https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/freemarker-maven-plugin'.Error:
>  sun.security.validator.ValidatorException: PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target"
> Q3. The url 
> "https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/freemarker-maven-plugin";
>  works without any problems when I point to it in Firefox. What is the actual 
> problem?
> P4. "[ERROR] Missing base FAQ.(fml|html|xml|apt)."
> Q4. I have the file site/fml/FAQ.fml. It's added to site.xml and generates 
> correctly to html when generating the site. What is the actual 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] Closed: (MDOCCK-1) [plugins/docck] fail to run "org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Jdk14Logger does not implement Log"

2007-07-26 Thread Dennis Lundberg (JIRA)

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

Dennis Lundberg closed MDOCCK-1.


 Assignee: Dennis Lundberg
   Resolution: Fixed
Fix Version/s: 1.0-beta-1

This was fix in beta-1.

> [plugins/docck] fail to run 
> "org.apache.commons.logging.LogConfigurationException: Class 
> org.apache.commons.logging.impl.Jdk14Logger does not implement Log"
> 
>
> Key: MDOCCK-1
> URL: http://jira.codehaus.org/browse/MDOCCK-1
> Project: Maven 2.x DOCCK Plugin
>  Issue Type: Bug
> Environment: maven 2.0.4
>Reporter: Jerome Lacoste
>Assignee: Dennis Lundberg
> Fix For: 1.0-beta-1
>
> Attachments: mvn.log
>
>
> This happens when I try running it on the under the 
> mojo/webstart-maven-plugin/plugin directory

-- 
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: (MEAR-73) Property to disable transitive dependencies resolving

2007-07-26 Thread Thomas Hart (JIRA)

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

Thomas Hart updated MEAR-73:


Attachment: ear.jpg

> Property to disable transitive dependencies resolving
> -
>
> Key: MEAR-73
> URL: http://jira.codehaus.org/browse/MEAR-73
> Project: Maven 2.x Ear Plugin
>  Issue Type: Improvement
>Reporter: Thomas Hart
>Assignee: Stephane Nicoll
> Attachments: ear.jpg, patch.txt
>
>
> We have ears with a lot of modules. So the transitive dependencies are very 
> huge and to exclude all these with {{true}} is no 
> option. Also to mark these dependencies with optional is no way. It is 
> possible to create a new property for that?

-- 
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: (MEAR-73) Property to disable transitive dependencies resolving

2007-07-26 Thread Stephane Nicoll (JIRA)

[ 
http://jira.codehaus.org/browse/MEAR-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103387
 ] 

Stephane Nicoll commented on MEAR-73:
-

WDYM when you say "it doen't work"?

> Property to disable transitive dependencies resolving
> -
>
> Key: MEAR-73
> URL: http://jira.codehaus.org/browse/MEAR-73
> Project: Maven 2.x Ear Plugin
>  Issue Type: Improvement
>Reporter: Thomas Hart
>Assignee: Stephane Nicoll
> Attachments: patch.txt
>
>
> We have ears with a lot of modules. So the transitive dependencies are very 
> huge and to exclude all these with {{true}} is no 
> option. Also to mark these dependencies with optional is no way. It is 
> possible to create a new property for that?

-- 
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: (MSITE-132) Use instead of for directories

2007-07-26 Thread Denis Cabasson (JIRA)

[ 
http://jira.codehaus.org/browse/MSITE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103377
 ] 

Denis Cabasson commented on MSITE-132:
--

I guess we basically all agree on this report. Its point is just changing name 
to artifactId, when no distributionManagement section is available.

Jörg later discussion should indeed be discussed somewhere else. Maybe in a 
wish task or an improvement.

For the time being, let's apply this patch on the trunk and get rid with it :)

> Use  instead of  for directories
> --
>
> Key: MSITE-132
> URL: http://jira.codehaus.org/browse/MSITE-132
> Project: Maven 2.x Site Plugin
>  Issue Type: Improvement
> Environment: maven-2.0.4 on any operating system with the latests 
> released plugins (after the doxia-1.0-alpha-8.pom bug)
>Reporter: Jörg Hohwiller
> Attachments: MSITE-132.patch
>
>
> The  of a project in the POM may contain characters that cause trouble 
> when used in directory names.
> E.g. my open-source project: 
> http://svn.projxpert.com/mmm/trunk/
> Uses names such as "MMM::Configuration". Now when I stage the site of the 
> entire project, the relative link "MMM::Configuration" causes mozilla to say 
> something like "Unknown protocol 'mmm:'".
> Could you please use the artefactId instead. 
> I think personally think that this is a lot better anyways.
> BTW - Thanks for your greate work. M2 is awesome!!!

-- 
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: (MSITE-132) Use instead of for directories

2007-07-26 Thread Denis Cabasson (JIRA)

[ 
http://jira.codehaus.org/browse/MSITE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103366
 ] 

Denis Cabasson commented on MSITE-132:
--

John,

I'm afraid I have to side with Jörg here.
Using the name, which is described in the POM descriptor as "The full name of 
the project.", doesn't looks sensible to me. Using the artifactId seems 
ways more coherent (with the distributionManagement behaviour at least).

> Use  instead of  for directories
> --
>
> Key: MSITE-132
> URL: http://jira.codehaus.org/browse/MSITE-132
> Project: Maven 2.x Site Plugin
>  Issue Type: Improvement
> Environment: maven-2.0.4 on any operating system with the latests 
> released plugins (after the doxia-1.0-alpha-8.pom bug)
>Reporter: Jörg Hohwiller
> Attachments: MSITE-132.patch
>
>
> The  of a project in the POM may contain characters that cause trouble 
> when used in directory names.
> E.g. my open-source project: 
> http://svn.projxpert.com/mmm/trunk/
> Uses names such as "MMM::Configuration". Now when I stage the site of the 
> entire project, the relative link "MMM::Configuration" causes mozilla to say 
> something like "Unknown protocol 'mmm:'".
> Could you please use the artefactId instead. 
> I think personally think that this is a lot better anyways.
> BTW - Thanks for your greate work. M2 is awesome!!!

-- 
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: (MJAVADOC-136) UmlGraph 4.8 - could not find map file

2007-07-26 Thread gvsg (JIRA)
UmlGraph 4.8 - could not find map file
--

 Key: MJAVADOC-136
 URL: http://jira.codehaus.org/browse/MJAVADOC-136
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
 Environment: Windows XP
Reporter: gvsg
Priority: Blocker


I'm using the maven-javadoc-plugin with the umlgraph doclet.
See below my partial pom.xml file.

org.apache.maven.plugins
maven-javadoc-plugin

true

gr.spinellis.umlgraph.doclet.UmlGraphDoc

  gr.spinellis
  UmlGraph
  4.8


   -inferrel -inferdep -quiet -hide 
java.*
   -collpackages java.util.* -qualify
   -postfixpackage -nodefontsize 9
   -nodefontpackagesize 7
 




When executing the javadoc plugin I receive the following error:

[WARNING] javadoc: warning - Could not find map file 
.\com\vangenechten\system\order\service\ConfirmationSloganManagementBean.map
[WARNING] java.io.IOException: CreateProcess: dot -Tcmapx -o 
E:\erp\java\systems\order\internals\target\site\apidocs\.\com\vangenechten\system\order\service\CommercialDivisionManagementBean.map
 -Tpng -o 
E:\erp\java\systems\order\internals\target\site\apidocs\.\com\vangenechten\system\order\service\C
ommercialDivisionManagementBean.png 
E:\erp\java\systems\order\internals\target\site\apidocs\.\com\vangenechten\system\order\service\CommercialDivisionManagementBean.dot
 error=2
[WARNING] at java.lang.ProcessImpl.create(Native Method)
[WARNING] at java.lang.ProcessImpl.(ProcessImpl.java:81)
[WARNING] at java.lang.ProcessImpl.start(ProcessImpl.java:30)
[WARNING] at java.lang.ProcessBuilder.start(ProcessBuilder.java:451)
[WARNING] at java.lang.Runtime.exec(Runtime.java:591)
[WARNING] at java.lang.Runtime.exec(Runtime.java:464)
[WARNING] at 
gr.spinellis.umlgraph.doclet.UmlGraphDoc.runGraphviz(UmlGraphDoc.java:131)
[WARNING] at 
gr.spinellis.umlgraph.doclet.UmlGraphDoc.generateContextDiagrams(UmlGraphDoc.java:114)
[WARNING] at gr.spinellis.umlgraph.doclet.UmlGraphDoc.start(UmlGraphDoc.java:64)
[WARNING] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[WARNING] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[WARNING] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[WARNING] at java.lang.reflect.Method.invoke(Method.java:585)
[WARNING] at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269)
[WARNING] at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:143)
[WARNING] at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340)
[WARNING] at com.sun.tools.javadoc.Start.begin(Start.java:128)
[WARNING] at com.sun.tools.javadoc.Main.execute(Main.java:41)
[WARNING] at com.sun.tools.javadoc.Main.main(Main.java:31)




-- 
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: (MSITE-132) Use instead of for directories

2007-07-26 Thread John Allen (JIRA)

[ 
http://jira.codehaus.org/browse/MSITE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103351
 ] 

John Allen commented on MSITE-132:
--

Denis,

Ahh, it's only if you have no distroManagement section that it invents the path 
and this is why I've never seen it (we use a flat project structure and thus 
have to declare distroManagement and project.URL in every POM as maven's 
default assumptions are wrong for us). Seems a reasonable fix, will apply to my 
local patched plugin and play.

> Use  instead of  for directories
> --
>
> Key: MSITE-132
> URL: http://jira.codehaus.org/browse/MSITE-132
> Project: Maven 2.x Site Plugin
>  Issue Type: Improvement
> Environment: maven-2.0.4 on any operating system with the latests 
> released plugins (after the doxia-1.0-alpha-8.pom bug)
>Reporter: Jörg Hohwiller
> Attachments: MSITE-132.patch
>
>
> The  of a project in the POM may contain characters that cause trouble 
> when used in directory names.
> E.g. my open-source project: 
> http://svn.projxpert.com/mmm/trunk/
> Uses names such as "MMM::Configuration". Now when I stage the site of the 
> entire project, the relative link "MMM::Configuration" causes mozilla to say 
> something like "Unknown protocol 'mmm:'".
> Could you please use the artefactId instead. 
> I think personally think that this is a lot better anyways.
> BTW - Thanks for your greate work. M2 is awesome!!!

-- 
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-3121) goal specified in execution but not found in plugin

2007-07-26 Thread gvsg (JIRA)
goal specified in execution but not found in plugin
---

 Key: MNG-3121
 URL: http://jira.codehaus.org/browse/MNG-3121
 Project: Maven 2
  Issue Type: Bug
Affects Versions: 2.0.7
Reporter: gvsg
Priority: Blocker


Hi all;

I want to run the XML-MAVEN-Plugin when 'mvn site:run' goal has been executed.
Whien doing this I receive the following exception:

org.apache.maven.lifecycle.LifecycleExecutionException: 'run' was specified in 
an execution, but not found in the plugin
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindExecutionToLifecycle(DefaultLifecycleExecutor.java:1342)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycle(DefaultLifecycleExecutor.java:1243)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:987)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
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:324)
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)

Here is a partial example of my pom.xml  file




org.codehaus.mojo
xml-maven-plugin
1.0-beta-2-patched


   org.codehaus.mojo
xml-maven-plugin
1.0-beta-2-patched
provided



  
execution1
site

run


true


target

./target/site/pmd-report-per-class.xslt



.html



pmd.xml

target/site



  




Note:: If I try to set this for other plugins this will also fail.

Kind regards,

Guy


-- 
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: (MAVENUPLOAD-1657) UrlRewriter

2007-07-26 Thread Luc Pezet (JIRA)
UrlRewriter
---

 Key: MAVENUPLOAD-1657
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1657
 Project: maven-upload-requests
  Issue Type: Wish
Reporter: Luc Pezet




-- 
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: (CONTINUUM-1354) meta refresh causes build loop

2007-07-26 Thread Emmanuel Venisse (JIRA)

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

Emmanuel Venisse updated CONTINUUM-1354:


Fix Version/s: 1.1-beta-2

> meta refresh causes build loop
> --
>
> Key: CONTINUUM-1354
> URL: http://jira.codehaus.org/browse/CONTINUUM-1354
> Project: Continuum
>  Issue Type: Bug
>  Components: Web interface
>Affects Versions: 1.1-beta-1
> Environment: all
>Reporter: Olivier Lamy
> Fix For: 1.1-beta-2
>
>
> Simple scenario : 
> - edit a project group
> - force a project build with the link "Build Now"
> - go to drink some coffe (longer than 5 minutes)
> - some project build have build  enqueuing
> It due to the link 
> http://${ip}:${pwd}/continuum/buildProject.action?fromGroupPage=true&projectGroupId=15&projectId=79
> The meta refresh force the build.
> As some browser have the tabs, this can cause a lot of not needed builds .
> --
> Olivier
> PS :  I will provide a patch next week.

-- 
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-3122) MAVENPROJECT: getActiveProfiles() returning duplicate activeByDefault profile defined in LOCAL_HOME/.m2/settings.xml

2007-07-26 Thread Ian Berry (JIRA)
MAVENPROJECT: getActiveProfiles() returning duplicate activeByDefault profile 
defined in LOCAL_HOME/.m2/settings.xml


 Key: MNG-3122
 URL: http://jira.codehaus.org/browse/MNG-3122
 Project: Maven 2
  Issue Type: Bug
  Components: Profiles
Affects Versions: 2.0.7
Reporter: Ian Berry
 Attachments: settings.xml

MavenProject:getActiveProfiles() is returning duplicate activeByDefault 
profiles defined in LOCAL_HOME/.m2/settings.xml.

Attached settings.xml resides in LOCAL_HOME/.m2.

Below is part of the output of a buildInformation plugin i am writing, which 
shows profile WLS8 twice.

 
 
   default-repositories 
   settings.xml 
 
   
  WLS8 
  settings.xml 

   
  WLS8 
  settings.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] Updated: (MRM-329) The Reports link gives an HTTP 500

2007-07-26 Thread Maria Odea Ching (JIRA)

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

Maria Odea Ching updated MRM-329:
-

Fix Version/s: (was: 1.0.x)
   1.0-beta-1

> The Reports link gives an HTTP 500
> --
>
> Key: MRM-329
> URL: http://jira.codehaus.org/browse/MRM-329
> Project: Archiva
>  Issue Type: Bug
>  Components: reporting
>Affects Versions: 1.0-alpha-1
>Reporter: Napoleon Esmundo C. Ramirez
>Assignee: Joakim Erdfelt
>Priority: Blocker
> Fix For: 1.0-beta-1
>
> Attachments: MRM-329-archiva-database-20070725.patch, 
> MRM-329-archiva-webapp-20070725.patch
>
>
> Clicking the Reports link in the side navigation menu displays the following 
> (edited/snipped stacktrace): 
> HTTP ERROR: 500
> RequestURI=/admin/reports.action
> Caused by: javax.el.PropertyNotFoundException: The class 
> 'org.apache.maven.archiva.reporting.artifact.OldArtifactReport' does not have 
> the property 'groupId'.
> at javax.el.BeanELResolver.getBeanProperty(BeanELResolver.java:574)
> at javax.el.BeanELResolver.getValue(BeanELResolver.java:280)
> at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:143)
> at com.sun.el.parser.AstValue.getValue(AstValue.java:118)
> at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:192)
> at 
> org.apache.jasper.runtime.PageContextImpl.evaluateExpression(PageContextImpl.java:974)
> at 
> org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp._jspx_meth_c_forEach_0(org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp:143)
> at 
> org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp._jspService(org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp:85)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> at 
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:373)

-- 
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