subject:"Re\: assembly \- plugin"

You should not traverse the file structure but rely on dependencies! It
should work building when just checking out this specific module from scm.

/Anders

On Thu, Apr 28, 2011 at 18:01, Dmitriy Neretin <
dmitriy.nere...@googlemail.com> wrote:

> Holy sh... :)) Of cource it works :) But it is not really that what I
> wanted
> but it's not important now :) Thank you very much. But I still don't
> understand why the moduleSet didn't work... Strange (How old is the maven
> documentation). With this variable ${project.parent.basedir} I can get
> access on parent directory structure. So I hope to solve my problems
> completly!
>
> Have a nice day!
>
> 2011/4/28 Anders Hammar 
>
> > No, you should not use moduleSet but dependencySet (or similar, I'm not
> at
> > my computer and cannot check syntax).
> >
> > /Anders (mobile)
> > Den 28 apr 2011 17.14 skrev "Dmitriy Neretin" <
> > dmitriy.nere...@googlemail.com>:
> > > Well I just removed the assembly declaration from the parent POM. I
> just
> > > left there the new distribution module. When I change to the
> distribution
> > > folder and execute mvn assembly:single or mvn clean package I get this:
> > >
> > > [INFO] Reading assembly descriptor: config/assembly.xml
> > > [WARNING] The following patterns were never triggered in this artifact
> > > inclusion filter:
> > > o 'A'
> > >
> > > [WARNING] The following patterns were never triggered in this artifact
> > > inclusion filter:
> > > o 'A'
> > >
> > > [WARNING] NOTE: Currently, inclusion of module dependencies may produce
> > > unpredictable results if a version conflict occu
> > > rs.
> > > [INFO]
> > >
> 
> > > [ERROR] BUILD ERROR
> > > [INFO]
> > >
> 
> > > [INFO] Failed to create assembly: Error creating assembly archive test:
> > You
> > > must set at least one file.
> > >
> > > Well the descriptor war reas only once, but we still see the double
> > warning
> > > about failed trigger :(
> > >
> > > But the assembly configuration is right:
> > >
> > > 
> > > 
> > > true
> > > 
> > > A
> > > 
> > > 
> > > tools/caseviewer
> > > false
> > > 
> > > 
> > > 
> > >
> > >
> > > 2011/4/28 Anders Hammar 
> > >
> > >> Ok, the log output indicates that the assembly is executed twice
> (there
> > is
> > >> a
> > >> warning about the same id used twice).
> > >> Start by removing any assembly configuration from your parent, to keep
> > >> things simple. Just add it yo your module. When you get that to work
> you
> > >> could start by doing advanced stuff.
> > >>
> > >> /Anders
> > >>
> > >> On Thu, Apr 28, 2011 at 15:37, Dmitriy Neretin <
> > >> dmitriy.nere...@googlemail.com> wrote:
> > >>
> > >> > Thanks for the reply!
> > >> >
> > >> > 2011/4/28 Anders Hammar 
> > >> >
> > >> > > The "declaration" in your parent, is that a binding? Or is it in
> > >> > > pluginManagement?
> > >> > >
> > >> >
> > >> > Well I don't really understand what do you mean with binding :) The
> > >> > assembly
> > >> > plugin is declared between the  tags:
> > >> >
> > >> > 
> > >> > 
> > >> > Assembly declaration
> > >> > 
> > >> > 
> > >> >
> > >> >
> > >> > >
> > >> > > Why are configuring the descriptor in the parent? Are you trying
> to
> > >> make
> > >> > an
> > >> > > assembly in the parent as well as in the child?
> > >> > >
> > >> >
> > >> > I configure the descriptor in the parent because I have read this
> > under
> > >> the
> > >> > link below (maven documentation). And I am not really shure it is
> > >> right...
> > >> > I
> > >> > am trying now to make an assembly from the child project but the
> main
> > >> > target
> > >> > is preety simple: After compiling (mvn install) of the whole project
> > >> (from
> > >> > the parent level) I want to find in the distribution directory some
> > >> > artifacts like binaries, some skripts, zips etc. I have already used
> > this
> > >> > plugin for a child project to build a zip file and it worked :(
> > >> >
> > >> > >
> > >> > > /Anders
> > >> > > On Thu, Apr 28, 2011 at 15:03, Dmitriy Neretin <
> > >> > > dmitriy.nere...@googlemail.com> wrote:
> > >> > >
> > >> > > > Hello everybody,
> > >> > > >
> > >> > > > I have a problem with the assembly plugin. I used the following
> > >> > > > documentation:
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> >
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html
> > >> > > >
> > >> > > > I created the additional module to keep my assembly in the
> parent
> > >> POM:
> > >> > > >
> > >> > > > ...
> > >> > > > 
> > >> > > > A
> > >> > > > B
> > >> > > > C
> > >> > > > distribution
> > >> > > > 
> > >> > > > ...
> > >> > > >
> > >> > > > and declared the assembly plugin in the parent POM:
> > >> > > >
> > >> > > > 
> > >> > > > org.apache.maven.plugins
> > >> > > > maven-assembly-plugin
> > >> > > > 2.2.1
> > >> > > > 
> > >> > > > con

Re: Assembly Plugin Problem with multi module Project

2011-04-28 Thread Dmitriy Neretin

Holy sh... :)) Of cource it works :) But it is not really that what I wanted
but it's not important now :) Thank you very much. But I still don't
understand why the moduleSet didn't work... Strange (How old is the maven
documentation). With this variable ${project.parent.basedir} I can get
access on parent directory structure. So I hope to solve my problems
completly!

Have a nice day!

2011/4/28 Anders Hammar 

