[jira] Created: (ARCHETYPE-155) use groovy templates to generate files
use groovy templates to generate files -- Key: ARCHETYPE-155 URL: http://jira.codehaus.org/browse/ARCHETYPE-155 Project: Maven Archetype Issue Type: Improvement Reporter: Ittay Dror velocity is really poor for creating templates. in my case, i have some rules for generating parent pom group/artifact ids from the current groupid, which is awkward to do in velocity (if possible, i didn't try). also, some parts need to be generated based on values passed by the user, and i want to signal errors if the values he passed are not correct. using groovy is very easy. maybe a parameter in archetype.xml? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-43) add ability to do filtering (i.e. template var replacement) for files in src/main/application/
[ http://jira.codehaus.org/browse/MEAR-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129923#action_129923 ] Stephane Nicoll commented on MEAR-43: - sounds good. It uses the new maven filtering thingy that Olivier made, right? > add ability to do filtering (i.e. template var replacement) for files in > src/main/application/ > -- > > Key: MEAR-43 > URL: http://jira.codehaus.org/browse/MEAR-43 > Project: Maven 2.x Ear Plugin > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Ian Springer >Assignee: Stephane Nicoll >Priority: Minor > Fix For: 2.3.2 > > Attachments: maven-ear-plugin-2.3.2-SNAPSHOT_sourceFilter.patch > > > I need to do some template var replacements in files in > src/main/application/. It would be great if the ear plugin could provide a > filtering configuration in a similar manner to the war plugin. That is, > something along the lines of: > > ... > > true > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-43) add ability to do filtering (i.e. template var replacement) for files in src/main/application/
[ http://jira.codehaus.org/browse/MEAR-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129922#action_129922 ] Martin Buechler commented on MEAR-43: - I attached a patch that does resouce filtering on sources in earSourceDir. Works for me, please review and comment. > add ability to do filtering (i.e. template var replacement) for files in > src/main/application/ > -- > > Key: MEAR-43 > URL: http://jira.codehaus.org/browse/MEAR-43 > Project: Maven 2.x Ear Plugin > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Ian Springer >Assignee: Stephane Nicoll >Priority: Minor > Fix For: 2.3.2 > > > I need to do some template var replacements in files in > src/main/application/. It would be great if the ear plugin could provide a > filtering configuration in a similar manner to the war plugin. That is, > something along the lines of: > > ... > > true > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MEAR-43) add ability to do filtering (i.e. template var replacement) for files in src/main/application/
[ http://jira.codehaus.org/browse/MEAR-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Buechler updated MEAR-43: Attachment: maven-ear-plugin-2.3.2-SNAPSHOT_sourceFilter.patch > add ability to do filtering (i.e. template var replacement) for files in > src/main/application/ > -- > > Key: MEAR-43 > URL: http://jira.codehaus.org/browse/MEAR-43 > Project: Maven 2.x Ear Plugin > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Ian Springer >Assignee: Stephane Nicoll >Priority: Minor > Fix For: 2.3.2 > > Attachments: maven-ear-plugin-2.3.2-SNAPSHOT_sourceFilter.patch > > > I need to do some template var replacements in files in > src/main/application/. It would be great if the ear plugin could provide a > filtering configuration in a similar manner to the war plugin. That is, > something along the lines of: > > ... > > true > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2759) Resolving transitive dependencies of artefacts with classifiers fails
[ http://jira.codehaus.org/browse/MNG-2759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129927#action_129927 ] Libor Kramolis commented on MNG-2759: - See also MINSTALL-41 and MDEPLOY-45. > Resolving transitive dependencies of artefacts with classifiers fails > - > > Key: MNG-2759 > URL: http://jira.codehaus.org/browse/MNG-2759 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.4 > Environment: Windows XP, Maven 2.0.4 >Reporter: Fabian Bauschulte > Fix For: Reviewed Pending Version Assignment > > Attachments: project.zip > > > I have the following projects with subprojects projectA, projectB and > projectC. projectA depends on projectB, projectC depends on projectB. All > projects use classifiers: > ... > projectB > > > > org.apache.maven.plugins > maven-jar-plugin > > someclassifier > > > > > > > test > projectB > 1.0.0 > someclassifier > > > When running "mvn clean install" on the the parent works fine. But running > "mvn install" only in projectC fails: > C:\Data\maven-test\projectC>mvn clean install > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Unnamed - test:projectC:jar:1.0.0 > [INFO]task-segment: [clean, install] > [INFO] > > [INFO] [clean:clean] > [INFO] Deleting directory C:\Data\maven-test\projectC\target > [INFO] Deleting directory C:\Data\maven-test\projectC\target\classes > [INFO] Deleting directory C:\Data\maven-test\projectC\target\test-classes > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > Downloading: > http://repo1.maven.org/maven2/test/projectB/1.0.0/projectB-1.0.0.pom > [WARNING] Unable to get resource from repository central > (http://repo1.maven.org/maven2) > [INFO] [compiler:compile] > Compiling 1 source file to C:\Daten\maven-test\projectC\target\classes > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > C:\Data\maven-test\projectC\src\main\java\ClassC.java:[3,12] cannot find > symbol > symbol : class ClassA > location: package test > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAVADOC-182) use ${project.build.sourceEncoding} as default value for "encoding" parameter
use ${project.build.sourceEncoding} as default value for "encoding" parameter
-
Key: MJAVADOC-182
URL: http://jira.codehaus.org/browse/MJAVADOC-182
Project: Maven 2.x Javadoc Plugin
Issue Type: Improvement
Affects Versions: 2.4
Reporter: Herve Boutemy
see
http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-57) Provide specific default value for "encoding" parameter
[ http://jira.codehaus.org/browse/MRESOURCES-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129932#action_129932 ] Herve Boutemy commented on MRESOURCES-57: - see http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding > Provide specific default value for "encoding" parameter > --- > > Key: MRESOURCES-57 > URL: http://jira.codehaus.org/browse/MRESOURCES-57 > Project: Maven 2.x Resources Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Benjamin Bentmann >Priority: Minor > Attachments: resource-encoding.patch > > > The platform's default encoding may easily differ among machines/developers > so relying on it breaks with the aim of reproducible builds. The encoding > used should always be fixed for a particular plugin run, either explicitly by > the user or implicitly by a known default value. > See also MCOMPILER-63. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCOMPILER-70) use ${project.build.sourceEncoding} as default value for "encoding" parameter
use ${project.build.sourceEncoding} as default value for "encoding" parameter
-
Key: MCOMPILER-70
URL: http://jira.codehaus.org/browse/MCOMPILER-70
Project: Maven 2.x Compiler Plugin
Issue Type: Improvement
Reporter: Herve Boutemy
see
http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (JXR-60) use ${project.build.sourceEncoding} as default value for "inputEncoding" parameter
use ${project.build.sourceEncoding} as default value for "inputEncoding"
parameter
--
Key: JXR-60
URL: http://jira.codehaus.org/browse/JXR-60
Project: Maven JXR
Issue Type: Improvement
Components: maven2 jxr plugin
Affects Versions: 2.1
Reporter: Herve Boutemy
see
http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPMD-76) use ${project.build.sourceEncoding} as default value for "sourceEncoding" parameter
use ${project.build.sourceEncoding} as default value for "sourceEncoding"
parameter
---
Key: MPMD-76
URL: http://jira.codehaus.org/browse/MPMD-76
Project: Maven 2.x PMD Plugin
Issue Type: Improvement
Components: CPD, PMD
Affects Versions: 2.3
Reporter: Herve Boutemy
see
http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-43) add ability to do filtering (i.e. template var replacement) for files in src/main/application/
[ http://jira.codehaus.org/browse/MEAR-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129939#action_129939 ] Martin Buechler commented on MEAR-43: - Yes, the code adds a new dependency on org.apache.maven.shared maven-filtering 1.0-alpha-1-SNAPSHOT and I actually forgot to include exactly this dependency in the patch :( I borrowed the code from current svn of the maven-war-plugin. I just started today looking at maven plugin code and I can't tell, what's missing. I guess handling of includes/excludes, encoding should be tested and/or is still waiting to get implemented. The way the plugin works now, enables the generation of EAR packaged JBoss DataSources along with driver jars, and that's what I really need right now. > add ability to do filtering (i.e. template var replacement) for files in > src/main/application/ > -- > > Key: MEAR-43 > URL: http://jira.codehaus.org/browse/MEAR-43 > Project: Maven 2.x Ear Plugin > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Ian Springer >Assignee: Stephane Nicoll >Priority: Minor > Fix For: 2.3.2 > > Attachments: maven-ear-plugin-2.3.2-SNAPSHOT_sourceFilter.patch > > > I need to do some template var replacements in files in > src/main/application/. It would be great if the ear plugin could provide a > filtering configuration in a similar manner to the war plugin. That is, > something along the lines of: > > ... > > true > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2008) Upload oval-1.20
Upload oval-1.20 Key: MAVENUPLOAD-2008 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2008 Project: maven-upload-requests Issue Type: Task Reporter: Sebastian T OVal is a pragmatic and extensible validation framework for any kind of Java objects (not only JavaBeans). Constraints can be configured with annotations, POJOs or XML. Custom constraints can be expressed in pure Java or by using scripting languages such as JavaScript, Groovy, BeanShell, OGNL, MVEL or Ruby. Besides simple object validation OVal implements Programming by Contract features by utilizing AspectJ based aspects. This program and the accompanying materials are made available under the terms of the Eclipse Public License v1.0 which accompanies this distribution, and is available at http://www.eclipse.org/legal/epl-v10.html Thanks in advance! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-83) Wrong username during release:prepare tagging
[
http://jira.codehaus.org/browse/MRELEASE-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129949#action_129949
]
Torben Giesselmann commented on MRELEASE-83:
Same problem with 2.0-beta-8 and SVN.
I looked into {{DefaultScmRepositoryConfigurator}}: the username is contained
in the _host_ part of the {{ScmProviderRepositoryWithHost}}, but it's never
extracted from that and {{scmRepo.setUser( username )}} is never called with
that value.
So I changed that and wrote some code to extract the username and password from
the SVN URL. Now the username is set. Therefore, in
{{ScmCommitPhase.checkin(...)}} the following code is called
{{result = provider.checkIn( repository, fileSet, (ScmVersion) null, message
);}}
with a configured username:
- in the provider's username attribute
- the URL
- and the host name
but _still_ I'm being asked for the wrong username! What is going on after
that? I mean: it's a direct call on the {{ScmProvider}}. A problem with the SVN
provider implementation?!?
> Wrong username during release:prepare tagging
> -
>
> Key: MRELEASE-83
> URL: http://jira.codehaus.org/browse/MRELEASE-83
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: scm
>Reporter: Niclas Hedhman
> Fix For: 2.0-beta-8
>
>
> If I my Svn repository requires a different username than the login name, and
> I issue
>mvn [EMAIL PROTECTED] release:prepare
> The first phase (checking in modified POMs) will succeed with that username.
> Then somewhere between that point and writing out the release.properties
> file, the user name falls back to the login name (in my case "niclas"), which
> is written into the release.properties file, and used during the tagging of
> the repository.
> Now, looking at the source, I think that is unwise to keep a username both in
> the ReleaseProgressTracker as well as in the ScmHelper, and I suspect that
> there is some type of sequencing problem in there.
> WORKAROUND;
> Before starting the release:prepare, create a release.properties file
> manually which contains
> [EMAIL PROTECTED]
> and everything will work.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-322) Unable to set the working directory for projects where the master pom isn't at the root of the project
[
http://jira.codehaus.org/browse/MRELEASE-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129950#action_129950
]
Torben Giesselmann commented on MRELEASE-322:
-
How about using the option {{-DcommitByProject=true}} ?
Does that change anything?
> Unable to set the working directory for projects where the master pom isn't
> at the root of the project
> --
>
> Key: MRELEASE-322
> URL: http://jira.codehaus.org/browse/MRELEASE-322
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.0-beta-7
>Reporter: Christian Nelson
>Priority: Blocker
>
> Branches and Tags are created from the current working directory, which isn't
> always correct and there isn't a way to override the working directory.
> For example, we have the following directory structure:
> ${root}/master/pom.xml - The modules section include relative paths to
> modules a, b, and c.
> ${root}/module-a/pom.xml
> ${root}/module-b/pom.xml
> ${root}/module-c/pom.xml
> All subversion copies (via branch or prepare) originate from ${root}/master.
> As a result, they are incomplete; we really want to create copies from
> ${root} not ${root}/master. Here's the subversion command that I think is
> the problem:
> {noformat}
> [INFO] Working directory: C:\devsys\repos\trunk\master
> [INFO] Branching release with the label release-1.0...
> [INFO] Executing: svn --non-interactive copy --file
> C:\Users\cnelson\AppData\Local\Temp\maven-scm-1179760787.commit .
> http://hostname/svn/dev/branches/release-1.0
> {noformat}
> The period after the filename is what's indicating to subversion to create
> the copy from master instead of ${root}. Note: the working directory is
> derived from the basedir and I couldn't find a way to override the basedir.
> While not having the master pom at the root of the project may be a little
> uncommon, it doesn't seem unreasonable. Can we add a configuration option to
> handle these cases?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
