from:"Joseph"

Hi Tamás,
I have created a simple example here: 
https://github.com/josple/mvn-multibuild-issue
Hopefully the README is clear enough – let me know if I can clarify anything.
Thanks,
Joe

On 2024/02/07 17:33:08 Tamás Cservenák wrote:
> Howdy,
>
> In that case, there is something fishy with the project, my blind guess
> would be some "hidden" inter-module dependency maybe?
>
> Can you provide access to source, or, if not feasible, could you provide
> some reproducer and publish it on Github/Gitlab/whatever (maybe even just
> send it privately as ML strips off attachments and images) for us to see
> this in action?
>
> Thanks
> T
>
> On Wed, Feb 7, 2024 at 6:29 PM Joseph Leonard <
> joseph.leon...@alfasystems.com> wrote:
>
> > Hi Tamás,
> > We have previously played around a bit with mvnd but not takari directly –
> > I will have a play with it. With regards to this issue, using the takari
> > smart builder unfortunately doesn’t resolve the issue.
> > Joe
> >
> > On 2024/02/07 11:41:22 Tamás Cservenák wrote:
> > > Can you please try smart builder instead?
> > > https://github.com/takari/takari-smart-builder
> > >
> > > (note: smart builder is used by mvnd as well)
> > >
> > > The difference between the two can be seen here:
> > > http://takari.io/book/30-team-maven.html#takari-smart-builder
> > >
> > > On Wed, Feb 7, 2024 at 11:50 AM Joseph Leonard <
> > > joseph.leon...@alfasystems.com> wrote:
> > >
> > > > Hi Tamás,
> > > > Yeah, this was unexpected to me initially as well. From what I can tell
> > > > the Maven reactor only considers direct dependencies (i.e. not
> > transitive
> > > > dependencies) between the modules in the reactor when working out the
> > build
> > > > graph. For example if you have a simple linear dependency chain of:
> > > > One --> Two --> Three --> Four --> Five
> > > > Then invoking “mvn clean verify -pl One,Two,Four,Five -T 2 will result
> > in
> > > > two ‘graphs’ being built in parallel ([One,Two] and [Four,Five]). I
> > assume
> > > > this is as designed because it actually offers quite powerful
> > functionality
> > > > to improve the parallelism in your build. An example of where this is
> > legit
> > > > is when:
> > > >
> > > >   *   “Four” has a test scope dependency on “Five”
> > > >   *   “One” has a test scoped dependency on “Two”
> > > > If you made a src code change to “Five” and “Two” then it would be
> > safe to
> > > > build [One,Two] and [Four,Five] in parallel because you know the
> > changes
> > > > within these graphs cannot impact each other.
> > > > Joe
> > > >
> > > > On 2024/02/06 21:37:42 Tamás Cservenák wrote:
> > > > > Howdy,
> > > > >
> > > > > To me this looks like Maven is not aware that the App depends on
> > > > ModuleB...
> > > > > Are they "plain dependency" linked? Or what kind of dependency we
> > talk
> > > > > about here?
> > > > > In short: why would App start while ModuleB (upstream dep) is not
> > done?
> > > > > Something is fishy here.
> > > > >
> > > > > T
> > > > >
> > > > >
> > > > > On Tue, Feb 6, 2024 at 11:40 AM Joseph Leonard <
> > > > > joseph.leon...@alfasystems.com> wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > It would be great to get any thoughts on whether the following is a
> > > > defect:
> > > > > >
> > > > > >
> > > > > > Issue details:
> > > > > > tl;dr
> > > > > >
> > > > > > Maven can resolve dependencies either from:
> > > > > >
> > > > > >   *   an external repo
> > > > > >   *   a class directory of a module being built within the reactor
> > > > > >   *   a packaged jar of a module being built within the reactor
> > > > > >
> > > > > > If you run a concurrent multi-module build it is possible to get a
> > race
> > > > > > condition whereby the build of module Foo may resolve module Bar
> > from
> > > > > > either of the three resolution channels. This inconsistency can
&g

RE: Re: Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

Hi Tamás,
We have previously played around a bit with mvnd but not takari directly – I 
will have a play with it. With regards to this issue, using the takari smart 
builder unfortunately doesn’t resolve the issue.
Joe

On 2024/02/07 11:41:22 Tamás Cservenák wrote:
> Can you please try smart builder instead?
> https://github.com/takari/takari-smart-builder
>
> (note: smart builder is used by mvnd as well)
>
> The difference between the two can be seen here:
> http://takari.io/book/30-team-maven.html#takari-smart-builder
>
> On Wed, Feb 7, 2024 at 11:50 AM Joseph Leonard <
> joseph.leon...@alfasystems.com> wrote:
>
> > Hi Tamás,
> > Yeah, this was unexpected to me initially as well. From what I can tell
> > the Maven reactor only considers direct dependencies (i.e. not transitive
> > dependencies) between the modules in the reactor when working out the build
> > graph. For example if you have a simple linear dependency chain of:
> > One --> Two --> Three --> Four --> Five
> > Then invoking “mvn clean verify -pl One,Two,Four,Five -T 2 will result in
> > two ‘graphs’ being built in parallel ([One,Two] and [Four,Five]). I assume
> > this is as designed because it actually offers quite powerful functionality
> > to improve the parallelism in your build. An example of where this is legit
> > is when:
> >
> >   *   “Four” has a test scope dependency on “Five”
> >   *   “One” has a test scoped dependency on “Two”
> > If you made a src code change to “Five” and “Two” then it would be safe to
> > build [One,Two] and [Four,Five] in parallel because you know the changes
> > within these graphs cannot impact each other.
> > Joe
> >
> > On 2024/02/06 21:37:42 Tamás Cservenák wrote:
> > > Howdy,
> > >
> > > To me this looks like Maven is not aware that the App depends on
> > ModuleB...
> > > Are they "plain dependency" linked? Or what kind of dependency we talk
> > > about here?
> > > In short: why would App start while ModuleB (upstream dep) is not done?
> > > Something is fishy here.
> > >
> > > T
> > >
> > >
> > > On Tue, Feb 6, 2024 at 11:40 AM Joseph Leonard <
> > > joseph.leon...@alfasystems.com> wrote:
> > >
> > > > Hi all,
> > > >
> > > > It would be great to get any thoughts on whether the following is a
> > defect:
> > > >
> > > >
> > > > Issue details:
> > > > tl;dr
> > > >
> > > > Maven can resolve dependencies either from:
> > > >
> > > >   *   an external repo
> > > >   *   a class directory of a module being built within the reactor
> > > >   *   a packaged jar of a module being built within the reactor
> > > >
> > > > If you run a concurrent multi-module build it is possible to get a race
> > > > condition whereby the build of module Foo may resolve module Bar from
> > > > either of the three resolution channels. This inconsistency can result
> > in
> > > > the Maven war plugin sometimes failing to build a functional war file.
> > I
> > > > would expect a consistent resolution would always take place.
> > > >
> > > > Full details
> > > > Scenario
> > > >
> > > > Consider you have a repo with the following structure:
> > > >
> > > >App
> > > >
> > > >  / \
> > > >
> > > > /   \
> > > >
> > > >(compile scope)  (test scope)
> > > >
> > > >   /   \
> > > >
> > > > \/_   _\/
> > > >
> > > >  ModuleA  TestSupportModule1
> > > >
> > > > /
> > > >
> > > >/
> > > >
> > > > (compile scope)
> > > >
> > > >  /
> > > >
> > > >\/_
> > > >
> > > > ModuleB
> > > >
> > > >/
> > > >
> > > >   /
> > > >
> > > > (test scope)
> > > >
> > > > /
> > > >
> > > >   \/_
> > > >
> > > > TestSupportModule2
> > > >
> > > > If you were to make a src code change to the following test support
>

RE: Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

Hi Nils,
Ah I see. We actually already use ‘-pl …’ arguments in conjunction with the 
Develocity Build Cache implementation because we have found this to still 
generate very significant time savings. Primarily because even with hits on the 
build cache there is still fairly substantial time spent resolving cached 
artifacts (and the reactor doing all its goal steps and determining cache 
hits). The other advantage of using ‘-pl …’ is that it gives opportunity for 
even greater parallelism (per my sub-thread example with Tamás).
Joe

On 2024/02/07 10:59:28 Nils Breunese wrote:
> Hi Jospeh,
>
> I didn’t necessarily expect that enabling the extension would solve/avoid the 
> issue you described, but I mentioned it, because it would allow you to not 
> have to specify an argument like '-pl 
> TestSupportModule1,TestSupportModule2,ModuleB,App’ in the first place, 
> because the Build Cache Extension should automatically determine which 
> modules need to be built and for which ones previously cached artifacts can 
> be used.

>
> Nils.
>
> > Op 6 feb 2024, om 15:11 heeft Joseph Leonard  het 
> > volgende geschreven:
> >
> > Thanks Nils,
> > maven-build-cache-extension looks very interesting generally – I will have 
> > a play with it.
> > With regards to this issue, the maven-build-cache-extension overview 
> > references “Subtree support for multimodule projects builds part of the 
> > codebase in isolation” which sounded similar to the solution I am proposing 
> > for this issue. Unfortunately, after enabling the 
> > maven-build-cache-extension I still hit the same issue.

