[proposal] Maven site navigation changes
Hello All, I've made some sample maven site navigation based on discussion on the list. The samples pages can be accessed at http://jira.codehaus.org/browse/MNG-2467 Post your comments on the issue, so that the discussion can be tracked easily. cheers, pete marvin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Maven site navigation changes
Sorry, here's the correct url http://jira.codehaus.org/browse/MNG-2473 Cabasson Denis wrote: Hum, is this just me, or the url for the sample page is kinda missing? (Didn't find any in the JIRA issue either) Denis. -Message d'origine- De : Pete Marvin King [mailto:[EMAIL PROTECTED] Envoyé : jeudi 24 août 2006 10:03 À : Maven Developers List Objet : [proposal] Maven site navigation changes Hello All, I've made some sample maven site navigation based on discussion on the list. The samples pages can be accessed at http://jira.codehaus.org/browse/MNG-2467 Post your comments on the issue, so that the discussion can be tracked easily. cheers, pete marvin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] add correct ejb-client to war if configured in dependency
I think this patch will fit in
http://jira.codehaus.org/browse/MWAR-58
Don't forget to add some comments on the issue after you attach it.
thanks,
pete marvin
Doug Douglass wrote:
Andreas,
I responded. My only advice is that you attach this patch to one of
the war
plugin JIRA issues that you cited. Add a comment to the other issue for
completeness. Patches sent to the mailing list(s) will probably get
little
reaction.
Just my .02$,
Doug
On 8/10/06, Andreas Wüst [EMAIL PROTECTED] wrote:
Hello,
since nobody responded on the user mailing list i am trying it with the
dev
list. the patch is related to the following ones :
http://jira.codehaus.org/browse/MWAR-59
http://jira.codehaus.org/browse/MWAR-38
Attached you will find a patch that will allow the maven-war-plugin
to add a ejb-client created by the maven-ejb-plugin. With the
latest cvs snapshot it is not possible to add the ejb client to the
war, always the ejb.jar will be added to the war file what is not
really inteded. the project looks like :
Parent
- Project A (Ejb)
- Project B (War)
this dependency will only add the ejb(server).jar to the war file.
What i really want is that the created ejb-client.jar is added to the
war.
adding the ejb(server).jar to the war file does not make sense for the
war file.
(the maven-ejb-plugin created a server and client version for the
de.blubb.project_name.ejb projekt,
which is actually another module of my project)
dependency
groupIdde.blubb.project_name/groupId
artifactIdejb/artifactId
version1.0/version
typeejb-client/type
/dependency
If the patch is obsolete, i was wondering if there is anybody out
there who is using the maven-ejb-plugin in combination with
the maven-war-plugin and is actually adding the
created ejb-client to the created war file successfully.
As far as i can tell the maven-ejb-plugin creates a client (if
requested) with the name artifcat-version-client.jar. however
the maven-war-plugin does not respect the -client in the client's
name. even if i set the type of the dependency to ejb-client
it is still getting the ejb.jar, not the ejb-client.jar. My
patch fixes this problem.
i can provide a testcase that shows the current problem, if requested.
feedback is really appreciated.
regards,
Andy
Index:
D:/WSAD/DefaultWorkspace/maven-war-plugin/src/test/java/org/apache/maven/plugin/war/WarExplodedMojoTest.java
===
---
D:/WSAD/DefaultWorkspace/maven-war-plugin/src/test/java/org/apache/maven/plugin/war/WarExplodedMojoTest.java
(revision
430070)
+++
D:/WSAD/DefaultWorkspace/maven-war-plugin/src/test/java/org/apache/maven/plugin/war/WarExplodedMojoTest.java
(working
copy)
@@ -478,7 +478,7 @@
File expectedWebSourceFile = new File( webAppDirectory,
pansit.jsp );
File expectedWebSource2File = new File( webAppDirectory,
org/web/app/last-exile.jsp );
// final name form is artifactId-version.type
-File expectedEJBArtifact = new File( webAppDirectory,
WEB-INF/lib/ejbclientartifact-0.0-Test.jar );
+File expectedEJBArtifact = new File( webAppDirectory,
WEB-INF/lib/ejbclientartifact-0.0-Test-client.jar );
assertTrue( source files not found: +
expectedWebSourceFile.toString(), expectedWebSourceFile.exists() );
assertTrue( source files not found: +
expectedWebSource2File.toString(), expectedWebSource2File.exists() );
@@ -488,7 +488,7 @@
expectedWebSourceFile.delete();
expectedWebSource2File.delete();
expectedEJBArtifact.delete();
-}
+}
Index:
D:/WSAD/DefaultWorkspace/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java
===
---
D:/WSAD/DefaultWorkspace/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java
(revision
430070)
+++
D:/WSAD/DefaultWorkspace/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java
(working
copy)
@@ -1022,8 +1022,15 @@
*/
private String getDefaultFinalName( Artifact artifact )
{
-return artifact.getArtifactId() + - + artifact.getVersion() +
. +
-artifact.getArtifactHandler().getExtension();
+String type = artifact.getType();
+if (ejb-client.equals( type )) {
+ return artifact.getArtifactId() + - +
artifact.getVersion() +
- + client +
+ . +
+ artifact.getArtifactHandler().getExtension();
+} else {
+ return artifact.getArtifactId() + - +
artifact.getVersion() +
. +
+ artifact.getArtifactHandler().getExtension();
+}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Mave site search box
Hello All, There was discussion on the list about putting a search box in the maven site index page. I gave it a shot, here's the sample page http://jira.codehaus.org/secure/attachment/21969/index.html Please post your feedback in the issue : http://jira.codehaus.org/browse/MNG-2471 Thanks, pete marvin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mave site search box
Tried that suggestion. I'm not sure if we're allowed to remove the google logo. Thanks for the feedback. pete marvin Cabasson Denis wrote: Now, that is a big box!!! Isn't there a way to make the Google logo a bit smaller? (I guess there are legals considerations there). For the design part, I would prefer 2 separate boxes for search and download. Would it be possible to add a radio button to include search in the mojo.codehaus.org domain (in addition to maven.apache.org)? (same comment posted in JIRA, as I don't know wether discussion will take place here or there). Denis. -Message d'origine- De : Pete Marvin King [mailto:[EMAIL PROTECTED] Envoyé : mercredi 2 août 2006 09:13 À : Maven Developers List Objet : Mave site search box Hello All, There was discussion on the list about putting a search box in the maven site index page. I gave it a shot, here's the sample page http://jira.codehaus.org/secure/attachment/21969/index.html Please post your feedback in the issue : http://jira.codehaus.org/browse/MNG-2471 Thanks, pete marvin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Uniform plugin site skin
Hello All, There's a discussion on the list on making the standard maven plugin's site skin uniform the the maven site. There's a suggestion in MNG1212, the site skin can be pack in a jar. But I'm wondering who will be responsible for maintaining the plugin site skins? if there are changes in the maven site skins then all plugin site skins needs to be updated. is the plugin maintainer responsible for this? or whoever changes the maven site skin? I'm also proposing we make an archetype for the standard maven plugins based on the mojo archetype, with the current maven site skin being configured in the site descriptor. wdyt? cheers, pete marvin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Refinements on the Maven Site plugin's list based on the discussion on the mailing list
Hello All, I tried to categorize the plugins on maven site's plugin list based on the discussion on the mailing list. It would be great if someone can provide a staging area for it. The patch can be found in : * http://jira.codehaus.org/browse/MNG-2468 ** *Please post your feedback on the issue, so that we can improve it further. thanks, pete marvin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Contribution to the Plugin Documentation
Hello All, I have contributed some plugin documentations for the ejb plugin and scm plugin. I don't have anyplace to stage the documentation patches if anyone is interested in staging these, the patch can be accessed in : http://jira.codehaus.org/browse/MEJB-17 http://jira.codehaus.org/browse/SCM-218 I'd be happy to fix and apply any comments and suggestions, feedback will be highly appreciated. =) Thanx! cheers, pete marvin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] WAR plugin: broken help link
hello, there's a new site documentations for the war plugin in the trunk. There's a better example of how to configure webResources. it's the 4th draft, if you have any comments please post it in MWAR-48. Mike Perham wrote: Looks like Brett committed draft 2 of the doc update in MWAR-48 and someone published the site, bugs and all. So the war site documentation needs to be polished and published ASAP. You can read through the patches attached to that issue and see if they provide the info you need. -Original Message- From: Matthew Beermann [mailto:[EMAIL PROTECTED] Sent: Thursday, July 06, 2006 10:51 AM To: dev@maven.apache.org Subject: [m2] WAR plugin: broken help link On the documentation site for the WAR plugin (http://maven.apache.org/plugins/maven-war-plugin/), the Filtering war dependencies link is broken. Which is unfortunate, because that's exactly the information I need right now. :P --Matthew Beermann - Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: List of components/parameters that a plugin can ask for?
see http://maven.apache.org/plugins/index.html on the specific plugin documentation page, check Project Documentation-Project Reports-Plugin Documentation then select the goal you wish to view. It's not much, but the basic information is there. =) Russell, Mark wrote: Is there a list anywhere of the components and parameters that a plugin can ask for (via the @component and @parameter annotations)? For example the MavenProjectHelper class is requested via @component, but the MavenProject class is requested via @parameter. Is there anyplace I can find a complete list of all these components and parameters? MAR - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RANT] This Maven thing is killing us....
sometimes it makes me wonder how gentoo manages their ebuilds. portage and maven both supports transitive dependencies, but somehow the portage ebuilds which can be compared to the maven pom is more stable and reliable. currently the number of portage ebuilds is around 24,000+, a large amount of ebuilds to maintain. i'm guessing the community plays a crucial part in the health of the ebuilds. the gentoo community has a lot of passionate people taking care of the ebuilds. jerome lacoste wrote: On 7/5/06, Steve Loughran [EMAIL PROTECTED] wrote: Ralph Goers wrote: Carlos Sanchez wrote: Yes you can, it's not the best way to do it but you can, by adding explicitly the dependency with the versoin you want to your pom. In the very worst case you have to add all transitive deendencies to your pom, like in Maven 1. [..] I've been following this thread with interest. It makes me think of the various problems Linux distribution have to deal with when making their own repositories. It took 10 years for these solutions to be what they are today. I really think some ideas should be reused, even though the goals are slightly different. Some features/ways of working that may or may not be applicable: - they typically use a versionning similar to x.y.z-n sometimes adding. -n can be used to fix packaging issues (POM in the case of maven). Vendor fixes are also accepted and version names reflect the vendor name. - the distributions with the best repositories typically require the package to be buildable from source. The build is tested in a separate environment where all the required build dependencies are listed, to make sure that the dependency list is accepted. Something similar should maybe be done before accepting a project on a POM, setting up a build environment based on the given pom. - number of versions of a particular package in a repo is reduced to a minimum. users are adviced to upgrade to the latest greatest to make sure that fixes are always present in the last released versions - responsibilities of preparing packages is spread around 10s of people. Packages are orphaned when no one is taking care of them. People can reuse tricks/scripts learned by former packagers to go on with the job. - use of provides and various other dependency markers (that's coming in m2 2.1 if I got it right) Cheers, Jerome - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin documentation standard
I think it's a good idea to be able to pull out the Project Document
to the top-level menus.
Currently it's hidden under Project Reports. The usual way to include
it on the site
descriptor is through ${reports}, maybe Project Documentation can have
its own
macro definition? like ${generated_documentation}. Or there's
already one and didn't
know about it. =)
Do you think it's also a good idea to standardized the top-level
menus? Pages no matter
how good is useless if it's not visible or tend to be ignored if not
easily accessible.
pete marvin
Brett Porter wrote:
I agree, I think there are some lessons to be learned from this for
apis and other project types in general (archetypes, and so on), and
the same tools can be used.
Worth keeping in mind, but I believe we've identified a particular
problem with plugin docs and should work to improve that asap.
- Brett
On 20/06/2006 1:15 AM, Ruel Loehr wrote:
Why stop at a plugin? Wouldn't this be valuable to have for
thirdparty dependencies as well?
Ruel Loehr
JBoss QA
-
512-342-7840 ext 2011
Yahoo: ruelloehr
Skype: ruelloehr
AOL: dokoruel
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, June 19,
2006 9:56 AM
To: Maven Developers List
Subject: Re: Plugin documentation standard
On 19 Jun 06, at 9:47 AM 19 Jun 06, Brett Porter wrote:
Hi,
Just thought I'd break this one out. This needs to be converted to
a guide - which is one of the tasks I'll list at the end.
(this is MNG-1987, btw)
* Required POM Elements
- modelVersion, version, group ID, artifact ID, packaging (required
anyway to build)
- name
- description
- url
- issueManagement
- prerequisites maven (I think it's good to make people think
about this)
- inceptionYear
- mailingLists (just a warning if missing as I guess there might
not be one, though we should have some other contact details - do
general contact details fit a list description?)
- license
- scm (warning if missing, may not be OSS!)
- organization
- plugin report must be configured
* Plugin configuration
- each @parameter field must have a description. Not required if
@readonly or @component
- Class level should have a description.
* Documents
- plugins must have an /index.html (from apt, xdoc, html etc). Not
generated automatically
- plugins must have a /usage.html, where the standard use case is
described. The recommended lifecycle phases should be listed. This
will almost be boilerplate (just some common configuration items,
how to include it in the POM, and whether it usually needs
executions or not). It will probably repeat for each goal available.
- plugins should have examples/*.html for individual use cases.
- plugins should have a FAQ page for common questions, issues, and
misunderstandings
Consider this example:
- use case: http://maven.apache.org/plugins/maven-release-plugin/
introduction.html
- specific examples: http://maven.apache.org/plugins/maven-release-
plugin/howto.html (should be broken out into examples/dryRun.apt, etc)
* Site descriptor
- navigation must include the link to the usage and the examples
under that
* Reports
- Plugin must have javadoc, jxr and changelog reports
* General guidelines
- Always be able to publish the latest and greatest. Mark new
features with the version they were introduced. Mark caveats in
certain versions.
- The Jetty6 and Cargo plugins are the level of information we are
looking for.
* Tasks (any volunteers? If so, please create a JIRA and grab it
(and drop a reply here to say so - eventually we'll get these all
in regardless though)
- convert the above to a guide on the Maven website
- add any missing checks to the docck plugin
- wire up the docck plugin to all maven plugins
- pilot plugins. Some of these have gone into JIRA already and been
assigned.
- rework the plugin reference page (a separate discussion,
MPLUGIN-7 is a starting point). This should be reworked not to
overwrite index.html
- create an archetype for a compliant plugin
- add @since tag to plugin fields (it's standard javadoc so we can
dual purpose it, but we need to acknowledge it in the descriptor)
Any additional thoughts?
Make a plugin to check all these thing and plug it into the
validation phase. This is all nice to enumerate but it will only
take effect when it is easy for people to comply.
- Brett
--
Brett Porter [EMAIL PROTECTED]
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Jason van Zyl
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
