Re: Augment pom dependencies information with custom ones

[Anton Tanasenko]

Hi François,

If you have control over report generation, what you can do is add xml
processing instructions into your pom files that your plugin can later
parse out of the xml without interfering with existing pom model.
M2Eclipse uses that approach to add some metadata to plugin executions.
Here's [1] the code pointer that performs the parsing from maven model.

[1]
https://github.com/eclipse/m2e-core/blob/master/org.eclipse.m2e.core/src/org/eclipse/m2e/core/internal/lifecyclemapping/AnnotationMappingMetadataSource.java#L168

чт, 5 дек. 2019 г. в 20:44, Anthony Whitford :

> Hi François,
>
> I would start with the Dependency Analyze Report:
> http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html
>  >
> It offers valuable insight because it can often tell you whether your
> dependencies are used or unused.
>
> Simply ensure that this plugin is part of your 
> section, and then when you build your site, you will have this report.  You
> can see a simple example here:
> http://anthonywhitford.com/lombok.maven/test-maven-lombok/dependency-analysis.html
> <
> http://anthonywhitford.com/lombok.maven/test-maven-lombok/dependency-analysis.html
> >
>
> Note that this report does have 1 major flaw — it does not recognize
> dynamically loaded dependencies, so it can false alert in the “Unused but
> declared dependencies” section.  In my example, it reports logback-classic
> is unused, however it is the runtime implementation dynamically loaded by
> slf4j-api.  My dependency declaration has the `runtime` scope, which is a
> clue that this is intentional.  I have seen more examples with the Spring
> Framework.
>
> You mentioned that you have “tooo many” dependencies.  I hope you are
> leveraging Maven correctly such that you are declaring your direct
> dependencies only, and allowing Maven to calculate the transitive
> dependencies.  This can dramatically cut down your direct dependency
> management overhead.  If you are doing this incorrectly, the Dependency
> Analyze Report may offer some insight into opportunities to cull
> dependencies.
>
> Finally, the Dependency Tree, found in the Project Dependencies report, is
> also useful to understand transitive dependencies.  Similar functionality
> is available from the command-line using:  mvn dependency:tree
>
> Note that these reports have a bunch of configuration options.  For
> example, dependencies may be forced as being marked as Used, or skipped
> from being analyzed.  Perhaps you can leverage that functionality along
> with POM comments to help document your dependency chain.
>
> Hope this helps,
>
> Anthony
>
>
> > On Dec 5, 2019, at 9:56 AM, Francois MAROT 
> wrote:
> >
> > Hello again (I'm active there today ;) ),
> >
> > this time I'd like to tell you about a feature I would like, and maybe
> some
> > of you will have something to advise me.
> > I have to generate a report listing all my dependencies (and I have
> tooo
> > many !) and for each one I have to provide a little text telling why I
> chose
> > this library.
> > The best way I could imagine would be to have an optional < rationale />
> tag
> > in the < dependency /> block in order to document this directly in the
> pom.
> > But to my knowledge this is not possible (maybe for the next version of
> the
> > pom format ?!). Then a simple plugin could generate directly a report.
> >
> > For the moment, I have used the license-maven-plugin which lists all the
> > dependencies in an html file that I have manually edited to add the info.
> > But it is not future proof and I will have to do it again next time ! Is
> > there any plugin that would take as input both your dependencies and a
> file
> > containing the choice rationale (for each dependency GAV) and would
> generate
> > an html listing dependencies and their rationale ?
> >
> > Have a good day !
> > François
> >
> >
> >
> > --
> > Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
>

-- 
Regards,
Anton.

Re: How to rewrite POMs retaining the XML structure

[Anton Tanasenko]

In the past I've used decentxml as a lightweight reader/writer which
retains everything as-is.

https://bitbucket.org/digulla/decentxml/wiki/Home


пт, 30 нояб. 2018 г. в 02:47, Chris Barlock :

> SInce it is XML, you could use the Java DOM or Sax parsers.
>
> Chris
>
>
>
>
> From:   Marc Rohlfs 
> To: users@maven.apache.org
> Date:   11/29/2018 07:42 PM
> Subject:How to rewrite POMs retaining the XML structure
>
>
>
> Hi all,
>
> is there a way to rewrite pom.xml files without loosing formatting,
> ordering and comments?
>
> We need to (programmatically) do several changes on Maven POMs, e.g.
> adding
> and removing dependencies and properties. Currently we're using
> the MavenXpp3Reader and MavenXpp3Writer classes to read and write the
> pom.xml files, but in the output files, all comments are removed, the XML
> nodes are reordered and formatting (indentations, empty lines) is lost.
> Does anybody know a way how to read and write POM files without loosing
> formatting ordering and comments?
>
> Best regards
> Marc
>
>
>
>
>

-- 
Regards,
Anton.

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 2)

[Anton Tanasenko]

Yeah, that could work as well.

On Tue, 14 Jun 2016, 21:05 Christian Schulte,  wrote:

> http://git-wip-us.apache.org/repos/asf/maven/commit/ded1379e
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 2)

[Anton Tanasenko]

Yes, exactly. To be able to show markers at correct locations in an editor,
we need to know if a particular problem is sourced at this particular file.
Since early 2.x versions of this source was exactly one path to a file and
now it has changed.

So it would be really helpful to know what the new format is.

On Tue, 14 Jun 2016, 20:37 Christian Schulte,  wrote:

> Am 06/14/16 um 18:46 schrieb Anton Tanasenko:
> > Christian? Anyone?
> >
> > 2016-06-13 1:19 GMT+03:00 Anton Tanasenko :
> >
> >> I've tried running m2eclipse tests with 3.4.0-SNAPSHOT maven. There are
> >> several failures.
> >>
> >> 1. src/x/resources-filtered addition, which we will need to adhere to
> when
> >> 3.4.0 gets released.
> >>
> >> 2.
> >>
> https://github.com/apache/maven/commit/508e16e23d66de09893d1eb52dff6a1c5ca019b3#diff-9cdcbb55d918f0d251c34a5e2fd863e8R168
> >> The change above causes the source to have the path to the pom.xml
> >> duplicated, in my test case it's
> >> "D:\work\eclipse\eclipse-rcp-mars-sr1\ws2\test\testproject\pom.xml
> >> [D:\work\eclipse\eclipse-rcp-mars-sr1\ws2\test\testproject\pom.xml]"
> >> M2e is looking at this source when generating error markers for pom
> files
> >> in the workspace and with 3.4 it's not doing it correctly, since the
> value
> >> is no longer one single path.
> >> Can somebody describe what possible values could this new "X [Y]" format
> >> contain when X and Y are not the same?
> >>
>
> You mean if 'getSource' does not return 'null' you expect it to be an
> absolute path to the pom file of of the problem?
>
> /**
>  * Gets the hint about the source of the problem. While the syntax
> of this hint is unspecified and depends on the
>  * creator of the problem, the general expectation is that the hint
> provides sufficient information to the user to
>  * track the problem back to its origin. A concrete example for such
> a source hint can be the file path or URL from
>  * which a POM was read.
>  *
>  * @return The hint about the source of the problem or an empty
> string if unknown, never {@code null}.
>  */
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 2)

[Anton Tanasenko]

Christian? Anyone?

2016-06-13 1:19 GMT+03:00 Anton Tanasenko :

> I've tried running m2eclipse tests with 3.4.0-SNAPSHOT maven. There are
> several failures.
>
> 1. src/x/resources-filtered addition, which we will need to adhere to when
> 3.4.0 gets released.
>
> 2.
> https://github.com/apache/maven/commit/508e16e23d66de09893d1eb52dff6a1c5ca019b3#diff-9cdcbb55d918f0d251c34a5e2fd863e8R168
> The change above causes the source to have the path to the pom.xml
> duplicated, in my test case it's
> "D:\work\eclipse\eclipse-rcp-mars-sr1\ws2\test\testproject\pom.xml
> [D:\work\eclipse\eclipse-rcp-mars-sr1\ws2\test\testproject\pom.xml]"
> M2e is looking at this source when generating error markers for pom files
> in the workspace and with 3.4 it's not doing it correctly, since the value
> is no longer one single path.
> Can somebody describe what possible values could this new "X [Y]" format
> contain when X and Y are not the same?
>
> There are more failures, but I'll need to look at them more closely.
>
>
> 2016-06-12 23:40 GMT+03:00 Karl Heinz Marbaise :
>
>> Hi to all Maven users,
>>
>> based on the issues which have been found with the first one here is
>> another chance to help .
>>
>> It would be nice if those who have found issues to retest their scenarios.
>>
>> Is someone of you willing to do some testing on the current state of
>> development for the upcoming Maven 3.4.0 release?
>>
>> Please be aware of this *** This is not an official release ***
>>
>> I have created downloadable packages which are available from here:
>>
>> Windows: https://s.apache.org/bnAi,
>> Linux: https://s.apache.org/TrbK
>>
>>
>> Every kind of feedback is helpful.
>>
>> This is only a current state of development (Git hash:
>> 92334a1dd9f2f3df77b3c039be7742ea19a8ee81) to get some feedback from the
>> community...
>>
>> The current list of changes can be seen in the issue tracker:
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>>
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>
>
> --
> Regards,
> Anton.
>



-- 
Regards,
Anton.

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 2)

[Anton Tanasenko]

I've tried running m2eclipse tests with 3.4.0-SNAPSHOT maven. There are
several failures.

1. src/x/resources-filtered addition, which we will need to adhere to when
3.4.0 gets released.

2.
https://github.com/apache/maven/commit/508e16e23d66de09893d1eb52dff6a1c5ca019b3#diff-9cdcbb55d918f0d251c34a5e2fd863e8R168
The change above causes the source to have the path to the pom.xml
duplicated, in my test case it's
"D:\work\eclipse\eclipse-rcp-mars-sr1\ws2\test\testproject\pom.xml
[D:\work\eclipse\eclipse-rcp-mars-sr1\ws2\test\testproject\pom.xml]"
M2e is looking at this source when generating error markers for pom files
in the workspace and with 3.4 it's not doing it correctly, since the value
is no longer one single path.
Can somebody describe what possible values could this new "X [Y]" format
contain when X and Y are not the same?

There are more failures, but I'll need to look at them more closely.


2016-06-12 23:40 GMT+03:00 Karl Heinz Marbaise :

> Hi to all Maven users,
>
> based on the issues which have been found with the first one here is
> another chance to help .
>
> It would be nice if those who have found issues to retest their scenarios.
>
> Is someone of you willing to do some testing on the current state of
> development for the upcoming Maven 3.4.0 release?
>
> Please be aware of this *** This is not an official release ***
>
> I have created downloadable packages which are available from here:
>
> Windows: https://s.apache.org/bnAi,
> Linux: https://s.apache.org/TrbK
>
>
> Every kind of feedback is helpful.
>
> This is only a current state of development (Git hash:
> 92334a1dd9f2f3df77b3c039be7742ea19a8ee81) to get some feedback from the
> community...
>
> The current list of changes can be seen in the issue tracker:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Regards,
Anton.

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing

[Anton Tanasenko]

It would be great if there was a way to enable/disable color using a
separate option or system property.
Adding -B could disable color by default, but explicitly enabling it might
prove useful in, say, Jenkins with AnsiColor plugin.

2016-06-12 23:39 GMT+03:00 Baptiste Mathus :

> Well, as I hadn't tested this version and was just guessing /by intuition/
> on what I generally use --batch-mode for, I'd disagree on your last
> statement :).
> But agreed it might be interesting to have some words about it in the help.
> Patches/PR are always welcome.
>
> 2016-06-12 22:15 GMT+02:00 Oliver B. Fischer :
>
> > Yes, running with -B disables the colorized output.
> >
> > But at least the description of this option should mention this too
> > because IMHO it is not intuitive that -B disables the colors.
> >
> >
> > WDYT?
> >
> > Am 12.06.16 um 22:09 schrieb Baptiste Mathus:
> >
> >> Didn't test it, but using batch mode would seem natural for that IMO.
> >>
> >> My 2 cents
> >>
> >> 2016-06-12 22:04 GMT+02:00 Oliver B. Fischer  >:
> >>
> >> The colorized output is very nice, but I would like to have also a
> >>> commandline option to disable it. I often redirect the output of Maven
> >>> to a
> >>> file to check the build. All the escape sequences are disturbing in
> this
> >>> case.
> >>>
> >>> Running mvn --help I didn't see an option to disable it. Could such an
> >>> option be added?
> >>>
> >>> Am 11.06.16 um 22:21 schrieb Karl Heinz Marbaise:
> >>>
> >>> --
> >>> N Oliver B. Fischer
> >>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >>> P +49 30 44793251
> >>> M +49 178 7903538
> >>> E o.b.fisc...@swe-blog.net
> >>> S oliver.b.fischer
> >>> J oliver.b.fisc...@jabber.org
> >>> X http://xing.to/obf
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: users-h...@maven.apache.org
> >>>
> >>>
> >>>
> > --
> > N Oliver B. Fischer
> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > P +49 30 44793251
> > M +49 178 7903538
> > E o.b.fisc...@swe-blog.net
> > S oliver.b.fischer
> > J oliver.b.fisc...@jabber.org
> > X http://xing.to/obf
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>



-- 
Regards,
Anton.

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing

[Anton Tanasenko]

Hi,
There is a commit for MNG-2478 which I think could cause problems for
projects that are authored using 3.4.0 and the new resources-filtered
source folder is used (provided it was not configured in the project as
such before). Those projects will not be buildable with prior maven
versions.
This is not something major, but it does break backwards compatibility
somewhat. Is that ok?

https://issues.apache.org/jira/browse/MNG-2478


2016-06-11 23:21 GMT+03:00 Karl Heinz Marbaise :

> Hi to all Maven users,
>
> is someone of you willing to do some testing on the current state of
> development for the upcoming Maven 3.4.0 release?
>
> Please be aware of this *** This is not an official release ***
>
> I have created downloadable packages which are available from here:
>
> Windows: https://s.apache.org/fawM,
> Linux: https://s.apache.org/RQ3C
>
>
> Every kind of feedback is helpful.
>
> This is only a current state of development (Git hash:
> 644ac9c40ad41bf61e3b099918af33b8eb950621) to get some feedback from the
> community...
>
> The current list of changes can be seen in the issue tracker:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Regards,
Anton.

Re: Status on namespace support for POM Elements ?

[Anton Tanasenko]

With eclipse we do autocompletion for nested elements using reflection, if
type information is available (e.g. generics are used for List and Map
elements) in almost the same as in Maven (almost - because maven takes
config and tries to apply each separate value, while from the editor we
need to discover what the model is overall - this might lead to
inconsistencies in some corner cases). Also it's worth to note that maven
doesn't look at @Parameter annotations in nested elements, it's all
reflection.

2016-06-05 23:23 GMT+03:00 Roland Huss :

>
> > Just on a side note, eclipse m2e pom editor does have an autocomplete for
> > plugin configuration based on the plugin descriptor and the classes that
> > are used.
> > +1 to namespace support though, since it could be used to provide
> > autocomplete for parts that cannot be deduced by looking at the model
> > (xpp3dom elements, maps, etc.)
>
> That's true for IDEA as well. Autocompletion works nicely on top-level
> configuration elements, however for nested structures like lists and
> maps it doesn't work so well. I.e. deducing the element name of a
> list-element it e.g. not possible by an IDE since in Maven afaik any
> name is allowed for a list-element's tag. In my case
> (docker-maven-plugin) I have configuration which is nested up to four
> levels. That's one of the reason wgy I'm looking for IDE support here
> (which as I said seems to work only on the top-level in IDEA).
>
> How is the situation in Eclipse ? Is it possible to do autocompletion on
> list elements (and their @Parameter), too ?
>
> In general I have the feeling that support for XSD based autocompletion
> is much more matured in IDEs.
>
> ... roland
>
>
> > 2016-06-05 12:32 GMT+03:00 Stian Soiland-Reyes :
> >
> >> +1 to ALLOW (but not require) the second use case of  >> xmlns=..>, this let you have autocomplete say in Eclipse's XML editor.
> >> However I believe a xsi schemalocation would then still be needed per
> >> plugin unless a catalogue is accessible out of bands, so it would still
> be
> >> a bit verbose.
> >>
> >> (I never understood why the default xsi schemalocation can't be the
> >> namespace)
> >> On 5 Jun 2016 8:38 a.m., "Roland Huss"  wrote:
> >>
>  Do you really think introducing XML namespaces would make the handling
>  of the pom better ? In particular if you have a separate namespace for
>  every plugin? (At apache maven project we have 49 plugins ? This would
>  mean in consequence 49 namespaces? And at mojohaus there are about
>  another 50 plugins? So this means having to use the configuration
>  parameters for all the plugins and on top you need to do namespace
>  configuration in your pom file? I'm the opinion this would make things
>  worse than better...(There are some things which are better)...
> >>>
> >>> I don't request to *require* the use of namespaces, but not to break if
> >>> a namespace is used. It would be competely sufficient when Maven would
> >>> ignore namespaces. The  element is specified having a
> >>>  content anyway.
> >>>
> >>> BTW, you don't have to specify the namespace on top, but can do at
> >>> directly on the enclosing element itself.
> >>>
> >>> Here's my use case: I'm writing a Maven plugin which has an XSD for its
> >>> configuration. This is useful for rich autocompletion and inline
> >>> documentation tooltips in a decent IDE.
> >>>
> >>> There are two ways how you could use this xsd:
> >>>
> >>> * You can declare a namespace with prefix in the preamble of your
> >>> pom.xml but then have to use the prefix for all your configuration
> >>> options (which is quite a lot in my use case). You are not required to
> >>> use a namespace, though (because of the  type of a
> configuration)
> >>>
> >>> * Or, the better, more elegant way is to switch to the default
> namespace
> >>> to your plugin int the  element :
> >>>
> >>> http://www.w3.org/2001/XMLSchema-instance";
> >>>  xmlns="http://maven.apache.org/POM/4.0.0";
> >>>  xsi:schemaLocation="">
> >>> ...
> >>> 
> >>>
> >>> >>> xmlns:m="http://maven.apache.org/POM/4.0.0";
> >>> xmlns="https://myplugin.org/v1";>
> >>>
> >>>   bla
> >>>
> >>>
> >>> 
> >>> ...
> >>> 
> >>>
> >>> Both usage patterns are currently broken in Maven 3.3.9
> >>>
>  In general pom changes in any way could only become part of pom model
> 5
>  (Maven 4/5 in line)  cause it would break to many things...You can
> take
>  a deep look into the jira for Maven 4..
> 
> >>>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12330198
> >>>
> >>> There is no change in the pom syntax required at all (i.e. the Schema
> is
> >>> exactly the same as defined in http://maven.apache.org/POM/4.0.0), its
> >>> only about the proper XML parsing of a pom model 4 with namespaces
> >>> (which btw each decent XML parser is capable of).
> >>>
> >>> But eve

Re: Status on namespace support for POM Elements ?

[Anton Tanasenko]

Just on a side note, eclipse m2e pom editor does have an autocomplete for
plugin configuration based on the plugin descriptor and the classes that
are used.
+1 to namespace support though, since it could be used to provide
autocomplete for parts that cannot be deduced by looking at the model
(xpp3dom elements, maps, etc.)

2016-06-05 12:32 GMT+03:00 Stian Soiland-Reyes :

> +1 to ALLOW (but not require) the second use case of  xmlns=..>, this let you have autocomplete say in Eclipse's XML editor.
> However I believe a xsi schemalocation would then still be needed per
> plugin unless a catalogue is accessible out of bands, so it would still be
> a bit verbose.
>
> (I never understood why the default xsi schemalocation can't be the
> namespace)
> On 5 Jun 2016 8:38 a.m., "Roland Huss"  wrote:
>
> > > Do you really think introducing XML namespaces would make the handling
> > > of the pom better ? In particular if you have a separate namespace for
> > > every plugin? (At apache maven project we have 49 plugins ? This would
> > > mean in consequence 49 namespaces? And at mojohaus there are about
> > > another 50 plugins? So this means having to use the configuration
> > > parameters for all the plugins and on top you need to do namespace
> > > configuration in your pom file? I'm the opinion this would make things
> > > worse than better...(There are some things which are better)...
> >
> > I don't request to *require* the use of namespaces, but not to break if
> > a namespace is used. It would be competely sufficient when Maven would
> > ignore namespaces. The  element is specified having a
> >  content anyway.
> >
> > BTW, you don't have to specify the namespace on top, but can do at
> > directly on the enclosing element itself.
> >
> > Here's my use case: I'm writing a Maven plugin which has an XSD for its
> > configuration. This is useful for rich autocompletion and inline
> > documentation tooltips in a decent IDE.
> >
> > There are two ways how you could use this xsd:
> >
> > * You can declare a namespace with prefix in the preamble of your
> > pom.xml but then have to use the prefix for all your configuration
> > options (which is quite a lot in my use case). You are not required to
> > use a namespace, though (because of the  type of a configuration)
> >
> > * Or, the better, more elegant way is to switch to the default namespace
> > to your plugin int the  element :
> >
> > http://www.w3.org/2001/XMLSchema-instance";
> >  xmlns="http://maven.apache.org/POM/4.0.0";
> >  xsi:schemaLocation="">
> > ...
> > 
> >
> > > xmlns:m="http://maven.apache.org/POM/4.0.0";
> > xmlns="https://myplugin.org/v1";>
> >
> >   bla
> >
> >
> > 
> > ...
> > 
> >
> > Both usage patterns are currently broken in Maven 3.3.9
> >
> > > In general pom changes in any way could only become part of pom model 5
> > > (Maven 4/5 in line)  cause it would break to many things...You can take
> > > a deep look into the jira for Maven 4..
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12330198
> >
> > There is no change in the pom syntax required at all (i.e. the Schema is
> > exactly the same as defined in http://maven.apache.org/POM/4.0.0), its
> > only about the proper XML parsing of a pom model 4 with namespaces
> > (which btw each decent XML parser is capable of).
> >
> > But even then, is the document
> >
> >
> https://cwiki.apache.org/confluence/display/MAVEN/Moving+forward+with+the+POM+data+model
> > obsolete /wrt to XML namespaces ? Or what is the status of namespace
> > support for the next major Maven version ? (sorry, couldn't find any
> > information about this).
> >
> > cheers ...
> > ... roland
> >
> > >
> > >
> > >
> > > Kind regards
> > > Karl Heinz Marbaise
> > >
> > > -
> > > 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
> >
> >
>



-- 
Regards,
Anton.

Re: iText 4.2.0 - Could a software licence be changed from MPL/LGPL to AGPL by simply redistributing the pom.xml?

[Anton Tanasenko]

This is weird indeed.
iText changed license/package starting from 5 and onwards.
4.2.0 wasn't officially released but sources are there and they are still
under MPL/LGPL and anyone can always build the jar himself [1] and I guess
nothing disallows one to distribute such jar, right?
Someone must've built and uploaded 4.2.0 unofficially to central in 2012.

The relocation in the recent pom, however, means that when you try depend
on 4.2.0 version, maven will actually download the AGPLed 5.5.6 version
which would be a serious problem.
I think the pom for 4.2.0 in central must be restored to its original state
[2].

[1]
http://sourceforge.net/p/itext/code/6803/log/?path=/tags/iText_4_2_0/src/ant/pom.xml
[2]
http://sourceforge.net/p/itext/code/4107/tree/tags/iText_4_2_0/src/ant/pom.xml


2016-01-20 2:38 GMT+02:00 Dan Tran :

> For my case, my Legal folks as my team to remove it
>
> Best to consult with your IP attorney
>
> -Dan
>
> On Tue, Jan 19, 2016 at 2:58 PM, Siegfried Goeschl 
> wrote:
>
> > Hi folks,
> >
> > I have a simple simple question - is it possible/legal to change the
> > software licence by simply re-distributing a POM a couple of years later?
> >
> > During a code review I came across a project using itext-4.2.0-jar.
> >
> > AFAIK iText 2.1.7 was the last version under MPL/LGPL and later they
> moved
> > to AGPL V3 - I suggested to remove the library but the developer insisted
> > that the library was indeed under MPL :-O
> >
> > * He showed me itext-4.2.0.jar/META-INF/maven/com.lowagie/itext/pom.xml
> > clearly displaying a MPL/LGPL licence
> > * I pointed him to
> >
> http://search.maven.org/#artifactdetails%7Ccom.lowagie%7Citext%7C4.2.0%7Cpom
> > clearly displaying a AGPL V3 licence
> >
> > But the
> >
> http://search.maven.org/remotecontent?filepath=com/lowagie/itext/4.2.0/itext-4.2.0.pom
> > actually contains a "relocation" section
> >
> > 
> > 
> > GNU Affero General Public License v3
> > http://www.fsf.org/licensing/licenses/agpl-3.0.html
> > 
> > 
> > 
> > 
> > com.itextpdf
> > itextpdf
> > 5.5.6
> > After release 2.1.7, iText moved from the MPLicense to
> > the AGPLicense.
> > The groupId changed from com.lowagie to com.itextpdf and the
> > artifactId from itext to itextpdf.
> > See http://itextpdf.com/functionalitycomparison for more
> > information.
> > 
> > 
> >
> > Mhmm, that puzzled me because itext-4.2.0.jar still has "com.lowagie"
> > package name so I started digging through Maven Central
> >
> >
> > 1) What Maven Central Says
> > ===
> >
> > http://repo1.maven.org/maven2/com/lowagie/itext/4.2.0/
> >
> > itext-4.2.0-bundle.jar.asc 20-Sep-2012 16:34
> >490
> > itext-4.2.0-bundle.jar.asc.md5 20-Sep-2012 16:34
> > 32
> > itext-4.2.0-bundle.jar.asc.sha120-Sep-2012 16:34
> > 40
> > itext-4.2.0-javadoc.jar20-Sep-2012 16:34
> >4498819
> > itext-4.2.0-javadoc.jar.asc20-Sep-2012 16:34
> >490
> > itext-4.2.0-javadoc.jar.asc.md520-Sep-2012 16:34
> > 32
> > itext-4.2.0-javadoc.jar.asc.sha1   20-Sep-2012 16:34
> > 40
> > itext-4.2.0-javadoc.jar.md520-Sep-2012 16:34
> > 32
> > itext-4.2.0-javadoc.jar.sha1   20-Sep-2012 16:34
> > 40
> > itext-4.2.0-sources.jar20-Sep-2012 16:34
> >4061295
> > itext-4.2.0-sources.jar.asc20-Sep-2012 16:34
> >490
> > itext-4.2.0-sources.jar.asc.md520-Sep-2012 16:34
> > 32
> > itext-4.2.0-sources.jar.asc.sha1   20-Sep-2012 16:34
> > 40
> > itext-4.2.0-sources.jar.md520-Sep-2012 16:34
> > 32
> > itext-4.2.0-sources.jar.sha1   20-Sep-2012 16:34
> > 40
> > itext-4.2.0.jar20-Sep-2012 16:34
> >2243043
> > itext-4.2.0.jar.asc20-Sep-2012 16:34
> >490
> > itext-4.2.0.jar.asc.md520-Sep-2012 16:34
> > 32
> > itext-4.2.0.jar.asc.sha1   20-Sep-2012 16:34
> > 40
> > itext-4.2.0.jar.md520-Sep-2012 16:34
> > 32
> > itext-4.2.0.jar.sha1   20-Sep-2012 16:34
> > 40
> > itext-4.2.0.pom10-Jul-2015 08:16
> >   2156
> > itext-4.2.0.pom.asc10-Jul-2015 08:16
> >821
> > itext-4.2.0.pom.asc.md509-Jul-2015 12:33
> > 32
> > itext-4.2.0.pom.asc.sha1   09-Jul-2015 12:33
> >

Re: [MNG-5947] dependency management: imports and lack of nearest-wins

[Anton Tanasenko]

Hi,
I did some research not so long ago to find out the way managed dependency
versions are resolved and ended up with a following logical lookup
algorithm:

Whichever is encountered first:
1. for each pom up the hierarchy:
   a. concrete dependency
   b. managed dependency
2. for each pom up the hierarchy
   a. for each import
  I. for each pom up the hierarchy
 i. managed dependency
  II. for each pom up the hierarchy
 i. for each import = 2.a.

e.g.:
1. current pom's concrete dependency
2. current pom's managed dependency
3. parent concrete dependency
4. parent managed dependency
... go up the parent hierarchy chain until no more parents found...

5. first imported pom's managed dependency
6. its parent's managed dependency
... up the parent hierarchy ...

7. first imported pom's first imported pom (yea you can nest those further)
8. it's parent...
...
9. first imported pom's second imported pom
...
10. second imported pom...
...


Michal, does your change take imports nesting into account?


2016-01-02 18:07 GMT+02:00 Michael Osipov :

> Am 2016-01-02 um 17:00 schrieb Michał Kowalcze:
>
>> Basically it's in https://issues.apache.org/jira/browse/MNG-5947 along
>> with
>> example POMs. Graphically - having imports in dependency management like:
>>
>> final:1.0
>>
>>  + import:1.0
>>
>>  +  parent:3.2.1
>>
>>  + commons-collections:3.2.1
>>
>>  + parent:3.2.2
>>
>>  +  commons-collections:3.2.2
>>
>>
>>
>> Version for commons-collections is 3.2.1 due to first match.
>>
>
> Nearest match makes sense to, i.e., shortest path to a node when several
> are in the dependency tree.
>
> Michael
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Regards,
Anton.

Re: SNAPSHOT jar incorrectly downloaded

[Anton Tanasenko]

I observe this happening from time to time when both maven2 and maven3
builds are using the same local repository. Maven2 seems to modify metadata
files in a way that maven3 fails to work with.
Cleaning bogus artifacts from local repo makes the problem go away.

2015-11-09 12:31 GMT+02:00 :

> Hi,
>
> I am using jenkins as a build server that uses an apache archiva
> repository as default repository. That repository is specified by a custom
> settings.xml I provide to the build.
>
> Now when building such a maven project it tries to download the
> dependencies from apache archiva, but fails, because it references the
> wrong pom.
>
> Here is the output of the build:
>
> /
> <===[JENKINS REMOTING CAPACITY]===>channel started
> Executing Maven:  -B -f /mnt/raid/jenkins/workspace/MvnTest/pom.xml
> -Dmaven.repo.local=/mnt/raid/jenkins/maven-repositories/1 -s
> /opt/jenkins/mvn-settings.xml clean package
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
> 
> [INFO] Building MvnTest 1.0-SNAPSHOT
> [INFO]
> 
> Downloading:
>
> http://192.168.30.10:5501/repository/BFR/myproject/Commons/1.0-SNAPSHOT/Commons-1.0-SNAPSHOT.pom
> [WARNING] The POM for myproject:Commons:jar:1.0-SNAPSHOT is missing, no
> dependency information available
> Downloading:
>
> http://192.168.30.10:5501/repository/MYREPO/myproject/Commons/1.0-SNAPSHOT/Commons-1.0-SNAPSHOT.jar
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time: 3.091s
> [INFO] Finished at: Mon Nov 09 11:21:57 CET 2015
> [INFO] Final Memory: 7M/20M
> [INFO]
> 
> [ERROR] Failed to execute goal on project MvnTest: Could not resolve
> dependencies for project myproject:MvnTest:jar:1.0-SNAPSHOT: Could not
> find artifact myproject:Commons:jar:1.0-SNAPSHOT in MYREPO
> (http://192.168.30.10:5501/repository/MYREPO) -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
>
> http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
> /
>
> The interesting thing is that is tries to download
> Commons-1.0-SNAPSHOT.jar, which really does not exist. The files are named
> like Commons-1.0-20151109.083301-1.jar.
>
> When building this project on my workstation it works, but the output is
> also different:
>
> /
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
> 
> [INFO] Building MvnTest 1.0-SNAPSHOT
> [INFO]
> 
> Downloading:
>
> http://192.168.30.10:5501/repository/MYREPO/myproject/Commons/1.0-SNAPSHOT/maven-metadata.xml
> Downloading:
> http://central/myproject/Commons/1.0-SNAPSHOT/maven-metadata.xml
> Downloaded:
>
> http://192.168.30.10:5501/repository/MYREPO/myproject/Commons/1.0-SNAPSHOT/maven-metadata.xml
> (357 B at 1.0 KB/sec)
> [WARNING] Could not transfer metadata
> myproject:Commons:1.0-SNAPSHOT/maven-metadata.xml from/to central-snap
> (http://central): central: unknown error
> Downloading:
>
> http://192.168.30.10:5501/repository/MYREPO/myproject/Commons/1.0-SNAPSHOT/Commons-1.0-20151109.095759-4.pom
> Downloaded:
>
> http://192.168.30.10:5501/repository/MYREPO/myproject/Commons/1.0-SNAPSHOT/Commons-1.0-20151109.095759-4.pom
> (2 KB at 19.0 KB/sec)
> Downloading:
>
> http://192.168.30.10:5501/repository/MYREPO/myproject/Commons/1.0-SNAPSHOT/Commons-1.0-20151109.095759-4.jar
> Downloaded:
>
> http://192.168.30.10:5501/repository/MYREPO/myproject/Commons/1.0-SNAPSHOT/Commons-1.0-20151109.095759-4.jar
> (90 KB at 528.9 KB/sec)
> [...]
> /
>
> What is going on here?
> Thanks in advance
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Regards,
Anton.

Re: dependency resolves strange...

[Anton Tanasenko]

Yes, pom should always be named -.pom and maven model
does not define a classifier project element.
Since this particular pom does not have anything beside GAV inside, apart
from making that warning disappear and getting rid of any potential
confusion in general, it wouldn't change anything. Maven assumes such
content when it cannot find the pom file.
Glad to help.

2015-06-24 16:46 GMT+03:00 Sören Daniel Krum :

> Hello Anton!
>
> Thank you for your help! That explain some things, i was a bit confused,
> because i just opened one of the locations in my browser
>  (namely
> https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/)
> and there, oh wonder, i find the following listing:
>
> Index of /nexus/content/repositories/public/javax/script/jruby-engine/1.1/
>
> NameLast ModifiedSizeDescription
> Parent Directory
> jruby-engine-1.1-jdk14.jarFri May 23 18:44:23 UTC 2014 11276
> jruby-engine-1.1-jdk14.jar.md5Mon May 26 20:32:39 UTC 2014 32
> jruby-engine-1.1-jdk14.jar.sha1Mon May 26 20:32:39 UTC 2014 40
> jruby-engine-1.1-jdk14.pomFri May 23 18:44:28 UTC 2014190
> jruby-engine-1.1-jdk14.pom.sha1Mon May 26 20:32:39 UTC 2014 40
>
> But if i understand you correctly, the pom file placed there should be
> named jruby-engine-1.1.pom, is that correct?
>
> So, i would have to talk to mulesoft to clean their repository... Sorry
> for disturbing the mailing list
>
>
> Am 24.06.2015 um 15:30 schrieb Anton Tanasenko:
>
>> Hi,
>> If you remove all traces of jruby-engine from your local repo, you will
>> see
>> that in second case maven will try to download both pom (which is missing,
>> more on that below) and the classified jar.
>> It does not try to download the jar in the first case because it is
>> referred to from a dependency that is marked as provided (your snippet).
>> Please consult [1] and note where it says that provided scope is not
>> transitive.
>>
>> As for classifiers, those are only used on artifacts themselves, not on
>> pom. So the pom at [2] is completely wrong and will never be picked up by
>> maven.
>> Typical use case is a single project pom and several artifacts with
>> different classifiers.
>>
>> [1]
>>
>> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
>> [2]
>>
>> https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/jruby-engine-1.1-jdk14.pom
>>
>>
>> 2015-06-24 13:55 GMT+03:00 Sören Daniel Krum :
>>
>>  Hi!
>>>
>>> I found a strange behaviour when having a referring to a dependency
>>> dependency with classifier in my pom:
>>>
>>> Let us say, my pom holds the following snippet:
>>>
>>>
>>>  
>>>org.mule.modules
>>> mule-module-scripting
>>>3.6.0
>>>provided
>>>  
>>>
>>> This strange mule thingy has a pom of its own, and in there is a
>>> classified reference to javax.script:jruby-engine.
>>> Then when calling
>>>
>>> # mvn dependency:resolve -U | grep jruby-engine
>>>
>>> i see the following log lines:
>>>
>>> Downloading:
>>>
>>> https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee/javax/script/jruby-engine/1.1/jruby-engine-1.1.pom
>>> Downloading:
>>>
>>> https://repository.mulesoft.org/releases/javax/script/jruby-engine/1.1/jruby-engine-1.1.pom
>>> Downloading:
>>>
>>> https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/jruby-engine-1.1.pom
>>> Downloading:
>>>
>>> https://repo.maven.apache.org/maven2/javax/script/jruby-engine/1.1/jruby-engine-1.1.pom
>>> Downloading:
>>>
>>> https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/jruby-engine-1.1.pom
>>> [WARNING] The POM for javax.script:jruby-engine:jar:jdk14:1.1 is missing,
>>> no dependency information available
>>>
>>> So, even if the warning says that they searched for the classified
>>> (jdk14)
>>> version, the debugging says they tried a download without classifier.
>>>
>>> But when i add a direct dependency in my pom file like that:
>>>
>>> 
>>>javax.script
>>>jruby-engine
>>>1.1
>>>jdk14
>>>  
>>>
>>> The log looks like that:
>>>
>>> Dow

Re: dependency resolves strange...

[Anton Tanasenko]

Hi,
If you remove all traces of jruby-engine from your local repo, you will see
that in second case maven will try to download both pom (which is missing,
more on that below) and the classified jar.
It does not try to download the jar in the first case because it is
referred to from a dependency that is marked as provided (your snippet).
Please consult [1] and note where it says that provided scope is not
transitive.

As for classifiers, those are only used on artifacts themselves, not on
pom. So the pom at [2] is completely wrong and will never be picked up by
maven.
Typical use case is a single project pom and several artifacts with
different classifiers.

[1]
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
[2]
https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/jruby-engine-1.1-jdk14.pom


2015-06-24 13:55 GMT+03:00 Sören Daniel Krum :

> Hi!
>
> I found a strange behaviour when having a referring to a dependency
> dependency with classifier in my pom:
>
> Let us say, my pom holds the following snippet:
>
>   
> 
>   org.mule.modules
> mule-module-scripting
>   3.6.0
>   provided
> 
>
> This strange mule thingy has a pom of its own, and in there is a
> classified reference to javax.script:jruby-engine.
> Then when calling
>
> # mvn dependency:resolve -U | grep jruby-engine
>
> i see the following log lines:
>
> Downloading:
> https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee/javax/script/jruby-engine/1.1/jruby-engine-1.1.pom
> Downloading:
> https://repository.mulesoft.org/releases/javax/script/jruby-engine/1.1/jruby-engine-1.1.pom
> Downloading:
> https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/jruby-engine-1.1.pom
> Downloading:
> https://repo.maven.apache.org/maven2/javax/script/jruby-engine/1.1/jruby-engine-1.1.pom
> Downloading:
> https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/jruby-engine-1.1.pom
> [WARNING] The POM for javax.script:jruby-engine:jar:jdk14:1.1 is missing,
> no dependency information available
>
> So, even if the warning says that they searched for the classified (jdk14)
> version, the debugging says they tried a download without classifier.
>
> But when i add a direct dependency in my pom file like that:
>
> 
>   javax.script
>   jruby-engine
>   1.1
>   jdk14
> 
>
> The log looks like that:
>
> Downloading:
> https://repository.mulesoft.org/nexus-ee/content/repositories/releases-ee/javax/script/jruby-engine/1.1/jruby-engine-1.1-jdk14.jar
> Downloading:
> https://repository.mulesoft.org/releases/javax/script/jruby-engine/1.1/jruby-engine-1.1-jdk14.jar
> Downloading:
> https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/jruby-engine-1.1-jdk14.jar
> Downloaded:
> https://repository.mulesoft.org/nexus/content/repositories/public/javax/script/jruby-engine/1.1/jruby-engine-1.1-jdk14.jar
> (0 B at 0.0 KB/sec)
> [INFO]javax.script:jruby-engine:jar:jdk14:1.1:compile
>
> Then they are really resolving the classifier and they really search for
> the classified version. I attach a stripped down pom file, if someone wants
> to give it a try...
>
> Am i missing something? Or is that considered to work like that?
>
> --
> Med vennlig hilsen / Mit freundlichem Gruß / Kind regards
>
> Sören Krum
> System Ingeniør - System
> UNINETT AS
> www.uninett.no
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>



-- 
Regards,
Anton.

Re: Maven Dependency Plugin Default life cycle phase not executed

[Anton Tanasenko]

That's the point. You don't have to specify an execution phase if a default
one is set.
But you do have to express your intent to execute the mojo during build by
specifying an execution itself.

In case of dependency:unpack, its

   ...
   
  
 ..
 unpack
 ...
  
   


See, no phase.

2015-06-02 20:16 GMT+03:00 Thomas Meyer :

>
> Am 02.06.2015 6:58 nachm. schrieb Anton Tanasenko  >:
> >
> > Hi, you probably missed the previous section:
> >
>
> Oops :-)
>
> Okay, I understand now.
>
> But one more question: what use has the assigned default life cycle of the
> resp Mojo class when you need to explicitly specify the execution phase in
> the pom?
>
> > If you intend to configure this mojo for execution on the command line
> > using:
> > mvn dependency:copy
> >
> > you must not put the configuration inside the executions tag. Your
> > configuration should look like this:
> > ...
> >
> > 2015-06-02 19:36 GMT+03:00 Thomas Meyer :
> >
> > > Hi,
> > >
> > > I've a question regarding the maven dependency plugin:
> > >
> > > In the usage description (
> > > https://maven.apache.org/plugins/maven-dependency-plugin/usage.html )
> in
> > > section "The dependency:unpack mojo" it's written that:
> > >
> > > "you must not put the configuration inside the executions tag. Your
> > > configuration should look like this:"
> > >
> > > But this doesn't seem to be true as the plugin seems not get executed
> at
> > > all, at least for a project with package type "war".
> > >
> > > So what am I missing here?
> > > Any ideas?
> > >
> > > My expectation was that the plugin gets executed in the generated
> sources
> > > phase.
> > >
> > > Here an excerpt of my pom file:
> > >
> > >
> > > [...]
> > >   
> > >  
> > >maven-dependency-plugin
> > >2.10
> > >
> > > 
> > >   
> > > [...]
> > >
> > >  
> > >
> > >  
> > >  
> > > org.bsc.maven
> > > maven-processor-plugin
> > > 2.2.4
> > > 
> > > 
> > > process
> > > generate-sources
> > > 
> > > process
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ${project.build.directory}/generated-sources
> > > 
> > > 
> > > org.mapstruct.ap.MappingProcessor > > processor>
> > > 
> > > 
> > > 
> > > 
> > > org.mapstruct
> > > mapstruct-processor
> > > ${version.mapstruct}
> > > 
> > > 
> > >  
> > >
> > > I'm using maven 3.3.1.
> > >
> > > With kind regards
> > > Thomas
> >
> >
> >
> >
> > --
> > Regards,
> > Anton.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>



-- 
Regards,
Anton.

Re: Maven Dependency Plugin Default life cycle phase not executed

[Anton Tanasenko]

Hi, you probably missed the previous section:

If you intend to configure this mojo for execution on the command line
using:
mvn dependency:copy

you must not put the configuration inside the executions tag. Your
configuration should look like this:
...

2015-06-02 19:36 GMT+03:00 Thomas Meyer :

> Hi,
>
> I've a question regarding the maven dependency plugin:
>
> In the usage description (
> https://maven.apache.org/plugins/maven-dependency-plugin/usage.html ) in
> section "The dependency:unpack mojo" it's written that:
>
> "you must not put the configuration inside the executions tag. Your
> configuration should look like this:"
>
> But this doesn't seem to be true as the plugin seems not get executed at
> all, at least for a project with package type "war".
>
> So what am I missing here?
> Any ideas?
>
> My expectation was that the plugin gets executed in the generated sources
> phase.
>
> Here an excerpt of my pom file:
>
>
> [...]
>   
>  
>maven-dependency-plugin
>2.10
>
> 
>   
> [...]
>
>  
>
>  
>  
> org.bsc.maven
> maven-processor-plugin
> 2.2.4
> 
> 
> process
> generate-sources
> 
> process
> 
> 
> 
> 
> 
> ${project.build.directory}/generated-sources
> 
> 
> org.mapstruct.ap.MappingProcessor processor>
> 
> 
> 
> 
> org.mapstruct
> mapstruct-processor
> ${version.mapstruct}
> 
> 
>  
>
> I'm using maven 3.3.1.
>
> With kind regards
> Thomas




-- 
Regards,
Anton.

Re: why the defaultValue is not being injected in @Parameter inside a complex parameter bean?

[Anton Tanasenko]

Hi,

@Parameter annotations are only supported in the mojo itself, not in any
nested parameter beans.

2015-05-23 11:22 GMT+03:00 Karl Heinz Marbaise :

> Hi,
>
> On 5/23/15 12:32 AM, Cristiano Gavião wrote:
>
>> Hello,
>>
>> I'm facing a problem and would like a help to figure it out.
>>
>> I'm developing a mojo (maven 3.3) that contains the following:
>>
>> @Parameter(required=true)
>>  private ManifestConfiguration manifest;
>>
>> and in the bean (in the same package) I have:
>>
>> @Parameter(defaultValue = "${project.name}")
>>  private String name;
>>
>> What is happen is that the default value is not being injected into the
>> name field, when executing the mojo I'm getting null for it.
>>
>
> has the tag name being set in the project where you executing the plugin?
>
>
> 
>  ..
>  WhatEver
>  ..
> 
>
>
>> The strange is that for other values that I've set in a test POM they are
>> being injected properly.
>>
>> Is this supposed to work, right?
>>
>
> May be you can show the code or having it on github or bitbuchet so we can
> take a look...
>
>
>> thanks,
>>
>> Cristiano
>>
>>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Regards,
Anton.

Re: Force install of dependent modules before package

[Anton Tanasenko]

I meant "(containing other modules)" of course.

2015-04-08 22:17 GMT+03:00 Anton Tanasenko :

> Shade plugin should pick up reactor dependencies just fine, as long as the
> shading module (3 in your case) references the root project (containing
> other dependencies) correctly in the parent section.
>
>
> 2015-04-08 21:14 GMT+03:00 Eric Kolotyluk :
>
>> Adrien, while this would be what we might expect, it fails because the
>> maven-shade-plugin pulls included artifacts from the local repo.
>> Consequently, during the package phase, while packages have been built for
>> all the modules in the right order, they have not been deposited in the
>> local repo because the install phase comes after the the package phase. If
>> the shade plugin were to take the artifacts from the target directories in
>> modules 1 & 2, then all would be fine, but that is not what shade does.
>>
>> Cheers, Eric
>>
>>
>> On 2015-04-08 10:50 AM, Adrien Rivard wrote:
>>
>>> Hi,
>>>
>>> Running package in project A should run package in module1, then package
>>> in
>>> module 2, then package in module 3 (which will be build with freshly
>>> build
>>> module 1 and 2).
>>> If this is not working then something is wrong within your build (either
>>> dependencies, or modules declaration?).
>>>
>>> There is generaly no need to  run install in a correct maven build.
>>>
>>> I am not sure if this is the case, but if you declared the shaded part in
>>> the project A pom, this is the wrong place, it should be either in
>>> module 3
>>> or module 4.
>>>
>>>
>>> On Wed, Apr 8, 2015 at 7:36 PM, Eric Kolotyluk >> >
>>> wrote:
>>>
>>>  The problem I have now is that I have to manually do the following:
>>>>
>>>> project A/module 1> mvn install
>>>> project A/module 2> mvn install
>>>> project A> mvn package
>>>>
>>>> Because the maven-shade-plugin for module 3 needs the artifacts for
>>>> modules 1 & 2 to be installed in the local repo first. This totally
>>>> sucks
>>>> because it is error prone, and Maven is supposed to be about automation.
>>>> Similarly, if I do something like
>>>>
>>>> project A/module 3> mvn package
>>>>
>>>> I want modules 2 & 3 to be installed first, if necessary, so that the
>>>> shade plugin will pick up the latest versions of these artifacts.
>>>>
>>>> The other approach I am considering is to run the maven-shade-plugin in
>>>> the deploy phase, to ensure that all dependencies have been installed
>>>> first, but I really don't want to have to do a deploy this often,
>>>> especially when I am testing. I wish there were a phase between install
>>>> and
>>>> deploy that I could used to create my shaded assemblies. Is there some
>>>> way
>>>> to ensure the shade plugin runs last in the install phase, after
>>>> everything
>>>> else has been installed?
>>>>
>>>> Cheers, Eric
>>>>
>>>>
>>>> On 2015-04-08 9:47 AM, Curtis Rueden wrote:
>>>>
>>>>  Hi Eric,
>>>>>
>>>>>   project A> mvn package
>>>>>
>>>>>> such that modules 1 & 2 will automatically be installed before the
>>>>>> shade plugin runs for module 3?
>>>>>>
>>>>>>  My understanding is that you would need to run "mvn install" (not
>>>>> "mvn
>>>>> package") from the project A base directory, if you want 1 and 2 to be
>>>>> installed. But it should happen in the order you desire, no?
>>>>>
>>>>> -Curtis
>>>>>
>>>>> On Wed, Apr 8, 2015 at 11:23 AM, Anders Hammar 
>>>>> wrote:
>>>>>
>>>>>   Not sure I follow. Isn't Project A a multi-module project? Then if
>>>>> you do
>>>>>
>>>>>> "mvn package", module 1 and 2 should build before 3 if you have
>>>>>> declared
>>>>>> the dependencies correctly.
>>>>>>
>>>>>> /Anders
>>>>>>
>>>>>> On Wed, Apr 8, 2015 at 6:17 PM, Eric Kolotyluk <
>>>>>> eric.koloty...@gmail.com
>>>>>> wrote:
>>>>>>
>>>>>>   I have
>>>>>>
>>>>>>> Project A
>>>>>>> - module 1
>>>>>>> - module 2
>>>>>>> - module 3 (depends on 1 & 1)
>>>>>>> -- creates shaded artifact
>>>>>>>
>>>>>>> Is there a way that I can configure my poms to do
>>>>>>>
>>>>>>> project A> mvn package
>>>>>>>
>>>>>>> such that modules 1 & 2 will automatically be installed before the
>>>>>>> shade
>>>>>>> plugin runs for module 3?
>>>>>>>
>>>>>>> Cheers, Eric
>>>>>>>
>>>>>>>
>>>>>>> 
>>>>>>> -
>>>>>>> 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
>>
>>
>
>
> --
> Regards,
> Anton.
>



-- 
Regards,
Anton.

Re: Force install of dependent modules before package

[Anton Tanasenko]

Shade plugin should pick up reactor dependencies just fine, as long as the
shading module (3 in your case) references the root project (containing
other dependencies) correctly in the parent section.


2015-04-08 21:14 GMT+03:00 Eric Kolotyluk :

> Adrien, while this would be what we might expect, it fails because the
> maven-shade-plugin pulls included artifacts from the local repo.
> Consequently, during the package phase, while packages have been built for
> all the modules in the right order, they have not been deposited in the
> local repo because the install phase comes after the the package phase. If
> the shade plugin were to take the artifacts from the target directories in
> modules 1 & 2, then all would be fine, but that is not what shade does.
>
> Cheers, Eric
>
>
> On 2015-04-08 10:50 AM, Adrien Rivard wrote:
>
>> Hi,
>>
>> Running package in project A should run package in module1, then package
>> in
>> module 2, then package in module 3 (which will be build with freshly build
>> module 1 and 2).
>> If this is not working then something is wrong within your build (either
>> dependencies, or modules declaration?).
>>
>> There is generaly no need to  run install in a correct maven build.
>>
>> I am not sure if this is the case, but if you declared the shaded part in
>> the project A pom, this is the wrong place, it should be either in module
>> 3
>> or module 4.
>>
>>
>> On Wed, Apr 8, 2015 at 7:36 PM, Eric Kolotyluk 
>> wrote:
>>
>>  The problem I have now is that I have to manually do the following:
>>>
>>> project A/module 1> mvn install
>>> project A/module 2> mvn install
>>> project A> mvn package
>>>
>>> Because the maven-shade-plugin for module 3 needs the artifacts for
>>> modules 1 & 2 to be installed in the local repo first. This totally sucks
>>> because it is error prone, and Maven is supposed to be about automation.
>>> Similarly, if I do something like
>>>
>>> project A/module 3> mvn package
>>>
>>> I want modules 2 & 3 to be installed first, if necessary, so that the
>>> shade plugin will pick up the latest versions of these artifacts.
>>>
>>> The other approach I am considering is to run the maven-shade-plugin in
>>> the deploy phase, to ensure that all dependencies have been installed
>>> first, but I really don't want to have to do a deploy this often,
>>> especially when I am testing. I wish there were a phase between install
>>> and
>>> deploy that I could used to create my shaded assemblies. Is there some
>>> way
>>> to ensure the shade plugin runs last in the install phase, after
>>> everything
>>> else has been installed?
>>>
>>> Cheers, Eric
>>>
>>>
>>> On 2015-04-08 9:47 AM, Curtis Rueden wrote:
>>>
>>>  Hi Eric,

   project A> mvn package

> such that modules 1 & 2 will automatically be installed before the
> shade plugin runs for module 3?
>
>  My understanding is that you would need to run "mvn install" (not "mvn
 package") from the project A base directory, if you want 1 and 2 to be
 installed. But it should happen in the order you desire, no?

 -Curtis

 On Wed, Apr 8, 2015 at 11:23 AM, Anders Hammar 
 wrote:

   Not sure I follow. Isn't Project A a multi-module project? Then if
 you do

> "mvn package", module 1 and 2 should build before 3 if you have
> declared
> the dependencies correctly.
>
> /Anders
>
> On Wed, Apr 8, 2015 at 6:17 PM, Eric Kolotyluk <
> eric.koloty...@gmail.com
> wrote:
>
>   I have
>
>> Project A
>> - module 1
>> - module 2
>> - module 3 (depends on 1 & 1)
>> -- creates shaded artifact
>>
>> Is there a way that I can configure my poms to do
>>
>> project A> mvn package
>>
>> such that modules 1 & 2 will automatically be installed before the
>> shade
>> plugin runs for module 3?
>>
>> Cheers, Eric
>>
>>
>> -
>> 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
>
>


-- 
Regards,
Anton.

Re: Maven Goes to Mars

[Anton Tanasenko]

There's usually a poll on how to name each release. Next after Mars should
be Neptune.
https://www.eclipse.org/mars/planning/poll.php

On Sun, 29 Mar 2015 14:47 Martin Gainty  wrote:

> eclipse had agreed to name released versions of eclipse after moons of
> Jupiter (notably Europa and Ganymede)
>
> i wonder if eclipse authors obtained permission from International
> Astronomical Union to name eclipse after a planet..why not Pluto?
>
> Thanks Paul,
> Martin
> __
>
>
>
> > Date: Sat, 28 Mar 2015 22:15:35 -0500
> > Subject: Re: Maven Goes to Mars
> > From: pbened...@apache.org
> > To: users@maven.apache.org
> >
> > The pun also works in regards to Eclipse 4.5 which is also named Mars.
> >
> >
> > Cheers,
> > Paul
> >
> > On Sat, Mar 28, 2015 at 8:15 PM, Martin Gainty 
> wrote:
> >
> > > http://www.nasa.gov/mission_pages/maven/main/
> > > was wondering why it took so long to get a response ..(know I know why)
> > >
> > > Maven is the first "Interplanetary Build System"
> > >
> > > Martin
> > > __
> > >
> > >
>