[jira] Commented: (MECLIPSE-165) Ability to exclude filtered resources from eclipse's source directories
[ http://jira.codehaus.org/browse/MECLIPSE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106262 ] Daniel Rijkhof commented on MECLIPSE-165: - I would really like this issue to be resolved. -> a way to have resources in maven which do not end up in the classpath within eclipse > Ability to exclude filtered resources from eclipse's source directories > --- > > Key: MECLIPSE-165 > URL: http://jira.codehaus.org/browse/MECLIPSE-165 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: PDE support >Affects Versions: 2.3 >Reporter: Cédric Vidal >Assignee: Brian Fox > Attachments: MECLIPSE-165.patch > > > Resources should be in the classpath from Eclipse's point of view because > they end up being in the classpath from Maven 2's point of view, but whenever > resources are marked as being filtered by M2, Eclipse puts them unfiltered in > the classpath thus introducing an inconsistency between Maven 2 and Eclipse. > Whether or not to include filtered resource directories in eclipse's sources > directories is therefore a real dilemna. While I'm sure a consistent solution > to this dilemna will eventually be found, it would be great to let the user > choose what to do in the meantime. > The attached patch adresses this issue by adding a parameter, > 'excludeFilteredResourcesFromSourceDirs', which when set to true prevents > filtered resource directories from being added to eclipse's source > directories. The parameter defaults to false to avoid changing current > projects' behavior. > Regards, > Cédric Vidal > http://www.B-Process.com > PS: This parameter could be overriden on a per resource directory basis as > mentionned in MECLIPSE-162. This is not adressed by the attached patch though -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-418) RSS feed for build status
[ http://jira.codehaus.org/browse/CONTINUUM-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106263 ] Olivier Lamy commented on CONTINUUM-418: IMHO, the best is a rss notifier (CONTINUUM-1370) > RSS feed for build status > - > > Key: CONTINUUM-418 > URL: http://jira.codehaus.org/browse/CONTINUUM-418 > Project: Continuum > Issue Type: Wish > Components: Web interface >Affects Versions: 1.0 >Reporter: David Blevins >Priority: Minor > Fix For: Future > > Attachments: rss.patch > > > Lyndon Samson suggested on the Geronimo dev list that an rss feed for > reporting build status would be a really great way to report build status. > A neat application of that feature would be the ability to include continuum > data on a confluence page. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1427) Ability to choose the build definition for 'Build all projects'
[ http://jira.codehaus.org/browse/CONTINUUM-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-1427: Fix Version/s: 1.1-beta-3 > Ability to choose the build definition for 'Build all projects' > --- > > Key: CONTINUUM-1427 > URL: http://jira.codehaus.org/browse/CONTINUUM-1427 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Affects Versions: 1.1-beta-2 >Reporter: George Gastaldi > Fix For: 1.1-beta-3 > > > Currently the default build definition is used when the 'Build all projects' > button is clicked. > It should be possible to choose a different build definition. > Show in the 'Group Actions' section, so only group-level build definitions > should be shown. > Place a drop down list right next to the 'Build all projects' button -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1425) URL in Company Pom should open in a new Window
[ http://jira.codehaus.org/browse/CONTINUUM-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-1425: Affects Version/s: 1.1-beta-2 Fix Version/s: 1.1-beta-3 > URL in Company Pom should open in a new Window > -- > > Key: CONTINUUM-1425 > URL: http://jira.codehaus.org/browse/CONTINUUM-1425 > Project: Continuum > Issue Type: Improvement > Components: Web - UI >Affects Versions: 1.1-beta-2 >Reporter: George Gastaldi >Priority: Trivial > Fix For: 1.1-beta-3 > > > The URL provided in the company POM should open in a new browser window. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-438) broken images in the download box on the artifact page
[ http://jira.codehaus.org/browse/MRM-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRM-438: - Attachment: firefox-download.png This is what the download page looks like in Firefox. > broken images in the download box on the artifact page > -- > > Key: MRM-438 > URL: http://jira.codehaus.org/browse/MRM-438 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-beta-1 >Reporter: Brett Porter >Assignee: Maria Odea Ching > Fix For: 1.0-beta-2 > > Attachments: firefox-download.png > > > these don't appear to work at all in the latest version - it isn't noticeable > in firefox but in ie you get the big white square with an X in it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRM-438) broken images in the download box on the artifact page
[ http://jira.codehaus.org/browse/MRM-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106266 ] Maria Odea Ching edited comment on MRM-438 at 9/3/07 3:20 AM: -- I updated the download page and used the existing gif images for a pom file and for a jar file (i've just resized it and renamed to download-type-[type].png). This is what the download page will look like in Firefox. Comments will be greatly appreciated :) was: This is what the download page looks like in Firefox. > broken images in the download box on the artifact page > -- > > Key: MRM-438 > URL: http://jira.codehaus.org/browse/MRM-438 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-beta-1 >Reporter: Brett Porter >Assignee: Maria Odea Ching > Fix For: 1.0-beta-2 > > Attachments: firefox-download.png > > > these don't appear to work at all in the latest version - it isn't noticeable > in firefox but in ie you get the big white square with an X in it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-438) broken images in the download box on the artifact page
[ http://jira.codehaus.org/browse/MRM-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRM-438: - Attachment: IE-download.png And this is what the download page will look like in IE. I was testing it using remote desktop so the IE browser wasn't in its maximized size.. > broken images in the download box on the artifact page > -- > > Key: MRM-438 > URL: http://jira.codehaus.org/browse/MRM-438 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-beta-1 >Reporter: Brett Porter >Assignee: Maria Odea Ching > Fix For: 1.0-beta-2 > > Attachments: firefox-download.png, IE-download.png > > > these don't appear to work at all in the latest version - it isn't noticeable > in firefox but in ie you get the big white square with an X in it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-213) more jee support for wtp
[ http://jira.codehaus.org/browse/MECLIPSE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106268 ] Richard van Nieuwenhoven commented on MECLIPSE-213: --- Just tested it on 3 different projects, looks very good! all worked! Do you need more tests before releasing the changes to the 2.5-SNAPSHOT ? Or should i wait for your 2.5-SNAPSHOT update? > 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 >Assignee: Brian Fox > Attachments: maven-eclipse-plugin-2.3-CFC-2007-03-08.patch, > maven-eclipse-plugin-2.3-PATCH-2007-03-08.tgz, > maven-eclipse-plugin-R494407.patch, maven-eclipse-plugin.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] Closed: (CONTINUUM-1425) URL in Company Pom should open in a new Window
[ http://jira.codehaus.org/browse/CONTINUUM-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1425. --- Assignee: Emmanuel Venisse Resolution: Fixed > URL in Company Pom should open in a new Window > -- > > Key: CONTINUUM-1425 > URL: http://jira.codehaus.org/browse/CONTINUUM-1425 > Project: Continuum > Issue Type: Improvement > Components: Web - UI >Affects Versions: 1.1-beta-2 >Reporter: George Gastaldi >Assignee: Emmanuel Venisse >Priority: Trivial > Fix For: 1.1-beta-3 > > > The URL provided in the company POM should open in a new browser window. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (ARCHETYPE-96) placeholder wrong in generated files
placeholder wrong in generated files
Key: ARCHETYPE-96
URL: http://jira.codehaus.org/browse/ARCHETYPE-96
Project: Maven Archetype
Issue Type: Bug
Components: Creator
Affects Versions: 1.0-alpha-6
Environment: jdk 1.5, maven 2.0.6
Reporter: Thomas Wabner
If I follow the
http://maven.apache.org/plugins/maven-archetype-plugin/examples/archetype.html
creation guide and use the
mvn archetype:create
-DgroupId=[your project's group id]
-DartifactId=[your project's artifact id]
-DarchetypeArtifactId=maven-archetype-archetype
stuff, all placeholders for groupId and artifactId are expanded in the
generated files incorrect. The should be ${groupId} and so on but is $groupId.
Same for artifactId. Looks like a problem in the creation stuff from the
archetype plugin.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-1384) Build error when enqueing happens during SCM update
[ http://jira.codehaus.org/browse/CONTINUUM-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1384. --- Assignee: Emmanuel Venisse Resolution: Cannot Reproduce Fix Version/s: 1.1-beta-3 I tested with 1.1-beta-2/beta-3 with a schedule defined to every second to try to reproduce this issue and all works fine without error > Build error when enqueing happens during SCM update > --- > > Key: CONTINUUM-1384 > URL: http://jira.codehaus.org/browse/CONTINUUM-1384 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-1 >Reporter: Julien S >Assignee: Emmanuel Venisse > Fix For: 1.1-beta-3 > > > I've noticed on several occasions that a project is suddenly marked as > "Error" without any change on the project itself. > The error is displayed on the global summary and in the project group > summary, but it does not appear on the builds page of the project. > There is no error in the logs. > As it happens quite often, I've finally noticed that the "trigger" to this > issue seem to be the following: > When a schedule runs to enqueue project while one of them is being updated > from its SCM (even when there is no change), the project is then marked as > error as described above. > More specifically, it seems that the log pattern common to these build > failure is: > 377162928 [pool-1-thread-1] INFO > org.apache.maven.scm.manager.ScmManager:default - Executing: /bin/bash -c > "cd /drive/continuum-1.1-beta-1/work/55 && cvs -z3 -f -q update -d" > 377162928 [pool-1-thread-1] INFO > org.apache.maven.scm.manager.ScmManager:default - Working directory: > /drive/continuum-1.1-beta-1/work/55 > 377163028 [defaultScheduler_Worker-1] INFO > org.apache.maven.continuum.build.settings.SchedulesActivator:default - > > Executing build job (DEFAULT_SCHEDULE)... > 377163307 [pool-1-thread-1] INFO > org.apache.maven.continuum.buildcontroller.BuildController:default - Merging > SCM results -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1259) Continuum web application is slower than before
[ http://jira.codehaus.org/browse/CONTINUUM-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106270 ] Damien Lecan commented on CONTINUUM-1259: - This issue seems to be closed, but for my new continuum 1.1.0-beta-2 instance, viewing "Project Group Summary" for a 17 modules project is slower than ever (25s !). Ok, my server is not very powerful, but Contiuum 1.0.3 was much more reactive on the same machine. > Continuum web application is slower than before > --- > > Key: CONTINUUM-1259 > URL: http://jira.codehaus.org/browse/CONTINUUM-1259 > Project: Continuum > Issue Type: Improvement >Affects Versions: 1.1-alpha-1 > Environment: Windows XP >Reporter: Kristoffer Moum >Assignee: Emmanuel Venisse > Fix For: 1.1-alpha-2 > > > The Continuum web application is dramatically slower than the released 1.0.3 > version. However, I have identified a single process which is really slow, > most other actions are "a bit" slower than 1.0.3. > In my case, there is an m2 multi-module project of which contains a total of > 34 modules. From the frontpage (i.e. (..)/continuum/groupSummary.action), if > I choose my project group from the list of groups, it takes approximately 17 > seconds to display the list of modules for that group. This is easy to > reproduce as it always takes the same amount of time. For my installation, I > haven't modified anything from the standard configuration settings. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1384) Build error when enqueing happens during SCM update
[ http://jira.codehaus.org/browse/CONTINUUM-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106271 ] Julien S commented on CONTINUUM-1384: - Indeed, I've been testing with beta-2 with a similar setup for a couple of days, and was about to comment that the issue seems to be fixed for us in beta-2 too. Thank you for the fix. > Build error when enqueing happens during SCM update > --- > > Key: CONTINUUM-1384 > URL: http://jira.codehaus.org/browse/CONTINUUM-1384 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-1 >Reporter: Julien S >Assignee: Emmanuel Venisse > Fix For: 1.1-beta-3 > > > I've noticed on several occasions that a project is suddenly marked as > "Error" without any change on the project itself. > The error is displayed on the global summary and in the project group > summary, but it does not appear on the builds page of the project. > There is no error in the logs. > As it happens quite often, I've finally noticed that the "trigger" to this > issue seem to be the following: > When a schedule runs to enqueue project while one of them is being updated > from its SCM (even when there is no change), the project is then marked as > error as described above. > More specifically, it seems that the log pattern common to these build > failure is: > 377162928 [pool-1-thread-1] INFO > org.apache.maven.scm.manager.ScmManager:default - Executing: /bin/bash -c > "cd /drive/continuum-1.1-beta-1/work/55 && cvs -z3 -f -q update -d" > 377162928 [pool-1-thread-1] INFO > org.apache.maven.scm.manager.ScmManager:default - Working directory: > /drive/continuum-1.1-beta-1/work/55 > 377163028 [defaultScheduler_Worker-1] INFO > org.apache.maven.continuum.build.settings.SchedulesActivator:default - > > Executing build job (DEFAULT_SCHEDULE)... > 377163307 [pool-1-thread-1] INFO > org.apache.maven.continuum.buildcontroller.BuildController:default - Merging > SCM results -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MDEP-108) Additional plexus UnArchiver specifyed by a separated plugin are not accessible to dependency plugin
Additional plexus UnArchiver specifyed by a separated plugin are not accessible to dependency plugin Key: MDEP-108 URL: http://jira.codehaus.org/browse/MDEP-108 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: unpack-dependencies Affects Versions: 2.0-alpha-4 Reporter: Matthieu Leclercq Assignee: Brian Fox I'have developed a Maven plugin that defines a new packaging type. Produced artifacts with this packaging type, have a "car" extension. Modules, that depends on "car" modules must unpack them to use them. To do so, I configure the maven-dependency-plugin like this (note that "cecilia-lib" is the name of the packaging type I've defined): maven-dependency-plugin unpack process-resources unpack-dependencies cecilia-lib Here, I get the error : Unknown archiver type Embedded error: No such archiver: 'car'. After some investigations, I add the following in the plexus/components.xml of my plugin: org.codehaus.plexus.archiver.UnArchiver car org.codehaus.plexus.archiver.zip.ZipUnArchiver per-lookup But I still get the same error. If I had somewhere in my plugin the following code: container.lookup( "org.codehaus.plexus.archiver.Archiver", "car"); archiverManager.getUnArchiver( "car" ) It works correctly... So I can't figure out why it doesn't work from the dependency plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-209) populateModulesMenu() logic results in invalid modules list if projects share artifactIds
[
http://jira.codehaus.org/browse/MSITE-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106281
]
John Allen commented on MSITE-209:
--
Crazy busy at the moment but yes of course (will take some time though sorry).
The logic above is fairly self-evident though. Namely increase the name
matching resolution to include an artefacts groupId as well as artifactId.
> populateModulesMenu() logic results in invalid modules list if projects share
> artifactIds
> -
>
> Key: MSITE-209
> URL: http://jira.codehaus.org/browse/MSITE-209
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-5, 2.0-beta-6
>Reporter: John Allen
>Priority: Critical
> Attachments: site-patch.diff, site-patch.diff
>
>
> populateModulesMenu() logic should compare groupIds as well as artifactIds.
> Failure to do so can result in invalid modules list being generated when the
> reactorProject.getParent().getArtifectId() is the same as the current project
> but is not of the same group. Logic should be (dont have the code available
> as its on my laptop), oh go on then Ill HTTP the source
> private void populateModulesMenuItemsFromReactorProjects( Menu menu )
> {
> [SNIP]
> if ( reactorProject != null && reactorProject.getParent() !=
> null &&
> project.getArtifactId().equals(
> reactorProject.getParent().getArtifactId() ) )
> {
> String reactorUrl = reactorProject.getUrl();
> String name = reactorProject.getName();
> appendMenuItem( menu, name, reactorUrl,
> reactorProject.getArtifactId() );
> }
> }
> }
> }
> Comparison should also check that the groupId of the reactorProject's parent
> matches our groupId.
> Clear?.. Sorry, the patch on my laptop too...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-1306) templated roles are not added automatically if missing after upgrade
[ http://jira.codehaus.org/browse/CONTINUUM-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1306. --- Assignee: Emmanuel Venisse (was: Olivier Lamy) Resolution: Fixed Fixed by CONTINUUM-1418 > templated roles are not added automatically if missing after upgrade > > > Key: CONTINUUM-1306 > URL: http://jira.codehaus.org/browse/CONTINUUM-1306 > Project: Continuum > Issue Type: Bug > Components: Database >Affects Versions: 1.1-alpha-2 >Reporter: Brett Porter >Assignee: Emmanuel Venisse >Priority: Critical > Fix For: 1.1-beta-3 > > > Fails at the last hurdle deleting a project group on an instance that had > been upgraded from an old version: > org.apache.maven.continuum.ContinuumException: error removing > tempalted role for project Maven > at > org.apache.maven.continuum.core.action.RemoveAssignableRolesAction.execute(RemoveAssignableRolesAction.java:78) > at > org.apache.maven.continuum.DefaultContinuum.executeAction(DefaultContinuum.java:2432) > at > org.apache.maven.continuum.DefaultContinuum.removeProjectGroup(DefaultContinuum.java:261) > at > org.apache.maven.continuum.web.action.ProjectGroupAction.remove(ProjectGroupAction.java:184) > I suspect this is an indication of a bigger problem that the missing > templated roles are not added automatically if they are missing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1418) Groups Roles aren't added automatically at startup in the available roles list if the users list was deleted
[ http://jira.codehaus.org/browse/CONTINUUM-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1418. --- Assignee: Emmanuel Venisse Resolution: Fixed > Groups Roles aren't added automatically at startup in the available roles > list if the users list was deleted > > > Key: CONTINUUM-1418 > URL: http://jira.codehaus.org/browse/CONTINUUM-1418 > Project: Continuum > Issue Type: Bug > Components: Security >Affects Versions: 1.1-beta-2 >Reporter: Emmanuel Venisse >Assignee: Emmanuel Venisse > Fix For: 1.1-beta-3 > > > As they aren't available, all groups are hidden even for the system > administrator, so projects must be readd to get old groups and project are > duplicated -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-605) Add a RecipientSource that derives addresses from the change list
[ http://jira.codehaus.org/browse/CONTINUUM-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-605: --- Assignee: Emmanuel Venisse Fix Version/s: (was: To Sort) 1.1-beta-3 I'll work on this issue but without the attached patch, I don't think it's the good way to resolve this issue. I think the best way is to modify the mail notifier. Based on the notifier configuration, we'd can choose between to send mails to the specified address or committers (or eventually all project developers) > Add a RecipientSource that derives addresses from the change list > - > > Key: CONTINUUM-605 > URL: http://jira.codehaus.org/browse/CONTINUUM-605 > Project: Continuum > Issue Type: New Feature > Components: Notification Subsystem >Reporter: John Didion >Assignee: Emmanuel Venisse > Fix For: 1.1-beta-3 > > Attachments: change-list-recipient-source.diff, > ChangeListRecipientSource.diff > > > CruiseControl has the nice feature of only sending notification email to > those users who submitted the changes in the build. I missed that feature > when switching to Continuum, so I implemented it. It compiles a list of scm > ids from the change list, then matches them against the developers in the POM > to get email addresses. It delegates to the default RecipientSource if there > is no change list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MDEP-108) Additional plexus UnArchiver specifyed by a separated plugin are not accessible to dependency plugin
[ http://jira.codehaus.org/browse/MDEP-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106289 ] Brian Fox commented on MDEP-108: Have you added your component as an extension to the build? If that doesn't work, try adding it as a dependency in the plugin configuration. > Additional plexus UnArchiver specifyed by a separated plugin are not > accessible to dependency plugin > > > Key: MDEP-108 > URL: http://jira.codehaus.org/browse/MDEP-108 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: unpack-dependencies >Affects Versions: 2.0-alpha-4 >Reporter: Matthieu Leclercq >Assignee: Brian Fox > > I'have developed a Maven plugin that defines a new packaging type. Produced > artifacts with this packaging type, have a "car" extension. > Modules, that depends on "car" modules must unpack them to use them. To do > so, I configure the maven-dependency-plugin like this (note that > "cecilia-lib" is the name of the packaging type I've defined): > > maven-dependency-plugin > > > unpack > process-resources > > unpack-dependencies > > > > > cecilia-lib > > > Here, I get the error : > Unknown archiver type > Embedded error: No such archiver: 'car'. > After some investigations, I add the following in the plexus/components.xml > of my plugin: > > org.codehaus.plexus.archiver.UnArchiver > car > > > org.codehaus.plexus.archiver.zip.ZipUnArchiver > per-lookup > > But I still get the same error. > If I had somewhere in my plugin the following code: > container.lookup( "org.codehaus.plexus.archiver.Archiver", "car"); > archiverManager.getUnArchiver( "car" ) > It works correctly... > So I can't figure out why it doesn't work from the dependency plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1700) java exchange connector (jec-1.53_12.jar)
java exchange connector (jec-1.53_12.jar) - Key: MAVENUPLOAD-1700 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1700 Project: maven-upload-requests Issue Type: Wish Reporter: eli hasson new JEC version -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MDEP-108) Additional plexus UnArchiver specifyed by a separated plugin are not accessible to dependency plugin
[ http://jira.codehaus.org/browse/MDEP-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106290 ] Matthieu Leclercq commented on MDEP-108: Yes, it works !! In fact, I missed something in how maven deals with plugin dependencies. So it means that the plugin is executed with the dependencies it declares and not with the dependencies declared in the project that is being built. Thank you for this quick answer. Matthieu > Additional plexus UnArchiver specifyed by a separated plugin are not > accessible to dependency plugin > > > Key: MDEP-108 > URL: http://jira.codehaus.org/browse/MDEP-108 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: unpack-dependencies >Affects Versions: 2.0-alpha-4 >Reporter: Matthieu Leclercq >Assignee: Brian Fox > > I'have developed a Maven plugin that defines a new packaging type. Produced > artifacts with this packaging type, have a "car" extension. > Modules, that depends on "car" modules must unpack them to use them. To do > so, I configure the maven-dependency-plugin like this (note that > "cecilia-lib" is the name of the packaging type I've defined): > > maven-dependency-plugin > > > unpack > process-resources > > unpack-dependencies > > > > > cecilia-lib > > > Here, I get the error : > Unknown archiver type > Embedded error: No such archiver: 'car'. > After some investigations, I add the following in the plexus/components.xml > of my plugin: > > org.codehaus.plexus.archiver.UnArchiver > car > > > org.codehaus.plexus.archiver.zip.ZipUnArchiver > per-lookup > > But I still get the same error. > If I had somewhere in my plugin the following code: > container.lookup( "org.codehaus.plexus.archiver.Archiver", "car"); > archiverManager.getUnArchiver( "car" ) > It works correctly... > So I can't figure out why it doesn't work from the dependency plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MDEP-108) Additional plexus UnArchiver specifyed by a separated plugin are not accessible to dependency plugin
[ http://jira.codehaus.org/browse/MDEP-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106295 ] Brian Fox commented on MDEP-108: So which did you end up doing? an extension or a dependency? > Additional plexus UnArchiver specifyed by a separated plugin are not > accessible to dependency plugin > > > Key: MDEP-108 > URL: http://jira.codehaus.org/browse/MDEP-108 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: unpack-dependencies >Affects Versions: 2.0-alpha-4 >Reporter: Matthieu Leclercq >Assignee: Brian Fox > > I'have developed a Maven plugin that defines a new packaging type. Produced > artifacts with this packaging type, have a "car" extension. > Modules, that depends on "car" modules must unpack them to use them. To do > so, I configure the maven-dependency-plugin like this (note that > "cecilia-lib" is the name of the packaging type I've defined): > > maven-dependency-plugin > > > unpack > process-resources > > unpack-dependencies > > > > > cecilia-lib > > > Here, I get the error : > Unknown archiver type > Embedded error: No such archiver: 'car'. > After some investigations, I add the following in the plexus/components.xml > of my plugin: > > org.codehaus.plexus.archiver.UnArchiver > car > > > org.codehaus.plexus.archiver.zip.ZipUnArchiver > per-lookup > > But I still get the same error. > If I had somewhere in my plugin the following code: > container.lookup( "org.codehaus.plexus.archiver.Archiver", "car"); > archiverManager.getUnArchiver( "car" ) > It works correctly... > So I can't figure out why it doesn't work from the dependency plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-197) Automatic reference of dependee projects
[ http://jira.codehaus.org/browse/MECLIPSE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106296 ] Andrea Aime commented on MECLIPSE-197: -- I would be very interested in a behaviour that's quite similar to this. I have two open source projects, GeoTools and GeoServer, both using maven, and GeoServer depending on GeoTools. Now, what I would like very much would be the ability to load both project modules into Eclipse so that GeoServer project refer directly GeoTools modules, instead of depending on the jars. GeoTools is a complex library made up of 90+ modules, organised in a tree hierarchy, so I guess to make this possible mvn eclipse:eclipse would have to actually scan the GeoTools poms. > Automatic reference of dependee projects > > > Key: MECLIPSE-197 > URL: http://jira.codehaus.org/browse/MECLIPSE-197 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: dependency resolution >Reporter: Alessandro Evangelista >Assignee: fabrizio giustina > Attachments: referenceDependeeProjects-patch.txt > > Original Estimate: 1 day > Remaining Estimate: 1 day > > It would very useful to have the ability to automatically reference dependee > project for which the project source code is locally found. > Let's assume that module y depends on module x. The project description of > module y will contain directly or indirectly - i.e. transitively - a > dependency to module x. > The execution of the goal "eclipse:eclipse" on the module y would normally > generate an eclipse project with a jar dependency to module x. > Often it is convenient to directly reference the module x as eclipse project > to allow concurrent modification and compilation of both module x and y. > The attached patch allows to automatically reference projects if the dependee > project's source code is found in same directory as the dependent project. A > project is a candidate match if the group-id and artifact-id properties of > the two project equal and the two version equal or the dependee's version is > the requested version but SNAPSHOT tagged. > Example of directory structure: > /usr/src/product/com.company.product.x/pom.xml > /usr/src/product/com.company.product.y/pom.xml > The feature can be enabled via the maven's boolean property > eclipse.referenceDependeeProjects > The property default value is false and therefore the feature is disabled per > default. > The following is an example of execution with the feature enabled: > # mvn eclipse:eclipse -Declipse.referenceDependeeProjects=true > > Currently it is assumed that the dependee project sources are within a > directory named after the project's artifact-id. > Future extensions could consider the more general maven's version matching > strategy - is this coded anywhere specific in maven's source code? - and > possibly allowing for locating the dependee source in directories with > generic names or paths. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-197) Automatic reference of dependee projects
[ http://jira.codehaus.org/browse/MECLIPSE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106299 ] Andrea Aime commented on MECLIPSE-197: -- Oh, an easier way would be to just be able to specify groups whose artifact references should be generated as project names, assuming something or someone already loaded those projects in the workspace. Something like: org.geotools or like: org.geotools commons-beanutils commons-beanutils-core > Automatic reference of dependee projects > > > Key: MECLIPSE-197 > URL: http://jira.codehaus.org/browse/MECLIPSE-197 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: dependency resolution >Reporter: Alessandro Evangelista >Assignee: fabrizio giustina > Attachments: referenceDependeeProjects-patch.txt > > Original Estimate: 1 day > Remaining Estimate: 1 day > > It would very useful to have the ability to automatically reference dependee > project for which the project source code is locally found. > Let's assume that module y depends on module x. The project description of > module y will contain directly or indirectly - i.e. transitively - a > dependency to module x. > The execution of the goal "eclipse:eclipse" on the module y would normally > generate an eclipse project with a jar dependency to module x. > Often it is convenient to directly reference the module x as eclipse project > to allow concurrent modification and compilation of both module x and y. > The attached patch allows to automatically reference projects if the dependee > project's source code is found in same directory as the dependent project. A > project is a candidate match if the group-id and artifact-id properties of > the two project equal and the two version equal or the dependee's version is > the requested version but SNAPSHOT tagged. > Example of directory structure: > /usr/src/product/com.company.product.x/pom.xml > /usr/src/product/com.company.product.y/pom.xml > The feature can be enabled via the maven's boolean property > eclipse.referenceDependeeProjects > The property default value is false and therefore the feature is disabled per > default. > The following is an example of execution with the feature enabled: > # mvn eclipse:eclipse -Declipse.referenceDependeeProjects=true > > Currently it is assumed that the dependee project sources are within a > directory named after the project's artifact-id. > Future extensions could consider the more general maven's version matching > strategy - is this coded anywhere specific in maven's source code? - and > possibly allowing for locating the dependee source in directories with > generic names or paths. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-298) Problem using -javaagent
[
http://jira.codehaus.org/browse/SUREFIRE-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106300
]
Martin Gilday commented on SUREFIRE-298:
I am attempting this with 2.4-SNAPSHOT and getting the error "Exception in
thread "Main Thread" java.lang.NoClassDefFoundError:
org/codehaus/plexus/util/cli/StreamConsumer". Please could you post a full
example POM?
> Problem using -javaagent
>
>
> Key: SUREFIRE-298
> URL: http://jira.codehaus.org/browse/SUREFIRE-298
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 2.0 (2.2 plugin)
> Environment: Windows XP
>Reporter: Bård Dybwad Kristensen
> Fix For: 2.4
>
>
> I try to run the JMockit framework in my tests to do some mocking of static
> classes.
> I supply the argLine arguments as follows (some spaces added to avoid
> smileys):
>
> -javaagent:D : \
> .m2\repository\jmockit\jmockit\0.83\jmockit-0.83.jar
> once
>
> This does not work. The problem is that the Mockit class is not able to find
> neither the class it is suppose to mock nor the class to use as a mock. I
> have made two small classes, Math and MockMath each with one similar method
> and one static String constant. My setup-method in the testclass is as
> follows:
> protected void setUp() throws Exception {
> super.setUp();
> System.out.println(Math.TEST);
> System.out.println(MockMath.TEST);
> Mockit.redefineMethods(Math.class, MockMath.class);
> }
> When I run this, the two System.out.printlns runs Ok, and prints what it
> should, but the Mockit class returns the following error:
> java.lang.RuntimeException: Failed to read class file for
> no.ergo.ec.vaktplan.MockMath
> at mockit.Mockit.readClassFile(Mockit.java:228)
> at mockit.Mockit.collectMockMethods(Mockit.java:191)
> at mockit.Mockit.redefineMethods(Mockit.java:176)
> at mockit.Mockit.redefineMethods(Mockit.java:162)
> at no.ergo.ec.vaktplan.TestMain.setUp(TestMain.java:12)
> at junit.framework.TestCase.runBare(TestCase.java:125)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)
> Caused by: java.io.IOException: Class not found
> at org.objectweb.asm2.ClassReader.readClass(ClassReader.java:259)
> at org.objectweb.asm2.ClassReader.(ClassReader.java:236)
> at org.objectweb.asm2.ClassReader.(ClassReader.java:246)
> at mockit.Mockit.readClassFile(Mockit.java:225)
> It is not able to find the class, which was ok in the System.out run just
> before.
> If I do a mvn eclipse:eclipse and create an eclipse project, I can run the
> test class without any problems in Eclipse (with exactly tha same VM
> arguments as I use in the pom.xml)
> So I guess it is some issue with which classloader that loads the Mockit
> class when it is supplied as the instrumentation class via the -javaagent
> switch.
> Anybody experience any problems like this using the -javaagent switch?
> Any feedback would be greatly appreciated.
> regards,
> bdk
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact o
[jira] Closed: (MEV-536) Broken checksums and signature for maven-2.0.7.pom
[ http://jira.codehaus.org/browse/MEV-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed MEV-536. - Resolution: Fixed Didn't sync, so fixed by hand on repo1 as it's easy to make the sigs look the same. > Broken checksums and signature for maven-2.0.7.pom > -- > > Key: MEV-536 > URL: http://jira.codehaus.org/browse/MEV-536 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Max Bowsher >Assignee: Henri Yandell > > http://repo1.maven.org/maven2/org/apache/maven/maven/2.0.7/maven-2.0.7.pom > .md5 and .sha1 are broken due to being in incorrect format (generated by BSD > checksum tools?) > .asc is bad signature. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-197) Automatic reference of dependee projects
[ http://jira.codehaus.org/browse/MECLIPSE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106304 ] Alex commented on MECLIPSE-197: --- This feature is also useful when debugging 3rd-party libraries. I would not limit the capability to "project reference" to projects within the same group. > Automatic reference of dependee projects > > > Key: MECLIPSE-197 > URL: http://jira.codehaus.org/browse/MECLIPSE-197 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: dependency resolution >Reporter: Alessandro Evangelista >Assignee: fabrizio giustina > Attachments: referenceDependeeProjects-patch.txt > > Original Estimate: 1 day > Remaining Estimate: 1 day > > It would very useful to have the ability to automatically reference dependee > project for which the project source code is locally found. > Let's assume that module y depends on module x. The project description of > module y will contain directly or indirectly - i.e. transitively - a > dependency to module x. > The execution of the goal "eclipse:eclipse" on the module y would normally > generate an eclipse project with a jar dependency to module x. > Often it is convenient to directly reference the module x as eclipse project > to allow concurrent modification and compilation of both module x and y. > The attached patch allows to automatically reference projects if the dependee > project's source code is found in same directory as the dependent project. A > project is a candidate match if the group-id and artifact-id properties of > the two project equal and the two version equal or the dependee's version is > the requested version but SNAPSHOT tagged. > Example of directory structure: > /usr/src/product/com.company.product.x/pom.xml > /usr/src/product/com.company.product.y/pom.xml > The feature can be enabled via the maven's boolean property > eclipse.referenceDependeeProjects > The property default value is false and therefore the feature is disabled per > default. > The following is an example of execution with the feature enabled: > # mvn eclipse:eclipse -Declipse.referenceDependeeProjects=true > > Currently it is assumed that the dependee project sources are within a > directory named after the project's artifact-id. > Future extensions could consider the more general maven's version matching > strategy - is this coded anywhere specific in maven's source code? - and > possibly allowing for locating the dependee source in directories with > generic names or paths. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1218) Automatically determine correct POM file location in Build Definition when checking out from SCMs like ClearCase
[ http://jira.codehaus.org/browse/CONTINUUM-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1218. --- Assignee: Emmanuel Venisse Resolution: Fixed Fixed. For the moment, after the first checkout, I modify the default build definition of the project, if the project have other build definitions, they aren't affected but I don't think a user already set some other build definitions before the first run > Automatically determine correct POM file location in Build Definition when > checking out from SCMs like ClearCase > > > Key: CONTINUUM-1218 > URL: http://jira.codehaus.org/browse/CONTINUUM-1218 > Project: Continuum > Issue Type: Improvement >Affects Versions: 1.1-alpha-1 >Reporter: Arne Degenring >Assignee: Emmanuel Venisse > Fix For: 1.1-beta-3 > > > SCM-288 has introduced an attribute in CheckoutScmResult that contains the > relative path of the project directory, relative to the checkout directory. > This is needed for SCMs like ClearCase that do NOT perform the checkout into > the checkout directory itself, but into a subdirectory. See SCM-288 for > details. > This information should be honored by Continuum when adding a new project > after checking out the sources. The POM filename of the Build Definition > should automatically be set accordingly. In most cases the default "pom.xml" > is sufficient, but in cases like ClearCase it would be e.g. > "MY_VOB/my/project/dir/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: (SUREFIRE-298) Problem using -javaagent
[
http://jira.codehaus.org/browse/SUREFIRE-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106306
]
Julian Wood commented on SUREFIRE-298:
--
Here's a cut down pom. Use the apache profile as described here:
http://maven.apache.org/guides/development/guide-plugin-snapshot-repositories.html
You need to install mockit into your local repository yourself:
http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
ca.ucalgary.it
gdir
war
1.0-SNAPSHOT
org.apache.maven.plugins
maven-clean-plugin
2.1
org.apache.maven.plugins
maven-release-plugin
2.0-beta-4
org.apache.maven.plugins
maven-compiler-plugin
2.0.1
org.apache.maven.plugins
maven-site-plugin
2.0-beta-5
org.apache.maven.plugins
maven-resources-plugin
2.2
org.apache.maven.plugins
maven-surefire-plugin
2.4-SNAPSHOT
org.apache.maven.plugins
maven-war-plugin
2.0.2
org.apache.maven.plugins
maven-jar-plugin
2.0
org.apache.maven
maven-archiver
2.0.1
org.apache.maven.plugins
maven-surefire-plugin
-javaagent:${user.home}/.m2/repository/mockit/jmockit/0.8.5/jmockit-0.8.5.jar
true
mockit
jmockit
0.8.5
test
mockit
jmockit-asm2
0.8.5
test
junit
junit
3.8.1
test
log4j
log4j
1.2.8
compile
> Problem using -javaagent
>
>
> Key: SUREFIRE-298
> URL: http://jira.codehaus.org/browse/SUREFIRE-298
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 2.0 (2.2 plugin)
> Environment: Windows XP
>Reporter: Bård Dybwad Kristensen
> Fix For: 2.4
>
>
> I try to run the JMockit framework in my tests to do some mocking of static
> classes.
> I supply the argLine arguments as follows (some spaces added to avoid
> smileys):
>
> -javaagent:D : \
> .m2\repository\jmockit\jmockit\0.83\jmockit-0.83.jar
> once
>
> This does not work. The problem is that the Mockit class is not able to find
> neither the class it is suppose to mock nor the class to use as a mock. I
> have made two small classes, Math and MockMath each with one similar method
> and one static String constant. My setup-method in the testclass is as
> follows:
> protected void setUp() throws Exception {
> super.setUp();
> System.out.println(Math.TEST);
> System.out.println(MockMath.TEST);
> Mockit.redefineMethods(Math.class, MockMath.class);
> }
> When I run this, the two System.out.printlns runs Ok, and prints what it
> should, but the Mockit class returns the following error:
> java.lang.RuntimeException: Failed to read class file for
> no.ergo.ec.vaktplan.MockMath
> at mockit.Mockit.readClassFile(Mockit.java:228)
> at mockit.Mockit.collectMockMethods(Mockit.java:191)
> at mockit.Mockit.redefineMethods(Mockit.java:176)
> at mockit.Mockit.redefineMethods(Mockit.java:162)
> at no.ergo.ec.vaktplan.TestMain.setUp(TestMain.java:12)
> at junit.framework.TestCase.runBare(TestCase.java:125)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.Tes
[jira] Issue Comment Edited: (SUREFIRE-298) Problem using -javaagent
[
http://jira.codehaus.org/browse/SUREFIRE-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106306
]
Julian Wood edited comment on SUREFIRE-298 at 9/3/07 12:09 PM:
---
Here's a cut down pom. Use the apache profile as described here:
http://maven.apache.org/guides/development/guide-plugin-snapshot-repositories.html
You need to install mockit into your local repository yourself:
http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html
{noformat}
4.0.0
ca.ucalgary.it
gdir
war
1.0-SNAPSHOT
org.apache.maven.plugins
maven-clean-plugin
2.1
org.apache.maven.plugins
maven-release-plugin
2.0-beta-4
org.apache.maven.plugins
maven-compiler-plugin
2.0.1
org.apache.maven.plugins
maven-site-plugin
2.0-beta-5
org.apache.maven.plugins
maven-resources-plugin
2.2
org.apache.maven.plugins
maven-surefire-plugin
2.4-SNAPSHOT
org.apache.maven.plugins
maven-war-plugin
2.0.2
org.apache.maven.plugins
maven-jar-plugin
2.0
org.apache.maven
maven-archiver
2.0.1
org.apache.maven.plugins
maven-surefire-plugin
-javaagent:${user.home}/.m2/repository/mockit/jmockit/0.8.5/jmockit-0.8.5.jar
true
mockit
jmockit
0.8.5
test
mockit
jmockit-asm2
0.8.5
test
junit
junit
3.8.1
test
log4j
log4j
1.2.8
compile
{noformat}
was:
Here's a cut down pom. Use the apache profile as described here:
http://maven.apache.org/guides/development/guide-plugin-snapshot-repositories.html
You need to install mockit into your local repository yourself:
http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html
{noformat}
4.0.0
ca.ucalgary.it
gdir
war
1.0-SNAPSHOT
org.apache.maven.plugins
maven-clean-plugin
2.1
org.apache.maven.plugins
maven-release-plugin
2.0-beta-4
org.apache.maven.plugins
maven-compiler-plugin
2.0.1
org.apache.maven.plugins
maven-site-plugin
2.0-beta-5
org.apache.maven.plugins
maven-resources-plugin
2.2
org.apache.maven.plugins
maven-surefire-plugin
2.4-SNAPSHOT
org.apache.maven.plugins
maven-war-plugin
2.0.2
org.apache.maven.plugins
maven-jar-plugin
2.0
org.apache.maven
maven-archiver
2.0.1
org.apache.maven.plugins
maven-surefire-plugin
-javaagent:${user.home}/.m2/repository/mockit/jmockit/0.8.5/jmockit-0.8.5.jar
true
mockit
jmockit
0.8.5
test
mockit
jmockit-asm2
0.8.5
test
junit
junit
[jira] Issue Comment Edited: (SUREFIRE-298) Problem using -javaagent
[
http://jira.codehaus.org/browse/SUREFIRE-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106306
]
Julian Wood edited comment on SUREFIRE-298 at 9/3/07 12:08 PM:
---
Here's a cut down pom. Use the apache profile as described here:
http://maven.apache.org/guides/development/guide-plugin-snapshot-repositories.html
You need to install mockit into your local repository yourself:
http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html
{noformat}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
ca.ucalgary.it
gdir
war
1.0-SNAPSHOT
org.apache.maven.plugins
maven-clean-plugin
2.1
org.apache.maven.plugins
maven-release-plugin
2.0-beta-4
org.apache.maven.plugins
maven-compiler-plugin
2.0.1
org.apache.maven.plugins
maven-site-plugin
2.0-beta-5
org.apache.maven.plugins
maven-resources-plugin
2.2
org.apache.maven.plugins
maven-surefire-plugin
2.4-SNAPSHOT
org.apache.maven.plugins
maven-war-plugin
2.0.2
org.apache.maven.plugins
maven-jar-plugin
2.0
org.apache.maven
maven-archiver
2.0.1
org.apache.maven.plugins
maven-surefire-plugin
-javaagent:${user.home}/.m2/repository/mockit/jmockit/0.8.5/jmockit-0.8.5.jar
true
mockit
jmockit
0.8.5
test
mockit
jmockit-asm2
0.8.5
test
junit
junit
3.8.1
test
log4j
log4j
1.2.8
compile
{noformat}
was:
Here's a cut down pom. Use the apache profile as described here:
http://maven.apache.org/guides/development/guide-plugin-snapshot-repositories.html
You need to install mockit into your local repository yourself:
http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
ca.ucalgary.it
gdir
war
1.0-SNAPSHOT
org.apache.maven.plugins
maven-clean-plugin
2.1
org.apache.maven.plugins
maven-release-plugin
2.0-beta-4
org.apache.maven.plugins
maven-compiler-plugin
2.0.1
org.apache.maven.plugins
maven-site-plugin
2.0-beta-5
org.apache.maven.plugins
maven-resources-plugin
2.2
org.apache.maven.plugins
maven-surefire-plugin
2.4-SNAPSHOT
org.apache.maven.plugins
maven-war-plugin
2.0.2
org.apache.maven.plugins
maven-jar-plugin
2.0
org.apache.maven
maven-archiver
2.0.1
org.apache.maven.plugins
maven-surefire-plugin
-javaagent:${user.home}/.m2/repositor
[jira] Issue Comment Edited: (SUREFIRE-298) Problem using -javaagent
[
http://jira.codehaus.org/browse/SUREFIRE-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106306
]
Julian Wood edited comment on SUREFIRE-298 at 9/3/07 12:09 PM:
---
Here's a cut down pom. Use the apache profile as described here:
http://maven.apache.org/guides/development/guide-plugin-snapshot-repositories.html
You need to install mockit into your local repository yourself:
http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html
{noformat}
4.0.0
ca.ucalgary.it
gdir
war
1.0-SNAPSHOT
org.apache.maven.plugins
maven-clean-plugin
2.1
org.apache.maven.plugins
maven-release-plugin
2.0-beta-4
org.apache.maven.plugins
maven-compiler-plugin
2.0.1
org.apache.maven.plugins
maven-site-plugin
2.0-beta-5
org.apache.maven.plugins
maven-resources-plugin
2.2
org.apache.maven.plugins
maven-surefire-plugin
2.4-SNAPSHOT
org.apache.maven.plugins
maven-war-plugin
2.0.2
org.apache.maven.plugins
maven-jar-plugin
2.0
org.apache.maven
maven-archiver
2.0.1
org.apache.maven.plugins
maven-surefire-plugin
-javaagent:${user.home}/.m2/repository/mockit/jmockit/0.8.5/jmockit-0.8.5.jar
true
mockit
jmockit
0.8.5
test
mockit
jmockit-asm2
0.8.5
test
junit
junit
3.8.1
test
log4j
log4j
1.2.8
compile
{noformat}
was:
Here's a cut down pom. Use the apache profile as described here:
http://maven.apache.org/guides/development/guide-plugin-snapshot-repositories.html
You need to install mockit into your local repository yourself:
http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html
{noformat}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
ca.ucalgary.it
gdir
war
1.0-SNAPSHOT
org.apache.maven.plugins
maven-clean-plugin
2.1
org.apache.maven.plugins
maven-release-plugin
2.0-beta-4
org.apache.maven.plugins
maven-compiler-plugin
2.0.1
org.apache.maven.plugins
maven-site-plugin
2.0-beta-5
org.apache.maven.plugins
maven-resources-plugin
2.2
org.apache.maven.plugins
maven-surefire-plugin
2.4-SNAPSHOT
org.apache.maven.plugins
maven-war-plugin
2.0.2
org.apache.maven.plugins
maven-jar-plugin
2.0
org.apache.maven
maven-archiver
2.0.1
org.apache.maven.plugins
maven-surefire-plugin
-javaagent:${user.home}/.m2/repository/mockit/jmockit/0.8.5/jmockit-0.8.5.jar
true
mockit
jm
[jira] Issue Comment Edited: (CONTINUUM-1402) Syncing with Perforce on Linux/Unix/Bash fails
[
http://jira.codehaus.org/browse/CONTINUUM-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106308
]
Matthias Wurm edited comment on CONTINUUM-1402 at 9/3/07 1:02 PM:
--
I guess there is a problem with backslashes in the command:
After setting loglevel to debug I've seen that maven-scm wants to do the
following:
2007-09-03 19:55:35,908 [pool-1-thread-1] DEBUG ScmManager:default
- Executing: /bin/bash --c "p4 -d
/data/local/continuum-1.1-beta-2/apps/continuum/webapp/WEB-INF/working-directory/3
-p perforce.e.secunet.de:1666
-chostname-MavenSCM-\data\local\continuum-1.1-beta-2\apps\continuum\webapp\WEB-INF\working-directory\3
sync -f"
Executing the command manually on my console removes the backslashes, hence the
command fails
Client
'hostname-MavenSCM-datalocalcontinuum-1.1-beta-2appscontinuumwebappWEB-INFworking-directory2'
unknown - use 'client' command to create it.
Setting the clientspec inside single quotes like this works on the console:
/bin/bash -c "p4 -d
/data/local/continuum-1.1-beta-2/apps/continuum/webapp/WEB-INF/working-directory/3
-p perforce.e.secunet.de:1666
-c'hostname-MavenSCM-\data\local\continuum-1.1-beta-2\apps\continuum\webapp\WEB-INF\working-directory\3'
sync -f"
Maybe changing the maven-scm-provider to add single quotes around the
clientspec name might fix this issue.
was:
I guess there is a problem with backslashes in the command:
After setting loglevel to debug I've seen that maven-scm wants to do the
following:
2007-09-03 19:55:35,908 [pool-1-thread-1] DEBUG ScmManager:default
- Executing: /bin/bash -c "p4 -d
/data/local/continuum-1.1-beta-2/apps/continuum/webapp/WEB-INF/working-directory/3
-p perforce.e.secunet.de:1666
-chostname-MavenSCM-\data\local\continuum-1.1-beta-2\apps\continuum\webapp\WEB-INF\working-directory\3
sync -f"
Executing the command manually on my console removes the backslashes, hence the
command fails
Client
'hostname-MavenSCM-datalocalcontinuum-1.1-beta-2appscontinuumwebappWEB-INFworking-directory2'
unknown - use 'client' command to create it.
Setting the clientspec inside single quotes like this works on the console:
/bin/bash -c "p4 -d
/data/local/continuum-1.1-beta-2/apps/continuum/webapp/WEB-INF/working-directory/3
-p perforce.e.secunet.de:1666
-c'hostname-MavenSCM-\data\local\continuum-1.1-beta-2\apps\continuum\webapp\WEB-INF\working-directory\3'
sync -f"
Maybe changing the maven-scm-provider to add single quotes around the
clientspec name might fix this issue.
> Syncing with Perforce on Linux/Unix/Bash fails
> --
>
> Key: CONTINUUM-1402
> URL: http://jira.codehaus.org/browse/CONTINUUM-1402
> Project: Continuum
> Issue Type: Bug
> Components: Integration - Maven 2, SCM
>Affects Versions: 1.1-beta-2
> Environment: Bash
>Reporter: Sebastian Annies
>Priority: Critical
>
> When a client is created it is named:
> E.g.{{monospaced}}
> sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6{{monospaced}}
> that is ok, but now comes the sync command and uses following commandline
> {{monospaced}}
> /bin/bash -c "p4 -d
> /opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
>
> -cbackground-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
> sync"
> {{monospaced}}
> The Bash now removes the backslashes in the client name! The result is that
> the client is not existent and perforce returns with an error.
> I think continuum does everything allright but we need the ticket here to be
> reminded to switch to a new plexus-utils or maven-scm if it is fixed there.
> The Problem starts in 'PerforceCheckOutCommand':
> {{monospaced}}
> public static Commandline createCommandLine(
> PerforceScmProviderRepository repo, File workingDirectory,
> ScmVersion version, String
> specname )
> {
> Commandline command = PerforceScmProvider.createP4Command( repo,
> workingDirectory );
> {color:red}
> command.createArgument().setValue( "-c" + specname );
> {color}
> command.createArgument().setValue( "sync" );
> // Use a simple heuristic to determine if we should use the Force flag
> // on sync. Forcing sync is a HUGE performance hit but is required in
> // rare instances where source is somehow deleted. If the target
> // directory is completely empty, assume a force is required. If
> // not empty, we assume a previous checkout was already done and a
> normal
> // sync will suffice.
> // SCM-110
> String[] files = workingDirectory.list();
> if ( files == null || files.length ==
[jira] Commented: (CONTINUUM-1402) Syncing with Perforce on Linux/Unix/Bash fails
[
http://jira.codehaus.org/browse/CONTINUUM-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106308
]
Matthias Wurm commented on CONTINUUM-1402:
--
I guess there is a problem with backslashes in the command:
After setting loglevel to debug I've seen that maven-scm wants to do the
following:
2007-09-03 19:55:35,908 [pool-1-thread-1] DEBUG ScmManager:default
- Executing: /bin/bash -c "p4 -d
/data/local/continuum-1.1-beta-2/apps/continuum/webapp/WEB-INF/working-directory/3
-p perforce.e.secunet.de:1666
-chostname-MavenSCM-\data\local\continuum-1.1-beta-2\apps\continuum\webapp\WEB-INF\working-directory\3
sync -f"
Executing the command manually on my console removes the backslashes, hence the
command fails
Client
'hostname-MavenSCM-datalocalcontinuum-1.1-beta-2appscontinuumwebappWEB-INFworking-directory2'
unknown - use 'client' command to create it.
Setting the clientspec inside single quotes like this works on the console:
/bin/bash -c "p4 -d
/data/local/continuum-1.1-beta-2/apps/continuum/webapp/WEB-INF/working-directory/3
-p perforce.e.secunet.de:1666
-c'hostname-MavenSCM-\data\local\continuum-1.1-beta-2\apps\continuum\webapp\WEB-INF\working-directory\3'
sync -f"
Maybe changing the maven-scm-provider to add single quotes around the
clientspec name might fix this issue.
> Syncing with Perforce on Linux/Unix/Bash fails
> --
>
> Key: CONTINUUM-1402
> URL: http://jira.codehaus.org/browse/CONTINUUM-1402
> Project: Continuum
> Issue Type: Bug
> Components: Integration - Maven 2, SCM
>Affects Versions: 1.1-beta-2
> Environment: Bash
>Reporter: Sebastian Annies
>Priority: Critical
>
> When a client is created it is named:
> E.g.{{monospaced}}
> sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6{{monospaced}}
> that is ok, but now comes the sync command and uses following commandline
> {{monospaced}}
> /bin/bash -c "p4 -d
> /opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
>
> -cbackground-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
> sync"
> {{monospaced}}
> The Bash now removes the backslashes in the client name! The result is that
> the client is not existent and perforce returns with an error.
> I think continuum does everything allright but we need the ticket here to be
> reminded to switch to a new plexus-utils or maven-scm if it is fixed there.
> The Problem starts in 'PerforceCheckOutCommand':
> {{monospaced}}
> public static Commandline createCommandLine(
> PerforceScmProviderRepository repo, File workingDirectory,
> ScmVersion version, String
> specname )
> {
> Commandline command = PerforceScmProvider.createP4Command( repo,
> workingDirectory );
> {color:red}
> command.createArgument().setValue( "-c" + specname );
> {color}
> command.createArgument().setValue( "sync" );
> // Use a simple heuristic to determine if we should use the Force flag
> // on sync. Forcing sync is a HUGE performance hit but is required in
> // rare instances where source is somehow deleted. If the target
> // directory is completely empty, assume a force is required. If
> // not empty, we assume a previous checkout was already done and a
> normal
> // sync will suffice.
> // SCM-110
> String[] files = workingDirectory.list();
> if ( files == null || files.length == 0 )
> {
> // We need to force so checkout to an empty directory will work.
> command.createArgument().setValue( "-f" );
> }
> // Not sure what to do here. I'm unclear whether we should be
> // sync'ing each file individually to the label or just sync the
> // entire contents of the workingDir. I'm going to assume the
> // latter until the exact semantics are clearer.
> if ( version != null && StringUtils.isNotEmpty( version.getName() ) )
> {
> command.createArgument().setValue( "@" + version.getName() );
> }
> return command;
> {{monospaced}}
> The {{monospaced}}specname {{monospaced}} contains the backslashes and is
> these are neither escaped nor quoted! Hmm ... Is that a job that the
> CommandLine should handle? I think so!
> The next thing I will do is to file an issue at plexus-utils and link the
> issues.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (CONTINUUM-1402) Syncing with Perforce on Linux/Unix/Bash fails
[
http://jira.codehaus.org/browse/CONTINUUM-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106308
]
Matthias Wurm edited comment on CONTINUUM-1402 at 9/3/07 1:05 PM:
--
I guess there is a problem with backslashes in the command:
After setting loglevel to debug I've seen that maven-scm wants to do the
following:
{noformat} 2007-09-03 19:55:35,908 [pool-1-thread-1] DEBUG ScmManager:default
- Executing: /bin/bash -c "p4 -d
/data/local/continuum-1.1-beta-2/apps/continuum/webapp/WEB-INF/working-directory/3
-p perforce.e.secunet.de:1666
-chostname-MavenSCM-\data\local\continuum-1.1-beta-2\apps\continuum\webapp\WEB-INF\working-directory\3
sync -f"{noformat}
Executing the command manually on my console removes the backslashes, hence the
command fails
{noformat}Client
'hostname-MavenSCM-datalocalcontinuum-1.1-beta-2appscontinuumwebappWEB-INFworking-directory2'
unknown - use 'client' command to create it.{noformat}
Setting the clientspec inside single quotes like this works on the console:
{noformat}/bin/bash -c "p4 -d
/data/local/continuum-1.1-beta-2/apps/continuum/webapp/WEB-INF/working-directory/3
-p perforce.e.secunet.de:1666
-c'hostname-MavenSCM-\data\local\continuum-1.1-beta-2\apps\continuum\webapp\WEB-INF\working-directory\3'
sync -f"{noformat}
Maybe changing the maven-scm-provider to add single quotes around the
clientspec name might fix this issue.
was:
I guess there is a problem with backslashes in the command:
After setting loglevel to debug I've seen that maven-scm wants to do the
following:
2007-09-03 19:55:35,908 [pool-1-thread-1] DEBUG ScmManager:default
- Executing: /bin/bash --c "p4 -d
/data/local/continuum-1.1-beta-2/apps/continuum/webapp/WEB-INF/working-directory/3
-p perforce.e.secunet.de:1666
-chostname-MavenSCM-\data\local\continuum-1.1-beta-2\apps\continuum\webapp\WEB-INF\working-directory\3
sync -f"
Executing the command manually on my console removes the backslashes, hence the
command fails
Client
'hostname-MavenSCM-datalocalcontinuum-1.1-beta-2appscontinuumwebappWEB-INFworking-directory2'
unknown - use 'client' command to create it.
Setting the clientspec inside single quotes like this works on the console:
/bin/bash -c "p4 -d
/data/local/continuum-1.1-beta-2/apps/continuum/webapp/WEB-INF/working-directory/3
-p perforce.e.secunet.de:1666
-c'hostname-MavenSCM-\data\local\continuum-1.1-beta-2\apps\continuum\webapp\WEB-INF\working-directory\3'
sync -f"
Maybe changing the maven-scm-provider to add single quotes around the
clientspec name might fix this issue.
> Syncing with Perforce on Linux/Unix/Bash fails
> --
>
> Key: CONTINUUM-1402
> URL: http://jira.codehaus.org/browse/CONTINUUM-1402
> Project: Continuum
> Issue Type: Bug
> Components: Integration - Maven 2, SCM
>Affects Versions: 1.1-beta-2
> Environment: Bash
>Reporter: Sebastian Annies
>Priority: Critical
>
> When a client is created it is named:
> E.g.{{monospaced}}
> sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6{{monospaced}}
> that is ok, but now comes the sync command and uses following commandline
> {{monospaced}}
> /bin/bash -c "p4 -d
> /opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
>
> -cbackground-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
> sync"
> {{monospaced}}
> The Bash now removes the backslashes in the client name! The result is that
> the client is not existent and perforce returns with an error.
> I think continuum does everything allright but we need the ticket here to be
> reminded to switch to a new plexus-utils or maven-scm if it is fixed there.
> The Problem starts in 'PerforceCheckOutCommand':
> {{monospaced}}
> public static Commandline createCommandLine(
> PerforceScmProviderRepository repo, File workingDirectory,
> ScmVersion version, String
> specname )
> {
> Commandline command = PerforceScmProvider.createP4Command( repo,
> workingDirectory );
> {color:red}
> command.createArgument().setValue( "-c" + specname );
> {color}
> command.createArgument().setValue( "sync" );
> // Use a simple heuristic to determine if we should use the Force flag
> // on sync. Forcing sync is a HUGE performance hit but is required in
> // rare instances where source is somehow deleted. If the target
> // directory is completely empty, assume a force is required. If
> // not empty, we assume a previous checkout was already done and a
> normal
> // sync will suffice.
> // SCM-110
> String[] files = workingDire
[jira] Issue Comment Edited: (CONTINUUM-1402) Syncing with Perforce on Linux/Unix/Bash fails
[
http://jira.codehaus.org/browse/CONTINUUM-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106308
]
Matthias Wurm edited comment on CONTINUUM-1402 at 9/3/07 1:06 PM:
--
I guess there is a problem with backslashes in the command:
After setting loglevel to debug I've seen that maven-scm wants to do the
following:
{noformat} 2007-09-03 19:55:35,908 [pool-1-thread-1] DEBUG ScmManager:default
- Executing: /bin/bash -c "p4 -d
/data/local/continuum-1.1-beta-2/apps/continuum/webapp/WEB-INF/working-directory/3
-p p4server:1666
-chostname-MavenSCM-\data\local\continuum-1.1-beta-2\apps\continuum\webapp\WEB-INF\working-directory\3
sync -f"{noformat}
Executing the command manually on my console removes the backslashes, hence the
command fails
{noformat}Client
'hostname-MavenSCM-datalocalcontinuum-1.1-beta-2appscontinuumwebappWEB-INFworking-directory2'
unknown - use 'client' command to create it.{noformat}
Setting the clientspec inside single quotes like this works on the console:
{noformat}/bin/bash -c "p4 -d
/data/local/continuum-1.1-beta-2/apps/continuum/webapp/WEB-INF/working-directory/3
-p perforce.e.secunet.de:1666
-c'hostname-MavenSCM-\data\local\continuum-1.1-beta-2\apps\continuum\webapp\WEB-INF\working-directory\3'
sync -f"{noformat}
Maybe changing the maven-scm-provider to add single quotes around the
clientspec name might fix this issue.
was:
I guess there is a problem with backslashes in the command:
After setting loglevel to debug I've seen that maven-scm wants to do the
following:
{noformat} 2007-09-03 19:55:35,908 [pool-1-thread-1] DEBUG ScmManager:default
- Executing: /bin/bash -c "p4 -d
/data/local/continuum-1.1-beta-2/apps/continuum/webapp/WEB-INF/working-directory/3
-p perforce.e.secunet.de:1666
-chostname-MavenSCM-\data\local\continuum-1.1-beta-2\apps\continuum\webapp\WEB-INF\working-directory\3
sync -f"{noformat}
Executing the command manually on my console removes the backslashes, hence the
command fails
{noformat}Client
'hostname-MavenSCM-datalocalcontinuum-1.1-beta-2appscontinuumwebappWEB-INFworking-directory2'
unknown - use 'client' command to create it.{noformat}
Setting the clientspec inside single quotes like this works on the console:
{noformat}/bin/bash -c "p4 -d
/data/local/continuum-1.1-beta-2/apps/continuum/webapp/WEB-INF/working-directory/3
-p perforce.e.secunet.de:1666
-c'hostname-MavenSCM-\data\local\continuum-1.1-beta-2\apps\continuum\webapp\WEB-INF\working-directory\3'
sync -f"{noformat}
Maybe changing the maven-scm-provider to add single quotes around the
clientspec name might fix this issue.
> Syncing with Perforce on Linux/Unix/Bash fails
> --
>
> Key: CONTINUUM-1402
> URL: http://jira.codehaus.org/browse/CONTINUUM-1402
> Project: Continuum
> Issue Type: Bug
> Components: Integration - Maven 2, SCM
>Affects Versions: 1.1-beta-2
> Environment: Bash
>Reporter: Sebastian Annies
>Priority: Critical
>
> When a client is created it is named:
> E.g.{{monospaced}}
> sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6{{monospaced}}
> that is ok, but now comes the sync command and uses following commandline
> {{monospaced}}
> /bin/bash -c "p4 -d
> /opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
>
> -cbackground-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
> sync"
> {{monospaced}}
> The Bash now removes the backslashes in the client name! The result is that
> the client is not existent and perforce returns with an error.
> I think continuum does everything allright but we need the ticket here to be
> reminded to switch to a new plexus-utils or maven-scm if it is fixed there.
> The Problem starts in 'PerforceCheckOutCommand':
> {{monospaced}}
> public static Commandline createCommandLine(
> PerforceScmProviderRepository repo, File workingDirectory,
> ScmVersion version, String
> specname )
> {
> Commandline command = PerforceScmProvider.createP4Command( repo,
> workingDirectory );
> {color:red}
> command.createArgument().setValue( "-c" + specname );
> {color}
> command.createArgument().setValue( "sync" );
> // Use a simple heuristic to determine if we should use the Force flag
> // on sync. Forcing sync is a HUGE performance hit but is required in
> // rare instances where source is somehow deleted. If the target
> // directory is completely empty, assume a force is required. If
> // not empty, we assume a previous checkout was already done and a
> normal
> // sync will suffice.
> //
[jira] Commented: (CONTINUUM-1402) Syncing with Perforce on Linux/Unix/Bash fails
[
http://jira.codehaus.org/browse/CONTINUUM-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106309
]
Sebastian Annies commented on CONTINUUM-1402:
-
I will provide a plexus-utils fix in the next days (perhaps I can even get this
done today)
> Syncing with Perforce on Linux/Unix/Bash fails
> --
>
> Key: CONTINUUM-1402
> URL: http://jira.codehaus.org/browse/CONTINUUM-1402
> Project: Continuum
> Issue Type: Bug
> Components: Integration - Maven 2, SCM
>Affects Versions: 1.1-beta-2
> Environment: Bash
>Reporter: Sebastian Annies
>Priority: Critical
>
> When a client is created it is named:
> E.g.{{monospaced}}
> sannies-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\6{{monospaced}}
> that is ok, but now comes the sync command and uses following commandline
> {{monospaced}}
> /bin/bash -c "p4 -d
> /opt/continuum-1.1-beta-3-SNAPSHOT/apps/continuum/webapp/WEB-INF/working-directory/1
>
> -cbackground-sojus-MavenSCM-\opt\continuum-1.1-beta-3-SNAPSHOT\apps\continuum\webapp\WEB-INF\working-directory\1
> sync"
> {{monospaced}}
> The Bash now removes the backslashes in the client name! The result is that
> the client is not existent and perforce returns with an error.
> I think continuum does everything allright but we need the ticket here to be
> reminded to switch to a new plexus-utils or maven-scm if it is fixed there.
> The Problem starts in 'PerforceCheckOutCommand':
> {{monospaced}}
> public static Commandline createCommandLine(
> PerforceScmProviderRepository repo, File workingDirectory,
> ScmVersion version, String
> specname )
> {
> Commandline command = PerforceScmProvider.createP4Command( repo,
> workingDirectory );
> {color:red}
> command.createArgument().setValue( "-c" + specname );
> {color}
> command.createArgument().setValue( "sync" );
> // Use a simple heuristic to determine if we should use the Force flag
> // on sync. Forcing sync is a HUGE performance hit but is required in
> // rare instances where source is somehow deleted. If the target
> // directory is completely empty, assume a force is required. If
> // not empty, we assume a previous checkout was already done and a
> normal
> // sync will suffice.
> // SCM-110
> String[] files = workingDirectory.list();
> if ( files == null || files.length == 0 )
> {
> // We need to force so checkout to an empty directory will work.
> command.createArgument().setValue( "-f" );
> }
> // Not sure what to do here. I'm unclear whether we should be
> // sync'ing each file individually to the label or just sync the
> // entire contents of the workingDir. I'm going to assume the
> // latter until the exact semantics are clearer.
> if ( version != null && StringUtils.isNotEmpty( version.getName() ) )
> {
> command.createArgument().setValue( "@" + version.getName() );
> }
> return command;
> {{monospaced}}
> The {{monospaced}}specname {{monospaced}} contains the backslashes and is
> these are neither escaped nor quoted! Hmm ... Is that a job that the
> CommandLine should handle? I think so!
> The next thing I will do is to file an issue at plexus-utils and link the
> issues.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-1388) the NOTICE file is overzealous in declaring dependencies
[ http://jira.codehaus.org/browse/CONTINUUM-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106316 ] Emmanuel Venisse commented on CONTINUUM-1388: - Why do you want to remove unnamed software? With the groupId aded in the NOTICE file, user can retrieve the names and check licenses We can use this format: This product includes/uses software(s) developped by the ASF (www.apache.org) -soft1 (url1) -soft2 (url2) ... This product includes/uses software(s) developped by Codehaus (www.codehaus.org) -soft3 (url3) -soft4 (url4) ... > the NOTICE file is overzealous in declaring dependencies > > > Key: CONTINUUM-1388 > URL: http://jira.codehaus.org/browse/CONTINUUM-1388 > Project: Continuum > Issue Type: Improvement >Affects Versions: 1.1-beta-2 >Reporter: Brett Porter > Fix For: 1.1-beta-3 > > > we only need to say, for example, software developed by the ASF once, and all > the unnamed ones don't need to be there. > This might require fixes in the remote reosurces plugin and an update. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-3182) Remove console logging from DefaultMaven
[ http://jira.codehaus.org/browse/MNG-3182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3182: --- Fix Version/s: 2.1-alpha-1 > Remove console logging from DefaultMaven > > > Key: MNG-3182 > URL: http://jira.codehaus.org/browse/MNG-3182 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.1.x >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 2.1-alpha-1 > > > All the console based logging code needs to move to MavenCli. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MNG-3182) Remove console logging from DefaultMaven
[ http://jira.codehaus.org/browse/MNG-3182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MNG-3182 started by Jason van Zyl. > Remove console logging from DefaultMaven > > > Key: MNG-3182 > URL: http://jira.codehaus.org/browse/MNG-3182 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.1.x >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 2.1-alpha-1 > > > All the console based logging code needs to move to MavenCli. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-3182) Remove console logging from DefaultMaven
Remove console logging from DefaultMaven Key: MNG-3182 URL: http://jira.codehaus.org/browse/MNG-3182 Project: Maven 2 Issue Type: Improvement Affects Versions: 2.1.x Reporter: Jason van Zyl Fix For: 2.1-alpha-1 All the console based logging code needs to move to MavenCli. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-3183) Allow a user to specify logging to a text file
Allow a user to specify logging to a text file -- Key: MNG-3183 URL: http://jira.codehaus.org/browse/MNG-3183 Project: Maven 2 Issue Type: Improvement Affects Versions: 2.1.x Reporter: Jason van Zyl Fix For: 2.1-alpha-1 We should have an option to log to text files: mvn -l build.txt clean -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MNG-3183) Allow a user to specify logging to a text file
[ http://jira.codehaus.org/browse/MNG-3183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MNG-3183 started by Jason van Zyl. > Allow a user to specify logging to a text file > -- > > Key: MNG-3183 > URL: http://jira.codehaus.org/browse/MNG-3183 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.1.x >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 2.1-alpha-1 > > > We should have an option to log to text files: mvn -l build.txt clean -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-3183) Allow a user to specify logging to a text file
[ http://jira.codehaus.org/browse/MNG-3183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3183: --- Fix Version/s: 2.1-alpha-1 > Allow a user to specify logging to a text file > -- > > Key: MNG-3183 > URL: http://jira.codehaus.org/browse/MNG-3183 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.1.x >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 2.1-alpha-1 > > > We should have an option to log to text files: mvn -l build.txt clean -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work stopped: (MNG-3183) Allow a user to specify logging to a text file
[ http://jira.codehaus.org/browse/MNG-3183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MNG-3183 stopped by Jason van Zyl. > Allow a user to specify logging to a text file > -- > > Key: MNG-3183 > URL: http://jira.codehaus.org/browse/MNG-3183 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.1.x >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 2.1-alpha-1 > > > We should have an option to log to text files: mvn -l build.txt clean -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MNG-3183) Allow a user to specify logging to a text file
[ http://jira.codehaus.org/browse/MNG-3183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-3183. -- Resolution: Fixed > Allow a user to specify logging to a text file > -- > > Key: MNG-3183 > URL: http://jira.codehaus.org/browse/MNG-3183 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.1.x >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 2.1-alpha-1 > > > We should have an option to log to text files: mvn -l build.txt clean -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work stopped: (MNG-3182) Remove console logging from DefaultMaven
[ http://jira.codehaus.org/browse/MNG-3182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MNG-3182 stopped by Jason van Zyl. > Remove console logging from DefaultMaven > > > Key: MNG-3182 > URL: http://jira.codehaus.org/browse/MNG-3182 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.1.x >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 2.1-alpha-1 > > > All the console based logging code needs to move to MavenCli. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MNG-3182) Remove console logging from DefaultMaven
[ http://jira.codehaus.org/browse/MNG-3182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-3182. -- Resolution: Fixed > Remove console logging from DefaultMaven > > > Key: MNG-3182 > URL: http://jira.codehaus.org/browse/MNG-3182 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.1.x >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 2.1-alpha-1 > > > All the console based logging code needs to move to MavenCli. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2173) support in plugins
[ http://jira.codehaus.org/browse/MNG-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106318 ] Garvin LeClaire commented on MNG-2173: -- I am also interested in having a resolution to this. Garvin Leclaire > support in plugins > - > > Key: MNG-2173 > URL: http://jira.codehaus.org/browse/MNG-2173 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Reporter: John Allen > Fix For: 2.1.x > > > Inconsistency with rest of design. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-256) Skin not applied in 2.0-alpha-6-SNAPSHOT
Skin not applied in 2.0-alpha-6-SNAPSHOT Key: MSITE-256 URL: http://jira.codehaus.org/browse/MSITE-256 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-6 Reporter: Arnaud Heritier The current SNAPSHOT of the maven-site-plugin breaks something in the skin resolution. You can reproduce it by building the web site of this project : http://forge.octo.com/svn/mtg/trunk/grails-maven-plugin There's a custom skin used in it. If you use the version 2.0-alpha-5 for the site plugin in the parent pom you have the site correctly skinned. Not with the 2.0-alpha-6-SNAPSHOT -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-178) APT format needs some "macros" for common constructs such as links to JavaDoc
[
http://jira.codehaus.org/browse/MSITE-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106319
]
Erik Putrycz commented on MSITE-178:
I totally second this idea. Has there been any progress done?
> APT format needs some "macros" for common constructs such as links to JavaDoc
> -
>
> Key: MSITE-178
> URL: http://jira.codehaus.org/browse/MSITE-178
> Project: Maven 2.x Site Plugin
> Issue Type: New Feature
>Reporter: Howard M. Lewis Ship
>Priority: Minor
>
> Some form of macro processing for APT format files would be nice.
> I often find myself writing very verbose links form APT to documentation, i.e.
> {{{apidocs/org/package/MyClass.html}MyClass}}
> (Not that I ever get to use something that terse, more like
> org.apache.tapestry.internal.ioc.RegistryImpl, etc.).
> I would love some alternate link forms, maybe something like:
> {{{api:MyClass}}}
> or
> {{{api:org.package.MyClass}}}
> and let Maven build the links for me.
> I also do some copious cross-linking of my documentation, so something akin
> to the Forrest site: prefix would be great (a way to reference another
> document by a logical id rather than a relative path).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MSITE-256) Skin not applied in 2.0-beta-6-SNAPSHOT
[ http://jira.codehaus.org/browse/MSITE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MSITE-256: -- Description: The current SNAPSHOT of the maven-site-plugin breaks something in the skin resolution. You can reproduce it by building the web site of this project : http://forge.octo.com/svn/mtg/trunk/grails-maven-plugin There's a custom skin used in it. If you use the version 2.0-beta-5 for the site plugin in the parent pom you have the site correctly skinned. Not with the 2.0-beta-6-SNAPSHOT was: The current SNAPSHOT of the maven-site-plugin breaks something in the skin resolution. You can reproduce it by building the web site of this project : http://forge.octo.com/svn/mtg/trunk/grails-maven-plugin There's a custom skin used in it. If you use the version 2.0-alpha-5 for the site plugin in the parent pom you have the site correctly skinned. Not with the 2.0-alpha-6-SNAPSHOT Summary: Skin not applied in 2.0-beta-6-SNAPSHOT (was: Skin not applied in 2.0-alpha-6-SNAPSHOT) > Skin not applied in 2.0-beta-6-SNAPSHOT > --- > > Key: MSITE-256 > URL: http://jira.codehaus.org/browse/MSITE-256 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: Arnaud Heritier > > The current SNAPSHOT of the maven-site-plugin breaks something in the skin > resolution. > You can reproduce it by building the web site of this project : > http://forge.octo.com/svn/mtg/trunk/grails-maven-plugin > There's a custom skin used in it. > If you use the version 2.0-beta-5 for the site plugin in the parent pom you > have the site correctly skinned. > Not with the 2.0-beta-6-SNAPSHOT -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-256) Skin not applied in 2.0-beta-6-SNAPSHOT
[
http://jira.codehaus.org/browse/MSITE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106321
]
Dennis Lundberg commented on MSITE-256:
---
I can't get that project to build properly. First I had to download from
http://forge.octo.com/svn/mtg/trunk/
to get the parent and the skin.
When I run 'mvn site' in .../grails-maven-plugin/ I get this error:
{code}
[ERROR] BUILD ERROR
[INFO]
[INFO] 'merge-descriptors' was specified in an execution, but not found in the
plugin
[INFO]
{code}
I tried building Apache Commons Logging, which also uses a custom skin, and
that project is properly skinned with 2.0-beta-6-SNAPSHOT:
https://svn.apache.org/repos/asf/commons/proper/logging/trunk/
> Skin not applied in 2.0-beta-6-SNAPSHOT
> ---
>
> Key: MSITE-256
> URL: http://jira.codehaus.org/browse/MSITE-256
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-6
>Reporter: Arnaud Heritier
>
> The current SNAPSHOT of the maven-site-plugin breaks something in the skin
> resolution.
> You can reproduce it by building the web site of this project :
> http://forge.octo.com/svn/mtg/trunk/grails-maven-plugin
> There's a custom skin used in it.
> If you use the version 2.0-beta-5 for the site plugin in the parent pom you
> have the site correctly skinned.
> Not with the 2.0-beta-6-SNAPSHOT
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-256) Skin not applied in 2.0-beta-6-SNAPSHOT
[ http://jira.codehaus.org/browse/MSITE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106323 ] Arnaud Heritier commented on MSITE-256: --- yes sorry, I made a bad cut'n paste you have to build all the project http://forge.octo.com/svn/mtg/trunk/ and then you call mvn install site I never had your build error :-( > Skin not applied in 2.0-beta-6-SNAPSHOT > --- > > Key: MSITE-256 > URL: http://jira.codehaus.org/browse/MSITE-256 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: Arnaud Heritier > > The current SNAPSHOT of the maven-site-plugin breaks something in the skin > resolution. > You can reproduce it by building the web site of this project : > http://forge.octo.com/svn/mtg/trunk/grails-maven-plugin > There's a custom skin used in it. > If you use the version 2.0-beta-5 for the site plugin in the parent pom you > have the site correctly skinned. > Not with the 2.0-beta-6-SNAPSHOT -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-256) Skin not applied in 2.0-beta-6-SNAPSHOT
[
http://jira.codehaus.org/browse/MSITE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106327
]
Arnaud Heritier commented on MSITE-256:
---
I don't know if there's a side effect with hudson, because launching the site
generation locally the result is correct.
I added some logs and here is what I have :
Locally :
{code}
[INFO] [site:site]
[DEBUG] Mapped url: E:\OCTO\mtg-trunk\src\site to relative path: src\site
[DEBUG] Reading site descriptor from src\site\site.xml
[DEBUG] Skin used : groupId = 'com.octo.mtg'
artifactId = 'mtg-site-skin'
version = '0.1-SNAPSHOT'
[DEBUG] Attempting to source module information from local filesystem
[DEBUG] Mapped url: http://forge.octo.com/maven/sites/mtg/grails-0.5.6-poms to
relative path: grails-0.5.6-poms
[DEBUG] Mapped url: http://forge.octo.com/maven/sites/mtg/mtg-site-skin to
relative path: mtg-site-skin
[DEBUG] Mapped url: http://forge.octo.com/maven/sites/mtg/grails-maven-plugin
to relative path: grails-maven-plugin
{code}
Hudson :
{code}
[INFO] [site:site]
[DEBUG] Mapped url:
D:\hudson\data\jobs\MavenTools4Grails\workspace\trunk\src\site to relative
path: src\site
[DEBUG] Attempting to source module information from local filesystem
[DEBUG] Mapped url: http://forge.octo.com/maven/sites/mtg/grails-0.5.6-poms to
relative path: grails-0.5.6-poms
[DEBUG] Mapped url: http://forge.octo.com/maven/sites/mtg/mtg-site-skin to
relative path: mtg-site-skin
[DEBUG] Mapped url: http://forge.octo.com/maven/sites/mtg/grails-maven-plugin
to relative path: grails-maven-plugin
{code}
I don't find something different between two envs. same JDK (1.5) and same
maven (2.0.7)
> Skin not applied in 2.0-beta-6-SNAPSHOT
> ---
>
> Key: MSITE-256
> URL: http://jira.codehaus.org/browse/MSITE-256
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-6
>Reporter: Arnaud Heritier
>
> The current SNAPSHOT of the maven-site-plugin breaks something in the skin
> resolution.
> You can reproduce it by building the web site of this project :
> http://forge.octo.com/svn/mtg/trunk/grails-maven-plugin
> There's a custom skin used in it.
> If you use the version 2.0-beta-5 for the site plugin in the parent pom you
> have the site correctly skinned.
> Not with the 2.0-beta-6-SNAPSHOT
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-256) Skin not applied in 2.0-beta-6-SNAPSHOT
[ http://jira.codehaus.org/browse/MSITE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106328 ] Arnaud Heritier commented on MSITE-256: --- The problem isn't only for the skin. All the descriptor isn't read (menu, links, ...) > Skin not applied in 2.0-beta-6-SNAPSHOT > --- > > Key: MSITE-256 > URL: http://jira.codehaus.org/browse/MSITE-256 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: Arnaud Heritier > > The current SNAPSHOT of the maven-site-plugin breaks something in the skin > resolution. > You can reproduce it by building the web site of this project : > http://forge.octo.com/svn/mtg/trunk/grails-maven-plugin > There's a custom skin used in it. > If you use the version 2.0-beta-5 for the site plugin in the parent pom you > have the site correctly skinned. > Not with the 2.0-beta-6-SNAPSHOT -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1424) Ability to Cancel Build for a subset of a project group
[ http://jira.codehaus.org/browse/CONTINUUM-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-1424: Attachment: CONTINUUM-1424 patch attached. Note : I have added some other utilies methods in Continuum for other issues concerning queue(s). Just change the order of the emmanuel's proposal. First remove other checked projects from the queue then cancel the current build (if was checked). > Ability to Cancel Build for a subset of a project group > --- > > Key: CONTINUUM-1424 > URL: http://jira.codehaus.org/browse/CONTINUUM-1424 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Affects Versions: 1.1-beta-2 >Reporter: Wendy Smoak >Assignee: Olivier Lamy > Fix For: 1.1-beta-3 > > Attachments: CONTINUUM-1424 > > > It should be possible to cancel the build for a subset of a project group > using the checkboxes and a new button. > It would be nice if the button did not appear if no builds are in progress. > (This was already implemented for "Delete Project" and "Build Project" in > CONTINUUM-983.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1388) the NOTICE file is overzealous in declaring dependencies
[ http://jira.codehaus.org/browse/CONTINUUM-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106330 ] Brett Porter commented on CONTINUUM-1388: - that'd be good, though I think it's only necessary to list each org once - would need to check. Certainly, we currently have "developed by ASF" at the top as a blanket, and then list a whole lot of ASF software that doesn't need to be. > the NOTICE file is overzealous in declaring dependencies > > > Key: CONTINUUM-1388 > URL: http://jira.codehaus.org/browse/CONTINUUM-1388 > Project: Continuum > Issue Type: Improvement >Affects Versions: 1.1-beta-2 >Reporter: Brett Porter > Fix For: 1.1-beta-3 > > > we only need to say, for example, software developed by the ASF once, and all > the unnamed ones don't need to be there. > This might require fixes in the remote reosurces plugin and an update. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-69) When 'index' and 'addClasspath' are both true, plugin fails.
[
http://jira.codehaus.org/browse/MJAR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106331
]
Rodolfo Rothganger commented on MJAR-69:
I have the same problem, but only when a dependency with "provided" scope is
informed.
Example:
javax.resource
connector-api
1.5
provided
> When 'index' and 'addClasspath' are both true, plugin fails.
>
>
> Key: MJAR-69
> URL: http://jira.codehaus.org/browse/MJAR-69
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Anagnostopoulos Kostis
>
> When both the 'index' and 'addClasspath' are true, the plugin fails to create
> jar with the following msg:
> Embedded error: Problem creating jar: **/target/classes (Is a directory)
> A typical configuration to produce the error would be:
> {code:xml}
>
> maven-jar-plugin
>
>
> true
>
> true
>
>
>
> {code}
> The issue below (about including dependency files in index) claims that it
> introduced this bug:
> http://jira.codehaus.org/browse/MJAR-40
> I'm posting this issue so that to ensure that version 2.2-SNAPSHOT does not
> suffer from the same problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-1323) Plugin extensions (dependencies) not resolved in reactor build
[ http://jira.codehaus.org/browse/MNG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Tabor updated MNG-1323: - Attachment: MNG-1323-components-2.0.x.diff Patch for this issue for 2.0.x. All it's passed. > Plugin extensions (dependencies) not resolved in reactor build > -- > > Key: MNG-1323 > URL: http://jira.codehaus.org/browse/MNG-1323 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Kenney Westerhof > Fix For: 2.0.x > > Attachments: MNG-1323-components-2.0.x.diff, > MNG-1323-core-integration-tests.diff > > > I've added a dependency on an Ant Task in > project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/ > and run that anttask using the antrun plugin. > When run from the project dir itself it runs fine. > When running from the root of the project tree (reactor build, project one > level below root), > antrun bails out because the taskdef can't be found (not on classpath). > It looks like the dependency isn't resolved, or not added to the plugins' > classrealm. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1323) Plugin extensions (dependencies) not resolved in reactor build
[ http://jira.codehaus.org/browse/MNG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Tabor updated MNG-1323: - Attachment: MNG-1323-core-integration-testing.diff It test for this issue. Actualized to current tests numeration (127) > Plugin extensions (dependencies) not resolved in reactor build > -- > > Key: MNG-1323 > URL: http://jira.codehaus.org/browse/MNG-1323 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Kenney Westerhof > Fix For: 2.0.x > > Attachments: MNG-1323-components-2.0.x.diff, > MNG-1323-core-integration-testing.diff, MNG-1323-core-integration-tests.diff > > > I've added a dependency on an Ant Task in > project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/ > and run that anttask using the antrun plugin. > When run from the project dir itself it runs fine. > When running from the root of the project tree (reactor build, project one > level below root), > antrun bails out because the taskdef can't be found (not on classpath). > It looks like the dependency isn't resolved, or not added to the plugins' > classrealm. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1323) Plugin extensions (dependencies) not resolved in reactor build
[ http://jira.codehaus.org/browse/MNG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Tabor updated MNG-1323: - Attachment: MNG-1323-core-integration-testing-2.diff Corrected one thing in it. > Plugin extensions (dependencies) not resolved in reactor build > -- > > Key: MNG-1323 > URL: http://jira.codehaus.org/browse/MNG-1323 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Kenney Westerhof > Fix For: 2.0.x > > Attachments: MNG-1323-components-2.0.x.diff, > MNG-1323-core-integration-testing-2.diff, > MNG-1323-core-integration-testing.diff, MNG-1323-core-integration-tests.diff > > > I've added a dependency on an Ant Task in > project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/ > and run that anttask using the antrun plugin. > When run from the project dir itself it runs fine. > When running from the root of the project tree (reactor build, project one > level below root), > antrun bails out because the taskdef can't be found (not on classpath). > It looks like the dependency isn't resolved, or not added to the plugins' > classrealm. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2771) Provide a means of loading custom substitute components instead of default Maven components
[ http://jira.codehaus.org/browse/MNG-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2771: --- Fix Version/s: (was: 2.1-alpha-1) 2.1-alpha-2 > Provide a means of loading custom substitute components instead of default > Maven components > --- > > Key: MNG-2771 > URL: http://jira.codehaus.org/browse/MNG-2771 > Project: Maven 2 > Issue Type: New Feature > Components: General >Affects Versions: 2.0.4 >Reporter: John Casey >Assignee: Kenney Westerhof > Fix For: 2.1-alpha-2 > > > At times, it is necessary to use different mechanisms for resolving > artifacts, building projects, etc. Since Maven is built on component-oriented > technology, it should be possible to substitute the component implementation > used for these tasks. Yet this is currently impossible. > We need a mechanism for specifying, resolving, loading, and using custom > components during the build process. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-3185) Release Maven Artifact 3.0-alpha-1
Release Maven Artifact 3.0-alpha-1 -- Key: MNG-3185 URL: http://jira.codehaus.org/browse/MNG-3185 Project: Maven 2 Issue Type: Task Affects Versions: 2.1-alpha-1 Reporter: Jason van Zyl -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-3184) Doxia Release 1.0-alpha-9
[ http://jira.codehaus.org/browse/MNG-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3184: --- Fix Version/s: 2.1-alpha-1 Summary: Doxia Release 1.0-alpha-9 (was: Doxia Release) > Doxia Release 1.0-alpha-9 > - > > Key: MNG-3184 > URL: http://jira.codehaus.org/browse/MNG-3184 > Project: Maven 2 > Issue Type: Task >Affects Versions: 2.1-alpha-1 >Reporter: Jason van Zyl > Fix For: 2.1-alpha-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] Created: (MNG-3184) Doxia Release
Doxia Release - Key: MNG-3184 URL: http://jira.codehaus.org/browse/MNG-3184 Project: Maven 2 Issue Type: Task Affects Versions: 2.1-alpha-1 Reporter: Jason van Zyl Fix For: 2.1-alpha-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] Updated: (MNG-3185) Release Maven Artifact 3.0-alpha-1
[ http://jira.codehaus.org/browse/MNG-3185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3185: --- Fix Version/s: 2.1-alpha-1 > Release Maven Artifact 3.0-alpha-1 > -- > > Key: MNG-3185 > URL: http://jira.codehaus.org/browse/MNG-3185 > Project: Maven 2 > Issue Type: Task >Affects Versions: 2.1-alpha-1 >Reporter: Jason van Zyl > Fix For: 2.1-alpha-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] Updated: (MNG-3186) First iteration of concise, user-centric error reporting
[ http://jira.codehaus.org/browse/MNG-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3186: --- Fix Version/s: 2.1-alpha-1 > First iteration of concise, user-centric error reporting > > > Key: MNG-3186 > URL: http://jira.codehaus.org/browse/MNG-3186 > Project: Maven 2 > Issue Type: New Feature > Components: Embedding >Reporter: Jason van Zyl > Fix For: 2.1-alpha-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] Commented: (MRELEASE-260) Profiles given on command-line not added to exec.additionalArguments
[
http://jira.codehaus.org/browse/MRELEASE-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106340
]
Matt Ryall commented on MRELEASE-260:
-
A simpler workaround is to use the -Darguments system property for the
release:perform step like so:
{noformat}
mvn release:perform -Darguments=-Pprivate
{noformat}
> Profiles given on command-line not added to exec.additionalArguments
>
>
> Key: MRELEASE-260
> URL: http://jira.codehaus.org/browse/MRELEASE-260
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-6
>Reporter: Matt Ryall
>
> In my POM, I have two distribution management sections, each in a separate
> profile:
> {code:xml}
> ...
>
>
> private
>
>
> private-repository
> scp://repository.example.com/opt/mvn/private
>
>
>
>
> public
>
>
> public-repository
> scp://repository.example.com/opt/mvn/public
>
>
>
>
> {code}
> Running {{mvn release:prepare -Ppublic}} puts the following line in
> release.properties:
> {{exec.additionalArguments=-P default-profile,default-profile}}
> (The profile "default-profile" is the profile in my settings.xml which is
> active by default.)
> If the release plugin was working correctly, this line would be:
> {{exec.additionalArguments=-P default-profile,public}}
> In earlier betas, I believe this worked correctly. The workaround I'm using
> is to run {{mvn release:prepare}}, then {{mvn release:perform}}. The second
> command fails, and I go to {{target/checkout}}, and run {{mvn deploy
> -Ppublic}} manually.
> Changing {{release.properties}} doesn't work, either. It seems like
> {{release:perform}} uses its own list of profiles, not the ones in the
> properties file.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MJAR-83) addClasspath is not respected for runtime dependencies
addClasspath is not respected for runtime dependencies
--
Key: MJAR-83
URL: http://jira.codehaus.org/browse/MJAR-83
Project: Maven 2.x Jar Plugin
Issue Type: Bug
Affects Versions: 2.1, 2.2
Reporter: William Ferguson
Attachments: pom.xml
maven-jar-plugin does not resolve dependencies itself, so specifying
{code}
true
{code}
will add no dependencies for
{noformat}
mvn jar:jar
{noformat}
And even
{noformat}
mvn compiler:compile jar:jar
{noformat}
will only add compile time dependencies, not runtime dependencies, presumably
because the maven-compiler-plugin causes resolution of the compile time
dependencies.
See the attached POM.
There is *no* manifest classpath generated by
{noformat}
mvn jar:jar
{noformat}
The manifest classpath generated by
{noformat}
mvn compiler:compile jar:jar
{noformat}
only contains commons-codec which is the compile time dependency.
There needs to be a way to add runtime dependences to the manifest classpath of
the jar.
And preferably not requiring some other plugin to resolve the dependencies
first.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-83) addClasspath is not respected for runtime dependencies
[
http://jira.codehaus.org/browse/MJAR-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106345
]
William Ferguson commented on MJAR-83:
--
The workaround for this is to
* List all deps with a scope of compile
* Execute *mvn* *compiler:compile* *jar:jar*
Neither of is nice and both of which is required.
NB I forgot to say why we need to create a Jar with no content other than a
manifest classpath.
Its because the Windows line length limit precludes classpaths that are too
long, so we generate a Jar with a manifest classpath that includes all the
target libraries and just include it.
But its seems like a problem in the general sense in any case.
> addClasspath is not respected for runtime dependencies
> --
>
> Key: MJAR-83
> URL: http://jira.codehaus.org/browse/MJAR-83
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.1, 2.2
>Reporter: William Ferguson
> Attachments: pom.xml
>
>
> maven-jar-plugin does not resolve dependencies itself, so specifying
> {code}
>
>
>
> true
>
>
>
> {code}
> will add no dependencies for
> {noformat}
> mvn jar:jar
> {noformat}
> And even
> {noformat}
> mvn compiler:compile jar:jar
> {noformat}
> will only add compile time dependencies, not runtime dependencies, presumably
> because the maven-compiler-plugin causes resolution of the compile time
> dependencies.
> See the attached POM.
> There is *no* manifest classpath generated by
> {noformat}
> mvn jar:jar
> {noformat}
> The manifest classpath generated by
> {noformat}
> mvn compiler:compile jar:jar
> {noformat}
> only contains commons-codec which is the compile time dependency.
> There needs to be a way to add runtime dependences to the manifest classpath
> of the jar.
> And preferably not requiring some other plugin to resolve the dependencies
> first.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-3187) Move out the scripting modules from the core
Move out the scripting modules from the core Key: MNG-3187 URL: http://jira.codehaus.org/browse/MNG-3187 Project: Maven 2 Issue Type: Task Reporter: Jason van Zyl The ant and beanshell stuff can be placed outside of the core. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-3186) First iteration of concise, user-centric error reporting
First iteration of concise, user-centric error reporting Key: MNG-3186 URL: http://jira.codehaus.org/browse/MNG-3186 Project: Maven 2 Issue Type: New Feature Components: Embedding Reporter: Jason van Zyl Fix For: 2.1-alpha-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: (MNG-3187) Move out the scripting modules from the core
[ http://jira.codehaus.org/browse/MNG-3187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-3187. -- Resolution: Fixed Moved. > Move out the scripting modules from the core > > > Key: MNG-3187 > URL: http://jira.codehaus.org/browse/MNG-3187 > Project: Maven 2 > Issue Type: Task >Reporter: Jason van Zyl >Assignee: Jason van Zyl > > The ant and beanshell stuff can be placed outside of the core. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MJAR-83) addClasspath is not respected for runtime dependencies
[
http://jira.codehaus.org/browse/MJAR-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106350
]
William Ferguson edited comment on MJAR-83 at 9/3/07 10:29 PM:
---
The patch adds @requiresDependencyResolution tags of *runtime* to
* JarMojo
* JarSignMojo
* JarSignVerifyMojo
And a @requiresDependencyResolution tag of *test* to
* TestJarMojo
I tried to put together a test case, but the existing test cases were not
particualrly helpful as a starting point. To test you need to ensure that with
the dependency list shown below, only commons-code and commons-io appear in
the manifest classpath for jar:jar etc.
{code}
commons-codec
commons-codec
compile
1.3
commons-io
commons-io
runtime
1.2
commons-lang
commons-lang
provided
2.1
commons-logging
commons-logging
test
1.0.4
{code}
was:
The patch adds @requiresDependencyResolution tags of *runtime* to
* JarMojo
* JarSignMojo
* JarSignVerifyMojo
And a @requiresDependencyResolution tag of *test* to
* TestJarMojo
I tried to put together a test case, but the existing test cases were not
particualrly helpful as a starting point. To test you need to ensure that with
the dependency list shown below, only commons-code and commons-io appear in
the manifest classpath for jar:jar etc.
{code}
commons-codec
commons-codec
compile
1.3
commons-io
commons-io
runtime
1.2
commons-lang
commons-lang
provided
2.1
commons-logging
commons-logging
test
1.0.4
{code}
> addClasspath is not respected for runtime dependencies
> --
>
> Key: MJAR-83
> URL: http://jira.codehaus.org/browse/MJAR-83
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.1, 2.2
>Reporter: William Ferguson
> Attachments: patch.txt, pom.xml
>
>
> maven-jar-plugin does not resolve dependencies itself, so specifying
> {code}
>
>
>
> true
>
>
>
> {code}
> will add no dependencies for
> {noformat}
> mvn jar:jar
> {noformat}
> And even
> {noformat}
> mvn compiler:compile jar:jar
> {noformat}
> will only add compile time dependencies, not runtime dependencies, presumably
> because the maven-compiler-plugin causes resolution of the compile time
> dependencies.
> See the attached POM.
> There is *no* manifest classpath generated by
> {noformat}
> mvn jar:jar
> {noformat}
> The manifest classpath generated by
> {noformat}
> mvn compiler:compile jar:jar
> {noformat}
> only contains commons-codec which is the compile time dependency.
> There needs to be a way to add runtime dependences to the manifest classpath
> of the jar.
> And preferably not requiring some other plugin to resolve the dependencies
> first.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MJAR-83) addClasspath is not respected for runtime dependencies
[
http://jira.codehaus.org/browse/MJAR-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Ferguson updated MJAR-83:
-
Attachment: patch.txt
The patch adds @requiresDependencyResolution tags of *runtime* to
* JarMojo
* JarSignMojo
* JarSignVerifyMojo
And a @requiresDependencyResolution tag of *test* to
* TestJarMojo
I tried to put together a test case, but the existing test cases were not
particualrly helpful as a starting point. To test you need to ensure that with
the dependency list shown below, only commons-code and commons-io appear in
the manifest classpath for jar:jar etc.
{code}
commons-codec
commons-codec
compile
1.3
commons-io
commons-io
runtime
1.2
commons-lang
commons-lang
provided
2.1
commons-logging
commons-logging
test
1.0.4
{code}
> addClasspath is not respected for runtime dependencies
> --
>
> Key: MJAR-83
> URL: http://jira.codehaus.org/browse/MJAR-83
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.1, 2.2
>Reporter: William Ferguson
> Attachments: patch.txt, pom.xml
>
>
> maven-jar-plugin does not resolve dependencies itself, so specifying
> {code}
>
>
>
> true
>
>
>
> {code}
> will add no dependencies for
> {noformat}
> mvn jar:jar
> {noformat}
> And even
> {noformat}
> mvn compiler:compile jar:jar
> {noformat}
> will only add compile time dependencies, not runtime dependencies, presumably
> because the maven-compiler-plugin causes resolution of the compile time
> dependencies.
> See the attached POM.
> There is *no* manifest classpath generated by
> {noformat}
> mvn jar:jar
> {noformat}
> The manifest classpath generated by
> {noformat}
> mvn compiler:compile jar:jar
> {noformat}
> only contains commons-codec which is the compile time dependency.
> There needs to be a way to add runtime dependences to the manifest classpath
> of the jar.
> And preferably not requiring some other plugin to resolve the dependencies
> first.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-1323) Plugin extensions (dependencies) not resolved in reactor build
[ http://jira.codehaus.org/browse/MNG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106351 ] Piotr Tabor commented on MNG-1323: -- Integration test was committed by Jason van Zyl. > Plugin extensions (dependencies) not resolved in reactor build > -- > > Key: MNG-1323 > URL: http://jira.codehaus.org/browse/MNG-1323 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Kenney Westerhof > Fix For: 2.0.x > > Attachments: MNG-1323-components-2.0.x.diff, > MNG-1323-core-integration-testing-2.diff, > MNG-1323-core-integration-testing.diff, MNG-1323-core-integration-tests.diff > > > I've added a dependency on an Ant Task in > project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/ > and run that anttask using the antrun plugin. > When run from the project dir itself it runs fine. > When running from the root of the project tree (reactor build, project one > level below root), > antrun bails out because the taskdef can't be found (not on classpath). > It looks like the dependency isn't resolved, or not added to the plugins' > classrealm. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-1323) Plugin extensions (dependencies) not resolved in reactor build
[ http://jira.codehaus.org/browse/MNG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106334 ] Piotr Tabor edited comment on MNG-1323 at 9/3/07 10:45 PM: --- Corrected one thing in Integration Test. was: Corrected one thing in it. > Plugin extensions (dependencies) not resolved in reactor build > -- > > Key: MNG-1323 > URL: http://jira.codehaus.org/browse/MNG-1323 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Kenney Westerhof > Fix For: 2.0.x > > Attachments: MNG-1323-components-2.0.x.diff, > MNG-1323-core-integration-testing-2.diff, > MNG-1323-core-integration-testing.diff, MNG-1323-core-integration-tests.diff > > > I've added a dependency on an Ant Task in > project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/ > and run that anttask using the antrun plugin. > When run from the project dir itself it runs fine. > When running from the root of the project tree (reactor build, project one > level below root), > antrun bails out because the taskdef can't be found (not on classpath). > It looks like the dependency isn't resolved, or not added to the plugins' > classrealm. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1701) Add scripts to sync AppFuse release repository
Add scripts to sync AppFuse release repository -- Key: MAVENUPLOAD-1701 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1701 Project: maven-upload-requests Issue Type: Wish Reporter: Matt Raible Contegix manages the static.appfuse.org and they've confirmed the public key is in place. AppFuse Core: - #!/bin/sh CONTACTS="[EMAIL PROTECTED]" MODE=rsync_ssh [EMAIL PROTECTED]:/var/www/appfuse-releases GROUP_DIR=org/appfuse/ AppFuse Maven Plugin: - #!/bin/sh CONTACTS="[EMAIL PROTECTED]" MODE=rsync_ssh [EMAIL PROTECTED]:/var/www/appfuse-releases GROUP_DIR=org/codehaus/mojo/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
