Re: M2Eclipse -workspace resolution
On Thu, Apr 24, 2008 at 12:46 AM, Salgar, Mehmet (external) [EMAIL PROTECTED] wrote: snip I would try to find the JIRA for m2eclipse and write this there... snip Sounds like you may be running into this (or a variation of)... http://jira.codehaus.org/browse/MNGECLIPSE-438
Re: Repository search order
On Fri, Apr 11, 2008 at 12:42 PM, Jason van Zyl [EMAIL PROTECTED] wrote: This is another classic example of why using a repository manager is a good thing. You can specify repositories in one central place, and with Nexus you can order, group, and route which means you can get certain artifacts from particular repositories if you so choose. Using Nexus will also help you manager all your repository use from one location. If you're a lone developer then this isn't much of an advantage, but if there is a team then using a repository manager has definite advantages. You can read about repository managers here: http://www.sonatype.com/book/reference/repository-manager.html# I've not tried using a repository manager for a while, so maybe I'm not understanding/remembering something, but is there a way to use a repository manager without making your builds dependent upon the correct configuration in settings.xml and on the repository manager being available? I don't version my settings.xml with my project source code, and we don't necessarily share a common settings.xml in our team, so depending on settings in there makes the build potentially non-repeatable and environmentally sensitive. I also tend to work disconnected from the company network quite a bit, so depending upon a corporate repository manager in order for the builds to work correctly can also be an issue (e.g. if Nexus is grouping several repositories under one URL, people are likely to miss adding the appropriate repository definition to the POM, and also the issue of artifacts in central also being in some 3rd party repositories - maybe with different content - which Nexus can work around - if I'm not using the Nexus proxy/mirror, maybe I'll pick up different artifacts). I think these were the issue I ran into last time around. I'll have to give it a go again - but has anyone else run into similar issues using repository managers, and if so, how do you work around them? Thanks, Mark
Re: [IMPORTANT] Maven 2 Plugin Auto-Versioning Considered Dangerous
On 4/15/07, John Casey [EMAIL PROTECTED] wrote:
Did you file a jira issue for this? If your assembly broke, then I'm
assuming there was some behavior change from 2.1 - 2.2-beta-1 that got you
in trouble...I think that even if we're not going to fix it, we should have
some doco for it...
So, would you file a JIRA for this?
Thanks,
john
My first issue seems to be covered by an existing issue. I am seeing
that for dependencies that I want unpacked into the assembly, the JAR
name is being used as part of the path - i.e. one-jar-boot-0.95.jar is
being unpacked into /one-jar-boot-0.95.jar/*. This is covered by
http://jira.codehaus.org/browse/MASSEMBLY-179.
My second issue is a little odd. The current project artifact is not
being included by my dependency set:
dependencySet
includes
include
${project.groupId}:${project.artifactId}
/include
/includes
outputDirectory/main/outputDirectory
unpackfalse/unpack
scoperuntime/scope
/dependencySet
This seems like it may be related to the current project's artifact
being associated with no scope, so maybe it's something I'm doing
wrong (I copied someone else's one jar assembly from the mailing
list archives, so maybe I don't fully understand it!). Here's the
relevant log messages (from 2.2-beta-1):
---
[INFO] Processing DependencySet (output=/main)
[DEBUG] com.firstdata.fdcs:CryptoUtil:jar:1.3-SNAPSHOT (selected for null)
[DEBUG] junit:junit:jar:3.8.1:compile (selected for compile)
[DEBUG] log4j:log4j:jar:1.2.14:compile (selected for compile)
[DEBUG] com.simontuffs:one-jar-boot:jar:0.95:runtime (selected for runtime)
[DEBUG] While resolving dependencies of
com.firstdata.fdcs:CryptoUtil:jar:1.3-SNAPSHOT:
[DEBUG] Statistics for Scope filter [compile=true, runtime=true,
test=false, provided=false, system=false]
[DEBUG] The following scope filters were not used:
o Test
o Provided
o System
[DEBUG] log4j:log4j:jar:1.2.14 was removed by one or more filters.
[DEBUG] com.simontuffs:one-jar-boot:jar:0.95 was removed by one or more filters.
[DEBUG] junit:junit:jar:3.8.1 was removed by one or more filters.
[DEBUG] Statistics for Includes filter:
o 'com.firstdata.fdcs:CryptoUtil'
[WARNING] The following patterns were never triggered in this artifact
inclusion filter:
o 'com.firstdata.fdcs:CryptoUtil'
[DEBUG] The following artifacts were removed by this artifact inclusion filter:
log4j:log4j:jar:1.2.14
com.simontuffs:one-jar-boot:jar:0.95
junit:junit:jar:3.8.1
---
The com.firstdata.fdcs:CryptoUtil artifact is copied into the /main
directory using 2.1, but with 2.2-beta-1 the /main directory is not
even created.
I'll see if I can make more sense of this and maybe create an example
project and create a JIRA for it.
Thanks,
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IMPORTANT] Maven 2 Plugin Auto-Versioning Considered Dangerous
On 4/11/07, John Casey [EMAIL PROTECTED] wrote: snip I'm sure many people have hit this plugin-versioning problem before... snip The first time this has really bit me in the rear is when the assembly plugin 2.2-beta-1 hit central, and my formerly working assembly went all to hell. Almost like you planned it! ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Skipping Tests but Still Compiling
On 1/30/07, Bashar Abdul Jawad [EMAIL PROTECTED] wrote: That is not true. Maven will still compile the test classes, but only if they have changed since the last compilation. To force maven to compile even if there were no changes run a clean first. Bashar Doesn't seem to for me... mvn -Dmaven.test.skip=true clean install lines deleted [INFO] [compiler:testCompile] [INFO] Not compiling test sources [INFO] [surefire:test] [INFO] Tests are skipped. lines deleted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Continuum behind Apache Proxy
On 9/28/06, Vivian Stelller [EMAIL PROTECTED] wrote: Hello at all, I want to setup continuum in a subdomain of my Apache 2.0.x managed domain. It should appear on http://continuum.eecoo.net Not sure if this will help, but here's how I'm doing it (which ends up with continuum being at http://scm.example.com/continuum/ VirtualHost *:80 ServerName scm.example.com ... RewriteEngine on # Proxy Continuum RewriteRule ^/continuum$ continuum/ [R] ProxyPass /continuum/ http://localhost:8090/continuum/ ProxyPassReverse /continuum/ http://localhost:8090/continuum/ /VirtualHost Mark
Re: [m2] eclipse attached sources for snapshot builds
On 8/7/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: great, that's it! But now the javadoc source is also generated, is it possible to switsh it off? the javadoc location in eclispse is not updated ;-( Fredy If you take a look at the super POM at http://maven.apache.org/guides/introduction/introduction-to-the-pom.html you can see what the -DperformRelease=true is doing - i.e. it enables a profile that configures the maven-source-plugin and maven-javadoc-plugin to generate the appropriate JARs. What I did, to always generate source and javadoc JARs during my builds, is to copy the configurations for those two plugins to my organization POM. You could just add the maven-source-plugin configuration to your POM if you always want a source JAR generated. Hope that helps. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.0 Eclipse Plug-in compatibility with Eclipse 3.2.x (and IBMRAD 6.x)
On 7/28/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Actually I get appears whenever I now access the Eclipse preferences dialog e.g. MenuBar - Windows - Preferences. Plug-in org.maven.ide.eclipse was unable to load class org.maven.ide.eclipse.preferences.Maven2PreferencePage. Peter, Check that you have a .m2 directory in the default location (~/.m2, C:\Documents and Settings\userid\.m2). See http://jira.codehaus.org/browse/MNGECLIPSE-124. Hope this helps, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] Custom built org.apache.maven.plugins.* plugins
I'm having an issue with some custom built plugins - I'm taking a SNAPSHOT version of a plugin (e.g. maven-jar-plugin-2.1-SNAPSHOT) from SVN, modifying the version to be a release (e.g. 2.1-417949, using the svn version for the number) and building the plugin and deploying it into an in-house remote plugin repository (this is so we can use the release plugin, which doesn't like SNAPSHOTs). I have referenced this plugin repository in our organization POM: pluginRepositories pluginRepository idcustom/id nameCustom Built Plugin Repository/name urlhttp://my.server.com/maven/custom/url layoutdefault/layout releases enabledtrue/enabled updatePolicydaily/updatePolicy checksumPolicywarn/checksumPolicy /releases snapshots enabledfalse/enabled /snapshots /pluginRepository /pluginRepositories Everything works fine *as long as* this custom build is also installed in the local repository. If it is not installed in the local repository it doesn't seem to download correctly from the remote custom plugin repository and the build fails. Also, in my local repository I am left with just the JAR and not the POM for the plugin. I can also get this to work if I use our central proxy (using Proximity) to also proxy this custom repository - I suppose because then the custom version is in central, as far as mvn knows. My reason for not wanting to do this is so that if someone doesn't have their mirror settings set up to point to our proxy then things should still work because the custom build is in a specifically defined plugin repository. i.e. the central mirror contains *only* central artifacts and nothing else. So, is there a way to deploy custom builds of org.apache.maven.plugins.* plugins to an internal remote repository? I had a search through the archives and it seems that maybe others have seen this, but previous messages seemed to imply that the issue was resolved. Am I just doing something wrong or is there a real issue here? Hopefully this makes sense - let me know if I need to clarify anything! Thanks, Mark Here's the partial output from mvn clean package on our project that should use the custom maven-jar-plugin version. (this is edited a little to remove company specifics - just paths, URLs etc.) ... [INFO] artifact org.apache.maven.plugins:maven-jar-plugin: checking for updates from custom [INFO] artifact org.apache.maven.plugins:maven-jar-plugin: checking for updates from central [DEBUG] maven-jar-plugin: resolved to version 2.1-417949 from repository central [DEBUG] Trying repository central Downloading: http://my.server.com/proximity/repository/org/apache/maven/plugins/maven-jar-plugin/2.1-417949/maven-jar-plugin-2.1-417949.pom [DEBUG] Artifact not found - using stub model: Unable to locate resource in repository org.apache.maven.plugins:maven-jar-plugin:pom:2.1-417949 from the specified remote repositories: central (http://repo1.maven.org/maven2), custom (http://my.server.com/maven/custom) [DEBUG] Using defaults for missing POM org.apache.maven.plugins:maven-jar-plugin:pom:2.1-417949 [DEBUG] Trying repository fdsecure-custom Downloading: http://my.server.com/maven/custom/org/apache/maven/plugins/maven-jar-plugin/2.1-417949/maven-jar-plugin-2.1-417949.jar 20K downloaded [DEBUG] Artifact resolved ... [DEBUG] org.apache.maven.plugins:maven-jar-plugin:maven-plugin:2.1-417949:runtime (selected for runtime) - this realm = app0.child-container[org.apache.maven.plugins:maven-jar-plugin] urls[0] = file:/C:/maven-repo/org/apache/maven/plugins/maven-jar-plugin/2.1-417949/maven-jar-plugin-2.1-417949.jar Number of imports: 0 this realm = plexus.core.maven urls[0] = file:/G:/bin/maven-2.0.4/bin/../lib/commons-cli-1.0.jar urls[1] = file:/G:/bin/maven-2.0.4/bin/../lib/doxia-sink-api-1.0-alpha-7.jar urls[2] = file:/G:/bin/maven-2.0.4/bin/../lib/jsch-0.1.24.jar urls[3] = file:/G:/bin/maven-2.0.4/bin/../lib/maven-artifact-2.0.4.jar urls[4] = file:/G:/bin/maven-2.0.4/bin/../lib/maven-artifact-manager-2.0.4.jar urls[5] = file:/G:/bin/maven-2.0.4/bin/../lib/maven-core-2.0.4.jar urls[6] = file:/G:/bin/maven-2.0.4/bin/../lib/maven-error-diagnostics-2.0.4.jar urls[7] = file:/G:/bin/maven-2.0.4/bin/../lib/maven-model-2.0.4.jar urls[8] = file:/G:/bin/maven-2.0.4/bin/../lib/maven-monitor-2.0.4.jar urls[9] = file:/G:/bin/maven-2.0.4/bin/../lib/maven-plugin-api-2.0.4.jar urls[10] = file:/G:/bin/maven-2.0.4/bin/../lib/maven-plugin-descriptor-2.0.4.jar urls[11] = file:/G:/bin/maven-2.0.4/bin/../lib/maven-plugin-parameter-documenter-2.0.4.jar urls[12] = file:/G:/bin/maven-2.0.4/bin/../lib/maven-plugin-registry-2.0.4.jar urls[13] = file:/G:/bin/maven-2.0.4/bin/../lib/maven-profile-2.0.4.jar urls[14] = file:/G:/bin/maven-2.0.4/bin/../lib/maven-project-2.0.4.jar urls[15] = file:/G:/bin/maven-2.0.4/bin/../lib/maven-reporting-api-2.0.4.jar urls[16] = file:/G:/bin/maven-2.0.4/bin/../lib/maven-repository-metadata-2.0.4.jar
Re: settings.xml activation activeByDefault setting
On 7/19/06, Max Cooper [EMAIL PROTECTED] wrote: Mykel, I am glad you posted your experience! I tried an empty activeByDefault/ the same way you did and assumed that it didn't work. I ended up listing the profile I wanted active in activeProfiles. And then setup an example settings.xml for the rest of my team to active the profile this way. So now my whole team is missing out on the simpler activeByDefault tag. If I had only known... :-) -Max And I did exactly the same thing! I wonder if at some point one of the examples had the empty activeByDefault/ tag? Anyway, my thanks also to Mykel for showing the solution. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] release:perform checkout vs. export (with Subversion)
When doing a release:perform the tagged version is checked out into target/checkout. This causes some issues with Subclipse - you end up with a Subversion working copy nested within a Subversion working copy, and even though the target directory is marked as ignored this causes new resources created under target/checkout during the build (in my case, cobertura.ser) to show up during a Team/Synchronize with Repository operation in Eclipse, and also causes the operation to take much longer. I'm told (on the Subclipse list) that if Maven 2 did an export instead of a checkout that this would not be an issue, performance would be improved (since the exported resources are not versioned at all the status would not be checked) and disk space would be saved (since you don't have a full working copy with export - just the actual resources). This applies to Subversion. I'm not sure if it also applies to CVS, although with export at least you would save creating the .CVS directories. So, any reason that release:perform can't use export instead of checkout? Should this be asked on the dev list instead (I'm not subscribed, and I don't see a way to search the archives to see if this has come up already). Thanks, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] release:perform checkout vs. export (with Subversion)
On 7/17/06, Mike Perham [EMAIL PROTECTED] wrote: release:perform just uses the scm:checkout command. There's no scm:export command. Ahh, and it seems that someone has already requested that export be added: http://jira.codehaus.org/browse/SCM-210 Maybe it's time to roll up my sleeves and see how hard it would be to add this. Hopefully there is a common base class for the providers that can just delegate export() to checkOut(). Thanks for the pointer. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Mojo development: access to resources inside the plugin
Maybe you can pack your foo directory structure into a JAR that gets
put into your plugin JAR. You can then try something like:
InputStream is = this.getClass().getClassLoader().getResourceAsStream(
/foo.jar );
JarInputStream jis = new JarInputStream(is);
JarEntry je = null;
while ((je = jis.getNextJarEntry()) != null) {
// write jar entry to file system
}
Note that this is completely untested (not even compiled!), and you
will have to write code to extract each file from the JAR (or google
it), but hopefully it's something that might work for you.
Mark
On 7/16/06, Sebastien Arbogast [EMAIL PROTECTED] wrote:
I tried that, based on Dennis' proposition:
URL url = this.getClass().getClassLoader().getResource( /foo );
try {
File servlet = new File(url.toURI());
getLog().info(servlet.getAbsolutePath());
} catch (URISyntaxException e) {
throw new MojoExecutionException(e.getMessage(),e);
}
But then I got an exception on the first line of the try block:
java.lang.IllegalArgumentException: URI is not hierarchical
I was thinking of using IOUtils to copy the content of foo to another
directory but it seems to be harder than I thought.
2006/7/16, dan tran [EMAIL PROTECTED]:
Thanks
On 7/16/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
It depends on what you want to do with the resource.
I used it with
FileUtils.copyURLToFile( url, new File( outputDirectory, filename ) );
to copy a resource from within the jar file to the target directory.
--
Dennis Lundberg
dan tran wrote:
Dennis, would you suggestion work? since the resource is in a jar,
and therefore obtaining a File object is not possible.
am I missing something?
-D
On 7/16/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
Sebastien Arbogast wrote:
In the plugin I'm working on, I have a src/main/resources/foo
directory and as a result, when the plugin is packaged, I get a foo
directory at the root of the plugin jar, and that's fine.
But now I want to get a java.io.File reference to this foo directory
from inside the code of one of my mojos. How can I do that?
You can get a URL which can then be used to create a file like this:
URL url = this.getClass().getClassLoader().getResource( /foo );
--
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]
--
Sébastien Arbogast
http://www.sebastien-arbogast.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]
[m2] release:prepare generateReleasePoms?
I have been trying to work out how to use release:prepare to create reproducible releases of our projects - i.e. trying to get a release-pom.xml generated with the versions of all the plugins resolved (as documented in the Mergere book and the plugin documentation). It seems like I should just specify -DgenerateReleasePoms=true (not sure why this wouldn't be the default), but this doesn't seem to result in a release-pom.xml being checked into the release-tag version in my SCM. After not being able to get it to work, I had a look at the code for the release plugin and it seems that the code in GenerateReleasePomsPhase.java that would actually do anything (other than printing out Generating release POMs...) is all commented out! I guess this would explain the results I am seeing, but does anyone know why this is the case? If this really isn't implemented, should we at least update the documentation to indicate this? Also, if anyone can confirm if the commented code worked at some point maybe I can take a look at it and see if it still works. Thanks, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] maven-jar-plugin-2.1 status?
Is there any estimate on when there will be a release build of the maven-jar-plugin-2.1 - even if it is a beta release build? We are using this to create signed JAR files, and so we are relying on the snapshot build on http://svn.apache.org/maven-snapshot-repository. However, this seems to stop us from using the release plugin for releasing our internal code. Alternatively, we could build an internal release version and deploy to our internal repository. Is there a versioning standard for internal release builds so that we would pick up any future release builds on the official repo? I'm thinking something like 2.1-INTERNAL1, but I'm afraid this would be seen as a later version than say 2.1-BETA1. Thanks, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [maven2] Generating several artifacts per project ?
You may be able to use the assembly plugin to do something like what you want - although I'm not sure if the extra jars will make it into your repository so that you could depend on them in other projects. Bind the assembly:attached target into your build process in your pom.xml with something like: ... build plugins plugin artifactIdmaven-assembly-plugin/artifactId executions execution goals goalattached/goal /goals phasepackage/phase /execution /executions configuration descriptors descriptorsrc/main/assembly/client.xml/descriptor descriptorsrc/main/assembly/server.xml/descriptor descriptorsrc/main/assembly/util.xml/descriptor /descriptors /configuration /plugin /plugins /build ... The client/server/util.xml files should be something like (see documentation for the assembly plugin at http://maven.apache.org/plugins/maven-assembly-plugin/introduction.html)... assembly idclient/id formats formatjar/format /formats includeBaseDirectoryfalse/includeBaseDirectory fileSets fileSet includes includetarget/classes/my/package1/**/include includetarget/classes/my/package2/**/include /includes /fileSet /fileSets /assembly This should build the extra jars in your target directory during the package phase. Hope this is helpful, and if anyone more experienced than me has any input on this method (like it sucks! :-), please let me know. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Location of cobertura-maven-plugin?
On 4/20/06, Sean McNamara [EMAIL PROTECTED] wrote: Simple question: Can anyone point me to the location of the cobertura-maven-plugin? I can't seem to find it in any of the online repositories. thanks! I think it's only in the snapshots repository at the moment. http://snapshots.maven.codehaus.org/maven2/org/codehaus/mojo/cobertura-maven-plugin/ Just about to try it out myself! Docs are at http://mojo.codehaus.org/cobertura-maven-plugin/. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Location of cobertura-maven-plugin?
No problem. I just tried it out and have a very nice report, so many thanks to the people working on this plugin! I should have mentioned that you can add the following to your POM to enable the snapshot repository, in case you haven't done this before. pluginRepositories pluginRepository idsnapshots/id urlhttp://snapshots.maven.codehaus.org/maven2/url /pluginRepository /pluginRepositories - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] How to sign a jar file
We are using the following.
plugin
artifactIdmaven-jar-plugin/artifactId
executions
execution
goals
goalsign/goal
/goals
/execution
/executions
configuration
jarpath${project.build.directory}/${project.build.finalName}.jar/jarpath
signedjar${project.build.directory}/signed/${project.build.finalName}.jar/signedjar
keystore${keystore.location}/keystore
storepass${keystore.storepass}/storepass
keypass${keystore.keypass}/keypass
alias${keystore.alias}/alias
/configuration
/plugin
The keystore properties are defined in our parent POM, but you can
just hard code them
You will also need to enable snapshots, since this needs the
2.1-SNAPSHOT version of the maven-jar-plugin. See
http://maven.apache.org/guides/development/guide-testing-development-plugins.html.
This also seems to install the signed JAR into the repository, in
place of the unsigned JAR.
Hope this helps.
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m202] eclipse plugin not running install correctly on multiproject?
On 2/3/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: snip I searched google and jira and found no hits. Has anyone else seen this behavior? This has come up on the [EMAIL PROTECTED] list. Probably worth creating a Jira entry for it, although I'm not sure if this is caused by the m2eclipse plugin or the Maven Embedder. I think the work around for now is to use an External Tool, as you have already discovered. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
