Re: Creating WEB-INF/lib directory
Ashish, Make sure you have specified war in your pom.xmlfile. Kind Regards, John Fallows. On 2/20/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: > > On 2/19/06, Ashish Srivastava <[EMAIL PROTECTED]> wrote: > > > Yes everything gets compiled in the target directory. > > I do not want to use to copy or create these > > directories. I want to keep the libraries with in its' > > own web contexts and do not want to copy them in the > > directories accessbile across the web contexts. > > Again, Maven should be putting the appropriate jars into WEB-INF/lib > for you. If it's not working, minimally we'll need to see your > pom.xml file and know exactly what commands you are executing. > > -- > Wendy > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- http://apress.com/book/bookDisplay.html?bID=10044 Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Re: [m2eclipse] Eclipse WebTools and Maven2 "Publishing Failed"
Hi Fabrizio, On 2/4/06, Fabrizio Giustina <[EMAIL PROTECTED]> wrote: > > > Publishing failed > > Resource /M2_REPO/commons-logging/commons-logging/1.0/commons- > > logging-1.0.jar does not exist. > > That's a WTP bug, in any version from WTP 1.0 till recent builds: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=116783 Thanks so much for the clarification! WTP 1.0 simply ignores external dependencies, later builds started to > fail publishing if the project contains dependencies with a variable > (vars are handled like phisical paths). Ony recent I/M builds are > finally handling this as expected. > Just grab a newer build from > http://download.eclipse.org/webtools/downloads/ and you will not have > problems anymore Okay, great! My environment uses Eclipse 3.2M4, WTP 1.5M4, M2 Eclipse plugin 0.0.4. Is this also fixed on the Eclipse 3.2 code stream? > I'll release a new version of the eclipse plugin during the weekend, > and I will republish the documentation with a warning on working WTP > versions. Good idea, that will help to prevent users from thinking the problem is with the M2 Eclipse plugin. Kind Regards, John Fallows. -- http://apress.com/book/bookDisplay.html?bID=10044 Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Re: [m2eclipse] Eclipse WebTools and Maven2 "Publishing Failed"
Thanks Lee, I'm trying this from home, so no proxy at the moment, although settings.xmlintegration will become more important later. :-) I tried your suggestion, but it did not seem to help. Just in case Eclipse or the Maven2 Eclipse plugin was being too smart and converting the "short-name" path to a canoncial path with spaces, I even relocated the to C:\m2repos, eliminating all spaces, but still no joy. ;-( The .settings/.component file does have all the relevant entries for each deployed JAR in the webapp, for example: uses ...but I still get the following error message: Publishing failed Resource /M2_REPO/commons-logging/commons-logging/1.0/commons- logging-1.0.jar does not exist. Is it possible that M2_REPO is really not defined during WTP deployment? Or could this be a more general problem with any classpath variable? Any pointers would be greatly appreciated. :-) Kind Regards, John Fallows. On 2/3/06, Lee Meador <[EMAIL PROTECTED]> wrote: > > There was a bug that showed up when you had spaces in the repository > location you told the maven2 eclipse plugin. You should try using the > short > name for "documents and settings" that you can get doing a "dir /x" in a > dos > box. The short name, on my machine, is DOCUME~1 for that folder. It lets > you > get rid of the spaces. > > The maven2 eclipse plugin 0.0.4 does not work with the proxy that you set > in > settings.xml. This leads to some "issues" if you need a proxy to let you > through to the remote repository. > > Maybe that could help. > > On 2/3/06, John Fallows <[EMAIL PROTECTED]> wrote: > > > > On 2/3/06, Domsch, Christian <[EMAIL PROTECTED]> wrote: > > > > > > we do have the same problem (its not a M4 specific problem, > > > it also shows up on eclipse 3.1.2 with WTP 1.0). I would > > > really like to have a solution to that. > > > > > > Btw, I scanned the eclipse wtp bug list and found something > > > on there. But they claim this has been solved since WTP 1.0M2 > > > or something like that. > > > (https://bugs.eclipse.org/bugs/show_bug.cgi?id=87474) > > > > > > Thanks for the pointer, Christian. This does indeed seem like the same > > bug, > > however it looks to be broken in my environment for Eclipse 3.2M4 and > WTP > > 1.5M4 and your environment for Eclipse 3.1.2 and WTP 1.0. > > > > Anyone else having similar difficulties, or better yet, a solution? > > > > Kind Regards, > > John Fallows. > > > > > -Original Message- > > > > From: John Fallows [mailto:[EMAIL PROTECTED] > > > > Sent: Freitag, 3. Februar 2006 07:05 > > > > To: Maven Users List > > > > Subject: [m2eclipse] Eclipse WebTools and Maven2 "Publishing Failed" > > > > > > > > > > > > I'm trying to use Eclipse 3.2M4, Eclipse WebTools 1.5M4, > > > > Maven2 Eclipse > > > > Plugin 0.0.4 and Tomcat 4.1. > > > > > > > > I have a WebTools Dynamic Web Project that uses Maven2 to > > > > resolve library > > > > dependencies. When trying to "Debug As -> Debug on Server", > > > > the following > > > > error occurs: > > > > > > > > Publishing failed > > > > Resource /M2_REPO/commons-logging/commons-logging/1.0/commons- > > > > logging-1.0.jar does not exist. > > > > > > > > It seems as though the "M2_REPO" variable is not being > > > > resolved correctly > > > > when the WAR is being constructed for deployment to Tomcat. > > > > > > > > Presumably this should resolve to > > > > C:\Documents and > > > > Settings\john.fallows\.m2\repository/commons-logging/commons-l > > > > ogging/1.0/commons- > > > > logging-1.0.jar > > > > > > > > which does exist on the local filesystem. > > > > > > > > Note that I have already set the Maven2 Preferences to use > > > > "C:\Documents and > > > > Settings\john.fallows\.m2\repository" as the Local Repository > > > > Folder value, > > > > enabling compilation to succeed. > > > > > > > > Btw, this type of IDE integration is exactly the right > > > > direction for Maven2 > > > > to be taking. Combined with automatic generation of all the > > > > various flavors > > > > of IDE project files, we are getting very close to having a > > > > single source of > > > > truth for both IDE development activities and continuous integration > > > > builds. Great work! > > > > > > > > Kind Regards, > > > > John Fallows. > > > > -- > > > > http://apress.com/book/bookDisplay.html?bID=10044 > > > > Author: Pro JSF and Ajax: Building Rich Internet Components, Apress > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > http://apress.com/book/bookDisplay.html?bID=10044 > > Author: Pro JSF and Ajax: Building Rich Internet Components, Apress > > > > > > > -- > -- Lee Meador > Sent from gmail. My real email address is [EMAIL PROTECTED] > > -- http://apress.com/book/bookDisplay.html?bID=10044 Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Re: [m2eclipse] Eclipse WebTools and Maven2 "Publishing Failed"
On 2/3/06, Domsch, Christian <[EMAIL PROTECTED]> wrote: > > we do have the same problem (its not a M4 specific problem, > it also shows up on eclipse 3.1.2 with WTP 1.0). I would > really like to have a solution to that. > > Btw, I scanned the eclipse wtp bug list and found something > on there. But they claim this has been solved since WTP 1.0M2 > or something like that. > (https://bugs.eclipse.org/bugs/show_bug.cgi?id=87474) Thanks for the pointer, Christian. This does indeed seem like the same bug, however it looks to be broken in my environment for Eclipse 3.2M4 and WTP 1.5M4 and your environment for Eclipse 3.1.2 and WTP 1.0. Anyone else having similar difficulties, or better yet, a solution? Kind Regards, John Fallows. > -Original Message- > > From: John Fallows [mailto:[EMAIL PROTECTED] > > Sent: Freitag, 3. Februar 2006 07:05 > > To: Maven Users List > > Subject: [m2eclipse] Eclipse WebTools and Maven2 "Publishing Failed" > > > > > > I'm trying to use Eclipse 3.2M4, Eclipse WebTools 1.5M4, > > Maven2 Eclipse > > Plugin 0.0.4 and Tomcat 4.1. > > > > I have a WebTools Dynamic Web Project that uses Maven2 to > > resolve library > > dependencies. When trying to "Debug As -> Debug on Server", > > the following > > error occurs: > > > > Publishing failed > > Resource /M2_REPO/commons-logging/commons-logging/1.0/commons- > > logging-1.0.jar does not exist. > > > > It seems as though the "M2_REPO" variable is not being > > resolved correctly > > when the WAR is being constructed for deployment to Tomcat. > > > > Presumably this should resolve to > > C:\Documents and > > Settings\john.fallows\.m2\repository/commons-logging/commons-l > > ogging/1.0/commons- > > logging-1.0.jar > > > > which does exist on the local filesystem. > > > > Note that I have already set the Maven2 Preferences to use > > "C:\Documents and > > Settings\john.fallows\.m2\repository" as the Local Repository > > Folder value, > > enabling compilation to succeed. > > > > Btw, this type of IDE integration is exactly the right > > direction for Maven2 > > to be taking. Combined with automatic generation of all the > > various flavors > > of IDE project files, we are getting very close to having a > > single source of > > truth for both IDE development activities and continuous integration > > builds. Great work! > > > > Kind Regards, > > John Fallows. > > -- > > http://apress.com/book/bookDisplay.html?bID=10044 > > Author: Pro JSF and Ajax: Building Rich Internet Components, Apress > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- http://apress.com/book/bookDisplay.html?bID=10044 Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
[m2eclipse] Eclipse WebTools and Maven2 "Publishing Failed"
I'm trying to use Eclipse 3.2M4, Eclipse WebTools 1.5M4, Maven2 Eclipse Plugin 0.0.4 and Tomcat 4.1. I have a WebTools Dynamic Web Project that uses Maven2 to resolve library dependencies. When trying to "Debug As -> Debug on Server", the following error occurs: Publishing failed Resource /M2_REPO/commons-logging/commons-logging/1.0/commons- logging-1.0.jar does not exist. It seems as though the "M2_REPO" variable is not being resolved correctly when the WAR is being constructed for deployment to Tomcat. Presumably this should resolve to C:\Documents and Settings\john.fallows\.m2\repository/commons-logging/commons-logging/1.0/commons- logging-1.0.jar which does exist on the local filesystem. Note that I have already set the Maven2 Preferences to use "C:\Documents and Settings\john.fallows\.m2\repository" as the Local Repository Folder value, enabling compilation to succeed. Btw, this type of IDE integration is exactly the right direction for Maven2 to be taking. Combined with automatic generation of all the various flavors of IDE project files, we are getting very close to having a single source of truth for both IDE development activities and continuous integration builds. Great work! Kind Regards, John Fallows. -- http://apress.com/book/bookDisplay.html?bID=10044 Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
M2 Eclipse Plugin
Folks, I've recently started playing around with the M2 Eclipse plugin - very cool stuff! Just wondering, apart from managing the libraries and neat repository searching, does M2 Eclipse plugin also implement an Eclipse Builder that would make sure all sources and resources are generated before compilation? Kind Regards, John Fallows. -- http://apress.com/book/bookDisplay.html?bID=10044 Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Re: Using Maven2 Site Plugin for Java.Net site documentation?
Hi Brett, On 1/29/06, Brett Porter <[EMAIL PROTECTED]> wrote: > > Hi John, > > On 1/10/06, John Fallows <[EMAIL PROTECTED]> wrote: > > Yeah, I considered that, but don't think it is quite right. This issue > of > > headings is specific to /index.html in the generated site, and does not > > affect any other page. If Java.Net was not prepending anything special > for > > the /index.html content (in addition to the regular Java.Net chrome), > then > > my src/site/apt/index.apt file would be of the form: > > For all this, I guess the best solution is going to be to allow out of > order sections (perhaps with a warning). This shouldn't be harmful, I > don't think. > > Can you file that in JIRA? http://jira.codehaus.org/browse/MNG-2024 I would like to be able to have a clean build with no warnings, despite having some APT fragment files in the project, and it would be important to still get warnings for other non-fragment APT files in case of user error. > Btw, is there any support in site skinning to supply an additional > Velocity > > Macro template for special files that have fixed names and should only > be > > generated once for the whole project, rather than running the macro on > every > > file in the site? > > No this is generally done by reports, but I'm not sure that's what you > are looking for here since it is really just a fragment. > > You can include it in the resources in the skin to have it hopy as > direct HTML - we might need to add some filtering though to be able to > modify it. That would be a new feature request if just static HTML is > not sufficient. I currently have a static HTML file in site/resources that successfully integrates with the Java.Net chrome. However, since this static file contains references to dynamically generated reports, I would like to generate this HTML fragment during site generation to keep the list of reports and their links synchronized. Having a custom report to generate this chrome fragment seems like a workaround, since we'll also need to customize the Velocity template used during site generation (which I understand can be customized by a site "skin"). I would like to have a single Java.Net "skin" that both gets the Velocity template correct and also generates the chrome fragment to dyamically link in the generated site reports. > Many of the standard Maven reports are duplicates of the Java.Net ones > added > > in the chrome at runtime, so we'd need to be able to exclude the > well-known > > duplicates and capture the rest automatically. > > > > It would be really great if all of this could actually be captured in a > > single site skin. > > The skin isn't really related to the selected reports at this point. > It might just need to be a FAQ on how to enable the right reports. Yep, fair enough. Even if these are generated anyway, it doesn't matter too much. Kind Regards, John Fallows. - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- http://apress.com/book/bookDisplay.html?bID=10044 Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Download page title
fyi - the download page title (window title) still says "Download Maven 2.0.1" instead of "Download Maven 2.0.2". http://maven.apache.org/download.html Kind Regards, John Fallows. -- http://apress.com/book/bookDisplay.html?bID=10044 Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
[m2] Respository create bundle mojo
Folks, When I try to run the repository create bundle mojo in a multi-module project, it fails with a build error: [ERROR] BUILD ERROR [INFO] [INFO] Packaging cannot be POM when creating an upload bundle. [INFO] As a workaround, I could go into each module directory manually and re-run the mojo, but then the parent pom.xml in the top level project directory is not present in any of those bundle JARs Any suggestions? Kind Regards, John Fallows. -- http://apress.com/book/bookDisplay.html?bID=10044 Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Re: APT syntax question
Has anyone managed to get hyperlinked images in the generated site docs authored using APT syntax? Kind Regards, John Fallows On 1/9/06, John Fallows <[EMAIL PROTECTED]> wrote: > > Is it possible to make a hyperlinked image using APT syntax? > > I was able to get an image (figure) and linked text working, but could not > discover the magic incantation for a linked image. :-) > > Kind Regards, > John Fallows. > > -- > Author Pro JSF and Ajax: Building Rich Internet Components > http://www.apress.com/book/bookDisplay.html?bID=10044 -- Author Pro JSF and Ajax: Building Rich Internet Components http://www.apress.com/book/bookDisplay.html?bID=10044
APT syntax question
Is it possible to make a hyperlinked image using APT syntax? I was able to get an image (figure) and linked text working, but could not discover the magic incantation for a linked image. :-) Kind Regards, John Fallows. -- Author Pro JSF and Ajax: Building Rich Internet Components http://www.apress.com/book/bookDisplay.html?bID=10044
Re: Using Maven2 Site Plugin for Java.Net site documentation?
Hi Brett, On 1/9/06, Brett Porter <[EMAIL PROTECTED]> wrote: > > Hi John, > > I think the answer is not to change the APT parsing, but allow mapping > level 1 to h3, level 2 to h4, etc (I think that's what you wanted?) It > still may be worth looking into. Yeah, I considered that, but don't think it is quite right. This issue of headings is specific to /index.html in the generated site, and does not affect any other page. If Java.Net was not prepending anything special for the /index.html content (in addition to the regular Java.Net chrome), then my src/site/apt/index.apt file would be of the form: Project Name some general project text goes here * Description the description text goes here * Mission the mission statement goes here As it is, Java.Net takes ownership of everything up to and including the "* Description". That's why I thought it would be useful to be able to provide context for APT parsing in this case. Suppose I would like to add another Section heading after the "Mission" Sub-section, such as a "Testimonials" Section, then there would be no way to represent that in the index.apt file if a change in heading mapping is used, whereas providing context would work fine. It might be useful to have some way to specify the structure without it being included in the generated documentation. For example: Project Name~!~ * Description~!~ the description text goes here * Mission the mission statement goes here Just an idea. :-) In all the other site documentation, I would definitely want Section to map to so that it matches the Project Name created automatically by Java.Net for /index.html. So, if we did go for a Section mapping to , it would need to be restricted to src/site/apt/index.apt only, although that would mean giving up on having additional Sections in /index.html, but that would be easy enough to live with. :-) Either way, these are core changes that would need to be investigated > (please JIRA). In the interim, can you achieve the look you want using > CSS to adjust the bigger headings? At the moment, my Maven-generated html site docs don't need any specific CSS, but they do reference the Java.Net "app" class as part of the java.net.vm Velocity template. This causes other contextual style selectors in the Java.Net CSS stylesheet to be picked up automatically, such as ".app h2" and ".app h3". At the moment, I'm just manually changing the Mission to Mission for /index.html when updating the site. I think it would be a good idea to release the CSS and site.vm as a > skin (either on java.net, or we'd accept it at Apache) so that other > java.net projects could use it out of the box. Yep, that's my plan. Btw, is there any support in site skinning to supply an additional Velocity Macro template for special files that have fixed names and should only be generated once for the whole project, rather than running the macro on every file in the site? For Java.Net a special file, called /project_tools.html is included at runtime inside the Java.Net navigation bar on the left side of the website for all pages. I'm using the following handwritten file on Java.Net - have to make sure Maven gets some credit for the generated site. :-) Project Reports Dependencies http://maven.apache.org/"; title="Built by Maven" > I would like to be able to dynamically generate the contents of this file, so that all the Maven-generated reports can be linked automatically. Many of the standard Maven reports are duplicates of the Java.Net ones added in the chrome at runtime, so we'd need to be able to exclude the well-known duplicates and capture the rest automatically. It would be really great if all of this could actually be captured in a single site skin. Kind Regards, John Fallows. On 1/10/06, John Fallows <[EMAIL PROTECTED] > wrote: > > Summary: > > > > I'm using the maven-site-plugin for Maven2 to generate the site > > documentation for a Java.Net project and the APT parser is choking on > the > > syntax needed to get the desired look for the index page. > > > > org.codehaus.doxia.module.apt.AptParseException: expected SECTION1, > found > > SECTION2 at line 20 > > > > Is there a workaround to let the parser continue? > > > > > > Background: > > > > Java.Net sites and Maven-generated sites both want to own the chrome > around > > the content defined in the site documentation. Initially, I tried > playing > > around with some tricks to automatically redirect the standard > > Java.Netindex page to the Maven generated index page, but then the > > Java.Net styles were lost and the other Java.Net chrome, such as > > breadcrum
Using Maven2 Site Plugin for Java.Net site documentation?
Summary: I'm using the maven-site-plugin for Maven2 to generate the site documentation for a Java.Net project and the APT parser is choking on the syntax needed to get the desired look for the index page. org.codehaus.doxia.module.apt.AptParseException: expected SECTION1, found SECTION2 at line 20 Is there a workaround to let the parser continue? Background: Java.Net sites and Maven-generated sites both want to own the chrome around the content defined in the site documentation. Initially, I tried playing around with some tricks to automatically redirect the standard Java.Netindex page to the Maven generated index page, but then the Java.Net styles were lost and the other Java.Net chrome, such as breadcrumbs, tabs, and especially login, were also lost. Btw, before figuring out how to turn off the Java.Net chrome (via /nonav in the URL) there was chrome from both Java.Net and Maven in the site docs, which definitely didn't look right. ;-) I finally settled on using a custom Velocity Macro template (see below) to generate the Maven2 site in a much more plain way, such that upon inclusion by Java.Net at runtime, all the styles would be picked up automatically, and the Java.Net chrome could remain. Some of the menus in this chrome can be customized by having a specially named file present in the web root, so I plan to leverage that to include links for Maven-generated reports, and a "Powered By" logo. Of course, it would be nice if that could be automated during Maven2 site generation, but I haven't got that far yet, due to the above APT parse error. :-) $title $bodyContent -- java.net.vm In addition to controlling the chrome for all pages on the site, Java.Netalso does something special with the index page. There is a pre-defined section at the top of the index page that includes the project name at , and a "Description" title at . Therefore, my Maven2 index.apt file starts with indented text, to indicate paragraph text for the description, which works just fine. However, when I try to add a second "h3" title for the index page, say "Mission", using the APT syntax for a sub-section, site generation breaks with an APT parsing error, because the APT parser has no awareness of the project name "section" title being managed by Java.Net at runtime. Therefore, it thinks I made a mistake to have my first title be a subsection instead of a section, but I really do need a subsection here. I realize that if the syntax for APT is relaxed too much, then many unwanted errors would leak into site documentation. However, I wonder if there is some value in keeping that strict default, but still being able to tell the APT parser that a particular file has a different initial state (such as after-subsection, instead of before-section) and then let the strict rules continue in that specific context? Kind Regards, John Fallows -- Author Pro JSF and Ajax: Building Rich Internet Components http://www.apress.com/book/bookDisplay.html?bID=10044
Re: plexus-archiver-1.3-SNAPSHOT?
Sure, now that I _know_ it's out there, I found it under the following... :-) http://www.ibiblio.org/maven2/org/codehaus/plexus/plexus-archiver/ rather than... http://www.ibiblio.org/maven2/plexus/plexus-archiver/ Thanks for the tip! Kind Regards, John Fallows. On 1/6/06, dan tran <[EMAIL PROTECTED]> wrote: > > would plexus-archiver-1.3 be ok? > > -D > > > On 1/6/06, John Fallows <[EMAIL PROTECTED]> wrote: > > > > Folks, > > > > Looks like plexus-archiver-1.3-SNAPSHOT is not available from > > http://snapshots.maven.codehaus.org even though there are dated > snapshots > > there. > > > > Any chance of getting this fixed in the CodeHaus snapshots repository? > > > > Kind Regards, > > John Fallows. > > > > -- > > Author Pro JSF and Ajax: Building Rich Internet Components > > http://www.apress.com/book/bookDisplay.html?bID=10044 > > > > > > -- Author Pro JSF and Ajax: Building Rich Internet Components http://www.apress.com/book/bookDisplay.html?bID=10044
plexus-archiver-1.3-SNAPSHOT?
Folks, Looks like plexus-archiver-1.3-SNAPSHOT is not available from http://snapshots.maven.codehaus.org even though there are dated snapshots there. Any chance of getting this fixed in the CodeHaus snapshots repository? Kind Regards, John Fallows. -- Author Pro JSF and Ajax: Building Rich Internet Components http://www.apress.com/book/bookDisplay.html?bID=10044
Re: [m2] Dependency scope options
Sean, On 1/2/06, Sean Schofield <[EMAIL PROTECTED]> wrote: > > I'm having trouble determining the scope choices for a dependency > entry. Right now I have something like: > > > commons-codec > commons-codec > 1.3 > compile > > > > commons-codec > commons-codec > 1.3 > test > > > I'd like to combine this dependency into one entry in my POM. Is ther > a value that covers *both* compile and test? > Here's the definition of the scopes from the Maven documentation at http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html There are 5 scopes available: - *compile* - this is the default scope, used if none is specified. Compile dependencies are available in all classpaths. - *provided* - this is much like compile, but indicates you expect the JDK or a container to provide it. It is only available on the compilation classpath, and is not transitive. - *runtime* - this scope indicates that the dependency is not required for compilation, but is for execution. It is in the runtime and test classpaths, but not the compile classpath. - *test* - this scope indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases. - *system* - this scope is similar to provided except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository. There should be no need to explicitly specify compile, as that is the default, and covers all classpaths, including test scope. Kind Regards, John Fallows. -- Author Pro JSF and Ajax: Building Rich Internet Components http://www.apress.com/book/bookDisplay.html?bID=10044
Re: auto download plugins from remote repo NOT central
Ryan, You can use the section of ~/.m2/settings.xml. Note: this file is located in C:\Documents and Settings\\.m2\settings.xml on WinXP. Kind Regards, John Fallows. On 12/29/05, Ryan Marsh <[EMAIL PROTECTED]> wrote: > > Is it possible to get maven2 to automatically download plugins from a > remote repository other than central? I have been unsuccessful in > getting mvn to use my own remote repository to download plugins from. > > This is for initial generation of a project so I can't specify > in a POM because there is none yet. I would like > to just add the project repo to settings.xml and see 'mvn > myproject:generate' work right off the bat. > > Ryan Marsh > (281) 785-1805 > [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Author Pro JSF and Ajax: Building Rich Internet Components http://www.apress.com/book/bookDisplay.html?bID=10044
Re: [m2] pom.xml syntax
On 10/5/05, Jason van Zyl <[EMAIL PROTECTED]> wrote: > On Wed, 2005-10-05 at 18:56 +0000, John Fallows wrote: > > Is it possible to customize the syntax of pom.xml without impacting > > the rest of the Maven2? > > In theory yes, but would we want to allow that I don't know. What do you > want to customize? Is is something generally useful that might be > incorporated into Maven itself? Not really - it's more of an intermediate step to aid initial Maven2 adoption for an existing build system. Over time we'll hopefully be able to consume pom.xml directly. We'll be sure to file any necessary enhancements or bugs that would otherwise prevent our migration to the standard pom.xmlsyntax. > > For example, could one provide a CustomMavenProjectBuilder and then > > register it as a Plexus MavenProjectBuilder component? > > Yes. > > > How would Maven2 decide which implementation to use, if both the > > Default and Custom implementations were registered on the M2 > > classpath? > > Plexus allows multiple implementations of a component which you select > by a component id or role hint as we call it in Plexus. You would make > your new component and would have to change the components.xml in maven- > project and it would work but I don't know if that's something I'd like > to see as a common occurrence. Agreed 100%. To get this working, we'd register a custom implementation with the same , but a different , say custom-syntax? Then we would have to directly update META-INF/plexus/components.xml to add that to the section of whatever consumes the MavenProjectBuilder , right? Does that mean we'd need to update the following from maven-core-2.0.jar!/META-INF/plexus/components.xml? org.apache.maven.Maven org.apache.maven.DefaultMaven org.apache.maven.project.MavenProjectBuilder custom-syntax org.apache.maven.lifecycle.LifecycleExecutor org.apache.maven.usability.diagnostics.ErrorDiagnostics org.apache.maven.execution.RuntimeInformation I was wondering if it was possible to put this in a different JAR, and leave maven-core-2.0.jar unchanged. This seems to imply that the org.apache.maven.Maven would need it's own as well. Is there a convenient way to get Maven2 to use a custom when discovering the org.apache.maven.Maven during "mvn" invocation? Kind Regards, John Fallows > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > -- > jvz. > > Jason van Zyl > jason at maven.org <http://maven.org> > http://maven.apache.org > > you are never dedicated to something you have complete confidence in. > No one is fanatically shouting that the sun is going to rise tomorrow. > They know it is going to rise tomorrow. When people are fanatically > dedicated to political or religious faiths or any other kind of > dogmas or goals, it's always because these dogmas or > goals are in doubt. > > -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [ANN] Maven 2.0 Release Now Available
Congratulations on a job well done. :-) Kind Regards, John Fallows. On 10/19/05, Brett Porter <[EMAIL PROTECTED]> wrote: > We are pleased to announce that Maven 2.0 has been released, and is > available for download from http://maven.apache.org/maven2/download.html > > Maven is a build system that provides software project management and > dependancy comprehension. Based on the concept of a project object model > (POM), Maven manages a project's build, reporting and documentation from > a central place. > > Maven 2.0 is a rewrite of the popular Maven application, designed to > both address previous functional requirements and provide a stable > platform for extending and enhancing its build management framework. > > This release is significantly faster and smaller than Maven 1.0 and > includes the following usability and performance improvements: > > * Enhanced Dependency Management - includes dependency closures >(transitive dependencies), version ranges, automatic build >numbering, and automatic updating on a configurable interval > > * Defined Build Lifecycle - developers can build any type of project >using standard commands such as compile, test and install > > * Unified Project Definition - manages all required build information in >a single POM now, including project information, dependencies and >plugin configuration > > * Extended Plugin Architecture - supports Java and scripting languages >such as Beanshell for plugin development > > * Better Repository Support - includes separated snapshot repositories, >a new more managable layout and per-project definitions of new >repositories > > * Expanded Reactor Operation - offers built-in support for multiple >projects (without the need to perform a full install cycle to compile >all projects) and support for project aggregation > > * New Site Management Tools - supports multiple input and output >formats, with input formats including wiki-like APT format and >docbook, while continuing to support traditional Maven XDoc and FAQ >format. > > * New Reporting API - offers a standardised method for producing project >information and reports > > * And much more... > > The Maven 2.0 release is considered stable and includes a Maven 1.0 > complete feature set, with additional functionality. The most popular > Maven 1.0 plugins have been converted for Maven 2.0, and many more are > available in beta. > See http://docs.codehaus.org/pages/MAVEN/Maven+Plugin+Matrix for more > information on particular plugins. > > Maven's advanced dependency management features rely on project > metadata. If you are interested in improving support for the users of > your project, see http://maven.apache.org/maven2/project-faq.html > > The Maven team would like to express thanks to the user and developer > community for their beta testing, feedback and contributions that helped > make the release possible! > > To get started with Maven now, see the getting started guide: > http://maven.apache.org/maven2/guides/getting-started/index.html > > > - > 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: [m2-b3] running a non-aggregator plugin after local install only
On 10/19/05, Brett Porter <[EMAIL PROTECTED]> wrote: > That's a good point. We will also investigate that avenue. > > Anything in a static var would also be an issue. Some of our unit tests did have some statics that we'll work on removing, and none of them had instance state that was not nulled out in tearDown. When I exclude the tests with statics from the surefire test suite, leaving 414 tests, the OutOfMemoryError still occurs, so it seems that something else is causing the leak. Note that the unit tests in question are part of the "api-module" project, whereas the OutOfMemoryError occurs during compilation of a subsequent "impl-module" project during the same reactor "install" build. As previously mentioned, skipping the tests causes the problem to go away. However, it is possible that there are multiple leaks (perhaps in some plugins?) and the test suite is just pushing it over the edge to trigger the OutOfMemoryError. Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2-b3] running a non-aggregator plugin after local install only
On 10/16/05, Brett Porter <[EMAIL PROTECTED]> wrote: > On 10/16/05, John Fallows <[EMAIL PROTECTED]> wrote: > > What do you mean by "reinstalled"? Is that related to m2 install? > > Yes, m2 install on a plugin that is already loaded will mean the next > time it is used, it will be reloaded (by checking the file timestamp). > > > > > I noticed that there is never any OutOfMemoryError in a local module > > project build, even when the top level project reactor build does > > throw an OutOfMemoryError. > > > > > > Not that big - only 4 modules, and no additional "sub-modules". There > > are 5 custom plugins too, giving a total of 22 custom goal executions > > during the reactor build. > > That seems unusual - m2 itself has a much bigger build. Is it possible > that your unit tests leak memory? Currently they are not forked, so > leaky tests will cause problems in a big reactor. > > I believe Cocoon had similar problems and we are going to look into it > in the next couple of weeks, but the tests would be the first thing to > check - is it all ok if -Dmaven.test.skip=true is used? Thanks for the tip, Brett. Disabling the tests did allow the build to succeed, and leaving the tests in place still causes the OutOfMemoryError, even on the 2.0-RC. I would like to better understand how (not) to write a leaky test. :-) My understanding is that each JUnit test is a separate instance of the test class, with independent setup and teardown. Suppose that some Object created during setup is not nulled out in teardown, then that would be a leak of private instance state inside the test class instance. I am wondering how this could lead to a real leak unless the test execution framework (surefire) is holding onto all the test instances even after testing has completed. If that is the case, wouldn't it also be a leak in surefire? In the meantime, I'll investigate to discover the leaks in our unit tests. :-) Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] managing transitive dependencies
On 10/7/05, Brett Porter <[EMAIL PROTECTED]> wrote: > The reason for this difference is because if B extends a class from A, > and C uses the class from B, A is required at compile time. Often this is not strictly necessary, but one usecase would be where Class-from-C extends Class-from-B, which extends Class-from-A and Class-from-C needs to call some protected method of Class-from-A, so it is needed at compile time, right? Thanks for helping to clarify my thinking on this. :-) Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2-b3] running a non-aggregator plugin after local install only
On 10/15/05, Brett Porter <[EMAIL PROTECTED]> wrote: > No, the plugins are only unloaded when reinstalled, but they are > unlikely to be the cause for this. What do you mean by "reinstalled"? Is that related to m2 install? I noticed that there is never any OutOfMemoryError in a local module project build, even when the top level project reactor build does throw an OutOfMemoryError. > How large is your reactor? Not that big - only 4 modules, and no additional "sub-modules". There are 5 custom plugins too, giving a total of 22 custom goal executions during the reactor build. Kind Regards, John Fallows. > On 10/15/05, John Fallows <[EMAIL PROTECTED]> wrote: > > Thanks Brett, > > > > On 10/13/05, Brett Porter <[EMAIL PROTECTED]> wrote: > > > This is fixed in the next Maven release (see it0013 for an example). > > > After traversing some hairy classloading issues, plugins can now be > > > reloaded during an execution which should pave the way for a console > > > and easier to use scripting. > > > > Would that also support more streamlined memory usage? > > > > I sometimes see an OutOfMemoryError for complex reactor builds, but if > > plugins could be executed and then unloaded, the steady-state memory > > usage should be much more constant, right? > > > > Kind Regards, > > John Fallows. > > > > > On 10/13/05, John Fallows <[EMAIL PROTECTED]> wrote: > > > > Folks, > > > > > > > > I developing a "non-aggregator" plugin that is manually executed on > > > > the command line using the goal name, in much the same way as "m2 > > > > idea:idea" is executed. > > > > > > > > However, this "custom:custom" plugin is still under development and so > > > > it has a n.m-SNAPSHOT version and has never been deployed to any > > > > central repository. Instead, it has been installed locally, so that > > > > it can be tested before the first official "release". > > > > > > > > When trying to run the plugin after a local install, I get the > > > > following exception. > > > > > > > > [INFO] Cannot find mojo descriptor for: 'custom:custom' - Treating as > > > > non-aggregator. > > > > [INFO] > > > > > > > > [INFO] Building Maven Plugin Parent > > > > [INFO]task-segment: [custom:custom] > > > > [INFO] > > > > > > > > [INFO] > > > > > > > > [ERROR] FATAL ERROR > > > > [INFO] > > > > > > > > [INFO] Diagnosis: Error resolving plugin version > > > > [INFO] > > > > > > > > [INFO] > > > > > > > > [ERROR] FATAL ERROR > > > > [INFO] > > > > > > > > FATAL ERROR: Error executing Maven for a project > > > > Error stacktrace: > > > > org.apache.maven.reactor.ReactorException: Error executing project > > > > within the reactor > > > > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:282) > > > > at org.apache.maven.cli.MavenCli.main(MavenCli.java:247) > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > > > at > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > > > > at > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > > > > > > > > at java.lang.reflect.Method.invoke(Method.java:324) > > > > at > > > > org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > > > > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > > > > at > > > > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > > > > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > > > > Caused by: org.apache.ma
Re: [m2-b3] running a non-aggregator plugin after local install only
Thanks Brett, On 10/13/05, Brett Porter <[EMAIL PROTECTED]> wrote: > This is fixed in the next Maven release (see it0013 for an example). > After traversing some hairy classloading issues, plugins can now be > reloaded during an execution which should pave the way for a console > and easier to use scripting. Would that also support more streamlined memory usage? I sometimes see an OutOfMemoryError for complex reactor builds, but if plugins could be executed and then unloaded, the steady-state memory usage should be much more constant, right? Kind Regards, John Fallows. > On 10/13/05, John Fallows <[EMAIL PROTECTED]> wrote: > > Folks, > > > > I developing a "non-aggregator" plugin that is manually executed on > > the command line using the goal name, in much the same way as "m2 > > idea:idea" is executed. > > > > However, this "custom:custom" plugin is still under development and so > > it has a n.m-SNAPSHOT version and has never been deployed to any > > central repository. Instead, it has been installed locally, so that > > it can be tested before the first official "release". > > > > When trying to run the plugin after a local install, I get the > > following exception. > > > > [INFO] Cannot find mojo descriptor for: 'custom:custom' - Treating as > > non-aggregator. > > [INFO] > > > > [INFO] Building Maven Plugin Parent > > [INFO]task-segment: [custom:custom] > > [INFO] > > > > [INFO] > > > > [ERROR] FATAL ERROR > > [INFO] > > > > [INFO] Diagnosis: Error resolving plugin version > > [INFO] > > > > [INFO] > > > > [ERROR] FATAL ERROR > > [INFO] > > > > FATAL ERROR: Error executing Maven for a project > > Error stacktrace: > > org.apache.maven.reactor.ReactorException: Error executing project > > within the reactor > > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:282) > > at org.apache.maven.cli.MavenCli.main(MavenCli.java:247) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > > > > at java.lang.reflect.Method.invoke(Method.java:324) > > at > > org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > > at > > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > > Caused by: org.apache.maven.lifecycle.LifecycleExecutionException: > > Error resolving plugin version > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycl > > eExecutor.java:1286) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLife > > cycleExecutor.java:516) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecu > > tor.java:498) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecy > > cleExecutor.java:307) > > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor. > > java:149) > > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:217) > > ... 9 more > > Caused by: org.apache.maven.plugin.version.PluginVersionResolutionException: > > Error resolving version for > > 'org.custom.maven.plugins:maven-custom-plugin': Failed to resolve a > > valid version for this plugin > > at > > org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion(Defa > > ultPluginVersionManager.java:202) > > at > > org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePlugi
[m2-b3] running a non-aggregator plugin after local install only
Folks, I developing a "non-aggregator" plugin that is manually executed on the command line using the goal name, in much the same way as "m2 idea:idea" is executed. However, this "custom:custom" plugin is still under development and so it has a n.m-SNAPSHOT version and has never been deployed to any central repository. Instead, it has been installed locally, so that it can be tested before the first official "release". When trying to run the plugin after a local install, I get the following exception. [INFO] Cannot find mojo descriptor for: 'custom:custom' - Treating as non-aggregator. [INFO] [INFO] Building Maven Plugin Parent [INFO]task-segment: [custom:custom] [INFO] [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Diagnosis: Error resolving plugin version [INFO] [INFO] [ERROR] FATAL ERROR [INFO] FATAL ERROR: Error executing Maven for a project Error stacktrace: org.apache.maven.reactor.ReactorException: Error executing project within the reactor at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:282) at org.apache.maven.cli.MavenCli.main(MavenCli.java:247) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.lifecycle.LifecycleExecutionException: Error resolving plugin version at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycl eExecutor.java:1286) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLife cycleExecutor.java:516) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecu tor.java:498) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecy cleExecutor.java:307) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor. java:149) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:217) ... 9 more Caused by: org.apache.maven.plugin.version.PluginVersionResolutionException: Error resolving version for 'org.custom.maven.plugins:maven-custom-plugin': Failed to resolve a valid version for this plugin at org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion(Defa ultPluginVersionManager.java:202) at org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion(Defa ultPluginVersionManager.java:79) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:1 56) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycl eExecutor.java:1277) ... 14 more Note that the "org.custom.maven.plugins" groupId is already in the pluginGroups section of ~/.m2/settings.xml, allowing that groupId to be searched for the "custom" plugin. Do I need to do something special so that the SNAPSHOT version can be picked up after only a local install? Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Delivering mock objects for a public API [was Re: [m2] custom compiler mojo]
On 10/9/05, Trygve Laugstøl <[EMAIL PROTECTED]> wrote: > On Thu, 2005-10-06 at 19:06 +0000, John Fallows wrote: > > On 9/28/05, Trygve Laugstøl <[EMAIL PROTECTED]> wrote: > > > On Mon, 2005-09-26 at 22:02 +, John Fallows wrote: > > > > On 9/25/05, Trygve Laugstøl <[EMAIL PROTECTED]> wrote: > > > > > On Sat, 2005-09-24 at 04:31 +, John Fallows wrote: > > > > > > On 9/23/05, Trygve Laugstøl <[EMAIL PROTECTED]> wrote: > > > > > > > On Fri, 2005-09-23 at 08:03 +, John Fallows wrote: > > > > > > [snip] > > > > > > > > [1]: http://jira.codehaus.org/browse/MNG-932 > > > > > > > > Yes, I understand that it would be generally useful to deliver a > > > > subset of the unit test code as a JAR. > > > > > > > > The above proposal still stands though, although the name "mock" can > > > > be treated as a placeholder for that subset until we have a better > > > > name. > > > > > > Not sure I agree, what more than distributing the test do you need? > > > > We need to make sure that not all the test code is delivered in the > > JAR, just the mocks. > > > > The reason is that this mock JAR is essentially a public API for > > testing, so any other test implementation code for the API project > > should not be included. > > > > This will prevent test authors using the mock JAR from inadvertently > > establishing a dependency on non-public test code in their own tests, > > that would then break when the API tests are changed. > > I think that the above JIRA issue is sufficient for your use case too as > it will have to include some form of includes/excludes thing. At least > there's a lot of stuff that's shared between installing a -test and a > -mock jar that will have to be resolved (as commented in the issue) > first. Looks like the issue has been closed, but I couldn't find any way to customize the includes/excludes for the test jar. Is this supported already or should I file another issue? Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] surefire context classloader
On 10/11/05, Brett Porter <[EMAIL PROTECTED]> wrote: > On 10/11/05, John Fallows <[EMAIL PROTECTED]> wrote: > > On 10/10/05, Brett Porter <[EMAIL PROTECTED]> wrote: > > > I think xerces needs to be endorsed if you want to use it as a parser, > > > and AFAIK that can't be done after the JVM has started up. So I think > > > you need to have the surefire forking ability to do this, and add a > > > feature to the plugin to enabled passing in an endorsed dir. > > > > The same error occurs when I have no dependency in pom.xml. > > Yes, the dependency is effectively a no-op. > > > > > Isn't there a built-in XML parser distributed with Java that should be > > reachable anyway? > > Yes, I'm not sure why it wouldn't be used though... do you have a > small test case we could look at? My apologies - looks like a false alarm. I found some code deep inside the test where the author had introduced a bug in the behavior of getResource() when modifying the thread context classloader. Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] why copy test resources?
On 10/10/05, Brett Porter <[EMAIL PROTECTED]> wrote: > That wouldn't work with includes/excludes. I suppose it could be made to work, though. :-) > The next version of the plugin only copies new files which should > minimise the effect of this. Okay - I'll retest when that becomes available to see how it performs. We have over 4000 resource files used during testing that are not filtered. Kind Regards, John Fallows. > On 10/11/05, John Fallows <[EMAIL PROTECTED]> wrote: > > Could we avoid spending time to copy all the test resources to the > > target directory during build if the resources are unfiltered? > > > > Instead, wouldn't it be sufficient to just put the src/test/resources > > directory on the test classpath? > > > > Kind Regards, > > John Fallows > > > > - > > 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]
Re: [m2] surefire context classloader
On 10/10/05, Brett Porter <[EMAIL PROTECTED]> wrote: > I think xerces needs to be endorsed if you want to use it as a parser, > and AFAIK that can't be done after the JVM has started up. So I think > you need to have the surefire forking ability to do this, and add a > feature to the plugin to enabled passing in an endorsed dir. The same error occurs when I have no dependency in pom.xml. Isn't there a built-in XML parser distributed with Java that should be reachable anyway? Kind Regards, John Fallows. > On 10/11/05, John Fallows <[EMAIL PROTECTED]> wrote: > > How is the thread context classloader determined for surefire test > > execution? > > > > I have a unit test that needs to parse an XML file, but it fails to > > initialize the SAXParserFactory, even though the following section is > > present in pom.xml... > > > > > > xerces > > xercesImpl > > 2.6.2 > > test > > > > > > During test execution, the following exception occurs... > > > > javax.xml.parsers.FactoryConfigurationError: Provider for > > javax.xml.parsers.SAXParserFactory can not be found > > at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source) > > > > Kind Regards, > > John Fallows. > > > > - > > 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]
[m2] surefire context classloader
How is the thread context classloader determined for surefire test execution? I have a unit test that needs to parse an XML file, but it fails to initialize the SAXParserFactory, even though the following section is present in pom.xml... xerces xercesImpl 2.6.2 test During test execution, the following exception occurs... javax.xml.parsers.FactoryConfigurationError: Provider for javax.xml.parsers.SAXParserFactory can not be found at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source) Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] why copy test resources?
Could we avoid spending time to copy all the test resources to the target directory during build if the resources are unfiltered? Instead, wouldn't it be sufficient to just put the src/test/resources directory on the test classpath? Kind Regards, John Fallows - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Delivering mock objects for a public API [was Re: [m2] custom compiler mojo]
On 9/28/05, Trygve Laugstøl <[EMAIL PROTECTED]> wrote: > On Mon, 2005-09-26 at 22:02 +0000, John Fallows wrote: > > On 9/25/05, Trygve Laugstøl <[EMAIL PROTECTED]> wrote: > > > On Sat, 2005-09-24 at 04:31 +, John Fallows wrote: > > > > On 9/23/05, Trygve Laugstøl <[EMAIL PROTECTED]> wrote: > > > > > On Fri, 2005-09-23 at 08:03 +, John Fallows wrote: > > [snip] > > > > [1]: http://jira.codehaus.org/browse/MNG-932 > > > > Yes, I understand that it would be generally useful to deliver a > > subset of the unit test code as a JAR. > > > > The above proposal still stands though, although the name "mock" can > > be treated as a placeholder for that subset until we have a better > > name. > > Not sure I agree, what more than distributing the test do you need? We need to make sure that not all the test code is delivered in the JAR, just the mocks. The reason is that this mock JAR is essentially a public API for testing, so any other test implementation code for the API project should not be included. This will prevent test authors using the mock JAR from inadvertently establishing a dependency on non-public test code in their own tests, that would then break when the API tests are changed. > > > Alternatively, is there any mileage in the idea of having completely > > separate sub-modules for main, mock, and test, all inside the > > api-module? > > Don't think so, but I also think I'm missing some information here :) Let me know what you think, now that the above additional requirement is more clear. Thanks in advance. Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] managing transitive dependencies
On 10/6/05, Brett Porter <[EMAIL PROTECTED]> wrote: > Sorry, I'm missing something. Why isn't B depending on A with "runtime" scope? B depends on A with "compile" scope because it directly uses classes from A during compilation, not just at runtime. This gives the following scenario. C --(compile)--> B --(compile)--> A But, I am concerned that this implies.. C --(compile)--> B C --(compile)--> A when all that is necessary is.. C --(compile)--> B C --(runtime)--> A so that C can successfully compile and so that the classes in both A and B can be loaded and resolved during unit testing of C. Kind Regards, John Fallows > On 10/6/05, John Fallows <[EMAIL PROTECTED]> wrote: > > Suppose I have 3 Maven2 projects, A, B and C. > > > > A is self-contained. > > B depends on A for-implementation-only. > > C depends on B. > > > > My understanding of dependency scopes is that if C depends on B at > > "compile" scope, then all of B's "compile" scope dependencies will > > also become transitive "compile" scope dependencies of C. > > > > How do I prevent the classes in A from being visible during > > compilation of C? Is this another usecase for "provided" scope? Or > > does marking the A dependency as "provided" scope may have other > > implications for project B? > > > > I am concerned about the potential to introduce an accidental direct > > dependency from A to C. > > > > Ideally, I'd like project B to control the full set of compile > > dependencies that are valid exports as transitive dependencies. > > > > Although I don't want to expose B's dependencies during compilation of > > C, some of those dependencies will be necessary at runtime or during > > unit test execution of C. > > > > Perhaps we could specify "compile" scope for C's dependency on project > > B itself, but "test" scope (say) for all of project B's dependencies? > > > > Kind Regards, > > John Fallows. > > > > - > > 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]
[m2] managing transitive dependencies
Suppose I have 3 Maven2 projects, A, B and C. A is self-contained. B depends on A for-implementation-only. C depends on B. My understanding of dependency scopes is that if C depends on B at "compile" scope, then all of B's "compile" scope dependencies will also become transitive "compile" scope dependencies of C. How do I prevent the classes in A from being visible during compilation of C? Is this another usecase for "provided" scope? Or does marking the A dependency as "provided" scope may have other implications for project B? I am concerned about the potential to introduce an accidental direct dependency from A to C. Ideally, I'd like project B to control the full set of compile dependencies that are valid exports as transitive dependencies. Although I don't want to expose B's dependencies during compilation of C, some of those dependencies will be necessary at runtime or during unit test execution of C. Perhaps we could specify "compile" scope for C's dependency on project B itself, but "test" scope (say) for all of project B's dependencies? Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] pom.xml syntax
Is it possible to customize the syntax of pom.xml without impacting the rest of the Maven2? For example, could one provide a CustomMavenProjectBuilder and then register it as a Plexus MavenProjectBuilder component? How would Maven2 decide which implementation to use, if both the Default and Custom implementations were registered on the M2 classpath? Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] non-filtered resource copy is incremental?
On 9/28/05, John Casey <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > doesn't look like it, from a quick read of the code. It's not using a > stale source scanner like the compiler plugin is... Understood. Filed issue MNG-1042. http://jira.codehaus.org/browse/MNG-1042 Kind Regards, John Fallows > John Fallows wrote: > | When filtering is disabled, are resources and testResources copied > | incrementally? > | > | For example, if the target file exists and has a more recent > | timestamp, is the resource file still copied? > | > | Kind Regards, > | John Fallows. > | > | - > | To unsubscribe, e-mail: [EMAIL PROTECTED] > | For additional commands, e-mail: [EMAIL PROTECTED] > | > | > | > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.6 (GNU/Linux) > > iD4DBQFDOvXWK3h2CZwO/4URAlD5AJiz87+3ExsCbfBJKMqX/EdIIXucAJ9ZHp8u > rbVmfkLGGtJA3Vce+/SjbQ== > =3hVe > -END PGP SIGNATURE- > > - > 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]
[m2] non-filtered resource copy is incremental?
When filtering is disabled, are resources and testResources copied incrementally? For example, if the target file exists and has a more recent timestamp, is the resource file still copied? Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2-b1] classifier-specific dependencies colliding with generic dependencies
On 9/28/05, Brett Porter <[EMAIL PROTECTED]> wrote: > I think its because the project you are depending on is in the > reactor, and its probably a bug. > > Basically, its trying to use the built version of that project, but > projects are only identified by group:artifactId Okay - filed issue MNG-1041. http://jira.codehaus.org/browse/MNG-1041 Kind Regards, John Fallows. > On 9/28/05, John Fallows <[EMAIL PROTECTED]> wrote: > > Folks, > > > > It seems like there is a collision between dependencies from the same > > project but with different classifiers, causing only the main > > dependency artifact to be present on the compilation classpath. > > > > This example will look familiar to anyone following a previous public > > mock api thread. :-) > > > > project/ > > api-module/ > > impl-module/ > > > > The api-module generates 2 artifacts, one with classifier "mock". > > The impl-module depends on both of these artifiacts, one with "mock" > > classifier at "test" scope and the other with no classifier at the > > default "compile" scope. > > > > During compilation of the impl-module tests, classes from the > > api-module "mock" artifact are not found on the classpath. > > > > It seems as though the "mock" artifact and the regular artifact are > > colliding, causing the "mock" artifact to be removed from the test > > compilation classpath. > > > > Both the "mock" and regular artifacts from the api-module have type > > "jar". Even when the "mock" type is changed to "zip", the same > > problem occurs. > > > > Perhaps dependency classifiers are ignored while constructing the > > compilation classpath? > > > > Kind Regards, > > John Fallows. > > > > - > > 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]
[m2-b1] classifier-specific dependencies colliding with generic dependencies
Folks, It seems like there is a collision between dependencies from the same project but with different classifiers, causing only the main dependency artifact to be present on the compilation classpath. This example will look familiar to anyone following a previous public mock api thread. :-) project/ api-module/ impl-module/ The api-module generates 2 artifacts, one with classifier "mock". The impl-module depends on both of these artifiacts, one with "mock" classifier at "test" scope and the other with no classifier at the default "compile" scope. During compilation of the impl-module tests, classes from the api-module "mock" artifact are not found on the classpath. It seems as though the "mock" artifact and the regular artifact are colliding, causing the "mock" artifact to be removed from the test compilation classpath. Both the "mock" and regular artifacts from the api-module have type "jar". Even when the "mock" type is changed to "zip", the same problem occurs. Perhaps dependency classifiers are ignored while constructing the compilation classpath? Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Delivering mock objects for a public API [was Re: [m2] custom compiler mojo]
On 9/25/05, Trygve Laugstøl <[EMAIL PROTECTED]> wrote: > On Sat, 2005-09-24 at 04:31 +0000, John Fallows wrote: > > On 9/23/05, Trygve Laugstøl <[EMAIL PROTECTED]> wrote: > > > On Fri, 2005-09-23 at 08:03 +, John Fallows wrote: > > > > I've created a custom compiler mojo that extends AbstractCompilerMojo > > > > from the maven-compiler-plugin. > > > > > > Is there a special reason for this? We where hoping that a new Compiler > > > implementation would suffice. The Compiler interface is defined in > > > plexus-compiler-api and you can select your own implementation by > > > setting the compilerId flag. > > [snip] > > In the snipped out part I understand what your issue is and agree that > it is a real issue. > > > Perhaps there is a better approach? > > The issue is not specific to mock objects, we could use the same thing > for our TCK type tests that we have for Maven SCM. See [1] for a issue > to follow (and vote for). I'm still not entirely sure how you would > separate out the tests for the artifacts itself and the reusable tests. > > Anyway, if you are mocking a Compiler implementation I'd be interested > to put that back into the Plexus repository. We'd need to decide on the correct lifecycle phase binding for the "mock" compiler. Strictly speaking, the input to the test-compile phase should include the compiled mock classes as a dependency. Presumably the default directories for source and target would be src/mock/java and target/mock-classes. We'd also want to take care of mock resources, making sure they are copied from src/mock/resources to target/mock-classes. This is sounding more like an extension of the current m2 lifecycle. validate generate-sources process-sources generate-resources process-resources compile process-classes generate-mock-sources process-mock-sources generate-mock-resources process-mock-resources mock-compile generate-test-sources process-test-sources generate-test-resources process-test-resources test-compile test package integration-test verify install deploy > [1]: http://jira.codehaus.org/browse/MNG-932 Yes, I understand that it would be generally useful to deliver a subset of the unit test code as a JAR. The above proposal still stands though, although the name "mock" can be treated as a placeholder for that subset until we have a better name. Alternatively, is there any mileage in the idea of having completely separate sub-modules for main, mock, and test, all inside the api-module? Kind Regards, John Fallows Kind Regards, John Fallows.
[m2] sources plugin
How does the sources plugin realize that it is part of a snapshot build, and therefore not generate a sources JAR? I didn't notice anything obvious in the source code for the Mojo at http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-plugins/maven-source-plugin/src/main/java/org/apache/maven/plugin/source/JarSourceMojo.java?rev=279318&view=markup Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] tests named XXXTestCase.java executed unexpectedly
On 9/24/05, Brett Porter <[EMAIL PROTECTED]> wrote: > Test*.java and *TestCase.java were added to the default list in > earlier releases. In that case, would it be useful to enhance the test discovery algorithm to not attempt to execute abstract testcase classes? Kind Regards, John Fallows. > > - Brett > > On 9/24/05, John Fallows <[EMAIL PROTECTED]> wrote: > > I have some base TestCase classes under src/test/java that are being > > executed during the test phase. > > > > This seems unexpected because their names do not match the default > > includes pattern of "**/*Test.java". > > > > One example could be src/test/java/org/example/ExampleTestCase.java. > > > > Kind Regards, > > John Fallows. > > > > - > > 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]
[m2] tests named XXXTestCase.java executed unexpectedly
I have some base TestCase classes under src/test/java that are being executed during the test phase. This seems unexpected because their names do not match the default includes pattern of "**/*Test.java". One example could be src/test/java/org/example/ExampleTestCase.java. Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Delivering mock objects for a public API [was Re: [m2] custom compiler mojo]
On 9/23/05, Trygve Laugstøl <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-09-23 at 08:03 +0000, John Fallows wrote:
> > I've created a custom compiler mojo that extends AbstractCompilerMojo
> > from the maven-compiler-plugin.
>
> Is there a special reason for this? We where hoping that a new Compiler
> implementation would suffice. The Compiler interface is defined in
> plexus-compiler-api and you can select your own implementation by
> setting the compilerId flag.
Glad you asked - it is symptomatic of a bigger issue to do with
delivering public mock objects for a public api.
Consider the following project layout:
project/
api-module/
src/
main/
test/
impl-module/
src/
main/
test/
Now consider that api-module defines a public Java API for general
consumption, whereas impl-module defines private Java implementation
that can change from release to release.
Many of the interfaces in api-module have associated mock objects used
by the api-module unit test code to test various api-module classes.
Naturally, many of the tests in impl-module also need to use the mock
objects defined by the api-module test code so there is a need for
some sort of mock object dependency.
However, the mock classes are not good candidates for their own
"mock-module" because of the following cyclic dependency.
api-module (test) -> mock-module (main) -> api-module (main)
and the alternative of
mock-module (test) -> mock-module (main) -> api-module (main)
moves the api unit tests into a different project, which allows the
api build to succeed even if the api unit tests fail.
So, I am attempting to keep the mocks for the public api in the
api-module as follows:
project/
api-module/
src/
main/
mock/
test/
impl-module/
src/
main/
test/
The reason for splitting the "mock" and "test" source groups is
because I need to deliver a JAR of mock api classes only, without
including the rest of the api unit test code.
The mock api JAR is for users consuming the api-module public API to
compile against when writing their own unit tests, so we don't want it
to be polluted with unit test code that they cannot safely depend upon
to remain stable between releases.
So, to achieve this purpose, I have written a "mock" plugin with the
following goals:
mock-process-resources (process-test-resources phase)
- copies src/mock/resources to target/mock-classes
- adds src/mock/java to test compilation sourcepath
mock-compile (test-compile phase)
- compiles src/mock/java to target/mock-classes
mock-package (package phase)
- creates a new artifact, called ${artifactId}-mock
- contents of artifact from target/mock-classes
- attaches it to the project for installation and deployment (not yet tested)
My first thought was to try to reuse the compiler plugin, but it just
didn't seem feasible using this approach.
Perhaps there is a better approach?
Kind Regards,
John Fallows.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[m2] custom compiler mojo
Folks, I've created a custom compiler mojo that extends AbstractCompilerMojo from the maven-compiler-plugin. However, at runtime, I'm getting a NPE in AbstractCompilerMojo.execute() because the compilerManager is null. The AbstractCompilerMojo has a special comment for compilerManager. /** * @component */ private CompilerManager compilerManager; This looks like some special indicator to instantiate compilerManager, but it doesn't appear to get instantiated during my custom plugin execution, probably because the relevant metadata is in the maven-compiler-plugin JAR, not my custom plugin JAR. Is it possible to make this work? Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to escape ${ in Jelly/Jexl ?
Try
Kind Regards,
John Fallows.
On 9/19/05, KC Baltz <[EMAIL PROTECTED]> wrote:
> We are in the process of migrating to Maven from Ant and I'm having a bit of
> trouble replicating in Maven a behavior we have in our Ant build. We use the
> Ant filtered copy mechanism where tokens are replaced with values. The copy
> task lets you specify your token delimiters and we chose ${ and } to begin
> and end our tokens respectively. So I tried to put the following in:
>
> id="build.propertiesFilter"
> description="Used to parse tokens in config files into their
> associated values in build.properties.">
>
>
>
> Maven complains about the value of begintoken because the ${ doesn't have a
> matching }. In Ant I escape $ with $$, but that doesn't appear to work here.
> I found an ugly workaround like this:
>
>
>
> id="build.propertiesFilter"
>
> That feels like a hack. Is there another way?
>
>
> K.C. Baltz
>
>
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] xmlbeans generated code in an m2 plugin
On 9/17/05, Jesse McConnell <[EMAIL PROTECTED]> wrote:
> I see what is going on...
>
> atm, I would say that you are probably doing what is needed given the way
> you have things packaged..
>
> it might help to pull out those generated classes from your plugin into
> thier own dependency, which could be simply a subproject in your project
> tree that is referenced as a dependency...I would think that would work, but
> having not tried it...I dunno for sure.
>
> If you think it is a bug then I would raise a jira issue on it, either as a
> comment on http://jira.codehaus.org/browse/MNG-697 or as a
> seperate issue entirey and maybe mention/link to that issue since it is a
> stab at addressing this kind of problem space (classpaths in plugins)
This problem seems unrelated to MNG-697 since it does not require the
plugin to access classes from the main project.
Filed JIRA Issue
MNG-908 Context class loader references incorrect realm during
plugin execution
http://jira.codehaus.org/browse/MNG-908
Kind Regards,
John Fallows.
> On 9/16/05, John Fallows <[EMAIL PROTECTED]> wrote:
> >
> > Just to be clear, the generated resources are actually packaged in my
> > plugin JAR.
> >
> > However, when the plugin executes, it does not have access to those
> > resources because the context class loader on the thread is not the
> > class loader of the plugin.
> >
> > I am proposing that the classloader of the plugin class be made the
> > active context class loader during plugin execution, and then restored
> > afterwards. (or something equivalent to these semantics)
> >
> > In the XmlBeans usecase, the context class loader was still set to
> > something else, presumably the classloader used for main project
> > processing. So, that classloader could not access the contents of my
> > plugin's JAR and XmlBeans therefore failed to load it's necessary
> > resources when running inside the plugin.
> >
> > This seems like a not-so-straightforward bug, but a bug nonetheless.
> >
> > Kind Regards,
> > John Fallows.
> >
> > On 9/16/05, Jesse McConnell < [EMAIL PROTECTED]> wrote:
> > > this is becoming a fairly common problem domain it seems
> > >
> > > as far as I know there is still no real straight-forward way to solve
> this
> > > outside of mucking around with classloaders in your plugin.
> > >
> > > there is the mechanism which would probably work as well
> but
> > > that is pretty cumbersome for this particular purpose...
> > >
> > > The rule of thumb is that the plugin runs in its own classloader and
> has
> > > access to the declared dependencies of the _plugin_ not the dependencies
> of
> > > the project that the plugin in running within...if you need to process
> the
> > > dependencies of the project in some way in your plugin then you need to
> do
> > > it by hand.
> > >
> > > there are a couple of examples of this in the mojo project, the
> > > maven-execute-plugin in the sandbox does this in a pretty simple sort of
> way
> > > if you want to take a look at that. (make sure you have
> > > @requiresDependencyResolution in the class lvl javadocs as well)
> > >
> > > List files =
> > > project.getCompileClasspathElements();
> > >
> > > URL[] urls = new URL[files.size()];
> > >
> > > for (int i = 0; i < files.size(); ++i) {
> > > getLog().debug((String)files.get(i));
> > > urls[i] = new
> > > File((String)files.get(i)).toURL();
> > > }
> > >
> > > URLClassLoader loader = new URLClassLoader(urls,
> > > Thread.currentThread()
> > > .getContextClassLoader());
> > >
> > > Class types[] = {String[].class};
> > >
> > > String[] args = (String[])params.toArray(new
> > > String[params.size()]);
> > >
> > > Class c = loader.loadClass(classname);
> > >
> > > Method m = c.getMethod("main", types);
> > >
> > > m.invoke(m, new Object[]{args});
> > >
> > > I have brought up the subject a number of times in different ways on
> irc
> > > but no real _good_ solution has been decided on. it isn't that bad to
> just
> > > do it yourself though...so don't worry, your not missing out on some
> spiffy
> > > way to do it...that I know about at least :)
> > >
>
Re: [m2] xmlbeans generated code in an m2 plugin
Just to be clear, the generated resources are actually packaged in my
plugin JAR.
However, when the plugin executes, it does not have access to those
resources because the context class loader on the thread is not the
class loader of the plugin.
I am proposing that the classloader of the plugin class be made the
active context class loader during plugin execution, and then restored
afterwards. (or something equivalent to these semantics)
In the XmlBeans usecase, the context class loader was still set to
something else, presumably the classloader used for main project
processing. So, that classloader could not access the contents of my
plugin's JAR and XmlBeans therefore failed to load it's necessary
resources when running inside the plugin.
This seems like a not-so-straightforward bug, but a bug nonetheless.
Kind Regards,
John Fallows.
On 9/16/05, Jesse McConnell <[EMAIL PROTECTED]> wrote:
> this is becoming a fairly common problem domain it seems
>
> as far as I know there is still no real straight-forward way to solve this
> outside of mucking around with classloaders in your plugin.
>
> there is the mechanism which would probably work as well but
> that is pretty cumbersome for this particular purpose...
>
> The rule of thumb is that the plugin runs in its own classloader and has
> access to the declared dependencies of the _plugin_ not the dependencies of
> the project that the plugin in running within...if you need to process the
> dependencies of the project in some way in your plugin then you need to do
> it by hand.
>
> there are a couple of examples of this in the mojo project, the
> maven-execute-plugin in the sandbox does this in a pretty simple sort of way
> if you want to take a look at that. (make sure you have
> @requiresDependencyResolution in the class lvl javadocs as well)
>
> List files =
> project.getCompileClasspathElements();
>
> URL[] urls = new URL[files.size()];
>
> for (int i = 0; i < files.size(); ++i) {
> getLog().debug((String)files.get(i));
> urls[i] = new
> File((String)files.get(i)).toURL();
> }
>
> URLClassLoader loader = new URLClassLoader(urls,
> Thread.currentThread()
> .getContextClassLoader());
>
> Class types[] = {String[].class};
>
> String[] args = (String[])params.toArray(new
> String[params.size()]);
>
> Class c = loader.loadClass(classname);
>
> Method m = c.getMethod("main", types);
>
> m.invoke(m, new Object[]{args});
>
> I have brought up the subject a number of times in different ways on irc
> but no real _good_ solution has been decided on. it isn't that bad to just
> do it yourself though...so don't worry, your not missing out on some spiffy
> way to do it...that I know about at least :)
>
> Jesse
>
>
>
>
>
> On 9/16/05, John Fallows <[EMAIL PROTECTED]> wrote:
> >
> > Ok, so i've done some more digging and it appears to be a classloader
> > problem in M2 rather than anything xmlbeans-specific.
> >
> > The reason that some of the xmlbeans type information is not available
> > is that a call to
> >
> contextClassLoader.getResourceAsStream("some-generated-xmlbeans-resource")
> > is returning null when it should be returning non-null.
> >
> > However, the class loader of the CustomMojo.class itself does return a
> > non-null stream as desired.
> >
> > So, I have worked around this by doing the following in CustomMojo:
> >
> > public void execute() throws MojoExecutionException
> > {
> > ClassLoader ccl = Thread.currentThread().getContextClassLoader();
> > try
> > {
> >
> Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
> > ... other Mojo code that calls XmlBeans here ...
> > }
> > finally
> > {
> > Thread.currentThread ().setContextClassLoader(ccl);
> > }
> > }
> >
> > Is this something that could be managed by the M2 runtime instead?
> >
> > Kind Regards,
> > John Fallows.
> >
> > On 9/16/05, John Fallows < [EMAIL PROTECTED]> wrote:
> > > Folks,
> > >
> > > I am currently developing a custom maven2 plugin that needs to parse
> > > some xml files (using xmlbeans). Therefore I used the m2 xmlbeans
> > > plugin at mojo.codehaus.org to generate the Java code for 3 different
> > > schema namespaces.
> > >
> > > Unit tests within the plugin verify that this code has been generated
> >
Re: [m2] xmlbeans generated code in an m2 plugin
Ok, so i've done some more digging and it appears to be a classloader
problem in M2 rather than anything xmlbeans-specific.
The reason that some of the xmlbeans type information is not available
is that a call to
contextClassLoader.getResourceAsStream("some-generated-xmlbeans-resource")
is returning null when it should be returning non-null.
However, the class loader of the CustomMojo.class itself does return a
non-null stream as desired.
So, I have worked around this by doing the following in CustomMojo:
public void execute() throws MojoExecutionException
{
ClassLoader ccl = Thread.currentThread().getContextClassLoader();
try
{
Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
... other Mojo code that calls XmlBeans here ...
}
finally
{
Thread.currentThread().setContextClassLoader(ccl);
}
}
Is this something that could be managed by the M2 runtime instead?
Kind Regards,
John Fallows.
On 9/16/05, John Fallows <[EMAIL PROTECTED]> wrote:
> Folks,
>
> I am currently developing a custom maven2 plugin that needs to parse
> some xml files (using xmlbeans). Therefore I used the m2 xmlbeans
> plugin at mojo.codehaus.org to generate the Java code for 3 different
> schema namespaces.
>
> Unit tests within the plugin verify that this code has been generated
> correctly and works as expected.
>
> However, when another m2 project attempts to use the custom plugin,
> not all the parsed xml data structures are strongly typed Java
> Objects. Instead, some are just simple XmlObjects, as though no type
> information was generated.
>
> It seems as though some of the type information cannot be located by
> the xmlbeans runtime when executed through a maven2 plugin. Could the
> classworlds classloader be somehow preventing xmlbeans from seeing all
> the type information?
>
> Kind Regards,
> John Fallows.
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2.0 Beta 1 Released
Congratulations to the Apache Maven team - this is a great milestone! Kind Regards, John Fallows. On 9/16/05, Brett Porter <[EMAIL PROTECTED]> wrote: > The Apache Maven team are proud to announce the beta release of Maven 2.0. > > Download it from http://maven.apache.org/maven2/download.html > > Maven is a software project management and comprehension tool. Based on > the concept of a project object model (POM), Maven can manage a > project's build, reporting and documentation from a central piece of > information. > > This release includes 206 bug fixes and enhancements [1] since the > previous release on 26 June. > > Maven 2.0 is a rewrite of the popular Maven application to achieve a > number of goals, and to provide a stable basis to take it into the > future. This release also includes the dependency management Ant tasks, > that bring all of Maven's dependency management features to Ant. > > The main new features in this release are: > > * Further improved dependency management: full support for dependency ranges > * Reactor project aggregation support and summary > * File system discovery of POMs and artifacts to reduce build time and > use of local and remote repositories > * Repository metadata support > * System scope dependency support > * Eclipse compiler support, ability to fork compiler > * Ability to automatically bundle sources and javadoc with deployments > * Maven 1.x repository support > * Allow use of setters in mojos for field population > * Ability to separate snapshot repository > * Ability to set minimum Maven version requirement for projects and plugins > * Build extension support > * Bugfixes and enhancements > > This release is considered stable with a feature set comparable to Maven > 1.0. Further betas and the final are expected to be backwards > compatible, with a primary goal of bugfixes, usability improvements, and > documentation. > > A large number of plugins will be released in the coming week to match > the primary Maven 1.0 plugin set. > See the Maven Plugin Matrix [2] for more information. > > We hope you enjoy using Maven! If you have any questions, please consult: > > * the web site: http://maven.apache.org/maven2/ > * the maven-user mailing list: http://maven.apache.org/mail-lists.html > > For news and information, see: > > * Maven Blogs: http://www.mavenblogs.com/ > > [1] > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&styleName=Html&version=11040 > [2] http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Matrix > > > - > 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]
[m2] xmlbeans generated code in an m2 plugin
Folks, I am currently developing a custom maven2 plugin that needs to parse some xml files (using xmlbeans). Therefore I used the m2 xmlbeans plugin at mojo.codehaus.org to generate the Java code for 3 different schema namespaces. Unit tests within the plugin verify that this code has been generated correctly and works as expected. However, when another m2 project attempts to use the custom plugin, not all the parsed xml data structures are strongly typed Java Objects. Instead, some are just simple XmlObjects, as though no type information was generated. It seems as though some of the type information cannot be located by the xmlbeans runtime when executed through a maven2 plugin. Could the classworlds classloader be somehow preventing xmlbeans from seeing all the type information? Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] warnings about invalid poms, ignored for artifact resolution
How can I determine the real problem indicated by the following warning? [WARNING] POM for: 'mygroup:myartifact:pom:1.2.3.4.5' does not appear to be valid. Its will be ignored for artifact resolution. In debug mode (m2 -X) no additional information is displayed. Btw, i'm working off the maven-components trunk, r289147. Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] plugin classpath
Makes sense - thanks.
When I tried to implement this approach,
project.getCompileClasspathElements() unexpectedly returned just the
project build output directory, and project.getArtifacts() returned
the empty set. However, project.getDependencies() is populated as
expected.
The plugin executes during generate-sources phase, and is triggered
implicitly by
m2 generate-sources
Any ideas on how to get a fully resolved compile classpath?
Kind Regards,
John Fallows.
On 9/15/05, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
> On Thu, 15 Sep 2005, John Fallows wrote:
>
> Hi,
>
> For now, you have to create an URLClassLoader and add the results
> of project.getXXXClasspath() to it. Then use that classloader to call
> getResource().
>
> Ofcourse, the build-project should be refferred to from the current
> project in a dependency, but I think that's already the case..?
>
> -- Kenney
>
> > Is it possible to add project dependencies to a plugin classpath?
> >
> > Here's the usecase project layout.
> >
> > project/
> > api-module/
> > impl-module/
> > build-module/
> >
> > The same plugin is used in both api-module and impl-module and needs
> > access to the same config files.
> >
> > The build-module contains the common config files and delivers a
> > self-contained JAR.
> >
> > The api-module and impl-module each depend on build-module.
> >
> > Is there some way to get build-module onto the classpath for the
> > plugin, so that ClassLoader.getResource("...") will see into the
> > contents of the build-module JAR during plugin execution?
> >
> > Perhaps ?
> >
> > Kind Regards,
> > John Fallows.
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> --
> Kenney Westerhof
> http://www.neonics.com
> GPG public key: http://www.gods.nl/~forge/kenneyw.key
>
> -
> 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]
[m2] plugin classpath
Is it possible to add project dependencies to a plugin classpath?
Here's the usecase project layout.
project/
api-module/
impl-module/
build-module/
The same plugin is used in both api-module and impl-module and needs
access to the same config files.
The build-module contains the common config files and delivers a
self-contained JAR.
The api-module and impl-module each depend on build-module.
Is there some way to get build-module onto the classpath for the
plugin, so that ClassLoader.getResource("...") will see into the
contents of the build-module JAR during plugin execution?
Perhaps ?
Kind Regards,
John Fallows.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] mock classes
There seems to be a bigger issue here too. What if I have the following project structure project/ api-module/ src/ main/ mock/ test/ impl-module/ src/ main/ test/ Now, api-module needs to provide mocks for use by both the api-module unit tests the impl-module unit tests. For impl-module unit test code to get the right dependency, the api-module mocks must be delivered as a JAR. This must be separate from the the main api-module JAR. So, why not just put the mocks in src/mock (alongside src/test) and make a mocks JAR as the secondary api-module deliverable? Well, that would need to JAR up the compiled mock classes which will be in api-module/target/test-classes. However, these test classes also include the compiled src/test/java classes, as well as test resources. Note: it is also not possible to split this out as a separate module, because there would be a cyclic dependency between api-module and "api-mock-module". Is there a way to deliver an api-module mock JAR that only contains classes for mocks, and can be used by both the api-module unit tests and the impl-module unit tests? Kind Regards, John Fallows. On 9/13/05, Jorg Heymans <[EMAIL PROTECTED]> wrote: > > Trygve Laugstøl wrote: > > > Just treat the mocks as unit test source code and use > > > > > > .. > > > > .. > > mocks > > .. > > > > > > > > Just tried this, doesn't seem to work. > > > Jorg > > > - > 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]
[m2] optimizing custom plugin execution
Folks, I'm writing a maven2 plugin that needs to parse various xml metadata files to drive it's behavior. There are a number of different (optional) goals in the same m2 plugin that need to consume the same xml metadata. Right now, each different goal is a different Mojo, with different instance state, so each Mojo is re-parsing the metadata files. Is there a best practice for sharing information across goals within the same plugin for the same lifecycle execution? Could the metadata be parsed on demand, and then maybe stored somewhere on the MavenProject for subsequent Mojos to locate? Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] plugin tests?
Hey Kenny,
I'm looking for something more like a unit test than an integration
test, such as:
public class MyMojoTest extends MojoTestCase
{
public void testMojo() throws MojoExecutionException
{
// create mojo, with default property values
Mojo mojo = createMojo(...);
// override certain mojo properties (optional)
setMojoProperty(mojo, "propertyName", ...);
// execute mojo
mojo.execute();
// check results for this particular test
}
}
The goal is to verify that this single Mojo class behaves as expected,
but it is not important to be running in the real M2 runtime.
However, since M2 runtime generally takes responsibility for
instantiation, configuration and execution of plugins, this needs to
be simulated for a unit test environment.
Is this a reasonable approach to M2 plugin testing, or is it better to
only test them using integration tests in the real M2 runtime?
Kind Regards,
John Fallows.
On 9/8/05, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
> On Thu, 8 Sep 2005, John Fallows wrote:
>
> You could try out the maven-it-plugin in the sandbox, if you're using
> svn head.
>
> Just place test projects in src/it/ and bind the maven-it-plugin
> to a phase after 'install', using the 'fork' goal.
>
> Unfortunately to be able to test a plugin it needs to be installed
> for maven to find it. I'm working on a way to let maven find and use that
> plugin so it doesn't need to be installed (it might already work since
> the 'current' project is in the reactor. You'd have to specify
> a dependency on it in the test project too, I think).
>
> As you can see it's not finished yet, so if you feel like
> experimenting, you're welcome.
>
> If not, take a look at the maven-eclipse-plugin. The JUnit tests
> 'fake' being maven, loading a fake pom, manually instantiating the
> Mojo, and using setter methods to fill in the parameters,
> and call the execute() method. I'm hoping to provide a general
> plugin testing framework (read: plugin :)) in maven-it-plugin
> so this 'hacking' isn't necessary.
>
> -- Kenney
>
> > What is the recommended approach for testing m2 plugin Java code?
> >
> > I would like to be able to write a JUnit test, but need to simulate
> > the bootstrap process of initializing the various properties to their
> > defaults, and possibly setting some non-default parameter values, all
> > before Mojo.execute() is called.
> >
> > Is there any existing solution for this? Perhaps a reusable JUnit
> > TestCase base class that could be extended?
> >
> > Thanks in advance,
> > John Fallows.
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> --
> Kenney Westerhof
> http://www.neonics.com
> GPG public key: http://www.gods.nl/~forge/kenneyw.key
>
> -
> 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]
[m2] plugin tests?
What is the recommended approach for testing m2 plugin Java code? I would like to be able to write a JUnit test, but need to simulate the bootstrap process of initializing the various properties to their defaults, and possibly setting some non-default parameter values, all before Mojo.execute() is called. Is there any existing solution for this? Perhaps a reusable JUnit TestCase base class that could be extended? Thanks in advance, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] plugin as module, timestamp checking and jar install
On 9/8/05, Brett Porter <[EMAIL PROTECTED]> wrote: > We were planning a more generic technique for this (letting Maven handle it > by declaring your inputs and only executing mojos that had their inputs > changed). This isn't scheduled for 2.0, however. That doesn't seem to cover the case where the inputs are static but the plugin itself is under development as a module and has changed since the last invocation. If none of the inputs have changed (static), and the plugin is not executed, then the plugin would not get a chance to throw away previously generated target files, even though they must be considered invalid. > If you have a solution to add to jar:jar and install:install then I'd be > happy to apply it. Where in the codebase should I be looking? I found that the maven-install-plugin uses an ArtifactInstaller, which is only an interface so the actual implementation is most likely instantiated by plexus. Where is the default implementation class for the ArtifactInstaller interface? It may very well already be implemented as incremental, since it seems like the target JAR is actually being recreated on each build. Looking at the maven-jar-plugin, it is using the MavenArchiver to create the JAR in target before installation. The MavenArchiver is eagerly creating some additional metadata files derived from the POM, then the Plexus JAR archiver is called to actually produce the archive. How incremental is the Plexus JAR archiver? Does it avoid updating the JAR if the contents are not different or is it based solely on timestamp? I would expect the latter, which explains the eager JAR creation due to the more recent timestamp on the per-build generated POM-derived metadata. Perhaps certain entries in the JAR archiver could be compared for content as well as timestamp, even when the timestamp indicates that they are more recent? This mode could be enabled for the Manifest, the pom.properties and the exported pom.xml files, giving a no-op on JAR creation when the output unchanged. This would then enable the ArtifactInstaller to behave truly incrementally, using a simple timestamp check. Thoughts? Kind Regards, John Fallows. > On 9/8/05, John Fallows <[EMAIL PROTECTED]> wrote: > > > > I'm developing a source generation plugin as a project module with the > > following structure: > > > > project/ > > plugin/ > > api/ > > impl/ > > > > where the plugin is part of the reactor build process. The plugin > > builds first and is used by the api and impl builds. > > > > As a good plugin developer citizen, I'd like to make sure the build is > > incremental when appropriate, so timestamp checks are used to avoid > > unnecessary regeneration of target files from source files during the > > api and impl builds. > > > > In addition, this incremental behavior should be avoided when the > > plugin itself has been updated because the previously generated api > > and impl results are no longer guaranteed to be valid. The > > plugin-up-to-date check can be verified using the timestamp of the > > plugin dependency JAR itself. > > > > Unfortunately, even when there is nothing to compile and no new > > resources to package, the install goal still copies the plugin JAR to > > the local repository, updating the timestamp and defeating the > > plugin-up-to-date check. > > > > Would it be reasonable to make the install goal incremental as well? > > For example, if nothing has changed and the local repository JAR has > > the same timestamp as the JAR sitting in project/plugin/target, then > > no need to copy? > > > > Kind Regards, > > John Fallows. > > > > > - > > 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]
[m2] plugin as module, timestamp checking and jar install
I'm developing a source generation plugin as a project module with the following structure: project/ plugin/ api/ impl/ where the plugin is part of the reactor build process. The plugin builds first and is used by the api and impl builds. As a good plugin developer citizen, I'd like to make sure the build is incremental when appropriate, so timestamp checks are used to avoid unnecessary regeneration of target files from source files during the api and impl builds. In addition, this incremental behavior should be avoided when the plugin itself has been updated because the previously generated api and impl results are no longer guaranteed to be valid. The plugin-up-to-date check can be verified using the timestamp of the plugin dependency JAR itself. Unfortunately, even when there is nothing to compile and no new resources to package, the install goal still copies the plugin JAR to the local repository, updating the timestamp and defeating the plugin-up-to-date check. Would it be reasonable to make the install goal incremental as well? For example, if nothing has changed and the local repository JAR has the same timestamp as the JAR sitting in project/plugin/target, then no need to copy? Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] customize default excludes?
On 9/6/05, Brett Porter <[EMAIL PROTECTED]> wrote: > Not currently possible - and probably not a great idea as there is potential > for different things to happen on different machines. Yes - I understand the general point. In this case, we would also happen to control a shared Maven2 installation, so it would be fine. > What you really need is to be able to configure it in a root POM shared by > all projects, I think. Agreed. I understand that the settings.xml approach is not currently possible - however is the root POM approach currently possible to customize the default set of excludes used by all the various plugins? If not, I can file an issue in JIRA. Kind Regards, John Fallows. > On 9/7/05, John Fallows <[EMAIL PROTECTED]> wrote: > > > > Our company uses a home-grown version control system that has it's own > > per-directory admin subdirectory, similar in purpose to the > > administration subdirectories used by other version control systems, > > eg. CVS, .svn, etc. > > > > These directories are excluded from processing by default in Maven2, > > and we would like to add our custom admin subdirectory to the default > > exclusion list. > > > > Is this possible? Perhaps something in settings.xml under M2_HOME? > > > > Kind Regards, > > John Fallows. > > > > > - > > 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]
[m2] customize default excludes?
Our company uses a home-grown version control system that has it's own per-directory admin subdirectory, similar in purpose to the administration subdirectories used by other version control systems, eg. CVS, .svn, etc. These directories are excluded from processing by default in Maven2, and we would like to add our custom admin subdirectory to the default exclusion list. Is this possible? Perhaps something in settings.xml under M2_HOME? Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] bootstrapping settings.xml in a corporate environment
Thanks for the info Kenney, I'll be sure to send more information to the mailing list as it is discovered. Btw, should we file this as a JIRA issue to make sure that such overriding is explicitly supported by Maven2? Kind Regards, John Fallows. On 8/11/05, Kenney Westerhof <[EMAIL PROTECTED]> wrote: > On Thu, 11 Aug 2005, John Fallows wrote: > > I've been having similar problems. Let me know if you can effectively > disable ALL downloads from repo1.maven.org. I saw that snapshot updates > for dependencies of maven2 itself still got downloaded from repo1. > I tried specifying repo's in the pom, in settings.xml, overriding > 'central', 'central-plugins', and 'snapshots', specifying mirrors. > Nothing worked. > > -- Kenney > > > What is the recommended strategy for bootstrapping M2 configuration to > > use an internal corporate "central" server, from behind a firewall? > > > > For example, is there a location under M2_HOME where a settings.xml > > could be stored such that it would be picked up automatically when m2 > > is executed? > > > > Alternatively, a settings.xml might be placed alongside pom.xml in a > > project directory, but this doesn't really solve the problem. > > > > Ideally, one could define this internal "central" repository once in a > > top-level parent pom that is referenced by each child project. > > Unfortunately, if the child project is executed directly, then a > > repository is needed to find the parent pom, creating a > > "chicken-and-egg" problem. > > > > So, having a project-local settings.xml would only work if it was > > sprinkled over every project, which defeats a single point of change > > unless you somehow make your version control system manage this part > > of the problem. > > > > Kind Regards, > > John Fallows. > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- > Kenney Westerhof > http://www.neonics.com > GPG public key: http://www.gods.nl/~forge/kenneyw.key > > - > 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]
[m2] bootstrapping settings.xml in a corporate environment
What is the recommended strategy for bootstrapping M2 configuration to use an internal corporate "central" server, from behind a firewall? For example, is there a location under M2_HOME where a settings.xml could be stored such that it would be picked up automatically when m2 is executed? Alternatively, a settings.xml might be placed alongside pom.xml in a project directory, but this doesn't really solve the problem. Ideally, one could define this internal "central" repository once in a top-level parent pom that is referenced by each child project. Unfortunately, if the child project is executed directly, then a repository is needed to find the parent pom, creating a "chicken-and-egg" problem. So, having a project-local settings.xml would only work if it was sprinkled over every project, which defeats a single point of change unless you somehow make your version control system manage this part of the problem. Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] trunk, r231365 unable to deploy
Further investigation has yielded more interesting results. :-) In turns out that the maven deploy plugin exception can be made to occur or not occur simply by the presence of a in my ~/.m2/settings.xml. Note that the profile does not even need to be active to trigger the "missing deploymentRepository" exception, so this seems like a bug rather than a mis-configuration of my environment. corporate corporate-central Corporate Maven http://... legacy After further debugging, it turns out that the contents of the actually has no impact, its mere presence triggers the bug. So... ...inside also triggers the exception during m2 deploy. Kind Regards, John Fallows. On 8/11/05, John Fallows <[EMAIL PROTECTED]> wrote: > Is there a problem with deployment on the m2 trunk, r231365? > > My project has "pom" packaging, with a > section that contains , and , > yet the maven-deploy-plugin deploy:deploy goal still fails with a null > deploymentRepository parameter. > > See below for pom.xml and stack trace. > > Thanks for any help you can provide. > > Kind Regards, > John Fallows. > > > 4.0.0 > > ... > ... > ... > pom > > > > corporate-central > http://... > legacy > > > > corporate-snapshots > http://... > legacy > > > > central > http://... > > > > > > corporate-plugins > http://... > > > > central-plugins > http://... > > > > > > corporate-central > scp://... > legacy > > > > corporate-snapshots > scp://... > > > > bali-site > http://... > > > > > > > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Diagnosis: Error configuring plugin for execution of 'deploy:deploy'. > [INFO] > > [ERROR] Cause: > org.apache.maven.plugin.MojoExecutionException: Error configuring > plugin for execution of 'deploy:deploy'. > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:342) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:472) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:445) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:431) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:127) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:186) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:292) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > > at java.lang.reflect.Method.invoke(Method.java:324) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.PluginParameterException: Invalid > or missing parameters: [Mojo parameter [name: 'deploymentRepository'; > alias: 'null']] for mojo: > org.apache.maven.plugins:maven-deploy-plugin:2.0-alpha-3:deploy > at > org.apache.maven.plugin.DefaultPluginManager.checkRequiredParameters(DefaultPluginManager.java:782) > at > org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:521) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:337) > ... 15 more > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] marmalade-parent pom 1.0-a3 malformed?
Seems okay now, after completely deleting my ~/.m2/repository and letting everything dowload again. Kind Regards, John Fallows. On 8/9/05, Brett Porter <[EMAIL PROTECTED]> wrote: > really? it looks ok in the repository. Can you try removing it locally > and letting it get downloaded again? > > Thanks, > Brett > > On 8/9/05, John Fallows <[EMAIL PROTECTED]> wrote: > > While trying to build the latest M2 trunk, which presumably now > > includes stricter pom.xml parsing (with much more readable errors - > > yay!), the marmalade parent pom dependency failed to parse. > > > > marmalade:marmalade-parent:1.0-alpha-3:pom > > > > It seems to need a rename from to to correctly wrap > > , , etc. > > > > As a workaround, I just modified the cached marmalade-parent pom in > > ~/.m2/repository. > > > > Kind Regards, > > John Fallows. > > > > - > > 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]
[m2] trunk, r231365 unable to deploy
Is there a problem with deployment on the m2 trunk, r231365? My project has "pom" packaging, with a section that contains , and , yet the maven-deploy-plugin deploy:deploy goal still fails with a null deploymentRepository parameter. See below for pom.xml and stack trace. Thanks for any help you can provide. Kind Regards, John Fallows. 4.0.0 ... ... ... pom corporate-central http://... legacy corporate-snapshots http://... legacy central http://... corporate-plugins http://... central-plugins http://... corporate-central scp://... legacy corporate-snapshots scp://... bali-site http://... [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Diagnosis: Error configuring plugin for execution of 'deploy:deploy'. [INFO] [ERROR] Cause: org.apache.maven.plugin.MojoExecutionException: Error configuring plugin for execution of 'deploy:deploy'. at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:342) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:472) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:445) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:431) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:127) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:186) at org.apache.maven.cli.MavenCli.main(MavenCli.java:292) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.PluginParameterException: Invalid or missing parameters: [Mojo parameter [name: 'deploymentRepository'; alias: 'null']] for mojo: org.apache.maven.plugins:maven-deploy-plugin:2.0-alpha-3:deploy at org.apache.maven.plugin.DefaultPluginManager.checkRequiredParameters(DefaultPluginManager.java:782) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:521) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:337) ... 15 more - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] trunk, r231316 clean:clean does not recurse by default
Thanks Trygve, but I am seeing a change in behavior for a "pom" packaged top level project with modules. There is no recursion of the "clean:clean" goal for this case on the trunk, which is a change in behavior from the last release. >From your description, this seems unintentional, or is it a deliberate change? Kind Regards, John Fallows. On 8/10/05, Trygve Laugstøl <[EMAIL PROTECTED]> wrote: > On Wed, Aug 10, 2005 at 10:50:52PM +, John Fallows wrote: > > Is this expected? > > For non-POM projects (packaging == "pom") this is the default and has > always been link that. For project with packaging="pom" it will execute > the clean:clean goal in all project listed inside the section of > the POM. > > > > > It seems that the old behavior can be achieved using m2 -r clean:clean. > > That's correct. > > > > > Perhaps a new lifecycle will be added so that one can just do m2 clean? > > I think that how it is today will suffice. > > $ m2 install > > will install all projects in the section and > > $ m2 clean:clean > > will likewise clean the same set of projects. > > -- > Trygve > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.1 (GNU/Linux) > > iD8DBQFC+oaM4EbM92cyCUURAltfAKCei1vAJkSDZMBY/BA50Y8AZ4ueTACfVjPr > QwOsh2ozKS9pOFE1VTvHBJI= > =t9Ox > -END PGP SIGNATURE- > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] trunk, r231316 clean:clean does not recurse by default
Is this expected? It seems that the old behavior can be achieved using m2 -r clean:clean. Perhaps a new lifecycle will be added so that one can just do m2 clean? Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] version string loses a zero during dependency resolution for pom
Using the latest M2 trunk. Suppose a JAR dependency has 0.09. When this dependency is being resolved, the POM that is used has a filename ending in 0.9.pom rather than 0.09.pom. It loses the first zero after the decimal point, leading to a dependency resolution failure. Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] marmalade-parent pom 1.0-a3 malformed?
While trying to build the latest M2 trunk, which presumably now includes stricter pom.xml parsing (with much more readable errors - yay!), the marmalade parent pom dependency failed to parse. marmalade:marmalade-parent:1.0-alpha-3:pom It seems to need a rename from to to correctly wrap , , etc. As a workaround, I just modified the cached marmalade-parent pom in ~/.m2/repository. Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] plugin parameter value configuration for non primitive types?
On 7/25/05, Peter van de Hoef <[EMAIL PROTECTED]> wrote:
> I think the PlexusConfiguration type is also worth mentioning here.
> It enabled me to pass a piece of xml right through to the plugin:
>
> import org.codehaus.plexus.configuration.PlexusConfiguration;
> ...
> class MyMojo [etc..]
> {
> /**
> * @parameter
> */
> private PlexusConfiguration anything;
> }
>
> Then, in the pom:
>
>
> org.apache.maven.plugins
> [etc...]
>
>
>
>
>
>
>
>
>
Thanks Peter, this is certainly very useful for passing XML fragments.
Kind Regards,
John Fallows.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[m2] jsp syntax verification
Does the war plugin verify the syntax correctness of JSP pages / documents during the build? If not, would this be a reasonable enhancement request to the maven-war-plugin? Or perhaps it should have its own maven-jspc-plugin? Such JSP files are usually compiled-on-demand after deployment to the web container. It would be useful to automatically fail the build when invalid JSP syntax is used. Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] slow filtered resources
On 7/19/05, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
> On Tue, 19 Jul 2005, Brett Porter wrote:
>
> Filtering is indeed off by default.
>
> My 2 cents:
>
> I've been pondering how to exclude resources from filtering. All that I
> could think of was to apply some includes/excludes mechanism (that would
> apply to all defined), or to add the tag to a
> tag to allow resources to be split up into filtering/non
> filtering ones. This would require a POM change..
>
> But the src/filtered-resources solution seems really great to me!
> Cons: you lose oversight (no more single directory structure for all
> resources)
Agreed.
To some degree, however, this has already happened as a result of
splitting Java source from JAR resources. For example, if there is
Java code in src/java/.../MyObject.java of the form:
MyObject.class.getResource("resource.txt");
then we have to ensure that resource.txt resides at the correct
location in src/resources, rather than just storing it next to
MyObject.java.
What was the original rationale for splitting these into separate
directories, rather than having a standard ".java" exclusion filter
for resources in the src/java/ directory?
Presumably, the same rationale applies here to the splitting of
resources and filtered resources.
> Pros: file location specifies filtering rather than complex
> include/exclude mechanisms in the pom.
Yes - although the name could use some work. :-)
perhaps src/resources-filtered to make it slightly more discoverable?
Kind Regards,
John Fallows.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[m2] slow filtered resources
If there are a lot of resources in a JAR, say images, and one text file that requires filtering, then filtering is still enabled with a global switch on the maven-reources-plugin, right? This seems to be causing a significant slow down in file copying. Perhaps all files are being put through the filtering process, even non-text files? Although my specific use case relates to binary vs. text files, I think this is a more general issue of filtered vs. non-filtered resources. Is there a way to restrict which resource files are filtered? The general directory layout for m2 seems to prefer to separate at top-level directories (eg. java vs. resources, rather than resource patterns inside java). Therefore, would it be appropriate to have separate java/, resources/ and filtered-resources/ directories, where filtering would only be enabled for files inside filtered resources? Then the rule would be: 1. if it is Java source, put it in java/ 2. if it is a static resource, put it in resources/ 3. if it is a filtered resource, put it in filtered-resources/ Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] plugin as module?
On 7/16/05, Brett Porter <[EMAIL PROTECTED]> wrote: > I think you had a pretty good handle on everything else in here, but > on this point: > > On 7/8/05, John Fallows <[EMAIL PROTECTED]> wrote: > > But, the reactor does not seem to notice that one of the modules is > > actually a plugin that is used by the other modules, so it does not > > ensure that the plugin module is executed before the other modules. > > Yep, there's an open bug for this. I think listing it first in > will do the trick for you now though - that's the fallback > after the intermodule dependencies. Thanks for the workaround, Brett. :-) Btw, I took a look on JIRA but didn't find the specific issue reported. Would you mind telling me the issue# so I can keep track of it? Thanks, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] deploy and release information
On 7/16/05, Brett Porter <[EMAIL PROTECTED]> wrote: > It should work. Please file a JIRA issue. Done, filed issue MNG-606. http://jira.codehaus.org/browse/MNG-606 Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] NPE in maven-javadoc-plugin
On 7/16/05, Brett Porter <[EMAIL PROTECTED]> wrote: > On 7/12/05, John Fallows <[EMAIL PROTECTED]> wrote: > > I just noticed a NPE in the Maven2 Javadoc Report that occurs when > > ... is not present in the > > POM. > > > > Do I just file this bug against MNG/maven-reports on JIRA? Done, issue MNG-604. http://jira.codehaus.org/browse/MNG-604 Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] plugin parameter value configuration for non primitive types?
Thanks Kenney, this is very helpful. :-) Would you mind posting a message to this email thread that contains a link to the APT documentation after is available on maven site? Kind Regards, John Fallows. On 7/15/05, Kenney Westerhof <[EMAIL PROTECTED]> wrote: > On Fri, 15 Jul 2005, John Fallows wrote: > > > What syntax is supported for M2 Plugin parameters of non-primitive types? > > > > For example, java.util.Collection (and subclasses), java.util.Map (and > > subclasses), arrays, Properties and JavaBeans. > > Collections / arrays: > > > value > > > value > value2 > > > > > > > 1 > stringvalue > > > > Map: > > > the value > another value > ... > > > > > Properties: > > > > the key > the value > > .. > > > JavaBeans: > > when 'items' maps to a field that is a JavaBean, it is treated > the same as the top-level 'configuration' tag, that is mapped > to the component instance. > > > > > /** > > * Items to be processed, defaults to the empty set. > > * > > * @parameter > > */ > > private Set items = Collections.EMPTY_SET; > > > > > > ??? > > > > > > Kind Regards, > > John Fallows. > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- > Kenney Westerhof > http://www.neonics.com > GPG public key: http://www.gods.nl/~forge/kenneyw.key > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] plugin parameter value configuration for non primitive types?
What syntax is supported for M2 Plugin parameters of non-primitive types? For example, java.util.Collection (and subclasses), java.util.Map (and subclasses), arrays, Properties and JavaBeans. /** * Items to be processed, defaults to the empty set. * * @parameter */ private Set items = Collections.EMPTY_SET; ??? Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] MNG-320 .svn files get copied in the generated WAR file
MNG-320 seems to still be a problem in 2.0-alpha-3.
http://jira.codehaus.org/browse/MNG-320
Looking at the WarMojo source on the trunk, it seems there is a TODO
comment indicating that includes and excludes should be applied while
copying resources.
if ( new File( warSourceDirectory ).exists() )
{
//TODO : Use includes and excludes
FileUtils.copyDirectoryStructure( sourceDirectory, webappDirectory );
}
It seems that this should read:
if ( new File( warSourceDirectory ).exists() )
{
FileUtils.copyDirectoryStructure( sourceDirectory, webappDirectory,
includes, excludes );
}
given that all the hard work was done in Plexus-utils to support a
version of FileUtils.copyDirectoryStructure that also takes includes
and excludes, but it is not being called from WarMojo.
Should MNG-320 be reopened, or is something else going on here?
Kind Regards,
John Fallows.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] maven checkstyle report customization
On 7/13/05, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: > John Fallows wrote: > > > > Is the maven-checkstyle-plugin aligned with the Maven2 beta-1 release, > > and therefore scheduled for mid July? > > I hope we can do it for the beta-1 release. I have filed JIRA issue MNG-587 to help track this improvement. http://jira.codehaus.org/browse/MNG-587 Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] MavenProject.add(Test)ResourceRoot
On 7/13/05, John Casey <[EMAIL PROTECTED]> wrote: > If you didn't find an issue in JIRA related to this, then it's probably > not on our radar for -beta-1. If you'd like, please file a JIRA for > this, and I'll work on it. :) Thanks, John. I filed JIRA issue MNG-583. http://jira.codehaus.org/browse/MNG-583 Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] MavenProject.add(Test)ResourceRoot
I seem to remember some brief discussion that it would be a good idea to add MavenProject.addResourceRoot(String) and MavenProject.addTestResourceRoot(String), so that plugins can be used to generate resources that can end up in the JAR without needing to generate them into the src/main/resources or src/test/resources directory. However, looking at MNG on Jira, there doesn't seem to be as issue for this - maybe I missed it. Is this functionality already scheduled for inclusion in beta-1? Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] maven checkstyle report customization
On 7/12/05, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: > In the next release, you'll can choose your own ruleset. That's the next release of the maven-checkstyle-plugin, right? Is the maven-checkstyle-plugin aligned with the Maven2 beta-1 release, and therefore scheduled for mid July? Kind Regards, John Fallows - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] migrating reports from m1
On 7/12/05, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: > > > John Fallows wrote: > > We have a custom report that generated a bunch of xdoc files for > > Maven1, and would like to know the easiest way to migrate that report > > to Maven2. > > > > Can we continue to generate xdoc files and then transform those files > > to .html as before? > > you can, but do you really need to generate xdoc files? During transition, we need to keep both Maven1 and Maven2 builds available in parallel. Therefore, I'd much prefer to focus on other issues in the short term, and update the custom report to use the Sink API directly after the Maven1 build is no longer needed. I looked at the SiteRenderer Java code, but found it a bit confusing. I'm hoping to save some time by asking the experts. :-) How can I use the SiteRenderer API to transform the xdoc files to .html? Is there a some existing part of the M2 codebase that illustrates the correct usage for an individual report like this, rather than the whole site? Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] migrating reports from m1
We have a custom report that generated a bunch of xdoc files for Maven1, and would like to know the easiest way to migrate that report to Maven2. Can we continue to generate xdoc files and then transform those files to .html as before? Or is it now required to use the Sink API directly during report generation rather than writing an intermediate xdoc file? Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] maven javadoc report and asserts
On 7/11/05, Vincent Siveton <[EMAIL PROTECTED]> wrote: > Hi, > > > You can specify a tag in the javadoc report configuration. > > > > See > > http://svn.apache.org/repos/asf/maven/components/trunk/maven- > > reports/maven-javadoc- > > plugin/src/main/java/org/apache/maven/plugin/javadoc/JavadocReport.java > > > > Not in the release but in SVN. > http://jira.codehaus.org/browse/MNG-561 > We're working on it. > > In the next release, you will be able to set all Javadoc options, for > instance in the pom.xml: > > > ... > > > > org.apache.maven.plugins > maven-javadoc-plugin > > 128m > 512 > ... > > > > ... > > ... > > Looks perfect, thanks. :-) Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] maven checkstyle report customization
Is it possible to customize the M2 maven-checkstyle-plugin to use a different ruleset? Given that a custom ruleset is likely to span multiple projects, and it doesn't make sense to duplicate the custom ruleset file in each project, what is the best way to configure such a plugin? Perhaps we could customize the report plugin via ClassLoader resource, so that a common dependency JAR (containing the custom ruleset definition) could be included on the classpath by a parent POM, while the same parent POM could be used to configure the maven-checkstyle-report (pointing to the location of the custom ruleset definition inside the JAR as a classpath resource). This assumes that the report plugin has a parameter such as "configResourcePath". Perhaps we need a src/plugin/resources directory so that such a classpath-based resource scheme could still work inside a single project. The "plugin/resources" would be on the classpath during plugin execution only, and would not contribute to either compilation or test classpaths. Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] maven javadoc report and asserts
When running the maven javadoc report against Java 1.4 code that contains asserts, the report fails, complaining that assert is a keyword in Java 1.4. This was the same error seen during compilation until the maven-compiler-plugin was parameterized to indicate source=1.4 syntax. However, there doesn't appear to be any way to specify the source syntax information to the maven javadoc report. Is it possible today, or should I file an enhancement request on JIRA? Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] NPE in maven-javadoc-plugin
I just noticed a NPE in the Maven2 Javadoc Report that occurs when ... is not present in the POM. Do I just file this bug against MNG/maven-reports on JIRA? Also, it does not seem to matter if the parent POM has the This was also unexpected. Is that a bug in maven2 core, or the maven2 javadoc report? Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] Filtered resources and the POM
I noticed that the latest code on the trunk adds support for filtered
resources, including the ability to refer to pom properties, in
addition to any filter properties defined in filter.properties.
For example:
src/main/resources/my-resource.txt
with contents
${version}
It seems that each property of the POM is exposed as an independent
top-level variable.
I was expecting the filtered resource file syntax to be...
${project.version}
...since that would be consistent with expressions used in the pom.xml
file, such as:
${project.basedir}/src/main/java
This would also seem to have the added benefit of reduced collision
space for top-level variables in filtered resource files.
Would it be reasonable to change the trunk to use the ${project.*}
syntax for filtered resources? Maybe it works this way already and I
just misread the code.
Let me know if I should file an issue or not on JIRA.
Kind Regards,
John Fallows.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[m2] deploy and release information
m2 deploy does not include RELEASE information by default. Presumably this works as designed to avoid accidental release publishing during nightly build deployment? m2 -DupdateReleaseInfo=true deploy breaks on first deploy with a FileNotFoundException. Is this a known issue? Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] plugin as module?
When using Maven1, we had four subprojects; api, impl, demo and tools, where tools created various utilities that were used during the build by the maven.xml files of the other subprojects. Now that we are putting in the effort to migrate to Maven2, we want to tidy up this tools project and turn it into a real maven-plugin. However, the tools project contains some project-specific build-time metadata files because they are needed by both api and impl projects at build time, but are never included in the api and impl JARs as they are not needed at runtime. Therefore, we plan to continue to version the tools module alongside the other modules, even though it is now implemented as a plugin. Releasing this tools plugin independently adds unwanted complexity to the development cycle. But, the reactor does not seem to notice that one of the modules is actually a plugin that is used by the other modules, so it does not ensure that the plugin module is executed before the other modules. Is there an way of achieving the desired execution order in maven2-alpha3? Would it be reasonable for the reactor to apply knowledge of maven-plugin modules and their use by other modules to calculate the desired execution order? Of course, if we figured out how to remove the project-specific metadata files from the tools plugin, such that they were still shareable across api and impl, then releasing it independently would make much more sense, because the rate of churn in the tools plugin implementation is far less than the shared metadata files. What is the recommended best practice for this sort of sharing problem? Should we splitting the maven-plugin and tools metadata into separate projects? Probably. Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] inherited plugin configuration is not applied to subprojects
When plugins are configured in a parent pom inside either or , with true, the child pom executes the plugins without the configuration applied. For example, even if the parent pom configures the maven-complier-plugin to use source 1.4, Java code in the child project still complains about the assert keyword, introduced in Java 1.4. When the plugin configuration is transferred to the child pom directly, then the correct configuration is used, as expected. Is this a known problem? Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] Transitive dependencies excluded from classpath for parent defined pluginManagement plugins
When the element is specified in a parent pom, the transitive dependencies needed by that plugin are not included on the classpath while the plugin is executing. This results in an unexpected ClassNotFoundException during plugin goal execution. However, when the element is transferred into the local pom, everything works as expected. Is this a known problem? Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] incorrect groupId, artifactId, version used during pom install
On 7/7/05, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: > Can you create a jira issue? Done, filed jira issue MNG-588. http://jira.codehaus.org/browse/MNG-558 Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] incorrect groupId, artifactId, version used during pom install
Maven 2.0-alpha-3, Java 1.5.0_02, WinXP SP2 When is present in pom.xml with "pom" packaging, then the last plugin artifact information (groupId, artifactId, version) is used during m2 install. 4.0.0 org.example sample alpha-1 pom org.apache.maven.plugins maven-compiler-plugin 1.0-alpha-1 [INFO] [INFO] Building org.apache.maven.plugins:maven-compiler-plugin:pom:1.0-alpha-1 [INFO] [INFO] maven-install-plugin: resolved to version 2.0-alpha-3 from local repository [INFO] [install:install] [INFO] Installing C:\Development\Projects\sample\pom.xml to C:\Documents and Settings\jfallows\.m2\repository\org\apache\maven\plugins\maven-compiler-plugin\1.0-alpha-1\maven-compiler-plugin-1.0-alpha-1.pom [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 second [INFO] Finished at: Thu Jul 07 11:14:11 PDT 2005 [INFO] Final Memory: 1M/3M [INFO] However, if is removed, giving: 4.0.0 org.example sample alpha-1 pom then everything works as expected, as shown below: [INFO] [INFO] Building org.example:sample:pom:alpha-1 [INFO] [INFO] maven-install-plugin: resolved to version 2.0-alpha-3 from local repository [INFO] [install:install] [INFO] Installing C:\Development\Projects\sample\pom.xml to C:\Documents and Settings\jfallows\.m2\repository\org\example\sample\alpha-1\sample-alpha-1.pom [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 second [INFO] Finished at: Thu Jul 07 11:15:54 PDT 2005 [INFO] Final Memory: 1M/3M [INFO] It doesn't appear to be limited to "pom" packaging, after changing to "jar" packaging, the m2 install behavior is still incorrectly influenced by the existence of in the pom. Is this a known issue? Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin never invoked (m2)
Kenny, On 7/6/05, Kenney Westerhof <[EMAIL PROTECTED]> wrote: > On Wed, 6 Jul 2005, Edwin Punzalan wrote: > > How did you invoke the plugin? > > Using m2 sablecc-plugin:sablecc ? > > You seem to have specified the plugin in the project pom that uses it; > if you want it to run automatically you have to add a > generate-sources tag near the executions element, and > specify the goal in sablecc. The generate-sources element is not required in the project pom using the plugin because this is already indicated the phase using the @phase taglet in the plugin goal Mojo source code. The ability to specify an explicit phase in the project pom is useful for cases where a goal might need to be executed in any phase, especially when the original goal Mojo is not already bound to a specific phase. The example in the documentation is a timestamp goal. Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Custom Plugins for alpha-3
> Thanks for the diagnosis. Can you put it in JIRA for us? Done, issue MNG-527. http://jira.codehaus.org/browse/MNG-527 Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