> > Joe
> >
> > On 2024/02/06 12:54:59 Nils Breunese wrote:
> >> I can’t comment on your question directly, but I just wanted to say that 
> >> your use case sounds like it could benefit from the Maven Build Cache 
> >> Extension 
> >> (https://maven.apache.org/extensions/maven-build-cache-extension/).

> >
> >>
> >> Just my 2 cents.
> >>
> >> Nils.
> >>
> >>> Op 6 feb 2024 om 11:40 heeft Joseph Leonard  het 
> >>> volgende geschreven:
> >>>
> >>> Hi all,
> >>>
> >>> It would be great to get any thoughts on whether the following is a 
> >>> defect:
> >>>
> >>>
> >>> Issue details:
> >>> tl;dr
> >>>
> >>> Maven can resolve dependencies either from:
> >>>
> >>> *   an external repo
> >>> *   a class directory of a module being built within the reactor
> >>> *   a packaged jar of a module being built within the reactor
> >>>
> >>> If you run a concurrent multi-module build it is possible to get a race 
> >>> condition whereby the build of module Foo may resolve module Bar from 
> >>> either of the three resolution channels. This inconsistency can result in 
> >>> the Maven war plugin sometimes failing to build a functional war file. I 
> >>> would expect a consistent resolution would always take place.

> >
> >>>
> >>> Full details
> >>> Scenario
> >>>
> >>> Consider you have a repo with the following structure:
> >>>
> >>>  App
> >>>
> >>>/ \
> >>>
> >>>   /   \
> >>>
> >>>  (compile scope)  (test scope)
> >>>
> >>> /   \
> >>>
> >>>   \/_   _\/
> >>>
> >>>ModuleA  TestSupportModule1
> >>>
> >>>   /
> >>>
> >>>  /
> >>>
> >>>   (compile scope)
> >>>
> >>>/
> >>>
> >>>  \/_
> >>>
> >>>   ModuleB
> >>>
> >>>  /
> >>>
> >>> /
> >>>
> >>>   (test scope)
> >>>
> >>>   /
> >>>
> >>> \/_
> >>>
> >>> TestSupportModule2
> >>>
> >>> If you were to make a src code change to the following test support 
> >>> modules:
> >>>
> >>> *   TestSupportModule1
> >>> *   TestSupportModule2
> >>>
> >>> Then the minimum number of modules we need to build to verify the change 
> >>> set is OK is:
> >>>
> >>> *   TestSupportModule1
> &

RE: Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

Hi Tamás,
Yeah, this was unexpected to me initially as well. From what I can tell the 
Maven reactor only considers direct dependencies (i.e. not transitive 
dependencies) between the modules in the reactor when working out the build 
graph. For example if you have a simple linear dependency chain of:
One --> Two --> Three --> Four --> Five
Then invoking “mvn clean verify -pl One,Two,Four,Five -T 2 will result in two 
‘graphs’ being built in parallel ([One,Two] and [Four,Five]). I assume this is 
as designed because it actually offers quite powerful functionality to improve 
the parallelism in your build. An example of where this is legit is when:

  *   “Four” has a test scope dependency on “Five”
  *   “One” has a test scoped dependency on “Two”
If you made a src code change to “Five” and “Two” then it would be safe to 
build [One,Two] and [Four,Five] in parallel because you know the changes within 
these graphs cannot impact each other.
Joe

On 2024/02/06 21:37:42 Tamás Cservenák wrote:
> Howdy,
>
> To me this looks like Maven is not aware that the App depends on ModuleB...
> Are they "plain dependency" linked? Or what kind of dependency we talk
> about here?
> In short: why would App start while ModuleB (upstream dep) is not done?
> Something is fishy here.
>
> T
>
>
> On Tue, Feb 6, 2024 at 11:40 AM Joseph Leonard <
> joseph.leon...@alfasystems.com> wrote:
>
> > Hi all,
> >
> > It would be great to get any thoughts on whether the following is a defect:
> >
> >
> > Issue details:
> > tl;dr
> >
> > Maven can resolve dependencies either from:
> >
> >   *   an external repo
> >   *   a class directory of a module being built within the reactor
> >   *   a packaged jar of a module being built within the reactor
> >
> > If you run a concurrent multi-module build it is possible to get a race
> > condition whereby the build of module Foo may resolve module Bar from
> > either of the three resolution channels. This inconsistency can result in
> > the Maven war plugin sometimes failing to build a functional war file. I
> > would expect a consistent resolution would always take place.
> >
> > Full details
> > Scenario
> >
> > Consider you have a repo with the following structure:
> >
> >App
> >
> >  / \
> >
> > /   \
> >
> >(compile scope)  (test scope)
> >
> >   /   \
> >
> > \/_   _\/
> >
> >  ModuleA  TestSupportModule1
> >
> > /
> >
> >/
> >
> > (compile scope)
> >
> >  /
> >
> >\/_
> >
> > ModuleB
> >
> >/
> >
> >   /
> >
> > (test scope)
> >
> > /
> >
> >   \/_
> >
> > TestSupportModule2
> >
> > If you were to make a src code change to the following test support
> > modules:
> >
> >   *   TestSupportModule1
> >   *   TestSupportModule2
> >
> > Then the minimum number of modules we need to build to verify the change
> > set is OK is:
> >
> >   *   TestSupportModule1
> >   *   TestSupportModule2
> >   *   ModuleB
> >   *   App
> >
> > i.e. there is no requirement to build ModuleA because we know that none of
> > the src code changes could impact the classpaths used in its maven build.
> >
> > We know that despite 'App' depending (transitively) on ModuleB there is no
> > need for the 'App' build to wait for ModuleB to complete its build because
> > the src code change to TestSupportModule2 will not impact any of the
> > classpaths used in the App maven build. Therefore to get the most efficient
> > build possible we ideally would invoke Maven to run with 2 threads and with
> > instruction to build two distinct 'dependency graphs':
> >
> >   *   TestSupportModule1 followed by ModuleB
> >   *   TestSupportModule1 followed by App
> >
> > The following Maven command achieves exactly what we want because the
> > reactor build order is based only on the direct (i.e. non-transitive)
> > dependencies of the modules provided to the reactor in the build command.
> > Therefore the absence of ModuleA results in two distinct 'dependency
> > graphs':
> >
> > mvn clean verify -pl TestSupportModule1,TestSupportModule2,ModuleB,App -T 2
> >
> > Note: In reality the code base I maintain ha

RE: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

2024-02-06 Thread Joseph Leonard

Note that my diagram formatting is very hard to read in the default formatting 
on this mailing list. If you view my email in 'raw source' then it is easier to 
understand!

On 2024/02/06 10:40:14 Joseph Leonard wrote:
> Hi all,
>
> It would be great to get any thoughts on whether the following is a defect:
>
>
> Issue details:
> tl;dr
>
> Maven can resolve dependencies either from:
>
>   *   an external repo
>   *   a class directory of a module being built within the reactor
>   *   a packaged jar of a module being built within the reactor
>
> If you run a concurrent multi-module build it is possible to get a race 
> condition whereby the build of module Foo may resolve module Bar from either 
> of the three resolution channels. This inconsistency can result in the Maven 
> war plugin sometimes failing to build a functional war file. I would expect a 
> consistent resolution would always take place.

>
> Full details
> Scenario
>
> Consider you have a repo with the following structure:
>
>App
>
>  / \
>
> /   \
>
>(compile scope)  (test scope)
>
>   /   \
>
> \/_   _\/
>
>  ModuleA  TestSupportModule1
>
> /
>
>/
>
> (compile scope)
>
>  /
>
>\/_
>
> ModuleB
>
>/
>
>   /
>
> (test scope)
>
> /
>
>   \/_
>
> TestSupportModule2
>
> If you were to make a src code change to the following test support modules:
>
>   *   TestSupportModule1
>   *   TestSupportModule2
>
> Then the minimum number of modules we need to build to verify the change set 
> is OK is:
>
>   *   TestSupportModule1
>   *   TestSupportModule2
>   *   ModuleB
>   *   App
>
> i.e. there is no requirement to build ModuleA because we know that none of 
> the src code changes could impact the classpaths used in its maven build.

>
> We know that despite 'App' depending (transitively) on ModuleB there is no 
> need for the 'App' build to wait for ModuleB to complete its build because 
> the src code change to TestSupportModule2 will not impact any of the 
> classpaths used in the App maven build. Therefore to get the most efficient 
> build possible we ideally would invoke Maven to run with 2 threads and with 
> instruction to build two distinct 'dependency graphs':

>
>   *   TestSupportModule1 followed by ModuleB
>   *   TestSupportModule1 followed by App
>
> The following Maven command achieves exactly what we want because the reactor 
> build order is based only on the direct (i.e. non-transitive) dependencies of 
> the modules provided to the reactor in the build command. Therefore the 
> absence of ModuleA results in two distinct 'dependency graphs':

>
> mvn clean verify -pl TestSupportModule1,TestSupportModule2,ModuleB,App -T 2
>
> Note: In reality the code base I maintain has a very large monobuild with 
> 100s of modules and this type of build optimisation makes a significant 
> difference to the speed of our monobuild (we use 
> https://github.com/gitflow-incremental-builder/gitflow-incremental-builder to 
> automate the logic of determining which modules to include in the reactor 
> based on our change set).

>
> Issue
>
> We have encountered an issue in the above scenario because the 'App' build 
> has a race condition with the ModuleB build which will result in one of the 
> following three outcomes:

>
>   *   If the 'App' build starts before the ModuleB build has compiled its src 
> classes then the 'App' build will resolve ModuleB from the external repo 
> (i.e. equivalent to ModuleB not being in the reactor at all)

>   *   If the 'App' build starts after ModuleB has compiled its src classes 
> but before it has packaged these classes into a jar then the 'App' build will 
> resolve ModuleB's target/classes directory

>   *   If the 'App' build starts after ModuleB has packaged its jar file then 
> the 'App' build will resolve ModuleB's target/ModuleB.jar file.

>
> In many scenarios this dependency resolution inconsistency doesn't represent 
> a challenge. However, it does cause an issue in our case because the 'App' 
> POM has its Maven packaging stanza configured to war and in the scenario 
> where ModuleB's target/classes directory is resolved by the 'App' then this 
> results in the resultant 'App' war file being packaged with a completely 
>

RE: Re: Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

2024-02-06 Thread Joseph Leonard

Thanks Nils,
maven-build-cache-extension looks very interesting generally – I will have a 
play with it.
With regards to this issue, the maven-build-cache-extension overview references 
“Subtree support for multimodule projects builds part of the codebase in 
isolation” which sounded similar to the solution I am proposing for this issue. 
Unfortunately, after enabling the maven-build-cache-extension I still hit the 
same issue.
Joe

On 2024/02/06 12:54:59 Nils Breunese wrote:
> I can’t comment on your question directly, but I just wanted to say that your 
> use case sounds like it could benefit from the Maven Build Cache Extension 
> (https://maven.apache.org/extensions/maven-build-cache-extension/).

>
> Just my 2 cents.
>
> Nils.
>
> > Op 6 feb 2024 om 11:40 heeft Joseph Leonard  het 
> > volgende geschreven:
> >
> > Hi all,
> >
> > It would be great to get any thoughts on whether the following is a defect:
> >
> >
> > Issue details:
> > tl;dr
> >
> > Maven can resolve dependencies either from:
> >
> >  *   an external repo
> >  *   a class directory of a module being built within the reactor
> >  *   a packaged jar of a module being built within the reactor
> >
> > If you run a concurrent multi-module build it is possible to get a race 
> > condition whereby the build of module Foo may resolve module Bar from 
> > either of the three resolution channels. This inconsistency can result in 
> > the Maven war plugin sometimes failing to build a functional war file. I 
> > would expect a consistent resolution would always take place.

> >
> > Full details
> > Scenario
> >
> > Consider you have a repo with the following structure:
> >
> >   App
> >
> > / \
> >
> >/   \
> >
> >   (compile scope)  (test scope)
> >
> >  /   \
> >
> >\/_   _\/
> >
> > ModuleA  TestSupportModule1
> >
> >/
> >
> >   /
> >
> >(compile scope)
> >
> > /
> >
> >   \/_
> >
> >ModuleB
> >
> >   /
> >
> >  /
> >
> >(test scope)
> >
> >/
> >
> >  \/_
> >
> > TestSupportModule2
> >
> > If you were to make a src code change to the following test support modules:
> >
> >  *   TestSupportModule1
> >  *   TestSupportModule2
> >
> > Then the minimum number of modules we need to build to verify the change 
> > set is OK is:
> >
> >  *   TestSupportModule1
> >  *   TestSupportModule2
> >  *   ModuleB
> >  *   App
> >
> > i.e. there is no requirement to build ModuleA because we know that none of 
> > the src code changes could impact the classpaths used in its maven build.

> >
> > We know that despite 'App' depending (transitively) on ModuleB there is no 
> > need for the 'App' build to wait for ModuleB to complete its build because 
> > the src code change to TestSupportModule2 will not impact any of the 
> > classpaths used in the App maven build. Therefore to get the most efficient 
> > build possible we ideally would invoke Maven to run with 2 threads and with 
> > instruction to build two distinct 'dependency graphs':

> >
> >  *   TestSupportModule1 followed by ModuleB
> >  *   TestSupportModule1 followed by App
> >
> > The following Maven command achieves exactly what we want because the 
> > reactor build order is based only on the direct (i.e. non-transitive) 
> > dependencies of the modules provided to the reactor in the build command. 
> > Therefore the absence of ModuleA results in two distinct 'dependency 
> > graphs':

> >
> > mvn clean verify -pl TestSupportModule1,TestSupportModule2,ModuleB,App -T 2
> >
> > Note: In reality the code base I maintain has a very large monobuild with 
> > 100s of modules and this type of build optimisation makes a significant 
> > difference to the speed of our monobuild (we use 
> > https://github.com/gitflow-incremental-builder/gitflow-incremental-builder 
> > to automate the logic of determining which modules to include in the 
> > reactor based on our change set).

> >
> > Issue
> >
> > We have encountered an issue in the above scenario because the 'App' build 
> > has a race condition with the ModuleB build which will result in one of the

Inconsistent dependency resolution behaviour for concurrent multi-module build can cause failures

2024-02-06 Thread Joseph Leonard

Hi all,

It would be great to get any thoughts on whether the following is a defect:


Issue details:
tl;dr

Maven can resolve dependencies either from:

  *   an external repo
  *   a class directory of a module being built within the reactor
  *   a packaged jar of a module being built within the reactor

If you run a concurrent multi-module build it is possible to get a race 
condition whereby the build of module Foo may resolve module Bar from either of 
the three resolution channels. This inconsistency can result in the Maven war 
plugin sometimes failing to build a functional war file. I would expect a 
consistent resolution would always take place.

Full details
Scenario

Consider you have a repo with the following structure:

   App

 / \

/   \

   (compile scope)  (test scope)

  /   \

\/_   _\/

 ModuleA  TestSupportModule1

/

   /

(compile scope)

 /

   \/_

ModuleB

   /

  /

(test scope)

/

  \/_

TestSupportModule2

If you were to make a src code change to the following test support modules:

  *   TestSupportModule1
  *   TestSupportModule2

Then the minimum number of modules we need to build to verify the change set is 
OK is:

  *   TestSupportModule1
  *   TestSupportModule2
  *   ModuleB
  *   App

i.e. there is no requirement to build ModuleA because we know that none of the 
src code changes could impact the classpaths used in its maven build.

We know that despite 'App' depending (transitively) on ModuleB there is no need 
for the 'App' build to wait for ModuleB to complete its build because the src 
code change to TestSupportModule2 will not impact any of the classpaths used in 
the App maven build. Therefore to get the most efficient build possible we 
ideally would invoke Maven to run with 2 threads and with instruction to build 
two distinct 'dependency graphs':

  *   TestSupportModule1 followed by ModuleB
  *   TestSupportModule1 followed by App

The following Maven command achieves exactly what we want because the reactor 
build order is based only on the direct (i.e. non-transitive) dependencies of 
the modules provided to the reactor in the build command. Therefore the absence 
of ModuleA results in two distinct 'dependency graphs':

mvn clean verify -pl TestSupportModule1,TestSupportModule2,ModuleB,App -T 2

Note: In reality the code base I maintain has a very large monobuild with 100s 
of modules and this type of build optimisation makes a significant difference 
to the speed of our monobuild (we use 
https://github.com/gitflow-incremental-builder/gitflow-incremental-builder to 
automate the logic of determining which modules to include in the reactor based 
on our change set).

Issue

We have encountered an issue in the above scenario because the 'App' build has 
a race condition with the ModuleB build which will result in one of the 
following three outcomes:

  *   If the 'App' build starts before the ModuleB build has compiled its src 
classes then the 'App' build will resolve ModuleB from the external repo (i.e. 
equivalent to ModuleB not being in the reactor at all)
  *   If the 'App' build starts after ModuleB has compiled its src classes but 
before it has packaged these classes into a jar then the 'App' build will 
resolve ModuleB's target/classes directory
  *   If the 'App' build starts after ModuleB has packaged its jar file then 
the 'App' build will resolve ModuleB's target/ModuleB.jar file.

In many scenarios this dependency resolution inconsistency doesn't represent a 
challenge. However, it does cause an issue in our case because the 'App' POM 
has its Maven packaging stanza configured to war and in the scenario where 
ModuleB's target/classes directory is resolved by the 'App' then this results 
in the resultant 'App' war file being packaged with a completely empty 
ModuleB.jar file.

Proposed solution

Ideally we would like the Maven reactor to retain isolation between the two 
distinct 'dependency graphs' it constructs at instantiation throughout the 
entire Maven build. This would mean, in the simple example above, that the 
'App' would always resolves ModuleB from the external repo (regardless of 
whether the reactor has built ModuleB or not in a separate 'dependency graph' 
in the reactor).



Joseph Leonard
Manager

Alfa

e: joseph.leon...@alfasystems.com | w: 
alfasystems.com<https://www.alfasystems.com>
t: +44 (0)20 7588 1800 | Moor Place, 1 Fore Street Avenue, London, EC2Y 9DT, GB


The contents of this communication are not intended to be binding or co

Re: creating a source directory on the fly

2023-12-06 Thread Joseph Kesselman

It has occurred to me that Maven needs something like the XSLT FAQ page -- a 
(semi)official collection of common "how to" questions with validated "best 
practice" worked examples, updated as best practice changes. It's easy to find 
examples, much harder for a novice to understand the subtleties that make them 
good or bad examples.

--
   /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
   /   https://www.amazon.com/dp/B09WJ3H657/

Caveat: Opinionated old geezer with overcompensated writer's block. May be 
redundant, verbose, prolix, sesquipedalian, didactic, officious, or redundant.

From: Dave Dyer 
Sent: Wednesday, December 6, 2023 11:43:37 AM
To: Maven Users List ; users@maven.apache.org 

Subject: RE: creating a source directory on the fly

At 06:55 AM 12/6/2023, mark.yagnatin...@barclays.com.INVALID wrote:
>Pretty sure that plugin is flexible enough to just copy what you tell it to?
>https://maven.apache.org/plugins/maven-resources-plugin/examples/include-exclude.html

Thanks.  I just hadn't encountered the right examples!

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

Re: Pure curiosity

2023-11-20 Thread Joseph Kesselman

BTW, apologies. The strengths/weaknesses post was intended to be sent to Gary 
for offline discussion , not list.

I'm very aware that I haven't used Maven long enough or deeply enough to have a 
valid opinion. This was initial reactions only, as I approach publishable 
version of a Maven build for Xalan. I badly mis-sized the effort, and I *think* 
the things I called out were the points I struggled most to wrap my head around.

Which may just be me. But I figured I'd toss that to Gary for discussion 
offline, then I fat-fingered the send. Again, apologies.

.

--
   /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
   /   https://www.amazon.com/dp/B09WJ3H657/

Caveat: Opinionated old geezer with overcompensated writer's block. May be 
redundant, verbose, prolix, sesquipedalian, didactic, officious, or redundant.
________
From: Joseph Kesselman 
Sent: Sunday, November 19, 2023 6:25:37 PM
To: Maven Users List 
Subject: Re: Pure curiosity

Maven's declarative nature may be its second greatest strength, following 
platform independence and preceding the rich plugin collection.

The lack of any _dependency_ driven flow below the module level -- apparently 
typically solved by throwing more modules into the mix just to achieve 
sequencing, or trying to use the fixed sequencing of the stages -- may be its 
greatest weakness. Note that I'm still having to play games with when site 
runs; site depends on code in the package, and the download zipfiles depend 
upon site.

Alex grants that if you're pushing declarative build design as a Maven 
advantage, _make_ beat you the punch by about half a century, and is fully 
dependency driven; its major downsides are that it doesn't have platform 
independence and isn't new and sexy and markup language based.

I really expected Maven to handle that better.

So my half-thought is what it would take to change from stages to dependencies, 
 and how much of the Maven design would have to be thrown out the window to 
achieve it... or at least to draft a prototype that could leverage what's 
already been done.

Maven does beat Ant. And it has the plugin tooling and auto-fetch from 
libraries. But the lack of dependency-driven execution Bothers me.

Vlad favors Gradle. I don't know if Gradle is better, worse, or just different, 
but from what he's said it sounds like it does have the ability to update just 
what it must, as make did, and to handle sequences that don't  match the 
predefined stage sequences. Maybe it's time to consider crossbreeding.

I may change my mind after further exposure to Maven, but that's my reaction to 
what I've seen of it so far and how much help I needed to understand its quirks.

--
   /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
   /   https://www.amazon.com/dp/B09WJ3H657/

Caveat: Opinionated old geezer with overcompensated writer's block. May be 
redundant, verbose, prolix, sesquipedalian, didactic, officious, or redundant.

From: Gary Gregory 
Sent: Sunday, November 19, 2023 5:55:40 PM
To: Maven Users List 
Subject: Re: Pure curiosity

You can get an idea by downloading the source zip file from
https://maven.apache.org/download.cgi and and counting something like Java
source files or kilobytes' worth of Java files, or LoCs...

FWIW, I see Gradle mentioned here and there in our issues. Using
Gradlebwould be a huge mistake IMO... I really don't like Gradle.

Maven has its quirks, sure, but if you implement a build using Maven's
philosophy of "configuration by exception", you end up with a nice easy to
maintain build.

Gary

On Sun, Nov 19, 2023, 5:39 PM Joseph Kesselman  wrote:

> How large is the actual Maven core application itself, without even the
> "standard" plugins?
>
> (I've got half an idea and am trying to guess how much work it would be to
> prototype something.)
>
> --
>/_  Joe Kesselman (he/him/his)
> -/ _) My Alexa skill for New Music/New Sounds fans:
>/   https://www.amazon.com/dp/B09WJ3H657/
>
> Caveat: Opinionated old geezer with overcompensated writer's block. May be
> redundant, verbose, prolix, sesquipedalian, didactic, officious, or
> redundant.
>

Re: Pure curiosity

2023-11-19 Thread Joseph Kesselman

I'm half asleep right now, so I may be completely confused. Or I may just not 
from Maven well enough yet. I did say it was half an idea, and might not have 
been worth posting. Lemme think about it further and see where, if anywhere, it 
goes.

--
   /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
   /   https://www.amazon.com/dp/B09WJ3H657/

Caveat: Opinionated old geezer with overcompensated writer's block. May be 
redundant, verbose, prolix, sesquipedalian, didactic, officious, or redundant.

From: Gary Gregory 
Sent: Sunday, November 19, 2023 6:43:30 PM
To: Maven Users List 
Subject: Re: Pure curiosity

I don't know what issue you're struggling with for the Maven build so we
should talk this week or discuss it over email. I don't want to ask you to
explain all of this over email if it's quicker to explain via voice. Maybe
we can start with: Where is the Maven build and what's the current hurdle?

Also note that the Maven devs can be quite helpful on their mailing list.

Gary


On Sun, Nov 19, 2023, 6:26 PM Joseph Kesselman  wrote:

> Maven's declarative nature may be its second greatest strength, following
> platform independence and preceding the rich plugin collection.
>
> The lack of any _dependency_ driven flow below the module level --
> apparently typically solved by throwing more modules into the mix just to
> achieve sequencing, or trying to use the fixed sequencing of the stages --
> may be its greatest weakness. Note that I'm still having to play games with
> when site runs; site depends on code in the package, and the download
> zipfiles depend upon site.
>
> Alex grants that if you're pushing declarative build design as a Maven
> advantage, _make_ beat you the punch by about half a century, and is fully
> dependency driven; its major downsides are that it doesn't have platform
> independence and isn't new and sexy and markup language based.
>
> I really expected Maven to handle that better.
>
> So my half-thought is what it would take to change from stages to
> dependencies,  and how much of the Maven design would have to be thrown out
> the window to achieve it... or at least to draft a prototype that could
> leverage what's already been done.
>
> Maven does beat Ant. And it has the plugin tooling and auto-fetch from
> libraries. But the lack of dependency-driven execution Bothers me.
>
> Vlad favors Gradle. I don't know if Gradle is better, worse, or just
> different, but from what he's said it sounds like it does have the ability
> to update just what it must, as make did, and to handle sequences that
> don't  match the predefined stage sequences. Maybe it's time to consider
> crossbreeding.
>
> I may change my mind after further exposure to Maven, but that's my
> reaction to what I've seen of it so far and how much help I needed to
> understand its quirks.
>
>
>
> --
>/_  Joe Kesselman (he/him/his)
> -/ _) My Alexa skill for New Music/New Sounds fans:
>/   https://www.amazon.com/dp/B09WJ3H657/
>
> Caveat: Opinionated old geezer with overcompensated writer's block. May be
> redundant, verbose, prolix, sesquipedalian, didactic, officious, or
> redundant.
> 
> From: Gary Gregory 
> Sent: Sunday, November 19, 2023 5:55:40 PM
> To: Maven Users List 
> Subject: Re: Pure curiosity
>
> You can get an idea by downloading the source zip file from
> https://maven.apache.org/download.cgi and and counting something like Java
> source files or kilobytes' worth of Java files, or LoCs...
>
> FWIW, I see Gradle mentioned here and there in our issues. Using
> Gradlebwould be a huge mistake IMO... I really don't like Gradle.
>
> Maven has its quirks, sure, but if you implement a build using Maven's
> philosophy of "configuration by exception", you end up with a nice easy to
> maintain build.
>
> Gary
>
> On Sun, Nov 19, 2023, 5:39 PM Joseph Kesselman 
> wrote:
>
> > How large is the actual Maven core application itself, without even the
> > "standard" plugins?
> >
> > (I've got half an idea and am trying to guess how much work it would be
> to
> > prototype something.)
> >
> > --
> >/_  Joe Kesselman (he/him/his)
> > -/ _) My Alexa skill for New Music/New Sounds fans:
> >/   https://www.amazon.com/dp/B09WJ3H657/
> >
> > Caveat: Opinionated old geezer with overcompensated writer's block. May
> be
> > redundant, verbose, prolix, sesquipedalian, didactic, officious, or
> > redundant.
> >
>

