[jira] Created: (MNG-2093) clean plugin unit test
clean plugin unit test -- Key: MNG-2093 URL: http://jira.codehaus.org/browse/MNG-2093 Project: Maven 2 Type: Improvement Components: General Reporter: Jesse McConnell Priority: Minor Attachments: clean-plugin-normal-unit-test.patch, maven-clean-plugin-plexify.jar straight forward unit test for clean plugin also added the version that was refactored to use plexus and convert the CleanMojo to more of an adapter onto a more easily tested plugin, or at least elegantly tested plugin adding this jira issue to hold this stuff and I'll link it in the email thread on dev -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-720) JavaCC 4.0
JavaCC 4.0 -- Key: MAVENUPLOAD-720 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-720 Project: maven-upload-requests Type: Task Reporter: Jesse McConnell http://www.perendengue.com/stuff/javacc-4.0-bundle.jar https://javacc.dev.java.net javacc 4.0 release needed for updated javacc-maven-plugin to support java 5 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-752) site should behave like an attached artifact
[ http://jira.codehaus.org/browse/MNG-752?page=comments#action_53161 ] Jesse McConnell commented on MNG-752: - I'll take this one > site should behave like an attached artifact > > > Key: MNG-752 > URL: http://jira.codehaus.org/browse/MNG-752 > Project: Maven 2 > Type: Improvement > Components: maven-site-plugin > Reporter: Brett Porter > Priority: Minor > > > the site plugin should behave like an attached artifact. This will allow > deployment of a zip of the site to the repository, as well as tying > site:deploy to the general deploy cycle. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (SUREFIRE-19) default excludes prevents inner class test cases
default excludes prevents inner class test cases Key: SUREFIRE-19 URL: http://jira.codehaus.org/browse/SUREFIRE-19 Project: surefire Type: Bug Versions: 1.4 Reporter: Jesse McConnell Assigned to: Jason van Zyl Fix For: 1.5 Attachments: maven-surefire-plugin.patch, surefire.patch some people use inner classes for junit tests since they have access to private variables in the unit tests. for my particular case we have all unit tests called Foo$TEST in the DirectoryBattery there was a default excludes that was _always_ getting added to exclude inner classes...so the patch attached moves this default exclusion to the listing of default excluders in the maven-surefire-plugin and removed the forced exclusion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-19) default excludes prevents inner class test cases
[ http://jira.codehaus.org/browse/SUREFIRE-19?page=comments#action_51663 ] Jesse McConnell commented on SUREFIRE-19: - oh, and I had the assumption that the maven-surefire-plugin is the only thing using surefireif it isn't I can adjust accordingly > default excludes prevents inner class test cases > > > Key: SUREFIRE-19 > URL: http://jira.codehaus.org/browse/SUREFIRE-19 > Project: surefire > Type: Bug > Versions: 1.4 > Reporter: Jesse McConnell > Assignee: Jason van Zyl > Fix For: 1.5 > Attachments: maven-surefire-plugin.patch, surefire.patch > > > some people use inner classes for junit tests since they have access to > private variables in the unit tests. > for my particular case we have all unit tests called Foo$TEST > in the DirectoryBattery there was a default excludes that was _always_ > getting added to exclude inner classes...so the patch attached moves this > default exclusion to the listing of default excluders in the > maven-surefire-plugin and removed the forced exclusion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-472) multiple 's with no goals not considered when running a goal directly from the CLI
[ http://jira.codehaus.org/browse/MNG-472?page=comments#action_51424 ] Jesse McConnell commented on MNG-472: - brett - I haven't put it together enough to think of it as a bug or not... or to warrent its own ticket really. in essense, if a mojo has a @phase specificed in the class lvl javadoc, and that mojo is used in multiple executions and you specify the in the execution, multiple executions will not occur, even if the is set to the same as the @phase in the mojo itself...remove the from the execution and it multiple of them will execution. I'll play with this a bit and see about opening an issue or just leaving this little trace here...worst case if ought to be mentioned somewhere as a potential gotcha > multiple 's with no goals not considered when running a goal > directly from the CLI > -- > > Key: MNG-472 > URL: http://jira.codehaus.org/browse/MNG-472 > Project: Maven 2 > Type: Bug > Components: maven-core > Reporter: John Casey > Priority: Critical > > > assume you specify a plugin in the pom with multiple sections, > each containing configurations. > It should be possible to directly invoke a goal within this plugin, and have > that goal run once per execution, despite the fact that the goal is not > explicitly specified in the . > This is not the case now. > Workaround: specify the goal for each execution in which you want it to run. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-472) multiple 's with no goals not considered when running a goal directly from the CLI
[ http://jira.codehaus.org/browse/MNG-472?page=comments#action_50808 ] Jesse McConnell commented on MNG-472: - one note on this issue.. if you specify the in the execution it will not process multiple elements using the default lifecycle (ie, mvn install)...the plugin declares the phase and the plugins can't mention the phase, even if it is the same one since that causes only the first one to be executed.. > multiple 's with no goals not considered when running a goal > directly from the CLI > -- > > Key: MNG-472 > URL: http://jira.codehaus.org/browse/MNG-472 > Project: Maven 2 > Type: Bug > Components: maven-core > Reporter: John Casey > Priority: Critical > > > assume you specify a plugin in the pom with multiple sections, > each containing configurations. > It should be possible to directly invoke a goal within this plugin, and have > that goal run once per execution, despite the fact that the goal is not > explicitly specified in the . > This is not the case now. > Workaround: specify the goal for each execution in which you want it to run. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1539) test summary
[ http://jira.codehaus.org/browse/MNG-1539?page=all ] Jesse McConnell updated MNG-1539: - Attachment: ws.patch test attachment from jesse > test summary > > > Key: MNG-1539 > URL: http://jira.codehaus.org/browse/MNG-1539 > Project: Maven 2 > Type: Bug > Components: maven-eclipse-plugin > Reporter: Jason van Zyl > Assignee: Jason van Zyl > Priority: Blocker > Fix For: 2.1 > Attachments: ws.patch > > > test description -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1390) @requiresDependencyResolution in process-classes post compile
@requiresDependencyResolution in process-classes post compile
-
Key: MNG-1390
URL: http://jira.codehaus.org/browse/MNG-1390
Project: Maven 2
Type: Bug
Components: maven-project
Versions: 2.0
Reporter: Jesse McConnell
I was looking back into some plugins I had written a while back and ran across
an oddity.
it appears that when using a plugin in the process-classes phase, after the
compiler plugin has done its thing, the @requiresDependencyResolution javadoc
flag will toggle the presense of dependencies that are scoped to provided in
the dependencies section when calling project.getCompileClasspathElements();
(a difference of 80 vs 24 when not using the flag and then using it)
---
this are two snippits of code from the plugin
/**
* A plugin for generating * java file containing all the classes in a src tree.
*
* @goal generate
* @requiresDependencyResolution
* @description Functions Generator plugin
* @author jesse <[EMAIL PROTECTED]>
*/
List classpathFiles = project.getCompileClasspathElements();
URL[] urls = new URL[classpathFiles.size() + 1];
getLog().debug("" + classpathFiles.size());
for (int i = 0; i < classpathFiles.size(); ++i) {
getLog().debug((String)classpathFiles.get(i));
urls[i] = new File((String)classpathFiles.get(i)).toURL();
}
urls[classpathFiles.size()] = new File( buildDirectory + "/classes"
).toURL();
URLClassLoader ucl = new URLClassLoader(urls,
Thread.currentThread().getContextClassLoader());
being used with the following plugin declaration:
gallup.maven
services-provider-maven-plugin
1.0.1
com/g/util/ServiceProvider.java
process-classes
generate
analyzing the debug output when I run the plugin without the
@requiresDependencyResolution I get 80 dependencies and it builds out the
classloader correctly..
but if I add the @requiresDependencyResolution statement I go down to 24
dependencies being put into the classloader...and the discrepency corresponds
to the presense of the provided statement.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-743) example maven project architecture (jars, wars, ejbs, and an ear)
[ http://jira.codehaus.org/browse/MNG-743?page=comments#action_49121 ] Jesse McConnell commented on MNG-743: - btw, I wanted to have the src/main/java and src/test/java dirs show up but you need to have something in them for the archetype plugin to work..so perhaps we tweak the plugin to accept dirs in the archetype.xml file or just add in some empty source example files > example maven project architecture (jars, wars, ejbs, and an ear) > - > > Key: MNG-743 > URL: http://jira.codehaus.org/browse/MNG-743 > Project: Maven 2 > Type: Improvement > Components: maven-archetype-plugin > Reporter: Jesse McConnell > Assignee: Jason van Zyl > Priority: Minor > Fix For: 2.0.1 > Attachments: maven-archetype-j2ee.jar, sample-m2-project.jar > > > someone on the mailing lists asked me for a working sample layout for a > project containing muliple source directories, nesting subprojects, servlets > in war files, ejbs, and ultimately into a ear file. > this is a small sample project, no source but it builds out all the > artifacts. also includes an example of dependencyManagement of versions at > the root pom file. > post comments and I'll make the changes if you want. anyway, on irc I said I > would make it and post it in an issue for review so here it is. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-743) example maven project architecture (jars, wars, ejbs, and an ear)
[ http://jira.codehaus.org/browse/MNG-743?page=all ] Jesse McConnell updated MNG-743: Attachment: maven-archetype-j2ee.jar jar xvf maven-archetype-j2ee.jar in this directory: maven-components/maven-archetype/maven-archetypes installs and builds off of the installation by out of the box. I have axis and fop jars as sample dependencies in there showing how dependencyManagement works as well. > example maven project architecture (jars, wars, ejbs, and an ear) > - > > Key: MNG-743 > URL: http://jira.codehaus.org/browse/MNG-743 > Project: Maven 2 > Type: Improvement > Components: maven-archetype-plugin > Reporter: Jesse McConnell > Assignee: Jason van Zyl > Priority: Minor > Fix For: 2.0.1 > Attachments: maven-archetype-j2ee.jar, sample-m2-project.jar > > > someone on the mailing lists asked me for a working sample layout for a > project containing muliple source directories, nesting subprojects, servlets > in war files, ejbs, and ultimately into a ear file. > this is a small sample project, no source but it builds out all the > artifacts. also includes an example of dependencyManagement of versions at > the root pom file. > post comments and I'll make the changes if you want. anyway, on irc I said I > would make it and post it in an issue for review so here it is. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-967) maven.mdo, settings.mdo, and generated-sources
maven.mdo, settings.mdo, and generated-sources -- Key: MNG-967 URL: http://jira.codehaus.org/browse/MNG-967 Project: Maven 2 Type: Bug Components: maven-model Reporter: Jesse McConnell Priority: Trivial a nice trivial issue... maven-components/maven-settings/settings.mdo maven-components/maven-model/maven.mdo those ought to be in src/main/modello and they ought to be generating their source to target/generated-sources/modello they are currently generating to target/generated-sources -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-575) Add a way to configure permissions on deployed files
[ http://jira.codehaus.org/browse/MNG-575?page=all ] Jesse McConnell updated MNG-575: Attachment: mng-575.patch this patch works for things like m2 deploy settings.xml controls the permissions as in the following example snapshots jesse /home/jesse/.ssh/id_dsa 775 775 > Add a way to configure permissions on deployed files > > > Key: MNG-575 > URL: http://jira.codehaus.org/browse/MNG-575 > Project: Maven 2 > Type: Improvement > Components: maven-artifact > Versions: 2.0-alpha-3 > Reporter: Kenney Westerhof > Fix For: 2.0-beta-2 > Attachments: mng-575.patch > > > [actually maven-artifact-manager..?] > Since my umask = 077, m2 deploy stores files in the remote repository that > aren't accessible > by httpd. > I need to provide file permissions in the repository configuration in the pom > or in the settings.xml > server definitions (perhaps the repo's, but permissions should go with > authentication information I think). > Wagon already supports filemode and group settings on it's Repositories. > DefaultWagonManager doesn't provide a way > to fill those settings. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-849) plugins that add source roots ignored under certain circumstances
plugins that add source roots ignored under certain circumstances - Key: MNG-849 URL: http://jira.codehaus.org/browse/MNG-849 Project: Maven 2 Type: Bug Reporter: Jesse McConnell kenney and I talked about this on irc for a while...here is a rundown.. Use Case 1: when working on my file activator for profiles I use the idea of checking for a file that is missing and if it is missing then activate the profile, which contains a plugin that generates the source file I want to compile...originally I was pointing at the generated java file so for the initial execution the profile is activated and the compile source root is added to the mix of things to compile however, after that should the build have failed and that file not have been compiled it will not be compiled from that point forward since that the file the profile was checking for did exist, just not the compiled class file version of it. so I switched it over to activate if the classfile didn't exist. well at that point I was just running > m2 compiler:compile which ends up bypassing the profile activation and not adding the compile source rootand since the original source files require that generated class to compile against the build is broken until there is a clean:clean and that profile is activated again. Use Case 2: this cropped up right after the discussion on the profile activation...dozer was using >m2 javadoc:javadoc to generate javadocs for a mess of generated classes but they were not getting picked up...since that generated source root was not readily apparent to the javadoc plugin when it was executed directly outside of the context of the normal lifecycle where such things ought to be set in the normal course of events. Breakdown: the thought here is that when a plugin is executed outside of the normal lifecycle it doesn't have the full context of the lifecycle in terms of compile source roots now it could be that this isn't something that m2 should deal with, instead leaving the onus onto the plugin writers to provide configuration options to the plugins to support the users mentioning what source roots to use here and there...and at least in the example of the profile there are lots of different ways I could have done it...I chose that route to give profiles a bit of a workout. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-821) file existence profile activation patch
[ http://jira.codehaus.org/browse/MNG-821?page=all ] Jesse McConnell updated MNG-821: Attachment: file-profile-activation.patch disregard the file-existence patch, renamed to simply file profile activator so we can have contents or whatever other type of file based profile activation > file existence profile activation patch > --- > > Key: MNG-821 > URL: http://jira.codehaus.org/browse/MNG-821 > Project: Maven 2 > Type: New Feature > Components: maven-project, maven-model > Versions: 2.0-beta-1 > Reporter: Jesse McConnell > Fix For: 2.0-beta-1 > Attachments: file-existence-profile-activation.patch, > file-profile-activation.patch > > > > classnames > > > > target/generated-sources/classname-generator/com/stuff/util/GClassnameProvider.java > > > > also is a valid tag inside that as well. > The problem with this patch atm is that it ceases to work outside of the > context of the subproject it exists in.. > this is because in the FileExistenceProfileActivator we have no mechanism of > getting the absolute path for that file string. > I looked into BuildBase object that you can get from the Profile passed in > but it is empty (null) and the string doesn't resolve expressions either... > so...if I can get pointed in the right direction for adding that expression > resolution in there I'll put that in...talked to kenney about this a bit on > irc this morning as well and he seemed to think that was probably the way to > go. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-821) file existence profile activation patch
file existence profile activation patch --- Key: MNG-821 URL: http://jira.codehaus.org/browse/MNG-821 Project: Maven 2 Type: New Feature Components: maven-project, maven-model Versions: 2.0-beta-1 Reporter: Jesse McConnell Fix For: 2.0-beta-1 Attachments: file-existence-profile-activation.patch classnames target/generated-sources/classname-generator/com/stuff/util/GClassnameProvider.java also is a valid tag inside that as well. The problem with this patch atm is that it ceases to work outside of the context of the subproject it exists in.. this is because in the FileExistenceProfileActivator we have no mechanism of getting the absolute path for that file string. I looked into BuildBase object that you can get from the Profile passed in but it is empty (null) and the string doesn't resolve expressions either... so...if I can get pointed in the right direction for adding that expression resolution in there I'll put that in...talked to kenney about this a bit on irc this morning as well and he seemed to think that was probably the way to go. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONTINUUM-258) https:// doesn't seem to be a supported mechanism for referencing a pom
[ http://jira.codehaus.org/browse/CONTINUUM-258?page=all ] Jesse McConnell updated CONTINUUM-258: -- Attachment: MungedHttpsURL.java /home/jesse/osrc/plexus/plexus-components/plexus-formica/src/main/java/org/codehaus/plexus/formica/util/MungedHttpsURL.java object for dealing with munged URL's of the format https://u:[EMAIL PROTECTED]/bar > https:// doesn't seem to be a supported mechanism for referencing a pom > --- > > Key: CONTINUUM-258 > URL: http://jira.codehaus.org/browse/CONTINUUM-258 > Project: Continuum > Type: Bug > Components: continuum-web > Reporter: Jesse McConnell > Fix For: 1.0-alpha-4 > Attachments: MungedHttpsURL.java, secure-url-continuum-pre.patch, > secure-url-validation.patch, secure-url.patch > > > I have a svn repository setup with https:// certificate and AD LDAP password > authentication... > would be real nice to be able to point to a pom with > https://svn.company.com/svn/g-maven-plugins/trunk/pom.xml > and have it picked up. > right now it just grumbles about > Enter the URL to the Maven 2 POM[ The URL you provided doesn't exist ] > (in red even :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-258) https:// doesn't seem to be a supported mechanism for referencing a pom
[ http://jira.codehaus.org/browse/CONTINUUM-258?page=all ] Jesse McConnell updated CONTINUUM-258: -- Attachment: secure-url.patch /home/jesse/osrc/plexus/secure-url.patch this patchs in the usage of the file I'll be attaching next for resolution of funky secure urls > https:// doesn't seem to be a supported mechanism for referencing a pom > --- > > Key: CONTINUUM-258 > URL: http://jira.codehaus.org/browse/CONTINUUM-258 > Project: Continuum > Type: Bug > Components: continuum-web > Reporter: Jesse McConnell > Fix For: 1.0-alpha-4 > Attachments: secure-url-continuum-pre.patch, secure-url-validation.patch, > secure-url.patch > > > I have a svn repository setup with https:// certificate and AD LDAP password > authentication... > would be real nice to be able to point to a pom with > https://svn.company.com/svn/g-maven-plugins/trunk/pom.xml > and have it picked up. > right now it just grumbles about > Enter the URL to the Maven 2 POM[ The URL you provided doesn't exist ] > (in red even :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-258) https:// doesn't seem to be a supported mechanism for referencing a pom
[ http://jira.codehaus.org/browse/CONTINUUM-258?page=comments#action_45192 ] Jesse McConnell commented on CONTINUUM-258: --- I am in the process of creating a plexus-url-http component that wraps this functionality into MungedHttpsURL...leaving us the chance to do a better solution in DefaultHttpsURL down the road that prompts the user for cert acceptance and username/password..It is pretty close to done I think, will need to play around getting it plugged in bit should be a much cleaner patch coming once I get a few hours...hopefully this week > https:// doesn't seem to be a supported mechanism for referencing a pom > --- > > Key: CONTINUUM-258 > URL: http://jira.codehaus.org/browse/CONTINUUM-258 > Project: Continuum > Type: Bug > Components: continuum-web > Reporter: Jesse McConnell > Fix For: 1.0-alpha-4 > Attachments: secure-url-continuum-pre.patch, secure-url-validation.patch > > > I have a svn repository setup with https:// certificate and AD LDAP password > authentication... > would be real nice to be able to point to a pom with > https://svn.company.com/svn/g-maven-plugins/trunk/pom.xml > and have it picked up. > right now it just grumbles about > Enter the URL to the Maven 2 POM[ The URL you provided doesn't exist ] > (in red even :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-258) https:// doesn't seem to be a supported mechanism for referencing a pom
[ http://jira.codehaus.org/browse/CONTINUUM-258?page=all ] Jesse McConnell updated CONTINUUM-258: -- Attachment: secure-url-validation.patch this is an attempt at a patch for this issue on the plexis UrlSourceValidator I couldn't locate the mechanism that plexus would use for a cleaner way of obtaining url, username and password from the https:// url string so I added a couple of scrapeX methods to the bottom. it builds in plexus-formica just fine...I haven't tried it yet with my continuum build but I built it from the commandline testing version I was playing with to get the things right should it should be good to go. I looked into adding to the test class for it but I don't know the policy for locating a https:// box for general testing of it. just grab me on irc or email if you have questions or want me to revisit parts of it. it did dirty up a pretty simple class to get it worked around. > https:// doesn't seem to be a supported mechanism for referencing a pom > --- > > Key: CONTINUUM-258 > URL: http://jira.codehaus.org/browse/CONTINUUM-258 > Project: Continuum > Type: Bug > Components: continuum-web > Reporter: Jesse McConnell > Fix For: 1.0-beta-1 > Attachments: secure-url-validation.patch > > > I have a svn repository setup with https:// certificate and AD LDAP password > authentication... > would be real nice to be able to point to a pom with > https://svn.company.com/svn/g-maven-plugins/trunk/pom.xml > and have it picked up. > right now it just grumbles about > Enter the URL to the Maven 2 POM[ The URL you provided doesn't exist ] > (in red even :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-772) maven-eclipse-plugin NPE during writing setting file.
maven-eclipse-plugin NPE during writing setting file. - Key: MNG-772 URL: http://jira.codehaus.org/browse/MNG-772 Project: Maven 2 Type: Bug Reporter: Jesse McConnell Attachments: eclipse-plugin.patch the maven eclipse plugin was certain that if the maven-compiler-plugin was mentioned in the artifacts list that it would have source and target values defined. maven-compiler-plugin iso-8859-1 I don't and the eclipse plugin was blowing up with a NPE for this. I patched it to check for the child Xpp3Dom objects to actually exist before trying to get their values, which was the cause of the NPE. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-756) error updating poms that should exist in the project hierarchy
error updating poms that should exist in the project hierarchy -- Key: MNG-756 URL: http://jira.codehaus.org/browse/MNG-756 Project: Maven 2 Type: Bug Reporter: Jesse McConnell I noticed this the other day and brett mentioned he saw it from time to time as well. basically, I start a process in a subproject first thing in the morning and I start getting exceptions in trying to find POM files from repositories when it is not a pom that _will_ be anywhere other then in the existing project hierarchy. my setup that is triggering this is: root/pom root/cli/pom root/core/pom subpoms both have the root pom as the parent. I'll note that I did include the exception from not being able to find the maven-execute-plugin from anywhere since that isn't in either of the places and I generally ignore it, but it I figured I would add it to this in case it was related in anyway. halfway through you'll see the reference to the gallup:g:1.0 artifact which is the interesting one. How can a child _not_ know that the parent isn't going to be on a webserver but locally? I would think this kinda stuff will generate a substantial amount of bad traffic to the main repos. This is what my logs show: (-X didn't yield anything different) ideation]g-maven/g-cli>m2 -Dexecute.class="com.gallup.net.URLTester" -Dexecute.args="https://svn.gallup.com/svn/g-maven/trunk/pom.xml"; execute:resources [INFO] Retrieving plugins.xml (plugin mappings) for group: 'org.apache.maven.plugins' [INFO] Retrieving plugins.xml (plugin mappings) for group: 'org.apache.maven.plugins' [INFO] Refreshing plugin mapping metadata; looking for plugin with prefix: 'execute'. [INFO] Refreshing plugin-mapping metadata... [INFO] maven-execute-plugin: updating metadata due to status of 'deployed' Downloading: http://maven.gallup.com/plugins-repository/org/apache/maven/plugins/maven-execute-plugin/0.1/maven-execute-plugin-0.1.pom [WARNING] Unable to get resource from repository http://maven.gallup.com/plugins-repository Downloading: http://repo1.maven.org/maven2/plugins/org/apache/maven/plugins/maven-execute-plugin/0.1/maven-execute-plugin-0.1.pom [WARNING] Unable to get resource from repository http://repo1.maven.org/maven2/plugins [WARNING] Error updating POM - using existing version org.apache.maven.artifact.resolver.ArtifactResolutionException: Unable to download the artifact from any repository org.apache.maven.plugins:maven-execute-plugin:0.1:pom from the specified remote repositories: http://maven.gallup.com/plugins-repository, http://repo1.maven.org/maven2/plugins at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:132) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveAlways(DefaultArtifactResolver.java:69) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:348) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:303) at org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:252) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:198) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:986) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecycleExecutor.java:366) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:108) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:186) at org.apache.maven.cli.MavenCli.main(MavenCli.java:316) 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:585) 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.wagon.ResourceDoesNotExistException: Unable to download the artifact from any repository at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:233) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:115) ... 18 more [INFO] [INFO] Building g - command line tools [INFO]task-segment: [execu
[jira] Commented: (MNG-743) example maven project architecture (jars, wars, ejbs, and an ear)
[ http://jira.codehaus.org/browse/MNG-743?page=comments#action_44588 ] Jesse McConnell commented on MNG-743: - I think it is worth it alone to have a working example of dependencyManagement with that version injection, that is just too cool > example maven project architecture (jars, wars, ejbs, and an ear) > - > > Key: MNG-743 > URL: http://jira.codehaus.org/browse/MNG-743 > Project: Maven 2 > Type: Improvement > Reporter: Jesse McConnell > Assignee: John Casey > Priority: Trivial > Attachments: sample-m2-project.jar > > > someone on the mailing lists asked me for a working sample layout for a > project containing muliple source directories, nesting subprojects, servlets > in war files, ejbs, and ultimately into a ear file. > this is a small sample project, no source but it builds out all the > artifacts. also includes an example of dependencyManagement of versions at > the root pom file. > post comments and I'll make the changes if you want. anyway, on irc I said I > would make it and post it in an issue for review so here it is. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-743) example maven project architecture (jars, wars, ejbs, and an ear)
example maven project architecture (jars, wars, ejbs, and an ear) - Key: MNG-743 URL: http://jira.codehaus.org/browse/MNG-743 Project: Maven 2 Type: Improvement Reporter: Jesse McConnell Priority: Trivial Attachments: sample-m2-project.jar someone on the mailing lists asked me for a working sample layout for a project containing muliple source directories, nesting subprojects, servlets in war files, ejbs, and ultimately into a ear file. this is a small sample project, no source but it builds out all the artifacts. also includes an example of dependencyManagement of versions at the root pom file. post comments and I'll make the changes if you want. anyway, on irc I said I would make it and post it in an issue for review so here it is. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-741) new method: addResource( String directory, String includes, String excludes ) on MavenProject
new method: addResource( String directory, String includes, String excludes ) on MavenProject - Key: MNG-741 URL: http://jira.codehaus.org/browse/MNG-741 Project: Maven 2 Type: Improvement Reporter: Jesse McConnell Attachments: add_resource_maven_project.patch in the sablecc plugin I have a case of *.dat files getting created that need to get jared up with the actual project so I needed to add them as a resource to the project...since the plugin developers should have to have a minimal exposure to internals of maven I added this method to MavenProject as a convience method...also means I have one less dependency that the plugin itself needs to reference...whichever one model is a part of. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-675) Improve 'dependencies.dependency.version is missing' error message
[ http://jira.codehaus.org/browse/MNG-675?page=comments#action_44387 ]
Jesse McConnell commented on MNG-675:
-
looks nice now...here is sample output:
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Reason: Failed to validate POM for
'/home/jesse/src/g-maven/g-app/pom.xml'.
Reason(s):
[0] In Dependency {groupId=gallup.g, artifactId=g-ejbs, version=null,
type=jar}:
-> 'dependencies.dependency.version' is missing.
[INFO]
[INFO] Total time: < 1 second
[INFO] Finished at: Fri Aug 12 16:58:38 CDT 2005
[INFO] Final Memory: 1M/40M
[INFO]
> Improve 'dependencies.dependency.version is missing' error message
> --
>
> Key: MNG-675
> URL: http://jira.codehaus.org/browse/MNG-675
> Project: Maven 2
> Type: Improvement
> Reporter: Kenney Westerhof
> Assignee: John Casey
> Fix For: 2.0-beta-2
>
>
> When leaving out a from at least one dependency, the following
> error message appears. With a lot of dependencies, where all versions are
> managed
> in dependencyManagement in the parent pom, it's hard to tell which version is
> missing:
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Reason: Failed to validate POM for
> 'm:\qwesken_adm_1.0_dev_inc2\spf\products\adm\design\application\pom.xml'.
> Reason(s):
> [0] 'dependencies.dependency.version' is missing.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-727) missing dependency version error is vague
missing dependency version error is vague - Key: MNG-727 URL: http://jira.codehaus.org/browse/MNG-727 Project: Maven 2 Type: Improvement Reporter: Jesse McConnell [INFO] Reason: Failed to validate POM for '/home/jesse/src/g-maven/g-app/pom.xml'. Reason(s): [0] 'dependencies.dependency.version' is missing. [1] 'dependencies.dependency.version' is missing. [2] 'dependencies.dependency.version' is missing. [3] 'dependencies.dependency.version' is missing. [4] 'dependencies.dependency.version' is missing. [5] 'dependencies.dependency.version' is missing. [INFO] [INFO] Total time: < 1 second [INFO] Finished at: Fri Aug 12 15:38:30 CDT 2005 [INFO] Final Memory: 2M/41M [INFO] It would be really nice if this message told you the actual dependency that was missing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-725) pom dependencies not added to compile Classpath
[ http://jira.codehaus.org/browse/MNG-725?page=comments#action_44332 ] Jesse McConnell commented on MNG-725: - was trying to put together and it0050 test for this but realized I needed to have some pom resource on a webserver...not sure how to make it happen otherwise. > pom dependencies not added to compile Classpath > --- > > Key: MNG-725 > URL: http://jira.codehaus.org/browse/MNG-725 > Project: Maven 2 > Type: Bug > Reporter: Jesse McConnell > > > I am trying to use a meta dependency pom file to lump several dependencies > together into one unit. > on the webserver I have > >4.0.0 >meta-dependency >oracle >pom >1.0 >oracle meta dependencies list > > > oracle > oracle > 9201 > provided > > > oracle > oracle_nls_charset > 9201.12 > provided > > > > in the local pom I have: > > meta-dependency > oracle > 1.0 > pom > > Note: I had to specify pom here otherwise it defaulted to trying to > find a .jar file for it even though the pom was specified in > the remote pom...this seemed redundent and unnecessary. In this case the > DEBUG showed it as oracle:jar:1.0 even though the remote pom was clearly in > my local repo and was the one from the server, not a default one like kenney > had mentioned might be the case on irc. > [DEBUG] xml-apis:xml-apis:jar:2.0.2 (selected for provided) > [DEBUG] meta-dependency:oracle:pom:1.0 (selected for compile) > [DEBUG] jclass:pagelayout:jar:5.0 (selected for provided) > that is the debug output from the compiler, I would expect to see the > dependencies in the remote pom listed just below the pom declaration. > I initially tried this with the subproject pom, and that was the same deal. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-725) pom dependencies not added to compile Classpath
pom dependencies not added to compile Classpath --- Key: MNG-725 URL: http://jira.codehaus.org/browse/MNG-725 Project: Maven 2 Type: Bug Reporter: Jesse McConnell I am trying to use a meta dependency pom file to lump several dependencies together into one unit. on the webserver I have 4.0.0 meta-dependency oracle pom 1.0 oracle meta dependencies list oracle oracle 9201 provided oracle oracle_nls_charset 9201.12 provided in the local pom I have: meta-dependency oracle 1.0 pom Note: I had to specify pom here otherwise it defaulted to trying to find a .jar file for it even though the pom was specified in the remote pom...this seemed redundent and unnecessary. In this case the DEBUG showed it as oracle:jar:1.0 even though the remote pom was clearly in my local repo and was the one from the server, not a default one like kenney had mentioned might be the case on irc. [DEBUG] xml-apis:xml-apis:jar:2.0.2 (selected for provided) [DEBUG] meta-dependency:oracle:pom:1.0 (selected for compile) [DEBUG] jclass:pagelayout:jar:5.0 (selected for provided) that is the debug output from the compiler, I would expect to see the dependencies in the remote pom listed just below the pom declaration. I initially tried this with http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONTINUUM-258) https:// doesn't seem to be a supported mechanism for referencing a pom
[ http://jira.codehaus.org/browse/CONTINUUM-258?page=comments#action_44200 ] Jesse McConnell commented on CONTINUUM-258: --- shoot, no dice on that approach [ You must provide a valid url ] password has a * in it though so that might be borking it as well.. > https:// doesn't seem to be a supported mechanism for referencing a pom > --- > > Key: CONTINUUM-258 > URL: http://jira.codehaus.org/browse/CONTINUUM-258 > Project: Continuum > Type: Bug > Components: continuum-web > Reporter: Jesse McConnell > Fix For: 1.0-beta-1 > > > I have a svn repository setup with https:// certificate and AD LDAP password > authentication... > would be real nice to be able to point to a pom with > https://svn.company.com/svn/g-maven-plugins/trunk/pom.xml > and have it picked up. > right now it just grumbles about > Enter the URL to the Maven 2 POM[ The URL you provided doesn't exist ] > (in red even :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-697) allow plugins to declare dependence on the project-classpath(s)
[ http://jira.codehaus.org/browse/MNG-697?page=comments#action_44001 ]
Jesse McConnell commented on MNG-697:
-
three use cases:
1) inside of a project, to add the classes created during compile time to the
plugins classpath for processes, as in process-classes phase. If you need to
use reflection on the classes you have to create your own classloader to load
them up.
2) inside of a project, for maven-execute-plugin where you pass to the plugin a
classname and some parameters to call the .main() method on...you need to
either create your own classloader to be able to get the class and method in
order to invoke the tool. this is useful for allowing the to manage the
classpath dependencies for commandline tools which can be simply launched
through the system.
3) out of the project, I tried the mechanism to suck on the
compiled classes to just put the maven-execute-plugin in its own subproject,
but that doesn't work either since, like the jdbc driver reqs for
maven-jdbc-driver needed the driver code...the execute plugin can't be compiled
against the project classes.
as for reuse, I can't be the only person that uses the build system to process
classfiles with reflection to create more source/classes (though this could be
fixed with 1.5 annotations, or @javadoc spec...our source base isn't getting
fixed for this until we switch to 1.5 and take a couple of days to audit a hunk
of java). Or to execute class files...
> allow plugins to declare dependence on the project-classpath(s)
> ---
>
> Key: MNG-697
> URL: http://jira.codehaus.org/browse/MNG-697
> Project: Maven 2
> Type: New Feature
> Components: maven-plugin-descriptor, maven-core
> Versions: 2.0-alpha-3
> Reporter: John Casey
> Assignee: John Casey
> Priority: Critical
> Fix For: 2.0-beta-1
>
>
> Currently the only way to provide access to the classpath which consists of
> the project artifacts within some scope from a plugin is to manually create
> your own classloader inside the plugin using project.getCompileClasspath() or
> somesuch. In many plugins (thinking of integration-tests where the project is
> NOT an appserver module), it would be most useful to have the plugin
> container started with the appropriate project-classpath already added to the
> container. This might even be nice for testing plexus projects, and would
> allow the plugin to simply instantiate (somehow) and use compiled classes in
> order to run tests.
> Jesse even tells me this would be useful from a process-classes phase, in
> order to gather info about the classes that were compiled.
> I propose the following modifications:
> 1. Add addProjectClasspath="scope" (where scope = {compile,test...})
> configuration for the maven-plugin-plugin, alongside prefix or whatever else
> we use to define the plugin-level metadata.
> 2. For plugins declaring addProjectClasspath, add the appropriate project
> classpath to the plugin container before calling the mojo.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-697) allow plugins to declare dependence on the project-classpath(s)
[ http://jira.codehaus.org/browse/MNG-697?page=comments#action_43904 ]
Jesse McConnell commented on MNG-697:
-
well, the mechanism provides a runtime tweak to the classloader
for declaring a late addition
like for the maven-jdbc-plugin I put together, needs extensions to support the
declaring of the driver code so it is not there at compile time.
> allow plugins to declare dependence on the project-classpath(s)
> ---
>
> Key: MNG-697
> URL: http://jira.codehaus.org/browse/MNG-697
> Project: Maven 2
> Type: New Feature
> Components: maven-plugin-descriptor, maven-core
> Versions: 2.0-alpha-3
> Reporter: John Casey
> Assignee: John Casey
> Priority: Critical
> Fix For: 2.0-beta-1
>
>
> Currently the only way to provide access to the classpath which consists of
> the project artifacts within some scope from a plugin is to manually create
> your own classloader inside the plugin using project.getCompileClasspath() or
> somesuch. In many plugins (thinking of integration-tests where the project is
> NOT an appserver module), it would be most useful to have the plugin
> container started with the appropriate project-classpath already added to the
> container. This might even be nice for testing plexus projects, and would
> allow the plugin to simply instantiate (somehow) and use compiled classes in
> order to run tests.
> Jesse even tells me this would be useful from a process-classes phase, in
> order to gather info about the classes that were compiled.
> I propose the following modifications:
> 1. Add addProjectClasspath="scope" (where scope = {compile,test...})
> configuration for the maven-plugin-plugin, alongside prefix or whatever else
> we use to define the plugin-level metadata.
> 2. For plugins declaring addProjectClasspath, add the appropriate project
> classpath to the plugin container before calling the mojo.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-681) Plugin Utility Class
[ http://jira.codehaus.org/browse/MNG-681?page=all ] Jesse McConnell closed MNG-681: --- Resolution: Duplicate this is mostly being addressed in MNG-697 as for the compiling aspect, john mentioned maybe just forking off another compile phase pointing at the new source...I'll investigate that later this week I think, but I am good with closing this issue out. thanks guys > Plugin Utility Class > > > Key: MNG-681 > URL: http://jira.codehaus.org/browse/MNG-681 > Project: Maven 2 > Type: New Feature > Components: maven-plugin-api > Versions: 2.0-alpha-3 > Reporter: Jesse McConnell > Priority: Minor > Fix For: 2.0-beta-2 > > > Tryg mentioned that we might want to make a plugins utility class for some of > the issues I ran into implementing a mess of a plugin. > the plugin was pinned into the process-classes phase and generated a source > file which needed to be compiled > 1) I needed to have the classes that were compiled in the compile phase in my > classpath for the plugin. my way around this was to make a URLClassLoader > pointed at the compiled classes. The classes I was processing all used one > of two interfaces and it would have been nice to have those interfaces > available to cast the new instances of the classes and call a method > directly. reflection served the purpose though > 2) I needed to compile the freshly generated source file, so I ripped a mess > of code from the maven compiler plugin to achieve this > two examples of things that would be nice to have a cleaner method of > achieving the same results..if you think it is a good idea I can generalize > what I did into a couple of api's I think. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-697) allow plugins to declare dependence on the project-classpath(s)
[ http://jira.codehaus.org/browse/MNG-697?page=comments#action_43885 ]
Jesse McConnell commented on MNG-697:
-
this addresses the lionshare of MNG-681 as well, I'll close that one out.
> allow plugins to declare dependence on the project-classpath(s)
> ---
>
> Key: MNG-697
> URL: http://jira.codehaus.org/browse/MNG-697
> Project: Maven 2
> Type: New Feature
> Components: maven-plugin-descriptor, maven-core
> Versions: 2.0-alpha-3
> Reporter: John Casey
> Assignee: John Casey
> Priority: Critical
> Fix For: 2.0-beta-1
>
>
> Currently the only way to provide access to the classpath which consists of
> the project artifacts within some scope from a plugin is to manually create
> your own classloader inside the plugin using project.getCompileClasspath() or
> somesuch. In many plugins (thinking of integration-tests where the project is
> NOT an appserver module), it would be most useful to have the plugin
> container started with the appropriate project-classpath already added to the
> container. This might even be nice for testing plexus projects, and would
> allow the plugin to simply instantiate (somehow) and use compiled classes in
> order to run tests.
> Jesse even tells me this would be useful from a process-classes phase, in
> order to gather info about the classes that were compiled.
> I propose the following modifications:
> 1. Add addProjectClasspath="scope" (where scope = {compile,test...})
> configuration for the maven-plugin-plugin, alongside prefix or whatever else
> we use to define the plugin-level metadata.
> 2. For plugins declaring addProjectClasspath, add the appropriate project
> classpath to the plugin container before calling the mojo.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-681) Plugin Utility Class
[ http://jira.codehaus.org/browse/MNG-681?page=comments#action_43672 ] Jesse McConnell commented on MNG-681: - I am cool with whatever makes it simple to write plugins generate-sources is cake, after the compile, post compile plugins are just a bit more painful is all :P > Plugin Utility Class > > > Key: MNG-681 > URL: http://jira.codehaus.org/browse/MNG-681 > Project: Maven 2 > Type: New Feature > Components: maven-plugin-api > Versions: 2.0-alpha-3 > Reporter: Jesse McConnell > Priority: Minor > Fix For: 2.0-beta-2 > > > Tryg mentioned that we might want to make a plugins utility class for some of > the issues I ran into implementing a mess of a plugin. > the plugin was pinned into the process-classes phase and generated a source > file which needed to be compiled > 1) I needed to have the classes that were compiled in the compile phase in my > classpath for the plugin. my way around this was to make a URLClassLoader > pointed at the compiled classes. The classes I was processing all used one > of two interfaces and it would have been nice to have those interfaces > available to cast the new instances of the classes and call a method > directly. reflection served the purpose though > 2) I needed to compile the freshly generated source file, so I ripped a mess > of code from the maven compiler plugin to achieve this > two examples of things that would be nice to have a cleaner method of > achieving the same results..if you think it is a good idea I can generalize > what I did into a couple of api's I think. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-681) Plugin Utility Class
[ http://jira.codehaus.org/browse/MNG-681?page=comments#action_43670 ] Jesse McConnell commented on MNG-681: - nope, this was an internal plugin...it was just such a pain that at least the ability to load the classes that were compiled into the plugin's classloader and post compile compiling abilities seemed warrented. Nothing secret in it so I can attach it to this issue on monday if you like...warning it is not a pretty sight in its current form :P > Plugin Utility Class > > > Key: MNG-681 > URL: http://jira.codehaus.org/browse/MNG-681 > Project: Maven 2 > Type: New Feature > Components: maven-plugin-api > Versions: 2.0-alpha-3 > Reporter: Jesse McConnell > Priority: Minor > Fix For: 2.0-beta-2 > > > Tryg mentioned that we might want to make a plugins utility class for some of > the issues I ran into implementing a mess of a plugin. > the plugin was pinned into the process-classes phase and generated a source > file which needed to be compiled > 1) I needed to have the classes that were compiled in the compile phase in my > classpath for the plugin. my way around this was to make a URLClassLoader > pointed at the compiled classes. The classes I was processing all used one > of two interfaces and it would have been nice to have those interfaces > available to cast the new instances of the classes and call a method > directly. reflection served the purpose though > 2) I needed to compile the freshly generated source file, so I ripped a mess > of code from the maven compiler plugin to achieve this > two examples of things that would be nice to have a cleaner method of > achieving the same results..if you think it is a good idea I can generalize > what I did into a couple of api's I think. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-681) Plugin Utility Class
Plugin Utility Class Key: MNG-681 URL: http://jira.codehaus.org/browse/MNG-681 Project: Maven 2 Type: New Feature Components: maven-plugin-api Versions: 2.0-alpha-3 Reporter: Jesse McConnell Priority: Minor Tryg mentioned that we might want to make a plugins utility class for some of the issues I ran into implementing a mess of a plugin. the plugin was pinned into the process-classes phase and generated a source file which needed to be compiled 1) I needed to have the classes that were compiled in the compile phase in my classpath for the plugin. my way around this was to make a URLClassLoader pointed at the compiled classes. The classes I was processing all used one of two interfaces and it would have been nice to have those interfaces available to cast the new instances of the classes and call a method directly. reflection served the purpose though 2) I needed to compile the freshly generated source file, so I ripped a mess of code from the maven compiler plugin to achieve this two examples of things that would be nice to have a cleaner method of achieving the same results..if you think it is a good idea I can generalize what I did into a couple of api's I think. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-603) sablecc plugin
[ http://jira.codehaus.org/browse/MNG-603?page=all ] Jesse McConnell updated MNG-603: Attachment: maven-sablecc-plugin.v3.tar bleh, missed the removal of the previously required tag ought to be gtg now > sablecc plugin > -- > > Key: MNG-603 > URL: http://jira.codehaus.org/browse/MNG-603 > Project: Maven 2 > Type: Improvement > Components: maven-plugins > Reporter: Jesse McConnell > Fix For: 2.0-beta-1 > Attachments: maven-sablecc-plugin.tar, maven-sablecc-plugin.v2.tar, > maven-sablecc-plugin.v3.tar > > > added a sablecc plugin which can be used like this: > > maven-sablecc-plugin > 1.0-SNAPSHOT > >expressions.grammar, aicc.grammar > > > > generate-sources > > generate > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-603) sablecc plugin
[ http://jira.codehaus.org/browse/MNG-603?page=all ] Jesse McConnell updated MNG-603: Attachment: maven-sablecc-plugin.v2.tar this is using a modifed computeStaleGrammars() from the AbstractCompilerMojo now all you need to do is put *.grammar files into the (src/main/sablecc by default) and it will pick them up and process them, and not reprocess them unless it has changed. > sablecc plugin > -- > > Key: MNG-603 > URL: http://jira.codehaus.org/browse/MNG-603 > Project: Maven 2 > Type: Improvement > Components: maven-plugins > Reporter: Jesse McConnell > Fix For: 2.0-beta-1 > Attachments: maven-sablecc-plugin.tar, maven-sablecc-plugin.v2.tar > > > added a sablecc plugin which can be used like this: > > maven-sablecc-plugin > 1.0-SNAPSHOT > >expressions.grammar, aicc.grammar > > > > generate-sources > > generate > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-603) sablecc plugin
[ http://jira.codehaus.org/browse/MNG-603?page=comments#action_43015 ] Jesse McConnell commented on MNG-603: - oh, namely - support for not running sablecc everytime based on a stored timestamp from the originating grammer - support for a default mechanism that grabs all the .grammer files in the sourceDirectory and crunches them > sablecc plugin > -- > > Key: MNG-603 > URL: http://jira.codehaus.org/browse/MNG-603 > Project: Maven 2 > Type: Improvement > Components: maven-plugins > Reporter: Jesse McConnell > Fix For: 2.0-beta-1 > Attachments: maven-sablecc-plugin.tar > > > added a sablecc plugin which can be used like this: > > maven-sablecc-plugin > 1.0-SNAPSHOT > >expressions.grammar, aicc.grammar > > > > generate-sources > > generate > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-603) sablecc plugin
[ http://jira.codehaus.org/browse/MNG-603?page=comments#action_43014 ] Jesse McConnell commented on MNG-603: - I thought of some things to add to this, I'll try and get them in tomorrow and attach another tar or diff > sablecc plugin > -- > > Key: MNG-603 > URL: http://jira.codehaus.org/browse/MNG-603 > Project: Maven 2 > Type: Improvement > Components: maven-plugins > Reporter: Jesse McConnell > Fix For: 2.0-beta-1 > Attachments: maven-sablecc-plugin.tar > > > added a sablecc plugin which can be used like this: > > maven-sablecc-plugin > 1.0-SNAPSHOT > >expressions.grammar, aicc.grammar > > > > generate-sources > > generate > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-603) sablecc plugin
sablecc plugin -- Key: MNG-603 URL: http://jira.codehaus.org/browse/MNG-603 Project: Maven 2 Type: Improvement Components: maven-plugins Reporter: Jesse McConnell Attachments: maven-sablecc-plugin.tar added a sablecc plugin which can be used like this: maven-sablecc-plugin 1.0-SNAPSHOT expressions.grammar, aicc.grammar generate-sources generate -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-602) tweak MojoExecutionException to use Throwable as opposed to Exception
tweak MojoExecutionException to use Throwable as opposed to Exception - Key: MNG-602 URL: http://jira.codehaus.org/browse/MNG-602 Project: Maven 2 Type: Bug Reporter: Jesse McConnell Attachments: throwable.patch some unfortunate things like sablecc toss Throwable so we need a clean way to catching those and returning the MojoExecutionException in plugins -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-595) patch for adding -encoding X to the javac
patch for adding -encoding X to the javac - Key: MNG-595 URL: http://jira.codehaus.org/browse/MNG-595 Project: Maven 2 Type: Improvement Components: maven-plugins Reporter: Jesse McConnell Attachments: patch for maven-compiler-plugin supports this now: maven-compiler-plugin utf8 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