> No, you should not use moduleSet but dependencySet (or similar, I'm not at
> my computer and cannot check syntax).
>
> /Anders (mobile)
> Den 28 apr 2011 17.14 skrev "Dmitriy Neretin" <
> dmitriy.nere...@googlemail.com>:
> > Well I just removed the assembly declaration from the parent POM. I just
> > left there the new distribution module. When I change to the distribution
> > folder and execute mvn assembly:single or mvn clean package I get this:
> >
> > [INFO] Reading assembly descriptor: config/assembly.xml
> > [WARNING] The following patterns were never triggered in this artifact
> > inclusion filter:
> > o 'A'
> >
> > [WARNING] The following patterns were never triggered in this artifact
> > inclusion filter:
> > o 'A'
> >
> > [WARNING] NOTE: Currently, inclusion of module dependencies may produce
> > unpredictable results if a version conflict occu
> > rs.
> > [INFO]
> > 
> > [ERROR] BUILD ERROR
> > [INFO]
> > 
> > [INFO] Failed to create assembly: Error creating assembly archive test:
> You
> > must set at least one file.
> >
> > Well the descriptor war reas only once, but we still see the double
> warning
> > about failed trigger :(
> >
> > But the assembly configuration is right:
> >
> > 
> > 
> > true
> > 
> > A
> > 
> > 
> > tools/caseviewer
> > false
> > 
> > 
> > 
> >
> >
> > 2011/4/28 Anders Hammar 
> >
> >> Ok, the log output indicates that the assembly is executed twice (there
> is
> >> a
> >> warning about the same id used twice).
> >> Start by removing any assembly configuration from your parent, to keep
> >> things simple. Just add it yo your module. When you get that to work you
> >> could start by doing advanced stuff.
> >>
> >> /Anders
> >>
> >> On Thu, Apr 28, 2011 at 15:37, Dmitriy Neretin <
> >> dmitriy.nere...@googlemail.com> wrote:
> >>
> >> > Thanks for the reply!
> >> >
> >> > 2011/4/28 Anders Hammar 
> >> >
> >> > > The "declaration" in your parent, is that a binding? Or is it in
> >> > > pluginManagement?
> >> > >
> >> >
> >> > Well I don't really understand what do you mean with binding :) The
> >> > assembly
> >> > plugin is declared between the  tags:
> >> >
> >> > 
> >> > 
> >> > Assembly declaration
> >> > 
> >> > 
> >> >
> >> >
> >> > >
> >> > > Why are configuring the descriptor in the parent? Are you trying to
> >> make
> >> > an
> >> > > assembly in the parent as well as in the child?
> >> > >
> >> >
> >> > I configure the descriptor in the parent because I have read this
> under
> >> the
> >> > link below (maven documentation). And I am not really shure it is
> >> right...
> >> > I
> >> > am trying now to make an assembly from the child project but the main
> >> > target
> >> > is preety simple: After compiling (mvn install) of the whole project
> >> (from
> >> > the parent level) I want to find in the distribution directory some
> >> > artifacts like binaries, some skripts, zips etc. I have already used
> this
> >> > plugin for a child project to build a zip file and it worked :(
> >> >
> >> > >
> >> > > /Anders
> >> > > On Thu, Apr 28, 2011 at 15:03, Dmitriy Neretin <
> >> > > dmitriy.nere...@googlemail.com> wrote:
> >> > >
> >> > > > Hello everybody,
> >> > > >
> >> > > > I have a problem with the assembly plugin. I used the following
> >> > > > documentation:
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
>
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html
> >> > > >
> >> > > > I created the additional module to keep my assembly in the parent
> >> POM:
> >> > > >
> >> > > > ...
> >> > > > 
> >> > > > A
> >> > > > B
> >> > > > C
> >> > > > distribution
> >> > > > 
> >> > > > ...
> >> > > >
> >> > > > and declared the assembly plugin in the parent POM:
> >> > > >
> >> > > > 
> >> > > > org.apache.maven.plugins
> >> > > > maven-assembly-plugin
> >> > > > 2.2.1
> >> > > > 
> >> > > > config/assembly.xml
> >> > > > 
> >> > > > 
> >> > > >
> >> > > > after that I declared the new POM in the distribution directory
> where
> >> I
> >> > > > also
> >> > > > referenced the parent POM:
> >> > > >
> >> > > > 
> >> > > > GROUPNAME
> >> > > > NAME
> >> > > > VERSION
> >> > > > ../pom.xml
> >> > > > 
> >> > > >
> >> > > > and also declared the assembly plugin:
> >> > > >
> >> > > > 
> >> > > > maven-assembly-plugin
> >> > > > 
> >> > > > 
> >> > > > create-assembly
> >> > > > package
> >> > > > 
> >> > > > single
> >> > > > 
> >> > > > 
> >> > > > 
> >> > > > conf

Re: Assembly Plugin Problem with multi module Project

No, you should not use moduleSet but dependencySet (or similar, I'm not at
my computer and cannot check syntax).

/Anders (mobile)
Den 28 apr 2011 17.14 skrev "Dmitriy Neretin" <
dmitriy.nere...@googlemail.com>:
> Well I just removed the assembly declaration from the parent POM. I just
> left there the new distribution module. When I change to the distribution
> folder and execute mvn assembly:single or mvn clean package I get this:
>
> [INFO] Reading assembly descriptor: config/assembly.xml
> [WARNING] The following patterns were never triggered in this artifact
> inclusion filter:
> o 'A'
>
> [WARNING] The following patterns were never triggered in this artifact
> inclusion filter:
> o 'A'
>
> [WARNING] NOTE: Currently, inclusion of module dependencies may produce
> unpredictable results if a version conflict occu
> rs.
> [INFO]
> 
> [ERROR] BUILD ERROR
> [INFO]
> 
> [INFO] Failed to create assembly: Error creating assembly archive test:
You
> must set at least one file.
>
> Well the descriptor war reas only once, but we still see the double
warning
> about failed trigger :(
>
> But the assembly configuration is right:
>
> 
> 
> true
> 
> A
> 
> 
> tools/caseviewer
> false
> 
> 
> 
>
>
> 2011/4/28 Anders Hammar 
>
>> Ok, the log output indicates that the assembly is executed twice (there
is
>> a
>> warning about the same id used twice).
>> Start by removing any assembly configuration from your parent, to keep
>> things simple. Just add it yo your module. When you get that to work you
>> could start by doing advanced stuff.
>>
>> /Anders
>>
>> On Thu, Apr 28, 2011 at 15:37, Dmitriy Neretin <
>> dmitriy.nere...@googlemail.com> wrote:
>>
>> > Thanks for the reply!
>> >
>> > 2011/4/28 Anders Hammar 
>> >
>> > > The "declaration" in your parent, is that a binding? Or is it in
>> > > pluginManagement?
>> > >
>> >
>> > Well I don't really understand what do you mean with binding :) The
>> > assembly
>> > plugin is declared between the  tags:
>> >
>> > 
>> > 
>> > Assembly declaration
>> > 
>> > 
>> >
>> >
>> > >
>> > > Why are configuring the descriptor in the parent? Are you trying to
>> make
>> > an
>> > > assembly in the parent as well as in the child?
>> > >
>> >
>> > I configure the descriptor in the parent because I have read this under
>> the
>> > link below (maven documentation). And I am not really shure it is
>> right...
>> > I
>> > am trying now to make an assembly from the child project but the main
>> > target
>> > is preety simple: After compiling (mvn install) of the whole project
>> (from
>> > the parent level) I want to find in the distribution directory some
>> > artifacts like binaries, some skripts, zips etc. I have already used
this
>> > plugin for a child project to build a zip file and it worked :(
>> >
>> > >
>> > > /Anders
>> > > On Thu, Apr 28, 2011 at 15:03, Dmitriy Neretin <
>> > > dmitriy.nere...@googlemail.com> wrote:
>> > >
>> > > > Hello everybody,
>> > > >
>> > > > I have a problem with the assembly plugin. I used the following
>> > > > documentation:
>> > > >
>> > > >
>> > >
>> >
>>
http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html
>> > > >
>> > > > I created the additional module to keep my assembly in the parent
>> POM:
>> > > >
>> > > > ...
>> > > > 
>> > > > A
>> > > > B
>> > > > C
>> > > > distribution
>> > > > 
>> > > > ...
>> > > >
>> > > > and declared the assembly plugin in the parent POM:
>> > > >
>> > > > 
>> > > > org.apache.maven.plugins
>> > > > maven-assembly-plugin
>> > > > 2.2.1
>> > > > 
>> > > > config/assembly.xml
>> > > > 
>> > > > 
>> > > >
>> > > > after that I declared the new POM in the distribution directory
where
>> I
>> > > > also
>> > > > referenced the parent POM:
>> > > >
>> > > > 
>> > > > GROUPNAME
>> > > > NAME
>> > > > VERSION
>> > > > ../pom.xml
>> > > > 
>> > > >
>> > > > and also declared the assembly plugin:
>> > > >
>> > > > 
>> > > > maven-assembly-plugin
>> > > > 
>> > > > 
>> > > > create-assembly
>> > > > package
>> > > > 
>> > > > single
>> > > > 
>> > > > 
>> > > > 
>> > > > config/assembly.xml
>> > > > 
>> > > > 
>> > > > 
>> > > > 
>> > > > 
>> > > >
>> > > > The assembly.xml is placed in the distribution/config directory and
>> > looks
>> > > > like this:
>> > > >
>> > > > test
>> > > >
>> > > > 
>> > > > dir
>> > > > 
>> > > >
>> > > > false
>> > > > 
>> > > > 
>> > > > true
>> > > > 
>> > > > A
>> > > > 
>> > > > 
>> > > > TOOLS
>> > > > false
>> > > > 
>> > > > 
>> > > > 
>> > > >
>> > > > If I execute mvn clean package I get following error message:
>> > > >
>> > > > [INFO] Reading assembly descriptor: config/assembly.xml
>> > > > [WARNING] The assembly id test is used more than once.
>> > > > [WARNING] The following patterns were never triggered in this
>> artifact
>> > > > inclusion filter:
>> > > > o 'A'
>> > > >
>> > > >

Re: Assembly Plugin Problem with multi module Project

2011-04-28 Thread Dmitriy Neretin

Well I just removed the assembly declaration from the parent POM. I just
left there the new distribution module. When I change to the distribution
folder and execute mvn assembly:single or mvn clean package I get this:

[INFO] Reading assembly descriptor: config/assembly.xml
[WARNING] The following patterns were never triggered in this artifact
inclusion filter:
o  'A'

[WARNING] The following patterns were never triggered in this artifact
inclusion filter:
o  'A'

[WARNING] NOTE: Currently, inclusion of module dependencies may produce
unpredictable results if a version conflict occu
rs.
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Failed to create assembly: Error creating assembly archive test: You
must set at least one file.

Well the descriptor war reas only once, but we still see the double warning
about failed trigger :(

But the assembly configuration is right:



true

A


tools/caseviewer
false


 


2011/4/28 Anders Hammar 

> Ok, the log output indicates that the assembly is executed twice (there is
> a
> warning about the same id used twice).
> Start by removing any assembly configuration from your parent, to keep
> things simple. Just add it yo your module. When you get that to work you
> could start by doing advanced stuff.
>
> /Anders
>
> On Thu, Apr 28, 2011 at 15:37, Dmitriy Neretin <
> dmitriy.nere...@googlemail.com> wrote:
>
> > Thanks for the reply!
> >
> > 2011/4/28 Anders Hammar 
> >
> > > The "declaration" in your parent, is that a binding? Or is it in
> > > pluginManagement?
> > >
> >
> > Well I don't really understand what do you mean with binding :) The
> > assembly
> > plugin is declared between the  tags:
> >
> > 
> > 
> > Assembly declaration
> > 
> > 
> >
> >
> > >
> > > Why are configuring the descriptor in the parent? Are you trying to
> make
> > an
> > > assembly in the parent as well as in the child?
> > >
> >
> > I configure the descriptor in the parent because I have read this under
> the
> > link below (maven documentation). And I am not really shure it is
> right...
> > I
> > am trying now to make an assembly from the child project but the main
> > target
> > is preety simple: After compiling (mvn install) of the whole project
> (from
> > the parent level) I want to find in the distribution directory some
> > artifacts like binaries, some skripts, zips etc. I have already used this
> > plugin for a child project to build a zip file and it worked :(
> >
> > >
> > > /Anders
> > > On Thu, Apr 28, 2011 at 15:03, Dmitriy Neretin <
> > > dmitriy.nere...@googlemail.com> wrote:
> > >
> > > > Hello everybody,
> > > >
> > > > I have a problem with the assembly plugin. I used the following
> > > > documentation:
> > > >
> > > >
> > >
> >
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html
> > > >
> > > > I created the additional module to keep my assembly in the parent
> POM:
> > > >
> > > > ...
> > > > 
> > > >  A
> > > >  B
> > > >  C
> > > >  distribution
> > > > 
> > > > ...
> > > >
> > > > and declared the assembly plugin in the parent POM:
> > > >
> > > > 
> > > >org.apache.maven.plugins
> > > >maven-assembly-plugin
> > > >2.2.1
> > > >
> > > >  config/assembly.xml
> > > >
> > > > 
> > > >
> > > > after that I declared the new POM in the distribution directory where
> I
> > > > also
> > > > referenced the parent POM:
> > > >
> > > > 
> > > >GROUPNAME
> > > >NAME
> > > >VERSION
> > > >../pom.xml
> > > > 
> > > >
> > > > and also declared the assembly plugin:
> > > >
> > > > 
> > > >  maven-assembly-plugin
> > > >  
> > > >
> > > >  create-assembly
> > > >  package
> > > >  
> > > >single
> > > >  
> > > >  
> > > >
> > > >  config/assembly.xml
> > > >
> > > >  
> > > >
> > > >  
> > > > 
> > > >
> > > > The assembly.xml is placed in the distribution/config directory and
> > looks
> > > > like this:
> > > >
> > > >test
> > > >
> > > >
> > > >dir
> > > >
> > > >
> > > > false
> > > >
> > > >
> > > >true
> > > >
> > > >A
> > > >
> > > >
> > > >TOOLS
> > > >false
> > > >
> > > >
> > > >
> > > >
> > > > If I execute mvn clean package I get following error message:
> > > >
> > > > [INFO] Reading assembly descriptor: config/assembly.xml
> > > > [WARNING] The assembly id test is used more than once.
> > > > [WARNING] The following patterns were never triggered in this
> artifact
> > > > inclusion filter:
> > > > o  'A'
> > > >
>

Re: Assembly Plugin Problem with multi module Project

Ok, the log output indicates that the assembly is executed twice (there is a
warning about the same id used twice).
Start by removing any assembly configuration from your parent, to keep
things simple. Just add it yo your module. When you get that to work you
could start by doing advanced stuff.

/Anders

On Thu, Apr 28, 2011 at 15:37, Dmitriy Neretin <
dmitriy.nere...@googlemail.com> wrote:

> Thanks for the reply!
>
> 2011/4/28 Anders Hammar 
>
> > The "declaration" in your parent, is that a binding? Or is it in
> > pluginManagement?
> >
>
> Well I don't really understand what do you mean with binding :) The
> assembly
> plugin is declared between the  tags:
>
> 
> 
> Assembly declaration
> 
> 
>
>
> >
> > Why are configuring the descriptor in the parent? Are you trying to make
> an
> > assembly in the parent as well as in the child?
> >
>
> I configure the descriptor in the parent because I have read this under the
> link below (maven documentation). And I am not really shure it is right...
> I
> am trying now to make an assembly from the child project but the main
> target
> is preety simple: After compiling (mvn install) of the whole project (from
> the parent level) I want to find in the distribution directory some
> artifacts like binaries, some skripts, zips etc. I have already used this
> plugin for a child project to build a zip file and it worked :(
>
> >
> > /Anders
> > On Thu, Apr 28, 2011 at 15:03, Dmitriy Neretin <
> > dmitriy.nere...@googlemail.com> wrote:
> >
> > > Hello everybody,
> > >
> > > I have a problem with the assembly plugin. I used the following
> > > documentation:
> > >
> > >
> >
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html
> > >
> > > I created the additional module to keep my assembly in the parent POM:
> > >
> > > ...
> > > 
> > >  A
> > >  B
> > >  C
> > >  distribution
> > > 
> > > ...
> > >
> > > and declared the assembly plugin in the parent POM:
> > >
> > > 
> > >org.apache.maven.plugins
> > >maven-assembly-plugin
> > >2.2.1
> > >
> > >  config/assembly.xml
> > >
> > > 
> > >
> > > after that I declared the new POM in the distribution directory where I
> > > also
> > > referenced the parent POM:
> > >
> > > 
> > >GROUPNAME
> > >NAME
> > >VERSION
> > >../pom.xml
> > > 
> > >
> > > and also declared the assembly plugin:
> > >
> > > 
> > >  maven-assembly-plugin
> > >  
> > >
> > >  create-assembly
> > >  package
> > >  
> > >single
> > >  
> > >  
> > >
> > >  config/assembly.xml
> > >
> > >  
> > >
> > >  
> > > 
> > >
> > > The assembly.xml is placed in the distribution/config directory and
> looks
> > > like this:
> > >
> > >test
> > >
> > >
> > >dir
> > >
> > >
> > > false
> > >
> > >
> > >true
> > >
> > >A
> > >
> > >
> > >TOOLS
> > >false
> > >
> > >
> > >
> > >
> > > If I execute mvn clean package I get following error message:
> > >
> > > [INFO] Reading assembly descriptor: config/assembly.xml
> > > [WARNING] The assembly id test is used more than once.
> > > [WARNING] The following patterns were never triggered in this artifact
> > > inclusion filter:
> > > o  'A'
> > >
> > > [WARNING] The following patterns were never triggered in this artifact
> > > inclusion filter:
> > > o  'A'
> > >
> > > [WARNING] NOTE: Currently, inclusion of module dependencies may produce
> > > unpredictable results if a version conflict occu
> > > rs.
> > > [INFO]
> > >
> 
> > > [ERROR] BUILD ERROR
> > > [INFO]
> > >
> 
> > > [INFO] Failed to create assembly: Error creating assembly archive test:
> > You
> > > must set at least one file.
> > >
> > > [INFO]
> > >
> 
> > >
> > > If I execute mvn assembly:single then the message that assembly id used
> > > more
> > > than once disappears.
> > > I use Maven 2.2.1 on WinXp Pro
> > >
> > > Can somebody help me?
> > >
> >
>

Re: Assembly Plugin Problem with multi module Project

2011-04-28 Thread Dmitriy Neretin

Thanks for the reply!

2011/4/28 Anders Hammar 

> The "declaration" in your parent, is that a binding? Or is it in
> pluginManagement?
>

Well I don't really understand what do you mean with binding :) The assembly
plugin is declared between the  tags:



Assembly declaration




>
> Why are configuring the descriptor in the parent? Are you trying to make an
> assembly in the parent as well as in the child?
>

I configure the descriptor in the parent because I have read this under the
link below (maven documentation). And I am not really shure it is right... I
am trying now to make an assembly from the child project but the main target
is preety simple: After compiling (mvn install) of the whole project (from
the parent level) I want to find in the distribution directory some
artifacts like binaries, some skripts, zips etc. I have already used this
plugin for a child project to build a zip file and it worked :(

>
> /Anders
> On Thu, Apr 28, 2011 at 15:03, Dmitriy Neretin <
> dmitriy.nere...@googlemail.com> wrote:
>
> > Hello everybody,
> >
> > I have a problem with the assembly plugin. I used the following
> > documentation:
> >
> >
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html
> >
> > I created the additional module to keep my assembly in the parent POM:
> >
> > ...
> > 
> >  A
> >  B
> >  C
> >  distribution
> > 
> > ...
> >
> > and declared the assembly plugin in the parent POM:
> >
> > 
> >org.apache.maven.plugins
> >maven-assembly-plugin
> >2.2.1
> >
> >  config/assembly.xml
> >
> > 
> >
> > after that I declared the new POM in the distribution directory where I
> > also
> > referenced the parent POM:
> >
> > 
> >GROUPNAME
> >NAME
> >VERSION
> >../pom.xml
> > 
> >
> > and also declared the assembly plugin:
> >
> > 
> >  maven-assembly-plugin
> >  
> >
> >  create-assembly
> >  package
> >  
> >single
> >  
> >  
> >
> >  config/assembly.xml
> >
> >  
> >
> >  
> > 
> >
> > The assembly.xml is placed in the distribution/config directory and looks
> > like this:
> >
> >test
> >
> >
> >dir
> >
> >
> > false
> >
> >
> >true
> >
> >A
> >
> >
> >TOOLS
> >false
> >
> >
> >
> >
> > If I execute mvn clean package I get following error message:
> >
> > [INFO] Reading assembly descriptor: config/assembly.xml
> > [WARNING] The assembly id test is used more than once.
> > [WARNING] The following patterns were never triggered in this artifact
> > inclusion filter:
> > o  'A'
> >
> > [WARNING] The following patterns were never triggered in this artifact
> > inclusion filter:
> > o  'A'
> >
> > [WARNING] NOTE: Currently, inclusion of module dependencies may produce
> > unpredictable results if a version conflict occu
> > rs.
> > [INFO]
> > 
> > [ERROR] BUILD ERROR
> > [INFO]
> > 
> > [INFO] Failed to create assembly: Error creating assembly archive test:
> You
> > must set at least one file.
> >
> > [INFO]
> > 
> >
> > If I execute mvn assembly:single then the message that assembly id used
> > more
> > than once disappears.
> > I use Maven 2.2.1 on WinXp Pro
> >
> > Can somebody help me?
> >
>

Re: Assembly Plugin Problem with multi module Project

The "declaration" in your parent, is that a binding? Or is it in
pluginManagement?

Why are configuring the descriptor in the parent? Are you trying to make an
assembly in the parent as well as in the child?

/Anders
On Thu, Apr 28, 2011 at 15:03, Dmitriy Neretin <
dmitriy.nere...@googlemail.com> wrote:

> Hello everybody,
>
> I have a problem with the assembly plugin. I used the following
> documentation:
>
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html
>
> I created the additional module to keep my assembly in the parent POM:
>
> ...
> 
>  A
>  B
>  C
>  distribution
> 
> ...
>
> and declared the assembly plugin in the parent POM:
>
> 
>org.apache.maven.plugins
>maven-assembly-plugin
>2.2.1
>
>  config/assembly.xml
>
> 
>
> after that I declared the new POM in the distribution directory where I
> also
> referenced the parent POM:
>
> 
>GROUPNAME
>NAME
>VERSION
>../pom.xml
> 
>
> and also declared the assembly plugin:
>
> 
>  maven-assembly-plugin
>  
>
>  create-assembly
>  package
>  
>single
>  
>  
>
>  config/assembly.xml
>
>  
>
>  
> 
>
> The assembly.xml is placed in the distribution/config directory and looks
> like this:
>
>test
>
>
>dir
>
>
> false
>
>
>true
>
>A
>
>
>TOOLS
>false
>
>
>
>
> If I execute mvn clean package I get following error message:
>
> [INFO] Reading assembly descriptor: config/assembly.xml
> [WARNING] The assembly id test is used more than once.
> [WARNING] The following patterns were never triggered in this artifact
> inclusion filter:
> o  'A'
>
> [WARNING] The following patterns were never triggered in this artifact
> inclusion filter:
> o  'A'
>
> [WARNING] NOTE: Currently, inclusion of module dependencies may produce
> unpredictable results if a version conflict occu
> rs.
> [INFO]
> 
> [ERROR] BUILD ERROR
> [INFO]
> 
> [INFO] Failed to create assembly: Error creating assembly archive test: You
> must set at least one file.
>
> [INFO]
> 
>
> If I execute mvn assembly:single then the message that assembly id used
> more
> than once disappears.
> I use Maven 2.2.1 on WinXp Pro
>
> Can somebody help me?
>

Re: assembly plugin broken going from 2.2.1 to 3.0.2

2011-03-03 Thread Dennis Lundberg

Hi

I'm assuming that org.ferris:ferris-assemblies:jar:0.0.3 is a dependency
that you have configured for the assembly-plugin. If that is the case
then with Maven 3 that dependency must be available in a repository that
is defined as a . If it is only available in a normal
 Maven 3 will not be able to resolve it as a dependency for
a plugin. This is a deliberate change in behavior between Maven 2 and
Maven 3.


On 2011-03-03 15:39, Michael Remijan wrote:
> I've switched to Maven 3.0.2in an attempt to get a working release plugin but 
> now the assembly plugin is not working.
> 
> I can 'clean install' my multi-module project fine with 2.2.1.  When 
> switching to 3.0.2 Maven has a problem with the assembly with the following 
> error printed to the console:
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5:single 
> (ferris-bin-assembly) on project ferris-bible-common: Execution 
> ferris-bin-assembly of goal 
> org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5:single failed: 
> Plugin org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5 or one of 
> its dependencies could not be resolved: Could not find artifact 
> org.ferris:ferris-assemblies:jar:0.0.3 in central (http://re
> po1.maven.org/maven2) -> [Help 1]

This is telling you that Maven 3 cannot find the artifact
org.ferris:ferris-assemblies:jar:0.0.3 in central
(http://repo1.maven.org/maven2). Note that it is only looking in
central, and not any of your own repositories.


> I highlighted what looks like the root cause of the problem.  My pom is 
> trying to use an assembly I created - org.ferris:ferris-assemblies:jar:0.0.3 
> - however for some reason Maven 3.0.2 is trying to find it in the main Maven 
> Repo.  This already exists in my LOCAL repository and if it didn't it exists 
> on my OSS SONATYPE repository which my settings.xml is configured to point to.
> 
> Any one know of any reason why the assembly plugin has decided to only look 
> for my assembly artifact on the main Maven Repo?
> 


-- 
Dennis Lundberg

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: assembly plugin broken going from 2.2.1 to 3.0.2

2011-03-03 Thread Benjamin Bentmann


Michael Remijan wrote:


[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5:single 
(ferris-bin-assembly) on project ferris-bible-common: Execution 
ferris-bin-assembly of goal 
org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5:single failed: Plugin 
org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5 or one of its 
dependencies could not be resolved: Could not find artifact 
org.ferris:ferris-assemblies:jar:0.0.3 in central (http://re
po1.maven.org/maven2) ->  [Help 1]

[...] This already exists in my LOCAL repository and if it didn't it exists on 
my OSS SONATYPE repository which my settings.xml is configured to point to.


Proposed next steps
a) Verify your OSS repo is also configured as a 
b) Re-test using staged Maven 3.0.3 [0]
c) Fill a bug with an example project to reproduce the issue


Benjamin


[0] 
https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.0.3/


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Assembly plugin to produce an EAR archive

2011-02-27 Thread Celinio


ok.
Someone knows a good example of the use of that assembly plugin with a multiple 
modules project ?


--- On Sat, 2/26/11, Anders Hammar  wrote:

From: Anders Hammar 
Subject: Re: Assembly plugin to produce an EAR archive
To: "Maven Users List" 
Date: Saturday, February 26, 2011, 7:17 AM

Normally, you ear plugin should fit your needs. If it turns out not to do
all you want it to do, then possibly look at the assembly plugin.

/Anders

On Sat, Feb 26, 2011 at 16:11, Celinio  wrote:

> Hi,
> I have this multiple module project where one module is the parent and 2
> other modules are children.
> One child module produces a JAR and the other child module produces a WAR
> archive (webapp).
>
> I would like to use the assembly plugin to join these 2 archives inside an
> EAR archive.
> Is there some example / tutorial out there ?
>
> I know there is also an EAR plugin but i'm still evaluating / testing these
> plugins so i am interested to know which one is best for this situation.
>
> Any idea ?
> Thanks for helping.
>
>
>
>

Re: Assembly plugin to produce an EAR archive

2011-02-26 Thread Anders Hammar

Normally, you ear plugin should fit your needs. If it turns out not to do
all you want it to do, then possibly look at the assembly plugin.

/Anders

On Sat, Feb 26, 2011 at 16:11, Celinio  wrote:

> Hi,
> I have this multiple module project where one module is the parent and 2
> other modules are children.
> One child module produces a JAR and the other child module produces a WAR
> archive (webapp).
>
> I would like to use the assembly plugin to join these 2 archives inside an
> EAR archive.
> Is there some example / tutorial out there ?
>
> I know there is also an EAR plugin but i'm still evaluating / testing these
> plugins so i am interested to know which one is best for this situation.
>
> Any idea ?
> Thanks for helping.
>
>
>
>

Re: assembly plugin sign all dependented jars

2011-01-05 Thread Stephen Connolly

On 5 January 2011 08:22, xtonic  wrote:

>
> I would like to produce a tar with my project artifact and all its
> dependents
> jars jarsigned. Also, I would like to deploy the tar as attachment.
>
> I used assembly plugin and write my own descriptor. However, I don’t know
> how to sign all the jars before the tar is created.
>
> I did try create the assemble as "dir"(instead of tar), call antrun to sign
> and create the final tar. However, Maven will not include the tar as
> attachment.
>

use
http://maven.apache.org/plugins/maven-antrun-plugin/tasks/attachArtifact.htmlto
attach the artifact


> Thanks
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/assembly-plugin-sign-all-dependented-jars-tp3328397p3328397.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Assembly Plugin not seeing local repository

2011-01-01 Thread Kalle Korhonen

Hmm.. I just mavenized RestFB
(http://code.google.com/p/restfb/source/browse/#svn%2Ftrunk%2FRestFB),
including an assembly-based distro and I can verify that
useAllReactorProjects works as expected and documented. The
documentation could be more clear though - I'm not sure it's obvious
what the intended use of useAllReactorProjects is (enable creating
assemblies in a child module) for new users. Also, as the
documentation says, if you are using moduleSets (rather than
dependencySets) make sure that your reactor (multi-module) build is
actually building those modules, otherwise you run into troubles.
Overall, it seems you had pretty much the right approach but
unfortunately your stack trace doesn't reveal enough to see if the
modules your are trying to include were built as part of that reactor
build.

Kalle


On Thu, Dec 30, 2010 at 9:12 AM, Steve Cohen  wrote:
> I am giving up trying to understand the mess below.  I have tried everything
> I can.  This new approach to moduleset inclusion with
>  isn't working for me and the debugging information
> isn't helping.
>
> I started with very simple requirements:
>
> Package a jar, some locally generated dependent jars, and some third party
> jars into the lib directory of a zip file, and package some other files into
> a config directory of the same zip file.
>
> The syntax that is required by this approach is mind-bogglingly difficult
> for such simple requirements.
>
> I had an almost working version using the old plugin with its old approach.
>  The only problem was that my JUnit tests were running twice.  I think
> perhaps that my experiments here may have shown me a way around this.  If
> not, I can live with it.
>
> The new approach must be rated a failure, or else some better documentation
> needs to be created.  What I see clearly does not apply to my situation.
>
> Happy New Year, folks.
>
> Steve Cohen
>
> On 12/29/2010 01:38 PM, Steve Cohen wrote:
>
>> Here ya go:
>>
>> [DEBUG] (f) mavenSession = org.apache.maven.execution.mavensess...@6691da
>> [DEBUG] (s) outputDirectory =
>> /home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/target
>> [DEBUG] (f) project = MavenProject: com.whatever:bpm-dist:0.0.3-SNAPSHOT
>> @ /home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/pom.xml
>> [DEBUG] (s) reactorProjects = [MavenProject:
>> com.whatever:Module001:0.0.3-SNAPSHOT @
>> /home/abcdefg/build/20101228-REFACTOR-DEPS/Module001/pom.xml,
>> MavenProject: com.whatever:Module002:0.0.3-SNAPSHOT @
>> /home/abcdefg/build/20101228-REFACTOR-DEPS/Module002/pom.xml,
>> MavenProject: com.whatever:HibernateWrapper:0.0.3-SNAPSHOT @
>> /home/abcdefg/build/20101228-REFACTOR-DEPS/HibernateWrapper/pom.xml,
>> MavenProject: com.whatever:Module003:0.0.3-SNAPSHOT @
>> /home/abcdefg/build/20101228-REFACTOR-DEPS/Module003/pom.xml,
>> MavenProject: com.whatever:WXYZClient:0.0.3-SNAPSHOT @
>> /home/abcdefg/build/20101228-REFACTOR-DEPS/WXYZClient/pom.xml,
>> MavenProject: com.whatever:BatchProcessManager:0.0.3-SNAPSHOT @
>> /home/abcdefg/build/20101228-REFACTOR-DEPS/BatchProcessManager/pom.xml,
>> MavenProject: com.whatever:BPM:0.0.3-SNAPSHOT @
>> /home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/pom.xml, MavenProject:
>> com.whatever:bpm-dist:0.0.3-SNAPSHOT @
>> /home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/pom.xml]
>> [DEBUG] (f) remoteRepositories = [ id: central
>> url: http://repo1.maven.org/maven2
>> layout: default
>> snapshots: [enabled => false, update => daily]
>> releases: [enabled => true, update => daily]
>> ]
>> [DEBUG] (f) runOnlyAtExecutionRoot = false
>> [DEBUG] (s) siteDirectory =
>> /home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/target/site
>> [DEBUG] (f) skipAssembly = false
>> [DEBUG] (s) tarLongFileMode = warn
>> [DEBUG] (s) tempRoot =
>> /home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/target/archive-tmp
>> [DEBUG] (f) updateOnly = false
>> [DEBUG] (f) useJvmChmod = false
>> [DEBUG] (s) workDirectory =
>>
>> /home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/target/assembly/work
>>
>> [DEBUG] -- end configuration --
>> [INFO] Reading assembly descriptor: ../src/main/assembly/zip.xml
>> [DEBUG] Before assembly is interpolated:
>>
>> 
>> 
>> BPM
>> 
>> zip
>> 
>> bpm
>> 
>> 
>> true
>> 
>> com.whatever:Module001
>> com.whatever:Module002
>> com.whatever:HibernateWrapper
>> com.whatever:Module003
>> com.whatever:WXYZClient
>> com.whatever:BatchProcessManager
>> 
>> 
>> lib
>> 
>> 
>> lib
>> 
>> 
>> false
>> 
>> 
>> 
>> 
>> 
>> config
>> 
>> **
>> 
>> ../../BatchProcessManager/unpackaged/config
>> 
>> 
>> 
>>
>>
>>
>> [DEBUG] After assembly is interpolated:
>>
>> 
>> 
>> BPM
>> 
>> zip
>> 
>> bpm
>> 
>> 
>> true
>> 
>> com.whatever:Module001
>> com.whatever:Module002
>> com.whatever:HibernateWrapper
>> com.whatever:Module003
>> com.whatever:WXYZClient
>> com.whatever:BatchProcessManager
>> 
>> 
>> lib
>> 
>> 
>> lib
>> 
>> 
>> false
>> 
>> 
>> 
>> 
>> 
>> config
>> 
>> **
>> 
>> ../../BatchProcessManager/unpackaged/config
>> 
>>

Re: Assembly Plugin adventures - further review

2010-12-31 Thread Ron Wheeler


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 that different.  And your example shows the use of the 
root-level  which I'm thinking would probably let me 
work without using appassembler.


But it's New Year's Eve, time to put this to bed.

Thanks again.

Steve


Have a great evening.
If you need any more details, let me know.
It is pretty easy and we build a few batch jobs so I may be able to show 
something more similar to your job.


Ron


On 12/31/2010 02:14 PM, Ron Wheeler wrote:

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 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 up, it was
getting the dependency modules from my local repository (put there by
a previous build), not building them, as was my intention. For that,
it was necessary to specify them as modules in the aggregator project.
And then by binding them to a phase in an  element, I was
able to avoid the command line specification. Live and learn.

I still like appassembler and how it just pulls all the dependencies
into its "repository".

The way I have it set up now, and it's working as I want, appassembler
is bound to the package phase of the main project, aggregating all
stuff needed in the ultimate zip file in target/appassembler of the
main project.

The aggregator project using the assembly plugin then pulls these as
filesets from this location.

There may be (and probably is, I would guess) a way to do this using
only the assembly plugin and not appassembler. But the documentation
is somewhat lacking in explaining all the confusing options that are
available.

Just one example:

In the assembly descriptor document, it is possible to place a
 element at the root level of the descriptor OR within
the  element of the root level. And
the difference is not explained at all on
http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html

Using the appassembler plugin as I have done, this is all quite clear.
And it spares me the need of specifying dependencies of the aggregator
project as described here:

http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html 




So to sum up:

I prepare the staging directory in the package phase of the main
application project with the appassembler plugin.

Then I build the target zipfile in the aggregator project from this
staging directory in the aggregator project.

But there may be a better way. I am still learning.

On 12/31/2010 08:19 AM, Stephen Connolly wrote:

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 
nonsense

words and other nonsense are a direct result of using swype to type
on the
screen
On 31 Dec 2010 13:52, "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 used a
separate uber-project to do nothing but the assembly. But I noticed,
once I started actually doing the JUnit tests during the build run 
that
they were being run twice, first as the dependent jars were being 
built

and then again in the assembly run. These were described as modules.
Dissatisfaction with that led me down the path of
 - which I didn't even understand - and 
this was

a total failure.

All I frickin wanted to do was package up stuff that had already been
built. I didn't want to think about module sets, dependency sets, any
of that nonsense at that point. Everything on the java side had been
built with that carefully thought through. At this point, all I 
wanted
was something that let me think of them as filesets to be combined 
into
an archive. This appassembler plugin let me do that. Whatever they 
are

doing is much cleaner than what the assembler plugin does.

This is even simpler than your approach: I am able to dispense 
with the

extra project just for the assembly and move it into the project that
builds the jar with the main() class. A single maven command does it
all from scratch:

clean install package appassembler:assemble assembly:single

Now it very well may be that there is a way to do the same thing with
the assembly p

Re: Assembly Plugin adventures - further review

2010-12-31 Thread Barrie Treloar

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 used a separate
> uber-project to do nothing but the assembly.  But I noticed, once I started
> actually doing the JUnit tests during the build run that they were being run

Running assembly:assembly is the bug that caused the goal "single" to
be created.
Because assembly is attached the lifecycle it incorrectly causes the
entire lifecycle to be run twice.

You will notice the same thing with surefire-report:report.

Its a known problem that I think is being addressed in Maven 3.0.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Assembly Plugin adventures - further review

2010-12-31 Thread Steve Cohen


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 use of the 
root-level  which I'm thinking would probably let me work 
without using appassembler.


But it's New Year's Eve, time to put this to bed.

Thanks again.

Steve


On 12/31/2010 02:14 PM, Ron Wheeler wrote:

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 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 up, it was
getting the dependency modules from my local repository (put there by
a previous build), not building them, as was my intention. For that,
it was necessary to specify them as modules in the aggregator project.
And then by binding them to a phase in an  element, I was
able to avoid the command line specification. Live and learn.

I still like appassembler and how it just pulls all the dependencies
into its "repository".

The way I have it set up now, and it's working as I want, appassembler
is bound to the package phase of the main project, aggregating all
stuff needed in the ultimate zip file in target/appassembler of the
main project.

The aggregator project using the assembly plugin then pulls these as
filesets from this location.

There may be (and probably is, I would guess) a way to do this using
only the assembly plugin and not appassembler. But the documentation
is somewhat lacking in explaining all the confusing options that are
available.

Just one example:

In the assembly descriptor document, it is possible to place a
 element at the root level of the descriptor OR within
the  element of the root level. And
the difference is not explained at all on
http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html

Using the appassembler plugin as I have done, this is all quite clear.
And it spares me the need of specifying dependencies of the aggregator
project as described here:

http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html


So to sum up:

I prepare the staging directory in the package phase of the main
application project with the appassembler plugin.

Then I build the target zipfile in the aggregator project from this
staging directory in the aggregator project.

But there may be a better way. I am still learning.

On 12/31/2010 08:19 AM, Stephen Connolly wrote:

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 nonsense
words and other nonsense are a direct result of using swype to type
on the
screen
On 31 Dec 2010 13:52, "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 used a
separate uber-project to do nothing but the assembly. But I noticed,
once I started actually doing the JUnit tests during the build run that
they were being run twice, first as the dependent jars were being built
and then again in the assembly run. These were described as modules.
Dissatisfaction with that led me down the path of
 - which I didn't even understand - and this was
a total failure.

All I frickin wanted to do was package up stuff that had already been
built. I didn't want to think about module sets, dependency sets, any
of that nonsense at that point. Everything on the java side had been
built with that carefully thought through. At this point, all I wanted
was something that let me think of them as filesets to be combined into
an archive. This appassembler plugin let me do that. Whatever they are
doing is much cleaner than what the assembler plugin does.

This is even simpler than your approach: I am able to dispense with the
extra project just for the assembly and move it into the project that
builds the jar with the main() class. A single maven command does it
all from scratch:

clean install package appassembler:assemble assembly:single

Now it very well may be that there is a way to do the same thing with
the assembly plugin alone. But the documentation and the examples for
that plugin do not explain that way for me. Instead I get dragged into
discussions of "Reactors" and all sorts of things that I shouldn't need
to understand (and don't), just to perform

Re: Assembly Plugin adventures - further review

2010-12-31 Thread Ron Wheeler


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 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 up, it was 
getting the dependency modules from my local repository (put there by 
a previous build), not building them, as was my intention.  For that, 
it was necessary to specify them as modules in the aggregator 
project.  And then by binding them to a phase in an  
element, I was able to avoid the command line specification.  Live and 
learn.


I still like appassembler and how it just pulls all the dependencies 
into its "repository".


The way I have it set up now, and it's working as I want, appassembler 
is bound to the package phase of the main project, aggregating all 
stuff needed in the ultimate zip file in target/appassembler of the 
main project.


The aggregator project using the assembly plugin then pulls these as 
filesets from this location.


There may be (and probably is, I would guess) a way to do this using 
only the assembly plugin and not appassembler.  But the documentation 
is somewhat lacking in explaining all the confusing options that are 
available.


Just one example:

In the assembly descriptor document, it is possible to place a 
 element at the root level of the descriptor OR within 
the  element of the root level.  And 
the difference is not explained at all on

http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html

Using the appassembler plugin as I have done, this is all quite clear. 
And it spares me the need of specifying dependencies of the aggregator 
project as described here:


http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html 



So to sum up:

I prepare the staging directory in the package phase of the main 
application project with the appassembler plugin.


Then I build the target zipfile in the aggregator project from this 
staging directory in the aggregator project.


But there may be a better way.  I am still learning.

On 12/31/2010 08:19 AM, Stephen Connolly wrote:

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 nonsense
words and other nonsense are a direct result of using swype to type 
on the

screen
On 31 Dec 2010 13:52, "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 used a
separate uber-project to do nothing but the assembly. But I noticed,
once I started actually doing the JUnit tests during the build run that
they were being run twice, first as the dependent jars were being built
and then again in the assembly run. These were described as modules.
Dissatisfaction with that led me down the path of
  - which I didn't even understand - and this 
was

a total failure.

All I frickin wanted to do was package up stuff that had already been
built. I didn't want to think about module sets, dependency sets, any
of that nonsense at that point. Everything on the java side had been
built with that carefully thought through. At this point, all I wanted
was something that let me think of them as filesets to be combined into
an archive. This appassembler plugin let me do that. Whatever they are
doing is much cleaner than what the assembler plugin does.

This is even simpler than your approach: I am able to dispense with the
extra project just for the assembly and move it into the project that
builds the jar with the main() class. A single maven command does it
all from scratch:

clean install package appassembler:assemble assembly:single

Now it very well may be that there is a way to do the same thing with
the assembly plugin alone. But the documentation and the examples for
that plugin do not explain that way for me. Instead I get dragged into
discussions of "Reactors" and all sorts of things that I shouldn't need
to understand (and don't), just to perform my simple aggregation task.

So I think the Codehaus appassembler folks are onto something here and
the maven assembly folks might want to look at it and figure out a
SIMPLE way to handle this scenario without it. Alternatively, the
appassembler folks could add packaging to their plugin and there'd 
be no

need of the assembly plugin.

Or, maybe it's better that there are two projects, each with its own
aims. That's the unix small-tools approach. But that w

Re: Assembly Plugin adventures - further review

2010-12-31 Thread Steve Cohen

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 up, it was getting 
the dependency modules from my local repository (put there by a previous 
build), not building them, as was my intention.  For that, it was 
necessary to specify them as modules in the aggregator project.  And 
then by binding them to a phase in an  element, I was able to 
avoid the command line specification.  Live and learn.


I still like appassembler and how it just pulls all the dependencies 
into its "repository".


The way I have it set up now, and it's working as I want, appassembler 
is bound to the package phase of the main project, aggregating all stuff 
needed in the ultimate zip file in target/appassembler of the main project.


The aggregator project using the assembly plugin then pulls these as 
filesets from this location.


There may be (and probably is, I would guess) a way to do this using 
only the assembly plugin and not appassembler.  But the documentation is 
somewhat lacking in explaining all the confusing options that are available.


Just one example:

In the assembly descriptor document, it is possible to place a 
 element at the root level of the descriptor OR within 
the  element of the root level.  And 
the difference is not explained at all on

http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html

Using the appassembler plugin as I have done, this is all quite clear. 
And it spares me the need of specifying dependencies of the aggregator 
project as described here:


http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html

So to sum up:

I prepare the staging directory in the package phase of the main 
application project with the appassembler plugin.


Then I build the target zipfile in the aggregator project from this 
staging directory in the aggregator project.


But there may be a better way.  I am still learning.

On 12/31/2010 08:19 AM, Stephen Connolly wrote:

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 nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 31 Dec 2010 13:52, "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 used a
separate uber-project to do nothing but the assembly. But I noticed,
once I started actually doing the JUnit tests during the build run that
they were being run twice, first as the dependent jars were being built
and then again in the assembly run. These were described as modules.
Dissatisfaction with that led me down the path of
  - which I didn't even understand - and this was
a total failure.

All I frickin wanted to do was package up stuff that had already been
built. I didn't want to think about module sets, dependency sets, any
of that nonsense at that point. Everything on the java side had been
built with that carefully thought through. At this point, all I wanted
was something that let me think of them as filesets to be combined into
an archive. This appassembler plugin let me do that. Whatever they are
doing is much cleaner than what the assembler plugin does.

This is even simpler than your approach: I am able to dispense with the
extra project just for the assembly and move it into the project that
builds the jar with the main() class. A single maven command does it
all from scratch:

clean install package appassembler:assemble assembly:single

Now it very well may be that there is a way to do the same thing with
the assembly plugin alone. But the documentation and the examples for
that plugin do not explain that way for me. Instead I get dragged into
discussions of "Reactors" and all sorts of things that I shouldn't need
to understand (and don't), just to perform my simple aggregation task.

So I think the Codehaus appassembler folks are onto something here and
the maven assembly folks might want to look at it and figure out a
SIMPLE way to handle this scenario without it. Alternatively, the
appassembler folks could add packaging to their plugin and there'd be no
need of the assembly plugin.

Or, maybe it's better that there are two projects, each with its own
aims. That's the unix small-tools approach. But that was supposed to
be what the assembler plugin was about and in this instance it falls
short of the mark.


On 12/30/2010 09:31 PM, Benson Margulies

Re: Assembly Plugin adventures - further review

2010-12-31 Thread Benson Margulies

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 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.  But I noticed, once I started
> actually doing the JUnit tests during the build run that they were being run
> twice, first as the dependent jars were being built and then again in the
> assembly run.  These were described as modules.
> Dissatisfaction with that led me down the path of  -
> which I didn't even understand - and this was a total failure.
>
> All I frickin wanted to do was package up stuff that had already been built.
>  I didn't want to think about module sets, dependency sets, any of that
> nonsense at that point.  Everything on the java side had been built with
> that carefully thought through.  At this point, all I  wanted was something
> that let me think of them as filesets to be combined into an archive.  This
> appassembler plugin let me do that.  Whatever they are doing is much cleaner
> than what the assembler plugin does.
>
> This is even simpler than your approach: I am able to dispense with the
> extra project just for the assembly and move it into the project that builds
> the jar with the main() class.  A single maven command does it all from
> scratch:
>
> clean install package appassembler:assemble assembly:single
>
> Now it very well may be that there is a way to do the same thing with the
> assembly plugin alone.  But the documentation and the examples for that
> plugin do not explain that way for me.  Instead I get dragged into
> discussions of "Reactors" and all sorts of things that I shouldn't need to
> understand (and don't), just to perform my simple aggregation task.
>
> So I think the Codehaus appassembler folks are onto something here and the
> maven assembly folks might want to look at it and figure out a SIMPLE way to
> handle this scenario without it.  Alternatively, the appassembler folks
> could add packaging to their plugin and there'd be no need of the assembly
> plugin.
>
> Or, maybe it's better that there are two projects, each with its own aims.
>  That's the unix small-tools approach.  But that was supposed to be what the
> assembler plugin was about and in this instance it falls short of the mark.
>
>
> On 12/30/2010 09:31 PM, Benson Margulies wrote:
>>
>> 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't be called out in the
>> dependencySet, I use dependency:copy to stage them and then, again,
>> pick them up as part of a fileSet.
>>
>> I've even managed to share the assembly descriptors by using the 'grab
>> them from an artifact' business.
>>
>>
>>
>> On Thu, Dec 30, 2010 at 10:02 PM, Steve Cohen
>>  wrote:
>>>
>>> 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 party deps, along with any config files (all of
>>> which is done easily by the appassembler plugin), then bundle the whole
>>> mess
>>> into whatever kind of archive you choose.
>>>
>>> This could be a mode of the assembly plugin, but it isn't.  Call it a
>>> feature request.  It would be worthwhile to combine these two
>>> functionalities.
>>>
>>> On 12/30/2010 06:00 PM, Steve Cohen wrote:

 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 New Year, to all who helped me here!! You're the best!


 Steve



 On 12/30/2010 05:41 PM, Dennis Lundberg wrote:
>
> 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
>> to suck all the jars into the assembly plugin.
>
> Yep, here's the assembly desc

Re: Assembly Plugin adventures - further review

2010-12-31 Thread Stephen Connolly

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 nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 31 Dec 2010 13:52, "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 used a
> separate uber-project to do nothing but the assembly. But I noticed,
> once I started actually doing the JUnit tests during the build run that
> they were being run twice, first as the dependent jars were being built
> and then again in the assembly run. These were described as modules.
> Dissatisfaction with that led me down the path of
>  - which I didn't even understand - and this was
> a total failure.
>
> All I frickin wanted to do was package up stuff that had already been
> built. I didn't want to think about module sets, dependency sets, any
> of that nonsense at that point. Everything on the java side had been
> built with that carefully thought through. At this point, all I wanted
> was something that let me think of them as filesets to be combined into
> an archive. This appassembler plugin let me do that. Whatever they are
> doing is much cleaner than what the assembler plugin does.
>
> This is even simpler than your approach: I am able to dispense with the
> extra project just for the assembly and move it into the project that
> builds the jar with the main() class. A single maven command does it
> all from scratch:
>
> clean install package appassembler:assemble assembly:single
>
> Now it very well may be that there is a way to do the same thing with
> the assembly plugin alone. But the documentation and the examples for
> that plugin do not explain that way for me. Instead I get dragged into
> discussions of "Reactors" and all sorts of things that I shouldn't need
> to understand (and don't), just to perform my simple aggregation task.
>
> So I think the Codehaus appassembler folks are onto something here and
> the maven assembly folks might want to look at it and figure out a
> SIMPLE way to handle this scenario without it. Alternatively, the
> appassembler folks could add packaging to their plugin and there'd be no
> need of the assembly plugin.
>
> Or, maybe it's better that there are two projects, each with its own
> aims. That's the unix small-tools approach. But that was supposed to
> be what the assembler plugin was about and in this instance it falls
> short of the mark.
>
>
> On 12/30/2010 09:31 PM, Benson Margulies wrote:
>> 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't be called out in the
>> dependencySet, I use dependency:copy to stage them and then, again,
>> pick them up as part of a fileSet.
>>
>> I've even managed to share the assembly descriptors by using the 'grab
>> them from an artifact' business.
>>
>>
>>
>> On Thu, Dec 30, 2010 at 10:02 PM, Steve Cohen
wrote:
>>> 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 party deps, along with any config files (all
of
>>> which is done easily by the appassembler plugin), then bundle the whole
mess
>>> into whatever kind of archive you choose.
>>>
>>> This could be a mode of the assembly plugin, but it isn't. Call it a
>>> feature request. It would be worthwhile to combine these two
>>> functionalities.
>>>
>>> On 12/30/2010 06:00 PM, Steve Cohen wrote:

 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 New Year, to all who helped me here!! You're the best!


 Steve



 On 12/30/2010 05:41 PM, Dennis Lundberg wrote:
>
> 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 repos

Re: Assembly Plugin adventures - further review

2010-12-31 Thread Steve Cohen

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.  But I noticed, 
once I started actually doing the JUnit tests during the build run that 
they were being run twice, first as the dependent jars were being built 
and then again in the assembly run.  These were described as modules.
Dissatisfaction with that led me down the path of 
 - which I didn't even understand - and this was 
a total failure.


All I frickin wanted to do was package up stuff that had already been 
built.  I didn't want to think about module sets, dependency sets, any 
of that nonsense at that point.  Everything on the java side had been 
built with that carefully thought through.  At this point, all I  wanted 
was something that let me think of them as filesets to be combined into 
an archive.  This appassembler plugin let me do that.  Whatever they are 
doing is much cleaner than what the assembler plugin does.


This is even simpler than your approach: I am able to dispense with the 
extra project just for the assembly and move it into the project that 
builds the jar with the main() class.  A single maven command does it 
all from scratch:


clean install package appassembler:assemble assembly:single

Now it very well may be that there is a way to do the same thing with 
the assembly plugin alone.  But the documentation and the examples for 
that plugin do not explain that way for me.  Instead I get dragged into 
discussions of "Reactors" and all sorts of things that I shouldn't need 
to understand (and don't), just to perform my simple aggregation task.


So I think the Codehaus appassembler folks are onto something here and 
the maven assembly folks might want to look at it and figure out a 
SIMPLE way to handle this scenario without it.  Alternatively, the 
appassembler folks could add packaging to their plugin and there'd be no 
need of the assembly plugin.


Or, maybe it's better that there are two projects, each with its own 
aims.  That's the unix small-tools approach.  But that was supposed to 
be what the assembler plugin was about and in this instance it falls 
short of the mark.



On 12/30/2010 09:31 PM, Benson Margulies wrote:

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't be called out in the
dependencySet, I use dependency:copy to stage them and then, again,
pick them up as part of a fileSet.

I've even managed to share the assembly descriptors by using the 'grab
them from an artifact' business.



On Thu, Dec 30, 2010 at 10:02 PM, Steve Cohen  wrote:

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 party deps, along with any config files (all of
which is done easily by the appassembler plugin), then bundle the whole mess
into whatever kind of archive you choose.

This could be a mode of the assembly plugin, but it isn't.  Call it a
feature request.  It would be worthwhile to combine these two
functionalities.

On 12/30/2010 06:00 PM, Steve Cohen wrote:


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 New Year, to all who helped me here!! You're the best!


Steve



On 12/30/2010 05:41 PM, Dennis Lundberg wrote:


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
to suck all the jars into the assembly plugin.


Yep, here's the assembly descriptor I use:

http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";

xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0

http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
dist

zip

false


target/appassembler


lib/maven-metadata-appassembler.xml

lib/${project.artifactId}-${project.version}-site.xml






and the relevant parts of the POM:



org.codehaus.mojo
appassembler-maven-plugin
1.0



my.class.name
MyProgram


flat
lib




assemble






org.apac

Re: Assembly Plugin adventures - further review

2010-12-30 Thread Benson Margulies

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't be called out in the
dependencySet, I use dependency:copy to stage them and then, again,
pick them up as part of a fileSet.

I've even managed to share the assembly descriptors by using the 'grab
them from an artifact' business.



On Thu, Dec 30, 2010 at 10:02 PM, Steve Cohen  wrote:
> 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 party deps, along with any config files (all of
> which is done easily by the appassembler plugin), then bundle the whole mess
> into whatever kind of archive you choose.
>
> This could be a mode of the assembly plugin, but it isn't.  Call it a
> feature request.  It would be worthwhile to combine these two
> functionalities.
>
> On 12/30/2010 06:00 PM, Steve Cohen wrote:
>>
>> 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 New Year, to all who helped me here!! You're the best!
>>
>>
>> Steve
>>
>>
>>
>> On 12/30/2010 05:41 PM, Dennis Lundberg wrote:
>>>
>>> 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
 to suck all the jars into the assembly plugin.
>>>
>>> Yep, here's the assembly descriptor I use:
>>>
>>> >>
>>> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
>>>
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>>
>>> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
>>>
>>> http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
>>> dist
>>> 
>>> zip
>>> 
>>> false
>>> 
>>> 
>>> target/appassembler
>>> 
>>> 
>>> lib/maven-metadata-appassembler.xml
>>>
>>> lib/${project.artifactId}-${project.version}-site.xml
>>> 
>>> 
>>> 
>>> 
>>>
>>>
>>> and the relevant parts of the POM:
>>>
>>>
>>> 
>>> org.codehaus.mojo
>>> appassembler-maven-plugin
>>> 1.0
>>> 
>>> 
>>> 
>>> my.class.name
>>> MyProgram
>>> 
>>> 
>>> flat
>>> lib
>>> 
>>> 
>>> 
>>> 
>>> assemble
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> org.apache.maven.plugins
>>> maven-assembly-plugin
>>> 
>>> 
>>> src/main/assembly/assembly.xml
>>> 
>>> gnu
>>> 
>>> 
>>> 
>>> make-assembly
>>> package
>>> 
>>> single
>>> 
>>> 
>>> 
>>> 
>>>
>>>
>>>


 On 12/30/2010 04: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 the way to go before I developed all this by hand
> with commons-daemon and NOT AT ALL about the actual packaging.
>
> Is the idea then to assemble everything in a directory and THEN pass
> this as a fileSet to the assembly plugin?
>
> Or am I missing something?
>
>
> On 12/30/2010 02:37 PM, Dennis Lundberg wrote:
>>
>> 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 understand the new
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
>


 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org


>>>
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>>
>
>
> -

Re: Assembly Plugin adventures - further review

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 party deps, along with any config 
files (all of which is done easily by the appassembler plugin), then 
bundle the whole mess into whatever kind of archive you choose.


This could be a mode of the assembly plugin, but it isn't.  Call it a 
feature request.  It would be worthwhile to combine these two 
functionalities.


On 12/30/2010 06:00 PM, Steve Cohen wrote:

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 New Year, to all who helped me here!! You're the best!


Steve



On 12/30/2010 05:41 PM, Dennis Lundberg wrote:

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
to suck all the jars into the assembly plugin.


Yep, here's the assembly descriptor I use:

http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0

http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
dist

zip

false


target/appassembler


lib/maven-metadata-appassembler.xml

lib/${project.artifactId}-${project.version}-site.xml






and the relevant parts of the POM:



org.codehaus.mojo
appassembler-maven-plugin
1.0



my.class.name
MyProgram


flat
lib




assemble






org.apache.maven.plugins
maven-assembly-plugin


src/main/assembly/assembly.xml

gnu



make-assembly
package

single










On 12/30/2010 04: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 the way to go before I developed all this by hand
with commons-daemon and NOT AT ALL about the actual packaging.

Is the idea then to assemble everything in a directory and THEN pass
this as a fileSet to the assembly plugin?

Or am I missing something?


On 12/30/2010 02:37 PM, Dennis Lundberg wrote:

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 understand the new




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org






-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org








-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org






-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Assembly Plugin adventures - further review

2010-12-30 Thread Ron Wheeler


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:

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 already written and basically never changes.  I don't
need something to manage this side of the process.  Is this going to get in
my way?  Or can I easily avoid dealing with this aspect?

All I want to do is build my stuff and copy the config files, the modules,
and the third party dependencies into a zip file.  End of story.  Can I do
it in less than a day?

Sorry to be so gun-shy but I'm still recovering from the assembly-plugin
experience.



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 understand the new ...

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Assembly Plugin adventures - further review

2010-12-30 Thread Ron Wheeler

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 data into our server.
- A batch job that is triggered by a portlet to run a data upload that 
takes 40 minutes to validate and update the database once the portlet 
has accepted the data and done a preliminary validation of 3 files that 
the user specified.


We did not have any Maven issues using the assembly plug-in to build the 
resulting artifacts.




On 30/12/2010 3:16 PM, Steve Cohen wrote:
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.


I am supporting two main applications in this system.

One is a fairly standard war file that runs under Tomcat.  It isn't 
really a web application, but from this perspective, one might as well 
assume that it is.



Pretty easy.
The other is a not really standard zip file that contains a standalone 
java application.  The standalone application deals with batch 
processes pertaining to the backend database that is used by the "web 
application".  While there may be other ways to organize this code, 
let's say that this mode of organization is an unalterable requirement.


Not unusual. Batch is not going away for some tasks that are either long 
running or need to be scheduled to run without user intervention..
The two applications share some modules - for database access, and for 
contacting some external web services of which both applications are 
clients at various points.



We call them "libraries".
The structure I use is that each module is a separate Eclipse project 
and a separate SVN project.  Each project is ultimately descended from 
a parent POM that governs which dependency version to use for each 
dependency and which plugin version to use.


We do not put dependency management in the parent but that is just my 
decision - not necessarily universally regarded as the best choice by my 
team but .
Since some of the modules need to be "owned" by both of the 
applications, they aren't actually owned by either.  Instead, I try to 
treat them as much like third-party jars as possible.  They are 
installed into the local repository and then used as appropriate.  
They aren't quite as stable as most third-party jars, they are 
evolving to different degrees, along with the main applications.


Libraries again. I would not tolerate the use of unreleased code in a 
production dependency. Write the library, test it and deploy it as a 
SNAPSHOT until it is ready to release.
Just because we wrote it does not mean that we don't have to do it 
right. Deploy it as a release once you are ready to release the modules 
that it supports or you are sure that it will not change. No local 
repositories - everything goes into Nexus as soon as the programmer is 
willing to warranty its perfection.


This applications of this system can be built both in m2eclipse and by 
a server process that builds automatically after getting pristine 
source from svn.


We are happy to go from the Nexus release repo into production but I can 
see the value of testing from the svn to ensure that programmers are 
behaving professionally and committing properly. We are pretty fortunate 
to have guys who actually care about quality.
As far as building the "webapp", that presents no problems.  But the 
standalone batch process application presents many problems.  Besides 
the module jars and third party jars that it needs to package into the 
zip file, it also needs to package in some configuration files that 
will ultimately live on the server file system.


We put the config files in the jar which is enough to get them on the 
classpath and we do not need to change them after they are released.
For this purpose, I have been using the assembly plugin.  I have a 
configuration that works, for the most part, using the 
assembly:assembly goal, which is now deprecated.  I have tried to 
build using the recommended way (using the single goal and the 
 tag) and I ran up against mind-boggling 
difficulties which I wasn't able to resolve.  (See 
http://www.mail-archive.com/users@maven.apache.org/msg115460.html) 
Evidently my system is enough out of the norm that this won't work for 
me.


We have a very simple assembly and I do not understand why you need 
anything special just to build a batch job.


So, to make a long story short, I'm looking for a better way to 
organize this system that would fit more with Maven.  I find it 
aggravating that what would be a simple thing to lay out with make or 
ant is seemingly almost impossible to achieve in Maven - esp

Re: Assembly Plugin adventures - further review


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 New Year, to all who helped me here!!  You're the best!


Steve



On 12/30/2010 05:41 PM, Dennis Lundberg wrote:

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
to suck all the jars into the assembly plugin.


Yep, here's the assembly descriptor I use:

http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
   dist
   
 zip
   
   false
   
 
   target/appassembler
   
   
 lib/maven-metadata-appassembler.xml

lib/${project.artifactId}-${project.version}-site.xml
   
 
   



and the relevant parts of the POM:


   
 org.codehaus.mojo
 appassembler-maven-plugin
 1.0
 
   
 
   my.class.name
   MyProgram
 
   
   flat
   lib
 
 
   
 
   assemble
 
   
 
   
   
   
 org.apache.maven.plugins
 maven-assembly-plugin
 
   
 src/main/assembly/assembly.xml
   
   gnu
 
 
   
 make-assembly
 package
 
   single
 
   
 
   






On 12/30/2010 04: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 the way to go before I developed all this by hand
with commons-daemon and NOT AT ALL about the actual packaging.

Is the idea then to assemble everything in a directory and THEN pass
this as a fileSet to the assembly plugin?

Or am I missing something?


On 12/30/2010 02:37 PM, Dennis Lundberg wrote:

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 understand the new




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org






-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org








-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Assembly Plugin adventures - further review

2010-12-30 Thread Dennis Lundberg

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
> to suck all the jars into the assembly plugin.

Yep, here's the assembly descriptor I use:

http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
  dist
  
zip
  
  false
  

  target/appassembler
  
  
lib/maven-metadata-appassembler.xml

lib/${project.artifactId}-${project.version}-site.xml
  

  



and the relevant parts of the POM:


  
org.codehaus.mojo
appassembler-maven-plugin
1.0

  

  my.class.name
  MyProgram

  
  flat
  lib


  

  assemble

  

  
  
  
org.apache.maven.plugins
maven-assembly-plugin

  
src/main/assembly/assembly.xml
  
  gnu


  
make-assembly
package

  single

  

  



> 
> 
> On 12/30/2010 04: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 the way to go before I developed all this by hand
>> with commons-daemon and NOT AT ALL about the actual packaging.
>>
>> Is the idea then to assemble everything in a directory and THEN pass
>> this as a fileSet to the assembly plugin?
>>
>> Or am I missing something?
>>
>>
>> On 12/30/2010 02:37 PM, Dennis Lundberg wrote:
>>> 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 understand the new
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>>
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 


-- 
Dennis Lundberg

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Assembly Plugin adventures - further review


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 12/30/2010 04: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 the way to go before I developed all this by hand
with commons-daemon and NOT AT ALL about the actual packaging.

Is the idea then to assemble everything in a directory and THEN pass
this as a fileSet to the assembly plugin?

Or am I missing something?


On 12/30/2010 02:37 PM, Dennis Lundberg wrote:

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 understand the new




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org






-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Assembly Plugin not seeing local repository

2010-12-30 Thread Barrie Treloar

I think the problem may be in terminology, I'll try to describe it
below.  It has to do with "modules"

Let me preface this by saying I have never got modulesets working and
have found that I don't need to.
Have you read 
http://maven.apache.org/plugins/maven-assembly-plugin/advanced-module-set-topics.html?

Quoting:
"In these builds, project hierarchy is established through use of the
modules  section of the POM, where parent POMs specify their children
in a modules  section. Other relationships, like interdependency, also
exist within multimodule builds; however, these are beyond the scope
of this document."

In reading your other post, I quote:
"The structure I use is that each module is a separate Eclipse project
and a separate SVN project."

But you haven't provided an example of the directory layout, so I am
guessing what you are doing from the problems you are describing.

Think of "module" as a convenient way to run the same set of commands
across multiple maven projects from a parent project.
Thus you can build from the top level via "mvn install" and maven will
run install in the defined modules in the correct order (generated by
building a dependency graph).
But a "module" is not in itself a declaration of a dependency.  A
module needs to define a parent so in that sense the parent must be
built/available first.
Take a look at 
http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-multi-vs-inherit.html

I think you are most of the way there because you say in your other post:
"Since some of the modules need to be "owned" by both of the
applications, they aren't actually owned by either.  Instead, I try to
treat them as much like third-party jars as possible.  They are
installed into the local repository and then used as appropriate.
They aren't quite as stable as most third-party jars, they are
evolving to different degrees, along with the main applications."

So what you really need is the assembly sorted.  See the "copy all
dependencies" description below, which is probably what you need.
I've attached our assembly file and this is what it does:
* Create two archives a zip (which will get installed into the
repository) and a directory (which doesn't get installed into the
repo, but is useful to run easily since it is already exploded)
* includeBaseDirectory = Always create the archive in a sub directory
named after the current artifact
* Include the fileset src/main/config that contains our configuration
data - log4j, spring contexts, etc that are easier to edit if not
included in jar files
* Include the project's main artifiact by copying it from target
(there is probably a better way to do this but this is an old assembly
file - but it works)
* Copy the windows and unix scripts with filtering turned on.  This
allows me to use "java -jar
${project.artifactId}-${project.version}.jar start" as the contents of
my start scripts.
* Copy ALL dependencies to the lib/ directory.

For us, because our main artifact is being run as a standalone
application we also need to make sure the Manifest.MF has the correct
Class-Path (include config/ and lib/ directories)
This requires configuring the maven-jar-plugin.  You may need to do
the same for the ejb plugin, and perhaps the war plugin (we don't
really use them)

Hope that helps.

=== Start:pom.xml ===
...

  org.apache.maven.plugins
  maven-jar-plugin
  

  
fqn.to.your.MainClass
  
  
config/
  
  
true
lib/
  

  

...

  org.apache.maven.plugins
  maven-assembly-plugin
  

  assembly:package
  package
  

single
  
  

  src/main/assembly/bin.xml

  

  

=== End:pom.xml ===


=== Start:Assembly file ===
http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
  bin
  
dir
zip
  
  true
  

  src/main/config
  config/
  
*
  
  
CVS
  


  target
  
  
${artifactId}-${version}.jar
  

  
  

  src/main/scripts/start_debug.bat
  true


  src/main/scripts/start.bat
  true


  src/main/scripts/stop.bat
  true


  src/main/scripts/start.sh
  true
  0744


  src/main/scripts/stop.sh
  true
  0744

  
  

  lib
  false
  
${artifact.artifactId}-${artifact.baseVersion}${dashClassifier?}.${artifact.extension}

  

===

Re: Assembly Plugin adventures - further review

2010-12-30 Thread Dan Tran

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 the way to go before I developed all this by hand with
> commons-daemon and NOT AT ALL about the actual packaging.
>
> Is the idea then to assemble everything in a directory and THEN pass this as
> a fileSet to the assembly plugin?

That is exactly what I did to get my standalone java app bundle

>
> Or am I missing something?
>
>
> On 12/30/2010 02:37 PM, Dennis Lundberg wrote:
>>
>> 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 understand the new
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Assembly Plugin adventures - further review

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 commons-daemon and NOT AT ALL about the actual packaging.


Is the idea then to assemble everything in a directory and THEN pass 
this as a fileSet to the assembly plugin?


Or am I missing something?


On 12/30/2010 02:37 PM, Dennis Lundberg wrote:

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 understand the new




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Assembly Plugin adventures - further review

2010-12-30 Thread Dan Tran

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.  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 already written and basically never changes.  I don't
> need something to manage this side of the process.  Is this going to get in
> my way?  Or can I easily avoid dealing with this aspect?
>
> All I want to do is build my stuff and copy the config files, the modules,
> and the third party dependencies into a zip file.  End of story.  Can I do
> it in less than a day?
>
> Sorry to be so gun-shy but I'm still recovering from the assembly-plugin
> experience.
>
>
>> 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 understand the new ...
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Assembly Plugin adventures - further review


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 already written and basically never 
changes.  I don't need something to manage this side of the process.  Is 
this going to get in my way?  Or can I easily avoid dealing with this 
aspect?


All I want to do is build my stuff and copy the config files, the 
modules, and the third party dependencies into a zip file.  End of 
story.  Can I do it in less than a day?


Sorry to be so gun-shy but I'm still recovering from the assembly-plugin 
experience.




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 understand the new ...


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Assembly Plugin adventures - further review

2010-12-30 Thread Dennis Lundberg

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 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.
> 
> I am supporting two main applications in this system.
> 
> One is a fairly standard war file that runs under Tomcat.  It isn't
> really a web application, but from this perspective, one might as well
> assume that it is.
> 
> The other is a not really standard zip file that contains a standalone
> java application.  The standalone application deals with batch processes
> pertaining to the backend database that is used by the "web
> application".  While there may be other ways to organize this code,
> let's say that this mode of organization is an unalterable requirement.
> 
> The two applications share some modules - for database access, and for
> contacting some external web services of which both applications are
> clients at various points.
> 
> The structure I use is that each module is a separate Eclipse project
> and a separate SVN project.  Each project is ultimately descended from a
> parent POM that governs which dependency version to use for each
> dependency and which plugin version to use.
> 
> Since some of the modules need to be "owned" by both of the
> applications, they aren't actually owned by either.  Instead, I try to
> treat them as much like third-party jars as possible.  They are
> installed into the local repository and then used as appropriate.  They
> aren't quite as stable as most third-party jars, they are evolving to
> different degrees, along with the main applications.
> 
> This applications of this system can be built both in m2eclipse and by a
> server process that builds automatically after getting pristine source
> from svn.
> 
> As far as building the "webapp", that presents no problems.  But the
> standalone batch process application presents many problems.  Besides
> the module jars and third party jars that it needs to package into the
> zip file, it also needs to package in some configuration files that will
> ultimately live on the server file system.
> 
> For this purpose, I have been using the assembly plugin.  I have a
> configuration that works, for the most part, using the assembly:assembly
> goal, which is now deprecated.  I have tried to build using the
> recommended way (using the single goal and the 
> tag) and I ran up against mind-boggling difficulties which I wasn't able
> to resolve.  (See
> http://www.mail-archive.com/users@maven.apache.org/msg115460.html)
> Evidently my system is enough out of the norm that this won't work for me.
> 
> So, to make a long story short, I'm looking for a better way to organize
> this system that would fit more with Maven.  I find it aggravating that
> what would be a simple thing to lay out with make or ant is seemingly
> almost impossible to achieve in Maven - especially since I am trying to
> convert my organization into using Maven.  I don't know if I'm dealing
> with bugs, or with things that Maven was never designed to be able to do
> in the first place.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 


-- 
Dennis Lundberg

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Assembly Plugin not seeing local repository

I am giving up trying to understand the mess below.  I have tried 
everything I can.  This new approach to moduleset inclusion with 
 isn't working for me and the debugging 
information isn't helping.


I started with very simple requirements:

Package a jar, some locally generated dependent jars, and some third 
party jars into the lib directory of a zip file, and package some other 
files into a config directory of the same zip file.


The syntax that is required by this approach is mind-bogglingly 
difficult for such simple requirements.


I had an almost working version using the old plugin with its old 
approach.  The only problem was that my JUnit tests were running twice. 
 I think perhaps that my experiments here may have shown me a way 
around this.  If not, I can live with it.


The new approach must be rated a failure, or else some better 
documentation needs to be created.  What I see clearly does not apply to 
my situation.


Happy New Year, folks.

Steve Cohen

On 12/29/2010 01:38 PM, Steve Cohen wrote:


Here ya go:

[DEBUG] (f) mavenSession = org.apache.maven.execution.mavensess...@6691da
[DEBUG] (s) outputDirectory =
/home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/target
[DEBUG] (f) project = MavenProject: com.whatever:bpm-dist:0.0.3-SNAPSHOT
@ /home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/pom.xml
[DEBUG] (s) reactorProjects = [MavenProject:
com.whatever:Module001:0.0.3-SNAPSHOT @
/home/abcdefg/build/20101228-REFACTOR-DEPS/Module001/pom.xml,
MavenProject: com.whatever:Module002:0.0.3-SNAPSHOT @
/home/abcdefg/build/20101228-REFACTOR-DEPS/Module002/pom.xml,
MavenProject: com.whatever:HibernateWrapper:0.0.3-SNAPSHOT @
/home/abcdefg/build/20101228-REFACTOR-DEPS/HibernateWrapper/pom.xml,
MavenProject: com.whatever:Module003:0.0.3-SNAPSHOT @
/home/abcdefg/build/20101228-REFACTOR-DEPS/Module003/pom.xml,
MavenProject: com.whatever:WXYZClient:0.0.3-SNAPSHOT @
/home/abcdefg/build/20101228-REFACTOR-DEPS/WXYZClient/pom.xml,
MavenProject: com.whatever:BatchProcessManager:0.0.3-SNAPSHOT @
/home/abcdefg/build/20101228-REFACTOR-DEPS/BatchProcessManager/pom.xml,
MavenProject: com.whatever:BPM:0.0.3-SNAPSHOT @
/home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/pom.xml, MavenProject:
com.whatever:bpm-dist:0.0.3-SNAPSHOT @
/home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/pom.xml]
[DEBUG] (f) remoteRepositories = [ id: central
url: http://repo1.maven.org/maven2
layout: default
snapshots: [enabled => false, update => daily]
releases: [enabled => true, update => daily]
]
[DEBUG] (f) runOnlyAtExecutionRoot = false
[DEBUG] (s) siteDirectory =
/home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/target/site
[DEBUG] (f) skipAssembly = false
[DEBUG] (s) tarLongFileMode = warn
[DEBUG] (s) tempRoot =
/home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/target/archive-tmp
[DEBUG] (f) updateOnly = false
[DEBUG] (f) useJvmChmod = false
[DEBUG] (s) workDirectory =
/home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/target/assembly/work

[DEBUG] -- end configuration --
[INFO] Reading assembly descriptor: ../src/main/assembly/zip.xml
[DEBUG] Before assembly is interpolated:



BPM

zip

bpm


true

com.whatever:Module001
com.whatever:Module002
com.whatever:HibernateWrapper
com.whatever:Module003
com.whatever:WXYZClient
com.whatever:BatchProcessManager


lib


lib


false





config

**

../../BatchProcessManager/unpackaged/config






[DEBUG] After assembly is interpolated:



BPM

zip

bpm


true

com.whatever:Module001
com.whatever:Module002
com.whatever:HibernateWrapper
com.whatever:Module003
com.whatever:WXYZClient
com.whatever:BatchProcessManager


lib


lib


false





config

**

../../BatchProcessManager/unpackaged/config






[DEBUG] All known ContainerDescritporHandler components:
[metaInf-services, file-aggregator, plexus, metaInf-spring]
[WARNING] The following patterns were never triggered in this artifact
inclusion filter:
o 'com.whatever:Module001'
o 'com.whatever:Module002'
o 'com.whatever:HibernateWrapper'
o 'com.whatever:Module003'
o 'com.whatever:WXYZClient'
o 'com.whatever:BatchProcessManager'

[DEBUG] Resolving project dependencies transitively.
[DEBUG] While resolving dependencies of
com.whatever:bpm-dist:pom:0.0.3-SNAPSHOT:
[DEBUG] Statistics for Scope filter [null-scope=true, compile=true,
runtime=true, test=false, provided=false, system=false]

[DEBUG] The following scope filters were not used:
o [Null Scope]
o Compile
o Runtime
o Test
o Provided
o System
[DEBUG] FileSet[config/] dir perms: -1 file perms: -1
[DEBUG] The archive base directory is 'null'
[DEBUG] NOT reformatting any files in
/home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/../../BatchProcessManager/unpackaged/config

[DEBUG] Adding file-set from directory:
'/home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/../../BatchProcessManager/unpackaged/config'

assembly output directory is: 'config/'
[DEBUG] Adding file-set in:
/home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/../../BatchProc

Re: Assembly Plugin not seeing local repository

2010-12-29 Thread Steve Cohen

On 12/29/2010 04:17 PM, Jon Paynter wrote:

well the build didnt fail. However it seems none of your modules were
included in the assembly. Ive done a little bit with assemblies, I was
never able to get the tags to work.

What are you trying to accomplish here?

Basically, I'm trying to retrofit into an environment where the service
management (deployers and such) know a fair bit about unix and much less
about java. It's nothing for them to unzip a tarball and restart an
application. This runs as a standalone java app, with some
configuration files outside of jars for on the fly tweaking. As its
name implies it manages batch processes. Some of these modules are used
in other applications, a set of Hibernate classes for manipulating a
database, some web service clients for outside web services, etc. Many
of these same modules get deployed in a Web App that runs from a WAR
file in Tomcat, but that's not this case for this application.

it looks like you just want the
artifacts from your 6 modules added into a zip file. Also, what is the
structure of your project?

So the basic structure is that each module is its own project, with its
own POM and gets deployed into the repository. I thought it would be
simple to just aggregate those into a zip along with their third party
dependencies but nothing is as simple with Maven as you hope it will be.
Well, not nothing, many things are simple, but the assemblies are a bear.

Have you tried running with useAllReactorProjects set to false?

No, as I said in my earlier thread, I was following the model that is
described at
http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html

where they introduce useAllReactorProjects which is supposed to be the
whole key to making this work, the greatest thing since sliced bread:

> Finally, notice the new useAllReactorProjects flag. This enables
access to all projects in the current reactor (multimodule build), even
from a child module. Using this flag, it's now possible to use a child
module - sorted to the end of the multimodule build process using
appropriate dependency declarations - to generate an assembly containing
module binaries.

Actually I had a workable but imperfect implementation that used the
older plugin until earlier this week. It bothered me because the Junit
tests were running twice for each build and this was supposed to fix
that. It did that -- and more :-(

I can always go back to that if I can't find an answer to this. But I
feel that I'm so close and just missing something simple.

beyond that -- somebody with more experience in asemblies will need to help
you.

Hope so, and thanks.

On Wed, Dec 29, 2010 at 11:38 AM, Steve Cohenwrote:

Here ya go:

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Assembly Plugin not seeing local repository

2010-12-29 Thread Jon Paynter

well the build didnt fail.  However it seems none of your modules were
included in the assembly. Ive done a little bit with assemblies,  I was
never able to get the  tags to work.

What are you trying to accomplish here?  it looks like you just want the
artifacts from your 6 modules added into a zip file.  Also, what is the
structure of your project?
Have you tried running with useAllReactorProjects set to false?

beyond that -- somebody with more experience in asemblies will need to help
you.

On Wed, Dec 29, 2010 at 11:38 AM, Steve Cohen wrote:

> Here ya go:
>

Re: Assembly Plugin not seeing local repository

2010-12-29 Thread Steve Cohen


Here ya go:

[DEBUG]   (f) mavenSession = org.apache.maven.execution.mavensess...@6691da
[DEBUG]   (s) outputDirectory = 
/home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/target
[DEBUG]   (f) project = MavenProject: 
com.whatever:bpm-dist:0.0.3-SNAPSHOT @ 
/home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/pom.xml
[DEBUG]   (s) reactorProjects = [MavenProject: 
com.whatever:Module001:0.0.3-SNAPSHOT @ 
/home/abcdefg/build/20101228-REFACTOR-DEPS/Module001/pom.xml, 
MavenProject: com.whatever:Module002:0.0.3-SNAPSHOT @ 
/home/abcdefg/build/20101228-REFACTOR-DEPS/Module002/pom.xml, 
MavenProject: com.whatever:HibernateWrapper:0.0.3-SNAPSHOT @ 
/home/abcdefg/build/20101228-REFACTOR-DEPS/HibernateWrapper/pom.xml, 
MavenProject: com.whatever:Module003:0.0.3-SNAPSHOT @ 
/home/abcdefg/build/20101228-REFACTOR-DEPS/Module003/pom.xml, 
MavenProject: com.whatever:WXYZClient:0.0.3-SNAPSHOT @ 
/home/abcdefg/build/20101228-REFACTOR-DEPS/WXYZClient/pom.xml, 
MavenProject: com.whatever:BatchProcessManager:0.0.3-SNAPSHOT @ 
/home/abcdefg/build/20101228-REFACTOR-DEPS/BatchProcessManager/pom.xml, 
MavenProject: com.whatever:BPM:0.0.3-SNAPSHOT @ 
/home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/pom.xml, MavenProject: 
com.whatever:bpm-dist:0.0.3-SNAPSHOT @ 
/home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/pom.xml]

[DEBUG]   (f) remoteRepositories = [   id: central
  url: http://repo1.maven.org/maven2
   layout: default
snapshots: [enabled => false, update => daily]
 releases: [enabled => true, update => daily]
]
[DEBUG]   (f) runOnlyAtExecutionRoot = false
[DEBUG]   (s) siteDirectory = 
/home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/target/site

[DEBUG]   (f) skipAssembly = false
[DEBUG]   (s) tarLongFileMode = warn
[DEBUG]   (s) tempRoot = 
/home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/target/archive-tmp

[DEBUG]   (f) updateOnly = false
[DEBUG]   (f) useJvmChmod = false
[DEBUG]   (s) workDirectory = 
/home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/target/assembly/work

[DEBUG] -- end configuration --
[INFO] Reading assembly descriptor: ../src/main/assembly/zip.xml
[DEBUG] Before assembly is interpolated:



  BPM
  
zip
  
  bpm
  

  true
  
com.whatever:Module001
com.whatever:Module002
com.whatever:HibernateWrapper
com.whatever:Module003
com.whatever:WXYZClient
com.whatever:BatchProcessManager
  
  
lib

  
lib
  

false
  

  
  

  config
  
**
  
  ../../BatchProcessManager/unpackaged/config

  




[DEBUG] After assembly is interpolated:



  BPM
  
zip
  
  bpm
  

  true
  
com.whatever:Module001
com.whatever:Module002
com.whatever:HibernateWrapper
com.whatever:Module003
com.whatever:WXYZClient
com.whatever:BatchProcessManager
  
  
lib

  
lib
  

false
  

  
  

  config
  
**
  
  ../../BatchProcessManager/unpackaged/config

  




[DEBUG] All known ContainerDescritporHandler components: 
[metaInf-services, file-aggregator, plexus, metaInf-spring]
[WARNING] The following patterns were never triggered in this artifact 
inclusion filter:

o  'com.whatever:Module001'
o  'com.whatever:Module002'
o  'com.whatever:HibernateWrapper'
o  'com.whatever:Module003'
o  'com.whatever:WXYZClient'
o  'com.whatever:BatchProcessManager'

[DEBUG] Resolving project dependencies transitively.
[DEBUG] While resolving dependencies of 
com.whatever:bpm-dist:pom:0.0.3-SNAPSHOT:
[DEBUG] Statistics for Scope filter [null-scope=true, compile=true, 
runtime=true, test=false, provided=false, system=false]


[DEBUG] The following scope filters were not used:
o [Null Scope]
o Compile
o Runtime
o Test
o Provided
o System
[DEBUG] FileSet[config/] dir perms: -1 file perms: -1
[DEBUG] The archive base directory is 'null'
[DEBUG] NOT reformatting any files in 
/home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/../../BatchProcessManager/unpackaged/config
[DEBUG] Adding file-set from directory: 
'/home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/../../BatchProcessManager/unpackaged/config'

assembly output directory is: 'config/'
[DEBUG] Adding file-set in: 
/home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/../../BatchProcessManager/unpackaged/config 
to archive location: bpm/config/

[DEBUG] No dependency sets specified.
[DEBUG] Cannot find ArtifactResolver with hint: project-cache-aware
org.codehaus.plexus.component.repository.exception.ComponentLookupException: 
java.util.NoSuchElementException

  role: org.apache.maven.artifact.resolver.ArtifactResolver
  roleHint: project-cache-aware
	at 
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:251)
	at 
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexu

Re: Assembly Plugin not seeing local repository

2010-12-29 Thread Jon Paynter

What error messages are you seeing?
running mvn -X should give much more detailed messages.   I know that helped
me a lot when debugging assembly problems.

On Wed, Dec 29, 2010 at 7:45 AM, Steve Cohen  wrote:

> On 12/29/2010 09:21 AM, Steve Cohen wrote:
>
>> Aargh!
>>
>> Following the pattern outlined here:
>>
>>
>> http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html
>>
>>
>> I create POM's and assembly descriptors fitting that model.
>>
>> All of the submodules are built and installed in a local repository. The
>> parts of maven that do that have no problem finding this local
>> repository or knowing that that's where they should be installed to.
>>
>> But when the assembly plugin goes to build the final assembly, it isn't
>> finding these modules in the local repository WHICH ARE THERE!
>>
>> Must I specify the local repository in the assembly descriptor?
>>
>> This was NOT necessary when I built the same thing with m2eclipse.
>>
>> Shoot me now and get it over with!
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>>
>>
> Perhaps shedding some light on the above is this detail:
>
> I see in the maven debug output, the following:
>
> [DEBUG] Reading resolution tracking file
> /home/.../.m2/repository/com/whatever/bpm-dist/0.0.3-SNAPSHOT/_maven.repositories
> [DEBUG] Writing resolution tracking file
> /home/.../.m2/repository/com/whatever/bpm-dist/0.0.3-SNAPSHOT/_maven.repositories
>
> This _maven.repositories file has the following content:
>
> #NOTE: This is an internal implementation file, its format can be changed
> without prior notice.
> #Wed Dec 29 10:26:30 EST 2010
> bpm-dist-0.0.3-SNAPSHOT.zip>=
> bpm-dist-0.0.3-SNAPSHOT.pom>=
>
> I don't know what this means, but it seems to significant that when this
> thing built successfully under m2eclipse, this file was NOT present in that
> machine's local repository.
>
> What am I doing wrong?
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Assembly Plugin not seeing local repository

2010-12-29 Thread Steve Cohen


On 12/29/2010 09:21 AM, Steve Cohen wrote:

Aargh!

Following the pattern outlined here:

http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html


I create POM's and assembly descriptors fitting that model.

All of the submodules are built and installed in a local repository. The
parts of maven that do that have no problem finding this local
repository or knowing that that's where they should be installed to.

But when the assembly plugin goes to build the final assembly, it isn't
finding these modules in the local repository WHICH ARE THERE!

Must I specify the local repository in the assembly descriptor?

This was NOT necessary when I built the same thing with m2eclipse.

Shoot me now and get it over with!

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





Perhaps shedding some light on the above is this detail:

I see in the maven debug output, the following:

[DEBUG] Reading resolution tracking file 
/home/.../.m2/repository/com/whatever/bpm-dist/0.0.3-SNAPSHOT/_maven.repositories
[DEBUG] Writing resolution tracking file 
/home/.../.m2/repository/com/whatever/bpm-dist/0.0.3-SNAPSHOT/_maven.repositories


This _maven.repositories file has the following content:

#NOTE: This is an internal implementation file, its format can be 
changed without prior notice.

#Wed Dec 29 10:26:30 EST 2010
bpm-dist-0.0.3-SNAPSHOT.zip>=
bpm-dist-0.0.3-SNAPSHOT.pom>=

I don't know what this means, but it seems to significant that when this 
thing built successfully under m2eclipse, this file was NOT present in 
that machine's local repository.


What am I doing wrong?

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Assembly Plugin 2.2 File Filtering

2010-11-30 Thread Simone Tripodi

Sorry, just realized you suggested the same workaround in the issue! :D
Thanks,
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Tue, Nov 30, 2010 at 11:10 AM, Simone Tripodi
 wrote:
> Hi Gérald,
> just a quick update: I arranged stuff working moving the 
> section inside the assembly plugin configuration, so instead of having
>
>
>            
>                
>                    
>                        maven-assembly-plugin
>                    
>                
>
>                
>                    
> ${basedir}/src/main/filters/prod.properties
>                
>            
>
> I had to do:
>
>
>            
>                
>                    
>                        maven-assembly-plugin
>                        
>                            
>
> ${basedir}/src/main/filters/prod.properties
>                            
>                        
>                    
>                
>            
>
> The dark side of this approach comes when you're using also other
> plugins, like the war-plugin, that need to filter resource, so you've
> to declare the same filters twice:
>
>
>            
>                
>                    
>                        maven-assembly-plugin
>                        
>                            
>
> ${basedir}/src/main/filters/prod.properties
>                            
>                        
>                    
>                
>
>                
>                    
> ${basedir}/src/main/filters/prod.properties
>                
>            
>
> I'll vote the issue, I hope in the meanwhile that could help you
> fixing your stuff.
> Have a nice day,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Mon, Nov 29, 2010 at 9:02 AM, Gérald Quintana
>  wrote:
>> It already exists, please vote for 
>> http://jira.codehaus.org/browse/MASSEMBLY-528
>>
>> Gérald
>>
>> 2010/11/26 Simone Tripodi :
>>> I got *exactly* the same issue, I suppose we should fill a new Issue on 
>>> Jira!!!
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Fri, Nov 26, 2010 at 3:18 PM, Gérald Quintana
>>>  wrote:
 The assembly plugin doesn't take the filter configuration from the
 project, I has to re-inject the filters!

 Gérald

 Le 26 novembre 2010 14:03, Arnaud Héritier  a écrit :
> Couldn't it be the same problem as in resources plugin (there are using 
> same libraries to do that) which stops if you have a @ character alone :
> http://jira.codehaus.org/browse/MRESOURCES-104
>
> On Nov 26, 2010, at 1:48 PM, Gérald Quintana wrote:
>
>> Hello,
>>
>> I have an assembly with files which should be copied and filtered:
>>        
>>            src/main/config
>>            config
>>            true
>>            
>>                quartz.properties
>>            
>>        
>>
>> Files are copied but not filtered (${...} are still here)
>>
>> The problem occurs with maven-assembly-plugin 2.2 but not with 
>> 2.2-beta-5.
>> It it a known bug or a problem in my configuration?
>>
>> Gérald
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org


>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Assembly Plugin 2.2 File Filtering

2010-11-30 Thread Simone Tripodi

Hi Gérald,
just a quick update: I arranged stuff working moving the 
section inside the assembly plugin configuration, so instead of having





maven-assembly-plugin




${basedir}/src/main/filters/prod.properties



I had to do:





maven-assembly-plugin



${basedir}/src/main/filters/prod.properties






The dark side of this approach comes when you're using also other
plugins, like the war-plugin, that need to filter resource, so you've
to declare the same filters twice:





maven-assembly-plugin



${basedir}/src/main/filters/prod.properties






${basedir}/src/main/filters/prod.properties



I'll vote the issue, I hope in the meanwhile that could help you
fixing your stuff.
Have a nice day,
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Mon, Nov 29, 2010 at 9:02 AM, Gérald Quintana
 wrote:
> It already exists, please vote for 
> http://jira.codehaus.org/browse/MASSEMBLY-528
>
> Gérald
>
> 2010/11/26 Simone Tripodi :
>> I got *exactly* the same issue, I suppose we should fill a new Issue on 
>> Jira!!!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Fri, Nov 26, 2010 at 3:18 PM, Gérald Quintana
>>  wrote:
>>> The assembly plugin doesn't take the filter configuration from the
>>> project, I has to re-inject the filters!
>>>
>>> Gérald
>>>
>>> Le 26 novembre 2010 14:03, Arnaud Héritier  a écrit :
 Couldn't it be the same problem as in resources plugin (there are using 
 same libraries to do that) which stops if you have a @ character alone :
 http://jira.codehaus.org/browse/MRESOURCES-104

 On Nov 26, 2010, at 1:48 PM, Gérald Quintana wrote:

> Hello,
>
> I have an assembly with files which should be copied and filtered:
>        
>            src/main/config
>            config
>            true
>            
>                quartz.properties
>            
>        
>
> Files are copied but not filtered (${...} are still here)
>
> The problem occurs with maven-assembly-plugin 2.2 but not with 2.2-beta-5.
> It it a known bug or a problem in my configuration?
>
> Gérald
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>


 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org


>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Assembly Plugin 2.2 File Filtering

2010-11-29 Thread Gérald Quintana

It already exists, please vote for http://jira.codehaus.org/browse/MASSEMBLY-528

Gérald

2010/11/26 Simone Tripodi :
> I got *exactly* the same issue, I suppose we should fill a new Issue on 
> Jira!!!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Fri, Nov 26, 2010 at 3:18 PM, Gérald Quintana
>  wrote:
>> The assembly plugin doesn't take the filter configuration from the
>> project, I has to re-inject the filters!
>>
>> Gérald
>>
>> Le 26 novembre 2010 14:03, Arnaud Héritier  a écrit :
>>> Couldn't it be the same problem as in resources plugin (there are using 
>>> same libraries to do that) which stops if you have a @ character alone :
>>> http://jira.codehaus.org/browse/MRESOURCES-104
>>>
>>> On Nov 26, 2010, at 1:48 PM, Gérald Quintana wrote:
>>>
 Hello,

 I have an assembly with files which should be copied and filtered:
        
            src/main/config
            config
            true
            
                quartz.properties
            
        

 Files are copied but not filtered (${...} are still here)

 The problem occurs with maven-assembly-plugin 2.2 but not with 2.2-beta-5.
 It it a known bug or a problem in my configuration?

 Gérald

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Assembly Plugin 2.2 File Filtering

2010-11-26 Thread Simone Tripodi

I got *exactly* the same issue, I suppose we should fill a new Issue on Jira!!!
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Fri, Nov 26, 2010 at 3:18 PM, Gérald Quintana
 wrote:
> The assembly plugin doesn't take the filter configuration from the
> project, I has to re-inject the filters!
>
> Gérald
>
> Le 26 novembre 2010 14:03, Arnaud Héritier  a écrit :
>> Couldn't it be the same problem as in resources plugin (there are using same 
>> libraries to do that) which stops if you have a @ character alone :
>> http://jira.codehaus.org/browse/MRESOURCES-104
>>
>> On Nov 26, 2010, at 1:48 PM, Gérald Quintana wrote:
>>
>>> Hello,
>>>
>>> I have an assembly with files which should be copied and filtered:
>>>        
>>>            src/main/config
>>>            config
>>>            true
>>>            
>>>                quartz.properties
>>>            
>>>        
>>>
>>> Files are copied but not filtered (${...} are still here)
>>>
>>> The problem occurs with maven-assembly-plugin 2.2 but not with 2.2-beta-5.
>>> It it a known bug or a problem in my configuration?
>>>
>>> Gérald
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Assembly Plugin 2.2 File Filtering

2010-11-26 Thread Gérald Quintana

The assembly plugin doesn't take the filter configuration from the
project, I has to re-inject the filters!

Gérald

Le 26 novembre 2010 14:03, Arnaud Héritier  a écrit :
> Couldn't it be the same problem as in resources plugin (there are using same 
> libraries to do that) which stops if you have a @ character alone :
> http://jira.codehaus.org/browse/MRESOURCES-104
>
> On Nov 26, 2010, at 1:48 PM, Gérald Quintana wrote:
>
>> Hello,
>>
>> I have an assembly with files which should be copied and filtered:
>>        
>>            src/main/config
>>            config
>>            true
>>            
>>                quartz.properties
>>            
>>        
>>
>> Files are copied but not filtered (${...} are still here)
>>
>> The problem occurs with maven-assembly-plugin 2.2 but not with 2.2-beta-5.
>> It it a known bug or a problem in my configuration?
>>
>> Gérald
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Assembly Plugin 2.2 File Filtering

2010-11-26 Thread Arnaud Héritier

Couldn't it be the same problem as in resources plugin (there are using same 
libraries to do that) which stops if you have a @ character alone :
http://jira.codehaus.org/browse/MRESOURCES-104

On Nov 26, 2010, at 1:48 PM, Gérald Quintana wrote:

> Hello,
> 
> I have an assembly with files which should be copied and filtered:
>
>src/main/config
>config
>true
>
>quartz.properties
>
>
> 
> Files are copied but not filtered (${...} are still here)
> 
> The problem occurs with maven-assembly-plugin 2.2 but not with 2.2-beta-5.
> It it a known bug or a problem in my configuration?
> 
> Gérald
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Assembly Plugin

2010-10-19 Thread Martin Gainty


works on my machine:


  
src/assemble/bin.xml
  


file structure:
pom.xml (located in current folder)
 src (folder of current folder)
   assemble (subfolder of src)
  bin.xml  (contents of assemble subfolder)

did you check to see if the descriptor tag is relative to the location of the 
pom.xml you are referencing?
is it located in the relative path referenced by descriptor tag?
do you have access to the file?
Martin 
__ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
 
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.




> Date: Tue, 19 Oct 2010 13:55:25 +0200
> Subject: Re: Assembly Plugin
> From: and...@hammar.net
> To: users@maven.apache.org
> 
> Yes, it works on my machine. :-)
> 
> It's very hard to spot the issue if you don't provide more info.
> 
> /Anders
> On Tue, Oct 19, 2010 at 13:49, Maimon Oded  wrote:
> 
> > Hi,
> > thanks, i was able to use it as a dependency, it was easy, but the problem
> > with the directory structure remains..
> > when my file is src/main/config/myxml.xml and i set the output directory to
> > be conf the result is
> > conf/src/main/config/myxml.xml
> > while i want it to just be
> > conf/myxml.xml
> >
> > i guess that i'm doing something wrong here..
> >
> > thanks.
> >
> > On Tue, Oct 19, 2010 at 1:23 PM, Anders Hammar  wrote:
> >
> > > OK, move the config file to a separate project then. The use the
> > dependency
> > > plugin as someone else suggested, and unpack.
> > >
> > > Have a look at the assembly plugin. You can control which folder stuff is
> > > added to in the archive. (define outputDirectory)
> > >
> > > /Anders
> > > On Tue, Oct 19, 2010 at 12:26, Maimon Oded 
> > wrote:
> > >
> > > > Hi,
> > > > Thanks for the very quick response.
> > > > I've one project that include a configuration file, the same
> > > configuration
> > > > file with same values need to be used in other projects (more than
> > one),
> > > i
> > > > didn't want to keep the same file on multiple projects and maintain
> > each
> > > of
> > > > them.
> > > >
> > > > i can change the structure of the project to maven structure but my
> > issue
> > > > with it is that in assembly that i create i want all files in
> > > > src/main/config to be save to conf directory, but what the assembly
> > > plugin
> > > > does instead is creating directory structure like this
> > > > conf/src/main/config/ (i actually need conf/)
> > > >
> > > > this xml file is being used by the other projects by sending the xml
> > path
> > > > as
> > > > a VM parameter...
> > > >
> > > > i hope i made my self clear...
> > > >
> > > > thanks
> > > >
> > > > On Tue, Oct 19, 2010 at 10:48 AM, Anders Hammar 
> > > wrote:
> > > >
> > > > > Your structure is not following the Maven file structure standard.
> > All
> > > > > files
> > > > > should typically be in the appropriate directory below src (like
> > > > > src/main/config, src/main/scripts, etc).
> > > > >
> > > > > I find what you're trying to do strange. We would most likely be able
> > > to
> > > > > suggest a good solution if you provided more info on what you're
> > trying
> > > > to
> > > > > actually achieve.
> > > > >
> > > > > I don't understand why you would like to assemble the c

Re: Assembly Plugin

2010-10-19 Thread Anders Hammar

Yes, it works on my machine. :-)

It's very hard to spot the issue if you don't provide more info.

/Anders
On Tue, Oct 19, 2010 at 13:49, Maimon Oded  wrote:

> Hi,
> thanks, i was able to use it as a dependency, it was easy, but the problem
> with the directory structure remains..
> when my file is src/main/config/myxml.xml and i set the output directory to
> be conf the result is
> conf/src/main/config/myxml.xml
> while i want it to just be
> conf/myxml.xml
>
> i guess that i'm doing something wrong here..
>
> thanks.
>
> On Tue, Oct 19, 2010 at 1:23 PM, Anders Hammar  wrote:
>
> > OK, move the config file to a separate project then. The use the
> dependency
> > plugin as someone else suggested, and unpack.
> >
> > Have a look at the assembly plugin. You can control which folder stuff is
> > added to in the archive. (define outputDirectory)
> >
> > /Anders
> > On Tue, Oct 19, 2010 at 12:26, Maimon Oded 
> wrote:
> >
> > > Hi,
> > > Thanks for the very quick response.
> > > I've one project that include a configuration file, the same
> > configuration
> > > file with same values need to be used in other projects (more than
> one),
> > i
> > > didn't want to keep the same file on multiple projects and maintain
> each
> > of
> > > them.
> > >
> > > i can change the structure of the project to maven structure but my
> issue
> > > with it is that in assembly that i create i want all files in
> > > src/main/config to be save to conf directory, but what the assembly
> > plugin
> > > does instead is creating directory structure like this
> > > conf/src/main/config/ (i actually need conf/)
> > >
> > > this xml file is being used by the other projects by sending the xml
> path
> > > as
> > > a VM parameter...
> > >
> > > i hope i made my self clear...
> > >
> > > thanks
> > >
> > > On Tue, Oct 19, 2010 at 10:48 AM, Anders Hammar 
> > wrote:
> > >
> > > > Your structure is not following the Maven file structure standard.
> All
> > > > files
> > > > should typically be in the appropriate directory below src (like
> > > > src/main/config, src/main/scripts, etc).
> > > >
> > > > I find what you're trying to do strange. We would most likely be able
> > to
> > > > suggest a good solution if you provided more info on what you're
> trying
> > > to
> > > > actually achieve.
> > > >
> > > > I don't understand why you would like to assemble the content of a
> > > project
> > > > plus a minor part of some other project. What's the purpose? Why
> isn't
> > > the
> > > > xml file in the project to begin with?
> > > >
> > > > /Anders
> > > >
> > > > On Tue, Oct 19, 2010 at 09:55, Maimon Oded 
> > > wrote:
> > > >
> > > > > Hi,
> > > > > I'm new to maven and I've a basic question that i hope that someone
> > can
> > > > > help
> > > > > me with, my projects structure looks something like this:
> > > > >
> > > > > My project structure is simple:
> > > > > - Project A
> > > > >  - src
> > > > >  - conf
> > > > >- myxml.xml
> > > > >  - scripts
> > > > >
> > > > > - Project B
> > > > >  - src
> > > > >
> > > > > I would like to have an assembly for project B that will include
> only
> > > the
> > > > > myxml.xml file from project A + all the files in project B,
> > > > > is it possible? how?
> > > > >
> > > > > thanks,
> > > > > Oded.
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > >
> > > Oded.
> > >
> >
>
>
>
> --
>
>
> Oded.
>

Re: Assembly Plugin

2010-10-19 Thread Maimon Oded

Hi,
thanks, i was able to use it as a dependency, it was easy, but the problem
with the directory structure remains..
when my file is src/main/config/myxml.xml and i set the output directory to
be conf the result is
conf/src/main/config/myxml.xml
while i want it to just be
conf/myxml.xml

i guess that i'm doing something wrong here..

thanks.

On Tue, Oct 19, 2010 at 1:23 PM, Anders Hammar  wrote:

> OK, move the config file to a separate project then. The use the dependency
> plugin as someone else suggested, and unpack.
>
> Have a look at the assembly plugin. You can control which folder stuff is
> added to in the archive. (define outputDirectory)
>
> /Anders
> On Tue, Oct 19, 2010 at 12:26, Maimon Oded  wrote:
>
> > Hi,
> > Thanks for the very quick response.
> > I've one project that include a configuration file, the same
> configuration
> > file with same values need to be used in other projects (more than one),
> i
> > didn't want to keep the same file on multiple projects and maintain each
> of
> > them.
> >
> > i can change the structure of the project to maven structure but my issue
> > with it is that in assembly that i create i want all files in
> > src/main/config to be save to conf directory, but what the assembly
> plugin
> > does instead is creating directory structure like this
> > conf/src/main/config/ (i actually need conf/)
> >
> > this xml file is being used by the other projects by sending the xml path
> > as
> > a VM parameter...
> >
> > i hope i made my self clear...
> >
> > thanks
> >
> > On Tue, Oct 19, 2010 at 10:48 AM, Anders Hammar 
> wrote:
> >
> > > Your structure is not following the Maven file structure standard. All
> > > files
> > > should typically be in the appropriate directory below src (like
> > > src/main/config, src/main/scripts, etc).
> > >
> > > I find what you're trying to do strange. We would most likely be able
> to
> > > suggest a good solution if you provided more info on what you're trying
> > to
> > > actually achieve.
> > >
> > > I don't understand why you would like to assemble the content of a
> > project
> > > plus a minor part of some other project. What's the purpose? Why isn't
> > the
> > > xml file in the project to begin with?
> > >
> > > /Anders
> > >
> > > On Tue, Oct 19, 2010 at 09:55, Maimon Oded 
> > wrote:
> > >
> > > > Hi,
> > > > I'm new to maven and I've a basic question that i hope that someone
> can
> > > > help
> > > > me with, my projects structure looks something like this:
> > > >
> > > > My project structure is simple:
> > > > - Project A
> > > >  - src
> > > >  - conf
> > > >- myxml.xml
> > > >  - scripts
> > > >
> > > > - Project B
> > > >  - src
> > > >
> > > > I would like to have an assembly for project B that will include only
> > the
> > > > myxml.xml file from project A + all the files in project B,
> > > > is it possible? how?
> > > >
> > > > thanks,
> > > > Oded.
> > > >
> > >
> >
> >
> >
> > --
> >
> >
> > Oded.
> >
>



-- 


Oded.

Re: Assembly Plugin

2010-10-19 Thread Anders Hammar

OK, move the config file to a separate project then. The use the dependency
plugin as someone else suggested, and unpack.

Have a look at the assembly plugin. You can control which folder stuff is
added to in the archive. (define outputDirectory)

/Anders
On Tue, Oct 19, 2010 at 12:26, Maimon Oded  wrote:

> Hi,
> Thanks for the very quick response.
> I've one project that include a configuration file, the same configuration
> file with same values need to be used in other projects (more than one), i
> didn't want to keep the same file on multiple projects and maintain each of
> them.
>
> i can change the structure of the project to maven structure but my issue
> with it is that in assembly that i create i want all files in
> src/main/config to be save to conf directory, but what the assembly plugin
> does instead is creating directory structure like this
> conf/src/main/config/ (i actually need conf/)
>
> this xml file is being used by the other projects by sending the xml path
> as
> a VM parameter...
>
> i hope i made my self clear...
>
> thanks
>
> On Tue, Oct 19, 2010 at 10:48 AM, Anders Hammar  wrote:
>
> > Your structure is not following the Maven file structure standard. All
> > files
> > should typically be in the appropriate directory below src (like
> > src/main/config, src/main/scripts, etc).
> >
> > I find what you're trying to do strange. We would most likely be able to
> > suggest a good solution if you provided more info on what you're trying
> to
> > actually achieve.
> >
> > I don't understand why you would like to assemble the content of a
> project
> > plus a minor part of some other project. What's the purpose? Why isn't
> the
> > xml file in the project to begin with?
> >
> > /Anders
> >
> > On Tue, Oct 19, 2010 at 09:55, Maimon Oded 
> wrote:
> >
> > > Hi,
> > > I'm new to maven and I've a basic question that i hope that someone can
> > > help
> > > me with, my projects structure looks something like this:
> > >
> > > My project structure is simple:
> > > - Project A
> > >  - src
> > >  - conf
> > >- myxml.xml
> > >  - scripts
> > >
> > > - Project B
> > >  - src
> > >
> > > I would like to have an assembly for project B that will include only
> the
> > > myxml.xml file from project A + all the files in project B,
> > > is it possible? how?
> > >
> > > thanks,
> > > Oded.
> > >
> >
>
>
>
> --
>
>
> Oded.
>

Re: Assembly Plugin

2010-10-19 Thread Maimon Oded

Hi,
Thanks for the very quick response.
I've one project that include a configuration file, the same configuration
file with same values need to be used in other projects (more than one), i
didn't want to keep the same file on multiple projects and maintain each of
them.

i can change the structure of the project to maven structure but my issue
with it is that in assembly that i create i want all files in
src/main/config to be save to conf directory, but what the assembly plugin
does instead is creating directory structure like this
conf/src/main/config/ (i actually need conf/)

this xml file is being used by the other projects by sending the xml path as
a VM parameter...

i hope i made my self clear...

thanks

On Tue, Oct 19, 2010 at 10:48 AM, Anders Hammar  wrote:

> Your structure is not following the Maven file structure standard. All
> files
> should typically be in the appropriate directory below src (like
> src/main/config, src/main/scripts, etc).
>
> I find what you're trying to do strange. We would most likely be able to
> suggest a good solution if you provided more info on what you're trying to
> actually achieve.
>
> I don't understand why you would like to assemble the content of a project
> plus a minor part of some other project. What's the purpose? Why isn't the
> xml file in the project to begin with?
>
> /Anders
>
> On Tue, Oct 19, 2010 at 09:55, Maimon Oded  wrote:
>
> > Hi,
> > I'm new to maven and I've a basic question that i hope that someone can
> > help
> > me with, my projects structure looks something like this:
> >
> > My project structure is simple:
> > - Project A
> >  - src
> >  - conf
> >- myxml.xml
> >  - scripts
> >
> > - Project B
> >  - src
> >
> > I would like to have an assembly for project B that will include only the
> > myxml.xml file from project A + all the files in project B,
> > is it possible? how?
> >
> > thanks,
> > Oded.
> >
>



-- 


Oded.

Re: Assembly Plugin

2010-10-19 Thread Anders Hammar

Your structure is not following the Maven file structure standard. All files
should typically be in the appropriate directory below src (like
src/main/config, src/main/scripts, etc).

I find what you're trying to do strange. We would most likely be able to
suggest a good solution if you provided more info on what you're trying to
actually achieve.

I don't understand why you would like to assemble the content of a project
plus a minor part of some other project. What's the purpose? Why isn't the
xml file in the project to begin with?

/Anders

On Tue, Oct 19, 2010 at 09:55, Maimon Oded  wrote:

> Hi,
> I'm new to maven and I've a basic question that i hope that someone can
> help
> me with, my projects structure looks something like this:
>
> My project structure is simple:
> - Project A
>  - src
>  - conf
>- myxml.xml
>  - scripts
>
> - Project B
>  - src
>
> I would like to have an assembly for project B that will include only the
> myxml.xml file from project A + all the files in project B,
> is it possible? how?
>
> thanks,
> Oded.
>

Re: Assembly Plugin

2010-10-19 Thread Nick Stolwijk

If it is a dependency of Project A and Project B it belongs to its own
module and be treated as a dependency. It is the easiest way, really.

Another option would be to use the dependency plugin unpack goal with
an includes of the needed file. [1]

[1] http://maven.apache.org/plugins/maven-dependency-plugin/unpack-mojo.html

Hth,

Nick Stolwijk
~Java Developer~

IPROFS BV.
Claus Sluterweg 125
2012 WS Haarlem
http://www.iprofs.nl



On Tue, Oct 19, 2010 at 9:55 AM, Maimon Oded  wrote:
> Hi,
> I'm new to maven and I've a basic question that i hope that someone can help
> me with, my projects structure looks something like this:
>
> My project structure is simple:
> - Project A
>  - src
>  - conf
>    - myxml.xml
>  - scripts
>
> - Project B
>  - src
>
> I would like to have an assembly for project B that will include only the
> myxml.xml file from project A + all the files in project B,
> is it possible? how?
>
> thanks,
> Oded.
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Assembly plugin: Same file with several file extensions?

2010-05-27 Thread Karl Heinz Marbaise


Hi Eric,

have you located the files you want to include into the src/main/resources
folder? If yes than they should be included automatically ...May be i didn't
understand what you like to do?

Kind regards
Karl Heinz Marbaise
-- 
View this message in context: 
http://old.nabble.com/Assembly-plugin%3A-Same-file-with-several-file-extensions--tp28692233p28693892.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: assembly plugin descriptorRefs use in org.apache:apache:7 pom

2010-04-13 Thread Marshall Schor



On 4/13/2010 10:15 AM, Marshall Schor wrote:
>
> On 4/13/2010 10:04 AM, Marshall Schor wrote:
>   
>> In the org.apache:apache:7 pom, a common parent-pom for apache projects,
>> I see in the apache-release profile section, a part which creates the
>> source-release artifact.
>>
>> This runs the maven-assembly-plugin, and passes it a dependency on
>> org.apache.apache.resources:apache-source-release-assembly-descriptor:1.0.2.
>>
>> In the configuration, it specifies a descriptorRef of
>> ${sourceReleaseAssemblyDescriptor}.
>>
>> I looked in the documentation for the maven-assembly-plugin, and can't
>> find this usage documented.
>>
>> So - some questions:
>>
>> Is the value of descriptorRef ( ${sourceReleaseAssemblyDescriptor} ) a
>> maven "property"?  If so, where is it set?
>>
>> The "descriptorRef" parameter is documented to refer to one of 4
>> built-in assembly descriptors.  Is this usage allowing it to refer to
>> some other non-built-in descriptor?  If so, how is the linkage
>> established (I presume via the "dependency" element, but what name(s)?
>> need to match with what to make this magic happen?
>>   
>> 
> I found the answer to this here:
>
> http://www.sonatype.com/books/mvnref-book/reference/assemblies-sect-best-practices.html#assemblies-sect-standard-reusable
>
> It doesn't however describe the "property", but instead uses a plain
> string.  So I still have that question...
>   

Found the answer to that, below in the file, where the line
source-release
defines this as the string "source-release"

Thanks for listening :-)  -Marshall

> -Marshall
>   
>> Or, have I guessed incorrectly as to what is happening here ;-) ?
>>
>> -Marshall
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>>
>>   
>> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
>
>   

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: assembly plugin descriptorRefs use in org.apache:apache:7 pom

2010-04-13 Thread Marshall Schor



On 4/13/2010 10:04 AM, Marshall Schor wrote:
> In the org.apache:apache:7 pom, a common parent-pom for apache projects,
> I see in the apache-release profile section, a part which creates the
> source-release artifact.
>
> This runs the maven-assembly-plugin, and passes it a dependency on
> org.apache.apache.resources:apache-source-release-assembly-descriptor:1.0.2.
>
> In the configuration, it specifies a descriptorRef of
> ${sourceReleaseAssemblyDescriptor}.
>
> I looked in the documentation for the maven-assembly-plugin, and can't
> find this usage documented.
>
> So - some questions:
>
> Is the value of descriptorRef ( ${sourceReleaseAssemblyDescriptor} ) a
> maven "property"?  If so, where is it set?
>
> The "descriptorRef" parameter is documented to refer to one of 4
> built-in assembly descriptors.  Is this usage allowing it to refer to
> some other non-built-in descriptor?  If so, how is the linkage
> established (I presume via the "dependency" element, but what name(s)?
> need to match with what to make this magic happen?
>   

I found the answer to this here:

http://www.sonatype.com/books/mvnref-book/reference/assemblies-sect-best-practices.html#assemblies-sect-standard-reusable

It doesn't however describe the "property", but instead uses a plain
string.  So I still have that question...

-Marshall
> Or, have I guessed incorrectly as to what is happening here ;-) ?
>
> -Marshall
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
>
>   

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Assembly plugin: specifying an alternative extension name for the assembly

2010-02-04 Thread Graham Charters

Thanks, Joe.  I've only just got round to looking into this again.  I
found I can get this to work by adding the following to the maven
assembly plugin's components.xml file:


  org.codehaus.plexus.archiver.Archiver
  ext
  
org.codehaus.plexus.archiver.zip.ZipArchiver
  per-lookup


Where 'ext' is the extension I want to use instead of zip.  I've only
been able to get this to work by having my own copy of the maven
assembly plugin.  Is there any other way to provide this configuration
from outside the maven assembly plugin?

Many thanks for any help.

Regards, Graham.




On 19 November 2009 13:03, Joe Hindsley  wrote:
> Hi Graham,
>
> The extension for the assembly is configured with the  element of
> the assembly descriptor. There are only a couple of supported formats. My
> guess is that you'd have to write a custom Archiver to get a different
> extension, but haven't looked under the hood of the assembly plugin to know
> for sure.
>
> More information is here:
>
> http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_assembly
>
> Joe Hindsley
>
>
> Graham Charters wrote:
>>
>> Hi,
>>
>> I'm trying to create a zip file using the assembly plugin, but I'd
>> like it to have a different extension (not .zip).  I've tried using
>> , but that still insists on giving the file the .zip
>> extension.
>>
>> Is this possible using the assembly plugin, or should I be using something
>> else?
>>
>> Many thanks for any help.
>>
>> Regards, Graham.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Assembly plugin corrupting generated source

2010-01-19 Thread Wayne Fay

> I am not sure what you are proposing. Wouldn't I still mvn install my
> artifacts before running  mvn assembly on my assembly project?

Its highly likely that my suggestion of using "single" is not
appropriate since you don't want to install things.

I'm not a hardcore assembly user. I am ok with multiple invocations to
build my projects. I am primarily pragmatic when it comes to
development practices.

If you are not ok with multiple invocations, then I guess you'll need
to solve this yourself another way or hope someone else posts with
help.

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Assembly plugin corrupting generated source

I am not sure what you are proposing. Wouldn't I still mvn install my
artifacts before running  mvn assembly on my assembly project?

Jeff

On Tue, Jan 19, 2010 at 4:34 PM, Wayne Fay  wrote:

> > I would prefer to build the entire project from one command line. If I
> put
> > the assembly into a sub project that is two steps. I must install all of
> my
> > artifacts and then run assembly on another module. While feasible it
> seems
> > wrong to me that I can't simply walk up to the top level and build my
> entire
> > maven project using a single command line.
>
> Can you not use the assembly:single mojo and bind it in that assembly
> module to the package phase?
>
> 
> 
> make-assembly
> package
> 
> single...
>
> Wayne
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Assembly plugin corrupting generated source

2010-01-19 Thread Wayne Fay

> I would prefer to build the entire project from one command line. If I put
> the assembly into a sub project that is two steps. I must install all of my
> artifacts and then run assembly on another module. While feasible it seems
> wrong to me that I can't simply walk up to the top level and build my entire
> maven project using a single command line.

Can you not use the assembly:single mojo and bind it in that assembly
module to the package phase?



make-assembly
package

single...

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Assembly plugin corrupting generated source

Because of the comment here. I have never been able to get my project to
build properly if I attach my assembly as a  build step.

http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html

*NOTE:* Because of a quirk in Maven 2.0's execution model relating to
aggregator mojos and the inheritance hierarchy, we need to explicitly
execute the package phase ahead of the assembly invocation, to ensure all
modules have been built.

I would prefer to build the entire project from one command line. If I put
the assembly into a sub project that is two steps. I must install all of my
artifacts and then run assembly on another module. While feasible it seems
wrong to me that I can't simply walk up to the top level and build my entire
maven project using a single command line.

Again, my project builds fine. if I do mvn package from the top level.
 However things only go awry when using the assembly plugin.

On Tue, Jan 19, 2010 at 3:00 PM, Wayne Fay  wrote:

> > I assume this is because I have no assembly at the top level.  Since I am
> > not installing the jar-a -> jar-b in the local repo I can't run assembly
> on
> > the sub module as I will get errors regarding missing dependencies.
>
> Why not?? "I don't want to" is not a valid answer. Maven uses its
> repository for a lot of things, you need to get comfortable using it.
>
> Is there a reason you're specifying assembly:assembly from the command
> line instead of simply binding it in your pom?
>
> Wayne
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Assembly plugin corrupting generated source

2010-01-19 Thread Wayne Fay

> I assume this is because I have no assembly at the top level.  Since I am
> not installing the jar-a -> jar-b in the local repo I can't run assembly on
> the sub module as I will get errors regarding missing dependencies.

Why not?? "I don't want to" is not a valid answer. Maven uses its
repository for a lot of things, you need to get comfortable using it.

Is there a reason you're specifying assembly:assembly from the command
line instead of simply binding it in your pom?

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Assembly plugin corrupting generated source

I have uploaded a second copy of my project

http://weseewhathappens.com/mvn2.zip

I took your suggestion and create a second module called assembly.  And
moved the assembly plugin there. I also added my other jars as dependencies.

At the top level if I run

mvn package, things work fine as expected.

if I run

mvn package assembly:assembly

I get

[INFO] Error reading assemblies: No assembly descriptors found.

I assume this is because I have no assembly at the top level.  Since I am
not installing the jar-a -> jar-b in the local repo I can't run assembly on
the sub module as I will get errors regarding missing dependencies.

On Tue, Jan 19, 2010 at 1:09 PM, Bill Smith wrote:

> Woult this new module for the assembly be a jar module or a pom only
> module?
>
>
> On Mon, Jan 18, 2010 at 9:38 PM, Wayne Fay  wrote:
>
>> > I think what you are suggesting is rather then have a parent module to
>> have
>> > another module at the same level as the jar/wars and list them as actual
>> > dependencies?
>>
>> Yes. The parent will be merely a "pom" project with no assembly plugin
>> declared, and then you'll have another module under it that is simply
>> your assembly project which lists the other modules as dependencies.
>>
>> You can read more about assemblies in the Sonatype book "Maven the
>> definitive guide" free online, especially section 8.6.2:
>> http://www.sonatype.com/books/mvnref-book/reference/assemblies.html
>>
>> Wayne
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>

Re: Assembly plugin corrupting generated source