[jira] Commented: (MWAR-182) warSourceIncludes no longer works
[ http://jira.codehaus.org/browse/MWAR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165322#action_165322 ] Jason Pringle commented on MWAR-182: Agreed, adding a corresponding parameter would allow precise control over what JARs should be packaged into an "almost skinny" WAR. > warSourceIncludes no longer works > - > > Key: MWAR-182 > URL: http://jira.codehaus.org/browse/MWAR-182 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.1-alpha-2 > Environment: RHEL 3 >Reporter: Bryan Loofbourrow > Attachments: pom.xml > > > The element no longer seems to work, as of 2.1-alpha-2. > It does seem to work in 2.1-alpha-1. I am attaching a pom.xml file which will > demonstrate the problem when used as follows: > 1) From the directory containing the pom.xml, create a web.xml, because > otherwise it fails (setting failsOnMissingWebXml didn't seem to do the trick): > mkdir -p src/main/webapp/WEB-INF > touch src/main/webapp/WEB-INF/web.xml > 2) Build with the 2.1-alpha-1 plugin > mvn clean install -Dwar.plugin.version=2.1-alpha-1 > 3) Dump out the jar contents to verify that only commons-logging and the > web.xml were packaged, as requested > [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war > META-INF/ > META-INF/MANIFEST.MF > WEB-INF/ > WEB-INF/web.xml > WEB-INF/lib/ > WEB-INF/lib/commons-logging-1.1.jar > META-INF/maven/ > META-INF/maven/example/ > META-INF/maven/example/example-war/ > META-INF/maven/example/example-war/pom.xml > META-INF/maven/example/example-war/pom.properties > 4) Now build using the 2.1-alpha-2 plugin version: > mvn clean install -Dwar.plugin.version=2.1-alpha-2 > 5) Dump out the jar contents and notice that warSourceIncludes was ignored > this time: > [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war > META-INF/ > META-INF/MANIFEST.MF > WEB-INF/ > WEB-INF/classes/ > WEB-INF/lib/ > WEB-INF/web.xml > WEB-INF/lib/commons-logging-1.1.jar > WEB-INF/lib/log4j-1.2.12.jar > WEB-INF/lib/logkit-1.0.1.jar > WEB-INF/lib/avalon-framework-4.1.3.jar > WEB-INF/lib/servlet-api-2.3.jar > META-INF/maven/ > META-INF/maven/example/ > META-INF/maven/example/example-war/ > META-INF/maven/example/example-war/pom.xml > META-INF/maven/example/example-war/pom.properties -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1351) Acnnot checkout sources - perforce.
[ http://jira.codehaus.org/browse/CONTINUUM-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106024 ] Jason Pringle commented on CONTINUUM-1351: -- This may be related to CONTINUUM-1402. I see the same error, but do see that the clients exist (check with p4 clients). If I copy/paste the command into a terminal (and escape it) it seems to work. Also, I haven't seen any changes in the perforceSCM provider in quite some time, so suspect something within Continuum is causing the issue (probably something that changed between alpha-2 and beta-1). > Acnnot checkout sources - perforce. > --- > > Key: CONTINUUM-1351 > URL: http://jira.codehaus.org/browse/CONTINUUM-1351 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-1 > Environment: Linux >Reporter: Duncan McNaught > > The pom files work in 1.1-alpha-2 but after creating a new 1.1-beta-1 release > I get the following build error: > Exception: > Cannot checkout sources. > Index: 0, Size: 0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (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_106023 ] Jason Pringle commented on CONTINUUM-1402: -- This may be related to CONTINUUM-1351. I see the same error, but do see that the clients exist (check with p4 clients). If I copy/paste the command into a terminal (and escape it) it seems to work. Also, I haven't seen any changes in the perforceSCM provider in quite some time, so suspect something within Continuum is causing the issue (probably something that changed between alpha-2 and beta-1). > 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] Created: (SCM-324) tag (label) should support revision-based tags
tag (label) should support revision-based tags -- Key: SCM-324 URL: http://jira.codehaus.org/browse/SCM-324 Project: Maven SCM Issue Type: Improvement Components: maven-scm-provider-perforce Reporter: Jason Pringle Perforce offers labels that are based on a revision specifier which providers higher-peformance within the perforce system. When performing a release via maven-release-plugin, It would be extremely nice to be able to leverage these types of labels due to their performance benefit. I'd even be willing to jump in and provide a patch etc, but would need a bit of guidance on how to extend the existing tag command implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira