You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Eric Kolotyluk <er...@gmail.com> on 2011/05/02 19:16:04 UTC
collecting dependent artifacts
I'm still new to Maven, so be patient...
After you have your artifact built, say foo.jar you have all the
artifacts it depends on like bar.jar which are all scattered through
~/.m2/...
If you want to write an installer for foo.jar, how do you collect all
the dependencies like bar.jar together to distribute with your
application installer?
In a similar fashion, when you do a release, don't you want to check all
your dependent artifacts like bar.jar into source control so you can
rebuild that release again without worrying that that version of bar.jar
has vanished from all repositories on earth?
Cheers, Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: collecting dependent artifacts
Posted by Eric Kolotyluk <er...@gmail.com>.
Thanks for point out the problem with the Kodak-Intersystem repository,
I was too focused on intersystem-common to notice.
I did a maven install on Kodak-Intersystem, the top level POM and now
the uber-jar has both the service and common classes included.
Thanks for the advice about the repository manager. I'll add that to my
list of things to do to become fully mavenized.
I've gotten some great advice on this mailing list. Thanks so much :-)
Cheers, Eric
On 2011-05-03 6:39 PM, Barrie Treloar wrote:
> On Wed, May 4, 2011 at 10:33 AM, Eric Kolotyluk
> <er...@gmail.com> wrote:
>> Well, still no luck.
>>
>> I added my common-module as a dependency in the service-module, but when I
>> build the package I get
>>
>> [ERROR] Failed to execute goal on project intersystem-service: Could not
>> resolve dependencies for project
>> com.kodak.intersystem:intersystem-service:jar:0.0.1-SNAPSHOT: Failed to
>> collect dependencies for
>> [de.uni_leipzig:wortschatz_webservice_client_sachgebiet:jar:1.0 (compile),
>> jivesoftware:whack-dist:jar:1.0 (compile),
>> jivesoftware:smackx-jingle:jar:3.1.0 (compile),
>> com.kodak.intersystem:intersystem-common:jar:0.0.1-SNAPSHOT (runtime),
>> info.collide:sqlspaces-client:jar:3.9.1 (compile),
>> org.hibernate:hibernate-core:jar:3.6.1.Final (compile),
>> org.eclipse.jetty:example-jetty-embedded:jar:8.0.0.M2 (compile),
>> org.jboss.logging:jboss-logging-log4j:jar:2.1.2.GA (compile),
>> org.slf4j:slf4j-log4j12:jar:1.6.1 (compile),
>> net.jcip:jcip-annotations:jar:1.0 (compile),
>> postgresql:postgresql:jar:9.0-801.jdbc4 (compile),
>> org.modeshape:modeshape-sequencer-jbpm-jpdl:jar:jar-with-dependencies:2.2.0.Final
>> (compile), org.javassist:javassist:jar:3.14.0-GA (compile),
>> com.sun.org.apache:jaxp-ri:jar:1.4 (compile),
>> com.miglayout:miglayout:jar:3.7.4 (compile), com.jidesoft:jide-oss:jar:2.4.8
>> (compile)]: Failed to read artifact descriptor for
>> com.kodak.intersystem:intersystem-common:jar:0.0.1-SNAPSHOT: Failure to find
>> com.kodak.intersystem:Kodak-Intersystem:pom:0.0.1-SNAPSHOT in
>> https://repository.jboss.org/nexus/content/repositories/releases/ was cached
>> in the local repository, resolution will not be reattempted until the update
>> interval of org.jboss.repository has elapsed or updates are forced -> [Help
>> 1]
>>
> Your problem is here:
> Failed to read artifact descriptor for
> com.kodak.intersystem:intersystem-common:jar:0.0.1-SNAPSHOT: Failure
> to find com.kodak.intersystem:Kodak-Intersystem:pom:0.0.1-SNAPSHOT
>
> Are you *sure* that you ran mvn install so that this artifact is in
> your ~/.m2 repository?
>
> p.s. You need to consider installing a repository manager on your local network.
> This will benefit you because there will be one repository that you
> contact (your internal repo manager) instead of all the repositories
> defined in your pom.xml.
>
> This will speed up your build!!!
> If you have N repositories defined then maven will check N
> repositories for artifacts that do not exist, e.g. *All* your internal
> artifacts like artifact descriptor for
> com.kodak.intersystem:intersystem-common:jar:0.0.1-SNAPSHOT. Each
> query takes a few seconds to do.
> Multiply N repos * A artifacts and you get serious degradation of build time.
>
> There are bunch of other reasons as well, like saving network
> bandwidth, and increased downloading speeds.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 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: collecting dependent artifacts
Posted by Barrie Treloar <ba...@gmail.com>.
On Wed, May 4, 2011 at 10:33 AM, Eric Kolotyluk
<er...@gmail.com> wrote:
> Well, still no luck.
>
> I added my common-module as a dependency in the service-module, but when I
> build the package I get
>
> [ERROR] Failed to execute goal on project intersystem-service: Could not
> resolve dependencies for project
> com.kodak.intersystem:intersystem-service:jar:0.0.1-SNAPSHOT: Failed to
> collect dependencies for
> [de.uni_leipzig:wortschatz_webservice_client_sachgebiet:jar:1.0 (compile),
> jivesoftware:whack-dist:jar:1.0 (compile),
> jivesoftware:smackx-jingle:jar:3.1.0 (compile),
> com.kodak.intersystem:intersystem-common:jar:0.0.1-SNAPSHOT (runtime),
> info.collide:sqlspaces-client:jar:3.9.1 (compile),
> org.hibernate:hibernate-core:jar:3.6.1.Final (compile),
> org.eclipse.jetty:example-jetty-embedded:jar:8.0.0.M2 (compile),
> org.jboss.logging:jboss-logging-log4j:jar:2.1.2.GA (compile),
> org.slf4j:slf4j-log4j12:jar:1.6.1 (compile),
> net.jcip:jcip-annotations:jar:1.0 (compile),
> postgresql:postgresql:jar:9.0-801.jdbc4 (compile),
> org.modeshape:modeshape-sequencer-jbpm-jpdl:jar:jar-with-dependencies:2.2.0.Final
> (compile), org.javassist:javassist:jar:3.14.0-GA (compile),
> com.sun.org.apache:jaxp-ri:jar:1.4 (compile),
> com.miglayout:miglayout:jar:3.7.4 (compile), com.jidesoft:jide-oss:jar:2.4.8
> (compile)]: Failed to read artifact descriptor for
> com.kodak.intersystem:intersystem-common:jar:0.0.1-SNAPSHOT: Failure to find
> com.kodak.intersystem:Kodak-Intersystem:pom:0.0.1-SNAPSHOT in
> https://repository.jboss.org/nexus/content/repositories/releases/ was cached
> in the local repository, resolution will not be reattempted until the update
> interval of org.jboss.repository has elapsed or updates are forced -> [Help
> 1]
>
Your problem is here:
Failed to read artifact descriptor for
com.kodak.intersystem:intersystem-common:jar:0.0.1-SNAPSHOT: Failure
to find com.kodak.intersystem:Kodak-Intersystem:pom:0.0.1-SNAPSHOT
Are you *sure* that you ran mvn install so that this artifact is in
your ~/.m2 repository?
p.s. You need to consider installing a repository manager on your local network.
This will benefit you because there will be one repository that you
contact (your internal repo manager) instead of all the repositories
defined in your pom.xml.
This will speed up your build!!!
If you have N repositories defined then maven will check N
repositories for artifacts that do not exist, e.g. *All* your internal
artifacts like artifact descriptor for
com.kodak.intersystem:intersystem-common:jar:0.0.1-SNAPSHOT. Each
query takes a few seconds to do.
Multiply N repos * A artifacts and you get serious degradation of build time.
There are bunch of other reasons as well, like saving network
bandwidth, and increased downloading speeds.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: collecting dependent artifacts
Posted by Eric Kolotyluk <er...@gmail.com>.
Well, still no luck.
I added my common-module as a dependency in the service-module, but when
I build the package I get
[ERROR] Failed to execute goal on project intersystem-service: Could not
resolve dependencies for project
com.kodak.intersystem:intersystem-service:jar:0.0.1-SNAPSHOT: Failed to
collect dependencies for
[de.uni_leipzig:wortschatz_webservice_client_sachgebiet:jar:1.0
(compile), jivesoftware:whack-dist:jar:1.0 (compile),
jivesoftware:smackx-jingle:jar:3.1.0 (compile),
com.kodak.intersystem:intersystem-common:jar:0.0.1-SNAPSHOT (runtime),
info.collide:sqlspaces-client:jar:3.9.1 (compile),
org.hibernate:hibernate-core:jar:3.6.1.Final (compile),
org.eclipse.jetty:example-jetty-embedded:jar:8.0.0.M2 (compile),
org.jboss.logging:jboss-logging-log4j:jar:2.1.2.GA (compile),
org.slf4j:slf4j-log4j12:jar:1.6.1 (compile),
net.jcip:jcip-annotations:jar:1.0 (compile),
postgresql:postgresql:jar:9.0-801.jdbc4 (compile),
org.modeshape:modeshape-sequencer-jbpm-jpdl:jar:jar-with-dependencies:2.2.0.Final
(compile), org.javassist:javassist:jar:3.14.0-GA (compile),
com.sun.org.apache:jaxp-ri:jar:1.4 (compile),
com.miglayout:miglayout:jar:3.7.4 (compile),
com.jidesoft:jide-oss:jar:2.4.8 (compile)]: Failed to read artifact
descriptor for
com.kodak.intersystem:intersystem-common:jar:0.0.1-SNAPSHOT: Failure to
find com.kodak.intersystem:Kodak-Intersystem:pom:0.0.1-SNAPSHOT in
https://repository.jboss.org/nexus/content/repositories/releases/ was
cached in the local repository, resolution will not be reattempted until
the update interval of org.jboss.repository has elapsed or updates are
forced -> [Help 1]
If I remove the dependency to the common-module then the build works,
but does not include the class files from the common-module in the uber-jar.
Does anyone have any other ideas of what to try?
Cheers, Eric
On 2011-05-03 12:51 PM, Eric Kolotyluk wrote:
> More below...
>
> On 2011-05-03 9:14 AM, Wayne Fay wrote:
>>> Anyway, shade is doing mostly what I want, except I cannot seem to
>>> configure
>>> it to include classes from a sibling module in Maven.
>> If you have it set up as a dependency, it should "just work."
> Except that then Maven complains it cannot find the repository that it
> is in.
>>> My structure is something like
>>>
>>> parent/pom.xml
>>> service-module/pom.xml
>>> common-module/pom.xml
>>> client-module/pom.xml
>> It is not clear to me if your parent directory is a sibling of
>> service-module and the others and thus all the pom.xml files are on
>> the same "level." If so, this is not how I would generally expect it
>> to be set up. Instead, you would have a parent directory and then
>> inside of that you would have the various modules.
>>
> So, I had to flatten my Eclipse projects because I am using IBM
> Rational Team Concert for SCM and it does not yet support nested
> projects the way Maven likes them. Consequently I followed the Maven
> documentation to "flatten" my projects on the file system. For the
> most part Maven seems happy with that - but maybe not in this case
>
> To be clear - parent/pom.xml is a POM project, and
> service-module/pom.xml, common-module/pom.xml and
> client-module/pom.xml are all modules of parent/pom.xml as well as
> being JAR projects. The directories parent, service-module,
> common-module and client-module are all siblings because they were
> flattened.
>>> I want the service-module.jar to contain the classes from
>>> common-module, but
>>> can't figure out how. I tried putting the coordinates of
>>> common-module into
>>> my service-module/pom.xml, but Maven complains because it cannot find
>>> common-module in any repository.
>> First, you are probably not running from the parent. This should work
>> if you are running from the parent and have your multimodule project
>> set up properly.
> When I tried running from the parent Maven threw a
> NullPointerException. I found an article somewhere where other people
> had this same problem. There was some advice there, but I have not got
> back to researching it further. Maybe I just need to configure the
> parent POM properly?
>> Second, you can get around this by running "mvn install" in
>> common-module, and then try building the shaded jar in service-module
>> again. It will use the jar contents that are in your local repo cache,
>> not from the sibling directory.
> OK, that makes sense - I will try that after my system backup finishes.
>> Hopefully you are using snapshot versions while sorting out these
>> issues. Versions are important and it is typical for someone new to
>> Maven to not fully appreciate that once versioned (with anything
>> except a Snapshot version), an artifact must never change. Versioned
>> artifacts are immutable in Maven.
> Yes, I still have not moved off of my first snapshot - I'm really a
> Maven newbie :-)
>
> "Versioned artifacts are immutable in Maven." That sounds serious? Can
> I take that to mean that you typically version a project after it has
> been released because you are never going to change it again? If you
> changed it then it would be another version wouldn't it?
>
> As it is, I don't even know how to change the version yet.
>> Wayne
> Thanks for all the advice.
>
> Cheers, Eric
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: 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: collecting dependent artifacts
Posted by Eric Kolotyluk <er...@gmail.com>.
Below...
On 2011-05-03 9:28 PM, Barrie Treloar wrote:
> On Wed, May 4, 2011 at 1:20 PM, Eric Kolotyluk<er...@gmail.com> wrote:
>>> I am not a fan of "flat" multimodule projects and don't use them. I
>>> know that things generally work OK with them but I would not be
>>> surprised if you run into issues.
>>>
>> I'm not a fan either, but it was the only way to get things to work with
>> Jazz RTC. I know IBM plan to fix the problems in RTC with nested Eclipse
>> projects as they have a lot of customers who are using Jazz and Maven
>> together.
> Someone else had a similar problem with another IBM product, can't
> recall the details.
>
> One option is to just ditch the IDE embedded version control and go
> back to the command line/GUI interface of the host version control.
> That way you can have your hierarchical project structure.
OMG - you speak heresy!
Just kidding ;-)
Seriously, I learned to program using optical mark cards - I've earned
the privilege to be spoiled by a sweet GUI like Eclipse IDE, and the
Sonatype m2e is working fine for me.
> Another thing to remember is that eclipse also has problems with
> hierarchical projects.
> And the IBM stuff is based on eclipse. I know this process works with
> Eclipse 3.2.2 +
Yes, the Jazz stuff is all based one Eclipse technology, which is one
reason it works so well with the Eclipse IDE. I've had a long love/hate
relationship with IBM over the years, but they've really earned my
respect with Eclipse and now Jazz.
Right now I have an almost unimaginably wonderful development
environment and writing code is more fun than it has ever been. I'm
especially pleased I took the time to start using Maven.
> The work around is to:
> * checkout the root project (which contains all sub-projects)
> * run mvn eclipse:eclipse
> * refresh your eclipse workspace
> * use the NAVIGATOR view and delete the .project file from your root project.
> * File Import> and select your root project
> * You should see your modules ready for import, if not then you forget
> to delete the .project file
>
> You will occasionally get out of sync between workspaces, so refresh
> them after checkin/checkout and maven command line invocations.
>
> You should be able to run Team> Sync at any of the projects, but it
> will work if you only do this from the root project.
Actually, my Maven/Eclipse environment is all working well now :-)
Cheers, Eric
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 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: collecting dependent artifacts
Posted by Barrie Treloar <ba...@gmail.com>.
On Wed, May 4, 2011 at 1:20 PM, Eric Kolotyluk <er...@gmail.com> wrote:
>> I am not a fan of "flat" multimodule projects and don't use them. I
>> know that things generally work OK with them but I would not be
>> surprised if you run into issues.
>>
> I'm not a fan either, but it was the only way to get things to work with
> Jazz RTC. I know IBM plan to fix the problems in RTC with nested Eclipse
> projects as they have a lot of customers who are using Jazz and Maven
> together.
Someone else had a similar problem with another IBM product, can't
recall the details.
One option is to just ditch the IDE embedded version control and go
back to the command line/GUI interface of the host version control.
That way you can have your hierarchical project structure.
Another thing to remember is that eclipse also has problems with
hierarchical projects.
And the IBM stuff is based on eclipse. I know this process works with
Eclipse 3.2.2 +
The work around is to:
* checkout the root project (which contains all sub-projects)
* run mvn eclipse:eclipse
* refresh your eclipse workspace
* use the NAVIGATOR view and delete the .project file from your root project.
* File Import > and select your root project
* You should see your modules ready for import, if not then you forget
to delete the .project file
You will occasionally get out of sync between workspaces, so refresh
them after checkin/checkout and maven command line invocations.
You should be able to run Team > Sync at any of the projects, but it
will work if you only do this from the root project.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: collecting dependent artifacts
Posted by Eric Kolotyluk <er...@gmail.com>.
OK, I solved my problem as you'll see from my previous post.
More comments below...
On 2011-05-03 7:12 PM, Wayne Fay wrote:
>> Except that then Maven complains it cannot find the repository that it is
>> in.
> If you haven't run "mvn install" from the common-module, then the jar
> does not exist (as far as Maven is concerned) when you build in the
> service-module.
>
I had to do a maven install on the top level POM as well, that was the
last thing tripping me up.
>> So, I had to flatten my Eclipse projects because I am using IBM Rational
>> Team Concert for SCM and it does not yet support nested projects the way
> I am not a fan of "flat" multimodule projects and don't use them. I
> know that things generally work OK with them but I would not be
> surprised if you run into issues.
>
I'm not a fan either, but it was the only way to get things to work with
Jazz RTC. I know IBM plan to fix the problems in RTC with nested Eclipse
projects as they have a lot of customers who are using Jazz and Maven
together.
By the way, I'm growing more and more fond of the Jazz development
environment (as I am Maven). I recommend people check out the free
community version of RTC (for up to 10 users). I think IBM give open
source organizations a special deal on running with more than 10 licenses.
>> When I tried running from the parent Maven threw a NullPointerException. I
>> found an article somewhere where other people had this same problem. There
>> was some advice there, but I have not got back to researching it further.
>> Maybe I just need to configure the parent POM properly?
> This is a problem you MUST RESOLVE first and foremost. None of the
> rest of this will work until you get this fixed. If you can't build
> from the parent, then the reactor cannot find the common-module
> artifact to use when it is building service-module. Thus, you will get
> the problems you keep complaining about. Fix this first!
>
As I mentioned, I have solved this problem now.
>> OK, that makes sense - I will try that after my system backup finishes.
> Did you run "mvn install" or not?
>
After my backup completed I found that doing a "mvn install" on the top
level POM solved the problem.
>> "Versioned artifacts are immutable in Maven." That sounds serious? Can I
>> take that to mean that you typically version a project after it has been
>> released because you are never going to change it again? If you changed it
>> then it would be another version wouldn't it?
> Yes, that's exactly the point. A versioned artifact can never change.
> If you have changes to make to an artifact, they must be made in a new
> version of that artifact. Never fall into the trap of just making some
> tweaks to a jar file and leaving it with the same version.
>
That totally makes sense.
>> As it is, I don't even know how to change the version yet.
> The release plugin can help when you get to that point. But I don't
> know how well it handles flat multimodule projects like yours.
>
> Wayne
Thanks again for all the advice :-)
Cheers, Eric
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 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: collecting dependent artifacts
Posted by Wayne Fay <wa...@gmail.com>.
> Except that then Maven complains it cannot find the repository that it is
> in.
If you haven't run "mvn install" from the common-module, then the jar
does not exist (as far as Maven is concerned) when you build in the
service-module.
> So, I had to flatten my Eclipse projects because I am using IBM Rational
> Team Concert for SCM and it does not yet support nested projects the way
I am not a fan of "flat" multimodule projects and don't use them. I
know that things generally work OK with them but I would not be
surprised if you run into issues.
> When I tried running from the parent Maven threw a NullPointerException. I
> found an article somewhere where other people had this same problem. There
> was some advice there, but I have not got back to researching it further.
> Maybe I just need to configure the parent POM properly?
This is a problem you MUST RESOLVE first and foremost. None of the
rest of this will work until you get this fixed. If you can't build
from the parent, then the reactor cannot find the common-module
artifact to use when it is building service-module. Thus, you will get
the problems you keep complaining about. Fix this first!
> OK, that makes sense - I will try that after my system backup finishes.
Did you run "mvn install" or not?
> "Versioned artifacts are immutable in Maven." That sounds serious? Can I
> take that to mean that you typically version a project after it has been
> released because you are never going to change it again? If you changed it
> then it would be another version wouldn't it?
Yes, that's exactly the point. A versioned artifact can never change.
If you have changes to make to an artifact, they must be made in a new
version of that artifact. Never fall into the trap of just making some
tweaks to a jar file and leaving it with the same version.
> As it is, I don't even know how to change the version yet.
The release plugin can help when you get to that point. But I don't
know how well it handles flat multimodule projects like yours.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: collecting dependent artifacts
Posted by Eric Kolotyluk <er...@gmail.com>.
More below...
On 2011-05-03 9:14 AM, Wayne Fay wrote:
>> Anyway, shade is doing mostly what I want, except I cannot seem to configure
>> it to include classes from a sibling module in Maven.
> If you have it set up as a dependency, it should "just work."
Except that then Maven complains it cannot find the repository that it
is in.
>> My structure is something like
>>
>> parent/pom.xml
>> service-module/pom.xml
>> common-module/pom.xml
>> client-module/pom.xml
> It is not clear to me if your parent directory is a sibling of
> service-module and the others and thus all the pom.xml files are on
> the same "level." If so, this is not how I would generally expect it
> to be set up. Instead, you would have a parent directory and then
> inside of that you would have the various modules.
>
So, I had to flatten my Eclipse projects because I am using IBM Rational
Team Concert for SCM and it does not yet support nested projects the way
Maven likes them. Consequently I followed the Maven documentation to
"flatten" my projects on the file system. For the most part Maven seems
happy with that - but maybe not in this case
To be clear - parent/pom.xml is a POM project, and
service-module/pom.xml, common-module/pom.xml and client-module/pom.xml
are all modules of parent/pom.xml as well as being JAR projects. The
directories parent, service-module, common-module and client-module are
all siblings because they were flattened.
>> I want the service-module.jar to contain the classes from common-module, but
>> can't figure out how. I tried putting the coordinates of common-module into
>> my service-module/pom.xml, but Maven complains because it cannot find
>> common-module in any repository.
> First, you are probably not running from the parent. This should work
> if you are running from the parent and have your multimodule project
> set up properly.
When I tried running from the parent Maven threw a NullPointerException.
I found an article somewhere where other people had this same problem.
There was some advice there, but I have not got back to researching it
further. Maybe I just need to configure the parent POM properly?
> Second, you can get around this by running "mvn install" in
> common-module, and then try building the shaded jar in service-module
> again. It will use the jar contents that are in your local repo cache,
> not from the sibling directory.
OK, that makes sense - I will try that after my system backup finishes.
> Hopefully you are using snapshot versions while sorting out these
> issues. Versions are important and it is typical for someone new to
> Maven to not fully appreciate that once versioned (with anything
> except a Snapshot version), an artifact must never change. Versioned
> artifacts are immutable in Maven.
Yes, I still have not moved off of my first snapshot - I'm really a
Maven newbie :-)
"Versioned artifacts are immutable in Maven." That sounds serious? Can I
take that to mean that you typically version a project after it has been
released because you are never going to change it again? If you changed
it then it would be another version wouldn't it?
As it is, I don't even know how to change the version yet.
> Wayne
Thanks for all the advice.
Cheers, Eric
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 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: collecting dependent artifacts
Posted by Wayne Fay <wa...@gmail.com>.
> Anyway, shade is doing mostly what I want, except I cannot seem to configure
> it to include classes from a sibling module in Maven.
If you have it set up as a dependency, it should "just work."
> My structure is something like
>
> parent/pom.xml
> service-module/pom.xml
> common-module/pom.xml
> client-module/pom.xml
It is not clear to me if your parent directory is a sibling of
service-module and the others and thus all the pom.xml files are on
the same "level." If so, this is not how I would generally expect it
to be set up. Instead, you would have a parent directory and then
inside of that you would have the various modules.
> I want the service-module.jar to contain the classes from common-module, but
> can't figure out how. I tried putting the coordinates of common-module into
> my service-module/pom.xml, but Maven complains because it cannot find
> common-module in any repository.
First, you are probably not running from the parent. This should work
if you are running from the parent and have your multimodule project
set up properly.
Second, you can get around this by running "mvn install" in
common-module, and then try building the shaded jar in service-module
again. It will use the jar contents that are in your local repo cache,
not from the sibling directory.
Hopefully you are using snapshot versions while sorting out these
issues. Versions are important and it is typical for someone new to
Maven to not fully appreciate that once versioned (with anything
except a Snapshot version), an artifact must never change. Versioned
artifacts are immutable in Maven.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: collecting dependent artifacts
Posted by Eric Kolotyluk <er...@gmail.com>.
Sorry for the newbie comment - but shade is way too cool!
Don't you just love serendipity :-)
How have I lasted so long without discovering maven sooner?
Anyway, shade is doing mostly what I want, except I cannot seem to
configure it to include classes from a sibling module in Maven.
My structure is something like
parent/pom.xml
service-module/pom.xml
common-module/pom.xml
client-module/pom.xml
I want the service-module.jar to contain the classes from common-module,
but can't figure out how. I tried putting the coordinates of
common-module into my service-module/pom.xml, but Maven complains
because it cannot find common-module in any repository.
Right now my service-module/pom.xml looks like
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<id>shade</id>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<artifactSet>
<includes>
<include>*:*</include>
<include>com.kodak.intersystem:intersystem-common</include>
</includes>
</artifactSet>
<transformers>
<transformer
implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<mainClass>com.kodak.intersystem.service.Service</mainClass>
</transformer>
</transformers>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
Eventually I also want client-module.jar to include the common classes too.
Am I I overlooking something obvious? Do I need to configure my parent
POM as an aggregator or something like that?
Cheers, Eric
On 2011-05-02 10:37 AM, Wayne Fay wrote:
>> If you want to write an installer for foo.jar, how do you collect all the
>> dependencies like bar.jar together to distribute with your application
>> installer?
> maven-shade-plugin
> assembly plugin
> appassembler
> etc
>
>> In a similar fashion, when you do a release, don't you want to check all
>> your dependent artifacts like bar.jar into source control so you can rebuild
>> that release again without worrying that that version of bar.jar has
>> vanished from all repositories on earth?
> Nexus
> Archiva
> Artifactory
> etc
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 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: collecting dependent artifacts
Posted by Wayne Fay <wa...@gmail.com>.
> If you want to write an installer for foo.jar, how do you collect all the
> dependencies like bar.jar together to distribute with your application
> installer?
maven-shade-plugin
assembly plugin
appassembler
etc
> In a similar fashion, when you do a release, don't you want to check all
> your dependent artifacts like bar.jar into source control so you can rebuild
> that release again without worrying that that version of bar.jar has
> vanished from all repositories on earth?
Nexus
Archiva
Artifactory
etc
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org