[jira] Updated: (CONTINUUM-755) Add field validations with webwork field validator

[Maria Odea Ching (JIRA)]

 [ http://jira.codehaus.org/browse/CONTINUUM-755?page=all ]

Maria Odea Ching updated CONTINUUM-755:
---

Due Date: 23/Aug/06  (was: 22/Aug/06)

 Add field validations with webwork field validator
 --

 Key: CONTINUUM-755
 URL: http://jira.codehaus.org/browse/CONTINUUM-755
 Project: Continuum
  Issue Type: Task
  Components: Web interface
Affects Versions: 1.1
Reporter: Emmanuel Venisse
 Assigned To: Maria Odea Ching
 Fix For: 1.1

   Original Estimate: 1 day, 6 hours
  Time Spent: 2 hours, 30 minutes
  Remaining Estimate: 1 day, 3 hours, 30 minutes



-- 
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: (DOXIA-72) Allow multiple powered by logos with no border and no fixed size

[Martin Zeltner (JIRA)]

Allow multiple powered by logos with no border and no fixed size


 Key: DOXIA-72
 URL: http://jira.codehaus.org/browse/DOXIA-72
 Project: doxia
  Issue Type: Improvement
  Components: Site Renderer
Affects Versions: 1.0-alpha-8
 Environment: WinXP, Java5
Reporter: Martin Zeltner
Priority: Trivial
 Attachments: maven-feather.png, patch_doxia-site_renderer.txt

Allow multiple powered by logos with no border and no fixed size.

Changes in patch:
   * Css adapted so powered by logo have no fixed size and no border
   * VM template adapted so generated site is XHMTL 1.1 valid im multiple logos 
are used.
   * Maven feather enlarged with a black 1px wide border (see sep attachement)

Cheers,
Martin

-- 
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-2507) multi module install has a race condition

[Stefan Stieglitz (JIRA)]

multi module install has a race condition
-

 Key: MNG-2507
 URL: http://jira.codehaus.org/browse/MNG-2507
 Project: Maven 2
  Issue Type: Bug
  Components: Bootstrap  Build, Dependencies
Affects Versions: 2.0.4
 Environment: Windows XP SP1; netbeans 5.0 using maven2 plugin; running 
on a notebook, disconnected from any central repository using only the local 
repository
Reporter: Stefan Stieglitz


Multi module projects (using a root project with pom packaging) are likely to 
run into a race condition when performing a multi module build. It seems to me 
that the installing of a just build (jar-) file for module A and the compile 
goal of the next build of a module B, run both in different threads. These 
threads are not sufficently synchronized. This can result in an artifact is 
missing error if B has a dependeny on A. Even worse, if an old jar from a 
previous build is still in place, module B is compiled against old code. To 
handle this, one has to search for any dependencies and build all modules 
manually in an appropriate order.
It is likely that this bug has no effect, if an up to date central repository 
is accessible.

Suggestion to fix this: Wait until each build is completely finished, before 
performing the next step of a multi module build.

Simplified example POMs:

root:
project
  modelVersion4.0.0/modelVersion
  groupIdvendor/groupId 
  artifactIdroot/artifactId
  nameroot/name
   packagingpom/packaging
  modules
moduleA/module
moduleB/module
  /modules
/project

module A:
project
modelVersion4.0.0/modelVersion
parent
groupIdvendor/groupId
artifactIdroot/artifactId
version1.0-SNAPSHOT/version
/parent
artifactIdA/artifactId
nameA/name
packagingjar/packaging
/project

module B:
 project
modelVersion4.0.0/modelVersion
parent
groupIdvendor/groupId
artifactIdroot/artifactId
version1.0-SNAPSHOT/version
/parent
artifactIdB/artifactId
nameB/name
packagingjar/packaging
   dependencies
dependency
groupIdvendor/groupId
artifactIdA/artifactId
version1.0-SNAPSHOT/version
 /dependency
   /dependencies
/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: (MAVENUPLOAD-1057) JCommon 1.0.5

[Takayoshi Kimura (JIRA)]

JCommon 1.0.5
-

 Key: MAVENUPLOAD-1057
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1057
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Takayoshi Kimura
 Attachments: jcommon-1.0.5-bundle.jar

http://www.jfree.org/jcommon/

-- 
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: (MASSEMBLY-99) dependencySets in a descriptor doesn't work anymore

[Norman Fomferra (JIRA)]

 [ http://jira.codehaus.org/browse/MASSEMBLY-99?page=all ]

Norman Fomferra updated MASSEMBLY-99:
-

Attachment: assembly-spike-1.0.zip

A multi-module project which shows that this issue insn't fixed in 2.2 as of 
Aug 17, 2006

 dependencySets in a descriptor doesn't work anymore
 ---

 Key: MASSEMBLY-99
 URL: http://jira.codehaus.org/browse/MASSEMBLY-99
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.1
 Environment: all
Reporter: Olivier Lamy
 Assigned To: John Casey
Priority: Blocker
 Fix For: 2.2

 Attachments: assembly-spike-1.0.zip, descriptor.xml


 I attached my descriptor file.
   dependencySets
 dependencySet
   outputDirectorylib/outputDirectory
   unpackfalse/unpack
   scoperuntime/scope
   !--
 how to exclude dependencies
   excludes
   excludejunit:junit/exclude
   /excludes 
   --
 /dependencySet
   /dependencySets
 unzip -l on the assembly file show empty lib directory.
 Olivier

-- 
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: (MASSEMBLY-99) dependencySets in a descriptor doesn't work anymore

[Norman Fomferra (JIRA)]

[ http://jira.codehaus.org/browse/MASSEMBLY-99?page=comments#action_72544 ] 

Norman Fomferra commented on MASSEMBLY-99:
--

This issue is definitely not fixed yet. See my attachment 'assembly-spike.zip' 
which contains a very simple two-modules project. Module JARs shall go into an 
output directory 'modules' (a moduleSet) and dependencies shall go into an 
output directory 'lib'  (a dependencySet). 'modules' is ok, but 'lib' is not 
created. Applies to 2.2-SNAPSHOT as of Aug 17, 2006.

Is there any workaround for this annoying bug in this very important plug-in? 
If not, we have to stop using maven (which I like and enjoy very much) in our 
project an go back to ant.

Cheers
   Norman 




 dependencySets in a descriptor doesn't work anymore
 ---

 Key: MASSEMBLY-99
 URL: http://jira.codehaus.org/browse/MASSEMBLY-99
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.1
 Environment: all
Reporter: Olivier Lamy
 Assigned To: John Casey
Priority: Blocker
 Fix For: 2.2

 Attachments: assembly-spike-1.0.zip, descriptor.xml


 I attached my descriptor file.
   dependencySets
 dependencySet
   outputDirectorylib/outputDirectory
   unpackfalse/unpack
   scoperuntime/scope
   !--
 how to exclude dependencies
   excludes
   excludejunit:junit/exclude
   /excludes 
   --
 /dependencySet
   /dependencySets
 unzip -l on the assembly file show empty lib directory.
 Olivier

-- 
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-1775) No property expansion in profile activation

[James Olsen (JIRA)]

[ http://jira.codehaus.org/browse/MNG-1775?page=comments#action_72547 ] 

James Olsen commented on MNG-1775:
--

Forgot to mention that in every case the result of 'mvn help:effective-pom' 
always returns a result with all the properties successfully expanded.

 No property expansion in profile activation
 ---

 Key: MNG-1775
 URL: http://jira.codehaus.org/browse/MNG-1775
 Project: Maven 2
  Issue Type: Bug
  Components: Inheritence and Interpolation
Affects Versions: 2.0, 2.0.1
 Environment: Linux
Reporter: Eric Andresen
 Fix For: 2.0.5


 I have a profile specified in the pom.xml of a project. It is inteded to be 
 activated based on the presence or absence of a file, using the file 
 profile activator.
 The profiles are simple:
   profile
   idmetis/id
   activation
   filemissing${basedir}/../build.properties/missing/file
   /activation
   build
   
 filtersfilter${basedir}/../build.properties.metis/filter/filters
   /build
   /profile
   profile
   iddev/id
   activation
   fileexists${basedir}/../build.properties/exists/file
   /activation
   build
   
 filtersfilter${basedir}/../build.properties/filter/filters
   /build
   /profile
 The problem comes in with ${basedir} -- it isn't being expanded for purposes 
 of evaluating the file. It's trying to look for a file named 
 ${basedir}/../build.properties, rather than 
 /home/joe/projectX/projY/../build.properties; as a result, the missing 
 directive is always true, and the dev profile is never activated. When the 
 filter path is evaluated, the ${basedir} property *is* evaluated, however.

-- 
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-1943) MavenProject::getParent() returns a MavenProject that is NOT interpolated

[James Olsen (JIRA)]

[ http://jira.codehaus.org/browse/MNG-1943?page=comments#action_72548 ] 

James Olsen commented on MNG-1943:
--

Perhaps the problem I describe in [#MNG-1775] (Comment James Olsen [15/Aug/06 
06:37 AM]) is a symptom of this issue?

 MavenProject::getParent() returns a MavenProject that is NOT interpolated
 -

 Key: MNG-1943
 URL: http://jira.codehaus.org/browse/MNG-1943
 Project: Maven 2
  Issue Type: Bug
Reporter: John Allen
Priority: Blocker
 Fix For: 2.1


 Plugin developers repeatedly use ${project}.getParent().someMethod() yet 
 getParent() returns a project that has not been interpolated. This obviously 
 needs to be fixed but may I also suggest that all plugin acceptance testing 
 is revisted to ensure that the tests use POMs that are littered with property 
 expressions and not literals.

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

[jira] Commented: (SUREFIRE-52) XML Reports include testcases from previous tests

[Brice Copy (JIRA)]

[ http://jira.codehaus.org/browse/SUREFIRE-52?page=comments#action_72549 ] 

Brice Copy commented on SUREFIRE-52:


Is there a workaround for this, like using an older version of surefire ?

 XML Reports include testcases from previous tests
 -

 Key: SUREFIRE-52
 URL: http://jira.codehaus.org/browse/SUREFIRE-52
 Project: surefire
  Issue Type: Bug
Affects Versions: 2.0
Reporter: bin zhu
Priority: Minor
 Attachments: patch.txt


 to reproduce
 1. create the following JUnit tests:
 public class TestA extends TestCase {
public void test1() {
}
 }
 public class TestB extends TestCase {
public void test2() {
 }
 2. run 'mvn clean install'
 note that in TEST-TestB.xml includes testcase results from test1 and test2, 
 even though TestB only has test2()
 testsuite errors=0 skipped=0 tests=1 time=0 failures=0 
 name=TestB
 ...
   testcase time=0 name=test1/
   testcase time=0 name=test2/
 /testsuite

-- 
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-2508) mvn complains about missing Java 1.4 on Java 1.4.2

[Markus KARG (JIRA)]

mvn complains about missing Java 1.4 on Java 1.4.2
--

 Key: MNG-2508
 URL: http://jira.codehaus.org/browse/MNG-2508
 Project: Maven 2
  Issue Type: Bug
  Components: Command Line
Affects Versions: 2.0.4
 Environment: java version 1.4.2
gij (GNU libgcj) version 4.1.0 (SUSE Linux)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Reporter: Markus KARG


[EMAIL PROTECTED]:~ /opt/maven-2.0.4/bin/mvn
Sorry, but JDK 1.4 or above is required to execute Maven
You appear to be using Java version: 1.4.2
[EMAIL PROTECTED]:~ java -version
java version 1.4.2
gij (GNU libgcj) version 4.1.0 (SUSE Linux)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


-- 
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-63) Goal 'idea' requires modules to be installed in order to generate module dependencies in the IDEA project file

[Norman Fomferra (JIRA)]

Goal 'idea' requires modules to be installed in order to generate module 
dependencies in the IDEA project file
--

 Key: MIDEA-63
 URL: http://jira.codehaus.org/browse/MIDEA-63
 Project: Maven 2.x Idea Plugin
  Issue Type: Bug
Affects Versions: 2.0
Reporter: Norman Fomferra
Priority: Minor


The goal 'idea' requires modules in a multi-module project to be installed in 
order to generate module dependencies in the IDEA project file. You must
   mvn clean install idea:idea
in order to create functioning IDEA module files. Actually the should be 
sufficient
   mvn clean package idea:idea
as it is for the eclipse 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] Created: (MNG-2509) M2/ANT : Weird ClassCastException in m:pom in macrodef when calling Beanshell scripting.

[Davy Toch (JIRA)]

M2/ANT : Weird ClassCastException in m:pom in macrodef when calling Beanshell 
scripting.
--

 Key: MNG-2509
 URL: http://jira.codehaus.org/browse/MNG-2509
 Project: Maven 2
  Issue Type: Bug
  Components: Ant tasks
Affects Versions: 2.0.4
 Environment: - ANT 1.6.5 (with bsh-2.0b4.jar in ANT_HOME/lib)
- JDK 1.5

Reporter: Davy Toch


Hi,

In ANT, sometimes more than one artifact is generated from the same
build file (e.g. myapp.jar, myapp-client.jar, myapp-with-deps.jar).

If using the M2 plugin for ANT (currently 2.0.4), this would mean
we would need three POM's for the above 3 artifacts. However, in the
above case the 3 POM's would be almost identical.

So I have taken the following approach in order to have only one generic
POM:

pom.xml (with ANT tokens _TOKEN_...):

project xmlns=http://maven.apache.org/POM/4.0.0;
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd;
  modelVersion4.0.0/modelVersion
  groupIdbe.steria.test/groupId
  artifactId_TOKEN_ARTIFACTID_/artifactId
  packaging_TOKEN_PACKAGING_/packaging
  version1.5-SNAPSHOT/version
  descriptionTest artifact/description
  dependencies
dependency
  groupIdlog4j/groupId
  artifactIdlog4j/artifactId
  version1.2.9/version
  scopecompile/scope
/dependency
dependency
  groupIdjunit/groupId
  artifactIdjunit/artifactId
  version3.8.1/version
  scopetest/scope
/dependency
  /dependencies
  distributionManagement
repository
  idrepo_dev/id
  urlscp://localhost/m2demo/repo_dev/url
/repository
  /distributionManagement
/project

build.xml:

project name=example-ant-using-m2-plugin default=m2init
  xmlns:m=antlib:org.apache.maven.artifact.ant

  macrodef name=create-pom
attribute name=pomRefId/
attribute name=artifactId/
attribute name=packaging default=jar/
sequential
  !-- IMPORTANT : derived POM files must be generated in the same
  folder as pom.xml, otherwise the paths, ... will be incorrect --
  copy file=pom.xml filtering=true
toFile=[EMAIL PROTECTED]
filterchain
  tokenfilter
replacestring from=_TOKEN_ARTIFACTID_
  to=@{artifactId}/
replacestring from=_TOKEN_PACKAGING_
  to=@{packaging}/
  /tokenfilter
/filterchain
  /copy
  m:pom id=@{pomRefId} file=[EMAIL PROTECTED]/
/sequential
  /macrodef

  target name=m2init

m:pom id=M2POM file=pom.xml/

!-- causes ClassCastException in macrodef 'create-pom' --
!--script language=beanshell/--

!-- create POM's on-the-fly (one for each artifact) --
create-pom pomRefId=M2POM_MYAPP artifactId=myapp/
create-pom pomRefId=M2POM_MYAPP_CLIENT artifactId=myapp-client/
create-pom pomRefId=M2POM_MYAPP_WITH_DEPS artifactId=myapp-with-deps/
  
  /target

  target name=package depends=m2init
