[jira] Updated: (CONTINUUM-1105) Duplicate email notifications with notifier in pom.xml
[ http://jira.codehaus.org/browse/CONTINUUM-1105?page=all ] Maria Odea Ching updated CONTINUUM-1105: Attachment: CONTINUUM-1105-continuum-core.patch The current situation is: When the project (with modules) are added in continuum, the notifiers from the pom are added in the project group notifier list. And when a new build is started, the same notifiers are also added to the project level. So after the build finishes, continuum sends notifications to the notifications list both in the project group level and project level, thereby duplicating the notifications. This also poses a problem when the notifier in the parent pom is modified. There is no way to know whether the notifier in the group is the old pom notifier or a user notifier becayse there is no reference to the pom that added it. The solution was not to add the notifiers (from the pom) in the project group level unless they are notifiers specifically created by the user in continuum. I removed the part where the pom notifiers are added in the project group in MavenTwoContinuumProjectBuilder. I also updated the following test cases: DefaultContinuumTest and MavenTwoProjectBuilderTest. > Duplicate email notifications with notifier in pom.xml > -- > > Key: CONTINUUM-1105 > URL: http://jira.codehaus.org/browse/CONTINUUM-1105 > Project: Continuum > Issue Type: Bug > Components: Notifier - Mail >Affects Versions: 1.1 >Reporter: Wendy Smoak > Assigned To: Maria Odea Ching > Attachments: CONTINUUM-1105-continuum-core.patch > > > When there is a notifier in the pom, and a group of projects (such as > maven/plugins/trunk/pom.xml) is added under the groupId in the pom, every > notification email is duplicated. > In the UI for each project, the notifier correctly shows "From Project". It > doesn't look like two notifiers have been added. > 20070102 IRC conversation about adding maven/plugins/trunk/pom.xml under > various groupIds: > what could make continuum send duplicate emails? > I've added and deleted all of maven/plugins/trunk/pom.xml a few > times under different project groups. > When I add it under the pom default org.apache.maven.plugins group, > I get duplicate emails for every build. > wsmoak, have you verified that there are not duplicate entries for > emails in the build defs? > I used to get duplicates when I belonged to an distribution-list and > a direct email address. > joakim: there is only the default build definition, and admin is > the only member of the group > wsmoak: I think we look at project group notifiers too when we > look at project notifier, so we get the project group notifier twice when we > send the mail > it only happens when I add the projects under the pom default group > id. If I delete and re-add it to some other group, I only get one email. > yes, because, when you use the default project group, project > notifiers are moved to the project group but I think they aren't removed in > the project > okay. and it's only happening with maven/plugins because struts, > etc. doesn't have notifiers in the pom. > From the log file (email addresses changed...): > INFO | jvm 1| 2007/01/02 20:16:39 | 2007-01-02 20:16:39,831 > [pool-1-thread-1] INFO ShellCommandHelper:default - Executing: mvn > --batch-mode --non-recursive clean install > INFO | jvm 1| 2007/01/02 20:16:39 | 2007-01-02 20:16:39,831 > [pool-1-thread-1] INFO ShellCommandHelper:default - Working directory: > /opt/continuum-1.1-r490629-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/7 > INFO | jvm 1| 2007/01/02 20:16:41 | 2007-01-02 20:16:41,660 > [pool-1-thread-1] INFO ContinuumBuildExecutor:maven2 - Exit code: 1 > INFO | jvm 1| 2007/01/02 20:16:41 | 2007-01-02 20:16:41,944 > [pool-1-thread-1] INFO BuildController:default- Performing action > deploy-artifact > INFO | jvm 1| 2007/01/02 20:16:42 | 2007-01-02 20:16:42,072 > [pool-1-thread-1] INFO Notifier:mail - Sending message: > From '"[EMAIL PROTECTED]" <[EMAIL PROTECTED]>'. > INFO | jvm 1| 2007/01/02 20:16:42 | 2007-01-02 20:16:42,072 > [pool-1-thread-1] INFO Notifier:mail - Recipient: To > '<[EMAIL PROTECTED]>'. > INFO | jvm 1| 2007/01/02 20:16:42 | 2007-01-02 20:16:42,337 > [pool-1-thread-1] INFO Notifier:mail - Sending message: > From '"[EMAIL PROTECTED]" <[EMAIL PROTECTED]>'. > INFO | jvm 1| 2007/01/02 20:16:42 | 2007-01-02 20:16:42,337 > [pool-1-thread-1] INFO Notifier:mail - Recipient: To > '<[EMAIL PROTECTED]>'. -- 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
[jira] Work stopped: (CONTINUUM-1105) Duplicate email notifications with notifier in pom.xml
[ http://jira.codehaus.org/browse/CONTINUUM-1105?page=all ] Work on CONTINUUM-1105 stopped by Maria Odea Ching. > Duplicate email notifications with notifier in pom.xml > -- > > Key: CONTINUUM-1105 > URL: http://jira.codehaus.org/browse/CONTINUUM-1105 > Project: Continuum > Issue Type: Bug > Components: Notifier - Mail >Affects Versions: 1.1 >Reporter: Wendy Smoak > Assigned To: Maria Odea Ching > Attachments: CONTINUUM-1105-continuum-core.patch > > > When there is a notifier in the pom, and a group of projects (such as > maven/plugins/trunk/pom.xml) is added under the groupId in the pom, every > notification email is duplicated. > In the UI for each project, the notifier correctly shows "From Project". It > doesn't look like two notifiers have been added. > 20070102 IRC conversation about adding maven/plugins/trunk/pom.xml under > various groupIds: > what could make continuum send duplicate emails? > I've added and deleted all of maven/plugins/trunk/pom.xml a few > times under different project groups. > When I add it under the pom default org.apache.maven.plugins group, > I get duplicate emails for every build. > wsmoak, have you verified that there are not duplicate entries for > emails in the build defs? > I used to get duplicates when I belonged to an distribution-list and > a direct email address. > joakim: there is only the default build definition, and admin is > the only member of the group > wsmoak: I think we look at project group notifiers too when we > look at project notifier, so we get the project group notifier twice when we > send the mail > it only happens when I add the projects under the pom default group > id. If I delete and re-add it to some other group, I only get one email. > yes, because, when you use the default project group, project > notifiers are moved to the project group but I think they aren't removed in > the project > okay. and it's only happening with maven/plugins because struts, > etc. doesn't have notifiers in the pom. > From the log file (email addresses changed...): > INFO | jvm 1| 2007/01/02 20:16:39 | 2007-01-02 20:16:39,831 > [pool-1-thread-1] INFO ShellCommandHelper:default - Executing: mvn > --batch-mode --non-recursive clean install > INFO | jvm 1| 2007/01/02 20:16:39 | 2007-01-02 20:16:39,831 > [pool-1-thread-1] INFO ShellCommandHelper:default - Working directory: > /opt/continuum-1.1-r490629-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/7 > INFO | jvm 1| 2007/01/02 20:16:41 | 2007-01-02 20:16:41,660 > [pool-1-thread-1] INFO ContinuumBuildExecutor:maven2 - Exit code: 1 > INFO | jvm 1| 2007/01/02 20:16:41 | 2007-01-02 20:16:41,944 > [pool-1-thread-1] INFO BuildController:default- Performing action > deploy-artifact > INFO | jvm 1| 2007/01/02 20:16:42 | 2007-01-02 20:16:42,072 > [pool-1-thread-1] INFO Notifier:mail - Sending message: > From '"[EMAIL PROTECTED]" <[EMAIL PROTECTED]>'. > INFO | jvm 1| 2007/01/02 20:16:42 | 2007-01-02 20:16:42,072 > [pool-1-thread-1] INFO Notifier:mail - Recipient: To > '<[EMAIL PROTECTED]>'. > INFO | jvm 1| 2007/01/02 20:16:42 | 2007-01-02 20:16:42,337 > [pool-1-thread-1] INFO Notifier:mail - Sending message: > From '"[EMAIL PROTECTED]" <[EMAIL PROTECTED]>'. > INFO | jvm 1| 2007/01/02 20:16:42 | 2007-01-02 20:16:42,337 > [pool-1-thread-1] INFO Notifier:mail - Recipient: To > '<[EMAIL PROTECTED]>'. -- 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: (CONTINUUM-1133) Project Site URL in wagon notifier edit pages is required but doesn't have validation
[ http://jira.codehaus.org/browse/CONTINUUM-1133?page=all ] Emmanuel Venisse closed CONTINUUM-1133. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.1 Applied without the hack on https protocol because it's a standard protocol > Project Site URL in wagon notifier edit pages is required but doesn't have > validation > - > > Key: CONTINUUM-1133 > URL: http://jira.codehaus.org/browse/CONTINUUM-1133 > Project: Continuum > Issue Type: Bug > Components: Notification Subsystem >Reporter: Henry S. Isidro > Assigned To: Emmanuel Venisse >Priority: Minor > Fix For: 1.1 > > Attachments: [CONTINUUM-1133]-continuum-webapp.patch, > [CONTINUUM-1133]-continuum-webapp.patch-2 > > -- 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-1136) relying on default charset while backing up continuum store
[ http://jira.codehaus.org/browse/CONTINUUM-1136?page=comments#action_84823 ] Emmanuel Venisse commented on CONTINUUM-1136: - Your patch isn't compatible with jdk1.4 > relying on default charset while backing up continuum store > --- > > Key: CONTINUUM-1136 > URL: http://jira.codehaus.org/browse/CONTINUUM-1136 > Project: Continuum > Issue Type: Bug > Components: Database >Affects Versions: 1.1 > Environment: Windows XP Professional SP2 > JDK6 >Reporter: Marcelo Takeshi Fukushima > Attachments: data-management.patch > > > While backing up the store, jdo continuum store uses a FileWriter wich relies > on the system's default charset encoding, but the continuum database tries to > store using utf-8. > Should use a FileOutputStream and OutputStreamWriter ( OutputStream, Charset > ) 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] Updated: (CONTINUUM-1136) relying on default charset while backing up continuum store
[ http://jira.codehaus.org/browse/CONTINUUM-1136?page=all ] Emmanuel Venisse updated CONTINUUM-1136: Comment: was deleted > relying on default charset while backing up continuum store > --- > > Key: CONTINUUM-1136 > URL: http://jira.codehaus.org/browse/CONTINUUM-1136 > Project: Continuum > Issue Type: Bug > Components: Database >Affects Versions: 1.1 > Environment: Windows XP Professional SP2 > JDK6 >Reporter: Marcelo Takeshi Fukushima > Fix For: 1.1 > > Attachments: data-management.patch > > > While backing up the store, jdo continuum store uses a FileWriter wich relies > on the system's default charset encoding, but the continuum database tries to > store using utf-8. > Should use a FileOutputStream and OutputStreamWriter ( OutputStream, Charset > ) 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] Closed: (CONTINUUM-1136) relying on default charset while backing up continuum store
[ http://jira.codehaus.org/browse/CONTINUUM-1136?page=all ] Emmanuel Venisse closed CONTINUUM-1136. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.1 Applied. > relying on default charset while backing up continuum store > --- > > Key: CONTINUUM-1136 > URL: http://jira.codehaus.org/browse/CONTINUUM-1136 > Project: Continuum > Issue Type: Bug > Components: Database >Affects Versions: 1.1 > Environment: Windows XP Professional SP2 > JDK6 >Reporter: Marcelo Takeshi Fukushima > Assigned To: Emmanuel Venisse > Fix For: 1.1 > > Attachments: data-management.patch > > > While backing up the store, jdo continuum store uses a FileWriter wich relies > on the system's default charset encoding, but the continuum database tries to > store using utf-8. > Should use a FileOutputStream and OutputStreamWriter ( OutputStream, Charset > ) 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: (MIDEA-54) Fixed range versions in dependencies corrupt the module file
[ http://jira.codehaus.org/browse/MIDEA-54?page=comments#action_84826 ]
Immo Huneke commented on MIDEA-54:
--
This is proving very inconvenient for us too. We have some components that can
work with a range of versions of other components. Each time we wish to
regenerate the IDEA module files, we have to replace every range expression
with just a single version number in order to ensure that the .iml file doesn't
omit all external libraries.
> Fixed range versions in dependencies corrupt the module file
>
>
> Key: MIDEA-54
> URL: http://jira.codehaus.org/browse/MIDEA-54
> Project: Maven 2.x Idea Plugin
> Issue Type: Bug
> Environment: maven 2.0.4, plugin snapshot built from svn
>Reporter: Andrew Perepelytsya
>
> I have the following config snippet declared in pom.xml:
> {code}
>
> xerces
> xercesImpl
>
> [2.8.0]
>
> {code}
> Note those *square brackets*, this works ok with Maven letting it sort of fix
> the 2.8.0 version. Now it seemed to be fine when I initially generated
> idea:idea project (dependency was at 2.6.2 version then). Recently it has
> been upgraded, and I went back to re-generate the core module via
> idea:module. The error I got:
> {panel}
> [WARNING] An error occurred during dependency resolution of the following
> artifact:
> org.codehaus.mule:mule-core2.0-SNAPSHOT
> Caused by: Missing:
> --
> 1) xerces:xercesImpl:jar:[2.8.0]
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=xerces -DartifactId=xercesImpl \
> -Dversion=[2.8.0] -Dpackaging=jar -Dfile=/path/to/file
> Path to dependency:
> 1) org.codehaus.mule:mule-core:jar:2.0-SNAPSHOT
> 2) xerces:xercesImpl:jar:[2.8.0]
> --
> 1 required artifact is missing.
> {panel}
> The generated iml file had *all libraries removed*.
--
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-54) Fixed range versions in dependencies corrupt the module file
[ http://jira.codehaus.org/browse/MIDEA-54?page=comments#action_84827 ]
Immo Huneke commented on MIDEA-54:
--
By the way, I don't understand why this issue is marked "closed" - it still
seems broken to me just as the description above says.
> Fixed range versions in dependencies corrupt the module file
>
>
> Key: MIDEA-54
> URL: http://jira.codehaus.org/browse/MIDEA-54
> Project: Maven 2.x Idea Plugin
> Issue Type: Bug
> Environment: maven 2.0.4, plugin snapshot built from svn
>Reporter: Andrew Perepelytsya
>
> I have the following config snippet declared in pom.xml:
> {code}
>
> xerces
> xercesImpl
>
> [2.8.0]
>
> {code}
> Note those *square brackets*, this works ok with Maven letting it sort of fix
> the 2.8.0 version. Now it seemed to be fine when I initially generated
> idea:idea project (dependency was at 2.6.2 version then). Recently it has
> been upgraded, and I went back to re-generate the core module via
> idea:module. The error I got:
> {panel}
> [WARNING] An error occurred during dependency resolution of the following
> artifact:
> org.codehaus.mule:mule-core2.0-SNAPSHOT
> Caused by: Missing:
> --
> 1) xerces:xercesImpl:jar:[2.8.0]
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=xerces -DartifactId=xercesImpl \
> -Dversion=[2.8.0] -Dpackaging=jar -Dfile=/path/to/file
> Path to dependency:
> 1) org.codehaus.mule:mule-core:jar:2.0-SNAPSHOT
> 2) xerces:xercesImpl:jar:[2.8.0]
> --
> 1 required artifact is missing.
> {panel}
> The generated iml file had *all libraries removed*.
--
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-1103) Build Fresh checkbox doesn't stay checked
[ http://jira.codehaus.org/browse/CONTINUUM-1103?page=comments#action_84830 ] Emmanuel Venisse commented on CONTINUUM-1103: - Marcelo, I committed your patches for continuum-stored with some fixes and more tests, but not the jpox patch because I'd prefer to use the latest jpox 1.1.5 and continuum doesn't start with jpox 1.1.3 (no time to investigate for now) > Build Fresh checkbox doesn't stay checked > - > > Key: CONTINUUM-1103 > URL: http://jira.codehaus.org/browse/CONTINUUM-1103 > Project: Continuum > Issue Type: Bug > Components: Web - UI >Affects Versions: 1.1 >Reporter: Wendy Smoak > Assigned To: Teodoro Cue Jr. > Attachments: buildFresh.patch, CONTINUUM-1103-continuum-core.patch, > jpox1.1.3.patch > > > To reproduce: > Project Groups -> [any group] -> Build Definitions tab > 1. Edit a build definition > 2. check the 'Build Fresh' checkbox > 3. Save > 4. Edit the same build definition > The checkbox should remain checked, but it does not. -- 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: (CONTINUUM-1103) Build Fresh checkbox doesn't stay checked
[ http://jira.codehaus.org/browse/CONTINUUM-1103?page=all ] Emmanuel Venisse closed CONTINUUM-1103. --- Assignee: Emmanuel Venisse (was: Teodoro Cue Jr.) Resolution: Fixed Fix Version/s: 1.1 Patch applied. Thanks Teodoro. > Build Fresh checkbox doesn't stay checked > - > > Key: CONTINUUM-1103 > URL: http://jira.codehaus.org/browse/CONTINUUM-1103 > Project: Continuum > Issue Type: Bug > Components: Web - UI >Affects Versions: 1.1 >Reporter: Wendy Smoak > Assigned To: Emmanuel Venisse > Fix For: 1.1 > > Attachments: buildFresh.patch, CONTINUUM-1103-continuum-core.patch, > jpox1.1.3.patch > > > To reproduce: > Project Groups -> [any group] -> Build Definitions tab > 1. Edit a build definition > 2. check the 'Build Fresh' checkbox > 3. Save > 4. Edit the same build definition > The checkbox should remain checked, but it does not. -- 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-2759) Resolving transitive dependencies of artefacts with classifiers fails
Resolving transitive dependencies of artefacts with classifiers fails - Key: MNG-2759 URL: http://jira.codehaus.org/browse/MNG-2759 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Environment: Windows XP, Maven 2.0.4 Reporter: Fabian Bauschulte Attachments: project.zip I have the following projects with subprojects projectA, projectB and projectC. projectA depends on projectB, projectC depends on projectB. All projects use classifiers: ... projectB org.apache.maven.plugins maven-jar-plugin someclassifier test projectB 1.0.0 someclassifier When running "mvn clean install" on the the parent works fine. But running "mvn install" only in projectC fails: C:\Data\maven-test\projectC>mvn clean install [INFO] Scanning for projects... [INFO] [INFO] Building Unnamed - test:projectC:jar:1.0.0 [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory C:\Data\maven-test\projectC\target [INFO] Deleting directory C:\Data\maven-test\projectC\target\classes [INFO] Deleting directory C:\Data\maven-test\projectC\target\test-classes [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. Downloading: http://repo1.maven.org/maven2/test/projectB/1.0.0/projectB-1.0.0.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) [INFO] [compiler:compile] Compiling 1 source file to C:\Daten\maven-test\projectC\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\Data\maven-test\projectC\src\main\java\ClassC.java:[3,12] cannot find symbol symbol : class ClassA location: package test [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1320) Javassist 3.1 upload request
Javassist 3.1 upload request Key: MAVENUPLOAD-1320 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1320 Project: maven-upload-requests Issue Type: Task Reporter: Hugo Palma Simple Java bytecode manipulation -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-67) webResource filtering needs filter
[ http://jira.codehaus.org/browse/MWAR-67?page=comments#action_84835 ] Robert Watkins commented on MWAR-67: While this patch allows for properties to be specified on the command line, it doesn't allow properties to be specified in a profile. Setting properties for filtering in a profile works with normal JAR resources. > webResource filtering needs filter > -- > > Key: MWAR-67 > URL: http://jira.codehaus.org/browse/MWAR-67 > Project: Maven 2.x War Plugin > Issue Type: Bug >Reporter: Tomasz Pik > Assigned To: Brett Porter >Priority: Minor > Fix For: 2.0.2 > > Attachments: MWAR-67-maven-war-plugin-2.patch, > MWAR-67-maven-war-plugin.patch > > > Filtering of webResources works only, if there's at least one > path/to/properties defined in pom. > So without such a configuration there's no possiblity to build war file with > filtering using values specified during build invocation, with -D options > (System properties are ignored). > Adding reference to (even empty) file using element 'solves' the > problem and properties defined using -D are used. -- 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: (MSUREFIRE-172) Bug into xml report generation
[ http://jira.codehaus.org/browse/MSUREFIRE-172?page=comments#action_84836
]
Milos Volauf commented on MSUREFIRE-172:
Hi.
I am also voting for this bug to be fixed.
Here is a hint for the fix:
in the module surefire-api, the class
org.apache.maven.surefire.report.XMLReporter
should implement a method:
public void testSetStarting(ReportEntry report) throws ReporterException {
super.testSetStarting(report);
results.clear();
}
(before each start, previous result should be cleared. AbstractTextReporter
does the same.)
I tried it locally and it works.
Can someone provide a guess when this fix could appear in the released plugin
(e.g. maven-surefire-plugin version 2.2.1 or something) ?
> Bug into xml report generation
> --
>
> Key: MSUREFIRE-172
> URL: http://jira.codehaus.org/browse/MSUREFIRE-172
> Project: Maven 2.x Surefire Plugin
> Issue Type: Bug
> Components: xml generation
> Environment: release 2.0 of maven-surfire-plugin
> mvn 2.0.4
>Reporter: Christophe Lallement
> Attachments: nick.zip,
> TEST-deai.ft.archi.common.debug.ThreadWarningSystemTest.xml,
> ThreadWarningSystem.java, ThreadWarningSystemTest.java
>
>
> since 2-3 weeks i have wrong information into my junit test tun (mvn test for
> example)
> In fact, the *.txt are right, but the corresponding xml file have wrong
> entry. i means additionnal testcase are present ninto the testcase section.
> you can find exmple in attachement (ThreadWarningSystemTest for example). You
> can see that the error number are good (because read into the attribute of
> the first xml tag) but in several TestSuite, we have testcase form other
> testsuite.
> I don't know if this errors comes from maven dependancies update.
> What i am sure is:
> 1/ a little bit of source modification into my project since this error
> appears.
> 2/ no new maven dependancies into my project
> 3/ i use only ibilio/maven2 as repository.
> This errors can'be shown on other projet and other not ...
> I have a workaround to solve this issue but with low performance:
> I use the option "fork per test" and the reports is right.
> Maybe a way to be investigate can be the temporaly file created by the
> command line:
> Forking command line: java -classpath
> > C:\HOMEWARE\maven-2_local\org\apache\maven\surefire\surefire-api\2.0\surefire-api-2.0.jar;C:\HOMEWARE\maven-2_local\o
> > rg\codehaus\plexus\plexus-utils\1.1\plexus-utils-1.1.jar;C:\HOMEWARE\maven-2_local\org\apache\maven\surefire\surefire-booter\2.0\surefire-booter-2.0.jar
> > or
> > g.apache.maven.surefire.booter.SurefireBooter C:\temp\surefire40840tmp
> > C:\temp\surefire40841tmp
> Any Idea ?
> Thx
> Christophe
--
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-1321) jawin
jawin - Key: MAVENUPLOAD-1321 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1321 Project: maven-upload-requests Issue Type: New Feature Reporter: Anna Alekseevna Nejentseva Attachments: jawin.jar, 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] Closed: (CONTINUUM-1105) Duplicate email notifications with notifier in pom.xml
[ http://jira.codehaus.org/browse/CONTINUUM-1105?page=all ] Emmanuel Venisse closed CONTINUUM-1105. --- Assignee: Emmanuel Venisse (was: Maria Odea Ching) Resolution: Fixed Fix Version/s: 1.1 Apply with some more tests > Duplicate email notifications with notifier in pom.xml > -- > > Key: CONTINUUM-1105 > URL: http://jira.codehaus.org/browse/CONTINUUM-1105 > Project: Continuum > Issue Type: Bug > Components: Notifier - Mail >Affects Versions: 1.1 >Reporter: Wendy Smoak > Assigned To: Emmanuel Venisse > Fix For: 1.1 > > Attachments: CONTINUUM-1105-continuum-core.patch > > > When there is a notifier in the pom, and a group of projects (such as > maven/plugins/trunk/pom.xml) is added under the groupId in the pom, every > notification email is duplicated. > In the UI for each project, the notifier correctly shows "From Project". It > doesn't look like two notifiers have been added. > 20070102 IRC conversation about adding maven/plugins/trunk/pom.xml under > various groupIds: > what could make continuum send duplicate emails? > I've added and deleted all of maven/plugins/trunk/pom.xml a few > times under different project groups. > When I add it under the pom default org.apache.maven.plugins group, > I get duplicate emails for every build. > wsmoak, have you verified that there are not duplicate entries for > emails in the build defs? > I used to get duplicates when I belonged to an distribution-list and > a direct email address. > joakim: there is only the default build definition, and admin is > the only member of the group > wsmoak: I think we look at project group notifiers too when we > look at project notifier, so we get the project group notifier twice when we > send the mail > it only happens when I add the projects under the pom default group > id. If I delete and re-add it to some other group, I only get one email. > yes, because, when you use the default project group, project > notifiers are moved to the project group but I think they aren't removed in > the project > okay. and it's only happening with maven/plugins because struts, > etc. doesn't have notifiers in the pom. > From the log file (email addresses changed...): > INFO | jvm 1| 2007/01/02 20:16:39 | 2007-01-02 20:16:39,831 > [pool-1-thread-1] INFO ShellCommandHelper:default - Executing: mvn > --batch-mode --non-recursive clean install > INFO | jvm 1| 2007/01/02 20:16:39 | 2007-01-02 20:16:39,831 > [pool-1-thread-1] INFO ShellCommandHelper:default - Working directory: > /opt/continuum-1.1-r490629-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/7 > INFO | jvm 1| 2007/01/02 20:16:41 | 2007-01-02 20:16:41,660 > [pool-1-thread-1] INFO ContinuumBuildExecutor:maven2 - Exit code: 1 > INFO | jvm 1| 2007/01/02 20:16:41 | 2007-01-02 20:16:41,944 > [pool-1-thread-1] INFO BuildController:default- Performing action > deploy-artifact > INFO | jvm 1| 2007/01/02 20:16:42 | 2007-01-02 20:16:42,072 > [pool-1-thread-1] INFO Notifier:mail - Sending message: > From '"[EMAIL PROTECTED]" <[EMAIL PROTECTED]>'. > INFO | jvm 1| 2007/01/02 20:16:42 | 2007-01-02 20:16:42,072 > [pool-1-thread-1] INFO Notifier:mail - Recipient: To > '<[EMAIL PROTECTED]>'. > INFO | jvm 1| 2007/01/02 20:16:42 | 2007-01-02 20:16:42,337 > [pool-1-thread-1] INFO Notifier:mail - Sending message: > From '"[EMAIL PROTECTED]" <[EMAIL PROTECTED]>'. > INFO | jvm 1| 2007/01/02 20:16:42 | 2007-01-02 20:16:42,337 > [pool-1-thread-1] INFO Notifier:mail - Recipient: To > '<[EMAIL PROTECTED]>'. -- 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: (CONTINUUM-1087) After disabling a schedule, the disabled schedule is not grayed out like the earlier version
[ http://jira.codehaus.org/browse/CONTINUUM-1087?page=all ] Emmanuel Venisse closed CONTINUUM-1087. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.1 I added a new column > After disabling a schedule, the disabled schedule is not grayed out like the > earlier version > > > Key: CONTINUUM-1087 > URL: http://jira.codehaus.org/browse/CONTINUUM-1087 > Project: Continuum > Issue Type: Bug > Components: Web - UI >Affects Versions: 1.1 > Environment: windows 2000 pro >Reporter: apache maillist > Assigned To: Emmanuel Venisse > Fix For: 1.1 > > -- 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-39) Documentation: filter web.xml should recommend to add a pregoal to war:war-resources
[ http://jira.codehaus.org/browse/MPWAR-39?page=all ] Jerome Lacoste closed MPWAR-39. --- > Documentation: filter web.xml should recommend to add a pregoal to > war:war-resources > > > Key: MPWAR-39 > URL: http://jira.codehaus.org/browse/MPWAR-39 > Project: maven-war-plugin > Issue Type: Improvement >Reporter: Jerome Lacoste > Assigned To: Stephane Nicoll > Fix For: 1.6.2 > > > Documentation says: > "If you need to copy the web.xml file in order to replace some filter tokens > or simply perform some custom modification to it, simply write a pre-goal to > the war:war goal in which you perform the manipulation. Then set the > maven.war.webxml property to point to your modified web.xml." > instead it could say > [...] simply write a pre-goal to the war:war-resources [...] > Otherwise it won't work with exploded war 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: (CONTINUUM-1106) Could not load class pssAutoLoginInterceptor Error due to missing plexus-ehcache class
[ http://jira.codehaus.org/browse/CONTINUUM-1106?page=all ] Emmanuel Venisse closed CONTINUUM-1106. --- Assignee: Emmanuel Venisse Resolution: Cannot Reproduce > Could not load class pssAutoLoginInterceptor Error due to missing > plexus-ehcache class > -- > > Key: CONTINUUM-1106 > URL: http://jira.codehaus.org/browse/CONTINUUM-1106 > Project: Continuum > Issue Type: Bug > Components: Core system >Affects Versions: 1.1 >Reporter: Albert Strasheim > Assigned To: Emmanuel Venisse > > I just deployed the WAR built from Continuum trunk to my brand new > installation of Apache Tomcat 5.5.20. > I ran into the following problems: > After configuring my app as shown here: > http://svn.apache.org/repos/asf/maven/continuum/trunk/continuum-webapp-test/src/test/tomcat5x/conf/Catalina/localhost/continuum.xml > Tomcat couldn't find Apache Derby. Copying the Derby JAR to common/lib solved > that problem. > Then Tomcat couldn't find a MessagingException from javax.mail. Copying > javax/mail/mail/1.4/mail-1.4.jar from my Maven repository to > webapps/continuum/WEB-INF/lib in my Tomcat directory solved that problem. > Now Tomcat can start Continuum but when I try to access the application, I > get the following error: > Caused by: java.lang.NoClassDefFoundError: > Lorg/codehaus/plexus/ehcache/EhcacheComponent > The JAR for this class (I'm guessing plexus-ehcache-something.jar) doesn't > seem to be in the WEB-INF/lib directory with the rest of the the Continuum > libraries > Complete log: > 1321 [http-8080-Processor23] INFO org.codehaus.plexus.PlexusContainer - > Loading on start [role]: [org.apache.maven.continuum.Continuum] > 1920 [http-8080-Processor23] INFO org.quartz.simpl.RAMJobStore - > RAMJobStore initialized. > 1920 [http-8080-Processor23] INFO org.quartz.impl.StdSchedulerFactory - > Quartz scheduler 'defaultScheduler' initialized from an externally provided > properties instance. > 1921 [http-8080-Processor23] INFO org.quartz.impl.StdSchedulerFactory - > Quartz scheduler version: 1.4.5 > 1921 [http-8080-Processor23] INFO org.quartz.core.QuartzScheduler - > Scheduler defaultScheduler_$_NON_CLUSTERED started. > 1969 [http-8080-Processor23] WARN > org.apache.maven.continuum.execution.ContinuumBuildExecutor:ant - Could not > find the executable 'ant' in the path '[]'. > 1975 [http-8080-Processor23] WARN > org.apache.maven.continuum.execution.ContinuumBuildExecutor:maven-1 - Could > not find the executable 'maven' in the path '[]'. > 2206 [http-8080-Processor23] DEBUG > org.apache.maven.settings.MavenSettingsBuilder - Building Maven global-level > settings from: '/opt/apache-tomcat-5.5.20/bin/null/conf/settings.xml' > 2206 [http-8080-Processor23] DEBUG > org.apache.maven.settings.MavenSettingsBuilder - Building Maven user-level > settings from: '/root/.m2/settings.xml' > 2298 [http-8080-Processor23] WARN > org.apache.maven.continuum.execution.ContinuumBuildExecutor:maven2 - Could > not find the executable 'mvn' in the path '[]'. > 2300 [http-8080-Processor23] INFO > org.apache.maven.continuum.execution.manager.BuildExecutorManager - Build > executors: > 2301 [http-8080-Processor23] INFO > org.apache.maven.continuum.execution.manager.BuildExecutorManager - maven-1 > 2301 [http-8080-Processor23] INFO > org.apache.maven.continuum.execution.manager.BuildExecutorManager - ant > 2301 [http-8080-Processor23] INFO > org.apache.maven.continuum.execution.manager.BuildExecutorManager - maven2 > 2301 [http-8080-Processor23] INFO > org.apache.maven.continuum.execution.manager.BuildExecutorManager - shell > 2803 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > Initializing Continuum. > 2803 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > Showing all projects: > 4175 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > Starting Continuum. > 4176 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > 4176 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > 4176 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - < > Continuum 1.1-SNAPSHOT started! > > 4177 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > --- > 4177 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > \ ^__^ > 4177 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > \ (oo)\___ > 4177 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > (__)\ )\/\ > 4177 [http-8080-Processor23] INFO org.apache.maven.continuum.Continuum - > ||w | > 4177 [http-8080-Processor23] INFO org.apache.maven.cont
[jira] Commented: (MNG-2068) Multiple inheritance fails to find "grand" parent in ../../pom.xml when the groupIds differ (Test Case Attached)
[ http://jira.codehaus.org/browse/MNG-2068?page=comments#action_84842 ] Vincenz Braun commented on MNG-2068: We have the same issue with maven 2.0.4. Please reopen this bug. You must have a clean repository and build from the "middle" project. The log output is: [DEBUG] Searching for parent-POM: samplegroup:master::0.0.1 of project: samplegroup:frameworks:pom:0.0.1 in relative path: ../pom.xml [DEBUG] Using parent-POM from the project hierarchy at: '../pom.xml' for project: samplegroup:frameworks:pom:0.0.1 [DEBUG] Retrieving parent-POM: samplegroup:master::0.0.1 for project: samplegroup:frameworks:pom:0.0.1 from the repository. [DEBUG] Trying repository central Downloading: http://repo1.maven.org/maven2/samplegroup/master/0.0.1/master-0.0.1.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) [INFO] [ERROR] FATAL ERROR [INFO] This is although all projects have the same groupid. I have attached a use case for this. > Multiple inheritance fails to find "grand" parent in ../../pom.xml when the > groupIds differ (Test Case Attached) > > > Key: MNG-2068 > URL: http://jira.codehaus.org/browse/MNG-2068 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.2 >Reporter: Brian Fox > Assigned To: John Casey >Priority: Critical > Fix For: 2.0.3 > > Attachments: good-sample.zip, mavenbugreport.zip, sample.zip > > > I have a project that inherits from 2 (or more) parents. If the grand parent > (parent of my parent) isn't in the repository, it isn't found at ../../pom.xml > In my sample, make sure none of the artifacts are in your repository, then go > down to sample-jar and try to build from there. See it fail. > Note: If you remove the ".sub" from the second parent's group and update the > sampe-jar pom, it no longer fails and finds the grandparent. > See below for the output when the groups are different (fails) and when they > are the same (works) > Failing output: > E:\sample\sample\sample-parent2\sample-jar>mvn -X compile > + Error stacktraces are turned on. > [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and > Settin > gs\brianf\.m2\plugin-registry.xml' > [DEBUG] Building Maven global-level plugin registry from: > 'c:\PROGRA~1\MAVEN-~1. > 2\bin\..\conf\plugin-registry.xml' > [INFO] Scanning for projects... > [DEBUG] Using parent-POM from the project hierarchy at: '../pom.xml' for > project > : null:sample-jar:jar:null > [DEBUG] Invalid parent-POM referenced by relative path '../pom.xml' in parent > sp > ecification in null:sample-parent2:pom:null: > Specified: sample-project.sub:sample-parent::SNAPSHOT > Found: sample-project:sample-parent:pom:SNAPSHOT > [DEBUG] Retrieving parent-POM from the repository for project: > null:sample-paren > t2:pom:null > [DEBUG] Skipping disabled repository central > [DEBUG] sample-parent: using locally installed snapshot > [DEBUG] Trying repository sv1-int > Downloading: > http://sv1.tus.stchome.com:9998/repository/sample-project/sub/sampl > e-parent/SNAPSHOT/sample-parent-SNAPSHOT.pom > [WARNING] Unable to get resource from repository sv1-int > (http://sv1.tus.stchome > .com:9998/repository) > [DEBUG] Trying repository Maven Snapshots > Downloading: > http://snapshots.maven.codehaus.org/maven2//sample-project/sub/samp > le-parent/SNAPSHOT/sample-parent-SNAPSHOT.pom > [WARNING] Unable to get resource from repository Maven Snapshots > (http://snapsho > ts.maven.codehaus.org/maven2/) > [DEBUG] Skipping disabled repository central > [INFO] > - > --- > [ERROR] FATAL ERROR > [INFO] > - > --- > [INFO] Failed to resolve artifact. > GroupId: sample-project.sub > ArtifactId: sample-parent > Version: SNAPSHOT > Reason: Unable to download the artifact from any repository > sample-project.sub:sample-parent:pom:SNAPSHOT > OUTPUT WITHOUT .sub: > E:\sample\sample\sample-parent2\sample-jar>mvn -X compile > + Error stacktraces are turned on. > [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and > Settin > gs\brianf\.m2\plugin-registry.xml' > [DEBUG] Building Maven global-level plugin registry from: > 'c:\PROGRA~1\MAVEN-~1. > 2\bin\..\conf\plugin-registry.xml' > [INFO] Scanning for projects... > [DEBUG] Using parent-POM from the project hierarchy at: '../pom.xml' for > project > : null:sample-jar:jar:null > [DEBUG] Using parent-POM from the project hierarchy at
[jira] Updated: (MNG-2068) Multiple inheritance fails to find "grand" parent in ../../pom.xml when the groupIds differ (Test Case Attached)
[ http://jira.codehaus.org/browse/MNG-2068?page=all ] Vincenz Braun updated MNG-2068: --- Attachment: mavenbugreport.zip new test case with only 3 poms that fails with maven 2.0.4 > Multiple inheritance fails to find "grand" parent in ../../pom.xml when the > groupIds differ (Test Case Attached) > > > Key: MNG-2068 > URL: http://jira.codehaus.org/browse/MNG-2068 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.2 >Reporter: Brian Fox > Assigned To: John Casey >Priority: Critical > Fix For: 2.0.3 > > Attachments: good-sample.zip, mavenbugreport.zip, sample.zip > > > I have a project that inherits from 2 (or more) parents. If the grand parent > (parent of my parent) isn't in the repository, it isn't found at ../../pom.xml > In my sample, make sure none of the artifacts are in your repository, then go > down to sample-jar and try to build from there. See it fail. > Note: If you remove the ".sub" from the second parent's group and update the > sampe-jar pom, it no longer fails and finds the grandparent. > See below for the output when the groups are different (fails) and when they > are the same (works) > Failing output: > E:\sample\sample\sample-parent2\sample-jar>mvn -X compile > + Error stacktraces are turned on. > [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and > Settin > gs\brianf\.m2\plugin-registry.xml' > [DEBUG] Building Maven global-level plugin registry from: > 'c:\PROGRA~1\MAVEN-~1. > 2\bin\..\conf\plugin-registry.xml' > [INFO] Scanning for projects... > [DEBUG] Using parent-POM from the project hierarchy at: '../pom.xml' for > project > : null:sample-jar:jar:null > [DEBUG] Invalid parent-POM referenced by relative path '../pom.xml' in parent > sp > ecification in null:sample-parent2:pom:null: > Specified: sample-project.sub:sample-parent::SNAPSHOT > Found: sample-project:sample-parent:pom:SNAPSHOT > [DEBUG] Retrieving parent-POM from the repository for project: > null:sample-paren > t2:pom:null > [DEBUG] Skipping disabled repository central > [DEBUG] sample-parent: using locally installed snapshot > [DEBUG] Trying repository sv1-int > Downloading: > http://sv1.tus.stchome.com:9998/repository/sample-project/sub/sampl > e-parent/SNAPSHOT/sample-parent-SNAPSHOT.pom > [WARNING] Unable to get resource from repository sv1-int > (http://sv1.tus.stchome > .com:9998/repository) > [DEBUG] Trying repository Maven Snapshots > Downloading: > http://snapshots.maven.codehaus.org/maven2//sample-project/sub/samp > le-parent/SNAPSHOT/sample-parent-SNAPSHOT.pom > [WARNING] Unable to get resource from repository Maven Snapshots > (http://snapsho > ts.maven.codehaus.org/maven2/) > [DEBUG] Skipping disabled repository central > [INFO] > - > --- > [ERROR] FATAL ERROR > [INFO] > - > --- > [INFO] Failed to resolve artifact. > GroupId: sample-project.sub > ArtifactId: sample-parent > Version: SNAPSHOT > Reason: Unable to download the artifact from any repository > sample-project.sub:sample-parent:pom:SNAPSHOT > OUTPUT WITHOUT .sub: > E:\sample\sample\sample-parent2\sample-jar>mvn -X compile > + Error stacktraces are turned on. > [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and > Settin > gs\brianf\.m2\plugin-registry.xml' > [DEBUG] Building Maven global-level plugin registry from: > 'c:\PROGRA~1\MAVEN-~1. > 2\bin\..\conf\plugin-registry.xml' > [INFO] Scanning for projects... > [DEBUG] Using parent-POM from the project hierarchy at: '../pom.xml' for > project > : null:sample-jar:jar:null > [DEBUG] Using parent-POM from the project hierarchy at: '../pom.xml' for > project > : null:sample-parent2:pom:null > [INFO] > - > --- > [INFO] Building Maven Quick Start Archetype > [INFO]task-segment: [compile] > [INFO] > - > --- > [DEBUG] maven-resources-plugin: resolved to version 2.1 from repository > central > [DEBUG] Retrieving parent-POM from the repository for project: > null:maven-resour -- 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: (CONTINUUM-1114) can't delete a whole project group
[ http://jira.codehaus.org/browse/CONTINUUM-1114?page=all ] Emmanuel Venisse closed CONTINUUM-1114. --- Assignee: Emmanuel Venisse Resolution: Cannot Reproduce Fix Version/s: 1.1 I can't reproduce it. Reopen this issue if you reproduce it and add informations on how to reproduce the pb. > can't delete a whole project group > -- > > Key: CONTINUUM-1114 > URL: http://jira.codehaus.org/browse/CONTINUUM-1114 > Project: Continuum > Issue Type: Bug > Components: Database >Affects Versions: 1.1 >Reporter: Brian Fox > Assigned To: Emmanuel Venisse > Fix For: 1.1 > > > I created a group, added projects. I was having build failures etc and then > tried to delete the whole group: >Continuum > Continuum | Maven | Apache > Current User: admin (admin) - Edit Details - Logout > Continuum > About > Show Project Groups > Add Project > Maven 2.0.x Project > Maven 1.x Project > Ant Project > Shell Project > Administration > Schedules > Configuration > Appearance > Users > Legend > Build Now > Build History > Build In Progess > Checking Out Build > Queued Build > Delete > Edit > Release > Build in Success > Build in Failure > Build in Error > > Error Occurred > javax.jdo.JDODataStoreException: Delete request failed: DELETE FROM > PROJECTGROUP WHERE ID = ? NestedThrowables: java.sql.SQLException: The DELETE > statement conflicted with the REFERENCE constraint "PROJECT_FK1". The > conflict occurred in database "continuum", table "continuum.PROJECT", column > 'PROJECT_GROUP_ID_OID'. > Show/hide Stack Trace > javax.jdo.JDODataStoreException: Delete request failed: DELETE FROM > PROJECTGROUP WHERE ID = ? > at > org.jpox.store.rdbms.request.DeleteRequest.execute(DeleteRequest.java:274) > at org.jpox.store.rdbms.table.ClassTable.delete(ClassTable.java:2471) > at org.jpox.store.StoreManager.delete(StoreManager.java:836) > at > org.jpox.state.StateManagerImpl.internalDeletePersistent(StateManagerImpl.java:4217) > at > org.jpox.state.StateManagerImpl.deletePersistent(StateManagerImpl.java:4172) > at > org.jpox.AbstractPersistenceManager.internalDeletePersistent(AbstractPersistenceManager.java:1393) > at > org.jpox.AbstractPersistenceManager.deletePersistent(AbstractPersistenceManager.java:1404) > at > org.codehaus.plexus.jdo.PlexusJdoUtils.removeObject(PlexusJdoUtils.java:121) > at > org.apache.maven.continuum.store.JdoContinuumStore.removeObject(JdoContinuumStore.java:1221) > at > org.apache.maven.continuum.store.JdoContinuumStore.removeProjectGroup(JdoContinuumStore.java:1142) > at > org.apache.maven.continuum.DefaultContinuum.removeProjectGroup(DefaultContinuum.java:247) > at > org.apache.maven.continuum.web.action.ProjectGroupAction.remove(ProjectGroupAction.java:150) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at > com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:364) > at > com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:216) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) > at > com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:168) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > org.apache.maven.continuum.web.interceptor.ForceContinuumConfigurationInterceptor.intercept(ForceContinuumConfigurationInterceptor.java:58) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > org.codehaus.plexus.security.ui.web.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.java:160) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) > at > org.codehaus.plexus.security.ui.web.interceptor.AutoLoginInterceptor.intercept(AutoLoginInterceptor.java:152) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(Defaul
[jira] Closed: (CONTINUUM-926) Unable to disable a schedule
[ http://jira.codehaus.org/browse/CONTINUUM-926?page=all ] Emmanuel Venisse closed CONTINUUM-926. -- Assignee: Emmanuel Venisse (was: Lester Ecarma) Resolution: Fixed Fix Version/s: 1.1 > Unable to disable a schedule > > > Key: CONTINUUM-926 > URL: http://jira.codehaus.org/browse/CONTINUUM-926 > Project: Continuum > Issue Type: Bug > Components: Core system >Affects Versions: 1.1 > Environment: acegi branch >Reporter: Carlos Sanchez > Assigned To: Emmanuel Venisse > Fix For: 1.1 > > > after unchecking the enabled box and saving next time i go to edit it's still > checked -- 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: (MECLIPSE-213) more jee support for wtp
[ http://jira.codehaus.org/browse/MECLIPSE-213?page=comments#action_84845 ] Richard van Nieuwenhoven commented on MECLIPSE-213: --- the idea to rename the project to the name with version name attached to it is realy very good. this solves a lot of troubles i have with the combination of maven with eclipse. when somebody needs it, i can sent an other patch to this pach that includes that setting! This makes project references a lot more simple to handle. - the manifest for eclipse could be done by the plexus-archiver now (open) this makes the generated artifacts of wtp more equal to the maven generated artifacts - the application.xml for eclipse could also be generated by the ear plugin (open) only the eclipse spesific ids must be added - it is now easy to have textual references to jar names in code, no more need for differences between eclipse-wtp and maven generated jar names. i must say that i vote for including the version into the name by default! > more jee support for wtp > > > Key: MECLIPSE-213 > URL: http://jira.codehaus.org/browse/MECLIPSE-213 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: WTP support >Affects Versions: 2.3 > Environment: linux suse 10.0 eclipse 3.2.1 and wtp 1.5.1 java 1.5.0_8 >Reporter: Richard van Nieuwenhoven > Attachments: maven-eclipse-plugin-R494407.patch > > > I tried the new release 2.3 of the eclipse plugin and noteted that not alle > of my paches where included. > I re-pached the 2.3 version again this time i made my changes configurable so > they can be turned on and off. > my changes: > - prohibit dupicate entries in the classpath > provided system paths in combination with log4j/commons-logging/xerces > can easely create such problems > - system paths are only included in ears and war when they are inside the > project >bether behavior would be to exclude all system paths because the war and > ear plugin also ignore these > - an application.xml specialy for eclipse-wtp >this makes wtp ears function correctly it includes the eclipse project > modules instead of the maven generated jars > - manifest generation for wtp >wtp needs manifest files, but not the ones maven creates because they have > version names for all modules etc >this generates a wtp manifest that will be in a ons eclipse source > directory that is ignored my maven itself > use the parameters -Declipse.wtpmanifest=true > -Declipse.wtpapplicationxml=true to acivate the patch. > The manifest generator could be combined with the RadManifestWriter in the > future, they are almost the same. > regards, > Ritchie -- 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-1322) Intellij 6.0.3 redistribution jars
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1322?page=comments#action_84847 ] Jerome Lacoste commented on MAVENUPLOAD-1322: - Forgot to say: I need this to update the ideauidesigner Mojo plugin. Thanks ! > Intellij 6.0.3 redistribution jars > -- > > Key: MAVENUPLOAD-1322 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1322 > Project: maven-upload-requests > Issue Type: Task >Reporter: Jerome Lacoste > Attachments: annotations-6.0.3-bundle.jar, forms_rt-6.0.3-bundle.jar, > javac2-6.0.3-bundle.jar > > > Intellij 5.0 and 5.1 jars are already distributed on ibiblio: > http://www.ibiblio.org/maven2/com/intellij/ > The poms are manually made and have been verified by compiling the sources > distributed with IDEA. Should I remove the section from the POM ? > > md5sum /usr/local/lib/idea-6.0.3/redist/*.jar > > /usr/local/lib/idea-6.0.3/redist/src/* > b5132ca1ac90701c0ae2622fe191c4b9 > /usr/local/lib/idea-6.0.3/redist/annotations.jar > dfed9d14de41952e73a4a87e47699271 > /usr/local/lib/idea-6.0.3/redist/forms_rt.jar > aeea1eb6fab86f4cdb5aa6aba4a5ae5c /usr/local/lib/idea-6.0.3/redist/javac2.jar > 6549d92828826d00e8fd1f1676d002d9 > /usr/local/lib/idea-6.0.3/redist/src/src_annotations.zip > de80928aeaebec995b8bd64ac84385eb > /usr/local/lib/idea-6.0.3/redist/src/src_forms_rt.zip > 3eba12d85a5ecb71f80e952be5e6017e > /usr/local/lib/idea-6.0.3/redist/src/src_javac2.zip > One can get IDEA from http://www.jetbrains.com/idea/download -- 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-1322) Intellij 6.0.3 redistribution jars
Intellij 6.0.3 redistribution jars -- Key: MAVENUPLOAD-1322 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1322 Project: maven-upload-requests Issue Type: Task Reporter: Jerome Lacoste Attachments: annotations-6.0.3-bundle.jar, forms_rt-6.0.3-bundle.jar, javac2-6.0.3-bundle.jar Intellij 5.0 and 5.1 jars are already distributed on ibiblio: http://www.ibiblio.org/maven2/com/intellij/ The poms are manually made and have been verified by compiling the sources distributed with IDEA. Should I remove the section from the POM ? > md5sum /usr/local/lib/idea-6.0.3/redist/*.jar > /usr/local/lib/idea-6.0.3/redist/src/* b5132ca1ac90701c0ae2622fe191c4b9 /usr/local/lib/idea-6.0.3/redist/annotations.jar dfed9d14de41952e73a4a87e47699271 /usr/local/lib/idea-6.0.3/redist/forms_rt.jar aeea1eb6fab86f4cdb5aa6aba4a5ae5c /usr/local/lib/idea-6.0.3/redist/javac2.jar 6549d92828826d00e8fd1f1676d002d9 /usr/local/lib/idea-6.0.3/redist/src/src_annotations.zip de80928aeaebec995b8bd64ac84385eb /usr/local/lib/idea-6.0.3/redist/src/src_forms_rt.zip 3eba12d85a5ecb71f80e952be5e6017e /usr/local/lib/idea-6.0.3/redist/src/src_javac2.zip One can get IDEA from http://www.jetbrains.com/idea/download -- 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: (MNG-2068) Multiple inheritance fails to find "grand" parent in ../../pom.xml when the groupIds differ (Test Case Attached)
[ http://jira.codehaus.org/browse/MNG-2068?page=all ] Brian Fox reopened MNG-2068: new test cases attached. > Multiple inheritance fails to find "grand" parent in ../../pom.xml when the > groupIds differ (Test Case Attached) > > > Key: MNG-2068 > URL: http://jira.codehaus.org/browse/MNG-2068 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.2 >Reporter: Brian Fox > Assigned To: John Casey >Priority: Critical > Fix For: 2.0.3 > > Attachments: good-sample.zip, mavenbugreport.zip, sample.zip > > > I have a project that inherits from 2 (or more) parents. If the grand parent > (parent of my parent) isn't in the repository, it isn't found at ../../pom.xml > In my sample, make sure none of the artifacts are in your repository, then go > down to sample-jar and try to build from there. See it fail. > Note: If you remove the ".sub" from the second parent's group and update the > sampe-jar pom, it no longer fails and finds the grandparent. > See below for the output when the groups are different (fails) and when they > are the same (works) > Failing output: > E:\sample\sample\sample-parent2\sample-jar>mvn -X compile > + Error stacktraces are turned on. > [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and > Settin > gs\brianf\.m2\plugin-registry.xml' > [DEBUG] Building Maven global-level plugin registry from: > 'c:\PROGRA~1\MAVEN-~1. > 2\bin\..\conf\plugin-registry.xml' > [INFO] Scanning for projects... > [DEBUG] Using parent-POM from the project hierarchy at: '../pom.xml' for > project > : null:sample-jar:jar:null > [DEBUG] Invalid parent-POM referenced by relative path '../pom.xml' in parent > sp > ecification in null:sample-parent2:pom:null: > Specified: sample-project.sub:sample-parent::SNAPSHOT > Found: sample-project:sample-parent:pom:SNAPSHOT > [DEBUG] Retrieving parent-POM from the repository for project: > null:sample-paren > t2:pom:null > [DEBUG] Skipping disabled repository central > [DEBUG] sample-parent: using locally installed snapshot > [DEBUG] Trying repository sv1-int > Downloading: > http://sv1.tus.stchome.com:9998/repository/sample-project/sub/sampl > e-parent/SNAPSHOT/sample-parent-SNAPSHOT.pom > [WARNING] Unable to get resource from repository sv1-int > (http://sv1.tus.stchome > .com:9998/repository) > [DEBUG] Trying repository Maven Snapshots > Downloading: > http://snapshots.maven.codehaus.org/maven2//sample-project/sub/samp > le-parent/SNAPSHOT/sample-parent-SNAPSHOT.pom > [WARNING] Unable to get resource from repository Maven Snapshots > (http://snapsho > ts.maven.codehaus.org/maven2/) > [DEBUG] Skipping disabled repository central > [INFO] > - > --- > [ERROR] FATAL ERROR > [INFO] > - > --- > [INFO] Failed to resolve artifact. > GroupId: sample-project.sub > ArtifactId: sample-parent > Version: SNAPSHOT > Reason: Unable to download the artifact from any repository > sample-project.sub:sample-parent:pom:SNAPSHOT > OUTPUT WITHOUT .sub: > E:\sample\sample\sample-parent2\sample-jar>mvn -X compile > + Error stacktraces are turned on. > [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and > Settin > gs\brianf\.m2\plugin-registry.xml' > [DEBUG] Building Maven global-level plugin registry from: > 'c:\PROGRA~1\MAVEN-~1. > 2\bin\..\conf\plugin-registry.xml' > [INFO] Scanning for projects... > [DEBUG] Using parent-POM from the project hierarchy at: '../pom.xml' for > project > : null:sample-jar:jar:null > [DEBUG] Using parent-POM from the project hierarchy at: '../pom.xml' for > project > : null:sample-parent2:pom:null > [INFO] > - > --- > [INFO] Building Maven Quick Start Archetype > [INFO]task-segment: [compile] > [INFO] > - > --- > [DEBUG] maven-resources-plugin: resolved to version 2.1 from repository > central > [DEBUG] Retrieving parent-POM from the repository for project: > null:maven-resour -- 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-2068) Multiple inheritance fails to find "grand" parent in ../../pom.xml when the groupIds differ (Test Case Attached)
[ http://jira.codehaus.org/browse/MNG-2068?page=all ] Brian Fox updated MNG-2068: --- Affects Version/s: (was: 2.0.2) 2.0.4 Fix Version/s: (was: 2.0.3) 2.0.x > Multiple inheritance fails to find "grand" parent in ../../pom.xml when the > groupIds differ (Test Case Attached) > > > Key: MNG-2068 > URL: http://jira.codehaus.org/browse/MNG-2068 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.4 >Reporter: Brian Fox > Assigned To: John Casey >Priority: Critical > Fix For: 2.0.x > > Attachments: good-sample.zip, mavenbugreport.zip, sample.zip > > > I have a project that inherits from 2 (or more) parents. If the grand parent > (parent of my parent) isn't in the repository, it isn't found at ../../pom.xml > In my sample, make sure none of the artifacts are in your repository, then go > down to sample-jar and try to build from there. See it fail. > Note: If you remove the ".sub" from the second parent's group and update the > sampe-jar pom, it no longer fails and finds the grandparent. > See below for the output when the groups are different (fails) and when they > are the same (works) > Failing output: > E:\sample\sample\sample-parent2\sample-jar>mvn -X compile > + Error stacktraces are turned on. > [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and > Settin > gs\brianf\.m2\plugin-registry.xml' > [DEBUG] Building Maven global-level plugin registry from: > 'c:\PROGRA~1\MAVEN-~1. > 2\bin\..\conf\plugin-registry.xml' > [INFO] Scanning for projects... > [DEBUG] Using parent-POM from the project hierarchy at: '../pom.xml' for > project > : null:sample-jar:jar:null > [DEBUG] Invalid parent-POM referenced by relative path '../pom.xml' in parent > sp > ecification in null:sample-parent2:pom:null: > Specified: sample-project.sub:sample-parent::SNAPSHOT > Found: sample-project:sample-parent:pom:SNAPSHOT > [DEBUG] Retrieving parent-POM from the repository for project: > null:sample-paren > t2:pom:null > [DEBUG] Skipping disabled repository central > [DEBUG] sample-parent: using locally installed snapshot > [DEBUG] Trying repository sv1-int > Downloading: > http://sv1.tus.stchome.com:9998/repository/sample-project/sub/sampl > e-parent/SNAPSHOT/sample-parent-SNAPSHOT.pom > [WARNING] Unable to get resource from repository sv1-int > (http://sv1.tus.stchome > .com:9998/repository) > [DEBUG] Trying repository Maven Snapshots > Downloading: > http://snapshots.maven.codehaus.org/maven2//sample-project/sub/samp > le-parent/SNAPSHOT/sample-parent-SNAPSHOT.pom > [WARNING] Unable to get resource from repository Maven Snapshots > (http://snapsho > ts.maven.codehaus.org/maven2/) > [DEBUG] Skipping disabled repository central > [INFO] > - > --- > [ERROR] FATAL ERROR > [INFO] > - > --- > [INFO] Failed to resolve artifact. > GroupId: sample-project.sub > ArtifactId: sample-parent > Version: SNAPSHOT > Reason: Unable to download the artifact from any repository > sample-project.sub:sample-parent:pom:SNAPSHOT > OUTPUT WITHOUT .sub: > E:\sample\sample\sample-parent2\sample-jar>mvn -X compile > + Error stacktraces are turned on. > [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and > Settin > gs\brianf\.m2\plugin-registry.xml' > [DEBUG] Building Maven global-level plugin registry from: > 'c:\PROGRA~1\MAVEN-~1. > 2\bin\..\conf\plugin-registry.xml' > [INFO] Scanning for projects... > [DEBUG] Using parent-POM from the project hierarchy at: '../pom.xml' for > project > : null:sample-jar:jar:null > [DEBUG] Using parent-POM from the project hierarchy at: '../pom.xml' for > project > : null:sample-parent2:pom:null > [INFO] > - > --- > [INFO] Building Maven Quick Start Archetype > [INFO]task-segment: [compile] > [INFO] > - > --- > [DEBUG] maven-resources-plugin: resolved to version 2.1 from repository > central > [DEBUG] Retrieving parent-POM from the repository for project: > null:maven-resour -- 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-2760) Fix deployment so that assemblies are signed with the GPG plugin
Fix deployment so that assemblies are signed with the GPG plugin Key: MNG-2760 URL: http://jira.codehaus.org/browse/MNG-2760 Project: Maven 2 Issue Type: Bug Components: Deployment Reporter: Jason van Zyl Fix For: 2.0.6 Currenty, the attached assemblies are not signed. -- 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-2760) Fix deployment so that assemblies are signed with the GPG plugin
[ http://jira.codehaus.org/browse/MNG-2760?page=all ] Jason van Zyl updated MNG-2760: --- Fix Version/s: 2.0.6 > Fix deployment so that assemblies are signed with the GPG plugin > > > Key: MNG-2760 > URL: http://jira.codehaus.org/browse/MNG-2760 > Project: Maven 2 > Issue Type: Bug > Components: Deployment >Reporter: Jason van Zyl > Assigned To: Jason van Zyl > Fix For: 2.0.6 > > > Currenty, the attached assemblies are not signed. -- 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: (MPHIBERNATE-9) plugin:test fails without a network connection
[ http://jira.codehaus.org/browse/MPHIBERNATE-9?page=comments#action_84861 ] John Hogan commented on MPHIBERNATE-9: -- This same bug is back in Maven 2. Things like hibernate do not work in offline mode because of attempted dtd resolution at hibernate.sourceforge.net, ughh > plugin:test fails without a network connection > -- > > Key: MPHIBERNATE-9 > URL: http://jira.codehaus.org/browse/MPHIBERNATE-9 > Project: maven-hibernate-plugin > Issue Type: Bug >Reporter: dion gillard > Assigned To: David Eric Pugh >Priority: Minor > Fix For: 1.3 > > > hibernate:aggregate-mappings: > [echo] Aggregating multiple hibernate mapping into one single file > Adding base dir: > C:\source\maven-plugins\hibernate\src\plugin-test\target\classes > Adding base dir: C:\source\maven-plugins\hibernate\src\plugin-test\src\etc > Aggregating to > C:\source\maven-plugins\hibernate\src\plugin-test/target/schema/aggregated-mappings.hbm.xml > BUILD FAILED > File.. C:\Documents and Settings\Dion > Gillard\.maven\cache\maven-plugin-plugin-1.5.2-SNAPSHOT\plugin.jelly > Element... maven:maven > Line.. 314 > Column 34 > Unable to obtain goal [test-hibernate-aggregate-mappings] -- C:\Documents and > Settings\Dion Gillard\.maven\cache\maven-hibernate-plu > gin-1.2-SNAPSHOT\plugin.jelly:38:53: Mapping > aggreagtion failed: hibernate.sourceforge.net Nested exception: > hibernate.sourceforge.net > Total time: 5 seconds > Finished at: Mon Jul 19 01:28:37 EST 2004 > If I have a net connection, all is fine. -- 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-215) WTP 1.5 Documentation
WTP 1.5 Documentation - Key: MECLIPSE-215 URL: http://jira.codehaus.org/browse/MECLIPSE-215 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: WTP support Affects Versions: 2.3 Reporter: Shelley L Priority: Minor The maven-eclipse-plugin mojo documentation should be updated to mention WTP 1.5 support. Currently, the wtpversion parameter description states that the only supported versions are "R7" and "1.0." http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.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: (MIDEA-54) Fixed range versions in dependencies corrupt the module file
[ http://jira.codehaus.org/browse/MIDEA-54?page=comments#action_84862 ]
Dennis Lundberg commented on MIDEA-54:
--
It's closed with the "Resolution" set to "Duplicate". That means that there is
another issue in JIRA for the same problem. The other issue - MIDEA-57 - is
used to track the issue instead of this one.
> Fixed range versions in dependencies corrupt the module file
>
>
> Key: MIDEA-54
> URL: http://jira.codehaus.org/browse/MIDEA-54
> Project: Maven 2.x Idea Plugin
> Issue Type: Bug
> Environment: maven 2.0.4, plugin snapshot built from svn
>Reporter: Andrew Perepelytsya
>
> I have the following config snippet declared in pom.xml:
> {code}
>
> xerces
> xercesImpl
>
> [2.8.0]
>
> {code}
> Note those *square brackets*, this works ok with Maven letting it sort of fix
> the 2.8.0 version. Now it seemed to be fine when I initially generated
> idea:idea project (dependency was at 2.6.2 version then). Recently it has
> been upgraded, and I went back to re-generate the core module via
> idea:module. The error I got:
> {panel}
> [WARNING] An error occurred during dependency resolution of the following
> artifact:
> org.codehaus.mule:mule-core2.0-SNAPSHOT
> Caused by: Missing:
> --
> 1) xerces:xercesImpl:jar:[2.8.0]
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=xerces -DartifactId=xercesImpl \
> -Dversion=[2.8.0] -Dpackaging=jar -Dfile=/path/to/file
> Path to dependency:
> 1) org.codehaus.mule:mule-core:jar:2.0-SNAPSHOT
> 2) xerces:xercesImpl:jar:[2.8.0]
> --
> 1 required artifact is missing.
> {panel}
> The generated iml file had *all libraries removed*.
--
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-2456) Maven Archiver creates incorrect Class-Path entry in Manifest for deployed snapshots
[ http://jira.codehaus.org/browse/MNG-2456?page=comments#action_84865 ]
Christian Goetze commented on MNG-2456:
---
I would like to see a fix that does not involve adding extra configuration
items to the assembly... whatever happened to "convention instead of
configuration" - and yes, the onus is on -you- to determine which behaviour
should be "standard"...
> Maven Archiver creates incorrect Class-Path entry in Manifest for deployed
> snapshots
>
>
> Key: MNG-2456
> URL: http://jira.codehaus.org/browse/MNG-2456
> Project: Maven 2
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: 2.0.4
>Reporter: Baerrach bonDierne
> Assigned To: Kenney Westerhof
> Attachments: MNG-2456-maxb.patch, MNG-2456-patch.txt,
> MNG-2456-step1-refactoring-patch.txt,
> MNG-2456-step2-add-test-cases-patch.txt, MNG-2456-step3-fix-bug-patch.txt
>
>
> See related problems MJAR-28 and MASSEMBLY-67.
> Summary:
> The Maven-Archiver uses the file part of the artifact's filename to create
> the Class-Path entries in the Manifest.
> This works fine for released artifacts and non-deployed snapshot.
> The problem occurs when using a deployed snapshot as the assembly plugin will
> copy the dependency as ${artifactId}-${version}-timestampedversion.jar and
> the entry in the Class-Path will be ${artifactId}-${version}-SNAPSHOT
> thus use of java -jar will fail because of the differing names.
--
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-1323) Please upload EZMorph-1.0
Please upload EZMorph-1.0 - Key: MAVENUPLOAD-1323 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1323 Project: maven-upload-requests Issue Type: Task Reporter: Andres Almiray EZMorph is simple java library for transforming an Object to another Object. -- 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: (SCM-270) scm:update does not set revisionKey/scm.property
[ http://jira.codehaus.org/browse/SCM-270?page=comments#action_84869 ]
Bernd commented on SCM-270:
---
This is the output from the command line:
D:\xx\>svn --username maven --non-interactive update
Revision 380.
org.apache.maven.scm.provider.svn.svnexe.command.update.SvnUpdateConsumer
contains
private static final String AT_REVISION_TOKEN = "At revision";
..
else if ( line.startsWith( AT_REVISION_TOKEN ) )
{
String revisionString = line.substring( AT_REVISION_TOKEN.length()
+ 1, line.length() - 1 );
revision = parseInt( revisionString );
so line.startsWith( AT_REVISION_TOKEN ) ) most likely does not compare
sucessfully.
> scm:update does not set revisionKey/scm.property
>
>
> Key: SCM-270
> URL: http://jira.codehaus.org/browse/SCM-270
> Project: Maven SCM
> Issue Type: Bug
>Affects Versions: 1.0-beta-3
> Environment: Windows XP, Java(TM) 2 Runtime Environment, Standard
> Edition (build 1.5.0_10-b03),
>Reporter: Bernd
>
> Using
>
> org.apache.maven.plugins
> maven-scm-plugin
>
>
> validate
> getting-scm.revision
>
> update
>
>
>
>
> as suggested on the user list results in
> [INFO] [scm:update {execution: getting-scm.revision}]
> [INFO] Executing: svn --username maven --non-interactive update
> [INFO] Working directory: D:\projekte\template\templatePom-trunk
> [DEBUG] Revision 375.
> [INFO] Unknown file status: 'R' in line Revision 375..
> [INFO] Storing revision in 'scm.revision' project property.
> This does not result in rev. 375 being replaced in filtered files.
> Actual result is that the content of scm.revision is "0"
> The filtered file looks like
> xyz=0
> instead of the expteced
> xyz=375
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1324) please upload new version of vafer.org dependency
please upload new version of vafer.org dependency - Key: MAVENUPLOAD-1324 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1324 Project: maven-upload-requests Issue Type: Task Reporter: Torsten Curdt please new release need it for the mojo minijar release -- 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-2762) warning during tar unpackaging
warning during tar unpackaging -- Key: MNG-2762 URL: http://jira.codehaus.org/browse/MNG-2762 Project: Maven 2 Issue Type: Bug Components: Bootstrap & Build Reporter: Tomasz Pik Priority: Minor Using tar distribution, during upackaging I'm getting: tar: A lone zero block at 4174 warning message in output. Archive is being untarred correctly but this message may worry users that archive is corrupted -- 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: (SCM-270) scm:update does not set revisionKey/scm.property
[ http://jira.codehaus.org/browse/SCM-270?page=comments#action_84879 ]
Bernd commented on SCM-270:
---
could it be that this is a more general issue with my german svn installation:
Running
org.apache.maven.scm.provider.svn.svnexe.command.status.SvnExeStatusCommandTckTest
Test command line: svnadmin create repository
[INFO] Executing: svn --non-interactive checkout
file:///D:/maven/maven-scm-provider-svnexe/target/scm-test/repository/trunk
working-copy
[INFO] Working directory: D:\maven\maven-scm-provider-svnexe\target\scm-test
[INFO] Executing: svn --non-interactive checkout
file:///D:/maven/maven-scm-provider-svnexe/target/scm-test/repository/trunk
updating-copy
[INFO] Working directory: D:\maven\maven-scm-provider-svnexe\target\scm-test
[INFO] Executing: svn add --non-recursive project.xml
[INFO] Working directory:
D:\maven\maven-scm-provider-svnexe\target\scm-test\working-copy
[INFO] Executing: svn --non-interactive commit --file
C:\DOKUME~1\bep\LOKALE~1\Temp\maven-scm-1299438067.commit
[INFO] Working directory:
D:\maven\maven-scm-provider-svnexe\target\scm-test\working-copy
[INFO] Unknown line: 'Hinzuf?gen project.xml'
[INFO] Unknown line: 'Sende readme.txt'
[INFO] Unknown line: 'Übertrage Daten ..'
[INFO] Unknown line: 'Revision 9 ?bertragen.'
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.886 sec <<<
FAILURE!
> scm:update does not set revisionKey/scm.property
>
>
> Key: SCM-270
> URL: http://jira.codehaus.org/browse/SCM-270
> Project: Maven SCM
> Issue Type: Bug
>Affects Versions: 1.0-beta-3
> Environment: Windows XP, Java(TM) 2 Runtime Environment, Standard
> Edition (build 1.5.0_10-b03),
>Reporter: Bernd
>
> Using
>
> org.apache.maven.plugins
> maven-scm-plugin
>
>
> validate
> getting-scm.revision
>
> update
>
>
>
>
> as suggested on the user list results in
> [INFO] [scm:update {execution: getting-scm.revision}]
> [INFO] Executing: svn --username maven --non-interactive update
> [INFO] Working directory: D:\projekte\template\templatePom-trunk
> [DEBUG] Revision 375.
> [INFO] Unknown file status: 'R' in line Revision 375..
> [INFO] Storing revision in 'scm.revision' project property.
> This does not result in rev. 375 being replaced in filtered files.
> Actual result is that the content of scm.revision is "0"
> The filtered file looks like
> xyz=0
> instead of the expteced
> xyz=375
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-270) scm:update does not set revisionKey/scm.property
[ http://jira.codehaus.org/browse/SCM-270?page=comments#action_84882 ]
Bernd commented on SCM-270:
---
here is the stacktrace for
org.apache.maven.scm.provider.svn.svnexe.command.status.SvnExeStatusCommandTckTest
junit.framework.AssertionFailedError: Expected 2 files in the committed files
list [] expected:&2& but was:&0&
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:201)
at
org.apache.maven.scm.tck.command.status.StatusCommandTckTest.commit(StatusCommandTckTest.java:69)
at
org.apache.maven.scm.tck.command.status.StatusCommandTckTest.testStatusCommand(StatusCommandTckTest.java:97)
> scm:update does not set revisionKey/scm.property
>
>
> Key: SCM-270
> URL: http://jira.codehaus.org/browse/SCM-270
> Project: Maven SCM
> Issue Type: Bug
>Affects Versions: 1.0-beta-3
> Environment: Windows XP, Java(TM) 2 Runtime Environment, Standard
> Edition (build 1.5.0_10-b03),
>Reporter: Bernd
>
> Using
>
> org.apache.maven.plugins
> maven-scm-plugin
>
>
> validate
> getting-scm.revision
>
> update
>
>
>
>
> as suggested on the user list results in
> [INFO] [scm:update {execution: getting-scm.revision}]
> [INFO] Executing: svn --username maven --non-interactive update
> [INFO] Working directory: D:\projekte\template\templatePom-trunk
> [DEBUG] Revision 375.
> [INFO] Unknown file status: 'R' in line Revision 375..
> [INFO] Storing revision in 'scm.revision' project property.
> This does not result in rev. 375 being replaced in filtered files.
> Actual result is that the content of scm.revision is "0"
> The filtered file looks like
> xyz=0
> instead of the expteced
> xyz=375
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-270) scm:update does not set revisionKey/scm.property
[ http://jira.codehaus.org/browse/SCM-270?page=comments#action_84883 ]
Bernd commented on SCM-270:
---
Forcing my svn installation to english resolves the issue. It also makes the
tests pass.
> scm:update does not set revisionKey/scm.property
>
>
> Key: SCM-270
> URL: http://jira.codehaus.org/browse/SCM-270
> Project: Maven SCM
> Issue Type: Bug
>Affects Versions: 1.0-beta-3
> Environment: Windows XP, Java(TM) 2 Runtime Environment, Standard
> Edition (build 1.5.0_10-b03),
>Reporter: Bernd
>
> Using
>
> org.apache.maven.plugins
> maven-scm-plugin
>
>
> validate
> getting-scm.revision
>
> update
>
>
>
>
> as suggested on the user list results in
> [INFO] [scm:update {execution: getting-scm.revision}]
> [INFO] Executing: svn --username maven --non-interactive update
> [INFO] Working directory: D:\projekte\template\templatePom-trunk
> [DEBUG] Revision 375.
> [INFO] Unknown file status: 'R' in line Revision 375..
> [INFO] Storing revision in 'scm.revision' project property.
> This does not result in rev. 375 being replaced in filtered files.
> Actual result is that the content of scm.revision is "0"
> The filtered file looks like
> xyz=0
> instead of the expteced
> xyz=375
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MCOMPILER-48) Add maven.compile.failonerror equivalent functionality
[ http://jira.codehaus.org/browse/MCOMPILER-48?page=all ]
Carlos Sanchez closed MCOMPILER-48.
---
Assignee: Carlos Sanchez
Resolution: Fixed
Fix Version/s: 2.1
> Add maven.compile.failonerror equivalent functionality
> --
>
> Key: MCOMPILER-48
> URL: http://jira.codehaus.org/browse/MCOMPILER-48
> Project: Maven 2.x Compiler Plugin
> Issue Type: Improvement
>Reporter: Ben Alex
> Assigned To: Carlos Sanchez
>Priority: Critical
> Fix For: 2.1
>
> Attachments: compiler-failonerror-test.zip,
> compiler-failonerror-test.zip, patch.txt
>
>
> Maven 1.x's "java" plugin offered a maven.compile.failonerror property, which
> could be set false in order to skip compilation errors.
> I am working on a code generation framework that uses a Maven plugin. The
> mojo spawns a parallel lifecycle via @execute phase="test-compile", as the
> mojo itself is @phase generate-sources. This is necessary as the code
> generator needs to instantiate certain classes to obtain metadata. The nature
> of the generated types means that users might write code that depends on the
> generated types to already be compiled on the classpath, although this has
> not yet happened at this phase because the code generator requires compiled
> classes first. By the time the generated-sources phase completes and releases
> to the original lifecycle, the subsequent compilation will work as the
> generated sources are now available for compilation.
> In practice this issue is easily resolved if AbstractCompilerMojo supported
> the Maven 1 style maven.compile.failonerror = false property, which could be
> injected via the MavenProject class during the parallel lifecycle (and
> reverted upon completion). The relevant lines are:
> 504 if ( compilationError )
> 505 {
> 506 throw new CompilationFailureException( messages );
> 507 }
> 508 else
> 509 {
> 510 for ( Iterator i = messages.iterator(); i.hasNext(); )
> 511 {
> 512 CompilerError message = (CompilerError) i.next();
> 513
> 514 getLog().warn( message.toString() );
> 515 }
> 516 }
> Could you change line 504 to reference an injected property, so the exception
> can be consumed with simply a warning?
> At present I am planning on working around this issue by using exclude
> filters (excluding common filename patterns users are likely to generated
> dependent code for) but this is an inelegant solution by comparison with
> supporting the injected property. If there is another way to skip errors and
> I am not aware of it, would you please let me know. Thanks.
--
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: (MCOMPILER-47) Inhertitance does not work when having more than one level
[ http://jira.codehaus.org/browse/MCOMPILER-47?page=comments#action_84885 ] Carlos Sanchez commented on MCOMPILER-47: - "Each pom.xml correctly declare their parent pom.xml, ie mitosis depends on apacheds pom.xml, and apacheds depends on top-level pom.xml" you mean "extends" instead of "depends"? > Inhertitance does not work when having more than one level > -- > > Key: MCOMPILER-47 > URL: http://jira.codehaus.org/browse/MCOMPILER-47 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Reporter: Emmanuel Lécharny > > If trying to build some projects in a hierarchy which is more than one level > high, then the top level configuration is not correctly used. > Our project (Apache Directory Server) is structured this way : > > | > +--> apacheds > | >+--> mitosis (and any other subprojects) > When we try to compile the whole projet, we launch mvn install in the > top-level. For some unknown reason, if we don't put compilation directives in > the apacheds pom.xml (for instance, the jdk version to use), then mitosis > does not use the directive ut in the top-level pom.xml > Each pom.xml correctly declare their parent pom.xml, ie mitosis depends on > apacheds pom.xml, and apacheds depends on top-level 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: (MCOMPILER-46) JDK defaulting to 1.4
[ http://jira.codehaus.org/browse/MCOMPILER-46?page=comments#action_84886 ] Carlos Sanchez commented on MCOMPILER-46: - are you sure? if defaults to the specified in JAVA_HOME > JDK defaulting to 1.4 > - > > Key: MCOMPILER-46 > URL: http://jira.codehaus.org/browse/MCOMPILER-46 > Project: Maven 2.x Compiler Plugin > Issue Type: Improvement >Reporter: Emmanuel Lécharny >Priority: Minor > > When you declare a tags in which the tag is empty > (), the jdk version default to 1.4. > Wouldn't it be good - or at least better - to default to the JDK which has > been used to launch maven ? If a project really need a specific version of > JDK, then I bet the developper has correctly set the > parameters into the pom.xml, I think. -- 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: (MCOMPILER-44) 'outputDirectory' configuration property should not be read-only
[ http://jira.codehaus.org/browse/MCOMPILER-44?page=all ] Carlos Sanchez closed MCOMPILER-44. --- Assignee: Carlos Sanchez Resolution: Won't Fix > 'outputDirectory' configuration property should not be read-only > > > Key: MCOMPILER-44 > URL: http://jira.codehaus.org/browse/MCOMPILER-44 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 2.0.1 >Reporter: Ian Springer > Assigned To: Carlos Sanchez > > I am trying to set up a 'dev' build profile that, when enabled, will cause my > artifacts to be built directly to an exploded ejb-jar deployment dir, instead > of target/classes/. The purpose is to make the development process more > efficient by skipping a number of time-consuming intermediate mvn steps (i.e. > jarring the artifact, copying the jar to the local repo, unjarring the > artifact to its deploy/test location). > Since profiles do not allow you to override project.build.outputDirectory, I > proceeded to override the outputDirectory config props in the > maven-clean-plugin, the maven-compiler-plugin, and the > maven-resources-plugin. The maven-clean-plugin and the maven-resources-plugin > allow me to modify the outputDirectory without any complaints, but the > maven-compiler-plugin does not... It fails with the following error: > [INFO] Error configuring: org.apache.maven.plugins:maven-compiler-plugin. > Reason: ERROR: Cannot override read-only parameter: outputDirectory in goal: > compiler:compile > Please make this property non-read-only. Making it read-only seriously limits > the flexibility of Maven2. > Thanks, > Ian -- 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-2763) Fix it0051 in trunk
Fix it0051 in trunk --- Key: MNG-2763 URL: http://jira.codehaus.org/browse/MNG-2763 Project: Maven 2 Issue Type: Bug Affects Versions: 2.1-alpha-1 Reporter: Jason van Zyl Fix For: 2.1-alpha-1 This is a Plexus/ClassWorlds problem causing the JavaDoc plugin to fail. -- 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-2763) Fix it0051 in trunk
[ http://jira.codehaus.org/browse/MNG-2763?page=all ] Jason van Zyl updated MNG-2763: --- Affects Version/s: (was: 2.1-alpha-1) 2.1.x Fix Version/s: 2.1-alpha-1 > Fix it0051 in trunk > --- > > Key: MNG-2763 > URL: http://jira.codehaus.org/browse/MNG-2763 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.1.x >Reporter: Jason van Zyl > Assigned To: Jason van Zyl > Fix For: 2.1-alpha-1 > > > This is a Plexus/ClassWorlds problem causing the JavaDoc plugin to fail. -- 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-2764) Refactor MavenProjectBuilder
Refactor MavenProjectBuilder Key: MNG-2764 URL: http://jira.codehaus.org/browse/MNG-2764 Project: Maven 2 Issue Type: Task Affects Versions: 2.1.x Reporter: Jason van Zyl Fix For: 2.1-alpha-1 This beast needed to be broken down and turned into a series of phases using smaller components. -- 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-2764) Refactor MavenProjectBuilder
[ http://jira.codehaus.org/browse/MNG-2764?page=all ] Jason van Zyl updated MNG-2764: --- Fix Version/s: 2.1-alpha-1 > Refactor MavenProjectBuilder > > > Key: MNG-2764 > URL: http://jira.codehaus.org/browse/MNG-2764 > Project: Maven 2 > Issue Type: Task >Affects Versions: 2.1.x >Reporter: Jason van Zyl > Fix For: 2.1-alpha-1 > > > This beast needed to be broken down and turned into a series of phases using > smaller components. -- 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-2765) Refactor DefaultPluginManager
Refactor DefaultPluginManager - Key: MNG-2765 URL: http://jira.codehaus.org/browse/MNG-2765 Project: Maven 2 Issue Type: Task Affects Versions: 2.1.x Reporter: Jason van Zyl Fix For: 2.1-alpha-1 This beast needed to be broken down and the call graph simplified. We could also create a lookup( role[-hint], configuration ) in plexus to keep from exposing configurators. -- 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-2765) Refactor DefaultPluginManager
[ http://jira.codehaus.org/browse/MNG-2765?page=all ] Jason van Zyl updated MNG-2765: --- Fix Version/s: 2.1-alpha-1 > Refactor DefaultPluginManager > - > > Key: MNG-2765 > URL: http://jira.codehaus.org/browse/MNG-2765 > Project: Maven 2 > Issue Type: Task >Affects Versions: 2.1.x >Reporter: Jason van Zyl > Fix For: 2.1-alpha-1 > > > This beast needed to be broken down and the call graph simplified. We could > also create a lookup( role[-hint], configuration ) in plexus to keep from > exposing configurators. -- 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-2766) Refactor DefaultLifecycleExecutor
Refactor DefaultLifecycleExecutor - Key: MNG-2766 URL: http://jira.codehaus.org/browse/MNG-2766 Project: Maven 2 Issue Type: Task Affects Versions: 2.1.x Reporter: Jason van Zyl Fix For: 2.1-alpha-1 Another large beast that needs to be broken up. -- 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-2766) Refactor DefaultLifecycleExecutor
[ http://jira.codehaus.org/browse/MNG-2766?page=all ] Jason van Zyl updated MNG-2766: --- Fix Version/s: 2.1-alpha-1 > Refactor DefaultLifecycleExecutor > - > > Key: MNG-2766 > URL: http://jira.codehaus.org/browse/MNG-2766 > Project: Maven 2 > Issue Type: Task >Affects Versions: 2.1.x >Reporter: Jason van Zyl > Fix For: 2.1-alpha-1 > > > Another large beast that needs to be broken up. -- 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-2753) trunk needs to support passing system properties and environment variables through the CLI into the embedder
[ http://jira.codehaus.org/browse/MNG-2753?page=all ] Jason van Zyl updated MNG-2753: --- Affects Version/s: (was: 2.1) 2.1.x Fix Version/s: (was: 2.1.x) 2.1-alpha-1 > trunk needs to support passing system properties and environment variables > through the CLI into the embedder > > > Key: MNG-2753 > URL: http://jira.codehaus.org/browse/MNG-2753 > Project: Maven 2 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.1.x >Reporter: Brett Porter > Assigned To: Jason van Zyl >Priority: Blocker > Fix For: 2.1-alpha-1 > > > handling was wisely removed from maven-project itself, but for backwards > compatibility we need to still support the population of properties from > system properties and environment variables at the CLI level. These variables > should be passed in to the embedder. -- 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-2767) Use MiniJAR to crush the final assembly down and munge package dependencies
Use MiniJAR to crush the final assembly down and munge package dependencies --- Key: MNG-2767 URL: http://jira.codehaus.org/browse/MNG-2767 Project: Maven 2 Issue Type: Improvement Affects Versions: 2.1.x Reporter: Jason van Zyl Fix For: 2.1-alpha-1 This would reduce the size of the final assembly and munge the use of any util code like plexus utils so that plugins will never be stuck using the same version that is used as a core dependency. -- 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-2767) Use MiniJAR to crush the final assembly down and munge package dependencies
[ http://jira.codehaus.org/browse/MNG-2767?page=all ] Jason van Zyl updated MNG-2767: --- Fix Version/s: 2.1-alpha-1 > Use MiniJAR to crush the final assembly down and munge package dependencies > --- > > Key: MNG-2767 > URL: http://jira.codehaus.org/browse/MNG-2767 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.1.x >Reporter: Jason van Zyl > Fix For: 2.1-alpha-1 > > > This would reduce the size of the final assembly and munge the use of any > util code like plexus utils so that plugins will never be stuck using the > same version that is used as a core dependency. -- 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-1436) Unable to load maven-model-2.0-all from a plugin
[ http://jira.codehaus.org/browse/MNG-1436?page=all ] Jason van Zyl updated MNG-1436: --- Affects Version/s: (was: 2.0) Fix Version/s: (was: 2.1.x) > Unable to load maven-model-2.0-all from a plugin > > > Key: MNG-1436 > URL: http://jira.codehaus.org/browse/MNG-1436 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Reporter: fabrizio giustina >Priority: Critical > > The org.apache.maven:maven-model artifact is available with the "all" > classifier in the maven repo. The "all" version also contains project v3 > classes and reader/writer. > Adding a dependency with: > > org.apache.maven > maven-model > 2.0 > jar > all > > let you use project 3 classes in a plugin and install successfully. > However, when running the plugin, the maven-model-2.0-all artifact seems to > be ignored and replaced by the version in m2/lib _also if the classifier is > different_. > This is the debug log from an execution of a plugin that uses this dependency: > [INFO] Searching repository for plugin with prefix: 'maven1'. > [DEBUG] maven-maven1-plugin: using locally installed snapshot > [DEBUG] maven-maven1-plugin: using locally installed snapshot > [DEBUG] > org.apache.maven.plugins:maven-maven1-plugin:maven-plugin:2.0-SNAPSHOT > (selected for runtime) > [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for runtime) > [DEBUG] Retrieving parent-POM from the repository for project: > org.apache.maven:maven-model:jar:2.0 > [DEBUG] org.apache.maven:maven-model:jar:all:2.0 (selected for runtime) > [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for runtime) > [DEBUG] dom4j:dom4j:jar:1.4 (selected for runtime) > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-maven1-plugin:2.0-SNAPSHOT:convert' --> > [DEBUG] (f) basedir = \testconvert > [DEBUG] -- end configuration -- > [INFO] [1:convert] > [WARNING] pom.xml in \testconvert already exists, overwriting > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] org/apache/maven/model/v3_0_0/io/xpp3/MavenXpp3Reader > [INFO] > > [DEBUG] Trace > java.lang.NoClassDefFoundError: > org/apache/maven/model/v3_0_0/io/xpp3/MavenXpp3Reader > At the moment this makes impossible to use pom v.3 in mvn. > Apart from the classifier issue that could be solved in a future m2 release, > I would like to find out a workaroud in order to use v3 poms for a mvn plugin > that could automatically convert maven 1 project.xml to mvn pom.xml for > making migration from maven 1 easier. > The current options I can think at are: > - embedding the org.apache.maven.model.v3_0_0.* classes in the plugin > - releasing maven-model-2.0-all with a different artifactId > (maven-model-all-2.0 or maven-model-v3-2.0) > thoughts? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-1943) MavenProject::getParent() returns a MavenProject that is NOT interpolated
[ http://jira.codehaus.org/browse/MNG-1943?page=all ]
Jason van Zyl updated MNG-1943:
---
Component/s: Inheritance and Interpolation
> 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
> Components: Inheritance and Interpolation
>Reporter: John Allen
>Priority: Blocker
> Fix For: 2.1.x
>
>
> 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] Updated: (MNG-1117) MavenEmbedder.writeModel( w, model) should allow to preserve xml formatting
[ http://jira.codehaus.org/browse/MNG-1117?page=all ] Jason van Zyl updated MNG-1117: --- Fix Version/s: (was: 2.1.x) 2.1-alpha-1 > MavenEmbedder.writeModel( w, model) should allow to preserve xml formatting > --- > > Key: MNG-1117 > URL: http://jira.codehaus.org/browse/MNG-1117 > Project: Maven 2 > Issue Type: Improvement > Components: Embedding >Reporter: Eugene Kuleshov > Assigned To: Jason van Zyl >Priority: Critical > Fix For: 2.1-alpha-1 > > > Currently MavenEmbedder.writeModel( w, model) method does not take into > account formatting of the existing pom.xml. This is critical limitation from > an end-user prospective. -- 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: (WAGON-68) Separate the interfaces for GET vs PUT
Separate the interfaces for GET vs PUT -- Key: WAGON-68 URL: http://jira.codehaus.org/browse/WAGON-68 Project: wagon Issue Type: New Feature Components: wagon-provider-api Affects Versions: 1.0-beta-2 Reporter: Jason van Zyl There are cases where I could see simply wanting the GET aspect of a Wagon. Two cases come to mind: a Grizzly wagon for high-speed GETs from a Jetty instance running the Grizzly connector; a BT client that would just be doing GETs. So maybe we could keep the original interfaces and add WagonRetriever/Getter and WagonPublisher/Putter. -- 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: (MEV-487) Xalan and hsqldb versions outdated
[ http://jira.codehaus.org/browse/MEV-487?page=all ] Carlos Sanchez closed MEV-487. -- Assignee: Carlos Sanchez Resolution: Won't Fix > Xalan and hsqldb versions outdated > -- > > Key: MEV-487 > URL: http://jira.codehaus.org/browse/MEV-487 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Mikko Wuokko > Assigned To: Carlos Sanchez > Attachments: xalan-hsqldb-dependency.patch > > > Xalan seems to use now x.x.x type of version so 2.4 -> 2.4.0. > I couldn find from the main Maven2 repos hsqldb of version 1.8.0, but there > are 1.8.0.1, 1.8.0.4, 1.8.0.5 and 1.8.0.1.7 versions. > Another thing I noticed is that the jar file for jdo 1.0.1 or neither the jar > or the pom files could not be found for jdori for any version. Don't know how > to handle that. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1323) Please upload EZMorph-1.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1323?page=all ] Carlos Sanchez closed MAVENUPLOAD-1323. --- Assignee: Carlos Sanchez Resolution: Fixed > Please upload EZMorph-1.0 > - > > Key: MAVENUPLOAD-1323 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1323 > 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. -- 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-1324) please upload new version of vafer.org dependency
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1324?page=all ] Carlos Sanchez closed MAVENUPLOAD-1324. --- Assignee: Carlos Sanchez Resolution: Fixed > please upload new version of vafer.org dependency > - > > Key: MAVENUPLOAD-1324 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1324 > Project: maven-upload-requests > Issue Type: Task >Reporter: Torsten Curdt > Assigned To: Carlos Sanchez > > please new release need it for the mojo minijar release -- 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-1321) jawin
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1321?page=comments#action_84897 ] Carlos Sanchez commented on MAVENUPLOAD-1321: - Check the instructions http://maven.apache.org/guides/mini/guide-central-repository-upload.html > jawin > - > > Key: MAVENUPLOAD-1321 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1321 > Project: maven-upload-requests > Issue Type: New Feature >Reporter: Anna Alekseevna Nejentseva > Attachments: jawin.jar, 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-1320) Javassist 3.1 upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1320?page=comments#action_84898 ] Carlos Sanchez commented on MAVENUPLOAD-1320: - groupId has to be jboss, other versions are there > Javassist 3.1 upload request > > > Key: MAVENUPLOAD-1320 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1320 > Project: maven-upload-requests > Issue Type: Task >Reporter: Hugo Palma > > Simple Java bytecode manipulation -- 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-1318) Please upload DWR 2.0.rc2 to maven repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1318?page=all ] Carlos Sanchez closed MAVENUPLOAD-1318. --- Assignee: Carlos Sanchez Resolution: Fixed > Please upload DWR 2.0.rc2 to maven repo > --- > > Key: MAVENUPLOAD-1318 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1318 > Project: maven-upload-requests > Issue Type: Task >Reporter: Brendan Grainger > Assigned To: Carlos Sanchez > Attachments: dwr-2.0.rc2-bundle.jar > > > Hi, > Please upload dwr 2.0.rc2 to ibiblio. DWR2 (rc1) has been uploaded > previously. I've attached the bundle and it is also available on the project > page at java.net. Please let me know if there are any issues. > Regards > Brendan Grainger -- 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-1317) SweetXML 0.2 bundles ready for repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1317?page=all ] Carlos Sanchez closed MAVENUPLOAD-1317. --- Assignee: Carlos Sanchez Resolution: Fixed > SweetXML 0.2 bundles ready for repository > - > > Key: MAVENUPLOAD-1317 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1317 > Project: maven-upload-requests > Issue Type: Task >Reporter: Paul Cantrell > Assigned To: Carlos Sanchez > > http://innig.net/tmp/maven-sweetxml-bundles-0.2/sweetxml-parent-pom-0.2-bundle.jar > http://innig.net/tmp/maven-sweetxml-bundles-0.2/sweetxml-0.2-bundle.jar > http://innig.net/tmp/maven-sweetxml-bundles-0.2/sweetxml-ant-0.2-bundle.jar > http://innig.net/tmp/maven-sweetxml-bundles-0.2/sweetxml-maven-0.2-bundle.jar > http://innig.net/software/sweetxml/ > http://innig.net/software/sweetxml/faq.html#who > The project has three modules, all of which inherit from a project-wide > parent POM. My understanding is that I have to release the parent POM as a > separate fourth artifact, so I have bundled it in its own jar. (I did this > manually, since repository:bundle-create doesn't work when the packaging type > is "pom".) If this is incorrect, or if there is a better way to handle this, > please let me know and I will recreate the bundles. -- 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-1316) upload vraptor 2.3.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1316?page=all ] Carlos Sanchez closed MAVENUPLOAD-1316. --- Assignee: Carlos Sanchez Resolution: Fixed > upload vraptor 2.3.1 > > > Key: MAVENUPLOAD-1316 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1316 > Project: maven-upload-requests > Issue Type: Task >Reporter: Nico Steppat > Assigned To: Carlos Sanchez > > VRaptor 2.3.1 comes with minor changes, bug fixes and a site updated. > > VRaptor 2 is a mvc controller based on the idea (stolen) from Rails that > configuration should be minimal and conventions should be maximized. > -- 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-1315) Upload antlr-3.0b5
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1315?page=all ] Carlos Sanchez closed MAVENUPLOAD-1315. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload antlr-3.0b5 > -- > > Key: MAVENUPLOAD-1315 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1315 > Project: maven-upload-requests > Issue Type: Task >Reporter: Jochen Wiedmann > Assigned To: Carlos Sanchez > > The AntLR Parser Generator, version 3.0b5 > Note: No dependencies, standalone jar file. > Note: Using the "org.antlr" groupId, which is in use for version 3, although > version 2 used "antlr". -- 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-1314) Upload antlr-2.7.7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1314?page=all ] Carlos Sanchez closed MAVENUPLOAD-1314. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload antlr-2.7.7 > -- > > Key: MAVENUPLOAD-1314 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1314 > Project: maven-upload-requests > Issue Type: Task >Reporter: Jochen Wiedmann > Assigned To: Carlos Sanchez > > The AntLR Parser Generator, version 2.7.7 > Note: No dependencies, standalone jar file. > Note: Using the "antlr" groupId, which has been used for all jar files of > version 2. Will use "org.antlr" for version 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] Closed: (MAVENUPLOAD-1313) Upload stringtemplates-3.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1313?page=all ] Carlos Sanchez closed MAVENUPLOAD-1313. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload stringtemplates-3.0 > -- > > Key: MAVENUPLOAD-1313 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1313 > Project: maven-upload-requests > Issue Type: Task >Reporter: Jochen Wiedmann > Assigned To: Carlos Sanchez > > Stringtemplate is a template library based on and using the AntLR 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] Reopened: (MAVENUPLOAD-1315) Upload antlr-3.0b5
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1315?page=all ] Carlos Sanchez reopened MAVENUPLOAD-1315: - Assignee: (was: Carlos Sanchez) pom is 3.0 but everything else 3.0b5 > Upload antlr-3.0b5 > -- > > Key: MAVENUPLOAD-1315 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1315 > Project: maven-upload-requests > Issue Type: Task >Reporter: Jochen Wiedmann > > The AntLR Parser Generator, version 3.0b5 > Note: No dependencies, standalone jar file. > Note: Using the "org.antlr" groupId, which is in use for version 3, although > version 2 used "antlr". -- 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-1311) Upload net.sf.oval-0.8
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1311?page=comments#action_84901 ] Carlos Sanchez commented on MAVENUPLOAD-1311: - ERROR 404: Not Found. > Upload net.sf.oval-0.8 > -- > > Key: MAVENUPLOAD-1311 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1311 > Project: maven-upload-requests > Issue Type: Task >Reporter: Sebastian Thomschke > > OVal is an extensible Java 5 based object validation framework that uses > annotations to express constraints and AspectJ to handle automatic validation > (programming by contract). > This program and the accompanying materials are made available under the > terms of the Eclipse Public License v1.0 which accompanies this distribution, > and is available at http://www.eclipse.org/legal/epl-v10.html > Thanks in advance! -- 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-1312) Upload ZK 2.2.1 to the central repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1312?page=comments#action_84900 ] Carlos Sanchez commented on MAVENUPLOAD-1312: - 404 for www.zkoss.org/maven/bundles/2.2.1/fckez-2.3-2-bundle.jar > Upload ZK 2.2.1 to the central repository > - > > Key: MAVENUPLOAD-1312 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1312 > Project: maven-upload-requests > Issue Type: Task >Reporter: Tom M. Yeh > > http://www.zkoss.org/maven/bundles/2.2.1/zcommon-2.2.1-bundle.jar > http://www.zkoss.org/maven/bundles/2.2.1/zweb-2.2.1-bundle.jar > http://www.zkoss.org/maven/bundles/2.2.1/zk-2.2.1-bundle.jar > http://www.zkoss.org/maven/bundles/2.2.1/zul-2.2.1-bundle.jar > http://www.zkoss.org/maven/bundles/2.2.1/zhtml-2.2.1-bundle.jar > http://www.zkoss.org/maven/bundles/2.2.1/zkplus-2.2.1-bundle.jar > http://www.zkoss.org/maven/bundles/2.2.1/fckez-2.3-2-bundle.jar > http://www.zkoss.org > http://sourceforge.net/users/tomyeh/ > ZK is an open-source Ajax Web framework that enables rich user interface for > Web applications with no JavaScript and little programming. -- 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-1310) NanoXML Lite
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1310?page=comments#action_84902 ] Carlos Sanchez commented on MAVENUPLOAD-1310: - This is not a bundle in the format specified in that page The pom misses many minimal information listed in that page: license for instance > NanoXML Lite > > > Key: MAVENUPLOAD-1310 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1310 > Project: maven-upload-requests > Issue Type: Task >Reporter: Tassilo Schweyer > > NanoXML Lite is an extremely small (6KB) XML parser -- 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-1319) JIntellitype 1.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1319?page=all ] Carlos Sanchez closed MAVENUPLOAD-1319. --- Assignee: Carlos Sanchez Resolution: Fixed > JIntellitype 1.2 > > > Key: MAVENUPLOAD-1319 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1319 > Project: maven-upload-requests > Issue Type: Task >Reporter: Emil A. Lefkof III > Assigned To: Carlos Sanchez > > Please upload JIntellitype 1.2 to ibiblio. -- 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-1322) Intellij 6.0.3 redistribution jars
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1322?page=all ] Carlos Sanchez closed MAVENUPLOAD-1322. --- Assignee: Carlos Sanchez Resolution: Fixed > Intellij 6.0.3 redistribution jars > -- > > Key: MAVENUPLOAD-1322 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1322 > Project: maven-upload-requests > Issue Type: Task >Reporter: Jerome Lacoste > Assigned To: Carlos Sanchez > Attachments: annotations-6.0.3-bundle.jar, forms_rt-6.0.3-bundle.jar, > javac2-6.0.3-bundle.jar > > > Intellij 5.0 and 5.1 jars are already distributed on ibiblio: > http://www.ibiblio.org/maven2/com/intellij/ > The poms are manually made and have been verified by compiling the sources > distributed with IDEA. Should I remove the section from the POM ? > > md5sum /usr/local/lib/idea-6.0.3/redist/*.jar > > /usr/local/lib/idea-6.0.3/redist/src/* > b5132ca1ac90701c0ae2622fe191c4b9 > /usr/local/lib/idea-6.0.3/redist/annotations.jar > dfed9d14de41952e73a4a87e47699271 > /usr/local/lib/idea-6.0.3/redist/forms_rt.jar > aeea1eb6fab86f4cdb5aa6aba4a5ae5c /usr/local/lib/idea-6.0.3/redist/javac2.jar > 6549d92828826d00e8fd1f1676d002d9 > /usr/local/lib/idea-6.0.3/redist/src/src_annotations.zip > de80928aeaebec995b8bd64ac84385eb > /usr/local/lib/idea-6.0.3/redist/src/src_forms_rt.zip > 3eba12d85a5ecb71f80e952be5e6017e > /usr/local/lib/idea-6.0.3/redist/src/src_javac2.zip > One can get IDEA from http://www.jetbrains.com/idea/download -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-271) scm:checkin should be allow to run with a pom
scm:checkin should be allow to run with a pom - Key: SCM-271 URL: http://jira.codehaus.org/browse/SCM-271 Project: Maven SCM Issue Type: Improvement Components: maven-plugin Affects Versions: 1.0-beta-4 Environment: windows, starteam, linux Reporter: Dan Tran any objections? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-272) connectionUrl is ignored when trying to execute scm:checkin within a phase. It always use the main connection in the pom
connectionUrl is ignored when trying to execute scm:checkin within a phase. It always use the main connection in the pom - Key: SCM-272 URL: http://jira.codehaus.org/browse/SCM-272 Project: Maven SCM Issue Type: Bug Components: maven-plugin Environment: xp, linux starteam Reporter: Dan Tran I am try to do this maven.scm.plugin checkin xuy ... -- 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: (SCM-272) connectionUrl is ignored when trying to execute scm:checkin within a phase. It always use the main connection in the pom
[ http://jira.codehaus.org/browse/SCM-272?page=all ] Dan Tran updated SCM-272: - Description: I am trying to do this maven.scm.plugin checkin xuy ... was: I am try to do this maven.scm.plugin checkin xuy ... > connectionUrl is ignored when trying to execute scm:checkin within a phase. > It always use the main connection in the pom > - > > Key: SCM-272 > URL: http://jira.codehaus.org/browse/SCM-272 > Project: Maven SCM > Issue Type: Bug > Components: maven-plugin > Environment: xp, linux starteam >Reporter: Dan Tran > > I am trying to do this > > > > maven.scm.plugin > > > > checkin > > xuy > > > > ... -- 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: (SCM-271) scm:checkin should be allow to run witout a pom
[ http://jira.codehaus.org/browse/SCM-271?page=all ] Dan Tran updated SCM-271: - Summary: scm:checkin should be allow to run witout a pom (was: scm:checkin should be allow to run with a pom) > scm:checkin should be allow to run witout a pom > > > Key: SCM-271 > URL: http://jira.codehaus.org/browse/SCM-271 > Project: Maven SCM > Issue Type: Improvement > Components: maven-plugin >Affects Versions: 1.0-beta-4 > Environment: windows, starteam, linux >Reporter: Dan Tran > > any objections? -- 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: (SCM-271) Allow scm:checkin to run without a pom
[ http://jira.codehaus.org/browse/SCM-271?page=all ] Dan Tran updated SCM-271: - Summary: Allow scm:checkin to run without a pom (was: scm:checkin should be allow to run witout a pom) > Allow scm:checkin to run without a pom > --- > > Key: SCM-271 > URL: http://jira.codehaus.org/browse/SCM-271 > Project: Maven SCM > Issue Type: Improvement > Components: maven-plugin >Affects Versions: 1.0-beta-4 > Environment: windows, starteam, linux >Reporter: Dan Tran > > any objections? -- 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