Re: Pure curiosity

2023-11-19 Thread Joseph Kesselman

Maven's declarative nature may be its second greatest strength, following 
platform independence and preceding the rich plugin collection.

The lack of any _dependency_ driven flow below the module level -- apparently 
typically solved by throwing more modules into the mix just to achieve 
sequencing, or trying to use the fixed sequencing of the stages -- may be its 
greatest weakness. Note that I'm still having to play games with when site 
runs; site depends on code in the package, and the download zipfiles depend 
upon site.

Alex grants that if you're pushing declarative build design as a Maven 
advantage, _make_ beat you the punch by about half a century, and is fully 
dependency driven; its major downsides are that it doesn't have platform 
independence and isn't new and sexy and markup language based.

I really expected Maven to handle that better.

So my half-thought is what it would take to change from stages to dependencies, 
 and how much of the Maven design would have to be thrown out the window to 
achieve it... or at least to draft a prototype that could leverage what's 
already been done.

Maven does beat Ant. And it has the plugin tooling and auto-fetch from 
libraries. But the lack of dependency-driven execution Bothers me.

Vlad favors Gradle. I don't know if Gradle is better, worse, or just different, 
but from what he's said it sounds like it does have the ability to update just 
what it must, as make did, and to handle sequences that don't  match the 
predefined stage sequences. Maybe it's time to consider crossbreeding.

I may change my mind after further exposure to Maven, but that's my reaction to 
what I've seen of it so far and how much help I needed to understand its quirks.

--
   /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
   /   https://www.amazon.com/dp/B09WJ3H657/

Caveat: Opinionated old geezer with overcompensated writer's block. May be 
redundant, verbose, prolix, sesquipedalian, didactic, officious, or redundant.

From: Gary Gregory 
Sent: Sunday, November 19, 2023 5:55:40 PM
To: Maven Users List 
Subject: Re: Pure curiosity

You can get an idea by downloading the source zip file from
https://maven.apache.org/download.cgi and and counting something like Java
source files or kilobytes' worth of Java files, or LoCs...

FWIW, I see Gradle mentioned here and there in our issues. Using
Gradlebwould be a huge mistake IMO... I really don't like Gradle.

Maven has its quirks, sure, but if you implement a build using Maven's
philosophy of "configuration by exception", you end up with a nice easy to
maintain build.

Gary

On Sun, Nov 19, 2023, 5:39 PM Joseph Kesselman  wrote:

> How large is the actual Maven core application itself, without even the
> "standard" plugins?
>
> (I've got half an idea and am trying to guess how much work it would be to
> prototype something.)
>
> --
>/_  Joe Kesselman (he/him/his)
> -/ _) My Alexa skill for New Music/New Sounds fans:
>/   https://www.amazon.com/dp/B09WJ3H657/
>
> Caveat: Opinionated old geezer with overcompensated writer's block. May be
> redundant, verbose, prolix, sesquipedalian, didactic, officious, or
> redundant.
>

Pure curiosity

2023-11-19 Thread Joseph Kesselman

How large is the actual Maven core application itself, without even the 
"standard" plugins?

(I've got half an idea and am trying to guess how much work it would be to 
prototype something.)

--
   /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
   /   https://www.amazon.com/dp/B09WJ3H657/

Caveat: Opinionated old geezer with overcompensated writer's block. May be 
redundant, verbose, prolix, sesquipedalian, didactic, officious, or redundant.

Re: Self-inflicted wounds again.

2023-11-14 Thread Joseph Kesselman

Thanks; hadn't gotten to retesting the latest changes on Windows this week. 
Though it did seem to be accepting the colons last time I tested. (This may be 
like / vs \, where Windows insists on its own syntax at the command line but 
also accepts the Posix convention at the API level...)

It appears that the recent problems were indeed due to my using a backlevel 
plug-in. Still don't grok how that happened when I'd been running fine the 
previous day, but it's fixed now. Many thanks for the catch.

--
   /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
   /   https://www.amazon.com/dp/B09WJ3H657/

() I still don't think HTML mail is a good idea
/\ but Outlook/Android is insisting. Need to
 change mail client.

From: Alexander Kriegisch 
Sent: Monday, November 13, 2023 8:02:01 PM
To: users@maven.apache.org 
Subject: Re: Self-inflicted wounds again.

Hi Joseph.

In your branch, please note that currently your build will not work for
Windows users:

[INFO] --- exec:3.1.0:exec (Xalan2 design documentation) @ xalan-project ---
Fehler: Hauptklasse org.apache.stylebook.StyleBook konnte nicht gefunden oder 
geladen werden
Ursache: java.lang.ClassNotFoundException: org.apache.stylebook.StyleBook
[ERROR] Command execution failed.
org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit 
value: 1)

I have replaced the UNIX-style ":'" path separators by instances of
"${path.separator}", see also my PR
https://github.com/apache/xalan-java/pull/119.

Now, the build passes. You seem to have upgraded the Assembly Plugin, as
Karl Heinz advised you to do. Please do not use things like LATEST or
version ranges, it defeats any efforts to get repeatable builds.

Before I look into your project any deeper, especially into your
assemblies - so far I did not look at all yet - can you tell me if your
problems are all fixed for the moment? The situation seems to have
progressed since last time you asked.

Kind regards
--
Alexander Kriegisch
https://scrum-master.de

Karl Heinz Marbaise schrieb am 14.11.2023 02:44 (GMT +07:00):

> The first what I see is that you are using an ancient old
> maven-assembly-plugin version (2.2-beta-5) ... Please upgrade first
> (most recent is currentl 3.6.0)..
>
> Here you find the overview of all plugins with the most recent versions:
>
> https://maven.apache.org/plugins/
>
>
> On 13.11.23 20:27, Joseph Kessselman wrote:
>
>> Had generation of the multi-module distribution binary zipfile working
>> yesterday.
>>
>> Came back today to find I had apparently stepped on it before pushing.
>> Sigh. OK, I should be able to reproduce this, right?
>>
>> Unfortunately, no. I'm missing something obvious again.
>>
>> In context, currently broken as checked in:
>> https://github.com/apache/xalan-java/tree/xalan-java-mvn-refactored
>>
>> Current error message is
>>
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5:single
>> (distro-assembly) on project distribution: Error reading assemblies:
>> Error reading descriptor at: src/assembly/bin.xml: Unrecognised tag:
>> 'useAllReactorProjects' (position: START_TAG seen ...\n
>> ... @15:30)  -> [Help 1]
>>
>> The bin.xml file mentioned currently contains something that is based
>> directly off the multi-module assembly instructions, just changing which
>> modules are included. Or at least that's the intent.
>>
>> 
>> http://maven.apache.org/ASSEMBLY/2.2.0";
>>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>  xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.2.0
>> http://maven.apache.org/xsd/assembly-2.2.0.xsd";>
>>bin
>> 
>>   zip 
>>   tar-gz 
>> 
>>false
>>
>>  
>>true
>>
>>
>>  xalan:serializer
>>  xalan:xalan
>>  xalan:samples
>>
>>
>>
>>  modules/maven-assembly-plugin
>>  false
>>
>>  
>>
>>
>>
>>  
>>../target/site
>>docs
>>  
>>  
>>../samples
>>
>>  target/**
>>  src/site/**
>>
>>  
>>
>> 
>> --
>> And the POM invoking this is likewise based pretty directly on the example:
>>
>> http://maven.apache.org/POM/4.0.0";
>>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>

Self-inflicted wounds again.

2023-11-13 Thread Joseph Kessselman

Had generation of the multi-module distribution binary zipfile working 
yesterday.


Came back today to find I had apparently stepped on it before pushing. 
Sigh. OK, I should be able to reproduce this, right?


Unfortunately, no. I'm missing something obvious again.


In context, currently broken as checked in:
https://github.com/apache/xalan-java/tree/xalan-java-mvn-refactored


Current error message is

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5:single 
(distro-assembly) on project distribution: Error reading assemblies: 
Error reading descriptor at: src/assembly/bin.xml: Unrecognised tag: 
'useAllReactorProjects' (position: START_TAG seen ...\n 
... @15:30)  -> [Help 1]


The bin.xml file mentioned currently contains something that is based 
directly off the multi-module assembly instructions, just changing which 
modules are included. Or at least that's the intent.



http://maven.apache.org/ASSEMBLY/2.2.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.2.0 
http://maven.apache.org/xsd/assembly-2.2.0.xsd";>

  bin
  
zip
tar-gz
  
  false
  

  true
  
  
xalan:serializer
xalan:xalan
xalan:samples
  
  
modules/maven-assembly-plugin
false
  

  
  
  

  ../target/site
  docs


  ../samples
  
target/**
src/site/**
  

  

--
And the POM invoking this is likewise based pretty directly on the example:

http://maven.apache.org/POM/4.0.0";
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
https://maven.apache.org/xsd/maven-4.0.0.xsd";>

  4.0.0
  
xalan
xalan-project
2.7.3
  

  distribution
  pom

  distribution

  
  

  xalan
  serializer
  2.7.3


  xalan
  xalan
  2.7.3


  xalan
  samples
  2.7.3

  

  

  
maven-assembly-plugin

  
distro-assembly
package

  single


  
src/assembly/bin.xml
  

  

  

  

--

I'm undoubtedly looking right past my error. Which foot am I shooting 
off this time?



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

Re: Can the jar plugin respect .gitignore?

I welcome feedback on where I might have departed from Maven conventions and 
defaults, or otherwise missed a bet. I actually don't think I'm far off -- 
maybe not the most elegant solutions possible, but basically using Maven as 
designed to be used.

But I'd sorta appreciate it if folks were throwing net-rocks at what I actually 
did rather than what you fear I might have done. Directed feedback is more 
useful.


--
   /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
   /   https://www.amazon.com/dp/B09WJ3H657/

() Plaintext Ribbon Campaign
/\ Stamp out HTML mail!

From: Alexander Kriegisch 
Sent: Saturday, November 11, 2023 7:31:25 PM
To: users@maven.apache.org 
Subject: Re: Can the jar plugin respect .gitignore?

Let me also chime in, telling an "old war story" from my early days in
AspectJ: It used to be a very complex and convoluted Ant multi-module
monster. I never dared to even try and understand the build or
contribute to the project. Then one day, Andy Clement converted the
project to a Maven project, and suddenly I began to understand the
structure better. I started contributing to the project infrastructure,
weeding out the remaining relics of a replicated, scripted build taken
over from Ant, and use *convention over configuration*. Now, you can
just clone the repository, import the Maven project into Eclipse or IDEA
and build it.

We also have some source and binary assemblies, and I never thought
about using .gitignore as a source for excludes, because

  -- as was said before, you usually exclude target, the very folder of
 most interest for binary assemblies, and

  -- whatever is ignored in my .gitignore and resides outside the target
 folder, is usually also to be ignored in source assemblies.

If your case is any different, chances are that your directory structure
is suboptimal and non-standard.

IMO, the one-time effort of developers getting to know the new directory
layout is well invested, because sticking to Maven conventions pays off
in so many ways, not just because IDE import is now easier and users can
contribute patches or features more easily due to painless on-boarding.

--
Alexander Kriegisch
https://scrum-master.de

Greg Chabala schrieb am 12.11.2023 06:32 (GMT +07:00):

> I hesitate to bring it up, but this seems as good a time as any.
> You've mentioned several times your intent to massage the Xalan Maven
> build to produce artifacts at parity with the existing Ant build, and
> not just the contents of artifacts but also where they end up in the
> directory structure, for the convenience of those who are used to the
> Ant build.
>
> I foresee that if you are truly successful in this goal, you will have
> thoroughly reimplemented a procedural Ant build, and created a very
> weird Maven build, to the point where you may exclaim 'why did I even
> start this? It took so much work to get Maven to do what I was doing
> easily in Ant!', and Maven users will be confused about why there's
> nothing they expected in the target directory after running compile.

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

Re: Can the jar plugin respect .gitignore?

I am using a Maven build structure. Or my best attempt at it as a newcomer to 
Maven. I've been delaying cutover specifically because I didn't want to pull 
the trigger without a sanity check.

Gary has said he'll try to look at what I've done soon. If anyone else has 
cycles, I'd welcome review of what I've done, questions about why I made those 
decisions, and suggestions for better ways to achieve the goals.

Again: This is intended to be a Maven-native build, with some postprocessing so 
folks who were used to the Ant build and have assumptions based on it can also 
find the jars, tars, and zips they expect in the place they're used to seeing 
them. The build itself is working; I'm essentially just dealing with that final 
cosmetic stage, and trying to do so in a reasonably drclarative Maven-native 
way rather than resorting to a shell script.

--
   /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
   /   https://www.amazon.com/dp/B09WJ3H657/

() Plaintext Ribbon Campaign
/\ Stamp out HTML mail!

From: Bernd Eckenfels 
Sent: Saturday, November 11, 2023 6:43:15 PM
To: users@maven.apache.org 
Subject: Re: Can the jar plugin respect .gitignore?

Hello,

Joseph Kesselman wrote on 11. Nov 2023 17:27 (GMT +01:00):
> ... Right. I was thinking specifically about source assembly, where a good
> initial approximation is to include the same files checked into git.

If you stick to the maven way, this is pretty trivial: you only need to exclude 
the target/ directory - or only include the src/ directory which is common for 
-src artifacts. I fully agree, don’t try to mold maven projects in a custom 
structure… it can be done to some extend, but it will not make you happy.

Gruß
Bernd
—
https://bernd.eckenfels.net

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

Re: Can the jar plugin respect .gitignore?

Don't worry. I'm not trying to reproduce the Ant build logic. I'm trying to be 
as Maven& idiomatic as I can in the actual build.

But if possible I want to produce, from that, a directory which contains 
somethIng close to what the Ant build would have delivered. Both because I 
haven't had time to rework the tests yet and they have assumptions about what 
they access to execute the build, and because showing that I can get the same 
final jar or zip file out of the build is strong evidence that the port is 
correct and complete.

I've been using diffs between the Maven-produced jarfiles and the Ant ones as 
sanity checks, and that has flushed out some errors in the build along the way. 
But that's the only level at which I'm making it look like Ant, and that only 
as a final postprocessing layer.

Remember, I'm an XSLT developer. Declarative programming is nothing new to me. 
I'm just still learning how to write the declarations so Maven will do what's 
necessary. If anything, I was hoping Maven's dependency driven defaults were 
just a bit stronger than they are... but I'm learning how to talk to it.

We're going in the same direction. I'm just learning how Maven wants to get 
there.



--
   /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
   /   https://www.amazon.com/dp/B09WJ3H657/

() Plaintext Ribbon Campaign
/\ Stamp out HTML mail!

From: Greg Chabala 
Sent: Saturday, November 11, 2023 6:32:13 PM
To: Maven Users List 
Subject: Re: Can the jar plugin respect .gitignore?

I hesitate to bring it up, but this seems as good a time as any. You've
mentioned several times your intent to massage the Xalan Maven build to
produce artifacts at parity with the existing Ant build, and not just the
contents of artifacts but also where they end up in the directory
structure, for the convenience of those who are used to the Ant build.

I foresee that if you are truly successful in this goal, you will have
thoroughly reimplemented a procedural Ant build, and created a very weird
Maven build, to the point where you may exclaim 'why did I even start this?
It took so much work to get Maven to do what I was doing easily in Ant!',
and Maven users will be confused about why there's nothing they expected in
the target directory after running compile.

There's something to be said for embracing the Maven Way [1], and if you
want to keep both builds in sync for a time, perhaps the effort would be
better spent in updating the Ant build to put things in the places Maven
puts them by default.

[1]: https://maven.apache.org/background/philosophy-of-maven.html

Re: Can the jar plugin respect .gitignore?

The "binary" assembly I'm trying to reproduce is the one our And project 
generated -- the artifact jarfile, plus source and input for the samples, plus 
the documentation directory -- basically, everything an end-user might want 
locally. I'm getting close to having that working.

Output directory in some places refers to directory within the archive. For 
example, I have it copying my Maven target/site/ directory to releaseName/docs/ 
inside the tar.gz and zip files, to confirm to past patterns.

It isn't clear whether I should move the src assembly build down into this late 
processing module. Conceptually it belongs next to the bin assembly, but 
syntactically I think it's simpler in the parent pom. Unless I'm missing 
something. Again.

Biggest remaining challenge: Again for convenience of folks who were used to 
the Ant build, I'd like to move/copy both bin and src assemblies to my 
Ant-emulation build/ directory. And again, if I try to do this with a separate 
copying operation it looks like I need another layer of dependency to ensure 
the bin assembly is generated before I copy it. Doable but not pretty. Having 
the assemblies write directly into build/ would be another solution if 
available.

Random brainstorm, may be all wet: Maven might want to consider allowing users 
to specify priority. Phase is a good default/basic sequencing tool, but as the 
need to resort to dependencies shows, not quite complete by itself. If I could 
assign what amount to sub-phases by saying "this is higher or lower priority 
than anything else which runs in that phase", that might let me resolve cases 
where the phase alone is not enough to ensure desired sequence of operations... 
such as not running assembly until after other packaging is complete.



--
   /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
   /   https://www.amazon.com/dp/B09WJ3H657/

() Plaintext Ribbon Campaign
/\ Stamp out HTML mail!

From: Greg Chabala 
Sent: Saturday, November 11, 2023 12:38:05 PM
To: Maven Users List 
Subject: Re: Can the jar plugin respect .gitignore?

I have no first hand experience using it, and only know of its existence as
it's mentioned at the bottom the Reproducible Builds docs:
https://reproducible-builds.org/docs/jvm/

Notably the maven-assembly-plugin documentation mentions a predefined
'project' descriptor which may also do just what you want(for buildable
sources):
https://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html#project

You should be able to configure outputDirectory for either to place the
assembly where you like:
https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#outputDirectory

Didn't see a binary equivalent, but perhaps that would just be your normal
build artifact?

Re: maven-assembly-plugin, bin example is giving me trouble

2023-11-11 Thread Joseph Kessselman

Duh. Just noticed that the FAQ explicitly mentions creating a child 
module just to achieve this sequencing in multi-module projects. Mea 
culpa, mea maxima culpa... I'd have hoped something could be done with 
phase and target, but if not, not.


On 11/11/2023 11:44 AM, Joseph Kessselman wrote:
Sorry: 
https://github.com/apache/xalan-java/tree/xalan-java-mvn-refactored 
(which currently has the binary assembly commented out).


Dependency order... Well, I'm currently running the assembly at the top 
level, which would presumably mean it has to run after packaging of the 
contained modules. I suppose I could try moving it down to the module at 
the farthest end of the current dependency chain, or even into a new 
module which exists just to depend on everything else, but that feels 
like I'm solving the wrong problem; "give me an assembly for the whole 
project" is conceptually a top-level operation and I'd expect to invoke 
it from the root module.


On 11/10/2023 10:54 PM, Alexander Kriegisch wrote:

Tried making my top-level module dependent on all the others


Don't! That does not make any logical sense.


Checked in on xalan-java branch xalan-java-mvn-refactored


Please always provide a link. I have no idea where to find your project.
To you, that might be obvious. to others, it is not.



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

Re: Can the jar plugin respect .gitignore?

2023-11-11 Thread Joseph Kessselman


On 11/11/2023 11:44 AM, Greg Chabala wrote:

Use the sourceReleaseAssemblyDescriptor of maven-assembly-plugin:
https://maven.apache.org/apache-resource-bundles/source-release/


Thanks; hadn't seen that one. Definitely a fan of not reinventing wheels.

Can that be configured to write the archives to a specific directory? 
I've been trying to simulate the Ant build/ directory, for backward
compatibility... I can copy the archives there after they've been built, 
of course, if I can get the phase sequencing right.


Is there an equivalent standard configuration for Apache binary release?

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

Re: maven-assembly-plugin, bin example is giving me trouble

2023-11-11 Thread Joseph Kessselman

Sorry: 
https://github.com/apache/xalan-java/tree/xalan-java-mvn-refactored 
(which currently has the binary assembly commented out).


Dependency order... Well, I'm currently running the assembly at the top 
level, which would presumably mean it has to run after packaging of the 
contained modules. I suppose I could try moving it down to the module at 
the farthest end of the current dependency chain, or even into a new 
module which exists just to depend on everything else, but that feels 
like I'm solving the wrong problem; "give me an assembly for the whole 
project" is conceptually a top-level operation and I'd expect to invoke 
it from the root module.


On 11/10/2023 10:54 PM, Alexander Kriegisch wrote:

Tried making my top-level module dependent on all the others


Don't! That does not make any logical sense.


Checked in on xalan-java branch xalan-java-mvn-refactored


Please always provide a link. I have no idea where to find your project.
To you, that might be obvious. to others, it is not.



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

Re: Can the jar plugin respect .gitignore?

... Right. I was thinking specifically about source assembly, where a good 
initial approximation is to include the same files checked into git. Obviously 
that's wrong for binary assembly, but having the option of "import ignore list 
into source excludes" would help keep the two in synch. And the basic selection 
pattern syntax seems close to the same.

Not a big deal to maintain manually; I'm just looking to automate what I can.

--
   /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
   /   https://www.amazon.com/dp/B09WJ3H657/

() Plaintext Ribbon Campaign
/\ Stamp out HTML mail!

From: John Patrick 
Sent: Saturday, November 11, 2023 6:18:43 AM
To: Maven Users List 
Subject: Re: Can the jar plugin respect .gitignore?

my .gitignore includes target, so that would probably cause more issues
with the assembly plugin.

On Fri, 10 Nov 2023 at 21:34,  wrote:

> I think there are two issues with this, first of all git is not the only
> SCM, so why prefer it’s file.
>
> But secondly it is very common that binary result artifacts are git
> ignored and exactly the stuff you want to package. For example target/
>
> Are you thinking about -src archives, only?
>
> Having said that, supporting the file format and patterns might be a good
> idea (if it can be sorted out which directory level should be relevant) and
> having a easy way to enable .*ignore.
>
> Joseph Kessselman wrote on 10. Nov 2023 19:42 (GMT +01:00):
>
> > (Or, equivalently be told to take exclude list from a file in .gitignore
> > syntax and then be told .gitignore was that file.)
> >
> > If not, I'd consider that worth adding.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: maven-assembly-plugin, bin example is giving me trouble

Tried making my top-level module dependent on all the others so the 
assembly invoked there would run last. Unfortunately, it seems the 
dependencies are inherited to all the children, and Maven complains 
about dependencies upon self.


I presume there's an obvious idiom that I just haven't yet beaten into 
my head.


Checked in on xalan-java branch xalan-java-mvn-refactored with bin 
assembly commented out, if anyone wants to see it in context.



On 11/10/2023 9:37 PM, Joseph Kessselman wrote:

Oh. I probably forgot to set dependencies. Checking.


On 11/10/2023 9:35 PM, Joseph Kessselman wrote:
I'm trying to adapt the examples given at 
https://maven.apache.org/plugins/maven-assembly-plugin to work with my 
multi-module project.


Source was mostly easy -- I copied the  into a file, 
tweaked its excludes (still wish it picked up the .gitinclude 
automagically), and it worked. I'd still like to change which 
directory the resulting archive files were written to, but that's a 
nitpick; maybe I can copy 'em to the "ant simulation" build/ directory 
afterward.



But binary is giving me a bit more trouble. This is working for 
others, so I presume it's another case of my just not understanding 
the idiom well enough.



All I did was add one more  to reference
src/assembly/bin.xml, and dropped there a copy of the 
taken from the page, modified to output to tar.gz and zip. I changed the
s to reference my artifacts, and ran mvn package again.

Maven objects to my first child module:

 > [ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-assembly-plugin:3.6.0:single 
(make-assembly) on project xalan-project: Failed to create assembly: 
Artifact: xalan:serializer:jar:2.7.3 (included by module) does not 
have an artifact with a file. Please ensure the package phase is run 
before the assembly is generated. -> [Help 1]



This confuses me. There is indeed a file there,
serializer/target/serializer-2.7.3.jar, which xalan:xalan seems to 
successfully use as the artifact for further compilation. Why isn't

maven-assembly-plugin finding and using it?

If I take out the  section entirely (trying to rely on 
defaults), I get the same error message.


Does a  assembly need to be put on a later phase? Or a 
different execution?



Any advice would bemore than welcome...!


In my pom.xml, last plugin before :
...
   
 maven-assembly-plugin
 3.6.0
 false
 
   
 src/assembly/src.xml
 src/assembly/bin.xml
   
 
 
   
 make-assembly 

 package 
 
   single
 
   
 
   
...

And my bin.xml:



http://maven.apache.org/ASSEMBLY/2.2.0";
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
   xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.2.0 
http://maven.apache.org/xsd/assembly-2.2.0.xsd";>

   bin
   
 tar.gz
 zip
   
   true
   
 
   

   true

   
   
   
   
   
   
   
   
   
 modules/maven-assembly-plugin
 false
   
 
   



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

Re: maven-assembly-plugin, bin example is giving me trouble


Oh. I probably forgot to set dependencies. Checking.


On 11/10/2023 9:35 PM, Joseph Kessselman wrote:
I'm trying to adapt the examples given at 
https://maven.apache.org/plugins/maven-assembly-plugin to work with my 
multi-module project.


Source was mostly easy -- I copied the  into a file, tweaked 
its excludes (still wish it picked up the .gitinclude automagically), 
and it worked. I'd still like to change which directory the resulting 
archive files were written to, but that's a nitpick; maybe I can copy 
'em to the "ant simulation" build/ directory afterward.



But binary is giving me a bit more trouble. This is working for others, 
so I presume it's another case of my just not understanding the idiom 
well enough.



All I did was add one more  to reference
src/assembly/bin.xml, and dropped there a copy of the 
taken from the page, modified to output to tar.gz and zip. I changed the
s to reference my artifacts, and ran mvn package again.

Maven objects to my first child module:

 > [ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-assembly-plugin:3.6.0:single 
(make-assembly) on project xalan-project: Failed to create assembly: 
Artifact: xalan:serializer:jar:2.7.3 (included by module) does not have 
an artifact with a file. Please ensure the package phase is run before 
the assembly is generated. -> [Help 1]



This confuses me. There is indeed a file there,
serializer/target/serializer-2.7.3.jar, which xalan:xalan seems to 
successfully use as the artifact for further compilation. Why isn't

maven-assembly-plugin finding and using it?

If I take out the  section entirely (trying to rely on 
defaults), I get the same error message.


Does a  assembly need to be put on a later phase? Or a 
different execution?



Any advice would bemore than welcome...!


In my pom.xml, last plugin before :
...
   
     maven-assembly-plugin
     3.6.0
 false
     
   
     src/assembly/src.xml
     src/assembly/bin.xml
   
     
 
   
     make-assembly 

     package 
     
   single
     
   
     
   
...

And my bin.xml:



http://maven.apache.org/ASSEMBLY/2.2.0";
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
   xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.2.0 
http://maven.apache.org/xsd/assembly-2.2.0.xsd";>

   bin
   
     tar.gz
     zip
   
   true
   
     
   

   true

   
   
   
   
   
   
   
   
   
     modules/maven-assembly-plugin
     false
   
     
   



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

maven-assembly-plugin, bin example is giving me trouble

I'm trying to adapt the examples given at 
https://maven.apache.org/plugins/maven-assembly-plugin to work with my 
multi-module project.


Source was mostly easy -- I copied the  into a file, tweaked 
its excludes (still wish it picked up the .gitinclude automagically), 
and it worked. I'd still like to change which directory the resulting 
archive files were written to, but that's a nitpick; maybe I can copy 
'em to the "ant simulation" build/ directory afterward.



But binary is giving me a bit more trouble. This is working for others, 
so I presume it's another case of my just not understanding the idiom 
well enough.



All I did was add one more  to reference
src/assembly/bin.xml, and dropped there a copy of the 
taken from the page, modified to output to tar.gz and zip. I changed the
s to reference my artifacts, and ran mvn package again.

Maven objects to my first child module:

> [ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-assembly-plugin:3.6.0:single 
(make-assembly) on project xalan-project: Failed to create assembly: 
Artifact: xalan:serializer:jar:2.7.3 (included by module) does not have 
an artifact with a file. Please ensure the package phase is run before 
the assembly is generated. -> [Help 1]



This confuses me. There is indeed a file there,
serializer/target/serializer-2.7.3.jar, which xalan:xalan seems to 
successfully use as the artifact for further compilation. Why isn't

maven-assembly-plugin finding and using it?

If I take out the  section entirely (trying to rely on 
defaults), I get the same error message.


Does a  assembly need to be put on a later phase? Or a 
different execution?



Any advice would bemore than welcome...!


In my pom.xml, last plugin before :
...
  
maven-assembly-plugin
3.6.0
false

  
src/assembly/src.xml
src/assembly/bin.xml
  


  
make-assembly 

package 

  single

  

  
...

And my bin.xml:



http://maven.apache.org/ASSEMBLY/2.2.0";
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
  xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.2.0 
http://maven.apache.org/xsd/assembly-2.2.0.xsd";>

  bin
  
tar.gz
zip
  
  true
  

  

  true

  
  
  
  
  
  
  
  
  
modules/maven-assembly-plugin
false
  

  


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

Re: Can the jar plugin respect .gitignore?


... Actually, correction -- not the jar plugin, the assembly plugin. (sigh)

On 11/10/2023 1:42 PM, Joseph Kessselman wrote:
(Or, equivalently be told to take exclude list from a file in .gitignore 
syntax and then be told .gitignore was that file.)


If not, I'd consider that worth adding.


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

Can the jar plugin respect .gitignore?

(Or, equivalently be told to take exclude list from a file in .gitignore 
syntax and then be told .gitignore was that file.)


If not, I'd consider that worth adding.

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

Keeping java's version in sync with project's version

2023-11-08 Thread Joseph Kessselman

For obvious reasons, if would be nice if the -version option on my 
project automatically reported the version I'd set in the pom.xml rather 
than my trying to synchronize the two manually.


The best approaches I've found so far are in
https://stackoverflow.com/questions/2712970/get-maven-artifact-version-at-runtime
... but there's a note that at least one of them doesn't work in all 
classloaders, or in openjdk.


I'm willing to have the pom write this into a file that the Java code 
would query, if that's what it takes to have a portable solution, but 
I'm not sure what the best way to express that would be.



There must be an established Best Practices solution for this, right?

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

Re: Multi-module build, emulating Ant build...

2023-11-06 Thread Joseph Kessselman


Right. Copypaste of the plugin doesn't work because Maven is declarative.

One instance of exec-maven-plugin with multiple s, each 
having its own ID (since the default is to collide) and its own set of 
arguments, appears to be what's intended.


Unfortunately only the first  seems to be running.

Undoubtedly a Maven-beginner error, misunderstanding some bit of idiom, 
but I haven't yet flailed my way to a solution.


I've opened this as an Issue, mostly because I think it's worth 
explicitly adding an example of this sort to the documentation to help 
other novices. That is, assuming that what I want to do is possible. 
Which it should be, right?


https://github.com/mojohaus/exec-maven-plugin/issues/388

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

Re: Multi-module build, emulating Ant build...

2023-11-06 Thread Joseph Kessselman

(To clarify: Reason I'm asking is that the example of exec:java puts all 
the parameters in  rather than in , and I'm 
not clear on whether I can have  for multiple runs, or
move the arguments into the , or something else to avoid 
repeating quite so much boilerplate.)


On 11/6/2023 7:14 PM, Joseph Kessselman wrote:
Turns out Stylebook does have a front-end driver that I don't have 
source for, so I'm just invoking it via exec:java for now. I'll clean up 
later. At least it gets rid of the platform-specific script and puts the 
pom in charge of everything.


Quick question re exec-maven-plugin: Is it possible for one instance of 
the plugin to run multiple executions, or should I just rely on copypasta?



On 11/4/2023 7:53 PM, Joseph Kessselman wrote:
1) For backward compatibility with the prior Ant build (and with the 
test framework's assumptions about where compiled code will land), I 
have my maven build creating ./build/ in the top-level directory and 
copying the jarfiles from the individual modules up to that using 
maven-dependency-plugin. It would probably be a good thing to copy the 
modules' *-sources.jar files there too, but I haven't found a syntax 
which will do that without also copying all the dependencies' 
sources.jar files. Any tips?



2) Some of Xalan's older documentation was written in stylebook. I'm 
currently handling that by running a post-build script (.sh or .bat) 
to execute the org.apache.stylebook.StyleBook class several times with 
appropriate arguments. It'd be more elegant to invoke that from the 
pom, of course, for clarity and portability... but I haven't yet 
gotten the exec plugin to Do The Right Thing. The needed command is 
something like (in Linux syntax):



java -cp 
stylebook/stylebook-1.0-b3_xalan-2.jar:tools/xalan2jdoc.jar:serializer/target/classes:xalan/target/classes org.apache.stylebook.StyleBook loaderConfig=sbk:/style/loaderdesign.xml targetDirectory=./target/site/design/ ./stylebook/sources/xalandesign.xml ./stylebook/style



... where of course the */target/classes are the compiled sub-modules 
and could just as easily be the generated jarfiles and referenced as 
maven artifacts (right?).


