Re: ARCHETYPE-494

[Hervé BOUTEMY]

Hi Petar,

Nice work!

I had a look, and I am a bit confused: is it about post-*generate*, ie after a 
project is generated from an archetype, or about post-*create*, ie after an 
archetype project is built from a sample project? See the workflow drawing I 
did to try to make that clear [1]

Because the Jira issue tells that it's about post-generate, but the script 
constant is ARCHETYPE_POST_GENERATION_SCRIPT = "META-INF/post_create.groovy"
and a lot of generated classes are about create (ArchetypeCreationRequest, 
CreateArchetypeFromProjectMojo, FilesetArchetypeCreator).

I see that Groovy script execution is in DefaultFilesetArchetypeGenerator, 
then it's really in archetype:generate, but then I don't understand what's the 
purpose of the code in archetype:create-from-project. And the 
"archetype.postScript" property name doesn't seem a good choice, since IMHO 
causes confusion with "archetype.postPhase": "archetype.postGenerateScript" 
would be better. But even the existence of this property seems questionable: 
can't it just be in a particular location in sample project, so it gets copied 
into META-INF/archetype-post-generate.groovy (whatever the 
ARCHETYPE_POST_GENERATION_SCRIPT constant will point to)?


I suppose some additional example in plugin's documentation, would make the 
feature easier to understand from an end-user point of view.


It's a good idea: let's continue!

Regards,

Hervé


[1] http://maven.apache.org/archetype/maven-archetype-plugin/

Le jeudi 17 décembre 2015 23:40:28 Petar Tahchiev a écrit :
> Hello all,
> 
> I've been having this idea to modify the resulting project after generating
> from a given archetype. In my particular case I'd like to be able to delete
> certain files, modify the pom.xml to add/remove dependencies, etc. After
> speaking with Herve Boutemy he suggested it would be a nice addition to the
> maven archetype plugin to be able to run a script after the project is
> generated from an archetype. I filed the enhancement here:
> 
> https://issues.apache.org/jira/browse/ARCHETYPE-494
> 
> I've also implemented it in a separate branch here:
> 
> https://git1-us-west.apache.org/repos/asf?p=maven-archetype.git;a=commit;h=d
> 60b876506e9b60ffa115c63425f837793fcaacf
> 
> The idea is very basic - if the archetype plugin finds a file called
> "post_create.groovy" in META-INF folder it will try to execute it, passing
> all the environment variables to it. I've also added a sample test-case.
> 
> I'd really like if someone takes a look on it before I merge it. Please
> share your comments here.
> 
> Thanks.


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

Re: CI core-it-maven

[Hervé BOUTEMY]

Hi,

it seems core-its use m-dependency-p version 2.8: did you try with latest, ie 
2.10?

then m-dependency-p uses shared dependency-tree, which is told to be buggy 
sometimes: I never got real examples, nor time to dig into details to find 
where the result is not consistent, but it may explain the difference when run 
with different Maven versions
At least, with latest Maven, everything is fine...

Regards,

Hervé

Le samedi 12 décembre 2015 18:05:30 Karl Heinz Marbaise a écrit :
> Hi,
> 
> after looking into the integration tests based on removing the Ant build
> i have observed a strange thing...
> 
> The following:
> https://builds.apache.org/view/M-R/view/Maven/job/core-it-maven-3-win/1045/c
> onsoleFull
> 
> is finished successfully whereas
> 
> https://builds.apache.org/view/M-R/view/Maven/job/core-it-maven-3-win/1044/c
> onsoleFull
> 
> is not finished successfully...
> 
> The only difference is that #1045 uses Maven 3.3.1 for running the
> integration tests..and #1044 uses Maven 3.0.5..
> 
> i have dived a little bit more into this and checked the bootstrap
> output during the start of the integration tests which uses mvn
> dependency:resolve-plugins which misses some artifacts:
> 
> http://localhost:8081/nexus/content/groups/public/org/apache/maven/maven-plu
> gin-parameter-documenter/2.0.6/maven-plugin-parameter-documenter-2.0.6.pom
> 
> and the running of the integration test fails on the missing for such
> artifact..During the bootstrap maven-plugin-parameter-documenter-2.0.9
> will be downloaded...but the integration test mng-5898 will try to get
> maven-plugin-parameter-documenter-2.0.6...
> 
> 
> 
> If i use Maven 3.3.1 for the integration tests the tests will work fine...
> 
> Someone an idea? what could be the root cause?...
> 
> 
> Kind regards
> Karl Heinz Marbaise
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org


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

