[jira] Commented: (MAVENUPLOAD-2272) upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] Commented: (MAVENUPLOAD-2272) upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156321#action_156321 ] Francois Fernandes commented on MAVENUPLOAD-2272: - could you please tell me what is wrong with the package? > 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-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=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] 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] 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.
[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] 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: ""
javadoc: error - Illegal package name: ""
javadoc: error - Illegal package name: "Copyright"
javadoc: error - Illegal package name: "&"
javadoc: error - Illegal package name: ""
javadoc: error - Illegal package name: ""
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}
>
>
> maven-javadoc-plugin
>
>
>
> jar
>
> package
>
>
>
>
> *.internal*
>
>
>
>
>
> {code}
> The resulting output is as follows:
> [INFO] Error while creating archive:Exit code: 1 - javadoc: error - Illegal
> package name: " 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: "/>Copyright"
> javadoc:
[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}
maven-javadoc-plugin
jar
package
*.internal*
{code}
The resulting output is as follows:
[INFO] Error while creating archive:Exit code: 1 - javadoc: error - Illegal
package name: "Copyright"
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] 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}
org.springframework
spring-jmx
2.0.4
{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
myprefix.
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
