Re: DB schema migration
Thanks Erik - I'll give that a try ASAP. On 24/04/2007, at 7:35 AM, Erik Bengtson wrote: Quoting Brett Porter [EMAIL PROTECTED]: Erik - the problem in upgrading is the changes in private tables between versions of jpox that we hadn't given explicit names to. We'd probably appreciate most help in future proofing our jpox use a bit more in case it's internal schema changes again. If you mean by private tables the JPOX_TABLES, you can drop it and JPOX will automatically recreate if it's needed.
Re: [VOTE] Release Maven Ant Tasks 2.0.6
Le lundi 23 avril 2007 22:05, Jason van Zyl a écrit : you mean: artifact:install-provider artifactId=wagon-ssh version=1.0- beta-2/ is not sufficient? and wagon-ftp? and wagon-webdav? Doesn't take much to make it that much easier. ok, why not. I tried to get how many KB each provider would add, to have figures for doesn't take much. But I couldn't: I get an error, either with trunk and 2.0.x branch: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error creating shaded jar. Embedded error: duplicate entry: hidden/org/codehaus/plexus/util/xml/PrettyPrintXMLWriter.class Do you know what's happening? I would have thought that this was the purpose of the shade version lockdown on 2.0.x branch, but that doesn't seem to work. BTW, the current staged Maven Ant Tasks are a lot better than the actually published 2.0.4 (which are quite buggy): I really think the better is to go with them, and only after that work on enhancements for 2.0.7. Maven 2.0.5 was released on 14/2 and 2.0.6 on 1/4: having a release for Ant Tasks is long awaited. Hervé - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Note on copying staged repositories
On 4/22/07, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, I just copied the staged repo for the clover plugin over and I used the following: mvn stage:copy -Dsource=http://people.apache.org/~vmassol/maven- staging -Dtarget=scp://people.apache.org/www/people.apache.org/repo/ m2-ibiblio-rsync-repository -Dversion=2.4 Will it copy all artifacts with version=2.4 from one repository to another? I think that optional groupId/artifactId parameters would be useful, what does others think about it? Regards, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r531837 - in /maven/release/trunk/maven-release-manager/src: main/java/org/apache/maven/shared/release/phase/ main/java/org/apache/maven/shared/release/util/ test/java/org/apache/maven
Cool. BTW, do you think we could release beta-5 soon (We'll have to
release the manager as well this time).
Thanks,
Stéphane
On 4/24/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: evenisse
Date: Tue Apr 24 01:57:36 2007
New Revision: 531837
URL: http://svn.apache.org/viewvc?view=revrev=531837
Log:
[MRELEASE-137] Fix proposed release tag name when the root project isn't the
parent of sub-modules
Added:
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/util/
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/util/ReleaseUtil.java
(with props)
Modified:
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/CheckPomPhase.java
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/InputVariablesPhase.java
maven/release/trunk/maven-release-manager/src/test/java/org/apache/maven/shared/release/phase/AbstractRewritingReleasePhaseTestCase.java
maven/release/trunk/maven-release-manager/src/test/java/org/apache/maven/shared/release/phase/ScmCommitPhaseTest.java
maven/release/trunk/maven-release-manager/src/test/java/org/apache/maven/shared/release/phase/ScmTagPhaseTest.java
Modified:
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java
URL:
http://svn.apache.org/viewvc/maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java?view=diffrev=531837r1=531836r2=531837
==
---
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java
(original)
+++
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java
Tue Apr 24 01:57:36 2007
@@ -40,6 +40,7 @@
import org.apache.maven.shared.release.scm.ReleaseScmCommandException;
import org.apache.maven.shared.release.scm.ReleaseScmRepositoryException;
import org.apache.maven.shared.release.scm.ScmRepositoryConfigurator;
+import org.apache.maven.shared.release.util.ReleaseUtil;
import org.codehaus.plexus.util.FileUtils;
import org.codehaus.plexus.util.IOUtil;
import org.codehaus.plexus.util.StringUtils;
@@ -262,7 +263,7 @@
}
transformScm( project, rootElement, namespace, releaseDescriptor,
projectId, scmRepository, result,
- (MavenProject) reactorProjects.get( 0 ) );
+ ReleaseUtil.getRootProject( reactorProjects ) );
}
private void rewriteVersion( Element rootElement, Namespace namespace, Map
mappedVersions, String projectId,
Modified:
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/CheckPomPhase.java
URL:
http://svn.apache.org/viewvc/maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/CheckPomPhase.java?view=diffrev=531837r1=531836r2=531837
==
---
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/CheckPomPhase.java
(original)
+++
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/CheckPomPhase.java
Tue Apr 24 01:57:36 2007
@@ -30,6 +30,7 @@
import org.apache.maven.shared.release.config.ReleaseDescriptor;
import org.apache.maven.shared.release.scm.ReleaseScmRepositoryException;
import org.apache.maven.shared.release.scm.ScmRepositoryConfigurator;
+import org.apache.maven.shared.release.util.ReleaseUtil;
import org.codehaus.plexus.util.StringUtils;
import java.util.Iterator;
@@ -56,7 +57,7 @@
// Currently, we don't deal with multiple SCM locations in a
multiproject
if ( StringUtils.isEmpty( releaseDescriptor.getScmSourceUrl() ) )
{
-MavenProject rootProject = (MavenProject) reactorProjects.get( 0 );
+MavenProject rootProject = ReleaseUtil.getRootProject(
reactorProjects );
if ( rootProject != null rootProject.getScm() != null )
{
if ( rootProject.getScm().getDeveloperConnection() != null )
Modified:
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/InputVariablesPhase.java
URL:
http://svn.apache.org/viewvc/maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/InputVariablesPhase.java?view=diffrev=531837r1=531836r2=531837
==
---
Re: How to share data between plugins after 2.0.5 change to extensions handling?
Ok, did some further investigation: What I have is an extension containing a class (C). This class is referenced in the fields of two different Mojos, the fields are not even initialized by Plexus. Looking at the new DefaultExtensionManager, I suppose this cannot work any more, because the newly introduced extension container has its own ClassRealm. When any of the plugins is instantiated by the PluginManager, I get a NoClassDefFoundError for class C. Does this mean that I cannot access classes from extensions in a plugin any more? And that I cannot share data between plugins, except by using JDK and Maven core classes? This would be a major setback for us. We're using maven to build C++ projects and wrote a bunch of plugins, which absolutely need to share data. Regards, Jochen On 2007-04-24 04:04:40 +0200, Brett Porter [EMAIL PROTECTED] said: An extension should still work there, as long as the things are instantiated in the extension itself - sounds like doing it in the plugin is the problem. Is there a reason it must be there, or can you use the plexus component lifecycle to do the instantiation? Other than extensions, you can use plugin dependencies in most cases (though doesn't sound suitable here). You might also be able to use the plugin context to share the values instead of an extension (though not if you are introducing new types, so probably not the case here also). - Brett On 23/04/2007, at 3:43 PM, Jochen Kuhnle wrote: Hi, we use several plugins that need to share data. This as done by creating an extension containing some container classes, and adding an extension to the project's pom. These container classes are instantiated in a plugin using Plexus. However, since 2.0.5, this stopped working, because extensions now have their own container and the Plugin throws a NoClassDefFoundError. Is there new way/workaround for this? Regards, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r531837 - in /maven/release/trunk/maven-release-manager/src: main/java/org/apache/maven/shared/release/phase/ main/java/org/apache/maven/shared/release/util/ test/java/org/apache/maven
Yes, we can. Do you want to do it?
I'll can continue my work on the release projects after the release or in a
branch.
Emmanuel
Stephane Nicoll a écrit :
Cool. BTW, do you think we could release beta-5 soon (We'll have to
release the manager as well this time).
Thanks,
Stéphane
On 4/24/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: evenisse
Date: Tue Apr 24 01:57:36 2007
New Revision: 531837
URL: http://svn.apache.org/viewvc?view=revrev=531837
Log:
[MRELEASE-137] Fix proposed release tag name when the root project
isn't the parent of sub-modules
Added:
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/util/
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/util/ReleaseUtil.java
(with props)
Modified:
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/CheckPomPhase.java
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/InputVariablesPhase.java
maven/release/trunk/maven-release-manager/src/test/java/org/apache/maven/shared/release/phase/AbstractRewritingReleasePhaseTestCase.java
maven/release/trunk/maven-release-manager/src/test/java/org/apache/maven/shared/release/phase/ScmCommitPhaseTest.java
maven/release/trunk/maven-release-manager/src/test/java/org/apache/maven/shared/release/phase/ScmTagPhaseTest.java
Modified:
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java
URL:
http://svn.apache.org/viewvc/maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java?view=diffrev=531837r1=531836r2=531837
==
---
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java
(original)
+++
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java
Tue Apr 24 01:57:36 2007
@@ -40,6 +40,7 @@
import org.apache.maven.shared.release.scm.ReleaseScmCommandException;
import
org.apache.maven.shared.release.scm.ReleaseScmRepositoryException;
import org.apache.maven.shared.release.scm.ScmRepositoryConfigurator;
+import org.apache.maven.shared.release.util.ReleaseUtil;
import org.codehaus.plexus.util.FileUtils;
import org.codehaus.plexus.util.IOUtil;
import org.codehaus.plexus.util.StringUtils;
@@ -262,7 +263,7 @@
}
transformScm( project, rootElement, namespace,
releaseDescriptor, projectId, scmRepository, result,
- (MavenProject) reactorProjects.get( 0 ) );
+ ReleaseUtil.getRootProject( reactorProjects ) );
}
private void rewriteVersion( Element rootElement, Namespace
namespace, Map mappedVersions, String projectId,
Modified:
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/CheckPomPhase.java
URL:
http://svn.apache.org/viewvc/maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/CheckPomPhase.java?view=diffrev=531837r1=531836r2=531837
==
---
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/CheckPomPhase.java
(original)
+++
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/CheckPomPhase.java
Tue Apr 24 01:57:36 2007
@@ -30,6 +30,7 @@
import org.apache.maven.shared.release.config.ReleaseDescriptor;
import
org.apache.maven.shared.release.scm.ReleaseScmRepositoryException;
import org.apache.maven.shared.release.scm.ScmRepositoryConfigurator;
+import org.apache.maven.shared.release.util.ReleaseUtil;
import org.codehaus.plexus.util.StringUtils;
import java.util.Iterator;
@@ -56,7 +57,7 @@
// Currently, we don't deal with multiple SCM locations in a
multiproject
if ( StringUtils.isEmpty( releaseDescriptor.getScmSourceUrl()
) )
{
-MavenProject rootProject = (MavenProject)
reactorProjects.get( 0 );
+MavenProject rootProject = ReleaseUtil.getRootProject(
reactorProjects );
if ( rootProject != null rootProject.getScm() != null )
{
if ( rootProject.getScm().getDeveloperConnection() !=
null )
Modified:
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/InputVariablesPhase.java
URL:
Re: svn commit: r531837 - in /maven/release/trunk/maven-release-manager/src: main/java/org/apache/maven/shared/release/phase/ main/java/org/apache/maven/shared/release/util/ test/java/org/apache/maven
I'd like to release beta-5 indeed. Note sure I will have time till
Thursday though so if anyone wants to take it, go ahead.
Thanks,
Stéphane
On 4/24/07, Emmanuel Venisse [EMAIL PROTECTED] wrote:
Yes, we can. Do you want to do it?
I'll can continue my work on the release projects after the release or in a
branch.
Emmanuel
Stephane Nicoll a écrit :
Cool. BTW, do you think we could release beta-5 soon (We'll have to
release the manager as well this time).
Thanks,
Stéphane
On 4/24/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: evenisse
Date: Tue Apr 24 01:57:36 2007
New Revision: 531837
URL: http://svn.apache.org/viewvc?view=revrev=531837
Log:
[MRELEASE-137] Fix proposed release tag name when the root project
isn't the parent of sub-modules
Added:
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/util/
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/util/ReleaseUtil.java
(with props)
Modified:
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/CheckPomPhase.java
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/InputVariablesPhase.java
maven/release/trunk/maven-release-manager/src/test/java/org/apache/maven/shared/release/phase/AbstractRewritingReleasePhaseTestCase.java
maven/release/trunk/maven-release-manager/src/test/java/org/apache/maven/shared/release/phase/ScmCommitPhaseTest.java
maven/release/trunk/maven-release-manager/src/test/java/org/apache/maven/shared/release/phase/ScmTagPhaseTest.java
Modified:
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java
URL:
http://svn.apache.org/viewvc/maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java?view=diffrev=531837r1=531836r2=531837
==
---
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java
(original)
+++
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java
Tue Apr 24 01:57:36 2007
@@ -40,6 +40,7 @@
import org.apache.maven.shared.release.scm.ReleaseScmCommandException;
import
org.apache.maven.shared.release.scm.ReleaseScmRepositoryException;
import org.apache.maven.shared.release.scm.ScmRepositoryConfigurator;
+import org.apache.maven.shared.release.util.ReleaseUtil;
import org.codehaus.plexus.util.FileUtils;
import org.codehaus.plexus.util.IOUtil;
import org.codehaus.plexus.util.StringUtils;
@@ -262,7 +263,7 @@
}
transformScm( project, rootElement, namespace,
releaseDescriptor, projectId, scmRepository, result,
- (MavenProject) reactorProjects.get( 0 ) );
+ ReleaseUtil.getRootProject( reactorProjects ) );
}
private void rewriteVersion( Element rootElement, Namespace
namespace, Map mappedVersions, String projectId,
Modified:
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/CheckPomPhase.java
URL:
http://svn.apache.org/viewvc/maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/CheckPomPhase.java?view=diffrev=531837r1=531836r2=531837
==
---
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/CheckPomPhase.java
(original)
+++
maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/CheckPomPhase.java
Tue Apr 24 01:57:36 2007
@@ -30,6 +30,7 @@
import org.apache.maven.shared.release.config.ReleaseDescriptor;
import
org.apache.maven.shared.release.scm.ReleaseScmRepositoryException;
import org.apache.maven.shared.release.scm.ScmRepositoryConfigurator;
+import org.apache.maven.shared.release.util.ReleaseUtil;
import org.codehaus.plexus.util.StringUtils;
import java.util.Iterator;
@@ -56,7 +57,7 @@
// Currently, we don't deal with multiple SCM locations in a
multiproject
if ( StringUtils.isEmpty( releaseDescriptor.getScmSourceUrl()
) )
{
-MavenProject rootProject = (MavenProject)
reactorProjects.get( 0 );
+MavenProject rootProject = ReleaseUtil.getRootProject(
reactorProjects );
if ( rootProject != null rootProject.getScm() != null )
{
if ( rootProject.getScm().getDeveloperConnection() !=
null )
Modified:
Re: Note on copying staged repositories
On 24 Apr 07, at 3:28 AM 24 Apr 07, Tomasz Pik wrote: On 4/22/07, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, I just copied the staged repo for the clover plugin over and I used the following: mvn stage:copy -Dsource=http://people.apache.org/~vmassol/maven- staging -Dtarget=scp://people.apache.org/www/people.apache.org/ repo/ m2-ibiblio-rsync-repository -Dversion=2.4 Will it copy all artifacts with version=2.4 from one repository to another? I think that optional groupId/artifactId parameters would be useful, what does others think about it? This is a complete stopgap, and I whipped this off because I was tired of something going wrong during deployment and screwing up my release. This only copies a staged repository and everything in the repository should be copied. You can't stage a release and then only release part of it so I'm not sure why you would want optional groupId/ artifactId parameters. This is not to extract a portion of a repository it copies it in its entirety. This might be the basis of something better but this is very much specific to Apache for http - scp, though it is the only combination that provides some degree of safety. The only thing that will ever provide safe and reliable releases is an application that knows how to accept an intact release and atomically merge it into a repository. Jason. Regards, Tomek - 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: [M1][vote] release plugins : idea 1.7, jalopy 1.5.1, jar 1.8.1, javadoc 1.9, multichanges 1.3, plugin 1.7.1
Both idea and plugin still have one issue scheduled for the releases that you propose (MPIDEA-41 and MPPLUGIN-30), are we going to un-schedule those? -Lukas Arnaud HERITIER wrote: Here is a new list of plugins to release for maven 1.x. -- IDEA 1.7 -- Changes in this version include : New Features: o Autodetect which version control system to use Fixes MPIDEA-43. Download : maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-idea-plugin -Dversion=1.7-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugins/idea/ -- JALOPY 1.5.1 -- Changes in this version include : New Features: o Add a property that controls the source code encoding. Fixes MPJALOPY-12. Thanks to Joachim Bader. Changes: o Upgrade plexus-utils to version 1.0.5 Fixes MAVEN-1803. Download : maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-jalopy-plugin -Dversion=1.5.1-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugins/jalopy/ -- JAR 1.8.1 -- Changes in this version include : Changes: o Change the default repository to http://repo1.maven.org/maven/ for dependencies url in the manifest. Fixes MAVEN-1789. o Update to velocity 1.5. Download : maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-jar-plugin -Dversion=1.8.1-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugins/jar/ -- JAVADOC 1.9 -- Changes : Download : maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-javadoc-plugin -Dversion=1.9-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugins/javadoc/ -- MULTICHANGES 1.3 -- Changes in this version include : New Features: o New page to describe the next releases. o New RSS feed for releases. Changes: o New internal format to store information about releases. o Remove usage of the deprecated dependency-handle tag. Download : maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-multichanges-plugin -Dversion=1.3-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugins/multichanges/ -- PLUGIN 1.7.1 -- Changes in this version include : Fixed bugs: o assert:assertPluginAvailable : Fix error (NoSuchElementException) if the minimum release number has less elements than the version number installed. Changes: o Don't check that a given plugin version is available in the bootstrap. o Update dependencies to unify them between plugins. The following dependencies are updated : commons-jelly-tags-interaction v1.0 to v1.1, jaxen v1.0-FCS-full to 1.1-beta-9. The following dependencies are removed : saxpath. o Upgrade to Xerces 2.8.0. Replace the deprecated xmlParserAPIs by xml-apis 1.3.03. Add the xml-resolver dependency for xerces. Fixes MAVEN-1753. Download : maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-plugin-plugin -Dversion=1.7.1-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugins/plugin/ Normal voting rules, 72 hours, +1/0/-1 My +1 for all Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: NullPointerException during maven-assembly-plugin
Hi all, as promised I changed the POMs to specify version 2.1 of the assembly
plug-in and now things seem to be working on the machines that were not
working before. So this seem to have solved the problem.
It does not explain why we do not have the same behaviour in all computers
as we all use the same settings , as far as I can tell.
In any case there seems to be an issue on maven-assembly-plugin:2.2 when
dealing with test only dependencies. In particular if the dependency only
constructs a test-jar and hence is not a regular jar artefact.
Thanks for your help.
Jose Alberto
Jose Alberto Fernandez wrote:
I will go and specify the versions.
Brian E. Fox wrote:
If you haven't specified the version of the plugin in your pom, then the
version each developer has can be different. See the other threads on
this list for more info.
-Original Message-
From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
Sent: Monday, April 23, 2007 8:36 AM
To: dev@maven.apache.org
Subject: Re: NullPointerException during maven-assembly-plugin
We are quite simple maven users here. We all installed maven 2.0.5, our
project code and POMs are on SVN. We do not build any maven component
from
source and using the same settings. And we all run maven from the same
recipe of commands that we more or less cut and paste like:
mvn install assembly:directory -Dlive
or
mvn -Dproject.test.skip=false install assembly:directory -Dlive
Nothing fancy.
Jason van Zyl-2 wrote:
If you all share a single configuration then they should behave them
same. If some developers have different update policies then some
users will download new versions and some won't. If some have built
from trunk then some will have yet again a different version. The
only way to lock it down is to specify the version. The assembly
plugin was released on the 11th it appears:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-assembly-
plugin/
As per a reproducible example, this is exactly the main issue we
are having,
we cannot even reproduce the error across our environments here.
Will try fixing to 2.1 and will let you know.
Jason van Zyl-2 wrote:
When you specify a version?
We are all
running maven 2.0.5 and we are all building out of the same source
on SVN.
Will let you know...
Jason van Zyl-2 wrote:
Specify the version of the assembly plugin you want to use, and you
probably want 2.1 which was the release before 2.2-beta-1.
You've hit a bug with the new version of the assembly plugin. This is
why it is good to specify the versions of plugins you are using. Your
builds probably updated to the latest version of the assembly plugin.
Please give us a build that is representative of your build so that
we can fix it.
Thanks,
Jason.
Jose Alberto Fernandez wrote:
Hi guys, I posted this on the user list but got no answers. It
is an
urgent matter as it is affecting some of our developers that are
unable to
build the project anymore while others can. Talking about
unreproducible
builds.
We are getting the following stack-trace while executing the
assembly:directory goal.
The artifact com.cellectivity:fattoush-test-shared is declared
on the
module POMs as:
dependency
groupIdcom.cellectivity/groupId
artifactIdfattoush-test-shared/artifactId
scopetest/scope
version[1.0,)/version
typetest-jar/type
/dependency
As it is needed only for testing. Notice that the version is
required by
MVN and if I ask for the specific current version $
{project.version} MVN
complaints it cannot find it. Eventhough it is one of the
artifacts that
is building.
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;
parent
groupIdcom.cellectivity/groupId
artifactIdfattoush/artifactId
version1.5.2-SNAPSHOT/version
/parent
modelVersion4.0.0/modelVersion
artifactIdfattoush-test-shared/artifactId
packagingjar/packaging
nameFattoush Test Shared/name
dependencies
dependency
groupIdcom.cellectivity/groupId
artifactIdfattoush-core/artifactId
/dependency
dependency
groupIdcom.cellectivity/groupId
artifactIdfattoush-module-constant/artifactId
/dependency
/dependencies
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
executions
execution
goals
goaltest-jar/goal
/goals
/execution
/executions
/plugin
/plugins
/build
/project
when we execute mvn install everything works, but if we do mvn
install
assembly:directory it fails during assembly. the stack-trace is as
follows:
[INFO] [assembly:directory]
Re: [M1][vote] release plugins : idea 1.7, jalopy 1.5.1, jar 1.8.1, javadoc 1.9, multichanges 1.3, plugin 1.7.1
Yes, I thought, I did it :-( It's done now. Arnaud On 24/04/07, Lukas Theussl [EMAIL PROTECTED] wrote: Both idea and plugin still have one issue scheduled for the releases that you propose (MPIDEA-41 and MPPLUGIN-30), are we going to un-schedule those? -Lukas Arnaud HERITIER wrote: Here is a new list of plugins to release for maven 1.x. -- IDEA 1.7 -- Changes in this version include : New Features: o Autodetect which version control system to use Fixes MPIDEA-43. Download : maven plugin:download - Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-idea-plugin -Dversion=1.7-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugins/idea/ -- JALOPY 1.5.1 -- Changes in this version include : New Features: o Add a property that controls the source code encoding. Fixes MPJALOPY-12. Thanks to Joachim Bader. Changes: o Upgrade plexus-utils to version 1.0.5 Fixes MAVEN-1803. Download : maven plugin:download - Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-jalopy-plugin -Dversion=1.5.1-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugins/jalopy/ -- JAR 1.8.1 -- Changes in this version include : Changes: o Change the default repository to http://repo1.maven.org/maven/ for dependencies url in the manifest. Fixes MAVEN-1789. o Update to velocity 1.5. Download : maven plugin:download - Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-jar-plugin -Dversion=1.8.1-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugins/jar/ -- JAVADOC 1.9 -- Changes : Download : maven plugin:download - Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-javadoc-plugin -Dversion=1.9-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugins/javadoc/ -- MULTICHANGES 1.3 -- Changes in this version include : New Features: o New page to describe the next releases. o New RSS feed for releases. Changes: o New internal format to store information about releases. o Remove usage of the deprecated dependency-handle tag. Download : maven plugin:download - Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-multichanges-plugin -Dversion=1.3-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugins/multichanges/ -- PLUGIN 1.7.1 -- Changes in this version include : Fixed bugs: o assert:assertPluginAvailable : Fix error (NoSuchElementException) if the minimum release number has less elements than the version number installed. Changes: o Don't check that a given plugin version is available in the bootstrap. o Update dependencies to unify them between plugins. The following dependencies are updated : commons-jelly-tags-interaction v1.0 to v1.1, jaxen v1.0-FCS-full to 1.1-beta-9. The following dependencies are removed : saxpath. o Upgrade to Xerces 2.8.0. Replace the deprecated xmlParserAPIs by xml-apis 1.3.03. Add the xml-resolver dependency for xerces. Fixes MAVEN-1753. Download : maven plugin:download - Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-plugin-plugin -Dversion=1.7.1-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugins/plugin/ Normal voting rules, 72 hours, +1/0/-1 My +1 for all Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M1][vote] release plugins : idea 1.7, jalopy 1.5.1, jar 1.8.1, javadoc 1.9, multichanges 1.3, plugin 1.7.1
+1 -Lukas Arnaud HERITIER wrote: Here is a new list of plugins to release for maven 1.x. -- IDEA 1.7 -- Changes in this version include : New Features: o Autodetect which version control system to use Fixes MPIDEA-43. Download : maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-idea-plugin -Dversion=1.7-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugins/idea/ -- JALOPY 1.5.1 -- Changes in this version include : New Features: o Add a property that controls the source code encoding. Fixes MPJALOPY-12. Thanks to Joachim Bader. Changes: o Upgrade plexus-utils to version 1.0.5 Fixes MAVEN-1803. Download : maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-jalopy-plugin -Dversion=1.5.1-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugins/jalopy/ -- JAR 1.8.1 -- Changes in this version include : Changes: o Change the default repository to http://repo1.maven.org/maven/ for dependencies url in the manifest. Fixes MAVEN-1789. o Update to velocity 1.5. Download : maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-jar-plugin -Dversion=1.8.1-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugins/jar/ -- JAVADOC 1.9 -- Changes : Download : maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-javadoc-plugin -Dversion=1.9-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugins/javadoc/ -- MULTICHANGES 1.3 -- Changes in this version include : New Features: o New page to describe the next releases. o New RSS feed for releases. Changes: o New internal format to store information about releases. o Remove usage of the deprecated dependency-handle tag. Download : maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-multichanges-plugin -Dversion=1.3-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugins/multichanges/ -- PLUGIN 1.7.1 -- Changes in this version include : Fixed bugs: o assert:assertPluginAvailable : Fix error (NoSuchElementException) if the minimum release number has less elements than the version number installed. Changes: o Don't check that a given plugin version is available in the bootstrap. o Update dependencies to unify them between plugins. The following dependencies are updated : commons-jelly-tags-interaction v1.0 to v1.1, jaxen v1.0-FCS-full to 1.1-beta-9. The following dependencies are removed : saxpath. o Upgrade to Xerces 2.8.0. Replace the deprecated xmlParserAPIs by xml-apis 1.3.03. Add the xml-resolver dependency for xerces. Fixes MAVEN-1753. Download : maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-plugin-plugin -Dversion=1.7.1-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugins/plugin/ Normal voting rules, 72 hours, +1/0/-1 My +1 for all Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to share data between plugins after 2.0.5 change to extensions handling?
On 24 Apr 07, at 5:48 AM 24 Apr 07, Jochen Kuhnle wrote: Ok, did some further investigation: What I have is an extension containing a class (C). This class is referenced in the fields of two different Mojos, the fields are not even initialized by Plexus. Looking at the new DefaultExtensionManager, I suppose this cannot work any more, because the newly introduced extension container has its own ClassRealm. When any of the plugins is instantiated by the PluginManager, I get a NoClassDefFoundError for class C. Does this mean that I cannot access classes from extensions in a plugin any more? And that I cannot share data between plugins, except by using JDK and Maven core classes? This would be a major setback for us. We're using maven to build C+ + projects and wrote a bunch of plugins, which absolutely need to share data. Provided they are in the same plugin you can always use the plugin context. We also wrote a huge slew of plugins for C development and we created a facility called the BuildContext for 2.1 because all these other methods were brittle and we wanted a stated way to do it. I'll think about a work around, you can probably use the plexus context. Jason. Regards, Jochen On 2007-04-24 04:04:40 +0200, Brett Porter [EMAIL PROTECTED] said: An extension should still work there, as long as the things are instantiated in the extension itself - sounds like doing it in the plugin is the problem. Is there a reason it must be there, or can you use the plexus component lifecycle to do the instantiation? Other than extensions, you can use plugin dependencies in most cases (though doesn't sound suitable here). You might also be able to use the plugin context to share the values instead of an extension (though not if you are introducing new types, so probably not the case here also). - Brett On 23/04/2007, at 3:43 PM, Jochen Kuhnle wrote: Hi, we use several plugins that need to share data. This as done by creating an extension containing some container classes, and adding an extension to the project's pom. These container classes are instantiated in a plugin using Plexus. However, since 2.0.5, this stopped working, because extensions now have their own container and the Plugin throws a NoClassDefFoundError. Is there new way/workaround for this? Regards, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: NullPointerException during maven-assembly-plugin
Jose,
Maven only updates plugins if you don't have the plugin or if you
specify -U on the command line. This means if you haven't specified a
specific version in your pom, Maven will use the latest version of each
plugin _in your local repository_. That's how different computers can
get out of sync. It's also why you should specify in your pom, because
then you are guaranteed to have a consistent version across your teams
(and reproducible in the future).
--Brian
-Original Message-
From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 24, 2007 8:18 AM
To: dev@maven.apache.org
Subject: RE: NullPointerException during maven-assembly-plugin
Hi all, as promised I changed the POMs to specify version 2.1 of the
assembly plug-in and now things seem to be working on the machines that
were not working before. So this seem to have solved the problem.
It does not explain why we do not have the same behaviour in all
computers as we all use the same settings , as far as I can tell.
In any case there seems to be an issue on maven-assembly-plugin:2.2 when
dealing with test only dependencies. In particular if the dependency
only constructs a test-jar and hence is not a regular jar artefact.
Thanks for your help.
Jose Alberto
Jose Alberto Fernandez wrote:
I will go and specify the versions.
Brian E. Fox wrote:
If you haven't specified the version of the plugin in your pom, then
the version each developer has can be different. See the other
threads on this list for more info.
-Original Message-
From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
Sent: Monday, April 23, 2007 8:36 AM
To: dev@maven.apache.org
Subject: Re: NullPointerException during maven-assembly-plugin
We are quite simple maven users here. We all installed maven 2.0.5,
our project code and POMs are on SVN. We do not build any maven
component from source and using the same settings. And we all run
maven from the same recipe of commands that we more or less cut and
paste like:
mvn install assembly:directory -Dlive
or
mvn -Dproject.test.skip=false install assembly:directory -Dlive
Nothing fancy.
Jason van Zyl-2 wrote:
If you all share a single configuration then they should behave them
same. If some developers have different update policies then some
users will download new versions and some won't. If some have built
from trunk then some will have yet again a different version. The
only way to lock it down is to specify the version. The assembly
plugin was released on the 11th it appears:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-assembl
y-
plugin/
As per a reproducible example, this is exactly the main issue we
are having, we cannot even reproduce the error across our
environments here.
Will try fixing to 2.1 and will let you know.
Jason van Zyl-2 wrote:
When you specify a version?
We are all
running maven 2.0.5 and we are all building out of the same source
on SVN.
Will let you know...
Jason van Zyl-2 wrote:
Specify the version of the assembly plugin you want to use, and you
probably want 2.1 which was the release before 2.2-beta-1.
You've hit a bug with the new version of the assembly plugin. This
is why it is good to specify the versions of plugins you are using.
Your builds probably updated to the latest version of the assembly
plugin.
Please give us a build that is representative of your build so that
we can fix it.
Thanks,
Jason.
Jose Alberto Fernandez wrote:
Hi guys, I posted this on the user list but got no answers. It is
an urgent matter as it is affecting some of our developers that
are unable to build the project anymore while others can. Talking
about unreproducible builds.
We are getting the following stack-trace while executing the
assembly:directory goal.
The artifact com.cellectivity:fattoush-test-shared is declared on
the module POMs as:
dependency
groupIdcom.cellectivity/groupId
artifactIdfattoush-test-shared/artifactId
scopetest/scope
version[1.0,)/version
typetest-jar/type
/dependency
As it is needed only for testing. Notice that the version is
required by MVN and if I ask for the specific current version $
{project.version} MVN complaints it cannot find it. Eventhough it
is one of the artifacts that is building.
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;
parent
groupIdcom.cellectivity/groupId
artifactIdfattoush/artifactId
version1.5.2-SNAPSHOT/version
/parent
modelVersion4.0.0/modelVersion
artifactIdfattoush-test-shared/artifactId
packagingjar/packaging
nameFattoush Test Shared/name
dependencies
dependency
groupIdcom.cellectivity/groupId
RE: NullPointerException during maven-assembly-plugin
Whoa! That is really an unexpected behaviour. Seems to be asking for teams to
get in trouble FAST.
This make the works of a team highly non-deterministic as users can get in
this bad state not even realizing it.
Jose Alberto
Brian E. Fox wrote:
Jose,
Maven only updates plugins if you don't have the plugin or if you
specify -U on the command line. This means if you haven't specified a
specific version in your pom, Maven will use the latest version of each
plugin _in your local repository_. That's how different computers can
get out of sync. It's also why you should specify in your pom, because
then you are guaranteed to have a consistent version across your teams
(and reproducible in the future).
--Brian
-Original Message-
From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 24, 2007 8:18 AM
To: dev@maven.apache.org
Subject: RE: NullPointerException during maven-assembly-plugin
Hi all, as promised I changed the POMs to specify version 2.1 of the
assembly plug-in and now things seem to be working on the machines that
were not working before. So this seem to have solved the problem.
It does not explain why we do not have the same behaviour in all
computers as we all use the same settings , as far as I can tell.
In any case there seems to be an issue on maven-assembly-plugin:2.2 when
dealing with test only dependencies. In particular if the dependency
only constructs a test-jar and hence is not a regular jar artefact.
Thanks for your help.
Jose Alberto
Jose Alberto Fernandez wrote:
I will go and specify the versions.
Brian E. Fox wrote:
If you haven't specified the version of the plugin in your pom, then
the version each developer has can be different. See the other
threads on this list for more info.
-Original Message-
From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
Sent: Monday, April 23, 2007 8:36 AM
To: dev@maven.apache.org
Subject: Re: NullPointerException during maven-assembly-plugin
We are quite simple maven users here. We all installed maven 2.0.5,
our project code and POMs are on SVN. We do not build any maven
component from source and using the same settings. And we all run
maven from the same recipe of commands that we more or less cut and
paste like:
mvn install assembly:directory -Dlive
or
mvn -Dproject.test.skip=false install assembly:directory -Dlive
Nothing fancy.
Jason van Zyl-2 wrote:
If you all share a single configuration then they should behave them
same. If some developers have different update policies then some
users will download new versions and some won't. If some have built
from trunk then some will have yet again a different version. The
only way to lock it down is to specify the version. The assembly
plugin was released on the 11th it appears:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-assembl
y-
plugin/
As per a reproducible example, this is exactly the main issue we
are having, we cannot even reproduce the error across our
environments here.
Will try fixing to 2.1 and will let you know.
Jason van Zyl-2 wrote:
When you specify a version?
We are all
running maven 2.0.5 and we are all building out of the same source
on SVN.
Will let you know...
Jason van Zyl-2 wrote:
Specify the version of the assembly plugin you want to use, and you
probably want 2.1 which was the release before 2.2-beta-1.
You've hit a bug with the new version of the assembly plugin. This
is why it is good to specify the versions of plugins you are using.
Your builds probably updated to the latest version of the assembly
plugin.
Please give us a build that is representative of your build so that
we can fix it.
Thanks,
Jason.
Jose Alberto Fernandez wrote:
Hi guys, I posted this on the user list but got no answers. It is
an urgent matter as it is affecting some of our developers that
are unable to build the project anymore while others can. Talking
about unreproducible builds.
We are getting the following stack-trace while executing the
assembly:directory goal.
The artifact com.cellectivity:fattoush-test-shared is declared on
the module POMs as:
dependency
groupIdcom.cellectivity/groupId
artifactIdfattoush-test-shared/artifactId
scopetest/scope
version[1.0,)/version
typetest-jar/type
/dependency
As it is needed only for testing. Notice that the version is
required by MVN and if I ask for the specific current version $
{project.version} MVN complaints it cannot find it. Eventhough it
is one of the artifacts that is building.
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;
parent
groupIdcom.cellectivity/groupId
Re: How to share data between plugins after 2.0.5 change to extensions handling?
On 2007-04-24 15:25:48 +0200, Jason van Zyl [EMAIL PROTECTED] said: On 24 Apr 07, at 5:48 AM 24 Apr 07, Jochen Kuhnle wrote: Ok, did some further investigation: What I have is an extension containing a class (C). This class is referenced in the fields of two different Mojos, the fields are not even initialized by Plexus. Looking at the new DefaultExtensionManager, I suppose this cannot work any more, because the newly introduced extension container has its own ClassRealm. When any of the plugins is instantiated by the PluginManager, I get a NoClassDefFoundError for class C. Does this mean that I cannot access classes from extensions in a plugin any more? And that I cannot share data between plugins, except by using JDK and Maven core classes? This would be a major setback for us. We're using maven to build C+ + projects and wrote a bunch of plugins, which absolutely need to share data. Provided they are in the same plugin you can always use the plugin context. We also wrote a huge slew of plugins for C development and we created a facility called the BuildContext for 2.1 because all these other methods were brittle and we wanted a stated way to do it. I'll think about a work around, you can probably use the plexus context. How about letting the extension specify where it wants to go, main container or extension container, with the last one as default? If that's ok, I can create a patch. Regards, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
2.0.6: Install fails but compile works. 2.0.5: Install works, compile works:
Weird, With 2.0.6 my multi-module simple J2EE app fails in the compile phase of my servlets child module during an install run of the reactor. However, it all builds if the reactor build is simply ‘compile’. Also, If I cd into the servlets module after the failed install build and just run install locally there, it works. If I drop to 2.0.5 or 2.0.4 it all builds fine. Looking at the attached logs you’ll see that for the 'mvn –X install’ blows up in the servlets module due to the missing EJB dependency. GOOD (mvn-2.0.6 –X compile): [INFO] [compiler:compile] [DEBUG] Using compiler 'javac'. [DEBUG] Source directories: [D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-servlets\src\main\java] [DEBUG] Classpath: [D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-servlets\target\classes D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-engine\target\classes D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-ejb\target\classes D:\APT\local-repository\javax\j2ee\j2ee\1.4\j2ee-1.4.jar] [DEBUG] Output directory: D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-servlets\target\classes [DEBUG] Classpath: [DEBUG] D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-servlets\target\classes [DEBUG] D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-engine\target\classes [DEBUG] D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-ejb\target\classes [DEBUG] D:\APT\local-repository\javax\j2ee\j2ee\1.4\j2ee-1.4.jar [DEBUG] Source roots: [DEBUG] D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-servlets\src\main\java Compiling 8 source files to D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-servlets\target\classes [INFO] [INFO] Building Calculator Webapp [INFO]task-segment: [compile] BAD (mvn-2.0.6 –X install): [INFO] [compiler:compile] [DEBUG] Using compiler 'javac'. [DEBUG] Source directories: [D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-servlets\src\main\java] [DEBUG] Classpath: [D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-servlets\target\classes D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-engine\target\classes D:\APT\local-repository\javax\j2ee\j2ee\1.4\j2ee-1.4.jar] [DEBUG] Output directory: D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-servlets\target\classes [DEBUG] Classpath: [DEBUG] D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-servlets\target\classes [DEBUG] D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-engine\target\classes http://www.nabble.com/file/8071/logs.zip logs.zip [DEBUG] D:\APT\local-repository\javax\j2ee\j2ee\1.4\j2ee-1.4.jar [DEBUG] Source roots: [DEBUG] D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-servlets\src\main\java Compiling 8 source files to D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-servlets\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] How, err, can this be? -- View this message in context: http://www.nabble.com/2.0.6%3A-Install-fails-but-compile-works.-2.0.5%3A-Install-works%2C-compile-works%3A-tf3639635s177.html#a10164169 Sent from the Maven Developers mailing list archive at Nabble.com.
Re: 2.0.6: Install fails but compile works. 2.0.5: Install works, compile works:
Use the user mailing list instead. Seems to be http://jira.codehaus.org/browse/MNG-2921 HTH, Rémy 2007/4/24, jallen [EMAIL PROTECTED]: Weird, With 2.0.6 my multi-module simple J2EE app fails in the compile phase of my servlets child module during an install run of the reactor. However, it all builds if the reactor build is simply 'compile'. Also, If I cd into the servlets module after the failed install build and just run install locally there, it works. If I drop to 2.0.5 or 2.0.4 it all builds fine. Looking at the attached logs you'll see that for the 'mvn –X install' blows up in the servlets module due to the missing EJB dependency. GOOD (mvn-2.0.6 –X compile): [INFO] [compiler:compile] [DEBUG] Using compiler 'javac'. [DEBUG] Source directories: [D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-servlets\src\main\java] [DEBUG] Classpath: [D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-servlets\target\classes D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-engine\target\classes D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-ejb\target\classes D:\APT\local-repository\javax\j2ee\j2ee\1.4\j2ee-1.4.jar] [DEBUG] Output directory: D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-servlets\target\classes [DEBUG] Classpath: [DEBUG] D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-servlets\target\classes [DEBUG] D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-engine\target\classes [DEBUG] D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-ejb\target\classes [DEBUG] D:\APT\local-repository\javax\j2ee\j2ee\1.4\j2ee-1.4.jar [DEBUG] Source roots: [DEBUG] D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-servlets\src\main\java Compiling 8 source files to D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-servlets\target\classes [INFO] [INFO] Building Calculator Webapp [INFO]task-segment: [compile] BAD (mvn-2.0.6 –X install): [INFO] [compiler:compile] [DEBUG] Using compiler 'javac'. [DEBUG] Source directories: [D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-servlets\src\main\java] [DEBUG] Classpath: [D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-servlets\target\classes D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-engine\target\classes D:\APT\local-repository\javax\j2ee\j2ee\1.4\j2ee-1.4.jar] [DEBUG] Output directory: D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-servlets\target\classes [DEBUG] Classpath: [DEBUG] D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-servlets\target\classes [DEBUG] D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-engine\target\classes http://www.nabble.com/file/8071/logs.zip logs.zip [DEBUG] D:\APT\local-repository\javax\j2ee\j2ee\1.4\j2ee-1.4.jar [DEBUG] Source roots: [DEBUG] D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-servlets\src\main\java Compiling 8 source files to D:\APT\projects\apt-examples\calculator\calculator-root\..\calculator-servlets\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] How, err, can this be? -- View this message in context: http://www.nabble.com/2.0.6%3A-Install-fails-but-compile-works.-2.0.5%3A-Install-works%2C-compile-works%3A-tf3639635s177.html#a10164169 Sent from the Maven Developers mailing list archive at Nabble.com.
RE: Remove auto-resolution of plugin versions from Maven 2.1
Brian E. Fox wrote: Everyone keeps referring to bundles that are known to work together. Come someone produce an example of plugins that are incompatible with each other? I haven't seen this and I'm not even sure it's possible given that plugins can't communicate or even know about each other. The war pluing depends on the jar plugin. A bug in the jar plugin could cause the war plugin to fail. The cobertura-maven-plugin v2.1 depends on cobertura v1.8. But cobertura v1.8 has a bug. cobertura-maven-plugin v2.0 depends on cobertura v1.7, but it has a different bug of it's own. Thus neither version combination is a known good set. -- View this message in context: http://www.nabble.com/Remove-auto-resolution-of-plugin-versions-from-Maven-2.1-tf3560617s177.html#a10164293 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Remove auto-resolution of plugin versions from Maven 2.1
Jose Alberto Fernandez wrote: I thought one of the main arguments in all this discussion is to make things simple and easy for users. At least those were the comments against forcing everyone to explicitly set versions for everything. The bundle will free every single user of having to go finding out what version of what to use. And it could allow for auto upgrading in a more consistent manner, if the user so chooses. Indeed, I'd rather version bump the bundle than version bump each individual plugin. If we are going to reccomend that all versions are set in the pom, then we are going to need an easy way to version bump. Perhaps we need something like mvn help:effective-pom does now, or pehaps a way of listing all newer available plugins. -- View this message in context: http://www.nabble.com/Remove-auto-resolution-of-plugin-versions-from-Maven-2.1-tf3560617s177.html#a10164518 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: NullPointerException during maven-assembly-plugin
That's why it's a best-practice to specify in your pom what version to use. See the other threads on this list regarding the topic. We are discussing making this a requirement in 2.1, but haven't settled on a single strategy yet. -Original Message- From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 24, 2007 10:27 AM To: dev@maven.apache.org Subject: RE: NullPointerException during maven-assembly-plugin Whoa! That is really an unexpected behaviour. Seems to be asking for teams to get in trouble FAST. This make the works of a team highly non-deterministic as users can get in this bad state not even realizing it. Jose Alberto Brian E. Fox wrote: Jose, Maven only updates plugins if you don't have the plugin or if you specify -U on the command line. This means if you haven't specified a specific version in your pom, Maven will use the latest version of each plugin _in your local repository_. That's how different computers can get out of sync. It's also why you should specify in your pom, because then you are guaranteed to have a consistent version across your teams (and reproducible in the future). --Brian -Original Message- From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 24, 2007 8:18 AM To: dev@maven.apache.org Subject: RE: NullPointerException during maven-assembly-plugin Hi all, as promised I changed the POMs to specify version 2.1 of the assembly plug-in and now things seem to be working on the machines that were not working before. So this seem to have solved the problem. It does not explain why we do not have the same behaviour in all computers as we all use the same settings , as far as I can tell. In any case there seems to be an issue on maven-assembly-plugin:2.2 when dealing with test only dependencies. In particular if the dependency only constructs a test-jar and hence is not a regular jar artefact. Thanks for your help. Jose Alberto Jose Alberto Fernandez wrote: I will go and specify the versions. Brian E. Fox wrote: If you haven't specified the version of the plugin in your pom, then the version each developer has can be different. See the other threads on this list for more info. -Original Message- From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] Sent: Monday, April 23, 2007 8:36 AM To: dev@maven.apache.org Subject: Re: NullPointerException during maven-assembly-plugin We are quite simple maven users here. We all installed maven 2.0.5, our project code and POMs are on SVN. We do not build any maven component from source and using the same settings. And we all run maven from the same recipe of commands that we more or less cut and paste like: mvn install assembly:directory -Dlive or mvn -Dproject.test.skip=false install assembly:directory -Dlive Nothing fancy. Jason van Zyl-2 wrote: If you all share a single configuration then they should behave them same. If some developers have different update policies then some users will download new versions and some won't. If some have built from trunk then some will have yet again a different version. The only way to lock it down is to specify the version. The assembly plugin was released on the 11th it appears: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-assemb l y- plugin/ As per a reproducible example, this is exactly the main issue we are having, we cannot even reproduce the error across our environments here. Will try fixing to 2.1 and will let you know. Jason van Zyl-2 wrote: When you specify a version? We are all running maven 2.0.5 and we are all building out of the same source on SVN. Will let you know... Jason van Zyl-2 wrote: Specify the version of the assembly plugin you want to use, and you probably want 2.1 which was the release before 2.2-beta-1. You've hit a bug with the new version of the assembly plugin. This is why it is good to specify the versions of plugins you are using. Your builds probably updated to the latest version of the assembly plugin. Please give us a build that is representative of your build so that we can fix it. Thanks, Jason. Jose Alberto Fernandez wrote: Hi guys, I posted this on the user list but got no answers. It is an urgent matter as it is affecting some of our developers that are unable to build the project anymore while others can. Talking about unreproducible builds. We are getting the following stack-trace while executing the assembly:directory goal. The artifact com.cellectivity:fattoush-test-shared is declared on the module POMs as: dependency groupIdcom.cellectivity/groupId artifactIdfattoush-test-shared/artifactId scopetest/scope version[1.0,)/version typetest-jar/type /dependency As it is needed only for testing. Notice that
Re: Note on copying staged repositories
Jason van Zyl wrote: On 23 Apr 07, at 5:40 PM 23 Apr 07, Dennis Lundberg wrote: I thought that I'd give this plugin a workout, but I ran into a couple of things that has prevented me from testing it completely. 1. The tests seem to require that there's an scp-server available on localhost. That's not the case on Windows, so no joy running the tests for me. Sorry, standard fair on OS/X and Linux. You get to install Cywin, as there aren't any free Java SSH servers. Naah, I'll just use maven.test.skip=true. We might want to document this later on, in case somebody wants to build it themselves. 2. After installing it, skipping the tests, I am not able to authenticate properly to the target repo. How do I supply a different username to the plugin? Let me see if I can make it easy. All the information is in the settings.xml files and I know where you want to deploy it as that's in the POM. I'll just try to make it use the info that's normally used for deployments. It's the way it should work anyway. I can deploy it if you point me at it for now if you like. No hurry on my part. It's the release of maven-stylus-skin that is going out. But that doesn't really need to happen until the next doxia release goes out. Since it's such a small release I thought it would be a good candidate to test the stage-plugin with. I'll hold that release for a while, if you think that you have time to look into this issue in the near future. Jason. I tried using -Dusername=dennisl but no luck. I get this error message: Embedded error: Cannot connect. Reason: Auth fail I guess this is a wagon thing. Jason van Zyl wrote: Hi, I just copied the staged repo for the clover plugin over and I used the following: mvn stage:copy -Dsource=http://people.apache.org/~vmassol/maven-staging; -Dtarget=scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository -Dversion=2.4 Just for the folks who are going to try and copy staged repositories in the next little while. I'll get it to figure out the version automatically but this seems to be working well. Is fairly atomic, it simply copies only merging the metadata, it doesn't do a redeploy. Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - 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] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Note on copying staged repositories
Jason van Zyl wrote: On 24 Apr 07, at 3:28 AM 24 Apr 07, Tomasz Pik wrote: On 4/22/07, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, I just copied the staged repo for the clover plugin over and I used the following: mvn stage:copy -Dsource=http://people.apache.org/~vmassol/maven- staging -Dtarget=scp://people.apache.org/www/people.apache.org/repo/ m2-ibiblio-rsync-repository -Dversion=2.4 Will it copy all artifacts with version=2.4 from one repository to another? I think that optional groupId/artifactId parameters would be useful, what does others think about it? This is a complete stopgap, and I whipped this off because I was tired of something going wrong during deployment and screwing up my release. This only copies a staged repository and everything in the repository should be copied. You can't stage a release and then only release part of it so I'm not sure why you would want optional groupId/artifactId parameters. This is not to extract a portion of a repository it copies it in its entirety. I can see where this would be a useful feature. If you are in the process of releasing several different artifacts it would be handy to be able to select which artifact to release by supplying its groupId/artifactId. This would do away with changing deploy.altRepository in settings.xml for every release. This might be the basis of something better but this is very much specific to Apache for http - scp, though it is the only combination that provides some degree of safety. The only thing that will ever provide safe and reliable releases is an application that knows how to accept an intact release and atomically merge it into a repository. Jason. Regards, Tomek - 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] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Archetypes - Question about languages and file extensions
Hi In order to implement the file resolution during the automatic creation of an archetype, i need to group the files potential files. I group the files by: - files located in directories with tree representation of package (like in src/main/java/org/apache/... where java is one of the language used) - files located in directories without tree representation (files excluded from the first pass) I then subgroup those group by: - files which are binary copied (based on file extension) - text files excluded from the binary search (files which will be velocity templates in the archetype). My questions are: - apart from java, groovy, aspectj, csharp, what are the common directory names where files with packaging ability are located? - which files extension represent text files and which represent binary files? how to store such a huge list? Thanks in advance for any answer. Regards, Raphaël
Re: Archetypes - Question about languages and file extensions
- which files extension represent text files and which represent binary files? how to store such a huge list? The mime.types file packaged by Apache webserver might prove useful for file extension/type analysis. Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Archetypes - Question about languages and file extensions
2007/4/24, Wayne Fay [EMAIL PROTECTED]: - which files extension represent text files and which represent binary files? how to store such a huge list? The mime.types file packaged by Apache webserver might prove useful for file extension/type analysis. Is there a jar file including such a list ? Raphaël Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Archetypes - Question about languages and file extensions
I found a few artifacts with the word mime in them but not sure if any of these will be helpful... http://www.mvnrepository.com/search.html?query=mime Wayne On 4/24/07, Raphaël Piéroni [EMAIL PROTECTED] wrote: 2007/4/24, Wayne Fay [EMAIL PROTECTED]: - which files extension represent text files and which represent binary files? how to store such a huge list? The mime.types file packaged by Apache webserver might prove useful for file extension/type analysis. Is there a jar file including such a list ? Raphaël Wayne - 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: Dep Analysis for plexus-utils
On 22 Apr 07, at 8:50 PM 22 Apr 07, Brian E. Fox wrote: Sure. I started to fix them before but got through 4-5 before I got sidetracked. I think I need to tweak the analyze plugin to output the xml you should use so it's easy to copy and paste into the pom. Then it's a piece of cake to update the poms. I'm happy with a rough list that we could post somewhere as I would like to systematically work through the list and release all of those projects even if it's just correcting the dependencies. This is required for a 2.1-alpha because there are many, many things broken and would like to get them all out ASAP. If you've already got something rigged I'll take it. Jason. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Sunday, April 22, 2007 4:08 PM To: Maven Developers List Subject: Dep Analysis for plexus-utils Hey Brian, Do you think you could publish a list of all the Maven projects/ plugins that need to be fixed insofar as needing to state a direct dependency on plexus-utils? I'm just going back to 2.1 and I'm using a shaded JAR which hides p-u so I need to hunt everything down and release everything that's awry. Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: undeclared dependencies in plugins
Brian E. Fox wrote: As part of the checking for 2.0.6, I ran dependency:analyze against the plugins. We found that almost all plugins have undeclared dependencies. Those with undeclared dependencies on plexus-utils will require a workaround in maven itself to avoid hosing people. (Jason is going to send a separate email) Please run maven-dependency-plugin 2.0-alpha-4-SNAPSHOT :analyze against a plugin if you work on it so you can update the pom appropriately. snip Below is the output for maven-idea-plugin. Should I do something about the Used undeclared dependencies? [INFO] [dependency:analyze] [INFO] Used declared dependencies: [INFO]org.apache.maven:maven-plugin-api:jar:2.0.1:compile [INFO]org.apache.maven:maven-project:jar:2.0.1:compile [INFO]org.apache.maven:maven-artifact-manager:jar:2.0.1:compile [INFO]org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:compile [INFO]org.apache.maven:maven-artifact:jar:2.0.1:compile [INFO]org.codehaus.plexus:plexus-utils:jar:1.1:compile [INFO]dom4j:dom4j:jar:1.6.1:compile [INFO]org.apache.maven:maven-model:jar:2.0.1:compile [INFO] org.apache.maven.shared:maven-plugin-testing-harness:jar:1.0-beta-1:test [INFO] Used undeclared dependencies: [WARNING]junit:junit:jar:3.8.1:compile [WARNING] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:compile [INFO] Unused declared dependencies: [INFO]None [WARNING] Potential problems discovered. [INFO] Found Resolved Dependency / DependencyManagement mismatches: [INFO]Nothing in DepMgt. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release maven ant plugin 2.0
I will have a look this week. Thanks, Vincent 2007/4/20, Carlos Sanchez [EMAIL PROTECTED]: Vincent is the most active with the plugin, so i didn't want to apply it if he already didn't I was waiting to hear his opinion in this thread On 4/14/07, Brian E. Fox [EMAIL PROTECTED] wrote: MANT-22 has a patch and it seems pretty trivial. Why not apply it? I don't use mant much so maybe I'm missing something obvious. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Saturday, April 14, 2007 11:48 AM To: Maven Developers List Subject: [VOTE] Release maven ant plugin 2.0 I'd like to release the maven ant plugin for Maven 2. Last release was a year ago Specially addressed to Vincent Siveton, as he has been the one working more on it. https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-ant-plugin rev# 528823 deployed as 2.0-SNAPSHOT Roadmap http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11124 fixfor=12933 I'd push MANT-22 for the next release -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - 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] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - 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] maven-model 3.0.2 for maven 1.1
The vote passed with 5 binding votes (Jason, Stephane, Emmanuel, Lukas and myself) and 1 non binding (Jeff). I launch the release. Arnaud On 23/04/07, Lukas Theussl [EMAIL PROTECTED] wrote: +1 Thanks! Let's get ready for m11 now... -Lukas Arnaud HERITIER wrote: Hi team, We finalized the new version of maven-model 3.0.2 for maven 1.1. You can find the new web site in [1] and the model documentation [2] will replace the one actually in the maven 1 site [3]. I deployed a Snapshot of the library. In this new version, the pom can be read/write with xpp3, dom4j and stax. In maven 1.1 RC1 we now use the stax reader/writer which supports xml entities to reintroduce the compatibility with old maven 1.0.X projects. (Thanks a lot for all the modello team and specially to Brett.) The vote is open for 72h. My +1 Arnaud [1] http://people.apache.org/~aheritier/staging-sites/maven-model/3.0.2-SNAPSHOT/ [2] http://people.apache.org/~aheritier/staging-sites/maven-model/3.0.2-SNAPSHOT/maven.html [3] http://maven.apache.org/maven-1.x/reference/project-descriptor.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Getting a configuration parameter into the ReleaseDescriptor
Hello, Can someone tell me why is it necessary to generate sources (using generate-sources) ? My initial thought was that the generated file(s) were based on annotations in other files. But in the case of ReleaseDescriptor, I don't see that hapenning. I have enhanced the maven-release-manager/maven-release-plugin to create a version.txt file in the deployed artifact so that the application can display that file indicating what version is in production. Now I'd like to make this a bit more configuranble so that the user can specify what that file should be called and where should it live. In order to read that info from the pom.xml, I would add a parameter to the AbstractReleaseMojo(I think). But from there I lose the thread... The AbstractReleaseMojo has a method called createReleaseDescriptor() where it places all the parameters in the descriptor.. However, how do I get the appropriate getter/setter on the ReleaseDescriptor? In other words, where is the annotation for that? Once it get's into the ReleaseDescriptor, I can take it from there... Thanks in advance, Pankaj -- View this message in context: http://www.nabble.com/Getting-a-configuration-parameter-into-the-ReleaseDescriptor-tf3641666s177.html#a10170350 Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: undeclared dependencies in plugins
On 24 Apr 07, at 5:29 PM 24 Apr 07, Dennis Lundberg wrote: Brian E. Fox wrote: As part of the checking for 2.0.6, I ran dependency:analyze against the plugins. We found that almost all plugins have undeclared dependencies. Those with undeclared dependencies on plexus-utils will require a workaround in maven itself to avoid hosing people. (Jason is going to send a separate email) Please run maven-dependency-plugin 2.0-alpha-4-SNAPSHOT :analyze against a plugin if you work on it so you can update the pom appropriately. snip Below is the output for maven-idea-plugin. Should I do something about the Used undeclared dependencies? That doesn't look right. Looking at the POM most of those are there. Plexus utils is even there in the POM. [INFO] [dependency:analyze] [INFO] Used declared dependencies: [INFO]org.apache.maven:maven-plugin-api:jar:2.0.1:compile [INFO]org.apache.maven:maven-project:jar:2.0.1:compile [INFO]org.apache.maven:maven-artifact-manager:jar:2.0.1:compile [INFO]org.apache.maven.wagon:wagon-provider-api:jar:1.0- alpha-5:compile [INFO]org.apache.maven:maven-artifact:jar:2.0.1:compile [INFO]org.codehaus.plexus:plexus-utils:jar:1.1:compile [INFO]dom4j:dom4j:jar:1.6.1:compile [INFO]org.apache.maven:maven-model:jar:2.0.1:compile [INFO] org.apache.maven.shared:maven-plugin-testing-harness:jar:1.0- beta-1:test [INFO] Used undeclared dependencies: [WARNING]junit:junit:jar:3.8.1:compile [WARNING] org.codehaus.plexus:plexus-container-default:jar:1.0- alpha-9:compile [INFO] Unused declared dependencies: [INFO]None [WARNING] Potential problems discovered. [INFO] Found Resolved Dependency / DependencyManagement mismatches: [INFO]Nothing in DepMgt. -- Dennis Lundberg - 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: undeclared dependencies in plugins
I think you're misreading the output. The first thing it prints are the used,declared dependencies. I should probably turn that off by default. Junit and the container are the only ones missing. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 24, 2007 6:02 PM To: Maven Developers List Subject: Re: undeclared dependencies in plugins On 24 Apr 07, at 5:29 PM 24 Apr 07, Dennis Lundberg wrote: Brian E. Fox wrote: As part of the checking for 2.0.6, I ran dependency:analyze against the plugins. We found that almost all plugins have undeclared dependencies. Those with undeclared dependencies on plexus-utils will require a workaround in maven itself to avoid hosing people. (Jason is going to send a separate email) Please run maven-dependency-plugin 2.0-alpha-4-SNAPSHOT :analyze against a plugin if you work on it so you can update the pom appropriately. snip Below is the output for maven-idea-plugin. Should I do something about the Used undeclared dependencies? That doesn't look right. Looking at the POM most of those are there. Plexus utils is even there in the POM. [INFO] [dependency:analyze] [INFO] Used declared dependencies: [INFO]org.apache.maven:maven-plugin-api:jar:2.0.1:compile [INFO]org.apache.maven:maven-project:jar:2.0.1:compile [INFO]org.apache.maven:maven-artifact-manager:jar:2.0.1:compile [INFO]org.apache.maven.wagon:wagon-provider-api:jar:1.0- alpha-5:compile [INFO]org.apache.maven:maven-artifact:jar:2.0.1:compile [INFO]org.codehaus.plexus:plexus-utils:jar:1.1:compile [INFO]dom4j:dom4j:jar:1.6.1:compile [INFO]org.apache.maven:maven-model:jar:2.0.1:compile [INFO] org.apache.maven.shared:maven-plugin-testing-harness:jar:1.0- beta-1:test [INFO] Used undeclared dependencies: [WARNING]junit:junit:jar:3.8.1:compile [WARNING] org.codehaus.plexus:plexus-container-default:jar:1.0- alpha-9:compile [INFO] Unused declared dependencies: [INFO]None [WARNING] Potential problems discovered. [INFO] Found Resolved Dependency / DependencyManagement mismatches: [INFO]Nothing in DepMgt. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin version removal proposal
On 22/04/2007, at 4:58 PM, Jason van Zyl wrote: - require the version in plugin definitions in the POM from modelVersion 4.1.0+ (for 4.0.0 modelVersions, continue to allow the RELEASE as the version). +1 - externalise all packagings/lifecycle definitions (with the exception of 'pom', perhaps) What does that mean exactly? Take them out of core's components.xml and into the plugins. - make the user declare the plugin that contains the packaging they want, including it's version (a plugin may contain more than one packaging) - make the packaging plugin declare the versions of the other lifecycle plugins it uses (in the lifecycle itself, not the plugins pom) - same for any overlaid lifecycles in plugins - declared plugins and pluginManagement in the POM always wins over the lifecycle. - running from the CLI behaves as it does now Now, while this could mean the jar packaging is in maven-jar- plugin, etc. I would suggest that's too many plugins to change when the compile plugin changes. So instead we could have the maven-java-packages-plugin, v1.0 that has jar, war, ear, ejb, compile, surefire, etc. all pinned to a known, tested set. If a user needs one of them newer: plugin management. I think that's that's just way to coupled. I think providing the latest releases that are available in an easy way when people get started is the key but then the versions used must be easily visible somewhere so they can be changed because the second some one finds a bug and needs to change a version of something they will need an easy way to change this. Having to then build the maven-java-packages with altered versions would be not fun. I was suggesting that using pluginManagement for an individual plugin would still work. Would this resolve the objection? I think publishing the laundry list of a usable set and making a simple plugin to have that easily consumable is a great idea. Plugins depending on another artifact for version binding I think is bad. I think we need to publish releases, make them easy to find an be absorbed which leaves us in the situation of providing up-to- date information coupled with getting that information easily to users and then the user is in charge of version selection. Seems like another good way. So a plugin takes a descriptor with a set of artifacts (with versions) and pulls them all into the build together (unless they already exist in plugin management which always wins)? I agree this is a better refinement of the same idea since it's easier to construct. It might be best to take it to the next level and build this in to Maven rather than it being a plugin for consuming it (for ease of use). But that can also be a separate next step. We should note that this does not tightly couple plugins in the same way it has before which was problematic in m1. If you bind that packaging set into the version resolution you are. That version set must be made available as a means for people to manage their own versions easily. We can update that often, and let people know, make tools, but ultimately you have to specify literally what you want so that when bad things happen there is only _one_ place to look to see how the version is resolved and that's the POM. Not some version set buried in a JAR file file somewhere, but the POMs used in your build. Period. We are still programming to interfaces - but the metadata wires up the right versions of things. -1 That will need to severe maintenance problems. The POM becomes the authority. How we help people get the right versions can range from simple to complex, but ultimately any tooling done ultimately manifests itself as versions that land in the users POM. I'm not really sure we understand each other here, since I am also advocating the POM being the final authority, and we are both proposing at least one level of indirection (one in plugin metadata, one in a 'laundry list'). I think it's the same solution. So the difference may seem slight where the list is in a JAR, versus some resource in the repository but it means people can look at it with a web browser, cut and paste (eek) if they like, but most likely use a plugin to incorporate that into their build. Ok, that makes sense. I agree having it easier to access is better. So, it seems you are in general agreement with the proposal, substituting the built plugin packs with a plugin that consumes metadata and incorporates those versions into the build? Diverging off this topic into the more general stuff... But the vast majority of our users are in a group situation and will have a parent POM with this information. If the pluginManagement section is more verbose then we can come up with something else. Having to bump the parent POM all the time is an equal maintenance nightmare that needs to be resolved. The bottom line is that I'm for
Re: Archetypes - Question about languages and file extensions
On 24/04/2007, at 9:29 PM, Raphaël Piéroni wrote: My questions are: - apart from java, groovy, aspectj, csharp, what are the common directory names where files with packaging ability are located? Wouldn't this be anything under main/ or test/ ? - which files extension represent text files and which represent binary files? how to store such a huge list? Is it better to instead look at the content of the file to determine this? This seems like a good general purpose IO utility if it doesn't already exist in another library. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Conflict resolvers
Cool, I'll take a look - since there seems to be a lot of talk about maven-artifact right now, maybe this could be added to a list of things to discuss while folks are f2f for the upcoming conferences. I'll send a separate mail. On 23/04/2007, at 7:01 PM, Mark Hobson wrote: Hi there, I've had an initial stab at implementing ConflictResolvers and attached a patch to MNG-612. If people wouldn't mind taking a peek, I'd appreciate some feedback on the following: 1) ConflictResolver API - is the negative/positive/zero return type sufficient, or would a boolean return type with an exception for the unresolvable state be more appropriate? 2) ArtifactCollector signature change - is this okay or will it break lots of code? If we are to maintain the original signatures, then should we really obtain a default ConflictResolver implementation via plexus? 3) New ArtifactResolver overloaded method okay? The original method implementations in DefaultArtifactResolver assume plexus default - is this okay or should it be passed in? 4) DefaultArtifactCollectorTest - many tests assume nearest conflict resolver, should these be refactored out? 5) ResolutionListener.OMIT_FOR_NEARER - should this be refactored to OMIT_FOR_CONFLICT? 6) Configuration - how do we specify a different conflict resolver implementation for the build? This does overlap with MNG-2771, but do we want a friendlier POM configuration based on role hints? e.g. buildconflictResolvernewest/conflictResolver/build. Does specifying an alternative conflict resolver in Maven's components.xml potentially cause problems outside of the build and within Maven itself? 7) Conflict resolver implementation names - newest/oldest or highest/lowest? 8) Any more conflict resolver implementations required? I've got some time allocated to work on this, so any thoughts are welcome and hopefully we can get this much-needed functionality into Maven. Cheers, Mark - 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]
ApacheCon EU
Hi, I saw that Dennis, Jason, Kenney, Eric, Martin, Robert, and Arnaud B will all be at AC EU next week - is anyone else attending ApacheCon? I think it would be good to get some time in front of a white board to go through a couple of the big issues while we have the opportunity for face time and to hack some things together. It sounds like the same opportunity will present itself at JavaOne too. Of course, we can discuss some in real time with people on IRC and bring any output back to the list so everyone gets a chance to participate. What day/time would suit people? Maybe the following are appropriate for AC: - anything more we can do for releases (polish up the staging stuff, incorporate RAT, ...?) - plugin integration testing and unit testing - roadmap discussion / highlighting other issues Any other thoughts? Interest from the folks attending in anything in particular? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Archetype] branching question
Sorry, I don't quite understand this? Are you saying it's just incompatible with what's in there already, or this now diverges from compatibility with the current version? I think it was the former, in which case you shouldn't need to do anything - you can use the revision number to go back to, but since it's not in use yet it's ok to make those breaking changes. Hope I got that right. - Brett On 17/04/2007, at 8:51 PM, Raphaël Piéroni wrote: Hi, With the archetypeng stuff, i think i have reached a point in which i need advice. For what i can see, the current code seems useable. I am currently refactoring the proposed descriptor. This change will be incompatible with the current proposition, which mimics and enchance the actual behaviour. I think i need to reprensent this changing in the SCM, but i can't figure the right way: a) create a branch in the mojo repository (but the current code is in the sandbox) b) tag by hand a 0.1-alpha-1 version (with lazy concensus vote) and stay in the sandbox c) use the release plugin to release as version (idem vote) and stay in the sandbox I dislike c, and have a light preference for b. Thanks in advance for any answer. Regards, Raphaël - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Archetypes] plugin proposition
Well, it sounds like you've got some more working happening now. What I'd suggest is that you get it to the point where you think it is ready for an alpha release - that would be a good point to replace the existing code. - Brett On 13/04/2007, at 7:57 PM, Raphaël Piéroni wrote: Hi, feel free to steal the code from mojo. but please, let me be informed as i could still contribute with patches. Raphaël 2007/4/9, Brett Porter [EMAIL PROTECTED]: I think we should continue to use ARCHETYPE and start planning towards a 1.0 with the new code base. The current JIRA will need a clean up to see what issues are still relevant in the new code base, of course. - Brett On 09/04/2007, at 5:02 AM, Franz Allan Valencia See wrote: Curious,.. Where is the jira issue(s) for this? ..Can't seem to find them :-) Thanks, Franz On 4/1/07, Milos Kleint [EMAIL PROTECTED] wrote: On 4/1/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 1 Apr 07, at 6:49 AM 1 Apr 07, Milos Kleint wrote: exactly this is a showstopper for me in the current archetype when I attempted to create an archetype for netbeans module development. I need to place Bundle.properties and layer.xml file in resources into the proper package. That's fine all we need is the right examples to work against. But in your case do you just need the final distributable to have resources in the same package as the classes or do you actually need to archetype to mix resources with the sources? having the resources in the right place at runtime is fine. I know about targetPath element in resource definition, however I'd rather stay away from that. Often people will need to use both the META-INF/services path and the package named path like: org/codehaus/mevenide/netbeans/xxx.xxx and it becomes non-obvious where to put the services when you define the targetPath. On top of that localization bundles come here as well, these are to be placed in package named path as well, so there's one Bundle.properties for for eac package in the module + some gifs etc. And the form editor in the IDE is not capable of handling the shortened paths. Also the module development file templates can have problems with it. Milos Jason. Milos - 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] - 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: [M1][vote] release plugins : idea 1.7, jalopy 1.5.1, jar 1.8.1, javadoc 1.9, multichanges 1.3, plugin 1.7.1
+1 -Original Message- From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] Sent: Monday, April 23, 2007 10:49 AM To: Maven Developers List Subject: [M1][vote] release plugins : idea 1.7, jalopy 1.5.1, jar 1.8.1, javadoc 1.9, multichanges 1.3, plugin 1.7.1 Here is a new list of plugins to release for maven 1.x. -- IDEA 1.7 -- Changes in this version include : New Features: o Autodetect which version control system to use Fixes MPIDEA-43. Download : maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-idea-plugin -Dversion=1.7-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugi ns/idea/ -- JALOPY 1.5.1 -- Changes in this version include : New Features: o Add a property that controls the source code encoding. Fixes MPJALOPY-12. Thanks to Joachim Bader. Changes: o Upgrade plexus-utils to version 1.0.5 Fixes MAVEN-1803. Download : maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-jalopy-plugin -Dversion=1.5.1-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugi ns/jalopy/ -- JAR 1.8.1 -- Changes in this version include : Changes: o Change the default repository to http://repo1.maven.org/maven/ for dependencies url in the manifest. Fixes MAVEN-1789. o Update to velocity 1.5. Download : maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-jar-plugin -Dversion=1.8.1-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugi ns/jar/ -- JAVADOC 1.9 -- Changes : Download : maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-javadoc-plugin -Dversion=1.9-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugi ns/javadoc/ -- MULTICHANGES 1.3 -- Changes in this version include : New Features: o New page to describe the next releases. o New RSS feed for releases. Changes: o New internal format to store information about releases. o Remove usage of the deprecated dependency-handle tag. Download : maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-multichanges-plugin -Dversion=1.3-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugi ns/multichanges/ -- PLUGIN 1.7.1 -- Changes in this version include : Fixed bugs: o assert:assertPluginAvailable : Fix error (NoSuchElementException) if the minimum release number has less elements than the version number installed. Changes: o Don't check that a given plugin version is available in the bootstrap. o Update dependencies to unify them between plugins. The following dependencies are updated : commons-jelly-tags-interaction v1.0 to v1.1, jaxen v1.0-FCS-full to 1.1-beta-9. The following dependencies are removed : saxpath. o Upgrade to Xerces 2.8.0. Replace the deprecated xmlParserAPIs by xml-apis 1.3.03. Add the xml-resolver dependency for xerces. Fixes MAVEN-1753. Download : maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-plugin-plugin -Dversion=1.7.1-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugi ns/plugin/ Normal voting rules, 72 hours, +1/0/-1 My +1 for all Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
