Re: maven-dependency-plugin unpacking aar format?
I totally agree that it makes sense for the dependency plugin to unpack the
AAR just like all other archives.
I just don't understand why you need the MDP to do so.
On Tue, Jul 22, 2014 at 10:58 PM, David Hoffer dhoff...@gmail.com wrote:
No that was just an example so I could create a sample project. Don't read
too much into this. They are just AAR dependencies (in my case they come
from our build not public). The maven dependency plugin should handle
these no different than it handles jars/etc.
On Mon, Jul 21, 2014 at 11:32 PM, William Ferguson
william.fergu...@xandar.com.au wrote:
So an Android library is packaging WSDL inside itself and is expecting
you
to use it at build time?
On Tue, Jul 22, 2014 at 8:53 AM, Martin Gainty mgai...@hotmail.com
wrote:
Here is an aar straight from Axis version example:
//layout of version.aar:
created: META-INF/
inflated: META-INF/MANIFEST.MF
created: sample/
created: sample/axisversion/
inflated: sample/axisversion/Version.class
inflated: META-INF/services.xml
//org.apache.axis2.deployment.DeploymentEngine axis code used to
populateService with .aar contents:
protected ArrayList populateService(AxisServiceGroup serviceGroup,
URL servicesURL,
String serviceName) throws
DeploymentException {
try {
serviceGroup.setServiceGroupName(serviceName);
ClassLoader serviceClassLoader = Utils.createClassLoader(
new URL[]{servicesURL},
axisConfig.getServiceClassLoader(),
true,
(File)
axisConfig.getParameterValue(Constants.Configuration.ARTIFACTS_TEMP_DIR),
axisConfig.isChildFirstClassLoading());
String metainf = meta-inf;
serviceGroup.setServiceGroupClassLoader(serviceClassLoader);
//processing wsdl.list
InputStream wsdlfilesStream =
serviceClassLoader.getResourceAsStream(meta-inf/wsdl.list);
if (wsdlfilesStream == null) {
wsdlfilesStream =
serviceClassLoader.getResourceAsStream(META-INF/wsdl.list);
if (wsdlfilesStream != null) {
metainf = META-INF;
}
}
HashMap servicesMap = new HashMap();
if (wsdlfilesStream != null) {
ArchiveReader reader = new ArchiveReader();
BufferedReader input = new BufferedReader(new
InputStreamReader(wsdlfilesStream));
String line;
while ((line = input.readLine()) != null) {
line = line.trim();
if (line.length() 0 line.charAt(0) != '#') {
line = metainf + / + line;
try {
List services =
reader.getAxisServiceFromWsdl(
serviceClassLoader.getResourceAsStream(line),
serviceClassLoader, line);
if (services != null) {
for (Object service : services) {
AxisService axisService =
(AxisService) service;
servicesMap.put(axisService.getName(),
axisService);
}
}
} catch (Exception e) {
throw new DeploymentException(e);
}
}
}
}
InputStream servicexmlStream =
serviceClassLoader.getResourceAsStream(META-INF/services.xml);
if (servicexmlStream == null) {
servicexmlStream =
serviceClassLoader.getResourceAsStream(meta-inf/services.xml);
} else {
metainf = META-INF;
}
if (servicexmlStream == null) {
throw new DeploymentException(
Messages.getMessage(DeploymentErrorMsgs.SERVICE_XML_NOT_FOUND,
servicesURL.toString()));
}
DescriptionBuilder builder = new
DescriptionBuilder(servicexmlStream, configContext);
OMElement rootElement = builder.buildOM();
String elementName = rootElement.getLocalName();
if (TAG_SERVICE.equals(elementName)) {
AxisService axisService = null;
String wsdlLocation = META-INF/service.wsdl;
InputStream wsdlStream =
serviceClassLoader.getResourceAsStream(wsdlLocation);
URL wsdlURL = serviceClassLoader.getResource(metainf +
/service.wsdl);
if (wsdlStream == null
Re: maven-dependency-plugin unpacking aar format?
MDP = maven-dependency-plugin
@domi yes you would normally use something like the maven-assembly-plugin
to disassemble (unpack) an archive.
On Wed, Jul 23, 2014 at 12:49 AM, domi d...@fortysix.ch wrote:
I think to recall a thread on the dev list about plans to remove the
unpack goal from the dependency plugin, but I can’t find it anymore…
regards Domi
On 22.07.2014, at 16:29, William Ferguson william.fergu...@xandar.com.au
wrote:
I totally agree that it makes sense for the dependency plugin to unpack
the
AAR just like all other archives.
I just don't understand why you need the MDP to do so.
On Tue, Jul 22, 2014 at 10:58 PM, David Hoffer dhoff...@gmail.com
wrote:
No that was just an example so I could create a sample project. Don't
read
too much into this. They are just AAR dependencies (in my case they
come
from our build not public). The maven dependency plugin should handle
these no different than it handles jars/etc.
On Mon, Jul 21, 2014 at 11:32 PM, William Ferguson
william.fergu...@xandar.com.au wrote:
So an Android library is packaging WSDL inside itself and is expecting
you
to use it at build time?
On Tue, Jul 22, 2014 at 8:53 AM, Martin Gainty mgai...@hotmail.com
wrote:
Here is an aar straight from Axis version example:
//layout of version.aar:
created: META-INF/
inflated: META-INF/MANIFEST.MF
created: sample/
created: sample/axisversion/
inflated: sample/axisversion/Version.class
inflated: META-INF/services.xml
//org.apache.axis2.deployment.DeploymentEngine axis code used to
populateService with .aar contents:
protected ArrayList populateService(AxisServiceGroup serviceGroup,
URL servicesURL,
String serviceName) throws
DeploymentException {
try {
serviceGroup.setServiceGroupName(serviceName);
ClassLoader serviceClassLoader = Utils.createClassLoader(
new URL[]{servicesURL},
axisConfig.getServiceClassLoader(),
true,
(File)
axisConfig.getParameterValue(Constants.Configuration.ARTIFACTS_TEMP_DIR),
axisConfig.isChildFirstClassLoading());
String metainf = meta-inf;
serviceGroup.setServiceGroupClassLoader(serviceClassLoader);
//processing wsdl.list
InputStream wsdlfilesStream =
serviceClassLoader.getResourceAsStream(meta-inf/wsdl.list);
if (wsdlfilesStream == null) {
wsdlfilesStream =
serviceClassLoader.getResourceAsStream(META-INF/wsdl.list);
if (wsdlfilesStream != null) {
metainf = META-INF;
}
}
HashMap servicesMap = new HashMap();
if (wsdlfilesStream != null) {
ArchiveReader reader = new ArchiveReader();
BufferedReader input = new BufferedReader(new
InputStreamReader(wsdlfilesStream));
String line;
while ((line = input.readLine()) != null) {
line = line.trim();
if (line.length() 0 line.charAt(0) != '#') {
line = metainf + / + line;
try {
List services =
reader.getAxisServiceFromWsdl(
serviceClassLoader.getResourceAsStream(line),
serviceClassLoader, line);
if (services != null) {
for (Object service : services) {
AxisService axisService =
(AxisService) service;
servicesMap.put(axisService.getName(),
axisService);
}
}
} catch (Exception e) {
throw new DeploymentException(e);
}
}
}
}
InputStream servicexmlStream =
serviceClassLoader.getResourceAsStream(META-INF/services.xml);
if (servicexmlStream == null) {
servicexmlStream =
serviceClassLoader.getResourceAsStream(meta-inf/services.xml);
} else {
metainf = META-INF;
}
if (servicexmlStream == null) {
throw new DeploymentException(
Messages.getMessage(DeploymentErrorMsgs.SERVICE_XML_NOT_FOUND,
servicesURL.toString()));
}
DescriptionBuilder builder = new
DescriptionBuilder(servicexmlStream, configContext);
OMElement rootElement = builder.buildOM();
String elementName = rootElement.getLocalName();
if (TAG_SERVICE.equals(elementName)) {
AxisService axisService = null
Re: maven-dependency-plugin unpacking aar format?
Ah well. I was just going from memory. On Wed, Jul 23, 2014 at 1:26 AM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi Robert, Sorry to interject, but isn¹t the unpack goal of the maven-assembly-plugin deprecated? The documentation actually refers users to the MDP¹s unpack capabilities: https://maven.apache.org/plugins/maven-assembly-plugin/plugin-info.html That page is dated from 2012, so I¹m not sure if something has changed since it was last published. What you mentioned is correct...the unpack goal is marked as deprecated and will be removed... This page is not updated cause on the public available things have not being changed... Apart from that those pages are only updated according with new released which has not been done yet (new release is in preparation 2.4.1 (http://jira.codehaus.org/ browse/MASSEMBLY), but it will take some time)... Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-dependency-plugin unpacking aar format?
David, what the use case for unpacking the AAR?
William
On Tue, Jul 22, 2014 at 7:27 AM, David Hoffer dhoff...@gmail.com wrote:
Here is a simplified project showing my use-case, I hope this helps. Note
I'm using unpack-dependencies as the aar is a module in the same project;
however I assume the same problem exists with unpack, if that's the case
that would make the test project even simpler.
?xml version=1.0 encoding=UTF-8?
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/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.company.project/groupId
artifactIdservice/artifactId
version1.0-SNAPSHOT/version
packagingpom/packaging
dependencies
!--note: maven-dependency-plug fails reporting that aar is not
supported--
dependency
groupIdcom.company.project/groupId
artifactIdaxis-service/artifactId
typeaar/type
version1.0-SNAPSHOT/version
/dependency
!--note: I assume it will have the same problem unpacking a public
artifact such as this--
dependency
groupIdcom.helpshift/groupId
artifactIdandroid-aar/artifactId
version3.4.2/version
typeaar/type
/dependency
/dependencies
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
executions
execution
idunpack-axis-service/id
phasegenerate-resources/phase
goals
goalunpack-dependencies/goal
/goals
configuration
includeArtifactIdsaxis-service/includeArtifactIds
outputDirectory${project.build.directory}/generated-resources/axis/outputDirectory
overWriteReleasestrue/overWriteReleases
overWriteSnapshotstrue/overWriteSnapshots
includesMETA-INF/*.wsdl,META-INF/schema/**/*.xsd/includes
/configuration
/execution
/executions
/plugin
/plugins
/build
/project
On Mon, Jul 21, 2014 at 3:05 PM, Karl Heinz Marbaise khmarba...@gmx.de
wrote:
HI David,
I'm getting the following error trying to unpack some files from an
aar.
Is this not supported? Is there any way to do this?
Failed to execute goal
org.apache.maven.plugins:maven-dependency-plugin:2.8:unpack-dependencies
(unpack-service) on project service: Unknown archiver type: No such
archiver: 'aar'. - [Help 1]
Could you please prepare a example project which reproduces the
problem..so i can create a JIRA issue for this...
Kind regards
Karl-Heinz Marbaise
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-dependency-plugin unpacking aar format?
So an Android library is packaging WSDL inside itself and is expecting you
to use it at build time?
On Tue, Jul 22, 2014 at 8:53 AM, Martin Gainty mgai...@hotmail.com wrote:
Here is an aar straight from Axis version example:
//layout of version.aar:
created: META-INF/
inflated: META-INF/MANIFEST.MF
created: sample/
created: sample/axisversion/
inflated: sample/axisversion/Version.class
inflated: META-INF/services.xml
//org.apache.axis2.deployment.DeploymentEngine axis code used to
populateService with .aar contents:
protected ArrayList populateService(AxisServiceGroup serviceGroup,
URL servicesURL,
String serviceName) throws
DeploymentException {
try {
serviceGroup.setServiceGroupName(serviceName);
ClassLoader serviceClassLoader = Utils.createClassLoader(
new URL[]{servicesURL},
axisConfig.getServiceClassLoader(),
true,
(File)
axisConfig.getParameterValue(Constants.Configuration.ARTIFACTS_TEMP_DIR),
axisConfig.isChildFirstClassLoading());
String metainf = meta-inf;
serviceGroup.setServiceGroupClassLoader(serviceClassLoader);
//processing wsdl.list
InputStream wsdlfilesStream =
serviceClassLoader.getResourceAsStream(meta-inf/wsdl.list);
if (wsdlfilesStream == null) {
wsdlfilesStream =
serviceClassLoader.getResourceAsStream(META-INF/wsdl.list);
if (wsdlfilesStream != null) {
metainf = META-INF;
}
}
HashMap servicesMap = new HashMap();
if (wsdlfilesStream != null) {
ArchiveReader reader = new ArchiveReader();
BufferedReader input = new BufferedReader(new
InputStreamReader(wsdlfilesStream));
String line;
while ((line = input.readLine()) != null) {
line = line.trim();
if (line.length() 0 line.charAt(0) != '#') {
line = metainf + / + line;
try {
List services = reader.getAxisServiceFromWsdl(
serviceClassLoader.getResourceAsStream(line),
serviceClassLoader, line);
if (services != null) {
for (Object service : services) {
AxisService axisService =
(AxisService) service;
servicesMap.put(axisService.getName(),
axisService);
}
}
} catch (Exception e) {
throw new DeploymentException(e);
}
}
}
}
InputStream servicexmlStream =
serviceClassLoader.getResourceAsStream(META-INF/services.xml);
if (servicexmlStream == null) {
servicexmlStream =
serviceClassLoader.getResourceAsStream(meta-inf/services.xml);
} else {
metainf = META-INF;
}
if (servicexmlStream == null) {
throw new DeploymentException(
Messages.getMessage(DeploymentErrorMsgs.SERVICE_XML_NOT_FOUND,
servicesURL.toString()));
}
DescriptionBuilder builder = new
DescriptionBuilder(servicexmlStream, configContext);
OMElement rootElement = builder.buildOM();
String elementName = rootElement.getLocalName();
if (TAG_SERVICE.equals(elementName)) {
AxisService axisService = null;
String wsdlLocation = META-INF/service.wsdl;
InputStream wsdlStream =
serviceClassLoader.getResourceAsStream(wsdlLocation);
URL wsdlURL = serviceClassLoader.getResource(metainf +
/service.wsdl);
if (wsdlStream == null) {
wsdlLocation = META-INF/ + serviceName + .wsdl;
wsdlStream = serviceClassLoader
.getResourceAsStream(wsdlLocation);
wsdlURL = serviceClassLoader.getResource(wsdlLocation);
}
if (wsdlStream != null) {
WSDL11ToAxisServiceBuilder wsdl2AxisServiceBuilder =
new WSDL11ToAxisServiceBuilder(wsdlStream,
null, null);
File file = Utils.toFile(servicesURL);
if (file != null file.exists()) {
wsdl2AxisServiceBuilder.setCustomWSDLResolver(
new AARBasedWSDLLocator(wsdlLocation,
file, wsdlStream));
Re: Need to resolve the dependencies for a MavenArtifact
Anyone? On Sun, Jun 15, 2014 at 12:49 PM, William Ferguson william.fergu...@xandar.com.au wrote: I have a Mojo that needs to work with Maven 3.0.* and 3.1+ In the Mojo I have an Artifact and I need to resolve it's dependencies. How can/should I do it? If I can resolve the Artifact to a MavenProject then I can use DependencyGraphBuilder (from maven-dependency-tree) to construct a graph of the deps. But I'm struggling to make the Artifact to MavenProject conversion happen. I thought that If I could get a URL to the Artifact's POM file then I could use DefaultMavenRuntime (maven-runtime) to resolve the URL into a MavenProject. But 1. I can't work out how to get a URL to the artifact's POM file (it needs to handle both reactor deps and repo deps) 2. Even with a URL to the POM file, MavenRuntime#getProject) is returning null. Can someone please point me in the right direction? Am I even on the right path or is there a much more straight forward way of getting the dependencies for the Artifact? William
Re: Need to resolve the dependencies for a MavenArtifact
Thanks James, but perhaps I wasn't clear. I need to be able to resolve the dependencies for a given artifact from within my Mojo (ie within my plugin). That's the problem I am trying to solve. William On Mon, Jun 16, 2014 at 5:38 PM, james northrup northrup.ja...@gmail.com wrote: mvn dependency:build-classpath is tricky in my experience but i have at least one script in guithub using it to launch a java service withoutr maven assembly plugin or untoward grepping. https://github.com/jnorthrup/RelaxFactory/blob/master/bin/run.sh On Mon, Jun 16, 2014 at 12:21 AM, William Ferguson william.fergu...@xandar.com.au wrote: Anyone? On Sun, Jun 15, 2014 at 12:49 PM, William Ferguson william.fergu...@xandar.com.au wrote: I have a Mojo that needs to work with Maven 3.0.* and 3.1+ In the Mojo I have an Artifact and I need to resolve it's dependencies. How can/should I do it? If I can resolve the Artifact to a MavenProject then I can use DependencyGraphBuilder (from maven-dependency-tree) to construct a graph of the deps. But I'm struggling to make the Artifact to MavenProject conversion happen. I thought that If I could get a URL to the Artifact's POM file then I could use DefaultMavenRuntime (maven-runtime) to resolve the URL into a MavenProject. But 1. I can't work out how to get a URL to the artifact's POM file (it needs to handle both reactor deps and repo deps) 2. Even with a URL to the POM file, MavenRuntime#getProject) is returning null. Can someone please point me in the right direction? Am I even on the right path or is there a much more straight forward way of getting the dependencies for the Artifact? William -- Jim Northrup * (408) 837-2270 *
Re: Need to resolve the dependencies for a MavenArtifact
I'm not looking for the dependencies of the current project. I'm looking for the dependencies of a given artifact. Perhaps I'm not reading maven-dependecy-tree:build-classpath correctly, but I don't see how it can be configured to provide that. On Tue, Jun 17, 2014 at 4:32 AM, james northrup northrup.ja...@gmail.com wrote: what's not clear is how build-classpath doesn't give you the deps you want. On Mon, Jun 16, 2014 at 1:23 AM, William Ferguson william.fergu...@xandar.com.au wrote: Thanks James, but perhaps I wasn't clear. I need to be able to resolve the dependencies for a given artifact from within my Mojo (ie within my plugin). That's the problem I am trying to solve. William On Mon, Jun 16, 2014 at 5:38 PM, james northrup northrup.ja...@gmail.com wrote: mvn dependency:build-classpath is tricky in my experience but i have at least one script in guithub using it to launch a java service withoutr maven assembly plugin or untoward grepping. https://github.com/jnorthrup/RelaxFactory/blob/master/bin/run.sh On Mon, Jun 16, 2014 at 12:21 AM, William Ferguson william.fergu...@xandar.com.au wrote: Anyone? On Sun, Jun 15, 2014 at 12:49 PM, William Ferguson william.fergu...@xandar.com.au wrote: I have a Mojo that needs to work with Maven 3.0.* and 3.1+ In the Mojo I have an Artifact and I need to resolve it's dependencies. How can/should I do it? If I can resolve the Artifact to a MavenProject then I can use DependencyGraphBuilder (from maven-dependency-tree) to construct a graph of the deps. But I'm struggling to make the Artifact to MavenProject conversion happen. I thought that If I could get a URL to the Artifact's POM file then I could use DefaultMavenRuntime (maven-runtime) to resolve the URL into a MavenProject. But 1. I can't work out how to get a URL to the artifact's POM file (it needs to handle both reactor deps and repo deps) 2. Even with a URL to the POM file, MavenRuntime#getProject) is returning null. Can someone please point me in the right direction? Am I even on the right path or is there a much more straight forward way of getting the dependencies for the Artifact? William -- Jim Northrup * (408) 837-2270 * -- Jim Northrup * (408) 837-2270 *
Re: Need to resolve the dependencies for a MavenArtifact
Thanks Curtis, that method (#getArtifactsInTopologicalOrder) is not far from my own code (they both use DependecyGraphBuilder to resolve the deps). But the first parameter of that method is the MavenProject for which you want the resolved dependencies, and that is the piece I am missing. I have an Artifact and if I could convert it into a MavenProject then that approach should work. So if I can't resolve the dependencies for an Artifact directly, then resolving an Artifact into it's MavenProject would be enough to get me moving forward. William On Tue, Jun 17, 2014 at 7:55 AM, Curtis Rueden ctrue...@wisc.edu wrote: Hi William, Am I even on the right path or is there a much more straight forward way of getting the dependencies for the Artifact? My naive impression, having dabbled with writing Maven plugins without spending too much time doing it, is that there is a lot of copying and pasting going on. Find a plugin that does close to what you want, and steal blocks of code. As such, unfortunately, it may very well be that there is not an especially straightforward way. Anyway, your question reminds me of something similar (IIUC?) asked and answered by Laird Nelson awhile back: http://mail-archives.apache.org/mod_mbox/maven-users/201401.mbox/%3CCAHNdxu==eJv-fuX8aAuVvzrhkEAXsy=rv2aforz+xumtlkz...@mail.gmail.com%3E https://github.com/ljnelson/maven-artifacts/blob/master/src/main/java/com/edugility/maven/Artifacts.java#L80 Maybe that code is helpful? Or if not, apologies for the noise. Regards, Curtis On Mon, Jun 16, 2014 at 4:40 PM, William Ferguson william.fergu...@xandar.com.au wrote: I'm not looking for the dependencies of the current project. I'm looking for the dependencies of a given artifact. Perhaps I'm not reading maven-dependecy-tree:build-classpath correctly, but I don't see how it can be configured to provide that. On Tue, Jun 17, 2014 at 4:32 AM, james northrup northrup.ja...@gmail.com wrote: what's not clear is how build-classpath doesn't give you the deps you want. On Mon, Jun 16, 2014 at 1:23 AM, William Ferguson william.fergu...@xandar.com.au wrote: Thanks James, but perhaps I wasn't clear. I need to be able to resolve the dependencies for a given artifact from within my Mojo (ie within my plugin). That's the problem I am trying to solve. William On Mon, Jun 16, 2014 at 5:38 PM, james northrup northrup.ja...@gmail.com wrote: mvn dependency:build-classpath is tricky in my experience but i have at least one script in guithub using it to launch a java service withoutr maven assembly plugin or untoward grepping. https://github.com/jnorthrup/RelaxFactory/blob/master/bin/run.sh On Mon, Jun 16, 2014 at 12:21 AM, William Ferguson william.fergu...@xandar.com.au wrote: Anyone? On Sun, Jun 15, 2014 at 12:49 PM, William Ferguson william.fergu...@xandar.com.au wrote: I have a Mojo that needs to work with Maven 3.0.* and 3.1+ In the Mojo I have an Artifact and I need to resolve it's dependencies. How can/should I do it? If I can resolve the Artifact to a MavenProject then I can use DependencyGraphBuilder (from maven-dependency-tree) to construct a graph of the deps. But I'm struggling to make the Artifact to MavenProject conversion happen. I thought that If I could get a URL to the Artifact's POM file then I could use DefaultMavenRuntime (maven-runtime) to resolve the URL into a MavenProject. But 1. I can't work out how to get a URL to the artifact's POM file (it needs to handle both reactor deps and repo deps) 2. Even with a URL to the POM file, MavenRuntime#getProject) is returning null. Can someone please point me in the right direction? Am I even on the right path or is there a much more straight forward way of getting the dependencies for the Artifact? William -- Jim Northrup * (408) 837-2270 * -- Jim Northrup * (408) 837-2270 *
Need to resolve the dependencies for a MavenArtifact
I have a Mojo that needs to work with Maven 3.0.* and 3.1+ In the Mojo I have an Artifact and I need to resolve it's dependencies. How can/should I do it? If I can resolve the Artifact to a MavenProject then I can use DependencyGraphBuilder (from maven-dependency-tree) to construct a graph of the deps. But I'm struggling to make the Artifact to MavenProject conversion happen. I thought that If I could get a URL to the Artifact's POM file then I could use DefaultMavenRuntime (maven-runtime) to resolve the URL into a MavenProject. But 1. I can't work out how to get a URL to the artifact's POM file (it needs to handle both reactor deps and repo deps) 2. Even with a URL to the POM file, MavenRuntime#getProject) is returning null. Can someone please point me in the right direction? Am I even on the right path or is there a much more straight forward way of getting the dependencies for the Artifact? William
Re: Nexus / Maven repository artifact handling
Mehul, this is the wrong pattern to use. It goes against the entire Maven dependency mechanism. Each GAV (aside from snapsghots) should represent a unique build. You should be creating new RC GAVs for each release candidate. eg groupX-artifactX-versionZ.rc1 William On Tue, Jun 3, 2014 at 12:27 PM, Mehul Sanghvi mehul.sang...@gmail.com wrote: We use SNAPSHOT during development, say 1.1.0-SNAPSHOT. At code freeze, we branch off from main line to a version specific branch and remove SNAPSHOT from the version string, so it becomes 1.1.0. Between code freeze and release we have RC builds. Its at that point that when a newer build of the same artifact is uploaded, so the GAV is identical, maven will not download the newest build. So its the same JAR file being uploaded, with the same version. The only thing changing is the file size and time stamp of the uploaded artifact. So I have fubar-1.1.0.jar uploaded to Nexus. The consumer picks up this jar file and downloads to ~/.m2. Now we find some problems with it, and there is an update. So a newer fubar-1.1.0.jar is uploaded, over-writing the old one. Then next time a build of the consuming project is run, it does not download the newly built fubar-1.1.0.jar. Based on what you're saying, this is a feature and the right way to do things, correct ? Than, how do folks handle RC versions ? cheers, mehul On Mon, Jun 2, 2014 at 6:54 PM, Jason van Zyl ja...@takari.io wrote: Are you deploying different artifacts with the same version? Release versions are expected to be immutable and Maven will not try to download a released artifact again because it's not expected to change. If you are deploying different artifacts using the same version you are using Maven incorrectly. On Jun 2, 2014, at 6:06 PM, mehul.sang...@gmail.com wrote: We have a Nexus server to which various projects upload artifacts. The artifacts are uploaded to a release repository, not a snapshot repository. One project is just a consumer of the artifacts. It does not upload anything. Even though we have an updated artifact available, the consuming project does not download the artifacts from nexus until we clear out the local repo in ~/.m2. How does Nexus / Maven determine that a new artifact needs to be downloaded from the remote repo? The timestamp reflects the time of upload of the artifact. So what am I missing ? The GAV is of the form: group:artifact.id:group.artifact.id-11.1.0.jar When a new group.artifact.id-11.1.0.jar is uploaded, it won't get downloaded by the consuming project. cheers, mehul -- Sent from my smart phone Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
Replacement for ArtifactResolver in Maven-3?
ArtifactResolver has been deprecated but it doesn't provide guidance on an appropriate replacement. http://maven.apache.org/ref/3.2.1/maven-compat/apidocs/index.html In the spirit of trying to move in the right direction what should I use instead? William
Re: Replacement for ArtifactResolver in Maven-3?
Thanks. Much appreciated. On Mon, May 26, 2014 at 5:08 AM, Martin Gainty mgai...@hotmail.com wrote: Subject: Re: Replacement for ArtifactResolver in Maven-3? From: dk...@apache.org Date: Sun, 25 May 2014 08:18:31 -0400 To: users@maven.apache.org On May 25, 2014, at 4:20 AM, William Ferguson william.fergu...@xandar.com.au wrote: ArtifactResolver has been deprecated but it doesn't provide guidance on an appropriate replacement. http://maven.apache.org/ref/3.2.1/maven-compat/apidocs/index.html In the spirit of trying to move in the right direction what should I use instead? I looked into this twice last week and ended up using org.apache.maven.repository.RepositorySystem See: https://svn.apache.org/repos/asf/aries/trunk/versioning/versioning-plugin/src/main/java/org/apache/aries/versioning/mojo/VersionCheckerMojo.java MGmake sure you update your components.xml role and implementation definitions:MG http://svn.apache.org/repos/asf/maven/sandbox/branches/maven-2.0.9/maven-artifact-manager/src/main/resources/META-INF/plexus/components.xmlMGotherwise your injector will inject the wrong implementor for MGlegacy ArtifactResolver interface -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Wagon extensions not available from AbstractMavenLifecycleParticipant or maven-dependency-tree?
Anyone? On Mon, May 12, 2014 at 8:58 PM, William Ferguson william.fergu...@xandar.com.au wrote: I have a MavenLifecycleParticipant in my plugin. It uses maven-dependency-tree to resolve some deps that we need to do extra processing on. It works fine if the deps are in the local repo. But if the s3 Wagon is defined in the project along with a dependency from the s3 bucket, then the following debug log shows that DependencyGraphBuilder of maven-dependency-tree can't resolve the s3 wagon, and the dependency is not resolved now or later in the build, so compilation fails. NB If I remove the MavenLifecycleParticipant then the dep is resolved via the S3 Wagon. Q1) When are the Wagons configured? Shouldn't it be prior to MavenLifecycleParticipant being called? Q2) How can I get the DependencyGraphBuilder to resolve the s3 artifact from within the MavenLifecycleParticipant? Here is the stacktrace: [DEBUG] Could not find metadata com.viewpagerindicator:viewpagerindicator:2.4.2-SNAPSHOT/maven-metadata.xml in local (D:\dev\maven-local-repository) [DEBUG] java.util.NoSuchElementException role: org.apache.maven.wagon.Wagon roleHint: s3 org.codehaus.plexus.component.repository.exception.ComponentLookupException: java.util.NoSuchElementException role: org.apache.maven.wagon.Wagon roleHint: s3 at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:264) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:252) at org.eclipse.aether.internal.connector.wagon.PlexusWagonProvider.lookup(PlexusWagonProvider.java:33) at org.eclipse.aether.connector.wagon.WagonRepositoryConnector.lookupWagon(WagonRepositoryConnector.java:337) at org.eclipse.aether.connector.wagon.WagonRepositoryConnector.init(WagonRepositoryConnector.java:157) at org.eclipse.aether.connector.wagon.WagonRepositoryConnectorFactory.newInstance(WagonRepositoryConnectorFactory.java:159) at org.eclipse.aether.internal.impl.DefaultRepositoryConnectorProvider.newRepositoryConnector(DefaultRepositoryConnectorProvider.java:139) at org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run(DefaultMetadataResolver.java:613) at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67) at org.eclipse.aether.internal.impl.DefaultMetadataResolver$1.execute(DefaultMetadataResolver.java:540) at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve(DefaultMetadataResolver.java:395) at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata(DefaultMetadataResolver.java:218) at org.apache.maven.repository.internal.DefaultVersionResolver.resolveVersion(DefaultVersionResolver.java:250) at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:284) at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:217) at org.eclipse.aether.internal.impl.DefaultDependencyCollector.process(DefaultDependencyCollector.java:461) at org.eclipse.aether.internal.impl.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:261) at org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:317) at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:159) at org.apache.maven.shared.dependency.graph.internal.Maven31DependencyGraphBuilder.resolveDependencies(Maven31DependencyGraphBuilder.java:113) at org.apache.maven.shared.dependency.graph.internal.Maven31DependencyGraphBuilder.buildDependencyGraph(Maven31DependencyGraphBuilder.java:99) at org.apache.maven.shared.dependency.graph.internal.DefaultDependencyGraphBuilder.buildDependencyGraph(DefaultDependencyGraphBuilder.java:74) at com.jayway.maven.plugins.android.common.DependencyResolver.getProjectDependenciesFor(DependencyResolver.java:54) at com.jayway.maven.plugins.android.phase_prebuild.ClasspathModifierLifecycleParticipant.afterProjectsRead(ClasspathModifierLifecycleParticipant.java:78) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213) at org.apache.maven.cli.MavenCli.main(MavenCli.java:157) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229
Wagon extensions not available from AbstractMavenLifecycleParticipant or maven-dependency-tree?
I have a MavenLifecycleParticipant in my plugin. It uses maven-dependency-tree to resolve some deps that we need to do extra processing on. It works fine if the deps are in the local repo. But if the s3 Wagon is defined in the project along with a dependency from the s3 bucket, then the following debug log shows that DependencyGraphBuilder of maven-dependency-tree can't resolve the s3 wagon, and the dependency is not resolved now or later in the build, so compilation fails. NB If I remove the MavenLifecycleParticipant then the dep is resolved via the S3 Wagon. Q1) When are the Wagons configured? Shouldn't it be prior to MavenLifecycleParticipant being called? Q2) How can I get the DependencyGraphBuilder to resolve the s3 artifact from within the MavenLifecycleParticipant? Here is the stacktrace: [DEBUG] Could not find metadata com.viewpagerindicator:viewpagerindicator:2.4.2-SNAPSHOT/maven-metadata.xml in local (D:\dev\maven-local-repository) [DEBUG] java.util.NoSuchElementException role: org.apache.maven.wagon.Wagon roleHint: s3 org.codehaus.plexus.component.repository.exception.ComponentLookupException: java.util.NoSuchElementException role: org.apache.maven.wagon.Wagon roleHint: s3 at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:264) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:252) at org.eclipse.aether.internal.connector.wagon.PlexusWagonProvider.lookup(PlexusWagonProvider.java:33) at org.eclipse.aether.connector.wagon.WagonRepositoryConnector.lookupWagon(WagonRepositoryConnector.java:337) at org.eclipse.aether.connector.wagon.WagonRepositoryConnector.init(WagonRepositoryConnector.java:157) at org.eclipse.aether.connector.wagon.WagonRepositoryConnectorFactory.newInstance(WagonRepositoryConnectorFactory.java:159) at org.eclipse.aether.internal.impl.DefaultRepositoryConnectorProvider.newRepositoryConnector(DefaultRepositoryConnectorProvider.java:139) at org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run(DefaultMetadataResolver.java:613) at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67) at org.eclipse.aether.internal.impl.DefaultMetadataResolver$1.execute(DefaultMetadataResolver.java:540) at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve(DefaultMetadataResolver.java:395) at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata(DefaultMetadataResolver.java:218) at org.apache.maven.repository.internal.DefaultVersionResolver.resolveVersion(DefaultVersionResolver.java:250) at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:284) at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:217) at org.eclipse.aether.internal.impl.DefaultDependencyCollector.process(DefaultDependencyCollector.java:461) at org.eclipse.aether.internal.impl.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:261) at org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:317) at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:159) at org.apache.maven.shared.dependency.graph.internal.Maven31DependencyGraphBuilder.resolveDependencies(Maven31DependencyGraphBuilder.java:113) at org.apache.maven.shared.dependency.graph.internal.Maven31DependencyGraphBuilder.buildDependencyGraph(Maven31DependencyGraphBuilder.java:99) at org.apache.maven.shared.dependency.graph.internal.DefaultDependencyGraphBuilder.buildDependencyGraph(DefaultDependencyGraphBuilder.java:74) at com.jayway.maven.plugins.android.common.DependencyResolver.getProjectDependenciesFor(DependencyResolver.java:54) at com.jayway.maven.plugins.android.phase_prebuild.ClasspathModifierLifecycleParticipant.afterProjectsRead(ClasspathModifierLifecycleParticipant.java:78) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213) at org.apache.maven.cli.MavenCli.main(MavenCli.java:157) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) William
Re: maven-dependency-tree reactor resolution
Thanks Herve, I have started down the path of ITs within maven-dep-tree. As a first step I have submitted a patch to enable all 3 of the existing ITs http://jira.codehaus.org/browse/MSHARED-326 Next step is to ass in new ones to highlight the missing func and then hopefully I can fill that space. William On Tue, Mar 25, 2014 at 12:14 PM, Hervé BOUTEMY herve.bout...@free.frwrote: you hit the problem I faced when doing magic for multi-Maven versions compatibility: I didn't figure out how to have tests inside the component itself or it would need ITs (through m-invoker-p), but requires to write a plugin that uses the API then a pom that uses the plugin: too much the way I did it is to use either ITs in maven-dependency-plugin to test modifications in maven-dependency-tree in fact, now that latest maven-dependency-plugin release uses latest maven- dependency-tree API, it could probably be used inside an IT in maven- dependency-tree: that would ease a lot maven-dependency-tree modifications (it was really a headache last time, checking for every Maven version...) tell me if you need more help Regards, Hervé Le mardi 25 mars 2014 09:53:24 William Ferguson a écrit : Herve, I'm looking at trying to add this functionality to maven-dependency-tree but I want to start with a unit test showing the failure. But there doesn't seem to be any unit tests for the DependencyGraphBuilder (for any environment). What's the best way to create a unit test that sets up the environment so that I can explicitly test the Maven3DependencyGraphBuilder and Maven31DependencyGraphBuilder? William On Thu, Mar 20, 2014 at 5:36 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: I don't really know: that's a precise feature that I didn't sudy dependency-tree is used in Maven plugins in contexts where components are already installed: so there is not much difference between reactor resolution and local repository resolution you're probably right: if reactor resolution is not done, it should be added, since that can be something generally expected from the component Regards, Hervé Le jeudi 20 mars 2014 17:30:38 William Ferguson a écrit : Herve, I didn't think I was asking for any extra flexibility out of dependency-tree that it didn't already give. Are you saying that it doesn't support resolution of projects in the current reactor? William On Thu, Mar 20, 2014 at 5:16 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: maven-dependency-tree offers a really simple API: that's its objective. The drawback is that it is not very flexible The value is that it hides Maven 2, Maven 3.0.x and Maven 3.1.x+ implementations, which are completely different (initial Maven 2 is made of listeners, Maven 3 uses Aether and Maven provider, with package changes from Maven 3.0 and 3.1) If you need more features, I think you'd better use Aether with Maven Provider: you can look both at maven-dependency-tree source to start and Aether examples to better understand Aether API, which is a lot more flexible- rich-complex Notice that your initial code will use latest Aether, then your plugin will require Maven 3.1.x minimum. If you want compatibility with Maven 3.0.x and 3.1.x+, you'll have to add some reflection magic which might add complexity (it was not so easy to do it in maven-dependency-tree) If you want Maven 2 compatibility, I would personnally not really think it is reasonably feasible Regards, Hervé Le jeudi 20 mars 2014 09:55:31 William Ferguson a écrit : Hi, I have a plugin that uses the maven-dependency-tree component to resolve project dependencies in a LifeCycleParticipant. (We need early access to deps because we need to modify the compile classpath). But I'm finding that with a clean repository, in a multi-module project with modules X and Y-depends-on-X that the DependencyGraphBuilder is throwing a DependencyGraphBuilderException when trying to resolve Y-depends-on-X. It says that it cannot find X. So it appears that the maven-dependency-tree is only using information from the repository and not the reactor. Is that expected? Is there anyway that I can get MDT to resolve from the reactor? Is there another approach that I should be taking to ensure that resolution looks in the reactor? NB I need to support both maven 3.0 and 3.1 which is why we are using MDT to provide a level of abstraction above the 2 differing Aether implementations. William
Re: maven-dependency-tree reactor resolution
Herve, I'm looking at trying to add this functionality to maven-dependency-tree but I want to start with a unit test showing the failure. But there doesn't seem to be any unit tests for the DependencyGraphBuilder (for any environment). What's the best way to create a unit test that sets up the environment so that I can explicitly test the Maven3DependencyGraphBuilder and Maven31DependencyGraphBuilder? William On Thu, Mar 20, 2014 at 5:36 PM, Hervé BOUTEMY herve.bout...@free.frwrote: I don't really know: that's a precise feature that I didn't sudy dependency-tree is used in Maven plugins in contexts where components are already installed: so there is not much difference between reactor resolution and local repository resolution you're probably right: if reactor resolution is not done, it should be added, since that can be something generally expected from the component Regards, Hervé Le jeudi 20 mars 2014 17:30:38 William Ferguson a écrit : Herve, I didn't think I was asking for any extra flexibility out of dependency-tree that it didn't already give. Are you saying that it doesn't support resolution of projects in the current reactor? William On Thu, Mar 20, 2014 at 5:16 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: maven-dependency-tree offers a really simple API: that's its objective. The drawback is that it is not very flexible The value is that it hides Maven 2, Maven 3.0.x and Maven 3.1.x+ implementations, which are completely different (initial Maven 2 is made of listeners, Maven 3 uses Aether and Maven provider, with package changes from Maven 3.0 and 3.1) If you need more features, I think you'd better use Aether with Maven Provider: you can look both at maven-dependency-tree source to start and Aether examples to better understand Aether API, which is a lot more flexible- rich-complex Notice that your initial code will use latest Aether, then your plugin will require Maven 3.1.x minimum. If you want compatibility with Maven 3.0.x and 3.1.x+, you'll have to add some reflection magic which might add complexity (it was not so easy to do it in maven-dependency-tree) If you want Maven 2 compatibility, I would personnally not really think it is reasonably feasible Regards, Hervé Le jeudi 20 mars 2014 09:55:31 William Ferguson a écrit : Hi, I have a plugin that uses the maven-dependency-tree component to resolve project dependencies in a LifeCycleParticipant. (We need early access to deps because we need to modify the compile classpath). But I'm finding that with a clean repository, in a multi-module project with modules X and Y-depends-on-X that the DependencyGraphBuilder is throwing a DependencyGraphBuilderException when trying to resolve Y-depends-on-X. It says that it cannot find X. So it appears that the maven-dependency-tree is only using information from the repository and not the reactor. Is that expected? Is there anyway that I can get MDT to resolve from the reactor? Is there another approach that I should be taking to ensure that resolution looks in the reactor? NB I need to support both maven 3.0 and 3.1 which is why we are using MDT to provide a level of abstraction above the 2 differing Aether implementations. William - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-dependency-tree reactor resolution
Herve, I didn't think I was asking for any extra flexibility out of dependency-tree that it didn't already give. Are you saying that it doesn't support resolution of projects in the current reactor? William On Thu, Mar 20, 2014 at 5:16 PM, Hervé BOUTEMY herve.bout...@free.frwrote: maven-dependency-tree offers a really simple API: that's its objective. The drawback is that it is not very flexible The value is that it hides Maven 2, Maven 3.0.x and Maven 3.1.x+ implementations, which are completely different (initial Maven 2 is made of listeners, Maven 3 uses Aether and Maven provider, with package changes from Maven 3.0 and 3.1) If you need more features, I think you'd better use Aether with Maven Provider: you can look both at maven-dependency-tree source to start and Aether examples to better understand Aether API, which is a lot more flexible- rich-complex Notice that your initial code will use latest Aether, then your plugin will require Maven 3.1.x minimum. If you want compatibility with Maven 3.0.x and 3.1.x+, you'll have to add some reflection magic which might add complexity (it was not so easy to do it in maven-dependency-tree) If you want Maven 2 compatibility, I would personnally not really think it is reasonably feasible Regards, Hervé Le jeudi 20 mars 2014 09:55:31 William Ferguson a écrit : Hi, I have a plugin that uses the maven-dependency-tree component to resolve project dependencies in a LifeCycleParticipant. (We need early access to deps because we need to modify the compile classpath). But I'm finding that with a clean repository, in a multi-module project with modules X and Y-depends-on-X that the DependencyGraphBuilder is throwing a DependencyGraphBuilderException when trying to resolve Y-depends-on-X. It says that it cannot find X. So it appears that the maven-dependency-tree is only using information from the repository and not the reactor. Is that expected? Is there anyway that I can get MDT to resolve from the reactor? Is there another approach that I should be taking to ensure that resolution looks in the reactor? NB I need to support both maven 3.0 and 3.1 which is why we are using MDT to provide a level of abstraction above the 2 differing Aether implementations. William - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-dependency-tree reactor resolution
Hi, I have a plugin that uses the maven-dependency-tree component to resolve project dependencies in a LifeCycleParticipant. (We need early access to deps because we need to modify the compile classpath). But I'm finding that with a clean repository, in a multi-module project with modules X and Y-depends-on-X that the DependencyGraphBuilder is throwing a DependencyGraphBuilderException when trying to resolve Y-depends-on-X. It says that it cannot find X. So it appears that the maven-dependency-tree is only using information from the repository and not the reactor. Is that expected? Is there anyway that I can get MDT to resolve from the reactor? Is there another approach that I should be taking to ensure that resolution looks in the reactor? NB I need to support both maven 3.0 and 3.1 which is why we are using MDT to provide a level of abstraction above the 2 differing Aether implementations. William
Re: maven-dependency-tree reactor resolution
Martin, https://github.com/jayway/maven-android-plugin-samples In particular the morseflash module which has: - morse-flash-lib - morse-flash-app (which is dependent on morse-flash-lib) William On Thu, Mar 20, 2014 at 10:28 AM, Martin Gainty mgai...@hotmail.com wrote: William- Can you show us the pom for both: Parent (X?) Dependency (Y?) Date: Thu, 20 Mar 2014 09:55:31 +1000 Subject: maven-dependency-tree reactor resolution From: william.fergu...@xandar.com.au To: users@maven.apache.org CC: mosa...@gmail.com Hi, I have a plugin that uses the maven-dependency-tree component to resolve project dependencies in a LifeCycleParticipant. (We need early access to deps because we need to modify the compile classpath). But I'm finding that with a clean repository, in a multi-module project with modules X and Y-depends-on-X that the DependencyGraphBuilder is throwing a DependencyGraphBuilderException when trying to resolve Y-depends-on-X. It says that it cannot find X. So it appears that the maven-dependency-tree is only using information from the repository and not the reactor. Is that expected? Is there anyway that I can get MDT to resolve from the reactor? Is there another approach that I should be taking to ensure that resolution looks in the reactor? NB I need to support both maven 3.0 and 3.1 which is why we are using MDT to provide a level of abstraction above the 2 differing Aether implementations. William
Re: maven-dependency-tree reactor resolution
Here's the direct links for both POMs morseflash-lib/pom.xmlhttps://github.com/jayway/maven-android-plugin-samples/blob/master/morseflash/morseflash-lib/pom.xml morseflash-app/pom.xmlhttps://github.com/jayway/maven-android-plugin-samples/blob/master/morseflash/morseflash-app/pom.xml On Thu, Mar 20, 2014 at 2:59 PM, William Ferguson william.fergu...@xandar.com.au wrote: Martin, https://github.com/jayway/maven-android-plugin-samples In particular the morseflash module which has: - morse-flash-lib - morse-flash-app (which is dependent on morse-flash-lib) William On Thu, Mar 20, 2014 at 10:28 AM, Martin Gainty mgai...@hotmail.comwrote: William- Can you show us the pom for both: Parent (X?) Dependency (Y?) Date: Thu, 20 Mar 2014 09:55:31 +1000 Subject: maven-dependency-tree reactor resolution From: william.fergu...@xandar.com.au To: users@maven.apache.org CC: mosa...@gmail.com Hi, I have a plugin that uses the maven-dependency-tree component to resolve project dependencies in a LifeCycleParticipant. (We need early access to deps because we need to modify the compile classpath). But I'm finding that with a clean repository, in a multi-module project with modules X and Y-depends-on-X that the DependencyGraphBuilder is throwing a DependencyGraphBuilderException when trying to resolve Y-depends-on-X. It says that it cannot find X. So it appears that the maven-dependency-tree is only using information from the repository and not the reactor. Is that expected? Is there anyway that I can get MDT to resolve from the reactor? Is there another approach that I should be taking to ensure that resolution looks in the reactor? NB I need to support both maven 3.0 and 3.1 which is why we are using MDT to provide a level of abstraction above the 2 differing Aether implementations. William
Re: Guice provision error with AbstractMavenLifecycleParticipant
Just for anyone coming after me .. Ended up rewriting everything that referenced Aether to use dependency-tree instead. It was definitely the way to go. Made everything much cleaner and simpler and firewalled up from directly using Maven 3.0 or 3.1 code. Thanks for all your help Stuart. It was much appreciated. William On Sun, Mar 2, 2014 at 6:23 AM, Stuart McCulloch mccu...@gmail.com wrote: On 1 Mar 2014, at 19:12, William Ferguson william.fergu...@xandar.com.au wrote: Thanks for the exceptionally clear explanation Stuart. I don't think we can just avoid the exception with stubbed implementations of the Resolver because the the plugin doesn't use the Resolver directly. It asks for an Aether RepositorySystem: @Requirement private RepositorySystem repoSystem; which is what instantiates the VersionResolver. I don't think this is an issue, just declaring a dummy component locally using @Component should satisfy the missing binding that leads to the original exception. In other words: at the moment you have a broken dependency chain that stops Guice from creating an instance of the repository system - if you provide a dummy link in the form of a local @Component(hint=dummy) that implements VersionResolver then the chain will be complete from the perspective of the current plugin and the repository system can be created. Of course you can't then do much with it because it would be using the dummy resolver, but it would avoid the original exception at creation time and allow the IntelliJ pom processing to continue. Note you may also need to stub out other resolver components required by the repository system. Of course as Manfred points out, if IntelliJ updated their bundled version of Maven to 3.1.x or later then that would also solve the problem and doesn't require any plugin changes. I'll have another look at maven-dependency-tree but I didn't see a clear path towards what we wanted. Could you shed some more light on: Unfortunately adding a direct plugin dependency to the maven-aether-provider from 3.1.1 won't help because Maven will filter out this dependency as being supplied from Maven core What's doing the filtering and why? IIRC this is done in DefaultClassRealmManager from maven-core... the reason it filters out dependencies/packages explicitly exported by core is to avoid class consistency issues, otherwise you could end up with the same class being defined twice, once by the core class loader and once by a plugin's class loader. Such classes would then be incompatible as they were defined by different class loaders and couldn't then be used for sharing data, such as sharing repository information between core and a plugin. What would be need to make it not filter out a maven-core library that is a different version of the running Maven instance? You can't without doing some complicated class loader hacks, this is a fundamental feature of Maven's plugin system. William On Fri, Feb 28, 2014 at 12:13 PM, Stuart McCulloch mccu...@gmail.com wrote: On 28 Feb 2014, at 01:17, William Ferguson william.fergu...@xandar.com.au wrote: As part of the development of the android-maven-plugin we have need to add in an AbstractMavenLifecycleParticipant so that we can modify the compile classpath to add artefacts that are contained within a project's dependencies. Igor provided a lot of the coaching on this. The build works fine. Does what is intended. But now, when you open a project in intelliJ13 that uses the android-maven-plugin, IntelliJ declares a problem with the POM that references our MavenLifecycleParticipant. What I'd like help with is: 1) Is this a problem with the plugin itself. Ie have we defined something incorrectly. 2) Is it just a problem with how IntelliJ is parsing a POM that declares the plugin. If it is (1), what do we need to do to fix it? However, I suspect it is (2) because similar error messages seem to occur when plugins designed for Maven 3.1 (and the switch to Eclipse Aether from Sonatype Aether) are used in a Maven-3.0 environment. I'm thinking that maybe IntelliJ is using a Maven-3.0 core. But I'm really not sure and would love some clarity from those who understand what is going on a bit better. And if it is (2) is there anything we or IntelliJ can do to fix it? The plugin itself can be found at: https://github.com/jayway/maven-android-plugin A project showing the failure can be found at: https://github.com/jayway/maven-android-plugin-samples/tree/master/morseflash/morseflash-app And the error message is (visible via flyover in the POM editor window or in idea.log): I can recreate the same exception on the command-line using the plugin with Maven 3.0.5 (after I removed the 3.1.1 pre-req from the plugin's pom.xml) The issue is that the plugin expects Maven core to supply
Re: Guice provision error with AbstractMavenLifecycleParticipant
Thanks for the exceptionally clear explanation Stuart. I don't think we can just avoid the exception with stubbed implementations of the Resolver because the the plugin doesn't use the Resolver directly. It asks for an Aether RepositorySystem: @Requirement private RepositorySystem repoSystem; which is what instantiates the VersionResolver. I'll have another look at maven-dependency-tree but I didn't see a clear path towards what we wanted. Could you shed some more light on: Unfortunately adding a direct plugin dependency to the maven-aether-provider from 3.1.1 won't help because Maven will filter out this dependency as being supplied from Maven core What's doing the filtering and why? What would be need to make it not filter out a maven-core library that is a different version of the running Maven instance? William On Fri, Feb 28, 2014 at 12:13 PM, Stuart McCulloch mccu...@gmail.comwrote: On 28 Feb 2014, at 01:17, William Ferguson william.fergu...@xandar.com.au wrote: As part of the development of the android-maven-plugin we have need to add in an AbstractMavenLifecycleParticipant so that we can modify the compile classpath to add artefacts that are contained within a project's dependencies. Igor provided a lot of the coaching on this. The build works fine. Does what is intended. But now, when you open a project in intelliJ13 that uses the android-maven-plugin, IntelliJ declares a problem with the POM that references our MavenLifecycleParticipant. What I'd like help with is: 1) Is this a problem with the plugin itself. Ie have we defined something incorrectly. 2) Is it just a problem with how IntelliJ is parsing a POM that declares the plugin. If it is (1), what do we need to do to fix it? However, I suspect it is (2) because similar error messages seem to occur when plugins designed for Maven 3.1 (and the switch to Eclipse Aether from Sonatype Aether) are used in a Maven-3.0 environment. I'm thinking that maybe IntelliJ is using a Maven-3.0 core. But I'm really not sure and would love some clarity from those who understand what is going on a bit better. And if it is (2) is there anything we or IntelliJ can do to fix it? The plugin itself can be found at: https://github.com/jayway/maven-android-plugin A project showing the failure can be found at: https://github.com/jayway/maven-android-plugin-samples/tree/master/morseflash/morseflash-app And the error message is (visible via flyover in the POM editor window or in idea.log): I can recreate the same exception on the command-line using the plugin with Maven 3.0.5 (after I removed the 3.1.1 pre-req from the plugin's pom.xml) The issue is that the plugin expects Maven core to supply an implementation of org.eclipse.aether.impl.VersionResolver, namely DefaultVersionResolver from maven-aether-provider. However in Maven 3.0.x the maven-aether-provider module only supplies an implementation of org.sonatype.aether.impl.VersionResolver ... which is why you see that exception :/ Unfortunately adding a direct plugin dependency to the maven-aether-provider from 3.1.1 won't help because Maven will filter out this dependency as being supplied from Maven core If you want the plugin to work on both Maven 3.0.x and 3.1.x then you'll either need to use an API common to both (like the shared maven-dependency-tree component) or write two versions of the code that talks to Aether and select the appropriate one at runtime using reflection. But if you just want to avoid the exception when Intellij processes the pom.xml then you could conceivably provide dummy/stubbed @Component implementations of the Eclipse/Aether resolver, with the role set to a non-default value such as dummy so that it doesn't interfere with the default implementation provided in Maven 3.1.1 java.lang.RuntimeException: com.google.inject.ProvisionException: Guice provision errors: 1) No implementation for org.eclipse.aether.impl.VersionResolver was bound. while locating org.eclipse.aether.internal.impl.DefaultRepositorySystem at ClassRealm[extensioncom.jayway.maven.plugins.android.generation2:android-maven-plugin:3.9.0-rc.1, parent: sun.misc.Launcher$AppClassLoader@39172e08] at ClassRealm[extensioncom.jayway.maven.plugins.android.generation2:android-maven-plugin:3.9.0-rc.1, parent: sun.misc.Launcher$AppClassLoader@39172e08] while locating org.eclipse.aether.RepositorySystem while locating com.jayway.maven.plugins.android.phase_prebuild.AarMavenLifecycleParticipant at ClassRealm[extensioncom.jayway.maven.plugins.android.generation2:android-maven-plugin:3.9.0-rc.1, parent: sun.misc.Launcher$AppClassLoader@39172e08] at ClassRealm[extensioncom.jayway.maven.plugins.android.generation2:android-maven-plugin:3.9.0-rc.1, parent: sun.misc.Launcher$AppClassLoader@39172e08] while locating org.apache.maven.AbstractMavenLifecycleParticipant annotated
Guice provision error with AbstractMavenLifecycleParticipant
As part of the development of the android-maven-plugin we have need to add in an AbstractMavenLifecycleParticipant so that we can modify the compile classpath to add artefacts that are contained within a project's dependencies. Igor provided a lot of the coaching on this. The build works fine. Does what is intended. But now, when you open a project in intelliJ13 that uses the android-maven-plugin, IntelliJ declares a problem with the POM that references our MavenLifecycleParticipant. What I'd like help with is: 1) Is this a problem with the plugin itself. Ie have we defined something incorrectly. 2) Is it just a problem with how IntelliJ is parsing a POM that declares the plugin. If it is (1), what do we need to do to fix it? However, I suspect it is (2) because similar error messages seem to occur when plugins designed for Maven 3.1 (and the switch to Eclipse Aether from Sonatype Aether) are used in a Maven-3.0 environment. I'm thinking that maybe IntelliJ is using a Maven-3.0 core. But I'm really not sure and would love some clarity from those who understand what is going on a bit better. And if it is (2) is there anything we or IntelliJ can do to fix it? The plugin itself can be found at: https://github.com/jayway/maven-android-plugin A project showing the failure can be found at: https://github.com/jayway/maven-android-plugin-samples/tree/master/morseflash/morseflash-app And the error message is (visible via flyover in the POM editor window or in idea.log): java.lang.RuntimeException: com.google.inject.ProvisionException: Guice provision errors: 1) No implementation for org.eclipse.aether.impl.VersionResolver was bound. while locating org.eclipse.aether.internal.impl.DefaultRepositorySystem at ClassRealm[extensioncom.jayway.maven.plugins.android.generation2:android-maven-plugin:3.9.0-rc.1, parent: sun.misc.Launcher$AppClassLoader@39172e08] at ClassRealm[extensioncom.jayway.maven.plugins.android.generation2:android-maven-plugin:3.9.0-rc.1, parent: sun.misc.Launcher$AppClassLoader@39172e08] while locating org.eclipse.aether.RepositorySystem while locating com.jayway.maven.plugins.android.phase_prebuild.AarMavenLifecycleParticipant at ClassRealm[extensioncom.jayway.maven.plugins.android.generation2:android-maven-plugin:3.9.0-rc.1, parent: sun.misc.Launcher$AppClassLoader@39172e08] at ClassRealm[extensioncom.jayway.maven.plugins.android.generation2:android-maven-plugin:3.9.0-rc.1, parent: sun.misc.Launcher$AppClassLoader@39172e08] while locating org.apache.maven.AbstractMavenLifecycleParticipant annotated with @com.google.inject.name.Named(value=AarMavenLifecycleListener) We are tracking this at: https://code.google.com/p/maven-android-plugin/issues/detail?id=449 Any help appreciated. William
Adding a classpath element within a Mojo
I have a Mojo which needs to add an element to the compile time classpath for future Mojos. I'm struggling to find any doco that points in the right direction. Is it possible? If so, how should I go about it? William
Re: Adding a classpath element within a Mojo
OK, let me clarify. Project has dependencies on artifacts of type AAR (Android archive - an archive that contains several sub-artifacts including a classes jar). My Mojo unpacks the AAR artifacts and makes the sub-artifacts available to other build components. One of those build components is the maven-compiler-plugin. We want to add the classes contained in the AAR dependencies to the compile classpath so that the maven-compiler-plugin can compile our classes against the classes from the AARs. How do we do that? William On Mon, Jan 20, 2014 at 1:14 AM, Anders Hammar and...@hammar.net wrote: Do you want to change the classpath of the project or of other mojos? Don't think either is possible. And if it was, I don't think it's wise. The dependencies of the project should be declared and not magically added. /Anders On Sun, Jan 19, 2014 at 1:18 PM, William Ferguson william.fergu...@xandar.com.au wrote: I have a Mojo which needs to add an element to the compile time classpath for future Mojos. I'm struggling to find any doco that points in the right direction. Is it possible? If so, how should I go about it? William
Re: Adding a classpath element within a Mojo
Hi Ron, appreciate the references, but I am not attempting to build an Android project, I am working on the android-maven-plugin which builds Android projects. The AAR consumption within android-maven-plugin is currently incomplete. Ie I need to know how to add a compile time dependency within the Mojo that consumes AAR artifacts. Not looking for a way to use Gradle to build. William On Mon, Jan 20, 2014 at 9:56 AM, Ron Wheeler rwhee...@artifact-software.com wrote: I don't do any Android development but since no one had responded, I thought that I wight try to get you started (or unblocked). Perhaps some of these references will help. http://www.vandalsoftware.com/post/52468430435/publishing- an-android-library-aar-to-a-maven http://stackoverflow.com/questions/15173923/external- android-library-projects-with-gradle http://blog.glassdiary.com/post/67134169807/how-to-share- android-archive-library-aar-across You might want to do some Googling to find exactly what you need. Ron On 19/01/2014 4:47 PM, William Ferguson wrote: OK, let me clarify. Project has dependencies on artifacts of type AAR (Android archive - an archive that contains several sub-artifacts including a classes jar). My Mojo unpacks the AAR artifacts and makes the sub-artifacts available to other build components. One of those build components is the maven-compiler-plugin. We want to add the classes contained in the AAR dependencies to the compile classpath so that the maven-compiler-plugin can compile our classes against the classes from the AARs. How do we do that? William On Mon, Jan 20, 2014 at 1:14 AM, Anders Hammar and...@hammar.net wrote: Do you want to change the classpath of the project or of other mojos? Don't think either is possible. And if it was, I don't think it's wise. The dependencies of the project should be declared and not magically added. /Anders On Sun, Jan 19, 2014 at 1:18 PM, William Ferguson william.fergu...@xandar.com.au wrote: I have a Mojo which needs to add an element to the compile time classpath for future Mojos. I'm struggling to find any doco that points in the right direction. Is it possible? If so, how should I go about it? William -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to add a dependency programmatically for the compile phase?
There are only a few consumers of aar (which is a newish packaging type) artifacts from a Maven repository. 1. People that build using Maven and our plugin. 2. People that build using Gradle. 3. Building from an IDE like IntelliJ/Eclipse This solution would appears to solve 1 and probably 3 (since typically the IDE just delegates to Maven - at least IntelliJ does). 2 is not our concern. But if we can somehow update the Project Model inside the IDE so that when it sees an aar dependency that it looks inside it and adds the embedded jar to the compile classpath that is ideal. If that is what you are suggesting with a custom ArtifactHandler then I am all ears. Can you point me to some high value doco? William On Thu, Dec 19, 2013 at 5:12 PM, Anders Hammar and...@hammar.net wrote: I don't have the code at hands on how to do what you're asking, but I wanted to stress that changing the dependency list in a plugin will only affect that list during the build where your plugin is executed. Any consumers of your artifact (from the repo) will not get this dependency, as the plugin is then not executed! Maybe you can solve this with a custom packaging type and a special ArtifactHandler, but I'm not sure. /Anders On Thu, Dec 19, 2013 at 5:25 AM, William Ferguson william.fergu...@xandar.com.au wrote: Hi, I would like to know how to add a dependency (such as a jar) into the project's list of compile time dependencies programmatically within a Mojo. Benoit should probably have posted this in Maven Users rather than Maven Dev, so I'm reposting here. We are developing a Mojo that needs to add some dependencies into the project list of compile time dependencies programmatically. I was sure that I've seen code that did this, but I can't find it now. Can anyone point us in the right direction? William -- Benoit's original post -- I require to do this programmatically because the user set a dependency of type aar(1) which itself contains a jar. This jar needs to be known by the compile phase (in order to succeed) Note: the compile phase knows about the aar dependency. (1) Aar format: http://tools.android.com/tech-docs/new-build-system/aar-format Other conversations: About AAR the included JAR: https://groups.google.com/forum/#!topic/maven-android-developers/bPK3EnbKH2M Programmatically adding dependencies to a MavenProject: (this conversation led to a hacky solution) http://maven.40175.n5.nabble.com/Programmatically-adding-dependencies-to-a-MavenProject-td215077i20.html#a5773302
How to add a dependency programmatically for the compile phase?
Hi, I would like to know how to add a dependency (such as a jar) into the project's list of compile time dependencies programmatically within a Mojo. Benoit should probably have posted this in Maven Users rather than Maven Dev, so I'm reposting here. We are developing a Mojo that needs to add some dependencies into the project list of compile time dependencies programmatically. I was sure that I've seen code that did this, but I can't find it now. Can anyone point us in the right direction? William -- Benoit's original post -- I require to do this programmatically because the user set a dependency of type aar(1) which itself contains a jar. This jar needs to be known by the compile phase (in order to succeed) Note: the compile phase knows about the aar dependency. (1) Aar format:http://tools.android.com/tech-docs/new-build-system/aar-format Other conversations: About AAR the included JAR:https://groups.google.com/forum/#!topic/maven-android-developers/bPK3EnbKH2M Programmatically adding dependencies to a MavenProject: (this conversation led to a hacky solution)http://maven.40175.n5.nabble.com/Programmatically-adding-dependencies-to-a-MavenProject-td215077i20.html#a5773302
Empty String as Mojo parameter value
I presume I'm missing something obvious, because this has to be reasonably common. But I haven't found anything after a couple of hours of searching so here goes. I have a Mojo parameter that needs the capability of being specified as an empty String. Eg configuration databaseName/databaseName /configuration though I'd settle for being able to specify empty String as the default-value in the Mojo. Eg /** * @parameter default-value= */ private String databaseName; But in either case databaseName is configured as null. Q: How do I construct the databaseName parameter so that it can be configured or have a default-value of empty String instead of null? I realise I could manually set databaseName to emptyString in Mojo#execute if databaseName is null, but that seems to make a mockery of the default-value annotation. William Stay connected to the people that matter most with a smarter inbox. Take a look http://au.docs.yahoo.com/mail/smarterinbox
Specifying fileName for assembly-plugin
Is it possible to generate an assembly whose filename does not get the artifactId appended to the end of the finalName? Eg the following config generates myproject-domain.zip (domain being the artifactId in the assembly descriptor). configuration finalNamemyproject/finalName descriptors descriptorsrc/main/assembly/domain.xml/descriptor /descriptors /configuration I'd like to be able to exactly specify the name of the generated assembly. I've tried specifying an empty classifier but specifying classifier in the plugin config seems to get ignored. William - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Specifying fileName for assembly-plugin
OK, I should have kept plugging away. Specifying an empty artifactId in the assembly descriptor achieves this. I was certain that it didn't use to though. William -Original Message- From: William Ferguson [mailto:[EMAIL PROTECTED] Sent: Thursday, 28 February 2008 8:38 AM To: Maven Users List Subject: Specifying fileName for assembly-plugin Is it possible to generate an assembly whose filename does not get the artifactId appended to the end of the finalName? Eg the following config generates myproject-domain.zip (domain being the artifactId in the assembly descriptor). configuration finalNamemyproject/finalName descriptors descriptorsrc/main/assembly/domain.xml/descriptor /descriptors /configuration I'd like to be able to exactly specify the name of the generated assembly. I've tried specifying an empty classifier but specifying classifier in the plugin config seems to get ignored. William - 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: Deploying a collection of Java class files
You can almost certainly do this using the assembly-plugin -Original Message- From: 8 [mailto:[EMAIL PROTECTED] Sent: Friday, 8 February 2008 9:30 AM To: users@maven.apache.org Subject: [***POSSIBLE SPAM***] - Deploying a collection of Java class files - Sender is forged (SPF Fail) Maven seems to have support in deploying single file artifacts like jars, ears, wars, etc. However, my project requires me to deploy (via FTP) to a particular directory on a machine all (or a selection) of my Java class files - i.e. in an exploded form (not jarred). My project is not a war or an ear - just regular Java class files. How can I do this with Maven? I can't seem to find any plugin that does this - it seems the deploy plugin doesn't do this. There may be an explode plugin, but I don't want the Manifest file there either - and the explode plugin is only Maven 1.0 compatible... -- View this message in context: http://www.nabble.com/Deploying-a-collection-of-Java-class-fil es-tp15346181s177p15346181.html Sent from the Maven - Users mailing list archive at Nabble.com. - 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: - possible maven defect?
Marshall,
the standard solution for what you are attempting would be to
install/deploy those libraries not managed by Maven into your own
repository or corporate repository and then you *would* have access to
them.
William
-Original Message-
From: Marshall Schor [mailto:[EMAIL PROTECTED]
Sent: Friday, 11 January 2008 9:40 AM
To: Maven Users List
Subject: [***POSSIBLE SPAM***] - possible maven defect? -
Sender is forged (SPF Fail)
We define shared values as property elements in a parent
POM and use them in child POMs. We have fragments like this,
near the top of the parent POM:
. . .
properties
. . .
uimaj-ee-version0.7.0/uimaj-version
uimaj-ee-release-version${uimaj-version}-incubating-SNAPSHOT
/uimaj-release-version
. . .
version0.7.0-incubating-SNAPSHOT/version
I noticed I might be able to replace the
version0.7.0-incubating-SNAPSHOT/version
with
version${uimaj-ee-release-version}/version
This only kind of worked. The way it would fail, would be
if there were no existing versions of the parent POM in any
repository, then the mvn install command for the parent POM
would fail when scanning the child POMs, saying, for example:
[ERROR] FATAL ERROR
[INFO]
--
--
[INFO] Error building POM (may not be this project's POM).
Project ID:
org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
Reason: Cannot find parent: org.apache.uima:uimaj-ee for project:
org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version} for
project
org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
I found (as a workaround) that if I modified the parent POM
to have no children (commenting out the module elements),
then mvn install for the parent POM would run; furthermore, I
could then uncomment out the module children and mvn
install on the parent POM would now build the children OK (I
guess because the parent POM was findable in the local repository).
This problem doesn't seem to occur if the parent POM doesn't
use substitutable property values for its own version
number. In that case the parent POM need not be previously
installed in the local repository.
Is this expected behavior in Maven, or is this a defect?
-Marshall
-
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: - possible maven defect?
My apologies Marshall, not quite sure how it occurred but my answer was
for an entirely different question by someone else.
To answer your question, Maven seems to be working largely as designed.
I'm actually surprised that your child POMs could build in any scenario
if their reference to the parent POM contains a build property only
found in the parent POM. Because that would be a circular reference.
You should really have groupId, artifactId and version hard-coded in all
POMs.
The standard Maven way of doing things would be to have the version
hard-coded with a similar value as the version of the parent in the
child POMs. You would then use the release-plugin to manage the
increment of the version.
Is there a particular reason that you needed to define ?
uimaj-ee-version0.7.0/uimaj-version
uimaj-ee-release-version${uimaj-version}-incubating-SNAPSHOT/uimaj-re
lease-version
I think you need to reconsider your project version. I think you want it
as 0.7.0-SNAPSHOT.
incubating would seem to belong as part of an artifactId or assembly
annotation (see the asembly plugin).
I hope this helps.
William
-Original Message-
From: Marshall Schor [mailto:[EMAIL PROTECTED]
Sent: Friday, 11 January 2008 10:06 AM
To: Maven Users List
Subject: [***POSSIBLE SPAM***] - Re: - possible maven defect?
- Sender is forged (SPF Fail)
William Ferguson wrote:
Marshall,
the standard solution for what you are attempting would be to
install/deploy those libraries not managed by Maven into your own
repository or corporate repository and then you *would*
have access to
them.
William
Hi William -
I must have not communicated well. All of the libraries are
manged by Maven. The situation where the failure occurs is
like a startup - when a user first checks out the set of
projects (having child POMs) and the main parent POM, then
tries to do a mvn install on the parent.
(I'm assuming here that they check out a development level,
where the components have not been installed to any repository, yet).
This first mvn install is intended to install of the parts
into the local repository, but it only works if you don't use
${ ... } variable substitution in the way I was trying to use it.
My question is whether this limitation on use of variable
substitution is a maven defect, or whether it is working as
designed (in which case - I'd appreciate learning what the
philosophy is behind this design choice).
-Marshall
-Original Message-
From: Marshall Schor [mailto:[EMAIL PROTECTED]
Sent: Friday, 11 January 2008 9:40 AM
To: Maven Users List
Subject: [***POSSIBLE SPAM***] - possible maven defect? -
Sender is
forged (SPF Fail)
We define shared values as property elements in a parent POM and
use them in child POMs. We have fragments like this, near
the top of
the parent POM:
. . .
properties
. . .
uimaj-ee-version0.7.0/uimaj-version
uimaj-ee-release-version${uimaj-version}-incubating-SNAPSHOT
/uimaj-release-version
. . .
version0.7.0-incubating-SNAPSHOT/version
I noticed I might be able to replace the
version0.7.0-incubating-SNAPSHOT/version
with
version${uimaj-ee-release-version}/version
This only kind of worked. The way it would fail, would
be if there
were no existing versions of the parent POM in any
repository, then
the mvn install command for the parent POM would fail
when scanning
the child POMs, saying, for example:
[ERROR] FATAL ERROR
[INFO]
--
--
[INFO] Error building POM (may not be this project's POM).
Project ID:
org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
Reason: Cannot find parent: org.apache.uima:uimaj-ee
for project:
org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version} for
project
org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
I found (as a workaround) that if I modified the parent
POM to have
no children (commenting out the module elements), then
mvn install
for the parent POM would run; furthermore, I could then
uncomment out
the module children and mvn install on the parent POM would now
build the children OK (I guess because the parent POM was
findable in
the local repository).
This problem doesn't seem to occur if the parent POM doesn't use
substitutable property values for its own version
number. In that
case the parent POM need not be previously installed in the local
repository.
Is this expected behavior in Maven, or is this a defect?
-Marshall
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED
Re: - possible maven defect?
From what you've said it seems that all your problems are solved by
hardcoding the version in the parent.
Ie don't use the property. Which is standard practice.
I don't know what causes the problem that you are describing, but if it
goes away when you stop punishing yourself with it then that would be a
good option IMHO.
William
-Original Message-
From: Marshall Schor [mailto:[EMAIL PROTECTED]
Sent: Friday, 11 January 2008 12:42 PM
To: Maven Users List
Subject: [***POSSIBLE SPAM***] - Re: - possible maven defect?
- Sender is forged (SPF Fail)
William Ferguson wrote:
My apologies Marshall, not quite sure how it occurred but my answer
was for an entirely different question by someone else.
To answer your question, Maven seems to be working largely
as designed.
I'm actually surprised that your child POMs could build in any
scenario if their reference to the parent POM contains a build
property only found in the parent POM. Because that would
be a circular reference.
True, but that's not what we're doing, exactly. In our code,
the reference to the parent POM *is* *hard-coded, and
doesn't contain any references such as
${property-defined-in-parent} for the very reason you describe.
You should really have groupId, artifactId and version
hard-coded in
all POMs.
Well, that's the question. We have groupId and artifactId
hard-coded.
The version *is* inheriting from the parent, via a
${property-defined-in-parent} (*this is working*).
What's not working is the parent itself being able to have a
${property-defined-in-itself} value for the version value.
The standard Maven way of doing things would be to have the version
hard-coded with a similar value as the version of the parent in the
child POMs. You would then use the release-plugin to manage the
increment of the version.
Is there a particular reason that you needed to define ?
uimaj-ee-version0.7.0/uimaj-version
uimaj-ee-release-version${uimaj-version}-incubating-SNAPSHOT/uimaj-
release-version I think you need to reconsider your
project version.
I think you want it as 0.7.0-SNAPSHOT.
incubating would seem to belong as part of an artifactId
or assembly
annotation (see the asembly plugin).
I hope this helps.
Because we are a project in the Apache Incubator, our version
names include the word incubator in them to insure that
users realize they are working with an incubating project.
The reason we define version numbers this way is that we have
some conflicting naming standards - some require
0.7.0-incubating-SNAPSHOT, while others (Eclipse plugins, in
particular) want 0.7.0.incubating-SNAPSHOT (not the .
instead of the '-' in front of the word incubating.
So we thought that we could put all this kind of stuff in one
common, factored out, parent, and be done with it :-)
-Marshall
William
-Original Message-
From: Marshall Schor [mailto:[EMAIL PROTECTED]
Sent: Friday, 11 January 2008 10:06 AM
To: Maven Users List
Subject: [***POSSIBLE SPAM***] - Re: - possible maven defect?
- Sender is forged (SPF Fail)
William Ferguson wrote:
Marshall,
the standard solution for what you are attempting would be to
install/deploy those libraries not managed by Maven
into your own
repository or corporate repository and then you *would*
have access to
them.
William
Hi William -
I must have not communicated well. All of the libraries
are manged
by Maven. The situation where the failure occurs is like
a startup -
when a user first checks out the set of projects (having
child POMs)
and the main parent POM, then tries to do a mvn install on the
parent.
(I'm assuming here that they check out a development
level, where the
components have not been installed to any repository, yet).
This first mvn install is intended to install of the
parts into the
local repository, but it only works if you don't use ${ ... }
variable substitution in the way I was trying to use it.
My question is whether this limitation on use of variable
substitution is a maven defect, or whether it is working
as designed
(in which case - I'd appreciate learning what the philosophy is
behind this design choice).
-Marshall
-Original Message-
From: Marshall Schor [mailto:[EMAIL PROTECTED]
Sent: Friday, 11 January 2008 9:40 AM
To: Maven Users List
Subject: [***POSSIBLE SPAM***] - possible maven defect? -
Sender is
forged (SPF Fail)
We define shared values as property elements in a
parent POM and
use them in child POMs. We have fragments like this, near
the top of
the parent POM:
. . .
properties
. . .
uimaj-ee-version0.7.0/uimaj-version
uimaj-ee-release-version${uimaj-version
RE: Trying to work out where a snapshot caching problem is
Ian, it sounds like you have not configured Maven with the address of the snapshot repositories. I suspect you have just setup a mirror to point to the main repository in Artifactory (in which you are caching Apache, Codehaus etc). Its generally a good idea to keep release and snapshot artifacts separate in any case Don't forget to list the pluginRepository too. And don't foget to activate the profile, either in settings.xml (typical) or on the command line. Try adding something like the following to your settings.xml profile iddefault-repositories/id repositories repository idsnapshot/id nameSNAPSHOT Repository/name urlhttp://hubpc65:8080/artifactory/snapshot/url releases enabledfalse/enabled /releases snapshots enabledtrue/enabled /snapshots /repository /repositories pluginRepositories pluginRepository idsnapshot/id nameSNAPSHOT Repository/name urlhttp://hubpc65:8080/artifactory/snapshot/url releases enabledfalse/enabled /releases snapshots enabledtrue/enabled updatePolicyalways/updatePolicy /snapshots /pluginRepository /pluginRepositories /profile William -Original Message- From: Ian Rowlands [mailto:[EMAIL PROTECTED] Sent: Friday, 21 December 2007 7:47 AM To: undisclosed-recipients Subject: [***POSSIBLE SPAM***] - Trying to work out where a snapshot caching problem is - Sender is forged (SPF Fail) Hi, I'm having a problem with Maven caching and snapshots. I am using Artifactory as a repository cache, which everybody is configured to use. If a release version is needed, everything is fetched into the users' local repository as expected. However the same is not happening with snapshots. I know the snapshots are there - I can see them, and if I do a manual copy out of Artifactory and place them in the local repository everything is fine. I'm not sure whether the problem is my Maven configuration, or an Artifactory configuration. Are there any diagnostics I can turn on to determine where the problem is? I've included the relevant bits of the (customised) settings.xml which everybody is using. This happens with Maven 2.0.7 and 2.0.8. Thanks, Ian settings servers server idartifactory.releases/id usernameadmin/username passwordpassword/password /server server idartifactory.snapshots/id usernameadmin/username passwordpassword/password /server /servers mirrors mirror idartifactory/id mirrorOf*/mirrorOf urlhttp://ebizci/artifactory/all//url nameArtifactory/name /mirror /mirrors profiles !-- Default profile, which should always be set -- profile iddefault/id !-- Need this repository until the dashboard plugin becomes ready for release -- pluginRepositories pluginRepository idCodehaus Snapshots/id url http://snapshots.repository.codehaus.org//url /pluginRepository pluginRepository idCodehaus Snapshots/id url http://snapshots.repository.codehaus.org//url /pluginRepository /pluginRepositories /profile /profiles !-- activeProfiles | List of profiles that are active for all builds. |-- activeProfiles activeProfiledefault/activeProfile /activeProfiles /settings Disclaimer: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from your computer. Privacy: If you are responding to this email or providing personal information to the SRO for the purposes of one of the Acts it administers, such information is used only for the purpose for which it was collected (administration of SRO legislation ) and is protected by the Information Privacy Act 2000 and secrecy provisions contained in legislation administered by SRO. It is not disclosed otherwise than in accordance with the law. If you would like a copy of the SRO Privacy Policy please refer to SRO website (www.sro.vic.gov.au) or contact SRO on 9628 0556 and request a copy.
RE: generated sources convention
Kallin,
You need to tell Maven that the location of your generated source should
be included as part of the build. Ie
/**
* @parameter default-value=${project}
* @required
* @readonly
*/
private MavenProject project;
/**
* @parameter
default-value=${project.build.directory}/generated-sources/myPluginId
* @required
* @readonly
*/
private File sourceDirectoryPath;
...
project.addCompileSourceRoot(sourceDirectoryPath);
Have a read of Better builds with Maven page 148.
William
-Original Message-
From: Kallin Nagelberg [mailto:[EMAIL PROTECTED]
Sent: Thursday, 20 December 2007 2:18 PM
To: users@maven.apache.org
Subject: [***POSSIBLE SPAM***] - generated sources convention
- Sender is forged (SPF Fail)
I'm working on adapting some source generation code into the
maven lifecycle. I've written a plugin that is generating the
sources (albeit at random places) and bound it to the
generate sources phase.
I've read in a couple places that the standard location is
target/generated-sources/plugin-id. However, the compiler
plugin doesn't check this directory. I could always just
ensure these directories are explicitly added for
compilation, but I wanted to check if there was any
convention (besides generating into src/main/java) that would
allow the compilation to occur automatically.
Thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: distributing multiple versions of sites to URLs containing the version number
I have the same requirement - versioning of sites.
In order to have a parent POM that safely defines inheritable site URLs
(which is what you are asking for) requires resolution of
http://jira.codehaus.org/browse/MNG-3244
Which *was* done for maven-2.0.8 but was then rolled back as changed
existing behaviour.
We need a solution that can be configured such that it just resolves the
inherited site URL and a default behaviuour (to support existing
projects) where it automagically appaends the child artifactId to the
inherited site URL.
Vote for it and arc up on the dev list proposing a backwards compatible
solution.
William
-Original Message-
From: jthomp [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 7 November 2007 6:37 AM
To: users@maven.apache.org
Subject: Re: distributing multiple versions of sites to URLs
containing the version number
I'm trying to do the exact same thing that Jerome was asking
about and ran into the same problem. His post received no
replies, so does that mean something like this is not
possible or is there some other way to do this that I overlooked?
As a workaround, I'm thinking about dropping the extra
${project.artifactId} and leaving just the ${project.version}
which is not ideal since it doesn't work w/ projects that
have sub-modules at different version numbers and it will
make ad-hoc browsing trickier since you have to know in
advance the version of a particular project.
I'm surprised others haven't run into this before.
Thoughts?
-JT
Jerome Lacoste-2 wrote:
I am trying to deploy each version of a site to a different
URL, and
use a single configuration in a parent pom. Given a project:
P1
- M1
- M2
where P1 inherits its config from a P0 master pom.
My intent is to obtain something like:
P1 be: http://my.domaine.com/projects/P1/${project.version}/
M1 be: http://my.domaine.com/projects/P1/${project.version}/M1
It works if I specify url for the pom and
distributionManagement in
each project, but I am trying to get it to work in a single pom.
I tried various things, including
distributionManagement
site
...
urlhttp://my.domaine.com/projects/${project.artifactId}/${project.ve
rsion}/
in P0
P1 gets http://my.domaine.com/projects/P1/${project.version}/P1
and
M1 gets http://my.domaine.com/projects/M1/${project.version}/P1/M1
I could live with the superfluous P1 for the moment, but the P1
replaced by M1 obviously breaks browsing...
Any comment?
Anyone else dealing with versionned sites ?
Jerome
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/distributing-multiple-versions-of-sites-
to-URLs-containing-the-version-number-tf1883686s177.html#a13615353
Sent from the Maven - Users mailing list archive at Nabble.com.
-
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: NPE all of a sudden
I suspect that you have a /src/test/java folder with no contents. Not sure why SureFire can't handle this, it looks like a bug to me. You have 2 options (if its as I suspect) 1) Remove the empty src/test/java folder 2) Declare the Surefire plugin and configure it not to execute any tests. William -Original Message- From: sudhakar [mailto:[EMAIL PROTECTED] Sent: Tuesday, 30 October 2007 9:00 AM To: users@maven.apache.org Subject: [***POSSIBLE SPAM***] - NPE all of a sudden - Bayesian Filter detected spam All of a sudden my maven (version 2.0.6) stopped working. I'm getting the following NPE for any new projects I create. All the existing projects are compiling and packing just fine. I tested this on a newly created project with nothing in it except the pom.xml. I'm attaching the zip file of the package if someone wants to give it a shot. [DEBUG] Adding to surefire test classpath: C:\Documents and Settings\sudhakar\.m 2\repository\org\apache\maven\surefire\surefire-api\2.3\surefire-api-2.3 .jar [DEBUG] Adding to surefire test classpath: C:\Documents and Settings\sudhakar\.m 2\repository\org\codehaus\plexus\plexus-utils\1.1\plexus-utils-1.1.jar [DEBUG] Adding to surefire test classpath: C:\Documents and Settings\sudhakar\.m 2\repository\commons-lang\commons-lang\2.1\commons-lang-2.1.jar [DEBUG] Adding to surefire test classpath: C:\Documents and Settings\sudhakar\.m 2\repository\junit\junit\3.8.1\junit-3.8.1.jar [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [DEBUG] Trace java.lang.NullPointerException at org.apache.maven.plugin.surefire.SurefirePlugin.constructSurefireBoot er(SurefirePlugin.java:594) at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugi n.java:391) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [INFO] Total time: 3 seconds [INFO] Finished at: Mon Oct 29 17:54:17 CDT 2007 [INFO] Final Memory: 4M/9M [INFO] E:\Java\workspaces\workspace\maventest - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Proxy
Hi Denis, I have had some experience of 3 of them in the last week. All of them deployed as WebApps inside Tomcat. Promixity - simple config, file based storage, developers seem absent (at least at present). We are using this as our main Maven repository and also as a mirror of that repository at an interstate office. Artifactory - simple config (perhaps simpler than Proximity), DB storage. Archiva (beta2) - couldn't get it to work by following the installation instructions. Doesn't install as a clean webapp (in Tomcat in any case). My preference is Tomcat for the simple config, file base storage. Its just a shame that the developers appear awol and I couldn't find a way to raise issues against it. Hope this helps. William -Original Message- From: Denis Bessmertniy [mailto:[EMAIL PROTECTED] Sent: Friday, 12 October 2007 7:04 PM To: 'Maven Users List' Subject: [***POSSIBLE SPAM***] - Maven Proxy - Email has different SMTP TO: and MIME TO: fields in the email addresses Hi, May you advise to me a good maven proxy? I know only http://proximity.abstracthorizon.org. Is it good? Maybe you know something better? - Denis - 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: Maven Proxy
Sorry Brett, I was already 2 days overdue thanks to infrastructure issues. I'll try to put together a JIRA this afternoon. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Monday, 15 October 2007 6:25 PM were you able to report these problems? Would be happy to hear bugs or thoughts on ways to make it easier to deploy into Tomcat. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven Proxy
Woops, just reread my post. The finally bit should have read: My preference is Proximity for the simple config, file base storage. :-) that makes more sense. William -Original Message- From: William Ferguson [mailto:[EMAIL PROTECTED] Sent: Monday, 15 October 2007 6:04 PM To: Maven Users List Subject: Re: Maven Proxy Hi Denis, I have had some experience of 3 of them in the last week. All of them deployed as WebApps inside Tomcat. Promixity - simple config, file based storage, developers seem absent (at least at present). We are using this as our main Maven repository and also as a mirror of that repository at an interstate office. Artifactory - simple config (perhaps simpler than Proximity), DB storage. Archiva (beta2) - couldn't get it to work by following the installation instructions. Doesn't install as a clean webapp (in Tomcat in any case). My preference is Tomcat for the simple config, file base storage. Its just a shame that the developers appear awol and I couldn't find a way to raise issues against it. Hope this helps. William -Original Message- From: Denis Bessmertniy [mailto:[EMAIL PROTECTED] Sent: Friday, 12 October 2007 7:04 PM To: 'Maven Users List' Subject: [***POSSIBLE SPAM***] - Maven Proxy - Email has different SMTP TO: and MIME TO: fields in the email addresses Hi, May you advise to me a good maven proxy? I know only http://proximity.abstracthorizon.org. Is it good? Maybe you know something better? - Denis - 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]
How to test a plugin
I haven't found it, so I have to ask. Is there a document describing best practice for testing a plugin? I keep running into what appear to be abberations in various Maven plugins, raising JIRAs for them and even submitting patches, but I haven't found any common pattern for constructing test cases to validate the plugins behaviour. Where can I find such a document? William - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
filtering properties like pom.
Meiko,
I'm surprised you are getting any resources copied during your build,
you seem to be excluding them all:
excludes
exclude**/*/exclude
/excludes
What resource file is being copied without filtering being applied?
And what does your filter file look like?
William
-Original Message-
From: meiko [mailto:[EMAIL PROTECTED]
Sent: Friday, 31 August 2007 9:01 AM
To: users@maven.apache.org
Subject: [***POSSIBLE SPAM***] - filtering properties like pom.* dont
work - Email has different SMTP TO: and MIME TO: fields in the email
addresses
I have a problem with filtering.
- properties like maven.* or pom.* or project.*(e.g. ${pom.version})
dont work
- other properties like ${basedir} or ${java.version} work What could be
the reason ?
Thank you for helping a frustrated maven-user ;-)
here is my pom:
?xml version=1.0 encoding=utf-8?
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
artifactIdtrilobita-game/artifactId
groupIdtrilobita/groupId
version1.0/version
/parent
modelVersion4.0.0/modelVersion
groupIdtrilobita/groupId
artifactIdtrilobita-frontend/artifactId
packagingwar/packaging
version1.0/version
build
filters
filter
${basedir}/src/main/resources/components.properties
/filter
/filters
resources
resource
directory/src/main/resources//directory
excludes
exclude**/*/exclude
/excludes
/resource
/resources
plugins
plugin
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.5/source
target1.5/target
/configuration
/plugin
plugin
artifactIdmaven-war-plugin/artifactId
version2.0/version
configuration
webResources
webResource
directory
${basedir}/src/main/webapp
/directory
filteringtrue/filtering
/webResource
/webResources
/configuration
/plugin
/plugins
/build
dependencies
dependency
groupIdjboss/groupId
artifactIdjboss-seam-ui/artifactId
version1.2.1.GA/version
/dependency
/dependencies
/project
--
View this message in context:
http://www.nabble.com/filtering-properties-like-pom.*-dont-work-tf435738
4s177.html#a12417818
Sent from the Maven - Users mailing list archive at Nabble.com.
-
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: Activating a Profile from another Profile
Thanks Tim,
I hadn't considered activating a profile using multiple properties.
If it were possible, then I think it might work.
But
activation
property
namedev/name
nameprod/name
/property
/activation
Is not valid syntax for the POM schema
http://maven.apache.org/maven-v4_0_0.xsd
William
-Original Message-
From: Tim Kettler [mailto:[EMAIL PROTECTED]
Sent: Friday, 24 August 2007 3:24 PM
To: Maven Users List
Subject: [***POSSIBLE SPAM***] - Re: Activating a Profile from another
Profile - Email has different SMTP TO: and MIME TO: fields in the email
addresses
Hi,
No, this is currently not possible directly. However, what you can do is
activate the set of profile via a system property you specify on the
commandline ('mvn -Ddev ...'):
profiles
profile
iddev/id
activation
property
namedev/name
/property
/activation
...
/profile
profile
idprod/id
activation
property
nameprod/name
/property
/activation
...
/profile
profile
idcommon/id
activation
property
namedev/name
nameprod/name
/property
/activation
...
/profile
/profiles
-Tim
William Ferguson schrieb:
Is there any way to activatee a Profile from another Profile?
We have some pieces of the build, specifcally build.resources
definitions that vary depending on which Profile is targetted. But
some of the resource definitions are identical for several of the
Profiles.
So I had hoped to extract the common resource definitions into their
own Profile which was then activated by the target Profiles.
Hopefully that makes sense :-)
It seems this has been asked before without any +ve answer.
http://mail-archives.apache.org/mod_mbox/maven-users/200702.mbox/%3Ce7
52 [EMAIL PROTECTED]
But maybe the question was just overlooked.
Then again, perhaps there is a better way to come at this, in which
case I'm all ears.
William
-
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: Accessing POM properties in a filter
Ah, but the filters file *is* filtered.
At least for Java System properties and for other filter tokens, and
(because of the order that the filtering mechanism is implemented) also
for values of simple POM elements (but not POM properties as they are
complex).
In order to allow replacement of POM porperties to filter files in the
same way as the others are replaced I have rasied the following JIRA and
supplied a patch.
http://jira.codehaus.org/browse/MRESOURCES-47
Its true, I could insert the POM properties directly into the resource
files. But many of the tokens are compounded from one or more POM
properties to produce understandable tokens instead of fragments.
So it would either require many more properties to be added to each
profile in my POM with much duplication between each profile, or it
would require the use of many non-intuitive tokens fragments in the
resource files.
William
-Original Message-
From: Tim Kettler [mailto:[EMAIL PROTECTED]
Sent: Friday, 24 August 2007 3:17 PM
To: Maven Users List
Subject: [***POSSIBLE SPAM***] - Re: [***POSSIBLE SPAM***] - Re:
Accessing POM properties in a filter - Email has different SMTP TO: and
MIME TO: fields in the email addresses - Email has different SMTP TO:
and MIME TO: fields in the email addresses
Hi,
The probem is that for this to work the filters file would need to be
filtered too, which is not the case. Use your declared properties
directly in the resource files you want filtered and don't do the extra
indirection via the filters file.
-Tim
William Ferguson schrieb:
${myProp1} doesn't work either.
With a POM declaring
myProp1Somevalue/myprop1
A filter.file of
some.token=${myProp1}
And a resource file with
Show.me.the.value.of.some.token=${some.token}
The resource file resolves to :
Show.me.the.value.of.some.token=${myProp1}
Instead of
Show.me.the.value.of.some.token=SomeValue
William
-Original Message-
From: Eric Redmond [mailto:[EMAIL PROTECTED]
Sent: Friday, 24 August 2007 12:36 PM
To: Maven Users List
Subject: [***POSSIBLE SPAM***] - Re: Accessing POM properties in a
filter - Email has different SMTP TO: and MIME TO: fields in the email
addresses
Why can't you just use ${myProp1} ? Why go through the trouble of
refering via project.properties?
--
Eric Redmond
http://blog.propellors.net
On 8/23/07, William Ferguson [EMAIL PROTECTED] wrote:
In a resource filter, I can specify tokens like:
token1=${project.version}
token2=${project.properties}
Which when used in a resource file evaluates to:
valueForToken1=1.0-SNAPSHOT
valueForToken2={myProp1=value1, myProp2=value2}
How do I specify a token in the resource filter that resolves to the
value of myProp1?
I've tried all variants (that I can think of) of
${project.properties.myProp1}.
I'm sure there's a way, but I can't find documentation spelling out
the syntax that is required.
William
-
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]
Activating a Profile from another Profile
Resending as its been 24 hours and the message hasn't shown up. Is there any way to activatee a Profile from another Profile? We have some pieces of the build, specifcally build.resources definitions that vary depending on which Profile is targetted. But some of the resource definitions are identical for several of the Profiles. So I had hoped to extract the common resource definitions into their own Profile which was then activated by the target Profiles. Hopefully that makes sense :-) It seems this has been asked before without any +ve answer. http://mail-archives.apache.org/mod_mbox/maven-users/200702.mbox/%3Ce752 [EMAIL PROTECTED] But maybe the question was just overlooked. Then again, perhaps there is a better way to come at this, in which case I'm all ears. William - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Accessing POM properties in a filter
Resending as its been 24 hours and the message hasn't shown up.
In a resource filter, I can specify tokens like:
token1=${project.version}
token2=${project.properties}
Which when used in a resource file evaluates to:
valueForToken1=1.0-SNAPSHOT
valueForToken2={myProp1=value1, myProp2=value2}
How do I specify a token in the resource filter that resolves to the
value of myProp1?
I've tried all variants (that I can think of) of
${project.properties.myProp1}.
I'm sure there's a way, but I can't find documentation spelling out the
syntax that is required.
William
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Accessing POM properties in a filter
In a resource filter, I can specify tokens like:
token1=${project.version}
token2=${project.properties}
Which when used in a resource file evaluates to:
valueForToken1=1.0-SNAPSHOT
valueForToken2={myProp1=value1, myProp2=value2}
How do I specify a token in the resource filter that resolves to the
value of myProp1?
I've tried all variants (that I can think of) of
${project.properties.myProp1}.
I'm sure there's a way, but I can't find documentation spelling out the
syntax that is required.
William
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Activating a Profile from another Profile
Is there any way to activatee a Profile from another Profile? We have some pieces of the build, specifcally build.resources definitions that vary depending on which Profile is targetted. But some of the resource definitions are identical for several of the Profiles. So I had hoped to extract the common resource definitions into their own Profile which was then activated by the target Profiles. Hopefully that makes sense :-) It seems this has been asked before without any +ve answer. http://mail-archives.apache.org/mod_mbox/maven-users/200702.mbox/%3Ce752 [EMAIL PROTECTED] But maybe the question was just overlooked. Then again, perhaps there is a better way to come at this, in which case I'm all ears. William - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Accessing POM properties in a filter
OK, well after a bit of investigation I found that the
maven-resources-plugin only resolves System properties and simple POM
elements, but not POM properties within the Filter before applying them.
So I have created a patch that resolves POM properties within filter
files too.
http://jira.codehaus.org/browse/MRESOURCES-47
If this is affecting you and I recall hearing that some of the Axis2
guys were affected by something that I suspect was this, then please
vote for it.
William
-Original Message-
From: William Ferguson [mailto:[EMAIL PROTECTED]
Sent: Thursday, 23 August 2007 5:10 PM
To: Maven Users List
Subject: Accessing POM properties in a filter
In a resource filter, I can specify tokens like:
token1=${project.version}
token2=${project.properties}
Which when used in a resource file evaluates to:
valueForToken1=1.0-SNAPSHOT
valueForToken2={myProp1=value1, myProp2=value2}
How do I specify a token in the resource filter that resolves to the
value of myProp1?
I've tried all variants (that I can think of) of
${project.properties.myProp1}.
I'm sure there's a way, but I can't find documentation spelling out the
syntax that is required.
William
-
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: [***POSSIBLE SPAM***] - Re: Accessing POM properties in a filter - Email has different SMTP TO: and MIME TO: fields in the email addresses
${myProp1} doesn't work either.
With a POM declaring
myProp1Somevalue/myprop1
A filter.file of
some.token=${myProp1}
And a resource file with
Show.me.the.value.of.some.token=${some.token}
The resource file resolves to :
Show.me.the.value.of.some.token=${myProp1}
Instead of
Show.me.the.value.of.some.token=SomeValue
William
-Original Message-
From: Eric Redmond [mailto:[EMAIL PROTECTED]
Sent: Friday, 24 August 2007 12:36 PM
To: Maven Users List
Subject: [***POSSIBLE SPAM***] - Re: Accessing POM properties in a
filter - Email has different SMTP TO: and MIME TO: fields in the email
addresses
Why can't you just use ${myProp1} ? Why go through the trouble of
refering via project.properties?
--
Eric Redmond
http://blog.propellors.net
On 8/23/07, William Ferguson [EMAIL PROTECTED] wrote:
In a resource filter, I can specify tokens like:
token1=${project.version}
token2=${project.properties}
Which when used in a resource file evaluates to:
valueForToken1=1.0-SNAPSHOT
valueForToken2={myProp1=value1, myProp2=value2}
How do I specify a token in the resource filter that resolves to the
value of myProp1?
I've tried all variants (that I can think of) of
${project.properties.myProp1}.
I'm sure there's a way, but I can't find documentation spelling out
the syntax that is required.
William
-
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]
Display lifecycle phases during a build
Is there any way to get Maven to output the liefecycle pahsaes as it is executing them? It displays the plugin and goal that is executing and that often gives a far bit on sinsight into where the built is up to, but it would be *really* nice if you could clearly see the phases as they are being iterated over. Not only would it help debug strange build problems, but it would help determine the best phase for execution of some plugins. William - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [***POSSIBLE SPAM***] - Re: How to increase the memory usage for mvn? - Email has different SMTP TO: and MIME TO: fields in the email addresses
That' should be fine. Mvn.bat is just a batch file. So as long as you don't override them in there (which Maven doesn't by default) you'll be ok. William -Original Message- From: Baz [mailto:[EMAIL PROTECTED] Sent: Wednesday, 8 August 2007 2:05 PM To: Maven Users List Subject: [***POSSIBLE SPAM***] - Re: How to increase the memory usage for mvn? - Email has different SMTP TO: and MIME TO: fields in the email addresses Can i set MAVEN_OPTS in system variables instead of mvn.bat? Is there any problems with it? On 8/6/07, William Ferguson [EMAIL PROTECTED] wrote: From mvn.bat: @REM MAVEN_OPTS - parameters passed to the Java VM when running Maven Eg set MAVEN_OPTS=-Xmx1024m William -Original Message- From: Baz [mailto:[EMAIL PROTECTED] Sent: Tuesday, 7 August 2007 9:19 AM To: Maven Users List Subject: [***POSSIBLE SPAM***] - How to increase the memory usage for mvn? - Email has different SMTP TO: and MIME TO: fields in the email addresses Hi, How can i increase the memory usage for mvn? Like using ANT, there is an option for that right? Thanks. A. - 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]
Making provided scope dependencies available
What lifecycle phase needs to have run in order to get provided scope
dependencies made available in a plugin.
http://maven.apache.org/ref/current/maven-project/apidocs/org/apache/mav
en/project/MavenProject.html#getArtifacts()
In my plugin during the package phase, ${project.artifacts} doesn't
contain any of the dependencies declared as 'provided'. Though it does
contain all dependencies declared as either compile or runtime.
What do I need to do to make provided scope dependencies available?
William
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to increase the memory usage for mvn?
From mvn.bat: @REM MAVEN_OPTS - parameters passed to the Java VM when running Maven Eg set MAVEN_OPTS=-Xmx1024m William -Original Message- From: Baz [mailto:[EMAIL PROTECTED] Sent: Tuesday, 7 August 2007 9:19 AM To: Maven Users List Subject: [***POSSIBLE SPAM***] - How to increase the memory usage for mvn? - Email has different SMTP TO: and MIME TO: fields in the email addresses Hi, How can i increase the memory usage for mvn? Like using ANT, there is an option for that right? Thanks. A. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: dependency-plugin without forking
Thanks Brian, that works nicely. Looking forward to it being released. Though I did think it kind of strange that it still provided this warning if the build is not forked, which it doesn't appear to be: [WARNING] Removing: just-analyze from forked lifecycle, to prevent recursive invocation. Nor did I understand what this message means: [INFO] No goals needed for project - skipping Any ideas? William -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Tuesday, 24 July 2007 11:36 PM To: Maven Users List Subject: [***POSSIBLE SPAM***] - RE: dependency-plugin without forking - Email has different SMTP TO: and MIME TO: fields in the email addresses Actually in the unreleased snapshot, there is a goal called (i think) just-analyze that does exactly what you ask ;-) From: William Ferguson [mailto:[EMAIL PROTECTED] Sent: Tue 7/24/2007 12:21 AM To: Maven Users List Subject: dependency-plugin without forking Is it possible execute dependency:analyze without having the dependency-plugin fork the build? We'd really like to have dependency:analyze execute as part of every build, but having all the phases execute twice is not going to be acceptable. Is there a way to stop the depdendency-plugin from causing the phases to execute again? We are using maven-dependency-plugin:2.0-alpha-4 and maven-2.0.7 William - 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: dependency-plugin without forking
Hi Eric, The use case is that we would like to ensure that the dependencies are the minimal set of the appropriate dependencies as an integral part of our build. Ie part of our quality bar. But looks like I'm not alone, as Brian pointed out dependency-plugin:2.0-alpha-5-SNAPSHOT has the just-analyze Mojo which does exactly what I need. William -Original Message- From: Eric Redmond [mailto:[EMAIL PROTECTED] Sent: Tuesday, 24 July 2007 11:22 PM To: Maven Users List Subject: [***POSSIBLE SPAM***] - Re: dependency-plugin without forking - Email has different SMTP TO: and MIME TO: fields in the email addresses dependency:analyze is meant to help people check their project dependencies occasionally and fix accordingly? What use-case do you have for requiring it to run every time? If you just want a print-out, there is always the dependency report. Eric On 7/23/07, William Ferguson [EMAIL PROTECTED] wrote: Is it possible execute dependency:analyze without having the dependency-plugin fork the build? We'd really like to have dependency:analyze execute as part of every build, but having all the phases execute twice is not going to be acceptable. Is there a way to stop the depdendency-plugin from causing the phases to execute again? We are using maven-dependency-plugin:2.0-alpha-4 and maven-2.0.7 William - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Eric Redmond http://blog.propellors.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
dependency-plugin without forking
Is it possible execute dependency:analyze without having the dependency-plugin fork the build? We'd really like to have dependency:analyze execute as part of every build, but having all the phases execute twice is not going to be acceptable. Is there a way to stop the depdendency-plugin from causing the phases to execute again? We are using maven-dependency-plugin:2.0-alpha-4 and maven-2.0.7 William - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
XML Schema for site.xml?
I'm creating customized sites for our projects and I was wondering: Is there an XML schema for site.xml? If so where can I find it? William - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Adding a phase to maven-release-plugin
Hi, I have a plugin that needs to be executed either 1) after the maven-release-plugin's scm-tag phase but before the scm-commit-development phase OR 2) after maven-release-plugin:prepare Option 1 is preferred as it would mean just 2 commits to the trunk during release. Option 2 would generate an extra commit. I think I can see how to do option 1, but it requires modifying the maven-release-manager. I believe just adding a phase in components.xml and the impl for it. But then I need to consider managing such a mod if it can't be folded back into the plugin. I'll probably push on this front in any case. But in the meantime, how do I couple 2 plugin's together to achieve option 2. Is there some way to specify that the release-plugin should always run before my plugin? William - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Determining project.version from maven-release-plugin
I have a plugin that needs to run either during after the
maven-release-plugin has doen a prepare.
I suspect after will be easier to manage.
My plugin needs as a minimum the ${project.version} at which the project
was released. Ie not the SNAPSHOT version either before or after.
How do I get that intermediate ${project.version}?
William
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Flushing the SCM password cache for Maven-SCM
Thanks Jorg. Any idea how I can get the Subversion userId and password from that config so my plugin can automtaically log into Subversion? I tried to follow how Maven-SCM does it, but got lost. William -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Monday, 14 May 2007 5:16 PM To: Maven Users List Subject: RE: Flushing the SCM password cache for Maven-SCM Hi William, William Ferguson wrote on Monday, May 14, 2007 6:43 AM: Where does maven-SCM cache my Subversion password and how can I get it to flush the cache? I have been having a little bit of trouble tagging using the release plugin. It fails with authorization problems, and has only been happening since my SVN paswword changed. The first time I used the SVN commandline after my password changed, SVN prompted me for my password and SVN works as expected. But mvn release:prepare doesn't prompt me for a new SCM password and fails during the tagging process with an auth failure. How do I get Maven-SCM to prompt for a new password? This is not Maven specific. All Subversion clients share the same configuration in ~/.subversion (or %USERHOME%/Application Data/Subversion). Caching is contained in the files beenath the auth directory. - Jörg - 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]
Flushing the SCM password cache for Maven-SCM
Where does maven-SCM cache my Subversion password and how can I get it to flush the cache? I have been having a little bit of trouble tagging using the release plugin. It fails with authorization problems, and has only been happening since my SVN paswword changed. The first time I used the SVN commandline after my password changed, SVN prompted me for my password and SVN works as expected. But mvn release:prepare doesn't prompt me for a new SCM password and fails during the tagging process with an auth failure. How do I get Maven-SCM to prompt for a new password? William - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: dependency management problems...
I was actually thinking that the validate phase would only compile a list of dependencies up to the furthermost lifecycle phase required by the list of goals specified. But I guess it amounts to the same thing. William -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, 4 May 2007 2:00 AM To: Maven Users List Subject: Re: dependency management problems... So essentially you'd break up and move the monolithic validate phase into a series of mini-validates that fire immediately before every other lifecycle phase, to validate the artifacts necessary for (only) that phase are available. I think it would complicate things a bit, but it doesn't sound unreasonable. Wayne On 5/2/07, William Ferguson [EMAIL PROTECTED] wrote: Interesting point. Aren't dependencies just compile time dependencies? So there is no need to resolve them unless your build includes the compile:compile goal. Plugin dependencies are only resolved if that plugin is required as part of the current build. So why do the (compile) dependencies need to be resolved if compilation is not part of the build? William -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Wednesday, 2 May 2007 1:24 PM To: Maven Users List Subject: Re: dependency management problems... As far as I know, you can't. Maven resolves all dependencies etc at the beginning of the lifecycle, so it can find all transitive artifacts etc and make sure EVERYTHING is available in the local cache before proceeding with the build. Wayne On 5/1/07, EJ Ciramella [EMAIL PROTECTED] wrote: Here's another way of phrasing this question - if a module has a dependency on another one, how do you stop it from attempting to download until absolutely necessary (say at compile time, NOT at process-resources time)? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 01, 2007 3:11 PM To: Maven Users List Subject: dependency management problems... We're having problems building modules like this from scratch. If we run process resources from the top most level, submodule.B complains about not being able to find module1's artifacts (why would submodule.B need module 1's jar artifact just to process resources?). parent - version 1.0-SNAPSHOT | |---module1 - version 1.0-SNAPSHOT | |---module2 - version 1.0-SNAPSHOT |---submodule.A- version 1.0-SNAPSHOT |---submodule.B- version 1.0-SNAPSHOT I'm really at the end of my rope on this one. The only way to successfully get this to go through is to run a mvn install from the top most level first. What's crazy is submodule.A has the same dependency and goes through just fine. - 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]
[m2] Out of date links to Maven projects
I just built a plugin with the following dependencies: org.apache.maven maven-plugin-api 2.0.6 org.apache.maven maven-project 2.0.6 org.apache.maven.shared file-management 1.1 While looking at the dependencies list on the generated site I notice that 7 of the 9 transitive Maven dependencies provide a project URL that is broken. Broken Maven project links: http://maven.apache.org/shared/file-management http://maven.apache.org/shared/maven-shared-io http://maven.apache.org/maven-project http://maven.apache.org/maven-profile http://maven.apache.org/maven-artifact-manager http://maven.apache.org/maven-repository-metadata http://maven.apache.org/maven-plugin-registry http://maven.apache.org/maven-artifact http://maven.apache.org/maven-plugin-api Congratulations to the members of 2 Maven projects that have kept their POMs up to date: http://maven.apache.org/maven-settings http://maven.apache.org/maven-model William - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Prepending a folder to a plugin's classpath
Sorry if this is a niave question, but I haven't had much success Googling it. We have a plugin that uses Velocity to generate some of our source. The plugin needs to look for overridden Velocity templates in a project specific location before using those contained within the plugin. At this point velocity has been configured to use the ClasspathResourceLoader. How can I ensure that the Plugin puts the project specific classpath resources ahead of the resources contained in the Plugin? Is there any Maven mechanism that can be used to prepend to the plugin classpath? Or do I need to set a new Classloader inside the plugin that looks for project resources before delegating to the pre-existing Classloader? And if so, does anyone know where to find such an inverted Classloader? William
RE: [***POSSIBLE SPAM***] - RE: Getting index.html of site generated automatically - Found word(s) list error in the Text body
Ian, are you saying that under the target/site folder you get project-info.html generated but not index.html? I also have no customisation of the site and get the following files generated at top level: dependencies.html index.html integration.html issue-tracking.html project-info.html project-summary.html source-repository.html William -Original Message- From: Ian Rowlands [mailto:[EMAIL PROTECTED] Sent: Thursday, 19 April 2007 10:18 PM To: Maven Users List Subject: [***POSSIBLE SPAM***] - RE: Getting index.html of site generated automatically - Found word(s) list error in the Text body Not sure what details you mean, so I'll make a guess! I'm running Maven 2.0.5, executing maven site:site on my projects (one parent project with a bunch of modules).Everything else seems to get generated in the site - the front page generated is the project-info.html file. Recently I cleaned the repository and tried it again, but the same result. The projects are Java 5 modules (web, ejb and other normal pieces). The reports I'm generating are Checkstyle, PMD, Javadoc, Cobertura, X-reference. There is no customisation of the site (don't dare to try that until I can get this to work!). Is that the information you want, or is there more that would be helpful? Any other suggestions? Regards, Ian - Message from William Ferguson [EMAIL PROTECTED] on Thu, 19 Apr 2007 09:29:07 +1000 - To: Maven Users List users@maven.apache.org Subject: RE: Getting index.html of site generated automatically Ian, I always get index.html generated by 'mvn site:site'. I'm using Maven-2.0.5 Can you provide more details? William -Original Message- From: Ian Rowlands [mailto:[EMAIL PROTECTED] Sent: Wednesday, 18 April 2007 5:25 PM To: users@maven.apache.org Subject: Getting index.html of site generated automatically When I do a site:site build of one of my projects, no index.html (or equivalent is generated). Is there a way to do this automatically, rather than put it an xdoc/index.xml in each individual project (this happens for all of the modules of the projects) as well? Regards, Ian Disclaimer: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from your computer. Privacy: If you are responding to this email or providing personal information to the SRO for the purposes of one of the Acts it administers, such information is used only for the purpose for which it was collected ( administration of SRO legislation ) and is protected by the Information Privacy Act 2000 and secrecy provisions contained in legislation administered by SRO. It is not disclosed otherwise than in accordance with the law. If you would like a copy of the SRO Privacy Policy please refer to SRO website (www.sro.vic.gov.au) or contact SRO on 9628 0556 and request a copy. - 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: Getting index.html of site generated automatically
Ian, I always get index.html generated by 'mvn site:site'. I'm using Maven-2.0.5 Can you provide more details? William -Original Message- From: Ian Rowlands [mailto:[EMAIL PROTECTED] Sent: Wednesday, 18 April 2007 5:25 PM To: users@maven.apache.org Subject: Getting index.html of site generated automatically When I do a site:site build of one of my projects, no index.html (or equivalent is generated). Is there a way to do this automatically, rather than put it an xdoc/index.xml in each individual project (this happens for all of the modules of the projects) as well? Regards, Ian Disclaimer: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from your computer. Privacy: If you are responding to this email or providing personal information to the SRO for the purposes of one of the Acts it administers, such information is used only for the purpose for which it was collected ( administration of SRO legislation ) and is protected by the Information Privacy Act 2000 and secrecy provisions contained in legislation administered by SRO. It is not disclosed otherwise than in accordance with the law. If you would like a copy of the SRO Privacy Policy please refer to SRO website (www.sro.vic.gov.au) or contact SRO on 9628 0556 and request a copy. - 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: Release Notes generation
But how do you get issues grouped by released version? Maven-changes-plugin provides a great list of issues for the projects, filtered by different criteria. So it could provide all open issues for instance. Maybe I'm missing something, but this isn't what you want for release notes. ReleaseNotes should contain all the resolved issues, grouped by released version, ordered from most recent to least recent. It might also contain a list of open issues. The maven-changes-plugin change:jira-report looks like it is retrieving enough information to do this, but I can't see how to configure it to produce release notes. Can anyone tell me? Alternatively, is there a plugin that does produce release notes (from JIRA). William -Original Message- From: Dennis Lundberg [mailto:[EMAIL PROTECTED] Sent: Sunday, 15 April 2007 6:46 AM To: Maven Users List Subject: Re: Release Notes generation That'd be the maven-changes-plugin then: http://maven.apache.org/plugins/maven-changes-plugin/ Pankaj Tandon wrote: Thanks Dennis, That was really helpful. However, is there a report plugin that produces release notes as against a change log. Actually, I've seen the report such a plugin produces on the site of one of the maven projects (maybe one of the plugins). I just can't seem to find it now. The report has a bugs, enhancements, wishlist and a features section, all broken out by release. This changelog plugin doesn't seem to produce this kind of report. Ofcourse, we are using the maven-release-plugin to produce the releases. Any suggestions what plugin produces that report? Thanks, Pankaj dennisl-2 wrote: Pankaj Tandon wrote: Hello, I'd like to generate release notes as a part of my mvn site command. If I annotate the site.xml with the following: menu name=Maven 2.0 item name=Introduction href=index.html/ item name=Download href=download.html/ item name=Release Notes href=release-notes.html / item name=General Information href=about.html/ item name=For Maven 1.0 Users href=maven1.html/ item name=Road Map href=roadmap.html / /menu It certainly creates the menu correctly. However, where is the plugin that will actually create the release-notes.html? I tried project-info-reports:scm but that looks like a dead-end to me as far as release note generation goes. Any help is appreciated. Thanks Pankaj You might be looking for maven-changelog-plugin: http://maven.apache.org/plugins/maven-changelog-plugin/ -- Dennis Lundberg - 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]
RE: [NEWSENDER] - Re: maven-release-plugin getiing SCM values - Message is from an unknown sender
Sorry Emmanuel, My post *should* have read : 1) If the SCM user/password has NOT been been explicitly configured in your POM or Settings, how does the maven-release-plugin discover the username/password of the current user ... With regards to determining the revision that is tagged, I need the actual revision number as this needs to be part of the vaolue stamped into the subclipse:tags property. So I should interrogate the working copy for its revision? William -Original Message- From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Sent: Thursday, 5 April 2007 5:40 PM To: Maven Users List Subject: [NEWSENDER] - Re: maven-release-plugin getiing SCM values - Message is from an unknown sender William Ferguson a écrit : Can someone please enlighten me on 1) If the SCM user/password has been been explicitly configured in your POM or Settings, how does the maven-release-plugin discover the username/password of the current user to supply to the SCM Eg Subversion)? I need this becxause my plugin will have to use javaSVN and needs to authenticate. It should be in the scm url. 2) How do you determine the revision of the code that the maven-release-plugin will tag? I assume the head but a check-in could have occured since the maven-release-plugin took a copy for the tag. We tag the working copy, so the code you release will be the code tagged. Emmanuel - 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]
maven-release-plugin getiing SCM values
Can someone please enlighten me on 1) If the SCM user/password has been been explicitly configured in your POM or Settings, how does the maven-release-plugin discover the username/password of the current user to supply to the SCM Eg Subversion)? I need this becxause my plugin will have to use javaSVN and needs to authenticate. 2) How do you determine the revision of the code that the maven-release-plugin will tag? I assume the head but a check-in could have occured since the maven-release-plugin took a copy for the tag. William
Retrieving info from maven-release-plugin
I have a plugin whose Mojo is executed as part of the maven-release-pluigin preparationGoals (see http://maven.apache.org/plugins/maven-release-plugin/examples/run-goals- before-commit.html) The Mojo executes OK, but I need to extract some of the info that has been accumulated by the maven-release-plugin. Namely the SCM release tag specified by the user. How do I get hold of this information inside my Mojo? William
RE: [***POSSIBLE SPAM***] - WAR Archiver: avoiding JAR files in WEB-INF/lib - Bayesian Filter detected spam
The scope you want is 'provided'. See http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html for more details on specifying dependencies. William -Original Message- From: Gonzalo Vásquez Sáez [mailto:[EMAIL PROTECTED] Sent: Tuesday, 3 April 2007 4:29 AM To: users@maven.apache.org Subject: [***POSSIBLE SPAM***] - WAR Archiver: avoiding JAR files in WEB-INF/lib - Bayesian Filter detected spam Is there any way to tell some dependencies just to be used on the compile phase and not to be included in the run phase during a WAR packaging? I have some Application Server specific JAR files needed during compile time (IBM WAS 6), but which they don't need to be included in the WAR itself, as they would be already accessible from the AppServer's classpath. Perhaps some other scope / other than compile, or some special plugin? Thanks.- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] Maven-release-plugin subclipse:tags property
Hi, we use SubVersion as our SCM, Eclipse as IDE and plan on using the maven-release-plugin to manage our release process. When we tag using the SubVersion Eclipse plugin (Subclipse), it updates the 'subclipse:tags SVN property on the target folder appending the tag just created. This is a handy feature to help map changes to releases at the source level. I'm sure there are plenty of teams using the same set of products as us and presumably attempting to use this kind of functionality. So I was wondering whether someone had already solved the problem of how to configure the maven-release-plugin to ensure the subclipse:tags property is updated as part of the release? William
[m2] TagListReport - AbstractMethodError
Does anyone know why I get: [WARNING] Error loading report org.apache.maven.plugin.taglist.TagListReport - AbstractMethodError: canGenerateReport() when executing 'mvn site' with the taglist-maven-plugin? plugin groupIdorg.codehaus.mojo/groupId artifactIdtaglist-maven-plugin/artifactId version2.0-beta-1/version /plugin The Taglist report is generated just fine. Just not sure why I'm getting the warning. William - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [***POSSIBLE SPAM***] - How to create multiple jar files from one project? - Bayesian Filter detected spam
Peter, I don't think a Maven solution is what you need. I think you need to rethink the packaging and dependencies of your 2 projects. It sounds like your interface project shouldn't depend on the Factory in the implementation project. You could organise this a couple of different ways: 1) The Factory class could ship with interface project. 2) Ship a Factory interface with your interface project, and ship the Factory impl in the other project. Hope this helps. William -Original Message- From: Peter Palmreuther [mailto:[EMAIL PROTECTED] Sent: Sunday, 3 December 2006 9:01 PM To: Maven Users List Subject: [***POSSIBLE SPAM***] - How to create multiple jar files from one project? - Bayesian Filter detected spam Hello, I'm new to Maven and tried to find an answer on the website, but either I'm to dense or it ain't there (yet). So if this question is already answered in a public available document I'd be happy to get the link. I have a project that should be a library to encapsulate the logger being used in all other projects. From this project I create two JAR files: one containing the interface(s) and a factory, the other one containing the implementation classes. By now I'm trying to switch to use Maven2 for project management and dependency tracking, but I'm still unable to get the two jars out of Maven build process. Therefore I've tried to split the project up into two projects to have two artifacts. But than I end up in a cyclic dependency: Interface project depends on implementation project for the factory to compile; Implementation project depends on interface project for the implementation class to compile (Class implements Interface). A deadlock :-( Anybody out there with an idea how to solve this problem the Maven2 way? I'd be happy with a hint on - either how to influence the packaging process for getting two JARs (artifacts?) from one POM - or how to tell the two Maven2 projects they belong somehow together for dependency resolution in a way it's done as if this were one project Thanks a lot in advance, -- Best regards Peter Palmreuther Bother, said Pooh as he found he'd used a dirty needle - 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: Can a project use a plugin that is part of the project - bootstrap issue
Matt, There was a similar post over the weekend http://www.nabble.com/Impossible-to-build-ourproject-from-scratch-tf2519 755s177.html#a7027880 Hope it helps. William -Original Message- From: J. Matthew Pryor [mailto:[EMAIL PROTECTED] Sent: Tuesday, 31 October 2006 9:18 AM To: Maven Users List Subject: Can a project use a plugin that is part of the project - bootstrap issue I am trying to work through a boot-strap issue. Currently we have a multi-project that includes a maven-plugin module that is then used to build other modules in the multi-project. As you might expect a clean checkout build at the top-level fails because mvn says it can't find the plugin in question (it hasn't been built yet). Is there any way to do this? Or do I have to break the plugin out into its own project build it separately? Thanks, Matthew p.s. I posted this question once before but did so as a reply and was worried it got lost in that noise, apologies for the duplication - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [POLL] Why switch to Maven?
I think a good solution to the problem would be more frequent milestone builds (both core and plugins), and a publicly available road map, giving people a good indication of when they can expect to see what released. +1 to that. If Maven could help provide greater visibility on when the next release is planned and what is incorporated and if there was general progression to release smaller offerings more regularly I think all projects would benefit. William - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Plugin Development Issue
To allow your parameter to be specified from the command line yoour
parameter specification needs to define the name of the commandline
parameter that it will accept. Eg
/**
* @parameter expression=${foo.bar}
*/
private String verbose;
Should work with a commandline of
mvn cleartrust:extract -Dfoo.bar=Testing
The POM configuration should work.
Are you sure you've defined the verbose element within your plugin
definition's configuration block?
William
-Original Message-
From: Marc L. Veary [mailto:[EMAIL PROTECTED]
Sent: Friday, 25 August 2006 4:57 PM
To: 'Maven Users'
Subject: Plugin Development Issue
Hi,
I have developed a very simple plugin that does nothing.
(code included below).
The problem is that I cannot seem to pass in a parameter
either on the command line or via a POM (in another project
that defines this plugin in the build section):
mvn cleartrust:extract -Dverbose=Testing
or
configuration
verbosetesting/verbose
/configuration
Could someone point me in the right direction here?
package uk.co.nwlcoc.aa.maven.plugins;
import org.apache.maven.plugin.AbstractMojo;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.plugin.MojoFailureException;
/**
* @goal extract
* @phase package
* @author Marc
* @version $LastChangedRevision$
*/
public class ClearTrustMojo extends AbstractMojo {
/**
* @parameter
*/
private String verbose;
public void execute() throws MojoExecutionException,
MojoFailureException
{
getLog().info( + verbose );
}
}
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIduk.co.nwlcoc.aa.maven.plugins/groupId
artifactIdmaven-cleartrust-plugin/artifactId
packagingmaven-plugin/packaging
version1.0-SNAPSHOT/version
nameClearTrust Mojo/name
dependencies
dependency
groupIdorg.apache.maven/groupId
artifactIdmaven-plugin-api/artifactId
version2.0/version
/dependency
/dependencies
/project
Kind regards,
--
Marc
-
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]
[m2] How to package a WebService?
Hi, I want to package up my Axis2 WebService as a WebService archive (aar). How do I go about it? Is there a particular value for the project#packaging attribute or a particular plugin that I need to use? William - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] phases and goals
Can someone point me to some doco that explains a phase, goal and mojo and lists the available phases. I thought I vaguely understood, but have become confused by the thread on binding mojos to lifecycle. William - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
