[jira] Commented: (MAVENUPLOAD-2272) upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=157833#action_157833 ] Francois Fernandes commented on MAVENUPLOAD-2272: - As far as I can see, there is no download location for the separate Bundles. Wouldn't it be possible that you download that ZIP file, extract the contents and then run your script on them? As an alternative I can download the zip, extract all and attach them as separate files to this upload request. upload --- Key: MAVENUPLOAD-2272 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2272 Project: Maven Upload Requests Issue Type: Wish Reporter: Francois Fernandes another version of the svnkit library. -- 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-2272) upload
upload --- Key: MAVENUPLOAD-2272 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2272 Project: Maven Upload Requests Issue Type: Wish Reporter: Francois Fernandes another version of the svnkit library. -- 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-2116) Add strict mode, to avoid any stubbing, dummying, etc. activities to account for missing data.
[ http://jira.codehaus.org/browse/MNG-2116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=139536#action_139536 ] Francois Fernandes commented on MNG-2116: - beside this I suggest that a strict mode would fail any build if dependency version conflicts occur. The transparent version selection is nice but for some situations it should be clear which version will be used. Add strict mode, to avoid any stubbing, dummying, etc. activities to account for missing data. -- Key: MNG-2116 URL: http://jira.codehaus.org/browse/MNG-2116 Project: Maven 2 Issue Type: New Feature Components: General Affects Versions: 2.0.2 Reporter: John Casey Priority: Minor Fix For: 2.1 Currently, Maven will create a stub POM when it cannot find one on the remote repository. However, there are cases where we need to have the ability to verify that all the components of an application or some other type of build are present. Therefore, we need a strict mode for Maven, which will suppress any stubbing activities like this. -- 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: (MJAVADOC-126) Add the ability to load the stylesheet from a jar (resource)
[ http://jira.codehaus.org/browse/MJAVADOC-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francois Fernandes updated MJAVADOC-126: Attachment: 20080530-maven-javadoc-plugin-external-resources-integration-tests.zip 20080530-maven-javadoc-plugin-external-resources.patch * updated the patch to meet the current trunk. * renamed the extra-resources integration test to MJAVADOC-126 Add the ability to load the stylesheet from a jar (resource) Key: MJAVADOC-126 URL: http://jira.codehaus.org/browse/MJAVADOC-126 Project: Maven 2.x Javadoc Plugin Issue Type: Wish Affects Versions: 2.2 Reporter: Julien S Priority: Minor Attachments: 20080520-maven-javadoc-plugin-external-resources-integration-tests.zip, 20080520-maven-javadoc-plugin-external-resources.patch, 20080530-maven-javadoc-plugin-external-resources-integration-tests.zip, 20080530-maven-javadoc-plugin-external-resources.patch Currently, the stylesheetfile has to be given as a path on the filesystem, which makes sharing quite difficult. It would be nice to be able to retrieve it from a jar (like the checkstyle and the pmd plugins). -- 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: (MJAVADOC-126) Add the ability to load the stylesheet from a jar (resource)
[ http://jira.codehaus.org/browse/MJAVADOC-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francois Fernandes updated MJAVADOC-126: Attachment: 20080520-maven-javadoc-plugin-external-resources-integration-tests.zip 20080520-maven-javadoc-plugin-external-resources.patch Add the ability to load the stylesheet from a jar (resource) Key: MJAVADOC-126 URL: http://jira.codehaus.org/browse/MJAVADOC-126 Project: Maven 2.x Javadoc Plugin Issue Type: Wish Affects Versions: 2.2 Reporter: Julien S Priority: Minor Attachments: 20080520-maven-javadoc-plugin-external-resources-integration-tests.zip, 20080520-maven-javadoc-plugin-external-resources.patch Currently, the stylesheetfile has to be given as a path on the filesystem, which makes sharing quite difficult. It would be nice to be able to retrieve it from a jar (like the checkstyle and the pmd plugins). -- 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-189) Allow skipping of javadoc generation
Allow skipping of javadoc generation Key: MJAVADOC-189 URL: http://jira.codehaus.org/browse/MJAVADOC-189 Project: Maven 2.x Javadoc Plugin Issue Type: Improvement Reporter: Francois Fernandes Priority: Minor Attachments: 20080520-maven-javadoc-plugin-skip-javadoc.patch As javadoc may be running a long time it would be nice to have to possibility to skip the javadoc generation, much the same like skipping surefire tests. I've attached a patch which will skip javadoc:jar if maven.javadoc.skip has been specified. -- 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: (MJAVADOC-126) Add the ability to load the stylesheet from a jar (resource)
[ http://jira.codehaus.org/browse/MJAVADOC-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=135496#action_135496 ] Francois Fernandes commented on MJAVADOC-126: - I have the same problem. Attached to this Issue you'll find two files: * [^20080520-maven-javadoc-plugin-external-resources.patch]: this contains the logic for using resources artifacts which should be extracted into the javadoc target directory. * [^20080520-maven-javadoc-plugin-external-resources-integration-tests.zip]: associated integration tests Add the ability to load the stylesheet from a jar (resource) Key: MJAVADOC-126 URL: http://jira.codehaus.org/browse/MJAVADOC-126 Project: Maven 2.x Javadoc Plugin Issue Type: Wish Affects Versions: 2.2 Reporter: Julien S Priority: Minor Attachments: 20080520-maven-javadoc-plugin-external-resources-integration-tests.zip, 20080520-maven-javadoc-plugin-external-resources.patch Currently, the stylesheetfile has to be given as a path on the filesystem, which makes sharing quite difficult. It would be nice to be able to retrieve it from a jar (like the checkstyle and the pmd plugins). -- 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: (MJAVADOC-161) performRelease=true breaks install/deploy with multimodule projects
[
http://jira.codehaus.org/browse/MJAVADOC-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113324
]
Francois Fernandes commented on MJAVADOC-161:
-
I can verify that this issue is caused due to the maven-javadoc-plugin. Thank
you Sebastian for your note! Whithout this a release of our software wouldn't
be possible using the release plugin. I think this problem correlates to
MJAVADOC-137
performRelease=true breaks install/deploy with multimodule projects
---
Key: MJAVADOC-161
URL: http://jira.codehaus.org/browse/MJAVADOC-161
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.3
Reporter: Julien HENRY
Attachments: unTest.zip
Hi,
To build my project, I use:
mvn clean install -DperformRelease=true
In a multimodule project, it doesn't work if all dependencies are not already
in the local repository.
Step to reproduce:
1) create a multimodule project with moduleA and moduleB. moduleA depends on
moduleB.
2) Hit mvn clean install: should work
3) Clean your local repository (remove moduleA and moduleB)
4) Hit mvn clean install -DperformRelease=true:
{quote}
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Unnamed - com.capgemini:unTest:pom:1.0-SNAPSHOT
[INFO] Unnamed - com.capgemini:moduleB:jar:1.0-SNAPSHOT
[INFO] Unnamed - com.capgemini:moduleA:jar:1.0-SNAPSHOT
[INFO]
[INFO] Building Unnamed - com.capgemini:unTest:pom:1.0-SNAPSHOT
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory D:\test\unTest\target
[INFO] Deleting directory D:\test\unTest\target\classes
[INFO] Deleting directory D:\test\unTest\target\test-classes
[INFO] Deleting directory D:\test\unTest\target\site
[INFO] [site:attach-descriptor]
[INFO] Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[INFO] No goals needed for project - skipping
[INFO] [source:jar {execution: attach-sources}]
[INFO] Preparing javadoc:jar
[INFO]
[INFO] Building Unnamed - com.capgemini:unTest:pom:1.0-SNAPSHOT
[INFO]
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[INFO] No goals needed for project - skipping
[INFO]
[INFO] Building Unnamed - com.capgemini:moduleB:jar:1.0-SNAPSHOT
[INFO]
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[INFO] No goals needed for project - skipping
[INFO]
[INFO] Building Unnamed - com.capgemini:moduleA:jar:1.0-SNAPSHOT
[INFO]
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[INFO] No goals needed for project - skipping
[INFO] snapshot com.capgemini:moduleB:1.0-SNAPSHOT: checking for updates from
illiade-maven-repository-snapshots
Downloading:
http://illiade.sud.capgemini.fr/maven2-snapshots/com/capgemini/moduleB/1.0-SNAPSHOT/moduleB-1.0-SNAPSHOT.jar
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) com.capgemini:moduleB:jar:1.0-SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=com.capgemini -DartifactId=moduleB \
-Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) com.capgemini:moduleA:jar:1.0-SNAPSHOT
2) com.capgemini:moduleB:jar:1.0-SNAPSHOT
--
1 required artifact is missing.
for artifact:
com.capgemini:moduleA:jar:1.0-SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
illiade-maven-repository-snapshots
(http://illiade.sud.capgemini.fr/maven2-snapshots)
[INFO]
[jira] Created: (MNG-3277) Add new dependency scope: include
Add new dependency scope: include - Key: MNG-3277 URL: http://jira.codehaus.org/browse/MNG-3277 Project: Maven 2 Issue Type: Improvement Components: Dependencies Reporter: Francois Fernandes It should be possible to specify a included scope for dependencies. They have the same meaning as runtime but with the little difference that they will be included into the resulting artifact. This could be achieved by using the jar-with-dependencies descriptor of the assembly plugin. Anyway, it would be nice to specify a dependency, which includes some or all of its artiacts and the missing (not included) are resolved transitively. -- 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: (MJAVADOC-137) javadoc:javadoc always runs as aggregator
[
http://jira.codehaus.org/browse/MJAVADOC-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103634
]
Francois Fernandes commented on MJAVADOC-137:
-
Got a problem with the aggregator here. Since javadoc 2.3 and the plugin
running as an aggregator, our build is broken. Due to the forking of a
lifecycle there are arifacts not beeing generated and referenced by other
modules. This results in a build failure. Up until now I was unable to create a
simple testcase which reproduces our problem. But here is the basic layout of
our project.
{noformat}
parent
+-- assembly
+-- submodule-A
+-- mod-A
+-- mod-B
+-- mod-C
{noformat}
In our case the mod-B produces a javadoc jar (using javadoc:jar) und creates a
assembly using the assembly (attached mojo) plugin. Both mojos are beeing
executed at the package phase. The assembly module has a dependecy to the mod-B
generated assembly as a zip file. If the javadoc mojo executes and forks the
lifecycle, the assembly hasn't been created yet. That means that building
assembly is failing due to the missing depenency of mod-B:zip.
javadoc:javadoc always runs as aggregator
---
Key: MJAVADOC-137
URL: http://jira.codehaus.org/browse/MJAVADOC-137
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.3
Reporter: Peter Hendriks
Priority: Critical
In version 2.2, javadoc aggregation was configurable using the configuration
property aggregate. In version 2.3, all javadoc goals got the @aggregator
attribute added to its mojos (through a change in
org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java), and the goals now
always run aggregated regardless of the configuration setting. This breaks
our build as we require non-aggregated javadoc execution in our multi-module
poms. Please fix this so this is once again configurable and backwards
compatible with previous versions of the javadoc plug-in.
--
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-133) Javadoc fails if footer contains newlines
Javadoc fails if footer contains newlines
-
Key: MJAVADOC-133
URL: http://jira.codehaus.org/browse/MJAVADOC-133
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.2
Environment: Windows XP, java 1.6 u1
Reporter: Francois Fernandes
The current version of the javadoc plugin fails if the footer specified for the
project contains newline characters:
{code:xml}
plugin
artifactIdmaven-javadoc-plugin/artifactId
executions
execution
goals
goaljar/goal
/goals
phasepackage/phase
/execution
/executions
configuration
excludePackageNames*.internal*/excludePackageNames
footer
![CDATA[
table border=0
cellpadding=0
trtdimg
src=[EMAIL PROTECTED]/icon.gif width=32 //tdtd All rights
reserved./td/tr/table
]]
/footer
/configuration
/plugin
{code}
The resulting output is as follows:
[INFO] Error while creating archive:Exit code: 1 - javadoc: error - Illegal
package name: trtdimg
javadoc: error - Illegal package name: src=
javadoc: error - Illegal package name: [EMAIL PROTECTED]/icon.gif
javadoc: error - Illegal package name: width=
javadoc: error - Illegal package name: 32
javadoc: error - Illegal package name: //tdtdCopyright
javadoc: error - Illegal package name:
{noformat}
{noformat}
--
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: (MJAVADOC-133) Javadoc fails if footer contains newlines
[
http://jira.codehaus.org/browse/MJAVADOC-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francois Fernandes updated MJAVADOC-133:
Attachment: packages
options
testcase.zip
I've attached a simple testcase which will fail using maven 2.0.7. The
generated argument files are attached too.
When this testcase is beeing executed, the following output will be on the
commandline:
{noformat}
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'assembly'.
[INFO]
[INFO] Building my-artifact
[INFO]task-segment: [assembly:assembly] (aggregator-style)
[INFO]
[INFO] Preparing assembly:assembly
[INFO]
[INFO] Building my-artifact
[INFO]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [jar:jar]
[INFO] Building jar: C:\temp\my-artifact\target\my-artifact-1.0-SNAPSHOT.jar
[INFO] Preparing javadoc:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation.
[INFO] No goals needed for project - skipping
[INFO] [javadoc:jar {execution: default}]
Loading source files for package com.mycompany...
Loading source files for package com.mycompany.group1...
Loading source files for package com.mycompany.group2...
Loading source files for package com.mycompany.group2.sub1...
Loading source files for package com.mycompany.group2.sub2...
Loading source files for package com.mycompany.group2.sub3...
12 errors
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error while creating archive:Exit code: 1 - javadoc: error - Illegal
package name: tr
javadoc: error - Illegal package name: tdimg
javadoc: error - Illegal package name: src=
javadoc: error - Illegal package name: [EMAIL PROTECTED]/icon.gif
javadoc: error - Illegal package name: width=
javadoc: error - Illegal package name: 32
javadoc: error - Illegal package name: //td
javadoc: error - Illegal package name: tdCopyright
javadoc: error - Illegal package name:
javadoc: error - Illegal package name: /tr
javadoc: error - Illegal package name: /table
javadoc: error - Illegal package name:
Command line was:C:\Programme\Java\jdk1.6.0\jre\..\bin\javadoc.exe @options
@packages
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 3 seconds
[INFO] Finished at: Wed Jul 11 15:50:13 CEST 2007
[INFO] Final Memory: 6M/14M
[INFO]
{noformat}
Javadoc fails if footer contains newlines
-
Key: MJAVADOC-133
URL: http://jira.codehaus.org/browse/MJAVADOC-133
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.2
Environment: Windows XP, java 1.6 u1
Reporter: Francois Fernandes
Attachments: options, packages, testcase.zip
The current version of the javadoc plugin fails if the footer specified for
the project contains newline characters:
{code:xml}
plugin
artifactIdmaven-javadoc-plugin/artifactId
executions
execution
goals
goaljar/goal
/goals
phasepackage/phase
/execution
/executions
configuration
excludePackageNames*.internal*/excludePackageNames
footer
![CDATA[
table border=0
cellpadding=0
trtdimg
src=[EMAIL
[jira] Created: (MECLIPSE-274) Optional dependencies of dependencies are beeing ignored
Optional dependencies of dependencies are beeing ignored
Key: MECLIPSE-274
URL: http://jira.codehaus.org/browse/MECLIPSE-274
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: dependency resolution
Reporter: Francois Fernandes
If a projects depends on a artifact that has optional dependencies, these
optional dependencies are beeing ignored by the plugin.
Reproducing is easy:
{code:xml}
dependencies
dependency
groupIdorg.springframework/groupId
artifactIdspring-jmx/artifactId
version2.0.4/version
/dependency
/dependencies
{code}
The spring-jmx has a optional dependency to spring-aop which isn't included as
a project dependency inside the eclipse project. As the spring-aop artifact is
not beeing excluded explicitly it should be included as a dependency into the
eclipse project
--
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: (MECLIPSE-251) Allows prefixing of eclipse project name
[
http://jira.codehaus.org/browse/MECLIPSE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francois Fernandes updated MECLIPSE-251:
Attachment: 20070509-maven-eclipse-plugin.patch
As I've had the same problem, here's a little patch which should do the work. I
would appreciate any feedback and notes about it. This patch is based on the
revision 520045 at
https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-eclipse-plugin.
To prefix a project with a specific name just add
-Declipse.projectNamePrefix=myprefix to the command line and it should work.
Inside the configuration of the plugin just specifiy
projectNamePrefixmyprefix/projectNamePrefix.
One thing I haven't done (shame on me) was to generate testcases (again, shame
on me). The probleme was, that I have no idea of the correct way how to
implement such a testcase using the existing plexus framework.
Allows prefixing of eclipse project name
Key: MECLIPSE-251
URL: http://jira.codehaus.org/browse/MECLIPSE-251
Project: Maven 2.x Eclipse Plugin
Issue Type: New Feature
Components: multiproject
Affects Versions: 2.4
Reporter: Martin Desruisseaux
Attachments: 20070509-maven-eclipse-plugin.patch
This issue is related to MECLIPSE-44, MECLIPSE-119 and MECLIPSE-161. They
were closed as fixed by MECLIPSE-189, but the later doesn't adress fully our
issue (or works only if we are lucky).
We have two Maven projects (namely _Geotools_ and _Geoserver_) made of many
modules. Some Geoserver modules may (by accident) have the same name than
Geotools modules. For example both Geotools and Geoserver have a module named
_main_. We need to import those two projects in Eclipse, because they are
closely related and share the same pool of developpers. Before MECLIPSE-189,
it was not possible with those names, because of module name clash like
_main_. Since MECLIPSE-189, it is possible if we are lucky enough to have
different Geotools and Geoserver version numbers.
We would like a way to prefix every Eclipse module names. For example we
would like a way to add {{gt-}} in front of every Geotools modules imported
in Eclipse. I realize that the common practice in Maven projects seems to be
long module names (for example {{maven-eclipse-plugin}}), but such practice
seems quite redundant with group name. We would like to keep module names
that match SVN directory names or Maven report directory names (otherwise we
often get broken links in generated HTML pages), and we would like to keep
the path names simple and intelligible (long module names don't bring much
compared to full path names, which should already be unique).
The ability to add some prefix before Eclipse project names would help. If
this is not possible, something like {{addGroupNameToProjectName}} property
(similar to {{addVersionToProjectName}} defined in MECLIPSE-189) could be a
fallback.
--
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: (ARCHETYPE-68) simple j2ee should use placeholders like ${groupId} and ${artifactId} for generation
simple j2ee should use placeholders like ${groupId} and ${artifactId} for
generation
Key: ARCHETYPE-68
URL: http://jira.codehaus.org/browse/ARCHETYPE-68
Project: Maven Archetype
Issue Type: Improvement
Components: Archetypes
Reporter: Francois Fernandes
Attachments: 070330-maven-archetype-j2ee-simple.patch
the maven-archetype-j2ee-simple should use placeholders instead of hardcoded
definitions for pom settings like groupId or artifactId.
Attached a patch, modifying the maven-archetype-j2ee-simple to use placeholders.
--
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
