Re: optional dependencies got pull into my web app?
On Fri, 2007-04-27 at 16:04 -0700, Dan Tran wrote: Hello, my webapp depends on commons-logging-1.1 which has a punch of optional jars and they are pull into my WEB-INF/lib directory is it a expected behavior, the optional depdendency seems to disagree with that According to the commons-logging POM 1.1 these dependencies are not optional. To get rid of them you can use exclusions: dependency groupIdcommons-logging/groupId artifactIdcommons-logging/artifactId version1.1/version exclusions exclusion groupIdavalon-framework/groupId artifactIdavalon-framework/artifactId /exclusion exclusion groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId /exclusion exclusion groupIdlog4j/groupId artifactIdlog4j/artifactId /exclusion exclusion groupIdlogkit/groupId artifactIdlogkit/artifactId /exclusion /exclusions /dependency - Henry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing a branch?
On 4/26/07, Crossley, Jim [EMAIL PROTECTED] wrote: I used the release plugin to successfully release version 2.0.2.1 of our project. We continued working on the HEAD targeting version 2.0.3 while QA tested 2.0.2.1. To address bugs reported against that release, we created a 2.0.2 branch in CVS. We applied our fixes there. I think, it was a bad move not to start 2.0.2.2-SNAPSHOT before you started the bug fixing. If a developer did a mvn install or deploy, the 2.0.2.1 version was overwritten by something that is not 2.0.2.1 anymore. Now it's time to create version 2.0.2.2 from that 2.0.2 branch. When I attempt to run release:prepare, it immediately fails because the version is not a SNAPSHOT. Of course it's not a snapshot. It's a released version requiring bug fixes. What did I do wrong? Is the maven release model such that releases are only ever cut from the HEAD? How do you account for bugfixes-without-new-features then? Do I need to manually update the versions of all the subprojects myself and then manually tag it? It seems kinda silly to change all the versions to 2.0.2.1-SNAPSHOT just so I can have the release plugin change them to 2.0.2.2! I may as well do that myself and eliminate the middle man, right? The good thing is, you have to do it only once per branch. The release plugin will prepare the next SNAPSHOT version for you. But I agree, a plugin to change a release version to the next snapshot version would be handy. - Henry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing a branch?
On 4/26/07, Roland Asmann [EMAIL PROTECTED] wrote: As I see it, you just described the only solution that works. I may be wrong here, so if any of the maven-programmers think I am: please DO tell me! No matter how you assign the version-numbers, fact remains that maven can not 'automatically' handle branching. As I see it there are two solutions: 1) starting the maintenance branch before the release and doing the release on the branch, in this case you have to manually adjust the version on the trunk. 2) doing the release on the trunk and starting the maintenance branch from the tagged version, in this case the version has to be manually updated on the branch. Both approaches work, but there is some manual version editing in both. Once the branching is done, the release plugin works fine on the branch (for releasing further maintenance releases) and on the trunk (for releasing the next major release). The manual update is only necessary once per branch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question regarding finalName in maven-assembly-plugin
On 4/11/07, Michael Dick [EMAIL PROTECTED] wrote:
Hi,
I've noticed that the finalName configuration option for an assembly is
ignored when you install or deploy your project. Is this intended behavior?
I have a project named openjpa-project which contains the a source and
binary assembly which packages various OpenJPA sub-projects. We'd like to
have the resulting zip files named openjpa-${version}-source.zip and
openjpa-${version}-binary.zip, but we're getting openjpa-project-${version}-
source.zip (and the same for -binary) when we deploy or install.
I can provide pom and assembly files if that would help.
Thanks,
--
-Michael Dick
There is no way for maven to access an artifact in the repository if
it does not follow the standard naming conventions.
Henry
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question regarding finalName in maven-assembly-plugin
On 4/11/07, Alan D. Salewski [EMAIL PROTECTED] wrote: On Wed, Apr 11, 2007 at 01:27:42PM -0500, Michael Dick spake thus: *snip* It seems that the finalName *could* be added in an xml file in the repository. Whether it *should* be added is another issue. I did not think too much about that, but I guess that something like this *could* be implemented. There would still be some issues with snapshot deployments. Also, one has to be careful not to slow down the standard case by an extra file access. I have projects that create artifacts with a 'finalName' set, and these artifacts get installed/deployed with the wrong file names (that is, not what I specified in 'finalName'). In all of my cases, these artifacts do not need to be accessible by maven for build purposes, so the fact that the files are installed and deployed with names different from what I specified in 'finalName' is simply an annoyance (because I then have to rename the files on the deployment server by hand). Maybe we need an attribute for 'finalName' that indicates yes I know this name will not be accessible by maven once installed or deployed; when set maven would deploy the file as named. Why insist to put something into a *maven* repository if there is no intention to access it by maven? Wouldn't it be more useful to be able to publish to a different place? I don't know, if there already is a plugin achieving that, but it would not be too hard to build. Henry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-assembly-plugin:2.2-SNAPSHOT cannot be downloaded
On 1/15/07, Annies, Sebastian [EMAIL PROTECTED] wrote: Hello, For some reason I cannot get any maven assembly plugin in version 2.2-SNAPSHOT to download. I added: repositories repository You need to use pluginRepositories and pluginRepository instead. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] any tips for site internationalization ?
On 1/3/07, Dário Luís Coneglian Oliveros [EMAIL PROTECTED] wrote: Hi Wayne, I am still not sure if a JIRA issue could be opened in this case. According to the instructions for translators at maven site plugin (http://maven.apache.org/plugins/maven-site-plugin/i18n.html), any translation (for instance, site-plugin_pt_BR.properties) should be saved with UTF-8 encoding. And the way I made it work was to save it with ISO-8859-1 encoding instead. Moreover there's another open issue (http://jira.codehaus.org/browse/MSITE-19) that is supposed to fix these encoding problems. Unfortunately it's taking too long to get them fixed. So until MSITE-19 is not closed I may stick with the workaround unless I get a thumbs up to add these new properties files for pt_BR (ISO-8859-1 encoding) in the maven-site-plugin trunk. Any thoughts ? My understanding of http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html is that property files have to be encoded in ISO-8859-1 Henry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mvn assembly:assembly only adding one dependency jar to assembly
On 12/15/06, Dan Tenenbaum [EMAIL PROTECTED] wrote: Hello, I am trying to create an assembly which has the functionality of the predefined jar-with-dependencies assembly, with one difference, namely that one specific dependency jar is excluded. I'm having a problem getting it to work. Instead of including all the dependency jars minus one with my code, it just includes a single one. I am struggling with the same problem at the moment, did you ever find a solution? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Archetype Question
On 11/22/06, Wendy Smoak [EMAIL PROTECTED] wrote:
Has anyone found a way to escape expressions in Velocity, so it will
pass them through?
One possibility is to define the property start sequence as velocity macro:
#set( $ps = ${ )
... and later in the file
this should remain ${ps}property.remaining.in.file} unescaped
The problem with the regular velocity escaping mechanism is that it
treats properties that are defined differently from properties that
are not defined. This feature makes it unusable in my opinion.
Henry
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