!-- ... generate artifacts (pure ANT) ... --
  /target

  target name=install depends=package
m:install file=myapp.jar
  pomRefId=M2POM_MYAPP/
m:install file=myapp-client.jar
  pomRefId=M2POM_MYAPP_CLIENT/
m:install file=myapp-with-deps.jar
  pomRefId=M2POM_MYAPP_WITH_DEPS/
  /target

  target name=deploy
m:deploy file=myapp.jar
  pomRefId=M2POM_MYAPP/
m:deploy file=myapp-client.jar
  pomRefId=M2POM_MYAPP_CLIENT/
m:deploy file=myapp-with-deps.jar
  pomRefId=M2POM_MYAPP_WITH_DEPS/
  /target

/project

Now if I execute the above, everything works fine, but if I add script
language=beanshell/ in the target 'm2init', then the following error
is generated on the first create-pom call:

  java.lang.ClassCastException: org.apache.maven.artifact.ant.Pom

Regards,
Davy Toch


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

[jira] Updated: (MNG-2509) M2/ANT : Weird ClassCastException in m:pom in macrodef when calling Beanshell scripting.

[Davy Toch (JIRA)]

 [ http://jira.codehaus.org/browse/MNG-2509?page=all ]

Davy Toch updated MNG-2509:
---

Attachment: build.xml

 M2/ANT : Weird ClassCastException in m:pom in macrodef when calling 
 Beanshell scripting.
 --

 Key: MNG-2509
 URL: http://jira.codehaus.org/browse/MNG-2509
 Project: Maven 2
  Issue Type: Bug
  Components: Ant tasks
Affects Versions: 2.0.4
 Environment: - ANT 1.6.5 (with bsh-2.0b4.jar in ANT_HOME/lib)
 - JDK 1.5
Reporter: Davy Toch
 Attachments: build.xml, pom.xml


 Hi,
 In ANT, sometimes more than one artifact is generated from the same
 build file (e.g. myapp.jar, myapp-client.jar, myapp-with-deps.jar).
 If using the M2 plugin for ANT (currently 2.0.4), this would mean
 we would need three POM's for the above 3 artifacts. However, in the
 above case the 3 POM's would be almost identical.
 So I have taken the following approach in order to have only one generic
 POM:
 pom.xml (with ANT tokens _TOKEN_...):
 project xmlns=http://maven.apache.org/POM/4.0.0;
   xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 
 http://maven.apache.org/maven-v4_0_0.xsd;
   modelVersion4.0.0/modelVersion
   groupIdbe.steria.test/groupId
   artifactId_TOKEN_ARTIFACTID_/artifactId
   packaging_TOKEN_PACKAGING_/packaging
   version1.5-SNAPSHOT/version
   descriptionTest artifact/description
   dependencies
 dependency
   groupIdlog4j/groupId
   artifactIdlog4j/artifactId
   version1.2.9/version
   scopecompile/scope
 /dependency
 dependency
   groupIdjunit/groupId
   artifactIdjunit/artifactId
   version3.8.1/version
   scopetest/scope
 /dependency
   /dependencies
   distributionManagement
 repository
   idrepo_dev/id
   urlscp://localhost/m2demo/repo_dev/url
 /repository
   /distributionManagement
 /project
 build.xml:
 project name=example-ant-using-m2-plugin default=m2init
   xmlns:m=antlib:org.apache.maven.artifact.ant
   macrodef name=create-pom
 attribute name=pomRefId/
 attribute name=artifactId/
 attribute name=packaging default=jar/
 sequential
   !-- IMPORTANT : derived POM files must be generated in the same
   folder as pom.xml, otherwise the paths, ... will be incorrect --
   copy file=pom.xml filtering=true
 toFile=[EMAIL PROTECTED]
 filterchain
   tokenfilter
 replacestring from=_TOKEN_ARTIFACTID_
   to=@{artifactId}/
 replacestring from=_TOKEN_PACKAGING_
   to=@{packaging}/
   /tokenfilter
 /filterchain
   /copy
   m:pom id=@{pomRefId} file=[EMAIL PROTECTED]/
 /sequential
   /macrodef
   target name=m2init
 m:pom id=M2POM file=pom.xml/
 !-- causes ClassCastException in macrodef 'create-pom' --
 !--script language=beanshell/--
 !-- create POM's on-the-fly (one for each artifact) --
 create-pom pomRefId=M2POM_MYAPP artifactId=myapp/
 create-pom pomRefId=M2POM_MYAPP_CLIENT artifactId=myapp-client/
 create-pom pomRefId=M2POM_MYAPP_WITH_DEPS 
 artifactId=myapp-with-deps/
   
   /target
   target name=package depends=m2init
 !-- ... generate artifacts (pure ANT) ... --
   /target
   target name=install depends=package
 m:install file=myapp.jar
   pomRefId=M2POM_MYAPP/
 m:install file=myapp-client.jar
   pomRefId=M2POM_MYAPP_CLIENT/
 m:install file=myapp-with-deps.jar
   pomRefId=M2POM_MYAPP_WITH_DEPS/
   /target
   target name=deploy
 m:deploy file=myapp.jar
   pomRefId=M2POM_MYAPP/
 m:deploy file=myapp-client.jar
   pomRefId=M2POM_MYAPP_CLIENT/
 m:deploy file=myapp-with-deps.jar
   pomRefId=M2POM_MYAPP_WITH_DEPS/
   /target
 /project
 Now if I execute the above, everything works fine, but if I add script
 language=beanshell/ in the target 'm2init', then the following error
 is generated on the first create-pom call:
   java.lang.ClassCastException: org.apache.maven.artifact.ant.Pom
 Regards,
 Davy Toch

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

[jira] Updated: (MNG-2509) M2/ANT : Weird ClassCastException in m:pom in macrodef when calling Beanshell scripting.

[Davy Toch (JIRA)]

 [ http://jira.codehaus.org/browse/MNG-2509?page=all ]

Davy Toch updated MNG-2509:
---

Attachment: pom.xml

 M2/ANT : Weird ClassCastException in m:pom in macrodef when calling 
 Beanshell scripting.
 --

 Key: MNG-2509
 URL: http://jira.codehaus.org/browse/MNG-2509
 Project: Maven 2
  Issue Type: Bug
  Components: Ant tasks
Affects Versions: 2.0.4
 Environment: - ANT 1.6.5 (with bsh-2.0b4.jar in ANT_HOME/lib)
 - JDK 1.5
Reporter: Davy Toch
 Attachments: build.xml, pom.xml


 Hi,
 In ANT, sometimes more than one artifact is generated from the same
 build file (e.g. myapp.jar, myapp-client.jar, myapp-with-deps.jar).
 If using the M2 plugin for ANT (currently 2.0.4), this would mean
 we would need three POM's for the above 3 artifacts. However, in the
 above case the 3 POM's would be almost identical.
 So I have taken the following approach in order to have only one generic
 POM:
 pom.xml (with ANT tokens _TOKEN_...):
 project xmlns=http://maven.apache.org/POM/4.0.0;
   xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 
 http://maven.apache.org/maven-v4_0_0.xsd;
   modelVersion4.0.0/modelVersion
   groupIdbe.steria.test/groupId
   artifactId_TOKEN_ARTIFACTID_/artifactId
   packaging_TOKEN_PACKAGING_/packaging
   version1.5-SNAPSHOT/version
   descriptionTest artifact/description
   dependencies
 dependency
   groupIdlog4j/groupId
   artifactIdlog4j/artifactId
   version1.2.9/version
   scopecompile/scope
 /dependency
 dependency
   groupIdjunit/groupId
   artifactIdjunit/artifactId
   version3.8.1/version
   scopetest/scope
 /dependency
   /dependencies
   distributionManagement
 repository
   idrepo_dev/id
   urlscp://localhost/m2demo/repo_dev/url
 /repository
   /distributionManagement
 /project
 build.xml:
 project name=example-ant-using-m2-plugin default=m2init
   xmlns:m=antlib:org.apache.maven.artifact.ant
   macrodef name=create-pom
 attribute name=pomRefId/
 attribute name=artifactId/
 attribute name=packaging default=jar/
 sequential
   !-- IMPORTANT : derived POM files must be generated in the same
   folder as pom.xml, otherwise the paths, ... will be incorrect --
   copy file=pom.xml filtering=true
 toFile=[EMAIL PROTECTED]
 filterchain
   tokenfilter
 replacestring from=_TOKEN_ARTIFACTID_
   to=@{artifactId}/
 replacestring from=_TOKEN_PACKAGING_
   to=@{packaging}/
   /tokenfilter
 /filterchain
   /copy
   m:pom id=@{pomRefId} file=[EMAIL PROTECTED]/
 /sequential
   /macrodef
   target name=m2init
 m:pom id=M2POM file=pom.xml/
 !-- causes ClassCastException in macrodef 'create-pom' --
 !--script language=beanshell/--
 !-- create POM's on-the-fly (one for each artifact) --
 create-pom pomRefId=M2POM_MYAPP artifactId=myapp/
 create-pom pomRefId=M2POM_MYAPP_CLIENT artifactId=myapp-client/
 create-pom pomRefId=M2POM_MYAPP_WITH_DEPS 
 artifactId=myapp-with-deps/
   
   /target
   target name=package depends=m2init
 !-- ... generate artifacts (pure ANT) ... --
   /target
   target name=install depends=package
 m:install file=myapp.jar
   pomRefId=M2POM_MYAPP/
 m:install file=myapp-client.jar
   pomRefId=M2POM_MYAPP_CLIENT/
 m:install file=myapp-with-deps.jar
   pomRefId=M2POM_MYAPP_WITH_DEPS/
   /target
   target name=deploy
 m:deploy file=myapp.jar
   pomRefId=M2POM_MYAPP/
 m:deploy file=myapp-client.jar
   pomRefId=M2POM_MYAPP_CLIENT/
 m:deploy file=myapp-with-deps.jar
   pomRefId=M2POM_MYAPP_WITH_DEPS/
   /target
 /project
 Now if I execute the above, everything works fine, but if I add script
 language=beanshell/ in the target 'm2init', then the following error
 is generated on the first create-pom call:
   java.lang.ClassCastException: org.apache.maven.artifact.ant.Pom
 Regards,
 Davy Toch

-- 
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: (MECLIPSE-92) Allow .classpath generation for plugin-development support

[David Boden (JIRA)]

 [ http://jira.codehaus.org/browse/MECLIPSE-92?page=all ]

David Boden updated MECLIPSE-92:


Attachment: screenshot-1.jpg

I'm building from CVS. I still get all the entries in .classpath even though 
the dependencies are inherited from ss_base_applet and ss_base_shared.

 Allow .classpath generation for plugin-development support
 --

 Key: MECLIPSE-92
 URL: http://jira.codehaus.org/browse/MECLIPSE-92
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Improvement
  Components: PDE support
Affects Versions: 2.1
Reporter: Sachin Patel
 Assigned To: fabrizio giustina
 Attachments: pde_patch_1.diff, screenshot-1.jpg


 In order to improve eclipse plugin development with maven, the configuration 
 of the eclipse:eclipse goal should allow a flag to be set that that given pom 
 is an eclipse plugin and the .classpath generated should not add .classpath 
 entries for dependencies declared in the POM, since plugins really just 
 reference other plugins in the workspace and or use the requiredPlugins 
 classpath container.  At runtime plugins cannot reference external 
 classes/jars so having all the var entries isn't necessary and adds clutter.

-- 
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-149) Removing source and target tags from pom.xml doesn't remove project specific compiler settings in eclipse

[Markus KARG (JIRA)]

Removing source and target tags from pom.xml doesn't remove project specific 
compiler settings in eclipse
-

 Key: MECLIPSE-149
 URL: http://jira.codehaus.org/browse/MECLIPSE-149
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
 Environment: SuSE Linux 10.1
Sun JDK 1.5.0_07
Eclipse 3.1
Maven 2.0.4
Reporter: Markus KARG


I added the following to the pom.xml, then execute mvn eclipse:eclipse:

build
  plugins
plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-compiler-plugin/artifactId
  configuration
source1.5/source
target1.5/target
  /configuration
/plugin
  /plugins
/build

Then pressing F5 in Eclipse makes the project's compiler settings beeing 
changed from workspace defaults to project specific, reflecting the value 
of 1.5. Fine. :-)

Now changing the pom.xml from 1.5 to 1.4, doing mvn eclipse:eclipse and F5 once 
more, makes the 1.4 beeing reflected in Eclipse's compiler settings dialog. 
Fine. :-)

Now completely removing the build section from pom.xml, doing mvn 
eclipse:eclipse and F5 a third time. But Eclipse still keeps the project 
specific settings! This is bad, it certainly has to remove the project specific 
settings since there are none to be found in the pom.xml!

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

[jira] Commented: (MIDEA-40) war module-dependencies are jarred and copied to /WEB-INF/classes

[Geoffrey De Smet (JIRA)]

[ http://jira.codehaus.org/browse/MIDEA-40?page=comments#action_72563 ] 

Geoffrey De Smet commented on MIDEA-40:
---

It's fixed in 2.0 as
module A : JAR module output and copy file to: /WEB-INF/lib/jarname.jar
This is probably indeed the best way in most cases.

Can be closed, although having a property to switch to the first way would be 
nice.

 war module-dependencies are jarred and copied to /WEB-INF/classes
 -

 Key: MIDEA-40
 URL: http://jira.codehaus.org/browse/MIDEA-40
 Project: Maven 2.x Idea Plugin
  Issue Type: Bug
Reporter: Geoffrey De Smet

 A mulitproject with a jar module A and a war module B, where B depends on A, 
 will be configured so that:
 In web module settings, under Modules and libraries to package:
 module A : JAR module output and copy file to: /WEB-INF/classes
 This should either be
 module A : copy module output to: /WEB-INF/classes
 or
 module A : JAR module output and copy file to: /WEB-INF/lib/jarname.jar
 Both should be supported a believe, as the second one mimics maven and the 
 real way of doing it, but the first one is a lot faster

-- 
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-64) Provided dependencies are also copied to /WEB-INF/lib

[Geoffrey De Smet (JIRA)]

Provided dependencies are also copied to /WEB-INF/lib
-

 Key: MIDEA-64
 URL: http://jira.codehaus.org/browse/MIDEA-64
 Project: Maven 2.x Idea Plugin
  Issue Type: Bug
Affects Versions: 2.0
Reporter: Geoffrey De Smet


A dependency with the scope provided (and probably system too) is also 
marked as to be copied to /WEB-INF/lib for webapp modules.

-- 
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-64) Provided dependencies are also copied to /WEB-INF/lib

