You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Joachim Durchholz <jo...@durchholz.org> on 2013/01/16 11:08:35 UTC
Packaging up pre-existing jar and source jar
Hi all,
sorry if this is a FAQ but I didn't find instructions on maven.org for this.
I'm provided with a lib.jar and lib-sources.jar.
How do I make Maven generate an artifact from these, without recompiling
the sources? (lib-sources.jar needs to be available for debugging when
importing the artifact as a dependency in other Maven projects.)
Any feedback appreciated!
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Packaging up pre-existing jar and source jar
Posted by Ron Wheeler <rw...@artifact-software.com>.
If I had more time, I would give him my "Resistance is futile!" speech.
Ron
On 17/01/2013 2:10 AM, Anders Hammar wrote:
> You need to read up on Maven terminology. "deploy" means deploying/copying
> to a remote repo (outside your machine). What you seem to be aiming at is
> "install" as installing/copying to your local repo on your machine.
>
> But, you seriously need to look into how Maven is supposed to work. Trying
> to fight the Maven way will just cause you pain and us on the mailing list
> a lot of trouble trying to patch your work. Start by getting a repo manager
> and set up a remote repo. You need that! Then deploy the lib and the
> sources lib to that repo (along with the pom you have created for those).
> They will have the same GAV but the sources artifact will have the
> "sources" classifier.
>
> Ron, if you're listening here, could you please tell Joachim how you wasted
> years not using a repo manager before you saw the light?
>
> /Anders
>
>
> On Thu, Jan 17, 2013 at 12:15 AM, Joachim Durchholz <jo...@durchholz.org>wrote:
>
>> Am 16.01.2013 13:08, schrieb Francesco Mari:
>>
>>> Take a look at the deploy-file mojo [0]. There is a brief explanation
>>> of it in the "Usage" page of the deploy plugin [1].
>>>
>>> [0] http://maven.apache.org/**plugins/maven-deploy-plugin/**
>>> deploy-file-mojo.html<http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html>
>>> [1] http://maven.apache.org/**plugins/maven-deploy-plugin/**usage.html<http://maven.apache.org/plugins/maven-deploy-plugin/usage.html>
>>>
>> Ah, I had seen that but thought it was inapplicable because I want to
>> deploy just to the local repo. But I guess I can tell it to deploy to
>> ${settings.localRepository}, right?
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Packaging up pre-existing jar and source jar
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 17/01/2013 3:43 AM, Joachim Durchholz wrote:
> Am 17.01.2013 08:10, schrieb Anders Hammar:
>> You need to read up on Maven terminology. "deploy" means
>> deploying/copying
>> to a remote repo (outside your machine). What you seem to be aiming
>> at is
>> "install" as installing/copying to your local repo on your machine.
>
> Been there, done that. Can't say that the docs are easy to navigate -
> it's really hard to see whether you have seen everything relevant, and
> if you want to find the exact definition of some terminology, googling
> is useless because that terminology is used all over the place and
> nobody links to the formal definition.
>
>> But, you seriously need to look into how Maven is supposed to work.
>
> Again, been there, done that, had the same problems.
>
> I'm turning to this mailing list because the docs didn't work for me.
> Don't blame me for not having grokked it all, I haven't had a chance
> for that.
>
> > Trying
>> to fight the Maven way will just cause you pain and us on the mailing
>> list
>> a lot of trouble trying to patch your work. Start by getting a repo
>> manager
>> and set up a remote repo. You need that!
>
> Then please tell why I need that. What's going to go wrong without it.
> (A link would be fine.)
>
>> Ron, if you're listening here, could you please tell Joachim how you
>> wasted
>> years not using a repo manager before you saw the light?
>
> No religious terminology like "see the light", "don't fight it", or
> "Maven way", please.
> I vastly prefer understanding over believing.
> I also vastly prefer to be in control of the tools, instead of the
> tools being in control of me.
Maven does not work that way. It will take a load off you and give you a
nice consistent way to develop but you need to do things in a sensible way.
If you want to share 3rd party libraries which are not available in a
Maven repo, you need to upload them into a Maven Repo.
That is your immediate use case for a Maven Repo.
A Maven Repo of your own will also clarify your understanding of how
Maven works by an order of magnitude.
It only takes a few minutes to install Nexus. I can not comment on the
other repo packages that are available.
>
> I'm handing control to tools as I gain confidence in that they'll do
> what I want.
Maven is an all-or-nothing tool. Your projects can not be "a little bit
Mavenized".
> Unfortunately, Maven doesn't really qualify (yet) because of the
> trouble I'm having with the docs. (I'm not having that kind of trouble
> with the Spring docs, by the way. Just to give feedback and a data
> point.)
>
Have you skimmed a couple of the free books that are available?
You don't have to read each paragraph but scan a couple to get a sense
of the way things work.
Do not try to optimize your build until after you get it working. That
is a trap that I have seen a few times. People try to run before they walk.
1) Get your repo setup with a proxy for Maven Central, your deployment
repos(releases and SNAPSHOTs) and a place for 3rd party libraries and
setup your settings.xml files for your team
2) upload your shared jars and explore the Repo
3) Define your Parent POM for your projects
4) Get your builds going with minimal POM files and as few plug-ins as
you can get away with.
Don't be afraid to have a number of Maven projects. You can connect them
up later if it makes sense.
If you are not using Eclipse/STS, I would recommend it. It comes fully
Mavenized.
Ron
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Packaging up pre-existing jar and source jar
Posted by Anders Hammar <an...@hammar.net>.
OK, here goes:
Maven is about several different things. One of those is distributing
software (in the form of artifacts). Maven does that through (remote) Maven
repositories. So unless it is just you, you do need a remote repo. And,
even if it is just you in the dev group, it would probably make sense to
have a repo manager anyways.
A remote repo is basically just a file system area with the Maven artifacts
and some metadata. So you could be fine with a file server or a plain web
server. BUT, your life is going to be so much easier if you go with any of
the (free) repo managers available as it will provide a lot of nice extra
features. And they are also quicker to install that you trying to create
your of solution.
Internally on your machine, Maven also uses a local repository. But this is
just sort of a cache that Maven uses and you should NEVER try to use that
in any way not intended. And it is not intended to be used outside of your
local Maven execution. It doesn't even support multiple concurrent local
Maven executions.
In the early days of Maven we all though we didn't need repo managers. We
all connected directly to remote repos like central and did hacky solutions
to have internal (remote) repos. But today we know that a Maven-based dev
environment REQUIRES a repo manager.
/Anders
On Thu, Jan 17, 2013 at 9:43 AM, Joachim Durchholz <jo...@durchholz.org> wrote:
> Am 17.01.2013 08:10, schrieb Anders Hammar:
>
>> You need to read up on Maven terminology. "deploy" means deploying/copying
>> to a remote repo (outside your machine). What you seem to be aiming at is
>> "install" as installing/copying to your local repo on your machine.
>>
>
> Been there, done that. Can't say that the docs are easy to navigate - it's
> really hard to see whether you have seen everything relevant, and if you
> want to find the exact definition of some terminology, googling is useless
> because that terminology is used all over the place and nobody links to the
> formal definition.
>
> But, you seriously need to look into how Maven is supposed to work.
>>
>
> Again, been there, done that, had the same problems.
>
> I'm turning to this mailing list because the docs didn't work for me.
> Don't blame me for not having grokked it all, I haven't had a chance for
> that.
>
> > Trying
>
>> to fight the Maven way will just cause you pain and us on the mailing list
>> a lot of trouble trying to patch your work. Start by getting a repo
>> manager
>> and set up a remote repo. You need that!
>>
>
> Then please tell why I need that. What's going to go wrong without it.
> (A link would be fine.)
>
> Ron, if you're listening here, could you please tell Joachim how you
>> wasted
>> years not using a repo manager before you saw the light?
>>
>
> No religious terminology like "see the light", "don't fight it", or "Maven
> way", please.
> I vastly prefer understanding over believing.
> I also vastly prefer to be in control of the tools, instead of the tools
> being in control of me.
>
> I'm handing control to tools as I gain confidence in that they'll do what
> I want.
> Unfortunately, Maven doesn't really qualify (yet) because of the trouble
> I'm having with the docs. (I'm not having that kind of trouble with the
> Spring docs, by the way. Just to give feedback and a data point.)
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Packaging up pre-existing jar and source jar
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 17.01.2013 08:10, schrieb Anders Hammar:
> You need to read up on Maven terminology. "deploy" means deploying/copying
> to a remote repo (outside your machine). What you seem to be aiming at is
> "install" as installing/copying to your local repo on your machine.
Been there, done that. Can't say that the docs are easy to navigate -
it's really hard to see whether you have seen everything relevant, and
if you want to find the exact definition of some terminology, googling
is useless because that terminology is used all over the place and
nobody links to the formal definition.
> But, you seriously need to look into how Maven is supposed to work.
Again, been there, done that, had the same problems.
I'm turning to this mailing list because the docs didn't work for me.
Don't blame me for not having grokked it all, I haven't had a chance for
that.
> Trying
> to fight the Maven way will just cause you pain and us on the mailing list
> a lot of trouble trying to patch your work. Start by getting a repo manager
> and set up a remote repo. You need that!
Then please tell why I need that. What's going to go wrong without it.
(A link would be fine.)
> Ron, if you're listening here, could you please tell Joachim how you wasted
> years not using a repo manager before you saw the light?
No religious terminology like "see the light", "don't fight it", or
"Maven way", please.
I vastly prefer understanding over believing.
I also vastly prefer to be in control of the tools, instead of the tools
being in control of me.
I'm handing control to tools as I gain confidence in that they'll do
what I want.
Unfortunately, Maven doesn't really qualify (yet) because of the trouble
I'm having with the docs. (I'm not having that kind of trouble with the
Spring docs, by the way. Just to give feedback and a data point.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Packaging up pre-existing jar and source jar
Posted by Ron Wheeler <rw...@artifact-software.com>.
No need.
It seems that he says that he was only waiting for a use case to install
Nexus and it appears that he found one.
Ron
On 17/01/2013 2:10 AM, Anders Hammar wrote:
> You need to read up on Maven terminology. "deploy" means deploying/copying
> to a remote repo (outside your machine). What you seem to be aiming at is
> "install" as installing/copying to your local repo on your machine.
>
> But, you seriously need to look into how Maven is supposed to work. Trying
> to fight the Maven way will just cause you pain and us on the mailing list
> a lot of trouble trying to patch your work. Start by getting a repo manager
> and set up a remote repo. You need that! Then deploy the lib and the
> sources lib to that repo (along with the pom you have created for those).
> They will have the same GAV but the sources artifact will have the
> "sources" classifier.
>
> Ron, if you're listening here, could you please tell Joachim how you wasted
> years not using a repo manager before you saw the light?
>
> /Anders
>
>
> On Thu, Jan 17, 2013 at 12:15 AM, Joachim Durchholz <jo...@durchholz.org>wrote:
>
>> Am 16.01.2013 13:08, schrieb Francesco Mari:
>>
>>> Take a look at the deploy-file mojo [0]. There is a brief explanation
>>> of it in the "Usage" page of the deploy plugin [1].
>>>
>>> [0] http://maven.apache.org/**plugins/maven-deploy-plugin/**
>>> deploy-file-mojo.html<http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html>
>>> [1] http://maven.apache.org/**plugins/maven-deploy-plugin/**usage.html<http://maven.apache.org/plugins/maven-deploy-plugin/usage.html>
>>>
>> Ah, I had seen that but thought it was inapplicable because I want to
>> deploy just to the local repo. But I guess I can tell it to deploy to
>> ${settings.localRepository}, right?
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Packaging up pre-existing jar and source jar
Posted by Anders Hammar <an...@hammar.net>.
You need to read up on Maven terminology. "deploy" means deploying/copying
to a remote repo (outside your machine). What you seem to be aiming at is
"install" as installing/copying to your local repo on your machine.
But, you seriously need to look into how Maven is supposed to work. Trying
to fight the Maven way will just cause you pain and us on the mailing list
a lot of trouble trying to patch your work. Start by getting a repo manager
and set up a remote repo. You need that! Then deploy the lib and the
sources lib to that repo (along with the pom you have created for those).
They will have the same GAV but the sources artifact will have the
"sources" classifier.
Ron, if you're listening here, could you please tell Joachim how you wasted
years not using a repo manager before you saw the light?
/Anders
On Thu, Jan 17, 2013 at 12:15 AM, Joachim Durchholz <jo...@durchholz.org>wrote:
> Am 16.01.2013 13:08, schrieb Francesco Mari:
>
>> Take a look at the deploy-file mojo [0]. There is a brief explanation
>> of it in the "Usage" page of the deploy plugin [1].
>>
>> [0] http://maven.apache.org/**plugins/maven-deploy-plugin/**
>> deploy-file-mojo.html<http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html>
>> [1] http://maven.apache.org/**plugins/maven-deploy-plugin/**usage.html<http://maven.apache.org/plugins/maven-deploy-plugin/usage.html>
>>
>
> Ah, I had seen that but thought it was inapplicable because I want to
> deploy just to the local repo. But I guess I can tell it to deploy to
> ${settings.localRepository}, right?
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Packaging up pre-existing jar and source jar
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Joachim,
Joachim Durchholz wrote:
> Am 17.01.2013 10:08, schrieb Jörg Schaible:
>>> Ah, I had seen that but thought it was inapplicable because I want to
>>> deploy just to the local repo. But I guess I can tell it to deploy to
>>> ${settings.localRepository}, right?
>>
>> What Anders tells you in a lot of word is: Your last sentence does not
>> make sense in Maven terminology. The local repository is on your home
>> directory and you will *never* deploy something there, "deploy" means
>> always a remote repository.
>
> Ah okay. Then maven-deploy-plugin isn't for me it seems.
>
> > See docs for similar goals:
>>
>> - install:install-file - will add artifact manually to local repo
>
> Ah nice, good enough for now.
> Yeah I know Anders will facepalm over this, but it can't be helped - I'm
> still not seing the use case for a repo server, I'm using maven as a
> download and build tool for now, deployment (to repositories as well as
> to the public) is months away and I have a gazillion of other issues to
> work on.
>
>> And yes, a jar that contains only the sources (must have proper layout
>> though) can be installed as an artifact with classifier "sources" (that's
>> what the maven-sources-plugin does) and you can do this manually with one
>> of the goals above - depending on your target.
>
> I'll just add an execution with install-file in the pom of the
> dependency project I think.
> I think this requires the dependency install to be manually run before
> the main project install. This is counter to Maven's "make the process
> fully automatic" idea, but I don't need that - the dependency needs
> manual intervention to upgrade, so it's no issue to finish the upgrade
> procedure with a mvn install, before returning to the regular scheduled
> main project.
>
> Would this work?
I never used the install-file goal from within a POM, but basically nobody
stops you.
> With the itsy bitsy teeny weeny exception that it won't scale beyond a
> single co-contributor or too many dependencies handled in that way. I
> know I'll have to tackle the repository server when that happens.
> Are there other signs of trouble I should be watching out for?
As fast alternative you may create a poor-man's remote repo. A remote
repository is defined in the end by a URL - and nobody stops you from using
the file protocol. I'd just define such a repo in your settings.xml and
point to a dedicated local or shared directory. That way you can still wipe
your local repo without losing anything or even use such a repo directly in
a small team.
A full-blown repo manager might give you more comfort and give you more
control over the downloaded artifacts if used as proxy, but sometimes a
simple folder hierarchy might be better transportable for private artifacts
... especially in companies you might not be able to provide access to an
internal repo manager for offshore devs ;-)
> Thanks to everybody for their time and patience!
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Packaging up pre-existing jar and source jar
Posted by Stephen Connolly <st...@gmail.com>.
On 17 January 2013 16:16, Joachim Durchholz <jo...@durchholz.org> wrote:
> Am 17.01.2013 10:08, schrieb Jörg Schaible:
>
> Ah, I had seen that but thought it was inapplicable because I want to
>>> deploy just to the local repo. But I guess I can tell it to deploy to
>>> ${settings.localRepository}, right?
>>>
>>
>> What Anders tells you in a lot of word is: Your last sentence does not
>> make
>> sense in Maven terminology. The local repository is on your home directory
>> and you will *never* deploy something there, "deploy" means always a
>> remote
>> repository.
>>
>
> Ah okay. Then maven-deploy-plugin isn't for me it seems.
>
>
> > See docs for similar goals:
>
>>
>> - install:install-file - will add artifact manually to local repo
>>
>
> Ah nice, good enough for now.
> Yeah I know Anders will facepalm over this, but it can't be helped - I'm
> still not seing the use case for a repo server, I'm using maven as a
> download and build tool for now, deployment (to repositories as well as to
> the public) is months away and I have a gazillion of other issues to work
> on.
>
>
> And yes, a jar that contains only the sources (must have proper layout
>> though) can be installed as an artifact with classifier "sources" (that's
>> what the maven-sources-plugin does) and you can do this manually with one
>> of
>> the goals above - depending on your target.
>>
>
> I'll just add an execution with install-file in the pom of the dependency
> project I think.
>
^^^ first sign of trouble
> I think this requires the dependency install to be manually run before the
> main project install. This is counter to Maven's "make the process fully
> automatic" idea,
but I don't need that
^^^ second sign of trouble
> - the dependency needs manual intervention to upgrade, so it's no issue to
> finish the upgrade procedure with a mvn install, before returning to the
> regular scheduled main project.
>
> Would this work?
>
> With the itsy bitsy teeny weeny exception that it won't scale beyond a
> single co-contributor or too many dependencies handled in that way. I know
> I'll have to tackle the repository server when that happens.
> Are there other signs of trouble I should be watching out for?
>
See in-line above
>
> Thanks to everybody for their time and patience!
>
> Regards,
> Jo
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Packaging up pre-existing jar and source jar
Posted by Ron Wheeler <rw...@artifact-software.com>.
Cool song.
Not sure I will last that long!
Ron
On 17/01/2013 11:39 AM, Stephen Connolly wrote:
> On 17 January 2013 16:35, Ron Wheeler <rw...@artifact-software.com>wrote:
>
>> On 17/01/2013 11:16 AM, Joachim Durchholz wrote:
>>
>>> Am 17.01.2013 10:08, schrieb Jörg Schaible:
>>>
>>>> Ah, I had seen that but thought it was inapplicable because I want to
>>>>> deploy just to the local repo. But I guess I can tell it to deploy to
>>>>> ${settings.localRepository}, right?
>>>>>
>>>> What Anders tells you in a lot of word is: Your last sentence does not
>>>> make
>>>> sense in Maven terminology. The local repository is on your home
>>>> directory
>>>> and you will *never* deploy something there, "deploy" means always a
>>>> remote
>>>> repository.
>>>>
>>> Ah okay. Then maven-deploy-plugin isn't for me it seems.
>>>
>>>> See docs for similar goals:
>>>> - install:install-file - will add artifact manually to local repo
>>>>
>>> Ah nice, good enough for now.
>>> Yeah I know Anders will facepalm over this, but it can't be helped - I'm
>>> still not seing the use case for a repo server, I'm using maven as a
>>> download and build tool for now, deployment (to repositories as well as to
>>> the public) is months away and I have a gazillion of other issues to work
>>> on.
>>>
>> Repositories are not public in most cases. It is a way to work with Maven
>> internally.
>> You are going to generate a gazillion of Maven issues that are completely
>> avoidable.
>
> I do love to reminisce about my early days of Maven usage when I through I
> didn't need a repository manager...
>
> Such reminiscence is best conducted while listening to
> https://www.youtube.com/watch?v=AsG1_3OTzyY
>
> -Stephen
>
>
>>
>>> And yes, a jar that contains only the sources (must have proper layout
>>>> though) can be installed as an artifact with classifier "sources" (that's
>>>> what the maven-sources-plugin does) and you can do this manually with
>>>> one of
>>>> the goals above - depending on your target.
>>>>
>>> I'll just add an execution with install-file in the pom of the dependency
>>> project I think.
>>> I think this requires the dependency install to be manually run before
>>> the main project install. This is counter to Maven's "make the process
>>> fully automatic" idea, but I don't need that - the dependency needs manual
>>> intervention to upgrade, so it's no issue to finish the upgrade procedure
>>> with a mvn install, before returning to the regular scheduled main project.
>>>
>>> Would this work?
>>>
>>> With the itsy bitsy teeny weeny exception that it won't scale beyond a
>>> single co-contributor or too many dependencies handled in that way. I know
>>> I'll have to tackle the repository server when that happens.
>>> Are there other signs of trouble I should be watching out for?
>>>
>>> Thanks to everybody for their time and patience!
>>>
>>> Regards,
>>> Jo
>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Packaging up pre-existing jar and source jar
Posted by Ron Wheeler <rw...@artifact-software.com>.
If you look at the list of project commiters, you can see that you got
the best advice possible.
I agree with your comments about the documentation in general and one
has to browse some of the books to get oriented to a point where the
docs are useful.
Good luck
Ron
On 18/01/2013 12:41 PM, Joachim Durchholz wrote:
> Am 18.01.2013 11:07, schrieb Stephen Connolly:
>
>> My point is, you think adding a MRM is adding a point of failure...
>> actually it's taking away about 3-4 points of failure, so NET GAIN in
>> reliability.
>
> Well, right now, everything is bootstrapping nicely from a Bitbucket
> repository.
> I'm using Maven as a build tool. Dependency consolidation is via
> Bitbucket, so that part of MRM functionality isn't very relevant to me.
>
>>> Third, performance. When you list multiple <repository> in your
>>> pom or
>>>> settings.xml you force artifact resolution to hit ALL of them. with
>>>> an MRM
>>>> you set <mirrorOf>*</mirrorOf> and you now only hit one, it's local
>>>> anyway,
>>>> it's flattened (because it's a virtual repo) and you have a fast
>>>> reliable
>>>> build and you can scale it out to others.
>>>>
>>>
>>> I supposes the m2eclipse repository manager does that already. It is
>>> hitting Maven Central on Eclipse startup, once (and takes minutes to
>>> complete).
>>
>> With an MRM this would be seconds not minutes
>
> Yep, it would be the MRM waiting for the repo information and not
> Eclipse :-)
> It looks like m2e is doing the proxying already, so that part of an
> MRM isn't relevant either.
>
>>> I can see that building from the command line might suck, because that
>>> won't have the m2eclipse "Workspace Repositories"
>>
>> That, and I don't use eclipse, is just building a reactor out of all the
>> projects in your workspace which is handy, but will cause issues for
>> you.
>
> Not sure what kinds of issues these might be.
>
>> If you are really trying to grok what maven is doing, forget eclipse,
>> start
>> from the CLI. Eclipse does all sorts of magic to try and protect you
>> from
>> people who don't grok Maven and set up insane builds.
>
> Oh, I don't think it's so hard. I'm avoiding the pom wizards (don't
> give me any value anymore), and I'm editing the poms in the XML editor.
>
> > That's what an IDE
>> should do, but for an engineer trying to grok what Maven is doing,
>> you got
>> to go back to vi and CLI... otherwise you are dealing with Magic
>
> Not much magic seems to be left with that.
>
> I'm starting the builds through a Maven launch configuration. That's
> essentially the command line.
>
> The only "magic" thing that happens is that I can have multiple
> projects open, modify code in any of them, and debug the whole system
> without having to mvn install. If that should fail - well, the launch
> configuration for "mvn install" is just a mouse click away.
>
>> Our issue is we see this *every day*, so our short cut is to tell
>> people:
>> learn from us, this is the way to do it.
>
> It would probably be easier if the online docs were better indexed.
>
> I mean, the "Documentation" link on http://eclipse.org/m2e/ leads to
> http://eclipse.org/m2e/documentation/, which has a single link to
> http://wiki.eclipse.org/Maven_Integration, which is essentially just a
> blurb and installation instructions, but no documentation on what it
> actually does (what you referred to as "magic" above).
> The info on, for example, the items in the "Maven repositories" tab is
> available, but you need to ask Google, it's not linked from the pages.
>
> There are more problems like that:
>
> The Maven documentation site
> (http://maven.apache.org/users/index.html) contains links to
> tutorials, to the POM and Settings references - but no link to
> http://maven.apache.org/guides/index.html .
>
> The list of standard plugins is under "Maven Projects". I ignored that
> section because, you see, a "project" is something that you contribute
> to; that section should be labelled "Maven Usage" or something.
>
> Plugin descriptions abound with terminology but lack links to the
> explanations of that terminology.
> Sample excerpts from pom files do not highlight those parts that are
> relevant to the plugin itself.
>
> Grouping the codehaus.org etc. plugins in a separate section creates
> more questions than answers. Are these plugins of lesser quality? Do
> they have some other technical quality? 'cause when I'm looking for a
> plugin that fulfills a specific task, the most important distinction
> is the class of tasks - core, packaging, reporting. (And the Tools
> section should be split up into "Publication", "Build process
> orchestration" and "Miscellaneous", "Tools" could apply to any plugin.)
>
> The boilerplate text in the "Usage" section of all the plugins is less
> than useful. It's always the same, except where it isn't but you don't
> see it because the differences drown in a sea of, well, boilerplate.
> Besides, what good is "General instructions on how to use the Shade
> Plugin can be found on the usage page." if the "Usage" entry is right
> in the Overview section to the left?
> The remaining boilerplate text follows just the same pattern:
> replicating links that are already present in the sidebar.
> And "To provide you with better understanding on some usages of the
> Shade Plugin, you can take a look into the following examples:" is
> just fluff. It's just text that needs to be scanned to see whether
> anything relevant is in it, but there isn't; a list of bullets under a
> heading of "Examples" is enough.
> The whole plugin documentation flies in the face of the DRY principle.
> Links to the standard explanations are in order, but they should be in
> the sidebar where people expect the always-the-same content, not in
> the running text.
> I'm not sure how that text generation got into the docpage generation
> process. Maybe somebody complained that they overlooked the link in
> the sidebar; in that case, it's probably more helpful to reconsider
> the sidebar structure. For example, it should be structured like this:
> Maven Shade plugin
> Introduction
> Goals
> Usage
> FAQ
> Examples
> Selecting Contents for Uber JAR
> Relocating Classes
> ...
> Plugin information (don't replicate "Introduction" as "About")
> (Leaving out "About", that's the same as "Introduction" - DRY)
> Summary ("project" isn't helpful unless you say which)
> License
> Team
> Source Repository
> ...
> Autogenerated Information (reordered: plugin user interests go first)
> Javadocs
> Main
> Test
> Sources ("Xref" would be names plus using lines)
> Main
> Test
> Test results
> Surefire
> Cobertura Text Coverage
> Code analysis
> Checkstyle
> PMD
> PMD's CPD
> Findbugs
> Sonar
> (Leave "Plugin documentation" out, it's a duplicate of "Goals")
> Maven
> (whatever sections are useful about Maven)
> Apache Software Foundation
> (whatever sections are useful about the ASF)
>
> There. Plugin information separated from Maven and ASF at the top
> level; no repetition, stuff restructured and renamed according to the
> target audience: People who're using the plugin.
>
> Just my 5 cents, while the impression is fresh, written in a somewhat
> dazed state while breeding a flu (apologies for the crankiness), to be
> taken as a data point, in the hope that it helps reducing the
> always-the-same-newbie-question clutter here in the list.
>
> Regards,
> Jo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Packaging up pre-existing jar and source jar
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 18.01.2013 11:07, schrieb Stephen Connolly:
> My point is, you think adding a MRM is adding a point of failure...
> actually it's taking away about 3-4 points of failure, so NET GAIN in
> reliability.
Well, right now, everything is bootstrapping nicely from a Bitbucket
repository.
I'm using Maven as a build tool. Dependency consolidation is via
Bitbucket, so that part of MRM functionality isn't very relevant to me.
>> Third, performance. When you list multiple <repository> in your pom or
>>> settings.xml you force artifact resolution to hit ALL of them. with an MRM
>>> you set <mirrorOf>*</mirrorOf> and you now only hit one, it's local
>>> anyway,
>>> it's flattened (because it's a virtual repo) and you have a fast reliable
>>> build and you can scale it out to others.
>>>
>>
>> I supposes the m2eclipse repository manager does that already. It is
>> hitting Maven Central on Eclipse startup, once (and takes minutes to
>> complete).
>
> With an MRM this would be seconds not minutes
Yep, it would be the MRM waiting for the repo information and not
Eclipse :-)
It looks like m2e is doing the proxying already, so that part of an MRM
isn't relevant either.
>> I can see that building from the command line might suck, because that
>> won't have the m2eclipse "Workspace Repositories"
>
> That, and I don't use eclipse, is just building a reactor out of all the
> projects in your workspace which is handy, but will cause issues for you.
Not sure what kinds of issues these might be.
> If you are really trying to grok what maven is doing, forget eclipse, start
> from the CLI. Eclipse does all sorts of magic to try and protect you from
> people who don't grok Maven and set up insane builds.
Oh, I don't think it's so hard. I'm avoiding the pom wizards (don't give
me any value anymore), and I'm editing the poms in the XML editor.
> That's what an IDE
> should do, but for an engineer trying to grok what Maven is doing, you got
> to go back to vi and CLI... otherwise you are dealing with Magic
Not much magic seems to be left with that.
I'm starting the builds through a Maven launch configuration. That's
essentially the command line.
The only "magic" thing that happens is that I can have multiple projects
open, modify code in any of them, and debug the whole system without
having to mvn install. If that should fail - well, the launch
configuration for "mvn install" is just a mouse click away.
> Our issue is we see this *every day*, so our short cut is to tell people:
> learn from us, this is the way to do it.
It would probably be easier if the online docs were better indexed.
I mean, the "Documentation" link on http://eclipse.org/m2e/ leads to
http://eclipse.org/m2e/documentation/, which has a single link to
http://wiki.eclipse.org/Maven_Integration, which is essentially just a
blurb and installation instructions, but no documentation on what it
actually does (what you referred to as "magic" above).
The info on, for example, the items in the "Maven repositories" tab is
available, but you need to ask Google, it's not linked from the pages.
There are more problems like that:
The Maven documentation site (http://maven.apache.org/users/index.html)
contains links to tutorials, to the POM and Settings references - but no
link to http://maven.apache.org/guides/index.html .
The list of standard plugins is under "Maven Projects". I ignored that
section because, you see, a "project" is something that you contribute
to; that section should be labelled "Maven Usage" or something.
Plugin descriptions abound with terminology but lack links to the
explanations of that terminology.
Sample excerpts from pom files do not highlight those parts that are
relevant to the plugin itself.
Grouping the codehaus.org etc. plugins in a separate section creates
more questions than answers. Are these plugins of lesser quality? Do
they have some other technical quality? 'cause when I'm looking for a
plugin that fulfills a specific task, the most important distinction is
the class of tasks - core, packaging, reporting. (And the Tools section
should be split up into "Publication", "Build process orchestration" and
"Miscellaneous", "Tools" could apply to any plugin.)
The boilerplate text in the "Usage" section of all the plugins is less
than useful. It's always the same, except where it isn't but you don't
see it because the differences drown in a sea of, well, boilerplate.
Besides, what good is "General instructions on how to use the Shade
Plugin can be found on the usage page." if the "Usage" entry is right in
the Overview section to the left?
The remaining boilerplate text follows just the same pattern:
replicating links that are already present in the sidebar.
And "To provide you with better understanding on some usages of the
Shade Plugin, you can take a look into the following examples:" is just
fluff. It's just text that needs to be scanned to see whether anything
relevant is in it, but there isn't; a list of bullets under a heading of
"Examples" is enough.
The whole plugin documentation flies in the face of the DRY principle.
Links to the standard explanations are in order, but they should be in
the sidebar where people expect the always-the-same content, not in the
running text.
I'm not sure how that text generation got into the docpage generation
process. Maybe somebody complained that they overlooked the link in the
sidebar; in that case, it's probably more helpful to reconsider the
sidebar structure. For example, it should be structured like this:
Maven Shade plugin
Introduction
Goals
Usage
FAQ
Examples
Selecting Contents for Uber JAR
Relocating Classes
...
Plugin information (don't replicate "Introduction" as "About")
(Leaving out "About", that's the same as "Introduction" - DRY)
Summary ("project" isn't helpful unless you say which)
License
Team
Source Repository
...
Autogenerated Information (reordered: plugin user interests go first)
Javadocs
Main
Test
Sources ("Xref" would be names plus using lines)
Main
Test
Test results
Surefire
Cobertura Text Coverage
Code analysis
Checkstyle
PMD
PMD's CPD
Findbugs
Sonar
(Leave "Plugin documentation" out, it's a duplicate of "Goals")
Maven
(whatever sections are useful about Maven)
Apache Software Foundation
(whatever sections are useful about the ASF)
There. Plugin information separated from Maven and ASF at the top level;
no repetition, stuff restructured and renamed according to the target
audience: People who're using the plugin.
Just my 5 cents, while the impression is fresh, written in a somewhat
dazed state while breeding a flu (apologies for the crankiness), to be
taken as a data point, in the hope that it helps reducing the
always-the-same-newbie-question clutter here in the list.
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Packaging up pre-existing jar and source jar
Posted by Ron Wheeler <rw...@artifact-software.com>.
Stephen has laid out the case very well.
Had I remembered that I wrote this, I should have referred you to
http://blog.artifact-software.com/tech/?p=177
We had pretty good success starting in Eclipse and once we moved to
Eclipse/STS and got our Nexus repo in place, we were in Maven heaven.
We had a small team with never more that 5 people but we built and
maintained an entire LMS with over 70 Maven projects producing over 60
war files.
I spite of starting out in this business long before GUIs were available
outside Xerox, I prefer to use a GUI when I can.
If you have a look at the articles tagged with Maven you will find some
things that we learned that seemed to help in various aspects of
development with Maven.
Ron
On 18/01/2013 5:07 AM, Stephen Connolly wrote:
> On 18 January 2013 09:35, Joachim Durchholz <jo...@durchholz.org> wrote:
>
>> Am 17.01.2013 23:17, schrieb Stephen Connolly:
>>
>> First, when you are playing with install:install-file you will find that
>>> you regularly need to blow away your local cache (which is the real name
>>> of
>>> the "local repository")...
>>>
>> Turned out I'm not really installing to .m2/repository, but to something
>> that m2eclipse calls "Workspace Projects".
>>
>> This has been working well, so I hope I can stick with that.
>>
>> Seems like that "local repository" terminology had me confused.
>> What about changing the docs so that they don't say "local repository" but
>> "repository cache"? That would spare future maven newbies that confusions.
>> The paragraph that introduces it can explain that it's technically just a
>> normal repository, but that you shouldn't do anything with it but
>> occasionally clean out old cruft (or whatever it is that's okay to do with
>> the local repository cache).
>>
>>
>> Second, repository routing... the killer feature of MRMs. Not everything
>>> is
>>> in central. There's the world of crazyness that is the redhat repos, the
>>> old java.net repos, the pile of people who have yet to get why you should
>>> push your stuff to central, or who think pushing to central is hard... and
>>> then you end up with a pom from one repo and an artifact from another...
>>> and the transitive deps are wrong because the poms are different.
>>>
>>> An MRM allows you to specify exactly what artifacts can be sourced from
>>> which repositories and also gives you a single flat repository for maven
>>> to
>>> pull from...
>>>
>> Okay, this hasn't been an issue yet but I'll keep that in mind.
>>
>>
>>> Most of the MRMs are trivial to set up and give you a reliable store
>>> to cache in front of you.
>> The issue being, this is another potential point of failure that I'll have
>> to check if something goes wrong. So I'll want to postpone this until I'm
>> familiar with the rest of the toolchain, getting that all to work hasn't
>> been easy and I probably haven't seen all failure modes yet.
>
> Run the MRM on your own machine.
>
> There is one MRM that claims to run in like JVM overhead + 64MB of RAM and
> consumes very few CPU resources (hint the company that makes it rhymes with
> Pony tripe and they have an OSS version, which is fine for your needs)
>
> I actually used to do this myself at my previous employers for when I
> needed to work from home. I would run all my builds through that. When I
> was commuting to and from work I could still work away, and when at home I
> didn't need to fire up the VPN to build.
>
> It made my on-line/off-line experience seamless. The other MRMs can provide
> the same experience, I just don't know how low you can push the memory
> usage of them and still have a functioning MRM.
>
> My point is, you think adding a MRM is adding a point of failure...
> actually it's taking away about 3-4 points of failure, so NET GAIN in
> reliability.
>
>
>>
>> Third, performance. When you list multiple <repository> in your pom or
>>> settings.xml you force artifact resolution to hit ALL of them. with an MRM
>>> you set <mirrorOf>*</mirrorOf> and you now only hit one, it's local
>>> anyway,
>>> it's flattened (because it's a virtual repo) and you have a fast reliable
>>> build and you can scale it out to others.
>>>
>> I supposes the m2eclipse repository manager does that already. It is
>> hitting Maven Central on Eclipse startup, once (and takes minutes to
>> complete).
>
> With an MRM this would be seconds not minutes
>
>
>> I think it allows building right away, so I'm probably fine.
>>
>> I can see that building from the command line might suck, because that
>> won't have the m2eclipse "Workspace Repositories"
>
> That, and I don't use eclipse, is just building a reactor out of all the
> projects in your workspace which is handy, but will cause issues for you.
>
> ... erm, what's an MRM? A Maven Repository Manager?
>
>
> Yes
>
>>
>> There's more reasons if you feel you still want some...
>> I'd love to, but only if they are relevant.
>> I have yet to look up what exactly the m2eclipse "Workspace Projects"
>> thing is. Eclipse lists it in the "Maven Repositories" tab.
>>
> If you are really trying to grok what maven is doing, forget eclipse, start
> from the CLI. Eclipse does all sorts of magic to try and protect you from
> people who don't grok Maven and set up insane builds. That's what an IDE
> should do, but for an engineer trying to grok what Maven is doing, you got
> to go back to vi and CLI... otherwise you are dealing with Magic and we
> have to resort to chants of "Follow the Maven way" and "just because" if we
> are dealing with somebody using Magic
>
>
>> Thanks for taking the effort to respond after my rant.
>>
> Our issue is we see this *every day*, so our short cut is to tell people:
> learn from us, this is the way to do it.
>
>
>> Regards,
>> Jo
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Packaging up pre-existing jar and source jar
Posted by Stephen Connolly <st...@gmail.com>.
On 18 January 2013 09:35, Joachim Durchholz <jo...@durchholz.org> wrote:
> Am 17.01.2013 23:17, schrieb Stephen Connolly:
>
> First, when you are playing with install:install-file you will find that
>> you regularly need to blow away your local cache (which is the real name
>> of
>> the "local repository")...
>>
>
> Turned out I'm not really installing to .m2/repository, but to something
> that m2eclipse calls "Workspace Projects".
>
> This has been working well, so I hope I can stick with that.
>
> Seems like that "local repository" terminology had me confused.
> What about changing the docs so that they don't say "local repository" but
> "repository cache"? That would spare future maven newbies that confusions.
> The paragraph that introduces it can explain that it's technically just a
> normal repository, but that you shouldn't do anything with it but
> occasionally clean out old cruft (or whatever it is that's okay to do with
> the local repository cache).
>
>
> Second, repository routing... the killer feature of MRMs. Not everything
>> is
>> in central. There's the world of crazyness that is the redhat repos, the
>> old java.net repos, the pile of people who have yet to get why you should
>> push your stuff to central, or who think pushing to central is hard... and
>> then you end up with a pom from one repo and an artifact from another...
>> and the transitive deps are wrong because the poms are different.
>>
>> An MRM allows you to specify exactly what artifacts can be sourced from
>> which repositories and also gives you a single flat repository for maven
>> to
>> pull from...
>>
>
> Okay, this hasn't been an issue yet but I'll keep that in mind.
>
>
> > Most of the MRMs are trivial to set up and give you a reliable store
> > to cache in front of you.
>
> The issue being, this is another potential point of failure that I'll have
> to check if something goes wrong. So I'll want to postpone this until I'm
> familiar with the rest of the toolchain, getting that all to work hasn't
> been easy and I probably haven't seen all failure modes yet.
Run the MRM on your own machine.
There is one MRM that claims to run in like JVM overhead + 64MB of RAM and
consumes very few CPU resources (hint the company that makes it rhymes with
Pony tripe and they have an OSS version, which is fine for your needs)
I actually used to do this myself at my previous employers for when I
needed to work from home. I would run all my builds through that. When I
was commuting to and from work I could still work away, and when at home I
didn't need to fire up the VPN to build.
It made my on-line/off-line experience seamless. The other MRMs can provide
the same experience, I just don't know how low you can push the memory
usage of them and still have a functioning MRM.
My point is, you think adding a MRM is adding a point of failure...
actually it's taking away about 3-4 points of failure, so NET GAIN in
reliability.
>
>
> Third, performance. When you list multiple <repository> in your pom or
>> settings.xml you force artifact resolution to hit ALL of them. with an MRM
>> you set <mirrorOf>*</mirrorOf> and you now only hit one, it's local
>> anyway,
>> it's flattened (because it's a virtual repo) and you have a fast reliable
>> build and you can scale it out to others.
>>
>
> I supposes the m2eclipse repository manager does that already. It is
> hitting Maven Central on Eclipse startup, once (and takes minutes to
> complete).
With an MRM this would be seconds not minutes
> I think it allows building right away, so I'm probably fine.
>
> I can see that building from the command line might suck, because that
> won't have the m2eclipse "Workspace Repositories"
That, and I don't use eclipse, is just building a reactor out of all the
projects in your workspace which is handy, but will cause issues for you.
... erm, what's an MRM? A Maven Repository Manager?
Yes
>
>
> There's more reasons if you feel you still want some...
>>
>
> I'd love to, but only if they are relevant.
> I have yet to look up what exactly the m2eclipse "Workspace Projects"
> thing is. Eclipse lists it in the "Maven Repositories" tab.
>
If you are really trying to grok what maven is doing, forget eclipse, start
from the CLI. Eclipse does all sorts of magic to try and protect you from
people who don't grok Maven and set up insane builds. That's what an IDE
should do, but for an engineer trying to grok what Maven is doing, you got
to go back to vi and CLI... otherwise you are dealing with Magic and we
have to resort to chants of "Follow the Maven way" and "just because" if we
are dealing with somebody using Magic
>
> Thanks for taking the effort to respond after my rant.
>
Our issue is we see this *every day*, so our short cut is to tell people:
learn from us, this is the way to do it.
>
> Regards,
> Jo
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Packaging up pre-existing jar and source jar
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 17.01.2013 23:17, schrieb Stephen Connolly:
> First, when you are playing with install:install-file you will find that
> you regularly need to blow away your local cache (which is the real name of
> the "local repository")...
Turned out I'm not really installing to .m2/repository, but to something
that m2eclipse calls "Workspace Projects".
This has been working well, so I hope I can stick with that.
Seems like that "local repository" terminology had me confused.
What about changing the docs so that they don't say "local repository"
but "repository cache"? That would spare future maven newbies that
confusions. The paragraph that introduces it can explain that it's
technically just a normal repository, but that you shouldn't do anything
with it but occasionally clean out old cruft (or whatever it is that's
okay to do with the local repository cache).
> Second, repository routing... the killer feature of MRMs. Not everything is
> in central. There's the world of crazyness that is the redhat repos, the
> old java.net repos, the pile of people who have yet to get why you should
> push your stuff to central, or who think pushing to central is hard... and
> then you end up with a pom from one repo and an artifact from another...
> and the transitive deps are wrong because the poms are different.
>
> An MRM allows you to specify exactly what artifacts can be sourced from
> which repositories and also gives you a single flat repository for maven to
> pull from...
Okay, this hasn't been an issue yet but I'll keep that in mind.
> Most of the MRMs are trivial to set up and give you a reliable store
> to cache in front of you.
The issue being, this is another potential point of failure that I'll
have to check if something goes wrong. So I'll want to postpone this
until I'm familiar with the rest of the toolchain, getting that all to
work hasn't been easy and I probably haven't seen all failure modes yet.
> Third, performance. When you list multiple <repository> in your pom or
> settings.xml you force artifact resolution to hit ALL of them. with an MRM
> you set <mirrorOf>*</mirrorOf> and you now only hit one, it's local anyway,
> it's flattened (because it's a virtual repo) and you have a fast reliable
> build and you can scale it out to others.
I supposes the m2eclipse repository manager does that already. It is
hitting Maven Central on Eclipse startup, once (and takes minutes to
complete). I think it allows building right away, so I'm probably fine.
I can see that building from the command line might suck, because that
won't have the m2eclipse "Workspace Repositories" ... erm, what's an
MRM? A Maven Repository Manager?
> There's more reasons if you feel you still want some...
I'd love to, but only if they are relevant.
I have yet to look up what exactly the m2eclipse "Workspace Projects"
thing is. Eclipse lists it in the "Maven Repositories" tab.
Thanks for taking the effort to respond after my rant.
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Packaging up pre-existing jar and source jar
Posted by Stephen Connolly <st...@gmail.com>.
First, when you are playing with install:install-file you will find that
you regularly need to blow away your local cache (which is the real name of
the "local repository")... that will kill you downloading everything again,
and because you had to do the install:install-file you have just lost all
those custom artifacts and you are in a world of pain.
Most of the MRMs are trivial to set up and give you a reliable store to
cache in front of you.
Second, repository routing... the killer feature of MRMs. Not everything is
in central. There's the world of crazyness that is the redhat repos, the
old java.net repos, the pile of people who have yet to get why you should
push your stuff to central, or who think pushing to central is hard... and
then you end up with a pom from one repo and an artifact from another...
and the transitive deps are wrong because the poms are different.
An MRM allows you to specify exactly what artifacts can be sourced from
which repositories and also gives you a single flat repository for maven to
pull from...
Third, performance. When you list multiple <repository> in your pom or
settings.xml you force artifact resolution to hit ALL of them. with an MRM
you set <mirrorOf>*</mirrorOf> and you now only hit one, it's local anyway,
it's flattened (because it's a virtual repo) and you have a fast reliable
build and you can scale it out to others.
There's more reasons if you feel you still want some...
On 17 January 2013 21:54, Joachim Durchholz <jo...@durchholz.org> wrote:
> You two are really priceless.
>
> I have heard the message, I have requested concrete reasoning, yet all I
> get is a pat on the shoulder and a commandment to shut up and believe
> already.
> Four mails, and not a SINGLE concrete explanation what could (or will) go
> wrong.
> You decry that people are creating avoidable problems, yet you fail to
> explain what the problems might be, depriving everybody of informed choice.
> Even if it would end up the same as the one you arrived at, but are you
> arrogantly assuming that anybody arriving at different conclusions must be
> entirely, totally wrong?
>
> And are we now starting to compare me to a boy of four years?
> That's adding insult to injury.
>
> You fail to answer basic questions (which I'm pretty sure are legit), you
> assume I'm an idiot (which I'm pretty sure I'm not), and I rewrote this
> mail approximately four times to tone it down to a marginally polite form
> (or so I hope).
> Sorry guys, but I think I have full rights to be mightily pissed off right
> now.
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Packaging up pre-existing jar and source jar
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 17/01/2013 4:54 PM, Joachim Durchholz wrote:
> You two are really priceless.
>
> I have heard the message, I have requested concrete reasoning, yet all
> I get is a pat on the shoulder and a commandment to shut up and
> believe already.
> Four mails, and not a SINGLE concrete explanation what could (or will)
> go wrong.
> You decry that people are creating avoidable problems, yet you fail to
> explain what the problems might be, depriving everybody of informed
> choice. Even if it would end up the same as the one you arrived at,
> but are you arrogantly assuming that anybody arriving at different
> conclusions must be entirely, totally wrong?
You are not the first person to want to do this.
They end up here with a stream of questions and problems that were
avoidable.
They eventually decide to do things the "Maven way" and start to be
happy about Maven.
I have no idea about what trouble your path will get into since you seem
to want to make up your own build pattern.
If you want a full description of the problems and frustration that I
had before we got the Maven Repo, just search the archives for my name.
>
> And are we now starting to compare me to a boy of four years?
> That's adding insult to injury.
Sorry if I contributed to your sense of being disrespected.
We are only trying to give you benefit of what we have seen and try to
convince you to at least trying to do it the right way once.
If you don't like the "Maven way" after trying it, you are free to use
another build methodology such as Ant.
There is nothing wrong with using Ant if you don't like Maven.
>
> You fail to answer basic questions (which I'm pretty sure are legit),
> you assume I'm an idiot (which I'm pretty sure I'm not), and I rewrote
> this mail approximately four times to tone it down to a marginally
> polite form (or so I hope).
> Sorry guys, but I think I have full rights to be mightily pissed off
> right now.
>
I have my own business to run and I have a lot to do in a day.
I am not under any obligation to provide you anything.
I am just a small developer like you with some Maven experience.
I have been visiting this forum for 4+ years to get help from other
volunteers.
Everyone here tries to give you the best advice possible for free.
If you want professional advice and want someone to take the time to
explain why your path is going to get you into trouble, you can get a
contract from one of the Maven guys that provide consulting service.
You got the free advice from some of the best Maven guys around.
If you want to use Maven at all and get any help at all, you are very
wise to keep editing your e-mails carefully.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Packaging up pre-existing jar and source jar
Posted by Graham Leggett <mi...@sharp.fm>.
On 17 Jan 2013, at 21:54, Joachim Durchholz <jo...@durchholz.org> wrote:
> You two are really priceless.
>
> I have heard the message, I have requested concrete reasoning, yet all I get is a pat on the shoulder and a commandment to shut up and believe already.
> Four mails, and not a SINGLE concrete explanation what could (or will) go wrong.
Put yourself in the shoes of a brand new developer to your team.
First thing you tell them is "we use Java 7". That's all you tell them. Java 7 is a known entity, they have never seen your system before ever, and yet that developer can bring their full past Java 7 experience to bear on your code, they get on with it, hitting the ground running.
Second thing you tell them is "we use Maven 3". That's all you tell them. Maven 3 is a known entity, they have never seen your system before ever, but they already know how to build your code: mvn install, mvn release:prepare release:perform. They get on with it, hitting the ground running.
Sometimes the developer hears "we build it with build.xml". Um, what? The developer can leverage nothing. Is your build.xml the same as past build.xml's? Nope. Can they type "build.xml" into google and get help? Nope. They have to waste time reading documentation that is only relevant to your site. Which no one bothered to write. So they reverse engineered build.xml to figure out how it works, just like they had to reverse engineer the last build.xml.
Compiling code is a solved problem. You don't hire a developer and tell them you've made your own custom version of Java.
Building code is a solved problem. You don't hire a developer and tell them you've made your own custom version of your build script.
"But I might want to do X" says the naive developer. No, you don't want to do X, I the investor want you to use the standards already laid down by maven, I don't want you reinventing the wheel, and I don't want you to waste my money trying to re-solve solved problems.
Regards,
Graham
--
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Packaging up pre-existing jar and source jar
Posted by Baptiste MATHUS <ml...@batmat.net>.
Le 17 janv. 2013 22:55, "Joachim Durchholz" <jo...@durchholz.org> a écrit :
>
> You two are really priceless.
>
> I have heard the message, I have requested concrete reasoning, yet all I
get is a pat on the shoulder and a commandment to shut up and believe
already.
> Four mails, and not a SINGLE concrete explanation what could (or will) go
wrong.
Well I guess others are maybe reluctant or just have no time to write
something that's already been answered tens of times.
Going through the list archive with something like "repository manager
blabla" and you ll find many answers.
Cheers
Re: Packaging up pre-existing jar and source jar
Posted by Joachim Durchholz <jo...@durchholz.org>.
You two are really priceless.
I have heard the message, I have requested concrete reasoning, yet all I
get is a pat on the shoulder and a commandment to shut up and believe
already.
Four mails, and not a SINGLE concrete explanation what could (or will)
go wrong.
You decry that people are creating avoidable problems, yet you fail to
explain what the problems might be, depriving everybody of informed
choice. Even if it would end up the same as the one you arrived at, but
are you arrogantly assuming that anybody arriving at different
conclusions must be entirely, totally wrong?
And are we now starting to compare me to a boy of four years?
That's adding insult to injury.
You fail to answer basic questions (which I'm pretty sure are legit),
you assume I'm an idiot (which I'm pretty sure I'm not), and I rewrote
this mail approximately four times to tone it down to a marginally
polite form (or so I hope).
Sorry guys, but I think I have full rights to be mightily pissed off
right now.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Packaging up pre-existing jar and source jar
Posted by Stephen Connolly <st...@gmail.com>.
On 17 January 2013 16:35, Ron Wheeler <rw...@artifact-software.com>wrote:
> On 17/01/2013 11:16 AM, Joachim Durchholz wrote:
>
>> Am 17.01.2013 10:08, schrieb Jörg Schaible:
>>
>>> Ah, I had seen that but thought it was inapplicable because I want to
>>>> deploy just to the local repo. But I guess I can tell it to deploy to
>>>> ${settings.localRepository}, right?
>>>>
>>>
>>> What Anders tells you in a lot of word is: Your last sentence does not
>>> make
>>> sense in Maven terminology. The local repository is on your home
>>> directory
>>> and you will *never* deploy something there, "deploy" means always a
>>> remote
>>> repository.
>>>
>>
>> Ah okay. Then maven-deploy-plugin isn't for me it seems.
>>
>> > See docs for similar goals:
>>
>>>
>>> - install:install-file - will add artifact manually to local repo
>>>
>>
>> Ah nice, good enough for now.
>> Yeah I know Anders will facepalm over this, but it can't be helped - I'm
>> still not seing the use case for a repo server, I'm using maven as a
>> download and build tool for now, deployment (to repositories as well as to
>> the public) is months away and I have a gazillion of other issues to work
>> on.
>>
> Repositories are not public in most cases. It is a way to work with Maven
> internally.
> You are going to generate a gazillion of Maven issues that are completely
> avoidable.
I do love to reminisce about my early days of Maven usage when I through I
didn't need a repository manager...
Such reminiscence is best conducted while listening to
https://www.youtube.com/watch?v=AsG1_3OTzyY
-Stephen
>
>
>> And yes, a jar that contains only the sources (must have proper layout
>>> though) can be installed as an artifact with classifier "sources" (that's
>>> what the maven-sources-plugin does) and you can do this manually with
>>> one of
>>> the goals above - depending on your target.
>>>
>>
>> I'll just add an execution with install-file in the pom of the dependency
>> project I think.
>> I think this requires the dependency install to be manually run before
>> the main project install. This is counter to Maven's "make the process
>> fully automatic" idea, but I don't need that - the dependency needs manual
>> intervention to upgrade, so it's no issue to finish the upgrade procedure
>> with a mvn install, before returning to the regular scheduled main project.
>>
>> Would this work?
>>
>> With the itsy bitsy teeny weeny exception that it won't scale beyond a
>> single co-contributor or too many dependencies handled in that way. I know
>> I'll have to tackle the repository server when that happens.
>> Are there other signs of trouble I should be watching out for?
>>
>> Thanks to everybody for their time and patience!
>>
>> Regards,
>> Jo
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Packaging up pre-existing jar and source jar
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 17/01/2013 11:16 AM, Joachim Durchholz wrote:
> Am 17.01.2013 10:08, schrieb Jörg Schaible:
>>> Ah, I had seen that but thought it was inapplicable because I want to
>>> deploy just to the local repo. But I guess I can tell it to deploy to
>>> ${settings.localRepository}, right?
>>
>> What Anders tells you in a lot of word is: Your last sentence does
>> not make
>> sense in Maven terminology. The local repository is on your home
>> directory
>> and you will *never* deploy something there, "deploy" means always a
>> remote
>> repository.
>
> Ah okay. Then maven-deploy-plugin isn't for me it seems.
>
> > See docs for similar goals:
>>
>> - install:install-file - will add artifact manually to local repo
>
> Ah nice, good enough for now.
> Yeah I know Anders will facepalm over this, but it can't be helped -
> I'm still not seing the use case for a repo server, I'm using maven as
> a download and build tool for now, deployment (to repositories as well
> as to the public) is months away and I have a gazillion of other
> issues to work on.
Repositories are not public in most cases. It is a way to work with
Maven internally.
You are going to generate a gazillion of Maven issues that are
completely avoidable.
>
>> And yes, a jar that contains only the sources (must have proper layout
>> though) can be installed as an artifact with classifier "sources"
>> (that's
>> what the maven-sources-plugin does) and you can do this manually with
>> one of
>> the goals above - depending on your target.
>
> I'll just add an execution with install-file in the pom of the
> dependency project I think.
> I think this requires the dependency install to be manually run before
> the main project install. This is counter to Maven's "make the process
> fully automatic" idea, but I don't need that - the dependency needs
> manual intervention to upgrade, so it's no issue to finish the upgrade
> procedure with a mvn install, before returning to the regular
> scheduled main project.
>
> Would this work?
>
> With the itsy bitsy teeny weeny exception that it won't scale beyond a
> single co-contributor or too many dependencies handled in that way. I
> know I'll have to tackle the repository server when that happens.
> Are there other signs of trouble I should be watching out for?
>
> Thanks to everybody for their time and patience!
>
> Regards,
> Jo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Packaging up pre-existing jar and source jar
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 17.01.2013 10:08, schrieb Jörg Schaible:
>> Ah, I had seen that but thought it was inapplicable because I want to
>> deploy just to the local repo. But I guess I can tell it to deploy to
>> ${settings.localRepository}, right?
>
> What Anders tells you in a lot of word is: Your last sentence does not make
> sense in Maven terminology. The local repository is on your home directory
> and you will *never* deploy something there, "deploy" means always a remote
> repository.
Ah okay. Then maven-deploy-plugin isn't for me it seems.
> See docs for similar goals:
>
> - install:install-file - will add artifact manually to local repo
Ah nice, good enough for now.
Yeah I know Anders will facepalm over this, but it can't be helped - I'm
still not seing the use case for a repo server, I'm using maven as a
download and build tool for now, deployment (to repositories as well as
to the public) is months away and I have a gazillion of other issues to
work on.
> And yes, a jar that contains only the sources (must have proper layout
> though) can be installed as an artifact with classifier "sources" (that's
> what the maven-sources-plugin does) and you can do this manually with one of
> the goals above - depending on your target.
I'll just add an execution with install-file in the pom of the
dependency project I think.
I think this requires the dependency install to be manually run before
the main project install. This is counter to Maven's "make the process
fully automatic" idea, but I don't need that - the dependency needs
manual intervention to upgrade, so it's no issue to finish the upgrade
procedure with a mvn install, before returning to the regular scheduled
main project.
Would this work?
With the itsy bitsy teeny weeny exception that it won't scale beyond a
single co-contributor or too many dependencies handled in that way. I
know I'll have to tackle the repository server when that happens.
Are there other signs of trouble I should be watching out for?
Thanks to everybody for their time and patience!
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Packaging up pre-existing jar and source jar
Posted by Jörg Schaible <Jo...@scalaris.com>.
Hi Joachim
Joachim Durchholz wrote:
> Am 16.01.2013 13:08, schrieb Francesco Mari:
>> Take a look at the deploy-file mojo [0]. There is a brief explanation
>> of it in the "Usage" page of the deploy plugin [1].
>>
>> [0]
>> [http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-
mojo.html
>> [1] http://maven.apache.org/plugins/maven-deploy-plugin/usage.html
>
> Ah, I had seen that but thought it was inapplicable because I want to
> deploy just to the local repo. But I guess I can tell it to deploy to
> ${settings.localRepository}, right?
What Anders tells you in a lot of word is: Your last sentence does not make
sense in Maven terminology. The local repository is on your home directory
and you will *never* deploy something there, "deploy" means always a remote
repository. See docs for similar goals:
- install:install-file - will add artifact manually to local repo
- deploy:deploy-file - will add artifact manually to remote repo
And yes, a jar that contains only the sources (must have proper layout
though) can be installed as an artifact with classifier "sources" (that's
what the maven-sources-plugin does) and you can do this manually with one of
the goals above - depending on your target.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Packaging up pre-existing jar and source jar
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 16.01.2013 13:08, schrieb Francesco Mari:
> Take a look at the deploy-file mojo [0]. There is a brief explanation
> of it in the "Usage" page of the deploy plugin [1].
>
> [0] http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html
> [1] http://maven.apache.org/plugins/maven-deploy-plugin/usage.html
Ah, I had seen that but thought it was inapplicable because I want to
deploy just to the local repo. But I guess I can tell it to deploy to
${settings.localRepository}, right?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Packaging up pre-existing jar and source jar
Posted by Anders Hammar <an...@hammar.net>.
Or, if you have a repo manager it probably also provides a GUI to do this.
/Anders
On Wed, Jan 16, 2013 at 1:08 PM, Francesco Mari <ma...@gmail.com>wrote:
> Take a look at the deploy-file mojo [0]. There is a brief explanation
> of it in the "Usage" page of the deploy plugin [1].
>
> [0]
> http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html
> [1] http://maven.apache.org/plugins/maven-deploy-plugin/usage.html
>
> 2013/1/16 Anders Hammar <an...@hammar.net>:
> > You already have the artifacts. You just need to create the pom (with the
> > correct metadata) and deploy the pom, lib.jar and lib-sources.jar to your
> > maven repository. There are different ways of doing this, depending on
> your
> > environment.
> >
> > /Anders
> >
> >
> > On Wed, Jan 16, 2013 at 11:08 AM, Joachim Durchholz <jo@durchholz.org
> >wrote:
> >
> >> Hi all,
> >>
> >> sorry if this is a FAQ but I didn't find instructions on maven.org for
> >> this.
> >>
> >> I'm provided with a lib.jar and lib-sources.jar.
> >> How do I make Maven generate an artifact from these, without recompiling
> >> the sources? (lib-sources.jar needs to be available for debugging when
> >> importing the artifact as a dependency in other Maven projects.)
> >>
> >> Any feedback appreciated!
> >> Jo
> >>
> >>
> ------------------------------**------------------------------**---------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
> users-unsubscribe@maven.apache.org>
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Packaging up pre-existing jar and source jar
Posted by Francesco Mari <ma...@gmail.com>.
Take a look at the deploy-file mojo [0]. There is a brief explanation
of it in the "Usage" page of the deploy plugin [1].
[0] http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html
[1] http://maven.apache.org/plugins/maven-deploy-plugin/usage.html
2013/1/16 Anders Hammar <an...@hammar.net>:
> You already have the artifacts. You just need to create the pom (with the
> correct metadata) and deploy the pom, lib.jar and lib-sources.jar to your
> maven repository. There are different ways of doing this, depending on your
> environment.
>
> /Anders
>
>
> On Wed, Jan 16, 2013 at 11:08 AM, Joachim Durchholz <jo...@durchholz.org>wrote:
>
>> Hi all,
>>
>> sorry if this is a FAQ but I didn't find instructions on maven.org for
>> this.
>>
>> I'm provided with a lib.jar and lib-sources.jar.
>> How do I make Maven generate an artifact from these, without recompiling
>> the sources? (lib-sources.jar needs to be available for debugging when
>> importing the artifact as a dependency in other Maven projects.)
>>
>> Any feedback appreciated!
>> Jo
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Packaging up pre-existing jar and source jar
Posted by Anders Hammar <an...@hammar.net>.
You already have the artifacts. You just need to create the pom (with the
correct metadata) and deploy the pom, lib.jar and lib-sources.jar to your
maven repository. There are different ways of doing this, depending on your
environment.
/Anders
On Wed, Jan 16, 2013 at 11:08 AM, Joachim Durchholz <jo...@durchholz.org>wrote:
> Hi all,
>
> sorry if this is a FAQ but I didn't find instructions on maven.org for
> this.
>
> I'm provided with a lib.jar and lib-sources.jar.
> How do I make Maven generate an artifact from these, without recompiling
> the sources? (lib-sources.jar needs to be available for debugging when
> importing the artifact as a dependency in other Maven projects.)
>
> Any feedback appreciated!
> Jo
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Packaging up pre-existing jar and source jar
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 16.01.2013 22:26, schrieb Ron Wheeler:
> If you want them both in one artifact:
> Use a "pom" packaging type with the dependencies lib.jar and
> lib-sources.jar.
> Use the Assembly plugin to make a jar with both jars inside.
Hmm... does that mean that a Maven project can install at most a single
jar per classifier?
I'd find that surprising enough to be worthy of being documented in the
30-minute introduction.
> If you want them as individual artifacts:
> If you are running Nexus as your Maven Repository, I think that you can
> just upload each jar and Nexus will generate a minimal POM with the
> specified GAV that can be downloaded by Maven just like any jar that you
> built from sources.
No Nexus here, just a local repository that's deployed to from the
command line via mvn deploy.
Shared data is exchanged via Bitbucket, so we haven't seen a use case
for Nexus yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Packaging up pre-existing jar and source jar
Posted by Ron Wheeler <rw...@artifact-software.com>.
If you want them both in one artifact:
Use a "pom" packaging type with the dependencies lib.jar and
lib-sources.jar.
Use the Assembly plugin to make a jar with both jars inside.
If you want them as individual artifacts:
If you are running Nexus as your Maven Repository, I think that you can
just upload each jar and Nexus will generate a minimal POM with the
specified GAV that can be downloaded by Maven just like any jar that you
built from sources.
Ron
On 16/01/2013 5:08 AM, Joachim Durchholz wrote:
> Hi all,
>
> sorry if this is a FAQ but I didn't find instructions on maven.org for
> this.
>
> I'm provided with a lib.jar and lib-sources.jar.
> How do I make Maven generate an artifact from these, without
> recompiling the sources? (lib-sources.jar needs to be available for
> debugging when importing the artifact as a dependency in other Maven
> projects.)
>
> Any feedback appreciated!
> Jo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org