OK, so I checked. We are indeed using our own archetype-plugin. It can resolve 
files that have variables in the name.

This way we can include several 'system'-files (like for CVS) and other files 
that are always needed, but have different names/packages depending on our 
project. Think along the lines of using the groupId as the package-name for 
java-classes.

So, I suggest you look into writing your own archetype-plugin or find one that 
can do similar things as our plugin.


On Friday 02 October 2009 11:21, you wrote:
> We are doing something similar in our company, although I curently can't
> tell you the exact solution (not at work yet).
> I believe we are using some renaming-scheme like calling those files
> '${DOT}cvsignore'  and then have the archetype replace the variable 'DOT'
> with '.'.
>
> As I said, I'm not 100% sure if this is our exact solution and if it works
> out of the box or if we implemented our own archetype-plugin. You could
> try this and I will get back at you when I'm at work to check this.
>
> Roland
>
> > Hi,
> >
> > We are stuck on using archetype on a complex multiproject template we
> > would like to give to our developpers. We need to automatize the artefact
> > publication for obvious reasons, but , it's not possible to add
> > .cvsignore files on archetypes using the archetype:create-from-project
> > goal.
> >
> > It is important for those files to be present prior to the developper
> > first projet commit, otherwise it's a pain to correct afteward.
> >
> > Our workaround for the moment is to use the assembly plugin to generete a
> > ZIP file of the template projet, then the developper will do a global
> > "search and replace" of the groupID,artifactID and version in the poms.
> >
> > As another option I would think of another plugin to take over the job on
> > creating those files, like the maven-eclipse-plugin...
> >
> > Is there anyone here with a similar issue ?
> >
> > Thanks.
> >
> > antonio
> >
> > -----Message d'origine-----
> > De : Nick Stolwijk [mailto:nick.stolw...@gmail.com]
> > Envoyé : jeudi, 1. octobre 2009 19:32
> > À : PAROLINI Antonio; Maven Users List
> > Objet : Re: Ant to Maven
> >
> > See also this link:
> > http://maven.apache.org/guides/introduction/introduction-to-the-pom.html
> >
> > Nick Stolwijk
> > ~Java Developer~
> >
> > IPROFS BV.
> > Claus Sluterweg 125
> > 2012 WS Haarlem
> > http://www.iprofs.nl
> >
> >
> >
> > On Thu, Oct 1, 2009 at 7:28 PM, Nick Stolwijk <nick.stolw...@gmail.com>
> >
> > wrote:
> >> From each module there will be one main artifact, ie a jar. Sometimes
> >> there can be multiple artifacts, like javadoc or sources. If you say
> >> that your ant script generates multiple jars, you will need to have
> >> multiple modules. That can be child-parent relation, or just a
> >> aggregator pom.
> >>
> >> Child parent relation:
> >> Each module has a section <parent> which point to a pom with shared
> >> configuration and/or dependency(management).
> >>
> >> Aggregator pom:
> >> You have multiple modules in subdirectories. You create a pom file
> >> with the modules tag to kick of all the builds with one command.
> >>
> >> These strategies can be combined. Your parent pom can also be your
> >> aggregator pom.
> >>
> >> Hth,
> >>
> >> Nick Stolwijk
> >> ~Java Developer~
> >>
> >> IPROFS BV.
> >> Claus Sluterweg 125
> >> 2012 WS Haarlem
> >> http://www.iprofs.nl
> >>
> >>
> >>
> >> On Thu, Oct 1, 2009 at 7:14 PM, chicagopooldude
> >>
> >> <seshu.pit...@cmegroup.com> wrote:
> >>> Thanks for your reply I have already started to use the antrun plugin.
> >>> I
> >>> wanted to know if you can please share some documentation on using
> >>> seperate
> >>> modules. Should I use parent-child modules ?
> >>> --
> >>> View this message in context:
> >>> http://www.nabble.com/Ant-to-Maven-tp25696939p25703038.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
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org

-- 
Roland Asmann

CFC Informationssysteme Entwicklungsgesellschaft m.b.H
Bäckerstrasse 1/2/7
A-1010 Wien
FN 266155f, Handelsgericht Wien

Tel.: +43/1/513 88 77 - 27
Fax.: +43/1/513 88 62
Email: roland.asm...@cfc.at
Web: www.cfc.at

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

Reply via email to