Re: [VOTE] Require Java 17 for Maven 4

[Joseph Kesselman]

+. 8

Xalan-J's next release should be Maven-based. But we wanted to put out one Java 
8-compatible-but-deprecated build before moving to Java 17.

Of course as part of that we could say Maven3 is compatible but deprecated. I 
haven't yet tested with Maven 4, though, and given my limited Maven skill if 
something odd turns up I may need to get help resolving that.

We can try a spin of that as a sanity check...


--
   /_  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: Wednesday, February 28, 2024 7:44:49 AM
To: Maven Users List 
Cc: Maven Developers List 
Subject: Re: [VOTE] Require Java 17 for Maven 4

+1

Also good idea to remind folks to stay focused in a vote thread.

Gary

On Wed, Feb 28, 2024, 2:31 AM Benjamin Marwell  wrote:

> Hi Maven Devs/Users/Committers and PMC members!
>
> After several discussions on the mailing lists, I would like to
> start a vote in favour of setting the minimal Java bytecode target
> of Maven-Core 4 to 17 and hence require Java 17 for Maven 4.
>
> This is a procedural majority vote [1*]:
> You can also vote with fractions and negative votes are not vetoes.
>
> Please also notice:
> * Maven 3 will stay at Java 8 no matter what.
> * We may raise Maven 4 to JDK 21 later if we feel like it (depending
> on the release date).
>   This is not part of this vote.
> * The linked PR is not part of this vote (this is not a code vote).
>   But you may take a look at it to understand the intended change.
>
> PR: https://github.com/apache/maven/pull/1430
>
> Maven-Parent will not be raised with this vote, the other PR is not
> part of this vote.
>
> Please refrain from starting discussions in this thread, but do
> include a reasoning on downvotes and feel free to start a new
> discussion on the mailing list, or comment on the existing ones.
>
> ---
>
> Vote open for 72 hours:
>
> [ ] +1 (set JDK17 min version for Maven 4.x)
> [ ] +0
> [ ] -1 (please include reasoning)
>
> ---
>
> - Ben
>
> [1*]: https://www.apache.org/foundation/voting.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: creating a source directory on the fly

[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

[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

[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

[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

[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.

[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;
>>   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
>>   

Re: Can the jar plugin respect .gitignore?

[Joseph Kesselman]

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?

[Joseph Kesselman]

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?

[Joseph Kesselman]

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?

[Joseph Kesselman]

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: Can the jar plugin respect .gitignore?

[Joseph Kesselman]

... 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: Multi-module build, emulating Ant build...

[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

Re: Feedback sought

[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

[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

[Joseph Kesselman]

... 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

[Joseph Kesselman]

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

[Joseph Kesselman]

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

[Joseph Kesselman]

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

[Joseph Kesselman]

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.

Re: Maven license distribution - repo

[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?

[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
>
>