Re: to delete windows build ?

[Hervé BOUTEMY]

is there something to do on m-shade-p before releasing 2.4.3?
because this fixed plugin version would perfectly fit the parent poms release I 
have to do...

Regards,

Hervé

Le vendredi 18 décembre 2015 07:53:19 Kristian Rosenvold a écrit :
> As long as shade is not released and updated it will probably come back.
> 
> I actually checked all the plugins for file leaks and there were no other
> leaks in the code that was being tested.
> 
> K
> 
> 2015-12-17 17:04 GMT+01:00 Tibor Digana :
> > Now the Windows build works [1] [2].
> > 
> > [1] https://builds.apache.org/job/maven-surefire-windows/
> > [2] https://issues.apache.org/jira/browse/INFRA-10724
> > 
> > On Sat, Nov 21, 2015 at 11:42 PM, Hervé BOUTEMY [via Maven] <
> > 
> > ml-node+s40175n5852667...@n5.nabble.com> wrote:
> > > ok, IIUC, this tweak seems about internal m-shade-p leaks: in such
> > > conditions,
> > > now that leaks are fixed, yes, let's just remove the code (or fix the
> > > plugin if
> > > another leak is found later)
> > > 
> > > Regards,
> > > 
> > > Hervé
> > > 
> > > Le samedi 21 novembre 2015 15:13:15 Kristian Rosenvold a écrit :
> > > > Some background is in order here; there are several file handle
> > > > "leaks" that will actually lead to the file handle being closed in a
> > > > finalizer. Which is why "shaking" System.gc a couple of times with a
> > > > sleep/retry or two sometimes actually is effective if weird :)
> > > > 
> > > > Within shade I just fixed all of these leaks to use deterministic
> > > > closing of all resources, so nothing gets closed in finalizers any
> > > > more. To my understanding these calls to System.gc and any kind of
> > > > retry logic can just be removed. So IMI it's a no-brainer, but
> > > > sometimes there's more history behind such hacks...
> > > > 
> > > > Kristian
> > > > 
> > > > 2015-11-21 11:13 GMT+01:00 Hervé BOUTEMY <[hidden email]
> > > 
> > > >:
> > > > > yes, should be deleted from a plugin silently doing such hacks: if
> > > > > we
> > > 
> > > try
> > > 
> > > > > to work around leaks issues, it should at least advertise that a
> > > > > leak
> > > 
> > > was
> > > 
> > > > > found, trying to show where the issue is
> > > > > 
> > > > > Since there is currently no warning, I don't know how much issues
> > 
> > will
> > 
> > > now
> > > 
> > > > > be visible if the plugin simply fails on such (recoverable) leaks
> > > > > 
> > > > > Do you have an idea of how much recoverable such leaks are with the
> > > > > System.gc() hack?
> > > > > 
> > > > > Just to choose if the removal should be done in 2 phases (warn
> > > > > before
> > > > > remove).
> > > > > 
> > > > > Because the only issue I fear is this hack makes the shade plugin
> > 
> > have
> > 
> > > > > support for other plugins leaks: it's probably not easy to know how
> > > 
> > > much
> > > 
> > > > > plugins have leaks...
> > > > > 
> > > > > Regards,
> > > > > 
> > > > > Hervé
> > > > > 
> > > > > Le samedi 21 novembre 2015 10:16:51 Karl Heinz Marbaise a écrit :
> > > > >> Hi Kristian,
> > > > >> 
> > > > >> On 11/21/15 9:33 AM, Kristian Rosenvold wrote:
> > > > >> > As some of you may have noticed, I have fixed a bunch of file
> > > 
> > > handle
> > > 
> > > > >> > leaks
> > > > >> > in the last weeks. This may eventually make running a CI on
> > 
> > windows
> > 
> > > > >> > feasible :)
> > > > >> > 
> > > > >> > The shade plugin was leaking like a sieve, and should now be
> > > > >> > fully
> > > > >> > watertight. There seems to be a few bits of silly code that I'd
> > > 
> > > just
> > > 
> > > > >> > like
> > > > >> > to remove, since the root cause in all likelyhood is fixed:
> > > > >> > 
> > > > >> > For instance this;
> > > 
> > > https://maven.apache.org/plugins/maven-shade-plugin/xref/org/apache/mav
> > > 
> > > > >> > en/
> > > > >> > plugins/shade/mojo/ShadeMojo.html#L643
> > > > >> 
> > > > >> This is definitively a thing which should be deleted...
> > > > >> 
> > > > >> > Any objections ?
> > > > >> 
> > > > >> No..
> > > > >> 
> > > > >> > Kristian
> > > > >> > 
> > > > >> > 5. nov. 2015 5.29 p.m. skrev "Tibor Digana"
> > > 
> > > <[hidden email]  > 
> > /user/SendEmail.jtp?type=node=5852667=1>>:
> > > > >> >> This issues is caused by long Windows paths.
> > > > >> >> INFRA made shorter file names and issue disappeared.
> > > > >> >> Reported issue with Git 2.6.2 installation requirements and Git
> > > > >> >> variable
> > > > >> >> "core.longPaths=true" setup, see
> > > > >> >> https://issues.apache.org/jira/browse/INFRA-10724.
> > > > >> >> 
> > > > >> >> On Fri, Oct 23, 2015 at 6:22 AM, Kristian Rosenvold <
> > > > >> >> 
> > > > >> >> [hidden email]
> > > 
> > > > wrote:
> > > > >> >>> (Tibor; I'm taking this to the mailing list)
> > > > >> >>> 
> > > > >> >>> 
> > > > >> >>> It would appear that we are leaking file handles/resources when
> > > 
> > > being
> > > 
> > > 

Re: to delete windows build ?

[Kristian Rosenvold]

Afaik it can be released any time.
18. des. 2015 16.38 skrev "Hervé BOUTEMY" :

> is there something to do on m-shade-p before releasing 2.4.3?
> because this fixed plugin version would perfectly fit the parent poms
> release I
> have to do...
>
> Regards,
>
> Hervé
>
> Le vendredi 18 décembre 2015 07:53:19 Kristian Rosenvold a écrit :
> > As long as shade is not released and updated it will probably come back.
> >
> > I actually checked all the plugins for file leaks and there were no other
> > leaks in the code that was being tested.
> >
> > K
> >
> > 2015-12-17 17:04 GMT+01:00 Tibor Digana :
> > > Now the Windows build works [1] [2].
> > >
> > > [1] https://builds.apache.org/job/maven-surefire-windows/
> > > [2] https://issues.apache.org/jira/browse/INFRA-10724
> > >
> > > On Sat, Nov 21, 2015 at 11:42 PM, Hervé BOUTEMY [via Maven] <
> > >
> > > ml-node+s40175n5852667...@n5.nabble.com> wrote:
> > > > ok, IIUC, this tweak seems about internal m-shade-p leaks: in such
> > > > conditions,
> > > > now that leaks are fixed, yes, let's just remove the code (or fix the
> > > > plugin if
> > > > another leak is found later)
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > Le samedi 21 novembre 2015 15:13:15 Kristian Rosenvold a écrit :
> > > > > Some background is in order here; there are several file handle
> > > > > "leaks" that will actually lead to the file handle being closed in
> a
> > > > > finalizer. Which is why "shaking" System.gc a couple of times with
> a
> > > > > sleep/retry or two sometimes actually is effective if weird :)
> > > > >
> > > > > Within shade I just fixed all of these leaks to use deterministic
> > > > > closing of all resources, so nothing gets closed in finalizers any
> > > > > more. To my understanding these calls to System.gc and any kind of
> > > > > retry logic can just be removed. So IMI it's a no-brainer, but
> > > > > sometimes there's more history behind such hacks...
> > > > >
> > > > > Kristian
> > > > >
> > > > > 2015-11-21 11:13 GMT+01:00 Hervé BOUTEMY <[hidden email]
> > > >
> > > > >:
> > > > > > yes, should be deleted from a plugin silently doing such hacks:
> if
> > > > > > we
> > > >
> > > > try
> > > >
> > > > > > to work around leaks issues, it should at least advertise that a
> > > > > > leak
> > > >
> > > > was
> > > >
> > > > > > found, trying to show where the issue is
> > > > > >
> > > > > > Since there is currently no warning, I don't know how much issues
> > >
> > > will
> > >
> > > > now
> > > >
> > > > > > be visible if the plugin simply fails on such (recoverable) leaks
> > > > > >
> > > > > > Do you have an idea of how much recoverable such leaks are with
> the
> > > > > > System.gc() hack?
> > > > > >
> > > > > > Just to choose if the removal should be done in 2 phases (warn
> > > > > > before
> > > > > > remove).
> > > > > >
> > > > > > Because the only issue I fear is this hack makes the shade plugin
> > >
> > > have
> > >
> > > > > > support for other plugins leaks: it's probably not easy to know
> how
> > > >
> > > > much
> > > >
> > > > > > plugins have leaks...
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Hervé
> > > > > >
> > > > > > Le samedi 21 novembre 2015 10:16:51 Karl Heinz Marbaise a écrit :
> > > > > >> Hi Kristian,
> > > > > >>
> > > > > >> On 11/21/15 9:33 AM, Kristian Rosenvold wrote:
> > > > > >> > As some of you may have noticed, I have fixed a bunch of file
> > > >
> > > > handle
> > > >
> > > > > >> > leaks
> > > > > >> > in the last weeks. This may eventually make running a CI on
> > >
> > > windows
> > >
> > > > > >> > feasible :)
> > > > > >> >
> > > > > >> > The shade plugin was leaking like a sieve, and should now be
> > > > > >> > fully
> > > > > >> > watertight. There seems to be a few bits of silly code that
> I'd
> > > >
> > > > just
> > > >
> > > > > >> > like
> > > > > >> > to remove, since the root cause in all likelyhood is fixed:
> > > > > >> >
> > > > > >> > For instance this;
> > > >
> > > >
> https://maven.apache.org/plugins/maven-shade-plugin/xref/org/apache/mav
> > > >
> > > > > >> > en/
> > > > > >> > plugins/shade/mojo/ShadeMojo.html#L643
> > > > > >>
> > > > > >> This is definitively a thing which should be deleted...
> > > > > >>
> > > > > >> > Any objections ?
> > > > > >>
> > > > > >> No..
> > > > > >>
> > > > > >> > Kristian
> > > > > >> >
> > > > > >> > 5. nov. 2015 5.29 p.m. skrev "Tibor Digana"
> > > >
> > > > <[hidden email]  > >
> > > /user/SendEmail.jtp?type=node=5852667=1>>:
> > > > > >> >> This issues is caused by long Windows paths.
> > > > > >> >> INFRA made shorter file names and issue disappeared.
> > > > > >> >> Reported issue with Git 2.6.2 installation requirements and
> Git
> > > > > >> >> variable
> > > > > >> >> "core.longPaths=true" setup, see
> > > > > >> >> https://issues.apache.org/jira/browse/INFRA-10724.
> > > > > >> >>
> > > > > >> >> On Fri, Oct 

