[continuum build - FAILED - update] Mon Sep 19 15:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050919.15.txt
[continuum build - FAILED - update] Mon Sep 19 16:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050919.16.txt
[continuum build - FAILED - update] Mon Sep 19 16:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050919.163000.txt
[continuum build - FAILED - update] Mon Sep 19 17:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050919.170001.txt
[continuum build - FAILED - update] Mon Sep 19 17:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050919.173000.txt
[jira] Commented: (CONTINUUM-245) Define what default information Continuum should populate on its first startup
[ http://jira.codehaus.org/browse/CONTINUUM-245?page=comments#action_46671 ] Trygve Laugstol commented on CONTINUUM-245: --- o The company logo should default to the Maven logo, the empty field in the upper left corner with a (text) link to Maven looks strange. Define what default information Continuum should populate on its first startup -- Key: CONTINUUM-245 URL: http://jira.codehaus.org/browse/CONTINUUM-245 Project: Continuum Type: Task Reporter: Jason van Zyl Fix For: 1.0-beta-1 Continuum is becoming more configurable but it would still be nice if Continuum could run out of the box by picking up system information like the: o JDK (the one used to run Continuum) o Default schedule (hourly is probably fine using update mode) o Ant o Maven 1.x o Maven 2.x -- 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
[continuum build - FAILED - update] Tue Sep 20 02:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050920.02.txt
[continuum build - SUCCESS - update] Tue Sep 20 03:30:00 GMT 2005
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20050920.033000.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050920.033000.txt
[jira] Updated: (MNG-871) propagate the type attribute of a pom up to the dependency when dependency doesn't specify it
[ http://jira.codehaus.org/browse/MNG-871?page=all ] Stephane Nicoll updated MNG-871: Comment: was deleted propagate the type attribute of a pom up to the dependency when dependency doesn't specify it - Key: MNG-871 URL: http://jira.codehaus.org/browse/MNG-871 Project: Maven 2 Type: Bug Components: maven-core Reporter: Adam Hardy Using maven-ear-plugin, I have two dependencies in my project and I left out the types when I declared the dependencies. maven-ear-plugin generated an application.xml descriptor for the EAR file, but left out the module declarations which it should have generated for the EJB dependencies, because the dependency types defaulted to JAR. The dependencies are not updated to reflect the type of the pom associated with it, and hence type has to be specified, yet it is possible to leave it out. However, since the type information is available in the pom, it would be very convenient if m2 just propagated that back to the dependency. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-871) propagate the type attribute of a pom up to the dependency when dependency doesn't specify it
[ http://jira.codehaus.org/browse/MNG-871?page=comments#action_46648 ] Stephane Nicoll commented on MNG-871: - I don't think so. propagate the type attribute of a pom up to the dependency when dependency doesn't specify it - Key: MNG-871 URL: http://jira.codehaus.org/browse/MNG-871 Project: Maven 2 Type: Bug Components: maven-core Reporter: Adam Hardy Using maven-ear-plugin, I have two dependencies in my project and I left out the types when I declared the dependencies. maven-ear-plugin generated an application.xml descriptor for the EAR file, but left out the module declarations which it should have generated for the EJB dependencies, because the dependency types defaulted to JAR. The dependencies are not updated to reflect the type of the pom associated with it, and hence type has to be specified, yet it is possible to leave it out. However, since the type information is available in the pom, it would be very convenient if m2 just propagated that back to the dependency. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-871) propagate the type attribute of a pom up to the dependency when dependency doesn't specify it
[ http://jira.codehaus.org/browse/MNG-871?page=comments#action_46649 ] Stephane Nicoll commented on MNG-871: - Is there an outstanding issue with the ear plugin to resolve here, I don't think so. propagate the type attribute of a pom up to the dependency when dependency doesn't specify it - Key: MNG-871 URL: http://jira.codehaus.org/browse/MNG-871 Project: Maven 2 Type: Bug Components: maven-core Reporter: Adam Hardy Using maven-ear-plugin, I have two dependencies in my project and I left out the types when I declared the dependencies. maven-ear-plugin generated an application.xml descriptor for the EAR file, but left out the module declarations which it should have generated for the EJB dependencies, because the dependency types defaulted to JAR. The dependencies are not updated to reflect the type of the pom associated with it, and hence type has to be specified, yet it is possible to leave it out. However, since the type information is available in the pom, it would be very convenient if m2 just propagated that back to the dependency. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r290069 - in /maven/components/trunk/sandbox/repoclean: ./ src/main/java/org/apache/maven/tools/repoclean/artifact/ src/main/java/org/apache/maven/tools/repoclean/digest/ src/main/java/org/apache/maven/tools/repoclean/phase/
Author: brett
Date: Sun Sep 18 23:30:04 2005
New Revision: 290069
URL: http://svn.apache.org/viewcvs?rev=290069view=rev
Log:
enable repo clean for new metadata
Removed:
maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/artifact/
maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/digest/DigestVerificationException.java
Modified:
maven/components/trunk/sandbox/repoclean/pom.xml
maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/phase/RewritePhase.java
Modified: maven/components/trunk/sandbox/repoclean/pom.xml
URL:
http://svn.apache.org/viewcvs/maven/components/trunk/sandbox/repoclean/pom.xml?rev=290069r1=290068r2=290069view=diff
==
--- maven/components/trunk/sandbox/repoclean/pom.xml (original)
+++ maven/components/trunk/sandbox/repoclean/pom.xml Sun Sep 18 23:30:04 2005
@@ -34,6 +34,11 @@
/dependency
dependency
groupIdorg.apache.maven/groupId
+ artifactIdmaven-project/artifactId
+ version2.0-beta-1/version
+/dependency
+dependency
+ groupIdorg.apache.maven/groupId
artifactIdmaven-artifact-manager/artifactId
version2.0-beta-1/version
/dependency
Modified:
maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/phase/RewritePhase.java
URL:
http://svn.apache.org/viewcvs/maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/phase/RewritePhase.java?rev=290069r1=290068r2=290069view=diff
==
---
maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/phase/RewritePhase.java
(original)
+++
maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/phase/RewritePhase.java
Sun Sep 18 23:30:04 2005
@@ -18,12 +18,15 @@
import org.apache.maven.artifact.Artifact;
import org.apache.maven.artifact.metadata.ArtifactMetadata;
-import org.apache.maven.artifact.metadata.ReleaseArtifactMetadata;
-import org.apache.maven.artifact.metadata.SnapshotArtifactMetadata;
import org.apache.maven.artifact.repository.ArtifactRepository;
import org.apache.maven.artifact.repository.layout.ArtifactRepositoryLayout;
+import
org.apache.maven.artifact.repository.metadata.ArtifactRepositoryMetadata;
+import org.apache.maven.artifact.repository.metadata.Metadata;
+import
org.apache.maven.artifact.repository.metadata.SnapshotArtifactRepositoryMetadata;
+import
org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Reader;
+import
org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Writer;
+import org.apache.maven.project.artifact.ProjectArtifactMetadata;
import org.apache.maven.tools.repoclean.RepositoryCleanerConfiguration;
-import org.apache.maven.tools.repoclean.artifact.metadata.ProjectMetadata;
import org.apache.maven.tools.repoclean.digest.DigestException;
import org.apache.maven.tools.repoclean.digest.DigestVerifier;
import org.apache.maven.tools.repoclean.report.ReportWriteException;
@@ -40,6 +43,7 @@
import org.codehaus.plexus.logging.Logger;
import org.codehaus.plexus.personality.plexus.lifecycle.phase.Contextualizable;
import org.codehaus.plexus.util.IOUtil;
+import org.codehaus.plexus.util.xml.pull.XmlPullParserException;
import java.io.BufferedInputStream;
import java.io.BufferedOutputStream;
@@ -51,7 +55,9 @@
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
+import java.io.Reader;
import java.io.StringReader;
+import java.io.Writer;
import java.net.MalformedURLException;
import java.net.URL;
import java.util.ArrayList;
@@ -208,27 +214,25 @@
Reporter artifactReporter, boolean
reportOnly )
throws Exception
{
-// SNAPSHOT metadata
-ArtifactMetadata snapshot = new SnapshotArtifactMetadata( artifact );
+ArtifactMetadata metadata = new ArtifactRepositoryMetadata( artifact );
-File snapshotSource = new File( sourceBase,
sourceRepo.pathOfArtifactMetadata( snapshot ) );
-File snapshotTarget = new File( targetBase,
targetRepo.pathOfArtifactMetadata( snapshot ) );
+File metadataSource = new File( sourceBase,
sourceRepo.pathOfRemoteRepositoryMetadata( metadata ) );
+File metadataTarget = new File( targetBase,
targetRepo.pathOfRemoteRepositoryMetadata( metadata ) );
-freshenSupplementalMetadata( snapshotSource, snapshotTarget,
transaction, artifactReporter, reportOnly );
+mergeMetadata( metadataSource, metadataTarget, transaction,
artifactReporter, reportOnly );
-// RELEASE metadata
-ArtifactMetadata release = new ReleaseArtifactMetadata( artifact );
+metadata = new SnapshotArtifactRepositoryMetadata( artifact );
-File
svn commit: r290070 - in /maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean: RepositoryCleaner.java report/AbstractReporter.java report/FileReporter.java
Author: brett
Date: Sun Sep 18 23:44:12 2005
New Revision: 290070
URL: http://svn.apache.org/viewcvs?rev=290070view=rev
Log:
refactor reporter
Added:
maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/report/AbstractReporter.java
(with props)
Modified:
maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/RepositoryCleaner.java
maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/report/FileReporter.java
Modified:
maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/RepositoryCleaner.java
URL:
http://svn.apache.org/viewcvs/maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/RepositoryCleaner.java?rev=290070r1=290069r2=290070view=diff
==
---
maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/RepositoryCleaner.java
(original)
+++
maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/RepositoryCleaner.java
Sun Sep 18 23:44:12 2005
@@ -23,6 +23,7 @@
import org.apache.maven.tools.repoclean.phase.DiscoveryPhase;
import org.apache.maven.tools.repoclean.phase.RewritePhase;
import org.apache.maven.tools.repoclean.report.FileReporter;
+import org.apache.maven.tools.repoclean.report.Reporter;
import org.codehaus.plexus.PlexusConstants;
import org.codehaus.plexus.PlexusContainer;
import org.codehaus.plexus.context.Context;
@@ -78,7 +79,7 @@
{
Logger logger = getLogger();
-FileReporter repoReporter = null;
+Reporter repoReporter = null;
try
{
repoReporter = new FileReporter( reportsBase,
repository.report.txt,
Added:
maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/report/AbstractReporter.java
URL:
http://svn.apache.org/viewcvs/maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/report/AbstractReporter.java?rev=290070view=auto
==
---
maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/report/AbstractReporter.java
(added)
+++
maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/report/AbstractReporter.java
Sun Sep 18 23:44:12 2005
@@ -0,0 +1,125 @@
+package org.apache.maven.tools.repoclean.report;
+
+/*
+ * Copyright 2001-2005 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+import java.io.PrintWriter;
+import java.io.StringWriter;
+
+/**
+ * Base implementation of reporter.
+ *
+ * @author a href=mailto:[EMAIL PROTECTED]Brett Porter/a
+ * @version $Id$
+ */
+public abstract class AbstractReporter
+implements Reporter
+{
+protected static final String WARN_LEVEL = [WARNING];
+
+protected static final String ERROR_LEVEL = [ERROR];
+
+protected boolean hasError;
+
+protected boolean hasWarning;
+
+protected final boolean warningsEnabled;
+
+protected AbstractReporter( boolean warningsEnabled )
+{
+this.warningsEnabled = warningsEnabled;
+}
+
+public boolean hasWarning()
+{
+return hasWarning;
+}
+
+public boolean hasError()
+{
+return hasError;
+}
+
+protected String getSourceLine()
+{
+NullPointerException npe = new NullPointerException();
+
+StackTraceElement element = npe.getStackTrace()[2];
+
+return Reported from: ( + element.getClassName() + . +
element.getMethodName() + (..): +
+element.getLineNumber() + )\n;
+}
+
+protected String format( String level, String source, String message )
+{
+return format( level, source, message, null );
+}
+
+protected String format( String level, String source, String message,
Throwable error )
+{
+StringBuffer buffer = new StringBuffer();
+buffer.append( level );
+buffer.append( );
+buffer.append( source );
+buffer.append( );
+buffer.append( message );
+if ( error != null )
+{
+buffer.append( formatThrowable( error ) );
+}
+return buffer.toString();
+}
+
+private String formatThrowable( Throwable throwable )
[maven2 build - FAILED - update] Mon Sep 19 06:30:01 GMT 2005
Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20050919.063001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (CONTINUUM-313) Cancel button for Add Ant Project, Add Shell Project, and Schedules is not working
[ http://jira.codehaus.org/browse/CONTINUUM-313?page=all ] Emmanuel Venisse closed CONTINUUM-313: -- Assign To: Emmanuel Venisse Resolution: Fixed Fix Version: 1.0-alpha-4 Fixed Cancel button for Add Ant Project, Add Shell Project, and Schedules is not working -- Key: CONTINUUM-313 URL: http://jira.codehaus.org/browse/CONTINUUM-313 Project: Continuum Type: Bug Components: continuum-web Reporter: Johnny R. Ruiz III Assignee: Emmanuel Venisse Priority: Minor Fix For: 1.0-alpha-4 When adding Ant Project or Adding Shell Project or Editing schedules.. the Cancel button will not return to the Show Project Page but instead will prompt for missing fields. -- 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
svn commit: r290082 - /maven/components/trunk/maven-artifact-manager/src/main/java/org/apache/maven/artifact/transform/AbstractVersionTransformation.java
Author: brett
Date: Mon Sep 19 00:50:33 2005
New Revision: 290082
URL: http://svn.apache.org/viewcvs?rev=290082view=rev
Log:
don't fail when legacy metadata can't be found due to an error with the
repository
Modified:
maven/components/trunk/maven-artifact-manager/src/main/java/org/apache/maven/artifact/transform/AbstractVersionTransformation.java
Modified:
maven/components/trunk/maven-artifact-manager/src/main/java/org/apache/maven/artifact/transform/AbstractVersionTransformation.java
URL:
http://svn.apache.org/viewcvs/maven/components/trunk/maven-artifact-manager/src/main/java/org/apache/maven/artifact/transform/AbstractVersionTransformation.java?rev=290082r1=290081r2=290082view=diff
==
---
maven/components/trunk/maven-artifact-manager/src/main/java/org/apache/maven/artifact/transform/AbstractVersionTransformation.java
(original)
+++
maven/components/trunk/maven-artifact-manager/src/main/java/org/apache/maven/artifact/transform/AbstractVersionTransformation.java
Mon Sep 19 00:50:33 2005
@@ -152,7 +152,7 @@
if ( !policy.isEnabled() )
{
-getLogger().debug( resolveMetaData: + artifact.getId()
+ : Skipping disabled repository +
+getLogger().debug( Legacy metadata: + artifact.getId()
+ : Skipping disabled repository +
repository.getId() + ( + repository.getUrl() + )
);
}
else
@@ -185,7 +185,12 @@
}
catch ( ResourceDoesNotExistException e )
{
-getLogger().debug( resolveMetaData: Artifact
version metadata for: + artifact.getId() +
+getLogger().debug( Legacy metadata for: +
artifact.getId() +
+ could not be found on repository: +
repository.getId(), e );
+}
+catch ( ArtifactMetadataRetrievalException e )
+{
+getLogger().warn( Legacy metadata for: +
artifact.getId() +
could not be found on repository: +
repository.getId(), e );
}
}
@@ -219,14 +224,6 @@
return localMetadata != null ? localMetadata.constructVersion() : null;
}
-/**
- * Select the version to use based on a merged versioning element.
- *
- * @param versioning the versioning element
- * @param defaultVersion the version to select if none is selected from
versioning
- * @return the version selected
- */
-//protected abstract String selectVersion( Versioning versioning, String
defaultVersion );
protected abstract LegacyArtifactMetadata createLegacyMetadata( Artifact
artifact );
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r290083 - /maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactMetadata.java
Author: brett
Date: Mon Sep 19 00:51:38 2005
New Revision: 290083
URL: http://svn.apache.org/viewcvs?rev=290083view=rev
Log:
allow creation without a file (purely repository)
Modified:
maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactMetadata.java
Modified:
maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactMetadata.java
URL:
http://svn.apache.org/viewcvs/maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactMetadata.java?rev=290083r1=290082r2=290083view=diff
==
---
maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactMetadata.java
(original)
+++
maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/artifact/ProjectArtifactMetadata.java
Mon Sep 19 00:51:38 2005
@@ -46,6 +46,11 @@
{
private final File file;
+public ProjectArtifactMetadata( Artifact artifact )
+{
+this( artifact, null );
+}
+
public ProjectArtifactMetadata( Artifact artifact, File file )
{
super( artifact );
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - FAILED - update] Mon Sep 19 07:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050919.073000.txt
svn commit: r290084 - in /maven/components/trunk/sandbox/repoclean/src/main: java/org/apache/maven/tools/repoclean/ java/org/apache/maven/tools/repoclean/digest/ java/org/apache/maven/tools/repoclean/phase/ resources/META-INF/plexus/
Author: brett
Date: Mon Sep 19 00:52:26 2005
New Revision: 290084
URL: http://svn.apache.org/viewcvs?rev=290084view=rev
Log:
add metadata for new artifact
Modified:
maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/RepositoryCleaner.java
maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/digest/Digestor.java
maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/phase/RewritePhase.java
maven/components/trunk/sandbox/repoclean/src/main/resources/META-INF/plexus/components.xml
Modified:
maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/RepositoryCleaner.java
URL:
http://svn.apache.org/viewcvs/maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/RepositoryCleaner.java?rev=290084r1=290083r2=290084view=diff
==
---
maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/RepositoryCleaner.java
(original)
+++
maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/RepositoryCleaner.java
Mon Sep 19 00:52:26 2005
@@ -73,8 +73,7 @@
File targetRepositoryBase = normalizeTargetRepositoryBase(
configuration.getTargetRepositoryPath() );
-// do not proceed if we cannot produce reports, or if the repository is
-// invalid.
+// do not proceed if we cannot produce reports, or if the repository
is invalid.
if ( reportsBase != null sourceRepositoryBase != null
targetRepositoryBase != null )
{
Logger logger = getLogger();
@@ -96,15 +95,13 @@
try
{
sourceLayout = (ArtifactRepositoryLayout)
container.lookup( ArtifactRepositoryLayout.ROLE,
-
configuration
-
.getSourceRepositoryLayout() );
+
configuration.getSourceRepositoryLayout() );
ArtifactRepository sourceRepo = new
DefaultArtifactRepository( source, file:// +
sourceRepositoryBase.getAbsolutePath(),
sourceLayout );
targetLayout = (ArtifactRepositoryLayout)
container.lookup( ArtifactRepositoryLayout.ROLE,
-
configuration
-
.getTargetRepositoryLayout() );
+
configuration.getTargetRepositoryLayout() );
ArtifactRepository targetRepo = new
DefaultArtifactRepository( target, file:// +
targetRepositoryBase.getAbsolutePath(),
targetLayout );
@@ -113,8 +110,6 @@
{
logger.debug( Rewriting POMs and artifact files.
);
}
-
-//List originalArtifacts = new
ArrayList( artifacts );
List rewritten = rewritePhase.execute( artifacts,
sourceRepo, targetRepo, configuration,
reportsBase,
repoReporter );
Modified:
maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/digest/Digestor.java
URL:
http://svn.apache.org/viewcvs/maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/digest/Digestor.java?rev=290084r1=290083r2=290084view=diff
==
---
maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/digest/Digestor.java
(original)
+++
maven/components/trunk/sandbox/repoclean/src/main/java/org/apache/maven/tools/repoclean/digest/Digestor.java
Mon Sep 19 00:52:26 2005
@@ -33,7 +33,6 @@
*/
public class Digestor
{
-
public static final String ROLE = Digestor.class.getName();
public static final String MD5 = MD5;
@@ -58,6 +57,25 @@
{
throw new DigestException( Cannot write digest to file: \' +
digestFile + \', e );
}
+}
+
+public File getDigestFile( File artifactFile, String algorithm )
+throws NoSuchAlgorithmException
+{
+String extension;
+if ( SHA.equals( algorithm ) )
+{
+extension = sha1;
+}
+else if ( MD5.equals( algorithm ) )
+{
+extension = md5;
+}
+else
+{
+throw new NoSuchAlgorithmException( Unknown
[jira] Closed: (CONTINUUM-301) Email notifications list wrong building machine
[ http://jira.codehaus.org/browse/CONTINUUM-301?page=all ] Emmanuel Venisse closed CONTINUUM-301: -- Resolution: Fixed Fix Version: (was: 1.0-beta-1) 1.0-alpha-4 Fixed. Thanks Alan. Email notifications list wrong building machine --- Key: CONTINUUM-301 URL: http://jira.codehaus.org/browse/CONTINUUM-301 Project: Continuum Type: Bug Reporter: Alan Cabrera Assignee: Emmanuel Venisse Fix For: 1.0-alpha-4 Email notifications list wrong building machine. Build statistics: State: Failed Previous State: Failed Started at: Wed, 31 Aug 2005 09:14:40 -0700 Finished at: Wed, 31 Aug 2005 09:21:42 -0700 Total time: 7m 1s Forced: false Exit code: 70 Building machine hostname: localhost The host name is not localhost. -- 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
svn commit: r290086 - /maven/components/trunk/sandbox/repoclean/src/assembly/bin.xml
Author: brett
Date: Mon Sep 19 01:03:36 2005
New Revision: 290086
URL: http://svn.apache.org/viewcvs?rev=290086view=rev
Log:
fix assembly settings for bin files
Modified:
maven/components/trunk/sandbox/repoclean/src/assembly/bin.xml
Modified: maven/components/trunk/sandbox/repoclean/src/assembly/bin.xml
URL:
http://svn.apache.org/viewcvs/maven/components/trunk/sandbox/repoclean/src/assembly/bin.xml?rev=290086r1=290085r2=290086view=diff
==
--- maven/components/trunk/sandbox/repoclean/src/assembly/bin.xml (original)
+++ maven/components/trunk/sandbox/repoclean/src/assembly/bin.xml Mon Sep 19
01:03:36 2005
@@ -7,6 +7,8 @@
fileSet
directorysrc/main/bash/directory
outputDirectory//outputDirectory
+ lineEndingunix/lineEnding
+ fileMode0755/fileMode
/fileSet
fileSet
!-- TODO: use expressions instead: ${project.build.directory},
${project.build.finalName}, or have a build / tag to include the built
artifact --
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - FAILED - update] Mon Sep 19 07:15:00 GMT 2005
Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20050919.071500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[result] Re: [vote] Release 1.0-alpha-4
There 4 +1's, all binding, and no other votes. Release will go ahead. - Brett Brett Porter wrote: This is a vote to release Continuum 1.0 alpha 4. Open for 72 hours. [ ] +1 release it [ ] -1 don't release it: fix _ first Cheers, Brett
Continuum release process
Hi, This should be the release process for continuum. Let me know if you think I missed anything. For this time around, make sure you are using a bootstrapped m2. A bug with the release profile has been fixed after m2 beta 1. 1) make sure there are no snapshots in the poms other than references to continuum snapshots 2) run: m2 release:prepare -Dtag=continuum-1.0-alpha-4 -B -DtagBase=https://svn.apache.org/repos/asf/maven/continuum/tags -Dusername=evenisse (obviously change username if someone else) 3) run: m2 release:perform (this deploys all the JARs and their sources) 4) cd continuum-plexus-application 5) m2 assembly:assembly 6) mkdir -p ~/release/continuum-1.0-alpha-4 7) cp target/*.zip target/*.tar.* ~/release/continuum-1.0-alpha-4 8) cd ~/release/continuum-1.0-alpha-4 9) for i in tar.gz tar.bz2 zip; do md5sum continuum-1.0-alpha-4-bin.$i | sed 's/ .*$//g' continuum-1.0-alpha-4-bin.$i.md5; done 10) make sure you have gpg installed and have a private key generated 11) add your key to cvs.apache.org:/www/www.apache.org/dist/maven/KEYS 12) for i in tar.gz tar.bz2 zip; do gpg --armor --output continuum-1.0-alpha-4-bin.$i.asc --detach-sig continuum-1.0-alpha-4-bin.$i; done 13) scp * cvs.apache.org:~evenisse/public_html/continuum-release-1.0-alpha-4 14) get people to test it. 15) on minotaur: cp ~evenisse/public_html/continuum-release-1.0-alpha-4/* /www/www.apache.org/dist/maven/binaries 16) wait for the files to arrive at http://www.apache.org/dist/maven/binaries/ 17) update website with new information, change links to downloads, etc. 18) update release notes on web site 19) write up release announcement and post to maven users list, maven dev list, maven diaries weblog, and announce@apache.org 20) go to admin in jira and mark 1.0-alpha-4 as released 21) celebrate Cheers, Brett
[jira] Created: (MAVENUPLOAD-521) Please create POM for javax.naming
Please create POM for javax.naming -- Key: MAVENUPLOAD-521 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-521 Project: maven-upload-requests Type: Wish Reporter: Henning Schmiedehausen Like some other POMs (javax.mail, javax.sql), javax.naming describes an additional jar that cannot currently be distributed through ibiblio. However, having a POM there, would help projects that consider moving to m2 but use this jar. project modelVersion4.0.0/modelVersion groupIdjavax.naming/groupId artifactIdjndi/artifactId version1.2.1/version /project would be fine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-522) Please update POM for javax.mail
Please update POM for javax.mail Key: MAVENUPLOAD-522 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-522 Project: maven-upload-requests Type: Wish Reporter: Henning Schmiedehausen javamail 1.3.3 is out: project modelVersion4.0.0/modelVersion groupIdjavamail/groupId artifactIdmail/artifactId version1.3.3/version dependencies dependency groupIdjavax.activation/groupId artifactIdactivation/artifactId version1.0.2/version scopecompile/scope /dependency /dependencies /project -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - FAILED - update] Mon Sep 19 08:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050919.08.txt
[jira] Updated: (MNG-859) Maven compiler plugin documentation
[ http://jira.codehaus.org/browse/MNG-859?page=all ] Johnny R. Ruiz III updated MNG-859: --- Attachment: MNG-859.patch Added Javadoc for Plugin Parameters Added brief how to use APT document. Maven compiler plugin documentation --- Key: MNG-859 URL: http://jira.codehaus.org/browse/MNG-859 Project: Maven 2 Type: Improvement Reporter: allan ramirez Assignee: Johnny R. Ruiz III Priority: Minor Fix For: 2.0 Attachments: MNG-859.patch Original Estimate: 8 hours Time Spent: 5 hours Remaining: 3 hours Add java doc and apt doc for an overview -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [poll] weekly betas - how can we approach it?
I am wondering if this means that I can look forward to having the integration tests fail for me one day each week while all of the version strings get updated. Yes, I realize this is because I clean out my m2 repository before rebuilding from SVN but it also means that anyone who decides on Tuesday to try building from SVN (especially if they don't realize that a new beta is just hours away) might get rather disappointed at how things don't build properly. If you want to do frequent beta releases, it might be good to change all of the 2.0-beta-?-SNAPSHOT version strings to 2.0-SNAPSHOT so that they don't need to be updated every week. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Sunday, September 18, 2005 20:11 To: Maven Developers List Subject: [poll] weekly betas - how can we approach it? We talked earlier about trying to do more regular releases, and now thing we are in a position to do that. I'd like to try doing weekly betas (next Monday, and then each week following that up to a final release). This would encourage a bit more stability and accountability week to week, and facilitate more community testing than publishing nightlies. This would be for the m2 core - plugins will get individual release votes whenever they are ready. This is doable, and just requires the official vote each time with 3 binding PMC votes. The question is, do we have extended votes for feedback (72 hours), or short votes? If we have extended votes, do we vote on code currently available and release something 3 days old, or vote on the date and trust the release manager to make sure the code is sane? The options I see are: - vote for 72 hours, release code from time of original vote - vote for 72 hours, release code at close of vote - vote on having weekly releases now, then vote on a release at the designated time, based on testing of that particular release, closing the vote after a shorter period (requiring 3 binding votes and considering any issues raised). Feel free to add your own options, voice opinions, vote for one of these options. My preference is for the last one, where if I am doing the releases I would open the vote Monday evening, giving Monday in the day for most parts of the world to test and vote and pushing up/announcing the release the following afternoon (Tuesday morning most places). Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] weekly betas - how can we approach it?
This will not be having the same afect as the last release where all the plugins and integration tests required changes. They can remain using beta-1 as they are now, and only be updated when they require a new API from a new version (Which we are loathe to do as it makes the plugin unusable from earlier betas). - Brett Allison, Bob wrote: I am wondering if this means that I can look forward to having the integration tests fail for me one day each week while all of the version strings get updated. Yes, I realize this is because I clean out my m2 repository before rebuilding from SVN but it also means that anyone who decides on Tuesday to try building from SVN (especially if they don't realize that a new beta is just hours away) might get rather disappointed at how things don't build properly. If you want to do frequent beta releases, it might be good to change all of the 2.0-beta-?-SNAPSHOT version strings to 2.0-SNAPSHOT so that they don't need to be updated every week. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Sunday, September 18, 2005 20:11 To: Maven Developers List Subject: [poll] weekly betas - how can we approach it? We talked earlier about trying to do more regular releases, and now thing we are in a position to do that. I'd like to try doing weekly betas (next Monday, and then each week following that up to a final release). This would encourage a bit more stability and accountability week to week, and facilitate more community testing than publishing nightlies. This would be for the m2 core - plugins will get individual release votes whenever they are ready. This is doable, and just requires the official vote each time with 3 binding PMC votes. The question is, do we have extended votes for feedback (72 hours), or short votes? If we have extended votes, do we vote on code currently available and release something 3 days old, or vote on the date and trust the release manager to make sure the code is sane? The options I see are: - vote for 72 hours, release code from time of original vote - vote for 72 hours, release code at close of vote - vote on having weekly releases now, then vote on a release at the designated time, based on testing of that particular release, closing the vote after a shorter period (requiring 3 binding votes and considering any issues raised). Feel free to add your own options, voice opinions, vote for one of these options. My preference is for the last one, where if I am doing the releases I would open the vote Monday evening, giving Monday in the day for most parts of the world to test and vote and pushing up/announcing the release the following afternoon (Tuesday morning most places). Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: optional scope for dependencies
As far as the end user would see, what is the difference between scope=optional and scope=provided? It sounds like both scopes do the same thing: use the dependency in the project's compile and test phases and prevent the dependency from being passed transitively. How would a developer know which scope to use, other than some verbiage in a (probably unread) README somewhere? -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Sunday, September 18, 2005 20:27 To: Maven Developers List Subject: Re: optional scope for dependencies Kenney Westerhof wrote: scope=provided currently does not do this (but I like it to :)) I thought that was the point - provided doesn't pass along the dependency, hence can be abused as an optional scope. I'm porposing we actually have an optional scope that does that. This would effectively be the same as removing them from the repository POM, though allows us to warn on it at least, and perhaps factor them into the version resolution if the dependency is present elsewhere in the tree. BTW, I've responded to that email - we should discuss that further there. Well, the excludes mechanism can deal with this. Yes, but that pushes the work to the client, which we are hearing regular complaints about. It's very verbose. I believe there was an idea about specifying api's as dependencies and a default implementation for that. If a nearer project specifies another implementation, that should be used. Although I don't know how this should (and can?) be implemented. For instance, a war project can be considered final, but then you could also package it into an ear, which might override the implementation specified in the war's pom. This is different to this - I'm not sure what you mean. Btw, the dependencies brought along with dom4j are needed to use that project, right? Unless the project uses that project with dom4j specifies those dependencies, it'll break at runtime. Isn't it the job of the 'nearest' conflict resolution to override versions brought in by dependencies? But i guess this is not a version issue, but an 'implementation provider' issue? Again, not sure what you mean about implementation provider in relation to this. Could you elaborate more on the exact problem? :) Yeah, probably didn't go through it enough as I thought it was well known. dom4j introduces a bunch of dependencies it needs to compile, but you most likely aren't using because they are optional. You are only using them if you use the piece of dom4j code that uses them. This is the same as velocity having a JDBC dependency for its JDBC resource loader that a lot of people don't use. The best solution is for dom4j to split up into a bunch of libraries that have smaller sets of individual dependencies, and you only depend on the pieces you use. As much as we can encourage that we can't enforce it. Letting them designate some dependencies as optional would mean that those are only used by specific functions not essential to the operation of the library, and Maven would skip them in the transitive dependency calculations. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - FAILED - update] Mon Sep 19 08:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050919.083000.txt
[jira] Created: (MPFILEACTIVITY-2) file activity plugin creates wrong links for Subversion repositories
file activity plugin creates wrong links for Subversion repositories Key: MPFILEACTIVITY-2 URL: http://jira.codehaus.org/browse/MPFILEACTIVITY-2 Project: maven-file-activity-plugin Type: Bug Versions: 1.5.2 Reporter: Henning Schmiedehausen Attachments: file-activity-report.html The maven file-activity plugin creates wrong links at docs/file-activity-report.html. project.xml repository connectionscm:svn:http://svn.apache.org/repos/asf/jakarta/turbine/core/branches/TURBINE_2_3_BRANCH/connection developerConnectionscm:svn:https://svn.apache.org/repos/asf/jakarta/turbine/core/branches/TURBINE_2_3_BRANCH/developerConnection urlhttp://svn.apache.org/viewcvs/jakarta/turbine/core/branches/TURBINE_2_3_BRANCH//url /repository results in the attached file-activity-report.html file where the links into the SCM look like this: http://svn.apache.org/viewcvs/jakarta/turbine/core/branches/TURBINE_2_3_BRANCH//jakarta/turbine/core/branches/TURBINE_2_3_BRANCH/xdocs/changes.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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPCHANGELOG-74) changelog plugin creates wrong links for Subversion repositories
changelog plugin creates wrong links for Subversion repositories Key: MPCHANGELOG-74 URL: http://jira.codehaus.org/browse/MPCHANGELOG-74 Project: maven-changelog-plugin Type: Bug Versions: 1.8.2 Reporter: Henning Schmiedehausen Attachments: changelog-report.html The maven file-activity plugin creates wrong links at docs/file-activity-report.html. project.xml repository connectionscm:svn:http://svn.apache.org/repos/asf/jakarta/turbine/core/branches/TURBINE_2_3_BRANCH/connection developerConnectionscm:svn:https://svn.apache.org/repos/asf/jakarta/turbine/core/branches/TURBINE_2_3_BRANCH/developerConnection urlhttp://svn.apache.org/viewcvs/jakarta/turbine/core/branches/TURBINE_2_3_BRANCH//url /repository results in the attached changelog-report.html file where the links into the SCM look like this: http://svn.apache.org/viewcvs/jakarta/turbine/core/branches/TURBINE_2_3_BRANCH//jakarta/turbine/core/branches/TURBINE_2_3_BRANCH/project.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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - FAILED - update] Mon Sep 19 09:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050919.09.txt
[maven2 build - SUCCESS - update] Mon Sep 19 08:15:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20050919.081500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20050919.081500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - SUCCESS - checkout] Mon Sep 19 10:07:28 GMT 2005
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20050919.100728.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050919.100728.txt
[jira] Created: (MNG-917) clover has to be declared as project dependency to run clover:report
clover has to be declared as project dependency to run clover:report Key: MNG-917 URL: http://jira.codehaus.org/browse/MNG-917 Project: Maven 2 Type: Bug Components: maven-clover-plugin Versions: 2.0-beta-1 Reporter: Daniel Schömer If I try to run m2 clover:report on one of my projects, the goal fails because the compiler can't find the com_cenqua_clover package. If I declare clover as compile-time dependency, the goal creates a clover report as expected. I think the clover:report goal should implicit include clover to the classpath. # m2 clover:report [INFO] Searching repository for plugin with prefix: 'clover'. [INFO] [INFO] Building clOptions [INFO]task-segment: [clover:report] [INFO] [INFO] [clover:instrument] [INFO] [resources:resources] [INFO] [compiler:compile] Compiling 6 source files to /home/daniel/workspace/option/target/clover/classes [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Reason: Compilation failure [INFO] [INFO] /home/daniel/workspace/option/target/clover/src/schoemer/cli/Command.java:[24,117] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Option.java:[74,115] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/LispToStringStyle.java:[14,104] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/ReflectionToStringBuilder2.java:[20,125] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Parser.java:[14,95] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/Utils.java:[18,76] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Command.java:[24,181] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Command.java:[24,533] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Command.java:[24,599] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Option.java:[74,179] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Option.java:[74,531] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Option.java:[74,597] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/LispToStringStyle.java:[14,168] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/LispToStringStyle.java:[14,520] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/LispToStringStyle.java:[14,586] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/ReflectionToStringBuilder2.java:[20,189] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/ReflectionToStringBuilder2.java:[20,541] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/ReflectionToStringBuilder2.java:[20,607] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Parser.java:[14,159] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Parser.java:[14,511] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Parser.java:[14,577] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/Utils.java:[18,140] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/Utils.java:[18,492] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/Utils.java:[18,558] package com_cenqua_clover does not exist [INFO] [INFO] Total time: 4 seconds [INFO] Finished at: Mon Sep 19 12:22:35 CEST 2005 [INFO] Final Memory: 5M/10M [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators:
SVN Build Error
While trying to rebuild my SVN tree from this morning's updates (revision 290102), I received the following: [INFO] [INFO] Building Maven Clover Plugin [INFO]task-segment: [clean:clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory /net/home/allisord/tmp/svn/maven-components/maven-plugins/maven-clover-p lugin/target [INFO] [plugin:descriptor] [INFO] [resources:resources] Downloading: http://draco.zone1.qintra.com:2003/central/clover/clover/1.3.9/clover-1. 3.9.pom 168b downloaded Downloading: http://draco.zone1.qintra.com:2003/central/clover/clover/1.3.9/clover-1. 3.9.jar 1492K downloaded [INFO] [compiler:compile] Compiling 5 source files to /net/home/allisord/tmp/svn/maven-components/maven-plugins/maven-clover-p lugin/target/classes [INFO] [resources:testResources] [INFO] [compiler:testCompile] Compiling 1 source file to /net/home/allisord/tmp/svn/maven-components/maven-plugins/maven-clover-p lugin/target/test-classes [INFO] [surefire:test] [INFO] Setting reports dir: /net/home/allisord/tmp/svn/maven-components/maven-plugins/maven-clover-p lugin/target/surefire-reports --- T E S T S --- [surefire] Running org.apache.maven.plugin.clover.CloverMojoTest RUN ABORTED java.lang.NoSuchMethodError org.codehaus.surefire.Runner An exception or error caused a run to abort. init Results : [surefire] Tests run: 0, Failures: 0, Errors: 1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: resource inheritence
On Mon, 19 Sep 2005, Brett Porter wrote:
Hi,
Some opinions needed. Currently we have a problem in: MNG-895 (cannot
add resources to a profile).
Basically, profiles operate identically to inheritence, and so resources
are not merged through inheritence, but if they do exist in the parent
they are inherited (eg src/main/resources from the super POM).
So, this seems a bit inconsistent to me. If you have 0 resources you get
the parent, if you have 1 you don't. But if you enable merging you have
no way to turn off inherited resources like src/main/resources.
To me, I don't see why resources should be inherited at all except to
apply that default, especially since ${basedir}/my-resources in the
parent actually doesn't point to teh parent's basedir but the
subprojects basedir. Furthermore, with aggregation, its possible that
new resource roots would be introduced for the parent and not the children.
Options:
1. handle profiles differently (merge resources, but don't merge for
inheritence)
2. merge for inheritence and profiles (we can probably live with it
because the extra directories will just be ignored in the children)
3. keep as is (inherit resources element if there is none in the
subproject, but don't merge, profiles would need to redefine resources)
4. turn off inheritence of resources altogether (src/main/resources
would be applied as a default after the fact if the end result is empty).
Resource inheritance from a normal pom seems useless to me since the
paths are totally different (other project). Specifying default
directories for an entire project tree (for users that don't conform to
the maven2 directory layout) is nice for pom readability, but bad for
the maven2 directory layout acceptance (i think the m2 directory layout is
very flexible and allows for extension, so everybody should adopt it :))
I'd say: use the parent pom's directory value as a default if none is
specified (inherit, don't merge), and augment the resources set using
profiles (merge). That would be 1 ?
(Although 3 is almost the same - profile redefine resources means
overriding?)
If people want to specify different resource sets using profiles, they
are probably different directories, or different filters.
If the default resources location is present, then those resources should
be included regardless of profiles.
If the profile's resources section specifies a different directory, it's
added, and if it specifies the same directory ('key'), but different
include/exclude patterns, it's likely the user intented to exclude
some resources or include some new ones. We can't force them to split up
according to directories, but this is safest. If we 'augment' the
includes/excludes, we would need a second set of include/exclude
parameters to the DirectoryScanner (override-*): if normally the resource
was excluded, but the override specifies otherwise, include it, and the
opposite. Technically hard, but intuitive.
-- Kenney
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r290109 - /maven/maven-1/plugins/trunk/checkstyle/plugin.jelly
Author: aheritier Date: Mon Sep 19 04:02:56 2005 New Revision: 290109 URL: http://svn.apache.org/viewcvs?rev=290109view=rev Log: fix missing namespace declaration. Modified: maven/maven-1/plugins/trunk/checkstyle/plugin.jelly Modified: maven/maven-1/plugins/trunk/checkstyle/plugin.jelly URL: http://svn.apache.org/viewcvs/maven/maven-1/plugins/trunk/checkstyle/plugin.jelly?rev=290109r1=290108r2=290109view=diff == --- maven/maven-1/plugins/trunk/checkstyle/plugin.jelly (original) +++ maven/maven-1/plugins/trunk/checkstyle/plugin.jelly Mon Sep 19 04:02:56 2005 @@ -28,6 +28,7 @@ xmlns:ant=jelly:ant xmlns:util=jelly:util xmlns:doc=doc + xmlns:plugin=plugin xmlns:maven=jelly:maven xmlns:define=jelly:define xmlns:checkstyle=checkstyle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-917) clover has to be declared as project dependency to run clover:report
[ http://jira.codehaus.org/browse/MNG-917?page=comments#action_46656 ] Vincent Massol commented on MNG-917: Definitely! This is a known issue. When I wrote this first version of the plugin I was not able to find a way to do so. I need to revisit this as it's probably possible by now. FYI there are some other known issues about the Clover plugin: MNG-618, MNG-917 I think the Clover plugin shouldn't have been released as it's not ready for prime-time yet. clover has to be declared as project dependency to run clover:report Key: MNG-917 URL: http://jira.codehaus.org/browse/MNG-917 Project: Maven 2 Type: Bug Components: maven-clover-plugin Versions: 2.0-beta-1 Reporter: Daniel Schömer If I try to run m2 clover:report on one of my projects, the goal fails because the compiler can't find the com_cenqua_clover package. If I declare clover as compile-time dependency, the goal creates a clover report as expected. I think the clover:report goal should implicit include clover to the classpath. # m2 clover:report [INFO] Searching repository for plugin with prefix: 'clover'. [INFO] [INFO] Building clOptions [INFO]task-segment: [clover:report] [INFO] [INFO] [clover:instrument] [INFO] [resources:resources] [INFO] [compiler:compile] Compiling 6 source files to /home/daniel/workspace/option/target/clover/classes [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Reason: Compilation failure [INFO] [INFO] /home/daniel/workspace/option/target/clover/src/schoemer/cli/Command.java:[24,117] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Option.java:[74,115] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/LispToStringStyle.java:[14,104] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/ReflectionToStringBuilder2.java:[20,125] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Parser.java:[14,95] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/Utils.java:[18,76] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Command.java:[24,181] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Command.java:[24,533] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Command.java:[24,599] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Option.java:[74,179] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Option.java:[74,531] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Option.java:[74,597] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/LispToStringStyle.java:[14,168] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/LispToStringStyle.java:[14,520] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/LispToStringStyle.java:[14,586] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/ReflectionToStringBuilder2.java:[20,189] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/ReflectionToStringBuilder2.java:[20,541] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/ReflectionToStringBuilder2.java:[20,607] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Parser.java:[14,159] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Parser.java:[14,511] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Parser.java:[14,577] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/Utils.java:[18,140] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/Utils.java:[18,492]
[jira] Commented: (MNG-917) clover has to be declared as project dependency to run clover:report
[ http://jira.codehaus.org/browse/MNG-917?page=comments#action_46657 ] Brett Porter commented on MNG-917: -- the clover plugin was only released as alpha clover has to be declared as project dependency to run clover:report Key: MNG-917 URL: http://jira.codehaus.org/browse/MNG-917 Project: Maven 2 Type: Bug Components: maven-clover-plugin Versions: 2.0-beta-1 Reporter: Daniel Schömer Assignee: Vincent Massol If I try to run m2 clover:report on one of my projects, the goal fails because the compiler can't find the com_cenqua_clover package. If I declare clover as compile-time dependency, the goal creates a clover report as expected. I think the clover:report goal should implicit include clover to the classpath. # m2 clover:report [INFO] Searching repository for plugin with prefix: 'clover'. [INFO] [INFO] Building clOptions [INFO]task-segment: [clover:report] [INFO] [INFO] [clover:instrument] [INFO] [resources:resources] [INFO] [compiler:compile] Compiling 6 source files to /home/daniel/workspace/option/target/clover/classes [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Reason: Compilation failure [INFO] [INFO] /home/daniel/workspace/option/target/clover/src/schoemer/cli/Command.java:[24,117] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Option.java:[74,115] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/LispToStringStyle.java:[14,104] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/ReflectionToStringBuilder2.java:[20,125] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Parser.java:[14,95] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/Utils.java:[18,76] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Command.java:[24,181] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Command.java:[24,533] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Command.java:[24,599] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Option.java:[74,179] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Option.java:[74,531] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Option.java:[74,597] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/LispToStringStyle.java:[14,168] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/LispToStringStyle.java:[14,520] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/LispToStringStyle.java:[14,586] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/ReflectionToStringBuilder2.java:[20,189] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/ReflectionToStringBuilder2.java:[20,541] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/ReflectionToStringBuilder2.java:[20,607] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Parser.java:[14,159] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Parser.java:[14,511] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/cli/Parser.java:[14,577] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/Utils.java:[18,140] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/Utils.java:[18,492] package com_cenqua_clover does not exist /home/daniel/workspace/option/target/clover/src/schoemer/util/Utils.java:[18,558] package com_cenqua_clover does not exist [INFO] [INFO] Total time: 4 seconds
svn commit: r290130 - /maven/maven-1/plugins/trunk/pdf/plugin.jelly
Author: aheritier
Date: Mon Sep 19 05:02:36 2005
New Revision: 290130
URL: http://svn.apache.org/viewcvs?rev=290130view=rev
Log:
cleanup unused variable
Modified:
maven/maven-1/plugins/trunk/pdf/plugin.jelly
Modified: maven/maven-1/plugins/trunk/pdf/plugin.jelly
URL:
http://svn.apache.org/viewcvs/maven/maven-1/plugins/trunk/pdf/plugin.jelly?rev=290130r1=290129r2=290130view=diff
==
--- maven/maven-1/plugins/trunk/pdf/plugin.jelly (original)
+++ maven/maven-1/plugins/trunk/pdf/plugin.jelly Mon Sep 19 05:02:36 2005
@@ -63,7 +63,6 @@
!-- internal variables --
j:set var=internal_pdf_workingDir value=${maven.build.dir}/pdf/
j:set var=java_version value=${java.specification.version}/
-j:set var=maven_version value=${maven.application.version}/
j:if test=${maven.pdf.debug}
ant:echo
### Debug mode is on ###
@@ -102,7 +101,8 @@
==
internal_pdf_workingDir = [${internal_pdf_workingDir}]
java_version= [${java_version}]
-maven_version = [${maven_version}]
+maven.application.version = [${maven.application.version}]
+plugin.currentVersion = [${plugin.currentVersion}]
/ant:echo
/j:if
j:if test=not ${maven.pdf.debug}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: optional scope for dependencies
Actually, I'd have said optional should be equivalent to compile but not passed on. While they might be significantly different in behaviour, I think that the naming makes it clearer about its use: optional is things used in some contexts but is optional and hence not passed on, while provided is something required, but you are expected to provide in your environment. The fact that provided is not passed on is not something your project should need to know about (like test dependencies, but different to optional ones that you would want to be aware of - they are sort of passed on but unused). - Brett Allison, Bob wrote: As far as the end user would see, what is the difference between scope=optional and scope=provided? It sounds like both scopes do the same thing: use the dependency in the project's compile and test phases and prevent the dependency from being passed transitively. How would a developer know which scope to use, other than some verbiage in a (probably unread) README somewhere? -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Sunday, September 18, 2005 20:27 To: Maven Developers List Subject: Re: optional scope for dependencies Kenney Westerhof wrote: scope=provided currently does not do this (but I like it to :)) I thought that was the point - provided doesn't pass along the dependency, hence can be abused as an optional scope. I'm porposing we actually have an optional scope that does that. This would effectively be the same as removing them from the repository POM, though allows us to warn on it at least, and perhaps factor them into the version resolution if the dependency is present elsewhere in the tree. BTW, I've responded to that email - we should discuss that further there. Well, the excludes mechanism can deal with this. Yes, but that pushes the work to the client, which we are hearing regular complaints about. It's very verbose. I believe there was an idea about specifying api's as dependencies and a default implementation for that. If a nearer project specifies another implementation, that should be used. Although I don't know how this should (and can?) be implemented. For instance, a war project can be considered final, but then you could also package it into an ear, which might override the implementation specified in the war's pom. This is different to this - I'm not sure what you mean. Btw, the dependencies brought along with dom4j are needed to use that project, right? Unless the project uses that project with dom4j specifies those dependencies, it'll break at runtime. Isn't it the job of the 'nearest' conflict resolution to override versions brought in by dependencies? But i guess this is not a version issue, but an 'implementation provider' issue? Again, not sure what you mean about implementation provider in relation to this. Could you elaborate more on the exact problem? :) Yeah, probably didn't go through it enough as I thought it was well known. dom4j introduces a bunch of dependencies it needs to compile, but you most likely aren't using because they are optional. You are only using them if you use the piece of dom4j code that uses them. This is the same as velocity having a JDBC dependency for its JDBC resource loader that a lot of people don't use. The best solution is for dom4j to split up into a bunch of libraries that have smaller sets of individual dependencies, and you only depend on the pieces you use. As much as we can encourage that we can't enforce it. Letting them designate some dependencies as optional would mean that those are only used by specific functions not essential to the operation of the library, and Maven would skip them in the transitive dependency calculations. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: resource inheritence
Kenney Westerhof wrote:
Resource inheritance from a normal pom seems useless to me since the
paths are totally different (other project).
Right, that's what I was getting at too.
Specifying default
directories for an entire project tree (for users that don't conform to
the maven2 directory layout) is nice for pom readability, but bad for
the maven2 directory layout acceptance (i think the m2 directory layout is
very flexible and allows for extension, so everybody should adopt it :))
Maven is about encouraging patterns, but not necessarily our patterns.
Hopefully people will use the defaults for simplicity, but if a company
standard is in force that should be easy too.
I'd say: use the parent pom's directory value as a default if none is
specified (inherit, don't merge), and augment the resources set using
profiles (merge). That would be 1 ?
(Although 3 is almost the same - profile redefine resources means
overriding?)
You're combining 1 and 4.
1 is where the profile (merged) behaves differently to inheritence (not
merged, but inherited as a whole) where 3 is where they behave the same
way (no merge for either, but inherited as a whole)
If people want to specify different resource sets using profiles, they
are probably different directories, or different filters.
If the default resources location is present, then those resources should
be included regardless of profiles.
If the profile's resources section specifies a different directory, it's
added, and if it specifies the same directory ('key'), but different
include/exclude patterns, it's likely the user intented to exclude
some resources or include some new ones. We can't force them to split up
according to directories, but this is safest. If we 'augment' the
includes/excludes, we would need a second set of include/exclude
parameters to the DirectoryScanner (override-*): if normally the resource
was excluded, but the override specifies otherwise, include it, and the
opposite. Technically hard, but intuitive.
That sounds reasonable. That given, I'd really prefer we merge
everything (including inheritence and the super POM). I think it is
useful for us to be able to say profiles behave identically to
inheritence (not just from a technical perspective). It's easy to
explain, allows all the features, shouldn't have negative side effects
if you end up with extras (as they just get ignored when they don't
exist), and allows setting a company standard. I definitely agree we can
merge the in/excludes list for a directory as you and John suggested (I
realise now this is different to just aggregating the different
resources sets because of the precedence of excludes).
So... that leads me to 2 now.
Cheers,
Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN Build Error
Working fine here and in continuous integration. I'd only suggest an incorrect surefire JAR, perhaps. What is your motivation for building from SVN? While I'd hope it was more stable than this for you, it is expected to be a moving target and have issues from time to time - unless you are working on patches or testing changes in the core (not the plugins, as they can be built and installed individually), I'd suggest running the latest available beta. Cheers, Brett Allison, Bob wrote: While trying to rebuild my SVN tree from this morning's updates (revision 290102), I received the following: [INFO] [INFO] Building Maven Clover Plugin [INFO]task-segment: [clean:clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory /net/home/allisord/tmp/svn/maven-components/maven-plugins/maven-clover-p lugin/target [INFO] [plugin:descriptor] [INFO] [resources:resources] Downloading: http://draco.zone1.qintra.com:2003/central/clover/clover/1.3.9/clover-1. 3.9.pom 168b downloaded Downloading: http://draco.zone1.qintra.com:2003/central/clover/clover/1.3.9/clover-1. 3.9.jar 1492K downloaded [INFO] [compiler:compile] Compiling 5 source files to /net/home/allisord/tmp/svn/maven-components/maven-plugins/maven-clover-p lugin/target/classes [INFO] [resources:testResources] [INFO] [compiler:testCompile] Compiling 1 source file to /net/home/allisord/tmp/svn/maven-components/maven-plugins/maven-clover-p lugin/target/test-classes [INFO] [surefire:test] [INFO] Setting reports dir: /net/home/allisord/tmp/svn/maven-components/maven-plugins/maven-clover-p lugin/target/surefire-reports --- T E S T S --- [surefire] Running org.apache.maven.plugin.clover.CloverMojoTest RUN ABORTED java.lang.NoSuchMethodError org.codehaus.surefire.Runner An exception or error caused a run to abort. init Results : [surefire] Tests run: 0, Failures: 0, Errors: 1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - FAILED - update] Mon Sep 19 12:30:01 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050919.123001.txt
Re: resource inheritence
On Mon, 19 Sep 2005, Brett Porter wrote: Kenney Westerhof wrote: Maven is about encouraging patterns, but not necessarily our patterns. Hopefully people will use the defaults for simplicity, but if a company standard is in force that should be easy too. Ofcourse, I totally agree. But now it seems that the most easy to read poms are those for projects that adhere to 'our' standards. If we don't inherit parent's settings (maybe only useful to inherit if the parent has packaging pom?) people are forced to re-specify those locations in each pom. I'd say: use the parent pom's directory value as a default if none is specified (inherit, don't merge), and augment the resources set using profiles (merge). That would be 1 ? (Although 3 is almost the same - profile redefine resources means overriding?) You're combining 1 and 4. 1 is where the profile (merged) behaves differently to inheritence (not merged, but inherited as a whole) where 3 is where they behave the same way (no merge for either, but inherited as a whole) Hm.. I meant to say: profiles are inherited AND merged (inheritance has to either replace values (override) or merge them), whereas I think the build information is project local and should not be merged, but possibly only used for specifying defaults. [snip] That sounds reasonable. That given, I'd really prefer we merge everything (including inheritence and the super POM). I think it is useful for us to be able to say profiles behave identically to inheritence (not just from a technical perspective). It's easy to explain, allows all the features, shouldn't have negative side effects if you end up with extras (as they just get ignored when they don't exist), and allows setting a company standard. I definitely agree we can merge the in/excludes list for a directory as you and John suggested (I realise now this is different to just aggregating the different resources sets because of the precedence of excludes). I agree.. except, the following is not possible then: PARENT: resource dir not specified (and no resources present; no need for resources here), so: resource dir = src/main/resources (from the built-in root pom) CHILD (extends parent) resource dir = specified explicitly as src/main/default-resources profile A: resource dir specified as src/main/resources Using your scheme the resources from profile A, even though that profile is not activated, are included (the filters aren't applied). But this is about the only problem I can see: a parent defines a default resource dir (either inherited from the root pom, or explicitly), and a child chooses to specify another resource dir as a default, and uses the same directory name for a resource specified in a profile. As it was not intended in the child to use that resource dir, it'll get used. This complicates things for users as they need knowledge of parent resource dirs to know what to specify and where. -- Kenney So... that leads me to 2 now. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: r280860 - in /maven/maven-1/plugins/trunk: ./ abbot/src/plugin-test/ clover/src/plugin-test/ cruisecontrol/src/plugin-test/ dashboard/src/plugin-test/ eclipse/src/plugin-test/
Hi Arnaud,
A pity... It took me a while to move from the reactor to using the
multiproject plugin and now we're back again to square one... :-)
Not that I care that much but I'm curious to understand if we have changed
our m1 vision (which was to reuse existing plugins as much as possible).
Here we are now duplicating code from the multiproject plugin.
Also it's dangerous as before a user could use all the available
multiproject properties to configure the plugins whereas now they are
limited to the ones you've defined as attributes of the reactor tag.
Thanks
-Vincent
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: mercredi 14 septembre 2005 16:07
To: [EMAIL PROTECTED]
Subject: svn commit: r280860 - in /maven/maven-1/plugins/trunk: ./
abbot/src/plugin-test/ clover/src/plugin-test/ cruisecontrol/src/plugin-
test/ dashboard/src/plugin-test/ eclipse/src/plugin-test/
Author: aheritier
Date: Wed Sep 14 07:06:20 2005
New Revision: 280860
URL: http://svn.apache.org/viewcvs?rev=280860view=rev
Log:
Replace the multiproject:goal by the reactor (workaround for MAVEN-1691).
Fix all tests in all plugins.
Removed:
maven/maven-1/plugins/trunk/abbot/src/plugin-test/project.properties
maven/maven-1/plugins/trunk/clover/src/plugin-test/project.properties
maven/maven-1/plugins/trunk/cruisecontrol/src/plugin-
test/project.properties
maven/maven-1/plugins/trunk/eclipse/src/plugin-test/project.properties
Modified:
maven/maven-1/plugins/trunk/abbot/src/plugin-test/maven.xml
maven/maven-1/plugins/trunk/clover/src/plugin-test/maven.xml
maven/maven-1/plugins/trunk/cruisecontrol/src/plugin-test/maven.xml
maven/maven-1/plugins/trunk/dashboard/src/plugin-test/maven.xml
maven/maven-1/plugins/trunk/dashboard/src/plugin-
test/project.properties
maven/maven-1/plugins/trunk/eclipse/src/plugin-test/maven.xml
maven/maven-1/plugins/trunk/maven.xml
Modified: maven/maven-1/plugins/trunk/abbot/src/plugin-test/maven.xml
URL: http://svn.apache.org/viewcvs/maven/maven-
1/plugins/trunk/abbot/src/plugin-
test/maven.xml?rev=280860r1=280859r2=280860view=diff
==
--- maven/maven-1/plugins/trunk/abbot/src/plugin-test/maven.xml (original)
+++ maven/maven-1/plugins/trunk/abbot/src/plugin-test/maven.xml Wed Sep 14
07:06:20 2005
@@ -1,6 +1,6 @@
?xml version=1.0?
-project xmlns:j=jelly:core
+project xmlns:j=jelly:core xmlns:maven=jelly:maven
goal name=testPlugin
echoThis plugin must be tested manually (with the testPlugin-manual
goal) as it requires defining a build.properties containing environment-
dependent configuration./echo
@@ -13,8 +13,7 @@
environment variable must be set. --
goal name=testPlugin-manual
- j:set var=goal value=dist/
-attainGoal name=multiproject:goal/
+maven:reactor basedir=${basedir} includes=*/project.xml
goals=dist banner=Test ignoreFailures=false/
/goal
[snip]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r280860 - in /maven/maven-1/plugins/trunk: ./ abbot/src/plugin-test/ clover/src/plugin-test/ cruisecontrol/src/plugin-test/ dashboard/src/plugin-test/ eclipse/src/plugin-test/
I agree with Vincent. I don't think we should be working around bugs in
the beta by changing the plugins (esp in breaking backwards compat)
Cheers,
Brett
Vincent Massol wrote:
Hi Arnaud,
A pity... It took me a while to move from the reactor to using the
multiproject plugin and now we're back again to square one... :-)
Not that I care that much but I'm curious to understand if we have changed
our m1 vision (which was to reuse existing plugins as much as possible).
Here we are now duplicating code from the multiproject plugin.
Also it's dangerous as before a user could use all the available
multiproject properties to configure the plugins whereas now they are
limited to the ones you've defined as attributes of the reactor tag.
Thanks
-Vincent
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: mercredi 14 septembre 2005 16:07
To: [EMAIL PROTECTED]
Subject: svn commit: r280860 - in /maven/maven-1/plugins/trunk: ./
abbot/src/plugin-test/ clover/src/plugin-test/ cruisecontrol/src/plugin-
test/ dashboard/src/plugin-test/ eclipse/src/plugin-test/
Author: aheritier
Date: Wed Sep 14 07:06:20 2005
New Revision: 280860
URL: http://svn.apache.org/viewcvs?rev=280860view=rev
Log:
Replace the multiproject:goal by the reactor (workaround for MAVEN-1691).
Fix all tests in all plugins.
Removed:
maven/maven-1/plugins/trunk/abbot/src/plugin-test/project.properties
maven/maven-1/plugins/trunk/clover/src/plugin-test/project.properties
maven/maven-1/plugins/trunk/cruisecontrol/src/plugin-
test/project.properties
maven/maven-1/plugins/trunk/eclipse/src/plugin-test/project.properties
Modified:
maven/maven-1/plugins/trunk/abbot/src/plugin-test/maven.xml
maven/maven-1/plugins/trunk/clover/src/plugin-test/maven.xml
maven/maven-1/plugins/trunk/cruisecontrol/src/plugin-test/maven.xml
maven/maven-1/plugins/trunk/dashboard/src/plugin-test/maven.xml
maven/maven-1/plugins/trunk/dashboard/src/plugin-
test/project.properties
maven/maven-1/plugins/trunk/eclipse/src/plugin-test/maven.xml
maven/maven-1/plugins/trunk/maven.xml
Modified: maven/maven-1/plugins/trunk/abbot/src/plugin-test/maven.xml
URL: http://svn.apache.org/viewcvs/maven/maven-
1/plugins/trunk/abbot/src/plugin-
test/maven.xml?rev=280860r1=280859r2=280860view=diff
==
--- maven/maven-1/plugins/trunk/abbot/src/plugin-test/maven.xml (original)
+++ maven/maven-1/plugins/trunk/abbot/src/plugin-test/maven.xml Wed Sep 14
07:06:20 2005
@@ -1,6 +1,6 @@
?xml version=1.0?
-project xmlns:j=jelly:core
+project xmlns:j=jelly:core xmlns:maven=jelly:maven
goal name=testPlugin
echoThis plugin must be tested manually (with the testPlugin-manual
goal) as it requires defining a build.properties containing environment-
dependent configuration./echo
@@ -13,8 +13,7 @@
environment variable must be set. --
goal name=testPlugin-manual
- j:set var=goal value=dist/
-attainGoal name=multiproject:goal/
+maven:reactor basedir=${basedir} includes=*/project.xml
goals=dist banner=Test ignoreFailures=false/
/goal
[snip]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - FAILED - update] Mon Sep 19 13:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050919.13.txt
Re: resource inheritence
Kenney Westerhof wrote: Hm.. I meant to say: profiles are inherited AND merged (inheritance has to either replace values (override) or merge them), whereas I think the build information is project local and should not be merged, but possibly only used for specifying defaults. Right, so we agree on that, but I'm firmly in favour for making it behave identically to inheritence. So I'd like to apply it to both. I agree.. except, the following is not possible then: PARENT: resource dir not specified (and no resources present; no need for resources here), so: resource dir = src/main/resources (from the built-in root pom) CHILD (extends parent) resource dir = specified explicitly as src/main/default-resources profile A: resource dir specified as src/main/resources Using your scheme the resources from profile A, even though that profile is not activated, are included (the filters aren't applied). But this is about the only problem I can see: a parent defines a default resource dir (either inherited from the root pom, or explicitly), and a child chooses to specify another resource dir as a default, and uses the same directory name for a resource specified in a profile. I think there are downsides either way. This one is pretty rare, and worked around by either using a different name, or putting it into the default with excludes **/**. As it was not intended in the child to use that resource dir, it'll get used. This complicates things for users as they need knowledge of parent resource dirs to know what to specify and where. The more I think about it, knowledge of parent isn't such a bad thing (As long as you are insulated from changes in some ways). So... are we agreeing on (2) or do you think we need to differ the behaviour of profiles and inheritence? Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r280860 - in /maven/maven-1/plugins/trunk: ./ abbot/src/plugin-test/ clover/src/plugin-test/ cruisecontrol/src/plugin-test/ dashboard/src/plugin-test/ eclipse/src/plugin-test/
The problem is that we added a lot of layers and I don't think it's a good
idea for the tests.
I agree to reuse as much as possible plugins feature between them (I'm
adding reusable goals where possible), but in tests we should be very simple
to avoid sideeffects (it's why m2 was done - less layers, a better
control...).
I spent a lot of time to find that it was because we have a bug in the maven
(MAVEN-1691 http://jira.codehaus.org/browse/MAVEN-1691) which produced a
problem in the multiproject plugin which drove to the failure of several
tests in different plugins.
I don't want to rewrite m1 (it's already - and well - done in m2) but I
don't want also to spent hours and hours to find a little bug.
Brett : why do you say we're breaking backwards compatibility ?
Vincent : Yes it a bad idea to keep the properties names comming from the
multiproject plugin. I should use the multiproject or remove it and rename
properties.
I'm doubtful I don't know what is the better
Arnaud
On 9/19/05, Brett Porter [EMAIL PROTECTED] wrote:
I agree with Vincent. I don't think we should be working around bugs in
the beta by changing the plugins (esp in breaking backwards compat)
Cheers,
Brett
Vincent Massol wrote:
Hi Arnaud,
A pity... It took me a while to move from the reactor to using the
multiproject plugin and now we're back again to square one... :-)
Not that I care that much but I'm curious to understand if we have
changed
our m1 vision (which was to reuse existing plugins as much as possible).
Here we are now duplicating code from the multiproject plugin.
Also it's dangerous as before a user could use all the available
multiproject properties to configure the plugins whereas now they are
limited to the ones you've defined as attributes of the reactor tag.
Thanks
-Vincent
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: mercredi 14 septembre 2005 16:07
To: [EMAIL PROTECTED]
Subject: svn commit: r280860 - in /maven/maven-1/plugins/trunk: ./
abbot/src/plugin-test/ clover/src/plugin-test/ cruisecontrol/src/plugin-
test/ dashboard/src/plugin-test/ eclipse/src/plugin-test/
Author: aheritier
Date: Wed Sep 14 07:06:20 2005
New Revision: 280860
URL: http://svn.apache.org/viewcvs?rev=280860view=rev
Log:
Replace the multiproject:goal by the reactor (workaround for
MAVEN-1691).
Fix all tests in all plugins.
Removed:
maven/maven-1/plugins/trunk/abbot/src/plugin-test/project.properties
maven/maven-1/plugins/trunk/clover/src/plugin-test/project.properties
maven/maven-1/plugins/trunk/cruisecontrol/src/plugin-
test/project.properties
maven/maven-1/plugins/trunk/eclipse/src/plugin-test/project.properties
Modified:
maven/maven-1/plugins/trunk/abbot/src/plugin-test/maven.xml
maven/maven-1/plugins/trunk/clover/src/plugin-test/maven.xml
maven/maven-1/plugins/trunk/cruisecontrol/src/plugin-test/maven.xml
maven/maven-1/plugins/trunk/dashboard/src/plugin-test/maven.xml
maven/maven-1/plugins/trunk/dashboard/src/plugin-
test/project.properties
maven/maven-1/plugins/trunk/eclipse/src/plugin-test/maven.xml
maven/maven-1/plugins/trunk/maven.xml
Modified: maven/maven-1/plugins/trunk/abbot/src/plugin-test/maven.xml
URL: http://svn.apache.org/viewcvs/maven/maven-
1/plugins/trunk/abbot/src/plugin-
test/maven.xml?rev=280860r1=280859r2=280860view=diff
==
--- maven/maven-1/plugins/trunk/abbot/src/plugin-test/maven.xml
(original)
+++ maven/maven-1/plugins/trunk/abbot/src/plugin-test/maven.xml Wed Sep
14
07:06:20 2005
@@ -1,6 +1,6 @@
?xml version=1.0?
-project xmlns:j=jelly:core
+project xmlns:j=jelly:core xmlns:maven=jelly:maven
goal name=testPlugin
echoThis plugin must be tested manually (with the testPlugin-manual
goal) as it requires defining a build.properties containing environment-
dependent configuration./echo
@@ -13,8 +13,7 @@
environment variable must be set. --
goal name=testPlugin-manual
- j:set var=goal value=dist/
- attainGoal name=multiproject:goal/
+ maven:reactor basedir=${basedir} includes=*/project.xml
goals=dist banner=Test ignoreFailures=false/
/goal
[snip]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] New Web Site CSS
Hi Brett, I retry again this morning on my work computer (IE, xp sp2 and so on) It works fine now. I have no clue on what happened. Regards, Vincent 2005/9/17, Brett Porter [EMAIL PROTECTED]: Strange - I don't see it here. Anything special about the environment? Version of Windows, exact version of IE, etc? I'm on XP SP2 with latest patches. Not sure there is much we can do about it. - Brett Vincent Siveton wrote: Let see the screenshot on IE 6.0 http://people.apache.org/~vsiveton/newcss/mavencss.JPG But seems to render fine on an other computer with IE or firefox. Cheers, Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - FAILED - update] Mon Sep 19 13:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050919.133000.txt
[jira] Commented: (MNG-441) surefire plugin needs to be able to fork tests
[ http://jira.codehaus.org/browse/MNG-441?page=comments#action_46661 ]
Andy Glick commented on MNG-441:
I've started work on this. Will add a class ForkMode as an enumerated type in
surefire and the plugin will reference it. The surefirebooter class will
determine the ForkMode value passed by the plugin {NONE, ONCE, EACH_TEST}
default value will be ONCE and kick off tests according to ForkMode - I intend
to add a class SurefireConfiguration to make this similar to plexus.compiler,
I'm attempting to create a protocol for parameter passing as we've already got
surefire-beanshell, surefire-jython, surefire-web and surefire-xmlrpc, i expect
to add surefire-testng and possibly surefire-ivalidator when things settle down
a bit :)
surefire plugin needs to be able to fork tests
--
Key: MNG-441
URL: http://jira.codehaus.org/browse/MNG-441
Project: Maven 2
Type: Improvement
Components: maven-surefire-plugin
Reporter: Brett Porter
Fix For: 2.0-beta-2
they can leak memory, so a fork once for all option would be good.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-523) iCal4j 0.9.15 - Maven bundle
iCal4j 0.9.15 - Maven bundle Key: MAVENUPLOAD-523 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-523 Project: maven-upload-requests Type: Task Reporter: Ben Fortuna http://ical4j.sourceforge.net/maven/ical4j-0.9.15-bundle.jar http://ical4j.sourceforge.net http://sourceforge.net/users/fortuna A Java library for reading and writing iCalendar (*.ics) files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - FAILED - update] Mon Sep 19 14:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050919.14.txt
[continuum build - FAILED - update] Mon Sep 19 14:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050919.143000.txt
Re: [M2] Out of memory exceptions
On Mon, 19 Sep 2005, Carsten Ziegeler wrote: Yes, set the environment variable MAVEN_OPTS; it's value is passed as JVM arguments. Btw this is a typical user question, you best use the users list for these types of questions. -- Kenney We get out of memory exceptions while trying to do a fresh build of Cocoon (it consists of approx 60 sub projects with several dependencies). Invoking the build after the OOM occured then builds the remaining parts of the project. Is there any way to increase the memory for m2? Is setting the usual java memory properties the right way? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-918) Typo in ant-tasks page
[ http://jira.codehaus.org/browse/MNG-918?page=all ] Chad Berghorst updated MNG-918: --- Attachment: MNG-918-maven-site.patch SVN patch file Typo in ant-tasks page -- Key: MNG-918 URL: http://jira.codehaus.org/browse/MNG-918 Project: Maven 2 Type: Bug Components: documentation Versions: 2.0-beta-1 Reporter: Chad Berghorst Priority: Trivial Attachments: MNG-918-maven-site.patch The Ant snippet for the typedef approach to using the Maven Ant tasks does not work. The uri attribute of typedef should be: urn:maven-artifact-ant to match the xmlns:artifact project attribute. The Ant sample script is correct. (In addition, the JAR should reference the beta JAR instead of the alpha JAR.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Out of memory exceptions
Kenney Westerhof schrieb: On Mon, 19 Sep 2005, Carsten Ziegeler wrote: Yes, set the environment variable MAVEN_OPTS; it's value is passed as JVM arguments. Ok, thanks Btw this is a typical user question, you best use the users list for these types of questions. Yepp, you're right - sorry! Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-919) Installation with symlinks
Installation with symlinks -- Key: MNG-919 URL: http://jira.codehaus.org/browse/MNG-919 Project: Maven 2 Type: Improvement Components: maven-core Versions: 2.0-beta-1 Environment: Linux/Unix Reporter: Alex Wood Attachments: m2-failed-start.txt When trying to install the Maven 2 beta, I followed the instructions available at http://maven.apache.org/maven2/download.html However, I did not set my $PATH to include a reference to the Maven 2 directory. I prefer to keep my $PATH very short and so I put a symlink to m2 in /usr/local/bin. When I tried to start Maven 2, I received the following message: Exception in thread main java.lang.NoClassDefFoundError: org/codehaus/classworlds/Launcher After looking at the m2 shell script, I noticed the reference to $M2_HOME was not being set correctly. After setting that variable correctly, Maven 2 started without a problem. I've attached the output of bash -x for a failed startup. It looks to me like the problem is in this section ## resolve links - $0 may be a link to maven's home PRG=$0 saveddir=`pwd` # need this for relative symlinks PRGDIR=`dirname $PRG` cd $PRGDIR while [ -h $PRG ] ; do [...] Since my symlink was in my path, PRG got set to just m2 which fouled the rest of the script. Using 'which' might help here. Regards, Alex -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [poll] weekly betas - how can we approach it?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd prefer the final option, as well. I think we're going to be working closely enough to keep the lines of communication open for things that need to be discussed without having a 72 hour window for a vote, and if the fix doesn't make it into a particular release, hey - we can wait a week. john Brett Porter wrote: | We talked earlier about trying to do more regular releases, and now | thing we are in a position to do that. | | I'd like to try doing weekly betas (next Monday, and then each week | following that up to a final release). This would encourage a bit more | stability and accountability week to week, and facilitate more community | testing than publishing nightlies. | | This would be for the m2 core - plugins will get individual release | votes whenever they are ready. | | This is doable, and just requires the official vote each time with 3 | binding PMC votes. | | The question is, do we have extended votes for feedback (72 hours), or | short votes? If we have extended votes, do we vote on code currently | available and release something 3 days old, or vote on the date and | trust the release manager to make sure the code is sane? | | The options I see are: | - vote for 72 hours, release code from time of original vote | - vote for 72 hours, release code at close of vote | - vote on having weekly releases now, then vote on a release at the | designated time, based on testing of that particular release, closing | the vote after a shorter period (requiring 3 binding votes and | considering any issues raised). | | Feel free to add your own options, voice opinions, vote for one of | these options. | | My preference is for the last one, where if I am doing the releases I | would open the vote Monday evening, giving Monday in the day for most | parts of the world to test and vote and pushing up/announcing the | release the following afternoon (Tuesday morning most places). | | Cheers, | Brett | | - | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | | -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDLtPxK3h2CZwO/4URAn9bAJ9/ZOBCGhIB205OiZh/zwKXddADiACdHx2Z SzCnCWiQIQdISM+fI8khrCw= =5wuE -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - SUCCESS - update] Mon Sep 19 15:00:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20050919.15.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20050919.15.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-920) Release plugin doesn't keep profiles in release pom
Release plugin doesn't keep profiles in release pom --- Key: MNG-920 URL: http://jira.codehaus.org/browse/MNG-920 Project: Maven 2 Type: Bug Components: maven-release-plugin Versions: 2.0-beta-1 Reporter: Emmanuel Venisse Assigned to: John Casey -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-921) release:perform must pass to m2 a profile to use if user provide one
release:perform must pass to m2 a profile to use if user provide one Key: MNG-921 URL: http://jira.codehaus.org/browse/MNG-921 Project: Maven 2 Type: Improvement Components: maven-release-plugin Versions: 2.0-beta-1 Reporter: Emmanuel Venisse -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[M1] RFC on doco - subject is: Setting or getting the value of plugin variables from a plugin context
All,
This is a preliminary reworking of the information that Brett entered into
Maven-1656. I wanted to let everyone have a look at what I'd cooked up and
to ask a couple of questions about things that are not clear to me.
Q1) Brett's writeup didn't mention including the namespace for the artifact
plugin, but in the M1.1b1 examples that I have worked through, the
inclusion of the namespace is mandatory. So I've added it but enclosed it
in braces with a note as this poses a potential problem. I've no longer got
M1 1.0.2 or M1 1.1B1 configured on my development machine, just M1 1.1B2.
It (M1 1.1B2) doesn't require the artifact namespace, but I did experience
situations with M1 1.1B1 where it was required. I'm not sure how to go
about constructing testcases for all of the cases, since they would have to
vary by Maven version and then by maven.xml file contents and I can't test
them on my Windows box.
Q2) Maven-1620 has the following text:
Setting a plugin property within a goal before attaining a goal for that
plugin fails. Whenever it is put in a preGoal it does work correctly.
So it isn't clear to me that method b be can be used to set plugin
variables as Brett stated in the writeup. It clearly will initialize a
plugin, but that's not the issue. I've taken the liberty of removing the
reference to b as a method for setting/getting variable values.
Q3) Are there cases in which none of this will work for whatever reason?
That isn't clear. Brett and VMassol have both claimed that this is a
non-deterministic mess, so 1 possibility is that there really are cases in
which it won't work.
You'll note that I reference some JIRA issues, is that OK in project level
documentation? Will people have to register to get read access to the
pages? You'll also note that I reference Why We Rewrote Maven. I intend
to start on that when this is put to bed.
I assume that this should be an entry in the M1 FAQ?
Andy
Setting or getting the value of plugin variables from a plugin context
If the plugin's logic does not determine if the variable that you are
setting has already been set and it has unconditional logic to set the
value of the variable, read overwrite your settings, then none of the
techniques described here will work. So please read the plugin.jelly file.
All of the plugins are expanded by default into ${user.home}/.maven/cache.
Plugin variables are only visible in the the Jelly execution context of the
plugin in which they are declared and only for during the plugin's
lifecycle. This context is created when the plugin is initialized, read
first loaded, and is destroyed when the plugin execution completes.
The plugin is initialised when any of the following occur:
a) the executing goal is a preGoal on a goal from that plugin
b) attainGoal has been called for that plugin
c) you have a namespace dependency on the plugin and it only works if you
reference a tag from the
plugin. This could be done using the define:taglib uri=test syntax, but
this approach proved to be unrealiable and has been deprecated.
Unfortunately, maven:set does not initialize the plugin context, as the
Maven developers had at first expected. Plugin initialization, read context
creation, occurs only as described above, and Jelly code executing in an
arbitrary maven goal context cannot determine the context in which the
plugin will run. So, to set or get the value of a plugin variable apply the
trial and error method as follows:
Number 1 is not necessary for M1 1.1B2, but may be necessary for M1 1.0.2
and/or 1.1B1 - see above
[1) insert the namespace for the artifact plugin into the local maven.xml
file's project tag, xmlns:artifact=artifact. This binds the artifact
plugin to the maven context and in some cases it is required.]
2a) if appropriate, set a preGoal on the target plugin coupled with the
desired maven:set/get statements.
2b) if 2a doesn't work or you know the plugin will not have been
initialized and you need to set a variable, you should try j:set without a
scope.
2c) if neither 2a or 2b works then try j:set with a scope of parent as a
last resort that will work in most but not all situations. [see the initial
disclaimer]
When 1st recognized, the developers thought that this issue regarding the
setting/getting of plugin variables could be fixed [see Jira Maven-1467]
But note Brett's comments about the issue, the fix caused other problems
which would have required backwards compatibility issues. Given that the
final conclusion was reached in May of 2005, when Maven 2 was scheduled for
delivery in only a few months, you can see that this was a non-starter.
This and similar issues with Jelly as an inappropriate execution
environment were major factors in the development team's decision to
rewrite Maven, which was reached a long time ago, in 2003. [see URL for Why
We Rewrote Maven]
Eclipse, WTP and Maven directory structure
Hi, FYI, it seems the Eclipse WTP team is considering supporting flexible source directory organization. They have listed 3 scenarios and one of them is Maven: http://tinyurl.com/9jn7s (scroll down to scenario 2 for the Maven part) -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r290197 - in /maven/maven-1/plugins/trunk: checkstyle/plugin.jelly dist/plugin.jelly faq/plugin.jelly jar/plugin.jelly jdiff/plugin.jelly plugin/plugin.jelly plugin/xdocs/changes.xml plugin/xdocs/tags.xml
Author: aheritier
Date: Mon Sep 19 09:37:34 2005
New Revision: 290197
URL: http://svn.apache.org/viewcvs?rev=290197view=rev
Log:
improve naming consistency : rename plugin:available by
assert:assertPluginAvailable
Modified:
maven/maven-1/plugins/trunk/checkstyle/plugin.jelly
maven/maven-1/plugins/trunk/dist/plugin.jelly
maven/maven-1/plugins/trunk/faq/plugin.jelly
maven/maven-1/plugins/trunk/jar/plugin.jelly
maven/maven-1/plugins/trunk/jdiff/plugin.jelly
maven/maven-1/plugins/trunk/plugin/plugin.jelly
maven/maven-1/plugins/trunk/plugin/xdocs/changes.xml
maven/maven-1/plugins/trunk/plugin/xdocs/tags.xml
Modified: maven/maven-1/plugins/trunk/checkstyle/plugin.jelly
URL:
http://svn.apache.org/viewcvs/maven/maven-1/plugins/trunk/checkstyle/plugin.jelly?rev=290197r1=290196r2=290197view=diff
==
--- maven/maven-1/plugins/trunk/checkstyle/plugin.jelly (original)
+++ maven/maven-1/plugins/trunk/checkstyle/plugin.jelly Mon Sep 19 09:37:34 2005
@@ -28,15 +28,15 @@
xmlns:ant=jelly:ant
xmlns:util=jelly:util
xmlns:doc=doc
- xmlns:plugin=plugin
+ xmlns:assert=assert
xmlns:maven=jelly:maven
xmlns:define=jelly:define
xmlns:checkstyle=checkstyle
j:if test=${bootstrapping == null}
-!-- fake test because the plugin:available tag is avalaible in the
maven-plugin-plugin 1.7 and newer. Thus maven will break if it's not present.
--
-plugin:available groupId=maven artifactId=maven-plugin-plugin
minRelease=1.7 neededBy=maven-faq-plugin/
-plugin:available groupId=maven artifactId=maven-xdoc-plugin
minRelease=1.10 neededBy=maven-faq-plugin/
+!-- fake test because the assert:assertPluginAvailable tag is avalaible
in the maven-plugin-plugin 1.7 and newer. Thus maven will break if it's not
present. --
+assert:assertPluginAvailable groupId=maven
artifactId=maven-plugin-plugin minRelease=1.7
neededBy=${plugin.artifactId}/
+assert:assertPluginAvailable groupId=maven
artifactId=maven-xdoc-plugin minRelease=1.10
neededBy=${plugin.artifactId}/
/j:if
!--
Modified: maven/maven-1/plugins/trunk/dist/plugin.jelly
URL:
http://svn.apache.org/viewcvs/maven/maven-1/plugins/trunk/dist/plugin.jelly?rev=290197r1=290196r2=290197view=diff
==
--- maven/maven-1/plugins/trunk/dist/plugin.jelly (original)
+++ maven/maven-1/plugins/trunk/dist/plugin.jelly Mon Sep 19 09:37:34 2005
@@ -23,11 +23,13 @@
xmlns:ant=jelly:ant
xmlns:maven=jelly:maven
xmlns:artifact=artifact
- xmlns:plugin=plugin
+ xmlns:assert=assert
xmlns:util=jelly:util
j:if test=${bootstrapping == null}
-plugin:available groupId=maven artifactId=maven-artifact-plugin
minRelease=1.3 neededBy=maven-dist-plugin/
+!-- fake test because the assert:assertPluginAvailable tag is avalaible
in the maven-plugin-plugin 1.7 and newer. Thus maven will break if it's not
present. --
+assert:assertPluginAvailable groupId=maven
artifactId=maven-plugin-plugin minRelease=1.7
neededBy=${plugin.artifactId}/
+assert:assertPluginAvailable groupId=maven
artifactId=maven-artifact-plugin minRelease=1.3
neededBy=${plugin.artifactId}/
/j:if
j:new var=distTypeHandler
className=org.apache.maven.dist.DistributionArtifactTypeHandler /
Modified: maven/maven-1/plugins/trunk/faq/plugin.jelly
URL:
http://svn.apache.org/viewcvs/maven/maven-1/plugins/trunk/faq/plugin.jelly?rev=290197r1=290196r2=290197view=diff
==
--- maven/maven-1/plugins/trunk/faq/plugin.jelly (original)
+++ maven/maven-1/plugins/trunk/faq/plugin.jelly Mon Sep 19 09:37:34 2005
@@ -26,13 +26,13 @@
xmlns:ant=jelly:ant
xmlns:define=jelly:define
xmlns:doc=doc
- xmlns:plugin=plugin
+ xmlns:assert=assert
xmlns:faq=faq
j:if test=${bootstrapping == null}
-!-- fake test because the plugin:available tag is avalaible in the
maven-plugin-plugin 1.7 and newer. Thus maven will break if it's not present.
--
-plugin:available groupId=maven artifactId=maven-plugin-plugin
minRelease=1.7 neededBy=maven-faq-plugin/
-plugin:available groupId=maven artifactId=maven-xdoc-plugin
minRelease=1.9.2 neededBy=maven-faq-plugin/
+!-- fake test because the assert:assertPluginAvailable tag is avalaible
in the maven-plugin-plugin 1.7 and newer. Thus maven will break if it's not
present. --
+assert:assertPluginAvailable groupId=maven
artifactId=maven-plugin-plugin minRelease=1.7
neededBy=${plugin.artifactId}/
+assert:assertPluginAvailable groupId=maven
artifactId=maven-xdoc-plugin minRelease=1.9.2
neededBy=${plugin.artifactId}/
/j:if
define:taglib uri=faq
Modified: maven/maven-1/plugins/trunk/jar/plugin.jelly
URL:
http://svn.apache.org/viewcvs/maven/maven-1/plugins/trunk/jar/plugin.jelly?rev=290197r1=290196r2=290197view=diff
[jira] Commented: (MNG-878) pom no longer correctly populated
[ http://jira.codehaus.org/browse/MNG-878?page=comments#action_4 ] John Casey commented on MNG-878: not sure how to tackle the second item on this list...did you have something specific in mind? pom no longer correctly populated - Key: MNG-878 URL: http://jira.codehaus.org/browse/MNG-878 Project: Maven 2 Type: Bug Components: maven-release-plugin Reporter: Brett Porter Assignee: John Casey Fix For: 2.0-beta-2 Original Estimate: 3 hours Remaining: 3 hours problems with the release pom generated by the release plugin: - RELEASE is the populated version for a plugin, instead of being resolved - plugins used in the build process but not explicitly listed in the pom are not populated - parent is not merge in -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eclipse, WTP and Maven directory structure
You can also refer to the following issue in Eclipse WTP's bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=102981 Cheers, Thomas On 9/19/05, Vincent Massol [EMAIL PROTECTED] wrote: Hi, FYI, it seems the Eclipse WTP team is considering supporting flexible source directory organization. They have listed 3 scenarios and one of them is Maven: http://tinyurl.com/9jn7s (scroll down to scenario 2 for the Maven part) -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-878) pom no longer correctly populated
[ http://jira.codehaus.org/browse/MNG-878?page=all ] John Casey updated MNG-878: --- Remaining Estimate: 2 hours (was: 0 minutes) pom no longer correctly populated - Key: MNG-878 URL: http://jira.codehaus.org/browse/MNG-878 Project: Maven 2 Type: Bug Components: maven-release-plugin Reporter: Brett Porter Assignee: John Casey Fix For: 2.0-beta-2 Original Estimate: 3 hours Time Spent: 6 hours Remaining: 2 hours problems with the release pom generated by the release plugin: - RELEASE is the populated version for a plugin, instead of being resolved - plugins used in the build process but not explicitly listed in the pom are not populated - parent is not merge in -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Eclipse, WTP and Maven directory structure
I should have mentioned that the pointer to the link below was provided by Thomas. Thanks Thomas! -Vincent -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Van de Velde Sent: lundi 19 septembre 2005 18:39 To: Maven Developers List Subject: Re: Eclipse, WTP and Maven directory structure You can also refer to the following issue in Eclipse WTP's bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=102981 Cheers, Thomas On 9/19/05, Vincent Massol [EMAIL PROTECTED] wrote: Hi, FYI, it seems the Eclipse WTP team is considering supporting flexible source directory organization. They have listed 3 scenarios and one of them is Maven: http://tinyurl.com/9jn7s (scroll down to scenario 2 for the Maven part) -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-878) pom no longer correctly populated
[ http://jira.codehaus.org/browse/MNG-878?page=comments#action_46668 ] John Casey commented on MNG-878: IMO, in order to support injection of command-line plugins, we'll have to have an audit trail in the MavenProject instance to record the plugins used and they're configurations - configuration from the command line also being a delta that we're not capturing here. I'm going to close this issue, because those would be new features, not bug fixes. pom no longer correctly populated - Key: MNG-878 URL: http://jira.codehaus.org/browse/MNG-878 Project: Maven 2 Type: Bug Components: maven-release-plugin Reporter: Brett Porter Assignee: John Casey Fix For: 2.0-beta-2 Original Estimate: 3 hours Time Spent: 6 hours Remaining: 2 hours problems with the release pom generated by the release plugin: - RELEASE is the populated version for a plugin, instead of being resolved - plugins used in the build process but not explicitly listed in the pom are not populated - parent is not merge in -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-878) pom no longer correctly populated
[ http://jira.codehaus.org/browse/MNG-878?page=all ] John Casey closed MNG-878: -- Resolution: Fixed injection of command-line configuration and mojo invocation are new features. pom no longer correctly populated - Key: MNG-878 URL: http://jira.codehaus.org/browse/MNG-878 Project: Maven 2 Type: Bug Components: maven-release-plugin Reporter: Brett Porter Assignee: John Casey Fix For: 2.0-beta-2 Original Estimate: 3 hours Time Spent: 7 hours Remaining: 0 minutes problems with the release pom generated by the release plugin: - RELEASE is the populated version for a plugin, instead of being resolved - plugins used in the build process but not explicitly listed in the pom are not populated - parent is not merge in -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r290221 - in /maven/components/trunk: maven-core-it/it2002/project/ maven-core-it/it2002/project/src/ maven-core-it/it2002/project/subproject/ maven-core-it/it2002/project/subproject/src/ maven-core-it/it2002/project/subproject/src/main/ ma...
Author: jdcasey
Date: Mon Sep 19 10:58:46 2005
New Revision: 290221
URL: http://svn.apache.org/viewcvs?rev=290221view=rev
Log:
Resolving: MNG-878, MNG-880 (again)
o Added full resolution of plugins listed in the project hierarchy
o Added better resolution of snapshots within the reactor, and resolution of
${finalName}
o Added usage of fully inherited model for release-pom.xml, to enable
convergence of all POM inheritance to a single POM with no parent.
o Improved handling of SCM info in a reactored situation.
Added:
maven/components/trunk/maven-core-it/it2002/project/subproject/
maven/components/trunk/maven-core-it/it2002/project/subproject/pom.xml
(with props)
maven/components/trunk/maven-core-it/it2002/project/subproject/src/
maven/components/trunk/maven-core-it/it2002/project/subproject/src/main/
maven/components/trunk/maven-core-it/it2002/project/subproject/src/main/java/
maven/components/trunk/maven-core-it/it2002/project/subproject/src/main/java/org/
maven/components/trunk/maven-core-it/it2002/project/subproject/src/main/java/org/apache/
maven/components/trunk/maven-core-it/it2002/project/subproject/src/main/java/org/apache/maven/
maven/components/trunk/maven-core-it/it2002/project/subproject/src/main/java/org/apache/maven/it2002/
maven/components/trunk/maven-core-it/it2002/project/subproject/src/main/java/org/apache/maven/it2002/Thing.java
(with props)
maven/components/trunk/maven-core-it/it2002/project/subproject/src/main/resources/
maven/components/trunk/maven-core-it/it2002/project/subproject/src/main/resources/META-INF/
maven/components/trunk/maven-core-it/it2002/project/subproject/src/main/resources/META-INF/plexus/
maven/components/trunk/maven-core-it/it2002/project/subproject/src/main/resources/META-INF/plexus/components.xml
(with props)
maven/components/trunk/maven-core-it/it2002/project/subproject/src/test/
maven/components/trunk/maven-core-it/it2002/project/subproject/src/test/java/
maven/components/trunk/maven-core-it/it2002/project/subproject/src/test/java/org/
maven/components/trunk/maven-core-it/it2002/project/subproject/src/test/java/org/apache/
maven/components/trunk/maven-core-it/it2002/project/subproject/src/test/java/org/apache/maven/
maven/components/trunk/maven-core-it/it2002/project/subproject/src/test/java/org/apache/maven/it2002/
maven/components/trunk/maven-core-it/it2002/project/subproject/src/test/java/org/apache/maven/it2002/ContainerDependentTest.java
(with props)
maven/components/trunk/maven-core-it/it2002/project/subproject2/
maven/components/trunk/maven-core-it/it2002/project/subproject2/pom.xml
(with props)
maven/components/trunk/maven-core-it/it2002/project/subproject2/src/
maven/components/trunk/maven-core-it/it2002/project/subproject2/src/main/
maven/components/trunk/maven-core-it/it2002/project/subproject2/src/main/java/
maven/components/trunk/maven-core-it/it2002/project/subproject2/src/main/java/org/
maven/components/trunk/maven-core-it/it2002/project/subproject2/src/main/java/org/apache/
maven/components/trunk/maven-core-it/it2002/project/subproject2/src/main/java/org/apache/maven/
maven/components/trunk/maven-core-it/it2002/project/subproject2/src/main/java/org/apache/maven/it2002/
maven/components/trunk/maven-core-it/it2002/project/subproject2/src/main/java/org/apache/maven/it2002/Thing.java
(with props)
maven/components/trunk/maven-core-it/it2002/project/subproject2/src/main/resources/
maven/components/trunk/maven-core-it/it2002/project/subproject2/src/main/resources/META-INF/
maven/components/trunk/maven-core-it/it2002/project/subproject2/src/main/resources/META-INF/plexus/
maven/components/trunk/maven-core-it/it2002/project/subproject2/src/main/resources/META-INF/plexus/components.xml
(with props)
maven/components/trunk/maven-core-it/it2002/project/subproject2/src/test/
maven/components/trunk/maven-core-it/it2002/project/subproject2/src/test/java/
maven/components/trunk/maven-core-it/it2002/project/subproject2/src/test/java/org/
maven/components/trunk/maven-core-it/it2002/project/subproject2/src/test/java/org/apache/
maven/components/trunk/maven-core-it/it2002/project/subproject2/src/test/java/org/apache/maven/
maven/components/trunk/maven-core-it/it2002/project/subproject2/src/test/java/org/apache/maven/it2002/
maven/components/trunk/maven-core-it/it2002/project/subproject2/src/test/java/org/apache/maven/it2002/ContainerDependentTest.java
(with props)
Removed:
maven/components/trunk/maven-core-it/it2002/project/src/
Modified:
maven/components/trunk/maven-core-it/it2002/project/pom.xml
maven/components/trunk/maven-plugins/maven-release-plugin/pom.xml
maven/components/trunk/maven-plugins/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
[jira] Closed: (MNG-880) release pom still contains snapshot version
[ http://jira.codehaus.org/browse/MNG-880?page=all ]
John Casey closed MNG-880:
--
Resolution: Fixed
found the problem and fixed it for dependencies, finalName, and
${project.version}.
release pom still contains snapshot version
---
Key: MNG-880
URL: http://jira.codehaus.org/browse/MNG-880
Project: Maven 2
Type: Bug
Components: maven-release-plugin
Reporter: Brett Porter
Assignee: John Casey
Fix For: 2.0-beta-2
Original Estimate: 3 hours
Time Spent: 30 minutes
Remaining: 0 minutes
this is a recent regression
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - FAILED - update] Mon Sep 19 18:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050919.18.txt
[maven2 build - SUCCESS - update] Mon Sep 19 18:00:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20050919.18.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20050919.18.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - FAILED - update] Mon Sep 19 18:30:01 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050919.183001.txt
[continuum build - FAILED - update] Mon Sep 19 19:00:01 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050919.190001.txt
svn commit: r290242 - /maven/components/trunk/maven-plugins/pom.xml
Author: jdcasey Date: Mon Sep 19 12:11:42 2005 New Revision: 290242 URL: http://svn.apache.org/viewcvs?rev=290242view=rev Log: Oops. Didn't mean to check that in. Modified: maven/components/trunk/maven-plugins/pom.xml Modified: maven/components/trunk/maven-plugins/pom.xml URL: http://svn.apache.org/viewcvs/maven/components/trunk/maven-plugins/pom.xml?rev=290242r1=290241r2=290242view=diff == --- maven/components/trunk/maven-plugins/pom.xml (original) +++ maven/components/trunk/maven-plugins/pom.xml Mon Sep 19 12:11:42 2005 @@ -152,7 +152,7 @@ modulemaven-assembly-plugin/module modulemaven-checkstyle-plugin/module modulemaven-clean-plugin/module -!-- modulemaven-clover-plugin/module -- +modulemaven-clover-plugin/module modulemaven-compiler-plugin/module modulemaven-deploy-plugin/module modulemaven-eclipse-plugin/module - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-921) release:perform must pass to m2 a profile to use if user provide one
[ http://jira.codehaus.org/browse/MNG-921?page=all ] John Casey updated MNG-921: --- Fix Version: 2.0-beta-2 Remaining Estimate: 2 hours Original Estimate: 7200 release:perform must pass to m2 a profile to use if user provide one Key: MNG-921 URL: http://jira.codehaus.org/browse/MNG-921 Project: Maven 2 Type: Improvement Components: maven-release-plugin Versions: 2.0-beta-1 Reporter: Emmanuel Venisse Assignee: John Casey Fix For: 2.0-beta-2 Original Estimate: 2 hours Remaining: 2 hours -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-920) Release plugin doesn't keep profiles in release pom
[ http://jira.codehaus.org/browse/MNG-920?page=all ] John Casey updated MNG-920: --- Fix Version: 2.0-beta-2 Remaining Estimate: 2 hours Original Estimate: 7200 Release plugin doesn't keep profiles in release pom --- Key: MNG-920 URL: http://jira.codehaus.org/browse/MNG-920 Project: Maven 2 Type: Bug Components: maven-release-plugin Versions: 2.0-beta-1 Reporter: Emmanuel Venisse Assignee: John Casey Fix For: 2.0-beta-2 Original Estimate: 2 hours Remaining: 2 hours -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - SUCCESS - update] Mon Sep 19 19:15:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20050919.191500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20050919.191500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - SUCCESS - update] Mon Sep 19 19:30:00 GMT 2005
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20050919.193000.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050919.193000.txt
[continuum build - SUCCESS - update] Mon Sep 19 20:00:00 GMT 2005
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20050919.21.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050919.21.txt
[jira] Closed: (MPPOM-2) pom:update goal contains no definition
[ http://jira.codehaus.org/browse/MPPOM-2?page=all ] Lukas Theussl closed MPPOM-2: - Resolution: Fixed Fix Version: 1.4.1 The goal pom:update has been removed in revision 114985 , also the documentation has been updated. pom:update goal contains no definition -- Key: MPPOM-2 URL: http://jira.codehaus.org/browse/MPPOM-2 Project: maven-pom-plugin Type: Bug Environment: All Reporter: Martin Lambert Fix For: 1.4.1 Below is the definition of the pom:update goal in Maven 1.0-rc1, this is also the same in 1.0 Beta: goal name=pom:update description=Update the POM from its current version to a specified version /goal This goal obviously doesn't work. Cheers, Martin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPPOM-5) pom:validate doesn't work in maven-1.1-beta-1
[ http://jira.codehaus.org/browse/MPPOM-5?page=all ] Lukas Theussl updated MPPOM-5: -- Fix Version: 1.4.2 pom:validate doesn't work in maven-1.1-beta-1 - Key: MPPOM-5 URL: http://jira.codehaus.org/browse/MPPOM-5 Project: maven-pom-plugin Type: Bug Versions: 1.4.1 Environment: Windows 2000, JDK 1.4.2_07 Reporter: Davy Toch Assignee: Lukas Theussl Fix For: 1.4.2 Attachments: project.xml Using the genapp plugin (2.2) of Maven-1.1-beta-1, I created a simple jar project. Running pom:validate on the POM gave errors due to the fact that project.xml generated by the genapp plugin isn't a model-3.0.0 POM, because e.g. the package element generated by the genapp wizard isn't defined in the model-3.0.0 xsd. So I modified project.xml in order to be conform with the model-3.0.0 xsd. However running pom:validate still gives the following error: ~~~ $maven -e pom:validate __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-1 build:start: pom:verify-version: pom:validate: [echo] == CUSTOM ADDED IN POM PLUGIN [echo] XSD file : c:\devtools\maven-1.1-beta-1/maven-project-3.xsd [echo] POM file : C:\tmp\myapp\project.xml [echo] === [java] C:\tmp\myapp\project.xml:19:10: error: cvc-elt.1: Cannot find the declaration of element 'project'. [java] [ERROR] Java Result: 1 BUILD SUCCESSFUL Total time : 4 seconds Finished at : zondag 31 juli 2005 12:58:49 CEST ~~~ The POM file project.xml is included as attachment. Additional question : is the pom plugin still necessary from maven-1.1-beta-1 onwards, because I thought the Maven core would verify more strictly the POM itself (cf http://maven.apache.org/reference/backwards-compatibility.html)? Regards, Davy Toch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPPOM-1) pom:validate does not work with extend
[ http://jira.codehaus.org/browse/MPPOM-1?page=all ] Lukas Theussl updated MPPOM-1: -- Assign To: Lukas Theussl Fix Version: 1.4.2 Environment: pom:validate does not work with extend Key: MPPOM-1 URL: http://jira.codehaus.org/browse/MPPOM-1 Project: maven-pom-plugin Type: Bug Reporter: Vincent Massol Assignee: Lukas Theussl Fix For: 1.4.2 For example, in the Maven plugins if you type maven pom:validate you get several errors even though the missing elements are defined in the parent project.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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r290257 - /maven/components/trunk/maven-core-it/integration-tests.txt
Author: jdcasey Date: Mon Sep 19 13:26:01 2005 New Revision: 290257 URL: http://svn.apache.org/viewcvs?rev=290257view=rev Log: Commenting out it0063 until I can get it to work. Modified: maven/components/trunk/maven-core-it/integration-tests.txt Modified: maven/components/trunk/maven-core-it/integration-tests.txt URL: http://svn.apache.org/viewcvs/maven/components/trunk/maven-core-it/integration-tests.txt?rev=290257r1=290256r2=290257view=diff == --- maven/components/trunk/maven-core-it/integration-tests.txt (original) +++ maven/components/trunk/maven-core-it/integration-tests.txt Mon Sep 19 13:26:01 2005 @@ -2,7 +2,7 @@ it0066 it0065 it0064 -it0063 +#it0063 it0062 it0061 it0060 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - SUCCESS - update] Mon Sep 19 20:30:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20050919.203000.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20050919.203000.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Eclipse, WTP and Maven directory structure
So go ahead and vote for it! Popular request does influence them. :) Vincent Massol wrote: I should have mentioned that the pointer to the link below was provided by Thomas. Thanks Thomas! -Vincent -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Van de Velde Sent: lundi 19 septembre 2005 18:39 To: Maven Developers List Subject: Re: Eclipse, WTP and Maven directory structure You can also refer to the following issue in Eclipse WTP's bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=102981 Cheers, Thomas On 9/19/05, Vincent Massol [EMAIL PROTECTED] wrote: Hi, FYI, it seems the Eclipse WTP team is considering supporting flexible source directory organization. They have listed 3 scenarios and one of them is Maven: http://tinyurl.com/9jn7s (scroll down to scenario 2 for the Maven part) -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Eclipse, WTP and Maven directory structure
The proposed directory layout is the old one in maven 1. Perhaps, should we say to them what the new project's layout is ? Arnaud So go ahead and vote for it! Popular request does influence them. :) Vincent Massol wrote: I should have mentioned that the pointer to the link below was provided by Thomas. Thanks Thomas! -Vincent -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Van de Velde Sent: lundi 19 septembre 2005 18:39 To: Maven Developers List Subject: Re: Eclipse, WTP and Maven directory structure You can also refer to the following issue in Eclipse WTP's bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=102981 Cheers, Thomas On 9/19/05, Vincent Massol [EMAIL PROTECTED] wrote: Hi, FYI, it seems the Eclipse WTP team is considering supporting flexible source directory organization. They have listed 3 scenarios and one of them is Maven: http://tinyurl.com/9jn7s (scroll down to scenario 2 for the Maven part) -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r290250 - in /maven/continuum/trunk: continuum-plexus-application/pom.xml pom.xml
I thought XFire was working now?
- Brett
[EMAIL PROTECTED] wrote:
Author: evenisse
Date: Mon Sep 19 12:42:46 2005
New Revision: 290250
URL: http://svn.apache.org/viewcvs?rev=290250view=rev
Log:
o Fix final name
o Remove continuum-xfire from dependency management
Modified:
maven/continuum/trunk/continuum-plexus-application/pom.xml
maven/continuum/trunk/pom.xml
Modified: maven/continuum/trunk/continuum-plexus-application/pom.xml
URL:
http://svn.apache.org/viewcvs/maven/continuum/trunk/continuum-plexus-application/pom.xml?rev=290250r1=290249r2=290250view=diff
==
--- maven/continuum/trunk/continuum-plexus-application/pom.xml (original)
+++ maven/continuum/trunk/continuum-plexus-application/pom.xml Mon Sep 19
12:42:46 2005
@@ -211,7 +211,7 @@
configuration
descriptorsrc/assembly/bin.xml/descriptor
!-- TODO: isn't this the default? if not, can we use the ${pom.}
expression? --
- finalNamecontinuum-1.0-alpha-4-SNAPSHOT/finalName
+ finalNamecontinuum-1.0-alpha-4/finalName
/configuration
executions
execution
Modified: maven/continuum/trunk/pom.xml
URL:
http://svn.apache.org/viewcvs/maven/continuum/trunk/pom.xml?rev=290250r1=290249r2=290250view=diff
==
--- maven/continuum/trunk/pom.xml (original)
+++ maven/continuum/trunk/pom.xml Mon Sep 19 12:42:46 2005
@@ -149,11 +149,13 @@
artifactIdcontinuum-web/artifactId
version1.0-alpha-4-SNAPSHOT/version
/dependency
+ !--
dependency
groupIdorg.apache.maven.continuum/groupId
artifactIdcontinuum-xfire/artifactId
version1.0-alpha-4-SNAPSHOT/version
/dependency
+ --
dependency
groupIdorg.apache.maven.continuum/groupId
artifactIdcontinuum-xmlrpc/artifactId
svn commit: r290276 - in /maven/components/trunk: maven-core-it/it2002/project/subproject2/pom.xml maven-plugins/maven-release-plugin/pom.xml maven-plugins/maven-surefire-plugin/pom.xml maven-project/src/main/java/org/apache/maven/project/ModelUtils.java
Author: jdcasey Date: Mon Sep 19 14:24:40 2005 New Revision: 290276 URL: http://svn.apache.org/viewcvs?rev=290276view=rev Log: Resolving: MNG-920, and setting the version of maven-release-plugin to a rev of -beta-1 instead of -SNAPSHOT, to allow locally installed versions to work without tweaking the version locally. Modified: maven/components/trunk/maven-core-it/it2002/project/subproject2/pom.xml maven/components/trunk/maven-plugins/maven-release-plugin/pom.xml maven/components/trunk/maven-plugins/maven-surefire-plugin/pom.xml maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/ModelUtils.java Modified: maven/components/trunk/maven-core-it/it2002/project/subproject2/pom.xml URL: http://svn.apache.org/viewcvs/maven/components/trunk/maven-core-it/it2002/project/subproject2/pom.xml?rev=290276r1=290275r2=290276view=diff == --- maven/components/trunk/maven-core-it/it2002/project/subproject2/pom.xml (original) +++ maven/components/trunk/maven-core-it/it2002/project/subproject2/pom.xml Mon Sep 19 14:24:40 2005 @@ -28,4 +28,16 @@ /dependency /dependencies + profiles +profile + idenv-test/id + activation +property + nameenv/name + valuetest/value +/property + /activation +/profile + /profiles + /project Modified: maven/components/trunk/maven-plugins/maven-release-plugin/pom.xml URL: http://svn.apache.org/viewcvs/maven/components/trunk/maven-plugins/maven-release-plugin/pom.xml?rev=290276r1=290275r2=290276view=diff == --- maven/components/trunk/maven-plugins/maven-release-plugin/pom.xml (original) +++ maven/components/trunk/maven-plugins/maven-release-plugin/pom.xml Mon Sep 19 14:24:40 2005 @@ -8,7 +8,7 @@ artifactIdmaven-release-plugin/artifactId packagingmaven-plugin/packaging nameMaven Release plugin/name - version2.0-beta-2-SNAPSHOT/version + version2.0-beta-1-rev1/version dependencies dependency groupIdorg.apache.maven/groupId Modified: maven/components/trunk/maven-plugins/maven-surefire-plugin/pom.xml URL: http://svn.apache.org/viewcvs/maven/components/trunk/maven-plugins/maven-surefire-plugin/pom.xml?rev=290276r1=290275r2=290276view=diff == --- maven/components/trunk/maven-plugins/maven-surefire-plugin/pom.xml (original) +++ maven/components/trunk/maven-plugins/maven-surefire-plugin/pom.xml Mon Sep 19 14:24:40 2005 @@ -29,13 +29,13 @@ dependency groupIdsurefire/groupId artifactIdsurefire/artifactId - version1.3/version + version1.4-SNAPSHOT/version scoperuntime/scope /dependency dependency groupIdsurefire/groupId artifactIdsurefire-booter/artifactId - version1.3/version + version1.4-SNAPSHOT/version /dependency dependency groupIdplexus/groupId @@ -44,4 +44,4 @@ scoperuntime/scope /dependency /dependencies -/project \ No newline at end of file +/project Modified: maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/ModelUtils.java URL: http://svn.apache.org/viewcvs/maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/ModelUtils.java?rev=290276r1=290275r2=290276view=diff == --- maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/ModelUtils.java (original) +++ maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/ModelUtils.java Mon Sep 19 14:24:40 2005 @@ -16,16 +16,32 @@ * limitations under the License. */ +import org.apache.maven.model.Activation; +import org.apache.maven.model.ActivationFile; +import org.apache.maven.model.ActivationProperty; +import org.apache.maven.model.Build; +import org.apache.maven.model.BuildBase; +import org.apache.maven.model.Dependency; +import org.apache.maven.model.DependencyManagement; +import org.apache.maven.model.DistributionManagement; +import org.apache.maven.model.Exclusion; import org.apache.maven.model.Goal; import org.apache.maven.model.Model; import org.apache.maven.model.Parent; import org.apache.maven.model.Plugin; import org.apache.maven.model.PluginContainer; import org.apache.maven.model.PluginExecution; +import org.apache.maven.model.PluginManagement; +import org.apache.maven.model.Profile; +import org.apache.maven.model.Relocation; import org.apache.maven.model.ReportPlugin; import org.apache.maven.model.ReportSet; import org.apache.maven.model.Reporting; import org.apache.maven.model.Repository; +import org.apache.maven.model.RepositoryBase; +import org.apache.maven.model.RepositoryPolicy; +import org.apache.maven.model.Resource; +import org.apache.maven.model.Site; import
[jira] Closed: (MNG-920) Release plugin doesn't keep profiles in release pom
[ http://jira.codehaus.org/browse/MNG-920?page=all ] John Casey closed MNG-920: -- Resolution: Fixed Release plugin doesn't keep profiles in release pom --- Key: MNG-920 URL: http://jira.codehaus.org/browse/MNG-920 Project: Maven 2 Type: Bug Components: maven-release-plugin Versions: 2.0-beta-1 Reporter: Emmanuel Venisse Assignee: John Casey Fix For: 2.0-beta-2 Original Estimate: 2 hours Time Spent: 2 hours Remaining: 0 minutes -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Out of memory exceptions
Though the devs are interested to hear what memory usage you were encountering... Cocoon could be a good test case to see if we can reduce the amount of memory used. - Brett Carsten Ziegeler wrote: Kenney Westerhof schrieb: On Mon, 19 Sep 2005, Carsten Ziegeler wrote: Yes, set the environment variable MAVEN_OPTS; it's value is passed as JVM arguments. Ok, thanks Btw this is a typical user question, you best use the users list for these types of questions. Yepp, you're right - sorry! Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
