[jira] Commented: (MNG-483) sort out artifact attachment
[ http://jira.codehaus.org/browse/MNG-483?page=comments#action_44522 ] Jason Grant commented on MNG-483: - Would you like me to check my enhancements in to svn? I notice that Daniel Krisher has patched the assembly plugin off the trunk, over in #MNG-735. He is probably unaware of the 'unpack' work (#MNG-723) and I think that Daniels directory patch will have implications for automatic addition of artifacts, as described here; i.e. we probably don't want to add a directory as a project artifact, right? sort out artifact attachment Key: MNG-483 URL: http://jira.codehaus.org/browse/MNG-483 Project: Maven 2 Type: Bug Reporter: Brett Porter Assignee: John Casey Priority: Blocker Fix For: 2.0-beta-1 Attachments: assembly-050814-1.zip currently, there is an attachArtifact call inside the plugin building the attachment. It imposes a m-a and m-p dependency, as well as an artifactFactory requirement to be able to construct the artifact to attach. sort out - if there is an easier way to achieve this - how to retain the default source binding, but also how to turn it off - how to make the source binding happen only on release (bear in mind people may not be using the release plugin... a profile was the original idea) - how to bind assembly similarly -- 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-483) sort out artifact attachment
[ http://jira.codehaus.org/browse/MNG-483?page=all ] Jason Grant updated MNG-483: Attachment: assembly-050814-1.zip I've made the change described in my comment above. Hope it finds its way into svn soon. Note that this attachment builds on the AssemblyMojo that was contributed in #MNG-723 (the new unpack goal). I'll make a note there too. I still intend to contribute an integration test for this in the near future. sort out artifact attachment Key: MNG-483 URL: http://jira.codehaus.org/browse/MNG-483 Project: Maven 2 Type: Bug Reporter: Brett Porter Assignee: John Casey Priority: Blocker Fix For: 2.0-beta-1 Attachments: assembly-050814-1.zip currently, there is an attachArtifact call inside the plugin building the attachment. It imposes a m-a and m-p dependency, as well as an artifactFactory requirement to be able to construct the artifact to attach. sort out - if there is an easier way to achieve this - how to retain the default source binding, but also how to turn it off - how to make the source binding happen only on release (bear in mind people may not be using the release plugin... a profile was the original idea) - how to bind assembly similarly -- 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-723) [patch] assembly:unpack
[ http://jira.codehaus.org/browse/MNG-723?page=comments#action_44425 ] Jason Grant commented on MNG-723: - The code attached to this issue has now been enhanced with extra functionality as described in #MNG-483. I've attached a new zip to that issue; it now obsoletes all of the attachments here. Actually, the only change is a new method in AssemblyMojo, but I've attached the same 3 classes there to make it easy to push into svn. [patch] assembly:unpack --- Key: MNG-723 URL: http://jira.codehaus.org/browse/MNG-723 Project: Maven 2 Type: New Feature Components: maven-plugins Versions: 2.0-beta-1 Reporter: Jason Grant Assignee: John Casey Priority: Minor Fix For: 2.0-beta-1 Attachments: AbstractAssemblyMojo.java, AssemblyMojo.diff, UnpackMojo.java, UnpackMojo.java, assembly-050811-1.zip I've coded an assembly:unpack goal. It will unpack any dependencies in the project whose filenames indicate type jar or zip. These are unpacked into the workDirectory. I went about it by pulling common infrastructure out of AssemblyMojo and placing it in a new abstract superclass AbstractAssemblyMojo. Another new class, called UnpackMojo now also resides in maven-assembly-plugin. I was going to code an integration test for this, however I will instead do some work on http://jira.codehaus.org/browse/MNG-483 first, so that I can use the latter as the first step in the test. I'll write some supporting notes over on that jira issue. Note that this is the first code that I've contributed to Maven - I'm happy to take direction should I be breaking conventions. You'll see me from time to time on #maven as jasong. -- 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-483) sort out artifact attachment
[ http://jira.codehaus.org/browse/MNG-483?page=comments#action_44464 ] Jason Grant commented on MNG-483: - Re (4): My patch does *not* cater for the cliOnly idea; it simply attaches all assemblies as project artifacts as described in #action_44289 above. I'm not game to start making changes to the core lifecycle algorithms until I graduate from novice status! sort out artifact attachment Key: MNG-483 URL: http://jira.codehaus.org/browse/MNG-483 Project: Maven 2 Type: Bug Reporter: Brett Porter Assignee: John Casey Priority: Blocker Fix For: 2.0-beta-1 Attachments: assembly-050814-1.zip currently, there is an attachArtifact call inside the plugin building the attachment. It imposes a m-a and m-p dependency, as well as an artifactFactory requirement to be able to construct the artifact to attach. sort out - if there is an easier way to achieve this - how to retain the default source binding, but also how to turn it off - how to make the source binding happen only on release (bear in mind people may not be using the release plugin... a profile was the original idea) - how to bind assembly similarly -- 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-723) [patch] assembly:unpack
[ http://jira.codehaus.org/browse/MNG-723?page=all ] Jason Grant updated MNG-723: Attachment: UnpackMojo.java The first attachment still had System.out debug statements. This one doesnt. [patch] assembly:unpack --- Key: MNG-723 URL: http://jira.codehaus.org/browse/MNG-723 Project: Maven 2 Type: New Feature Components: maven-plugins Versions: 2.0-beta-1 Reporter: Jason Grant Assignee: John Casey Priority: Minor Fix For: 2.0-beta-1 Attachments: AbstractAssemblyMojo.java, AssemblyMojo.diff, UnpackMojo.java, UnpackMojo.java I've coded an assembly:unpack goal. It will unpack any dependencies in the project whose filenames indicate type jar or zip. These are unpacked into the workDirectory. I went about it by pulling common infrastructure out of AssemblyMojo and placing it in a new abstract superclass AbstractAssemblyMojo. Another new class, called UnpackMojo now also resides in maven-assembly-plugin. I was going to code an integration test for this, however I will instead do some work on http://jira.codehaus.org/browse/MNG-483 first, so that I can use the latter as the first step in the test. I'll write some supporting notes over on that jira issue. Note that this is the first code that I've contributed to Maven - I'm happy to take direction should I be breaking conventions. You'll see me from time to time on #maven as jasong. -- 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-723) [patch] assembly:unpack
[ http://jira.codehaus.org/browse/MNG-723?page=comments#action_44305 ] Jason Grant commented on MNG-723: - I want to do a further update - AssemblyMojo has been wired so far to assume that dependencies are jars - if unpack is required, then it tries to unjar the dependency. I'd like to contribute an additional enhancement to allow it to handle zips too. Also, reading my code just now, I think more methods should be pulled down from the abstract class. I won't burden you with more diffs just now, but I might ask if it is OK to check this stuff in rather than polluting jira issues with superceded versions (I cannot delete my attachments above). [patch] assembly:unpack --- Key: MNG-723 URL: http://jira.codehaus.org/browse/MNG-723 Project: Maven 2 Type: New Feature Components: maven-plugins Versions: 2.0-beta-1 Reporter: Jason Grant Assignee: John Casey Priority: Minor Fix For: 2.0-beta-1 Attachments: AbstractAssemblyMojo.java, AssemblyMojo.diff, UnpackMojo.java, UnpackMojo.java I've coded an assembly:unpack goal. It will unpack any dependencies in the project whose filenames indicate type jar or zip. These are unpacked into the workDirectory. I went about it by pulling common infrastructure out of AssemblyMojo and placing it in a new abstract superclass AbstractAssemblyMojo. Another new class, called UnpackMojo now also resides in maven-assembly-plugin. I was going to code an integration test for this, however I will instead do some work on http://jira.codehaus.org/browse/MNG-483 first, so that I can use the latter as the first step in the test. I'll write some supporting notes over on that jira issue. Note that this is the first code that I've contributed to Maven - I'm happy to take direction should I be breaking conventions. You'll see me from time to time on #maven as jasong. -- 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-723) [patch] assembly:unpack
[ http://jira.codehaus.org/browse/MNG-723?page=all ] Jason Grant updated MNG-723: Attachment: assembly-050811-1.zip Oh what the heck - did the changes described above and am attaching the code, since doing otherwise will just hold things up. This time, I'm zipping the source and attaching it as assembly-050811-1.zip. The other attachments are now obsolete. [patch] assembly:unpack --- Key: MNG-723 URL: http://jira.codehaus.org/browse/MNG-723 Project: Maven 2 Type: New Feature Components: maven-plugins Versions: 2.0-beta-1 Reporter: Jason Grant Assignee: John Casey Priority: Minor Fix For: 2.0-beta-1 Attachments: AbstractAssemblyMojo.java, AssemblyMojo.diff, UnpackMojo.java, UnpackMojo.java, assembly-050811-1.zip I've coded an assembly:unpack goal. It will unpack any dependencies in the project whose filenames indicate type jar or zip. These are unpacked into the workDirectory. I went about it by pulling common infrastructure out of AssemblyMojo and placing it in a new abstract superclass AbstractAssemblyMojo. Another new class, called UnpackMojo now also resides in maven-assembly-plugin. I was going to code an integration test for this, however I will instead do some work on http://jira.codehaus.org/browse/MNG-483 first, so that I can use the latter as the first step in the test. I'll write some supporting notes over on that jira issue. Note that this is the first code that I've contributed to Maven - I'm happy to take direction should I be breaking conventions. You'll see me from time to time on #maven as jasong. -- 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-709) lifecycle can end up in an infinite loop
[ http://jira.codehaus.org/browse/MNG-709?page=comments#action_44343 ] Jason Grant commented on MNG-709: - Yes, you're right; depending on a separate dedicated project is the way to go. For some reason, I had it in my head that maven would sweep each phase across all projects before proceeding to the next phase, but's its clear that the build system cannot work like this when dependencies are catered for. My misunderstanding. Maybe I should have a go at updating the lifecycle or dependency pages to make this explicit for noobs like me. 8-) lifecycle can end up in an infinite loop Key: MNG-709 URL: http://jira.codehaus.org/browse/MNG-709 Project: Maven 2 Type: Bug Components: maven-plugins Versions: 2.0-beta-1 Environment: linux fedora core 3 Reporter: Jason Grant Assignee: John Casey Priority: Blocker Fix For: 2.0-beta-1 The pom source below used to work for alpha-3 subject to the comment about phase. I just built maven2 from the trunk head, and AssemblyMojo.execute() no longer gets called. If I call it from the command-line, it works fine. Interestingly, if I uncomment the phase clause, the m2 script goes into an infinite loop. build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId configuration descriptorsrc/assemble/zip-source.xml/descriptor /configuration executions execution !-- Bug in alpha: phase was not defined in the mojo javadoc so we need the element below -- !--phasepackage/phase-- goals goalassembly/goal /goals /execution /executions /plugin /plugins /build -- 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-723) [patch] assembly:unpack
[patch] assembly:unpack --- Key: MNG-723 URL: http://jira.codehaus.org/browse/MNG-723 Project: Maven 2 Type: New Feature Components: maven-plugins Versions: 2.0-beta-1 Reporter: Jason Grant Priority: Minor Fix For: 2.0-beta-1 Attachments: AbstractAssemblyMojo.java, AssemblyMojo.diff, UnpackMojo.java I've coded an assembly:unpack goal. It will unpack any dependencies in the project whose filenames indicate type jar or zip. These are unpacked into the workDirectory. I went about it by pulling common infrastructure out of AssemblyMojo and placing it in a new abstract superclass AbstractAssemblyMojo. Another new class, called UnpackMojo now also resides in maven-assembly-plugin. I was going to code an integration test for this, however I will instead do some work on http://jira.codehaus.org/browse/MNG-483 first, so that I can use the latter as the first step in the test. I'll write some supporting notes over on that jira issue. Note that this is the first code that I've contributed to Maven - I'm happy to take direction should I be breaking conventions. You'll see me from time to time on #maven as jasong. -- 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-483) sort out artifact attachment
[ http://jira.codehaus.org/browse/MNG-483?page=comments#action_44289 ] Jason Grant commented on MNG-483: - A bit of background with regard to Brett's mention of me looking at the attachment of artifacts, above. I've been using assembly to produce zip files, and asked questions on IRC about how best to get these across to the local repo so that other project could depend on them. If I understand correctly, Brett suggested an enhancement to AssemblyMojo that will attach all assemblies to the project as artifacts. Then, when the project is installed, these artifacts will wind up in the local repo. There was some talk of only doing this if the project packaging was of [new] type assembly, but I think we agreed to do it whatever the packaging is (see below). I'm happy to have a go at this - I'll build it on top of my contribution sent as a patch in http://jira.codehaus.org/browse/MNG-723 if other folk agree. So just to be clear, my contribution to this issue has quite limited scope. I'm too green to understand some of the content above. --- (15:58:29) jasong: [junk snipped] just thinking ahead though - I was going to modify AssemblyMojo to simply attach each archive to the project. Is that a reasonable start, or should I be considering what the project's packaging is? (16:05:05) brett: jasong: attach away! That's great, because then anyone generating an assembly (even for a jar) will be able to install/deploy it. Thanks! sort out artifact attachment Key: MNG-483 URL: http://jira.codehaus.org/browse/MNG-483 Project: Maven 2 Type: Bug Reporter: Brett Porter Assignee: John Casey Priority: Blocker Fix For: 2.0-beta-1 currently, there is an attachArtifact call inside the plugin building the attachment. It imposes a m-a and m-p dependency, as well as an artifactFactory requirement to be able to construct the artifact to attach. sort out - if there is an easier way to achieve this - how to retain the default source binding, but also how to turn it off - how to make the source binding happen only on release (bear in mind people may not be using the release plugin... a profile was the original idea) - how to bind assembly similarly -- 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-709) lifecycle can end up in an infinite loop
[ http://jira.codehaus.org/browse/MNG-709?page=comments#action_44293 ] Jason Grant commented on MNG-709: - Would that approach allow me to specify, say, phasegenerate-sources/phase if I wanted to create some zips for inclusion into tests, etc.? WRT your question about anyone else working on this - I'm not game to fiddle about with classes like DefaultLifecycleExecutor just yet, so I'll work on the assembly stuff, as described in #MNG-483 and #MNG-723. lifecycle can end up in an infinite loop Key: MNG-709 URL: http://jira.codehaus.org/browse/MNG-709 Project: Maven 2 Type: Bug Components: maven-plugins Versions: 2.0-beta-1 Environment: linux fedora core 3 Reporter: Jason Grant Assignee: John Casey Priority: Blocker Fix For: 2.0-beta-1 The pom source below used to work for alpha-3 subject to the comment about phase. I just built maven2 from the trunk head, and AssemblyMojo.execute() no longer gets called. If I call it from the command-line, it works fine. Interestingly, if I uncomment the phase clause, the m2 script goes into an infinite loop. build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId configuration descriptorsrc/assemble/zip-source.xml/descriptor /configuration executions execution !-- Bug in alpha: phase was not defined in the mojo javadoc so we need the element below -- !--phasepackage/phase-- goals goalassembly/goal /goals /execution /executions /plugin /plugins /build -- 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-709) AssemblyMojo.execute() no longer gets invoked from pom
AssemblyMojo.execute() no longer gets invoked from pom -- Key: MNG-709 URL: http://jira.codehaus.org/browse/MNG-709 Project: Maven 2 Type: Bug Components: maven-plugins Versions: 2.0-beta-1 Environment: linux fedora core 3 Reporter: Jason Grant The pom source below used to work for alpha-3 subject to the comment about phase. I just built maven2 from the trunk head, and AssemblyMojo.execute() no longer gets called. If I call it from the command-line, it works fine. Interestingly, if I uncomment the phase clause, the m2 script goes into an infinite loop. build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId configuration descriptorsrc/assemble/zip-source.xml/descriptor /configuration executions execution !-- Bug in alpha: phase was not defined in the mojo javadoc so we need the element below -- !--phasepackage/phase-- goals goalassembly/goal /goals /execution /executions /plugin /plugins /build -- 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]
