Re: Maven plugin trademarks [Re: Downloading a file for shipping in an artifact]
Hi, For the record, the two pages above were patched. TL;DR *don't name your maven plugin maven-foo-plugin but foo-maven-plugin. Legally compulsory, not just a recommendation.* Cheers Le 12 juin 2013 14:13, "Baptiste MATHUS" a écrit : > > 2013/6/12 Stephen Connolly > >> On 12 June 2013 11:04, Stephen Colebourne wrote: >> >> > I made this mistake too. Could I make some suggestions? >> > >> > Add the banned naming to the top of plugin guides, such as: >> > >> http://maven.apache.org/guides/plugin/guide-java-plugin-development.html >> > >> > >> +1, anyone want to take a stab at providing a patch? >> >> >> > Change this page to only have the single prefix-maven-plugin example: >> > >> > >> http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html >> > I scan read and thought they were just two options. >> > >> > >> +1, anyone want to take a stab at providing a patch? >> > > I'll propose that patch this week, maybe tonight if no one else does it > before. > > -- Baptiste >
Re: Maven plugin trademarks [Re: Downloading a file for shipping in an artifact]
For the record, see https://jira.codehaus.org/browse/MNGSITE-180 Cross-posting to dev list so that PMC can discuss that issue at what should be the exact wording. Cheers 2013/6/12 Stephen Connolly > On 12 June 2013 11:04, Stephen Colebourne wrote: > > > I made this mistake too. Could I make some suggestions? > > > > Add the banned naming to the top of plugin guides, such as: > > http://maven.apache.org/guides/plugin/guide-java-plugin-development.html > > > > > +1, anyone want to take a stab at providing a patch? > > > > Change this page to only have the single prefix-maven-plugin example: > > > > > http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html > > I scan read and thought they were just two options. > > > > > +1, anyone want to take a stab at providing a patch? > > > > > Use big/bold/red font. > > "You must not name your plugin maven-foo-plugin as these are reserved > > by trademark for the Apache Maven project itself" > > > > Correction, in order to protect the Maven trademark, we need to get people > to acknowledge the mark whenever they use it. We have consulted with legal > and the agreement that was reached was that if we defined a pattern of > allowed usage, we need not be "all over" people who are complying with the > allowed pattern of usage. > > The allowed pattern of usage is that where the use of the mark is referring > to the plugin being for use with Maven, hence "___ Plugin for Maven" is > fine but "Maven ___ Plugin" is not. Obviously "___'s ___ plugin for Maven" > is even better, e.g. "Mojo's Cassandra plugin for Maven" (which has the > bigger fun of using two Apache marks... that plugin is the one that got me > sucked into this rats nets) > > As to the artifactId convention. That was a long standing, if undocumented > convention. The Maven Plugin Plugin currently emits a stern warning if you > use the maven-___-plugin pattern > > http://maven.apache.org/plugin-tools/maven-plugin-plugin/xref/org/apache/maven/plugin/plugin/AbstractGeneratorMojo.html#177 > > Perhaps we are at the point where we should start breaking builds rather > than just giving a stern warning... certainly the warning has been there > for long enough > > > > > > Sonatype's Maven Central upload should have a rule to prevent any new > > jar being pushed with the maven-*-plugin name (unless its an update to > > an existing version or within org.apache.maven group). > > > > Somebody from Sonatype would need to comment on that... or maybe the PMC > will request Sonatype to provide such a facility to assist in our > protection of our mark... needs thinking time > > > > > > I'd note that now I have a plugin in Maven Central with the wrong name > > I can't remove it, so getting this wrong is a right pain in the *** > > and messes lots of things up. > > > > What matters is that you are complying going forward and that, when we > become aware of infringing use, we get you to ack the trademark (sending > C&Ds if necessary). > > So step 1 is to ack the mark. As long as you ack the mark we are 90% happy. > > IANAL, but as I understand it, if you use the term in writing a plugin for > Maven *and* you use the approved naming convention (the one that makes it > clear that the plugin is *for* Maven) then you might not need to ack the > mark in the strictest sense, but it is safer to ack it anyway in other > words the approved naming is just to help people comply > > > > Stephen > > > > > > On 12 June 2013 07:59, James Green wrote: > > > Many thanks for filing this - I do assure you that I was not under the > > > impression the GitHub plugin was official or even endorsed but I agree > > that > > > the trademark requires work to enforce. And I just love their response > in > > > your ticket - made me laugh and cringe..! > > > > > > James > > > > > > > > > On 11 June 2013 22:44, Stephen Connolly < > stephen.alan.conno...@gmail.com > > >wrote: > > > > > >> On 11 June 2013 22:27, Stephen Connolly < > > stephen.alan.conno...@gmail.com > > >> >wrote: > > >> > > >> > On 11 June 2013 22:03, James Green > wrote: > > >> > > > >> >> If you search for maven-download-plugin you should reach a project > on > > >> >> GitHub. > > >> > > > >> > > > >> > Please advise them to rename their plugin as the current name is in > > >> > violation of the permitted usages of the ASF's trademark Maven: > > >> > > > >> > > > http://markmail.org/search/?q=list%3Aorg.apache.maven.dev#query:list%3Aorg.apache.maven.dev+page:1+mid:cmqxvj6ddshmnzwr+state:results > > >> > > > >> > And further the name confuses users as to who is responsible for the > > >> > plugin. > > >> > > > >> > > >> Filed: > > >> > > >> > > https://github.com/maven-download-plugin/maven-download-plugin/issues/14 > > >> > > >> I so hate having to do this... the "joys" of having to defend a > > trademark! > > >> > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >
Re: Downloading a file for shipping in an artifact
Would an installer help resolve this? Open source IzPack uses a maven plug-in to create an installation file that could build the required structure on the user side from the artifacts that you have. Ron On 11/06/2013 4:31 PM, James Green wrote: Nexus is used to host the .exe file. As the exe originates from a separate Maven project, and it needs to live somewhere, I folded the exe generation into an ant task as part of that maven project. Now I have versioned hosting of the exe. But our customers are trapped behind a strict firewall. We will by arrangement be shipping our .war file to them for hosting. The .exe is required for internal distribution by our customers and the software it installs provides custom access to the services offered by that web application. It therefore makes sense to ship the exe within the war. Now back to Nexus. When I search for the artifact that is the .exe and copy the download link, it is of a redirection URL. The wagon plugin, for some reason, wants a directory to look in more similar to an FTP service I guess. So I'm rather stuck and seeking suggestions. Nexus doesn't appear to be compatible with the wagon method, while the download plugin appears to mutate the URL on Linux yet works on Windows. I find both circumstances rather hard to believe yet my battle today leaves me empty handed and frustrated. James On 11 June 2013 19:43, Wayne Fay wrote: We have a maven project that results in a web archive. We want to ship a file (a .exe) within this for simple download by customers. ... So I am left wondering how I can ask that a web archive can be built that ships with a file downloaded from our Nexus installation? This doesn't sound like it should be difficult but I'm still left frustrated. You're asking 2 different questions from my POV. In the first, you want to make a WAR and include a special EXE file inside the WAR. Then I imagine you would deploy the WAR somewhere and the EXE would be downloadable. In the second, you start talking about Nexus. If you just want people to be able to download a file from Nexus, I'd use deploy:deploy-file or similar to deploy the EXE by itself to Nexus. What are you really trying to do? Why are you bringing up Nexus in the first place? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven plugin trademarks [Re: Downloading a file for shipping in an artifact]
2013/6/12 Stephen Connolly > On 12 June 2013 11:04, Stephen Colebourne wrote: > > > I made this mistake too. Could I make some suggestions? > > > > Add the banned naming to the top of plugin guides, such as: > > http://maven.apache.org/guides/plugin/guide-java-plugin-development.html > > > > > +1, anyone want to take a stab at providing a patch? > > > > Change this page to only have the single prefix-maven-plugin example: > > > > > http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html > > I scan read and thought they were just two options. > > > > > +1, anyone want to take a stab at providing a patch? > I'll propose that patch this week, maybe tonight if no one else does it before. -- Baptiste
Re: Maven plugin trademarks [Re: Downloading a file for shipping in an artifact]
On 12 June 2013 11:04, Stephen Colebourne wrote: > I made this mistake too. Could I make some suggestions? > > Add the banned naming to the top of plugin guides, such as: > http://maven.apache.org/guides/plugin/guide-java-plugin-development.html > > +1, anyone want to take a stab at providing a patch? > Change this page to only have the single prefix-maven-plugin example: > > http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html > I scan read and thought they were just two options. > > +1, anyone want to take a stab at providing a patch? > Use big/bold/red font. > "You must not name your plugin maven-foo-plugin as these are reserved > by trademark for the Apache Maven project itself" > Correction, in order to protect the Maven trademark, we need to get people to acknowledge the mark whenever they use it. We have consulted with legal and the agreement that was reached was that if we defined a pattern of allowed usage, we need not be "all over" people who are complying with the allowed pattern of usage. The allowed pattern of usage is that where the use of the mark is referring to the plugin being for use with Maven, hence "___ Plugin for Maven" is fine but "Maven ___ Plugin" is not. Obviously "___'s ___ plugin for Maven" is even better, e.g. "Mojo's Cassandra plugin for Maven" (which has the bigger fun of using two Apache marks... that plugin is the one that got me sucked into this rats nets) As to the artifactId convention. That was a long standing, if undocumented convention. The Maven Plugin Plugin currently emits a stern warning if you use the maven-___-plugin pattern http://maven.apache.org/plugin-tools/maven-plugin-plugin/xref/org/apache/maven/plugin/plugin/AbstractGeneratorMojo.html#177 Perhaps we are at the point where we should start breaking builds rather than just giving a stern warning... certainly the warning has been there for long enough > > Sonatype's Maven Central upload should have a rule to prevent any new > jar being pushed with the maven-*-plugin name (unless its an update to > an existing version or within org.apache.maven group). > Somebody from Sonatype would need to comment on that... or maybe the PMC will request Sonatype to provide such a facility to assist in our protection of our mark... needs thinking time > > I'd note that now I have a plugin in Maven Central with the wrong name > I can't remove it, so getting this wrong is a right pain in the *** > and messes lots of things up. > What matters is that you are complying going forward and that, when we become aware of infringing use, we get you to ack the trademark (sending C&Ds if necessary). So step 1 is to ack the mark. As long as you ack the mark we are 90% happy. IANAL, but as I understand it, if you use the term in writing a plugin for Maven *and* you use the approved naming convention (the one that makes it clear that the plugin is *for* Maven) then you might not need to ack the mark in the strictest sense, but it is safer to ack it anyway in other words the approved naming is just to help people comply > Stephen > > > On 12 June 2013 07:59, James Green wrote: > > Many thanks for filing this - I do assure you that I was not under the > > impression the GitHub plugin was official or even endorsed but I agree > that > > the trademark requires work to enforce. And I just love their response in > > your ticket - made me laugh and cringe..! > > > > James > > > > > > On 11 June 2013 22:44, Stephen Connolly >wrote: > > > >> On 11 June 2013 22:27, Stephen Connolly < > stephen.alan.conno...@gmail.com > >> >wrote: > >> > >> > On 11 June 2013 22:03, James Green wrote: > >> > > >> >> If you search for maven-download-plugin you should reach a project on > >> >> GitHub. > >> > > >> > > >> > Please advise them to rename their plugin as the current name is in > >> > violation of the permitted usages of the ASF's trademark Maven: > >> > > >> > http://markmail.org/search/?q=list%3Aorg.apache.maven.dev#query:list%3Aorg.apache.maven.dev+page:1+mid:cmqxvj6ddshmnzwr+state:results > >> > > >> > And further the name confuses users as to who is responsible for the > >> > plugin. > >> > > >> > >> Filed: > >> > >> > https://github.com/maven-download-plugin/maven-download-plugin/issues/14 > >> > >> I so hate having to do this... the "joys" of having to defend a > trademark! > >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Downloading a file for shipping in an artifact
you want to bind the dependency:copy-dependencies execution to the `generate-resources` phase or at the latest the `prepare-package` phase... though you may run into issues if you are using the common reactor for generating the .exe and the .war (at least in the case where you use lifecycle phases that span the reactor and are before the phase where the .exe gets attached to the reactor On 12 June 2013 10:08, James Green wrote: > Stephen/Wayne, > > I've got the maven-dependency-plugin to download and copy our .exe into > src/main/webapp just fine. However, with the package lifecycle, it fails to > make it into the web archive. If I switch it to the validate lifecycle, it > works. > > I'm supposing the invocation is happening after the war plugin has > executed, or that the war plugin does not include the .exe (even though the > documentation states everything is included)? > > On the right track at least! > > Thanks, > > James > > > On 11 June 2013 22:27, Stephen Connolly >wrote: > > > On 11 June 2013 22:03, James Green wrote: > > > > > See responses inline. > > > > > > > > > On 11 June 2013 21:47, Wayne Fay wrote: > > > > > > > > Nexus is used to host the .exe file. As the exe originates from a > > > > separate > > > > > Maven project, and it needs to live somewhere, I folded the exe > > > > generation > > > > > into an ant task as part of that maven project. Now I have > versioned > > > > > hosting of the exe. > > > > > > > > I'm still confused about why you are having this problem at all. I > > > > think you are inventing solutions to a problem that already has a > > > > solution in Maven. > > > > > > > > > > That's why I'm here in the hope there is a more accepted way to follow > :) > > > > > > > > > > > > > > I expect you are using "deploy:deploy-file" to push this EXE artifact > > > > to Nexus -- if not, how are you doing this? Then you should be able > to > > > > simply add a standard dependency in the WAR pom file against that EXE > > > > and it should be pulled down and included along with other > > > > dependencies when the WAR is constructed. (Probably you should be > > > > using a classifier like "windows" and a type like "exe" when you > > > > deploy this file, and then specify those in the WAR pom dependency as > > > > well.) > > > > > > > > > > I'm not at my desk at the moment and I don't recall how the additional > > file > > > (the .exe) gets included in the deploy phase. I'll try to remember to > > > report back in the morning more specifically. > > > > > > In regards to adding the dependency, this seems logical. But won't the > > file > > > be shipped in a part of the archive not normally accessible to web > > clients? > > > Specifically if it ends up in WEB-INF/lib - doesn't feel like a natural > > > place to serve downloadable content from. > > > > > > > No, unless it is a "known" file type it will not be included in the .war > > *by default* > > > > You will need to use dependency:copy-dependencies to copy the .exe into > the > > location you want within your .war file > > > > > > > > > > > > > > > So I'm rather stuck and seeking suggestions. Nexus doesn't appear > to > > be > > > > > compatible with the wagon method, while the download plugin appears > > to > > > > > mutate the URL on Linux yet works on Windows. I find both > > circumstances > > > > > rather hard to believe yet my battle today leaves me empty handed > and > > > > > frustrated. > > > > > > > > I have never heard of nor used "the download plugin" you speak of. If > > > > it does not work as you expect, I'd encourage you to sort out who > > > > "owns" it and perhaps talk to them about its deficiencies. This is > not > > > > an Apache Maven-supported plugin but rather something created by a > > > > random user, I'd assume. > > > > > > > > > > If you search for maven-download-plugin you should reach a project on > > > GitHub. > > > > > > Please advise them to rename their plugin as the current name is in > > violation of the permitted usages of the ASF's trademark Maven: > > > > > http://markmail.org/search/?q=list%3Aorg.apache.maven.dev#query:list%3Aorg.apache.maven.dev+page:1+mid:cmqxvj6ddshmnzwr+state:results > > > > And further the name confuses users as to who is responsible for the > > plugin. > > > > > > > There is another problem with this plugin in our case - it caches > > > the result which may prove undesirable given we are currently > developing > > > against snapshots... > > > > > > > > > > > > > > Perhaps take a look at the maven-remote-resources-plugin, or the > > > > maven-dependency-plugin (get or copy goals). Both are "official" and > > > > supported plugins produced by the Apache Maven team. But I don't > think > > > > you should need to use either of them, as stated earlier. > > > > > > > > > > I'll take a look it only to be more familiar with them. I'll look at > the > > > dependency option harder albeit with my concern about them living in a > > area > > > of the archive not normally served to
Maven plugin trademarks [Re: Downloading a file for shipping in an artifact]
I made this mistake too. Could I make some suggestions? Add the banned naming to the top of plugin guides, such as: http://maven.apache.org/guides/plugin/guide-java-plugin-development.html Change this page to only have the single prefix-maven-plugin example: http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html I scan read and thought they were just two options. Use big/bold/red font. "You must not name your plugin maven-foo-plugin as these are reserved by trademark for the Apache Maven project itself" Sonatype's Maven Central upload should have a rule to prevent any new jar being pushed with the maven-*-plugin name (unless its an update to an existing version or within org.apache.maven group). I'd note that now I have a plugin in Maven Central with the wrong name I can't remove it, so getting this wrong is a right pain in the *** and messes lots of things up. Stephen On 12 June 2013 07:59, James Green wrote: > Many thanks for filing this - I do assure you that I was not under the > impression the GitHub plugin was official or even endorsed but I agree that > the trademark requires work to enforce. And I just love their response in > your ticket - made me laugh and cringe..! > > James > > > On 11 June 2013 22:44, Stephen Connolly > wrote: > >> On 11 June 2013 22:27, Stephen Connolly > >wrote: >> >> > On 11 June 2013 22:03, James Green wrote: >> > >> >> If you search for maven-download-plugin you should reach a project on >> >> GitHub. >> > >> > >> > Please advise them to rename their plugin as the current name is in >> > violation of the permitted usages of the ASF's trademark Maven: >> > >> http://markmail.org/search/?q=list%3Aorg.apache.maven.dev#query:list%3Aorg.apache.maven.dev+page:1+mid:cmqxvj6ddshmnzwr+state:results >> > >> > And further the name confuses users as to who is responsible for the >> > plugin. >> > >> >> Filed: >> >> https://github.com/maven-download-plugin/maven-download-plugin/issues/14 >> >> I so hate having to do this... the "joys" of having to defend a trademark! >> - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Downloading a file for shipping in an artifact
Stephen/Wayne, I've got the maven-dependency-plugin to download and copy our .exe into src/main/webapp just fine. However, with the package lifecycle, it fails to make it into the web archive. If I switch it to the validate lifecycle, it works. I'm supposing the invocation is happening after the war plugin has executed, or that the war plugin does not include the .exe (even though the documentation states everything is included)? On the right track at least! Thanks, James On 11 June 2013 22:27, Stephen Connolly wrote: > On 11 June 2013 22:03, James Green wrote: > > > See responses inline. > > > > > > On 11 June 2013 21:47, Wayne Fay wrote: > > > > > > Nexus is used to host the .exe file. As the exe originates from a > > > separate > > > > Maven project, and it needs to live somewhere, I folded the exe > > > generation > > > > into an ant task as part of that maven project. Now I have versioned > > > > hosting of the exe. > > > > > > I'm still confused about why you are having this problem at all. I > > > think you are inventing solutions to a problem that already has a > > > solution in Maven. > > > > > > > That's why I'm here in the hope there is a more accepted way to follow :) > > > > > > > > > > I expect you are using "deploy:deploy-file" to push this EXE artifact > > > to Nexus -- if not, how are you doing this? Then you should be able to > > > simply add a standard dependency in the WAR pom file against that EXE > > > and it should be pulled down and included along with other > > > dependencies when the WAR is constructed. (Probably you should be > > > using a classifier like "windows" and a type like "exe" when you > > > deploy this file, and then specify those in the WAR pom dependency as > > > well.) > > > > > > > I'm not at my desk at the moment and I don't recall how the additional > file > > (the .exe) gets included in the deploy phase. I'll try to remember to > > report back in the morning more specifically. > > > > In regards to adding the dependency, this seems logical. But won't the > file > > be shipped in a part of the archive not normally accessible to web > clients? > > Specifically if it ends up in WEB-INF/lib - doesn't feel like a natural > > place to serve downloadable content from. > > > > No, unless it is a "known" file type it will not be included in the .war > *by default* > > You will need to use dependency:copy-dependencies to copy the .exe into the > location you want within your .war file > > > > > > > > > > So I'm rather stuck and seeking suggestions. Nexus doesn't appear to > be > > > > compatible with the wagon method, while the download plugin appears > to > > > > mutate the URL on Linux yet works on Windows. I find both > circumstances > > > > rather hard to believe yet my battle today leaves me empty handed and > > > > frustrated. > > > > > > I have never heard of nor used "the download plugin" you speak of. If > > > it does not work as you expect, I'd encourage you to sort out who > > > "owns" it and perhaps talk to them about its deficiencies. This is not > > > an Apache Maven-supported plugin but rather something created by a > > > random user, I'd assume. > > > > > > > If you search for maven-download-plugin you should reach a project on > > GitHub. > > > Please advise them to rename their plugin as the current name is in > violation of the permitted usages of the ASF's trademark Maven: > > http://markmail.org/search/?q=list%3Aorg.apache.maven.dev#query:list%3Aorg.apache.maven.dev+page:1+mid:cmqxvj6ddshmnzwr+state:results > > And further the name confuses users as to who is responsible for the > plugin. > > > > There is another problem with this plugin in our case - it caches > > the result which may prove undesirable given we are currently developing > > against snapshots... > > > > > > > > > > Perhaps take a look at the maven-remote-resources-plugin, or the > > > maven-dependency-plugin (get or copy goals). Both are "official" and > > > supported plugins produced by the Apache Maven team. But I don't think > > > you should need to use either of them, as stated earlier. > > > > > > > I'll take a look it only to be more familiar with them. I'll look at the > > dependency option harder albeit with my concern about them living in a > area > > of the archive not normally served to web clients. > > > > Thanks very much for the information so far. > > > > James > > > > > > > > > > Wayne > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > >
Re: Downloading a file for shipping in an artifact
Stephen, Many thanks for filing this - I do assure you that I was not under the impression the GitHub plugin was official or even endorsed but I agree that the trademark requires work to enforce. And I just love their response in your ticket - made me laugh and cringe..! James On 11 June 2013 22:44, Stephen Connolly wrote: > On 11 June 2013 22:27, Stephen Connolly >wrote: > > > On 11 June 2013 22:03, James Green wrote: > > > >> If you search for maven-download-plugin you should reach a project on > >> GitHub. > > > > > > Please advise them to rename their plugin as the current name is in > > violation of the permitted usages of the ASF's trademark Maven: > > > http://markmail.org/search/?q=list%3Aorg.apache.maven.dev#query:list%3Aorg.apache.maven.dev+page:1+mid:cmqxvj6ddshmnzwr+state:results > > > > And further the name confuses users as to who is responsible for the > > plugin. > > > > Filed: > > https://github.com/maven-download-plugin/maven-download-plugin/issues/14 > > I so hate having to do this... the "joys" of having to defend a trademark! >
Re: Downloading a file for shipping in an artifact
On 11 June 2013 22:27, Stephen Connolly wrote: > On 11 June 2013 22:03, James Green wrote: > >> If you search for maven-download-plugin you should reach a project on >> GitHub. > > > Please advise them to rename their plugin as the current name is in > violation of the permitted usages of the ASF's trademark Maven: > http://markmail.org/search/?q=list%3Aorg.apache.maven.dev#query:list%3Aorg.apache.maven.dev+page:1+mid:cmqxvj6ddshmnzwr+state:results > > And further the name confuses users as to who is responsible for the > plugin. > Filed: https://github.com/maven-download-plugin/maven-download-plugin/issues/14 I so hate having to do this... the "joys" of having to defend a trademark!
Re: Downloading a file for shipping in an artifact
> If you search for maven-download-plugin you should reach a project on > GitHub. There is another problem with this plugin in our case - it caches Yes, I found it, but don't plan to do much more at this time. > I'll take a look it only to be more familiar with them. I'll look at the > dependency option harder albeit with my concern about them living in a area > of the archive not normally served to web clients. You can specify where you might like files to be located in the resulting package via the m-dependency-p with proper configuration. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Downloading a file for shipping in an artifact
On 11 June 2013 22:03, James Green wrote: > See responses inline. > > > On 11 June 2013 21:47, Wayne Fay wrote: > > > > Nexus is used to host the .exe file. As the exe originates from a > > separate > > > Maven project, and it needs to live somewhere, I folded the exe > > generation > > > into an ant task as part of that maven project. Now I have versioned > > > hosting of the exe. > > > > I'm still confused about why you are having this problem at all. I > > think you are inventing solutions to a problem that already has a > > solution in Maven. > > > > That's why I'm here in the hope there is a more accepted way to follow :) > > > > > > I expect you are using "deploy:deploy-file" to push this EXE artifact > > to Nexus -- if not, how are you doing this? Then you should be able to > > simply add a standard dependency in the WAR pom file against that EXE > > and it should be pulled down and included along with other > > dependencies when the WAR is constructed. (Probably you should be > > using a classifier like "windows" and a type like "exe" when you > > deploy this file, and then specify those in the WAR pom dependency as > > well.) > > > > I'm not at my desk at the moment and I don't recall how the additional file > (the .exe) gets included in the deploy phase. I'll try to remember to > report back in the morning more specifically. > > In regards to adding the dependency, this seems logical. But won't the file > be shipped in a part of the archive not normally accessible to web clients? > Specifically if it ends up in WEB-INF/lib - doesn't feel like a natural > place to serve downloadable content from. > No, unless it is a "known" file type it will not be included in the .war *by default* You will need to use dependency:copy-dependencies to copy the .exe into the location you want within your .war file > > > > > So I'm rather stuck and seeking suggestions. Nexus doesn't appear to be > > > compatible with the wagon method, while the download plugin appears to > > > mutate the URL on Linux yet works on Windows. I find both circumstances > > > rather hard to believe yet my battle today leaves me empty handed and > > > frustrated. > > > > I have never heard of nor used "the download plugin" you speak of. If > > it does not work as you expect, I'd encourage you to sort out who > > "owns" it and perhaps talk to them about its deficiencies. This is not > > an Apache Maven-supported plugin but rather something created by a > > random user, I'd assume. > > > > If you search for maven-download-plugin you should reach a project on > GitHub. Please advise them to rename their plugin as the current name is in violation of the permitted usages of the ASF's trademark Maven: http://markmail.org/search/?q=list%3Aorg.apache.maven.dev#query:list%3Aorg.apache.maven.dev+page:1+mid:cmqxvj6ddshmnzwr+state:results And further the name confuses users as to who is responsible for the plugin. > There is another problem with this plugin in our case - it caches > the result which may prove undesirable given we are currently developing > against snapshots... > > > > > > Perhaps take a look at the maven-remote-resources-plugin, or the > > maven-dependency-plugin (get or copy goals). Both are "official" and > > supported plugins produced by the Apache Maven team. But I don't think > > you should need to use either of them, as stated earlier. > > > > I'll take a look it only to be more familiar with them. I'll look at the > dependency option harder albeit with my concern about them living in a area > of the archive not normally served to web clients. > > Thanks very much for the information so far. > > James > > > > > > Wayne > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
Re: Downloading a file for shipping in an artifact
See responses inline. On 11 June 2013 21:47, Wayne Fay wrote: > > Nexus is used to host the .exe file. As the exe originates from a > separate > > Maven project, and it needs to live somewhere, I folded the exe > generation > > into an ant task as part of that maven project. Now I have versioned > > hosting of the exe. > > I'm still confused about why you are having this problem at all. I > think you are inventing solutions to a problem that already has a > solution in Maven. > That's why I'm here in the hope there is a more accepted way to follow :) > > I expect you are using "deploy:deploy-file" to push this EXE artifact > to Nexus -- if not, how are you doing this? Then you should be able to > simply add a standard dependency in the WAR pom file against that EXE > and it should be pulled down and included along with other > dependencies when the WAR is constructed. (Probably you should be > using a classifier like "windows" and a type like "exe" when you > deploy this file, and then specify those in the WAR pom dependency as > well.) > I'm not at my desk at the moment and I don't recall how the additional file (the .exe) gets included in the deploy phase. I'll try to remember to report back in the morning more specifically. In regards to adding the dependency, this seems logical. But won't the file be shipped in a part of the archive not normally accessible to web clients? Specifically if it ends up in WEB-INF/lib - doesn't feel like a natural place to serve downloadable content from. > > So I'm rather stuck and seeking suggestions. Nexus doesn't appear to be > > compatible with the wagon method, while the download plugin appears to > > mutate the URL on Linux yet works on Windows. I find both circumstances > > rather hard to believe yet my battle today leaves me empty handed and > > frustrated. > > I have never heard of nor used "the download plugin" you speak of. If > it does not work as you expect, I'd encourage you to sort out who > "owns" it and perhaps talk to them about its deficiencies. This is not > an Apache Maven-supported plugin but rather something created by a > random user, I'd assume. > If you search for maven-download-plugin you should reach a project on GitHub. There is another problem with this plugin in our case - it caches the result which may prove undesirable given we are currently developing against snapshots... > > Perhaps take a look at the maven-remote-resources-plugin, or the > maven-dependency-plugin (get or copy goals). Both are "official" and > supported plugins produced by the Apache Maven team. But I don't think > you should need to use either of them, as stated earlier. > I'll take a look it only to be more familiar with them. I'll look at the dependency option harder albeit with my concern about them living in a area of the archive not normally served to web clients. Thanks very much for the information so far. James > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Downloading a file for shipping in an artifact
> Nexus is used to host the .exe file. As the exe originates from a separate > Maven project, and it needs to live somewhere, I folded the exe generation > into an ant task as part of that maven project. Now I have versioned > hosting of the exe. I'm still confused about why you are having this problem at all. I think you are inventing solutions to a problem that already has a solution in Maven. I expect you are using "deploy:deploy-file" to push this EXE artifact to Nexus -- if not, how are you doing this? Then you should be able to simply add a standard dependency in the WAR pom file against that EXE and it should be pulled down and included along with other dependencies when the WAR is constructed. (Probably you should be using a classifier like "windows" and a type like "exe" when you deploy this file, and then specify those in the WAR pom dependency as well.) > So I'm rather stuck and seeking suggestions. Nexus doesn't appear to be > compatible with the wagon method, while the download plugin appears to > mutate the URL on Linux yet works on Windows. I find both circumstances > rather hard to believe yet my battle today leaves me empty handed and > frustrated. I have never heard of nor used "the download plugin" you speak of. If it does not work as you expect, I'd encourage you to sort out who "owns" it and perhaps talk to them about its deficiencies. This is not an Apache Maven-supported plugin but rather something created by a random user, I'd assume. Perhaps take a look at the maven-remote-resources-plugin, or the maven-dependency-plugin (get or copy goals). Both are "official" and supported plugins produced by the Apache Maven team. But I don't think you should need to use either of them, as stated earlier. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Downloading a file for shipping in an artifact
Nexus is used to host the .exe file. As the exe originates from a separate Maven project, and it needs to live somewhere, I folded the exe generation into an ant task as part of that maven project. Now I have versioned hosting of the exe. But our customers are trapped behind a strict firewall. We will by arrangement be shipping our .war file to them for hosting. The .exe is required for internal distribution by our customers and the software it installs provides custom access to the services offered by that web application. It therefore makes sense to ship the exe within the war. Now back to Nexus. When I search for the artifact that is the .exe and copy the download link, it is of a redirection URL. The wagon plugin, for some reason, wants a directory to look in more similar to an FTP service I guess. So I'm rather stuck and seeking suggestions. Nexus doesn't appear to be compatible with the wagon method, while the download plugin appears to mutate the URL on Linux yet works on Windows. I find both circumstances rather hard to believe yet my battle today leaves me empty handed and frustrated. James On 11 June 2013 19:43, Wayne Fay wrote: > > We have a maven project that results in a web archive. We want to ship a > > file (a .exe) within this for simple download by customers. > ... > > So I am left wondering how I can ask that a web archive can be built that > > ships with a file downloaded from our Nexus installation? This doesn't > > sound like it should be difficult but I'm still left frustrated. > > You're asking 2 different questions from my POV. > > In the first, you want to make a WAR and include a special EXE file > inside the WAR. Then I imagine you would deploy the WAR somewhere and > the EXE would be downloadable. > > In the second, you start talking about Nexus. If you just want people > to be able to download a file from Nexus, I'd use deploy:deploy-file > or similar to deploy the EXE by itself to Nexus. > > What are you really trying to do? Why are you bringing up Nexus in the > first place? > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Downloading a file for shipping in an artifact
> We have a maven project that results in a web archive. We want to ship a > file (a .exe) within this for simple download by customers. ... > So I am left wondering how I can ask that a web archive can be built that > ships with a file downloaded from our Nexus installation? This doesn't > sound like it should be difficult but I'm still left frustrated. You're asking 2 different questions from my POV. In the first, you want to make a WAR and include a special EXE file inside the WAR. Then I imagine you would deploy the WAR somewhere and the EXE would be downloadable. In the second, you start talking about Nexus. If you just want people to be able to download a file from Nexus, I'd use deploy:deploy-file or similar to deploy the EXE by itself to Nexus. What are you really trying to do? Why are you bringing up Nexus in the first place? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Downloading a file for shipping in an artifact
We have a maven project that results in a web archive. We want to ship a file (a .exe) within this for simple download by customers. I've looked at the wagon plugin ( http://mojo.codehaus.org/wagon-maven-plugin/download-mojo.html) but this requires the target URL to be a directory from which a relative file is chosen. I'm downloading from a Nexus installation which provides a URL for a single file so isn't suitable. I've looked at the maven-download-plugin but while this works perfectly on our development Windows workstations, on our Linux Jenkins instance we end up with the final slash in the URL duplicated, resulting in entirely the wrong content downloaded. So I am left wondering how I can ask that a web archive can be built that ships with a file downloaded from our Nexus installation? This doesn't sound like it should be difficult but I'm still left frustrated. Any suggestions? I really don't want to take responsibility to manually constructing this thing, or have to manually commit to the project's SVN repo the .exe file to skip this dynamic process. Thanks, James
