On 31/12/2010 4:27 PM, Steve Cohen wrote:
No. Sorry. But thanks.
I thought I'd struck gold with that appassembler thing and by the time
I figured out that I hadn't I had forgotten all about your sample.
Now that I look at it, it seems that what you are doing and what I am
doing are not tha
On Sat, Jan 1, 2011 at 12:22 AM, Steve Cohen wrote:
> Well, all I can say is that I was doing approximately as you have described
> and it didn't really work.
>
> I was using assembly:assembly (single for some reason failed to bring in
> everything needed - perhaps the mistake was mine), I also us
No. Sorry. But thanks.
I thought I'd struck gold with that appassembler thing and by the time I
figured out that I hadn't I had forgotten all about your sample.
Now that I look at it, it seems that what you are doing and what I am
doing are not that different. And your example shows the us
Did you try the POM and assembly that I sent you?
It is pretty straightforward.
Ron
On 31/12/2010 2:47 PM, Steve Cohen wrote:
Yes, you are basically right. You can't get away from the need of the
aggregator project. And the dual testing was caused by specifying too
many phases on the command
Yes, you are basically right. You can't get away from the need of the
aggregator project. And the dual testing was caused by specifying too
many phases on the command line.
I was overly exuberant in my earlier praise of appassembler. It
appeared to do what I want, but the way I had it set u
Never do anything interesting in a aggregate project (what I think
you're calling an uber-project). Make a separate leaf project, listed
last in the list of modules, to run assembly:single.
On Fri, Dec 31, 2010 at 8:52 AM, Steve Cohen wrote:
> Well, all I can say is that I was doing approximate
Install implies package.
If you run
mvn clean install package
Yoyr tests will run twicr because you asked maven to run them twice
Also you should be binding assembly: single to tgen lifecycle, not invoking
directly
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random
Well, all I can say is that I was doing approximately as you have
described and it didn't really work.
I was using assembly:assembly (single for some reason failed to bring in
everything needed - perhaps the mistake was mine), I also used a
separate uber-project to do nothing but the assembly.
I do this all the time.
I use assembly:single.
I run it from a project that has pretty much nothing else in it except
the assembly run.
For shared config files and such, I package them up as zip files, push
them to nexus, and stage them with dependency:unpack.
For jar file dependencies that can
Now that was good, but the question is why can't something like that be
available through the assembly plugin itself?
Build the main jar and its dependencies, install the non-third party
jars into the local repository, then pull them back out into an assembly
staging area, together with third
On 30/12/2010 5:05 PM, Dan Tran wrote:
use a combination of antrun, dependency plugin to prepare a staging
directory, then use the assembly to create the package.
Way too much work. Not needed. Maven can build batch jobs by itself.
Ron
-D
On Thu, Dec 30, 2010 at 1:55 PM, Steve Cohen wrote:
This is very similar to what we have done with out portal that consists
of 70+ maven projects that produce libraries, servlets, portlets and
batch jobs.
The batch jobs include:
- A batch job that is run on a third party's server that extracts data
from another 3rd party's database and puts the
BINGO!
Thanks so much, Dennis for pointing me in the RIGHT direction!!
This is simple, just what I wanted.
The last piece of the puzzle was the need to use the flat
Just what I wanted in under 2 hours, as opposed to two days fighting
with the complexities of the assembler plugin!
Happy
On 2010-12-31 00:08, Steve Cohen wrote:
> I think this is going to work.
>
> I absolutely don't need any of the shellscript generation (it would be
> nice to be able to turn it off) but I can ignore that. The creation of
> the repository inside the target is slick, and I assume I can use that
> t
I think this is going to work.
I absolutely don't need any of the shellscript generation (it would be
nice to be able to turn it off) but I can ignore that. The creation of
the repository inside the target is slick, and I assume I can use that
to suck all the jars into the assembly plugin.
On Thu, Dec 30, 2010 at 2:23 PM, Steve Cohen wrote:
> Thanks again, Dennis. I've now read the documentation more carefully and
> this doesn't look as though it does any actual packaging into an archive (be
> it zip, jar, tar, etc.) It seems to be ALL about the launch script and
> might have been
Thanks again, Dennis. I've now read the documentation more carefully
and this doesn't look as though it does any actual packaging into an
archive (be it zip, jar, tar, etc.) It seems to be ALL about the launch
script and might have been the way to go before I developed all this by
hand with c
use a combination of antrun, dependency plugin to prepare a staging
directory, then use the assembly to create the package.
-D
On Thu, Dec 30, 2010 at 1:55 PM, Steve Cohen wrote:
> On 12/30/2010 02:37 PM, Dennis Lundberg wrote:
> Thanks, Dennis. This looks very interesting on the surface. Befo
On 12/30/2010 02:37 PM, Dennis Lundberg wrote:
Thanks, Dennis. This looks very interesting on the surface. Before I
dive too deeply into it, though, let me ask you some questions about it.
I am already using commons-daemon to "daemonize" the thing and the
script to launch the thing is alread
Hi Steve
May I suggest that you have a look at the Appassembler Maven Plugin for
your batch processing application.
http://mojo.codehaus.org/appassembler/appassembler-maven-plugin/usage-program.html
On 2010-12-30 21:16, Steve Cohen wrote:
> After a very frustrating couple of days trying to under
After a very frustrating couple of days trying to understand the new
features of the assembly plugin, let me try to specify what I am TRYING
to do and see if there isn't a better (i.e. more mavenish) way of doing
it. Maven is flexible as long as you don't stray too far out of the
beaten path.
21 matches
Mail list logo
