On 11 June 2013 22:03, James Green <[email protected]> wrote: > See responses inline. > > > On 11 June 2013 21:47, Wayne Fay <[email protected]> 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
