search

gbivins / maven-external-dependency-plugin

Automatically exported from code.google.com/p/maven-external-dependency-plugin
0 stars 0 forks source link

Support ZIP files #1

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Some projects are shipped as ZIP files, like GAE...

Would be awesome seeing it downloading it once
http://googleappengine.googlecode.com/files/appengine-java-sdk-1.3.0.zip
then unpacking and slicing it.

VELO

Original issue reported on code.google.com by velo...@gmail.com on 8 Feb 2010 at 1:03

GoogleCodeExporter commented 9 years ago 
Hi VELO, love the idea!  

Download and unpack should not be an issue.  When you say slicing it, do you 
mean 
that multiple artifacts may need to get installed into repo from the exploded 
ZIP 
contents?   If that is the case, I guess some configuration would be needed to 
define 
multiple artifacts from a single downloaded resource.  

Please comment back with any comments or how you think something like this 
would 
work.  If you have an example of what artifacts would be created from the GAE 
zip, 
that would be helpful as a target use case.  

Thank You, Robert

Original comment by savage7....@gmail.com on 8 Feb 2010 at 6:43

GoogleCodeExporter commented 9 years ago 
Exactly that....

Right know on flexmojos we do that using a XML  descriptor...
https://docs.sonatype.org/display/FLEXMOJOS/Installing+Flex+SDK+into+maven+repos
itory

But it does need to manually download the flex SDK, you approach seem much more
automated and solid for outsiders....

I think would be a matter of adding the download url on this XML and configure 
your
plugin doing something like:
   <bundle>
       <groupId>org.sonatype.flexmojos</groupId>
       <artifactId>flex-sdk</artifactId>
       <version>1.1.1</version>
       <force>false</force>
   </bundle>

Then it would look find the flex-sdk.xml and read the instructions from it.  
What do
you think?

VELO

Original comment by velo...@gmail.com on 8 Feb 2010 at 11:34

GoogleCodeExporter commented 9 years ago 
Thank you for the example.  Once I get the basic project structure working 
properly, 
I'll add this functionality.  I like the XML descriptor concept.  I'll look 
into this 
further.

Original comment by savage7....@gmail.com on 9 Feb 2010 at 4:16

GoogleCodeExporter commented 9 years ago 
BTW, do you try to download the artifact from remote repos before you try to 
install it?

I ask that because people may try to use your plugin to overwrite artifacts 
already
available on cental, but doing so it is a very dangerous path.

VELO

Original comment by velo...@gmail.com on 9 Feb 2010 at 4:24

GoogleCodeExporter commented 9 years ago 
That is a very good point!  I am checking the local repository before 
downloading, but 
am not first attempting to resolve in remote repositories.   This should be an 
easy 
add!

Original comment by savage7....@gmail.com on 9 Feb 2010 at 4:29

GoogleCodeExporter commented 9 years ago 
FWIW, I think you try to resolve the artifact from remote first and fail the 
build if
the checksum doesn't match (when there is a checksum) , but if there is no 
checksum
just print a warning saying you didn't get it from the URL, but from repo.

Original comment by velo...@gmail.com on 9 Feb 2010 at 4:35

GoogleCodeExporter commented 9 years ago 
Implemented:  Checksum validation 
see Issue #3
http://code.google.com/p/maven-external-dependency-plugin/issues/detail?id=3

I do throw MojoFailureException which ends the build if a checksum does not 
validate.  I also now try to 
resolve the artifact from all repositories prior to downloading.  

Implemented: Attempt to resolve dependencies in repos before downloading 
see Issue #4
http://code.google.com/p/maven-external-dependency-plugin/issues/detail?id=4

_I think I captured the spirit of what you were suggesting...._

