[jira] Created: (CONTINUUM-1567) Continuum properties available in the maven context
Continuum properties available in the maven context
---
Key: CONTINUUM-1567
URL: http://jira.codehaus.org/browse/CONTINUUM-1567
Project: Continuum
Issue Type: Improvement
Components: Core system
Affects Versions: 1.1
Reporter: Teun Hakvoort
Priority: Minor
Make continuum properties available in the maven context.
So it's possible to use properties such as: ${continuum.buildNumber} (the
current buildnumber), ${continuum.logFile} (reference to the log file), etc.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-592) For upgrade, assume that existing users have been verified (pre-beta-4)
[ http://jira.codehaus.org/browse/MRM-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRM-592: - Fix Version/s: 1.1 > For upgrade, assume that existing users have been verified (pre-beta-4) > --- > > Key: MRM-592 > URL: http://jira.codehaus.org/browse/MRM-592 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-beta-4 >Reporter: James William Dumay > Fix For: 1.1 > > > Hey guys, > Upgraded my Archiva instances to beta-4 from a beta-3 SNAPSHOT and noticed > that none of the user accounts could be accessed because they had not been > verified with the user via email. > Can we assume when archiva is upgraded that all existing users have been > verified in this case? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1816) Upload Joda-Time jsptags 1.0.1
Upload Joda-Time jsptags 1.0.1 -- Key: MAVENUPLOAD-1816 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1816 Project: maven-upload-requests Issue Type: Task Reporter: Stephen Colebourne http://joda-time.sourceforge.net/joda-time-jsptags-1.0.1-bundle.jar http://joda-time.sourceforge.net/contrib/jsptags/ http://joda-time.sourceforge.net/contrib/jsptags/team-list.html Please upload joda-time-jsptags-1.0.1, thanks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MECLIPSE-264) Support for WTP2.0
[ http://jira.codehaus.org/browse/MECLIPSE-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MECLIPSE-264 started by Arnaud Heritier. > Support for WTP2.0 > -- > > Key: MECLIPSE-264 > URL: http://jira.codehaus.org/browse/MECLIPSE-264 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: WTP support >Affects Versions: 2.4 >Reporter: Geir Pettersen >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: maven-264.patch, MECLIPSE-264-NEW.patch > > > As far as I can see this plugin only supports WTP version 1.0 and 1.5. while > WTP 2.0 is already released in milestone 6 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-343) classpath entries sort order changes
[ http://jira.codehaus.org/browse/MECLIPSE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MECLIPSE-343. Assignee: Arnaud Heritier Resolution: Duplicate duplicates MECLIPSE-294 > classpath entries sort order changes > > > Key: MECLIPSE-343 > URL: http://jira.codehaus.org/browse/MECLIPSE-343 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: MacOSX 10.4.10, Maven 2.0.6 >Reporter: Marc Guenther >Assignee: Arnaud Heritier >Priority: Trivial > > The order of the entries in the .classpath file is not fixed. It changes > everytime I run mvn eclipse:eclipse. This makes SVN think the file has > changed, even though semantically it hasn't. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-372) Surefire does not work properly with maven.repo.local
Surefire does not work properly with maven.repo.local - Key: SUREFIRE-372 URL: http://jira.codehaus.org/browse/SUREFIRE-372 Project: Maven Surefire Issue Type: Bug Components: classloading Affects Versions: 2.3, 2.4 Reporter: Kasper Nielsen Surefire fails with the following exception when maven.repo.local is set: org.apache.maven.surefire.booter.SurefireExecutionException: junit/framework/TestCase; nested exception is java.lang.NoClassDefFoundError: junit/framework/TestCase java.lang.NoClassDefFoundError: junit/framework/TestCase at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) Steps to reproduce- mvn archetype:create -DgroupId=sample.group.id -DartifactId=foo -DartifaceId=maven-artifact-quickstart mvn -Dmaven.repo.local=tmp-repo -f foo/pom.xml install -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1565) continuum does not see update files via scm plugin
[
http://jira.codehaus.org/browse/CONTINUUM-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113844
]
Spencer White commented on CONTINUUM-1565:
--
That is correct. The find statement is executed in the working directory for
the project.
> continuum does not see update files via scm plugin
> --
>
> Key: CONTINUUM-1565
> URL: http://jira.codehaus.org/browse/CONTINUUM-1565
> Project: Continuum
> Issue Type: Bug
> Components: SCM
>Affects Versions: 1.1-beta-4
> Environment: linux 2.6.16.18, Perforce Server 2005.2.PATCH/100601,
> maven 2.0.7, jdk 1.6.0_03
>Reporter: Spencer White
>
> BuildController does not see changes and therefor does not do a build. Here
> is how I tested:
> 1. cd /project/dir
> 2. find ./ -type f -exec md5sum {} \; > 2.old
> 3. check in changes to perforce from another client
> 4. wait for Continuum to do run it's scheduled task to update code
> 5. Continuum:
> 346298228 [pool-1-thread-1] INFO
> org.apache.maven.continuum.buildcontroller.BuildController:default - Merging
> SCM results
> 346298254 [pool-1-thread-1] INFO
> org.apache.maven.continuum.buildcontroller.BuildController:default - The
> project was not built because no changes were detected in sources since the
> last build.
> 346298255 [pool-1-thread-1] INFO
> org.apache.maven.continuum.buildcontroller.BuildController:default - No
> changes, not building
> 6. find ./ -type f -exec md5sum {} \; > 2.new
> 7. diff 2.old 2.new
> 28c27
> < d408dc1aab6914b85e3bd2e1ae609368
> ./src/main/java/com/visto/apps/client/IPhoneyClientProtocolHandler.java
> ---
> > 79dfa098c212744ffec226a8126bb3f5
> > ./src/main/java/com/visto/apps/client/IPhoneyClientProtocolHandler.java
> IPhoneyClientProtocolHandler.java was the file that I had changed and checked
> into perforce.
> In Continuum 1.0.3 this project worked fine but it looks like maven-scm used
> p4 sync to update files. Then I had to add another project on the same
> perforce server and had to upgrade to 1.1-beta-4.
> This may have something to do with the maven-scm plugin possibly?
> Thanks.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-545) Documentation for configuring for Tomcat is invalid
[
http://jira.codehaus.org/browse/MRM-545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113842
]
Eduardo Issao Ito commented on MRM-545:
---
I've just installed Archiva-1.0-beta4 in Tomcat-5.5.25 and what I did was:
1. Compiled the source manually and uncompressed the file
archiva-web/archiva-webapp/target/archiva-webapp-1.0-beta-4.war into
$CATALINA_HOME/archiva/archiva-webapp-1.0-beta-4
2. Copied mail-1.4.jar and derby-10.1.3.1.jar to $CATALINA_HOME/commons/lib
3. Created the file $CATALINA_HOME/conf/Catalina/localhost/archiva.xml
4. I didn't changed $CATALINA_HOME/conf/web.xml as stated n the docs. Is it
still needed? What is the bug?
5. Edited the file $CATALINA_HOME/bin/setenv.sh to add the line below:
export CATALINA_OPTS="-Dappserver.home=$CATALINA_HOME
-Dappserver.base=$CATALINA_HOME"
It seems to be working!
But there is an issue: the derby database and derby.log are created in the
current directory from where I start Tomcat...
How can I fix the path of derby?
By the way, why is derby.jar in a Tomcat directry instead of WEB-INF/lib inside
the war?
> Documentation for configuring for Tomcat is invalid
> ---
>
> Key: MRM-545
> URL: http://jira.codehaus.org/browse/MRM-545
> Project: Archiva
> Issue Type: Bug
> Components: documentation
>Affects Versions: 1.0-beta-2
> Environment: Windows XP, Tomcat-5.5.17/Tomcat-5.5.20, JDK-1.5.0_06
>Reporter: William Ferguson
>Priority: Critical
> Fix For: 1.0
>
> Attachments: bad-log-filename.log, mail-auth-class-not-found.log
>
>
> Following http://maven.apache.org/archiva/guides/getting-started.html for
> Tomcat didn't get me started.
> I'll go through it point by point
> # Create a directory in tomcat called archiva, at the same level as bin,
> conf, logs and the others.
> # Copy the war file from apps/archiva/lib into the new directory
> There is not apps/archiva/lib in the 1.0-beta-2 distribution.
> apps contains a single file : archiva-plexus-application-1.0-beta-2.jar which
> does itself contain a war file, so I extracted that file and copied it to the
> TOMCAT_HOME/archiva folder.
> NB IMHO modifying TOMCAT in this manner smells all wrong.
> # Create a conf/Catalina/localhost/archiva.xml file with the following data:
> yadda, yadda
> The docBase attribute refers to archiva-webapp-1.0-SNAPSHOT.war instead of
> archiva-webapp-1.0-beta-2.war
> No idea why a javax.mail.Session needs to be configured here, haven't seen
> any documentation in Archiva that suggests it send, receives email. But this
> was a slight pain when configuring for Tomcat-5.5.20 as I needed to follow
> the extra steps for the missing classes. If the MailSession is not required
> it would be better to avoid this pain by simplifying the config.
> Again modifying TOMCAT like this does not feel right. Surely this config
> could be contained within the webapp.
> # Copy $HOME/.m2/org/apache/derby/derby/10.1.3.1/derby-10.1.3.1.jar (or from
> the remote repository) into the Tomcat common/lib
> I am *really* against this as I have now introduced Derby-10.1.3.1 into the
> classpath of 8all* my other applications running on that Tomcat instance.
> Surely this library could be packaged up into the webapp.
> # To deal with a current bug, you'll also need to add the following to your
> $catalina.home/conf/web.xml in the relevant section (search for jspx):
> Again, surely this could be included in the config for the Archiva webapp
> instead of introduced into Tomcat generally. This heavy handed approach makes
> maintenance difficult, eg upgrading to a new version of Tomcat is now
> extremely onerous.
> OK, so having followed the instructions above, when I try to startup Tomcat
> the first thin I get is a failure with the logging sub system. see attached
> bad-log-filename.log. I believe this is due to the fact that
> ${appserver.base} in log4j.xml has never been set:
> {code}
>
> {code}
> Next, it fails as it can't find javax.mail.Authenticator (this is
> Tomcat-5.5.17).
> NB I never saw any indication that "schema SA does not exist" as the final
> note suggests. But perhaps this was because Archiva never got that far.
> Certainly no application is available at http://localhost:8080/archiva/
> Anyway, by this stage I became discouraged enough that I gave up.
> Its a shame really as I would have liked to be able to compare Archiva
> against Proximity and Artifactory, both of which I managed to get setup in
> under 10 mins including vastly restructuring the default repository config
> that they ship with.
> Brett, hope that helps.
> Further notes:
> I really don't like modifying the contents of TOMCAT_HOME other than to
> deploy a WAR to TOMCAT_HOME/webapps.
> And the infrastructure team weren't impressed either and
[jira] Created: (MRM-595) regression : server-side relocation fails
regression : server-side relocation fails - Key: MRM-595 URL: http://jira.codehaus.org/browse/MRM-595 Project: Archiva Issue Type: Bug Components: WebDAV interface Affects Versions: 1.0-beta-4 Reporter: nicolas de loof 1.0-beta-4 introduces a regression in maven1 request handling : simply try to get : http://localhost:8080/archiva/repository/internal/servletapi/jars/servletapi-2.4.jar two causes : 1. as fetchContentFromProxies MAY change the request pathInfo when relocation occurs, it MUST be called before resource file is build based on request.getLogicalResource(). 2. getLogicalResource() is used to get the resource path. The value returned is not affected when the request PathInfo has been changed. point 2 may require some changes in plexus DavServerRequest : compute the logical resource on-demand, or add a new public method to set it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-594) add some minimal hook in LegacyPathParser to allow exception management in artifact resolution
add some minimal hook in LegacyPathParser to allow exception management in
artifact resolution
--
Key: MRM-594
URL: http://jira.codehaus.org/browse/MRM-594
Project: Archiva
Issue Type: Improvement
Components: repository interface
Affects Versions: 1.0-beta-4
Reporter: nicolas de loof
Some existing artifacts are not available to maven1. jaxen-1.0-FCS-full for
example (use by some core maven1 plugins) can only be obtained by specifying a
classifier "full".
The maven1 request "/jaxen/jars/jaxen-1.0-FCS-full.jar" is converted as
artifact [ jaxen : jaxen : 1.0-FCS-full ], that doesn't exist.
The LegacyPathParser is allready very complex and works for many artifact, but
cannot handle classifiers as they can be any string.
A solution to help archiva managers should be to use an resolution exception
list :
if ( exceptions.contains( path ) )
{
String exception = exceptions.getProperty( path );
String[] ref = exception.split( ":" );
artifact.setGroupId( ref[0] );
artifact.setArtifactId( ref[1] );
artifact.setVersion( ref[2] );
if ( ref.length > 3 )
{
artifact.setClassifier( ref[3] );
}
return artifact;
}
based on a simple properties file :
jaxen/jars/jaxen-1.0-FCS-full.jar = jaxen:jaxen:1.0-FCS:full
This would allow admins to quickly fix such issues and not require archiva to
find a way to make legacy path deterministic.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHECKSTYLE-79) CLONE -Allow multiple sources directories in input
CLONE -Allow multiple sources directories in input -- Key: MCHECKSTYLE-79 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-79 Project: Maven 2.x Checkstyle Plugin Issue Type: Wish Affects Versions: 2.1 Environment: Maven module with multiple sources directories (due to external constraints) Reporter: Benjamin Pochat Priority: Minor For different reasons we can have multiple sources directories even in a Maven Projet. The sourceDirectory attribute allows only one directory, it would be great to allow several directories. http://maven.apache.org/plugins/maven-checkstyle-plugin/checkstyle-mojo.html#sourceDirectory -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCLEAN-25) Optionally don't delete the 'target ' directory
[ http://jira.codehaus.org/browse/MCLEAN-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113832 ] Joern Huxhorn commented on MCLEAN-25: - Very nice, thank you! This does not solve the problem of vanishing explorer-windows but it does solve our main problem of failed builds. Can we expect a 2.2 release in the near future? > Optionally don't delete the 'target ' directory > > > Key: MCLEAN-25 > URL: http://jira.codehaus.org/browse/MCLEAN-25 > Project: Maven 2.x Clean Plugin > Issue Type: New Feature >Reporter: Joern Huxhorn >Assignee: Vincent Siveton > Fix For: 2.2 > > Attachments: clean-patch.patch > > > Would it be possible to add an option to the clean-plugin so only the content > of the target folder(s) are deleted but not the directory itself? > This would help developers using windoze quite a lot since: > - clean fails if you happen to have opened a command line with target as the > current dir. > - windoze closes explorer windows pointing to deleted directories, so you > have to reopen the windows after a clean install > Those problems would both be solved by an option like deleteRoot=false or > something. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3286) execution.inherited field is ignored
execution.inherited field is ignored Key: MNG-3286 URL: http://jira.codehaus.org/browse/MNG-3286 Project: Maven 2 Issue Type: Bug Components: Inheritance and Interpolation Affects Versions: 2.0.7 Reporter: Brian Fox I have a plugin with multiple executions, one of them I only want to apply to the parent. I set the execution.inherited=false, the execution is still run on all the children. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHECKSTYLE-77) Allow multiple sources directories in input
[ http://jira.codehaus.org/browse/MCHECKSTYLE-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113828 ] Benjamin Pochat commented on MCHECKSTYLE-77: I totally agree with Gerald. It would be very nice that checkstyle plugin workes with build-helper-maven-plugin (http://mojo.codehaus.org/build-helper-maven-plugin/usage.html) Benjamin > Allow multiple sources directories in input > --- > > Key: MCHECKSTYLE-77 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-77 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Wish >Affects Versions: 2.1 > Environment: Maven module with multiple sources directories (due to > external constraints) >Reporter: Gerald Reinhart >Priority: Minor > > For different reasons we can have multiple sources directories even in a > Maven Projet. > The sourceDirectory attribute allows only one directory, it would be great to > allow several directories. > http://maven.apache.org/plugins/maven-checkstyle-plugin/checkstyle-mojo.html#sourceDirectory -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MENFORCER-24) create a rule to check that certain profiles are activated.
create a rule to check that certain profiles are activated. --- Key: MENFORCER-24 URL: http://jira.codehaus.org/browse/MENFORCER-24 Project: Maven 2.x Enforcer Plugin Issue Type: New Feature Components: Standard Rules Affects Versions: 1.0-alpha-3 Reporter: Brian Fox Assignee: Brian Fox -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DOXIA-187) Use AbstractSinkTest in DocBookBookSinkTest
[ http://jira.codehaus.org/browse/DOXIA-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-187. --- Assignee: Lukas Theussl Resolution: Fixed I re-wrote the test. You can always add additional unit tests if you want. > Use AbstractSinkTest in DocBookBookSinkTest > --- > > Key: DOXIA-187 > URL: http://jira.codehaus.org/browse/DOXIA-187 > Project: Maven Doxia > Issue Type: Test > Components: Book >Affects Versions: 1.0-alpha-9 >Reporter: Dave Syer >Assignee: Lukas Theussl >Priority: Minor > Fix For: 1.0-beta-1 > > > Lukas: the DocBookBookSinkTest should be written the same way as > DocBookSinkTest, ie extends AbstractSinkTest (not AbstractSinkTestCase). > Dave: I'm not so sure it's a good idea, but I'll put it in JIRA anyway. The > AbstractSinkTest would just test the base class again (which has already been > tested in the docbook module). It would be better to have a real unit test > for the BookSink which didn't depend on the base class behaviour at all. > Could be achieved by adopting a delegate pattern for the BookSink instead of > extending the DocBookSink - but is it worth the effort when there is a > regression test that covers the book extensions pretty well? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3086) NullPointerException in ResolutionNode.getTrail(ResolutionNode.java:136)
[
http://jira.codehaus.org/browse/MNG-3086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113824
]
egor kolesnikov commented on MNG-3086:
--
There's a small workaround for this bug.
org.apache.maven.artifact.resolver.ResolutionNode.getTrail(ResolutionNode.java:136)
replate initial code
String version = artifact.getSelectedVersion().toString();
artifact.selectVersion( version );
with:
// set the recommended version
if(artifact.getSelectedVersion()==null) {
throw new RuntimeException("selected version is null:" +
artifact.getArtifactId());
}
String version = artifact.getSelectedVersion().toString();
artifact.selectVersion( version );
After that Maven will throw definitive exception instead of NPE in this case,
thus you could find out which dependency was the actual reason.
In my case the problem was in commons-digester [1.6) - I just added the exact
version 1.7 to the root POM's dependencyManagement and maven does not fail any
more.
Hope that will help :-)
> NullPointerException in ResolutionNode.getTrail(ResolutionNode.java:136)
>
>
> Key: MNG-3086
> URL: http://jira.codehaus.org/browse/MNG-3086
> Project: Maven 2
> Issue Type: Bug
> Components: Errors
>Affects Versions: 2.0.7
>Reporter: Thomas Leonard
> Fix For: 2.0.x
>
>
> After upgrading from 2.0.6 to 2.0.7, our build fails with:
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException
> at
> org.apache.maven.artifact.resolver.ResolutionNode.getTrail(ResolutionNode.java:136)
> at
> org.apache.maven.artifact.resolver.ResolutionNode.filterTrail(ResolutionNode.java:211)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:89)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272)
> at
> org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Thanks,
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCLEAN-25) Optionally don't delete the 'target ' directory
[ http://jira.codehaus.org/browse/MCLEAN-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113823 ] Vincent Siveton commented on MCLEAN-25: --- You could also use ignoreErrors parameter (see MCLEAN-22 ) > Optionally don't delete the 'target ' directory > > > Key: MCLEAN-25 > URL: http://jira.codehaus.org/browse/MCLEAN-25 > Project: Maven 2.x Clean Plugin > Issue Type: New Feature >Reporter: Joern Huxhorn >Assignee: Vincent Siveton > Fix For: 2.2 > > Attachments: clean-patch.patch > > > Would it be possible to add an option to the clean-plugin so only the content > of the target folder(s) are deleted but not the directory itself? > This would help developers using windoze quite a lot since: > - clean fails if you happen to have opened a command line with target as the > current dir. > - windoze closes explorer windows pointing to deleted directories, so you > have to reopen the windows after a clean install > Those problems would both be solved by an option like deleteRoot=false or > something. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MCLEAN-27) fileset directory does not work as expected when cleaning "modules" in sub-directories
[
http://jira.codehaus.org/browse/MCLEAN-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed MCLEAN-27.
-
Assignee: Vincent Siveton
Resolution: Fixed
Fix Version/s: 2.2
o handle subproject dir
> fileset directory does not work as expected when cleaning "modules" in
> sub-directories
> --
>
> Key: MCLEAN-27
> URL: http://jira.codehaus.org/browse/MCLEAN-27
> Project: Maven 2.x Clean Plugin
> Issue Type: Improvement
>Affects Versions: 2.1.1
>Reporter: Jacob Robertson
>Assignee: Vincent Siveton
> Fix For: 2.2
>
>
> Following the example given on the plugin site, I used a fileset with a
> directory like so.
> {code}
>
> maven-clean-plugin
>
>
>
>
> src/main/application
>
>
> *.jar
>
>
>
>
>
> {code}
> I did this, or a variation on it, to several projects. I then created a
> parent pom in the directory above those projects, added them as modules in
> that pom, and ran "mvn clean" expecting to have those specified directories
> cleaned for me (of all jar files). However, it did not work. To get it to
> work, I had to prefix my directories with ${basedir}, for example
> "${basedir}/src/main/application".
> If this is the desired behavior, I recommend adding one sentence to the
> documentation to explain this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1815) upload new release 1.11 to org.mentaframework
upload new release 1.11 to org.mentaframework -- Key: MAVENUPLOAD-1815 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1815 Project: maven-upload-requests Issue Type: Task Reporter: Fernando Boaglio The Mentawai goal is to be a simple, flexible, joyful and productive Java web framework. This is a new release with a lot of improvements . TIA -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3285) Cached plugins are used, even when different versions are specifically declared
[ http://jira.codehaus.org/browse/MNG-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nigel Magnay closed MNG-3285. - Resolution: Duplicate sorry - jira obviously doesn't like safari. dup of MNG-3284 > Cached plugins are used, even when different versions are specifically > declared > > > Key: MNG-3285 > URL: http://jira.codehaus.org/browse/MNG-3285 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies, Plugins and Lifecycle >Affects Versions: 2.0.7 >Reporter: Nigel Magnay >Priority: Critical > Attachments: pluginbug.tar > > > In the attached project, you can build module A, then build module B, but the > top level aggregator project will fail at B. > The reason this happens is that maven seems to cache plugins. When B is built > in isolation, all things are fine - but when built in aggregation, one of the > plugins that it uses has already been instantiated, and so it uses that one. > This is incorrect, since the declared version is different in B, and is > relying on functionality not present in the version declared in A. > I have seen similar behaviour when a plugin relies on other plugins to get > work done - all of a sudden a build mysteriously stops working, because of a > completely unrelated plugin. > This is pretty painful because > - it's possible to get into a 'no solution', where one project relies on one > behaviour so can't upgrade, and one project relies on new behaviour, so can't > downgrade. > - you get builds that work OK in isolation, but not in their project. This is > bad. Also builds tied together in bigger aggregator projects can fail in > mysterious ways (mysterious because the user /has/ specified the plugin > version, and maven has ignored them, or it's a plugin dependency that got > there first) > - subtle build ordering changes can cause new failures (the example has B > depend on A - but the bug might only manifest itself in certain build orders > that change even when B and A don't). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3285) Cached plugins are used, even when different versions are specifically declared
Cached plugins are used, even when different versions are specifically declared Key: MNG-3285 URL: http://jira.codehaus.org/browse/MNG-3285 Project: Maven 2 Issue Type: Bug Components: Dependencies, Plugins and Lifecycle Affects Versions: 2.0.7 Reporter: Nigel Magnay Priority: Critical Attachments: pluginbug.tar In the attached project, you can build module A, then build module B, but the top level aggregator project will fail at B. The reason this happens is that maven seems to cache plugins. When B is built in isolation, all things are fine - but when built in aggregation, one of the plugins that it uses has already been instantiated, and so it uses that one. This is incorrect, since the declared version is different in B, and is relying on functionality not present in the version declared in A. I have seen similar behaviour when a plugin relies on other plugins to get work done - all of a sudden a build mysteriously stops working, because of a completely unrelated plugin. This is pretty painful because - it's possible to get into a 'no solution', where one project relies on one behaviour so can't upgrade, and one project relies on new behaviour, so can't downgrade. - you get builds that work OK in isolation, but not in their project. This is bad. Also builds tied together in bigger aggregator projects can fail in mysterious ways (mysterious because the user /has/ specified the plugin version, and maven has ignored them, or it's a plugin dependency that got there first) - subtle build ordering changes can cause new failures (the example has B depend on A - but the bug might only manifest itself in certain build orders that change even when B and A don't). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3284) Cached plugins are used, even when the specifically declared
Cached plugins are used, even when the specifically declared - Key: MNG-3284 URL: http://jira.codehaus.org/browse/MNG-3284 Project: Maven 2 Issue Type: Bug Components: Dependencies, Plugins and Lifecycle Affects Versions: 2.0.7 Reporter: Nigel Magnay Priority: Critical Attachments: pluginbug.tar In the attached project, you can build module A, then build module B, but the top level aggregator project will fail at B. The reason this happens is that maven seems to cache plugins. When B is built in isolation, all things are fine - but when built in aggregation, one of the plugins that it uses has already been instantiated, and so it uses that one. This is incorrect, since the declared version is different in B, and is relying on functionality not present in the version declared in A. I have seen similar behaviour when a plugin relies on other plugins to get work done - all of a sudden a build mysteriously stops working, because of a completely unrelated plugin. This is pretty painful because - it's possible to get into a 'no solution', where one project relies on one behaviour so can't upgrade, and one project relies on new behaviour, so can't downgrade. - you get builds that work OK in isolation, but not in their project. This is bad. Also builds tied together in bigger aggregator projects can fail in mysterious ways (mysterious because the user /has/ specified the plugin version, and maven has ignored them, or it's a plugin dependency that got there first) - subtle build ordering changes can cause new failures (the example has B depend on A - but the bug might only manifest itself in certain build orders that change even when B and A don't). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCLEAN-25) Optionally don't delete the 'target ' directory
[ http://jira.codehaus.org/browse/MCLEAN-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113815 ] Joern Huxhorn commented on MCLEAN-25: - This isn't a windows handler problem but a windows "feature". You can't delete a directory that is the current directory of a cmd-console. The real problem is that clean fails if it can't delete a root directory. I don't know about any other handler problems that this patch doesn't fix but I just can't see whats so bad about my suggestion. > Optionally don't delete the 'target ' directory > > > Key: MCLEAN-25 > URL: http://jira.codehaus.org/browse/MCLEAN-25 > Project: Maven 2.x Clean Plugin > Issue Type: New Feature >Reporter: Joern Huxhorn >Assignee: Vincent Siveton > Fix For: 2.2 > > Attachments: clean-patch.patch > > > Would it be possible to add an option to the clean-plugin so only the content > of the target folder(s) are deleted but not the directory itself? > This would help developers using windoze quite a lot since: > - clean fails if you happen to have opened a command line with target as the > current dir. > - windoze closes explorer windows pointing to deleted directories, so you > have to reopen the windows after a clean install > Those problems would both be solved by an option like deleteRoot=false or > something. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-344) connecting existing workspace artifact-projects
[ http://jira.codehaus.org/browse/MECLIPSE-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113804 ] Richard van Nieuwenhoven commented on MECLIPSE-344: --- typo the property is -Declipse.workspaceToConnect=... > connecting existing workspace artifact-projects > --- > > Key: MECLIPSE-344 > URL: http://jira.codehaus.org/browse/MECLIPSE-344 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: dependency resolution >Reporter: Richard van Nieuwenhoven > Attachments: workspace-new-files.tgz, workspace.patch > > > This patch enables you to specify your workspace, and all dependent artefacts > that are available in your eclipse-workspace will be attached as project > references even if they are not in the reactor. > the property can be set with -DworkspaceToConnect=. > I did not have the time to create Test cases but, i maybe someone can help > with that! > The patch is based on the MECLIPSE-333 branch. > as usual the new files are in the extra tgz. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-344) connecting existing workspace artifact-projects
connecting existing workspace artifact-projects --- Key: MECLIPSE-344 URL: http://jira.codehaus.org/browse/MECLIPSE-344 Project: Maven 2.x Eclipse Plugin Issue Type: New Feature Components: dependency resolution Reporter: Richard van Nieuwenhoven Attachments: workspace-new-files.tgz, workspace.patch This patch enables you to specify your workspace, and all dependent artefacts that are available in your eclipse-workspace will be attached as project references even if they are not in the reactor. the property can be set with -DworkspaceToConnect=. I did not have the time to create Test cases but, i maybe someone can help with that! The patch is based on the MECLIPSE-333 branch. as usual the new files are in the extra tgz. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVEN-1854) Unknown error
[ http://jira.codehaus.org/browse/MAVEN-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MAVEN-1854. Assignee: Lukas Theussl Resolution: Duplicate You are using java 6 which is not supported by the m1 java plugin (see MPJAVA-46). I could compile winstone with both jdk1.4 and 5. > Unknown error > - > > Key: MAVEN-1854 > URL: http://jira.codehaus.org/browse/MAVEN-1854 > Project: Maven 1 > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Zurk Tech >Assignee: Lukas Theussl > > maven-1.1/bin/maven > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.1 > --- > You have encountered an unknown error running Maven. > Please help us to correct this problem by following these simple steps: > - read the Maven FAQ at http://maven.apache.org/maven-1.x/faq.html > - run the same command again with the '-e' parameter, eg 'maven -e jar' > - search the maven-user archives for the error at > http://www.mail-archive.com/[EMAIL PROTECTED] > - post the output of maven -e to JIRA at > http://jira.codehaus.org/browse/MAVEN (you must sign up first) > - run 'maven --info' and post the output as the environment to the bug above > --- > >> org.apache.tools.ant.taskdefs.condition.Os.isFamily(Ljava/lang/String;)Z > --- > BUILD FAILED > --- > Total time : 0 seconds > Finished at : Monday, November 12, 2007 12:06:39 PM EST > Final Memory : 1M/4M > --- > maven-1.1/bin/maven -e > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.1 > --- > You have encountered an unknown error running Maven. > Please help us to correct this problem by following these simple steps: > - read the Maven FAQ at http://maven.apache.org/maven-1.x/faq.html > - run the same command again with the '-e' parameter, eg 'maven -e jar' > - search the maven-user archives for the error at > http://www.mail-archive.com/[EMAIL PROTECTED] > - post the output of maven -e to JIRA at > http://jira.codehaus.org/browse/MAVEN (you must sign up first) > - run 'maven --info' and post the output as the environment to the bug above > --- > Errors stack : > >> org.apache.tools.ant.taskdefs.condition.Os.isFamily(Ljava/lang/String;)Z > Exception stack traces : > java.lang.NoSuchMethodError: > org.apache.tools.ant.taskdefs.condition.Os.isFamily(Ljava/lang/String;)Z > at > org.apache.tools.ant.util.JavaEnvUtils.(JavaEnvUtils.java:35) > at > org.apache.commons.jelly.tags.ant.DefaultPropsHandler.setJavaVersionProperty(DefaultPropsHandler.java:197) > at > org.apache.commons.jelly.tags.ant.GrantProject.setJavaVersionProperty(GrantProject.java:205) > at org.apache.tools.ant.Project.init(Project.java:160) > at org.apache.maven.AntProjectBuilder.build(AntProjectBuilder.java:50) > at > org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:575) > at org.apache.maven.MavenSession.attainGoals(MavenSession.java:265) > at org.apache.maven.cli.App.doMain(App.java:307) > at org.apache.maven.cli.App.main(App.java:217) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at com.werken.forehead.Forehead.run(Forehead.java:551) > at com.werken.forehead.Forehead.main(Forehead.java:581) > --- > BUILD FAILED > --- > Total time : 0 seconds > Finished at : Monday, November 12, 2007 12:10:09 PM EST > Final Memory : 1M/4M > --- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MENFORCER-23) deep check for snapshots
deep check for snapshots Key: MENFORCER-23 URL: http://jira.codehaus.org/browse/MENFORCER-23 Project: Maven 2.x Enforcer Plugin Issue Type: Improvement Components: Standard Rules Affects Versions: 1.0-alpha-3 Reporter: Brian Fox Assignee: Brian Fox To be thorough, the rule should check plugin dependencies (as set in the user's pom) are not snapshots and also extensions. We already check project dependencies and plugins. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MENFORCER-22) create a rule to check the current project is not a snapshot
[ http://jira.codehaus.org/browse/MENFORCER-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MENFORCER-22. -- Resolution: Fixed Fix Version/s: 1.0 > create a rule to check the current project is not a snapshot > > > Key: MENFORCER-22 > URL: http://jira.codehaus.org/browse/MENFORCER-22 > Project: Maven 2.x Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Affects Versions: 1.0-alpha-3 >Reporter: Brian Fox >Assignee: Brian Fox > Fix For: 1.0 > > > There is already a rule to check that dependencies cannot be a snapshot, > create a rule to ensure the current project is not a snapshot. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MENFORCER-22) create a rule to check the current project is not a snapshot
create a rule to check the current project is not a snapshot Key: MENFORCER-22 URL: http://jira.codehaus.org/browse/MENFORCER-22 Project: Maven 2.x Enforcer Plugin Issue Type: New Feature Components: Standard Rules Affects Versions: 1.0-alpha-3 Reporter: Brian Fox Assignee: Brian Fox There is already a rule to check that dependencies cannot be a snapshot, create a rule to ensure the current project is not a snapshot. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1560) Error with group summary auto-refresh after performing a release
[
http://jira.codehaus.org/browse/CONTINUUM-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Venisse closed CONTINUUM-1560.
---
Assignee: Emmanuel Venisse
Resolution: Fixed
> Error with group summary auto-refresh after performing a release
>
>
> Key: CONTINUUM-1560
> URL: http://jira.codehaus.org/browse/CONTINUUM-1560
> Project: Continuum
> Issue Type: Bug
> Components: Web - UI
>Affects Versions: 1.1-beta-4
> Environment: 1.1-beta-4 on Linux. Firefox.
>Reporter: Wendy Smoak
>Assignee: Emmanuel Venisse
> Fix For: 1.1
>
>
> After completing the release process, click Done to return to the Group
> Summary page.
> The URL at this time is http://example.com/continuum/releaseCleanup.action.
>
> Wait for it to automatically refresh. It should display the list of groups
> and project counts again, but instead you get:
> {noformat}
> Error Occurred
> org.apache.maven.continuum.ContinuumException: could not find project group
> containing 0
> Show/hide Stack Trace
> org.apache.maven.continuum.ContinuumException: could not find project
> group containing 0
> at
> org.apache.maven.continuum.DefaultContinuum.getProjectGroupByProjectId(DefaultContinuum.java:265)
> at
> org.apache.maven.continuum.web.action.ReleaseCleanupAction.getProjectGroupName(ReleaseCleanupAction.java:97)
> at
> org.apache.maven.continuum.web.action.ReleaseCleanupAction.execute(ReleaseCleanupAction.java:45)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:358)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:218)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:192)
> at
> org.codehaus.plexus.xwork.interceptor.PlexusReleaseComponentInterceptor.intercept(PlexusReleaseComponentInterceptor.java:69)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175)
> at
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115)
> at
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> org.apache.maven.continuum.web.interceptor.ForceContinuumConfigurationInterceptor.intercept(ForceContinuumConfigurationInterceptor.java:72)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInterceptor.java:100)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> org.codehaus.plexus.redback.xwork.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.java:178)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> org.codehaus.plexus.xwork.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:58)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175)
> at
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115)
> at
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
> at
> com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31)
> at
[jira] Commented: (CONTINUUM-1565) continuum does not see update files via scm plugin
[
http://jira.codehaus.org/browse/CONTINUUM-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113789
]
Emmanuel Venisse commented on CONTINUUM-1565:
-
files are updated in the continuum working directory?
> continuum does not see update files via scm plugin
> --
>
> Key: CONTINUUM-1565
> URL: http://jira.codehaus.org/browse/CONTINUUM-1565
> Project: Continuum
> Issue Type: Bug
> Components: SCM
>Affects Versions: 1.1-beta-4
> Environment: linux 2.6.16.18, Perforce Server 2005.2.PATCH/100601,
> maven 2.0.7, jdk 1.6.0_03
>Reporter: Spencer White
>
> BuildController does not see changes and therefor does not do a build. Here
> is how I tested:
> 1. cd /project/dir
> 2. find ./ -type f -exec md5sum {} \; > 2.old
> 3. check in changes to perforce from another client
> 4. wait for Continuum to do run it's scheduled task to update code
> 5. Continuum:
> 346298228 [pool-1-thread-1] INFO
> org.apache.maven.continuum.buildcontroller.BuildController:default - Merging
> SCM results
> 346298254 [pool-1-thread-1] INFO
> org.apache.maven.continuum.buildcontroller.BuildController:default - The
> project was not built because no changes were detected in sources since the
> last build.
> 346298255 [pool-1-thread-1] INFO
> org.apache.maven.continuum.buildcontroller.BuildController:default - No
> changes, not building
> 6. find ./ -type f -exec md5sum {} \; > 2.new
> 7. diff 2.old 2.new
> 28c27
> < d408dc1aab6914b85e3bd2e1ae609368
> ./src/main/java/com/visto/apps/client/IPhoneyClientProtocolHandler.java
> ---
> > 79dfa098c212744ffec226a8126bb3f5
> > ./src/main/java/com/visto/apps/client/IPhoneyClientProtocolHandler.java
> IPhoneyClientProtocolHandler.java was the file that I had changed and checked
> into perforce.
> In Continuum 1.0.3 this project worked fine but it looks like maven-scm used
> p4 sync to update files. Then I had to add another project on the same
> perforce server and had to upgrade to 1.1-beta-4.
> This may have something to do with the maven-scm plugin possibly?
> Thanks.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-884) svn metadata not properly shown in Build Result or Email Notification
[ http://jira.codehaus.org/browse/CONTINUUM-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113788 ] Emmanuel Venisse commented on CONTINUUM-884: Do you have the same system date on your continuum server and on your svn server? If they are different the changelog command return the wrong result. > svn metadata not properly shown in Build Result or Email Notification > - > > Key: CONTINUUM-884 > URL: http://jira.codehaus.org/browse/CONTINUUM-884 > Project: Continuum > Issue Type: Bug > Components: Notifier - Mail >Affects Versions: 1.1-alpha-1 > Environment: Windows >Reporter: David Schwartz > Fix For: Future > > Attachments: continuum.log.tar.gz, log4j.xml > > > When you do a build the webpage and the email that is sent show what files > have been changed. The correct file(s) are shown but the following info is > missing for each file: author, date, comment, revision > Here is an example from an email: > > Changes: > > Changed: no author @ no date > Comment: no comment > Files changed: > src\main\java\org\codehaus\mojo\websphere\tasks\utils\ValidationUtils.java > ( no revision ) > > Also, on the webpage for that shows the Build Result there is a table called > "Changes" that is missing Author, Date, Comment -- 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
