[continuum build - FAILED - update] Wed Jan 11 08:00:00 GMT 2006
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20060111.080001.txt
[continuum build - FAILED - update] Wed Jan 11 10:00:00 GMT 2006
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20060111.10.txt
[jira] Commented: (CONTINUUM-555) Continuum only executes default build-definition
[ http://jira.codehaus.org/browse/CONTINUUM-555?page=comments#action_4 ] Emmanuel Venisse commented on CONTINUUM-555: Not exactly. Actually, Continuum run the *first* build definition found for the current schedule. I don't know for now if we'll disallow the creation of multiple build definition on the same schedule or if we'll run all build definitions define on a schedule. Continuum only executes default build-definition Key: CONTINUUM-555 URL: http://jira.codehaus.org/browse/CONTINUUM-555 Project: Continuum Type: Bug Components: Core system Versions: 1.0.2 Reporter: Dave Brown Fix For: 1.1 Attachments: Picture 1.png Can't find any documentation to state to the contrary, but my understanding is that Continuum should execute all build-definitions on each scheduled build (only the default is executed on a Build Now) Attached is a screen shot of my build definitions. On the latest build, continuum only build the default. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-555) Continuum only executes default build-definition
[ http://jira.codehaus.org/browse/CONTINUUM-555?page=all ] Emmanuel Venisse updated CONTINUUM-555: --- Fix Version: 1.1 Continuum only executes default build-definition Key: CONTINUUM-555 URL: http://jira.codehaus.org/browse/CONTINUUM-555 Project: Continuum Type: Bug Components: Core system Versions: 1.0.2 Reporter: Dave Brown Fix For: 1.1 Attachments: Picture 1.png Can't find any documentation to state to the contrary, but my understanding is that Continuum should execute all build-definitions on each scheduled build (only the default is executed on a Build Now) Attached is a screen shot of my build definitions. On the latest build, continuum only build the default. -- 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 - checkout] Thu Jan 12 01:30:00 GMT 2006
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20060112.013000.txt
[continuum build - FAILED - update] Thu Jan 12 02:00:00 GMT 2006
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20060112.02.txt
[continuum build - FAILED - update] Thu Jan 12 02:30:00 GMT 2006
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20060112.023000.txt
[continuum build - FAILED - update] Thu Jan 12 03:30:00 GMT 2006
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20060112.033000.txt
[continuum build - FAILED - update] Thu Jan 12 05:00:00 GMT 2006
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20060112.050001.txt
[continuum build - SUCCESS - update] Thu Jan 12 05:30:00 GMT 2006
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20060112.053000.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20060112.053000.txt
Maven Repository Manager and Maven-Proxy integration
I've been thinking of a good design for the MRM and maven-proxy integration and got stuck with this issue: (1) Should we setup the maven-proxy app and then allow it to use MRM indexing and caching and other stuffs? or (2) can have an MRM app that can accept the same config that maven-proxy uses ? or is there a better way? Comments/suggestions are highly appreciated... ^_^ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNGECLIPSE-25) Enable Maven in project causes ClassCastException
[ http://jira.codehaus.org/browse/MNGECLIPSE-25?page=comments#action_55491
]
Roland Klein commented on MNGECLIPSE-25:
Hello,
this behavior results from a corrupt tarball i got from ViewCVS, some filenames
were changed in that way that the extensions are not longer .java. So this
files weren't compiled. I just changed the filenames back to .java and
everything ist working fine.
I think especially the Maven2ClasspathContainerInitializer.java file makes this
trouble because no initialization took place.
There were also some ClassCastExceptions during my testing, but after changing
the filenames and rebuilding no exceptions anymore.
Roland
Enable Maven in project causes ClassCastException
-
Key: MNGECLIPSE-25
URL: http://jira.codehaus.org/browse/MNGECLIPSE-25
Project: Maven 2.x Plug-in for Eclipse
Type: Bug
Environment: WIN2K, Eclipse 3.1, JDK 1.5
Reporter: Roland Klein
Assignee: Eugene Kuleshov
Attachments: pzFileReader.zip, src.zip
Hello,
i encounter some problem with the eclipse plugin, when i enable Maven2 for a
particular project.
In the eclipse log are three entries and one of them says that there is a
ClassCastException in Maven2Builder.java line 52
52: Maven2ClasspathContainer container = ( Maven2ClasspathContainer )
JavaCore.getClasspathContainer( path, project );
sometimes i got a NPE in the same class line 54, then the variable container
is not initialized.
54: JavaCore.setClasspathContainer( container.getPath(), new IJavaProject[] {
project }, new IClasspathContainer[] { new Maven2ClasspathContainer( entries
) }, monitor );
After debugging i can say that the method JavaCore.getClasspathContainer()
returns a JavaModelManager when you just started eclipse and causes the
ClassCastExceptions, but I don't know if we can ignore it.
I tried to fix this problem, but i don't know the eclipse API very well. So i
post it here in the hope someone can use and improve it.
Then i encounter a problem with MavenEmbedder and i changed the
maven-embedder-2.0-beta-4-SNAPSHOT-dep.jar to maven-embedder-2.0.1-dep.jar
and rebuild the plugin.
This problem occurs, everytime i change the pom.xml by hand then the project
rebuilds but MavenEmbedder is still running and claims there is a duplicate
projectId in pom.xml. Then i inserted in
Maven2Plugin.resolveClasspathEntries() a call to resetMavenEmbedder() before
it is got through getMavenEmbedder(), this fixes the problem, but i thing
this is shooting with canons on birds. Maybe there is a possibility to reset
MavenEmbedder without to instantiate a new one.
codesnippet Maven2Builder.build()
// line 52-55 are replaced
//Maven2ClasspathContainer container = ( Maven2ClasspathContainer )
JavaCore
//.getClasspathContainer( path, project );
//JavaCore.setClasspathContainer( container.getPath(), new
IJavaProject[] { project },
//new IClasspathContainer[] { new Maven2ClasspathContainer(
entries ) }, monitor );
// ### CHANGES
IClasspathContainer icContainer = JavaCore.getClasspathContainer(
path, project );
IJavaProject[] projects = new IJavaProject[] { project };
IPath newPath = null;
IClasspathContainer[] classpathContainers = null;
if( icContainer == null ) {
newPath = new Path( Maven2Plugin.CONTAINER_ID );
classpathContainers = new IClasspathContainer[] { new
Maven2ClasspathContainer( entries ) };
JavaCore.setClasspathContainer( newPath, projects,
classpathContainers, monitor );
} else {
newPath = icContainer.getPath();
if( icContainer instanceof Maven2ClasspathContainer ) {
classpathContainers = new IClasspathContainer[] { new
Maven2ClasspathContainer( entries ) };
JavaCore.setClasspathContainer( newPath, projects,
classpathContainers, monitor );
} else {
newPath = new Path( Maven2Plugin.CONTAINER_ID );
classpathContainers = new IClasspathContainer[] { new
Maven2ClasspathContainer( entries ) };
JavaCore.setClasspathContainer( newPath, projects,
classpathContainers, monitor );
}
}
// ### CHANGES
/codesnippet
--
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 trunk - SUCCESS - update] Wed Jan 11 08:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060111.080001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060111.080001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNGECLIPSE-25) Enable Maven in project causes ClassCastException
[ http://jira.codehaus.org/browse/MNGECLIPSE-25?page=all ]
Roland Klein closed MNGECLIPSE-25:
--
Resolution: Fixed
Oh, i just entered some comment look above ;)
Enable Maven in project causes ClassCastException
-
Key: MNGECLIPSE-25
URL: http://jira.codehaus.org/browse/MNGECLIPSE-25
Project: Maven 2.x Plug-in for Eclipse
Type: Bug
Environment: WIN2K, Eclipse 3.1, JDK 1.5
Reporter: Roland Klein
Assignee: Eugene Kuleshov
Attachments: pzFileReader.zip, src.zip
Hello,
i encounter some problem with the eclipse plugin, when i enable Maven2 for a
particular project.
In the eclipse log are three entries and one of them says that there is a
ClassCastException in Maven2Builder.java line 52
52: Maven2ClasspathContainer container = ( Maven2ClasspathContainer )
JavaCore.getClasspathContainer( path, project );
sometimes i got a NPE in the same class line 54, then the variable container
is not initialized.
54: JavaCore.setClasspathContainer( container.getPath(), new IJavaProject[] {
project }, new IClasspathContainer[] { new Maven2ClasspathContainer( entries
) }, monitor );
After debugging i can say that the method JavaCore.getClasspathContainer()
returns a JavaModelManager when you just started eclipse and causes the
ClassCastExceptions, but I don't know if we can ignore it.
I tried to fix this problem, but i don't know the eclipse API very well. So i
post it here in the hope someone can use and improve it.
Then i encounter a problem with MavenEmbedder and i changed the
maven-embedder-2.0-beta-4-SNAPSHOT-dep.jar to maven-embedder-2.0.1-dep.jar
and rebuild the plugin.
This problem occurs, everytime i change the pom.xml by hand then the project
rebuilds but MavenEmbedder is still running and claims there is a duplicate
projectId in pom.xml. Then i inserted in
Maven2Plugin.resolveClasspathEntries() a call to resetMavenEmbedder() before
it is got through getMavenEmbedder(), this fixes the problem, but i thing
this is shooting with canons on birds. Maybe there is a possibility to reset
MavenEmbedder without to instantiate a new one.
codesnippet Maven2Builder.build()
// line 52-55 are replaced
//Maven2ClasspathContainer container = ( Maven2ClasspathContainer )
JavaCore
//.getClasspathContainer( path, project );
//JavaCore.setClasspathContainer( container.getPath(), new
IJavaProject[] { project },
//new IClasspathContainer[] { new Maven2ClasspathContainer(
entries ) }, monitor );
// ### CHANGES
IClasspathContainer icContainer = JavaCore.getClasspathContainer(
path, project );
IJavaProject[] projects = new IJavaProject[] { project };
IPath newPath = null;
IClasspathContainer[] classpathContainers = null;
if( icContainer == null ) {
newPath = new Path( Maven2Plugin.CONTAINER_ID );
classpathContainers = new IClasspathContainer[] { new
Maven2ClasspathContainer( entries ) };
JavaCore.setClasspathContainer( newPath, projects,
classpathContainers, monitor );
} else {
newPath = icContainer.getPath();
if( icContainer instanceof Maven2ClasspathContainer ) {
classpathContainers = new IClasspathContainer[] { new
Maven2ClasspathContainer( entries ) };
JavaCore.setClasspathContainer( newPath, projects,
classpathContainers, monitor );
} else {
newPath = new Path( Maven2Plugin.CONTAINER_ID );
classpathContainers = new IClasspathContainer[] { new
Maven2ClasspathContainer( entries ) };
JavaCore.setClasspathContainer( newPath, projects,
classpathContainers, monitor );
}
}
// ### CHANGES
/codesnippet
--
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: svn commit: r367861 - in /maven/maven-1/plugins/trunk/dashboard: src/plugin-resources/templates/dashboard.jsl xdocs/changes.xml
[SNIP]
URL: http://svn.apache.org/viewcvs?rev=367861view=rev
Log:
PR: MPDASHBOARD-32
maven.dashboard.report.showempty property not honored.
[SNIP]
- j:if test=${notEmptyElems.isEmpty() == 'true'}
+ j:if test=${empty(notEmptyElems)}
[SNIP]
Lukas, did you test it with maven 1.1 and 1.0 ?
I remember that there was a problem with the empty function in an old
release of Jelly ?
Arnaud
[jira] Created: (MDEPLOY-19) Ability to deploy-file as classifier
Ability to deploy-file as classifier Key: MDEPLOY-19 URL: http://jira.codehaus.org/browse/MDEPLOY-19 Project: Maven 2.x Deploy Plugin Type: New Feature Versions: 2.1 Environment: xp Reporter: Dan Tran deploy-file currently does not support this option -- 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: [vote] release maven-help-plugin 2.0
+1 Emmanuel Brett Porter a écrit : This needs to get out there with the new name. Can we do a release of the current code? There are 2 feature requests in JIRA that can wait until 2.1. Also, we should possibly rename the JIRA project and prefix. [ ] +1 [ ] +0 [ ] -1 - 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]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Wed Jan 11 08:15:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060111.081501.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060111.081501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - FAILED - update] Wed Jan 11 08:30:00 GMT 2006
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20060111.083000.txt
[jira] Created: (MNG-1952) Give equal footing to all m2 plugins and add Cargo plugin to the list
Give equal footing to all m2 plugins and add Cargo plugin to the list - Key: MNG-1952 URL: http://jira.codehaus.org/browse/MNG-1952 Project: Maven 2 Type: Improvement Components: documentation - general Reporter: Vincent Massol Attachments: siteplugin.patch Right now there are several plugin lists (3) making it harder to find a given plugin as this breaks the alphabetical order. In addition plugins that come later on the page get less visibility. I am sending a patch that lists all the plugins in the same table. If it's required we could create another column mentioning where the plugin comes from but I don't think that's required. I have also added the Cargo m2 plugin which was missing from the list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNGECLIPSE-4) Problems with dependencies other that jar and war (ie. par, ejb3)
[ http://jira.codehaus.org/browse/MNGECLIPSE-4?page=all ] Mark Chesney updated MNGECLIPSE-4: -- Attachment: MNGECLIPSE-4.jpg Problems with dependencies other that jar and war (ie. par, ejb3) - Key: MNGECLIPSE-4 URL: http://jira.codehaus.org/browse/MNGECLIPSE-4 Project: Maven 2.x Plug-in for Eclipse Type: Bug Environment: MS Windows XP, Eclipse 3.2M2, plugin ver. 0.0.3 Reporter: Piotr Bzdyl Assignee: Dmitri Maximovich Attachments: MNGECLIPSE-4.jpg I found a problem in eclipse with projects producing artifacts with other than war and jar types. I use mvn eclipse:eclipse to generate .project and .classpath on the pom.xml with packagingwar/packaging which contains dependency to the mymodel.par artifact (Persistence archive jar file) (I still don't know how to open project in eclipse with only pom.xml - no .project and .classpath files), then I import this project to the workspace. Until now everything is working fine. Then I use context menu on the project and select Maven 2 - Enable. I got errors with duplicated dependencies (in .classpath and in the Maven2 Dependencies node) so I remove duplicated entries from eclipse java build path. Then I have one more error which I can't remove: Illegal type of archive for required library: 'C:\Documents and Settings\piotr\.m2\repository\com\example\mymodel\1.0\mymodel-1.0.par' in project mywar. How to cope with this error? I think that maven2 plugin should try to treat all dependencies as jar files and if it fails generate this error. This same occurs with mylogic.ejb3 (plain jar file with EJB3 session beans). -- 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-1952) Give equal footing to all m2 plugins and add Cargo plugin to the list
[ http://jira.codehaus.org/browse/MNG-1952?page=all ] Vincent Massol updated MNG-1952: Attachment: (was: siteplugin.patch) Give equal footing to all m2 plugins and add Cargo plugin to the list - Key: MNG-1952 URL: http://jira.codehaus.org/browse/MNG-1952 Project: Maven 2 Type: Improvement Components: documentation - general Reporter: Vincent Massol Right now there are several plugin lists (3) making it harder to find a given plugin as this breaks the alphabetical order. In addition plugins that come later on the page get less visibility. I am sending a patch that lists all the plugins in the same table. If it's required we could create another column mentioning where the plugin comes from but I don't think that's required. I have also added the Cargo m2 plugin which was missing from the list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNGECLIPSE-4) Problems with dependencies other that jar and war (ie. par, ejb3)
[ http://jira.codehaus.org/browse/MNGECLIPSE-4?page=all ] Mark Chesney updated MNGECLIPSE-4: -- Attachment: test-projects-MNGECLIPSE-4.zip Problems with dependencies other that jar and war (ie. par, ejb3) - Key: MNGECLIPSE-4 URL: http://jira.codehaus.org/browse/MNGECLIPSE-4 Project: Maven 2.x Plug-in for Eclipse Type: Bug Environment: MS Windows XP, Eclipse 3.2M2, plugin ver. 0.0.3 Reporter: Piotr Bzdyl Assignee: Dmitri Maximovich Attachments: MNGECLIPSE-4.jpg, test-projects-MNGECLIPSE-4.zip I found a problem in eclipse with projects producing artifacts with other than war and jar types. I use mvn eclipse:eclipse to generate .project and .classpath on the pom.xml with packagingwar/packaging which contains dependency to the mymodel.par artifact (Persistence archive jar file) (I still don't know how to open project in eclipse with only pom.xml - no .project and .classpath files), then I import this project to the workspace. Until now everything is working fine. Then I use context menu on the project and select Maven 2 - Enable. I got errors with duplicated dependencies (in .classpath and in the Maven2 Dependencies node) so I remove duplicated entries from eclipse java build path. Then I have one more error which I can't remove: Illegal type of archive for required library: 'C:\Documents and Settings\piotr\.m2\repository\com\example\mymodel\1.0\mymodel-1.0.par' in project mywar. How to cope with this error? I think that maven2 plugin should try to treat all dependencies as jar files and if it fails generate this error. This same occurs with mylogic.ejb3 (plain jar file with EJB3 session beans). -- 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-1952) Give equal footing to all m2 plugins and add Cargo plugin to the list
[ http://jira.codehaus.org/browse/MNG-1952?page=all ] Vincent Massol updated MNG-1952: Attachment: siteplugin2.patch Give equal footing to all m2 plugins and add Cargo plugin to the list - Key: MNG-1952 URL: http://jira.codehaus.org/browse/MNG-1952 Project: Maven 2 Type: Improvement Components: documentation - general Reporter: Vincent Massol Attachments: siteplugin2.patch Right now there are several plugin lists (3) making it harder to find a given plugin as this breaks the alphabetical order. In addition plugins that come later on the page get less visibility. I am sending a patch that lists all the plugins in the same table. If it's required we could create another column mentioning where the plugin comes from but I don't think that's required. I have also added the Cargo m2 plugin which was missing from the list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Wed Jan 11 08:45:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060111.084501.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060111.084501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - FAILED - update] Wed Jan 11 09:00:00 GMT 2006
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20060111.09.txt
Re: Maven 2 and Ant classpath issue
I wasn't looking for extra help posted here when I got no response from users mailing list. no worries -Hassan Brett Porter [EMAIL PROTECTED] 10/01/2006 23:48 Please respond to Maven Developers List To: Maven Developers List dev@maven.apache.org cc: Subject:Re: Maven 2 and Ant classpath issue I believe you already asked this on the users@ list? You won't get any extra help here, sorry - that was the right place. Please follow up there. - Brett [EMAIL PROTECTED] wrote: Hi I'm using Maven 2.0.1 and trying to use a non-standard Ant task (scriptdef), in my pom.xml. It's giving me this error: Embedded error: Could not create task or type of type: scriptdef. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Wed Jan 11 09:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060111.09.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060111.09.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPRELEASE-17) copy-dependencies does not work for type ejb-client
copy-dependencies does not work for type ejb-client --- Key: MPRELEASE-17 URL: http://jira.codehaus.org/browse/MPRELEASE-17 Project: maven-release-plugin Type: Bug Versions: 1.5 Environment: maven 1.1 beta 2 Reporter: Fredrik Vraalsen Attachments: mprelease-handle-ejb-client-type.patch copy-dependencies does not work for dependencies of type ejb-client. The attached patch contains a workaround for plugin.jelly, but there may be better ways of handling 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - FAILED - update] Wed Jan 11 09:30:00 GMT 2006
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20060111.093000.txt
[jira] Updated: (MNGECLIPSE-19) version can not be supplied in parent pom
[ http://jira.codehaus.org/browse/MNGECLIPSE-19?page=all ] Mark Chesney updated MNGECLIPSE-19: --- Attachment: test-projects-MNGECLIPSE-19.zip version can not be supplied in parent pom - Key: MNGECLIPSE-19 URL: http://jira.codehaus.org/browse/MNGECLIPSE-19 Project: Maven 2.x Plug-in for Eclipse Type: Bug Reporter: Lee Meador Assignee: Dmitri Maximovich Attachments: test-projects-MNGECLIPSE-19.zip If I don't have a version tag in the POM, I get an eclipse error with its little red spot on the top line of the POM. The maven dependencies all disappear (and, of course, most everything won't compile any more). The version should be gotten from the parent POM but doesn't seem to be. Interestingly enough, the first dependency with no version (jmock) seems to be ok. The message on the red spot on the pom does not mention jmock. It does mention all three of the spring dependencies that follow 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNGECLIPSE-19) version can not be supplied in parent pom
[ http://jira.codehaus.org/browse/MNGECLIPSE-19?page=all ] Mark Chesney updated MNGECLIPSE-19: --- Attachment: MNGECLIPSE-19.jpg version can not be supplied in parent pom - Key: MNGECLIPSE-19 URL: http://jira.codehaus.org/browse/MNGECLIPSE-19 Project: Maven 2.x Plug-in for Eclipse Type: Bug Reporter: Lee Meador Assignee: Dmitri Maximovich Attachments: MNGECLIPSE-19.jpg, test-projects-MNGECLIPSE-19.zip If I don't have a version tag in the POM, I get an eclipse error with its little red spot on the top line of the POM. The maven dependencies all disappear (and, of course, most everything won't compile any more). The version should be gotten from the parent POM but doesn't seem to be. Interestingly enough, the first dependency with no version (jmock) seems to be ok. The message on the red spot on the pom does not mention jmock. It does mention all three of the spring dependencies that follow 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1952) Give equal footing to all m2 plugins and add Cargo plugin to the list
[ http://jira.codehaus.org/browse/MNG-1952?page=comments#action_55500 ] Brett Porter commented on MNG-1952: --- Honestly, I think they should be separate. The other plugins are not part of the Maven project. If you really want Cargo at the top, put that table first :) Anyway, this is a temporary solution. It will be generated at some point. You're welcome to commit your changes, but I'd like to hear from others whether they object to the blending. It doesn't really give equal footing, it's just alphabetical discrimination :) Give equal footing to all m2 plugins and add Cargo plugin to the list - Key: MNG-1952 URL: http://jira.codehaus.org/browse/MNG-1952 Project: Maven 2 Type: Improvement Components: documentation - general Reporter: Vincent Massol Attachments: siteplugin2.patch Right now there are several plugin lists (3) making it harder to find a given plugin as this breaks the alphabetical order. In addition plugins that come later on the page get less visibility. I am sending a patch that lists all the plugins in the same table. If it's required we could create another column mentioning where the plugin comes from but I don't think that's required. I have also added the Cargo m2 plugin which was missing from the list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repository Manager Proxy features
Brian E. Fox wrote: What would be nice is if you could define some list of groups and say don't look here Or better, define a repo to be internal and say these groups are internal. I think this has been proposed as a pure Maven feature before, and its best to keep it there. Can you file it in JIRA if it isn't already? What we can do with the repository proxy is make it appear to be several repositories, caching each under one app. I'm not sure there is a purpose to looking in several repositories for the same thing (unless its for mirroring - again something that should be in Maven itself). WDYT? Will this even be a problem with the RM? Is the RM in some state that is alpha testable? The pieces are there and tested, but the integration is just starting to arrive (skeletal webapp). Plenty of JIRA issues and I hope we can do some discussion here. Thanks, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: m2 logging
Hi John, I think we'd all agree with the sentiment. I think the default needs to be less noisy, and -X should be targetted (debug artifact resolution, debug pom, etc). We could name systems and log accordingly. This is all in JIRA. If you have any suggestions for implementation, please say so! Cheers, Brett John Allen wrote: Thoughts on logging:- I would like to see logging messages use relevant and meaningful identifiers that are correlatable to provide users with a means of knowing what is going on and what sequence of events has brought about the output. Currently huge amounts of work goes on 'behind the scenes' that results in lots of messages being produced long before there's any mention of what phase or plugin goal has caused the messages or where the user is in the flow of things. One of the biggest draw backs with using maven 2, beyond the lack of tutorials and indepth technical documentation, is its difficulty in problem identifcation and resolution - even to the hex headed, when something breaks/doesnt work (as expected) the only option is to spend a week (or 2) hacking away at the mighty collection of projects, code, apis and utils (i.e. custom everything) trying to get to grips with whats going on uner the scenes. In my humble opinion, a build system, with its critical posiitoning within the engineering process, has gotta be simple (or at least appear to be without obscuring pertinent details), accessible and above all easy to fix and administer and currently the lack of consistent, user oriented logging and tracing gets in the way of this. Regarding m2s adoption in large scale enterprise dev env projects: yes I need a build fwk that supports/promotes depedency mgmt, standardisation, reporting, network delivery, deployment control, agile SDM techniques and architeral governance but more importantly, i need one that is easy to support, train, administer, adapt, extend and fix. Better messages and message tracing and some proper technical docs will help this i think. Observations:- - Too much noise that is only really meaningful to experts - Unable to distinguish what action has caused a message, part of a wider issue with not being able to associate what is being said, by who, and why (users pov) - No ability to extend message generation/delivery with adapters etc. John Allen. - 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]
[jira] Commented: (MJAVADOC-42) Ability to provide more complex data to bottom tag (e.g. HTML code)
[ http://jira.codehaus.org/browse/MJAVADOC-42?page=comments#action_55502 ] Alexander Hars commented on MJAVADOC-42: You are right, you can achieve this with CDATA right now. For example: bottom![CDATA[Copyright 2005, a href=[WWW] http://www.mycompany.com;MyCompany, Inc.a]]/bottom I guess, this is a documentation issue. I have added this info to the wiki page at: http://wiki.apache.org/maven/JavadocPlugin But it would be good to add this to the documentation of the JavaDoc Plugin. Ability to provide more complex data to bottom tag (e.g. HTML code) - Key: MJAVADOC-42 URL: http://jira.codehaus.org/browse/MJAVADOC-42 Project: Maven 2.x Javadoc Plugin Type: Improvement Reporter: Chris Hagmann Before when using ANT we used something like the following for the bottom tag: ©2004-2006 a href='http://www.mhave.com'mHave/a, all rights reserved.pUse is subject to these a href='http://www.mhave.com/licenses/mhave-commons/license.html'license terms/a unless otherwise stated. Obviously, I'm not able to do this currently with the javadoc plugin. I'm assuming that it needs to be possible to specify the content of bottom as CDATA to achieve something like 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improve methods to define the scope and packaging of dependencies(MNG-1732)
Hi Bob,
We've been over the first case before. I think its dangerous to change
that now - better documentation/explanation (or maybe even alternative
naming), but I think we need to retain the compile - runtime - test
relationship.
I know we need to sort out that second use case. There's also
discussions on skinny wars and appserver located (provided) jars.
I think we should pull this together for a discussion on the wiki for 2.1.
I don't believe the usage tag is the solution as it still doesn't answer
the question of how you allocate transitive dependencies to the war/ear.
The current WAR includes all JARs and blocks dependencies transitively
(because they are already included). The opposite is the skinny WAR that
would not include and and passes all on transitively. I think the
solution is to allow configuration of an artifact filter that
includes/excludes artifacts. The filter that excludes from the WAR would
be used to include in the EAR.
We've talked about doing this for configuration already. Making them
easy to configure would be a good idea, na dmaybe we should make them
identifiable sections of the pom so they can be reused like in this use
case.
Maybe the ideas need to be combined - filters that do things (war
inclusion) that are listed on dependencies and would supersede
exclusions. I haven't thought that trough yet, but its one thing we can
discuss.
- Brett
Allison, Bob wrote:
I understand what you are saying on this. I am also looking at the
number of questions on the user list in the vein of
-- How do I get a jar in both scope=compile and scope=test?
-- How do I get a jar packaged in the ear instead of the war?
Answering the first question is simply a matter of pointing the user to
the correct documentation, since it is obvious that they need to better
understand the scope definitions, but it also points out that
scope=compile is not intuitively use this jar everywhere. Allowing
the alternative definition I outlined in the JIRA issue allows people to
explicitly state their intentions.
Answering the second question seems much more difficult. I saw one email
yesterday where someone recommended against using Maven 2 because of
this issue. With my proposal, the answer would be to define the jar as
follows in the war project:
dependency
groupIdg/groupId
artifactIda/artifactId
usage
warfalse/war
eartrue/true
/usage
/dependency
Because in this case scope is not defined, it defaults to compile
which makes it available to the ear project transitively.
The changes that would be needed for the war and ear plugins is to look
for the usage Map:
If (usage == null) {
// proceed as done currently
} else {
String todo = (String)usage.get(war); // or ear for the ear
plugin
if (true.equalsIgnoreCase(todo)) {
// package it
}
}
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 28, 2005 06:14
To: Maven Developers List
Subject: Re: Improve methods to define the scope and packaging of
dependencies(MNG-1732)
We went over these suggestions in March and I was originally a proponent
of phase or goal-based scoping instead of what we kept, but now agree we
made the right choice.
Basically, the scope is an intelligent default for most settings, it
maps well to a number of different scenarios, and scopes are based on
each other. This is the reason we don't have compile and test as
separate, for example.
As for the others, the main issue with this is transitive dependencies.
If A uses B and B uses C, how does A control the properties/usages of C?
With scope, these can be intelligentally combined, but this might not be
the case with arbitrary properties/usages.
The suggestion we have had is to use configuration on the plugin that
takes an artifact filter for applying boolean properties. When it comes
to mapping paths, this configuration would be in the form of name value
pairs (a list of items, each having group, artifact id and installation
location).
I think in this case you'd have a lot of repeated information. My
preference would be to build up a database of these things somewhere
were it is only required once.
I hope this explains it.
- Brett
Allison, Bob wrote:
I'm back from vacation now, so if this won't start another holy war
(like XML format) I have two questions on this issue:
1) Why is this a bad idea?
2) Assuming that this idea won't be done, any suggestions on how to
configure the mapping of dependencies to RPM installation locations?
A good deal of the reason for the suggestion was to allow dependencies
to be easily mapped to the location where the RPM package should
install
them. If the project has dependencies which need to be packaged, I
need
to know where to put them. With things the way they are right now, I
need to specify the group/artifact/version/type as a dependency then
repeat the information in
Re: [m2] Problem having the parent on the same level as the children using the site-plugin
Hi Dennis,
Could you drop a test case into JIRA for this? Would like to get it
resolved before 2.0. Looks like a bug, because it should find stuff
inside the reactor. It may be related to the
non-inheritance/interpolation bugs which are already there.
Do you have relativePath/ set correctly in the children? It shouldn't
matter in the reactor, but worth checking.
- Brett
Dennis Lundberg wrote:
Hi all
I'm trying out the new site-plugin in a multi-module setup. My setup
looks like this:
-+- parent-project
| +- pom.xml
| +- src
| +- site
|+- site.xml
+- module-1
| +- pom.xml
| +- src
| +- site
|+- site.xml
+- module-2
| +- pom.xml
| +- src
| +- site
|+- site.xml
+- ...
In the pom of the parent project I have a modules section that looks
like this:
modules
module../module-1/module
module../module-2/module
...
/modules
Running mvn site, in the directory of the parent project, successfully
builds the parent site as well as the sites for each of the modules.
However, the parent project has a ${modulesItems} in it's site.xml and
there are no links there to the modules.
If I move a module into the parent directory and change the
module-elements accordingly, the links show up correctly.
Can someone help me out?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[result][vote] release doxia 1.0-alpha-7
The final result is 4 binding +1's I will release tomorrow. - Brett Brett Porter wrote: Hi, There's been a bunch of changes for site 2.0, and the sink api now includes some classes for backwards compatibility after the package change that need to go into the Maven 2.0.2 release. I'd like to release 1.0 alpha 7 [ ] +1 [ ] +0 [ ] -1 72 Hours. Tick Tock. - Brett
[jira] Commented: (MJAVADOC-42) Ability to provide more complex data to bottom tag (e.g. HTML code)
[ http://jira.codehaus.org/browse/MJAVADOC-42?page=comments#action_55503 ]
Alexander Hars commented on MJAVADOC-42:
My previous comment was thrown off because of JIRA markup.
Here is the correct (unformatted) version:
{noformat}
bottom![CDATA[Copyright 2005, a href=http://www.mycompany.com;MyCompany,
Inc.a]]/bottom
{noformat}
Ability to provide more complex data to bottom tag (e.g. HTML code)
-
Key: MJAVADOC-42
URL: http://jira.codehaus.org/browse/MJAVADOC-42
Project: Maven 2.x Javadoc Plugin
Type: Improvement
Reporter: Chris Hagmann
Before when using ANT we used something like the following for the bottom tag:
©2004-2006 a href='http://www.mhave.com'mHave/a, all rights
reserved.pUse is subject to these a
href='http://www.mhave.com/licenses/mhave-commons/license.html'license
terms/a unless otherwise stated.
Obviously, I'm not able to do this currently with the javadoc plugin. I'm
assuming that it needs to be possible to specify the content of bottom as
CDATA to achieve something like 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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Maven Wiki] Update of JavadocPlugin by AlexanderHars
Dear Wiki user, You have subscribed to a wiki page or wiki category on Maven Wiki for change notification. The following page has been changed by AlexanderHars: http://wiki.apache.org/maven/JavadocPlugin -- * bottom tag: If you want to include html markup, embed the text in a cdata section: e.g. bottom![CDATA[Copyright 2005, a href=http://www.mycompany.com;MyCompany, Inc.a]]/bottom - * excludePackageNames tag: currently does not work (2006-Dec-20). See: http://jira.codehaus.org/browse/MJAVADOC-21 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vote] release maven-help-plugin 2.0
+1 -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 10, 2006 11:03 PM To: Maven Developers List Subject: [vote] release maven-help-plugin 2.0 This needs to get out there with the new name. Can we do a release of the current code? There are 2 feature requests in JIRA that can wait until 2.1. Also, we should possibly rename the JIRA project and prefix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-help-plugin 2.0
+1 arnaud On 1/11/06, Mike Perham [EMAIL PROTECTED] wrote: +1 -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 10, 2006 11:03 PM To: Maven Developers List Subject: [vote] release maven-help-plugin 2.0 This needs to get out there with the new name. Can we do a release of the current code? There are 2 feature requests in JIRA that can wait until 2.1. Also, we should possibly rename the JIRA project and prefix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_55510 ] Jesse Kuhnert commented on MSUREFIRE-23: Ahh, I didn't know about this part. The runtime errors are the biggest reason I did it, but perhaps there is an easy solution to the other dependencies. I have no idea. I sent the testng group my patch a few minutes ago, when I get some approval (or make modifications + approval to get it into a commitable state) I'll post the patches here for all the surefire bits along with the jars you'll need on ibiblio to make it work. I'll submit the report plugin patch to the othe jira ticket and link these two tickets together. (If that's possible from completely different jira's. ) Support TestNG -- Key: MSUREFIRE-23 URL: http://jira.codehaus.org/browse/MSUREFIRE-23 Project: Maven 2.x Surefire Plugin Type: New Feature Reporter: Mike Perham Add support for running unit tests with TestNG. http://www.testng.org -- 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 logging
I have been a big fan of domained logging...where the logging api call contains whatever is necessary to earmark that log message as belonging to a particular domain (domain being whatever you want to define it as, the class, the package, the logical functionality of something..) I have done this before with something akin to getLog().log(foo, Domain.REPO); where REPO is a short or a long constant defined in the Domain object. I don't think that would work for our purposes since we are hiding the logging classes from a mojo for instance... getLog().domain(foo, repo); might work, and have some dynamic process in the logging that registers new logging domains on the fly. In log4j I just made the domain be their own logger instance with custom appenders...in maven they could be shoved out to the console marked as [REPO] in the log message so you can easily grep through for those logging outputs. It is probably overkill to make seperate logging files for each domain, but domained logging to one output file toggled by a flag, coupled with the [FOO] distingishers would take care of the problem I think.. jesse On 1/11/06, Brett Porter [EMAIL PROTECTED] wrote: Hi John, I think we'd all agree with the sentiment. I think the default needs to be less noisy, and -X should be targetted (debug artifact resolution, debug pom, etc). We could name systems and log accordingly. This is all in JIRA. If you have any suggestions for implementation, please say so! Cheers, Brett John Allen wrote: Thoughts on logging:- I would like to see logging messages use relevant and meaningful identifiers that are correlatable to provide users with a means of knowing what is going on and what sequence of events has brought about the output. Currently huge amounts of work goes on 'behind the scenes' that results in lots of messages being produced long before there's any mention of what phase or plugin goal has caused the messages or where the user is in the flow of things. One of the biggest draw backs with using maven 2, beyond the lack of tutorials and indepth technical documentation, is its difficulty in problem identifcation and resolution - even to the hex headed, when something breaks/doesnt work (as expected) the only option is to spend a week (or 2) hacking away at the mighty collection of projects, code, apis and utils (i.e. custom everything) trying to get to grips with whats going on uner the scenes. In my humble opinion, a build system, with its critical posiitoning within the engineering process, has gotta be simple (or at least appear to be without obscuring pertinent details), accessible and above all easy to fix and administer and currently the lack of consistent, user oriented logging and tracing gets in the way of this. Regarding m2s adoption in large scale enterprise dev env projects: yes I need a build fwk that supports/promotes depedency mgmt, standardisation, reporting, network delivery, deployment control, agile SDM techniques and architeral governance but more importantly, i need one that is easy to support, train, administer, adapt, extend and fix. Better messages and message tracing and some proper technical docs will help this i think. Observations:- - Too much noise that is only really meaningful to experts - Unable to distinguish what action has caused a message, part of a wider issue with not being able to associate what is being said, by who, and why (users pov) - No ability to extend message generation/delivery with adapters etc. John Allen. - 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] -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom
[jira] Commented: (MNG-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=comments#action_55515 ] Brian Fox commented on MNG-624: --- here's my 2 cents: What if the parent version could take a tag like LATEST and then the release plugin could resolve it like it does with SNAPSHOTS. IMO, if you can't define your parent in a flexible way, it almost make it pointless to be able to inherit the version from the parentyou still need to go to each pom and update the parent rev. The problem with it always taking the latest is when you tag something, if you go back later the parent could be different. automatic parent versioning --- Key: MNG-624 URL: http://jira.codehaus.org/browse/MNG-624 Project: Maven 2 Type: Improvement Components: Inheritence and Interpolation Reporter: Brett Porter Assignee: Brett Porter Priority: Blocker Fix For: 2.1 Original Estimate: 4 hours Remaining: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- 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-179) go offline goal - download dependencies
[ http://jira.codehaus.org/browse/MNG-179?page=comments#action_55517 ] Brian Fox commented on MNG-179: --- I recently added a resolve goal to the 1.1 version of dependency plugin on the mojo project. This does effectively this except it doesn't get all plugins. Might work for some people in the meantime. go offline goal - download dependencies - Key: MNG-179 URL: http://jira.codehaus.org/browse/MNG-179 Project: Maven 2 Type: Improvement Reporter: Brett Porter Assignee: John Casey Fix For: 2.1 Original Estimate: 4 hours Remaining: 4 hours add a goal/cli option to transitively resolve all deps (including mojos), and download them. This may not work for standalone mojos with no configuration - may need to explicitly list them -- 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-1898) Plugin classpath broken from 2.0 to 2.0.1
[ http://jira.codehaus.org/browse/MNG-1898?page=comments#action_55518 ]
Brian Fox commented on MNG-1898:
I was really hoping this could get fixed in 2.0.2, I can't proceed with my Kodo
plugin until it gets fixed. If there is something I can do to help let me know,
the code causing the problem is on mojo.
Plugin classpath broken from 2.0 to 2.0.1
-
Key: MNG-1898
URL: http://jira.codehaus.org/browse/MNG-1898
Project: Maven 2
Type: Bug
Environment: winxp
Reporter: Brian Fox
Assignee: John Casey
Priority: Blocker
Fix For: 2.0.3
I'm working on a kodo plugin in the codehaus mojo sandbox. Using 2.0, it
works fine. In 2.1, it can't find xercesImpl, which is a transitive
dependency of the plugin. Did something change to cause new behavior (aka a
bug) related to this? Just eyeballing the info below, in 2.0, the instance of
classloader was org.codehaus.classworlds.RealmClassLoader but in 2.0.1 it is
org.codehaus.plexus.util.RealmDelegatingClassLoader
I tried specifying xercesImpl as a direct dependency and that didn't work
either so I'm not sure it's related to the transitivity.
Output from 2.0.1: (2.0 follows further below)
[DEBUG] org.codehaus.mojo:kodo-maven-plugin:maven-plugin:1.0-alpha-1-SNAPSHOT
(selected for runtime)
[DEBUG] org.apache.maven:maven-model:jar:2.0 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for runtime)
[DEBUG] Skipping disabled repository snapshots
[DEBUG] com.solarmetric:kodo-jdo:jar:3.3.3 (setting version to: 3.3.3 from
range: [3.0,])
[DEBUG] com.solarmetric:kodo-jdo:jar:3.3.3 (selected for runtime)
[DEBUG] com.solarmetric:kodo-wl81manage:jar:1.0 (selected for runtime)
[DEBUG] com.solarmetric:kodo-workbench:jar:1.0 (selected for runtime)
[DEBUG] org.hsqldb:jdbc-hsql:jar:1.7.0 (selected for runtime)
[DEBUG] sqlline:sqlline:jar:1.0 (selected for runtime)
[DEBUG] jcommon:jcommon:jar:0.9.1 (selected for runtime)
[DEBUG] javax.jdo:jdo:jar:1.0.2 (selected for runtime)
[DEBUG] xalan:xalan:jar:2.5.1 (selected for runtime)
[DEBUG] jfreechart:jfreechart:jar:0.9.16 (selected for runtime)
[DEBUG] com.solarmetric:kodo-jdo-runtime:jar:3.3.3 (selected for runtime)
[DEBUG] javax.sql:jdbc-stdext:jar:2.0 (selected for runtime)
[DEBUG] jline:jline:jar:0.9.1 (selected for runtime)
[DEBUG] mx4j:mx4j-jmx:jar:1.1.1 (selected for runtime)
[DEBUG] jta-spec:jta-spec:jar:1.0.1 (selected for runtime)
[WARNING] While downloading xml-apis:xml-apis:2.0.0
This artifact has been relocated to xml-apis:xml-apis:1.0.b2.
[DEBUG] xml-apis:xml-apis:jar:1.0.b2 (selected for runtime)
[DEBUG] xerces:xercesImpl:jar:2.5.0 (selected for runtime)
[DEBUG] jca:jca:jar:1.0.0 (selected for runtime)
[DEBUG] mx4j:mx4j-tools:jar:1.1.1 (selected for runtime)
[DEBUG] jndi:jndi:jar:1.2.1 (selected for runtime)
[DEBUG] Skipping disabled repository snapshots
[DEBUG] log4j:log4j:jar:1.2.12 (setting version to: 1.2.12 from range:
[1.2.9,])
[DEBUG] log4j:log4j:jar:1.2.12 (selected for runtime)
[DEBUG] org.apache.maven:maven-plugin-api:jar:2.0 (selected for runtime)
[DEBUG] Configuring mojo
'org.codehaus.mojo:kodo-maven-plugin:1.0-alpha-1-SNAPSHOT:enhance' --
[DEBUG] (f) classDir =
E:\STC\svn\modules\services\supplementaldata-jdo\trunk\target\classes
[DEBUG] (f) resources = [EMAIL PROTECTED]
[DEBUG] (f) searchDir =
E:\STC\svn\modules\services\supplementaldata-jdo\trunk\target\classes
[DEBUG] -- end configuration --
[INFO] [kodo:enhance {execution: kodo-enhance}]
[info] Found
file:E:\STC\svn\modules\services\supplementaldata-jdo\trunk\target\classes\com\stchome\application\supplementalforms\persist\persist.jdo
[info] [EMAIL PROTECTED]
[debug] Added to Classpath:
[debug]
/E:/STC/svn/modules/services/supplementaldata-jdo/trunk/src/main/resources/
[debug]
/E:/STC/svn/modules/services/supplementaldata-jdo/trunk/target/classes/
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Provider org.apache.xerces.jaxp.SAXParserFactoryImpl not found
[INFO]
[DEBUG] Trace
javax.xml.parsers.FactoryConfigurationError: Provider
org.apache.xerces.jaxp.SAXParserFactoryImpl not found
at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:93)
at serp.xml.XMLFactory.checkSAXCache(XMLFactory.java:217)
at serp.xml.XMLFactory.getSAXParser(XMLFactory.java:66)
at
com.solarmetric.meta.XMLMetaDataParser.parseNew(XMLMetaDataParser.java:354)
at com.solarmetric.meta.XMLMetaDataParser.parse(XMLMetaDataParser.java:320)
at
Re: [vote] release maven-help-plugin 2.0
+1 Vincent 2006/1/11, Brett Porter [EMAIL PROTECTED]: This needs to get out there with the new name. Can we do a release of the current code? There are 2 feature requests in JIRA that can wait until 2.1. Also, we should possibly rename the JIRA project and prefix. [ ] +1 [ ] +0 [ ] -1 - 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: [vote] PMD plugin 2.0-beta-1 release
+1 Vincent 2006/1/9, Mike Perham [EMAIL PROTECTED]: All outstanding JIRA issues have been closed so I'd like to suggest a new release. http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hide sorter/order=ASCsorter/field=prioritypid=11140fixfor=12176 Brett asks: - How does its functionality compare to Maven 1.0? Maven 1.x's PMD plugin is documented here: http://maven.apache.org/maven-1.x/reference/plugins/pmd/ The only thing I think is missing is more flexibility around the source files: source excluding, multiple source roots, etc. CPD was added today. The m1 plugin did not have the capability to generate non-html output which m2 does. - Is this a 2.0 release? Beta release? Personally I think it's a 2.0-beta-1. There are no tests currently so I would be hesitant to call this a quality release without some sort of test suite. mike - 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]
[jira] Created: (MANTRUN-38) Messed up maven.dependency.classpath when using maven-antrun-plugin-1.1
Messed up maven.dependency.classpath when using maven-antrun-plugin-1.1
---
Key: MANTRUN-38
URL: http://jira.codehaus.org/browse/MANTRUN-38
Project: Maven 2.x Antrun Plugin
Type: Bug
Versions: 1.1
Environment: suse10, maven-2.0.1, maven-antrun-plugin-1.1.
Reporter: Rohnny Moland (JIRA)
When running embedded ant tasks inside the pom, and trying to retrieve the
maven.dependency.classpath,
it is messed up. Works fine in the 1.0 version of the plugin, but not in 1.1.
How to reproduce:
In pom.xml include something like:
[..]
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
version1.1/version
executions
execution
idtest-compile/id
phasecompile/phase
configuration
tasks
property name=mdc refid=maven.dependency.classpath/
echoMDC: ${mdc}/echo
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
/plugin
[..]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MAVENUPLOAD-660) ProGuard
[ http://jira.codehaus.org/browse/MAVENUPLOAD-660?page=all ] Michael Böckling updated MAVENUPLOAD-660: - Attachment: proguard-3.4-bundle.jar ProGuard Key: MAVENUPLOAD-660 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-660 Project: maven-upload-requests Type: Task Reporter: Michael Böckling Attachments: proguard-3.4-bundle.jar, proguard-3.4-bundle.jar ProGuard is a free Java class file shrinker, optimizer, and obfuscator. It can detect and remove unused classes, fields, methods, and attributes. It can then optimize bytecode and remove unused instructions. Finally, it can rename the remaining classes, fields, and methods using short meaningless names. The resulting jars are smaller and harder to reverse-engineer. Note: - I'm not the developer - This project doesn't use Maven, but I checked it builds correctly using the provided POM - you might want to check the kenv dependency and see if you like the group-id (there is no proposal for naming j2me jars in the coping-with-sun-jars table) - It is under GPL with a special excpetion clause. Both parts are in the license.txt. - I contacted the author if he would grant a GPL exception for Proguard usage in Maven (meaning that a maven proguard plugin is allowed to use e.g. Apache 2.0 license), and it seems that he would do that. If you have any questions, you may contact me at michael dot boeckling at giniality dot ch -- 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 trunk - SUCCESS - update] Wed Jan 11 15:30:02 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060111.153002.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060111.153002.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No longer syncing Maven 1.x repository to Ibiblio
that's it On 1/11/06, Brett Porter [EMAIL PROTECTED] wrote: Ok, I understand now what you mean by relocate. We should put the relocation info in the POM, but still retain the JAR in both locations. - Brett Carlos Sanchez wrote: On 1/10/06, Brett Porter [EMAIL PROTECTED] wrote: A problem is that we'll be publishing things like log4j 1.1-dev, probably we should relocate this to log4j-1.1-2005 to keep it consistent. m1 would still get the 1.1-dev but m2 will get the snapshot and a warning if somebody tries to use it. I don't think so. The Maven 1.x repository basically doesn't exist (its not web accessible). They are identical. yep, but m1 won't follow pom relocations - 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]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Wed Jan 11 15:45:01 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060111.154501.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060111.154501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-660) ProGuard
[ http://jira.codehaus.org/browse/MAVENUPLOAD-660?page=comments#action_55524 ] Carlos Sanchez commented on MAVENUPLOAD-660: com.sun.j2me.wtk artifact doesn't exist. If it can't be redistributed at least you have to provide a pom. ant is required to compile and runtime? that's what you're saying here ProGuard Key: MAVENUPLOAD-660 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-660 Project: maven-upload-requests Type: Task Reporter: Michael Böckling Attachments: proguard-3.4-bundle.jar, proguard-3.4-bundle.jar ProGuard is a free Java class file shrinker, optimizer, and obfuscator. It can detect and remove unused classes, fields, methods, and attributes. It can then optimize bytecode and remove unused instructions. Finally, it can rename the remaining classes, fields, and methods using short meaningless names. The resulting jars are smaller and harder to reverse-engineer. Note: - I'm not the developer - This project doesn't use Maven, but I checked it builds correctly using the provided POM - you might want to check the kenv dependency and see if you like the group-id (there is no proposal for naming j2me jars in the coping-with-sun-jars table) - It is under GPL with a special excpetion clause. Both parts are in the license.txt. - I contacted the author if he would grant a GPL exception for Proguard usage in Maven (meaning that a maven proguard plugin is allowed to use e.g. Apache 2.0 license), and it seems that he would do that. If you have any questions, you may contact me at michael dot boeckling at giniality dot ch -- 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: (MAVENUPLOAD-644) Maven Jini Plug-in version 2.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-644?page=all ] Carlos Sanchez closed MAVENUPLOAD-644: -- Resolution: Fixed Maven Jini Plug-in version 2.0 -- Key: MAVENUPLOAD-644 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-644 Project: maven-upload-requests Type: Task Reporter: Chris Sterling Assignee: Carlos Sanchez This is a Maven plug-in for Jini service based projects. It's initial capabilities are: * Archetype for Jini service project creation * Starting/Stopping of Jini starter kit services: Reggie, Mahalo, Phoenix, Fiddler, Norm, Mercury, Outrigger, Browser, and HTTP daemon * Configurable RMI runtime: JRMP, JERI, or JERI/JSSE * Configurable activation and persistence modes: transient, activatable, nonactivatable -- 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] Reopened: (MNG-1950) Ability to introduce new lifecycles phases
[ http://jira.codehaus.org/browse/MNG-1950?page=all ] Chris Hagmann reopened MNG-1950: Brett, I reopened this issue, because: As long as I cannot use a plugin with one configuration per goal, I still have the need to have custom lifecycle phases. Nobody has ever mentioned how to do that. All I know how to do is to have one configuration per lifecycle phase, using the execution tag. So, it's either that which is described in (MJAVADOC-44) or additional lifecycle phase, otherwise I'm dead in the water and cannot move my projects to Maven 2. Solutions mentioned on the mailing lists don't resolve my issues, they just work for very simple use cases. On a different note, I think you should really think about making the lifecycle more flexible. In Maven 1 this was so much more flexibile, and I would have introduced so many people to Maven, if it wasn't for lack of performance. I simply don't think that a build tool is supposed to impose a build lifecycle on a project. At least, converting it to a New Feature request would be appreciated. Chris Ability to introduce new lifecycles phases -- Key: MNG-1950 URL: http://jira.codehaus.org/browse/MNG-1950 Project: Maven 2 Type: Improvement Components: Plugins and Lifecycle Versions: 2.0.1 Reporter: Chris Hagmann Assignee: Brett Porter Priority: Blocker I have simple use case which I cannot resolve with Maven 2 as it is right now. I have a project (actually many), where I need to do the following: - Create an JAR artifact (standard stuff, easily possible) - Create a source code artifact (standard stuff, easily possible) - Create Javadoc and a JAR archive of it (not possible, I explain why). - Create a distribution package with release notes, customized reports, Javadoc, JAR, dependencies, documentation, filtered files, etc. (not possible, I explain why and will file another JIRA issue for this) The constraint is that I need to create all 4 artifacts and have them installed them in the repository when using mvn install. As there are no other appropriate lifecycle phases in the default lifecycle, I attach the generation of all 4 artifacts to the phase package. That is very messy, and won't provide me with what I need. It should be possible to define a new lifecycle and have new phases attached to it. E.g.: - ... (standard lifecycle phases) - test - jar - javadoc - source-archive - javadoc-archive - package - ... (standard lifecycle phases) The reason why it is mandatory at this point to have new lifecycle phases, is that there is a constraint that a plugin can have only one unique configuration per lifecycle phase. So if I need to use the same plugin, but e.g. using different goals which require different plugin configurations, then that's not possible. The only way this can be achieved is by using new lifecycle phases, which is also not possible at this point. Meaning, I cannot create a solution for my simple use case in Maven 2 and hence it blocks me for moving to Maven 2 (I really hate to file blockers, but I'm at a dead-end). -- 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: (MEV-287) Spring beans 1.2.5 jar is corrupted
[ http://jira.codehaus.org/browse/MEV-287?page=comments#action_55527 ] Carlos Sanchez commented on MEV-287: I don't see any problem , how can be reproduced? Spring beans 1.2.5 jar is corrupted --- Key: MEV-287 URL: http://jira.codehaus.org/browse/MEV-287 Project: Maven Evangelism Type: Bug Reporter: Alexandre Poitras Some headers seem to be corrupted. -- 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: (MEV-286) Erase top Spring package since the real ones are in org.springframework
[ http://jira.codehaus.org/browse/MEV-286?page=all ] Carlos Sanchez closed MEV-286: -- Assign To: Carlos Sanchez Resolution: Won't Fix Nothing is removed from ibiblio you can provide relocation poms though Erase top Spring package since the real ones are in org.springframework --- Key: MEV-286 URL: http://jira.codehaus.org/browse/MEV-286 Project: Maven Evangelism Type: Improvement Components: Invalid POM Reporter: Alexandre Poitras Assignee: Carlos Sanchez The top spring package is confusing and the poms updated are located in org.springframework package. -- 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 logging
Jesse McConnell wrote: I have been a big fan of domained logging...where the logging api call contains whatever is necessary to earmark that log message as belonging to a particular domain (domain being whatever you want to define it as, the class, the package, the logical functionality of something..) I have done this before with something akin to getLog().log(foo, Domain.REPO); where REPO is a short or a long constant defined in the Domain object. I don't think that would work for our purposes since we are hiding the logging classes from a mojo for instance... getLog().domain(foo, repo); might work, and have some dynamic process in the logging that registers new logging domains on the fly. In log4j I just made the domain be their own logger instance with custom appenders...in maven they could be shoved out to the console marked as [REPO] in the log message so you can easily grep through for those logging outputs. It is probably overkill to make seperate logging files for each domain, but domained logging to one output file toggled by a flag, coupled with the [FOO] distingishers would take care of the problem I think.. That would be cool! It would be far simpler for users to track down specific problems and even if there are intersecting domains involved you just turn on the logging for the appropriate domain. Very nice idea. jesse On 1/11/06, Brett Porter [EMAIL PROTECTED] wrote: Hi John, I think we'd all agree with the sentiment. I think the default needs to be less noisy, and -X should be targetted (debug artifact resolution, debug pom, etc). We could name systems and log accordingly. This is all in JIRA. If you have any suggestions for implementation, please say so! Cheers, Brett John Allen wrote: Thoughts on logging:- I would like to see logging messages use relevant and meaningful identifiers that are correlatable to provide users with a means of knowing what is going on and what sequence of events has brought about the output. Currently huge amounts of work goes on 'behind the scenes' that results in lots of messages being produced long before there's any mention of what phase or plugin goal has caused the messages or where the user is in the flow of things. One of the biggest draw backs with using maven 2, beyond the lack of tutorials and indepth technical documentation, is its difficulty in problem identifcation and resolution - even to the hex headed, when something breaks/doesnt work (as expected) the only option is to spend a week (or 2) hacking away at the mighty collection of projects, code, apis and utils (i.e. custom everything) trying to get to grips with whats going on uner the scenes. In my humble opinion, a build system, with its critical posiitoning within the engineering process, has gotta be simple (or at least appear to be without obscuring pertinent details), accessible and above all easy to fix and administer and currently the lack of consistent, user oriented logging and tracing gets in the way of this. Regarding m2s adoption in large scale enterprise dev env projects: yes I need a build fwk that supports/promotes depedency mgmt, standardisation, reporting, network delivery, deployment control, agile SDM techniques and architeral governance but more importantly, i need one that is easy to support, train, administer, adapt, extend and fix. Better messages and message tracing and some proper technical docs will help this i think. Observations:- - Too much noise that is only really meaningful to experts - Unable to distinguish what action has caused a message, part of a wider issue with not being able to associate what is being said, by who, and why (users pov) - No ability to extend message generation/delivery with adapters etc. John Allen. - 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] -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org you are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-285) Erase JAXME package since it is now located in org.apache.ws
[ http://jira.codehaus.org/browse/MEV-285?page=all ] Carlos Sanchez closed MEV-285: -- Assign To: Carlos Sanchez Resolution: Won't Fix Nothing is removed from ibiblio you can provide relocation poms though Erase JAXME package since it is now located in org.apache.ws Key: MEV-285 URL: http://jira.codehaus.org/browse/MEV-285 Project: Maven Evangelism Type: Improvement Components: Invalid POM Reporter: Alexandre Poitras Assignee: Carlos Sanchez Having jaxme located at the repository root and in the org.apache.ws is confusing. Plus, the pom files in the /jaxme package don't have any dependencies in it, everyone should use the org.apache.ws.jaxme package. -- 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: (MAVENUPLOAD-660) ProGuard
[ http://jira.codehaus.org/browse/MAVENUPLOAD-660?page=comments#action_55531 ] Michael Böckling commented on MAVENUPLOAD-660: -- No, ANT and WTK are needed to compile proguard, but are not necessarily needed when using proguard. Isn't that what the compile scope implies? I also tried using optional, so the dependencies don't get inherited, but that caused Maven to say that it can't find the files from the stated dependencies (using maven 2.0.1). Is this a bug? I will upload the wtk jar, too, but maybe you guys should first define the recommended naming of Sun j2me groupId's? ProGuard Key: MAVENUPLOAD-660 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-660 Project: maven-upload-requests Type: Task Reporter: Michael Böckling Attachments: proguard-3.4-bundle.jar, proguard-3.4-bundle.jar ProGuard is a free Java class file shrinker, optimizer, and obfuscator. It can detect and remove unused classes, fields, methods, and attributes. It can then optimize bytecode and remove unused instructions. Finally, it can rename the remaining classes, fields, and methods using short meaningless names. The resulting jars are smaller and harder to reverse-engineer. Note: - I'm not the developer - This project doesn't use Maven, but I checked it builds correctly using the provided POM - you might want to check the kenv dependency and see if you like the group-id (there is no proposal for naming j2me jars in the coping-with-sun-jars table) - It is under GPL with a special excpetion clause. Both parts are in the license.txt. - I contacted the author if he would grant a GPL exception for Proguard usage in Maven (meaning that a maven proguard plugin is allowed to use e.g. Apache 2.0 license), and it seems that he would do that. If you have any questions, you may contact me at michael dot boeckling at giniality dot ch -- 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]
Errors running 1.1-SNAPSHOT
After building with sh build.sh i can create the root user.
Trying to login results allways in:
org.codehaus.plexus.action.ActionNotFoundException: Cannot find action:
login
at
org.codehaus.plexus.action.DefaultActionManager.lookup(DefaultActionMana
ger.java:61)
at
org.codehaus.plexus.summit.pipeline.valve.ActionValve.invoke(ActionValve
.java:62)
at
org.codehaus.plexus.summit.pipeline.AbstractPipeline.invoke(AbstractPipe
line.java:70)
at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54)
at org.codehaus.plexus.summit.Summit.doPost(Summit.java:108)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:615)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationH
andler.java:294)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1807)
at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationCon
text.java:525)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1757)
at org.mortbay.http.HttpServer.service(HttpServer.java:879)
at
org.mortbay.http.HttpConnection.service(HttpConnection.java:789)
at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960)
at
org.mortbay.http.HttpConnection.handle(HttpConnection.java:806)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218
)
at
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:331)
at
org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:520)
Caused by:
org.codehaus.plexus.component.repository.exception.ComponentLookupExcept
ion: Unable to lookup component
'org.codehaus.plexus.action.Actionlogin', it could not be started
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer
.java:335)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer
.java:436)
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.PlexusContainerLo
cator.lookup(PlexusContainerLocator.java:38)
at
org.codehaus.plexus.action.DefaultActionManager.lookup(DefaultActionMana
ger.java:57)
... 19 more
Caused by:
org.codehaus.plexus.component.repository.exception.ComponentLifecycleExc
eption: Error starting component
at
org.codehaus.plexus.component.manager.AbstractComponentManager.startComp
onentLifecycle(AbstractComponentManager.java:109)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.createCom
ponentInstance(AbstractComponentManager.java:95)
at
org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.g
etComponent(ClassicSingletonComponentManager.java:92)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer
.java:327)
... 22 more
Caused by:
org.codehaus.plexus.personality.plexus.lifecycle.phase.PhaseExecutionExc
eption: Error composing component
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.
execute(CompositionPhase.java:33)
at
org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLif
ecycleHandler.java:101)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.startComp
onentLifecycle(AbstractComponentManager.java:105)
... 25 more
Caused by:
org.codehaus.plexus.component.composition.CompositionException:
Composition failed of field authenticator in object of type
org.apache.maven.continuum.web.action.Login because the requirement
ComponentRequirement{role='org.codehaus.plexus.security.Authenticator',
roleHint='built-in-store', fieldName='null'} was missing
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assignR
equirementToField(FieldComponentComposer.java:154)
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assembl
eComponent(FieldComponentComposer.java:73)
at
org.codehaus.plexus.component.composition.DefaultComponentComposerManage
r.assembleComponent(DefaultComponentComposerManager.java:68)
at
org.codehaus.plexus.DefaultPlexusContainer.composeComponent(DefaultPlexu
sContainer.java:1476)
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.
execute(CompositionPhase.java:29)
... 27 more
Caused by:
org.codehaus.plexus.component.repository.exception.ComponentLookupExcept
ion: Unable to lookup component
'org.codehaus.plexus.security.Authenticatorbuilt-in-store', it could not
be started
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer
.java:335)
at
org.codehaus.plexus.component.composition.FieldComponentComposer.assignR
equirementToField(FieldComponentComposer.java:129)
... 31 more
Caused by:
[jira] Commented: (MAVENUPLOAD-660) ProGuard
[ http://jira.codehaus.org/browse/MAVENUPLOAD-660?page=comments#action_55532 ] Carlos Sanchez commented on MAVENUPLOAD-660: not necessarily needed sounds like optional, and it should work to know the naming i have to know what jar are you talking about, where to get it,... ProGuard Key: MAVENUPLOAD-660 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-660 Project: maven-upload-requests Type: Task Reporter: Michael Böckling Attachments: proguard-3.4-bundle.jar, proguard-3.4-bundle.jar ProGuard is a free Java class file shrinker, optimizer, and obfuscator. It can detect and remove unused classes, fields, methods, and attributes. It can then optimize bytecode and remove unused instructions. Finally, it can rename the remaining classes, fields, and methods using short meaningless names. The resulting jars are smaller and harder to reverse-engineer. Note: - I'm not the developer - This project doesn't use Maven, but I checked it builds correctly using the provided POM - you might want to check the kenv dependency and see if you like the group-id (there is no proposal for naming j2me jars in the coping-with-sun-jars table) - It is under GPL with a special excpetion clause. Both parts are in the license.txt. - I contacted the author if he would grant a GPL exception for Proguard usage in Maven (meaning that a maven proguard plugin is allowed to use e.g. Apache 2.0 license), and it seems that he would do that. If you have any questions, you may contact me at michael dot boeckling at giniality dot ch -- 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 logging
On 1/11/06, Brett Porter [EMAIL PROTECTED] wrote: I think we'd all agree with the sentiment. I think the default needs to be less noisy Well, a good start for removing LOTS of useless debug messages while generating site or reports could be committing this patch to plexus: http://jira.codehaus.org/browse/PLX-180 I recently reviewed a few m2 plugins, jxr and so on, by reducing the log at info level. This plus the plexus-velocity patch should really improve the situation... fabrizio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=all ] Jesse Kuhnert updated MSUREFIRE-23: --- Attachment: testng-4.4.5-jdk14.jar Support TestNG -- Key: MSUREFIRE-23 URL: http://jira.codehaus.org/browse/MSUREFIRE-23 Project: Maven 2.x Surefire Plugin Type: New Feature Reporter: Mike Perham Attachments: maven-surefire-plugin-patch.txt, maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, testng-4.4.5-jdk14.jar, testng-4.4.5-jdk15.jar Add support for running unit tests with TestNG. http://www.testng.org -- 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: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=all ] Jesse Kuhnert updated MSUREFIRE-23: --- Attachment: testng-4.4.5-jdk15.jar Support TestNG -- Key: MSUREFIRE-23 URL: http://jira.codehaus.org/browse/MSUREFIRE-23 Project: Maven 2.x Surefire Plugin Type: New Feature Reporter: Mike Perham Attachments: maven-surefire-plugin-patch.txt, maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, testng-4.4.5-jdk14.jar, testng-4.4.5-jdk15.jar Add support for running unit tests with TestNG. http://www.testng.org -- 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: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=all ] Jesse Kuhnert updated MSUREFIRE-23: --- Attachment: surefire-patch.txt maven-surefire-report-maven-plugin-patch.txt maven-surefire-plugin-patch.txt Support TestNG -- Key: MSUREFIRE-23 URL: http://jira.codehaus.org/browse/MSUREFIRE-23 Project: Maven 2.x Surefire Plugin Type: New Feature Reporter: Mike Perham Attachments: maven-surefire-plugin-patch.txt, maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, testng-4.4.5-jdk14.jar, testng-4.4.5-jdk15.jar Add support for running unit tests with TestNG. http://www.testng.org -- 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: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_55533 ] Jesse Kuhnert commented on MSUREFIRE-23: These patches should be enough for someone to play around with the patch work. I'm going to create sub-tasks on this issue for the work I still have left to do. Support TestNG -- Key: MSUREFIRE-23 URL: http://jira.codehaus.org/browse/MSUREFIRE-23 Project: Maven 2.x Surefire Plugin Type: New Feature Reporter: Mike Perham Attachments: maven-surefire-plugin-patch.txt, maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, testng-4.4.5-jdk14.jar, testng-4.4.5-jdk15.jar Add support for running unit tests with TestNG. http://www.testng.org -- 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: (MSUREFIRE-40) Add relevant parameters for configuring testng
Add relevant parameters for configuring testng -- Key: MSUREFIRE-40 URL: http://jira.codehaus.org/browse/MSUREFIRE-40 Project: Maven 2.x Surefire Plugin Type: Sub-task Environment: any Reporter: Jesse Kuhnert Add all of the normal testng parameters to runtime, like which groups to run, an optional suite.xml file to use, 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MSUREFIRE-41) Enable show/hide on surefire report
Enable show/hide on surefire report --- Key: MSUREFIRE-41 URL: http://jira.codehaus.org/browse/MSUREFIRE-41 Project: Maven 2.x Surefire Plugin Type: Sub-task Environment: any Reporter: Jesse Kuhnert enable show/hide on surefire report -- 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: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_55535 ] Jesse Kuhnert commented on MSUREFIRE-23: I still need to convert testng to use maven, at least for publishing to testng but thought I'd save myself the trouble if everyone hates the patches. Support TestNG -- Key: MSUREFIRE-23 URL: http://jira.codehaus.org/browse/MSUREFIRE-23 Project: Maven 2.x Surefire Plugin Type: New Feature Reporter: Mike Perham Attachments: maven-surefire-plugin-patch.txt, maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, testng-4.4.5-jdk14.jar, testng-4.4.5-jdk15.jar Add support for running unit tests with TestNG. http://www.testng.org -- 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-672) cactus:cactus:13-1.7 relocation to cactus:cactus-13:1.7 incomplete
cactus:cactus:13-1.7 relocation to cactus:cactus-13:1.7 incomplete -- Key: MAVENUPLOAD-672 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-672 Project: maven-upload-requests Type: Bug Reporter: Shinobu Kawai Yoshida Adding cactus:cactus:13-1.7 to dependencies causes the following BUILD ERROR: [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [WARNING] While downloading cactus:cactus:13-1.7 This artifact has been relocated to cactus:cactus-13:1.7. Downloading: http://repo1.maven.org/maven2/cactus/cactus-13/1.7/cactus-13-1.7.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) Downloading: http://repo1.maven.org/maven2/cactus/cactus-13/1.7/cactus-13-1.7.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Error transferring file cactus:cactus-13:jar:1.7 from the specified remote repositories: central (http://repo1.maven.org/maven2) Path to dependency: 1) com.mycompany.app:my-app:jar:1.0-SNAPSHOT 2) cactus:cactus-13:jar:1.7 -- 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: svn commit: r367861 - in /maven/maven-1/plugins/trunk/dashboard: src/plugin-resources/templates/dashboard.jsl xdocs/changes.xml
I checked with m1.0.2 and m1.1b3-SNAPSHOT. Seems to work fine.
-Lukas
Arnaud HERITIER wrote:
[SNIP]
URL: http://svn.apache.org/viewcvs?rev=367861view=rev
Log:
PR: MPDASHBOARD-32
maven.dashboard.report.showempty property not honored.
[SNIP]
- j:if test=${notEmptyElems.isEmpty() == 'true'}
+ j:if test=${empty(notEmptyElems)}
[SNIP]
Lukas, did you test it with maven 1.1 and 1.0 ?
I remember that there was a problem with the empty function in an old
release of Jelly ?
Arnaud
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-help-plugin 2.0
+1 Lukas Brett Porter wrote: This needs to get out there with the new name. Can we do a release of the current code? There are 2 feature requests in JIRA that can wait until 2.1. Also, we should possibly rename the JIRA project and prefix. [ ] +1 [ ] +0 [ ] -1 - 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]
Security in Continuum
Hi, In 1.1, we have decided to rework all security features. I tried to use osuser but this framework is crappy : - UserManager is a final class that load a osuser config file, we can't set parameters with plexus because all initialization phase are done in constuctor that read config file - need to duplicate code between Authenticator and AccessProvider - all providers interface extends a base provider interface that require some methods without relation with provider must do I looked at berkano too. This project use actually dao pattern and hibernate and permission doesn't seems to be supported I looked at seraph too. This project seems to be interesting, it's used by confluence and jira. It seems we have all we need in it but it require to be used in a web app environment, so i think we can't use it if we want to use security framework in a standalone app in future. jaas: i think we need a more high level framework. I'd prefer to use a plugin where jaas can be plugged acegisecurity: this framework seems to be the more advanced. The most important problem for its usage, it's that required spring framework. I don't like to include in continuum a new IOC container only for this feature especially with a 2Mo jar. Can we exclude easily spring dependency from acegi by writing a mockimplementation? Can we use it in a standalone app? last possibility : we can write our own security framework. If we choose it, we'll can start with features required by continuum (user, group, general and per project permission schemes) and we'll add more functionalities later if we need more. What do you think about all these frameworks? Which do we choose? Emmanuel
[jira] Closed: (MANTRUN-38) Messed up maven.dependency.classpath when using maven-antrun-plugin-1.1
[ http://jira.codehaus.org/browse/MANTRUN-38?page=all ]
Carlos Sanchez closed MANTRUN-38:
-
Assign To: Carlos Sanchez
Resolution: Fixed
Fix Version: 1.2
Reverted the changes, not it's equal to compile classpath as before, but will
be deprecated in favor of maven.compile.classpath
Messed up maven.dependency.classpath when using maven-antrun-plugin-1.1
---
Key: MANTRUN-38
URL: http://jira.codehaus.org/browse/MANTRUN-38
Project: Maven 2.x Antrun Plugin
Type: Bug
Versions: 1.1
Environment: suse10, maven-2.0.1, maven-antrun-plugin-1.1.
Reporter: Rohnny Moland (JIRA)
Assignee: Carlos Sanchez
Fix For: 1.2
When running embedded ant tasks inside the pom, and trying to retrieve the
maven.dependency.classpath,
it is messed up. Works fine in the 1.0 version of the plugin, but not in 1.1.
How to reproduce:
In pom.xml include something like:
[..]
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
version1.1/version
executions
execution
idtest-compile/id
phasecompile/phase
configuration
tasks
property name=mdc refid=maven.dependency.classpath/
echoMDC: ${mdc}/echo
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
/plugin
[..]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Wed Jan 11 18:15:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060111.181501.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060111.181501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Wed Jan 11 18:30:01 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060111.183001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060111.183001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MANTRUN-37) Antrun breaks on multi-module builds
[ http://jira.codehaus.org/browse/MANTRUN-37?page=comments#action_55539 ]
Carlos Sanchez commented on MANTRUN-37:
---
I see in your logs maven-antrun-plugin:1.0 ???
I need more info to reproduce it
The it tests use multimodule and they work
Antrun breaks on multi-module builds
Key: MANTRUN-37
URL: http://jira.codehaus.org/browse/MANTRUN-37
Project: Maven 2.x Antrun Plugin
Type: Bug
Versions: 1.1
Environment: Maven 2.0.1
Reporter: Mike Perham
Priority: Critical
Fix For: 1.2
I just updated to antrun v1.1 (which needs to be marked as released in jira
BTW) and find that my multimodule build is now breaking. Running the build
in the child module itself works fine but if I build the parent, it fails
when it gets to the child with the antrun task. Here's part of the debug
output. Note it says 1.1 in the dependency tree but 1.0 further down.
{noformat}
[DEBUG] org.apache.maven.plugins:maven-antrun-plugin:maven-plugin:1.1
(selected for runtime)
[DEBUG] org.apache.maven:maven-project:jar:2.0.1 (selected for runtime)
[DEBUG] org.apache.maven:maven-model:jar:2.0.1 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5 (selected for
runtime)
[DEBUG] classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
[DEBUG] org.apache.maven:maven-profile:jar:2.0.1 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9
(selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
found: 1.0.5)
[DEBUG] junit:junit:jar:3.8.1 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9
(selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
found: 1.0.5)
[DEBUG] classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
[DEBUG] junit:junit:jar:3.8.1 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5 (selected for runtime)
[DEBUG] org.apache.maven:maven-artifact-manager:jar:2.0.1 (selected for
runtime)
[DEBUG] org.apache.maven:maven-repository-metadata:jar:2.0.1 (selected
for runtime)
[DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5
(selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
found: 1.0.5)
[DEBUG] org.apache.maven:maven-artifact:jar:2.0.1 (selected for runtime)
[DEBUG] org.apache.maven:maven-artifact:jar:2.0.1 (selected for runtime)
[DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.1 (selected for runtime)
[DEBUG] ant:ant:jar:1.6.5 (selected for runtime)
[DEBUG] ant:ant-launcher:jar:1.6.5 (selected for runtime)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Internal error in the plugin manager executing goal
'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the
mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin
'org.apache.maven.plugins:maven-antrun-plugin'
Component descriptor cannot be found in the component repository:
org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-antrun-plugin:1.0:run.
[INFO]
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the
plugin manager executing goal
'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the
mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin
'org.apache.maven.plugins:maven-antrun-plugin'
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
[maven2 build branches/maven-2.0.x - SUCCESS - update] Wed Jan 11 18:45:01 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060111.184501.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060111.184501.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: m2 logging
Jason van Zyl wrote: That would be cool! It would be far simpler for users to track down specific problems and even if there are intersecting domains involved you just turn on the logging for the appropriate domain. Very nice idea. Agreed. So how do we go about this? We can probably match the package name to a domain, but I'm not sure how we then rename that and get the plexus logger to spit it out. Jesse, are you interested in investigating? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: m2 logging
sure thing, might not get to it for a bit...kinda crushed under some other things but definitely something interesting to look into. I was just thinking, that perhaps instead of domaining by package, it might be interesting to try and do it via artifact...I am not sure what kind of overhead would be involved, but getClass().getResource() works for pulling out of the jar you are a part of...so we ought to be able to discover the artifact pretty easily. Probably not something we want to do every log hit but some kinda singleton in the plexus logging might be able to manage it... but by domaining by artifact, you could have the added benefit of logging context of artifact interaction and by grepping out on a particular artifact get all of the dealings in that particular artifact. just a thought jesse On 1/11/06, Brett Porter [EMAIL PROTECTED] wrote: Jason van Zyl wrote: That would be cool! It would be far simpler for users to track down specific problems and even if there are intersecting domains involved you just turn on the logging for the appropriate domain. Very nice idea. Agreed. So how do we go about this? We can probably match the package name to a domain, but I'm not sure how we then rename that and get the plexus logger to spit it out. Jesse, are you interested in investigating? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom
[jira] Created: (MEV-289) Spring-full doesn't have any jars and there is already a Spring artifact.
Spring-full doesn't have any jars and there is already a Spring artifact. - Key: MEV-289 URL: http://jira.codehaus.org/browse/MEV-289 Project: Maven Evangelism Type: Bug Reporter: Alexandre Poitras Spring-full seems useless because there's already a Spring artifact wich is the complete Spring jar. It should be deleted since it is confusing. -- 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 trunk - SUCCESS - update] Wed Jan 11 19:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060111.190001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060111.190001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MJAR-17) specifying manifestFile does nothing
specifying manifestFile does nothing
--
Key: MJAR-17
URL: http://jira.codehaus.org/browse/MJAR-17
Project: Maven 2.x Jar Plugin
Type: Bug
Reporter: darren hartford
Trying to set an existing MANIFEST.MF file as the JAR Manifest, but continues
to generate the default Manifest.
sample config:
==
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
configuration
archive
indextrue/index
manifestFile${basedir}/META-INF/MANIFEST.MF/manifestFile
/archive
/configuration
/plugin
==
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MJAR-17) specifying manifestFile does nothing
[ http://jira.codehaus.org/browse/MJAR-17?page=all ]
darren hartford closed MJAR-17:
---
Resolution: Fixed
user.insufficient.Caffine error :-)
Just adds more data to the top of the specified Manifest file which is fine.
specifying manifestFile does nothing
--
Key: MJAR-17
URL: http://jira.codehaus.org/browse/MJAR-17
Project: Maven 2.x Jar Plugin
Type: Bug
Reporter: darren hartford
Trying to set an existing MANIFEST.MF file as the JAR Manifest, but continues
to generate the default Manifest.
sample config:
==
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
configuration
archive
indextrue/index
manifestFile${basedir}/META-INF/MANIFEST.MF/manifestFile
/archive
/configuration
/plugin
==
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-286) Erase top Spring package since the real ones are in org.springframework
[ http://jira.codehaus.org/browse/MEV-286?page=comments#action_55541 ] Alexandre Poitras commented on MEV-286: --- Cool! What is a relocation pom or is there any documentation on the subject? Erase top Spring package since the real ones are in org.springframework --- Key: MEV-286 URL: http://jira.codehaus.org/browse/MEV-286 Project: Maven Evangelism Type: Improvement Components: Invalid POM Reporter: Alexandre Poitras Assignee: Carlos Sanchez The top spring package is confusing and the poms updated are located in org.springframework package. -- 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: (MEV-286) Erase top Spring package since the real ones are in org.springframework
[ http://jira.codehaus.org/browse/MEV-286?page=comments#action_55543 ] Carlos Sanchez commented on MEV-286: Take a look at this http://test.maven.codehaus.org/maven2/servletapi/servlet-api/2.4/servlet-api-2.4.pom and http://maven.apache.org/guides/mini/guide-maven-evangelism.html Erase top Spring package since the real ones are in org.springframework --- Key: MEV-286 URL: http://jira.codehaus.org/browse/MEV-286 Project: Maven Evangelism Type: Improvement Components: Invalid POM Reporter: Alexandre Poitras Assignee: Carlos Sanchez The top spring package is confusing and the poms updated are located in org.springframework package. -- 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: (MEV-289) Spring-full doesn't have any jars and there is already a Spring artifact.
[ http://jira.codehaus.org/browse/MEV-289?page=all ] Carlos Sanchez closed MEV-289: -- Assign To: Carlos Sanchez Resolution: Won't Fix That pom was used to make easier poms for spring jars Spring-full doesn't have any jars and there is already a Spring artifact. - Key: MEV-289 URL: http://jira.codehaus.org/browse/MEV-289 Project: Maven Evangelism Type: Bug Reporter: Alexandre Poitras Assignee: Carlos Sanchez Spring-full seems useless because there's already a Spring artifact wich is the complete Spring jar. It should be deleted since it is confusing. -- 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: (MRESOURCES-8) maven-resources-plugin ignores configuration/resources property
[ http://jira.codehaus.org/browse/MRESOURCES-8?page=comments#action_55545 ]
Leszek Gawron commented on MRESOURCES-8:
My discussion on irc with Kenney ended up with the conclusion that something is
wrong in plexus configurator because maven-resources-plugin mojo 'resources'
field cannot be set from configuration (although it is not read-only). Thus the
patch provided is only a workaround.
maven-resources-plugin ignores configuration/resources property
---
Key: MRESOURCES-8
URL: http://jira.codehaus.org/browse/MRESOURCES-8
Project: Maven 2.x Resources Plugin
Type: Bug
Reporter: Leszek Gawron
Assignee: Brett Porter
Attachments: MRESOURCES-8-workaround.patch, example.zip, pom.xml
I am evaluating maven + eclipse combo. In a trivial POM filtered resources
exist only in target/classes. If one executes Project - Clean under eclipse
this information is lost. If filtered resources would appear as source folder
they would survive cleaning and not got overriden by unfiltered ones.
I have been trying to implement a scenario which would allow filtered
resources to appear as static source folder under eclipse.
The POM explains it best:
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.mobilebox.squash.client/groupId
artifactIdsquash-client/artifactId
packagingjar/packaging
version1.0-SNAPSHOT/version
nameMaven Quick Start Archetype/name
urlhttp://maven.apache.org/url
build
plugins
plugin
artifactIdmaven-resources-plugin/artifactId
executions
execution
idprefilter-resources/id
phasegenerate-resources/phase
goals
goalresources/goal
/goals
configuration
outputDirectorytarget/generated-resources/outputDirectory
resources
resource
directorysrc/main/resource-templates/directory
filteringtrue/filtering
/resource
/resources
/configuration
/execution
/executions
/plugin
/plugins
filters
filter${ffile}/filter
/filters
resources
resource
directorysrc/main/resources/directory
/resource
resource
directorytarget/generated-resources/directory
/resource
/resources
/build
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version3.8.1/version
scopetest/scope
/dependency
/dependencies
properties
ffilefilter.properties/ffile
/properties
/project
thing is this part:
resources
resource
directorysrc/main/properties/directory
filteringtrue/filtering
/resource
/resources
is completely ignored. Instead for both maven-resource-plugin executions (the
one in generate-resources phase and the default one) this config is used:
resources
resource
directorysrc/main/resources/directory
/resource
resource
directorytarget/generated-resources/directory
/resource
/resources
which of course breaks the whole idea.
Is this a bug or a design decision. In latter case is there any equivalent
approach I might take?
--
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: (MEV-290) Spring beans 1.2.5 jar is corrupted
Spring beans 1.2.5 jar is corrupted --- Key: MEV-290 URL: http://jira.codehaus.org/browse/MEV-290 Project: Maven Evangelism Type: Bug Reporter: Alexandre Poitras I get a jar bad header error whenever I attempt to use 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1898) Plugin classpath broken from 2.0 to 2.0.1
[ http://jira.codehaus.org/browse/MNG-1898?page=all ]
Brian Fox updated MNG-1898:
---
Attachment: test-1.0.zip
Plugin classpath broken from 2.0 to 2.0.1
-
Key: MNG-1898
URL: http://jira.codehaus.org/browse/MNG-1898
Project: Maven 2
Type: Bug
Environment: winxp
Reporter: Brian Fox
Assignee: John Casey
Priority: Blocker
Fix For: 2.0.3
Attachments: test-1.0.zip
I'm working on a kodo plugin in the codehaus mojo sandbox. Using 2.0, it
works fine. In 2.1, it can't find xercesImpl, which is a transitive
dependency of the plugin. Did something change to cause new behavior (aka a
bug) related to this? Just eyeballing the info below, in 2.0, the instance of
classloader was org.codehaus.classworlds.RealmClassLoader but in 2.0.1 it is
org.codehaus.plexus.util.RealmDelegatingClassLoader
I tried specifying xercesImpl as a direct dependency and that didn't work
either so I'm not sure it's related to the transitivity.
Output from 2.0.1: (2.0 follows further below)
[DEBUG] org.codehaus.mojo:kodo-maven-plugin:maven-plugin:1.0-alpha-1-SNAPSHOT
(selected for runtime)
[DEBUG] org.apache.maven:maven-model:jar:2.0 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for runtime)
[DEBUG] Skipping disabled repository snapshots
[DEBUG] com.solarmetric:kodo-jdo:jar:3.3.3 (setting version to: 3.3.3 from
range: [3.0,])
[DEBUG] com.solarmetric:kodo-jdo:jar:3.3.3 (selected for runtime)
[DEBUG] com.solarmetric:kodo-wl81manage:jar:1.0 (selected for runtime)
[DEBUG] com.solarmetric:kodo-workbench:jar:1.0 (selected for runtime)
[DEBUG] org.hsqldb:jdbc-hsql:jar:1.7.0 (selected for runtime)
[DEBUG] sqlline:sqlline:jar:1.0 (selected for runtime)
[DEBUG] jcommon:jcommon:jar:0.9.1 (selected for runtime)
[DEBUG] javax.jdo:jdo:jar:1.0.2 (selected for runtime)
[DEBUG] xalan:xalan:jar:2.5.1 (selected for runtime)
[DEBUG] jfreechart:jfreechart:jar:0.9.16 (selected for runtime)
[DEBUG] com.solarmetric:kodo-jdo-runtime:jar:3.3.3 (selected for runtime)
[DEBUG] javax.sql:jdbc-stdext:jar:2.0 (selected for runtime)
[DEBUG] jline:jline:jar:0.9.1 (selected for runtime)
[DEBUG] mx4j:mx4j-jmx:jar:1.1.1 (selected for runtime)
[DEBUG] jta-spec:jta-spec:jar:1.0.1 (selected for runtime)
[WARNING] While downloading xml-apis:xml-apis:2.0.0
This artifact has been relocated to xml-apis:xml-apis:1.0.b2.
[DEBUG] xml-apis:xml-apis:jar:1.0.b2 (selected for runtime)
[DEBUG] xerces:xercesImpl:jar:2.5.0 (selected for runtime)
[DEBUG] jca:jca:jar:1.0.0 (selected for runtime)
[DEBUG] mx4j:mx4j-tools:jar:1.1.1 (selected for runtime)
[DEBUG] jndi:jndi:jar:1.2.1 (selected for runtime)
[DEBUG] Skipping disabled repository snapshots
[DEBUG] log4j:log4j:jar:1.2.12 (setting version to: 1.2.12 from range:
[1.2.9,])
[DEBUG] log4j:log4j:jar:1.2.12 (selected for runtime)
[DEBUG] org.apache.maven:maven-plugin-api:jar:2.0 (selected for runtime)
[DEBUG] Configuring mojo
'org.codehaus.mojo:kodo-maven-plugin:1.0-alpha-1-SNAPSHOT:enhance' --
[DEBUG] (f) classDir =
E:\STC\svn\modules\services\supplementaldata-jdo\trunk\target\classes
[DEBUG] (f) resources = [EMAIL PROTECTED]
[DEBUG] (f) searchDir =
E:\STC\svn\modules\services\supplementaldata-jdo\trunk\target\classes
[DEBUG] -- end configuration --
[INFO] [kodo:enhance {execution: kodo-enhance}]
[info] Found
file:E:\STC\svn\modules\services\supplementaldata-jdo\trunk\target\classes\com\stchome\application\supplementalforms\persist\persist.jdo
[info] [EMAIL PROTECTED]
[debug] Added to Classpath:
[debug]
/E:/STC/svn/modules/services/supplementaldata-jdo/trunk/src/main/resources/
[debug]
/E:/STC/svn/modules/services/supplementaldata-jdo/trunk/target/classes/
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Provider org.apache.xerces.jaxp.SAXParserFactoryImpl not found
[INFO]
[DEBUG] Trace
javax.xml.parsers.FactoryConfigurationError: Provider
org.apache.xerces.jaxp.SAXParserFactoryImpl not found
at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:93)
at serp.xml.XMLFactory.checkSAXCache(XMLFactory.java:217)
at serp.xml.XMLFactory.getSAXParser(XMLFactory.java:66)
at
com.solarmetric.meta.XMLMetaDataParser.parseNew(XMLMetaDataParser.java:354)
at com.solarmetric.meta.XMLMetaDataParser.parse(XMLMetaDataParser.java:320)
at
com.solarmetric.meta.ClassArgParser.getFromMetaData(ClassArgParser.java:182)
at
com.solarmetric.meta.ClassArgParser.parseClassNames(ClassArgParser.java:98)
at
[jira] Updated: (MNG-1898) Plugin classpath broken from 2.0 to 2.0.1
[ http://jira.codehaus.org/browse/MNG-1898?page=all ]
Brian Fox updated MNG-1898:
---
Attachment: test-case.zip
Plugin classpath broken from 2.0 to 2.0.1
-
Key: MNG-1898
URL: http://jira.codehaus.org/browse/MNG-1898
Project: Maven 2
Type: Bug
Environment: winxp
Reporter: Brian Fox
Assignee: John Casey
Priority: Blocker
Fix For: 2.0.3
Attachments: test-1.0.zip, test-case.zip
I'm working on a kodo plugin in the codehaus mojo sandbox. Using 2.0, it
works fine. In 2.1, it can't find xercesImpl, which is a transitive
dependency of the plugin. Did something change to cause new behavior (aka a
bug) related to this? Just eyeballing the info below, in 2.0, the instance of
classloader was org.codehaus.classworlds.RealmClassLoader but in 2.0.1 it is
org.codehaus.plexus.util.RealmDelegatingClassLoader
I tried specifying xercesImpl as a direct dependency and that didn't work
either so I'm not sure it's related to the transitivity.
Output from 2.0.1: (2.0 follows further below)
[DEBUG] org.codehaus.mojo:kodo-maven-plugin:maven-plugin:1.0-alpha-1-SNAPSHOT
(selected for runtime)
[DEBUG] org.apache.maven:maven-model:jar:2.0 (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for runtime)
[DEBUG] Skipping disabled repository snapshots
[DEBUG] com.solarmetric:kodo-jdo:jar:3.3.3 (setting version to: 3.3.3 from
range: [3.0,])
[DEBUG] com.solarmetric:kodo-jdo:jar:3.3.3 (selected for runtime)
[DEBUG] com.solarmetric:kodo-wl81manage:jar:1.0 (selected for runtime)
[DEBUG] com.solarmetric:kodo-workbench:jar:1.0 (selected for runtime)
[DEBUG] org.hsqldb:jdbc-hsql:jar:1.7.0 (selected for runtime)
[DEBUG] sqlline:sqlline:jar:1.0 (selected for runtime)
[DEBUG] jcommon:jcommon:jar:0.9.1 (selected for runtime)
[DEBUG] javax.jdo:jdo:jar:1.0.2 (selected for runtime)
[DEBUG] xalan:xalan:jar:2.5.1 (selected for runtime)
[DEBUG] jfreechart:jfreechart:jar:0.9.16 (selected for runtime)
[DEBUG] com.solarmetric:kodo-jdo-runtime:jar:3.3.3 (selected for runtime)
[DEBUG] javax.sql:jdbc-stdext:jar:2.0 (selected for runtime)
[DEBUG] jline:jline:jar:0.9.1 (selected for runtime)
[DEBUG] mx4j:mx4j-jmx:jar:1.1.1 (selected for runtime)
[DEBUG] jta-spec:jta-spec:jar:1.0.1 (selected for runtime)
[WARNING] While downloading xml-apis:xml-apis:2.0.0
This artifact has been relocated to xml-apis:xml-apis:1.0.b2.
[DEBUG] xml-apis:xml-apis:jar:1.0.b2 (selected for runtime)
[DEBUG] xerces:xercesImpl:jar:2.5.0 (selected for runtime)
[DEBUG] jca:jca:jar:1.0.0 (selected for runtime)
[DEBUG] mx4j:mx4j-tools:jar:1.1.1 (selected for runtime)
[DEBUG] jndi:jndi:jar:1.2.1 (selected for runtime)
[DEBUG] Skipping disabled repository snapshots
[DEBUG] log4j:log4j:jar:1.2.12 (setting version to: 1.2.12 from range:
[1.2.9,])
[DEBUG] log4j:log4j:jar:1.2.12 (selected for runtime)
[DEBUG] org.apache.maven:maven-plugin-api:jar:2.0 (selected for runtime)
[DEBUG] Configuring mojo
'org.codehaus.mojo:kodo-maven-plugin:1.0-alpha-1-SNAPSHOT:enhance' --
[DEBUG] (f) classDir =
E:\STC\svn\modules\services\supplementaldata-jdo\trunk\target\classes
[DEBUG] (f) resources = [EMAIL PROTECTED]
[DEBUG] (f) searchDir =
E:\STC\svn\modules\services\supplementaldata-jdo\trunk\target\classes
[DEBUG] -- end configuration --
[INFO] [kodo:enhance {execution: kodo-enhance}]
[info] Found
file:E:\STC\svn\modules\services\supplementaldata-jdo\trunk\target\classes\com\stchome\application\supplementalforms\persist\persist.jdo
[info] [EMAIL PROTECTED]
[debug] Added to Classpath:
[debug]
/E:/STC/svn/modules/services/supplementaldata-jdo/trunk/src/main/resources/
[debug]
/E:/STC/svn/modules/services/supplementaldata-jdo/trunk/target/classes/
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Provider org.apache.xerces.jaxp.SAXParserFactoryImpl not found
[INFO]
[DEBUG] Trace
javax.xml.parsers.FactoryConfigurationError: Provider
org.apache.xerces.jaxp.SAXParserFactoryImpl not found
at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:93)
at serp.xml.XMLFactory.checkSAXCache(XMLFactory.java:217)
at serp.xml.XMLFactory.getSAXParser(XMLFactory.java:66)
at
com.solarmetric.meta.XMLMetaDataParser.parseNew(XMLMetaDataParser.java:354)
at com.solarmetric.meta.XMLMetaDataParser.parse(XMLMetaDataParser.java:320)
at
com.solarmetric.meta.ClassArgParser.getFromMetaData(ClassArgParser.java:182)
at
com.solarmetric.meta.ClassArgParser.parseClassNames(ClassArgParser.java:98)
at
[maven2 build trunk - FAILED - update] Wed Jan 11 20:00:00 GMT 2006
Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060111.21.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-290) Spring beans 1.2.5 jar is corrupted
[ http://jira.codehaus.org/browse/MEV-290?page=all ] Carlos Sanchez closed MEV-290: -- Assign To: Carlos Sanchez Resolution: Duplicate Why do you create duplicated issues? Spring beans 1.2.5 jar is corrupted --- Key: MEV-290 URL: http://jira.codehaus.org/browse/MEV-290 Project: Maven Evangelism Type: Bug Reporter: Alexandre Poitras Assignee: Carlos Sanchez I get a jar bad header error whenever I attempt to use 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONTINUUM-555) Continuum only executes default build-definition
Continuum only executes default build-definition Key: CONTINUUM-555 URL: http://jira.codehaus.org/browse/CONTINUUM-555 Project: Continuum Type: Bug Components: Core system Versions: 1.0.2 Reporter: Dave Brown Attachments: Picture 1.png Can't find any documentation to state to the contrary, but my understanding is that Continuum should execute all build-definitions on each scheduled build (only the default is executed on a Build Now) Attached is a screen shot of my build definitions. On the latest build, continuum only build the default. -- 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: (MEV-290) Spring beans 1.2.5 jar is corrupted
[ http://jira.codehaus.org/browse/MEV-290?page=comments#action_1 ] Alexandre Poitras commented on MEV-290: --- Sorry I didn't search before, my bad I taught if it was already reported it would have been fixed by now. I'll search before creating any issues. Spring beans 1.2.5 jar is corrupted --- Key: MEV-290 URL: http://jira.codehaus.org/browse/MEV-290 Project: Maven Evangelism Type: Bug Reporter: Alexandre Poitras Assignee: Carlos Sanchez I get a jar bad header error whenever I attempt to use 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-287) Spring beans 1.2.5 jar is corrupted
[ http://jira.codehaus.org/browse/MEV-287?page=all ] Carlos Sanchez closed MEV-287: -- Assign To: Carlos Sanchez Resolution: Cannot Reproduce jar tf works fine and the jar is exactly the same as distibuted by spring Spring beans 1.2.5 jar is corrupted --- Key: MEV-287 URL: http://jira.codehaus.org/browse/MEV-287 Project: Maven Evangelism Type: Bug Reporter: Alexandre Poitras Assignee: Carlos Sanchez Some headers seem to be corrupted. -- 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]
