Thanks Jason, Yes I understand what you are saying now and I agree it doesn't make sense to create a generic EAR/RAR or even WAR, but I think it is reasonable to be able to consume/includes those existing resources from within other artifacts (esp. when the artifact isn't in your control to create in the first place).
I might have been barking up the wrong tree here, I'm not really dealing with artifact that is an archived of templates but just a set of files and resources residing in other artifacts. BTW: I'm trying to convert existing applications from Ant to Maven with minimal changes to their structure that's why I'm looking for such flexibility. Anyway, in this case, I do have control over the generated WAR so I'll do what you suggested and it should resolve my problem! Regards, rOnn c. Jason van Zyl <[EMAIL PROTECTED]> 05/16/2007 06:53 PM Please respond to "Maven Developers List" <[email protected]> To "Maven Developers List" <[email protected]> cc Subject Re: Support for other types of artifacts in remote-resource-plugin On 16 May 07, at 1:21 AM 16 May 07, [EMAIL PROTECTED] wrote: > Hi Jason, > > Sounds like a good solution but seems like a perculiarity rather than > something that is intuitive. > Why would you package resources for general reuse in a WAR? The remote resources is simply an archive for templates. > I think it is perfectly valid and consistent with Maven's notion of > coordinate system to support war and any other artifacts that can be > fetched from repository. I don't think it would make sense to fetch an EAR to have resources inserted into deployed artifacts. > > I accept your work around but it is a limitation that I don't > understand. > Can you explain why it should not designed to support any other > artifacts? Because placing resources in a JAR is all that's required. The remote resources plugin inserts the resources into the POM and any archiver can take advantage of that. The JAR and Javadoc plugin being the first examples of this use. So we would probably have to make a small change to the WAR plugin, or we could just make the change in the maven-archiver and then it will just work with everything. > > > Regards, > rOnn c. > > > > > > > > Jason van Zyl <[EMAIL PROTECTED]> > 05/16/2007 05:31 PM > Please respond to > "Maven Developers List" <[email protected]> > > > To > "Maven Developers List" <[email protected]> > cc > > Subject > Re: Support for other types of artifacts in remote-resource-plugin > > > > > > > > On 16 May 07, at 12:01 AM 16 May 07, > [EMAIL PROTECTED] wrote: > >> Hello again, >> >> Maven remote resource plugin is a very handy utility but it doesn't >> support any other artifact type than jar. >> > > Not designed to, and not intended to. > >> My scenario is that I have a Maven project for a set of XML schemas >> which >> are packaged and distributed as war. > > Why? > >> I also have another dependent Maven >> project which I'd like to include those schema. Remote resource >> plugin >> seems like a good fit but it doesn't handle war resource. >> > > You can put the resources in a JAR, then your WAR can use this to > package the schemas in the WAR. And anything else that needs them can > just use the JAR. > >> Now, I haven't been reading this list long enough to know if it has >> been >> discussed and JIRA appears to be off line! Is it worth putting in a >> JIRA >> request when it is back up? >> >> Regards, >> rOnn c. >> >> ##################################################################### >> # >> DISCLAIMER: >> This email and any attachment may contain confidential information. >> If you are not the intended recipient you are not authorized to copy >> or disclose all or any part of it without the prior written consent >> of Toyota. >> >> Opinions expressed in this email and any attachments are those of the >> sender and not necessarily the opinions of Toyota. >> Please scan this email and any attachment(s) for viruses. >> Toyota does not accept any responsibility for problems caused by >> viruses, whether it is Toyota's fault or not. >> ##################################################################### >> # > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder and PMC Chair, Apache Maven > jason at sonatype dot com > ---------------------------------------------------------- > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > ###################################################################### > DISCLAIMER: > This email and any attachment may contain confidential information. > If you are not the intended recipient you are not authorized to copy > or disclose all or any part of it without the prior written consent > of Toyota. > > Opinions expressed in this email and any attachments are those of the > sender and not necessarily the opinions of Toyota. > Please scan this email and any attachment(s) for viruses. > Toyota does not accept any responsibility for problems caused by > viruses, whether it is Toyota's fault or not. > ###################################################################### Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com ---------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ###################################################################### DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ######################################################################