Re: ARCHETYPE-494

[Petar Tahchiev]

Hello Herve,

thanks for the feedback. Indeed, looking at your email I realize the file
naming is not the best. To answer your question - it is both post-create
and post-generate. I'm developing a project which later on I make into an
archetype using mvn archetype:create-from-project. This script lies in the
src/main/resources/META-INF/post_create.groovy and after archetype creation
it ends up in the jar's META-INF/post_create.groovy.

I guess the best would be to rename the file to
archetype-post-generate.groovy and not use any properties - just detect if
a file is present
then put it in the META-INF during archetype:create-from-project and
respectfully if a file called archetype-post-generate.groovy is in the
META-INF
folder then try to execute it. How does this sound?

2015-12-18 13:48 GMT+02:00 Hervé BOUTEMY :

> Hi Petar,
>
> Nice work!
>
> I had a look, and I am a bit confused: is it about post-*generate*, ie
> after a
> project is generated from an archetype, or about post-*create*, ie after an
> archetype project is built from a sample project? See the workflow drawing
> I
> did to try to make that clear [1]
>
> Because the Jira issue tells that it's about post-generate, but the script
> constant is ARCHETYPE_POST_GENERATION_SCRIPT =
> "META-INF/post_create.groovy"
> and a lot of generated classes are about create (ArchetypeCreationRequest,
> CreateArchetypeFromProjectMojo, FilesetArchetypeCreator).
>
> I see that Groovy script execution is in DefaultFilesetArchetypeGenerator,
> then it's really in archetype:generate, but then I don't understand what's
> the
> purpose of the code in archetype:create-from-project. And the
> "archetype.postScript" property name doesn't seem a good choice, since IMHO
> causes confusion with "archetype.postPhase": "archetype.postGenerateScript"
> would be better. But even the existence of this property seems
> questionable:
> can't it just be in a particular location in sample project, so it gets
> copied
> into META-INF/archetype-post-generate.groovy (whatever the
> ARCHETYPE_POST_GENERATION_SCRIPT constant will point to)?
>
>
> I suppose some additional example in plugin's documentation, would make the
> feature easier to understand from an end-user point of view.
>
>
> It's a good idea: let's continue!
>
> Regards,
>
> Hervé
>
>
> [1] http://maven.apache.org/archetype/maven-archetype-plugin/
>
> Le jeudi 17 décembre 2015 23:40:28 Petar Tahchiev a écrit :
> > Hello all,
> >
> > I've been having this idea to modify the resulting project after
> generating
> > from a given archetype. In my particular case I'd like to be able to
> delete
> > certain files, modify the pom.xml to add/remove dependencies, etc. After
> > speaking with Herve Boutemy he suggested it would be a nice addition to
> the
> > maven archetype plugin to be able to run a script after the project is
> > generated from an archetype. I filed the enhancement here:
> >
> > https://issues.apache.org/jira/browse/ARCHETYPE-494
> >
> > I've also implemented it in a separate branch here:
> >
> >
> https://git1-us-west.apache.org/repos/asf?p=maven-archetype.git;a=commit;h=d
> > 60b876506e9b60ffa115c63425f837793fcaacf
> >
> > The idea is very basic - if the archetype plugin finds a file called
> > "post_create.groovy" in META-INF folder it will try to execute it,
> passing
> > all the environment variables to it. I've also added a sample test-case.
> >
> > I'd really like if someone takes a look on it before I merge it. Please
> > share your comments here.
> >
> > Thanks.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

