Re: AW: expressing dependencies of third-party jars in internal repository

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: AW: expressing dependencies of third-party jars in internal repository

Doug Douglass
Matthias,

This issue was the initial reason I setup an internal repo -- I couldn't
determine the EXACT versions of the dependencies required by/bundled
with a third party jar, so I did just I as you describe below.

The general problem, as you know, is discovering the dependencies of a
dependency and having them all added to a projects POM (or at least it's
classpath). I presume this is where Deputy helps (I haven't had time yet
to check it out).

Perhaps a new "bundle" dependency type could be used (i.e.,
<groupdId>/bundles/<artifactId>-<version>...) where the bundle is just a
zip of jars. Or better yet a jar with a Class-Path entry in its
manifest. Hmmmm...

Since I haven't written any plugins (yet), I'm not sure of the
feasibility/effort of adding a new dependency type, but I'm willing to
help ;)

Cheers,
Doug

Matthias Burbach wrote:

> Hi,
>
> The other day I posted a similar question.
>
> It was in reply to Brett's hint that the Deputy sources don't build
> because I defined dependencies to 3rd party jars which are only
> available in my local repository under exactly those names.
>
> The question went like this:
>
>>...
>>I am not so sure, however, what to do about the 'doesn't build'
>
> problem. >The obvious thing would be, of course, not to use a
> private-only repository >for the dependencies. The problem then is: The
> jars I use are mainly taken >from the JDOM distribution and I don't know
> if I can find exactly those >anywhere out there in a public repository.
> And even worse, they seldom have >a proper version coded in the file
> name nor do they have a POM stating >their dependencies. Same thing with
> the Java Help jar. So I renamed jars to >include versions I figured from
> Mainfest files and I 'invented' a few POMs >and put all of this into my
> private repository.
>
>>How can I do better? Is there an accepted way to improve the contents
>
> of a >public repository even if it concerns artifacts I'm just a user
> of?
>
>>...
>
>
> It would be great to find a better solution to this.
>
> Regards,
> Matthias
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

AW: AW: expressing dependencies of third-party jars in internal repository

Matthias Burbach
Doug,

You're right that Deputy recursively discovers dependencies of
dependencies and adds them to a project's POM.
The prerequisite to make this work is that each dependency project has a
POM in a repository which defines its dependencies.
And this is where the problem is: if 3rd-party jars occur somewhere in
my dependency graph which are not (yet) represented by a proper POM in a
public repository I have to reconstruct/fake it in my local repository.
But this is not in line with the Maven idea as I understand it (though
it works in an isolated environment).

Cheers,
Matthias

-----Urspr√ľngliche Nachricht-----
Von: users-return-23847-Matthias.Burbach=[hidden email]
[mailto:users-return-23847-Matthias.Burbach=[hidden email]] Im
Auftrag von Doug Douglass
Gesendet: Donnerstag, 5. Mai 2005 00:06
An: Maven Users List
Betreff: Re: AW: expressing dependencies of third-party jars in internal
repository

Matthias,

This issue was the initial reason I setup an internal repo -- I couldn't

determine the EXACT versions of the dependencies required by/bundled
with a third party jar, so I did just I as you describe below.

The general problem, as you know, is discovering the dependencies of a
dependency and having them all added to a projects POM (or at least it's

classpath). I presume this is where Deputy helps (I haven't had time yet

to check it out).

Perhaps a new "bundle" dependency type could be used (i.e.,
<groupdId>/bundles/<artifactId>-<version>...) where the bundle is just a

zip of jars. Or better yet a jar with a Class-Path entry in its
manifest. Hmmmm...

Since I haven't written any plugins (yet), I'm not sure of the
feasibility/effort of adding a new dependency type, but I'm willing to
help ;)

Cheers,
Doug

Matthias Burbach wrote:

> Hi,
>
> The other day I posted a similar question.
>
> It was in reply to Brett's hint that the Deputy sources don't build
> because I defined dependencies to 3rd party jars which are only
> available in my local repository under exactly those names.
>
> The question went like this:
>
>>...
>>I am not so sure, however, what to do about the 'doesn't build'
>
> problem. >The obvious thing would be, of course, not to use a
> private-only repository >for the dependencies. The problem then is:
The
> jars I use are mainly taken >from the JDOM distribution and I don't
know
> if I can find exactly those >anywhere out there in a public
repository.
> And even worse, they seldom have >a proper version coded in the file
> name nor do they have a POM stating >their dependencies. Same thing
with
> the Java Help jar. So I renamed jars to >include versions I figured
from
> Mainfest files and I 'invented' a few POMs >and put all of this into
my

> private repository.
>
>>How can I do better? Is there an accepted way to improve the contents
>
> of a >public repository even if it concerns artifacts I'm just a user
> of?
>
>>...
>
>
> It would be great to find a better solution to this.
>
> Regards,
> Matthias
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: AW: expressing dependencies of third-party jars in internal repository

Brett Porter
The plan going forward is for Maven 2.0 to support reading POMs for
these, but not distributing the JARs, so the error messages can be
more helpful. A plugin will be provided to make it easy to add to your
local/internal repository from a filesystem location.

HTH,
BRett

On 5/5/05, Matthias Burbach <[hidden email]> wrote:

> Doug,
>
> You're right that Deputy recursively discovers dependencies of
> dependencies and adds them to a project's POM.
> The prerequisite to make this work is that each dependency project has a
> POM in a repository which defines its dependencies.
> And this is where the problem is: if 3rd-party jars occur somewhere in
> my dependency graph which are not (yet) represented by a proper POM in a
> public repository I have to reconstruct/fake it in my local repository.
> But this is not in line with the Maven idea as I understand it (though
> it works in an isolated environment).
>
> Cheers,
> Matthias
>
> -----Urspr√ľngliche Nachricht-----
> Von: users-return-23847-Matthias.Burbach=[hidden email]
> [mailto:users-return-23847-Matthias.Burbach=[hidden email]] Im
> Auftrag von Doug Douglass
> Gesendet: Donnerstag, 5. Mai 2005 00:06
> An: Maven Users List
> Betreff: Re: AW: expressing dependencies of third-party jars in internal
> repository
>
> Matthias,
>
> This issue was the initial reason I setup an internal repo -- I couldn't
>
> determine the EXACT versions of the dependencies required by/bundled
> with a third party jar, so I did just I as you describe below.
>
> The general problem, as you know, is discovering the dependencies of a
> dependency and having them all added to a projects POM (or at least it's
>
> classpath). I presume this is where Deputy helps (I haven't had time yet
>
> to check it out).
>
> Perhaps a new "bundle" dependency type could be used (i.e.,
> <groupdId>/bundles/<artifactId>-<version>...) where the bundle is just a
>
> zip of jars. Or better yet a jar with a Class-Path entry in its
> manifest. Hmmmm...
>
> Since I haven't written any plugins (yet), I'm not sure of the
> feasibility/effort of adding a new dependency type, but I'm willing to
> help ;)
>
> Cheers,
> Doug
>
> Matthias Burbach wrote:
> > Hi,
> >
> > The other day I posted a similar question.
> >
> > It was in reply to Brett's hint that the Deputy sources don't build
> > because I defined dependencies to 3rd party jars which are only
> > available in my local repository under exactly those names.
> >
> > The question went like this:
> >
> >>...
> >>I am not so sure, however, what to do about the 'doesn't build'
> >
> > problem. >The obvious thing would be, of course, not to use a
> > private-only repository >for the dependencies. The problem then is:
> The
> > jars I use are mainly taken >from the JDOM distribution and I don't
> know
> > if I can find exactly those >anywhere out there in a public
> repository.
> > And even worse, they seldom have >a proper version coded in the file
> > name nor do they have a POM stating >their dependencies. Same thing
> with
> > the Java Help jar. So I renamed jars to >include versions I figured
> from
> > Mainfest files and I 'invented' a few POMs >and put all of this into
> my
> > private repository.
> >
> >>How can I do better? Is there an accepted way to improve the contents
> >
> > of a >public repository even if it concerns artifacts I'm just a user
> > of?
> >
> >>...
> >
> >
> > It would be great to find a better solution to this.
> >
> > Regards,
> > Matthias
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]