Might be possible to use the ant-stylebook plugin instead, but that 
seems to be deprecated, not well documented, and have CVEs against 
it... which last probably apply to my local copy too, admittedly.


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



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

Re: Multi-module build, emulating Ant build...

2023-11-06 Thread Joseph Kessselman

Turns out Stylebook does have a front-end driver that I don't have
source for, so I'm just invoking it via exec:java for now. I'll clean up
later. At least it gets rid of the platform-specific script and puts the
pom in charge of everything.

Quick question re exec-maven-plugin: Is it possible for one instance of
the plugin to run multiple executions, or should I just rely on copypasta?

On 11/4/2023 7:53 PM, Joseph Kessselman wrote:
1) For backward compatibility with the prior Ant build (and with the
test framework's assumptions about where compiled code will land), I
have my maven build creating ./build/ in the top-level directory and
copying the jarfiles from the individual modules up to that using
maven-dependency-plugin. It would probably be a good thing to copy the
modules' *-sources.jar files there too, but I haven't found a syntax
which will do that without also copying all the dependencies'
sources.jar files. Any tips?

2) Some of Xalan's older documentation was written in stylebook. I'm
currently handling that by running a post-build script (.sh or .bat) to
execute the org.apache.stylebook.StyleBook class several times with
appropriate arguments. It'd be more elegant to invoke that from the pom,
of course, for clarity and portability... but I haven't yet gotten the
exec plugin to Do The Right Thing. The needed command is something like
(in Linux syntax):

java -cp
stylebook/stylebook-1.0-b3_xalan-2.jar:tools/xalan2jdoc.jar:serializer/target/classes:xalan/target/classes org.apache.stylebook.StyleBook loaderConfig=sbk:/style/loaderdesign.xml targetDirectory=./target/site/design/ ./stylebook/sources/xalandesign.xml ./stylebook/style

... where of course the */target/classes are the compiled sub-modules
and could just as easily be the generated jarfiles and referenced as
maven artifacts (right?).

Might be possible to use the ant-stylebook plugin instead, but that
seems to be deprecated, not well documented, and have CVEs against it...
which last probably apply to my local copy too, admittedly.

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

Re: Multi-module build, emulating Ant build...

2023-11-05 Thread Joseph Kesselman

Well, I'm an idiot... Stylebook processing (at least until you want to try to 
run it through  FO and FOP) is just XSLT. There is a Maven plugin to invoke 
XSLT. It looks like it can even be configured to run from the copy I've just 
built, though I need to check that.

Duh. Too obvious.

--
   /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
   /   https://www.amazon.com/dp/B09WJ3H657/

() Plaintext Ribbon Campaign
/\ Stamp out HTML mail!

From: Alexander Kriegisch 
Sent: Saturday, November 4, 2023 9:51:37 PM
To: users@maven.apache.org 
Subject: Re: Multi-module build, emulating Ant build...

Hi Joseph.

Just some thoughts:

  -- Stylebook seems to be a DocBook variant or extension. Maybe you
 could with little effort change the documentations to conform to
 DocBook and then use existing Docbook solutions for Maven.

  -- Scripting the build Ant-style by using Groovy or Bsh from
 corresponding Maven plugins is another, albeiut ugly, option. So is
 using Ant from Maven.

  -- You could write a simple Maven plugin encapsulating the minimal
 behaviour you need, publish it use it for Xalan.

  -- You could convert Stylebook to AsciiDoc and use existing Maven
 plugins to generate the documentation. Last year, I started to
 convert the DocBook and HTML files from the AspectJ documentation
 to AsciiDoc. I did the heavy lifting with Pandoc, batch-converting
 the DocBook stuff. Then I manually fixed up stuff like code blocks
 and other details to be as clean as I like them to be, which was
 tedious, but manageable. Back then, I did not finish my work,
 because the last step, changing the Maven docs generation stuff,
 has not been done yet, but the files look pretty nice already and
 can be directly displayed inline on GitHub, because, well - they
 are AsciiDoc now.

HTH. Regards
--
Alexander Kriegisch
https://scrum-master.de


Joseph Kessselman schrieb am 05.11.2023 06:53 (GMT +07:00):

> 1) For backward compatibility with the prior Ant build (and with the
> test framework's assumptions about where compiled code will land), I
> have my maven build creating ./build/ in the top-level directory and
> copying the jarfiles from the individual modules up to that using
> maven-dependency-plugin. It would probably be a good thing to copy the
> modules' *-sources.jar files there too, but I haven't found a syntax
> which will do that without also copying all the dependencies'
> sources.jar files. Any tips?
>
>
> 2) Some of Xalan's older documentation was written in stylebook. I'm
> currently handling that by running a post-build script (.sh or .bat) to
> execute the org.apache.stylebook.StyleBook class several times with
> appropriate arguments. It'd be more elegant to invoke that from the pom,
> of course, for clarity and portability... but I haven't yet gotten the
> exec plugin to Do The Right Thing. The needed command is something like
> (in Linux syntax):
>
>
> java -cp
> stylebook/stylebook-1.0-b3_xalan-2.jar:tools/xalan2jdoc.jar:serializer/target/classes:xalan/target/classes
>
> org.apache.stylebook.StyleBook loaderConfig=sbk:/style/loaderdesign.xml
> targetDirectory=./target/site/design/
> ./stylebook/sources/xalandesign.xml ./stylebook/style
>
>
> ... where of course the */target/classes are the compiled sub-modules
> and could just as easily be the generated jarfiles and referenced as
> maven artifacts (right?).
>
> Might be possible to use the ant-stylebook plugin instead, but that
> seems to be deprecated, not well documented, and have CVEs against it...
> which last probably apply to my local copy too, admittedly.
>
> -
> 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

Multi-module build, emulating Ant build...

2023-11-04 Thread Joseph Kessselman

