[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