If the artifact can be resolved in a local or remote repository, then this 
plugin does nothing further 
with that artifact.  That artifact will be resolved by the default Maven 
dependency resolver prior to 
compile.  Attempting to go around the Maven resolver to download an artifact 
that is hosted in a Maven 
repository  with this plugin would violate the purpose of this plugin and the 
Maven conventions.  This 
plugin is only intended to pull down non-Maven hosted artifacts.

Original comment by savage7....@gmail.com on 11 Feb 2010 at 3:17

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Hi Velo,

FYI, don't have the bundle stuff in yet, but I did look into that and it 
shouldn't be 
too difficult. 

I did add support in the latest build to extract a single artifact from from a 
compressed ZIP download.  See Wiki: Extract_Artifact_From_Downloaded_File

Thanks,
Robert

Original comment by savage7....@gmail.com on 13 Feb 2010 at 7:05

GoogleCodeExporter commented 9 years ago 
Issue 10 has been merged into this issue.

Original comment by savage7....@gmail.com on 26 Sep 2010 at 3:42

GoogleCodeExporter commented 9 years ago 
Two comments on the extractFile solution:

1.) Please don't use an external "descriptor file". Having everything in one 
place (pom.xml) is really nice.

2.) Unfortunately, configuring multiple artifactItems that extract files from 
the same downloadUrl is currently quite verbose, even if one uses properties:

<configuration>
  <artifactItems>
    <artifactItem>
      <groupId>org.example</groupId>
      <artifactId>first-artifact</artifactId>
      <version>1.0</version>
      <packaging>jar</packaging>
      <downloadUrl>${download.url}</downloadUrl>
      <extractFile>{artifactId}.{packaging}</extractFile>
    </artifactItem>
    <artifactItem>
      <groupId>org.example</groupId>
      <artifactId>second-artifact</artifactId>
      <version>1.0</version>
      <packaging>jar</packaging>
      <downloadUrl>${download.url}</downloadUrl>
      <extractFile>{artifactId}.{packaging}</extractFile>
    </artifactItem>
  </artifactItems>
</configuration>

It would be nice if one could define a configuration-level groupId, version,  
packaging, and downloadUrl (maybe even extractFile) to which the individual 
artifactItems would then default:

<configuration>
  <groupId>org.example</groupId>
  <version>1.0</version>
  <packaging>jar</packaging>
  <downloadUrl>${download.url}</downloadUrl>
  <artifactItems>
    <artifactItem>
      <artifactId>first-artifact</artifactId>
      <extractFile>{artifactId}.{packaging}</extractFile>
    </artifactItem>
    <artifactItem>
      <artifactId>second-artifact</artifactId>
      <extractFile>{artifactId}.{packaging}</extractFile>
    </artifactItem>
  </artifactItems>
</configuration>

If one wants to apply different defaults to different sets of artifactItems, 
this is easily possible as well; one simply defines several plugin executions.

Original comment by s...@st.informatik.tu-darmstadt.de on 27 Sep 2010 at 7:27

GoogleCodeExporter commented 9 years ago 
I've implemented caching of downloaded files (patch attached).

The implementation is quite straight-forward. In particular, it doesn't 
introduce any new configuration syntax; it simply avoids superfluous downloads 
when several artifactItems have the same downloadUrl.

Original comment by s...@st.informatik.tu-darmstadt.de on 19 Feb 2011 at 4:02

Attachments:

GoogleCodeExporter commented 9 years ago 
I've also implemented a defaulting mechanism (patch attached) whereby 
individual artifactItems inherit their groupId, artifactId, version, 
classifier, packaging, downloadUrl and extractFile properties from the plugin's 
configuration (see comment 11).

Defaults are filled in before token substitution takes place, so that 
parameterizing downloadUrl or extractFile works as expected. This allows one to 
considerably shorten the configuration when extracting multiple artifacts from 
one bundle. (IMHO, this also makes external XML descriptors unnecessary.)

Original comment by s...@st.informatik.tu-darmstadt.de on 19 Feb 2011 at 5:06

Attachments: