Re: How to produce a pom.xml that is guaranteed to fail, with specific error messages
On Wed, Mar 30, 2022 at 11:52 AM Jörg Schaible wrote: > Hi David, > > On Wednesday, 30. March 2022, 19:46:35 CEST David Karr wrote: > > I work in a large company on a large project with hundreds of services, > > most of which are Java Maven projects. We have an "archetype" we use for > > new services. It doesn't use the Maven archetype process. There are > > particular areas in the pom.xml that is generated that really need to be > > modified by the developer to reflect their actual application. > > > > We could certainly put comments in the template that tell the developer > > what sort of changes need to be made, but I wonder if there's any way we > > can ensure that they notice and handle particular areas of the pom.xml. > > Just generating a comment with directions isn't enough. I wish there was > > some way I could ensure that running the build would fail with a specific > > error message if they haven't dealt with each area. I suppose I could > > create an XML syntax error in each area that should be addressed, with > text > > near the error that explains what to do, but that seems like a bit of a > > hack, although it may be the only strategy I can use. Is there a cleaner > > way to do this sort of thing that I'm not aware of? > > Add the maven-verifier-plugin and a verification file to your archetype, > bind it > to the validation phase and check the content of the pom.xml. If it still > contains your placeholders, it can fail your build. > I've never looked at the verifier before. This could be useful. It's unfortunate that it doesn't provide any way to communicate anything in the log when the build fails. I at least submitted an enhancement request for that.
Re: How to produce a pom.xml that is guaranteed to fail, with specific error messages
On Wed, Mar 30, 2022 at 11:52 AM Shipp, Scott wrote: > Are you saying that this is not a Maven archetype or that it is? The Maven > archtetype feature allows the POM (and other files) to be templated. It > sounds like exactly what you are looking for. Check out > https://maven.apache.org/guides/mini/guide-creating-archetypes.html it > will probably do what you want. > Actually, I was mistaken. The service generation process does use a Maven archetype. > From: David Karr > Date: Wednesday, March 30, 2022 at 10:47 AM > To: Maven Users List > Subject: How to produce a pom.xml that is guaranteed to fail, with > specific error messages > External Email > > I work in a large company on a large project with hundreds of services, > most of which are Java Maven projects. We have an "archetype" we use for > new services. It doesn't use the Maven archetype process. There are > particular areas in the pom.xml that is generated that really need to be > modified by the developer to reflect their actual application. > > We could certainly put comments in the template that tell the developer > what sort of changes need to be made, but I wonder if there's any way we > can ensure that they notice and handle particular areas of the pom.xml. > Just generating a comment with directions isn't enough. I wish there was > some way I could ensure that running the build would fail with a specific > error message if they haven't dealt with each area. I suppose I could > create an XML syntax error in each area that should be addressed, with text > near the error that explains what to do, but that seems like a bit of a > hack, although it may be the only strategy I can use. Is there a cleaner > way to do this sort of thing that I'm not aware of? >
Re: How to produce a pom.xml that is guaranteed to fail, with specific error messages
Hi David, On Wednesday, 30. March 2022, 19:46:35 CEST David Karr wrote: > I work in a large company on a large project with hundreds of services, > most of which are Java Maven projects. We have an "archetype" we use for > new services. It doesn't use the Maven archetype process. There are > particular areas in the pom.xml that is generated that really need to be > modified by the developer to reflect their actual application. > > We could certainly put comments in the template that tell the developer > what sort of changes need to be made, but I wonder if there's any way we > can ensure that they notice and handle particular areas of the pom.xml. > Just generating a comment with directions isn't enough. I wish there was > some way I could ensure that running the build would fail with a specific > error message if they haven't dealt with each area. I suppose I could > create an XML syntax error in each area that should be addressed, with text > near the error that explains what to do, but that seems like a bit of a > hack, although it may be the only strategy I can use. Is there a cleaner > way to do this sort of thing that I'm not aware of? Add the maven-verifier-plugin and a verification file to your archetype, bind it to the validation phase and check the content of the pom.xml. If it still contains your placeholders, it can fail your build. Regards, Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to produce a pom.xml that is guaranteed to fail, with specific error messages
Are you saying that this is not a Maven archetype or that it is? The Maven archtetype feature allows the POM (and other files) to be templated. It sounds like exactly what you are looking for. Check out https://maven.apache.org/guides/mini/guide-creating-archetypes.html it will probably do what you want. From: David Karr Date: Wednesday, March 30, 2022 at 10:47 AM To: Maven Users List Subject: How to produce a pom.xml that is guaranteed to fail, with specific error messages External Email I work in a large company on a large project with hundreds of services, most of which are Java Maven projects. We have an "archetype" we use for new services. It doesn't use the Maven archetype process. There are particular areas in the pom.xml that is generated that really need to be modified by the developer to reflect their actual application. We could certainly put comments in the template that tell the developer what sort of changes need to be made, but I wonder if there's any way we can ensure that they notice and handle particular areas of the pom.xml. Just generating a comment with directions isn't enough. I wish there was some way I could ensure that running the build would fail with a specific error message if they haven't dealt with each area. I suppose I could create an XML syntax error in each area that should be addressed, with text near the error that explains what to do, but that seems like a bit of a hack, although it may be the only strategy I can use. Is there a cleaner way to do this sort of thing that I'm not aware of?
Re: How to produce a pom.xml that is guaranteed to fail, with specific error messages
Syntax error sounds like the best thing - using a enforcer plugin to produce an error will not be possible in arbritary locations. And of course you also can add a commit or review hook to block template snippets to be committed. Not sure if any of that is required if you have a commit review process. Gruss Bernd -- http://bernd.eckenfels.net Von: David Karr Gesendet: Wednesday, March 30, 2022 7:46:35 PM An: Maven Users List Betreff: How to produce a pom.xml that is guaranteed to fail, with specific error messages I work in a large company on a large project with hundreds of services, most of which are Java Maven projects. We have an "archetype" we use for new services. It doesn't use the Maven archetype process. There are particular areas in the pom.xml that is generated that really need to be modified by the developer to reflect their actual application. We could certainly put comments in the template that tell the developer what sort of changes need to be made, but I wonder if there's any way we can ensure that they notice and handle particular areas of the pom.xml. Just generating a comment with directions isn't enough. I wish there was some way I could ensure that running the build would fail with a specific error message if they haven't dealt with each area. I suppose I could create an XML syntax error in each area that should be addressed, with text near the error that explains what to do, but that seems like a bit of a hack, although it may be the only strategy I can use. Is there a cleaner way to do this sort of thing that I'm not aware of?
How to produce a pom.xml that is guaranteed to fail, with specific error messages
I work in a large company on a large project with hundreds of services, most of which are Java Maven projects. We have an "archetype" we use for new services. It doesn't use the Maven archetype process. There are particular areas in the pom.xml that is generated that really need to be modified by the developer to reflect their actual application. We could certainly put comments in the template that tell the developer what sort of changes need to be made, but I wonder if there's any way we can ensure that they notice and handle particular areas of the pom.xml. Just generating a comment with directions isn't enough. I wish there was some way I could ensure that running the build would fail with a specific error message if they haven't dealt with each area. I suppose I could create an XML syntax error in each area that should be addressed, with text near the error that explains what to do, but that seems like a bit of a hack, although it may be the only strategy I can use. Is there a cleaner way to do this sort of thing that I'm not aware of?
Re: Getting the groupid, artifact id, and version of the package under test
It is actually easier than that, there is no need to use system
properties. You can pass a parameter to an agent's 'premain' and
'agentmain' methods, which have signatures
public static void premain(
String commandLineOptions,
Instrumentation instr
)
public static void agentmain(
String commandLineOptions,
Instrumentation instr
)
Simply pass the information after '=' in
-javaagent:/path/to/myagent.jar=whatever
If 'whatever' is a simple string or something you want to further parse
and break down into key-value pairs or so, is totally up to you. I.e.
something like
${myJavaAgent}=${project.groupId}:${project.artifactId}
would be just fine.
--
Alexander Kriegisch
https://scrum-master.de
John Patrick schrieb am 30.03.2022 19:34 (GMT +07:00):
> I would do this via a profile, default value and surefire config, so
> something like;
>
>
>
> withJavaAgent
>
> -javaagent:C:\JARS\agent.jar
>
>
>
>
>
>
>
> maven-surefire-plugin
>
> ${myJavaAgent}
> -DtheGroup=${project.groupId} -DtheArtifact=${project.artifactId}
>
>
>
> Then if you want to override on the command line it's; mvn test
> -DmyJavaAgent="-javaagent:C:\JARS\agent.jar"
> Or; mvn test -PwithJavaAgent
>
> John
>
>
> On Wed, 30 Mar 2022 at 06:45, Laurian Angelescu
> wrote:
>
>> I am working on a Java agent that instruments test suites and the code
>> under test. The agent runs by invoking the following command on the command
>> line:
>>
>> mvn test -DargLine="-javaagent:C:\JARS\agent.jar"
>>
>> The apache surefire plugin takes care of running the tests and pushing the
>> -DargLine argument to the test JVM.
>>
>> But for hierarchical projects, I believe multiple JVMs are instantiated,
>> one for each child package configured with pom.xml, as *mvn test *is
>> recusively invoked downstream. I would like to keep track of each such
>> child by capturing in mid-flight the group id, artifact id and version if
>> it's available and passing this information into the agent.
>>
>> Is there a way to accomplish this data capture? Assume JUnit test suites.
>>
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Getting the groupid, artifact id, and version of the package under test
I would do this via a profile, default value and surefire config, so
something like;
withJavaAgent
-javaagent:C:\JARS\agent.jar
maven-surefire-plugin
${myJavaAgent}
-DtheGroup=${project.groupId} -DtheArtifact=${project.artifactId}
Then if you want to override on the command line it's; mvn test
-DmyJavaAgent="-javaagent:C:\JARS\agent.jar"
Or; mvn test -PwithJavaAgent
John
On Wed, 30 Mar 2022 at 06:45, Laurian Angelescu
wrote:
> I am working on a Java agent that instruments test suites and the code
> under test. The agent runs by invoking the following command on the command
> line:
>
> mvn test -DargLine="-javaagent:C:\JARS\agent.jar"
>
> The apache surefire plugin takes care of running the tests and pushing the
> -DargLine argument to the test JVM.
>
> But for hierarchical projects, I believe multiple JVMs are instantiated,
> one for each child package configured with pom.xml, as *mvn test *is
> recusively invoked downstream. I would like to keep track of each such
> child by capturing in mid-flight the group id, artifact id and version if
> it's available and passing this information into the agent.
>
> Is there a way to accomplish this data capture? Assume JUnit test suites.
>
Call for Presentations now open, ApacheCon North America 2022
[You are receiving this because you are subscribed to one or more user or dev mailing list of an Apache Software Foundation project.] ApacheCon draws participants at all levels to explore “Tomorrow’s Technology Today” across 300+ Apache projects and their diverse communities. ApacheCon showcases the latest developments in ubiquitous Apache projects and emerging innovations through hands-on sessions, keynotes, real-world case studies, trainings, hackathons, community events, and more. The Apache Software Foundation will be holding ApacheCon North America 2022 at the New Orleans Sheration, October 3rd through 6th, 2022. The Call for Presentations is now open, and will close at 00:01 UTC on May 23rd, 2022. We are accepting presentation proposals for any topic that is related to the Apache mission of producing free software for the public good. This includes, but is not limited to: Community Big Data Search IoT Cloud Fintech Pulsar Tomcat You can submit your session proposals starting today at https://cfp.apachecon.com/ Rich Bowen, on behalf of the ApacheCon Planners apachecon.com @apachecon - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