1) For backward compatibility with the prior Ant build (and with the
test framework's assumptions about where compiled code will land), I
have my maven build creating ./build/ in the top-level directory and
copying the jarfiles from the individual modules up to that using
maven-dependency-plugin. It would probably be a good thing to copy the
modules' *-sources.jar files there too, but I haven't found a syntax
which will do that without also copying all the dependencies'
sources.jar files. Any tips?

java -cp
stylebook/stylebook-1.0-b3_xalan-2.jar:tools/xalan2jdoc.jar:serializer/target/classes:xalan/target/classes
org.apache.stylebook.StyleBook loaderConfig=sbk:/style/loaderdesign.xml
targetDirectory=./target/site/design/
./stylebook/sources/xalandesign.xml ./stylebook/style

... where of course the */target/classes are the compiled sub-modules
and could just as easily be the generated jarfiles and referenced as
maven artifacts (right?).

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

Re: Feedback sought

2023-10-15 Thread Joseph Kesselman

Hm. Doesn't handle language-semantic formatting (yet?), which in my experience 
is often a bigger deal than spaces vs tabs. Good start, though.

--
   /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
   /   https://www.amazon.com/dp/B09WJ3H657/

() Plaintext Ribbon Campaign
/\ Stamp out HTML mail!

From: Nils Breunese 
Sent: Sunday, October 15, 2023 3:01:28 AM
To: Maven Users List 
Subject: Re: Feedback sought

Joseph Kesselman  wrote:

> Re "IDE droppings"... My experience is that they can actually be useful in 
> expressing things like preferred code formatting style in 
> importable/executable form. (I'd rather have a standard cross-editor way if 
> representing that, but I don't know of one.)

You could take a look at EditorConfig: https://editorconfig.org/

Nils.

Re: Feedback sought

2023-10-15 Thread Joseph Kesselman

Thanks for the pointer.

--
   /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
   /   https://www.amazon.com/dp/B09WJ3H657/

() Plaintext Ribbon Campaign
/\ Stamp out HTML mail!

From: Nils Breunese 
Sent: Sunday, October 15, 2023 3:01:28 AM
To: Maven Users List 
Subject: Re: Feedback sought

Joseph Kesselman  wrote:

> Re "IDE droppings"... My experience is that they can actually be useful in 
> expressing things like preferred code formatting style in 
> importable/executable form. (I'd rather have a standard cross-editor way if 
> representing that, but I don't know of one.)

You could take a look at EditorConfig: https://editorconfig.org/

Nils.

Re: Feedback sought

... And I committed my own typo; it should of course have been "moving forward 
with", not living. Darned auto-correct; I really need to learn to proofread 
more carefully when typing on the phone.


--
   /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
   /   https://www.amazon.com/dp/B09WJ3H657/

() Plaintext Ribbon Campaign
/\ Stamp out HTML mail!
____
From: Joseph Kesselman 
Sent: Sunday, October 15, 2023 12:48:38 AM
To: Maven Users List 
Subject: Re: Feedback sought

Don't worry, we recognized your intent.

I do appreciate the feedback I'm getting. I asked for it, and hopefully the 
parts that don't make sense to apply right now will be useful in the future.

But, yes, let's focus on whether what I've done is worth living forward with 
rather than the details of how we got here. I realize that this large a 
changeset is a pain to review, and I wouldn't normally do it this way. But it 
isn't as much actual change as it appears to be, and I *think* it's stable 
enough to seriously consider cutting over to or I wouldn't have issued the PR.

I'd love to see the maven build tested on a few more systems, too. I've run it 
on Fedora (under WSL) and Windows 10; it would be good to have someone 
sanity-check it on a Mac.

--
   /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
   /   https://www.amazon.com/dp/B09WJ3H657/

() Plaintext Ribbon Campaign
/\ Stamp out HTML mail!

From: Alexander Kriegisch 
Sent: Saturday, October 14, 2023 11:40:52 PM
To: users@maven.apache.org 
Subject: Re: Feedback sought

Alexander Kriegisch schrieb am 15.10.2023 10:36 (GMT +07:00):

>   -- Let us abuse reviews as a tool to micro-manage the contributor to
   
OMG, of course I meant "let us NOT abuse".

>  change what we would have done differently, until it looks exactly
>  like a change we would have done. It is both disheartening and a
>  waste of resources on both sides.

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

Re: Feedback sought

Don't worry, we recognized your intent.

I do appreciate the feedback I'm getting. I asked for it, and hopefully the 
parts that don't make sense to apply right now will be useful in the future.

But, yes, let's focus on whether what I've done is worth living forward with 
rather than the details of how we got here. I realize that this large a 
changeset is a pain to review, and I wouldn't normally do it this way. But it 
isn't as much actual change as it appears to be, and I *think* it's stable 
enough to seriously consider cutting over to or I wouldn't have issued the PR.

I'd love to see the maven build tested on a few more systems, too. I've run it 
on Fedora (under WSL) and Windows 10; it would be good to have someone 
sanity-check it on a Mac.

--
   /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
   /   https://www.amazon.com/dp/B09WJ3H657/

() Plaintext Ribbon Campaign
/\ Stamp out HTML mail!

From: Alexander Kriegisch 
Sent: Saturday, October 14, 2023 11:40:52 PM
To: users@maven.apache.org 
Subject: Re: Feedback sought

Alexander Kriegisch schrieb am 15.10.2023 10:36 (GMT +07:00):

>   -- Let us abuse reviews as a tool to micro-manage the contributor to
   
OMG, of course I meant "let us NOT abuse".

>  change what we would have done differently, until it looks exactly
>  like a change we would have done. It is both disheartening and a
>  waste of resources on both sides.

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

Re: Feedback sought

Taking out the META-INF: I'll look at that.

NOTE that as long as this is basically an acceptable framework to replace the 
And build, and produces correct code, quibbles like editor configurations and 
unnecessary files can be cleaned up in subsequent edits; they shouldn't be 
considered blockers now. "Make it work, make it good, make it great. In that 
order."

--
   /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
   /   https://www.amazon.com/dp/B09WJ3H657/

() Plaintext Ribbon Campaign
/\ Stamp out HTML mail!

From: Greg Chabala 
Sent: Saturday, October 14, 2023 1:50:16 PM
To: Maven Users List 
Subject: Re: Feedback sought

That's certainly an ambitious changeset, but it takes courage to do great
work.

I'd generally suggest trying to make smaller steps so it's easier on
reviewers.

For instance:

   - Could you make a basic Maven build that delegated most of the work to
   Ant with maven-antrun-plugin?
   - If so, then you could have separate follow up steps for moving code
   into the standard Maven layout, and converting from libraries in source to
   Maven retrieved versions.
   - Could you convert a smaller artifact first, like the samples directory?

As far as specific advice on your current PR:

   - I'd recommend taking this opportunity to remove IDE droppings from
   source control entirely. .classpath, .project, .settings/* are all Eclipse
   specific and will be regenerated when the project is imported, if needed.
   They are needless noise in source control and IntelliJ IDEA users don't
   care about them at all.
   - Everything in META-INF will be generated by Maven, so none of that
   should be in source control either.

Re: Feedback sought

Re "IDE droppings"... My experience is that they can actually be useful in 
expressing things like preferred code formatting style in importable/executable 
form. (I'd rather have a standard cross-editor way if representing that, but I 
don't know of one.) But I don't care that strongly; if consensus is to drop 
them, I won't object. Nitpick, but a valid one.

--
   /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
   /   https://www.amazon.com/dp/B09WJ3H657/

() Plaintext Ribbon Campaign
/\ Stamp out HTML mail!

From: Greg Chabala 
Sent: Saturday, October 14, 2023 1:50:16 PM
To: Maven Users List 
Subject: Re: Feedback sought

That's certainly an ambitious changeset, but it takes courage to do great
work.

I'd generally suggest trying to make smaller steps so it's easier on
reviewers.

For instance:

   - Could you make a basic Maven build that delegated most of the work to
   Ant with maven-antrun-plugin?
   - If so, then you could have separate follow up steps for moving code
   into the standard Maven layout, and converting from libraries in source to
   Maven retrieved versions.
   - Could you convert a smaller artifact first, like the samples directory?

As far as specific advice on your current PR:

   - I'd recommend taking this opportunity to remove IDE droppings from
   source control entirely. .classpath, .project, .settings/* are all Eclipse
   specific and will be regenerated when the project is imported, if needed.
   They are needless noise in source control and IntelliJ IDEA users don't
   care about them at all.
   - Everything in META-INF will be generated by Maven, so none of that
   should be in source control either.

Re: Feedback sought

There didn't seem to be a good intermediate point.

Maven wanted things organized differently, and I didn't know Maven well enough 
to argue with it.

Switching from private binaries to Maven packages was a driving force behind 
the cut-over, and the need to move from jlec to jflex forced the one 
significant  code change.

The "insignificant" ones in Javadoc were an attempt to get a Maven build with 
no errors before I found the control for turning off doclint. I could back them 
out but that doesn't seem a good use of resource at this point.

There really isn't that much actual code change. Most of it is moving things 
into different subdirectories.

It's a one time cost. There's really less needing review than may appear.

If someone wants to volunteer to take my changeset as the final goal and 
deliver it incrementally, I have no objection. I'm sure someone who knew Maven 
better could have done this more incrementally.

But I'm what was available, and this is what I could do. And it's actually 
pretty clean.

I think.



--
   /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
   /   https://www.amazon.com/dp/B09WJ3H657/

() Plaintext Ribbon Campaign
/\ Stamp out HTML mail!

From: Greg Chabala 
Sent: Saturday, October 14, 2023 1:50:16 PM
To: Maven Users List 
Subject: Re: Feedback sought

That's certainly an ambitious changeset, but it takes courage to do great
work.

I'd generally suggest trying to make smaller steps so it's easier on
reviewers.

For instance:

   - Could you make a basic Maven build that delegated most of the work to
   Ant with maven-antrun-plugin?
   - If so, then you could have separate follow up steps for moving code
   into the standard Maven layout, and converting from libraries in source to
   Maven retrieved versions.
   - Could you convert a smaller artifact first, like the samples directory?

As far as specific advice on your current PR:

   - I'd recommend taking this opportunity to remove IDE droppings from
   source control entirely. .classpath, .project, .settings/* are all Eclipse
   specific and will be regenerated when the project is imported, if needed.
   They are needless noise in source control and IntelliJ IDEA users don't
   care about them at all.
   - Everything in META-INF will be generated by Maven, so none of that
   should be in source control either.

Feedback sought

2023-10-14 Thread Joseph Kessselman

I've just issued a pull request proposing that the Apache Xalan-Java 
project cut over from Ant-based to Maven-based build.


This is the first time I'm working with Maven, and I'm *sure* I have 
done things that are bad form. If anyone has time and energy to glance 
at it and sanity-check that I haven't made too much of a mess, that 
would be tremendously appreciated.


https://github.com/apache/xalan-java/pull/101

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

Re: Maven license distribution - repo

2023-10-11 Thread Joseph Kesselman

I presume: Maven can automatically download declared dependencies from a 
repository into the local repository  directory as needed. Or  users can 
manually download them into some other location and reference them as local 
"provided" resources.

--
   /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
   /   https://www.amazon.com/dp/B09WJ3H657/

() Plaintext Ribbon Campaign
/\ Stamp out HTML mail!

From: Florent Biville 
Sent: Wednesday, October 11, 2023 5:54:18 AM
To: Maven Users List 
Subject: Maven license distribution - repo

Hello,

Could someone clarify what "repo" actually means in terms of license
distribution.
I searched the interwebz without much success.

I also find the official documentation
 quite vague:

This describes how the project may be legally distributed. The two stated
> methods are repo (they may be downloaded from a Maven repository) or manual
> (they must be manually installed).
>

What does "downloaded from a Maven repository" mean here?

Thanks a lot!
Florent

Re: "First time caller..." javadoc taglet dependencies?

2023-10-04 Thread Joseph Kessselman


Oh. Duh.

  
com.sun
tools
1.6.0
system
${toolsjar}
  



On 10/3/2023 10:04 PM, Alexander Kriegisch wrote:

Hi Joseph.

I think you uncovered a bug in Maven Javadoc Plugin. I just created
https://issues.apache.org/jira/browse/MJAVADOC-775 on your behalf.

As a workaround for the non-functioning 'tagletpath' option, I recommend
to separately publish the taglet library as a Maven artifact, which then
you can refer to using the 'tagletArtifact' option. The hypothetical
workaround to just use a system-scoped dependency and refer to that in
'tagletArtifact', is not working either. So, until this will have been
fixed, your options are very limited.

Because I was looking at the two simple taglet classes in your JAR
anyway from my IDE when analysing your problem, in the attached ZIP
archive is the decompiled source code for both classes, just in case you
do not have the sources anymore and want to recreate the JAR as a
separate artifact. I hope that the mailing list does not strip off
attachments.

Regards


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

Re: "First time caller..." javadoc taglet dependencies?

2023-10-04 Thread Joseph Kesselman

Thanks for the analysis, and the decompile. One of the reasons we're being 
pushed to Mavenize xalan is that people have been grumbling about our carrying 
binaries in the package, so this will make them happier.

My only other real gripe with Maven at the moment is that I haven't yet found a 
way to tell the javadoc plugin "Yes, I know there's lots that can be improved, 
but for now please consider that a Warning rather than an Error."


--
   /_  Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
   /   https://www.amazon.com/dp/B09WJ3H657/

() Plaintext Ribbon Campaign
/\ Stamp out HTML mail!

From: Alexander Kriegisch 
Sent: Tuesday, October 3, 2023 10:04:33 PM
To: users@maven.apache.org 
Subject: Re: "First time caller..." javadoc taglet dependencies?

Hi Joseph.

I think you uncovered a bug in Maven Javadoc Plugin. I just created
https://issues.apache.org/jira/browse/MJAVADOC-775 on your behalf.

As a workaround for the non-functioning 'tagletpath' option, I recommend
to separately publish the taglet library as a Maven artifact, which then
you can refer to using the 'tagletArtifact' option. The hypothetical
workaround to just use a system-scoped dependency and refer to that in
'tagletArtifact', is not working either. So, until this will have been
fixed, your options are very limited.

Because I was looking at the two simple taglet classes in your JAR
anyway from my IDE when analysing your problem, in the attached ZIP
archive is the decompiled source code for both classes, just in case you
do not have the sources anymore and want to recreate the JAR as a
separate artifact. I hope that the mailing list does not strip off
attachments.

Regards
--
Alexander Kriegisch
https://scrum-master.de


Joseph Kessselman schrieb am 04.10.2023 05:41 (GMT +07:00):

> Hi, folks. I'm in the process of trying to port the Apache Xalan build
> from Ant to Maven. It's close to usable, but I'm still struggling with a
> few odd corners.
>
> One of the odder corners: The Xalan documentation uses a javadoc taglet,
> @xsl.usage, to indicate whether a method is intended only for internal
> use despite having to be public for cross-package references. This is
> working fine in one of the two modules of this project, but in the other
> I get:
>
> [ERROR] javadoc: error - Error - Exception
> java.lang.ClassNotFoundException thrown while trying to register Taglet
> xalan2jtaglet.XSLUsageTag...
> [ERROR]
> /home/keshlam/git/xalan-java-mvn/serializer/src/main/java/org/apache/xml/serializer/AttributesImplSerializer.java:37:
>
> error: unknown tag: xsl.usage
>
> Not a very helpful error message Trying to probe at this, the best
> guess I have is that the taglet code has a dependency on another
> jarfile, specifically tools.jar (or equivalent). None of my POMs
> explicitly reference tools.jar, but it's possible that one module is
> acquiring it as an indirect dependency while the other isn't.
>
> My question is whether this diagnosis is likely to be vaguely correct,
> if not how to get a more useful error message out of the javadoc
> invocation, and if so how to make tools.jar available to the taglet in a
> moderately portable manner. I've been trying various fragments from
> Stack Overflow and haven't found one that worked for me yet, hence the
> question here.
>
>
>
> The overall porting attempt is checked in as
> https://github.com/jkesselm/xalan-java-mvn.git if you want to look at
> the configuration as it currently stands, with this problem as yet unsolved.
>
> Thanks in advance. "If it was easy, they wouldn't need _us_."
>
>
> (If anyone is foolish enough to want to glance over the pom.xml files
> for this build and sanity-check them for massive volations of Maven
> idiom or horrible misunderstandings of Maven use, I'd greatly appreciate
> it. I haven't previously written a Maven configuration and a lot of this
> has been guesswork based on how many other build systems have behaved.)
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

"First time caller..." javadoc taglet dependencies?

2023-10-03 Thread Joseph Kessselman

Hi, folks. I'm in the process of trying to port the Apache Xalan build
from Ant to Maven. It's close to usable, but I'm still struggling with a
few odd corners.

One of the odder corners: The Xalan documentation uses a javadoc taglet,
@xsl.usage, to indicate whether a method is intended only for internal
use despite having to be public for cross-package references. This is
working fine in one of the two modules of this project, but in the other
I get:

[ERROR] javadoc: error - Error - Exception
java.lang.ClassNotFoundException thrown while trying to register Taglet
xalan2jtaglet.XSLUsageTag...
[ERROR]
/home/keshlam/git/xalan-java-mvn/serializer/src/main/java/org/apache/xml/serializer/AttributesImplSerializer.java:37:
error: unknown tag: xsl.usage

Not a very helpful error message Trying to probe at this, the best
guess I have is that the taglet code has a dependency on another
jarfile, specifically tools.jar (or equivalent). None of my POMs
explicitly reference tools.jar, but it's possible that one module is
acquiring it as an indirect dependency while the other isn't.

My question is whether this diagnosis is likely to be vaguely correct,
if not how to get a more useful error message out of the javadoc
invocation, and if so how to make tools.jar available to the taglet in a
moderately portable manner. I've been trying various fragments from
Stack Overflow and haven't found one that worked for me yet, hence the
question here.

The overall porting attempt is checked in as
https://github.com/jkesselm/xalan-java-mvn.git if you want to look at
the configuration as it currently stands, with this problem as yet unsolved.

Thanks in advance. "If it was easy, they wouldn't need _us_."

(If anyone is foolish enough to want to glance over the pom.xml files
for this build and sanity-check them for massive volations of Maven
idiom or horrible misunderstandings of Maven use, I'd greatly appreciate
it. I haven't previously written a Maven configuration and a lot of this
has been guesswork based on how many other build systems have behaved.)

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

Parent pom not resolved in current reactor ?

2014-10-13 Thread Grégory Joseph

Hey there,

In the documentation for "relativePath" in
http://maven.apache.org/xsd/maven-4.0.0.xsd, I read that "Maven looks
for the parent pom first in the reactor of currently building
projects, then <...>". Oddly enough, even though the reference docs
_seem_ to be generated off of the same source, this bit is absent from
http://maven.apache.org/ref/3.2.3/maven-model/maven.html#class_parent

Empirically, it would appear the online doc is correct and the xsd doc
is wrong, but I'd like a confirmation this is indeed the intended
behavior. I'm currently working on a project that has a reactor, but
where some of the modules have a different lifecycle than others; for
those, it is inconvenient to have to have  (because that
paths points to a current snapshot, where as the rest of the 
tag point to a release version of the same artifact, making it unclear
which one is actually used)

Thanks for any hint or tip,

Cheers,

-greg

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

Changes in how exclusions are applied transitively ?

2013-07-24 Thread Grégory Joseph

Hey there,

I can't seem to find an accurate trace of this in the release notes,
so I thought I'd just ping the list - Changes in how exclusions are
applied transitively between Maven 2.2.1 and 3.1 ?

Here's a situation: A has dependencies on B and C. Both transitively
depend on D  (through X, which is irrelevant, I think)  but B excludes
it (on its dep declaration of X)

With 2.2.1, D was (wrongly imo) excluded from A (depending on
dependency order, seemingly)

With 3.1, it appears to behave "correctly".

Since I'm stuck with 2.2.1 for a bit, I'm facing a situation right now
where I need to work around the bug, currently by removing the
exclusions. That's currently OK, but at some point, those exclusions
will be re-added (in A or in a new project) and we'll face the same
issue again, without any clue as to why.

How have people dealt with this so far ?

Thanks for any hint or pointers !

-greg

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

Changes in how exclusions are applied transitively ?

2013-07-24 Thread Grégory Joseph

Hey there,

I can't seem to find an accurate trace of this in the release notes,
so I thought I'd just ping the list - Changes in how exclusions are
applied transitively between Maven 2.2.1 and 3.1 ?

Here's a situation: A has dependencies on B and C. Both transitively
depend on D  (through X, which is irrelevant, I think)  but B excludes
it (on its dep declaration of X)

With 2.2.1, D was (wrongly imo) excluded from A (depending on
dependency order, seemingly)

With 3.1, it appears to behave "correctly".

Since I'm stuck with 2.2.1 for a bit, I'm facing a situation right now
where I need to work around the bug, currently by removing the
exclusions. That's currently OK, but at some point, those exclusions
will be re-added (in A or in a new project) and we'll face the same
issue again, without any clue as to why.

How have people dealt with this so far ?

Thanks for any hint or pointers !

-greg

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

Re: Site, deployment url and inheritance

On 2 July 2012 14:38, Lukas Theussl  wrote:
> Grégory Joseph wrote:
>> Just tried staging, and indeed, the paths in that case are correct* -

I take it back. Staging was fine… with 2.1.1.
With 3.1 I get this, for example for last module of the multi-module build
[INFO] Pushing /project-root/moduleX/target/site
[INFO]>>> to
file:///project-root/target/staging/../..//
… which is wrong, since that makes
 end up in the project root,
and not under target/staging/...

>> but again, I'm assuming that's because the normalization is done and
>> supported by my local FS ?
>
> IIRC normalization is done by the wagon you are using for the deploy, so
> it's outside the realm of the site plugin. I seem to remember that this
> was also the reason for adding a dot component /./ in the deployment url
> because some wagons only worked like that (I might be wrong though, it's
> been a while...).
>
> OTOH, I don't quite see what the problem is, a non-normalized url is
> still a valid url and every server/file system should be able to deal
> with it. Or do you have a specific actual issue that's caused by it?
> There have been issues reported (MSITE-531, MSITE-601) but in each case
> the underlying cause was outside maven/wagon/site-plugin.

Yes I do have an issue with that, that's why I'm here for ;) The "../"
isn't resolved properly, I'm assuming on the server side -- it seems
my Nexus instance just zaps it entirely, so "a/b/../../foo" ends up in
"a/b/foo".

Anyhow - I am currently re-testing all I can, and considering going
back to 2.1.1 - not sure what my problem was with it in the first
place, that I wanted to try the newer version :D

Cheers,

-g

>>
>> * with the strange bug that "https://nexus.domain.org/xyz"; was
>> converted to targetstaging/http/s.domain.org/xyz ...
>
> that looks weird indeed, if you have a test case I will look at it.
>
> -Lukas
>
>>
>> On 2 July 2012 13:57, Grégory Joseph  wrote:
>>> Hi Lukas,
>>>
>>> On 2 July 2012 13:18, Lukas Theussl  wrote:
>>>> Grégory Joseph wrote:
>>>>> It kind of sounds like MSITE-600 to me, so I'm unsure if/how the issue
>>>>> was fixed. Example:
>>>>> * Corporate parent pom defines this site deployment url:
>>>>> prot://foo/${artifactId}/${version} -- it works for this pom, and it's
>>>>> a good enough default for most of our single-module projects. Not the
>>>>> lack of trailing slash, btw.
>>>>> * Some multi-module project defines this site deployment url:
>>>>> prot://foo/xuq/lolcats/${version}. And the resulting deployment urls
>>>>> end up looking like:
>>>>> prot://foo/corp-parent/12//../../xuq/lolcats/${version} (and I still
>>>>> don't know where the double slash comes from)
>>>>
>>>> Normalizing this is exactly the same as
>>>> prot://foo/xuq/lolcats/${version},
>>>
>>> It *should* be, but by using those URLs as-is, Maven relies on the
>>> receiving end to do the normalization.
>>> And I'm still wondering why it bothers doing that in the first place ;)
>>>
>>>> so the deployment location should be
>>>> correct. Did you try site:stage to check?
>>>
>>> How is that helping ? I am not worried about inter-module links -
>>> those indeed seem to work - but about why the parent's urls are taken
>>> into account in the first place, and if there's a good reason for
>>> that, then I wonder why normalization doesn't happen on the Maven
>>> side.
>>>
>>> Cheers,
>>>
>>> -g
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

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

Re: Site, deployment url and inheritance

Just tried staging, and indeed, the paths in that case are correct* -
but again, I'm assuming that's because the normalization is done and
supported by my local FS ?

-g

* with the strange bug that "https://nexus.domain.org/xyz"; was
converted to targetstaging/http/s.domain.org/xyz ...

On 2 July 2012 13:57, Grégory Joseph  wrote:
> Hi Lukas,
>
> On 2 July 2012 13:18, Lukas Theussl  wrote:
>> Grégory Joseph wrote:
>>> It kind of sounds like MSITE-600 to me, so I'm unsure if/how the issue
>>> was fixed. Example:
>>> * Corporate parent pom defines this site deployment url:
>>> prot://foo/${artifactId}/${version} -- it works for this pom, and it's
>>> a good enough default for most of our single-module projects. Not the
>>> lack of trailing slash, btw.
>>> * Some multi-module project defines this site deployment url:
>>> prot://foo/xuq/lolcats/${version}. And the resulting deployment urls
>>> end up looking like:
>>> prot://foo/corp-parent/12//../../xuq/lolcats/${version} (and I still
>>> don't know where the double slash comes from)
>>
>> Normalizing this is exactly the same as
>> prot://foo/xuq/lolcats/${version},
>
> It *should* be, but by using those URLs as-is, Maven relies on the
> receiving end to do the normalization.
> And I'm still wondering why it bothers doing that in the first place ;)
>
>> so the deployment location should be
>> correct. Did you try site:stage to check?
>
> How is that helping ? I am not worried about inter-module links -
> those indeed seem to work - but about why the parent's urls are taken
> into account in the first place, and if there's a good reason for
> that, then I wonder why normalization doesn't happen on the Maven
> side.
>
> Cheers,
>
> -g

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

Re: Site, deployment url and inheritance

Hi Lukas,

On 2 July 2012 13:18, Lukas Theussl  wrote:
> Grégory Joseph wrote:
>> It kind of sounds like MSITE-600 to me, so I'm unsure if/how the issue
>> was fixed. Example:
>> * Corporate parent pom defines this site deployment url:
>> prot://foo/${artifactId}/${version} -- it works for this pom, and it's
>> a good enough default for most of our single-module projects. Not the
>> lack of trailing slash, btw.
>> * Some multi-module project defines this site deployment url:
>> prot://foo/xuq/lolcats/${version}. And the resulting deployment urls
>> end up looking like:
>> prot://foo/corp-parent/12//../../xuq/lolcats/${version} (and I still
>> don't know where the double slash comes from)
>
> Normalizing this is exactly the same as
> prot://foo/xuq/lolcats/${version},

It *should* be, but by using those URLs as-is, Maven relies on the
receiving end to do the normalization.
And I'm still wondering why it bothers doing that in the first place ;)

> so the deployment location should be
> correct. Did you try site:stage to check?

How is that helping ? I am not worried about inter-module links -
those indeed seem to work - but about why the parent's urls are taken
into account in the first place, and if there's a good reason for
that, then I wonder why normalization doesn't happen on the Maven
side.

Cheers,

-g

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

Site, deployment url and inheritance