RE: compile tries to bundle up the ear - should it?
I realize I'm bumping a VERY old thread at this point, but I'm completely unsuccessful in tracking down the error here (even with -x and -e on). I'm also seeing the ejbs rebuilding every time (recompiling the source with each pass). How are people making ear files with maven two? Is there some sort of textual layout I could look at? I'm totally losing it. I've read and re-read (and we followed their example very closely) the better builds with maven pdf. -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 07, 2007 4:02 PM To: Maven Users List Subject: Re: compile tries to bundle up the ear - should it? Unfortunately, you've completely exhausted my knowledge of Maven, and I have no response to your queries at this point. Perhaps try debugging Maven while it is executing your EAR compile and you'll find out... You might even uncover a bug. Wayne On 2/7/07, EJ Ciramella <[EMAIL PROTECTED]> wrote: > Ok, my final attempt - why would there be code inside maven that sees an > "packaging" type of ear and decide there's something to do during the > compile lifecycle goal. > > What purpose could this serve? > > -Original Message- > From: Wayne Fay [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 07, 2007 2:49 PM > To: Maven Users List > Subject: Re: compile tries to bundle up the ear - should it? > > I also spend a bit of time working at the top most level... > > I just ran my test again (jars etc named to jarx in local repo) and > had no problems running "mvn clean compile" from my parent directory. > Everything ran straight thru and I got a BUILD SUCCESSFUL at the end. > > One possible thought is that you are basically dirtying your project > files etc with the p4 sync, so Maven thinks it has to recompile all > the files etc in all the modules instead of just the EAR (?). I don't > use SCM with Maven so I don't know much about that, just a thought. > > Wayne > > On 2/7/07, EJ Ciramella <[EMAIL PROTECTED]> wrote: > > No, my question is still unanswered. > > > > I guess what I'm looking for is for those working at the top most > level, > > is it expected that if you want to compile, you must build an ear? > > > > So for anyone who does an install, p4 sync, compile - they can expect > to > > see errors unless they do an additional install? > > > > -Original Message- > > From: Wayne Fay [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, February 07, 2007 2:14 PM > > To: Maven Users List > > Subject: Re: compile tries to bundle up the ear - should it? > > > > EJ, based on this response, does this mean that your issue can be > > considered "fully resolved" or are there other issues? > > > > As for the install question -- yes, I have previously executed "mvn > > install" to copy these artifacts to my local repo. The way I work, I > > am generally only working inside one module at a time, so I can run > > "mvn install" to copy all the other artifacts into my repo, then go > > into the specific module to do my edits etc and run "mvn compile" in > > that artifact alone, which will use the other unedited dependent > > artifacts out of my repo if needed. > > > > As for "why does Maven EAR plugin require all artifacts be available > > during compile" -- I'm pretty sure this just happens automatically > > during validate phase, which happens before compile, so when those > > artifacts are not available to validate, you never get to the compile > > phase. > > > > Wayne > > > > On 2/7/07, EJ Ciramella <[EMAIL PROTECTED]> wrote: > > > Well I figured out why the ejbs continue to recompile - their > package > > > name doesn't reflect their location in main/java. > > > > > > -Original Message- > > > From: EJ Ciramella [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, February 07, 2007 1:38 PM > > > To: Maven Users List > > > Subject: RE: compile tries to bundle up the ear - should it? > > > > > > Wayne - did you do an "install" to get them into your local > > repository? > > > > > > My problem is compile tries to build an ear. In all my years of > > release > > > engineering, compile has meant "turn source code into byte code". > > > Nothing more, nothing less. > > > > > > To have compile build an ear (which needs a war and ejbs) seems > > backward > > > to me. > > > > > > Add to this that a standard compile too
Re: compile tries to bundle up the ear - should it?
Unfortunately, you've completely exhausted my knowledge of Maven, and I have no response to your queries at this point. Perhaps try debugging Maven while it is executing your EAR compile and you'll find out... You might even uncover a bug. Wayne On 2/7/07, EJ Ciramella <[EMAIL PROTECTED]> wrote: Ok, my final attempt - why would there be code inside maven that sees an "packaging" type of ear and decide there's something to do during the compile lifecycle goal. What purpose could this serve? -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 07, 2007 2:49 PM To: Maven Users List Subject: Re: compile tries to bundle up the ear - should it? I also spend a bit of time working at the top most level... I just ran my test again (jars etc named to jarx in local repo) and had no problems running "mvn clean compile" from my parent directory. Everything ran straight thru and I got a BUILD SUCCESSFUL at the end. One possible thought is that you are basically dirtying your project files etc with the p4 sync, so Maven thinks it has to recompile all the files etc in all the modules instead of just the EAR (?). I don't use SCM with Maven so I don't know much about that, just a thought. Wayne On 2/7/07, EJ Ciramella <[EMAIL PROTECTED]> wrote: > No, my question is still unanswered. > > I guess what I'm looking for is for those working at the top most level, > is it expected that if you want to compile, you must build an ear? > > So for anyone who does an install, p4 sync, compile - they can expect to > see errors unless they do an additional install? > > -Original Message- > From: Wayne Fay [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 07, 2007 2:14 PM > To: Maven Users List > Subject: Re: compile tries to bundle up the ear - should it? > > EJ, based on this response, does this mean that your issue can be > considered "fully resolved" or are there other issues? > > As for the install question -- yes, I have previously executed "mvn > install" to copy these artifacts to my local repo. The way I work, I > am generally only working inside one module at a time, so I can run > "mvn install" to copy all the other artifacts into my repo, then go > into the specific module to do my edits etc and run "mvn compile" in > that artifact alone, which will use the other unedited dependent > artifacts out of my repo if needed. > > As for "why does Maven EAR plugin require all artifacts be available > during compile" -- I'm pretty sure this just happens automatically > during validate phase, which happens before compile, so when those > artifacts are not available to validate, you never get to the compile > phase. > > Wayne > > On 2/7/07, EJ Ciramella <[EMAIL PROTECTED]> wrote: > > Well I figured out why the ejbs continue to recompile - their package > > name doesn't reflect their location in main/java. > > > > -Original Message- > > From: EJ Ciramella [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, February 07, 2007 1:38 PM > > To: Maven Users List > > Subject: RE: compile tries to bundle up the ear - should it? > > > > Wayne - did you do an "install" to get them into your local > repository? > > > > My problem is compile tries to build an ear. In all my years of > release > > engineering, compile has meant "turn source code into byte code". > > Nothing more, nothing less. > > > > To have compile build an ear (which needs a war and ejbs) seems > backward > > to me. > > > > Add to this that a standard compile took 58 seconds. Due to the other > > things that have to get run (namely the atg assembler), in order to > get > > everything built and installed into our local repository, we need to > run > > "mvn install" from the top level. This takes 13 - 15 minutes. That > > just isn't going to work. > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: compile tries to bundle up the ear - should it?
Ok, my final attempt - why would there be code inside maven that sees an "packaging" type of ear and decide there's something to do during the compile lifecycle goal. What purpose could this serve? -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 07, 2007 2:49 PM To: Maven Users List Subject: Re: compile tries to bundle up the ear - should it? I also spend a bit of time working at the top most level... I just ran my test again (jars etc named to jarx in local repo) and had no problems running "mvn clean compile" from my parent directory. Everything ran straight thru and I got a BUILD SUCCESSFUL at the end. One possible thought is that you are basically dirtying your project files etc with the p4 sync, so Maven thinks it has to recompile all the files etc in all the modules instead of just the EAR (?). I don't use SCM with Maven so I don't know much about that, just a thought. Wayne On 2/7/07, EJ Ciramella <[EMAIL PROTECTED]> wrote: > No, my question is still unanswered. > > I guess what I'm looking for is for those working at the top most level, > is it expected that if you want to compile, you must build an ear? > > So for anyone who does an install, p4 sync, compile - they can expect to > see errors unless they do an additional install? > > -Original Message- > From: Wayne Fay [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 07, 2007 2:14 PM > To: Maven Users List > Subject: Re: compile tries to bundle up the ear - should it? > > EJ, based on this response, does this mean that your issue can be > considered "fully resolved" or are there other issues? > > As for the install question -- yes, I have previously executed "mvn > install" to copy these artifacts to my local repo. The way I work, I > am generally only working inside one module at a time, so I can run > "mvn install" to copy all the other artifacts into my repo, then go > into the specific module to do my edits etc and run "mvn compile" in > that artifact alone, which will use the other unedited dependent > artifacts out of my repo if needed. > > As for "why does Maven EAR plugin require all artifacts be available > during compile" -- I'm pretty sure this just happens automatically > during validate phase, which happens before compile, so when those > artifacts are not available to validate, you never get to the compile > phase. > > Wayne > > On 2/7/07, EJ Ciramella <[EMAIL PROTECTED]> wrote: > > Well I figured out why the ejbs continue to recompile - their package > > name doesn't reflect their location in main/java. > > > > -Original Message- > > From: EJ Ciramella [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, February 07, 2007 1:38 PM > > To: Maven Users List > > Subject: RE: compile tries to bundle up the ear - should it? > > > > Wayne - did you do an "install" to get them into your local > repository? > > > > My problem is compile tries to build an ear. In all my years of > release > > engineering, compile has meant "turn source code into byte code". > > Nothing more, nothing less. > > > > To have compile build an ear (which needs a war and ejbs) seems > backward > > to me. > > > > Add to this that a standard compile took 58 seconds. Due to the other > > things that have to get run (namely the atg assembler), in order to > get > > everything built and installed into our local repository, we need to > run > > "mvn install" from the top level. This takes 13 - 15 minutes. That > > just isn't going to work. > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compile tries to bundle up the ear - should it?
I also spend a bit of time working at the top most level... I just ran my test again (jars etc named to jarx in local repo) and had no problems running "mvn clean compile" from my parent directory. Everything ran straight thru and I got a BUILD SUCCESSFUL at the end. One possible thought is that you are basically dirtying your project files etc with the p4 sync, so Maven thinks it has to recompile all the files etc in all the modules instead of just the EAR (?). I don't use SCM with Maven so I don't know much about that, just a thought. Wayne On 2/7/07, EJ Ciramella <[EMAIL PROTECTED]> wrote: No, my question is still unanswered. I guess what I'm looking for is for those working at the top most level, is it expected that if you want to compile, you must build an ear? So for anyone who does an install, p4 sync, compile - they can expect to see errors unless they do an additional install? -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 07, 2007 2:14 PM To: Maven Users List Subject: Re: compile tries to bundle up the ear - should it? EJ, based on this response, does this mean that your issue can be considered "fully resolved" or are there other issues? As for the install question -- yes, I have previously executed "mvn install" to copy these artifacts to my local repo. The way I work, I am generally only working inside one module at a time, so I can run "mvn install" to copy all the other artifacts into my repo, then go into the specific module to do my edits etc and run "mvn compile" in that artifact alone, which will use the other unedited dependent artifacts out of my repo if needed. As for "why does Maven EAR plugin require all artifacts be available during compile" -- I'm pretty sure this just happens automatically during validate phase, which happens before compile, so when those artifacts are not available to validate, you never get to the compile phase. Wayne On 2/7/07, EJ Ciramella <[EMAIL PROTECTED]> wrote: > Well I figured out why the ejbs continue to recompile - their package > name doesn't reflect their location in main/java. > > -Original Message- > From: EJ Ciramella [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 07, 2007 1:38 PM > To: Maven Users List > Subject: RE: compile tries to bundle up the ear - should it? > > Wayne - did you do an "install" to get them into your local repository? > > My problem is compile tries to build an ear. In all my years of release > engineering, compile has meant "turn source code into byte code". > Nothing more, nothing less. > > To have compile build an ear (which needs a war and ejbs) seems backward > to me. > > Add to this that a standard compile took 58 seconds. Due to the other > things that have to get run (namely the atg assembler), in order to get > everything built and installed into our local repository, we need to run > "mvn install" from the top level. This takes 13 - 15 minutes. That > just isn't going to work. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: compile tries to bundle up the ear - should it?
No, my question is still unanswered. I guess what I'm looking for is for those working at the top most level, is it expected that if you want to compile, you must build an ear? So for anyone who does an install, p4 sync, compile - they can expect to see errors unless they do an additional install? -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 07, 2007 2:14 PM To: Maven Users List Subject: Re: compile tries to bundle up the ear - should it? EJ, based on this response, does this mean that your issue can be considered "fully resolved" or are there other issues? As for the install question -- yes, I have previously executed "mvn install" to copy these artifacts to my local repo. The way I work, I am generally only working inside one module at a time, so I can run "mvn install" to copy all the other artifacts into my repo, then go into the specific module to do my edits etc and run "mvn compile" in that artifact alone, which will use the other unedited dependent artifacts out of my repo if needed. As for "why does Maven EAR plugin require all artifacts be available during compile" -- I'm pretty sure this just happens automatically during validate phase, which happens before compile, so when those artifacts are not available to validate, you never get to the compile phase. Wayne On 2/7/07, EJ Ciramella <[EMAIL PROTECTED]> wrote: > Well I figured out why the ejbs continue to recompile - their package > name doesn't reflect their location in main/java. > > -Original Message- > From: EJ Ciramella [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 07, 2007 1:38 PM > To: Maven Users List > Subject: RE: compile tries to bundle up the ear - should it? > > Wayne - did you do an "install" to get them into your local repository? > > My problem is compile tries to build an ear. In all my years of release > engineering, compile has meant "turn source code into byte code". > Nothing more, nothing less. > > To have compile build an ear (which needs a war and ejbs) seems backward > to me. > > Add to this that a standard compile took 58 seconds. Due to the other > things that have to get run (namely the atg assembler), in order to get > everything built and installed into our local repository, we need to run > "mvn install" from the top level. This takes 13 - 15 minutes. That > just isn't going to work. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compile tries to bundle up the ear - should it?
EJ, based on this response, does this mean that your issue can be considered "fully resolved" or are there other issues? As for the install question -- yes, I have previously executed "mvn install" to copy these artifacts to my local repo. The way I work, I am generally only working inside one module at a time, so I can run "mvn install" to copy all the other artifacts into my repo, then go into the specific module to do my edits etc and run "mvn compile" in that artifact alone, which will use the other unedited dependent artifacts out of my repo if needed. As for "why does Maven EAR plugin require all artifacts be available during compile" -- I'm pretty sure this just happens automatically during validate phase, which happens before compile, so when those artifacts are not available to validate, you never get to the compile phase. Wayne On 2/7/07, EJ Ciramella <[EMAIL PROTECTED]> wrote: Well I figured out why the ejbs continue to recompile - their package name doesn't reflect their location in main/java. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 07, 2007 1:38 PM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? Wayne - did you do an "install" to get them into your local repository? My problem is compile tries to build an ear. In all my years of release engineering, compile has meant "turn source code into byte code". Nothing more, nothing less. To have compile build an ear (which needs a war and ejbs) seems backward to me. Add to this that a standard compile took 58 seconds. Due to the other things that have to get run (namely the atg assembler), in order to get everything built and installed into our local repository, we need to run "mvn install" from the top level. This takes 13 - 15 minutes. That just isn't going to work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: compile tries to bundle up the ear - should it?
Well I figured out why the ejbs continue to recompile - their package name doesn't reflect their location in main/java. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 07, 2007 1:38 PM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? Wayne - did you do an "install" to get them into your local repository? My problem is compile tries to build an ear. In all my years of release engineering, compile has meant "turn source code into byte code". Nothing more, nothing less. To have compile build an ear (which needs a war and ejbs) seems backward to me. Add to this that a standard compile took 58 seconds. Due to the other things that have to get run (namely the atg assembler), in order to get everything built and installed into our local repository, we need to run "mvn install" from the top level. This takes 13 - 15 minutes. That just isn't going to work. Every time I compile after doing an install, I see this: [INFO] No goals needed for project - skipping [INFO] [INFO] Building template [INFO]task-segment: [compile] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] No sources to compile [INFO] [INFO] Building ltyApp_ear [INFO]task-segment: [compile] [INFO] [INFO] snapshot lty:ltyWebApp:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:transferEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:messageEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:withdrawalEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:inboundenrollmentEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:enrollmentEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:upAdminEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:partnerEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:authserverEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:CSREJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:accountGuestEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:communityEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:testcellEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:upErrorEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:salesscriptEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:memberProfileEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:transactionEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:groceryEJB:1.0-SNAPSHOT: checking for updates from central [INFO] [ear:generate-application-xml] [INFO] Generating application.xml [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. Why? Then running a compile a second time, I see this: [INFO] Building accountGuestEJB [INFO]task-segment: [compile] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] Compiling 3 source files to E:\work\39-FUSED\frontoffice\ltyApp\ejb\accountGuest\target\classes It JUST compiled these sources -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 07, 2007 1:02 PM To: Maven Users List Subject: Re: compile tries to bundle up the ear - should it? EJ, it sounds like you've got something misconfigured or screwy, because I can run the following just fine: parent -> ear, war, ejb, lib lib has no deps ejb dep lib war dep ejb ear dep war from parent directory mvn clean compile cleans and builds all modules in turn from parent directory mvn compile Nothing to compile - all classes are up to date cd into ear module (has no code, only bundles up the war, ejb, lib) mvn -X compile [DEBUG] x_web: using locally installed snapshot [DEBUG] x_ejb: using locally installed snapshot [DEBUG] x_lib: using locally installed snapshot BUILD SUCCESSFUL So I'm really not sure what you're doing that's resulting in these troubles... Wayne On 2/7/07, EJ Ciramella <[EMAIL PROTECTED]> wrote: > This is all very contradictory. > > So I need to do a maven install so the ear can find the war/ejbs, yet > all I REALLY want to do is compile. > > I have to do an INSTALL even though "SNAPSHOT" in essence means build > every ti
RE: compile tries to bundle up the ear - should it?
Wayne - did you do an "install" to get them into your local repository? My problem is compile tries to build an ear. In all my years of release engineering, compile has meant "turn source code into byte code". Nothing more, nothing less. To have compile build an ear (which needs a war and ejbs) seems backward to me. Add to this that a standard compile took 58 seconds. Due to the other things that have to get run (namely the atg assembler), in order to get everything built and installed into our local repository, we need to run "mvn install" from the top level. This takes 13 - 15 minutes. That just isn't going to work. Every time I compile after doing an install, I see this: [INFO] No goals needed for project - skipping [INFO] [INFO] Building template [INFO]task-segment: [compile] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] No sources to compile [INFO] [INFO] Building ltyApp_ear [INFO]task-segment: [compile] [INFO] [INFO] snapshot lty:ltyWebApp:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:transferEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:messageEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:withdrawalEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:inboundenrollmentEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:enrollmentEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:upAdminEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:partnerEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:authserverEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:CSREJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:accountGuestEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:communityEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:testcellEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:upErrorEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:salesscriptEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:memberProfileEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:transactionEJB:1.0-SNAPSHOT: checking for updates from central [INFO] snapshot lty:groceryEJB:1.0-SNAPSHOT: checking for updates from central [INFO] [ear:generate-application-xml] [INFO] Generating application.xml [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. Why? Then running a compile a second time, I see this: [INFO] Building accountGuestEJB [INFO]task-segment: [compile] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] Compiling 3 source files to E:\work\39-FUSED\frontoffice\ltyApp\ejb\accountGuest\target\classes It JUST compiled these sources -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 07, 2007 1:02 PM To: Maven Users List Subject: Re: compile tries to bundle up the ear - should it? EJ, it sounds like you've got something misconfigured or screwy, because I can run the following just fine: parent -> ear, war, ejb, lib lib has no deps ejb dep lib war dep ejb ear dep war from parent directory mvn clean compile cleans and builds all modules in turn from parent directory mvn compile Nothing to compile - all classes are up to date cd into ear module (has no code, only bundles up the war, ejb, lib) mvn -X compile [DEBUG] x_web: using locally installed snapshot [DEBUG] x_ejb: using locally installed snapshot [DEBUG] x_lib: using locally installed snapshot BUILD SUCCESSFUL So I'm really not sure what you're doing that's resulting in these troubles... Wayne On 2/7/07, EJ Ciramella <[EMAIL PROTECTED]> wrote: > This is all very contradictory. > > So I need to do a maven install so the ear can find the war/ejbs, yet > all I REALLY want to do is compile. > > I have to do an INSTALL even though "SNAPSHOT" in essence means build > every time. Why do things need to go into the repository? > > Developers used to be able to do a compile in 58 seconds. Now because > "compile" needs to build the ear/war/ejbs, you have to do an install > that takes 13 - 15 minutes. > > How does this not seem infinitely frustrating and completely >
Re: compile tries to bundle up the ear - should it?
EJ, it sounds like you've got something misconfigured or screwy, because I can run the following just fine: parent -> ear, war, ejb, lib lib has no deps ejb dep lib war dep ejb ear dep war from parent directory mvn clean compile cleans and builds all modules in turn from parent directory mvn compile Nothing to compile - all classes are up to date cd into ear module (has no code, only bundles up the war, ejb, lib) mvn -X compile [DEBUG] x_web: using locally installed snapshot [DEBUG] x_ejb: using locally installed snapshot [DEBUG] x_lib: using locally installed snapshot BUILD SUCCESSFUL So I'm really not sure what you're doing that's resulting in these troubles... Wayne On 2/7/07, EJ Ciramella <[EMAIL PROTECTED]> wrote: This is all very contradictory. So I need to do a maven install so the ear can find the war/ejbs, yet all I REALLY want to do is compile. I have to do an INSTALL even though "SNAPSHOT" in essence means build every time. Why do things need to go into the repository? Developers used to be able to do a compile in 58 seconds. Now because "compile" needs to build the ear/war/ejbs, you have to do an install that takes 13 - 15 minutes. How does this not seem infinitely frustrating and completely infuriating? -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 06, 2007 8:58 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? I would need more information on your POMs, project structure etc to be able to explain why you are having these problems. At this stage there is probably no other advice I can give you. Is there anyone else out there who can help? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, 7 February 2007 4:43 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? Yeah, this is kinda nuts, even after running an install, I see things getting rebuilt: [INFO] Building withdrawalEJB [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] Compiling 3 source files to E:\work\39-FUSED\frontoffice\ltyApp\ejb\withdrawal\target\classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] No sources to compile [INFO] [surefire:test] [INFO] No tests to run. [INFO] [jar:jar] [INFO] Building jar: E:\work\39-FUSED\frontoffice\ltyApp\ejb\withdrawal\target\withdrawalEJB- 1.0-SNAPSHOT.jar [INFO] [install:install] [INFO] Installing E:\work\39-FUSED\frontoffice\ltyApp\ejb\withdrawal\target\withdrawalEJB- 1.0-SNAPSHOT.jar to E:\work\m2\Repository\lty\withdrawa Shouldn't this happen just once? Why each time? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 06, 2007 9:59 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? So in essence you're suggesting shutting of unittests via a switch (most developers already think it takes too long and use -Dtest=asdf). I personally find this unacceptable. I still think it's silly that mvn tries to build an ear/war/ejbs when all it needs are the underlying classes. There's part of the picture I think I'm not emphasizing enough which is the inherently long drawn out process building an atg app requires (their assembly phase) which we've linked to the package lifecycle goal. Having to do an install of each module takes too much time moving around and doing an install of everything takes too long if all you want to do is compile. To build an ejb, the underlying java source needs to be compiled and stashed somewhere doesn't it? I just still don't understand why there would be this dependency on an ear file to simply compile something in one of the main applications. I have a feeling this will be the straw that breaks the development camels back. -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 8:05 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? Hopefully they're all using Eclipse and they can run 'mvn eclipse:eclipse' to generate the Eclipse project files they need so that they can compile their Java code as they develop. You don't need to build your EJB, WAR and EAR files just to get your classes to compile UNLESS other modules depend on them. For example, if I have modules A, B and C and module B is dependent on A but C is independent of both of them, I can build C without needing access to artifacts from A and B. If, however, I want to build B, I will need access to A.jar. A.jar would normally come from my local repository since I've run 'm
RE: compile tries to bundle up the ear - should it?
This is all very contradictory. So I need to do a maven install so the ear can find the war/ejbs, yet all I REALLY want to do is compile. I have to do an INSTALL even though "SNAPSHOT" in essence means build every time. Why do things need to go into the repository? Developers used to be able to do a compile in 58 seconds. Now because "compile" needs to build the ear/war/ejbs, you have to do an install that takes 13 - 15 minutes. How does this not seem infinitely frustrating and completely infuriating? -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 06, 2007 8:58 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? I would need more information on your POMs, project structure etc to be able to explain why you are having these problems. At this stage there is probably no other advice I can give you. Is there anyone else out there who can help? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, 7 February 2007 4:43 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? Yeah, this is kinda nuts, even after running an install, I see things getting rebuilt: [INFO] Building withdrawalEJB [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] Compiling 3 source files to E:\work\39-FUSED\frontoffice\ltyApp\ejb\withdrawal\target\classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] No sources to compile [INFO] [surefire:test] [INFO] No tests to run. [INFO] [jar:jar] [INFO] Building jar: E:\work\39-FUSED\frontoffice\ltyApp\ejb\withdrawal\target\withdrawalEJB- 1.0-SNAPSHOT.jar [INFO] [install:install] [INFO] Installing E:\work\39-FUSED\frontoffice\ltyApp\ejb\withdrawal\target\withdrawalEJB- 1.0-SNAPSHOT.jar to E:\work\m2\Repository\lty\withdrawa Shouldn't this happen just once? Why each time? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 06, 2007 9:59 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? So in essence you're suggesting shutting of unittests via a switch (most developers already think it takes too long and use -Dtest=asdf). I personally find this unacceptable. I still think it's silly that mvn tries to build an ear/war/ejbs when all it needs are the underlying classes. There's part of the picture I think I'm not emphasizing enough which is the inherently long drawn out process building an atg app requires (their assembly phase) which we've linked to the package lifecycle goal. Having to do an install of each module takes too much time moving around and doing an install of everything takes too long if all you want to do is compile. To build an ejb, the underlying java source needs to be compiled and stashed somewhere doesn't it? I just still don't understand why there would be this dependency on an ear file to simply compile something in one of the main applications. I have a feeling this will be the straw that breaks the development camels back. -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 8:05 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? Hopefully they're all using Eclipse and they can run 'mvn eclipse:eclipse' to generate the Eclipse project files they need so that they can compile their Java code as they develop. You don't need to build your EJB, WAR and EAR files just to get your classes to compile UNLESS other modules depend on them. For example, if I have modules A, B and C and module B is dependent on A but C is independent of both of them, I can build C without needing access to artifacts from A and B. If, however, I want to build B, I will need access to A.jar. A.jar would normally come from my local repository since I've run 'mvn clean install' in module A. The whole point is that you've decided when designing your project structure that A, B and C are separately managed modules (with dependencies between them). Therefore, to access A's classes from B you need to package them in some way. In Maven, the way to do this is to package them as a jar file and place them in your local repository (and eventually in your snapshot repository and, finally, in your production repository). As for running tests, developers can turn off running the tests during their development cycle (see the Maven Website for details). The actual package/install steps of creating a jar and copying it to a local repository are very quick so no developer is really going to notice the l
RE: compile tries to bundle up the ear - should it?
I would need more information on your POMs, project structure etc to be able to explain why you are having these problems. At this stage there is probably no other advice I can give you. Is there anyone else out there who can help? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, 7 February 2007 4:43 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? Yeah, this is kinda nuts, even after running an install, I see things getting rebuilt: [INFO] Building withdrawalEJB [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] Compiling 3 source files to E:\work\39-FUSED\frontoffice\ltyApp\ejb\withdrawal\target\classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] No sources to compile [INFO] [surefire:test] [INFO] No tests to run. [INFO] [jar:jar] [INFO] Building jar: E:\work\39-FUSED\frontoffice\ltyApp\ejb\withdrawal\target\withdrawalEJB- 1.0-SNAPSHOT.jar [INFO] [install:install] [INFO] Installing E:\work\39-FUSED\frontoffice\ltyApp\ejb\withdrawal\target\withdrawalEJB- 1.0-SNAPSHOT.jar to E:\work\m2\Repository\lty\withdrawa Shouldn't this happen just once? Why each time? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 06, 2007 9:59 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? So in essence you're suggesting shutting of unittests via a switch (most developers already think it takes too long and use -Dtest=asdf). I personally find this unacceptable. I still think it's silly that mvn tries to build an ear/war/ejbs when all it needs are the underlying classes. There's part of the picture I think I'm not emphasizing enough which is the inherently long drawn out process building an atg app requires (their assembly phase) which we've linked to the package lifecycle goal. Having to do an install of each module takes too much time moving around and doing an install of everything takes too long if all you want to do is compile. To build an ejb, the underlying java source needs to be compiled and stashed somewhere doesn't it? I just still don't understand why there would be this dependency on an ear file to simply compile something in one of the main applications. I have a feeling this will be the straw that breaks the development camels back. -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 8:05 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? Hopefully they're all using Eclipse and they can run 'mvn eclipse:eclipse' to generate the Eclipse project files they need so that they can compile their Java code as they develop. You don't need to build your EJB, WAR and EAR files just to get your classes to compile UNLESS other modules depend on them. For example, if I have modules A, B and C and module B is dependent on A but C is independent of both of them, I can build C without needing access to artifacts from A and B. If, however, I want to build B, I will need access to A.jar. A.jar would normally come from my local repository since I've run 'mvn clean install' in module A. The whole point is that you've decided when designing your project structure that A, B and C are separately managed modules (with dependencies between them). Therefore, to access A's classes from B you need to package them in some way. In Maven, the way to do this is to package them as a jar file and place them in your local repository (and eventually in your snapshot repository and, finally, in your production repository). As for running tests, developers can turn off running the tests during their development cycle (see the Maven Website for details). The actual package/install steps of creating a jar and copying it to a local repository are very quick so no developer is really going to notice the lost time. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 10:37 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? Yeah, I mentioned cruisecontrol, just not looking forward to telling developers they need to run the install process now even if all they want is a simple compile. I still don't see any good reason why you'd have to build up an ejb file (or war or ear) just to get your classes to compile. These things shouldn't even be attempted until the package stage. This seems like a shortcoming. -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 6:29 PM To: 'Maven Users
RE: compile tries to bundle up the ear - should it?
Yeah, this is kinda nuts, even after running an install, I see things getting rebuilt: [INFO] Building withdrawalEJB [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] Compiling 3 source files to E:\work\39-FUSED\frontoffice\ltyApp\ejb\withdrawal\target\classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] No sources to compile [INFO] [surefire:test] [INFO] No tests to run. [INFO] [jar:jar] [INFO] Building jar: E:\work\39-FUSED\frontoffice\ltyApp\ejb\withdrawal\target\withdrawalEJB- 1.0-SNAPSHOT.jar [INFO] [install:install] [INFO] Installing E:\work\39-FUSED\frontoffice\ltyApp\ejb\withdrawal\target\withdrawalEJB- 1.0-SNAPSHOT.jar to E:\work\m2\Repository\lty\withdrawa Shouldn't this happen just once? Why each time? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 06, 2007 9:59 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? So in essence you're suggesting shutting of unittests via a switch (most developers already think it takes too long and use -Dtest=asdf). I personally find this unacceptable. I still think it's silly that mvn tries to build an ear/war/ejbs when all it needs are the underlying classes. There's part of the picture I think I'm not emphasizing enough which is the inherently long drawn out process building an atg app requires (their assembly phase) which we've linked to the package lifecycle goal. Having to do an install of each module takes too much time moving around and doing an install of everything takes too long if all you want to do is compile. To build an ejb, the underlying java source needs to be compiled and stashed somewhere doesn't it? I just still don't understand why there would be this dependency on an ear file to simply compile something in one of the main applications. I have a feeling this will be the straw that breaks the development camels back. -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 8:05 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? Hopefully they're all using Eclipse and they can run 'mvn eclipse:eclipse' to generate the Eclipse project files they need so that they can compile their Java code as they develop. You don't need to build your EJB, WAR and EAR files just to get your classes to compile UNLESS other modules depend on them. For example, if I have modules A, B and C and module B is dependent on A but C is independent of both of them, I can build C without needing access to artifacts from A and B. If, however, I want to build B, I will need access to A.jar. A.jar would normally come from my local repository since I've run 'mvn clean install' in module A. The whole point is that you've decided when designing your project structure that A, B and C are separately managed modules (with dependencies between them). Therefore, to access A's classes from B you need to package them in some way. In Maven, the way to do this is to package them as a jar file and place them in your local repository (and eventually in your snapshot repository and, finally, in your production repository). As for running tests, developers can turn off running the tests during their development cycle (see the Maven Website for details). The actual package/install steps of creating a jar and copying it to a local repository are very quick so no developer is really going to notice the lost time. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 10:37 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? Yeah, I mentioned cruisecontrol, just not looking forward to telling developers they need to run the install process now even if all they want is a simple compile. I still don't see any good reason why you'd have to build up an ejb file (or war or ear) just to get your classes to compile. These things shouldn't even be attempted until the package stage. This seems like a shortcoming. -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 6:29 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? You need to run 'mvn install' at least once to ensure your dependencies are in a repository. In fact, if your cruisecontrol build is running on another machine, you will need to run 'mvn deploy' at least once to get a snapshot in your corporate repository. Then, you can run 'mvn compile' at will, as long as your Java so
RE: compile tries to bundle up the ear - should it?
Additionally - you miss the point about just wanting to compile and unittest with no startup of the actual app (repeatedly, in quick succession). -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 8:05 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? Hopefully they're all using Eclipse and they can run 'mvn eclipse:eclipse' to generate the Eclipse project files they need so that they can compile their Java code as they develop. You don't need to build your EJB, WAR and EAR files just to get your classes to compile UNLESS other modules depend on them. For example, if I have modules A, B and C and module B is dependent on A but C is independent of both of them, I can build C without needing access to artifacts from A and B. If, however, I want to build B, I will need access to A.jar. A.jar would normally come from my local repository since I've run 'mvn clean install' in module A. The whole point is that you've decided when designing your project structure that A, B and C are separately managed modules (with dependencies between them). Therefore, to access A's classes from B you need to package them in some way. In Maven, the way to do this is to package them as a jar file and place them in your local repository (and eventually in your snapshot repository and, finally, in your production repository). As for running tests, developers can turn off running the tests during their development cycle (see the Maven Website for details). The actual package/install steps of creating a jar and copying it to a local repository are very quick so no developer is really going to notice the lost time. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 10:37 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? Yeah, I mentioned cruisecontrol, just not looking forward to telling developers they need to run the install process now even if all they want is a simple compile. I still don't see any good reason why you'd have to build up an ejb file (or war or ear) just to get your classes to compile. These things shouldn't even be attempted until the package stage. This seems like a shortcoming. -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 6:29 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? You need to run 'mvn install' at least once to ensure your dependencies are in a repository. In fact, if your cruisecontrol build is running on another machine, you will need to run 'mvn deploy' at least once to get a snapshot in your corporate repository. Then, you can run 'mvn compile' at will, as long as your Java sources don't change enough to make your compiles fail. Having said that, I would recommend that you run 'mvn clean deploy' every night so that you are getting a complete build and test-cycle run every night (or use a continuous integration server like Continuum). You can also add the 'findbugs' report to your projects so this is run for you automatically as well. -Original Message----- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 10:18 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? So if (in my case) we do a compile prior to running findbugs each night (a case where we DON'T need an ear file), I'm going to have to start performing a "mvn install" instead? P.S - this is running via cruisecontrol and always from the top directory. We're very used to an ant based build where we can run various stages as we wish. Compile being a very desirable thing. If we can no longer run compile to compile source without having to wait for a much longer process (unit tests, site building, atg assembler, ejb building, war building then finally ear building), I think I may be in a bind (being the soul release engineer forced to support maven 2). Can I forcefully de-couple these two things? -----Original Message----- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 6:05 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? It hasn't tried to build the EAR yet: > [INFO] Building ltyApp_ear > [INFO]task-segment: [compile] You have specified 'mvn compile' in the EAR project and it is simply trying to download dependencies at this stage so it can do the compile. My suggestion would be to not run the compile phase explicitly, particularly in the EAR module, but run 'mvn install' even if you are building virtually empty artifacts for the other components. In other words, get the whole build process working correctly
RE: compile tries to bundle up the ear - should it?
So in essence you're suggesting shutting of unittests via a switch (most developers already think it takes too long and use -Dtest=asdf). I personally find this unacceptable. I still think it's silly that mvn tries to build an ear/war/ejbs when all it needs are the underlying classes. There's part of the picture I think I'm not emphasizing enough which is the inherently long drawn out process building an atg app requires (their assembly phase) which we've linked to the package lifecycle goal. Having to do an install of each module takes too much time moving around and doing an install of everything takes too long if all you want to do is compile. To build an ejb, the underlying java source needs to be compiled and stashed somewhere doesn't it? I just still don't understand why there would be this dependency on an ear file to simply compile something in one of the main applications. I have a feeling this will be the straw that breaks the development camels back. -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 8:05 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? Hopefully they're all using Eclipse and they can run 'mvn eclipse:eclipse' to generate the Eclipse project files they need so that they can compile their Java code as they develop. You don't need to build your EJB, WAR and EAR files just to get your classes to compile UNLESS other modules depend on them. For example, if I have modules A, B and C and module B is dependent on A but C is independent of both of them, I can build C without needing access to artifacts from A and B. If, however, I want to build B, I will need access to A.jar. A.jar would normally come from my local repository since I've run 'mvn clean install' in module A. The whole point is that you've decided when designing your project structure that A, B and C are separately managed modules (with dependencies between them). Therefore, to access A's classes from B you need to package them in some way. In Maven, the way to do this is to package them as a jar file and place them in your local repository (and eventually in your snapshot repository and, finally, in your production repository). As for running tests, developers can turn off running the tests during their development cycle (see the Maven Website for details). The actual package/install steps of creating a jar and copying it to a local repository are very quick so no developer is really going to notice the lost time. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 10:37 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? Yeah, I mentioned cruisecontrol, just not looking forward to telling developers they need to run the install process now even if all they want is a simple compile. I still don't see any good reason why you'd have to build up an ejb file (or war or ear) just to get your classes to compile. These things shouldn't even be attempted until the package stage. This seems like a shortcoming. -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 6:29 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? You need to run 'mvn install' at least once to ensure your dependencies are in a repository. In fact, if your cruisecontrol build is running on another machine, you will need to run 'mvn deploy' at least once to get a snapshot in your corporate repository. Then, you can run 'mvn compile' at will, as long as your Java sources don't change enough to make your compiles fail. Having said that, I would recommend that you run 'mvn clean deploy' every night so that you are getting a complete build and test-cycle run every night (or use a continuous integration server like Continuum). You can also add the 'findbugs' report to your projects so this is run for you automatically as well. -----Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 10:18 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? So if (in my case) we do a compile prior to running findbugs each night (a case where we DON'T need an ear file), I'm going to have to start performing a "mvn install" instead? P.S - this is running via cruisecontrol and always from the top directory. We're very used to an ant based build where we can run various stages as we wish. Compile being a very desirable thing. If we can no longer run compile to compile source without having to wait for a much longer process (unit tests, site building, atg assembler, ejb building, war building then finally ear building), I think I
RE: compile tries to bundle up the ear - should it?
Hopefully they're all using Eclipse and they can run 'mvn eclipse:eclipse' to generate the Eclipse project files they need so that they can compile their Java code as they develop. You don't need to build your EJB, WAR and EAR files just to get your classes to compile UNLESS other modules depend on them. For example, if I have modules A, B and C and module B is dependent on A but C is independent of both of them, I can build C without needing access to artifacts from A and B. If, however, I want to build B, I will need access to A.jar. A.jar would normally come from my local repository since I've run 'mvn clean install' in module A. The whole point is that you've decided when designing your project structure that A, B and C are separately managed modules (with dependencies between them). Therefore, to access A's classes from B you need to package them in some way. In Maven, the way to do this is to package them as a jar file and place them in your local repository (and eventually in your snapshot repository and, finally, in your production repository). As for running tests, developers can turn off running the tests during their development cycle (see the Maven Website for details). The actual package/install steps of creating a jar and copying it to a local repository are very quick so no developer is really going to notice the lost time. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 10:37 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? Yeah, I mentioned cruisecontrol, just not looking forward to telling developers they need to run the install process now even if all they want is a simple compile. I still don't see any good reason why you'd have to build up an ejb file (or war or ear) just to get your classes to compile. These things shouldn't even be attempted until the package stage. This seems like a shortcoming. -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 6:29 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? You need to run 'mvn install' at least once to ensure your dependencies are in a repository. In fact, if your cruisecontrol build is running on another machine, you will need to run 'mvn deploy' at least once to get a snapshot in your corporate repository. Then, you can run 'mvn compile' at will, as long as your Java sources don't change enough to make your compiles fail. Having said that, I would recommend that you run 'mvn clean deploy' every night so that you are getting a complete build and test-cycle run every night (or use a continuous integration server like Continuum). You can also add the 'findbugs' report to your projects so this is run for you automatically as well. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 10:18 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? So if (in my case) we do a compile prior to running findbugs each night (a case where we DON'T need an ear file), I'm going to have to start performing a "mvn install" instead? P.S - this is running via cruisecontrol and always from the top directory. We're very used to an ant based build where we can run various stages as we wish. Compile being a very desirable thing. If we can no longer run compile to compile source without having to wait for a much longer process (unit tests, site building, atg assembler, ejb building, war building then finally ear building), I think I may be in a bind (being the soul release engineer forced to support maven 2). Can I forcefully de-couple these two things? -----Original Message----- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 6:05 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? It hasn't tried to build the EAR yet: > [INFO] Building ltyApp_ear > [INFO]task-segment: [compile] You have specified 'mvn compile' in the EAR project and it is simply trying to download dependencies at this stage so it can do the compile. My suggestion would be to not run the compile phase explicitly, particularly in the EAR module, but run 'mvn install' even if you are building virtually empty artifacts for the other components. In other words, get the whole build process working correctly first. Alternatively, the next best thing to do would be to remove the EAR module from your modules list for now until you have everything else to a stage where the repository has all of the artifacts required to build an EAR. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 9:42 AM To: Maven Users List Sub
RE: compile tries to bundle up the ear - should it?
Yeah, I mentioned cruisecontrol, just not looking forward to telling developers they need to run the install process now even if all they want is a simple compile. I still don't see any good reason why you'd have to build up an ejb file (or war or ear) just to get your classes to compile. These things shouldn't even be attempted until the package stage. This seems like a shortcoming. -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 6:29 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? You need to run 'mvn install' at least once to ensure your dependencies are in a repository. In fact, if your cruisecontrol build is running on another machine, you will need to run 'mvn deploy' at least once to get a snapshot in your corporate repository. Then, you can run 'mvn compile' at will, as long as your Java sources don't change enough to make your compiles fail. Having said that, I would recommend that you run 'mvn clean deploy' every night so that you are getting a complete build and test-cycle run every night (or use a continuous integration server like Continuum). You can also add the 'findbugs' report to your projects so this is run for you automatically as well. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 10:18 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? So if (in my case) we do a compile prior to running findbugs each night (a case where we DON'T need an ear file), I'm going to have to start performing a "mvn install" instead? P.S - this is running via cruisecontrol and always from the top directory. We're very used to an ant based build where we can run various stages as we wish. Compile being a very desirable thing. If we can no longer run compile to compile source without having to wait for a much longer process (unit tests, site building, atg assembler, ejb building, war building then finally ear building), I think I may be in a bind (being the soul release engineer forced to support maven 2). Can I forcefully de-couple these two things? -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 6:05 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? It hasn't tried to build the EAR yet: > [INFO] Building ltyApp_ear > [INFO]task-segment: [compile] You have specified 'mvn compile' in the EAR project and it is simply trying to download dependencies at this stage so it can do the compile. My suggestion would be to not run the compile phase explicitly, particularly in the EAR module, but run 'mvn install' even if you are building virtually empty artifacts for the other components. In other words, get the whole build process working correctly first. Alternatively, the next best thing to do would be to remove the EAR module from your modules list for now until you have everything else to a stage where the repository has all of the artifacts required to build an EAR. -Original Message----- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 9:42 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? Wait - even if I'm simply doing a compile? Why should it start trying to build an ear? I tried a "mvn compile" that results in all kinds of failures cause it tries to build up an ear (and there's no war/ejbs to include). The ear file building is linked to the compile lifecycle phase? -----Original Message----- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 4:40 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? The modules need to be downloaded since they are dependencies at compile time (the default), even in an EAR package. Modules will never be picked up from their target directories (part of the design of Maven). You need to run 'mvn install' on the other modules to ensure they are in your local repository at least before running a build in the EAR module. Hope this helps. -----Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 8:19 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? Still haven't seen any response - this has us wedged, can anyone shed any light on this for me? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 31, 2007 6:23 PM To: Maven Users List Subject: compile tries to bundle up the ear - should it? I'm running just compile but one module that has an ear artifact is trying to bundle up the ear file (which subsequently fails because the war a
RE: compile tries to bundle up the ear - should it?
You need to run 'mvn install' at least once to ensure your dependencies are in a repository. In fact, if your cruisecontrol build is running on another machine, you will need to run 'mvn deploy' at least once to get a snapshot in your corporate repository. Then, you can run 'mvn compile' at will, as long as your Java sources don't change enough to make your compiles fail. Having said that, I would recommend that you run 'mvn clean deploy' every night so that you are getting a complete build and test-cycle run every night (or use a continuous integration server like Continuum). You can also add the 'findbugs' report to your projects so this is run for you automatically as well. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 10:18 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? So if (in my case) we do a compile prior to running findbugs each night (a case where we DON'T need an ear file), I'm going to have to start performing a "mvn install" instead? P.S - this is running via cruisecontrol and always from the top directory. We're very used to an ant based build where we can run various stages as we wish. Compile being a very desirable thing. If we can no longer run compile to compile source without having to wait for a much longer process (unit tests, site building, atg assembler, ejb building, war building then finally ear building), I think I may be in a bind (being the soul release engineer forced to support maven 2). Can I forcefully de-couple these two things? -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 6:05 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? It hasn't tried to build the EAR yet: > [INFO] Building ltyApp_ear > [INFO]task-segment: [compile] You have specified 'mvn compile' in the EAR project and it is simply trying to download dependencies at this stage so it can do the compile. My suggestion would be to not run the compile phase explicitly, particularly in the EAR module, but run 'mvn install' even if you are building virtually empty artifacts for the other components. In other words, get the whole build process working correctly first. Alternatively, the next best thing to do would be to remove the EAR module from your modules list for now until you have everything else to a stage where the repository has all of the artifacts required to build an EAR. -Original Message----- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 9:42 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? Wait - even if I'm simply doing a compile? Why should it start trying to build an ear? I tried a "mvn compile" that results in all kinds of failures cause it tries to build up an ear (and there's no war/ejbs to include). The ear file building is linked to the compile lifecycle phase? -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 4:40 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? The modules need to be downloaded since they are dependencies at compile time (the default), even in an EAR package. Modules will never be picked up from their target directories (part of the design of Maven). You need to run 'mvn install' on the other modules to ensure they are in your local repository at least before running a build in the EAR module. Hope this helps. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 8:19 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? Still haven't seen any response - this has us wedged, can anyone shed any light on this for me? -----Original Message----- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 31, 2007 6:23 PM To: Maven Users List Subject: compile tries to bundle up the ear - should it? I'm running just compile but one module that has an ear artifact is trying to bundle up the ear file (which subsequently fails because the war and ejbs don't exist). Is this supposed to happen or is this something I've misconfigured: [INFO] [INFO] Building ltyApp_ear [INFO]task-segment: [compile] [INFO] Downloading: file:\\build.corp.upromise.com/maven2/lty/upErrorEJB/1.0-SNAPSHOT/upErro rEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/
RE: compile tries to bundle up the ear - should it?
Again, I'm sitting at the top most pom level and running mvn compile. No one here expects to cd around to build the various modules. -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 6:14 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? BTW, I'ce just tried running 'mvn compile' in an EAR module on one of my projects and the ear plugin substitutes the ear-generate-application-xml goal for the usual compile goal as explained in http://maven.apache.org/guides/introduction/introduction-to-the-lifecycl e.ht ml. So, it is quite safe to run 'mvn compile' in an EAR module but you need your dependencies to be available in your repository (local or remote). -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 10:05 AM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? It hasn't tried to build the EAR yet: > [INFO] Building ltyApp_ear > [INFO]task-segment: [compile] You have specified 'mvn compile' in the EAR project and it is simply trying to download dependencies at this stage so it can do the compile. My suggestion would be to not run the compile phase explicitly, particularly in the EAR module, but run 'mvn install' even if you are building virtually empty artifacts for the other components. In other words, get the whole build process working correctly first. Alternatively, the next best thing to do would be to remove the EAR module from your modules list for now until you have everything else to a stage where the repository has all of the artifacts required to build an EAR. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 9:42 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? Wait - even if I'm simply doing a compile? Why should it start trying to build an ear? I tried a "mvn compile" that results in all kinds of failures cause it tries to build up an ear (and there's no war/ejbs to include). The ear file building is linked to the compile lifecycle phase? -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 4:40 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? The modules need to be downloaded since they are dependencies at compile time (the default), even in an EAR package. Modules will never be picked up from their target directories (part of the design of Maven). You need to run 'mvn install' on the other modules to ensure they are in your local repository at least before running a build in the EAR module. Hope this helps. -Original Message----- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 8:19 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? Still haven't seen any response - this has us wedged, can anyone shed any light on this for me? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 31, 2007 6:23 PM To: Maven Users List Subject: compile tries to bundle up the ear - should it? I'm running just compile but one module that has an ear artifact is trying to bundle up the ear file (which subsequently fails because the war and ejbs don't exist). Is this supposed to happen or is this something I've misconfigured: [INFO] [INFO] Building ltyApp_ear [INFO]task-segment: [compile] [INFO] Downloading: file:\\build.corp.upromise.com/maven2/lty/upErrorEJB/1.0-SNAPSHOT/upErro rEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/salesscriptEJB/1.0-SNAPSHOT/sa lesscriptEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/transferEJB/1.0-SNAPSHOT/trans ferEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/transactionEJB/1.0-SNAPSHOT/tr ansactionEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/CSREJB/1.0-SNAPSHOT/CSREJB-1.0 -SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/upAdminEJB/1.0-SNAPSHOT/upAdmi nEJB-1.0-SNAPSHOT.jar
RE: compile tries to bundle up the ear - should it?
So if (in my case) we do a compile prior to running findbugs each night (a case where we DON'T need an ear file), I'm going to have to start performing a "mvn install" instead? P.S - this is running via cruisecontrol and always from the top directory. We're very used to an ant based build where we can run various stages as we wish. Compile being a very desirable thing. If we can no longer run compile to compile source without having to wait for a much longer process (unit tests, site building, atg assembler, ejb building, war building then finally ear building), I think I may be in a bind (being the soul release engineer forced to support maven 2). Can I forcefully de-couple these two things? -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 6:05 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? It hasn't tried to build the EAR yet: > [INFO] Building ltyApp_ear > [INFO]task-segment: [compile] You have specified 'mvn compile' in the EAR project and it is simply trying to download dependencies at this stage so it can do the compile. My suggestion would be to not run the compile phase explicitly, particularly in the EAR module, but run 'mvn install' even if you are building virtually empty artifacts for the other components. In other words, get the whole build process working correctly first. Alternatively, the next best thing to do would be to remove the EAR module from your modules list for now until you have everything else to a stage where the repository has all of the artifacts required to build an EAR. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 9:42 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? Wait - even if I'm simply doing a compile? Why should it start trying to build an ear? I tried a "mvn compile" that results in all kinds of failures cause it tries to build up an ear (and there's no war/ejbs to include). The ear file building is linked to the compile lifecycle phase? -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 4:40 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? The modules need to be downloaded since they are dependencies at compile time (the default), even in an EAR package. Modules will never be picked up from their target directories (part of the design of Maven). You need to run 'mvn install' on the other modules to ensure they are in your local repository at least before running a build in the EAR module. Hope this helps. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 8:19 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? Still haven't seen any response - this has us wedged, can anyone shed any light on this for me? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 31, 2007 6:23 PM To: Maven Users List Subject: compile tries to bundle up the ear - should it? I'm running just compile but one module that has an ear artifact is trying to bundle up the ear file (which subsequently fails because the war and ejbs don't exist). Is this supposed to happen or is this something I've misconfigured: [INFO] [INFO] Building ltyApp_ear [INFO]task-segment: [compile] [INFO] Downloading: file:\\build.corp.upromise.com/maven2/lty/upErrorEJB/1.0-SNAPSHOT/upErro rEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/salesscriptEJB/1.0-SNAPSHOT/sa lesscriptEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/transferEJB/1.0-SNAPSHOT/trans ferEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/transactionEJB/1.0-SNAPSHOT/tr ansactionEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/CSREJB/1.0-SNAPSHOT/CSREJB-1.0 -SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/upAdminEJB/1.0-SNAPSHOT/upAdmi nEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (fil
RE: compile tries to bundle up the ear - should it?
BTW, I'ce just tried running 'mvn compile' in an EAR module on one of my projects and the ear plugin substitutes the ear-generate-application-xml goal for the usual compile goal as explained in http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.ht ml. So, it is quite safe to run 'mvn compile' in an EAR module but you need your dependencies to be available in your repository (local or remote). -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 10:05 AM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? It hasn't tried to build the EAR yet: > [INFO] Building ltyApp_ear > [INFO]task-segment: [compile] You have specified 'mvn compile' in the EAR project and it is simply trying to download dependencies at this stage so it can do the compile. My suggestion would be to not run the compile phase explicitly, particularly in the EAR module, but run 'mvn install' even if you are building virtually empty artifacts for the other components. In other words, get the whole build process working correctly first. Alternatively, the next best thing to do would be to remove the EAR module from your modules list for now until you have everything else to a stage where the repository has all of the artifacts required to build an EAR. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 9:42 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? Wait - even if I'm simply doing a compile? Why should it start trying to build an ear? I tried a "mvn compile" that results in all kinds of failures cause it tries to build up an ear (and there's no war/ejbs to include). The ear file building is linked to the compile lifecycle phase? -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 4:40 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? The modules need to be downloaded since they are dependencies at compile time (the default), even in an EAR package. Modules will never be picked up from their target directories (part of the design of Maven). You need to run 'mvn install' on the other modules to ensure they are in your local repository at least before running a build in the EAR module. Hope this helps. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 8:19 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? Still haven't seen any response - this has us wedged, can anyone shed any light on this for me? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 31, 2007 6:23 PM To: Maven Users List Subject: compile tries to bundle up the ear - should it? I'm running just compile but one module that has an ear artifact is trying to bundle up the ear file (which subsequently fails because the war and ejbs don't exist). Is this supposed to happen or is this something I've misconfigured: [INFO] [INFO] Building ltyApp_ear [INFO]task-segment: [compile] [INFO] Downloading: file:\\build.corp.upromise.com/maven2/lty/upErrorEJB/1.0-SNAPSHOT/upErro rEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/salesscriptEJB/1.0-SNAPSHOT/sa lesscriptEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/transferEJB/1.0-SNAPSHOT/trans ferEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/transactionEJB/1.0-SNAPSHOT/tr ansactionEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/CSREJB/1.0-SNAPSHOT/CSREJB-1.0 -SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/upAdminEJB/1.0-SNAPSHOT/upAdmi nEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/inboundenrollmentEJB/1.0-SNAPS HOT/inboundenrollmentEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.
RE: compile tries to bundle up the ear - should it?
It hasn't tried to build the EAR yet: > [INFO] Building ltyApp_ear > [INFO]task-segment: [compile] You have specified 'mvn compile' in the EAR project and it is simply trying to download dependencies at this stage so it can do the compile. My suggestion would be to not run the compile phase explicitly, particularly in the EAR module, but run 'mvn install' even if you are building virtually empty artifacts for the other components. In other words, get the whole build process working correctly first. Alternatively, the next best thing to do would be to remove the EAR module from your modules list for now until you have everything else to a stage where the repository has all of the artifacts required to build an EAR. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 9:42 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? Wait - even if I'm simply doing a compile? Why should it start trying to build an ear? I tried a "mvn compile" that results in all kinds of failures cause it tries to build up an ear (and there's no war/ejbs to include). The ear file building is linked to the compile lifecycle phase? -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 4:40 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? The modules need to be downloaded since they are dependencies at compile time (the default), even in an EAR package. Modules will never be picked up from their target directories (part of the design of Maven). You need to run 'mvn install' on the other modules to ensure they are in your local repository at least before running a build in the EAR module. Hope this helps. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 8:19 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? Still haven't seen any response - this has us wedged, can anyone shed any light on this for me? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 31, 2007 6:23 PM To: Maven Users List Subject: compile tries to bundle up the ear - should it? I'm running just compile but one module that has an ear artifact is trying to bundle up the ear file (which subsequently fails because the war and ejbs don't exist). Is this supposed to happen or is this something I've misconfigured: [INFO] [INFO] Building ltyApp_ear [INFO]task-segment: [compile] [INFO] Downloading: file:\\build.corp.upromise.com/maven2/lty/upErrorEJB/1.0-SNAPSHOT/upErro rEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/salesscriptEJB/1.0-SNAPSHOT/sa lesscriptEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/transferEJB/1.0-SNAPSHOT/trans ferEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/transactionEJB/1.0-SNAPSHOT/tr ansactionEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/CSREJB/1.0-SNAPSHOT/CSREJB-1.0 -SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/upAdminEJB/1.0-SNAPSHOT/upAdmi nEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/inboundenrollmentEJB/1.0-SNAPS HOT/inboundenrollmentEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/authserverEJB/1.0-SNAPSHOT/aut hserverEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/communityEJB/1.0-SNAPSHOT/comm unityEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/accountGuestEJB/1.0-SNAPSHOT/a ccountGuestEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.uprom
RE: compile tries to bundle up the ear - should it?
Wait - even if I'm simply doing a compile? Why should it start trying to build an ear? I tried a "mvn compile" that results in all kinds of failures cause it tries to build up an ear (and there's no war/ejbs to include). The ear file building is linked to the compile lifecycle phase? -Original Message- From: Greg Jones [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 4:40 PM To: 'Maven Users List' Subject: RE: compile tries to bundle up the ear - should it? The modules need to be downloaded since they are dependencies at compile time (the default), even in an EAR package. Modules will never be picked up from their target directories (part of the design of Maven). You need to run 'mvn install' on the other modules to ensure they are in your local repository at least before running a build in the EAR module. Hope this helps. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 8:19 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? Still haven't seen any response - this has us wedged, can anyone shed any light on this for me? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 31, 2007 6:23 PM To: Maven Users List Subject: compile tries to bundle up the ear - should it? I'm running just compile but one module that has an ear artifact is trying to bundle up the ear file (which subsequently fails because the war and ejbs don't exist). Is this supposed to happen or is this something I've misconfigured: [INFO] [INFO] Building ltyApp_ear [INFO]task-segment: [compile] [INFO] Downloading: file:\\build.corp.upromise.com/maven2/lty/upErrorEJB/1.0-SNAPSHOT/upErro rEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/salesscriptEJB/1.0-SNAPSHOT/sa lesscriptEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/transferEJB/1.0-SNAPSHOT/trans ferEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/transactionEJB/1.0-SNAPSHOT/tr ansactionEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/CSREJB/1.0-SNAPSHOT/CSREJB-1.0 -SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/upAdminEJB/1.0-SNAPSHOT/upAdmi nEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/inboundenrollmentEJB/1.0-SNAPS HOT/inboundenrollmentEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/authserverEJB/1.0-SNAPSHOT/aut hserverEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/communityEJB/1.0-SNAPSHOT/comm unityEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/accountGuestEJB/1.0-SNAPSHOT/a ccountGuestEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/testcellEJB/1.0-SNAPSHOT/testc ellEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/enrollmentEJB/1.0-SNAPSHOT/enr ollmentEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/partnerEJB/1.0-SNAPSHOT/partne rEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/groceryEJB/1.0-SNAPSHOT/grocer yEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/messageEJB/1.0-SNAPSHOT/messag eEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository
RE: compile tries to bundle up the ear - should it?
The modules need to be downloaded since they are dependencies at compile time (the default), even in an EAR package. Modules will never be picked up from their target directories (part of the design of Maven). You need to run 'mvn install' on the other modules to ensure they are in your local repository at least before running a build in the EAR module. Hope this helps. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Tuesday, 6 February 2007 8:19 AM To: Maven Users List Subject: RE: compile tries to bundle up the ear - should it? Still haven't seen any response - this has us wedged, can anyone shed any light on this for me? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 31, 2007 6:23 PM To: Maven Users List Subject: compile tries to bundle up the ear - should it? I'm running just compile but one module that has an ear artifact is trying to bundle up the ear file (which subsequently fails because the war and ejbs don't exist). Is this supposed to happen or is this something I've misconfigured: [INFO] [INFO] Building ltyApp_ear [INFO]task-segment: [compile] [INFO] Downloading: file:\\build.corp.upromise.com/maven2/lty/upErrorEJB/1.0-SNAPSHOT/upErro rEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/salesscriptEJB/1.0-SNAPSHOT/sa lesscriptEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/transferEJB/1.0-SNAPSHOT/trans ferEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/transactionEJB/1.0-SNAPSHOT/tr ansactionEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/CSREJB/1.0-SNAPSHOT/CSREJB-1.0 -SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/upAdminEJB/1.0-SNAPSHOT/upAdmi nEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/inboundenrollmentEJB/1.0-SNAPS HOT/inboundenrollmentEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/authserverEJB/1.0-SNAPSHOT/aut hserverEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/communityEJB/1.0-SNAPSHOT/comm unityEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/accountGuestEJB/1.0-SNAPSHOT/a ccountGuestEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/testcellEJB/1.0-SNAPSHOT/testc ellEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/enrollmentEJB/1.0-SNAPSHOT/enr ollmentEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/partnerEJB/1.0-SNAPSHOT/partne rEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/groceryEJB/1.0-SNAPSHOT/grocer yEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/messageEJB/1.0-SNAPSHOT/messag eEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/memberProfileEJB/1.0-SNAPSHOT/ memberProfileEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/ltyWebApp/1.0-SNAPSHOT/ltyWebA pp-1.0-SNAPSHOT.war [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.co
Re: compile tries to bundle up the ear - should it?
EJ Ciramella wrote: Still haven't seen any response - this has us wedged, can anyone shed any light on this for me? If you run "mvn " in some project/module subdirectory, you are assuming that all dependencies are built and installed, and therefore available either from your local repo, or from your other repositories. If this is not true, then you cannot build. If you are in the situation where "your" code builds, but "some else's" code doesn't, then you won't be able to use your .ear file anyway. If you don't need the .ear file yet, but do wish to run unit tests on "your" code, then maybe you should temparily change your packaging to "jar". If you want a more permanent solution, then make a separate artifact which just has the dependencies to pack the ear, but no code (except perhaps for some simple wrapping or debugging code) on its own... But to me it sounds simply as if you'd want to run "mvn" from a higher directory to get it to build all of your modules - or that you need to ensure that the other people deploy the results of their builds. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: compile tries to bundle up the ear - should it?
Still haven't seen any response - this has us wedged, can anyone shed any light on this for me? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 31, 2007 6:23 PM To: Maven Users List Subject: compile tries to bundle up the ear - should it? I'm running just compile but one module that has an ear artifact is trying to bundle up the ear file (which subsequently fails because the war and ejbs don't exist). Is this supposed to happen or is this something I've misconfigured: [INFO] [INFO] Building ltyApp_ear [INFO]task-segment: [compile] [INFO] Downloading: file:\\build.corp.upromise.com/maven2/lty/upErrorEJB/1.0-SNAPSHOT/upErro rEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/salesscriptEJB/1.0-SNAPSHOT/sa lesscriptEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/transferEJB/1.0-SNAPSHOT/trans ferEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/transactionEJB/1.0-SNAPSHOT/tr ansactionEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/CSREJB/1.0-SNAPSHOT/CSREJB-1.0 -SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/upAdminEJB/1.0-SNAPSHOT/upAdmi nEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/inboundenrollmentEJB/1.0-SNAPS HOT/inboundenrollmentEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/authserverEJB/1.0-SNAPSHOT/aut hserverEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/communityEJB/1.0-SNAPSHOT/comm unityEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/accountGuestEJB/1.0-SNAPSHOT/a ccountGuestEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/testcellEJB/1.0-SNAPSHOT/testc ellEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/enrollmentEJB/1.0-SNAPSHOT/enr ollmentEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/partnerEJB/1.0-SNAPSHOT/partne rEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/groceryEJB/1.0-SNAPSHOT/grocer yEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/messageEJB/1.0-SNAPSHOT/messag eEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/memberProfileEJB/1.0-SNAPSHOT/ memberProfileEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/ltyWebApp/1.0-SNAPSHOT/ltyWebA pp-1.0-SNAPSHOT.war [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/withdrawalEJB/1.0-SNAPSHOT/wit hdrawalEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org
compile tries to bundle up the ear - should it?
I'm running just compile but one module that has an ear artifact is trying to bundle up the ear file (which subsequently fails because the war and ejbs don't exist). Is this supposed to happen or is this something I've misconfigured: [INFO] [INFO] Building ltyApp_ear [INFO]task-segment: [compile] [INFO] Downloading: file:\\build.corp.upromise.com/maven2/lty/upErrorEJB/1.0-SNAPSHOT/upErro rEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/salesscriptEJB/1.0-SNAPSHOT/sa lesscriptEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/transferEJB/1.0-SNAPSHOT/trans ferEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/transactionEJB/1.0-SNAPSHOT/tr ansactionEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/CSREJB/1.0-SNAPSHOT/CSREJB-1.0 -SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/upAdminEJB/1.0-SNAPSHOT/upAdmi nEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/inboundenrollmentEJB/1.0-SNAPS HOT/inboundenrollmentEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/authserverEJB/1.0-SNAPSHOT/aut hserverEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/communityEJB/1.0-SNAPSHOT/comm unityEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/accountGuestEJB/1.0-SNAPSHOT/a ccountGuestEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/testcellEJB/1.0-SNAPSHOT/testc ellEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/enrollmentEJB/1.0-SNAPSHOT/enr ollmentEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/partnerEJB/1.0-SNAPSHOT/partne rEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/groceryEJB/1.0-SNAPSHOT/grocer yEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/messageEJB/1.0-SNAPSHOT/messag eEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/memberProfileEJB/1.0-SNAPSHOT/ memberProfileEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/ltyWebApp/1.0-SNAPSHOT/ltyWebA pp-1.0-SNAPSHOT.war [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) Downloading: file:\\build.corp.upromise.com/maven2/lty/withdrawalEJB/1.0-SNAPSHOT/wit hdrawalEJB-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository central (file:\\build.corp.upromise.com/maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 lty ltyApp 1.0-SNAPSHOT EAR ear ltyApp_ear http://www.upromise.com 1.0-SNAPSHOT