[GitHub] maven pull request: MNG-5837: Use a subshell, rather than the 'loc...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/maven/pull/50


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Modello Pull Request

[Petar Tahchiev]

Hi guys,

I've been playing with the MavenXpp3Reader/MavenXpp3Writer lately. I
managed to generate a pom.xml but my maven-rat-plugin failed because my
generated pom.xml did not have the appropriate license header. Then I
decided to add a new field in the MavenXpp3Writer called "fileComment". I
modified the code so that if this field is not null, we use the string that
is set as a comment on file level. Now I can do this:

org.apache.maven.model.io.xpp3.MavenXpp3Writer writer = new
org.apache.maven.model.io.xpp3.MavenXpp3Writer();
writer.setFileComment("My comment");
writer.write(new FileWriter(file), model);

and the generated pom.xml has a "My comment" on top.

It's all in here:
https://github.com/codehaus-plexus/modello/pull/3

Please someone review and merge.

Thanks.

-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

[GitHub] maven pull request: Fix MNG-5538

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/maven/pull/27


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: ARCHETYPE-494

[Hervé BOUTEMY]

yes, this sounds reasonable :)

Regards,

Hervé

Le vendredi 18 décembre 2015 21:27:48 Petar Tahchiev a écrit :
> Hello Herve,
> 
> thanks for the feedback. Indeed, looking at your email I realize the file
> naming is not the best. To answer your question - it is both post-create
> and post-generate. I'm developing a project which later on I make into an
> archetype using mvn archetype:create-from-project. This script lies in the
> src/main/resources/META-INF/post_create.groovy and after archetype creation
> it ends up in the jar's META-INF/post_create.groovy.
> 
> I guess the best would be to rename the file to
> archetype-post-generate.groovy and not use any properties - just detect if
> a file is present
> then put it in the META-INF during archetype:create-from-project and
> respectfully if a file called archetype-post-generate.groovy is in the
> META-INF
> folder then try to execute it. How does this sound?
> 
> 2015-12-18 13:48 GMT+02:00 Hervé BOUTEMY :
> > Hi Petar,
> > 
> > Nice work!
> > 
> > I had a look, and I am a bit confused: is it about post-*generate*, ie
> > after a
> > project is generated from an archetype, or about post-*create*, ie after
> > an
> > archetype project is built from a sample project? See the workflow drawing
> > I
> > did to try to make that clear [1]
> > 
> > Because the Jira issue tells that it's about post-generate, but the script
> > constant is ARCHETYPE_POST_GENERATION_SCRIPT =
> > "META-INF/post_create.groovy"
> > and a lot of generated classes are about create (ArchetypeCreationRequest,
> > CreateArchetypeFromProjectMojo, FilesetArchetypeCreator).
> > 
> > I see that Groovy script execution is in DefaultFilesetArchetypeGenerator,
> > then it's really in archetype:generate, but then I don't understand what's
> > the
> > purpose of the code in archetype:create-from-project. And the
> > "archetype.postScript" property name doesn't seem a good choice, since
> > IMHO
> > causes confusion with "archetype.postPhase":
> > "archetype.postGenerateScript"
> > would be better. But even the existence of this property seems
> > questionable:
> > can't it just be in a particular location in sample project, so it gets
> > copied
> > into META-INF/archetype-post-generate.groovy (whatever the
> > ARCHETYPE_POST_GENERATION_SCRIPT constant will point to)?
> > 
> > 
> > I suppose some additional example in plugin's documentation, would make
> > the
> > feature easier to understand from an end-user point of view.
> > 
> > 
> > It's a good idea: let's continue!
> > 
> > Regards,
> > 
> > Hervé
> > 
> > 
> > [1] http://maven.apache.org/archetype/maven-archetype-plugin/
> > 
> > Le jeudi 17 décembre 2015 23:40:28 Petar Tahchiev a écrit :
> > > Hello all,
> > > 
> > > I've been having this idea to modify the resulting project after
> > 
> > generating
> > 
> > > from a given archetype. In my particular case I'd like to be able to
> > 
> > delete
> > 
> > > certain files, modify the pom.xml to add/remove dependencies, etc. After
> > > speaking with Herve Boutemy he suggested it would be a nice addition to
> > 
> > the
> > 
> > > maven archetype plugin to be able to run a script after the project is
> > > generated from an archetype. I filed the enhancement here:
> > > 
> > > https://issues.apache.org/jira/browse/ARCHETYPE-494
> > 
> > > I've also implemented it in a separate branch here:
> > https://git1-us-west.apache.org/repos/asf?p=maven-archetype.git;a=commit;h
> > =d> 
> > > 60b876506e9b60ffa115c63425f837793fcaacf
> > > 
> > > The idea is very basic - if the archetype plugin finds a file called
> > > "post_create.groovy" in META-INF folder it will try to execute it,
> > 
> > passing
> > 
> > > all the environment variables to it. I've also added a sample test-case.
> > > 
> > > I'd really like if someone takes a look on it before I merge it. Please
> > > share your comments here.
> > > 
> > > Thanks.
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org


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