You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by tbee <tb...@tbee.org> on 2010/02/23 13:24:02 UTC

fetching an artifact directly

I'm well on my way in creating my first Maven plugin. One unexpected
behavior, but I've coded around that. But what I require now is some what
deviating; the plugin creates a special jar similar to onejar, containing
all files that are required at runtime as a single deliverable. 

Naturally there is some bootstrap code and it is present in its own
jar-artifact. What I require the plugin to do is explicitly fetch that
artifact and unpack it. It's not a dependency in the pom of the plugin (it
could be, but isn't atm) nor in the pom of the actual project; I simply need
a "artifact = resolveArtifact(groupid, artifactid, version)".

It is either that, or I need to attach the jar as a resource to the plugin.
-- 
View this message in context: http://old.nabble.com/fetching-an-artifact-directly-tp27702529p27702529.html
Sent from the Maven Developers mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: fetching an artifact directly

Posted by tbee <tb...@tbee.org>.


tbee wrote:
> 
> - include bootstrap-1.0.jar as a resource in plugin-1.0.jar, so it can be
> opened as a resource when the plugin runs

That was easy; first use the maven-dependency-plugin to put all dependencies
in a separate folder and then configure a resource including only the one
jar. 

-- 
View this message in context: http://old.nabble.com/fetching-an-artifact-directly-tp27702529p27705178.html
Sent from the Maven Developers mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: fetching an artifact directly

Posted by tbee <tb...@tbee.org>.


Stephen Connolly-2 wrote:
> 
> fetching the artifact directly can cause issues when you want to use the
> release plugin if the artifact you want to fetch is part of the reactor
> you
> are fetching.
> 

The plugin knows it requires "bootstrap-1.0.jar"; it needs to fetch it
somehow, unpack it and include the contents directly into the resulting jar. 

This can be done in two ways:
- include bootstrap-1.0.jar as a resource in plugin-1.0.jar, so it can be
opened as a resource when the plugin is run (how?)
- "download" bootstrap-1.0.jar from the repository when the plugin is run
(how?)

Release of either bootstrap and plugin are separate; the plugin may become
more complex, but still depend on bootstrap-1.0. And vice versa the
bootstrap code may do some bug fixing, but have no API changes. Although I
would expect that if the bootstrap has a new release, the plugin will as
well.

What I really need to know is either how to include a dependency as a
resource, or how to force-download a dependency in a plugin.



-- 
View this message in context: http://old.nabble.com/fetching-an-artifact-directly-tp27702529p27702943.html
Sent from the Maven Developers mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: fetching an artifact directly

Posted by Stephen Connolly <st...@gmail.com>.
fetching the artifact directly can cause issues when you want to use the
release plugin if the artifact you want to fetch is part of the reactor you
are fetching.

if you will always be releasing this artifact separately from the "onejar"
projects, then you can fetch it directly

if you will have different versions used by different "onejar" projects in
the same reactor, then (at least for m2) you cannot use it as a plugin
dependency [by that I mean
onejar-project/pom.xml:/project/build/plugins/plugin/dependencies/dependency
and not onejar-maven-plugin/pom.xml:/project/dependencies/dependency ] (due
to a bug in how m2 sets up the classloaders for a plugin, the first time a
plugin is loaded, that classloader is used for all throught the reactor)

To my mind it makes more sense as a project dependency with scope of either
provided (i.e. it's provided if it's needed) or runtime (i.e. it will be
available at runtime but not on the compile classpath) but only if you might
be releasing it in the same reactor as a "onejar" project that uses it.

So you need to answer for yourself, how will this get released.

In my case, I would probably just keep the version synced through the plugin
and tell people to go and jump if they want to release from the same reactor
two modules which are using different versions ;-) [that is add the dep in
onejar-maven-plugin/pom.xml:/project/dependencies/dependency]

-Stephen

On 23 February 2010 12:24, tbee <tb...@tbee.org> wrote:

>
> I'm well on my way in creating my first Maven plugin. One unexpected
> behavior, but I've coded around that. But what I require now is some what
> deviating; the plugin creates a special jar similar to onejar, containing
> all files that are required at runtime as a single deliverable.
>
> Naturally there is some bootstrap code and it is present in its own
> jar-artifact. What I require the plugin to do is explicitly fetch that
> artifact and unpack it. It's not a dependency in the pom of the plugin (it
> could be, but isn't atm) nor in the pom of the actual project; I simply
> need
> a "artifact = resolveArtifact(groupid, artifactid, version)".
>
> It is either that, or I need to attach the jar as a resource to the plugin.
> --
> View this message in context:
> http://old.nabble.com/fetching-an-artifact-directly-tp27702529p27702529.html
> Sent from the Maven Developers mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>