assembly plugin sign all dependented jars
I would like to produce a tar with my project artifact and all its dependents jars jarsigned. Also, I would like to deploy the tar as attachment. I used assembly plugin and write my own descriptor. However, I don’t know how to sign all the jars before the tar is created. I did try create the assemble as dir(instead of tar), call antrun to sign and create the final tar. However, Maven will not include the tar as attachment. Thanks -- View this message in context: http://maven.40175.n5.nabble.com/assembly-plugin-sign-all-dependented-jars-tp3328397p3328397.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Where is the global settings.xml for built-in (embedded) Maven in Eclipse?
Eclipse says: Embedded Runtime is always used for dependency resolution, but does not use global settings when it is used to launch Maven. So i think, there is just no global configuration file for this runtime, because it doesn't use one. You have to use the user configuration file or an external Maven. Manuel - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: assembly plugin sign all dependented jars
On 5 January 2011 08:22, xtonic davidptw...@gmail.com wrote: I would like to produce a tar with my project artifact and all its dependents jars jarsigned. Also, I would like to deploy the tar as attachment. I used assembly plugin and write my own descriptor. However, I don’t know how to sign all the jars before the tar is created. I did try create the assemble as dir(instead of tar), call antrun to sign and create the final tar. However, Maven will not include the tar as attachment. use http://maven.apache.org/plugins/maven-antrun-plugin/tasks/attachArtifact.htmlto attach the artifact Thanks -- View this message in context: http://maven.40175.n5.nabble.com/assembly-plugin-sign-all-dependented-jars-tp3328397p3328397.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: The master password
OK, will likely soon be included in a plugin coming to a repo close to you...:-) /Anders On Tue, Jan 4, 2011 at 23:21, Brett Porter br...@apache.org wrote: I believe if you regenerated another settings-security.xml file with the same master password, while the hash would be different it would effectively decrypt the passwords. However, you make a good point - automatically generating it would be a nice additional feature. - Brett On 04/01/2011, at 7:40 PM, Anders Hammar wrote: Is there any reason why I would need to remember my master password (used for encrypting my server passwords in settings.xml)? I haven't found any and I'm thinking that it could be auto-generated (by some tool) when creating settings-security.xml, instead of specified by the user. /Anders -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Exclusion does not work when using dependencies generated using assembly plug in
What do you mean when you say that the exclusions don't get excluded when you build from the root? The subject mentions the assembly plugin, but I don't see that mentioned in your structure. More info, please! /Anders On Wed, Jan 5, 2011 at 01:36, Anand HS anan...@gmail.com wrote: Hi, I have a project with the following structure - ROOT - ModuleA - GeneratedDistribution.jar - Several Dependencies - ModuleB - Several Dependencies - Depends on GeneratedDistribution.jar - ExclusionofDependenciesofModuleA Now When i build from ROOT, the exclusions do not really get excluded. However, when i build from inside ModuleB, the exclusions get excluded. I use Maven 2.0.9 but have also tried on 2.0.10 and the problem exists. Any solution on how to ensure a uniform behavior of ModuleA's dependencies to be excluded from ModuleB. would be appreciated Thanks, Anand
Our IP Was blocked
Hello; I was working on a project for our custom needs about dependency management. I have written a program that traverses the repo1.maven.org and list all the available artifacts. Unfortunately I'm not able access repo1.maven.org any more. Our company uses maven in many projects for build scripting. Hence it is essential for our company. I'm sorry for causing any problems. Can anyone restore our ip address or addresses. Our IP addresses are below: 95.9.74.92 88.249.20.72 78.187.132.76 Thank You Best Regards. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Indirect dependency of sub modules problem.
Thank you Anders and Zac. The project was originally managed by Ant (by other man), and I'm porting that project to maven now. I don't change module structure yet, but probably the time to change will come soon. The manager is standalone data server that manage whole configurations of the system. Other subsystems get their initual configs from manager by using manager's clientAPI. The utils:config is a library that integrate config values from manager, local config file, VM arguements or environmental variables, so depend on manager:clientAPI. I found that other modules of utils don't depend on config, and it's possible to wipe out dependency on config from manager:*. I'll pick config out from utils. 2011년 01월 05일 13:27, Zac Thompson 쓴 글: I agree with Anders that your structure should probably be modified. I am also suspicious of the utils/config component. I highly doubt that it should be dependent on clientAPI. I find myself questioning if it should exist at all. 1) I think utils/config should not be dependent on clientAPI, or ... 2) ... else config does not belong as a utils component and is really part of mid/manager, or ... 3) ... else clientAPI does not belong as part of mid/manager and should be in its own project at the same level as utils and mid However, if you change your hierarchy to be completely flat (all modules become siblings at the same level), then your problems will go away for now. On Mon, Jan 3, 2011 at 11:20 PM, Anders Hammarand...@hammar.net wrote: What version of Maven are you using? Have you tried 3.0.1? Out of a module design perspective, I find your structure strange and I think that you should try to re-arrange. In some sense you do have cyclic dependencies, as utils depends on mid, while mid depends on utils. /Anders On Tue, Jan 4, 2011 at 03:19, Hayarobi Parkhayarobip...@gmail.com wrote: Hello, I'm managing maven project of my team, and having truble in module dependencies.. The root project has some sub modules. A submodule named utils has a few submodule; config, logger, json and etc. Another submodule mid has manager submodule, which are pom project and has core, clientAPI and protocol sub modules. The problem is that utils:config depends on mid:manager:clientAPI, mid:manager:clientAPI depends on utils:logger and utils:json, and the other modules in mid:manager depend on submodules utils, including config. There are not cyclic, but twisted dependencies, and maven can't solve the dependency well. I have to do tedius steps to build whole project in the new configuration. 1. install utils first, maven complains and stop building utils:config since mid:manager:clientAPI was not installed yet, just after installing utils pom project. 2. go to utils:logger and install, and for utils:json respectively. 3. go to mid directory and install mid, maven will install mid and stop further install caused by dependeny on utils:config of some other submodules of mid. 4. go to mid:manager and install it. 5. go to mid:manager:clientAPI and install it. 6. go to utils:config and install it. 7. Finally, go to top level and install whole modules. How to solve this situation? - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Our IP Was blocked
You do know that there is an index that should be used for these purposes, yes? /Anders On Wed, Jan 5, 2011 at 11:34, Faruk Can Kaya fck...@datasel.com.tr wrote: Hello; I was working on a project for our custom needs about dependency management. I have written a program that traverses the repo1.maven.organd list all the available artifacts. Unfortunately I'm not able access repo1.maven.org any more. Our company uses maven in many projects for build scripting. Hence it is essential for our company. I'm sorry for causing any problems. Can anyone restore our ip address or addresses. Our IP addresses are below: 95.9.74.92 88.249.20.72 78.187.132.76 Thank You Best Regards. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Our IP Was blocked
If you have Nexus installed, you can find any dependency available in any repository that you configure either by looking at the full list or by searching for it . That is the right way to manage dependencies. It is a really big help in making your management of dependencies much less painful and provides a sound foundation for managing your own artifacts. Nexus will not get you banned. I gather that you will get banned again if you run your program. Ron On 05/01/2011 5:34 AM, Faruk Can Kaya wrote: Hello; I was working on a project for our custom needs about dependency management. I have written a program that traverses the repo1.maven.org and list all the available artifacts. Unfortunately I'm not able access repo1.maven.org any more. Our company uses maven in many projects for build scripting. Hence it is essential for our company. I'm sorry for causing any problems. Can anyone restore our ip address or addresses. Our IP addresses are below: 95.9.74.92 88.249.20.72 78.187.132.76 Thank You Best Regards. - 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: Our IP Was blocked
File an issue at https://issues.sonatype.org under the Community Support - Maven Central to get removed from the blacklist. Rich On Jan 5, 2011, at 8:05 AM, Ron Wheeler wrote: If you have Nexus installed, you can find any dependency available in any repository that you configure either by looking at the full list or by searching for it . That is the right way to manage dependencies. It is a really big help in making your management of dependencies much less painful and provides a sound foundation for managing your own artifacts. Nexus will not get you banned. I gather that you will get banned again if you run your program. Ron On 05/01/2011 5:34 AM, Faruk Can Kaya wrote: Hello; I was working on a project for our custom needs about dependency management. I have written a program that traverses the repo1.maven.org and list all the available artifacts. Unfortunately I'm not able access repo1.maven.org any more. Our company uses maven in many projects for build scripting. Hence it is essential for our company. I'm sorry for causing any problems. Can anyone restore our ip address or addresses. Our IP addresses are below: 95.9.74.92 88.249.20.72 78.187.132.76 Thank You Best Regards. - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Accessing the version of a dependency
Thanks, that's a simple solution that might even work in most of the
situations (perhaps excepting the release plugin, etc).
I also found a more complex way to access the versions of a dependency
using Groovy plugin. For those who are interested:
plugins
plugin
groupIdorg.codehaus.groovy.maven/groupId
artifactIdgmaven-plugin/artifactId
version1.0-rc-5/version
executions
execution
phasevalidate/phase
goals
goalexecute/goal
/goals
configuration
source
print
project.dependencies;
for ( i in
project.dependencies ) {
project.properties[ 'depinfo.' + i['groupId'] + '.' +
i['artifactId'] + '.version' ] = i['version'];
}
/source
/configuration
/execution
/executions
/plugin
Then you can access ${depinfo.mygroup.myartifact.version}... But I'll try to
go with your suggestion.
Juha
Right, and the rest of your build needs to know that version as well,
right? Put that version in a property and use it in the dependency as
well as resource filtering, i.e.
properties
cssversion2/cssversion
/properties
Kalle
--
View this message in context:
http://maven.40175.n5.nabble.com/Accessing-the-version-of-a-dependency-tp3327490p3329171.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Is there any way to stop the same version of pom file/build being built more than once?
Wendy, thanks for your reply. Here is the example: 1. Someone need to fix a bug in production. 2. Create a new branch for bug fix based on a label. 3. The newly created branch will contain older pom files with older version that already released in Nexus (or any Maven based repository). 4. Logically, once the branch is created from an older label, in order to avoid redeploying the old version numbers, the version number should be changed. 5. Say, if #4 is skipped, then the same version number that exist in Nexus will be overwritten after performing a release build. 6. This is to assume that we should keep the old release version even if it is buggy. So, my question is: Is there any way to skip #4 by having some Maven type mechanism to check and stop a release build if the version already exist in maven repo? Thanks. B. On Tue, Jan 4, 2011 at 10:01 AM, Wendy Smoak wsm...@gmail.com wrote: On Tue, Jan 4, 2011 at 12:28 PM, baz themail bazthem...@gmail.com wrote: Hi, Is there any way to stop the same version of pom file/build being built more than once? Being _built_? Probably not... anyone can check out a tag and re-build that version locally, nothing to prevent that from happening. (Nor should there be.) What's the real underlying problem? My guess is that it's about not overwriting released versions. In which case... are you using -SNAPSHOT version numbers and going through a release process? A repository manager to store your artifacts? Tell us more about your situation and most likely someone will have some advice for you. -- Wendy - 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: Is there any way to stop the same version of pom file/build being built more than once?
Configure your Nexus server to not allow artifacts to get overwritten. You can't stop the build from happening, but you can stop the artifact from being deployed. -Original Message- From: baz themail [mailto:bazthem...@gmail.com] Sent: Wednesday, January 05, 2011 12:55 PM To: Maven Users List Subject: Re: Is there any way to stop the same version of pom file/build being built more than once? Wendy, thanks for your reply. Here is the example: 1. Someone need to fix a bug in production. 2. Create a new branch for bug fix based on a label. 3. The newly created branch will contain older pom files with older version that already released in Nexus (or any Maven based repository). 4. Logically, once the branch is created from an older label, in order to avoid redeploying the old version numbers, the version number should be changed. 5. Say, if #4 is skipped, then the same version number that exist in Nexus will be overwritten after performing a release build. 6. This is to assume that we should keep the old release version even if it is buggy. So, my question is: Is there any way to skip #4 by having some Maven type mechanism to check and stop a release build if the version already exist in maven repo? Thanks. B. On Tue, Jan 4, 2011 at 10:01 AM, Wendy Smoak wsm...@gmail.com wrote: On Tue, Jan 4, 2011 at 12:28 PM, baz themail bazthem...@gmail.com wrote: Hi, Is there any way to stop the same version of pom file/build being built more than once? Being _built_? Probably not... anyone can check out a tag and re-build that version locally, nothing to prevent that from happening. (Nor should there be.) What's the real underlying problem? My guess is that it's about not overwriting released versions. In which case... are you using -SNAPSHOT version numbers and going through a release process? A repository manager to store your artifacts? Tell us more about your situation and most likely someone will have some advice for you. -- Wendy - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Is there any way to stop the same version of pom file/build being built more than once?
On Wed, Jan 5, 2011 at 12:54 PM, baz themail bazthem...@gmail.com wrote: 1. Someone need to fix a bug in production. 2. Create a new branch for bug fix based on a label. 3. The newly created branch will contain older pom files with older version that already released in Nexus (or any Maven based repository). How is the branch being created? Either the release plugin or the scm plugin has a branch goal that will change the version number, though iirc it modifies the tag to do it, which I don't like. Or, you can use the versions plugin to easily set the new version. 4. Logically, once the branch is created from an older label, in order to avoid redeploying the old version numbers, the version number should be changed. 5. Say, if #4 is skipped, then the same version number that exist in Nexus will be overwritten after performing a release build. It shouldn't -- isn't there a setting to make it disallow this? 6. This is to assume that we should keep the old release version even if it is buggy. Released artifacts should never change, so yes, you should keep the old buggy version separate from the new fixed version. -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Is there any way to stop the same version of pom file/build being built more than once?
And use the Maven Release Plugin to create the branch[1][2] in the first place. This will change the version numbers back to snapshot. [1] http://maven.apache.org/plugins/maven-release-plugin/branch-mojo.html [2] http://maven.apache.org/plugins/maven-release-plugin/examples/branch.html Hth, Nick Stolwijk ~Senior Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Wed, Jan 5, 2011 at 6:58 PM, Thiessen, Todd (Todd) tthies...@avaya.com wrote: Configure your Nexus server to not allow artifacts to get overwritten. You can't stop the build from happening, but you can stop the artifact from being deployed. -Original Message- From: baz themail [mailto:bazthem...@gmail.com] Sent: Wednesday, January 05, 2011 12:55 PM To: Maven Users List Subject: Re: Is there any way to stop the same version of pom file/build being built more than once? Wendy, thanks for your reply. Here is the example: 1. Someone need to fix a bug in production. 2. Create a new branch for bug fix based on a label. 3. The newly created branch will contain older pom files with older version that already released in Nexus (or any Maven based repository). 4. Logically, once the branch is created from an older label, in order to avoid redeploying the old version numbers, the version number should be changed. 5. Say, if #4 is skipped, then the same version number that exist in Nexus will be overwritten after performing a release build. 6. This is to assume that we should keep the old release version even if it is buggy. So, my question is: Is there any way to skip #4 by having some Maven type mechanism to check and stop a release build if the version already exist in maven repo? Thanks. B. On Tue, Jan 4, 2011 at 10:01 AM, Wendy Smoak wsm...@gmail.com wrote: On Tue, Jan 4, 2011 at 12:28 PM, baz themail bazthem...@gmail.com wrote: Hi, Is there any way to stop the same version of pom file/build being built more than once? Being _built_? Probably not... anyone can check out a tag and re-build that version locally, nothing to prevent that from happening. (Nor should there be.) What's the real underlying problem? My guess is that it's about not overwriting released versions. In which case... are you using -SNAPSHOT version numbers and going through a release process? A repository manager to store your artifacts? Tell us more about your situation and most likely someone will have some advice for you. -- Wendy - 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 - 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: Accessing the version of a dependency
On Wed, Jan 5, 2011 at 9:33 AM, juranta juha.ra...@iki.fi wrote:
Thanks, that's a simple solution that might even work in most of the
situations (perhaps excepting the release plugin, etc).
The release plugin is surprisingly good at dealing with versions
declared in properties, try it, might just work out of the box for
your use case.
Kalle
I also found a more complex way to access the versions of a dependency
using Groovy plugin. For those who are interested:
plugins
plugin
groupIdorg.codehaus.groovy.maven/groupId
artifactIdgmaven-plugin/artifactId
version1.0-rc-5/version
executions
execution
phasevalidate/phase
goals
goalexecute/goal
/goals
configuration
source
print
project.dependencies;
for ( i in
project.dependencies ) {
project.properties[ 'depinfo.' + i['groupId'] + '.' +
i['artifactId'] + '.version' ] = i['version'];
}
/source
/configuration
/execution
/executions
/plugin
Then you can access ${depinfo.mygroup.myartifact.version}... But I'll try to
go with your suggestion.
Juha
Right, and the rest of your build needs to know that version as well,
right? Put that version in a property and use it in the dependency as
well as resource filtering, i.e.
properties
cssversion2/cssversion
/properties
Kalle
--
View this message in context:
http://maven.40175.n5.nabble.com/Accessing-the-version-of-a-dependency-tp3327490p3329171.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
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: can i change the name of the uploaded/installed artifact?
-Original Message-
From: Reynald Borer [mailto:reynald.bo...@gmail.com]
You can modify the finalName tag to change the name of artifact. By default
it is defined like the following:
project
build
finalName${artifactId}-${version}/finalName
/build
/project
That only affects what gets created in your target directory. Once the
artifact gets uploaded to a repository (e.g. ~/.m2, or a central Nexus repo)
the standard naming is enforced.
The finalName tag is really only useful if you skip the deploy step and use the
output artifact directly. (e.g. as part of a larger, non-maven build, or
emailing it to a customer, etc...)
eric
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Exclusion does not work when using dependencies generated using assembly plug in
Hi,
Apologize for not providing more details.
Here are more details -
1. The ROOT is a ROOT pom that builds both ModuleA and ModuleB.
2. ModuleA uses assembly plug in to generate a Distribution jar. Here is the
distribution XML that builds this jar -
!--
This is the maven assembly descriptor file. It is used by maven assemly
plugin defined in
POM.xml for atlasservice-jar to churn out a distributable jar that can be
used by web service
clients.
Since: Version 1.0
--
assembly
iddistribution/id
formats
formatjar/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
fileSets
fileSet
directory${basedir}/target/classes/directory
outputDirectory//outputDirectory
includes
includecom/psi/common/*.class/include
/includes
excludes
excludecom/psi/common/ErrorConstants.class/exclude
/excludes
/fileSet
/fileSets
/assembly
3. Now ModuleB uses this Distribution.jar as a dependency. The POM of
ModuleB is given below . -
project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=
http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.psi.lc/groupId
artifactIdpsi-lc-ops/artifactId
packagingwar/packaging
namepsi-lc-ops/name
parent
groupIdcom.psi/groupId
artifactIdlc/artifactId
version${lc.version}/version
/parent
scm
developerConnection
scm:svn:
https://cobasvn01.coreobjects.com/svn/PSI/products/LC/apps/Atlas/trunk/atlas-web
/developerConnection
/scm
dependencies
!-- START: dependencies for older psi-lc-ops --
dependency
groupIdjstl/groupId
artifactIdjstl/artifactId
version1.1.2/version
/dependency
dependency
groupIdxmlparser/groupId
artifactIdxmlparser/artifactId
version2.0/version
/dependency
dependency
groupIdjavax.mail/groupId
artifactIdmail/artifactId
version1.4/version
exclusions
exclusion
groupIdjavax.activation/groupId
artifactIdactivation/artifactId
/exclusion
/exclusions
/dependency
dependency
groupIdstandard/groupId
artifactIdstandard/artifactId
version1.0/version
/dependency
!-- Unit Testing dependencies --
dependency
groupIdorg.testng/groupId
artifactIdtestng/artifactId
version5.12.1/version
scopetest/scope
/dependency
dependency
groupIdorg.mockito/groupId
artifactIdmockito-all/artifactId
version1.8.5/version
scopetest/scope
/dependency
!-- Unit Testing dependencies end --
dependency
groupIdcom.psi.lc/groupId
artifactIdModuleA/artifactId
version${lc.version}/version
classifierdistribution/classifier
typejar/type
exclusions
exclusion
groupIdquartz/groupId
artifactIdquartz/artifactId
/exclusion
exclusion
groupIdpsistatefunctions/groupId
artifactIdpsistatefunctions/artifactId
/exclusion
exclusion
groupIdcorecccejb/groupId
artifactIdcorecccejb/artifactId
/exclusion
exclusion
groupIdanttex/groupId
artifactIdanttex/artifactId
/exclusion
exclusion
groupIdtreeapplet/groupId
artifactIdtreeapplet/artifactId
/exclusion
exclusion
groupIdVerisign/groupId
artifactIdVerisign/artifactId
/exclusion
exclusion
groupIdreportgenfiles/groupId
artifactIdreportgenfiles/artifactId
/exclusion
exclusion
groupIdcommons-digester/groupId
artifactIdcommons-digester/artifactId
/exclusion
exclusion
groupIdjavax.xml.bind/groupId
artifactIdjaxb-api/artifactId
/exclusion
exclusion
groupIdorg.apache.cxf/groupId
artifactIdcxf-rt-frontend-jaxws/artifactId
/exclusion
exclusion
groupIdcom.psi/groupId
artifactIdcontentservice/artifactId
/exclusion
exclusion
groupIdorg.apache.cxf/groupId
artifactIdcxf-rt-ws-security/artifactId
/exclusion
exclusion
Re: Exclusion does not work when using dependencies generated using assembly plug in
Anand HS wrote: 4. Now when I invoke mvn install from the ROOT pom, I see that ModuleA and ModuleA-distribution.jar get build with no issues. Now when ModuleB is built, in spite of explicit exclusion of ModuleA's dependencies , those dependencies do not get excluded. Could be http://jira.codehaus.org/browse/MNG-4872. Benjamin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: can i change the name of the uploaded/installed artifact?
Indeed. Sorry I read the topic too quickly to give a wrong answer ;-)
Leon, why do you explicitly need to install the war file in your m2repo with a
custom name? Couldn't you simply use the one you can find in the target/
folder? Or you can always use the maven-resources-plugin to copy the generated
war to a given specific folder.
Cheers,
Reynald
On Wednesday, January 5, 2011 at 19:30 , Haszlakiewicz, Eric wrote:
-Original Message-
From: Reynald Borer [mailto:reynald.bo...@gmail.com]
You can modify the finalName tag to change the name of artifact. By default
it is defined like the following:
project
build
finalName${artifactId}-${version}/finalName
/build
/project
That only affects what gets created in your target directory. Once the
artifact gets uploaded to a repository (e.g. ~/.m2, or a central Nexus repo)
the standard naming is enforced.
The finalName tag is really only useful if you skip the deploy step and use
the output artifact directly. (e.g. as part of a larger, non-maven build, or
emailing it to a customer, etc...)
eric
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: can i change the name of the uploaded/installed artifact?
Hello Reynald,
I posted it in my original post.
The webapp have to be accessed by a specific context-path, e.g.
http://host:port/distributeme/registry/list
The easiest way to achieve it, is to name the war distributeme.war.
In other words, for external users its easier to understand:
Download distributeme.war from xyz and place it under webapps in your
app container
as
Download version-x from xyz, rename it to distributeme.war and than
place it under webapps in your app container
regards
Leon
On Wed, Jan 5, 2011 at 7:52 PM, Reynald Borer reynald.bo...@gmail.com wrote:
Indeed. Sorry I read the topic too quickly to give a wrong answer ;-)
Leon, why do you explicitly need to install the war file in your m2repo with
a custom name? Couldn't you simply use the one you can find in the target/
folder? Or you can always use the maven-resources-plugin to copy the
generated war to a given specific folder.
Cheers,
Reynald
On Wednesday, January 5, 2011 at 19:30 , Haszlakiewicz, Eric wrote:
-Original Message-
From: Reynald Borer [mailto:reynald.bo...@gmail.com]
You can modify the finalName tag to change the name of artifact. By default
it is defined like the following:
project
build
finalName${artifactId}-${version}/finalName
/build
/project
That only affects what gets created in your target directory. Once the
artifact gets uploaded to a repository (e.g. ~/.m2, or a central Nexus repo)
the standard naming is enforced.
The finalName tag is really only useful if you skip the deploy step and use
the output artifact directly. (e.g. as part of a larger, non-maven build, or
emailing it to a customer, etc...)
eric
-
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: can i change the name of the uploaded/installed artifact?
Understood. So you want your users to download the WAR directly from either
your m2repo (weird) or from a Maven repository tool like Nexus, right?
In that case, I don't think it's a Maven problem. You should consider deploying
your generated war file to a web server like Apache (through
maven-resources-plugin for example). Or you might also have an Apache in front
of your Nexus server that is correctly configured to rewrite
/xyz/distributeme.war to the correct location of the latest war in Nexus, and
then it'll be downloaded as distributeme.war.
Regards,
Reynald
On Wednesday, January 5, 2011 at 21:00 , Leon Rosenberg wrote:
Hello Reynald,
I posted it in my original post.
The webapp have to be accessed by a specific context-path, e.g.
http://host:port/distributeme/registry/list
The easiest way to achieve it, is to name the war distributeme.war.
In other words, for external users its easier to understand:
Download distributeme.war from xyz and place it under webapps in your
app container
as
Download version-x from xyz, rename it to distributeme.war and than
place it under webapps in your app container
regards
Leon
On Wed, Jan 5, 2011 at 7:52 PM, Reynald Borer reynald.bo...@gmail.com wrote:
Indeed. Sorry I read the topic too quickly to give a wrong answer ;-)
Leon, why do you explicitly need to install the war file in your m2repo
with a custom name? Couldn't you simply use the one you can find in the
target/ folder? Or you can always use the maven-resources-plugin to copy
the generated war to a given specific folder.
Cheers,
Reynald
On Wednesday, January 5, 2011 at 19:30 , Haszlakiewicz, Eric wrote:
-Original Message-
From: Reynald Borer [mailto:reynald.bo...@gmail.com]
You can modify the finalName tag to change the name of artifact. By
default
it is defined like the following:
project
build
finalName${artifactId}-${version}/finalName
/build
/project
That only affects what gets created in your target directory. Once the
artifact gets uploaded to a repository (e.g. ~/.m2, or a central Nexus
repo) the standard naming is enforced.
The finalName tag is really only useful if you skip the deploy step and
use the output artifact directly. (e.g. as part of a larger, non-maven
build, or emailing it to a customer, etc...)
eric
-
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
[PLEASE TEST] Apache Maven 3.0.2-RC1
Hi, we're aiming at a bugfix release of Maven 3 in the next week and following tradition we invite interested users in taking the RC for a test drive in order to detect and fix potential regressions since version 3.0.1 before the actual release of 3.0.2. For the duration of the RC testing, sources and binaries are staged at: https://repository.apache.org/content/repositories/maven-006/org/apache/maven/apache-maven/3.0.2-RC1/ As usual, the changes since the previous release are listed in JIRA: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=16952 Thanks, -The Maven Team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: can i change the name of the uploaded/installed artifact?
The webapp have to be accessed by a specific context-path, e.g. http://host:port/distributeme/registry/list The easiest way to achieve it, is to name the war distributeme.war. Each app server has its own way of handling this -- context.xml, weblogic, xml, etc. You could also just include all those configuration files in your war file directly. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: One project depends on another, how to declare dependency, again...
Since you say I always want bar to use the latest release of foo
then you might as well release them together.
http://www.sonatype.com/books/mvnex-book/reference/multimodule.html
Or, if you feel it's not appropriate to have them be part of the same
project (for example, if 'foo' changes infrequently but 'bar' changes
frequently), you may want to automate use of the
versions-maven-plugin, which will seek out updates for you.
http://mojo.codehaus.org/versions-maven-plugin/
Zac
On Tue, Jan 4, 2011 at 4:59 AM, Leon Rosenberg rosenberg.l...@gmail.com wrote:
On Tue, Jan 4, 2011 at 12:11 PM, Anders Hammar and...@hammar.net wrote:
I recommend 1.0.1, as I dislike ranges (might break reproducible builds
and is just to much automagic in my taste).
RELEASE, LATEST is depracted and should not be used.
When ever a new release is available you need to update the bar pom.
Well in practice I have like 10 projects, so I will probably have to
update 9 poms in worst case. For now I moved dependency management
into parent.pom.
Or, you could keep both projects together with an aggregating project and
have one release lifecycle for them (same version in both,
${project.version}).
version${project.version}/version ?
I tried it in a module in an aggregated project (another one) and get
Project build error: Resolving expression: '${project.version}':
Detected the following recursive expression cycle:
[] pom.xml /distributeme-runtime line 1 Maven Problem
Project build error: Resolving expression: '${version}': Detected the
following recursive expression cycle:
[version] pom.xml /distributeme-runtime line 1 Maven Problem
regards
Leon
/Anders
On Tue, Jan 4, 2011 at 11:46, Leon Rosenberg rosenberg.l...@gmail.comwrote:
Hi,
say I have two projects,
foo and bar, and bar depends on foo. My question is how should I
properly declare this dependency.
From the maintainers point of view (and I'm the maintainer of both) I
always want bar to use the newest release of foo.
So, I have a released version of foo - 1.0.1, which is known to me at
the moment I'm writing the pom for bar.
Do I reference foo in bar as:
1.0.1
or
[1.0.1,)
or
[1.0.1]
or
RELEASE
or
... ?
regards
Leon
-
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
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
mvn deploy and password encryption
I am, for the first time, trying to use a nexus repository. I have read all the information here: http://maven.apache.org/guides/mini/guide-encryption.html on password encryption and to the best of my knowledge, have followed it correctly and set up my setting.xml, settings-security.xml and pom file correctly to enable deployment. And yet, when I try to deploy something to my repository, I get 401 errors. The one question I am having is that I am using maven 3.0.1, whereas the repo may be expecting 2.2.1. Would this make a difference here, and how can I debug the situation? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn deploy and password encryption
On 01/05/2011 04:36 PM, Steve Cohen wrote:
I am, for the first time, trying to use a nexus repository. I have read
all the information here:
http://maven.apache.org/guides/mini/guide-encryption.html on password
encryption and to the best of my knowledge, have followed it correctly
and set up my setting.xml, settings-security.xml and pom file correctly
to enable deployment.
And yet, when I try to deploy something to my repository, I get 401 errors.
The one question I am having is that I am using maven 3.0.1, whereas the
repo may be expecting 2.2.1. Would this make a difference here, and how
can I debug the situation?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Another thing I notice is that
mvn -ep {password}
when run several times in succession generates different encryptions
each time. Yet the instructions tell you to add the encrypted value to
the settings file. Can this be right, or will several different
encryptions yield the same unencrypted pw when decrypted?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Copying dependencies' binaries (dlls) for runtime
Is it appropriate / best practice to use the maven-resources-plugin to copy dlls from target\dependency\bin to target\bin so they will be where I need them for runtime? Thanks, Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn deploy and password encryption
Steve Cohen wrote:
Another thing I notice is that
mvn -ep {password}
when run several times in succession generates different encryptions
each time.
This is correct/expected, the encrypted value is also based on a random
salt.
Benjamin
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: Copying dependencies' binaries (dlls) for runtime
You might want to look at the maven-dependency-plugin(http://maven.apache.org/plugins/maven-dependency-plugin/). Nice if you also need the transitive dependencies. Also unpack makes it nice to work with zip files. From: Phillip Hellewell [via Maven] [mailto:ml-node+3329689-622232288-147...@n5.nabble.com] Sent: Wednesday, January 05, 2011 2:52 PM To: Khai Do Subject: Copying dependencies' binaries (dlls) for runtime Is it appropriate / best practice to use the maven-resources-plugin to copy dlls from target\dependency\bin to target\bin so they will be where I need them for runtime? Thanks, Phillip - To unsubscribe, e-mail: [hidden email]/user/SendEmail.jtp?type=nodenode=3329689i=0 For additional commands, e-mail: [hidden email]/user/SendEmail.jtp?type=nodenode=3329689i=1 View message @ http://maven.40175.n5.nabble.com/Copying-dependencies-binaries-dlls-for-runtime-tp3329689p3329689.html To start a new topic under Maven - Users, email ml-node+40176-907978382-147...@n5.nabble.com To unsubscribe from Maven - Users, click herehttp://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=40176code=a2hhaS5kb0BpbXBpbmouY29tfDQwMTc2fC0xMjUwNjg2MDQ0. -- View this message in context: http://maven.40175.n5.nabble.com/Copying-dependencies-binaries-dlls-for-runtime-tp3329689p3329746.html Sent from the Maven - Users mailing list archive at Nabble.com.
Re: Copying dependencies' binaries (dlls) for runtime
On Wed, Jan 5, 2011 at 4:24 PM, khaido khai...@impinj.com wrote: You might want to look at the maven-dependency-plugin(http://maven.apache.org/plugins/maven-dependency-plugin/). Nice if you also need the transitive dependencies. Also unpack makes it nice to work with zip files. Thanks. I'm actually already using the dependency plugin to copy and unpack the dependencies from the local repo to below target\dependency. But now I need to take a subset of those (the dlls needed for runtime) and copy them from target\dependency\bin to target\bin. I'm thinking of writing my own plugin to do the copying, because I need some additional logic. Looking at the mojos in the maven-resources-plugin, it looks like I can use shared code from org.apache.maven.shared.filtering to do most of the work for me. My question now is, if I want to define the resources in a separate stand-alone xml file (actually there will be more than one), rather than in the pom.xml, what code/class do I use to read an xml file into a java.util.List of org.apache.maven.model.Resource? Thanks, Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Copying dependencies' binaries (dlls) for runtime
On Wed, Jan 5, 2011 at 4:32 PM, Phillip Hellewell ssh...@gmail.com wrote: My question now is, if I want to define the resources in a separate stand-alone xml file (actually there will be more than one), rather than in the pom.xml, what code/class do I use to read an xml file into a java.util.List of org.apache.maven.model.Resource? Would it work to take read the resources tag from my XML, surround it with projectbuild /build/project or whatever to make it a valid pom, and then use the MavenXpp3Reader to parse that? I think I found the code where it parses a Resource, and obviously I don't want to duplicate that code in my own plugin: http://maven.apache.org/ref/2.0.11/xref/org/apache/maven/model/io/xpp3/MavenXpp3Reader.html#4474 Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn deploy and password encryption
I figured that that must be the case.
Do you have any idea why this would fail? Could the 3.0.1 vs. 2.2.1
thing be involved or MUST it be that I'm making a mistake I just can't see?
On 01/05/2011 05:04 PM, Benjamin Bentmann wrote:
Steve Cohen wrote:
Another thing I notice is that
mvn -ep {password}
when run several times in succession generates different encryptions
each time.
This is correct/expected, the encrypted value is also based on a random
salt.
Benjamin
-
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: Copying dependencies' binaries (dlls) for runtime
Resources are for things packaged and to be used at runtime - that doesn't sound like what you want here. This is typically done with a combination of the dependecy assembly plugin. You might also be interested in NPanday (http://incubator.apache.org/npanday/) which provides several .NET specific plugins if that's the flavour of DLL you are dealing with. - Brett On 06/01/2011, at 11:22 AM, Phillip Hellewell wrote: On Wed, Jan 5, 2011 at 4:32 PM, Phillip Hellewell ssh...@gmail.com wrote: My question now is, if I want to define the resources in a separate stand-alone xml file (actually there will be more than one), rather than in the pom.xml, what code/class do I use to read an xml file into a java.util.List of org.apache.maven.model.Resource? Would it work to take read the resources tag from my XML, surround it with projectbuild /build/project or whatever to make it a valid pom, and then use the MavenXpp3Reader to parse that? I think I found the code where it parses a Resource, and obviously I don't want to duplicate that code in my own plugin: http://maven.apache.org/ref/2.0.11/xref/org/apache/maven/model/io/xpp3/MavenXpp3Reader.html#4474 Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Creating an exploded ear file.
I also want to know how to deploy to auto-deploy of weblogic in exploded
format using maven.
Presently we run 'mvn clean install' which creates ear. We run a batch file
to explode this ear and copy this exploded ear to the autodeploy directory.
If we have java changes, we do 'mvn compile' on java source files and then
copy the java files ('com') into the autodeploy and touch the REDEPLOY file
to trigger auto-deploy.
I would like to improve/automat this as lot of steps above are manual (like
running batch file to explode, copying, touching the file etc.)
Any help on this ?
--
View this message in context:
http://maven.40175.n5.nabble.com/Creating-an-exploded-ear-file-tp80817p3330081.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