[Geoffrey De Smet (JIRA)]

 [ http://jira.codehaus.org/browse/MIDEA-64?page=all ]

Geoffrey De Smet updated MIDEA-64:
--

Attachment: screenshot-1.jpg

I 've made log4j provided in my case.

 Provided dependencies are also copied to /WEB-INF/lib
 -

 Key: MIDEA-64
 URL: http://jira.codehaus.org/browse/MIDEA-64
 Project: Maven 2.x Idea Plugin
  Issue Type: Bug
Affects Versions: 2.0
Reporter: Geoffrey De Smet
 Attachments: screenshot-1.jpg


 A dependency with the scope provided (and probably system too) is also 
 marked as to be copied to /WEB-INF/lib for webapp modules.

-- 
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: (MNGECLIPSE-59) Allow artifact resolution from workspace projects

[Scott Cytacki (JIRA)]

[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_72565 
] 

Scott Cytacki commented on MNGECLIPSE-59:
-

I just checked it out.  The refactoring looks good, and thanks for updating the 
eclipse formater settings.  But...

It only worked for a few seconds, and then all the eclipse project dependencies 
disappeared from the classpath container and were replaced with maven jar 
dependencies.  I'll try to figure out what is going on.

 Allow artifact resolution from workspace projects
 -

 Key: MNGECLIPSE-59
 URL: http://jira.codehaus.org/browse/MNGECLIPSE-59
 Project: Maven 2.x Extension for Eclipse
  Issue Type: New Feature
  Components: Dependency Resolver
Affects Versions: 0.0.4
Reporter: Leonardo Quijano Vincenzi
 Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, 
 mngeclipse-59-drew-hack.txt, project-artifacts-2006062701.patch, 
 project-artifacts-2006062900.patch, project-artifacts.patch


 Provide artifact resolution from workspace projects, which override the same 
 artifact from the local or remote repositories. This would allow to work with 
 dependant Eclipse projects without specifying the Eclipse dependency manually.
 The workspace artifact resolution would have to be specified manually, since 
 several Maven-Enabled projects in the same workspace could have the same 
 artifact and version Id. Or at least automatic resolution with an optional 
 override would be nice.
 More comments here:
 http://jira.codehaus.org/browse/MNGECLIPSE-58

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

[jira] Created: (MSITE-176) AbstractSiteRenderingMojo causes a NPE if url of current project is not set

[Martin Zeltner (JIRA)]

AbstractSiteRenderingMojo causes a NPE if url of current project is not set
---

 Key: MSITE-176
 URL: http://jira.codehaus.org/browse/MSITE-176
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
Affects Versions: 2.0
 Environment: WinXP, Java5
Reporter: Martin Zeltner
Priority: Blocker
 Attachments: patch_maven-site-plugin.txt

AbstractSiteRenderingMojo causes a NullPointerException in 
org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler
 if url of current project is not set.

$ mvn site:site
...
[INFO] [site:site]
[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] null
[INFO] 
[INFO] Trace
java.lang.NullPointerException
at 
org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.getParentPrefix
(DefaultDecorationModelInheritanceAssembler.java:340)
at 
org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleModelIn
heritance(DefaultDecorationModelInheritanceAssembler.java:46)
at 
org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getDecorationModel(AbstractSiteRenderingMojo.java:225
)
at 
org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getDecorationModel(AbstractSiteRenderingMojo.java:217
)
at 
org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getDecorationModel(AbstractSiteRenderingMojo.java:492
)
at 
org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.
java:431)
at 
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:108)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:92)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:417)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav
a:306)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:393)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:182)
at 
org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:690)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:380)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)


This url is mostly not set, anyway not for each child module. To solve this 
issue I did the following in method *getDecorationModel* of 
*org.apache.maven.plugins.site.AbstractSiteRenderingMojo*:

If the parent model descriptor exists, the current and the parent model will be 
assembled by using following url parameters:

If parent's url is null but child's not child's url will be used for parent.
If both urls are null the url ./ will be used for current and parent.

See appended patch.

Cheers,
Martin




-- 
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: (MPJAVADOC-77) taglet allow only one taglet

[Martin Desruisseaux (JIRA)]

taglet allow only one taglet
--

 Key: MPJAVADOC-77
 URL: http://jira.codehaus.org/browse/MPJAVADOC-77
 Project: maven-javadoc-plugin
  Issue Type: Bug
Reporter: Martin Desruisseaux


The {{taglet}} configuration element in the javadoc plugin allows for only 
one taglet, or doesn't document how to add more than one taglet.

* I tried to put one than one {{taglet}} element in the {{pom.xml}} file, but 
the last one seems to override all the previous ones.
* I tried space, coma, : and ; as separator, without success.

It should be possible to add an arbitrary amount of {{taglet}} elements, and 
each of them should register a new taglet (through a new occurence of 
{{-taglet}} argument given to the {{javadoc}} command line I guess). I tested 
that multiple occurence of {{taglet}} works as expected with Ant.


-- 
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: (MNGECLIPSE-59) Allow artifact resolution from workspace projects

[Eugene Kuleshov (JIRA)]

[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_72573 
] 

Eugene Kuleshov commented on MNGECLIPSE-59:
---

I pushed some fixes. Namely: changed key in models Map to string (I wonder if 
it would fix your issue) and fixed issue when artifact version is defined in 
the parent pom.

However there is some weirdness. For instance, when I import maven-tools 
project from http://svn.apache.org/repos/asf/maven/components/trunk/maven-tools 
 I see some broken dependencies and it looks like maven-core is not being 
resolved transitively. Not sure if it is anyhow related to the last 
refactorings or it is just broken snapsht dependencies...

 Allow artifact resolution from workspace projects
 -

 Key: MNGECLIPSE-59
 URL: http://jira.codehaus.org/browse/MNGECLIPSE-59
 Project: Maven 2.x Extension for Eclipse
  Issue Type: New Feature
  Components: Dependency Resolver
Affects Versions: 0.0.4
Reporter: Leonardo Quijano Vincenzi
 Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, 
 mngeclipse-59-drew-hack.txt, project-artifacts-2006062701.patch, 
 project-artifacts-2006062900.patch, project-artifacts.patch


 Provide artifact resolution from workspace projects, which override the same 
 artifact from the local or remote repositories. This would allow to work with 
 dependant Eclipse projects without specifying the Eclipse dependency manually.
 The workspace artifact resolution would have to be specified manually, since 
 several Maven-Enabled projects in the same workspace could have the same 
 artifact and version Id. Or at least automatic resolution with an optional 
 override would be nice.
 More comments here:
 http://jira.codehaus.org/browse/MNGECLIPSE-58

-- 
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: (MAVEN-410) maven plugins seem to choke on properties containing a -?

[Lukas Theussl (JIRA)]

 [ http://jira.codehaus.org/browse/MAVEN-410?page=all ]

Lukas Theussl closed MAVEN-410.
---

 Assignee: Lukas Theussl
   Resolution: Won't Fix
Fix Version/s: (was: 1.1-rc1)

See http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg83427.html

 maven plugins seem to choke on properties containing a -?
 ---

 Key: MAVEN-410
 URL: http://jira.codehaus.org/browse/MAVEN-410
 Project: Maven
  Issue Type: Bug
  Components: core
Affects Versions: 1.0-beta-9
 Environment: RedHat Linux 7.3, JDK 1.3.1
Reporter: Henning Schmiedehausen
 Assigned To: Lukas Theussl

 I'm using the Torque plugin to create id-table init sql files from my
 XML schemas. If I download maven 1.0b9 from apache.org, install it and
 then issue
 % maven -X torque
 I get
 torque:id-table-init-sql:
 Using contextProperties file: 
 /mnt/home.net/henning/cvs/turbine-2/project.properties
 [torque-sql] [VERBOSE] Using templatePath: 
 /mnt/home.net/henning/cvs/turbine-2/src/torqueTemplates
 [torque-sql] Using classpath
 [torque-sql] Generating to file 
 /mnt/home.net/henning/cvs/turbine-2/target/sql/report.idtable-init.sql.generation
 [torque-sql] [DEBUG] fileset: Setup scanner in dir 
 /mnt/home.net/henning/cvs/turbine-2/target with patternSet{ includes: [0] 
 excludes: [0] }
 BUILD SUCCESSFUL
 Total time:  7 seconds
 Note the [0] for include and exclude list in the file scanner.
 If I now load the plugin.properties and plugin.jelly file from
 Torque and replace in both files for the properties
 torque.schema.init-sql.includes
 torque.schema.init-sql.excludes
 the init-sql part with initsql
 and re-issue the command:
 % maven -X torque
 then I get
 torque:id-table-init-sql:
 Using contextProperties file: 
 /mnt/home.net/henning/cvs/turbine-2/project.properties
 [torque-sql] [VERBOSE] Using templatePath: 
 /mnt/home.net/henning/cvs/turbine-2/src/torqueTemplates
 [torque-sql] Using classpath
 [torque-sql] Generating to file 
 /mnt/home.net/henning/cvs/turbine-2/target/sql/report.idtable-init.sql.generation
 [torque-sql] [DEBUG] fileset: Setup scanner in dir 
 /mnt/home.net/henning/cvs/turbine-2/target with patternSet{ includes: 
 [*-schema.xml] excludes: [id-table-schema.xml] }
 Parsing file: 'scheduler-schema.xml'
 log4j:WARN No appenders could be found for logger 
 (org.apache.torque.engine.database.transform.DTDResolver).
 log4j:WARN Please initialize the log4j system properly.
 Parsing file: 'torque-security-schema.xml'
 Parsing file: 'scheduler-idtable-schema.xml'
 Parsing file: 'torque-security-idtable-schema.xml'
 BUILD SUCCESSFUL
 Total time:  9 seconds
 Note that now the file scanner correctly picks up my schema files
 and builds the sql init 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] Moved: (MJAVADOC-85) taglet allow only one taglet

[Lukas Theussl (JIRA)]

 [ http://jira.codehaus.org/browse/MJAVADOC-85?page=all ]

Lukas Theussl moved MPJAVADOC-77 to MJAVADOC-85:


Workflow: Maven New  (was: jira)
 Key: MJAVADOC-85  (was: MPJAVADOC-77)
 Project: Maven 2.x Javadoc Plugin  (was: maven-javadoc-plugin)

 taglet allow only one taglet
 --

 Key: MJAVADOC-85
 URL: http://jira.codehaus.org/browse/MJAVADOC-85
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Reporter: Martin Desruisseaux

 The {{taglet}} configuration element in the javadoc plugin allows for only 
 one taglet, or doesn't document how to add more than one taglet.
 * I tried to put one than one {{taglet}} element in the {{pom.xml}} file, 
 but the last one seems to override all the previous ones.
 * I tried space, coma, : and ; as separator, without success.
 It should be possible to add an arbitrary amount of {{taglet}} elements, 
 and each of them should register a new taglet (through a new occurence of 
 {{-taglet}} argument given to the {{javadoc}} command line I guess). I tested 
 that multiple occurence of {{taglet}} works as expected with Ant.

-- 
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: (MPMULTIPROJECT-69) report failed throwing NullPointerException invoking getProjects

[Lukas Theussl (JIRA)]

 [ http://jira.codehaus.org/browse/MPMULTIPROJECT-69?page=all ]

Lukas Theussl closed MPMULTIPROJECT-69.
---

  Assignee: Lukas Theussl
Resolution: Cannot Reproduce

Cannot reproduce without user feedback, please reopen with more detailed 
information if necessary.

 report failed throwing NullPointerException invoking getProjects
 

 Key: MPMULTIPROJECT-69
 URL: http://jira.codehaus.org/browse/MPMULTIPROJECT-69
 Project: maven-multiproject-plugin
  Issue Type: Bug
Affects Versions: 1.5
 Environment: maven 1.1-beta-3-SNAPSHOT (20060729), windows 2000
Reporter: Piotr Kania
 Assigned To: Lukas Theussl
Priority: Blocker

 running command maven site for project containing report 
 maven-multiproject-plugin following error occurs:
 multiproject:dependency-convergence-report:
 BUILD FAILED
 org.apache.velocity.exception.MethodInvocationException: Invocation of method 
 'getProjects' in  clas
 s org.apache.maven.multiproject.harmonizer.MultiDependency threw exception 
 class java.lang.NullPoint
 erException : null
 at 
 org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:246)
 at 
 org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:175)
 at 
 org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:327)
 at 
 org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:131)
 at 
 org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:114)
 at 
 org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:55)
 at 
 org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:166)
 at 
 org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:114)
 at 
 org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:55)
 at 
 org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:166)
 at 
 org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:114)
 at 
 org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:230)
 at org.apache.velocity.Template.merge(Template.java:256)
 at 
 org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:450)
 at 
 org.apache.commons.jelly.tags.velocity.MergeTag.mergeTemplate(MergeTag.java:186)
 at 
 org.apache.commons.jelly.tags.velocity.MergeTag.doTag(MergeTag.java:68)
 at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
 at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
 at 
 org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:82)
 at 
 org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag
 .java:115)
 at org.apache.maven.werkz.Goal.fire(Goal.java:647)
 at org.apache.maven.werkz.Goal.attain(Goal.java:582)
 at 
 org.apache.maven.werkz.WerkzProject.attainGoal(WerkzProject.java:208)
 at 
 org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:114)
 at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
 at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
 at 
 org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:82)
 at 
 org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag
 .java:115)
 at org.apache.maven.werkz.Goal.fire(Goal.java:647)
 at org.apache.maven.werkz.Goal.attain(Goal.java:582)
 at 
 org.apache.maven.werkz.WerkzProject.attainGoal(WerkzProject.java:208)
 at 
 org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:114)
 at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
 at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
 at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
 at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:46)
 at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
 at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
 at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
 at 
 org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:38)
 at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
 at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
 at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
 at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:42)
 at 

[jira] Commented: (MJAVADOC-85) taglet allow only one taglet

[Shinobu Kawai (JIRA)]

[ http://jira.codehaus.org/browse/MJAVADOC-85?page=comments#action_72576 ] 

Shinobu Kawai commented on MJAVADOC-85:
---

Unfortunately, the plugin currently only allows one taglet.

 taglet allow only one taglet
 --

 Key: MJAVADOC-85
 URL: http://jira.codehaus.org/browse/MJAVADOC-85
 Project: Maven 2.x Javadoc Plugin
  Issue Type: Bug
Reporter: Martin Desruisseaux

 The {{taglet}} configuration element in the javadoc plugin allows for only 
 one taglet, or doesn't document how to add more than one taglet.
 * I tried to put one than one {{taglet}} element in the {{pom.xml}} file, 
 but the last one seems to override all the previous ones.
 * I tried space, coma, : and ; as separator, without success.
 It should be possible to add an arbitrary amount of {{taglet}} elements, 
 and each of them should register a new taglet (through a new occurence of 
 {{-taglet}} argument given to the {{javadoc}} command line I guess). I tested 
 that multiple occurence of {{taglet}} works as expected with Ant.

-- 
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: (MPWAR-63) ClassNotFoundException when trying to war SNAPSHOT version

[Lukas Theussl (JIRA)]

[ http://jira.codehaus.org/browse/MPWAR-63?page=comments#action_72577 ] 

Lukas Theussl commented on MPWAR-63:


Cannot reproduce with jdk 1.4.2_11 ...

 ClassNotFoundException when trying to war SNAPSHOT version
 --

 Key: MPWAR-63
 URL: http://jira.codehaus.org/browse/MPWAR-63
 Project: maven-war-plugin
  Issue Type: Bug
Affects Versions: 1.6.2
 Environment: Fedora Core 5
 Sun JDK 1.5.0_07
 Maven 1.1-beta3
Reporter: Steve Molloy

 When trying to build a war for a SNAPSHOT version, a ClassNotFoundException 
 occurs when trying to perform the staticInvoke on StringUtils:
 ...
 war:war:
 [echo] Building WAR TawJni
 BUILD FAILED
 java.lang.ClassNotFoundException: org.apache.commons.lang.StringUtils
   at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
   at 
 org.apache.commons.jelly.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:91)
   at 
 org.apache.commons.jelly.tags.core.InvokeStaticTag.loadClass(InvokeStaticTag.java:167)
   at 
 org.apache.commons.jelly.tags.core.InvokeStaticTag.doTag(InvokeStaticTag.java:124)
   at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
   at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
   at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
   at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:46)
   at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
   at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
   at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
   at org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:38)
   at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
   at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
   at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
   at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234)
   at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:222)
   at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:237)
   at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
   at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
   at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186)
   at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234)
   at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:222)
   at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:160)
   at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
   at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
   at 
 org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:82)
   at 
 org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:115)
   at org.apache.maven.werkz.Goal.fire(Goal.java:647)
   at org.apache.maven.werkz.Goal.attain(Goal.java:582)
   at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:494)
   at org.apache.maven.werkz.Goal.attain(Goal.java:580)
   at 
 org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:709)
   at org.apache.maven.MavenSession.attainGoals(MavenSession.java:264)
   at org.apache.maven.cli.App.doMain(App.java:546)
   at org.apache.maven.cli.App.main(App.java:1390)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 File.. file:/home/smolloy/.maven/cache/maven-war-plugin-1.6.2/plugin.jelly
 Element... j:invokeStatic
 Line.. 103
 Column 130
 org.apache.commons.lang.StringUtils
   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 com.werken.forehead.Forehead.run(Forehead.java:551)
   at com.werken.forehead.Forehead.main(Forehead.java:581)
 Total time   : 2 minutes 26 seconds 
 Finished at  : Monday, August 14, 2006 11:06:43 EDT AM

