[jira] Commented: (MACR-3) Maven site should has an example with adding Main Class
[ https://jira.codehaus.org/browse/MACR-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=282661#comment-282661 ] Dennis Lundberg commented on MACR-3: Yes, I understood that is what you wanted. I am just pointing out that some of it is already documented elsewhere. So those bits will not be documented on the plugin site. If you write up the missing pieces I can add them to the plugin site. Maven site should has an example with adding Main Class --- Key: MACR-3 URL: https://jira.codehaus.org/browse/MACR-3 Project: Maven ACR Plugin Issue Type: Improvement Affects Versions: 1.0 Reporter: Gustavo Orair Maven ACR plugin should confirm if the resulting Manifest contain a setting for Main-Class, because The Java EE spec requires that app clients specify the main class (http://www.java.net/forum/topic/glassfish/glassfish/problems-using-java-web-start-application-client-libraries-not-found). If Manifest does not contain Main-Class a warning should be emitted. Also, It would be very valuable if some examples specifying Main-Class are added to the site http://maven.apache.org/plugins/maven-acr-plugin/. In actual configuration, users tend to create application clients without Main-Class and may get strange errors while trying to launch the application client. One example of these errors, may be accessed in: http://www.java.net/forum/topic/glassfish/glassfish/problems-using-java-web-start-application-client-libraries-not-found -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-266) Establish generated-webresource convention similar to generated-sources
[ https://jira.codehaus.org/browse/MWAR-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=282663#comment-282663 ] Dietrich Schulten commented on MWAR-266: see also http://netbeans.org/bugzilla/show_bug.cgi?id=182407 Establish generated-webresource convention similar to generated-sources --- Key: MWAR-266 URL: https://jira.codehaus.org/browse/MWAR-266 Project: Maven 2.x WAR Plugin Issue Type: Wish Reporter: Dietrich Schulten For generated java sources there is a convention to use a target folder generated-sources/[name of the generator]. The same applies to generated resources. Generator plugins are supposed to add their output results to the project sources during the generate-sources and generate-resources phase. Besides, the build-helper plugin allows to add src folders manually. Netbeans relies on this convention to find additional sources and resources in the IDE. I wish there was a similar convention for generated webresources, e.g. for generated faces configuration files as created by Openarchitectureware/MWE (http://wiki.eclipse.org/Modeling_Workflow_Engine_%28MWE%29). So here is my wish: Everything below generated-webresources/[name of the generator] should be included by the war plugin as additional webresource automatically. This would allow IDEs like Netbeans to include generated webresources automatically. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MWAR-266) Establish generated-webresource convention similar to generated-sources
Establish generated-webresource convention similar to generated-sources --- Key: MWAR-266 URL: https://jira.codehaus.org/browse/MWAR-266 Project: Maven 2.x WAR Plugin Issue Type: Wish Reporter: Dietrich Schulten For generated java sources there is a convention to use a target folder generated-sources/[name of the generator]. The same applies to generated resources. Generator plugins are supposed to add their output results to the project sources during the generate-sources and generate-resources phase. Besides, the build-helper plugin allows to add src folders manually. Netbeans relies on this convention to find additional sources and resources in the IDE. I wish there was a similar convention for generated webresources, e.g. for generated faces configuration files as created by Openarchitectureware/MWE (http://wiki.eclipse.org/Modeling_Workflow_Engine_%28MWE%29). So here is my wish: Everything below generated-webresources/[name of the generator] should be included by the war plugin as additional webresource automatically. This would allow IDEs like Netbeans to include generated webresources automatically. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5102) Mixin POM fragments
[ https://jira.codehaus.org/browse/MNG-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=282705#comment-282705 ] Darren Hartford commented on MNG-5102: -- Just to make sure there is an appropriate discussion on other points-of-view: as a consumer of different maven plugins/other projects there are times when each individual plugin/project requires a large amount of configuration within the pom (particularly third-party plugins). If mixin is intended to help mitigate this problem, great, just didn't want to assume without asking :-) Examples include the maven-gwt-plugin which requires a good amount of configuration, as well as Enunciate. Having those plugins be able to provide example mixin file that only focuses on their particular plugin will avoid a lot of merging problems that usually occur in sometimes very large pom.xml files. Mixin POM fragments --- Key: MNG-5102 URL: https://jira.codehaus.org/browse/MNG-5102 Project: Maven 2 3 Issue Type: Wish Components: POM Affects Versions: 2.2.1 Reporter: Anthony Whitford Fix For: 3.1 Attachments: maven-tiles.zip I am looking for a way to _mixin_ POM fragments into POMs. Note that this idea is beyond parent pom inheritance because all projects inherit from a corporate parent pom. The problem that I am running into is that the corporate parent pom is turning into an _everything but the kitchen sink_ POM and I'd like to dissect it into POM fragments relevant for individual modules. For example, I would like to have mixins for: * Java projects (that include static code analysis plugins, javadoc, etc.) * JPA projects (that include DDL generation) * Flex projects (that include flexmojos, asdoc, etc.) * Scala projects (that include the maven-scala-compiler plugin, scaladoc, etc.) * JavaScript projects (that include build plugins like maven-yuicompressor-plugin with jslint and compress goals) Hopefully, you get the idea. Without the ability to factor pom logic, we are left with two symptoms: # copy/paste duplication # complex _it does it all_ parent poms (which slow down builds because more plugins are loaded even though they might not do anything material) Note that a project may include multiple mixins as I could have a project that contains Java code, Scala code, and JavaScript. Another idea is that the mixins could be parameterized, so that the ultimate pom can be customized based on the parameters (like tokens). I recall reading about Mixins coming in Maven 3.1, but could not find any such issue to watch, so am creating one. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-211) assembly plugin and jar plugin disagree about whether to use uniqueVersion snapshot names
[ https://jira.codehaus.org/browse/MASSEMBLY-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=282734#comment-282734 ] Hellmut Adolphs commented on MASSEMBLY-211: --- We are seeing this problem as well using 2.2.1 We have both the jar and assembly plugin working together to produce a zip file that contains an executable jar (produced with the jar plugin including a manifest that has all dependencies) and all the jar library dependencies as well. The problem we are seeing is probably the same or similar to what you were having, I see some jars with timestamps (we are using SNAPSHOTS for development) but there is one of them that has not time stamp... and in the manifest its being looked for with a timestamp. So this disagreement between the assembly and jar plugin create class not found exceptions on run time. assembly plugin and jar plugin disagree about whether to use uniqueVersion snapshot names - Key: MASSEMBLY-211 URL: https://jira.codehaus.org/browse/MASSEMBLY-211 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-1 Reporter: Max Bowsher Assignee: John Casey Priority: Blocker Fix For: 2.2-beta-3 Attachments: CSMDirectoryListingOfJars.txt, CSMJarManifest.txt Background: Consider the following setup: jar-plugin configured with addClasspath=true, writing list of dependency jar file names into manifest of project jar. assembly-plugin configured with a dependencySet pulling all dependencies into a single directory. Result: application is runnable with with java -jar mainartifact.jar There has long been a problem (i.e. with assembly-plugin 2.1) that when deployed snapshot jars were in use, the jar and assembly plugins would disagree in whether the uniqueVersion name was used, and this is MNG-2456. However, assembly-plugin 2.2-beta-1 has introduced further complications to the situation by not using the lifecycle's default set of resolved artifacts, but by running a manual resolution of its own. This has made the two plugins disagree in more scenarios than before, and broke the workaround patch that I posted in MNG-2456. At the root of these problems is some very peculiar handling of the 'file', 'baseVersion' and 'version' fields of Artifact objects, two notable instances of which are the DefaultArtifact.isSnapshot method, which despite being an accessor, actually changes the state of the object, and the DefaultArtifactResolver.resolve method, which contains some rather bizarre manipulation of the 'file' field (more detail may comments in MNG-2456). An interim fix to this issue might involve workarounds in both the jar and assembly plugins to get them to agree. A true fix probably also involves fixing Maven core classes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MACR-3) Maven site should has an example with adding Main Class
[ https://jira.codehaus.org/browse/MACR-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=282737#comment-282737 ] Gustavo Orair commented on MACR-3: -- Lundberg, As you recommended, I am sending missing pieces to be added in plugin site. I would change inside the Usage Page (http://maven.apache.org/plugins/maven-acr-plugin/usage.html): I would add before If the packaging type defined in the pom.xml is app-client, the package lifecycle phase can be used the sentence: Define the package type to be app-client. Before: Pay attention that prior to Maven 3.0.4, the plugin's extension must be enabled since the app-client packaging type is new. I would add Pay attention that JEE spec requires to add a manifest and a Main-Class. So, your application client need this to be JEE compliant. See How can I specify a Main-Class: entry in the manifest of an Application Client jar? inside FAQ for more details. Note: Some application servers may execute an application client without a Main-Class if you specify the Main-Class while running, however specify Main-Class while running would not be possible for some technologies such as Java Web Start Technology. Inside FAQ Page (http://maven.apache.org/plugins/maven-acr-plugin/faq.html): Add as the FIRST question: 1 - How can I specify a Main-Class: entry in the manifest of an Application Client jar? JEE spec and also some launching technologies such as Java Web Start Technology require to add a manifest and a Main-Class in application clients. This requirement is done because the launching technology need to know which method to execute. So, you need to configure Maven Archiver accordingly inside the acr-plugin configuration of your pom.xml app-client project. Here is a sample pom.xml configured to use the class fully.qualified.MainClass as the main class: project ... build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-acr-plugin/artifactId ... configuration archive manifest mainClassfully.qualified.MainClass/mainClass /manifest /archive /configuration ... /plugin /plugins /build ... /project This configuration is really similar to making the jar executable for jar Maven projects. See Make the jar executable in Maven Archiver Examples Page for more details (http://maven.apache.org/shared/maven-archiver/examples/classpath.html#aMake). Optionally you can configure Archiver to use your own manifest file with an already define Main-Class. Details can be found here http://maven.apache.org/shared/maven-archiver/examples/manifestFile.html. Obviously, a good improvement should be make maven acr plugin warns the user if do not find a Main Class configuration neither a manifestFilesrc/main/resources/META-INF/MANIFEST.MF/manifestFile. In the case user added a manifestFile option and plugin couldn't check if this manifestFile has a Main-Class, the plugin could at least info the user to add a MainClass inside you own Manifest-File. Best regards, Maven site should has an example with adding Main Class --- Key: MACR-3 URL: https://jira.codehaus.org/browse/MACR-3 Project: Maven ACR Plugin Issue Type: Improvement Affects Versions: 1.0 Reporter: Gustavo Orair Maven ACR plugin should confirm if the resulting Manifest contain a setting for Main-Class, because The Java EE spec requires that app clients specify the main class (http://www.java.net/forum/topic/glassfish/glassfish/problems-using-java-web-start-application-client-libraries-not-found). If Manifest does not contain Main-Class a warning should be emitted. Also, It would be very valuable if some examples specifying Main-Class are added to the site http://maven.apache.org/plugins/maven-acr-plugin/. In actual configuration, users tend to create application clients without Main-Class and may get strange errors while trying to launch the application client. One example of these errors, may be accessed in: http://www.java.net/forum/topic/glassfish/glassfish/problems-using-java-web-start-application-client-libraries-not-found -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MNGSITE-144) Updates to NetBeans integration pages
[ https://jira.codehaus.org/browse/MNGSITE-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved MNG-5186 to MNGSITE-144: -- Complexity: (was: Intermediate) Component/s: (was: Documentation: General) Key: MNGSITE-144 (was: MNG-5186) Project: Maven Project Web Site (was: Maven 2 3) Updates to NetBeans integration pages - Key: MNGSITE-144 URL: https://jira.codehaus.org/browse/MNGSITE-144 Project: Maven Project Web Site Issue Type: Task Reporter: Jesse Glick Priority: Minor Attachments: x.diff Miscellaneous updates to pages talking about the NetBeans IDE, which are rather old and also miscapitalize the product name. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNGSITE-144) Updates to NetBeans integration pages
[ https://jira.codehaus.org/browse/MNGSITE-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MNGSITE-144. --- Resolution: Fixed Assignee: Dennis Lundberg Patch applied with minor modifications. Thanks! Updates to NetBeans integration pages - Key: MNGSITE-144 URL: https://jira.codehaus.org/browse/MNGSITE-144 Project: Maven Project Web Site Issue Type: Task Reporter: Jesse Glick Assignee: Dennis Lundberg Priority: Minor Attachments: x.diff Miscellaneous updates to pages talking about the NetBeans IDE, which are rather old and also miscapitalize the product name. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNGSITE-75) Add scriptSourceDirectory to introduction-to-the-standard-directory-layout.html
[ https://jira.codehaus.org/browse/MNGSITE-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MNGSITE-75. -- Resolution: Fixed Assignee: Dennis Lundberg The patch didn't apply any longer, but the change was small and easy to make manually. Thanks! Add scriptSourceDirectory to introduction-to-the-standard-directory-layout.html --- Key: MNGSITE-75 URL: https://jira.codehaus.org/browse/MNGSITE-75 Project: Maven Project Web Site Issue Type: Improvement Reporter: Nick Stolwijk Assignee: Dennis Lundberg Attachments: mngsite-75.patch On http://maven.apache.org/guides/introduction/introduction-to-the-pom.html there is a scriptSourceDirectory which is missing from introduction-to-the-standard-directory-layout.html. Patch will follow as soon as I have setup subversion. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNGSITE-50) Project information page is lacking
[ https://jira.codehaus.org/browse/MNGSITE-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MNGSITE-50. -- Resolution: Fixed Assignee: Dennis Lundberg These seem to have been fixed now. The Source Repository page has link to Maven 2 and 3. The Issue Tracking page references a whole bunch of trackers for the various parts of Maven. Project information page is lacking - Key: MNGSITE-50 URL: https://jira.codehaus.org/browse/MNGSITE-50 Project: Maven Project Web Site Issue Type: Wish Reporter: John Williams Assignee: Dennis Lundberg The Project Information page for Maven itself is missing most of the items that are typically present in Maven-generated project pages. Just as an example, the Surefire plugin's project information page (http://maven.apache.org/plugins/maven-surefire-plugin/project-info.html) has links for issue tracking, dependencies, and the project summary. All of these are relevant to Maven itself and most of them are present somewhere in the Maven site, but not having these links in the usual location makes them much harder to find. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNGSITE-79) Release instructions unclear
[
https://jira.codehaus.org/browse/MNGSITE-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MNGSITE-79.
--
Resolution: Won't Fix
Assignee: Dennis Lundberg
The focus of these pages have changed since this issue was created. They now
focus on releasing parts of the Maven project.
General ASF release instructions can be found at
http://www.apache.org/dev/publishing-maven-artifacts.html#maven and the ASF POM
has its own website at
http://maven.apache.org/pom/asf/
Release instructions unclear
Key: MNGSITE-79
URL: https://jira.codehaus.org/browse/MNGSITE-79
Project: Maven Project Web Site
Issue Type: Improvement
Reporter: David Jencks
Assignee: Dennis Lundberg
Refers to http://maven.apache.org/developers/release/releasing.html
This is AFAICT the de-facto advice on best practices for apache projects that
want to use maven... if there's more information elsewhere it should be
linked from here. As such it is sorely lacking some basic info such as...
1. It applies to projects using the apache pom version 5 which implies you
are deploying to nexus. This needs to be stated up front and the
consequences outlined (e.g. getting someone (who?) to move old stuff onto
nexus, and what happens to a large collection of projects (e.g. portals or
geronimo) that may not want to move everything at once)
2. if
altDeploymentRepository${deploy.altRepository}/altDeploymentRepository in
the release profile is actually recommended please document where the value
actually comes from.
3. In the Release Process for part of Maven 1.b it says Verify that all
pom.xml files have an SCM definition. I think this is wrong. IIUC only
root poms in a multimodule project should define scm.
4. In the note on the settings.xml server definition of
apache.snapshots.https please document that it is used from the apache 5 pom.
Also, I think that the password required is your apache svn password rather
than a possible p.a.o password. There is at least one other reference to
logging on to nexus with apache credentials that should be more
specifically apache svn username and password
5. If this is the de-facto advice to apache projects wishing to move from the
file based repo to apache's nexus it needs to be findable through google.
Linking it to INFRA-1885 would be good. Linking from the front page of the
maven docs would be good. More generic separate docs would be better.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNGSITE-133) Inadequate documentation on Maven modules
[ https://jira.codehaus.org/browse/MNGSITE-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MNGSITE-133. --- Resolution: Fixed Assignee: Dennis Lundberg I fixed the link to the book. Inadequate documentation on Maven modules - Key: MNGSITE-133 URL: https://jira.codehaus.org/browse/MNGSITE-133 Project: Maven Project Web Site Issue Type: Bug Environment: http://maven.apache.org/guides/mini/guide-multiple-modules.html Reporter: SebbASF Assignee: Dennis Lundberg The page http://maven.apache.org/guides/mini/guide-multiple-modules.html is very brief, considering that it is about the Maven module system. It contains a link for further information, but the link is broken: a class=externalLink href=http://www.sonatype.com/books/maven-book/reference/multimodule.html; Chapter 6. A Multi-module Project (Maven: The Definitive Guide)/a I had a look in the guide, but cannot find a suitable target for the link; there appears to be no definitive documentation on modules. Please can this be fixed ASAP as otherwise there is no official documentation for modules AFAICT. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNGSITE-119) French maven mirror proposal
[ https://jira.codehaus.org/browse/MNGSITE-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MNGSITE-119. --- Resolution: Won't Fix Assignee: Dennis Lundberg Thanks for your offer, but we already have a European mirror in the shape of repo2.maven.org. French maven mirror proposal Key: MNGSITE-119 URL: https://jira.codehaus.org/browse/MNGSITE-119 Project: Maven Project Web Site Issue Type: New Feature Reporter: Freddy munoz Assignee: Dennis Lundberg Please allow me introduce myself, my name is Freddy; I'm a software engineer at Antelink, a software development start-up in Paris, France. The Antelink development team uses intensively maven and other open-source development tools to build our private and community services (http://www.antelink.com/community). In this regard, we would like to give in return by becoming an official mirror of maven (our servers would be hosted in France, would be interesting for the Maven community to have a new reliable mirror in Europe.). Yet, before proceeding with the setup of a server, we would like to know whether our resources fit the mirroring needs. More precisely, we would like to know: - What do you require to push changes directly to the mirror (hosted in our servers)? Kind Regards -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNGSITE-116) Documentation: Maven installation instructions should be on a separate installation page, not in the download page
[ https://jira.codehaus.org/browse/MNGSITE-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MNGSITE-116. --- Resolution: Won't Fix Assignee: Dennis Lundberg I've add the word Install to the Run Maven page. Documentation: Maven installation instructions should be on a separate installation page, not in the download page -- Key: MNGSITE-116 URL: https://jira.codehaus.org/browse/MNGSITE-116 Project: Maven Project Web Site Issue Type: Improvement Reporter: Daniel Kaplan Assignee: Dennis Lundberg Priority: Minor this quick start guide should really have installation instructions link on it: http://maven.apache.org/run-maven/index.html#Quick_Start As I skimmed the quick start, I didn't expect the installation instructions to be on the download page. It took me a while to figure out how to install maven after I downloaded it. To put it another way: most software has their installation instructions on an installation page, not their download page. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHANGES-268) Create an issue link template for Sourceforge 2.0
Create an issue link template for Sourceforge 2.0 - Key: MCHANGES-268 URL: https://jira.codehaus.org/browse/MCHANGES-268 Project: Maven 2.x Changes Plugin Issue Type: Improvement Reporter: Matthias Nuessler The new SF.net 2.0 (currently beta) has new redesigned tools including a new bug tracker. The Issue Link Template would look like the following: %URL%/%ISSUE% -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