-- 
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-1911) Building plugins with extensions in a reactor fails

[Jason Dillon (JIRA)]

[ http://jira.codehaus.org/browse/MNG-1911?page=comments#action_72578 ] 

Jason Dillon commented on MNG-1911:
---

Any status on when this will make it into a m2 release?

 Building plugins with extensions in a reactor fails
 ---

 Key: MNG-1911
 URL: http://jira.codehaus.org/browse/MNG-1911
 Project: Maven 2
  Issue Type: Bug
Affects Versions: 2.0.1
Reporter: Guillaume Nodet
Priority: Critical
 Fix For: 2.0.5


 I have the following in my main pom
   build
 pluginManagement
   plugins
 plugin
   groupIdorg.apache.servicemix.plugins/groupId
   artifactIdmaven2-jbi-plugin/artifactId
   version1.0-SNAPSHOT/version
   extensionstrue/extensions
 /plugin
   /plugins
 /pluginManagement
   /build
 If i try to add it to the modules, the first time, maven complains that it 
 can not download the plugin.
 If i remove the extensions tag, all works, but i need it :)

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

[jira] Closed: (MAVENUPLOAD-1051) TestNG 5.1 release

[Carlos Sanchez (JIRA)]

 [ http://jira.codehaus.org/browse/MAVENUPLOAD-1051?page=all ]

Carlos Sanchez closed MAVENUPLOAD-1051.
---

  Assignee: Carlos Sanchez
Resolution: Fixed

 TestNG 5.1 release
 --

 Key: MAVENUPLOAD-1051
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1051
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Jesse Kuhnert
 Assigned To: Carlos Sanchez
 Attachments: testng-5.1.tgz


 A new release of TestNG has been made, 5.1. The attached tgz contains the two 
 jdk14/jdk15 jars as well as the main pom.xml . 

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

[jira] Commented: (MAVENUPLOAD-1047) Upload Retroweaver 1.2.4

[Carlos Sanchez (JIRA)]

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1047?page=comments#action_72579 ] 

Carlos Sanchez commented on MAVENUPLOAD-1047:
-

so is this ready or not ?

 Upload Retroweaver 1.2.4
 

 Key: MAVENUPLOAD-1047
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1047
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Xavier Le Vourch

 Retroweaver is a tool, which converts Java 5 (or 6) compliant
 class files into Java 1.x compliant class files. The jar file
 retroweaver.jar contains both the class processor (which may
 be used at compile time) and the runtime classes. Additionally
 there is the jar file retroweaver-rt.jar (which contains the
 runtime classes only).
 The bundle contains file for both the retroweaver and retroweaver-rt 
 subpackages.

-- 
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: (MAVENUPLOAD-1029) fit-1.1

[Carlos Sanchez (JIRA)]

 [ http://jira.codehaus.org/browse/MAVENUPLOAD-1029?page=all ]

Carlos Sanchez closed MAVENUPLOAD-1029.
---

Resolution: Fixed

 fit-1.1 
 

 Key: MAVENUPLOAD-1029
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1029
 Project: maven-upload-requests
  Issue Type: Wish
Reporter: Mauro Talevi
 Assigned To: Carlos Sanchez

 Please upload fit-1.1.jar with POM
 project
   modelVersion4.0.0/modelVersion
   groupIdfit/groupId
   artifactIdfit/artifactId
   nameFit/name
   version1.1/version
 /project  
 

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

[jira] Commented: (MAVENUPLOAD-1050) content repository API 1.0 and 1.0.1

[Carlos Sanchez (JIRA)]

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1050?page=comments#action_72580 ] 

Carlos Sanchez commented on MAVENUPLOAD-1050:
-

Does that license allow redistribution?

 content repository API 1.0 and 1.0.1
 

 Key: MAVENUPLOAD-1050
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1050
 Project: maven-upload-requests
  Issue Type: Task
Reporter: fabrizio giustina

 version 1.0 bundle: 
 http://maven-taglib.sourceforge.net/bundles/jcr-1.0-bundle.jar
 version 1.0.1 bundle: 
 http://maven-taglib.sourceforge.net/bundles/jcr-1.0.1-bundle.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] Closed: (MAVENUPLOAD-1052) SUN runtime 1.3.1_18

[Carlos Sanchez (JIRA)]

 [ http://jira.codehaus.org/browse/MAVENUPLOAD-1052?page=all ]

Carlos Sanchez closed MAVENUPLOAD-1052.
---

  Assignee: Carlos Sanchez
Resolution: Fixed

 SUN runtime 1.3.1_18
 

 Key: MAVENUPLOAD-1052
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1052
 Project: maven-upload-requests
  Issue Type: Task
Reporter: nicolas de loof
 Assigned To: Carlos Sanchez

 SUN JRE runtime

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

[jira] Commented: (MAVENUPLOAD-1055) Please Upload Registry J2SE

[Carlos Sanchez (JIRA)]

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1055?page=comments#action_72581 ] 

Carlos Sanchez commented on MAVENUPLOAD-1055:
-

You have to proof ownership over jvending.org to use that groupId

 Please Upload Registry J2SE
 ---

 Key: MAVENUPLOAD-1055
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1055
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Shane Isbell

 This library provides a registry function for storing and finding data. It 
 supports Hibernate2, Hibernate3 and JAXB configuration 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] Closed: (MAVENUPLOAD-1054) Please upload EZMorph-0.8.1

[Carlos Sanchez (JIRA)]

 [ http://jira.codehaus.org/browse/MAVENUPLOAD-1054?page=all ]

Carlos Sanchez closed MAVENUPLOAD-1054.
---

  Assignee: Carlos Sanchez
Resolution: Fixed

 Please upload EZMorph-0.8.1
 ---

 Key: MAVENUPLOAD-1054
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1054
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Andres Almiray
 Assigned To: Carlos Sanchez

 EZMorph is simple java library for transforming an Object to another Object.
 EZMorph is a dependency of upcoming releases Json-lib.
 Bundle was created by hand according to spec.
 The pom includes a PluginRepositories definition for the FindBugs plugin at 
 codehaus.

-- 
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: (MAVENUPLOAD-1057) JCommon 1.0.5

[Carlos Sanchez (JIRA)]

 [ http://jira.codehaus.org/browse/MAVENUPLOAD-1057?page=all ]

Carlos Sanchez closed MAVENUPLOAD-1057.
---

  Assignee: Carlos Sanchez
Resolution: Fixed

 JCommon 1.0.5
 -

 Key: MAVENUPLOAD-1057
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1057
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Takayoshi Kimura
 Assigned To: Carlos Sanchez
 Attachments: jcommon-1.0.5-bundle.jar


 http://www.jfree.org/jcommon/

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

[jira] Commented: (MAVENUPLOAD-1055) Please Upload Registry J2SE

[Shane Isbell (JIRA)]

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1055?page=comments#action_72582 ] 

Shane Isbell commented on MAVENUPLOAD-1055:
---

The domain entry of my control of the domain name is at: 
http://reports.internic.net/cgi/whois?whois_nic=jvending.orgtype=domain.

 Please Upload Registry J2SE
 ---

 Key: MAVENUPLOAD-1055
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1055
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Shane Isbell

 This library provides a registry function for storing and finding data. It 
 supports Hibernate2, Hibernate3 and JAXB configuration 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: (MAVEN-1779) Un-deprecate maven.src.dir

[Lukas Theussl (JIRA)]

Un-deprecate maven.src.dir
--

 Key: MAVEN-1779
 URL: http://jira.codehaus.org/browse/MAVEN-1779
 Project: Maven
  Issue Type: Wish
  Components: documentation
Affects Versions: 1.1-beta-3
Reporter: Lukas Theussl
 Assigned To: Lukas Theussl
 Fix For: 1.1-rc1


The current properties reference [1] falsely states that maven.src.dir is not 
used anymore, - it is still used in current ear, ejb, rar, war plugins (at 
least). I'd also like to use it to resolve MPDIST-29, are there any 
objections/remarks? We'd just have to update the documentation.

[1] 
http://maven.apache.org/maven-1.x/reference/properties.html#Build_Structure_Properties

-- 
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-1058) Incorrect POM for xdoclet-bea-module.

[Davy Toch (JIRA)]

Incorrect POM for xdoclet-bea-module.
-

 Key: MAVENUPLOAD-1058
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1058
 Project: maven-upload-requests
  Issue Type: Improvement
Reporter: Davy Toch


The POM should also include a dependency to xdoclet-web-module.

-- 
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: (MPDIST-29) src distribution archive has incorrect directory structure

[Lukas Theussl (JIRA)]

[ http://jira.codehaus.org/browse/MPDIST-29?page=comments#action_72583 ] 

Lukas Theussl commented on MPDIST-29:
-

This has the disadvantage that src will be hardcoded in the jelly script. 
What if somebody has a sourceDirectorysource/main/java/sourceDirectory 
element? I first thought I'd introduce a new maven.dist.src.dir property, but 
then realized that the common maven.src.dir would be better fit for that. See 
MAVEN-1779.

 src distribution archive has incorrect directory structure
 --

 Key: MPDIST-29
 URL: http://jira.codehaus.org/browse/MPDIST-29
 Project: maven-dist-plugin
  Issue Type: Bug
Affects Versions: 1.7
Reporter: Jarkko Viinamäki
 Fix For: 1.7.1


 With Maven 1.1-beta-2 and maven-dist-plugin-1.7:
 if my project.xml defines:
 build
 sourceDirectorysrc/main/java/sourceDirectory
 ...
 Then the dist:build-src target generates an incorrect src distribution file 
 since the source files are packaged to path src/foo/bar/MyClass.java instead 
 of src/main/java/foo/bar/MyClass.java
 -
 To fix this, change the dist:prepare-src-filesystem goal in 
 maven-dist-plugin-1.7 to read:
 util:available file=src
 ant:copy todir=${maven.dist.src.assembly.dir}/src
 ant:fileset dir=src /
 /ant:copy
 /util:available
 This will preserve the actual directory structure.

-- 
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-2511) Need ability to redefine distribution management url

[Brian Fox (JIRA)]

Need ability to redefine distribution management url


 Key: MNG-2511
 URL: http://jira.codehaus.org/browse/MNG-2511
 Project: Maven 2
  Issue Type: Improvement
  Components: Settings
Affects Versions: 2.0.4
Reporter: Brian Fox


Currently the only way to specify a url for distributionManagement is in the 
pom. We need to be able to override that so that if needed a developer can set 
a server id in their settings and define a new url. For example, some 
developers are outside the company's infrastructure and they deploy differently 
than developers internally. 

-- 
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-2511) Need ability to redefine distribution management url

[Milos Kleint (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2511?page=comments#action_72588 ] 

Milos Kleint commented on MNG-2511:
---

putting a variable property in the disributionManagement section and defining 
the property in settings.xml (optionally also define reasonable defaults in the 
pom.xml) doesn't work?


 Need ability to redefine distribution management url
 

 Key: MNG-2511
 URL: http://jira.codehaus.org/browse/MNG-2511
 Project: Maven 2
  Issue Type: Improvement
  Components: Settings
Affects Versions: 2.0.4
Reporter: Brian Fox

 Currently the only way to specify a url for distributionManagement is in the 
 pom. We need to be able to override that so that if needed a developer can 
 set a server id in their settings and define a new url. For example, some 
 developers are outside the company's infrastructure and they deploy 
 differently than developers internally. 

-- 
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-2511) Need ability to redefine distribution management url

[Arik Kfir (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2511?page=comments#action_72590 ] 

Arik Kfir commented on MNG-2511:


Milos,

It should work, but I think this JIRA refers to use-cases when the project at 
hand had not defined such a property. For example, we work in an offline 
environment, where I'd like to generate and deploy the Maven site to our 
intranet servers. I cannot do that since such a property does not exist in 
components/pom.xml.

 Need ability to redefine distribution management url
 

 Key: MNG-2511
 URL: http://jira.codehaus.org/browse/MNG-2511
 Project: Maven 2
  Issue Type: Improvement
  Components: Settings
Affects Versions: 2.0.4
Reporter: Brian Fox

 Currently the only way to specify a url for distributionManagement is in the 
 pom. We need to be able to override that so that if needed a developer can 
 set a server id in their settings and define a new url. For example, some 
 developers are outside the company's infrastructure and they deploy 
 differently than developers internally. 

-- 
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-138) No way to use moduleSet in a multi-level project

[Travis Carlson (JIRA)]

No way to use moduleSet in a multi-level project
--

 Key: MASSEMBLY-138
 URL: http://jira.codehaus.org/browse/MASSEMBLY-138
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Travis Carlson


The moduleSet as illustrated at 
http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html
assumes that all modules are directly below the pom.xml and therefore does not 
work in a hierarchical (multi-level) project structure.  

See discussion thread: 
http://www.nabble.com/Assembly-and-multi-levels-multi-modules-t1747056.html

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

[jira] Commented: (MNG-2510) Maven 2.0.4 is failing at Getting-Started-Tour

[Dennis Lundberg (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2510?page=comments#action_72593 ] 

Dennis Lundberg commented on MNG-2510:
--

This happens sometimes if ibiblio is under extremely heavy load. Did you try to 
run the command a second time? If not, please try that and report back.

 Maven 2.0.4 is failing at Getting-Started-Tour
 --

 Key: MNG-2510
 URL: http://jira.codehaus.org/browse/MNG-2510
 Project: Maven 2
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 2.0.4
 Environment: SuSE Linux 10.1
 java version 1.5.0_07
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
 Java HotSpot(TM) Client VM (build 1.5.0_07-b03, mixed mode, sharing)
Reporter: Markus KARG

 Followed the Getting-Started-Tour, everything worked well until the following 
 command:
 [EMAIL PROTECTED]:~/my-app mvn idea:idea
 [INFO] Scanning for projects...
 [INFO] Searching repository for plugin with prefix: 'idea'.
 [INFO] artifact org.apache.maven.plugins:maven-idea-plugin: checking for 
 updates from central
 Downloading: 
 http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-idea-plugin/2.0/maven-idea-plugin-2.0.pom
 2K downloaded
 Downloading: 
 http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugins/1/maven-plugins-1.pom
 3K downloaded
 Downloading: 
 http://repo1.maven.org/maven2/org/apache/maven/maven-parent/1/maven-parent-1.pom
 6K downloaded
 Downloading: http://repo1.maven.org/maven2/org/apache/apache/1/apache-1.pom
 3K downloaded
 Downloading: 
 http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-idea-plugin/2.0/maven-idea-plugin-2.0.jar
 37K downloaded
 [INFO] 
 
 [INFO] Building Maven Quick Start Archetype
 [INFO]task-segment: [idea:idea]
 [INFO] 
 
 [INFO] Preparing idea:idea
 [INFO] No goals needed for project - skipping
 Downloading: 
 http://repo1.maven.org/maven2/org/apache/maven/maven-project/2.0.1/maven-project-2.0.1.pom
 1K downloaded
 Downloading: 
 http://repo1.maven.org/maven2/org/apache/maven/maven/2.0.1/maven-2.0.1.pom
 11K downloaded
 Downloading: 
 http://repo1.maven.org/maven2/org/apache/maven/maven-model/2.0.1/maven-model-2.0.1.pom
 2K downloaded
 Downloading: 
 http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.0.5/plexus-utils-1.0.5.pom
 918b downloaded
 Downloading: 
 http://repo1.maven.org/maven2/org/apache/maven/maven-profile/2.0.1/maven-profile-2.0.1.pom
 1K downloaded
 Downloading: 
 http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.pom
 1K downloaded
 Downloading: 
 http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-containers/1.0.3/plexus-containers-1.0.3.pom
 492b downloaded
 Downloading: 
 http://repo1.maven.org/maven2/org/apache/maven/maven-artifact-manager/2.0.1/maven-artifact-manager-2.0.1.pom
 1K downloaded
 Downloading: 
 http://repo1.maven.org/maven2/org/apache/maven/maven-repository-metadata/2.0.1/maven-repository-metadata-2.0.1.pom
 1K downloaded
 Downloading: 
 http://repo1.maven.org/maven2/org/apache/maven/maven-artifact/2.0.1/maven-artifact-2.0.1.pom
 765b downloaded
 Downloading: 
 http://repo1.maven.org/maven2/org/apache/maven/maven-plugin-api/2.0.1/maven-plugin-api-2.0.1.pom
 643b downloaded
 Downloading: http://repo1.maven.org/maven2/dom4j/dom4j/1.6.1/dom4j-1.6.1.pom
 6K downloaded
 Downloading: 
 http://repo1.maven.org/maven2/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.pom
 [INFO] 
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Error building POM (may not be this project's POM).
 Project ID: xml-apis:xml-apis
 Reason: Error getting POM for 'xml-apis:xml-apis' from the repository: Error 
 transferring file
   xml-apis:xml-apis:pom:1.0.b2
 from the specified remote repositories:
   central (http://repo1.maven.org/maven2),
   apache.snapshots (http://svn.apache.org/maven-snapshot-repository),
   snapshots (http://snapshots.maven.codehaus.org/maven2)
 [INFO] 
 
 [INFO] For more information, run Maven with the -e switch
 [INFO] 
 
 [INFO] Total time: 13 seconds
 [INFO] Finished at: Thu Aug 17 13:45:18 CEST 2006
 [INFO] Final Memory: 2M/4M
 [INFO] 
 

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

[jira] Closed: (MCHANGELOG-43) Changelog not getting created properly.

[Dennis Lundberg (JIRA)]

 [ http://jira.codehaus.org/browse/MCHANGELOG-43?page=all ]

Dennis Lundberg closed MCHANGELOG-43.
-

Resolution: Won't Fix

The problem was in the org.codehaus.mojo version of the plugin.

 Changelog not getting created properly.
 ---

 Key: MCHANGELOG-43
 URL: http://jira.codehaus.org/browse/MCHANGELOG-43
 Project: Maven 2.x Changelog Plugin
  Issue Type: Bug
Affects Versions: 2.0-beta-1
 Environment: Windows xp SP2 / maven 2.0.4
Reporter: Abhijit Diwan

 I am trying to generate change log for my maven project. 
 I have following scm section under my pom.xml
 scm
 connectionscm:perforce://EJB/ejb-dev/MavenCodeline//connection
 /scm
 and following plugin decalration under reporting section
 plugin
 groupIdorg.codehaus.mojo/groupId
 artifactIdchangelog-maven-plugin/artifactId
 reportSets
 reportSet
 idPerofrce report/id
 configuration
 typerange/type
 range10/range
 repositoryConnection
 
 scm:perforce://EJB/ejb-dev/MavenCodeline//repositoryConnection
 properties
 maven.changelog.factory
 
 org.apache.maven.perforcelib.PerforceChangeLogFactory/maven.changelog.factory
 /properties
 /configuration
 reports
 reportchangelog/report
 reportfile-activity/report
 reportdev-activity/report
 /reports
 /reportSet
 /reportSets
 /plugin
 I have already defined P4PORT variable on my machine.
 When I ran mvn site command from module directory AeConnector I get following 
 error.
 [INFO] Generating changed sets xml to: 
 E:\views\EJB\ejb-dev\MavenCodeline\AeConn
 ector\target\changelog.xml
 [INFO] SCM Working Directory: 
 E:\views\EJB\ejb-dev\MavenCodeline\AeConnector\src
 \main\java
 [INFO] SCM Command Line[0]: p4
 [INFO] SCM Command Line[1]: filelog
 [INFO] SCM Command Line[2]: -tl
 [INFO] SCM Command Line[3]: //EJB/ejb-dev/MavenCodeline/AeConnector
 [ERROR] //EJB/ejb-dev/MavenCodeline/AeConnector - no such file(s).
 All my java code is under that directory but the plugin is not able to 
 recurse all the subdirectories under that directory. I looked at perforce doc 
 and ran command p4 filelog //EJB/ejb-dev/MavenCodeline/AeConnector/... and 
 it worked so I think with plugin those last 3 dots which makes p4 recurse is 
 not there. The documentation for p4 command you can find from following url - 
 (http://www.perforce.com/perforce/doc.051/manuals/cmdref/filelog.html)
 Please please help.
 thanks a lot
 abhijit

-- 
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: (MPWAR-45) [PATCH] war:inplace should check for maven.war.src

[Lukas Theussl (JIRA)]

 [ http://jira.codehaus.org/browse/MPWAR-45?page=all ]

Lukas Theussl closed MPWAR-45.
--

  Assignee: Lukas Theussl
Resolution: Fixed

 [PATCH] war:inplace should check for maven.war.src
 --

 Key: MPWAR-45
 URL: http://jira.codehaus.org/browse/MPWAR-45
 Project: maven-war-plugin
  Issue Type: Improvement
Affects Versions: 1.6
Reporter: Kim Dykeman
 Assigned To: Lukas Theussl
Priority: Minor
 Fix For: 1.6.3

 Attachments: maven-plugins-war-inplace.patch


 The war:inplace goal doesn't check to see if maven.war.src is present prior 
 to running war:webapp.  The result when used with the multiproject plugin is 
 several webapp directories being created in subprojects that don't build a 
 war artifact.

-- 
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-1059) j2ssh (sshtools) 0.2.7

[Michael Burton (JIRA)]

j2ssh (sshtools) 0.2.7
--

 Key: MAVENUPLOAD-1059
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1059
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Michael Burton


update to j2ssh.  Built from 
http://prdownloads.sourceforge.net/sshtools/j2ssh-0.2.7-src.tar.gz

SSHTools is a suite of Java SSH applications providing a Java SSH API, SSH 
Terminal, SSH secured VNC client, SFTP client and SSH Daemon.

-- 
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-821) The Project.getBuildResults() method returns an empty list

[John Smart (JIRA)]

The Project.getBuildResults() method returns an empty list
--

 Key: CONTINUUM-821
 URL: http://jira.codehaus.org/browse/CONTINUUM-821
 Project: Continuum
  Issue Type: Bug
  Components: XMLRPC Interface
Affects Versions: 1.0.3
 Environment: JDK 1.5.0_07, Linux (Fedora Core 5)
Reporter: John Smart


The Project.getBuildResults() method returns an empty list.  The unit test is 
shown here:

@Test
public void testGetProjectBuildResults() throws XmlRpcException, 
IOException {
String url = http://localhost:8000/continuum;;
ProjectsReader pr = new ProjectsReader( new URL( url ) );

Project[] projects =  projects = pr.readProjects();
//
// Note: All the projects on the localhost server have builds
//
for ( Project project : projects){

   ListBuildResult buildResults = project.getBuildResults();
   //
   // Builds have been defined
   //
   assertTrue(project.getBuildDefinitions().size()  0);
   //
   // Builds have been done
   //
   assertTrue(project.getBuildNumber()  0);
   //
   // We can access the build results
   //
   assertNotNull(buildResults);
   //
   // Test fails here:
   //
   assertTrue(buildResults.size()  0);
}
}


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

[jira] Closed: (MPWAR-36) tld folder is always created

[Lukas Theussl (JIRA)]

 [ http://jira.codehaus.org/browse/MPWAR-36?page=all ]

Lukas Theussl closed MPWAR-36.
--

  Assignee: Lukas Theussl
Resolution: Fixed

 tld folder is always created
 

 Key: MPWAR-36
 URL: http://jira.codehaus.org/browse/MPWAR-36
 Project: maven-war-plugin
  Issue Type: Bug
Affects Versions: 1.7, 1.6.3
Reporter: Alexey Adamov
 Assigned To: Lukas Theussl
Priority: Trivial
 Fix For: 1.6.3


 maven-1.1-SNAPSHOT, maven-war-plugin-1.7-SNAPSHOT
 Problem: web application may not use tld and even jsp, so tld is not always 
 needed
 Now i need to set ${mave.war.tld.dir}=WEB-INF, it works, but it is an anal 
 solution.
 Proposal:
   do not create ${mave.war.tld.dir} folder when no tld libs are defined   in 
 the dependencies (so no file need to be copied)
 --
 Great thanks in prior

-- 
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-821) The Project.getBuildResults() method returns an empty list

[Emmanuel Venisse (JIRA)]

 [ http://jira.codehaus.org/browse/CONTINUUM-821?page=all ]

Emmanuel Venisse updated CONTINUUM-821:
---

Fix Version/s: 1.1

 The Project.getBuildResults() method returns an empty list
 --

 Key: CONTINUUM-821
 URL: http://jira.codehaus.org/browse/CONTINUUM-821
 Project: Continuum
  Issue Type: Bug
  Components: XMLRPC Interface
Affects Versions: 1.0.3
 Environment: JDK 1.5.0_07, Linux (Fedora Core 5)
Reporter: John Smart
 Fix For: 1.1


 The Project.getBuildResults() method returns an empty list.  The unit test is 
 shown here:
 @Test
 public void testGetProjectBuildResults() throws XmlRpcException, 
 IOException {
   String url = http://localhost:8000/continuum;;
   ProjectsReader pr = new ProjectsReader( new URL( url ) );
   
   Project[] projects =  projects = pr.readProjects();
   //
   // Note: All the projects on the localhost server have builds
   //
   for ( Project project : projects){
   
  ListBuildResult buildResults = project.getBuildResults();
  //
  // Builds have been defined
  //
  assertTrue(project.getBuildDefinitions().size()  0);
  //
  // Builds have been done
  //
  assertTrue(project.getBuildNumber()  0);
  //
  // We can access the build results
  //
  assertNotNull(buildResults);
  //
  // Test fails here:
  //
  assertTrue(buildResults.size()  0);
   }
 }

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

[jira] Commented: (MPARTIFACT-71) Can't deploy artifacts due to reject HostKey error

[Jeff Jensen (JIRA)]

[ http://jira.codehaus.org/browse/MPARTIFACT-71?page=comments#action_72596 
] 

Jeff Jensen commented on MPARTIFACT-71:
---

Good job Arnaud, the new snapshot works for SFTP.

 Can't deploy artifacts due to reject HostKey error
 

 Key: MPARTIFACT-71
 URL: http://jira.codehaus.org/browse/MPARTIFACT-71
 Project: maven-artifact-plugin
  Issue Type: Bug
Affects Versions: 1.8
 Environment: Client=Win XP; Maven 1.1b3; deploying tasks 1.3-snapshot 
 to maven-plugins at SourceForge
Reporter: Jeff Jensen
 Assigned To: Arnaud Heritier
Priority: Blocker
 Fix For: 1.8.1


 This is the high-level error info:
 plugin:repository-deploy:
 [echo] Deploying...
 Will deploy to 1 repository(ies): maven.plugins.sf.snapshots
 Deploying to repository: maven.plugins.sf.snapshots
 Failed to deploy to: maven.plugins.sf.snapshots Reason: 
 org.apache.maven.wagon.authentication.AuthenticationException: Cannot 
 connect. Reason: reject HostKey: shell.sourceforge.net
 org.apache.maven.wagon.authentication.AuthenticationException: Cannot 
 connect. Reason: reject HostKey: shell.sourceforge.net
 at 
 org.apache.maven.wagon.providers.ssh.AbstractSshWagon.openConnection(AbstractSshWagon.java:232)
 If I use m1.1b3-snapshot of 6/30 from Arnaud's website, it works.  Any 
 snapshot after that and the b3 release do not work - they have this problem.
 I think (but not sure) one key procedure to reproducing this is to start with 
 clean repo and plugins install area: delete the .maven dir and any existing 
 Maven program dir (the plugins must start with only the bundled ones).

-- 
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: (MJAR-7) jar plugin recreates jar files all the time

[Richard Allen (JIRA)]

[ http://jira.codehaus.org/browse/MJAR-7?page=comments#action_72598 ] 

Richard Allen commented on MJAR-7:
--

Maven 2 has several great features, but the performance as compared to what you 
can get with Ant is quite disappointing. Because Maven 2 re-creates and 
re-installs artifacts (JAR, WAR, ZIP, whatever) even when no code or POM 
changes have been made, development multi-module builds are considerably slower 
than Ant, which does not recreate a JAR/WAR project if not necessary. This 
slows you down when you simply need to make a small change in one project of a 
multi-project build and re-build to test the change.

 jar plugin recreates jar files all the time
 ---

 Key: MJAR-7
 URL: http://jira.codehaus.org/browse/MJAR-7
 Project: Maven 2.x Jar Plugin
  Issue Type: Bug
Reporter: Jochen Wiedmann
 Attachments: plexus-archiver-up2date.patch


 The jar plugin doesn't seem to check, whether rebuilding a jar file is 
 actually required. For daily work, it would be faster to do what Ant's jar 
 task does: Compare the timestamps of the input files with the timestamp of 
 the target file.
 While this approach has the obvious advantage of being safe (and thus 
 possibly well choosen as a default), it is not appropriate for large 
 projects, where a single build requires a real lot of jar files being 
 rebuilt, even if only a single source file has been changed. This applies, in 
 particular, because comparable plugins like the war, ear, and assembly plugin 
 are forced to behave in the same manner.
 Suggestion:
 - Introduce a new property, for example maven.build.force. The main idea of 
 the property would
   be, that other plugins (install, war, assembly, ...) would listen to the 
 same property. While they
   would possible ignore it initially, one could add support later on.
 - The default property value would be true.
 - If the property value is set to false, then the jar plugin compares the 
 timestamps of the input files with
   the timestamp of the output file. If the latter is newer than the input 
 timestamps, then the jar file isn't
   being rebuilt.
 I am ready to provide a patch, if my suggestion should find interest.

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

[jira] Commented: (MRELEASE-151) All child modules are forced to share the same parent POM

[John Casey (JIRA)]

[ http://jira.codehaus.org/browse/MRELEASE-151?page=comments#action_72602 ] 

John Casey commented on MRELEASE-151:
-

FWIW, it might be helpful to know how you arrived at the conclusion that the 
release plugin expects all modules to have the same parent. What symptoms are 
you seeing?

 All child modules are forced to share the same parent POM
 -

 Key: MRELEASE-151
 URL: http://jira.codehaus.org/browse/MRELEASE-151
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
Affects Versions: 2.0-beta-4
 Environment: Windows XP
Reporter: James Carpenter
Priority: Blocker

 Problem Description:
 Assume the following layout:
 fooProject/pom.xml
 fooProject/dotnet1/pom.xml (has parent pom of maven-csharp-master-parent)
 fooProject/dotnet2/pom.xml (has parent pom of maven-csharp-master-parent)
 fooProject/dotnet3/pom.xml (has parent pom of maven-csharp-master-parent)
 fooProject/java1/pom.xml (has parent pom found above it ../pom.xml)
 fooProject/java2/pom.xml (has parent pom found above it ../pom.xml)
 fooProject/java3/pom.xml (has parent pom of 
 maven-fancy-framework-master-parent)
 Assume fooProject/pom.xml lists dotnet1, dotnet2, dotnet3, java1, and java2 
 in the modules section.  Furthemore, assume that the dotnet modules all refer 
 to a parent pom of maven-csharp-master-parent rather than refering to the pom 
 shown at fooProject/pom.xml.  By changing into the fooProject directory one 
 can successfully run mvn clean, and mvn install without any problems.  
 Unfortunately, the maven release plugin has problems because it seems to 
 expect all of the child poms to refer to the parent above them.
 Motivation:
 Any time a child pom needs a bunch of custom plugin's configured, its always 
 nice to inherit the setup from a parent pom.  As it turns out, modules which 
 should naturally be released and packaged together occassionally need to be 
 configured quite differently.  This is certainly the case whenever dotnet 
 code is co-released with java code.  The dotnet code requires a significant 
 number of custom plugins be setup for any arbitrary csharp build.  It 
 therefore makes a lot of sense to have a maven-csharp-master-parent to take 
 care of this.  These csharp related configurations are inappropriate for a 
 java build.  In my case the java code happens to be a maven plugin which is 
 executing the csharp code from a sister module (equivalent in example above 
 would be for a plugin in fooProject/java1 to be executing code from 
 fooProject/dotnet3.
 Although the motivating example above describes the issue in terms of java 
 and dotnet build interactions, its not at all unreasonable to think one might 
 have java code requiring lots of plugins (say cactus configuration, etc) 
 which would be inappropriate for sister modules.  Required differences in 
 plugin configuration should not impose any constraints on which modules are 
 considered to be released/packaged together.  Maven doesn't impose any such 
 constraint, but the release plugin is.
 Progress So Far:
 I havn't taken the time to dig around in the release plugin and figure out 
 how to fix this.  Currently, I am just manually performing what the release 
 plugin would normally do for me.

-- 
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: (MAVEN-1779) Un-deprecate maven.src.dir

[Arnaud Heritier (JIRA)]

[ http://jira.codehaus.org/browse/MAVEN-1779?page=comments#action_72605 ] 

Arnaud Heritier commented on MAVEN-1779:


But whats happen if sourceDirectory and maven.src.dir are defined together ???

 Un-deprecate maven.src.dir
 --

 Key: MAVEN-1779
 URL: http://jira.codehaus.org/browse/MAVEN-1779
 Project: Maven
  Issue Type: Wish
  Components: documentation
Affects Versions: 1.1-beta-3
Reporter: Lukas Theussl
 Assigned To: Lukas Theussl
 Fix For: 1.1-rc1


 The current properties reference [1] falsely states that maven.src.dir is not 
 used anymore, - it is still used in current ear, ejb, rar, war plugins (at 
 least). I'd also like to use it to resolve MPDIST-29, are there any 
 objections/remarks? We'd just have to update the documentation.
 [1] 
 http://maven.apache.org/maven-1.x/reference/properties.html#Build_Structure_Properties

-- 
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: (MAVEN-1779) Un-deprecate maven.src.dir

[Lukas Theussl (JIRA)]

[ http://jira.codehaus.org/browse/MAVEN-1779?page=comments#action_72606 ] 

Lukas Theussl commented on MAVEN-1779:
--

sourceDirectory only indicates the java sources, while maven.src.dir contains 
'everything', ie src, test,site, conf,...
Cleary, sourceDirectory should be a subdirectory of maven.src.dir, as long as 
that's the case, there should be no problem if they are defined together (they 
are already defined at the same time in the current maven version). 

 Un-deprecate maven.src.dir
 --

 Key: MAVEN-1779
 URL: http://jira.codehaus.org/browse/MAVEN-1779
 Project: Maven
  Issue Type: Wish
  Components: documentation
Affects Versions: 1.1-beta-3
Reporter: Lukas Theussl
 Assigned To: Lukas Theussl
 Fix For: 1.1-rc1


 The current properties reference [1] falsely states that maven.src.dir is not 
 used anymore, - it is still used in current ear, ejb, rar, war plugins (at 
 least). I'd also like to use it to resolve MPDIST-29, are there any 
 objections/remarks? We'd just have to update the documentation.
 [1] 
 http://maven.apache.org/maven-1.x/reference/properties.html#Build_Structure_Properties

-- 
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: (MAVEN-1410) pom.artifactId is missing from XML schema and pom.id should be removed

[Lukas Theussl (JIRA)]

[ http://jira.codehaus.org/browse/MAVEN-1410?page=comments#action_72608 ] 

Lukas Theussl commented on MAVEN-1410:
--

Actually, the id element is only mandatory in stand-alone poms, ie in 
pom-strict-3.xsd, which is part of the pom plugin, so I think this issue can be 
regarded as superceded by MPPOM-6. We only need to review the documentation.

 pom.artifactId is missing from XML schema and pom.id should be removed
 --

 Key: MAVEN-1410
 URL: http://jira.codehaus.org/browse/MAVEN-1410
 Project: Maven
  Issue Type: Bug
  Components: model
Affects Versions: 1.0
Reporter: Dennis Lundberg
 Assigned To: Lukas Theussl
 Fix For: 1.1-rc1

 Attachments: maven-project-3.xsd.patch, 
 maven-project.xsd-1_0-BRANCH.patch, xdocs-artifactId-version2.patch, 
 xdocs-artifactId.patch


 After some discussion on the dev-list pom.id versus pom.artifactId - which 
 is correct? there seems to be some inconsistencies in the 1.0 release.
 The discussion resulted in the following conclusions:
 1. The element project.id should be removed from the XML schema
 2. The element project.artifactId should be added to the XML schema
 3. Documentation needs to be updated to reflect the above issues
 1 and 2 should probably be done by one of the core developers, including 
 decisions regarding version numbers for the XML schema. I can make a patch 
 for it if you think that's ok.
 I can make patches for the xdocs to fix 3. On which branch should I create 
 the patches?

-- 
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-2512) Special Runtime Plugin Dependencies

[James Carpenter (JIRA)]

Special Runtime Plugin Dependencies
---

 Key: MNG-2512
 URL: http://jira.codehaus.org/browse/MNG-2512
 Project: Maven 2
  Issue Type: New Feature
  Components: Plugin Creation Tools, Plugins and Lifecycle
Reporter: James Carpenter


On ocassion a plugin may have dependencies upon non-java artifacts even though 
the plugin/Mojo is written in Java.  For example the maven-exec-plugin could be 
extended to support execution of dotnet executables.  It is assumed the dotnet 
executable (perhaps a code generator) will be executed by executing a system 
call.  The Mojo should somehow be able to make maven aware of the dotnet 
executable (and it's transitive dependencies).

This can be done today as long as the dotnet executable is a versioned 
dependency.  On the other hand if the dotnet executable is a snapshot version 
found in a sister module (released/packaged together) , the only way to avoid 
problems is to be very careful of the ordering in the modules configuration of 
the top level pom.  (Thats what I'm doing today).

Chat log from #maven IRC channel

[15:26] nawkboy: How far out is mvn 2.1?
[15:26] jdcasey: nawkboy: :-)
[15:26] jdcasey: ...get comfortable
[15:27] jdcasey: we're still putting together the list of subjects we want to 
tackle, from a much larger list of possibilities
[15:27] jdcasey: it's slow going, because many of us have less time to work on 
it than we'd like, unfortunately
[15:27] nawkboy: Are you going to allow a plugin to inject dependencies in some 
fashion?
[15:28] nawkboy: For example I have a mojo which runs a dotnet executable.
[15:28] nawkboy: My mojo has to first download the dotnet executable from the 
repo (using the artifact resolver).
[15:30] nawkboy: So although the mojo needs to execute a given artifact , the 
mojo code itself doesn't actually need the artifact to run.  Its just the 
system call my mojo is making that needs the artifact resolved.
[15:30] nawkboy: So in conclusion I have a Mojo which effectively has a 
dependency maven isn't aware of. 
[15:31] jdcasey: nawkboy: can you not use a plugin-level dependency in that 
case?
[15:31] jdcasey: should be injected straight into the plugin container's 
classpath
[15:31] jdcasey: is the app dependent on that artifact before or after the 
plugin runs?
[15:31] nawkboy: If my mojo could somehow register this extra dependency things 
would be improved.
[15:32] nawkboy: Well my plugin is java, but the executable I resolve and run 
is dotnet.  The java based Mojo won't like having a dotnet dependency.
[15:32] jdcasey: hmm
[15:32] jdcasey: and the executable is not tailored to that particular app, 
right?
[15:32] nawkboy: Another way to think about this is in terms of the 
maven-exec-plugin.
[15:33] jdcasey: it's not really a project dependency, though, is it?
[15:33] jdcasey: it's not used by any project code, right?
[15:33] jdcasey: hmm
[15:33] nawkboy: The fix I made http://jira.codehaus.org/browse/MEXEC-4  lets a 
csharp project use the maven-exec-plugin to start up a java based server.
[15:34] jdcasey: well, I think a better solution in that case would be to 
provide better tools for resolving these things, or an annotation saying I 
don't need this in my classpath, but get it anyway, and inject the path here
[15:34] nawkboy: But my fix only works nicely since the server I am starting is 
java based.  If the server I wanted the maven-exec-plugin to run was written in 
say perl, I would have a smilar to problem to that described above.
[15:34] nawkboy: bingo.  I think you got it.
[15:35] jdcasey: nawkboy: file a jira for that, if you would...in the MNG 
project
[15:35] jdcasey: so we can track it.
[15:35] jdcasey: that's a pretty new request, AFAIK
[15:36] jdcasey: there are some folks who want to inject a new project-level 
dep because they're instrumenting the source/classes...
[15:36] jdcasey: but IMO that's a wrong approach...but this is different
[15:36] nawkboy: Potentially, a Mojo (say the maven-exec-plugin trying to start 
a perl based process) might only know what these sort of dependencies where 
based on the plugin's configuration.
[15:37] nawkboy: where=were
[15:39] nawkboy: MNG?  Where is that?  I'm on the codehaus JIRA, but don't see 
a project of MNG.
[15:39] *** yuri has joined #maven.
[15:39] jdcasey: hmm...ok, but it would be nice to have some plumbing for that, 
so we can accommodate it in things like a go-offline mojo
[15:39] jdcasey: http://jira.codehaus.org/browse/MNG
[15:40] nawkboy: What component should I place it under?
[15:40] jdcasey: is there one for plugin tools?
[15:40] jdcasey: or plugin management?
[15:40] * jdcasey goes to look
[15:40] nawkboy: Plugin API, Plugin Creation Tools, Plugin Requests, Plugins 
and Lifecycle
[15:41] jdcasey: Plugins and Lifecycle and Plugin Creation Tools, I 
think...just use the CTL-click method :)
[15:41] jdcasey: should get you close 

[jira] Created: (MCLOVER-50) Test failure during Site goal should not stop the Clover build

[Andrew Perepelytsya (JIRA)]

Test failure during Site goal should not stop the Clover build
--

 Key: MCLOVER-50
 URL: http://jira.codehaus.org/browse/MCLOVER-50
 Project: Maven 2.x Clover Plugin
  Issue Type: Bug
Affects Versions: 2.2
Reporter: Andrew Perepelytsya
Priority: Critical


This problem is similar to whatever surefire-report plugin experienced up until 
recently. Clover plugin runs tests in its own lifecycle. If there was a test 
failure, the build should continue and site be generated with failure reports. 
At the moment the build is stopped with a failure completely, and site *not* 
generated.

-- 
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-800) Use maven-user project for user management

[Joakim Erdfelt (JIRA)]

 [ http://jira.codehaus.org/browse/CONTINUUM-800?page=all ]

Joakim Erdfelt updated CONTINUUM-800:
-

Attachment: maven-user-model-testing.patch

attached maven-user-model-testing.patch as a boilerplate for some 
maven-user-model testing.  however the following jpox/jdo error is confounding 
me.

org.jpox.metadata.InvalidMetaDataException: Error in MetaData for field group 
in class User : this is declared as org.apache.maven.user.model.UserGroup 
with persistence-modifier=none yet has either default-fetch-group=true or 
primary-key=true specified! These should be false.
at 
org.jpox.metadata.AbstractPropertyMetaData.populate(AbstractPropertyMetaData.java:801)
at 
org.jpox.metadata.ClassMetaData.populatePropertyMetaData(ClassMetaData.java:349)
at org.jpox.metadata.ClassMetaData.populate(ClassMetaData.java:219)
at 
org.jpox.metadata.MetaDataManager.populateClassesInterfacesInFile(MetaDataManager.java:1235)
at 
org.jpox.metadata.MetaDataManager.loadMetaDataForClass(MetaDataManager.java:1357)
at 
org.jpox.metadata.MetaDataManager.getMetaDataForClassOrInterface(MetaDataManager.java:510)
at 
org.jpox.metadata.MetaDataManager.getMetaDataForClassInternal(MetaDataManager.java:471)
at 
org.jpox.metadata.MetaDataManager.getMetaDataForClass(MetaDataManager.java:354)
at 
org.jpox.metadata.MetaDataManager.getMetaDataForClass(MetaDataManager.java:340)
at 
org.jpox.store.rdbms.RDBMSManager$ClassAdder.getReferencedClasses(RDBMSManager.java:2510)
at 
org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTables(RDBMSManager.java:2276)
at 
org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTablesAndValidate(RDBMSManager.java:2573)
at 
org.jpox.store.rdbms.RDBMSManager$ClassAdder.run(RDBMSManager.java:2213)
at 
org.jpox.store.rdbms.RDBMSManager$MgmtTransaction.execute(RDBMSManager.java:2069)
at org.jpox.store.rdbms.RDBMSManager.addClasses(RDBMSManager.java:564)
at org.jpox.SchemaTool.createSchemaTables(SchemaTool.java:189)
at 
org.apache.maven.user.model.impl.DefaultUserManagerTest.setUp(DefaultUserManagerTest.java:80)
at junit.framework.TestCase.runBare(TestCase.java:125)
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 junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at 
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
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)

 Use maven-user project for user management
 --

 Key: CONTINUUM-800
 URL: http://jira.codehaus.org/browse/CONTINUUM-800
 Project: Continuum
  Issue Type: Sub-task
Reporter: Carlos Sanchez
 Attachments: CONTINUUM-800-continuum-webapp.patch, 
 CONTINUUM-800-maven-user-webapp.patch, CONTINUUM-800-maven-user.patch, 
 maven-user-model-testing.patch


 Added a first version of user management in 
 https://svn.apache.org/repos/asf/maven/shared/trunk/maven-user
 We have to move user code from Continuum there and use it instead

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

[jira] Commented: (MRELEASE-151) All child modules are forced to share the same parent POM

[James Carpenter (JIRA)]

[ http://jira.codehaus.org/browse/MRELEASE-151?page=comments#action_72613 ] 

James Carpenter commented on MRELEASE-151:
--

Relevant discussion on #maven IRC channel:

[15:15] nawkboy: The core issue being that whenever maven tries to satisfy the 
@requiresDependencyResolution it isn't smart enough to look in modules which 
don't share the same parent pom.
[15:16] nawkboy: (It wouldn't surprise me that when building on the command 
line I get around the problem at first by running mvn -o install.  Then the 
second time I have the snapshot. :) )
[15:16] jdcasey: nawkboy: actually, I don't think that's it
[15:17] jdcasey: I think this is something that the assembly plugin has trouble 
with, too...
[15:17] nawkboy: I know this seems to happen before I hit the execute method of 
the PrepareReleaseMojo.
[15:17] nawkboy: (I ran the plugin in my debugger, and never got to the evil 
line.)
[15:17] jdcasey: not sure, but I'm thinking that since it's subbing in the 
projects for artifacts it would normally resolve externally, these project 
artifacts aren't resolved (or resolvable, since it didn't run to package phase)
[15:18] jdcasey: hang on
[15:18] jdcasey: yup, you're going to have to run at least:
[15:18] jdcasey: mvn package release:prepare
[15:19] jdcasey: ideally, the prepare-release mojo would spawn a forked 
execution to run to the package phase, to ensure that project-artifacts are 
resolvable before continuing
[15:19] jdcasey: it's an aggregator mojo, which is why this is a problem...at 
least partially
[15:20] jdcasey: nawkboy: let me guess...you got stuck somewhere just inside 
executeMojo(..) in the plugin manager?
[15:20] nawkboy: Can you explain in slightly more detail?  I'm only half way 
understanding the explaination, because I don't completely understand all of 
the core maven details.  I have written and/or modified several plugins but 
havn't gotten that deep into maven so far.
[15:20] jdcasey: ok, so here's the deal...get comfortable ;)
[15:20] nawkboy: I think I will.  Can quickly give you the line I stick on if 
needed. (will take about 3min)
[15:20] jdcasey: when maven starts up, it will resolve inter-project 
dependencies that exist among modules
[15:21] jdcasey: you'll have to run the build at least to the package phase 
just before the prepare mojo is called
[15:21] jdcasey: so...
[15:22] jdcasey: it places a project reference in the MavenProject instances to 
account for these interdependencies, in the form of an active artifact.
[15:22] jdcasey: that artifact is resolved when the project produces a jar, 
or whatever artifact is produced by the package phase
[15:23] jdcasey: when a mojo requires dependency resolution, these active 
artifacts are a part of that resolution process...if their corresponding 
projects haven't produced a binary yet, they aren't resolved within the build, 
and maven looks for them externally (in the repo)
[15:23] *** tom has joined #maven.
[15:23] jdcasey: since the prepare mojo doesn't require execution to the 
package phase, the project interdependencies aren't resolved to artifacts, and 
maven tries to look on the repo for them
[15:24] jdcasey: it's part of a sticky problem we're going to try to resolve 
for 2.1
[15:24] jdcasey: actually, come to think of it, this isn't unique to aggregator 
mojos
[15:24] jdcasey: it's more a side-effect of running a mojo outside of the 
normal build lifecycle
[15:25] nawkboy: So whats the bug fix to the mojo?  can I place a 
quasi-annotation on the mojo to make it first build to the package phase?
[15:26] nawkboy: Do I need to internally use the artifactResolver in some 
explict manner (I had to do this for one of the plugins I wrote)
[15:26] jdcasey: you can use @exec phase=package but you're likely to make 
some people mad if you were to commit it ;)
[15:26] nawkboy: lol
[15:26] jdcasey: put that in the class-level javadoc

 All child modules are forced to share the same parent POM
 -

 Key: MRELEASE-151
 URL: http://jira.codehaus.org/browse/MRELEASE-151
 Project: Maven 2.x Release Plugin
  Issue Type: Bug
Affects Versions: 2.0-beta-4
 Environment: Windows XP
Reporter: James Carpenter
Priority: Blocker

 Problem Description:
 Assume the following layout:
 fooProject/pom.xml
 fooProject/dotnet1/pom.xml (has parent pom of maven-csharp-master-parent)
 fooProject/dotnet2/pom.xml (has parent pom of maven-csharp-master-parent)
 fooProject/dotnet3/pom.xml (has parent pom of maven-csharp-master-parent)
 fooProject/java1/pom.xml (has parent pom found above it ../pom.xml)
 fooProject/java2/pom.xml (has parent pom found above it ../pom.xml)
 fooProject/java3/pom.xml (has parent pom of 
 maven-fancy-framework-master-parent)
 Assume fooProject/pom.xml lists dotnet1, dotnet2, dotnet3, java1, and java2 
 in the modules section.  

[jira] Closed: (MPPOM-6) Id in POM is deprecated.

[Lukas Theussl (JIRA)]

 [ http://jira.codehaus.org/browse/MPPOM-6?page=all ]

Lukas Theussl closed MPPOM-6.
-

  Assignee: Lukas Theussl
Resolution: Fixed

I only fixed pom-strict-3.xsd, the id element is already not required in child 
poms (http://maven.apache.org/xsd/maven-v3_0_0.xsd). Please review.

 Id in POM is deprecated.
 

 Key: MPPOM-6
 URL: http://jira.codehaus.org/browse/MPPOM-6
 Project: maven-pom-plugin
  Issue Type: Bug
Affects Versions: 1.5
Reporter: Arnaud Heritier
 Assigned To: Lukas Theussl
Priority: Critical
 Fix For: 1.5.1


 The pom:validate goal uses a schema which is false. The id element is 
 deprecated and replaced by groupId/artifactId.

-- 
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: (MPGENAPP-27) Generated poms contain deprecated id elements

[Lukas Theussl (JIRA)]

 [ http://jira.codehaus.org/browse/MPGENAPP-27?page=all ]

Lukas Theussl closed MPGENAPP-27.
-

Resolution: Fixed

 Generated poms contain deprecated id elements
 -

 Key: MPGENAPP-27
 URL: http://jira.codehaus.org/browse/MPGENAPP-27
 Project: maven-genapp-plugin
  Issue Type: Bug
Reporter: Lukas Theussl
 Assigned To: Lukas Theussl
 Fix For: 2.3.1


 Replace by artifactId

-- 
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] Reopened: (MASSEMBLY-99) dependencySets in a descriptor doesn't work anymore

[Edwin Punzalan (JIRA)]

 [ http://jira.codehaus.org/browse/MASSEMBLY-99?page=all ]

Edwin Punzalan reopened MASSEMBLY-99:
-

 
I used the attached test case and it does prove the bug.

 dependencySets in a descriptor doesn't work anymore
 ---

 Key: MASSEMBLY-99
 URL: http://jira.codehaus.org/browse/MASSEMBLY-99
 Project: Maven 2.x Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.1
 Environment: all
Reporter: Olivier Lamy
 Assigned To: John Casey
Priority: Blocker
 Fix For: 2.2

 Attachments: assembly-spike-1.0.zip, descriptor.xml


 I attached my descriptor file.
   dependencySets
 dependencySet
   outputDirectorylib/outputDirectory
   unpackfalse/unpack
   scoperuntime/scope
   !--
 how to exclude dependencies
   excludes
   excludejunit:junit/exclude
   /excludes 
   --
 /dependencySet
   /dependencySets
 unzip -l on the assembly file show empty lib directory.
 Olivier

-- 
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-800) Use maven-user project for user management

[Carlos Sanchez (JIRA)]

[ http://jira.codehaus.org/browse/CONTINUUM-800?page=comments#action_72620 
] 

Carlos Sanchez commented on CONTINUUM-800:
--

what I see in the branch is 

16:09:00,140 ERROR JPOX.RDBMS.SCHEMA[org.jpox.store.rdbms.RDBMSManager] 
Failed initialising database. Exception : The class 
org.apache.maven.continuum.model.system.ContinuumUser is required to be 
Persistence-Capable yet no Meta-Data can be found for this class. Please check 
that the Meta-Data is defined in a valid file location for JDO.
org.jpox.exceptions.MetaDataForPersistenceCapableClassNotReachableException: 
The class org.apache.maven.continuum.model.system.ContinuumUser is required 
to be Persistence-Capable yet no Meta-Data can be found for this class. Please 
check that the Meta-Data is defined in a valid file location for JDO.
at 
org.jpox.store.rdbms.RDBMSManager$ClassAdder.getReferencedClasses(RDBMSManager.java:2514)
at 
org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTables(RDBMSManager.java:2276)
at 
org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTablesAndValidate(RDBMSManager.java:2573)
at 
org.jpox.store.rdbms.RDBMSManager$ClassAdder.run(RDBMSManager.java:2213)
at 
org.jpox.store.rdbms.RDBMSManager$MgmtTransaction.execute(RDBMSManager.java:2069)
at org.jpox.store.rdbms.RDBMSManager.addClasses(RDBMSManager.java:564)
at 
org.jpox.store.StoreManager.initialiseAutoStart(StoreManager.java:407)
at 
org.jpox.store.rdbms.RDBMSManager.initialiseSchema(RDBMSManager.java:483)
at org.jpox.store.rdbms.RDBMSManager.init(RDBMSManager.java:242)
at 
org.jpox.store.rdbms.RDBMSManagerFactory.getStoreManager(RDBMSManagerFactory.java:59)
at 
org.jpox.AbstractPersistenceManager.init(AbstractPersistenceManager.java:222)
at 
org.jpox.PersistenceManagerImpl.init(PersistenceManagerImpl.java:34)
at 
org.jpox.PersistenceManagerFactoryImpl.getPersistenceManager(PersistenceManagerFactoryImpl.java:916)
at 
org.jpox.PersistenceManagerFactoryImpl.getPersistenceManager(PersistenceManagerFactoryImpl.java:891)
at 
org.apache.maven.continuum.store.JdoContinuumStore.getPersistenceManager(JdoContinuumStore.java:1295)
at 
org.apache.maven.continuum.store.JdoContinuumStore.updateObject(JdoContinuumStore.java:598)
at 
org.apache.maven.continuum.store.JdoContinuumStore.updateSystemConfiguration(JdoContinuumStore.java:1045)
at 
org.apache.maven.continuum.configuration.DefaultConfigurationService.store_aroundBody50(DefaultConfigurationService.java:266)
at 
org.apache.maven.continuum.configuration.DefaultConfigurationService.store(DefaultConfigurationService.java:1)
at 
org.apache.maven.continuum.DefaultContinuum.stopContinuum_aroundBody156(DefaultContinuum.java:2064)
at 
org.apache.maven.continuum.DefaultContinuum$AjcClosure157.run(DefaultContinuum.java:1)
at 
org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0cproceed(SecurityAspect.aj)
at 
org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0c(SecurityAspect.aj:66)
at 
org.apache.maven.continuum.DefaultContinuum.stopContinuum(DefaultContinuum.java:1)
at 
org.apache.maven.continuum.DefaultContinuum$1.run(DefaultContinuum.java:163)

Exception in thread Thread-2 
org.jpox.exceptions.MetaDataForPersistenceCapableClassNotReachableException: 
The class org.apache.maven.continuum.model.system.ContinuumUser is required 
to be Persistence-Capable yet no Meta-Data can be found for this class. Please 
check that the Meta-Data is defined in a valid file location for JDO.
at 
org.jpox.store.rdbms.RDBMSManager$ClassAdder.getReferencedClasses(RDBMSManager.java:2514)
at 
org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTables(RDBMSManager.java:2276)
at 
org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTablesAndValidate(RDBMSManager.java:2573)
at 
org.jpox.store.rdbms.RDBMSManager$ClassAdder.run(RDBMSManager.java:2213)
at 
org.jpox.store.rdbms.RDBMSManager$MgmtTransaction.execute(RDBMSManager.java:2069)
at org.jpox.store.rdbms.RDBMSManager.addClasses(RDBMSManager.java:564)
at 
org.jpox.store.StoreManager.initialiseAutoStart(StoreManager.java:407)
at 
org.jpox.store.rdbms.RDBMSManager.initialiseSchema(RDBMSManager.java:483)
at org.jpox.store.rdbms.RDBMSManager.init(RDBMSManager.java:242)
at 
org.jpox.store.rdbms.RDBMSManagerFactory.getStoreManager(RDBMSManagerFactory.java:59)
at 
org.jpox.AbstractPersistenceManager.init(AbstractPersistenceManager.java:222)
at 
org.jpox.PersistenceManagerImpl.init(PersistenceManagerImpl.java:34)
at 

[jira] Closed: (MPGENAPP-26) Problem with maven.genapp.repackage.dir and maven.genapp.repackage

[Lukas Theussl (JIRA)]

 [ http://jira.codehaus.org/browse/MPGENAPP-26?page=all ]

Lukas Theussl closed MPGENAPP-26.
-

Resolution: Fixed

I fixed the issue but I couldn't apply your patch: it's not in unified diff 
format, the ant:exclude part broke some other standard templates, and I 
couldn't figure out what the rest of the patch is supposed to do. Please open a 
new issue with a more detailed description.

 Problem with maven.genapp.repackage.dir and maven.genapp.repackage
 --

 Key: MPGENAPP-26
 URL: http://jira.codehaus.org/browse/MPGENAPP-26
 Project: maven-genapp-plugin
  Issue Type: Bug
Affects Versions: 2.3
 Environment: Test on windows
Reporter: Charles Rathouis
 Assigned To: Lukas Theussl
 Fix For: 2.3.1

 Attachments: jelly.diff, saint-gobain.zip


 When you use the maven.genapp.repackage.dir properties and set it to . , the 
 files contained in the maven.genapp.repackage directory are not  moved  to 
 the new package directory, but copied in it, and steel in the base directory.
 Here is the template.properties file :
 maven.genapp.repackage.dir=
 maven.genapp.repackage=main/src/java,test/src/unit
 maven.genapp.filter=project.xml
 maven.genapp.default.package=com.saint-gobain.sgsi.my_application
 maven.genapp.filter=project.xml,main/src/webapp/WEB-INF/web.xml
 The content of main/src/java are not moved in 
 main/src/java/com/saint-gobain/sgsi/my_application but copyed in it and 
 steel in the main/src/java directory.
 If I put the main and test directory in a src directory, and remove the 
 maven.genapp.repackage.dir propertie, everything works fine.
 You can find in attachment the template

-- 
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-822) Create acegi acl tables on database creation

[Carlos Sanchez (JIRA)]

Create acegi acl tables on database creation


 Key: CONTINUUM-822
 URL: http://jira.codehaus.org/browse/CONTINUUM-822
 Project: Continuum
  Issue Type: Sub-task
Reporter: Carlos Sanchez




-- 
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-822) Create acegi acl tables on database creation

[Carlos Sanchez (JIRA)]

 [ http://jira.codehaus.org/browse/CONTINUUM-822?page=all ]

Carlos Sanchez updated CONTINUUM-822:
-

  Description: 
The SQL script is in continuum-security-acegi
src/main/resources 
org.apache.maven.continuum.security.acegi.acl.acegi-acl-derby.sql

This needs to be run against the db when the database is created. I think 
there's a sql plugin for maven somewhere.
Fix Version/s: 1.1
  Component/s: Web interface

 Create acegi acl tables on database creation
 

 Key: CONTINUUM-822
 URL: http://jira.codehaus.org/browse/CONTINUUM-822
 Project: Continuum
  Issue Type: Sub-task
  Components: Web interface
Reporter: Carlos Sanchez
 Fix For: 1.1


 The SQL script is in continuum-security-acegi
 src/main/resources 
 org.apache.maven.continuum.security.acegi.acl.acegi-acl-derby.sql
 This needs to be run against the db when the database is created. I think 
 there's a sql plugin for maven somewhere.

-- 
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-1060) jstl-1.2.jar corrupt

[JIRA]

jstl-1.2.jar corrupt


 Key: MAVENUPLOAD-1060
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1060
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Jörg Prante


Please check  the jstl-1.2.jar file in the directory

http://www.ibiblio.org/maven2/javax/servlet/jsp/jstl/jstl/1.2/

as of 17-Jul-2006

The jar file is corrupt, it contains a classes directory, so it can't be used 
in a classpath.

The correct package is available at

https://maven-repository.dev.java.net/nonav/repository/jstl/

as of 21-Jul-2006

Just out of curiosity, why is the groupId now javax.servlet.jsp.jstl and no 
longer jstl ?

Best regards,

Jörg


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

[jira] Commented: (MAVENUPLOAD-1060) jstl-1.2.jar corrupt

[Carlos Sanchez (JIRA)]

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1060?page=comments#action_72623 ] 

Carlos Sanchez commented on MAVENUPLOAD-1060:
-

Removed that folder, java.net repo incorrectly put it there.

 jstl-1.2.jar corrupt
 

 Key: MAVENUPLOAD-1060
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1060
 Project: maven-upload-requests
  Issue Type: Task
Reporter: Jörg Prante

 Please check  the jstl-1.2.jar file in the directory
 http://www.ibiblio.org/maven2/javax/servlet/jsp/jstl/jstl/1.2/
 as of 17-Jul-2006
 The jar file is corrupt, it contains a classes directory, so it can't be used 
 in a classpath.
 The correct package is available at
 https://maven-repository.dev.java.net/nonav/repository/jstl/
 as of 21-Jul-2006
 Just out of curiosity, why is the groupId now javax.servlet.jsp.jstl and no 
 longer jstl ?
 Best regards,
 Jörg

-- 
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: (MEV-434) Upload POM for org.apache.bcel:bcel:5.2 to ibiblio

[Matt Whitlock (JIRA)]

Upload POM for org.apache.bcel:bcel:5.2 to ibiblio
--

 Key: MEV-434
 URL: http://jira.codehaus.org/browse/MEV-434
 Project: Maven Evangelism
  Issue Type: Task
  Components: Missing POM
Reporter: Matt Whitlock


Artifact org.apache.bcel:bcel:5.2 in ibiblio repository is missing POM.

It might also be worth mentioning that bcel has historically lived at 
bcel:bcel, so moving it to org.apache.bcel:bcel is a departure from that 
precedent.

-- 
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-2511) Need ability to redefine distribution management url

[Brian Fox (JIRA)]

[ http://jira.codehaus.org/browse/MNG-2511?page=comments#action_72625 ] 

Brian Fox commented on MNG-2511:


That's correct, I really need to do both. It would certainly simplify the case 
where you need to build a plugin or something from svn and install in your own 
environment. The property thing could work also, but it seems logical to add it 
to the server section. It actually would be nice to merge with the mirror 
functionality. Currently you can't define a mirror that needs login info either 
because it seems to ignore the server section for something defined as a mirror.

 Need ability to redefine distribution management url
 

 Key: MNG-2511
 URL: http://jira.codehaus.org/browse/MNG-2511
 Project: Maven 2
  Issue Type: Improvement
  Components: Settings
Affects Versions: 2.0.4
Reporter: Brian Fox

 Currently the only way to specify a url for distributionManagement is in the 
 pom. We need to be able to override that so that if needed a developer can 
 set a server id in their settings and define a new url. For example, some 
 developers are outside the company's infrastructure and they deploy 
 differently than developers internally. 

-- 
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-2513) ArtifactResolver.resolveTransitively() is not working

[Jason Dillon (JIRA)]

ArtifactResolver.resolveTransitively() is not working
-

 Key: MNG-2513
 URL: http://jira.codehaus.org/browse/MNG-2513
 Project: Maven 2
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 2.0.4
Reporter: Jason Dillon


I've got a plugin which is basically doing the same thing that the dependency 
plugin is, defining artifactItem elements in a configuration, which provide he 
details for a maven artifact.  The version details are filled in just like the 
dependency plugin.

Problem is that I need to take each of those artifactItems and get the 
transitive dependencies for them... but so far all of my attempts to do so with 
ArtifactResolver.resolveTransitively() is not working.

Should be easy enough to test, just create a new artifact that you know has 
deps with a ArtifactFactory, then try to get the transitive dependencies.

Everytime I try I get an empty set from result.getArtifacts().

-- 
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-819) project.getWorkingDirectory is null

[Edwin Punzalan (JIRA)]

[ http://jira.codehaus.org/browse/CONTINUUM-819?page=comments#action_72628 
] 

Edwin Punzalan commented on CONTINUUM-819:
--

I found that existing projects added to continuum prior to this patch will 
still return null for their working directory probably because the project was 
persisted with the null and is not computed anymore afterwards.

 project.getWorkingDirectory is null
 ---

 Key: CONTINUUM-819
 URL: http://jira.codehaus.org/browse/CONTINUUM-819
 Project: Continuum
  Issue Type: Bug
  Components: Core system
Affects Versions: 1.1
Reporter: Edwin Punzalan
 Assigned To: Edwin Punzalan
 Attachments: CONTINUUM-819-continuum-core.patch


 inside an action class' execute method, 
 continuum.getProject().getWorkingDirectory returns null

-- 
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-309) add junit results report to website, failures to email

[Edwin Punzalan (JIRA)]

 [ http://jira.codehaus.org/browse/CONTINUUM-309?page=all ]

Edwin Punzalan updated CONTINUUM-309:
-

Attachment: CONTINUUM-309-continuum-webapp.patch
CONTINUUM-309-sample.GIF

Attached a patch with sample output page.  The page is generated by reading the 
xml files generated by surefire and requires the patch for CONTINUUM-819 to 
work.

 add junit results report to website, failures to email
 --

 Key: CONTINUUM-309
 URL: http://jira.codehaus.org/browse/CONTINUUM-309
 Project: Continuum
  Issue Type: New Feature
Reporter: Brett Porter
 Assigned To: Edwin Punzalan
 Fix For: 1.1

 Attachments: CONTINUUM-309-continuum-webapp.patch, 
 CONTINUUM-309-sample.GIF, continuum-api.diff, continuum-core.diff, 
 continuum-model.diff, continuum-web.diff




-- 
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-823) Continuum hangs when trying to build Continuum

[Lester Ecarma (JIRA)]

Continuum hangs when trying to build Continuum
--

 Key: CONTINUUM-823
 URL: http://jira.codehaus.org/browse/CONTINUUM-823
 Project: Continuum
  Issue Type: Bug
 Environment: Linux (Ubuntu 6.06)
Reporter: Lester Ecarma


When adding Continuum 
(http://svn.apache.org/repos/asf/maven/continuum/trunk/pom.xml) as a project in 
Continuum, it stops at a certain point when the build is executed (webapp seems 
to hang). 

The project and all nested modules are added successfully, with all files 
downloaded. The error happens during execution of the build. 

The running continuum server is built from trunk and started with 'mvn 
jetty:run'. The error does not occur with Continnum 1.0.3.

-- 
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-823) Continuum hangs when trying to build Continuum

[Lester Ecarma (JIRA)]

 [ http://jira.codehaus.org/browse/CONTINUUM-823?page=all ]

Lester Ecarma updated CONTINUUM-823:


Affects Version/s: 1.1
Fix Version/s: 1.1

 Continuum hangs when trying to build Continuum
 --

 Key: CONTINUUM-823
 URL: http://jira.codehaus.org/browse/CONTINUUM-823
 Project: Continuum
  Issue Type: Bug
Affects Versions: 1.1
 Environment: Linux (Ubuntu 6.06)
Reporter: Lester Ecarma
 Fix For: 1.1


 When adding Continuum 
 (http://svn.apache.org/repos/asf/maven/continuum/trunk/pom.xml) as a project 
 in Continuum, it stops at a certain point when the build is executed (webapp 
 seems to hang). 
 The project and all nested modules are added successfully, with all files 
 downloaded. The error happens during execution of the build. 
 The running continuum server is built from trunk and started with 'mvn 
 jetty:run'. The error does not occur with Continnum 1.0.3.

-- 
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-309) add junit results report to website, failures to email

[Edwin Punzalan (JIRA)]

[ http://jira.codehaus.org/browse/CONTINUUM-309?page=comments#action_72632 
] 

Edwin Punzalan commented on CONTINUUM-309:
--

Hi, I think the css need some updating so that the h5 tags will get to look 
better.

 add junit results report to website, failures to email
 --

 Key: CONTINUUM-309
 URL: http://jira.codehaus.org/browse/CONTINUUM-309
 Project: Continuum
  Issue Type: New Feature
Reporter: Brett Porter
 Assigned To: Edwin Punzalan
 Fix For: 1.1

 Attachments: CONTINUUM-309-continuum-webapp.patch, 
 CONTINUUM-309-sample.GIF, continuum-api.diff, continuum-core.diff, 
 continuum-model.diff, continuum-web.diff




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

[jira] Updated: (MNG-2473) Improve Site Structuring

[Marvin King (JIRA)]

 [ http://jira.codehaus.org/browse/MNG-2473?page=all ]

Marvin King updated MNG-2473:
-

Attachment: index-improve-content-visibility.html


 - improve content visibility

 Improve Site Structuring
 

 Key: MNG-2473
 URL: http://jira.codehaus.org/browse/MNG-2473
 Project: Maven 2
  Issue Type: Task
  Components: Documentation:  General
Reporter: Marvin King
 Assigned To: Marvin King
 Attachments: index-improve-content-visibility.html

  Time Spent: 6 hours
  Remaining Estimate: 0 minutes

 *  http://mail-archives.apache.org/mod_mbox/maven-dev/200602.mbox/[EMAIL 
 PROTECTED]
 * http://mail-archives.apache.org/mod_mbox/maven-dev/200602.mbox/[EMAIL 
 PROTECTED]
 * see also Better Builds with Maven section on separating developer and 
 user content

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

[jira] Updated: (MNG-2473) Improve Site Structuring

[Marvin King (JIRA)]

 [ http://jira.codehaus.org/browse/MNG-2473?page=all ]

Marvin King updated MNG-2473:
-

Attachment: index-draft-plugin-subsite.html


 - draft plugin subsite

 Improve Site Structuring
 

 Key: MNG-2473
 URL: http://jira.codehaus.org/browse/MNG-2473
 Project: Maven 2
  Issue Type: Task
  Components: Documentation:  General
Reporter: Marvin King
 Assigned To: Marvin King
 Attachments: index-draft-plugin-subsite.html, 
 index-improve-content-visibility.html

  Time Spent: 6 hours
  Remaining Estimate: 0 minutes

 *  http://mail-archives.apache.org/mod_mbox/maven-dev/200602.mbox/[EMAIL 
 PROTECTED]
 * http://mail-archives.apache.org/mod_mbox/maven-dev/200602.mbox/[EMAIL 
 PROTECTED]
 * see also Better Builds with Maven section on separating developer and 
 user content

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

[jira] Updated: (MNG-2473) Improve Site Structuring

[Marvin King (JIRA)]

 [ http://jira.codehaus.org/browse/MNG-2473?page=all ]

Marvin King updated MNG-2473:
-

Attachment: (was: index-draft-plugin-subsite.html)

 Improve Site Structuring
 

 Key: MNG-2473
 URL: http://jira.codehaus.org/browse/MNG-2473
 Project: Maven 2
  Issue Type: Task
  Components: Documentation:  General
Reporter: Marvin King
 Assigned To: Marvin King
 Attachments: index-draft-plugin-subsite.html, 
 index-improve-content-visibility.html

  Time Spent: 6 hours
  Remaining Estimate: 0 minutes

 *  http://mail-archives.apache.org/mod_mbox/maven-dev/200602.mbox/[EMAIL 
 PROTECTED]
 * http://mail-archives.apache.org/mod_mbox/maven-dev/200602.mbox/[EMAIL 
 PROTECTED]
 * see also Better Builds with Maven section on separating developer and 
 user content

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

[jira] Updated: (MNG-2473) Improve Site Structuring

[Marvin King (JIRA)]

 [ http://jira.codehaus.org/browse/MNG-2473?page=all ]

Marvin King updated MNG-2473:
-

Attachment: index-draft-plugin-subsite.html

 Improve Site Structuring
 

 Key: MNG-2473
 URL: http://jira.codehaus.org/browse/MNG-2473
 Project: Maven 2
  Issue Type: Task
  Components: Documentation:  General
Reporter: Marvin King
 Assigned To: Marvin King
 Attachments: index-draft-plugin-subsite.html, 
 index-improve-content-visibility.html

  Time Spent: 6 hours
  Remaining Estimate: 0 minutes

 *  http://mail-archives.apache.org/mod_mbox/maven-dev/200602.mbox/[EMAIL 
 PROTECTED]
 * http://mail-archives.apache.org/mod_mbox/maven-dev/200602.mbox/[EMAIL 
 PROTECTED]
 * see also Better Builds with Maven section on separating developer and 
 user content

-- 
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-2514) improve physical layout of the web site

[Brett Porter (JIRA)]

improve physical layout of the web site
---

 Key: MNG-2514
 URL: http://jira.codehaus.org/browse/MNG-2514
 Project: Maven 2
  Issue Type: Task
  Components: Documentation:  General
Reporter: Brett Porter


*  http://mail-archives.apache.org/mod_mbox/maven-dev/200602.mbox/[EMAIL 
PROTECTED]
* http://mail-archives.apache.org/mod_mbox/maven-dev/200602.mbox/[EMAIL 
PROTECTED]
* see also Better Builds with Maven section on separating developer and 
user content


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

[jira] Updated: (MNG-2473) Improve Site Structuring

[Brett Porter (JIRA)]

 [ http://jira.codehaus.org/browse/MNG-2473?page=all ]

Brett Porter updated MNG-2473:
--

Description: 

See my proposal here:
http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/[EMAIL PROTECTED]

See also:
http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/[EMAIL 
PROTECTED]
http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/[EMAIL 
PROTECTED]

Key to this is particularly changing the content of the front page, as well as 
the navigation.

  was:
*  http://mail-archives.apache.org/mod_mbox/maven-dev/200602.mbox/[EMAIL 
PROTECTED]
* http://mail-archives.apache.org/mod_mbox/maven-dev/200602.mbox/[EMAIL 
PROTECTED]
* see also Better Builds with Maven section on separating developer and 
user content



 Improve Site Structuring
 

 Key: MNG-2473
 URL: http://jira.codehaus.org/browse/MNG-2473
 Project: Maven 2
  Issue Type: Task
  Components: Documentation:  General
Reporter: Marvin King
 Assigned To: Marvin King
 Attachments: index-draft-plugin-subsite.html, 
 index-improve-content-visibility.html

  Time Spent: 6 hours
  Remaining Estimate: 0 minutes

 See my proposal here:
 http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/[EMAIL 
 PROTECTED]
 See also:
 http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/[EMAIL 
 PROTECTED]
 http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/[EMAIL 
 PROTECTED]
 Key to this is particularly changing the content of the front page, as well 
 as the navigation.

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