Re: Maven 5 pom extension for agents

[Henning Schmiedehausen]

I don't understand fatjar and fatmodule. Why would we need that? How would
maven treat this different from a regular jar / module ?

-h



On Sun, Oct 29, 2023 at 8:10 AM Tamás Cservenák  wrote:

> Howdy,
>
> The current draft of types we want to introduce (and  packaging):
> https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8
>
> ===
>
> Romain, I don't understand your "This is wrong, downstream is either module
> or jar", as it was actually you and your example that mentioned "once put
> it here, once put it there". Nothing is lost IMHO, just like in case of
> "takari-jar" nothing is lost.
>
> Or if we misunderstood each other: by "downstream" I mean "down the road,
> when a project being built, is about to be consumed as dependency".
>
> And the point is, that exactly due ArtifactHandler/ArtifactType/Type (in
> mvn4), Maven "sees" it as "jar" or "module" or whatever, but for resolver,
> those two are _same thing_. It is _same file_. And this is the crux, as for
> the resolver, it is really about getting that one file, while the type (for
> Maven) tells HOW to make use of it. So for resolving, there is no any kind
> of "lost" information, again, the very same way it works for "takari-jar".
>
> T
>
> On Sun, Oct 29, 2023 at 3:52 PM Romain Manni-Bucau 
> wrote:
>
> > Le dim. 29 oct. 2023 à 15:29, Tamás Cservenák  a
> > écrit :
> >
> > > Howdy,
> > >
> > > So to return to the "root" idea (of Maven), Maven is "declarative",
> where
> > > users should declare what they want, it should most certainly not
> "guess"
> > > what user intent is. As long as we have "magical implicit guesswork"
> > (like
> > > that in javadoc) present in process, it is bad, as that means we do not
> > > allow our users to express their goal.
> > >
> >
> > Yes and i liked that but we broke it with forcing plugin version locking
> > (for good) so we can need to revise our root too to match current world
> > which is no more unique, makes years we ignore that fact but it already
> > blows up.
> >
> > So my 2cts are  we cant by design here, we tried hard and failed, not
> > technically but by design.
> >
> >
> >
> > > Originally Mojos were envisioned to be simple, focused, doing one thing
> > and
> > > doing it well (a la UNIX tools). Some plugins went in the total
> opposite
> > > direction, as they became Godzilla plugins (with unmaintainable complex
> > and
> > > large amounts of "logic" -- guess logic and bloated codebase) targeting
> > to
> > > solve "everything". This also resulted in our users assuming "every
> > problem
> > > should have a corresponding Mojo" (this also steered toward bloated,
> over
> > > complex Mojos), where many many other aspects and capabilities of Maven
> > > were totally neglected, like lifecycle, custom packaging and so on.
> > >
> > > In short, Romain, yes, today, you CAN build all sort of things in
> "smart
> > > way", just like cooking a soup: get a good base (packaging), add a
> little
> > > bit of this (mojo A) and a little bit of that (mojo B) and voila, you
> > will
> > > end up with a "soup". And it works, yes, but this "smart" way has many
> > > pitfalls along the way, with most problematic of not being explicit.
> But
> > by
> > > doing that, your build becomes Ant-ish (imperative-ish), and you are
> > > sliding off the declarative path.
> > >
> >
> > For cases needing it and all the mentionned ones are (and will) NOT (be)
> > mainstream.
> > So all good IMHO.
> >
> >
> > > Also, you ARE aware that if you build a project w/ packaging=module
> (that
> > > as output has an artifact with extension jar), you DON'T HAVE TO
> address
> > it
> > > downstream (when you depend on it) as "module", right? This is the
> actual
> > > reason why I brought up Takari Lifecycle, as there you are building
> > > projects with packaging=takari-jar, but when you consume those, you
> refer
> > > to them as type=jar, and not as type=takari-jar, right?
> > >
> >
> > This is wrong, downstream is either module or jar, here you loose if it
> is
> > a module transitively and module assume all transitive deps are which is
> > very often wrong so it does not work downstream.
> >
> >
> > > So, I have a feeling that you bring bold conclusions (like "Your
> solution
> > > is valid technically but does not solve the original issue"), you do
> not
> > > really understand what I am trying to say here.
> > >
> >
> > Hooe you are true but trust me i went where you are and my conclusion is
> it
> > cant be done right for enough projects to be worth it.
> >
> >
> > > Also, "this" certainly does NOT "work well today" (even in this thread
> > poor
> > > tooling mentioned), but true, you can hack-around it, or alike, but
> none
> > of
> > > current solutions are explicit, declarative and naturally expressed in
> > > Maven (but are bolted on).
> > >
> > > Finally, having anything "on top" of resolver is not gonna help
> anything,
> > > as Resolver is really about Artifacts only (Everything is an Artifact!)
> > and
> > > it i

Re: Maven 5 pom extension for agents

[Henning Schmiedehausen]

If the current standard type would be "dependency", this would work IMHO.
It is not. It is "jar". This is perceived as "packaging", not a specific
semantic type that represents "dependency").

A bom is "type == pom, scope == import" which is a special case. If this
were "type == bom, scope == import" and maps onto "pom file" (extension ==
pom), this would make sense. It does not.

In the same vein, the type == "test-jar" should not be that. It should be
"tests" (because test-jar implies the packaging already). And it is unclear
to me what we should do if a type is given (e.g. "jar" which implies
dependency) but then a classifier ("tests"). All the semantics here are
muddled up.

All the "type / classifier" -> "extension" translation is ad hoc, there are
no defined rules anywhere. I think we could create this (for maven 4? maven
5?) but we can not retcon this for Maven 3 where type is a mixture between
"purpose" (dependency) and "packaging" (jar).

A dependency IMHO consists of

* gav -> coordinates of the artifact
* scope -> scope in which the artifact is valid

* "packaging" -> defines how the artifact is packaged if it is possible to
have multiple styles. At the minimum, we need to support "jar" and "file".
The default packaging may be controlled by the type but can be overridden.
I don't like "extension" because it implies that the collection of bytes on
disk has a specific name.

* "type" -> semantic type of the artifact. Default should be "dependency"

* "variant" to select a specific variant of an artifact. E.g. "x86_64" or
"arm64" for native artifacts.

"classifier" I think is the main problem.  Today it serves double-duty as
"variant" but also affects the final name of the file on disk.  Changing
the classifier actually affects the type, which it should not. But on the
other hand, setting the type should affect the final name on disk as well.
(e.g. type == "test-jar" would turn the name into
"artifact-version-tests.packaging-specific-extension"

It would be nice to fix all of this, but then again, what we have today is
so deeply entrenched in 20+ years of maven ecosystem, that I am not sure
that it can be done without breaking compatibility.

-h





On Sat, Oct 28, 2023 at 3:27 PM Tamás Cservenák  wrote:

> So, basically this is what am proposing:
> https://gist.github.com/cstamas/76f262538b5a11f6ee23d6d8c86f10ec
>
> Basically, Maven core (and hence plugins) could distinguish among different
> "types" of dependencies (while would all still be plain JARs).
> So "jar" would be put on classpath, "module" on module path, "agent" would
> got special treatment and so on.
>
> Point is to _differentiate_.
>
> T
>
> On Sun, Oct 29, 2023 at 12:21 AM Tamás Cservenák 
> wrote:
>
> > Unsure from where you get that, but is wrong conclusion.
> >
> > You can have dep1:jar, dep2:module, dep3:agent and all 3 MAY
> > (ArtifactHandler dependent, assuming "jar", "module" and "agent" artifact
> > handlers all return extension=jar) refer to the same JAR file in your
> local
> > repository.
> >
> > Type merely adds "semantics" WHAT is it about, HOW to make use of it.
> > Please see
> >
> https://maven.apache.org/repositories/artifacts.html#but-where-do-i-set-artifact-extension
> >
> > Thanks
> > T
> >
> > On Sun, Oct 29, 2023 at 12:17 AM Martin Desruisseaux <
> > martin.desruisse...@geomatys.com> wrote:
> >
> >> Le 2023-10-28 à 22 h 54, Tamás Cservenák a écrit :
> >>
> >> > I still see these just as new dependency types: "module", "agent",
> >> > "doclet", and so on.
> >> >
> >> Does "dependency type" means the  element inside ? If
> >> yes, then specifying a different type causes Maven to download a
> >> different JAR, without changing the kind of path (class path versus
> >> module path) where the JAR is put. The proposed  element (or
> >> whatever equivalent alternatives) has the opposite semantic: it does not
> >> change the JAR to download, but put it on a different kind of path.
> >>
> >>  Martin
> >>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
>

Re: Maven 5 pom extension for agents

[Henning Schmiedehausen]

Modules are just regular dependencies that need to end up on the module
path instead of the classpath. Creating a new section in the pom (with all
its pains, because it would not just be "modules" but also
"moduleManagement", akin to "dependencyManagement") is IMHO a really bad
idea. Also, "module" is already taken. ;-)

-h



On Sat, Oct 28, 2023 at 1:55 PM Tamás Cservenák  wrote:

> Howdy,
>
> I still see these just as new dependency types: "module", "agent",
> "doclet", and so on.
>
> Also, for "other end" (producing) we'd need new packaging as well: "module"
> at least for example.
>
> ArtifactHandler would need to be extended as well, or better, complete
> adopt Resolver ArtifactType instead (of limited Maven ArtifactHandler):
>
> https://github.com/apache/maven-resolver/blob/master/maven-resolver-api/src/main/java/org/eclipse/aether/artifact/ArtifactType.java
>
> And plugins should just do what given Artifact's ArtifactType says, no
> more, no less.
> No heuristic, no "guesswork", or anything like that, just keep the simple
> stupid.
>
> Thanks
> T
>
>
> On Tue, Oct 24, 2023 at 7:42 AM Thomas Reinhardt 
> wrote:
>
> >
> > On 20/10/2023 20:43, Romain Manni-Bucau wrote:
> > > Can be the way to define the lookup, an heuristic will never work by
> > > design...that said, on my side, not sure JPMS will be widely adopted
> > > anytime soon so can be a false problem.
> > This is a chicken and egg problem. My company would love to use JPMS
> > more. But right now it is basically unusable for us and part of it is
> > lacking maven support. The next big maven release should definitely
> > improve the support. One big problem is testing (and all the
> > implications with different classpaths etc) but that deserves its own
> > discussion I think.
> >
> >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > >
> > >
> > > Le ven. 20 oct. 2023 à 20:24, Henning Schmiedehausen <
> > > henn...@schmiedehausen.org> a écrit :
> > >
> > >> I think we will need to start rethinking dependencies more. A similar
> > >> problem exists with modules; the current heuristics to decide whether
> a
> > >> dependency goes on module path or classpath will start to become
> > painful in
> > >> the very near future.
> > >>
> > >> -h
> > >>
> > >>
> > >> On Tue, Oct 17, 2023 at 10:05 PM Benjamin Marwell <
> bmarw...@apache.org>
> > >> wrote:
> > >>
> > >>> If you can still use it twice, works for me, too.
> > >>>
> > >>> Either way, you'd need it both as a dependency and as an agent.
> > >>>
> > >>> Another requirement Romain mentioned is the order of agent loading.
> > >> Mockito
> > >>> wants to be first, and others can come later.
> > >>>
> > >>> - Ben
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Wed, 18 Oct 2023, 00:11 Tamás Cservenák, 
> > wrote:
> > >>>
> > >>>> What about type=java-agent? Basically a new ArtifactHandler?
> > >>>>
> > >>>> See https://maven.apache.org/repositories/artifacts.html
> > >>>>
> > >>>> T
> > >>>>
> > >>>> On Tue, Oct 17, 2023, 23:54 Benjamin Marwell 
> > >>> wrote:
> > >>>>
> > >>>>> Hey all,
> > >>>>>
> > >>>>> In a mockito issue, JDK maintainers suggested to differentiate
> > >> between
> > >>>>> agents and normal dependencies. Starting with JDK 21 already, this
> > >>> makes
> > >>>> a
> > >>>>> lot of sense: dynamic loading of agents will be a no-go.
> > >>>>>
> > >>>>> One suggestion was:
> > >>>>>
> > >>>>> 
> > >>>>>  
> 

Re: [VOTE] Retire Maven Docck Plugin

[Henning Schmiedehausen]

+1

-h

On Mon, Oct 16, 2023 at 3:50 PM Slawomir Jaranowski 
wrote:

> Hi,
>
> - Last release was in 2015
> - use Maven 2.2.1
> - we have a Maven Plugin Tools - which should be one project for build and
> check Maven plugins
> - no active development ...
>
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MDOCCK%20AND%20(%20resolution%20%3D%20Unresolved%20OR%20fixVersion%20%3D%203.0.0)
> - no working with current plugins
>
> I therefore propose that we retire maven-docck-plugin -
> https://maven.apache.org/plugins/maven-docck-plugin/
>
> If this vote is successful I will make one final release of the plugin,
> making it clear on the plugin site that it has been retired.
> After that the source code will be moved into read-only mode.
>
> The process for retiring a plugin is described here:
> https://maven.apache.org/developers/retirement-plan-plugins.html
>
> The vote is open for 72 hours.
>
> [ ] +1 Yes, it's about time
> [ ] -1 No, because...
>
> [1]
>
> --
> Sławomir Jaranowski
>

Re: Maven 5 pom extension for agents

[Henning Schmiedehausen]

I think we will need to start rethinking dependencies more. A similar
problem exists with modules; the current heuristics to decide whether a
dependency goes on module path or classpath will start to become painful in
the very near future.

-h


On Tue, Oct 17, 2023 at 10:05 PM Benjamin Marwell 
wrote:

> If you can still use it twice, works for me, too.
>
> Either way, you'd need it both as a dependency and as an agent.
>
> Another requirement Romain mentioned is the order of agent loading. Mockito
> wants to be first, and others can come later.
>
> - Ben
>
>
>
>
> On Wed, 18 Oct 2023, 00:11 Tamás Cservenák,  wrote:
>
> > What about type=java-agent? Basically a new ArtifactHandler?
> >
> > See https://maven.apache.org/repositories/artifacts.html
> >
> > T
> >
> > On Tue, Oct 17, 2023, 23:54 Benjamin Marwell 
> wrote:
> >
> > > Hey all,
> > >
> > > In a mockito issue, JDK maintainers suggested to differentiate between
> > > agents and normal dependencies. Starting with JDK 21 already, this
> makes
> > a
> > > lot of sense: dynamic loading of agents will be a no-go.
> > >
> > > One suggestion was:
> > >
> > > 
> > > 
> > > ...
> > > 
> > > 
> > > 
> > > ...
> > > 
> > > 
> > > 
> > >
> > > Not sure if this is the best way, but this is something similar might
> be
> > > needed.
> > > Currently, the only way to handle agents is to add them manually to the
> > > surefire argLine. To make things worse, a deoendency goal is needed
> until
> > > Romains PR is merged:
> > > https://github.com/apache/maven/pull/1281
> > >
> > > Another issue is that a parent pom might not be able to easily define
> > this
> > > option. There were some concerns that part of the configuration needed
> to
> > > be repeated in every module.
> > >
> > > So, I wrote Maven 5.
> > > Maven 4 is the stepping stone to the build/consumer pom. But this is an
> > > extension. Not really a breaking change in terms of parsing, but in
> terms
> > > of building a project. Thus, it should go onto the roadmap.
> > >
> > > ... unless you want to keep the current status quo, which is also an
> > > option. But before making an argument here, I'd recommend reading the
> > > lengthy (sorry!) discussion on the mockito issue tracker. Since Karl
> > Heinz
> > > started the issue, I'd love to hear back from you, too. Link:
> > > https://github.com/mockito/mockito/issues/3037
> > >
> > > If no discussion is needed at this point, let's keep this as a reminder
> > for
> > > the next Apero and/or Maven 5 then.
> > >
> > > - Ben
> > >
> >
>

Re: [VOTE] Release Apache Maven 3.9.5

[Henning Schmiedehausen]

+1

Eyeballed it and did some basic testing on MacOS. All seems good here.

-h


On Sun, Oct 1, 2023 at 12:07 PM Tamás Cservenák  wrote:

> Howdy,
>
> Note: This release completes the main goals of Maven 3.9.x lineage, among
> others moving to Java 8 and transition to latest Resolver 1.9.x features
> (new robust transports, local repository locking, provided checksums,
> remote repository filtering and more). Maven Resolver 1.9.x lineage is
> already in "bugfix only" (no new features) maintenance mode, and this makes
> Maven 3.9.x lineage getting into this maintenance mode as well. I do
> foresee some more Maven 3.9.x releases with usual fluff (bug fixes,
> lifecycle plugin updates), but the focus should move to upcoming Maven 4,
> Resolver 2 and mvnd (at least when "core" is considered).
>
> ---
>
> We solved 8 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12353460
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1995
>
> Dev dist directory (binary bundles updated):
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.5/
>
> Source release checksums:
> apache-maven-3.9.5-src.zip sha512:
>
> f1e7f36a6423c4f6d98e599120ede3a9f9f62448edeb2d49ffbdc05e36548190049bc83aae4f49e3305da1060d7b8e49477a55cb78b938951fd41ab3d360995f
>
> apache-maven-3.9.5-src.tar.gz sha512:
>
> fd8f9c4f3c6af001d11146102ba491b248163cd45d8be16907f7dcdc763eef4a081a02286b28a74de7f48c3f377a0a4491d2fa9155c906466aa3c831a5b4ef8e
>
> Staged site:
> https://maven.apache.org/ref/3-LATEST/
>
> Draft for release notes:
> https://github.com/apache/maven-site/pull/458
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72h
>
> [ ] +1
> [ ] +0
> [ ] -1
>

thoughts about SUREFIRE-2191

[Henning Schmiedehausen]

So I looked a bit more into that bug and why it crashes the way it crashes.
I also added this as a comment to the ticket but given the silence on most
tickets, I'd like to push for some discussion here on the mailing list.


I have two modules, core and testing (these are defined modules, they have
a module descriptor)

"core" is just a regular build, it uses junit5 as its test framework.

surefire creates a classpath with all the surefire deps (surefire-api,
surefire-extensions, surefire-junit-platform, surefire-logging-api,
surefire-shared-utils) and the junit deps (junit-jupiter-api,
junit-jupiter-engine, junit-jupiter-params, junit-platform-commons,
junit-platform-engine, junit-platform-launcher). The module path only gets
the actual module dependencies of module A

All works well in that case.

Now the "testing" module declares org.junit.jupiter.api as a dependency and
has requires org.junit.jupiter.api in its module descriptor (transitive or
not transitive does not matter) because there is code that implements some
of those APIs.

surefire now creates a classpath with the same surefire deps and only a
subset of junit deps. The missing deps (junit-jupiter-api and
junit-platform-commons) are pulled onto the module path.

This explains the error message:

*java.lang.IllegalAccessError: class
org.junit.platform.launcher.core.LauncherDiscoveryRequestBuilder (in
unnamed module @0x6392827e) cannot access class
org.junit.platform.commons.util.Preconditions (in module
org.junit.platform.commons) because module org.junit.platform.commons does
not export org.junit.platform.commons.util to unnamed module @0x6392827e*

The launcher (in junit-platform-launcher) lives on the classpath and is
therefore in the unnamed module. But the launcher requires the
org.junit.platform.commons module from the junit-platform-commons jar,
which is on the module path. And the junit-platform-commons module has the
following clause in its module descriptor:

exports org.junit.platform.commons.util to
[...]
org.junit.platform.launcher,
[...];

and it does not export the package to the unnamed module. And now JVM fails
with the error above.

I can not see any good solution:

- The current solution does not work (see above)
- The junit-jupiter-api jar which contains org.junit.jupiter.api can not go
on the class path because now the main artifact which requires it can not
find it (the classes would be in the unnamed module and the main module
requests org.junit.jupiter.api)
- It can not be patched into the main module because now
the org.junit.jupiter.api module would be invisible to everything else on
the module path (packages can't exist twice)
- It can only stay on the module path if everything that depends on it gets
pulled there as well. This requires a "bottom up" resolution of all modules
that depend on this (in this case org.junit.jupiter.api) and may interfere
with the ability of the surefire launcher to launch code.
- We could fall back to "legacy" mode where everything is on the classpath
and the module path is ignored. This is problematic as tests may pass and
code later fails because of not matching entries in the module descriptor

Thoughts? This seems to be a blocker for projects that want to use JPMS and
implement test code.

-h

dependency metadata

[Henning Schmiedehausen]

The more I spend time with JPMS and maven, the more I wonder if we need to
have some kind of additional metadata for our dependency declarations.

Up until Java 8, dependencies were pretty straightforward: They go on the
classpath depending on their scope. Some are only on the compile classpath,
some on the test classpath, some on the runtime classpath.

In the Java 9+ world, things get trickier.

- If a project builds a regular jar (no module descriptor or only an entry
in the Manifest), then the world still works as above.
- If a project builds a JPMS module (has a module descriptor)...
  - A dependency that has a module descriptor (module-info) normally goes
on the module path
  - A dependency that does not have a module descriptor may go onto the
module path (where it lives as an automatic module) *OR* could go on the
class path where it would be part of the unnamed module. The latter may be
necessary for dependencies that have overlapping packages.

So for any dependency, there is a default (classpath for a regular project,
module path for a project with a module descriptor) but there are
situations where that default may need to be overridden. And, what is
worse, there may be situations where overriding depends on whether it is
used for compilation or testing.

There is currently no way to communicate to maven as a user whether a given
dependency should be on the module path or the class path short of adding a
config option to a plugin that controls this. We have this scenario in
multiple places where dependency specific configuration is added to a
plugin because there is no better place.

I wonder if there is an opportunity when overhauling the POM right now, to
add a "properties bag" to each dependency. Basically


  ...
  ...
  ...
  ...
  ...
  ...




*  some-value
some-value  *

which would allow general metadata association to the dependencies.

In that scenario, I could see using e.g.


  true


or


  compile


to hint the various plugins whether a given dependency should be treated as
a module path or a classpath element.

-h

[ANN] Apache Maven Javadoc Plugin 3.6.0 released

[Henning Schmiedehausen]

The Apache Maven team is pleased to announce the release of the Apache
Maven Javadoc Plugin, version 3.6.0

The Javadoc Plugin uses the Javadoc tool to generate javadocs for the
specified project.

https://maven.apache.org/plugins/maven-javadoc-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-javadoc-plugin
  3.6.0


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-javadoc-plugin/download.cgi

Release Notes - Maven Javadoc Plugin - Version 3.6.0

** Bug
* [MJAVADOC-642] - Setting maven.javadoc.isoffline seems to have no
effect
* [MJAVADOC-701] - javadoc site is broken for projects that contain
modules
* [MJAVADOC-733] - Alternative doclet page points to an SEO spammy page
* [MJAVADOC-742] - [REGRESSION] Transitive dependencies of
docletArtifact missing
* [MJAVADOC-757] - Unresolvable link in javadoc tag with value
ResourcesBundleMojo#getAttachmentClassifier() found in ResourcesBundleMojo
* [MJAVADOC-758] - IOException --> NullPointerException in
JavadocUtil.copyResource
* [MJAVADOC-763] - JavadocReportTest.testExceptions is broken
* [MJAVADOC-767] - javadoc creates invalid --patch-module statements
* [MJAVADOC-769] - javadoc plugin can not deal with transitive filename
based modules

** Improvement
* [MJAVADOC-755] - Clean up deprecated and unpreferred methods in
JavadocUtil
* [MJAVADOC-760] - Cleanup dependency declarations as best possible
* [MJAVADOC-770] - Allow building javadoc "the old fashioned way" after
Java 8

** Task
* [MJAVADOC-743] - Drop use of deprecated localRepository mojo parameter
* [MJAVADOC-765] - Make build pass with Java 20
* [MJAVADOC-772] - Refresh download page

Enjoy,

-The Apache Maven team

[RESULT] [VOTE] Release Apache Maven Javadoc Plugin version 3.6.0

[Henning Schmiedehausen]

Hi,

The vote has passed with the following result:

+1 : henning, hboutemy, slachiewicz, cstamas, khmarbaise, sjaranowski
0 : -
-1: -

PMC quorum:  hboutemy, slachiewicz, cstamas, khmarbaise, sjaranowski

I will promote the source release zip file to Apache distribution area and
the artifacts to the central repo.

Re: [VOTE] Release Apache Maven Javadoc Plugin version 3.6.0

[Henning Schmiedehausen]

Good call. Done.

-h


On Tue, Sep 12, 2023 at 11:08 AM Elliotte Rusty Harold 
wrote:

> MJAVADOC-747 and MJAVADOC-764 are listed as blockers. Please
> reclassify these if they're not truly release blockers.
>
> On Tue, Sep 12, 2023 at 2:23 AM Henning Schmiedehausen
>  wrote:
> >
> > Hi,
> >
> > We solved 16 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317529&version=12352956
> >
> > There are still a couple of issues left in
> > JIRA:
> https://issues.apache.org/jira/projects/MJAVADOC?filter=allopenissues
> >
> > Staging repo:
> https://repository.apache.org/content/repositories/maven-1989/https://repository.apache.org/service/local/repositories/maven-1989/content/org/apache/maven/plugins/maven-javadoc-plugin/3.6.0/maven-javadoc-plugin-3.6.0-source-release.zip
> >
> > Source release checksum(s):
> > maven-javadoc-plugin-3.6.0-source-release.zip sha512:
> >
> 82fa3e3685b90225749ae884fd9ea2cb72385524e76df299c5176baed983f39a433fa29e93554e207d8ed9aaa10bb6e7b148409a865ecce1b3f40ef0cf9032d4
> >
> > Staging site:
> https://maven.apache.org/plugins-archives/maven-javadoc-plugin-LATEST/
> >
> > Guide to testing staged
> > releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
>
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Javadoc Plugin version 3.6.0

[Henning Schmiedehausen]

Interesting. Thank you for finding this. I literally followed the release
steps on
https://maven.apache.org/developers/release/maven-project-release-procedure.html
step by step. Not sure what went wrong here.

-h



On Wed, Sep 13, 2023 at 12:12 AM Hervé Boutemy 
wrote:

> +1
>
> Reproducible Build not fully ok: reference build done with JDK 17 on *nix
> with
> umask 022
>
> maven-javadoc-plugin-3.6.0-source-release.zip is the file that is not
> reproducible: it contains non-reproducible
> src/it/mrm/3rdparty/_doclet-1.0.jar
> and src/it/mrm/repository/_mjavadoc450-static.jar
> I suppose these files should not be there, they are not in Git
>
> IMHO It does not deserve to drop the release, but we should dig into why
> this
> issue is happening now, it did not happen in the previous releases
>
> Regards,
>
> Hervé
>
> Le mardi 12 septembre 2023, 08:22:43 CEST Henning Schmiedehausen a écrit :
> > Hi,
> >
> > We solved 16
> > issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=123
> > 17529&version=12352956
> >
> > There are still a couple of issues left in
> > JIRA:
> https://issues.apache.org/jira/projects/MJAVADOC?filter=allopenissues
> >
> > Staging
> > repo:
> https://repository.apache.org/content/repositories/maven-1989/https://
> >
> repository.apache.org/service/local/repositories/maven-1989/content/org/apac
> >
> he/maven/plugins/maven-javadoc-plugin/3.6.0/maven-javadoc-plugin-3.6.0-sourc
> > e-release.zip
> >
> > Source release checksum(s):
> > maven-javadoc-plugin-3.6.0-source-release.zip sha512:
> >
> 82fa3e3685b90225749ae884fd9ea2cb72385524e76df299c5176baed983f39a433fa29e9355
> > 4e207d8ed9aaa10bb6e7b148409a865ecce1b3f40ef0cf9032d4
> >
> > Staging
> > site:
> https://maven.apache.org/plugins-archives/maven-javadoc-plugin-LATEST/
> >
> > Guide to testing staged
> > releases:
> https://maven.apache.org/guides/development/guide-testing-releases.
> > html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Javadoc Plugin version 3.6.0

[Henning Schmiedehausen]

Thank you for the feedback. I am clearly rusty with apache releases (and
this is not my regular computer, as I am traveling)

On Tue, Sep 12, 2023 at 10:51 AM Tamás Cservenák 
wrote:

> Howdy,
>
> Staging repository
> https://repository.apache.org/content/repositories/maven-1989


- closed the repo, it did not close because it could not validate the
signing key. Fixed that.


>
>
> But few nits more aside of GPG signature:
> - JIRA contains one open issue (!)
>

- fixed (i split off the missing PR)


> - JIRA contains an unassigned issue, which is kinda strange (who fixed it?)
>

rusty did. :-) I fixed that.


> - not a deal breaker
> - JIRA contains several non-closed (but resolved-only) issue, we usually
> close them out - not a deal breaker
>

- fixed.


> - staging repository is in "open" state, hence is not accessible by anyone
> than you, you need to "Close" it
>

- see above. fixed it.


> - to close it, you will have your GPG signatures validation (and is where
> Slawek remark about key availability on SKS comes in, otherwise Nexus2 will
> refuse to close the repository)
>
> Due to the staging repository left in "open" state, nobody has access to
> your deployed artifacts (except you), so the vote cannot proceed.
> We get this error from repository.apache.org when trying to get to
> artifacts:
>

Understood. This should be better now.


>
> 404 - Repository "maven-1989 (staging: open)" [id=maven-1989] exists but is
> not exposed.
> Repository "maven-1989 (staging: open)" [id=maven-1989] exists but is not
> exposed.
>


Still need to push the key to the maven svn (ugh) repo.

-h



>
> TIA
> T
>
> On Tue, Sep 12, 2023 at 8:23 AM Henning Schmiedehausen <
> henn...@schmiedehausen.org> wrote:
>
> > Hi,
> >
> > We solved 16 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317529&version=12352956
> >
> > There are still a couple of issues left in
> > JIRA:
> https://issues.apache.org/jira/projects/MJAVADOC?filter=allopenissues
> >
> > Staging repo:
> >
> https://repository.apache.org/content/repositories/maven-1989/https://repository.apache.org/service/local/repositories/maven-1989/content/org/apache/maven/plugins/maven-javadoc-plugin/3.6.0/maven-javadoc-plugin-3.6.0-source-release.zip
> >
> > Source release checksum(s):
> > maven-javadoc-plugin-3.6.0-source-release.zip sha512:
> >
> >
> 82fa3e3685b90225749ae884fd9ea2cb72385524e76df299c5176baed983f39a433fa29e93554e207d8ed9aaa10bb6e7b148409a865ecce1b3f40ef0cf9032d4
> >
> > Staging site:
> > https://maven.apache.org/plugins-archives/maven-javadoc-plugin-LATEST/
> >
> > Guide to testing staged
> > releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
>

Re: [VOTE] Release Apache Maven Javadoc Plugin version 3.6.0

[Henning Schmiedehausen]

obviously my +1

-h



On Mon, Sep 11, 2023 at 11:22 PM Henning Schmiedehausen <
henn...@schmiedehausen.org> wrote:

> Hi,
>
> We solved 16 
> issues:https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317529&version=12352956
>
> There are still a couple of issues left in 
> JIRA:https://issues.apache.org/jira/projects/MJAVADOC?filter=allopenissues
>
> Staging 
> repo:https://repository.apache.org/content/repositories/maven-1989/https://repository.apache.org/service/local/repositories/maven-1989/content/org/apache/maven/plugins/maven-javadoc-plugin/3.6.0/maven-javadoc-plugin-3.6.0-source-release.zip
>
> Source release checksum(s):
> maven-javadoc-plugin-3.6.0-source-release.zip sha512: 
> 82fa3e3685b90225749ae884fd9ea2cb72385524e76df299c5176baed983f39a433fa29e93554e207d8ed9aaa10bb6e7b148409a865ecce1b3f40ef0cf9032d4
>
> Staging 
> site:https://maven.apache.org/plugins-archives/maven-javadoc-plugin-LATEST/
>
> Guide to testing staged 
> releases:https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>

[VOTE] Release Apache Maven Javadoc Plugin version 3.6.0

[Henning Schmiedehausen]

Hi,

We solved 16 
issues:https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317529&version=12352956

There are still a couple of issues left in
JIRA:https://issues.apache.org/jira/projects/MJAVADOC?filter=allopenissues

Staging 
repo:https://repository.apache.org/content/repositories/maven-1989/https://repository.apache.org/service/local/repositories/maven-1989/content/org/apache/maven/plugins/maven-javadoc-plugin/3.6.0/maven-javadoc-plugin-3.6.0-source-release.zip

Source release checksum(s):
maven-javadoc-plugin-3.6.0-source-release.zip sha512:
82fa3e3685b90225749ae884fd9ea2cb72385524e76df299c5176baed983f39a433fa29e93554e207d8ed9aaa10bb6e7b148409a865ecce1b3f40ef0cf9032d4

Staging 
site:https://maven.apache.org/plugins-archives/maven-javadoc-plugin-LATEST/

Guide to testing staged
releases:https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1

Re: Remove / reset compileSourceRoots list?

[Henning Schmiedehausen]

On Sun, Sep 3, 2023 at 11:19 PM Guillaume Nodet  wrote:

> Le sam. 2 sept. 2023 à 08:16, Henning Schmiedehausen <
> henn...@schmiedehausen.org> a écrit :
>
> > I have a mixed kotlin/java multi-module project that uses src/main/java
> for
> > the java code and src/main/kotlin for kotlin code.
> >
> > For the java-only projects, everything is fine. sourceDirectory points to
> > src/main/java, testSourceDirectory points to src/test/java.
> >
> > We activate a specific profile that turns on the kotlin compiler if
> > src/main/kotlin is present. For modules that have both kotlin and java
> > code, this works fine as well. We add src/main/kotlin to the source roots
> > and src/test/kotlin to the test roots (using the build-helper plugin).
> >
> > However, for kotlin-only projects (where no src/main/java and
> src/test/java
> > exists), we get a build warning:  "Source root doesn't exist:
> > .../src/main/java" (e.g. from the kotlin compiler).
> >
>
> Why is the kotlin compiler given a pointer to a java source root ?
> The java compiler has a property compileSourceRoots which defaults to the
> project.compileSourceRoots but that can be overridden in such cases.
> It seems the kotlin-maven-plugin has a sourceDirs property which you could
> set to only the kotlin one.
>

Yes. It's complicated. Basically, for mixed source trees, the kotlin
compiler needs to be able to read the java and the kotlin source files,
otherwise you could not write kotlin code that references java code in the
same module. See
https://kotlinlang.org/docs/maven.html#compile-kotlin-and-java-sources for
details.


>
>
> >
> > As we activate the compiler from a profile, we can not set the initial
> > sourceDirectory or testSourceDirectory (overriding those values is not
> > supported in a profile).
> >
>
> Have you tried setting those values with properties and override the
> properties in the profile ?
>

Oh, that is an interesting approach. I have not actually tried that.


>
>
> >
> > Is there a way to clear the list of source roots in the maven project? I
> > looked into the code and what the build helper does and tried using
> > project.getCompileSourceRoots().clear() which works only partially.
> >
>
> Why partially ?
>

Because it works for a bit (it seems in the same lifecycle phase) and then
a bit later, plugin execution has the old values (pre calling "clear()")
again. There is some cloning of the project element somewhere, so the
clear() call removes the directories from the cloned Project object but can
not affect the actual source.


>
>
> >
> > Is there an official way to clear / set the list of compileSourceRoots
> and
> > testSourceRoots from a plugin that can be used from a profile?
> >
>
> Not sure about that... ;-)
>

Thanks for looking into this.

-h

Re: How to fix MNG-7855 (dependencies wrongly put on class-path rather than module-path)?

[Henning Schmiedehausen]

I am not sure that we have to. I think that the discussion got derailed by
disagreement about the "automatic module name" entry in a jar.

My interpretation of JEPS-261 is, that there are only two things:

- JPMS modules, which have a module-info.class file at the root of the
implementation jar
- everything else, which are treated as "automatic modules". The entry in
the manifest controls the "automatically created name" for the module. But
they are fundamentally the same thing.

So for running the build lifecycle, there is IMHO only:

- if there is a module-info.java in any source root present, it is a JPMS
module. This should use the JPMS toolchain
- Everything else gets treated like a "legacy" java build, independent of
whether there is an automatic module name set in the jar or not or what JDK
version is used to build the artifact

Maven spends a lot of time trying to deal with corner cases and I am not
sure that we get them right.

-h





On Sun, Sep 3, 2023 at 1:58 AM Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:

> Le 2023-09-02 à 21 h 15, Henning Schmiedehausen a écrit :
>
> > This is the piece that really makes me sad. We tend to get lost in
> > "rightness" discussions and don't show pragmatism.
> In this case we have an opinion-free, objective criterion: make possible
> to pass to Java tools (java, javac, javadoc…) command-line arguments
> that work for a JPMS application. Making that task easier would be a
> bonus, but at first at least make it possible.
>
>
> >> The most urgent one in my opinion is to give control to developers
> >> about class-path versus module-path decisions.
> > I tend to agree with this, however extending the pom model is most
> > likely not a viable option.
> Recent emails about Maven 4 made me think that POM changes may be
> possible. But anyway, no matter if POM changes are accepted or not,
> there is also a need for some global option for controlling the current
> algorithm. The reason is that even if POM changes were accepted, the
> current algorithm would still be the default applied when nothing is
> specified in the POM, and that default needs to be changed.
>
>  Martin
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: How to fix MNG-7855 (dependencies wrongly put on class-path rather than module-path)?

[Henning Schmiedehausen]

On Sat, Sep 2, 2023 at 2:57 AM Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:

> Hello Henning
>
> That migration would have been impossible with Maven, so we had to
> switch to Gradle. Even then it was difficult, but it could be made much
> easier with more adequate tooling support. Discussions with Gradle
> developers about possible improvements started on GitGub issues. On
> Maven side we could improve things with small steps.


This is the piece that really makes me sad. We tend to get lost in
"rightness" discussions and don't show pragmatism.


> The most urgent one
> in my opinion is to give control to developers about class-path versus
> module-path decisions.
>

I tend to agree with this, however extending the pom model is most likely
not a viable option.

-h

Remove / reset compileSourceRoots list?

[Henning Schmiedehausen]

I have a mixed kotlin/java multi-module project that uses src/main/java for
the java code and src/main/kotlin for kotlin code.

For the java-only projects, everything is fine. sourceDirectory points to
src/main/java, testSourceDirectory points to src/test/java.

We activate a specific profile that turns on the kotlin compiler if
src/main/kotlin is present. For modules that have both kotlin and java
code, this works fine as well. We add src/main/kotlin to the source roots
and src/test/kotlin to the test roots (using the build-helper plugin).

However, for kotlin-only projects (where no src/main/java and src/test/java
exists), we get a build warning:  "Source root doesn't exist:
.../src/main/java" (e.g. from the kotlin compiler).

As we activate the compiler from a profile, we can not set the initial
sourceDirectory or testSourceDirectory (overriding those values is not
supported in a profile).

Is there a way to clear the list of source roots in the maven project? I
looked into the code and what the build helper does and tried using
project.getCompileSourceRoots().clear() which works only partially.

Is there an official way to clear / set the list of compileSourceRoots and
testSourceRoots from a plugin that can be used from a profile?

-h

Re: How to fix MNG-7855 (dependencies wrongly put on class-path rather than module-path)?

[Henning Schmiedehausen]

You will get zero participation in that case. I have one mailbox with my
mailing lists that I check from time to time. If a discussion is not there,
I will not go and look for it. Neither to a bug tracker (dozens of projects
and hundreds of issues with discussions) nor a chat system where tens of
channels ask for my attention.

-h

On Tue, Aug 29, 2023 at 4:46 AM Elliotte Rusty Harold 
wrote:

> On Mon, Aug 28, 2023 at 12:25 PM Martin Desruisseaux
>  wrote:
> >
> >  > Meta-point: it's easier to keep long term track of discussions like
> >  > this if they're in the issue tracker instead of the mailing list.
> >
> > We have https://issues.apache.org/jira/browse/MNG-7855. Should it be a
> > wiki or a GitHub discussion page instead? (whatever is more convenient
> > for developers involved in those parts of Maven).
> >
>
> The JIRA is the right place. I'm simply suggesting that this
> discussion about transitive dependencies etc. take place there instead
> of in the mailing list.
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: How to fix MNG-7855 (dependencies wrongly put on class-path rather than module-path)?

[Henning Schmiedehausen]

Hello fellow Maven & JPMS struggler!

I summarized the state of things for Jdbi here:
https://github.com/jdbi/jdbi/blob/master/JPMS-SUPPORT.md

My current belief is that there is no good path forward for projects to
transition from non-JPMS to JPMS unless you are willing to rework your
maven module structure (e.g. abandon the per-module src/main and src/test
trees, give up test scope) and even then, there are a number of problems in
the way various plugins (biggest offenders are javadoc and surefire) try to
"guess" module path / classpath scenarios (and often different within a
single maven build). Which is especially sad as JPMS is dependent on
"bottom up" transitioning where lower level projects transition first to
JPMS and projects "higher up" then follow.

For a lot of projects, the "Automatic-Module-Name in manifest" is good
enough and the pain to introduce module descriptors is so big that
incentive to move forward is limited. Looking at a large project such as
Jdbi, we theoretically *can* transition to JPMS (I have a fully working
manual build that creates project jars, test jars, executes all the tests
and creates javadoc jars), but it seems impossible to get maven to execute
the same steps as my collection of scrappy shell scripts.

We are discussing more whether silently dropping modules is acceptable
user-visible behavior than being pragmatic and creating solutions for users
to build fully modularized components.

Right now,  JPMS feels like a build afterthought that works in very few
extremely specific scenarios and your only choice is to structure your code
exactly in that scenario. I have abandoned the JPMS transition for Jdbi for
now until some of the tooling has improved.

-h

On Sat, Aug 26, 2023 at 4:10 AM Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:

> Hello all
>
> MNG-7855 [1] is a quasi-blocker issue (at least a major impediment) for
> migration to JPMS. I can try to provide a patch, but I'm not familiar
> with Maven internal and would need guidance. Another issue is that
> fixing this bug probably requires the addition of a new option, which
> would require discussion.
>
> The bug is in the way that dependencies are dispatched between
> class-path and module-path. It is based on the wrong assumption that if
> an application is not modularized, then all its dependencies must be on
> the class-path. This is not true. An application can be classical
> (non-modularized) and still have some or all its dependencies on the
> module-path. For the application, it may make no visible difference.
> However for the dependency itself, the fact that it was declared on the
> class-path or on the module-path can make a big difference. This is
> explained in the issue [1] and a "hello-world" project demonstrating
> that is at [2].
>
> On the Maven discussion mailing list, it has been suggested that the
> workaround is easy (duplicate module-info information into
> META-INF/services/) and that if a library behaves differently depending
> on whether it was specified on the class-path or on the module-path, it
> would be a library bug. I question those claims:
>
>   * A module can declare a lot of service providers (~70 in my case),
> and being forced to keep module-info and META-INF/services/ in sync
> is a risk of inconsistency.
>   * META-INF/services/ is not always equivalent to module-info. In some
> cases, there is no easy way to reproduce the same effect (e.g.
> singleton provider instances).
>   * Reflection methods do not behave in the same way depending on
> whether the library was declared on the class-path or module-path.
> More generally, the OpenJDK API contains between 100 and 200
> caller-sensitive methods. There is plenty of room for unforeseen
> behavioral differences.
>   * If the library wants to load external JAR files dynamically (after
> JVM startup), the ways to do that are totally different: with
> URLClassLoader in a class-path world, but with ModuleLayer in a
> module-path world. The differences are too large for making
> practical to support both.
>
> So workarounds for MNG-7855 are practical only in simple cases, and
> MNG-7855 can become a blocker issue in more complex applications. A
> quick and I think "behaviorally correct" fix would be to drop the check
> about whether the project is modularized or not, i.e. check only if the
> _dependency_ is modularized. This approach was discussed in Gradle as
> well [3]. But because this fix may be backward incompatible if some
> projects rely on the current behavior, we may need to make this change
> an opt-in. So we may need to discuss for a new option.
>
> A better long-term fix would be to allow developers to specify in their
>  block whether they want the dependency to be on the
> class-path or module-path. But that would require a POM model change, so
> for now I would like to contribute to a shorter-term fix with a new
> option if possible.
>
>  Thanks,
>
>

Re: [ANN] Apache Maven 4.0.0-alpha-7 released

[Henning Schmiedehausen]

The sonatype nexus staging plugin at this point seems abandoned. Last
relevant commit/release was 17 months (!) ago, they killed the bug tracker
and removed all references to JIRA from the code.

The plugin does not work well in multi-module scenarios where the last
module does not commit an artifact and sonatype is not responsive at all to
bug reports (they actively closed out any means of communication outside
their commercial offerings). I am not surprised that it has issues with
4.0.0 maven and I would not consider that maven issue but a plugin problem.

-h



On Fri, Sep 1, 2023 at 3:22 PM Justin Lee  wrote:

> I use testng and it seems to work fine, fwiw.  But I *have* noticed a
> difference in the nexus-staging-plugin: it's not autoreleasing under 4.0
> even though I have it configured to do so and does just fine under 3.9.4.
> Haven't had a chance to dig in to that one.
>
> On Sun, Aug 27, 2023 at 6:21 PM Mark Derricutt  wrote:
>
> >  On 29/06/2023 at 3:16:24 PM, Guillaume Nodet  wrote:
> >
> > > Maven 4.0.0-alpha-7 is available via
> > https://maven.apache.org/download.cgi
> > >
> >
> >
> > Interesting - I noticed over the weekend that under 4.0.0-alpha-7
> surefire
> > isn’t picking up any of my Junit 5 tests, but maven 3.9.4 is.
> >
> > I haven’t had a chance to look into this yet - but I wondered if anyone
> > else had seen anything similar?
> >
> >
> > --
> > "Great artists are extremely selfish and arrogant things" — Steven
> Wilson,
> > Porcupine Tree
> >
>

maven javadoc aggregator goals (aggregator-jar)

[Henning Schmiedehausen]

I have a large-ish project that builds JPMS "Automatic-Module-Name"
artifacts. At this point, I have the system to create per module javadocs
that use Java 9+ style (.../target/apidocs/{module.name}/module-summary.html
is the starting page).

Now I am trying to aggregate the various artifacts into a single, project
javadoc jar which contains all the modules. I tried a somewhat naive
approach, adding a new maven module to the project using "pom" as
packaging, declaring dependencies on all my maven modules and add a javadoc
configuration:




















*maven-javadoc-plugin
  javadoc-jar
aggregate-jar
package
true
false

org.jdbi:*
  
*

this does not work. The plugin never considers the build being JPMS
modularized, creates an options file with a class path only and then fails
during building the aggregation jar.

I changed the packaging of the module in which the aggregate jar is built
from pom to jar. This now creates a javadoc/apidocs/options file that uses
a module path and also patches all the modules
that are included. However, this now fails with








*MavenReportException: Error while generating Javadoc:[ERROR] Exit code:
1[ERROR] error: too many patched modules
(org.jdbi.v3.core,org.jdbi.v3.caffeine,org.jdbi.v3.cache.noop,org.jdbi.v3.testing),
use --module-source-path[ERROR] 1 error[ERROR] Command line was:
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
-J-Xmx1024m @options @packages[ERROR][ERROR] Refer to the generated Javadoc
files in '/Users/henning/code/jdbi/javadoc/target/apidocs' dir.*

At this point, I am stuck. It is not clear to me how to create an aggregate
jar correctly. I looked at the MJAVADOC-639 integration test which seems to
be similar to my first approach.

Any pointers appreciated.

-h

Re: [VOTE] Release Apache Maven Daemon 1.0-m7

[Henning Schmiedehausen]

tested my m6 regression and m7 works again.

+1

-h


On Tue, Jul 11, 2023 at 7:47 AM Guillaume Nodet  wrote:

> I've staged a candidate release at
> https://dist.apache.org/repos/dist/dev/maven/mvnd/1.0-m7/
>
> This release provides distributions based on Maven 3.9.3 and 4.0.0-alpha-7
> releases.
> The release notes are available at :
>
>
> https://github.com/apache/maven-mvnd/releases/tag/untagged-0c3daa8b506a95c908b2
>
> Please review and vote !
>
> --
> 
> Guillaume Nodet
>

Re: Gratuitous refactorings

[Henning Schmiedehausen]

This is most likely a bot "warming up" by contributing to some well-known
(high-reputation) repository. Merging those will allow them to build a
reputation for things like "sell stars for github repos".

- https://the-guild.dev/blog/judging-open-source-by-github-stars
- https://dagster.io/blog/fake-stars

Straight up "don't merge", ask the person to not send in PRs like this
(there are sometimes newbies but most likely it is a bot), if they keep
doing it, report them to GH, they actually take a dim view on this.

This is the equivalent of "me too spam" in the end times of the usenet.

-h



On Wed, Jul 5, 2023 at 6:05 AM Elliotte Rusty Harold 
wrote:

> Lately I've noticed a few random PRs from first time contributors that
> use some automated refactoring tool on our code for no obvious reason.
> Here's an example:
>
> https://github.com/apache/maven-assembly-plugin/pull/131
>
> These refactorings don't seem helpful and don't IMO improve the code in
> any way.
>
> I'm not sure what's going on here. Perhaps Maven is getting used as an
> example in a training course or class somewhere. Perhaps someone is
> evaluated on the number of Github PRs they create or get merged.
>
> I'm inclined to close these without further comment. Thoughts?
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven 4.0.0-alpha-7

[Henning Schmiedehausen]

The mail refers to -alpha-6 everywhere. but the subject says alpha-7.

-h

On Sat, Jun 24, 2023 at 3:57 AM Guillaume Nodet  wrote:

> I'm starting a new vote to release this new alpha.
>
> 67 issues solved:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12353052
>
> Staging repository:
> https://repository.apache.org/content/repositories/maven-1970
>
> Dev dist directory:
> https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-alpha-7/
>
> Source release checksums:
> apache-maven-4.0.0-alpha-6-src.zip sha512:
>
>
> bc822a381f84b156f2d5c2b59502db44ef3e8689f534913820dc0c68014e02dc75639c1990df4203d7923318d2b1668b050f452556c15eb638271e1ae3688e87
>
> apache-maven-4.0.0-alpha-6-src.tar.gz sha512:
>
>
> c7e9d13df74797163e816536e76f14c25496cdc8f13faa990bf14ce5a5669ec09cdc44dd4da866dd72d68ba9e2d8d6bdcce57110e21ecbeb8d15c50cad64430b
>
>
> Binary release checksums:
> apache-maven-4.0.0-alpha-6-bin.zip sha512:
>
>
> ec47b84cbf5dd85a8081d218bf105d4664e298d906c28f11192bf563f30087a4d898f872fc73230391579f8aa84e70bddb0ae2eabc42b53a2c574d5793ceb1a2
>
> apache-maven-4.0.0-alpha-6-bin.tar.gz sha512:
>
>
> 9959e537712167094a7909006168404c16b0788862311ef65840f5b8d3afc519e63262b064db7361bc6ef77940bed14ead5e0a59d135bcdeea83be4d9893
>
>
> Staged site:
> https://maven.apache.org/ref/4-LATEST/
>
> Draft for release notes:
> https://github.com/apache/maven-site/pull/432
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72h
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> --
> 
> Guillaume Nodet
>

Re: [VOTE] Release Apache Maven 3.9.3

[Henning Schmiedehausen]

Seems to work fine in my pipelines.

+1

The changed behavior for plugin validation should be documented; just
reading the release notes gives no clear indication what changed.

-h

(I can haz wrapper plugin and mvnd as well plz?)

On Fri, Jun 23, 2023 at 6:34 AM Tamás Cservenák  wrote:

> Howdy,
>
> We solved 22 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12353255
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1968/
>
> Dev dist directory:
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.3/
>
> Source release checksums:
> apache-maven-3.9.3-src.zip sha512:
>
> a56a9e47e70ba8e3e83ff627b76a712c7b5bda59245d23bcbc541b2358b859f699d4916b7e715c45a5c336676b8b2ab0ab472dffc045ae4db635b21f7ddcc0c2
> apache-maven-3.9.3-src.tar.gz sha512:
>
> 5511b20c36fd09a8ba7260bfa78d29bb683a04828c56e93d176768eb61cb07ab91f29db745460ce9784c84561f359497158f4c800142716d3e590ac2c333e8fb
>
> Binary release checksums:
> apache-maven-3.9.3-bin.zip sha512:
>
> fba80f4bb0429052d558959b1bfbc99984f8cb8ff59a53baae0a0874b71a2601e2805c5e557b7b59d81716a0b4b35d1b2eeccb566c40b23cc575331a4984ef6c
> apache-maven-3.9.3-bin.tar.gz sha512:
>
> 400fc5b6d000c158d5ee7937543faa06b6bda8408caa2444a9c947c21472fde0f0b64ac452b8cec8855d528c0335522ed5b6c8f77085811c7e29e1bedbb5daa2
>
> Staged site:
> https://maven.apache.org/ref/3-LATEST/
>
> Draft for release notes:
> https://github.com/apache/maven-site/pull/424
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72h
>
> [ ] +1
> [ ] +0
> [ ] -1
>

Re: Maven 3.9.x plugins verifications

[Henning Schmiedehausen]

On Fri, Jun 9, 2023 at 7:44 AM Slawomir Jaranowski 
wrote:

> In current 3.9.x we have:
>
>  - NONE, // mute validation completely (validation issue collection still
> happens, it is just not reported!)
>  - INLINE, // inline, each "internal" problem one line next to mojo
> invocation
>  - SUMMARY, // at end, list of plugin GAVs along with "internal" issues
>  - BRIEF, // synonym to SUMMARY
>  - VERBOSE // at end, list of plugin GAVs along with detailed report of ANY
> validation issues
>
> First BRIEF and SUMMARY are duplicated one should be enough.
>

Then remove SUMMARY. We shipped BRIEF in Maven 3.9.2, so it is here to
stay.

-h

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Henning Schmiedehausen]

Uhm, I have definitely gotten pushback when I ported some changes back to
the 3.8.x branch. The wording was (paraphrasing)  "maven 3.8 is dead and we
do not plan to do any further releases, so don't add code to it". This was
with Maven 3.8.4  :-)

-h

On Wed, May 31, 2023 at 3:37 AM Guillaume Nodet  wrote:

> Le mer. 31 mai 2023 à 12:28, Michael Osipov  a écrit
> :
>
> > On 2023/05/31 10:03:34 Guillaume Nodet wrote:
> > > Le mer. 31 mai 2023 à 11:21, Michael Osipov  a
> > écrit :
> > >
> > > > > I think with those improvements, requiring JDK 17 for master should
> > be
> > > > > doable.  Any concerns of suggestions ?
> > > >
> > > > I am against this. There are enough people who cannot move to Java 17
> > for
> > > > a plethora of reasons regardless of Toolchains support. We provide a
> > low
> > > > level tool and it should have a low barrier to use. Maven 4 should be
> > used
> > > > as a transitional version to 5 to cut old ties and solve many issues
> --
> > > > even if we are in alpha phase now.
> > > > I bet many people will stick for 3.9.x or even 3.8.x for the years to
> > come.
> > > >
> > >
> > > I don't get the argument here.  If people can stick with old versions
> of
> > > maven, this is actually an argument for moving the next releases
> forward,
> > > because that won't be a problem for them.
> >
> > If Maven 4 will be the only option for them since 3.x won't be maintained
> > anymore then this is a problem for many.
> >
>
> Who said so ?  If there's a need and will to maintain the 3.x branch, so be
> it.  No one is forbidden to work on those branches.
>
>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> 
> Guillaume Nodet
>

Re: [DISCUSS] Maven runtime vs artifact runtime?

[Henning Schmiedehausen]

Agreed, that is one way to do that, but it seems to me that this is a
CI/integration test issue, not a build issue per se.

We do the same thing in Jdbi: Build with the LTS JDK, then test against 8,
11, 17, current Java release:
https://github.com/jdbi/jdbi/blob/master/.github/workflows/ci.yml

Personally, I have zero interest in installing many JDKs on my laptop
(hah!) and am happy to let the CI manage those. It's its job after all. :-)

-h


On Thu, Jun 1, 2023 at 9:51 AM Tamás Cservenák  wrote:

> Howdy,
>
> define 3 Java versions in my toolchains.xml, and then add 3 executions for
> surefire like here?
>
> https://maven.apache.org/surefire/maven-surefire-plugin/examples/toolchains.html
>
> Thanks
> T
>
>
> On Thu, Jun 1, 2023 at 6:39 PM Gary Gregory 
> wrote:
>
> > I claim it is not wasteful to run unit tests on Java 8, 11, and 17, which
> > usually is the longest and most resource intensive part of a build.
> >
> > How would you do that were it not for a GitHub matrix?
> >
> > Gary
> >
> > On Thu, Jun 1, 2023, 08:01 Tamás Cservenák  wrote:
> >
> > > Howdy,
> > >
> > > From recent discussions I see an interesting pattern: it seems that
> > people
> > > (even our PMCs) are using Maven in a way that is making sure that "same
> > > Java version" (I guess vendor + version) is used from "beginning" to
> > "end".
> > >
> > > And "beginning" here means BUILDING (think workstations and CI and so
> > on),
> > > while "end" means PRODUCTION (deploying the stuff into production).
> > >
> > > Why is that?
> > >
> > > We all know that even before this "speedup" of Java releases (so to
> say,
> > up
> > > to Java 8) we did put extra effort into supporting this (running Maven
> on
> > > different Java versions and producing another bytecode output). One
> can:
> > > - use source/target compiler flags + animal sniffer (if on Java 8 or
> > older)
> > > - use release compiler flag (if Java9+ used)
> > > - use toolchains
> > >
> > > Why does any of these above "does not work" for those "aligning Java
> from
> > > beginning to end"?
> > >
> > > With today's tools like sdkman, jenv, homebrew, jbang, mvnw (and who
> > knows
> > > what) it is REALLY HARD to miss the automation of getting JDKs and
> tools
> > > (and keeping them up to date!!!) on workstations and CIs (deployment
> not
> > > counted here, but hopefully it is automated as well).
> > >
> > > Another point is that upcoming Maven 4 has tremendous improvements
> > > targeting toolchains.
> > >
> > > Finally, a bit of digression, but very much related thing: as Niels
> > > showcased on other thread in
> > > https://github.com/nielsbasjes/ToolChainsInCiBuilds
> > >
> > > The CI "matrix" build's Java version part can be moved into Maven
> itself.
> > > Personally, I always hated "matrix" as they explode very easily (size
> > wise)
> > > but in MOST cases they really just "warm the oceans" (from HB) and do
> not
> > > do anything useful. I do keep _matrix useful_ for OS variations, but to
> > > rebuild the same commit over and over with Java8, Java11, Java17 only
> to
> > > "be sure" it will work, is really an overkill (and very wasteful). The
> > > added beauty of applying this pattern is that one can perform the whole
> > > build and testing (using different Javas) even on their own
> workstations.
> > >
> > > Does Maven miss some features (aside from those above) to make it
> > possible
> > > for those "aligning" Java versions to move?
> > >
> > > Thanks
> > > T
> > >
> >
>

Re: [DISCUSS] Maven runtime vs artifact runtime?

[Henning Schmiedehausen]

I always assumed that Java versions are a solved problem in JDK 9+ with
'-release' which creates bytecode for the targeted JDK and even ensures
that no classes or methods from the JDK are used that are not supported in
that version.

There is a desire for "everything must be the same" that I am not sure I
understand. I ship a lot of open source and compile everything with "latest
LTS" to Java 8 or Java 11. I have never seen a user complain that the
resulting artifacts do not work.

So why do I need that support? I am genuinely curious. It seems that there
is something that I am missing or are too naive about. What is the problem
that toolchains (in maven or gradle) solve that I am not aware of?

-h


On Thu, Jun 1, 2023 at 5:12 AM Christoph Läubrich 
wrote:

>  > Does Maven miss some features
>
> Just look at how gradle support toolchains:
>
> https://docs.gradle.org/current/userguide/toolchains.html
>
> That's all shows what maven refuses to support and leaving people think
> its easier to use the same JVM "from beginning to end":
>
> 1) First class declarative central configuration (no need to configure
> it here and there)
> 2) automatic discovery of installed toolchains
> 3) Support for automatically download if a matching one if not found
>
> All this has nothing to do with that is is *possible* to do so in maven
> as well, it is just not *convenient* to do so and as its is not *easy*
> as well (you can just miss a thing) people are skeptical and try to "be
> sure" by using the same JVM from start-to-end...
>
>
> Am 01.06.23 um 14:00 schrieb Tamás Cservenák:
> > Howdy,
> >
> >  From recent discussions I see an interesting pattern: it seems that
> people
> > (even our PMCs) are using Maven in a way that is making sure that "same
> > Java version" (I guess vendor + version) is used from "beginning" to
> "end".
> >
> > And "beginning" here means BUILDING (think workstations and CI and so
> on),
> > while "end" means PRODUCTION (deploying the stuff into production).
> >
> > Why is that?
> >
> > We all know that even before this "speedup" of Java releases (so to say,
> up
> > to Java 8) we did put extra effort into supporting this (running Maven on
> > different Java versions and producing another bytecode output). One can:
> > - use source/target compiler flags + animal sniffer (if on Java 8 or
> older)
> > - use release compiler flag (if Java9+ used)
> > - use toolchains
> >
> > Why does any of these above "does not work" for those "aligning Java from
> > beginning to end"?
> >
> > With today's tools like sdkman, jenv, homebrew, jbang, mvnw (and who
> knows
> > what) it is REALLY HARD to miss the automation of getting JDKs and tools
> > (and keeping them up to date!!!) on workstations and CIs (deployment not
> > counted here, but hopefully it is automated as well).
> >
> > Another point is that upcoming Maven 4 has tremendous improvements
> > targeting toolchains.
> >
> > Finally, a bit of digression, but very much related thing: as Niels
> > showcased on other thread in
> > https://github.com/nielsbasjes/ToolChainsInCiBuilds
> >
> > The CI "matrix" build's Java version part can be moved into Maven itself.
> > Personally, I always hated "matrix" as they explode very easily (size
> wise)
> > but in MOST cases they really just "warm the oceans" (from HB) and do not
> > do anything useful. I do keep _matrix useful_ for OS variations, but to
> > rebuild the same commit over and over with Java8, Java11, Java17 only to
> > "be sure" it will work, is really an overkill (and very wasteful). The
> > added beauty of applying this pattern is that one can perform the whole
> > build and testing (using different Javas) even on their own workstations.
> >
> > Does Maven miss some features (aside from those above) to make it
> possible
> > for those "aligning" Java versions to move?
> >
> > Thanks
> > T
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Henning Schmiedehausen]

To get this discussion a bit more back to actual substance:

Do you still need toolchains with JDK 11/17? I set the release version to
"8" (or anything else) in my builds, ripped out all the toolchains and it
"just works". We have done this for Jdbi for ages (require Java 11+ as the
build JDK; we even enforce "latest LTS" for releases) and compile to Java 8
bytecode. So far, we had zero complaints from users that the resulting
releases do not work / cause problems on JDK 8.

It seems to me that toolchains are only relevant if you need to compile to
Java 1.6 or lower (shudder). The current LTS supports any version post-7 as
release target.

Am I missing something?

Oh, I am totally cool with Maven 4 requiring Java 17 to run. In fact, this
will give us an opportunity to actually use java 17 code to *write* maven,
which in turn will collapse all of those thousand little domain objects
into single line records. Can't wait for that. :-)

The challenge for plugin writers will be to support Maven 3.x (mostly 3.8,
3.9) and 4 evenly. The current set of available modules and libraries makes
that hard. A page with "use this to be compatible with that" would be
helpful.

-h




On Mon, Jun 5, 2023 at 2:23 PM Delany  wrote:

> Your inclination to ignore points of the debate doesn't do your own
> arguments any justice.
> Multiple times it's been explained that raising the required runtime JDK in
> Maven 4 will not prevent you from
> - building with a lower JDK (via toolchains)
> - targeting a lower JDK (via the release property)
> - building with Maven 3
>
> This is the main point of the debate, not the language.
>
> On Mon, 5 Jun 2023 at 21:42, Hunter C Payne
>  wrote:
>
> > * Attract devsAbsolutely not.  If you want to attract devs, switch to a
> > language that is actually growing (no I'm advocating for this).  That
> isn't
> > Java.  If anything, this will lose you devs.  The company I work for will
> > be leaving Maven if you stop supporting Java8.  That's 300 users you lose
> > right there.  That's just 1 company.  You will lose users in droves if
> you
> > stop Java8 support.  Many companies don't have/put enough resources into
> > this type of upgrade.  Its hard to justify to the business and it makes
> > lots of work for devs (expensive).  If it is cheaper to switch build
> > systems that to upgrade the JVM, that's exactly what folks will do.  My
> > company certainly will (not my decision so don't try to convince me, I'm
> > not the one you have to convince).
> >
> > * CDS for non-OpenJ9-usersI'm not sure this is something that is really
> > taken advantage of by Maven.  Perhaps I am wrong.
> >
> > * Better clarity of code (yes, I mean that)That you say that you actually
> > mean this says it all.  Clearly this is something that isn't agreed upon
> > universally.  Your personal taste shouldn't decide the future of a
> project
> > used by so many others.
> > * No additional work (we don't need to migrate, just use the features
> when
> > modifying a line for a bug/feature anyway)This is simply not true.  There
> > have been comments by devs on this very list, in this very discussion
> that
> > disprove this point.  It isn't OK to just ignore their input because you
> > really want to use lambdas.
> >
> > * We leave no one behind b/c of Maven 3.8/3.9, thus no drawbacks.You have
> > that backwards.   If you leave Java8, you leave behind everyone who can't
> > upgrade their source base.  It seems to me that the size of the group of
> > Java8 folks you will leave behind is quite large.  So your argument about
> > no drawbacks isn't credible.  There are no drawbacks for you, that isn't
> > the same as there being no drawbacks for the entire user base.
> > * By the time Maven 4 final is out, your views might have changed!I write
> > most of my code in Scala so I doubt it seriously.
> >
> > Your points are not nearly as strong as you imply with your tone.  Some
> of
> > them indicate a lack of understanding of some more advanced parts of FP
> > which is understandable for Java devs but doesn't make your points
> > correct.  And your analysis of the impact on the userbase is just plain
> > wrong.  If you want people to bomb this list with complains, drop Java 8
> > support and enjoy the rage postings you get from 100s to 1000s of devs
> who
> > work for companies and projects that don't have to resources to upgrade.
> >
> > Hunter
> > PS Lambdas are only useful if there is function composition and currying.
> > Java lacks both.  So the debate over lambdas is pretty amusing to me.  It
> > is just syntactic sugar.  It doesn't actually give you the ability to do
> > other things like in Scala or Kotlin.  So I don't really understand why
> you
> > want to use them so much.  Are for loops really that hard to write?  I
> mean
> > there is already so much ceremony in Java that saving 3 or 4 keystrokes
> per
> > loop doesn't really make any difference.
> >
> >
> >On Monday, June 5, 2023 at 11:52:16 AM PDT, Tamás Cservenák 

Re: [HEADS UP] Upcoming Resolver and Maven releases

[Henning Schmiedehausen]

I don't care about the threads. They are fine with me. I care about the
amount of ceremony that you create that eats into developer time. If you
want to do it for yourself: feel free to do so. It is your time after all.

But you and others then turn around and say "everyone now needs to do what
I am doing and you can no longer work the way that Apache always worked".
And I object to that.

There is value in ceremony for large, gnarly, critical changes that need
discussion. And those should be approached very carefully and slowly. But
having ceremony for a non-controversial, one line change that can be backed
out easily if needed, is ceremony for ceremonies' sake.

-h




On Wed, May 31, 2023 at 4:23 AM Tamás Cservenák  wrote:

> Henning,
>
> This intent of all threads (the "[HEADS UP]") that I have been creating
> since the 3.9.0 release was actually meant as a communication effort to
> users not on ML (btw, see related comm related discussions). What I usually
> do is copy the ponymail URL of the thread and post it on twitter or
> mastodon etc.
> People not on ML are still eager to be "in the loop", to get the news about
> 3.9.x just like you might be.
>
> While I understand your frustration about these threads (probably noise to
> you), please understand the intent behind these threads it as well.
>
> Thanks
> T
>
>
>
> On Sun, May 28, 2023 at 10:58 PM Henning Schmiedehausen <
> henn...@schmiedehausen.org> wrote:
>
> > You spend so much time on ceremony and bureaucracy by filing tickets that
> > no one is going to pick up or read and then creating pull requests that
> at
> > best will be glanced at and then "LGTM"ed.
> >
> > This is a trivial, non-controversial change that any committer can just
> > commit. Worst case scenario, someone else is going to comment on it and
> > then it can be iterated. That is how Apache has always worked and why CTR
> > is more efficient with a small team. Every committer is explicitly
> trusted
> > to work on the code base without constant "there needs to be a ticket.
> > there needs to be a PR. there needs to be a week of discussion whether
> that
> > change is good. there needs to be "approval" or "majority agreement" by
> > some star chamber that can decide what is good for the project.
> >
> > Reserve the ceremony and discussion for the large, gnarly, controversial
> > changes that warrant discussion and where there is value in doing more
> > upfront planning. But for god's sake, stop doing ceremony for ceremony's
> > sake.
> >
> > It is a literal one-liner. - https://github.com/apache/maven/pull/1132
> >
> > -h
> >
> >
> > On Fri, May 26, 2023 at 1:24 PM Tamás Cservenák 
> > wrote:
> >
> > > Howdy,
> > >
> > > good call, created https://issues.apache.org/jira/browse/MNG-7797
> > >
> > > Thanks
> > > T
> > >
> > > On Fri, May 26, 2023 at 10:09 PM Henning Schmiedehausen <
> > > henn...@schmiedehausen.org> wrote:
> > >
> > > > maven 3.9.2:
> > > >
> > > > mvn -DskipTests -Dmaven.plugin.validation=BRIEF -pl :jdbi3-core clean
> > > > install
> > > > [...]
> > > >
> > > > current 3.9.3-SNAPSHOT:
> > > >
> > > > mvn -DskipTests -Dmaven.plugin.validation=BRIEF -pl :jdbi3-core clean
> > > > install
> > > > [...]
> > > >
> > > > *[WARNING] Invalid value specified for property
> > maven.plugin.validation:
> > > > 'BRIEF'. Supported values are (case insensitive): [NONE, INLINE,
> > SUMMARY,
> > > > VERBOSE]*
> > > >
> > > > You shipped "BRIEF" in 3.9.2, removing it now breaks scripts that
> added
> > > > this to the command line or the pom.
> > > >
> > > > I suggest mapping "BRIEF" to "SUMMARY".
> > > >
> > > > -h
> > > >
> > > >
> > > > On Fri, May 26, 2023 at 12:46 AM Tamás Cservenák <
> ta...@cservenak.net>
> > > > wrote:
> > > >
> > > > > Howdy,
> > > > >
> > > > > Resolver 1.9.11 is shaping:
> > > > >
> > > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.11
> > > > >
> > > > > one resolver issue under scrutiny:
> > > > > https://issues.apache.org/jira/browse/MRESOLVER-362
> > > > >
> > > > > Maven 3.9.3 as well:
> > > > >
> > > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.3
> > > > >
> > > > > As usual, I plan these for next week, so if anyone has anything to
> > say,
> > > > > speak up!
> > > > >
> > > > > Thanks
> > > > > T
> > > > >
> > > >
> > >
> >
>

Re: [HEADS UP] Upcoming Resolver and Maven releases

[Henning Schmiedehausen]

You spend so much time on ceremony and bureaucracy by filing tickets that
no one is going to pick up or read and then creating pull requests that at
best will be glanced at and then "LGTM"ed.

This is a trivial, non-controversial change that any committer can just
commit. Worst case scenario, someone else is going to comment on it and
then it can be iterated. That is how Apache has always worked and why CTR
is more efficient with a small team. Every committer is explicitly trusted
to work on the code base without constant "there needs to be a ticket.
there needs to be a PR. there needs to be a week of discussion whether that
change is good. there needs to be "approval" or "majority agreement" by
some star chamber that can decide what is good for the project.

Reserve the ceremony and discussion for the large, gnarly, controversial
changes that warrant discussion and where there is value in doing more
upfront planning. But for god's sake, stop doing ceremony for ceremony's
sake.

It is a literal one-liner. - https://github.com/apache/maven/pull/1132

-h


On Fri, May 26, 2023 at 1:24 PM Tamás Cservenák  wrote:

> Howdy,
>
> good call, created https://issues.apache.org/jira/browse/MNG-7797
>
> Thanks
> T
>
> On Fri, May 26, 2023 at 10:09 PM Henning Schmiedehausen <
> henn...@schmiedehausen.org> wrote:
>
> > maven 3.9.2:
> >
> > mvn -DskipTests -Dmaven.plugin.validation=BRIEF -pl :jdbi3-core clean
> > install
> > [...]
> >
> > current 3.9.3-SNAPSHOT:
> >
> > mvn -DskipTests -Dmaven.plugin.validation=BRIEF -pl :jdbi3-core clean
> > install
> > [...]
> >
> > *[WARNING] Invalid value specified for property maven.plugin.validation:
> > 'BRIEF'. Supported values are (case insensitive): [NONE, INLINE, SUMMARY,
> > VERBOSE]*
> >
> > You shipped "BRIEF" in 3.9.2, removing it now breaks scripts that added
> > this to the command line or the pom.
> >
> > I suggest mapping "BRIEF" to "SUMMARY".
> >
> > -h
> >
> >
> > On Fri, May 26, 2023 at 12:46 AM Tamás Cservenák 
> > wrote:
> >
> > > Howdy,
> > >
> > > Resolver 1.9.11 is shaping:
> > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.11
> > >
> > > one resolver issue under scrutiny:
> > > https://issues.apache.org/jira/browse/MRESOLVER-362
> > >
> > > Maven 3.9.3 as well:
> > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.3
> > >
> > > As usual, I plan these for next week, so if anyone has anything to say,
> > > speak up!
> > >
> > > Thanks
> > > T
> > >
> >
>

Re: [HEADS UP] Upcoming Resolver and Maven releases

[Henning Schmiedehausen]

maven 3.9.2:

mvn -DskipTests -Dmaven.plugin.validation=BRIEF -pl :jdbi3-core clean
install
[...]

current 3.9.3-SNAPSHOT:

mvn -DskipTests -Dmaven.plugin.validation=BRIEF -pl :jdbi3-core clean
install
[...]

*[WARNING] Invalid value specified for property maven.plugin.validation:
'BRIEF'. Supported values are (case insensitive): [NONE, INLINE, SUMMARY,
VERBOSE]*

You shipped "BRIEF" in 3.9.2, removing it now breaks scripts that added
this to the command line or the pom.

I suggest mapping "BRIEF" to "SUMMARY".

-h


On Fri, May 26, 2023 at 12:46 AM Tamás Cservenák 
wrote:

> Howdy,
>
> Resolver 1.9.11 is shaping:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.11
>
> one resolver issue under scrutiny:
> https://issues.apache.org/jira/browse/MRESOLVER-362
>
> Maven 3.9.3 as well:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.3
>
> As usual, I plan these for next week, so if anyone has anything to say,
> speak up!
>
> Thanks
> T
>

Re: getting rid of Contextualizable

[Henning Schmiedehausen]

Turns out that simply removing the method and annotating the field with
`@Inject` and adding sisu-plexus solved that for me.

-h


On Sun, May 21, 2023 at 3:37 PM Henning Schmiedehausen <
henn...@schmiedehausen.org> wrote:

> I have a plugin where the mojo implements Contextualizable and it does
> this:
>
> @Override
> public void contextualize(final Context context)
> throws ContextException {
> this.container = (PlexusContainer)
> context.get(PlexusConstants.PLEXUS_KEY);
> }
>
> Basically, this gives me access to the Plexus container at the heart of
> maven. In turn, the code uses the container to look up specific,
> user-loadable components:
>
> macroType = (MacroType) container.lookup(MacroType.ROLE, ...);
>
> where "MacroType.ROLE" is a specific plexus role. There are components
> registered with the container like this:
>
> @Component(role = MacroType.class, hint = "demo")
> public class DemoMacro
> implements MacroType {
>
> If I get rid of Contextualizable, how will I get access to the container?
> Basically, I need to get my fingers on something that allows me dynamic
> lookup of components. I am fine to rewrite this to use the sisu or guice
> injectors, but right now, it does not work at all (the container is null).
>
> Googling/trawling the maven doc did not give any useful answers.
>
> -h
>
>
>
>

getting rid of Contextualizable

[Henning Schmiedehausen]

I have a plugin where the mojo implements Contextualizable and it does this:

@Override
public void contextualize(final Context context)
throws ContextException {
this.container = (PlexusContainer)
context.get(PlexusConstants.PLEXUS_KEY);
}

Basically, this gives me access to the Plexus container at the heart of
maven. In turn, the code uses the container to look up specific,
user-loadable components:

macroType = (MacroType) container.lookup(MacroType.ROLE, ...);

where "MacroType.ROLE" is a specific plexus role. There are components
registered with the container like this:

@Component(role = MacroType.class, hint = "demo")
public class DemoMacro
implements MacroType {

If I get rid of Contextualizable, how will I get access to the container?
Basically, I need to get my fingers on something that allows me dynamic
lookup of components. I am fine to rewrite this to use the sisu or guice
injectors, but right now, it does not work at all (the container is null).

Googling/trawling the maven doc did not give any useful answers.

-h

Re: maven resolver beyond 1.6.x

[Henning Schmiedehausen]

Thank you for the quick response. However, I am not sure that I got what I
needed.

Upgrading/changing maven etc. is a non-starter. This is a plugin (
https://github.com/basepom/dependency-versions-check-maven-plugin/), which
I maintain. It is supposed to be compatible with Maven 3.8.x (older
versions at your own risk. :-) ) and beyond.

Currently I use API 3.8.7 and resolver 1.6.3. I am fine to keep using this;
it contains all I need. The question was, if I upgrade the dependency here
to post-1.6, assuming that I keep using the 1.6. API footprint, will this
cause problems with users' Maven 3.8.x installation?

The plugin declares the API as "provided" as suggested, but uses the
resolver-util jar as well which is a dependency of the plugin.

I am aware of the "maven-3.8 with resolver 1.8 and 1.9 distributions" but
most (all?) users will not have that.

-h



On Sat, May 20, 2023 at 1:14 AM Michael Osipov  wrote:

> Am 2023-05-20 um 00:35 schrieb Henning Schmiedehausen:
> > Hi,
> >
> > The page on https://maven.apache.org/resolver/maven-3.8.x.html states
> > that *"Since
> > version 1.7.0, Maven Resolver requires Java 8 to run and a brand new
> > default sync context factory has been implemented."*.
> >
> > Assuming for a moment that Java 8+ is a no-brainer, what does the second
> > part of that sentence mean? If a plugin would require Java 8+ anyway (or
> > even Java 11+), would it be possible for a plugin to move past 1.6.x and
> > still be compatible with Maven 3.8.x or would using any version past
> 1.6.3
> > (we are on 1.9.x now) not work with Maven 3.8?
> >
> > I have a plugin that has resolver api in "provided" scope so it will be
> > whatever maven will inject into the plugin and the implementation itself
> is
> > in compile scope (so it will be bundled with the plugin).
>
> Short version: yes.
>
> First of all, I provide signed artifacts of Maven 3.8.x:
> *
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.x-resolver-1.9.x/
> *
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.x-resolver-1.8.x/
>
> with just Maven Resolver updated. It just works with 3.8.x
>
> Long answer: As long as your plugin uses the API from 1.6.x it can run
> with 3.8.x and above, but if there is any API change and you start to
> use it, of course you need my modified version. You can enjoy all
> benefits from 1.9.x with 3.8.x. Beware that settings done by Maven 3.9.x
> directly to Resolver do not apply here, so the 3.8.x defaults apply,
> e.g., transport and stuff.
> I will try to produce updated artifacts with Resolver 1.9.10.
>
> I must admit that 3.9.x should have been 3.10.x and 3.8.x moved to 3.9.x
> with just the Resolver and Java 8 upgrade, but that ship has sailed :-(
>
> M
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

maven resolver beyond 1.6.x

[Henning Schmiedehausen]

Hi,

The page on https://maven.apache.org/resolver/maven-3.8.x.html states
that *"Since
version 1.7.0, Maven Resolver requires Java 8 to run and a brand new
default sync context factory has been implemented."*.

Assuming for a moment that Java 8+ is a no-brainer, what does the second
part of that sentence mean? If a plugin would require Java 8+ anyway (or
even Java 11+), would it be possible for a plugin to move past 1.6.x and
still be compatible with Maven 3.8.x or would using any version past 1.6.3
(we are on 1.9.x now) not work with Maven 3.8?

I have a plugin that has resolver api in "provided" scope so it will be
whatever maven will inject into the plugin and the implementation itself is
in compile scope (so it will be bundled with the plugin).

Any pointer appreciated.

-h

Re: maven 3.9.x warnings

[Henning Schmiedehausen]

Thank you for speaking up. I would encourage others that feel the same way
to speak up as well. I do not believe that the "we ram this through and
hope that at some point all plugins are updated so the warnings die down"
is a viable approach.

This is what I wrote on the PR ("you/your" is @tamas here): *"I very much
disagree with your "my way or the highway" approach. There is a lot of
criticism with the approach to "the purpose". Of course, you can just ram
your approach through and hope for the best. It will not work, as the
changes will break older builds that people do not update and you cause
continuing pain for developers. People will be stuck on 3.9 forever because
"it is the last version that supports that unmaintained foo plugin that I
need for my build and can not move off" and grind their teeth. The answer
will be "we move off maven", not "we fix that plugin"."*

Not going where the users are or actively snubbing your users is a good way
to lose users. 3.9.x so far is a case study on focusing on the maven
developers own needs and snubbing the maven users.

-h


On Fri, May 19, 2023 at 12:33 PM Romain Manni-Bucau 
wrote:

> +1 to make NONE the default, know it defeats the purpose but this feature
> makes end user builds nasty whereas it should help them.
>
> I would also be +1 to make it a help:check-state goal rather than having it
> in maven core where it is quite pointless IMHO as explained in earlier
> threads.
>
> Le ven. 19 mai 2023 à 21:17, Henning Schmiedehausen <
> henn...@schmiedehausen.org> a écrit :
>
> > Hi Gary,
> >
> > Seems we both work in similar places. :-) Looking at
> >
> >
> https://github.com/apache/maven/commit/11d97e64e7e3fbed23d8e98abdd8c015a957ee82
> > ,
> > it seems that 3.9.3 (whenever that comes) will improve things; the
> default
> > logging is still not great but at least I can add
> > `NONE` to all my
> > projects get back to the pre-3.9.x state. @michaelo might like that as
> > well.
> >
> > @tamas I would have preferred if we did not add a "NONE" setting but made
> > the "DEFAULT" value having no logging and replaced what is "DEFAULT" in
> > 3.9.2 with "SUMMARY" or "NORMAL" or something else. That way, the default
> > state would be the same as it was with maven 3.8.x (which is IMHO the
> right
> > thing to call "default") and everyone who wants to actually log warnings
> > can turn it on.
> >
> > Adding the property above to my poms is a stop-gap, as it emits a warning
> > on pre-3.9.3 maven versions, something that I can not fix because older
> > versions of the build tool are "out there". I could put the property
> under
> > a profile but at that point it feels like fighting the tool.
> >
> > -h
> >
> > (pro-tip: Never call the value for a default setting "default". "default"
> > is a state, not a value. If you want to change the "default" state, you
> are
> > now stuck with a value called "default")
> >
> >
> >
> > On Fri, May 19, 2023 at 11:47 AM Gary Gregory 
> > wrote:
> >
> > > From this user's POV, I feel these warning force me to spin my wheels:
> > If I
> > > have old plugins I can update their versions, and then I still get the
> > > warnings, none of which I can do anything about. I can do something
> about
> > > compiler warnings, I can do nothing about these.
> > >
> > > I am left to explain up and down the food chain with hand handwaving
> why
> > > these warnings are "ok" :-(
> > >
> > > Gary
> > >
> > >
> > > On Fri, May 19, 2023, 14:15 Henning Schmiedehausen <
> > > henn...@schmiedehausen.org> wrote:
> > >
> > > > Hi Tamas,
> > > >
> > > > Thanks for the quick response.
> > > >
> > > > On Fri, May 19, 2023 at 2:35 AM Tamás Cservenák  >
> > > > wrote:
> > > >
> > > > > Howdy,
> > > > >
> > > > > So, have a small local change, probably to go with 3.9.3.
> > > > >
> > > >
> > > > [...]
> > > >
> > > >
> > > > > [WARNING]  * org.basepom.maven:inline-maven-plugin:1.0.1
> > > > > [WARNING]   Declared at location(s):
> > > > > [WARNING]* org.jdbi:jdbi3-core:3.38.3-SNAPSHOT (core/pom.xml) @
> > > line
> > > > > 145
> > > > > [WARNING]   Used in module(s):
> > > > 

Re: maven 3.9.x warnings

[Henning Schmiedehausen]

I put https://github.com/apache/maven/pull/1116 together which does exactly
that. It is literally three lines of code.

-h


On Fri, May 19, 2023 at 12:17 PM Henning Schmiedehausen <
henn...@schmiedehausen.org> wrote:

> Hi Gary,
>
> Seems we both work in similar places. :-) Looking at
> https://github.com/apache/maven/commit/11d97e64e7e3fbed23d8e98abdd8c015a957ee82,
> it seems that 3.9.3 (whenever that comes) will improve things; the default
> logging is still not great but at least I can add
> `NONE` to all my
> projects get back to the pre-3.9.x state. @michaelo might like that as well.
>
> @tamas I would have preferred if we did not add a "NONE" setting but made
> the "DEFAULT" value having no logging and replaced what is "DEFAULT" in
> 3.9.2 with "SUMMARY" or "NORMAL" or something else. That way, the default
> state would be the same as it was with maven 3.8.x (which is IMHO the right
> thing to call "default") and everyone who wants to actually log warnings
> can turn it on.
>
> Adding the property above to my poms is a stop-gap, as it emits a warning
> on pre-3.9.3 maven versions, something that I can not fix because older
> versions of the build tool are "out there". I could put the property under
> a profile but at that point it feels like fighting the tool.
>
> -h
>
> (pro-tip: Never call the value for a default setting "default". "default"
> is a state, not a value. If you want to change the "default" state, you are
> now stuck with a value called "default")
>
>
>
> On Fri, May 19, 2023 at 11:47 AM Gary Gregory 
> wrote:
>
>> From this user's POV, I feel these warning force me to spin my wheels: If
>> I
>> have old plugins I can update their versions, and then I still get the
>> warnings, none of which I can do anything about. I can do something about
>> compiler warnings, I can do nothing about these.
>>
>> I am left to explain up and down the food chain with hand handwaving why
>> these warnings are "ok" :-(
>>
>> Gary
>>
>>
>> On Fri, May 19, 2023, 14:15 Henning Schmiedehausen <
>> henn...@schmiedehausen.org> wrote:
>>
>> > Hi Tamas,
>> >
>> > Thanks for the quick response.
>> >
>> > On Fri, May 19, 2023 at 2:35 AM Tamás Cservenák 
>> > wrote:
>> >
>> > > Howdy,
>> > >
>> > > So, have a small local change, probably to go with 3.9.3.
>> > >
>> >
>> > [...]
>> >
>> >
>> > > [WARNING]  * org.basepom.maven:inline-maven-plugin:1.0.1
>> > > [WARNING]   Declared at location(s):
>> > > [WARNING]* org.jdbi:jdbi3-core:3.38.3-SNAPSHOT (core/pom.xml) @
>> line
>> > > 145
>> > > [WARNING]   Used in module(s):
>> > > [WARNING]* org.jdbi:jdbi3-core:3.38.3-SNAPSHOT (core/pom.xml)
>> > > [WARNING]   Plugin issue(s):
>> > > [WARNING]* Plugin descriptor should not contain these Maven
>> > artifacts:
>> > > [org.apache.maven:maven-artifact:3.8.4,
>> > > org.apache.maven:maven-settings-builder:3.8.4,
>> > > org.apache.maven:maven-repository-metadata:3.8.4,
>> > > org.apache.maven:maven-builder-support:3.8.4,
>> > > org.apache.maven:maven-core:3.8.4,
>> > > org.apache.maven:maven-resolver-provider:3.8.4,
>> > > org.apache.maven:maven-settings:3.8.4,
>> > > org.apache.maven:maven-plugin-api:3.8.4,
>> > > org.apache.maven:maven-model-builder:3.8.4,
>> > > org.apache.maven:maven-model:3.8.4]
>> > >
>> >
>> > This has *zero* meaning to the person running the build. And it still
>> does
>> > not help the plugin author either. Because they (I) used the maven tool
>> > chain that was current at the point in time the plugin was created.
>> There
>> > is still no actionable advice in here and there is no link to any
>> > documentation that tells a plugin author what the root cause is and
>> what to
>> > do. Developers can now either do the "update everything and pray", an
>> > approach that worked exceedingly well with maven dependencies (look at
>> all
>> > the incompatibilities with the 4.0.0-M components) or turn around to
>> the
>> > maven mailing list asking "what should I do".
>> >
>> > You need to write documentation that helps your users. All the error
>> > messages and warnings and "this is wrong, fix it" messages 

Re: maven 3.9.x warnings

[Henning Schmiedehausen]

Hi Gary,

Seems we both work in similar places. :-) Looking at
https://github.com/apache/maven/commit/11d97e64e7e3fbed23d8e98abdd8c015a957ee82,
it seems that 3.9.3 (whenever that comes) will improve things; the default
logging is still not great but at least I can add
`NONE` to all my
projects get back to the pre-3.9.x state. @michaelo might like that as well.

@tamas I would have preferred if we did not add a "NONE" setting but made
the "DEFAULT" value having no logging and replaced what is "DEFAULT" in
3.9.2 with "SUMMARY" or "NORMAL" or something else. That way, the default
state would be the same as it was with maven 3.8.x (which is IMHO the right
thing to call "default") and everyone who wants to actually log warnings
can turn it on.

Adding the property above to my poms is a stop-gap, as it emits a warning
on pre-3.9.3 maven versions, something that I can not fix because older
versions of the build tool are "out there". I could put the property under
a profile but at that point it feels like fighting the tool.

-h

(pro-tip: Never call the value for a default setting "default". "default"
is a state, not a value. If you want to change the "default" state, you are
now stuck with a value called "default")



On Fri, May 19, 2023 at 11:47 AM Gary Gregory 
wrote:

> From this user's POV, I feel these warning force me to spin my wheels: If I
> have old plugins I can update their versions, and then I still get the
> warnings, none of which I can do anything about. I can do something about
> compiler warnings, I can do nothing about these.
>
> I am left to explain up and down the food chain with hand handwaving why
> these warnings are "ok" :-(
>
> Gary
>
>
> On Fri, May 19, 2023, 14:15 Henning Schmiedehausen <
> henn...@schmiedehausen.org> wrote:
>
> > Hi Tamas,
> >
> > Thanks for the quick response.
> >
> > On Fri, May 19, 2023 at 2:35 AM Tamás Cservenák 
> > wrote:
> >
> > > Howdy,
> > >
> > > So, have a small local change, probably to go with 3.9.3.
> > >
> >
> > [...]
> >
> >
> > > [WARNING]  * org.basepom.maven:inline-maven-plugin:1.0.1
> > > [WARNING]   Declared at location(s):
> > > [WARNING]* org.jdbi:jdbi3-core:3.38.3-SNAPSHOT (core/pom.xml) @
> line
> > > 145
> > > [WARNING]   Used in module(s):
> > > [WARNING]* org.jdbi:jdbi3-core:3.38.3-SNAPSHOT (core/pom.xml)
> > > [WARNING]   Plugin issue(s):
> > > [WARNING]* Plugin descriptor should not contain these Maven
> > artifacts:
> > > [org.apache.maven:maven-artifact:3.8.4,
> > > org.apache.maven:maven-settings-builder:3.8.4,
> > > org.apache.maven:maven-repository-metadata:3.8.4,
> > > org.apache.maven:maven-builder-support:3.8.4,
> > > org.apache.maven:maven-core:3.8.4,
> > > org.apache.maven:maven-resolver-provider:3.8.4,
> > > org.apache.maven:maven-settings:3.8.4,
> > > org.apache.maven:maven-plugin-api:3.8.4,
> > > org.apache.maven:maven-model-builder:3.8.4,
> > > org.apache.maven:maven-model:3.8.4]
> > >
> >
> > This has *zero* meaning to the person running the build. And it still
> does
> > not help the plugin author either. Because they (I) used the maven tool
> > chain that was current at the point in time the plugin was created. There
> > is still no actionable advice in here and there is no link to any
> > documentation that tells a plugin author what the root cause is and what
> to
> > do. Developers can now either do the "update everything and pray", an
> > approach that worked exceedingly well with maven dependencies (look at
> all
> > the incompatibilities with the 4.0.0-M components) or turn around to
> the
> > maven mailing list asking "what should I do".
> >
> > You need to write documentation that helps your users. All the error
> > messages and warnings and "this is wrong, fix it" messages to users do
> not
> > help.
> >
> > This passive-aggressive attempt to surface problems in an obscure way to
> > the end user and hope that "they file bugs with the plugin authors" is a
> > terrible way to instigate change.
> >
> > I understand that there is limited developer time on Maven and this looks
> > tempting as the "simplest path" but all you have accomplished is reduce
> > trust. "maven suddenly reports problems that were not there before. Were
> > those always there? Are my builds still good? Do my older projects still
> > build?"
> >
> > Surfaci

Re: maven 3.9.x warnings

[Henning Schmiedehausen]

Hi Tamas,

Thanks for the quick response.

On Fri, May 19, 2023 at 2:35 AM Tamás Cservenák  wrote:

> Howdy,
>
> So, have a small local change, probably to go with 3.9.3.
>

[...]


> [WARNING]  * org.basepom.maven:inline-maven-plugin:1.0.1
> [WARNING]   Declared at location(s):
> [WARNING]* org.jdbi:jdbi3-core:3.38.3-SNAPSHOT (core/pom.xml) @ line
> 145
> [WARNING]   Used in module(s):
> [WARNING]* org.jdbi:jdbi3-core:3.38.3-SNAPSHOT (core/pom.xml)
> [WARNING]   Plugin issue(s):
> [WARNING]* Plugin descriptor should not contain these Maven artifacts:
> [org.apache.maven:maven-artifact:3.8.4,
> org.apache.maven:maven-settings-builder:3.8.4,
> org.apache.maven:maven-repository-metadata:3.8.4,
> org.apache.maven:maven-builder-support:3.8.4,
> org.apache.maven:maven-core:3.8.4,
> org.apache.maven:maven-resolver-provider:3.8.4,
> org.apache.maven:maven-settings:3.8.4,
> org.apache.maven:maven-plugin-api:3.8.4,
> org.apache.maven:maven-model-builder:3.8.4,
> org.apache.maven:maven-model:3.8.4]
>

This has *zero* meaning to the person running the build. And it still does
not help the plugin author either. Because they (I) used the maven tool
chain that was current at the point in time the plugin was created. There
is still no actionable advice in here and there is no link to any
documentation that tells a plugin author what the root cause is and what to
do. Developers can now either do the "update everything and pray", an
approach that worked exceedingly well with maven dependencies (look at all
the incompatibilities with the 4.0.0-M components) or turn around to the
maven mailing list asking "what should I do".

You need to write documentation that helps your users. All the error
messages and warnings and "this is wrong, fix it" messages to users do not
help.

This passive-aggressive attempt to surface problems in an obscure way to
the end user and hope that "they file bugs with the plugin authors" is a
terrible way to instigate change.

I understand that there is limited developer time on Maven and this looks
tempting as the "simplest path" but all you have accomplished is reduce
trust. "maven suddenly reports problems that were not there before. Were
those always there? Are my builds still good? Do my older projects still
build?"

Surfacing non-actionable warnings or errors to a non-audience is a no-no
for any user experience; this is UX 101.

For Jdbi, I still get complaints
about org.apache.maven.plugins:maven-pmd-plugin,
org.apache.maven.plugins:maven-javadoc-plugin,
org.apache.maven.plugins:maven-source-plugin,
org.apache.maven.plugins:maven-dependency-plugin.
So even the official maven plugins have not gotten this right. Of course
you can say "time heals all wounds". That is not true, because there is
attrition by people switching tools. Heck, the ASF is now running a gradle
enterprise server.

You need to turn all of these warnings *OFF* and document the existence of
the switch *and* give developer documentation what you expect plugin users
*to do*. And then evangelize that. That will get your allies (which are the
plugin authors that will *want* to fix the problems) to help you.  Not
throw out another release with slightly tweaked warnings.

Calling "maven 3.9 is about the journey to 4.0" is ridiculous. Maven 3.9 is
a, by definition, fully backwards compatible release of Apache Maven 3.x.
If you need a journey, then release Maven 4.0.0 as that stepping stone and
then 5.0 as a backwards incompatible version. Maven 4 has been in
development for many years and developer uptake will take a long time,
especially if all old builds break left and right. You may even end up
having to call it "mvn4" and not "mvn" to not break build scripts in
countless organizations.

-h


>

maven 3.9.x warnings

[Henning Schmiedehausen]

>From maven 3.9.2:

[WARNING]  * org.basepom.maven:inline-maven-plugin:1.0.1
[WARNING]   Declared at location(s):
[WARNING]* org.jdbi:jdbi3-core:3.38.3-SNAPSHOT (core/pom.xml) @ line 145
[WARNING]   Used in module(s):
[WARNING]* org.jdbi:jdbi3-core:3.38.3-SNAPSHOT (core/pom.xml)
[WARNING]   Plugin issue(s):
[WARNING]* Plugin should declare these Maven artifacts in `*provided*`
scope: [
  org.apache.maven:maven-artifact:3.8.4,
  org.apache.maven:maven-settings-builder:3.8.4,
  org.apache.maven:maven-repository-metadata:3.8.4,
  org.apache.maven:maven-builder-support:3.8.4,
  org.apache.maven:maven-core:3.8.4,
  org.apache.maven:maven-resolver-provider:3.8.4,
  org.apache.maven:maven-settings:3.8.4,
  org.apache.maven:maven-plugin-api:3.8.4,
  org.apache.maven:maven-model-builder:3.8.4,
  org.apache.maven:maven-model:3.8.4]


>From the plugin project itself, on the 1.0.1 tag:

❯ mvn dependency:list -pl :inline-maven-plugin | grep provided | sort
[...]
[INFO]org.apache.maven:maven-artifact:jar:3.8.4:*provided* -- module
maven.artifact (auto)
[INFO]org.apache.maven:maven-builder-support:jar:3.8.4:*provided* --
module maven.builder.support (auto)
[INFO]org.apache.maven:maven-core:jar:3.8.4:*provided* -- module
maven.core (auto)
[INFO]org.apache.maven:maven-model-builder:jar:3.8.4:*provided* --
module maven.model.builder (auto)
[INFO]org.apache.maven:maven-model:jar:3.8.4:*provided* -- module
maven.model (auto)
[INFO]org.apache.maven:maven-plugin-api:jar:3.8.4:*provided* -- module
maven.plugin.api (auto)
[INFO]org.apache.maven:maven-repository-metadata:jar:3.8.4:*provided*
-- module maven.repository.metadata (auto)
[INFO]org.apache.maven:maven-resolver-provider:jar:3.8.4:*provided* --
module maven.resolver.provider (auto)
[INFO]org.apache.maven:maven-settings-builder:jar:3.8.4:*provided* --
module maven.settings.builder (auto)
[INFO]org.apache.maven:maven-settings:jar:3.8.4:*provided* -- module
maven.settings (auto)
[...]

Sorry, folks, I got nothing.

Maven 3.9.2 complains that the inline plugin needs to declare
 in *provided* scope. A build user might report that to their
build engineer or report it to the plugin author.

As the plugin author, my plugin in the version 1.0.1 *DOES* declare every
single dependency that maven warns about in *provided* scope.

There is literally *nothing* that I can do. Neither as build user, nor as
build engineer, nor as plugin author.

I don't get it. What *is* the point? Really interested to learn *why* the
maven team has chosen to go down this path.

-h

Some thoughts about the maven parameter deprecation messages

[Henning Schmiedehausen]

Hi,

[I wanted to write about this for a while]

Maven has recently (3.9.x) started to log warning messages like this:

*[WARNING] Parameter 'localRepository' is deprecated core expression; Avoid
use of ArtifactRepository type. If you need access to local repository,
switch to '${repositorySystemSession}' expression and get LRM from it
instead.*

I understand that this is an attempt to get plugin developers to replace
APIs that are considered deprecated.

Here is my take on this attempt:

- The messages are shown to end users. *The end user is not the audience.*
Plugin authors are. Most end users can not do anything about these errors
but "upgrade the plugin version and hope for the best" or "file a report
with the plugin authors (see
https://issues.apache.org/jira/projects/MPMD/issues/MPMD-368 or
https://issues.apache.org/jira/browse/MCHECKSTYLE-429)"

- The messages are logged at "WARNING" level. So builds break for some
users. *This is a bad user experience.* Best case scenario: Users work
around (upgrade maven, downgrade maven, upgrade plugins, change build
system setup). Worst case scenario: Use a different build tool so you just
lost an user. Less users means fewer contributions, means less traction.
That is how projects die.

- *People need to build older code bases that use older versions of plugins*.
They want to use "the `mvn` command" which may be installed by their OS or
some packaging tool. They either experience a plethora of warnings "that
were not there before" or need to install older versions of maven manually
which is hard/impossible for many users. Spending time on "upgrading the
build system", especially for larger projects is not an option (either
skill-wise or willingness to spend time on a project that someone wants to
evaluate or try out).

- *The messages are not actionable*. There are official plugins (pmd is the
latest example) whose current version logs these errors. *There is no
workaround for end users.*

- *There is not a clear path for plugin authors on how to fix this.*
Googling for "maven localRepository deprecation" reports
https://issues.apache.org/jira/browse/MNG-7706 as the fifth or sixth link
(below the fold) which describes why this is reported but no clear recipe
like "replace this dependency with this dependency. Use this injection."
There are cryptic comments like the one on
https://issues.apache.org/jira/projects/MPMD/issues/MPMD-368 which points
at https://issues.apache.org/jira/browse/MCHECKSTYLE-429 which reads "*Recent
Maven Reporting Impl is local localRepository-free. See my doxia-2.0.0
branch as well. With the upcoming major version this will be implicitly
solved.*". Even if someone *wants* to contribute possible fixes, there is
simply not enough information. And naively replacing the dependency leads
to other errors (and probably stops working in older versions of maven).


To summarize: From my PoV, *it is a bad decision to display deprecation
messages that are intended for plugin authors to end users*. If the goal is
to get plugin authors to change their code, this is the wrong way. It feels
passive aggressive to me ("get end users to report bugs to plugins, so the
plugin authors are compelled to fix this").

Here are some suggestions:

- the vast majority of builds have been designed for maven 3.x.x and they
will keep using plugins that work with maven 3.x.x. So 3.x.x should not
display warnings in the first place.

- Removing these deprecated APIs is not an option for the 3.x.x cycle, so
why display warnings about it? Introducing this in 3.8 -> 3.9 is wrong as
there is an expectation with users that "upgrading a minor version should
just work" (Backwards compatibility).

- make it clear when things will stop working. Is that maven 4.x.x? Great.
Having 4.0.0 show these warnings may be acceptable (as this is a new major
version). Document that 4.0.0 will support them with warnings and 4.1.0
will no longer support them.

- show these warnings in the developer tooling. Every maven developer uses
the maven-plugin-plugin. Or plexus-component-metadata. Having those tools
showing warnings (or errors) makes sense, because the audience are plugin
developers and they can actually fix the problems.

- Maven could have a "lint" or "-Wall" mode under a switch. If that switch
is on, show these warnings. Otherwise, don't. The switch needs to be
documented clearly. The argument "no one will use that" does not count. If
it is documented, plugin developers will use it to find this type of
problem. Build engineers will use it to find incompatibilities.

- At the very minimum, ensure that all "official" maven plugins (the ones
on https://maven.apache.org/plugins/index.html) are all updated before
enabling this type of warning. At the very least, end users then *can* get
rid of them by upgrading. The argument "This is a lot of work and we are
only a few people that no one thanks for our hard work" is not an argument
here. If this is a problem for code that is maintained a

Re: [VOTE] Release Maven PMD Plugin version 3.21.0

[Henning Schmiedehausen]

MPMD-368 is the most user visible problem with this plugin and the next
release should contain a fix for it. I tried 3.21.0 in our internal builds
and it still shows the same behavior as 3.20.0

I abstain from voting as there is no point in voting it down and I will not
vote this release up.

-h

On Fri, May 12, 2023 at 1:30 PM Michael Osipov  wrote:

> Hi,
>
> we solved 7 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317621&version=12352863
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPMD%20AND%20resolution%20%3D%20Unresolved
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1942/
>
> https://repository.apache.org/content/repositories/maven-1942/org/apache/maven/plugins/maven-pmd-plugin/3.21.0/maven-pmd-plugin-3.21.0-source-release.zip
>
> Source release checksum(s):
> maven-pmd-plugin-3.21.0-source-release.zip
> sha512:
>
> 05cf8bf31dd96485f7dc8473e0bc02387c1ec7e39fdbace04bb82167286f6ca1cff14a2623792eb3ef8c426050151244d6d03a3c43fffd9f41024677d4297edf
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-pmd-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: artifacts and release versions

[Henning Schmiedehausen]

On Wed, Aug 31, 2022 at 3:33 AM Tamás Cservenák  wrote:

I do not understand why you felt the need to insert this into the thread,
but just to be clear.

But a word of warning to avoid any misunderstanding: Maven (and ASF AFAIK,
> at least from 2010) was always "stable = RTC".
>

To avoid any misunderstandings, *this* is the Apache Maven documentation:
https://maven.apache.org/project-roles.html

[...]
Formal roles

Committers

These are those people who have been given write access to the Apache Maven
code repository and have a signed Contributor License Agreement (CLA) on
file with the ASF.

The Apache Maven project uses a *Commit then Review policy* and has a
number of conventions which should be followed
[...]

emphasis by me. None of the conventions linked mentions anything otherwise.

-h

>
>

artifacts and release versions

[Henning Schmiedehausen]

Team,

While tackling some issues around MNG-7529, I realized that there are
specific versions that can not be used for released artifacts. Specifically
any artifact whose version is shaped like the "SNAPSHOT_TIMESTAMP" format (
see
https://github.com/apache/maven-resolver/blob/master/maven-resolver-api/src/main/java/org/eclipse/aether/artifact/AbstractArtifact.java#L39)
will be treated as a snapshot independently whether it was loaded as part
of resolving a "xxx-SNAPSHOT" artifact from a remote repository or as an
actual released artifact.

While I understand *how* that happens (
https://github.com/apache/maven-resolver/blob/master/maven-resolver-api/src/main/java/org/eclipse/aether/artifact/AbstractArtifact.java#L48
,
https://github.com/apache/maven/blob/master/maven-artifact/src/main/java/org/apache/maven/artifact/ArtifactUtils.java#L49
,
https://github.com/apache/maven/blob/master/maven-compat/src/main/java/org/apache/maven/artifact/resolver/DefaultArtifactResolver.java#L229
all assume that any version that happens to match this pattern is a
snapshot, independently whether they are released or not), I am not sure
that this is the right thing to do.

IMHO, if an artifact is resolved out of remote snapshot metadata (IAW,
doing a foo-SNAPSHOT -> resolved artifact translation (the remote repos
store versions with immutable timestamps as
//-SNAPSHOT/file--), this
translation is correct. However, if a release artifact is retrieved (which
is stored as
///file-),
this mapping is *not* correct.

I know that this is probably a quite obscure situation, however I can
easily get maven to not be able to consume release artifacts with that
specific version shape. Integration test available on request. :-)

At the very least, this limitation should be documented so that users won't
stumble upon it. The format is not really that obscure;
eight-digit-datesix-digit-timebuild-number may not be very
common but it is also not incredibly obscure.

I understand that "maven has always been that way and no one complained".
That does not mean that the behavior is correct IMHO.

-h

Re: Integration test suite

[Henning Schmiedehausen]

Hi Herve,

I saw your fix but I was wondering if just adding those two lines to the
bootstrap.txt:

+org.apache.maven.plugins:maven-dependency-plugin:3.1.1
+org.apache.maven.plugins:maven-dependency-plugin:3.3.0

wouldn't be a simpler fix. The test itself seems fine, just the deps are
missing.

-h



On Sun, Aug 21, 2022 at 11:29 PM Hervé BOUTEMY 
wrote:

> I did a first quick pass, but I fear there is an unexpected warning with m-
> antrun-p that still causes a failure: I don't time yet to fix, I need to
> leave,
> help welcome...
>
> Le lundi 22 août 2022, 07:57:31 CEST Hervé BOUTEMY a écrit :
> > uh, sorry, I overlooked that I broke the core ITs...
> >
> > looking at the error message:
> > "[ERROR] Plugin org.apache.maven.plugins:maven-dependency-plugin:3.3.0 or
> > one of its dependencies could not be resolved:
> > org.apache.maven.plugins:maven- dependency-plugin:jar:3.3.0 was not found
> > in file:target/null"
> > it seems it's the classical "disconnected ITs run" issue: let's use my
> > mistake as a training :)
> >
> > - explanations are in the "Core ITs Suite and Dependencies (incl.
> Plugins)"
> > of https://maven.apache.org/core-its/core-it-suite/
> >
> > - looking at bootstrap output, it seems maven-dependency-plugin 3.1.1 is
> > available instead of 3.3.0 => I'll update the failing ITs and it should
> be
> > solved
> >
> > Regards,
> >
> > Hervé
> >
> > Le lundi 22 août 2022, 06:50:40 CEST Henning Schmiedehausen a écrit :
> > > Folks,
> > >
> > > I am somewhat struggling to make integration tests pass for PRs. And it
> > > seems that I am not alone. Looking at
> > > https://github.com/apache/maven/commits/master, none of the merged
> commits
> > > on master has successfully passed the test suite. It seems to have
> started
> > > with the "[MNG-7353] ..." commit here:
> > >
> https://github.com/apache/maven/commit/35b93b0a589752cc88105623a2ddf9e52b5
> > > 6c 1ce
> > >
> > > The same seems to apply for the maven-3.9.x branch (
> > > https://github.com/apache/maven/commits/maven-3.9.x) - test failures
> for
> > > all commits after "[MNG-7353] ..." (
> > >
> https://github.com/apache/maven/commit/95bdbf6821d16c2b4f1df6f820600e0d4b1
> > > b9 166 )
> > >
> > > This makes it slightly difficult for me to understand if my PRs
> actually
> > > break something in maven (I am pretty sure they do not) or whether
> this is
> > > a knock on effect from other integration tests failing.  The issue may
> be
> > > with the CI setup itself; I can make the integration test suite pass
> > > locally (MacOS 12, Intel, JDK 17) for either branch.
> > >
> > > I tried to make sense of the github actions but they seem to be more
> > > complicated than I thought. I can get the test to pass locally by
> running
> > >
> > > % cd maven
> > > % mvn -PversionlessMavenDist clean install
> > > % cd ../maven-integration-testing
> > > % mvn -Prun-its clean install  -DmavenDistro=... reference to the maven
> > > folder .../apache-maven/target/apache-maven-bin.zip
> > >
> > > Grateful for any advice. Ideally the folks that wrote the gh actions
> > > (Martin, Sylwester, Maarten) or who commited that change (Hervé) could
> > > help.
> > >
> > > Thanks,
> > >
> > > Henning
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Integration test suite

[Henning Schmiedehausen]

Hi Maarten,

Thank you for the explanation! The GH actions are much more visible on Pull
Requests; I was not even aware that there is a jenkins setup (as this is
not surfaced anywhere for a PR).

It would be good to document that implicit maven /
maven-integration-testing checking; I am not actually sure that I used the
same branch names.

I see failures in the GH actions (as shown on the github project in the
actions tab). Hervé seems to have found the root cause; I can wait for him
to dig deeper into this.

-h


-h


On Mon, Aug 22, 2022 at 6:59 AM Maarten Mulders 
wrote:

> Hi all,
>
> The overall idea of the integation tests in GH Actions is this:
> 1. Check if the org/owner of the fork where the PR comes from _also_ has
> a fork of maven-integration-testing.
> 2. If so, check if they have a branch on that fork with the same name as
> the fork of maven-core.
> 3. If so, run the Maven PR against that fork.
> Otherwise, run the Maven PR against the *master* branch of
> maven-integration-testing.
>
> Having said that, I believe most of the GH Action jobs run fine. What
> indeed fails - starting at #35b93b0a - is same jobs running in ASF
> Jenkins. I believe they should do the same as GH Actions, but apparently
> they do not do the same thing. Ideally, if one fails, the other should
> fail as well.
>
> I've had a look at it and I think the main difference is that the GH
> Actions set maven.repo.local to $HOME/.m2/repository, whereas Jenkins
> does not. Would it make sense to specify maven.repo.local for GitHub
> actions, too?
>
>
> Thanks,
>
> Maarten
>
>
> On 22/08/2022 07:57, Hervé BOUTEMY wrote:
> > uh, sorry, I overlooked that I broke the core ITs...
> >
> > looking at the error message:
> > "[ERROR] Plugin org.apache.maven.plugins:maven-dependency-plugin:3.3.0
> or one
> > of its dependencies could not be resolved:
> org.apache.maven.plugins:maven-
> > dependency-plugin:jar:3.3.0 was not found in file:target/null"
> > it seems it's the classical "disconnected ITs run" issue: let's use my
> mistake
> > as a training :)
> >
> > - explanations are in the "Core ITs Suite and Dependencies (incl.
> Plugins)" of
> > https://maven.apache.org/core-its/core-it-suite/
> >
> > - looking at bootstrap output, it seems maven-dependency-plugin 3.1.1 is
> > available instead of 3.3.0 => I'll update the failing ITs and it should
> be
> > solved
> >
> > Regards,
> >
> > Hervé
> >
> > Le lundi 22 août 2022, 06:50:40 CEST Henning Schmiedehausen a écrit :
> >> Folks,
> >>
> >> I am somewhat struggling to make integration tests pass for PRs. And it
> >> seems that I am not alone. Looking at
> >> https://github.com/apache/maven/commits/master, none of the merged
> commits
> >> on master has successfully passed the test suite. It seems to have
> started
> >> with the "[MNG-7353] ..." commit here:
> >>
> https://github.com/apache/maven/commit/35b93b0a589752cc88105623a2ddf9e52b56c
> >> 1ce
> >>
> >> The same seems to apply for the maven-3.9.x branch (
> >> https://github.com/apache/maven/commits/maven-3.9.x) - test failures
> for
> >> all commits after "[MNG-7353] ..." (
> >>
> https://github.com/apache/maven/commit/95bdbf6821d16c2b4f1df6f820600e0d4b1b9
> >> 166 )
> >>
> >> This makes it slightly difficult for me to understand if my PRs actually
> >> break something in maven (I am pretty sure they do not) or whether this
> is
> >> a knock on effect from other integration tests failing.  The issue may
> be
> >> with the CI setup itself; I can make the integration test suite pass
> >> locally (MacOS 12, Intel, JDK 17) for either branch.
> >>
> >> I tried to make sense of the github actions but they seem to be more
> >> complicated than I thought. I can get the test to pass locally by
> running
> >>
> >> % cd maven
> >> % mvn -PversionlessMavenDist clean install
> >> % cd ../maven-integration-testing
> >> % mvn -Prun-its clean install  -DmavenDistro=... reference to the maven
> >> folder .../apache-maven/target/apache-maven-bin.zip
> >>
> >> Grateful for any advice. Ideally the folks that wrote the gh actions
> >> (Martin, Sylwester, Maarten) or who commited that change (Hervé) could
> help.
> >>
> >> Thanks,
> >>  Henning
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Integration test suite

[Henning Schmiedehausen]

Folks,

I am somewhat struggling to make integration tests pass for PRs. And it
seems that I am not alone. Looking at
https://github.com/apache/maven/commits/master, none of the merged commits
on master has successfully passed the test suite. It seems to have started
with the "[MNG-7353] ..." commit here:
https://github.com/apache/maven/commit/35b93b0a589752cc88105623a2ddf9e52b56c1ce

The same seems to apply for the maven-3.9.x branch (
https://github.com/apache/maven/commits/maven-3.9.x) - test failures for
all commits after "[MNG-7353] ..." (
https://github.com/apache/maven/commit/95bdbf6821d16c2b4f1df6f820600e0d4b1b9166
)

This makes it slightly difficult for me to understand if my PRs actually
break something in maven (I am pretty sure they do not) or whether this is
a knock on effect from other integration tests failing.  The issue may be
with the CI setup itself; I can make the integration test suite pass
locally (MacOS 12, Intel, JDK 17) for either branch.

I tried to make sense of the github actions but they seem to be more
complicated than I thought. I can get the test to pass locally by running

% cd maven
% mvn -PversionlessMavenDist clean install
% cd ../maven-integration-testing
% mvn -Prun-its clean install  -DmavenDistro=... reference to the maven
folder .../apache-maven/target/apache-maven-bin.zip

Grateful for any advice. Ideally the folks that wrote the gh actions
(Martin, Sylwester, Maarten) or who commited that change (Hervé) could help.

Thanks,
Henning

Re: MDEP-804 - Allow auto-ignore of all non-test scoped dependencies used only in test scope

[Henning Schmiedehausen]

rly
> broad scope.
>
> 2. All these checks are completely optional. If a project doesn't find
> these helpful, it doesn't have to use the dependencies plugin.
>
> Unless I am factually wrong about one of these claims (certainly
> possible, if so please describe exactly how with a reproducible
> example) I don't see any reason to revisit this now, and I think
> adding further flags is a bad idea. It's not only more complex. It's
> actively wrong.
>
> What developers who choose to turn on this check want is simple: warn
> about any unnecessary dependency, including dependencies whose scope
> is too broad. That's what the plugin should do, and I *think* that's
> what it currently does.
>
> On Sun, May 1, 2022 at 8:59 PM Henning Schmiedehausen
>  wrote:
> >
> > Hi,
> >
> > [I discussed this on slack with @sjaranowski, he suggested to bring this
> > conversation here ]
> >
> > The latest releases of the maven dependency plugin (3.2.0, 3.3.0)
> > introduced some changes in the way test dependencies are handled and
> > potentially flagged. Especially the "Non-test scoped test only
> dependencies
> > found" warning/error has turned into quite a problem for larger projects
> > that worked fine with the 3.1.x versions of the dependency plugin.
> >
> > 3.3.0 introduced the "ignoredNonTestScopedDependencies" exclusion list in
> > the configuration which helps to work around those problems by allowing
> > flagged dependencies to be ignored.
> >
> > The challenge with this is that retrofitting on larger projects with a
> lot
> > of dependencies now flagged either leads to a lot of very brittle
> > per-module configuration work or adding a blanket exclusion to a base pom
> > with no recourse within modules.
> >
> > I proposed therefore adding another flag to the plugin in MDEP-804. Flags
> > are useful because they can be driven out of properties which in turn can
> > be overridden on a per-module base. This e.g. allows me to set a blanket
> > policy of ignoring these problems by default and then turn that blanket
> > policy off on a per-module base and add finer grained exclusions. This
> > solves both by problems and also the issues described in MDEP-791.
> >
> > @sjaranowski pushed back a bit in the PR, questioning whether we want
> more
> > flags. What is important to me is that flags are much more useful than
> > exclusion lists, because I can drive them out of properties.
> >
> > It would be good to get some more opinions. The PR (
> > https://github.com/apache/maven-dependency-plugin/pull/211) is ready to
> go
> > in (it has integration tests). Technically, I still have my commit bit
> (and
> > I assume Maven is still CTR) but I haven't comitted to that code base
> for a
> > long time and I don't want to step on any toes.
> >
> > -h
> >
> > (Wow, this may be my first post to dev@maven in six+ years. Feels good.
> :-)
> > )
>
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

MDEP-804 - Allow auto-ignore of all non-test scoped dependencies used only in test scope

[Henning Schmiedehausen]

Hi,

[I discussed this on slack with @sjaranowski, he suggested to bring this
conversation here ]

The latest releases of the maven dependency plugin (3.2.0, 3.3.0)
introduced some changes in the way test dependencies are handled and
potentially flagged. Especially the "Non-test scoped test only dependencies
found" warning/error has turned into quite a problem for larger projects
that worked fine with the 3.1.x versions of the dependency plugin.

3.3.0 introduced the "ignoredNonTestScopedDependencies" exclusion list in
the configuration which helps to work around those problems by allowing
flagged dependencies to be ignored.

The challenge with this is that retrofitting on larger projects with a lot
of dependencies now flagged either leads to a lot of very brittle
per-module configuration work or adding a blanket exclusion to a base pom
with no recourse within modules.

I proposed therefore adding another flag to the plugin in MDEP-804. Flags
are useful because they can be driven out of properties which in turn can
be overridden on a per-module base. This e.g. allows me to set a blanket
policy of ignoring these problems by default and then turn that blanket
policy off on a per-module base and add finer grained exclusions. This
solves both by problems and also the issues described in MDEP-791.

@sjaranowski pushed back a bit in the PR, questioning whether we want more
flags. What is important to me is that flags are much more useful than
exclusion lists, because I can drive them out of properties.

It would be good to get some more opinions. The PR (
https://github.com/apache/maven-dependency-plugin/pull/211) is ready to go
in (it has integration tests). Technically, I still have my commit bit (and
I assume Maven is still CTR) but I haven't comitted to that code base for a
long time and I don't want to step on any toes.

-h

(Wow, this may be my first post to dev@maven in six+ years. Feels good. :-)
)

Re: Accessing a maven repository programatically (in 2019)

[Henning Schmiedehausen]

This repo: https://github.com/airlift/resolver  should have all you need.
The Presto engine uses it to discover and load plugins if necessary from
the local or remote repo. It uses the sonatype version of Aether, not the
current Apache Maven Artifact Resolver but my guess is that this is
straightforward to refactor.

-h


On Sat, Apr 20, 2019 at 10:16 PM Michael Lipp  wrote:

> On 2019/04/08 11:21:19, Paul Hammant  wrote:
> > There's shades of https://en.wikipedia.org/wiki/XY_problem to what you>
> > posting. I, for one, an interested in what your trying to make after
> you've>
> > solved this problem :)>
>
> It's not trivial. There is a tool called "bnd" that supports the
> development and deployment of OSGi bundles. The tool works "natively"
> with OSGi Repositories
> (
> https://osgi.org/javadoc/osgi.cmpn/7.0.0/org/osgi/service/repository/Repository.html
> ).
> There are various bnd plugins that provide "OSGi repository views" on a
> selection of artifacts from one or more maven repositories. In order to
> do this, bnd provides its own library for accessing maven repositories,
> including classes for parsing and evaluating POMs.
>
> When I started to write my own bnd plugin
> (
> https://github.com/mnlipp/de.mnl.osgi/tree/master/de.mnl.osgi.bnd.repository
> )
> I found that bnd's POM evaluation lacks some features. My first idea was
> to replace all of bnd's maven library with the "standard" maven library.
> This led to my initial question in this list. Sorry to say, but none of
> the answers really helped. I dug further through the maven API and the
> sources. Much too late I found
>
> https://lairdnelson.wordpress.com/2017/03/06/maven-and-the-project-formerly-known-as-aether/
> ,
> I wish I had found it earlier, would have saved me a lot of "digging".
> It is obviously impossible to use the "standard" maven library (or
> better "components") without a ridiculous number of (partially
> redundant) CDI libraries. (That gave me quite a different perspective on
> bnd's sleek implementation.)
>
> Having understood this, I thought about fixing the problems I had
> identified with bnd's POM handling. But somehow, it seemed ridiculous to
> maintain this non-trivial functionality twice. So what I have ended up
> with is this:
>
> https://github.com/mnlipp/de.mnl.osgi/blob/2e9246a3a1fe416c50ec3667676a95b92babe232/de.mnl.osgi.bnd.repository/src/de/mnl/osgi/bnd/maven/CompositeMavenRepository.java#L134
> . I use the "components" from the maven library and assemble them myself
> to avoid pulling in all those CDI libraries. Assembling the components,
> I found that eventually the only "repository functionality" required to
> evaluate a POM into a "Model" (using the standard maven components) is
> an implementation of "ModelResolver". I therefore provide such an
> implementation based on bnd's repository (access) classes
> (
> https://github.com/mnlipp/de.mnl.osgi/blob/bnd.repository-2.0.0/de.mnl.osgi.bnd.repository/src/de/mnl/osgi/bnd/maven/BndModelResolver.java
> ).
> Maybe I'll some day try to assemble a "standard" repository access from
> the (former) aether components. But actually, this part of bnd's maven
> library seems to work flawlessly, so my motivation is quite low. (And I
> still don't understand the aether API. It seems to duplicate a lot of
> the functionality provided by the org.apache.maven.* classes.)
>
> Is this an X/Y problem? Maybe. The question was "How can I use the maven
> libraries for (easily) accessing a maven repository?". Maybe I should
> have asked first "Is the collection of maven APIs in the various
> libraries intended to support easy access to the content of a maven
> repository?"
>
>  - Michael
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Releasing the Checkstyle Plugin

[Henning Schmiedehausen]

On Wed, Jan 21, 2015 at 11:49 PM, Dennis Lundberg  wrote:
> On Thu, Jan 22, 2015 at 5:29 AM, Hervé BOUTEMY  wrote:
>> Le mercredi 21 janvier 2015 14:44:27 Dennis Lundberg a écrit :
>>> There is some piece of code in Checkstyle 5.9 that uses Java 6+
>>> classes/methods. I don't remember where, but it isn't covered by our
>>> integration tests.
>> since our ITs use the 3 integrated rulesets, I suppose this is in a rule that
>> isn't used by these rulesets
>> Notice: the animalsniffer check you added doesn't check dependency jars full
>> content?
>
> No, and I don't think we can get that from our end. We had newer Java
> versions leaking into Apache Rat, and I solved those by adding a
> combination of animal-sniffer and enforcer plugin. But I don't think
> that can check the sources of the dependencies. It's a mystery to me
> how they managed to build Checkstyle 5.9 at all. When I check out the
> 5.9 tag from git and try to build it using Java 1.5 I get these
> errors:

Java 6 or 7 compiler with java6 rt.jar and -source 1.5 -target 1.5

Unfortunately the result does not actually work on JDK5. :-/

-h

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

Re: Releasing the dependency plugin?

[Henning Schmiedehausen]

Thanks for getting this going, I was distracted for a while. Anders,
thanks for catching that regression in time.

-h

On Sun, Jan 18, 2015 at 6:04 AM, Karl Heinz Marbaise  wrote:
> Hi,
>
> On 1/18/15 2:42 PM, Anders Hammar wrote:
>>
>> MDEP-466 [1] is the regression I was talking about. The issue has been
>> fixed in source but it requires a new release of
>> maven-dependency-analyzer.
>
>
> Ok...Than i will start VOTE for maven-dependency-analyzer...
>
> First ...
>
>
>>
>> [1] https://jira.codehaus.org/browse/MDEP-466
>>
>> /Anders
>>
>> On Sun, Jan 18, 2015 at 10:22 AM, Anders Hammar > <mailto:and...@hammar.net>> wrote:
>>
>> There's a regression in the last release that would be great to have
>> fixed as well. I'm not by a computer right now though to dig up the
>> jira.
>>
>> /Anders (mobile)
>>
>> Den 17 jan 2015 09:41 skrev "Karl Heinz Marbaise" > <mailto:khmarba...@gmx.de>>:
>>
>> Hi,
>>
>> On 1/17/15 6:16 AM, Henning Schmiedehausen wrote:
>>
>> Hi,
>>
>> any chance to do a dependency plugin release?
>>
>>
>> Just release it or special issue to be fixed ?
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

Re: Releasing the Checkstyle Plugin

[Henning Schmiedehausen]

Thanks, will do.

On Sun, Jan 18, 2015 at 8:12 AM, Dennis Lundberg  wrote:
> Henning,
>
> Please try the latest 2.14-SNAPSHOT version from the ASF repository.
> You should be able to just override the Checkstyle version by adding a
> dependency on Checkstyle 6.2 to the Maven Checkstyle Plugin in your
> project's POM.
>
> On Sat, Jan 17, 2015 at 6:39 PM, Henning Schmiedehausen
>  wrote:
>> As long as I can just drop in 6.2 and the plugin does not break (as it
>> does today), I am fine.
>>
>> We are running our own checkstyle ruleset anyway, it is just the
>> default that does not work well.
>>
>> Where are your changes, I haven't seen them on the trunk @ github.
>>
>> -h
>>
>>
>> On Sat, Jan 17, 2015 at 9:30 AM, Hervé BOUTEMY  wrote:
>>> yes, i know you did that in the branch to test upgrade for a release with
>>> Checkstyle 6.2 as default version
>>>
>>> I did it in trunk, even without changing Checkstyle version: even if maven-
>>> checkstyle-plugin ships with an older Checkstyle version as default
>>> dependency, end-users can now upgrade the dependency when using the plugin
>>>
>>> Regards,
>>>
>>> Hervé
>>>
>>>
>>> Le samedi 17 janvier 2015 09:17:08 Henning Schmiedehausen a écrit :
>>>> I already did that. See https://github.com/apache/maven-plugins/pull/42
>>>>
>>>> -h
>>>>
>>>> On Sat, Jan 17, 2015 at 9:02 AM, Hervé BOUTEMY 
>>> wrote:
>>>> > Le mercredi 14 janvier 2015 11:08:40 Henning Schmiedehausen a écrit :
>>>> >> The 6.2 checkstyle requires java 7 and it also removes (!) at least
>>>> >> one of the checks (RedundantThrows) which is used in all shipped
>>>> >> checkstyle sets and one of the integration tests. So you can no longer
>>>> >> use any of the builtin styles but have to use a custom style which has
>>>> >> the RedundantThrows check removed.
>>>> >
>>>> > the RedundantThrows check causes a lot of false positives: it is maked as
>>>> > "ingore" in Maven parent pom
>>>> > I'll remove it from default configs for next release: see MCHECKSTYLE-276
>>>> >
>>>> >> Having code that can dynamically discover whether a given check exists
>>>> >> or not and change the configuration accordingly is something that
>>>> >> probably would need to be done inside checkstyle proper, not the
>>>> >> plugin driving it.
>>>> >>
>>>> >> I have a pull request prepared (not pushed yet) which would upgrade
>>>> >> checkstyle and the build to java 7 for a possible 2.16 release. One of
>>>> >> the problems here is that at least one integration test will not pass
>>>> >> until the patch was applied to trunk (because it remote-loads the rule
>>>> >> set from the svn repo which in turn currently still has the bad rule).
>>>> >>
>>>> >> It is all a mess and prolonging it to accomodate the one hold-out on
>>>> >> Java 5 (which is EOLed for > 5 years now) and the few that insist on
>>>> >> using Java 6 (which is EOLed for ~ 2 years) makes no sense to me. We
>>>> >> should lead, not lag behind.
>>>> >>
>>>> >> -h
>>>> >>
>>>> >> On Tue, Jan 13, 2015 at 11:09 PM, Hervé BOUTEMY 
>>>> >
>>>> > wrote:
>>>> >> > question: is upgrading only a question of changing dependency version?
>>>> >> > or
>>>> >> > does it require code change?
>>>> >> > and if it requires code change, can we do it with reasonable 
>>>> >> > reflection
>>>> >> > or
>>>> >> > is it really too much change?
>>>> >> >
>>>> >> > because if we can let the end user upgrade his config (and better
>>>> >> > document), we would get the best of every choice
>>>> >> >
>>>> >> > Regards,
>>>> >> >
>>>> >> > Hervé
>>>> >> >
>>>> >> > Le mardi 13 janvier 2015 19:52:35 Henning Schmiedehausen a écrit :
>>>> >> >> I would pretty much abandon anything pre-Java 6 at this point and
>>>> >> >> start moving towards Java 7 soon. The ch

Re: Releasing the Checkstyle Plugin

[Henning Schmiedehausen]

As long as I can just drop in 6.2 and the plugin does not break (as it
does today), I am fine.

We are running our own checkstyle ruleset anyway, it is just the
default that does not work well.

Where are your changes, I haven't seen them on the trunk @ github.

-h


On Sat, Jan 17, 2015 at 9:30 AM, Hervé BOUTEMY  wrote:
> yes, i know you did that in the branch to test upgrade for a release with
> Checkstyle 6.2 as default version
>
> I did it in trunk, even without changing Checkstyle version: even if maven-
> checkstyle-plugin ships with an older Checkstyle version as default
> dependency, end-users can now upgrade the dependency when using the plugin
>
> Regards,
>
> Hervé
>
>
> Le samedi 17 janvier 2015 09:17:08 Henning Schmiedehausen a écrit :
>> I already did that. See https://github.com/apache/maven-plugins/pull/42
>>
>> -h
>>
>> On Sat, Jan 17, 2015 at 9:02 AM, Hervé BOUTEMY 
> wrote:
>> > Le mercredi 14 janvier 2015 11:08:40 Henning Schmiedehausen a écrit :
>> >> The 6.2 checkstyle requires java 7 and it also removes (!) at least
>> >> one of the checks (RedundantThrows) which is used in all shipped
>> >> checkstyle sets and one of the integration tests. So you can no longer
>> >> use any of the builtin styles but have to use a custom style which has
>> >> the RedundantThrows check removed.
>> >
>> > the RedundantThrows check causes a lot of false positives: it is maked as
>> > "ingore" in Maven parent pom
>> > I'll remove it from default configs for next release: see MCHECKSTYLE-276
>> >
>> >> Having code that can dynamically discover whether a given check exists
>> >> or not and change the configuration accordingly is something that
>> >> probably would need to be done inside checkstyle proper, not the
>> >> plugin driving it.
>> >>
>> >> I have a pull request prepared (not pushed yet) which would upgrade
>> >> checkstyle and the build to java 7 for a possible 2.16 release. One of
>> >> the problems here is that at least one integration test will not pass
>> >> until the patch was applied to trunk (because it remote-loads the rule
>> >> set from the svn repo which in turn currently still has the bad rule).
>> >>
>> >> It is all a mess and prolonging it to accomodate the one hold-out on
>> >> Java 5 (which is EOLed for > 5 years now) and the few that insist on
>> >> using Java 6 (which is EOLed for ~ 2 years) makes no sense to me. We
>> >> should lead, not lag behind.
>> >>
>> >> -h
>> >>
>> >> On Tue, Jan 13, 2015 at 11:09 PM, Hervé BOUTEMY 
>> >
>> > wrote:
>> >> > question: is upgrading only a question of changing dependency version?
>> >> > or
>> >> > does it require code change?
>> >> > and if it requires code change, can we do it with reasonable reflection
>> >> > or
>> >> > is it really too much change?
>> >> >
>> >> > because if we can let the end user upgrade his config (and better
>> >> > document), we would get the best of every choice
>> >> >
>> >> > Regards,
>> >> >
>> >> > Hervé
>> >> >
>> >> > Le mardi 13 janvier 2015 19:52:35 Henning Schmiedehausen a écrit :
>> >> >> I would pretty much abandon anything pre-Java 6 at this point and
>> >> >> start moving towards Java 7 soon. The checkstyle plugin right now has
>> >> >> three open releases with only the third being really useful ("upgrade
>> >> >> to latest checkstyle") and given the previous release cadence it makes
>> >> >> me fear that this release will not show before Mid-2015.
>> >> >>
>> >> >> -h
>> >> >>
>> >> >> On Fri, Jan 9, 2015 at 4:29 AM, Dennis Lundberg 
>> >
>> > wrote:
>> >> >> > I've started going through the open issues and have found a problem
>> >> >> > that I need som help with. It turns out that Checkstyle 5.9 uses
>> >> >> > Java
>> >> >> > 6 classes, even though it is not mentioned in the release notes. How
>> >> >> > do we want to handle this? I see two possible options:
>> >> >> >
>> >> >> > 1. Make version 2.14 of the plugin require Java 6, and update it to
>> >> >> > use the lat

Re: Releasing the dependency plugin?

[Henning Schmiedehausen]

MDEP-476 as a crucial feature that would help me a lot with the
basepom project.

-h



On Sat, Jan 17, 2015 at 12:40 AM, Karl Heinz Marbaise  wrote:
> Hi,
>
> On 1/17/15 6:16 AM, Henning Schmiedehausen wrote:
>>
>> Hi,
>>
>> any chance to do a dependency plugin release?
>
>
> Just release it or special issue to be fixed ?
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

Re: Releasing the Checkstyle Plugin

[Henning Schmiedehausen]

I already did that. See https://github.com/apache/maven-plugins/pull/42

-h

On Sat, Jan 17, 2015 at 9:02 AM, Hervé BOUTEMY  wrote:
> Le mercredi 14 janvier 2015 11:08:40 Henning Schmiedehausen a écrit :
>> The 6.2 checkstyle requires java 7 and it also removes (!) at least
>> one of the checks (RedundantThrows) which is used in all shipped
>> checkstyle sets and one of the integration tests. So you can no longer
>> use any of the builtin styles but have to use a custom style which has
>> the RedundantThrows check removed.
> the RedundantThrows check causes a lot of false positives: it is maked as
> "ingore" in Maven parent pom
> I'll remove it from default configs for next release: see MCHECKSTYLE-276
>
>>
>> Having code that can dynamically discover whether a given check exists
>> or not and change the configuration accordingly is something that
>> probably would need to be done inside checkstyle proper, not the
>> plugin driving it.
>>
>> I have a pull request prepared (not pushed yet) which would upgrade
>> checkstyle and the build to java 7 for a possible 2.16 release. One of
>> the problems here is that at least one integration test will not pass
>> until the patch was applied to trunk (because it remote-loads the rule
>> set from the svn repo which in turn currently still has the bad rule).
>>
>> It is all a mess and prolonging it to accomodate the one hold-out on
>> Java 5 (which is EOLed for > 5 years now) and the few that insist on
>> using Java 6 (which is EOLed for ~ 2 years) makes no sense to me. We
>> should lead, not lag behind.
>>
>> -h
>>
>> On Tue, Jan 13, 2015 at 11:09 PM, Hervé BOUTEMY 
> wrote:
>> > question: is upgrading only a question of changing dependency version? or
>> > does it require code change?
>> > and if it requires code change, can we do it with reasonable reflection or
>> > is it really too much change?
>> >
>> > because if we can let the end user upgrade his config (and better
>> > document), we would get the best of every choice
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> > Le mardi 13 janvier 2015 19:52:35 Henning Schmiedehausen a écrit :
>> >> I would pretty much abandon anything pre-Java 6 at this point and
>> >> start moving towards Java 7 soon. The checkstyle plugin right now has
>> >> three open releases with only the third being really useful ("upgrade
>> >> to latest checkstyle") and given the previous release cadence it makes
>> >> me fear that this release will not show before Mid-2015.
>> >>
>> >> -h
>> >>
>> >> On Fri, Jan 9, 2015 at 4:29 AM, Dennis Lundberg 
> wrote:
>> >> > I've started going through the open issues and have found a problem
>> >> > that I need som help with. It turns out that Checkstyle 5.9 uses Java
>> >> > 6 classes, even though it is not mentioned in the release notes. How
>> >> > do we want to handle this? I see two possible options:
>> >> >
>> >> > 1. Make version 2.14 of the plugin require Java 6, and update it to
>> >> > use the latest available version of Checkstyle that runs on Java 6.
>> >> >
>> >> > 2. Revert the plugin back to Checkstyle 5.8 and release 2.14 of the
>> >> > plugin with a Java 5 requirement. After that release 2.15 of the
>> >> > plugin fairly straight away with a Java 6 requirement, and using the
>> >> > latest available version of Checkstyle that runs on Java 6. It should
>> >> > be noted that Checkstyle 5.8 does NOT work on Java 8 source code.
>> >> >
>> >> > Perhaps there are other alternatives? What do you think?
>> >> >
>> >> > On Thu, Jan 8, 2015 at 3:51 PM, Dennis Lundberg 
>> >
>> > wrote:
>> >> >> Hi,
>> >> >>
>> >> >> I'd like to release version 2.14 of Maven Checkstyle Plugin. The main
>> >> >> motive for 2.14 is the ability to check Java 8 source code.
>> >> >>
>> >> >> According to the road map there are 5 unresolved issues scheduled for
>> >> >> 2.14.
>> >> >>
>> >> >> https://jira.codehaus.org/browse/MCHECKSTYLE#selectedTab=com.atlassian
>> >> >> .ji
>> >> >> ra.plugin.system.project%3Aroadmap-panel
>> >> >>
>> >> >> If anyone is interested in fixing one or more of these 

Releasing the dependency plugin?

[Henning Schmiedehausen]

Hi,

any chance to do a dependency plugin release?

Thanks,
Henning

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

Re: Releasing the Checkstyle Plugin

[Henning Schmiedehausen]

I made all the necessary changes to run out-of-the-box with 6.2 (and
have all the integration tests etc. pass) at
https://github.com/apache/maven-plugins/pull/42

Getting this out quickly would IMHO be a benefit to the whole apache
community (compared to, say lovingly maintain backwards compat to 5+
years EOLed versions of Java).

-h



On Wed, Jan 14, 2015 at 11:08 AM, Henning Schmiedehausen
 wrote:
> The 6.2 checkstyle requires java 7 and it also removes (!) at least
> one of the checks (RedundantThrows) which is used in all shipped
> checkstyle sets and one of the integration tests. So you can no longer
> use any of the builtin styles but have to use a custom style which has
> the RedundantThrows check removed.
>
> Having code that can dynamically discover whether a given check exists
> or not and change the configuration accordingly is something that
> probably would need to be done inside checkstyle proper, not the
> plugin driving it.
>
> I have a pull request prepared (not pushed yet) which would upgrade
> checkstyle and the build to java 7 for a possible 2.16 release. One of
> the problems here is that at least one integration test will not pass
> until the patch was applied to trunk (because it remote-loads the rule
> set from the svn repo which in turn currently still has the bad rule).
>
> It is all a mess and prolonging it to accomodate the one hold-out on
> Java 5 (which is EOLed for > 5 years now) and the few that insist on
> using Java 6 (which is EOLed for ~ 2 years) makes no sense to me. We
> should lead, not lag behind.
>
> -h
>
> On Tue, Jan 13, 2015 at 11:09 PM, Hervé BOUTEMY  wrote:
>> question: is upgrading only a question of changing dependency version? or 
>> does
>> it require code change?
>> and if it requires code change, can we do it with reasonable reflection or is
>> it really too much change?
>>
>> because if we can let the end user upgrade his config (and better document), 
>> we
>> would get the best of every choice
>>
>> Regards,
>>
>> Hervé
>>
>> Le mardi 13 janvier 2015 19:52:35 Henning Schmiedehausen a écrit :
>>> I would pretty much abandon anything pre-Java 6 at this point and
>>> start moving towards Java 7 soon. The checkstyle plugin right now has
>>> three open releases with only the third being really useful ("upgrade
>>> to latest checkstyle") and given the previous release cadence it makes
>>> me fear that this release will not show before Mid-2015.
>>>
>>> -h
>>>
>>> On Fri, Jan 9, 2015 at 4:29 AM, Dennis Lundberg  wrote:
>>> > I've started going through the open issues and have found a problem
>>> > that I need som help with. It turns out that Checkstyle 5.9 uses Java
>>> > 6 classes, even though it is not mentioned in the release notes. How
>>> > do we want to handle this? I see two possible options:
>>> >
>>> > 1. Make version 2.14 of the plugin require Java 6, and update it to
>>> > use the latest available version of Checkstyle that runs on Java 6.
>>> >
>>> > 2. Revert the plugin back to Checkstyle 5.8 and release 2.14 of the
>>> > plugin with a Java 5 requirement. After that release 2.15 of the
>>> > plugin fairly straight away with a Java 6 requirement, and using the
>>> > latest available version of Checkstyle that runs on Java 6. It should
>>> > be noted that Checkstyle 5.8 does NOT work on Java 8 source code.
>>> >
>>> > Perhaps there are other alternatives? What do you think?
>>> >
>>> > On Thu, Jan 8, 2015 at 3:51 PM, Dennis Lundberg 
>> wrote:
>>> >> Hi,
>>> >>
>>> >> I'd like to release version 2.14 of Maven Checkstyle Plugin. The main
>>> >> motive for 2.14 is the ability to check Java 8 source code.
>>> >>
>>> >> According to the road map there are 5 unresolved issues scheduled for
>>> >> 2.14.
>>> >>
>>> >> https://jira.codehaus.org/browse/MCHECKSTYLE#selectedTab=com.atlassian.ji
>>> >> ra.plugin.system.project%3Aroadmap-panel
>>> >>
>>> >> If anyone is interested in fixing one or more of these for 2.14 now
>>> >> would be a good time to do it. Just reply here with an estimated time
>>> >> frame. If noone has the time for this now, I'll reschedule those
>>> >> issues for 2.15, which will require Java 6.
>>> >>
>>> >> --
>>> >> Dennis Lundberg
>>> >
>>> > --
>>> > D

Re: Releasing the Checkstyle Plugin

[Henning Schmiedehausen]

The 6.2 checkstyle requires java 7 and it also removes (!) at least
one of the checks (RedundantThrows) which is used in all shipped
checkstyle sets and one of the integration tests. So you can no longer
use any of the builtin styles but have to use a custom style which has
the RedundantThrows check removed.

Having code that can dynamically discover whether a given check exists
or not and change the configuration accordingly is something that
probably would need to be done inside checkstyle proper, not the
plugin driving it.

I have a pull request prepared (not pushed yet) which would upgrade
checkstyle and the build to java 7 for a possible 2.16 release. One of
the problems here is that at least one integration test will not pass
until the patch was applied to trunk (because it remote-loads the rule
set from the svn repo which in turn currently still has the bad rule).

It is all a mess and prolonging it to accomodate the one hold-out on
Java 5 (which is EOLed for > 5 years now) and the few that insist on
using Java 6 (which is EOLed for ~ 2 years) makes no sense to me. We
should lead, not lag behind.

-h

On Tue, Jan 13, 2015 at 11:09 PM, Hervé BOUTEMY  wrote:
> question: is upgrading only a question of changing dependency version? or does
> it require code change?
> and if it requires code change, can we do it with reasonable reflection or is
> it really too much change?
>
> because if we can let the end user upgrade his config (and better document), 
> we
> would get the best of every choice
>
> Regards,
>
> Hervé
>
> Le mardi 13 janvier 2015 19:52:35 Henning Schmiedehausen a écrit :
>> I would pretty much abandon anything pre-Java 6 at this point and
>> start moving towards Java 7 soon. The checkstyle plugin right now has
>> three open releases with only the third being really useful ("upgrade
>> to latest checkstyle") and given the previous release cadence it makes
>> me fear that this release will not show before Mid-2015.
>>
>> -h
>>
>> On Fri, Jan 9, 2015 at 4:29 AM, Dennis Lundberg  wrote:
>> > I've started going through the open issues and have found a problem
>> > that I need som help with. It turns out that Checkstyle 5.9 uses Java
>> > 6 classes, even though it is not mentioned in the release notes. How
>> > do we want to handle this? I see two possible options:
>> >
>> > 1. Make version 2.14 of the plugin require Java 6, and update it to
>> > use the latest available version of Checkstyle that runs on Java 6.
>> >
>> > 2. Revert the plugin back to Checkstyle 5.8 and release 2.14 of the
>> > plugin with a Java 5 requirement. After that release 2.15 of the
>> > plugin fairly straight away with a Java 6 requirement, and using the
>> > latest available version of Checkstyle that runs on Java 6. It should
>> > be noted that Checkstyle 5.8 does NOT work on Java 8 source code.
>> >
>> > Perhaps there are other alternatives? What do you think?
>> >
>> > On Thu, Jan 8, 2015 at 3:51 PM, Dennis Lundberg 
> wrote:
>> >> Hi,
>> >>
>> >> I'd like to release version 2.14 of Maven Checkstyle Plugin. The main
>> >> motive for 2.14 is the ability to check Java 8 source code.
>> >>
>> >> According to the road map there are 5 unresolved issues scheduled for
>> >> 2.14.
>> >>
>> >> https://jira.codehaus.org/browse/MCHECKSTYLE#selectedTab=com.atlassian.ji
>> >> ra.plugin.system.project%3Aroadmap-panel
>> >>
>> >> If anyone is interested in fixing one or more of these for 2.14 now
>> >> would be a good time to do it. Just reply here with an estimated time
>> >> frame. If noone has the time for this now, I'll reschedule those
>> >> issues for 2.15, which will require Java 6.
>> >>
>> >> --
>> >> Dennis Lundberg
>> >
>> > --
>> > Dennis Lundberg
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: dev-h...@maven.apache.org
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

Re: Releasing the Checkstyle Plugin

[Henning Schmiedehausen]

I would pretty much abandon anything pre-Java 6 at this point and
start moving towards Java 7 soon. The checkstyle plugin right now has
three open releases with only the third being really useful ("upgrade
to latest checkstyle") and given the previous release cadence it makes
me fear that this release will not show before Mid-2015.

-h

On Fri, Jan 9, 2015 at 4:29 AM, Dennis Lundberg  wrote:
> I've started going through the open issues and have found a problem
> that I need som help with. It turns out that Checkstyle 5.9 uses Java
> 6 classes, even though it is not mentioned in the release notes. How
> do we want to handle this? I see two possible options:
>
> 1. Make version 2.14 of the plugin require Java 6, and update it to
> use the latest available version of Checkstyle that runs on Java 6.
>
> 2. Revert the plugin back to Checkstyle 5.8 and release 2.14 of the
> plugin with a Java 5 requirement. After that release 2.15 of the
> plugin fairly straight away with a Java 6 requirement, and using the
> latest available version of Checkstyle that runs on Java 6. It should
> be noted that Checkstyle 5.8 does NOT work on Java 8 source code.
>
> Perhaps there are other alternatives? What do you think?
>
> On Thu, Jan 8, 2015 at 3:51 PM, Dennis Lundberg  wrote:
>> Hi,
>>
>> I'd like to release version 2.14 of Maven Checkstyle Plugin. The main
>> motive for 2.14 is the ability to check Java 8 source code.
>>
>> According to the road map there are 5 unresolved issues scheduled for 2.14.
>>
>> https://jira.codehaus.org/browse/MCHECKSTYLE#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel
>>
>> If anyone is interested in fixing one or more of these for 2.14 now
>> would be a good time to do it. Just reply here with an estimated time
>> frame. If noone has the time for this now, I'll reschedule those
>> issues for 2.15, which will require Java 6.
>>
>> --
>> Dennis Lundberg
>
>
>
> --
> Dennis Lundberg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

Release plugin release?

[Henning Schmiedehausen]

Hi,

any chance to do a maven release plugin release soon? 2.4 has the annoying
regression of not being able to deploy from a local repo (fixed in
MRELEASE-818) so either getting 2.4.1 or 2.5 would be really helpful.

Thanks,
Henning

Re: [Vote #2] maven-dependency-plugin 2.7 AND maven-dependency-analyzer 1.4

[Henning Schmiedehausen]

+1 to release.

Thanks,
Henning




On Mon, Mar 11, 2013 at 9:44 AM, John Casey  wrote:

> Bump...
>
> Has this vote failed, then, or are we saying that all the +1's from the
> previous round of voting should be counted here? There is new code in this
> vote, so I'm not 100% sure that's a good idea.
>
> I can complete the release of the dependency analyzer, I guess, as that
> code has not changed.
>
> On 3/7/13 1:48 PM, John Casey wrote:
>
>> Hi,
>>
>> This vote is for the Maven dependency plugin version 2.7, which also
>> requires the release of Maven shared dependency analyzer version 1.4.
>>
>> The first vote failed due to MDEP-391. Since I had previously staged
>> both of these together, I had to redeploy the same tag for the
>> maven-dependency-analyzer to a new staging repo, then deploy the new
>> code for the maven-dependency-plugin to another staging repo. The new
>> repos are listed below.
>>
>> maven-dependency-plugin 2.7:
>> 
>>
>> We solved 7 issues: http://s.apache.org/cmZc
>>
>> The new issue from the first vote is MDEP-391.
>>
>> There are still issues left in JIRA: http://s.apache.org/N6u
>>
>>
>> maven-dependency-analyzer 1.4:
>> --
>>
>> We solved 1 issue: http://s.apache.org/48k
>>
>> There is still 1 issue left in JIRA: http://s.apache.org/ZCc
>>
>> ---
>>
>> Staging repos:
>>
>> https://repository.apache.org/**content/repositories/maven-**339/
>> https://repository.apache.org/**content/repositories/maven-**340/
>>
>> * maven-dependency-analyzer is under maven-339
>> * maven-dependency-plugin is under maven-340
>>
>>
>> Source releases:
>>
>> http://s.apache.org/mda-1.4-**src.zip 
>> (maven-dependency-analyzer 1.4)
>> http://s.apache.org/mdep-2.7-**src.zip(maven-dependency-plugin
>>  2.7)
>>
>>
>> Staging site:
>>
>> http://maven.apache.org/**shared-archives/maven-**
>> dependency-analyzer-1.4/
>> http://maven.apache.org/**plugins-archives/maven-**dependency-plugin-2.7/
>>
>> Guide to testing staged releases:
>>
>> http://maven.apache.org/**guides/development/guide-**
>> testing-releases.html
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>>
>> Here's my +1.
>>
>> -john
>>
>>
>
> --
> John Casey
> Developer, PMC Member - Apache Maven (http://maven.apache.org)
> GitHub - http://github.com/jdcasey
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@maven.apache.**org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: xdoc DTD - Do we already have a PUBLIC identifier?

[Henning Schmiedehausen]

Hi,

getting XDOC out of the maven/velocity realm and making an  "official"
format would IMHO help its visibility tremendously. That's why I
proposed to adopt it as 

-//Apache Software Foundation//DTD XDOC 1.0//EN"

and removed all the maven and velocity references from it. Having it
online is good, having it at www.apache.org/dtds with an official
location and version number (1.0) is IMHO much better.

It would also avoid "sneaking stuff in". ;-) (navbar...)

Best regards
Henning




On Fri, 2006-03-31 at 22:25 +0200, Arnaud HERITIER wrote:
> Hi, in fact it's not yet documented but the dtd is already online :
> http://maven.apache.org/maven-1.x/plugins/xdoc/maven-xdoc.dtd
> 
> cheers 
> 
> arnaud
> 
> On 3/31/06, Lukas Theussl <[EMAIL PROTECTED]> wrote:
> 
> No, there is none. The DTD is currently only available in SVN,
> it was
> added in the 1.10 version of the maven-1 xdoc plugin which is
> not
> released yet. As such, it is still work in progress, so I
> don't know if
> it's a good idea to publish it at this point. However, as far
> as I'm
> concerned, the xdoc-1.10 plugin could be released very soon,
> we will
> consider your demand as soon as it's done (please remind us if
>     we
>     forget, I know you are good at that! ;) ) 
> 
> -Lukas
> 
> 
> Henning Schmiedehausen wrote:
> > Hi,
> >
> > I finally was able to make heads and tails of the xdoc DTD
> as included
> > in the maven 1 xdoc plugin (thanks a lot for this, Lukas &
> Arnaud!) . To 
> > make XMLMind to automatically identify these files, we do
> need a DTD
> > public identifier. Do you already have one? Googling for
> this didn't
> > really help me here.
> >
> > If you don't have decided for an identifier, I'd like to
> propose: 
> >
> >  Foundation//DTD XDOC 1.0//EN"
> >
> "http://www.apache.org/dtds/xdoc_1_0.dtd";>
> >
> > as DTD identifier for the XDOC format. As I understand, we
> then must
> > make this DTD visible at the designated location, which
> needs
> > coordination with the infra people. However, putting it
> under 
> > www.apache.org means, that the mirror system will pick up
> these DTDs.
> >
> > Any opinions? If you agree, you can take a look at
> > http://wiki.apache.org/jakarta-velocity/EditXdocs
> >
> > to get my XMLMind hackery for actually editing xdocs (not
> just painfully
> > writing them... :-) ).
> >
> >   Best regards
> >   Henning 
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen  INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0   http://www.intermeta.de/

  RedHat Certified Engineer -- Jakarta Turbine Development
   Linux, Java, perl, Solaris -- Consulting, Training, Engineering

Social behaviour: Bavarians can be extremely egalitarian and folksy.
-- http://en.wikipedia.org/wiki/Bavaria
Most Franconians do not like to be called Bavarians.
-- http://en.wikipedia.org/wiki/Franconia


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: xdoc DTD - Do we already have a PUBLIC identifier?

[Henning Schmiedehausen]

On Fri, 2006-03-31 at 19:12 +, Lukas Theussl wrote:
> No, there is none. The DTD is currently only available in SVN, it was 
> added in the 1.10 version of the maven-1 xdoc plugin which is not 
> released yet. As such, it is still work in progress, so I don't know if 
> it's a good idea to publish it at this point. However, as far as I'm 
> concerned, the xdoc-1.10 plugin could be released very soon, we will 
> consider your demand as soon as it's done (please remind us if we 
> forget, I know you are good at that! ;) )

;-)

I've created MPXDOC-192, please make sure to resolve it before releasing
1.10

Best regards
        Henning



> 
> -Lukas
> 
> 
> Henning Schmiedehausen wrote:
> > Hi,
> > 
> > I finally was able to make heads and tails of the xdoc DTD as included
> > in the maven 1 xdoc plugin (thanks a lot for this, Lukas & Arnaud!) . To
> > make XMLMind to automatically identify these files, we do need a DTD
> > public identifier. Do you already have one? Googling for this didn't
> > really help me here.
> > 
> > If you don't have decided for an identifier, I'd like to propose:
> > 
> >  >   "http://www.apache.org/dtds/xdoc_1_0.dtd";>
> > 
> > as DTD identifier for the XDOC format. As I understand, we then must
> > make this DTD visible at the designated location, which needs
> > coordination with the infra people. However, putting it under
> > www.apache.org means, that the mirror system will pick up these DTDs.
> > 
> > Any opinions? If you agree, you can take a look at
> > http://wiki.apache.org/jakarta-velocity/EditXdocs
> > 
> > to get my XMLMind hackery for actually editing xdocs (not just painfully
> > writing them... :-) ).
> > 
> > Best regards
> > Henning
> > 
-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen  INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0   http://www.intermeta.de/

  RedHat Certified Engineer -- Jakarta Turbine Development
   Linux, Java, perl, Solaris -- Consulting, Training, Engineering

Social behaviour: Bavarians can be extremely egalitarian and folksy.
-- http://en.wikipedia.org/wiki/Bavaria
Most Franconians do not like to be called Bavarians.
-- http://en.wikipedia.org/wiki/Franconia


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

xdoc DTD - Do we already have a PUBLIC identifier?

[Henning Schmiedehausen]

Hi,

I finally was able to make heads and tails of the xdoc DTD as included
in the maven 1 xdoc plugin (thanks a lot for this, Lukas & Arnaud!) . To
make XMLMind to automatically identify these files, we do need a DTD
public identifier. Do you already have one? Googling for this didn't
really help me here.

If you don't have decided for an identifier, I'd like to propose:

http://www.apache.org/dtds/xdoc_1_0.dtd";>

as DTD identifier for the XDOC format. As I understand, we then must
make this DTD visible at the designated location, which needs
coordination with the infra people. However, putting it under
www.apache.org means, that the mirror system will pick up these DTDs.

Any opinions? If you agree, you can take a look at
http://wiki.apache.org/jakarta-velocity/EditXdocs

to get my XMLMind hackery for actually editing xdocs (not just painfully
writing them... :-) ).

Best regards
Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen  INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0   http://www.intermeta.de/

  RedHat Certified Engineer -- Jakarta Turbine Development
   Linux, Java, perl, Solaris -- Consulting, Training, Engineering

Social behaviour: Bavarians can be extremely egalitarian and folksy.
-- http://en.wikipedia.org/wiki/Bavaria
Most Franconians do not like to be called Bavarians.
-- http://en.wikipedia.org/wiki/Franconia


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (MPFILEACTIVITY-2) file activity plugin creates wrong links for Subversion repositories

[Henning Schmiedehausen (JIRA)]

[ 
http://jira.codehaus.org/browse/MPFILEACTIVITY-2?page=comments#action_56554 ] 

Henning Schmiedehausen commented on MPFILEACTIVITY-2:
-

Any idea on the 1.6 release date?

> file activity plugin creates wrong links for Subversion repositories
> 
>
>  Key: MPFILEACTIVITY-2
>  URL: http://jira.codehaus.org/browse/MPFILEACTIVITY-2
>  Project: maven-file-activity-plugin
> Type: Bug

> Versions: 1.5.2
> Reporter: Henning Schmiedehausen
>  Fix For: 1.6
>  Attachments: file-activity-report.html
>
>
> The maven file-activity plugin creates wrong links at 
> docs/file-activity-report.html.
> project.xml
>   
> 
> scm:svn:http://svn.apache.org/repos/asf/jakarta/turbine/core/branches/TURBINE_2_3_BRANCH
> 
> scm:svn:https://svn.apache.org/repos/asf/jakarta/turbine/core/branches/TURBINE_2_3_BRANCH
> 
> http://svn.apache.org/viewcvs/jakarta/turbine/core/branches/TURBINE_2_3_BRANCH/
>   
> results in the attached file-activity-report.html file where the links into 
> the SCM look like this:
> http://svn.apache.org/viewcvs/jakarta/turbine/core/branches/TURBINE_2_3_BRANCH//jakarta/turbine/core/branches/TURBINE_2_3_BRANCH/xdocs/changes.xml

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

maven changelog plugin issues (was: Re: Something fishy with SVN?)

[Henning Schmiedehausen]

Hi,

[removed Apache Infra, because it no longer concerns them, but added
maven-dev]

I didn't really understand the "small library" comment. Is that a
comment about commons-email needing that information or did I get it
wrong? It is not just commons-email. I only noticed the problem on
commons-email. But I'm sure, many people imported CVS trees into
Subversion and having _less_ information in my sites after doing a
conversion is not really a good thing to have.

As I wrote some times before, I do have a number of issues with the
changelog plugin:

What I would _love_ to see (especially in the light of being able to
reproduce a site build at a given time) is the ability to define a point
in time which is used for generating the changelog. Or a tag. But a
fixed point in time. 

So I can do (example, does not work):

maven.changelog.type = date
maven.changelog.lastdate = 2005-09-29
maven.changelog.range = 30

and that would produce the changelog of 30 days up to 2005-09-29. No
matter on which date I ran the changelog generation command. Same would
be great for tags:

maven.changelog.type=tag
maven.changelog.tag=RELEASE_1_0
maven.changelog.range=30

The frustrating thing here is, that most of this is already in place but
does not work as I would expect: There is the ability to give a
changelog relative to a tag but only _after_ that tag. If you want to
build a site documenting a release, you want to have information _up to_
that tag. There is range but it is not used if type is tag.

The current changelog generation is highly volatile because it considers
the "state of now()" as a part of the information which is used to
generate the changelog. This means that potentially no two changelog
generations are the same. And one can't reproduce a changelog, because
you can't go back in time. Even though there is a change log type
"date", it does not really help you because it sets the _START_ date,
not the _END_ date of the change log.

But unless you do build a site related to a current development tree and
not to a released (i.e. fixed in time) version, setting the start date
is not really interesting. Because for a release, I want to know "how
did I get to this point in time/code". For a development tree, I want to
know "How did I get to now() when I started at /?".

As a side point: For subversion, where you have unified revision numbers
and atomic commits, the ability to use a tag would be cool(because
according to the
http://maven.apache.org/reference/plugins/changelog/properties.html page
this works only for CVS anyway) but the ability to specify a revision
number (because in Subversion, tags are just 'named revisions') would be
even more useful.

On Wed, 2005-09-28 at 07:35 +1000, Brett Porter wrote:
> Someone has recently posted a workaround (patch) in Maven's JIRA. It
> gets all revisions for the repository and then only puts any in the last
> 30 days in the report. A bit too brute force for general use, but it'll
> work if you need it for a small library.

I don't think that you can do it any other way. This is a subversion
shortcoming, not a changelog plugin. If you try to use date range
checking and subversion does not deliver all the log information, you
must pull everything and pick. Unless you have a really, really long
changelog, that shouldn't really be a problem.

Best regards
Henning


> 
> - Brett
> 
> Henning Schmiedehausen wrote:
> 
> >Hi,
> >
> >ah, thanks, didn't know about that FAQ. Doesn't help me with my problems
> >as the change logs are maven driven, though. :-)
> >
> > Best regards
> > Henning
> >
> >
> >  
> >
-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen  INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0   http://www.intermeta.de/

  RedHat Certified Engineer -- Jakarta Turbine Development
   Linux, Java, perl, Solaris -- Consulting, Training, Engineering

 4 - 8 - 15 - 16 - 23 - 42


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (MPTEST-57) Customize classpath when running tests

[Henning Schmiedehausen (JIRA)]

Customize classpath when running tests
--

 Key: MPTEST-57
 URL: http://jira.codehaus.org/browse/MPTEST-57
 Project: maven-test-plugin
Type: Improvement
Versions: 1.7
 Reporter: Henning Schmiedehausen
 Attachments: classpath.patch

For some test scenarios (e.g. loading custom elements from the class path), it 
would be very convenient if one could manipulate the class path used to run the 
unit tests.

The attached patch allows a maven user to add a property

maven.test.classpath = foo.jar:bar.jar:baz.jar

to the project.properties and then the jar will be on the class path when the 
tests are run. This patch would help the Velocity project tremendously in 
running its unit tests, so please consider it for inclusion.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (MPCHANGELOG-74) changelog plugin creates wrong links for Subversion repositories

[Henning Schmiedehausen (JIRA)]

changelog plugin creates wrong links for Subversion repositories


 Key: MPCHANGELOG-74
 URL: http://jira.codehaus.org/browse/MPCHANGELOG-74
 Project: maven-changelog-plugin
Type: Bug
Versions: 1.8.2
 Reporter: Henning Schmiedehausen
 Attachments: changelog-report.html

 The maven file-activity plugin creates wrong links at 
docs/file-activity-report.html.

project.xml

  

scm:svn:http://svn.apache.org/repos/asf/jakarta/turbine/core/branches/TURBINE_2_3_BRANCH

scm:svn:https://svn.apache.org/repos/asf/jakarta/turbine/core/branches/TURBINE_2_3_BRANCH

http://svn.apache.org/viewcvs/jakarta/turbine/core/branches/TURBINE_2_3_BRANCH/
  

results in the attached changelog-report.html file where the links into the SCM 
look like this: 

http://svn.apache.org/viewcvs/jakarta/turbine/core/branches/TURBINE_2_3_BRANCH//jakarta/turbine/core/branches/TURBINE_2_3_BRANCH/project.xml

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (MPFILEACTIVITY-2) file activity plugin creates wrong links for Subversion repositories

[Henning Schmiedehausen (JIRA)]

file activity plugin creates wrong links for Subversion repositories


 Key: MPFILEACTIVITY-2
 URL: http://jira.codehaus.org/browse/MPFILEACTIVITY-2
 Project: maven-file-activity-plugin
Type: Bug
Versions: 1.5.2
 Reporter: Henning Schmiedehausen
 Attachments: file-activity-report.html

The maven file-activity plugin creates wrong links at 
docs/file-activity-report.html.

project.xml

  

scm:svn:http://svn.apache.org/repos/asf/jakarta/turbine/core/branches/TURBINE_2_3_BRANCH

scm:svn:https://svn.apache.org/repos/asf/jakarta/turbine/core/branches/TURBINE_2_3_BRANCH

http://svn.apache.org/viewcvs/jakarta/turbine/core/branches/TURBINE_2_3_BRANCH/
  

results in the attached file-activity-report.html file where the links into the 
SCM look like this:

http://svn.apache.org/viewcvs/jakarta/turbine/core/branches/TURBINE_2_3_BRANCH//jakarta/turbine/core/branches/TURBINE_2_3_BRANCH/xdocs/changes.xml


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (MAVENUPLOAD-522) Please update POM for javax.mail

[Henning Schmiedehausen (JIRA)]

Please update POM for javax.mail


 Key: MAVENUPLOAD-522
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-522
 Project: maven-upload-requests
Type: Wish
 Reporter: Henning Schmiedehausen


javamail 1.3.3 is out:


  4.0.0
  javamail
  mail
  1.3.3
  

  javax.activation
  activation
  1.0.2
  compile

  


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (MAVENUPLOAD-521) Please create POM for javax.naming

[Henning Schmiedehausen (JIRA)]

Please create POM for javax.naming
--

 Key: MAVENUPLOAD-521
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-521
 Project: maven-upload-requests
Type: Wish
 Reporter: Henning Schmiedehausen


Like some other POMs (javax.mail, javax.sql), javax.naming describes an 
additional jar that cannot currently be distributed through ibiblio. However, 
having a POM there, would help projects that consider moving to m2 but use this 
jar.


  4.0.0
  javax.naming
  jndi
  1.2.1


would be fine.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (MAVEN-1690) maven 1.1 beta 2 confuses class loaders while compiling plugin-genererated code

[Henning Schmiedehausen (JIRA)]

maven 1.1 beta 2 confuses class loaders while compiling plugin-genererated code
---

 Key: MAVEN-1690
 URL: http://jira.codehaus.org/browse/MAVEN-1690
 Project: Maven
Type: Bug
  Components: core  
Versions: 1.1-beta-2
 Environment: java version "1.4.2_09"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_09-b05)
Java HotSpot(TM) Client VM (build 1.4.2_09-b05, mixed mode)

Fedora Core 3 Linux on x86

 Reporter: Henning Schmiedehausen
Priority: Critical
 Attachments: maventest.tar.gz

This is a bit complicated to describe, so I've prepared an example to provoke 
this bug.

- Unpack the attached maventest.tar.gz
- install the Torque Plugin into your maven by running
  maven -DartifactId=maven-torque-plugin -DgroupId=torque -Dversion=3.1.1 
plugin:download

% cd maventest ; maven -q java:compile
build:start:

java:prepare-filesystem:
[mkdir] Created dir: /home/henning/scratch/test/maventest/target/classes

java:compile:
build-om:
torque:init:

BUILD FAILED
File.. /home/henning/.maven/cache/maven-torque-plugin-3.1.1/plugin.jelly
Element... taskdef
Line.. 87
Column -1
taskdef A class needed by class org.apache.torque.task.TorqueJDBCTransformTask 
cannot be found: org/apache/xerces/dom/CoreDocumentImpl

The missing class is inside the xerces jar, which is put on the classpath by 
the torque plugin (see 
http://svn.apache.org/viewcvs.cgi/db/torque/maven-plugin/trunk/plugin.jelly?rev=239621&view=markup,
 the torque:init task defines the classpath exactly as described on 
http://maven.apache.org/faq.html#classloader-property)

Funnily enough, the "jar:jar" task, which runs java:compile as a prerequisite 
works:

% cd maventest ; rm -rf target ; maven -q jar:jar
build:start:

java:prepare-filesystem:
[mkdir] Created dir: /home/henning/scratch/test/maventest/target/classes

java:compile:
build-om:
torque:init:

torque:om-check:

torque:om:
torque:init:
Overriding previous definition of reference to torque-classpath

torque:om-generate:
Using contextProperties file: 
/home/henning/scratch/test/maventest/project.properties
[torque-data-model] Using classpath
[torque-data-model] Generating to file 
/home/henning/scratch/test/maventest/target/src/report.test.om.generation



Overriding previous definition of reference to maven.compile.src.set
[echo] Compiling to /home/henning/scratch/test/maventest/target/classes
[echo]
==

  NOTE: Targetting JVM 1.4, classes
  will not run on earlier JVMs

==

[javac] Compiling 5 source files to 
/home/henning/scratch/test/maventest/target/classes
[javac] Note: 
/home/henning/scratch/test/maventest/target/src/org/test/BaseJobEntryPeer.java 
uses or overrides a deprecated API.
[javac] Note: Recompile with -deprecation for details.

java:jar-resources:

test:prepare-filesystem:
[mkdir] Created dir: 
/home/henning/scratch/test/maventest/target/test-classes
[mkdir] Created dir: 
/home/henning/scratch/test/maventest/target/test-reports

test:test-resources:

test:compile:
[echo] No test source files to compile.

test:test:
[echo] No tests to run.

jar:jar:
[jar] Building jar: /home/henning/scratch/test/maventest/target/test-1.0.jar

% jar tvf target/test-1.0.jar
0 Tue Sep 13 22:28:48 CEST 2005 META-INF/
   280 Tue Sep 13 22:28:46 CEST 2005 META-INF/MANIFEST.MF
 0 Tue Sep 13 22:28:48 CEST 2005 org/
 0 Tue Sep 13 22:28:48 CEST 2005 org/test/
 0 Tue Sep 13 22:28:48 CEST 2005 org/test/map/
  7625 Tue Sep 13 22:28:48 CEST 2005 org/test/BaseJobEntry.class
 12288 Tue Sep 13 22:28:48 CEST 2005 org/test/BaseJobEntryPeer.class
   311 Tue Sep 13 22:28:48 CEST 2005 org/test/JobEntry.class
   288 Tue Sep 13 22:28:48 CEST 2005 org/test/JobEntryPeer.class
  2043 Tue Sep 13 22:28:48 CEST 2005 org/test/map/JobEntryMapBuilder.class

Both tasks, java:compile and jar:jar work fine and as expected using maven-1.0.2

This is a test case for a real world example, trying to compile and build the 
site for the turbine 2.3.2-rc1 release. The classpath error
occurs when the site build process tries to run jdepend to build the metrics. 
So the problem doesn't seem to be part of the plugins or
tasks but of the core.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (MAVEN-1688) The ${pom.versions} List behaves differently when running plugins under maven 1.1 and maven 1.0

[Henning Schmiedehausen (JIRA)]

The ${pom.versions} List behaves differently when running plugins under maven 
1.1 and maven 1.0
---

 Key: MAVEN-1688
 URL: http://jira.codehaus.org/browse/MAVEN-1688
 Project: Maven
Type: Bug
  Components: core  
Versions: 1.1-beta-2
 Reporter: Henning Schmiedehausen


Consider the following POM snipped:



  2.1
  TURBINE_2_1


  2.2
  TURBINE_2_2_0


  2.3-rc1
  TURBINE_2_3_RC1


  2.3-rc2
  TURBINE_2_3_RC2


  2.3
  TURBINE_2_3


  2.3.1-RC1
  TURBINE_2_3_1_RC1


  2.3.1-RC2
  TURBINE_2_3_1_RC2


  2.3.1
  TURBINE_2_3_1
  2.3.1


  2.3.2-RC1
  TURBINE_2_3_2_RC1

  

echoing ${pom.versions} under the 1.0.2 maven release issues the following 
output:

[echo] [2.1, 2.2, 2.3-rc1, 2.3-rc2, 2.3, 2.3.1-RC1, 2.3.1-RC2, 2.3.1, 
2.3.2-RC1]

doing the same thing under the 1.1-beta 2 core results in

[echo] [null, null, null, null, null, null, null, 2.3.1, null]

It seems that 1.0 uses the name as key and 1.1 uses the id. This causes e.g. 
the clirr plugin to fail if a project
defines names for a version entry but no id.

If it is necessary that a version entry contains name and/or id, it should be 
enforced by the maven core and bad
entries should be reported.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (MPTEST-56) maven test-plugin silently ignores test definitions in the POM when run under maven 1.1 beta 2

[Henning Schmiedehausen (JIRA)]

maven test-plugin silently ignores test definitions in the POM when run under 
maven 1.1 beta 2
--

 Key: MPTEST-56
 URL: http://jira.codehaus.org/browse/MPTEST-56
 Project: maven-test-plugin
Type: Bug
Versions: 1.7
 Reporter: Henning Schmiedehausen


use the following unitTest definition in your POM:

   
  
**/*Test.java
  
  
**/Test*.java
  
  
**/test/*.java
  
[...]
  

When running under maven 1.0.2, all Test classes that start with Test or end 
with Test are executed. 

When running under maven 1.1-beta2, only the classes starting with Test are 
executed. The second  definition overrides the first. Under maven
1.0.2 the two definitions are added.

According to my understanding of the xsd, there should either be a maxOccurs to 
prevent this, an exception being thrown when encountering the second includes 
or the old maven 1.0.2 behaviour being restored.

This is a real world example. I ran into this when test driving the Jakarta 
Turbine 2.3.2 RC1 with maven 1.1

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (MAVEN-1687) Jakarta Turbine has a maven plugin

[Henning Schmiedehausen (JIRA)]

Jakarta Turbine has a maven plugin
--

 Key: MAVEN-1687
 URL: http://jira.codehaus.org/browse/MAVEN-1687
 Project: Maven
Type: Task
  Components: documentation  
 Reporter: Henning Schmiedehausen


Please add the following to the http://maven.apache.org/reference/3rdparty.html 
page:

http://jakarta.apache.org/turbine/meta -- Maven Environment for Turbine 
Applications, a maven plugin for developing applications based on the Jakarta 
Turbine framework using Maven.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [ANN] Maven XDoc Plug-in 1.9.2 released

[Henning Schmiedehausen]

Hi,

I knew that this would come out wrong / will be read wrong.

a) I'm aware that this is not Jakarta. It is Maven. So rules are 
   probably different (I'm not on the Maven PMC, so all I know are the 
   public pages on maven.apache.org which is not really much. So I
   considered the main apache rules from apache.org to apply)

b) From a personal, scratch my itch, point of view: Great! Bugs fixed,
   new plugin, cool.

My concerns are of a different nature: The ASF is a people driven
organization. It is about participation. About people swapping opinions,
discussing topics. Agreeing. Not agreeing. This means, there are a few
rules to which everyone and every project should try to hold up. One of
them is voting and voting periods. 

If you run a vote which takes only a few hours and then stop it "because
half of the PMC has voted", then you don't have to run a public vote at
all. Just vote on the PMC list and then release. But if you want people
to react on the vote, maybe try out the code that is voted on and be
able to raise objections (look at the commons-email voting thread that
runs on [EMAIL PROTECTED] We were ready to release and then someone
not really involved with c-e before, raised a valid objection about
dependencies) or concerns, then you do have to take some time to allow
people to react.

If you don't want or care about these reactions, then a project is no
longer people and community driven. Which is _the_ _main_ _point_ of all
ASF projects. This is what I meant with 'just watching the big guys
doing their thing'. Apache and Apache projects is about "everyone can
participate". 

The mail went to the users-list because the announcement was sent only
there (I couldn't find it on the dev list, but this can be due to my
personal mailing list setup, if this is the case then apologies). I
agree that -dev is the better choice.

Regards
Henning


On Tue, 2005-09-06 at 18:00 +1000, Brett Porter wrote:
> Wow.
> 
> (moving to the dev list, as it is completely inappropriate for the
> users list)
> 
> You jump on the list saying how urgent it is you have this released
> because it has been broken for a while. We act to release it as
> quickly as possible, and you complain that it was too quick. Make up
> your mind! :)
> 
> Half of the PMC voted. The time that the vote would be open for was
> specified, and elapsed.
> 
> As for forwarding a result to the PMC - this is not Jakarta. There are
> not multiple subprojects and a huge number of PMC members - the PMC is
> active in the dev list.
> 
> If you are genuinely concerned, feel free to discuss it - but please
> tell me you actually think there was some reason this shouldn't have
> gone ahead.
> 
> - Brett
> 
> On 9/6/05, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote:
> Arnaud HERITIER <[EMAIL PROTECTED]> writes:
> 
> >We are pleased to announce the Maven XDoc Plug-in 1.9.2
> release!=20
> 
> Folks,
> 
> |Subject: [vote] maven-xdoc-plugin 1.9.2 for maven 1.X
> |Date: Sun, 4 Sep 2005 01:40:29 + (UTC)
> 
> 
> |Subject: [ANN] Maven XDoc Plug-in 1.9.2 released
> |Date: Mon, 5 Sep 2005 21:16:24 + (UTC)
> 
> Sorry to bother you, but IMHO it must not work that way. Even
> if the 
> maven PMC runs things a bit differently, a voting period of
> not even
> 48 hours isn't the way to go. Also, according to the voting
> rules
> stated on the apache pages and your own maven developer pages,
> you
> should at least post a result to the dev-list (and you
> probably have 
> to run the result by the Maven PMC (At least it is like this
> in
> Jakarta land and I don't think it is much different in Maven
> land)).
> 
> Running the show like this ("We decided to release. Poof. We
> release.") might be ok for your very own project hosted at 
> sourceforge. Not for an Apache project.
> 
> You might think about this for future releases. The ASF has
> not many
> rules and they are very flexible but there _are_ rules and the
> point
> is to allow people to participate. Not just to sit and watch
> "the big 
> guys do their thing".
> 
> Regards
> Henning
> 
> 
> 
> --
> Dipl.-Inf. (Univ.) Henning P.
> Schmiedehausen  INTERMETA GmbH
> [EMAIL PROTECTED]+49 9131 50 654 0
> http://www.intermeta.de/
> 
> RedHat Certified Engineer -- Jakarta Turbine Development  --
> hero for hire
>Linux, Java, perl, Solaris -- Consulting, Training,
> Development 
> 
>   4 - 8 - 15 - 16 - 23 - 42
> 
> --

[jira] Commented: (MAVENUPLOAD-501) Please upload village-2.0 to ibiblio

[Henning Schmiedehausen (JIRA)]

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-501?page=comments#action_45652 ] 

Henning Schmiedehausen commented on MAVENUPLOAD-501:


http://www.ibiblio.org/maven/village/jars/

What part of "For projects with artifacts already uploaded to ibiblio it can be 
equal" did I get wrong?

> Please upload village-2.0 to ibiblio
> 
>
>  Key: MAVENUPLOAD-501
>  URL: http://jira.codehaus.org/browse/MAVENUPLOAD-501
>  Project: maven-upload-requests
> Type: Task
>     Reporter: Henning Schmiedehausen

>
>
> http://www.softwareforge.de/projects/village/
> http://www.softwareforge.de/projects/village/team-list.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (MAVENUPLOAD-501) Please upload village-2.0 to ibiblio

[Henning Schmiedehausen (JIRA)]

Please upload village-2.0 to ibiblio


 Key: MAVENUPLOAD-501
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-501
 Project: maven-upload-requests
Type: Task
 Reporter: Henning Schmiedehausen


http://www.softwareforge.de/projects/village/
http://www.softwareforge.de/projects/village/team-list.html


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (MPXDOC-154) system locale setting makes test cases fail.

[Henning Schmiedehausen (JIRA)]

[ http://jira.codehaus.org/browse/MPXDOC-154?page=comments#action_45373 ] 

Henning Schmiedehausen commented on MPXDOC-154:
---

Type the following instructions into a Linux command line:

svn checkout 
http://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk/plugin-parent
svn checkout http://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk/xdoc 
maven-xdoc-plugin
cd maven-xdoc-plugin
export LANG=en_US
rm -rf target
maven -q test > /tmp/result1
export LANG=en_US.UTF-8
rm -rf target
maven -q test > /tmp/result2
diff -u /tmp/result1 /tmp/result2

The maven-xdoc-plugin _IS_ the test case. Not "some projects of yours". The bug 
is in the test cases. Not in the plugin.


> system locale setting makes test cases fail.
> 
>
>  Key: MPXDOC-154
>  URL: http://jira.codehaus.org/browse/MPXDOC-154
>  Project: maven-xdoc-plugin
> Type: Bug
> Versions: 1.9.1
>  Environment: java version "1.4.2_08"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode)
> Fedora Core 3 x86
> Reporter: Henning Schmiedehausen

>
>
> [EMAIL PROTECTED] maven-xdoc-plugin-1.9.1]$ echo $LANG
> en_US
> [EMAIL PROTECTED] maven-xdoc-plugin-1.9.1]$ rm -rf target ; maven -q test
> [...]
> test:test:
> [junit] Running org.apache.maven.xdoc.util.LocaleUtilTest
> [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 1.854 sec 
> <- !!!
> [junit] Running org.apache.maven.NavBeanTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.567 sec
> [EMAIL PROTECTED] maven-xdoc-plugin-1.9.1]$ export LANG=en_US.UTF-8 (this is 
> the default on all recent Linux systems)
> [EMAIL PROTECTED] maven-xdoc-plugin-1.9.1]$ rm -rf target; maven -q test:test
> [...]
> test:test:
> [junit] Running org.apache.maven.xdoc.util.LocaleUtilTest
> [junit] Tests run: 7, Failures: 1, Errors: 0, Time elapsed: 1.843 sec
> [junit] [ERROR] TEST org.apache.maven.xdoc.util.LocaleUtilTest FAILED  
> < !!
> [junit] Running org.apache.maven.NavBeanTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.506 sec
> Same behaviour for plugins/trunk/xdoc

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (MPCHANGELOG-70) The Subversion parser of the maven-changelog-plugin chokes on spaces in usernames.

[Henning Schmiedehausen (JIRA)]

The Subversion parser of the maven-changelog-plugin chokes on spaces in 
usernames.
--

 Key: MPCHANGELOG-70
 URL: http://jira.codehaus.org/browse/MPCHANGELOG-70
 Project: maven-changelog-plugin
Type: Bug
Versions: 1.8.2
 Reporter: Henning Schmiedehausen
 Attachments: patch

We use client certificates for authentication to the web server which holds our 
SVN repository. This results in the changelog messages containing the CN field 
of the certificate; in my case e.g. it is "Henning Schmiedehausen".

Subversion now produces log files like this:

----
r237 | Henning Schmiedehausen | 2005-08-10 13:02:39 +0200 (Wed, 10 Aug 2005) | 
3 lines

and the changelog report is empty. The reason for this is a bad regular 
expression in the SvnLogParser which does not expect user names to contain
blanks.

The attached patch fixes this by using a greedy RE. Changelog now works for me 
again. Please consider this patch to be part of the (not yet released?!?) 1.8.2 
or 1.8.3 release.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (MPCHANGELOG-70) The Subversion parser of the maven-changelog-plugin chokes on spaces in usernames.

[Henning Schmiedehausen (JIRA)]

 [ http://jira.codehaus.org/browse/MPCHANGELOG-70?page=all ]

Henning Schmiedehausen updated MPCHANGELOG-70:
--

Attachment: patch

patch vs. changelog-plugin  1.8.2 to fix the "space in usernames" issue.

> The Subversion parser of the maven-changelog-plugin chokes on spaces in 
> usernames.
> --
>
>  Key: MPCHANGELOG-70
>  URL: http://jira.codehaus.org/browse/MPCHANGELOG-70
>  Project: maven-changelog-plugin
> Type: Bug
> Versions: 1.8.2
> Reporter: Henning Schmiedehausen
>  Attachments: patch
>
>
> We use client certificates for authentication to the web server which holds 
> our SVN repository. This results in the changelog messages containing the CN 
> field of the certificate; in my case e.g. it is "Henning Schmiedehausen".
> Subversion now produces log files like this:
> --------
> r237 | Henning Schmiedehausen | 2005-08-10 13:02:39 +0200 (Wed, 10 Aug 2005) 
> | 3 lines
> and the changelog report is empty. The reason for this is a bad regular 
> expression in the SvnLogParser which does not expect user names to contain
> blanks.
> The attached patch fixes this by using a greedy RE. Changelog now works for 
> me again. Please consider this patch to be part of the (not yet released?!?) 
> 1.8.2 or 1.8.3 release.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (MPXDOC-154) system locale setting makes test cases fail.

[Henning Schmiedehausen (JIRA)]

system locale setting makes test cases fail.


 Key: MPXDOC-154
 URL: http://jira.codehaus.org/browse/MPXDOC-154
 Project: maven-xdoc-plugin
Type: Bug
Versions: 1.9.1
 Environment: java version "1.4.2_08"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03)
Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode)
Fedora Core 3 x86
 Reporter: Henning Schmiedehausen
 Assigned to: Arnaud Heritier 


[EMAIL PROTECTED] maven-xdoc-plugin-1.9.1]$ echo $LANG
en_US
[EMAIL PROTECTED] maven-xdoc-plugin-1.9.1]$ rm -rf target ; maven -q test
[...]
test:test:
[junit] Running org.apache.maven.xdoc.util.LocaleUtilTest
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 1.854 sec 
<- !!!
[junit] Running org.apache.maven.NavBeanTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.567 sec

[EMAIL PROTECTED] maven-xdoc-plugin-1.9.1]$ export LANG=en_US.UTF-8 (this is 
the default on all recent Linux systems)
[EMAIL PROTECTED] maven-xdoc-plugin-1.9.1]$ rm -rf target; maven -q test:test
[...]
test:test:
[junit] Running org.apache.maven.xdoc.util.LocaleUtilTest
[junit] Tests run: 7, Failures: 1, Errors: 0, Time elapsed: 1.843 sec
[junit] [ERROR] TEST org.apache.maven.xdoc.util.LocaleUtilTest FAILED  
< !!
[junit] Running org.apache.maven.NavBeanTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.506 sec

Same behaviour for plugins/trunk/xdoc

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New Site CSS

[Henning Schmiedehausen]

On Wed, 2005-08-03 at 10:02 +0200, Fabrizio Giustina wrote:
> On 8/2/05, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> > > Question: Is there documentation somewhere how you can influence the
> > > site build with your own style sheet? And which CSS tags must be
> > > defined for the site to build?
> > The properties you can set are described at
> > http://maven.apache.org/reference/plugins/xdoc/properties.html
> 
> The maven.ui.* properties are pretty useless now, if you want to
> modifify the look and feel for the generated file simply place a
> project.css stylesheet in xdoc/style.
> Pages generated by xdoc are fully xhtml compliant, without any layout
> information embedded in the page: you can use ids and classes added to
> any element in your custom css rules, overwriting the default rules in
> the base maven css.

Is that for Maven 1 or Maven 2? Is there a list of the ids and classes
somewhere besides the base maven css file?

Regards
Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen  INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0   http://www.intermeta.de/

  RedHat Certified Engineer -- Jakarta Turbine Development
   Linux, Java, perl, Solaris -- Consulting, Training, Engineering

 4 - 8 - 15 - 16 - 23 - 42


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (MPCHECKSTYLE-29) Turbine checkstyle rules do not match Turbine coding rules

[Henning Schmiedehausen (JIRA)]

 [ 
http://jira.codehaus.org/browse/MPCHECKSTYLE-29?page=comments#action_40759 ]
 
Henning Schmiedehausen commented on MPCHECKSTYLE-29:


(So the current lag seems to be six months?)

http://jakarta.apache.org/turbine/common/code-standards.html

e.g.

Or you can simply trust me. I'm a committer on the Turbine project.


> Turbine checkstyle rules do not match Turbine coding rules
> --
>
>  Key: MPCHECKSTYLE-29
>  URL: http://jira.codehaus.org/browse/MPCHECKSTYLE-29
>  Project: maven-checkstyle-plugin
> Type: Bug
> Versions: 2.5
> Reporter: Henning Schmiedehausen

>
> Original Estimate: 10 minutes
> Remaining: 10 minutes
>
> The maven-checkstyle plugin contains the following rule for the Turbine 
> checkstyle mode:
>
>  
>
> which is silly. Such a rule was never part of the Turbine coding style rules. 
> Please remove these.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (MPXDOC-134) rewrite - scm support for xdoc plugin

[Henning Schmiedehausen (JIRA)]

rewrite - scm support for xdoc plugin
-

 Key: MPXDOC-134
 URL: http://jira.codehaus.org/browse/MPXDOC-134
 Project: maven-xdoc-plugin
Type: Improvement
Reporter: Henning Schmiedehausen
 Assigned to: Arnaud HERITIER 
 Attachments: xdoc.patch

This patch removes a lot of CVS'isms from the xdoc plugin and allows to plug in 
documentation for other scm systems instead of blindlingly parsing 
cvs-usage.xml. It splits the page into a -public and -developer fragment which 
is pulled into the scm-usage.xml page dynamically.

It also allows for the possible situation that the public repository is of type 
"A" (let's say "CVS") and the developer repository is of type "B" (let's say 
Subversion), skips around some bad (cvs-specific) code in 
org.apache.maven.project.repository) and adds a few new features to the CVS 
page (such as displaying the anonymous user and possible password when they are 
present in the pom).

This patch should not be applied "as is", it is a diff of our internal 
development tree against the SVN trunk. There are changes e.g. to the 
project.xml file that one does not want to have inside the Apache SVN tree.

Just as the changelog plugin: If I get karma, I'm willing to apply these 
patches myself.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (MPCHANGELOG-60) maven-changelog-plugin major rewrite

[Henning Schmiedehausen (JIRA)]

maven-changelog-plugin major rewrite


 Key: MPCHANGELOG-60
 URL: http://jira.codehaus.org/browse/MPCHANGELOG-60
 Project: maven-changelog-plugin
Type: Improvement
Reporter: Henning Schmiedehausen
 Attachments: changelog.patch

This is a major rewrite of the maven-changelog-plugin to start tacking the 
abysmal state that it is in.

I was pretty p*ssed to find out that I have to set a "factory" property when I 
want to use SVN, that the SVN support only works when the plugin runs in the 
correct working directory and that the date limitation does not work at all (at 
least on Linux).

Also the different repository syntax from CVS (why do we have this scm: definition if no one cares about it?) 
is misleading, local URLs like file: or svn+ssh don't seem to work and all in 
all the whole SVN support is rudimentary at best. 

This rewrite tackles the following problems:

- Auto select the SCM type. Look at the second field and choose cvs, clearcase, 
perforce, starteam, svn.

- do some code cleanup. Juggle a few constants, move a bit of the init code, 
make token parsing saner.

- bring the SVN code somehow in line with CVS. Repository connections now look 
like CVS connection:

   scm:svn:http:svn.apache.org:/repos/asf/foo/trunk

   or 

   scm:svn:svnssh:[EMAIL 
PROTECTED]:/repos/local/opensource/foo

- support for all SVN connection types (http, https, file, local, svn, svnssh)

- support for passwords (when using the ";" delimiter):

   scm;svn;http;henning:[EMAIL 
PROTECTED];/repos/asf/foo/trunk

- make the svn log actually look at the pom defined repository and not at 
"current working directory"

- supply username and password to svn if given by the pom



This patch should probably _not_ be applied "as is". It is a patch from our 
internal SVN to the current SVN head @ apache.
It contains a few changes to e.g. project.xml which shouldn't be applied to the 
repo (but I'm much too lazy to start sorting out this patch). 

If you give me karma for the changelog-plugin I'd even be willing to apply them 
to the Apache SVN myself. :-) 



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (MPTEST-47) It should be possible to add additional elements to the test classpath

[Henning Schmiedehausen (JIRA)]

It should be possible to add additional elements to the test classpath
--

 Key: MPTEST-47
 URL: http://jira.codehaus.org/browse/MPTEST-47
 Project: maven-test-plugin
Type: Improvement
 Environment: Java(TM) 2 Runtime Environment, Standard Edition (build 
1.4.2_07-b05)
Java HotSpot(TM) Client VM (build 1.4.2_07-b05, mixed mode)

Reporter: Henning Schmiedehausen
 Attachments: maven-test.patch

(this is basically a rehash of MPTEST-16)

For porting unit tests from ant to maven, it was necessary to add certain 
pre-produced jars to the test classpath. This is not possible with the 1.6.2 
plugin. My solution was (as the solution of some other users), to add a 
property which can
be assigned and is then added to the classpath. This allows me to do e.g.

maven.test.classpath= 
${basedir}/test/cpload/test1.jar;${basedir}/test/cpload/test2.jar

where test1.jar and test2.jar are jars that must not be present in the build 
phase but need to present in the test phase.

There have different solution been discussed. However:

- adding something to the "resources" part of the POM makes it impossible to 
automatically download such a jar
  through maven.
- adding a property to the dependencies makes it impossible to ship such a test 
jar with the distribution and reference
  it locally. 

and still we currently have no solution at all. I'd therefore propose the 
attached patch which allows all three test goals in maven-test-plugin 
(test:single, test:test and test:match) to evaluate a property variable called 
maven.test.classpath. This
variable (if nonempty) is transferred to a  element 
and can therefore contain multiple elements (separated by e.g. ";").

The attached patch is IMHO the easiest fix for this problem with seems to 
affect a lot of maven users.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

preGoal and postGoal and extended POM

[Henning Schmiedehausen]

Hi,

I have the following situation

Project A

project.xml

maven.xml, contains java:compile preGoal and postGoal

These are needed to compile project A.


Project B

extends Project A project.xml (because it shares the dependencies and
   some more information)

maven.xml contains no pre and post goals because they're not needed
here.


Building Project B now crashes, because it tries to execute the pre
and post goal from Project A maven.xml file!

Building Project B is completely different from Project A. All I need
are a few properties. So this is not possible? How can I avoid to run
the project A pre and post goals when I want to build Project B.

(This is a real world situation. Consider "Project A" being the
db-torque runtime and "Project B" the db-torque generator).

Test case:


/tmp/bar/maven.xml:
--- cut ---


  
PRE BAR
  

  
POST BAR
  

--- cut ---

/tmp/bar/foo/maven.xml:
--- cut ---


  
PRE FOO
  

  
POST FOO
  

--- cut ---

% cd /tmp/bar
% maven -b java:compile
java:compile:
[echo] PRE BAR
[echo] Compiling to /tmp/bar/target/classes
[echo] No java source files to compile.
[echo] POST BAR
BUILD SUCCESSFUL

% cd /tmp/bar/foo
% maven -b java:compile
java:compile:
[echo] PRE BAR
[echo] PRE FOO
[echo] Compiling to /tmp/bar/foo/target/classes
[echo] No java source files to compile.
[echo] POST BAR
[echo] POST FOO
BUILD SUCCESSFUL

I tested this with beta9 and rc1 snapshots. Both exhibit the same
behaviour.

Please include me in Cc because I don't monitor the maven lists on a
regular base.

Regards
Henning


-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen  INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0   http://www.intermeta.de/

Java, perl, Solaris, Linux, xSP Consulting, Web Services 
freelance consultant -- Jakarta Turbine Development  -- hero for hire

"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!" 
  -- AOL CD when played backwards  (User Friendly - 200-10-15)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Patch for Maven Torque Plugin

[Henning Schmiedehausen]

Hi,

to whom it may concern:

property names in maven (at least up to b9, don't know about b10) must
not contain "-". The torque plugin unfortunately contains two of these
which are promptly interpreted by jelly as .foo - bar.yyy instead
of .foo-bar.yyy

Please apply the attached patch to the torque plugin, which fixes this.

Regards
Henning


-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen  INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0   http://www.intermeta.de/

Java, perl, Solaris, Linux, xSP Consulting, Web Services 
freelance consultant -- Jakarta Turbine Development  -- hero for hire

--- Quote of the week: "It is pointless to tell people anything when
you know that they won't process the message." --- Jonathan Revusky
Index: plugin.jelly
===
RCS file: /home/cvspublic/maven/src/plugins-build/torque/plugin.jelly,v
retrieving revision 1.6
diff -u -b -r1.6 plugin.jelly
--- plugin.jelly	22 May 2003 04:59:36 -	1.6
+++ plugin.jelly	9 Jul 2003 12:49:27 -
@@ -354,8 +354,8 @@
   templatePath="${torque.templatePath}"
   useClasspath="${torque.useClasspath}">
   
 
 
@@ -471,8 +471,8 @@
   templatePath="${torque.templatePath}"
   useClasspath="${torque.useClasspath}">
   
 
 
Index: plugin.properties
===
RCS file: /home/cvspublic/maven/src/plugins-build/torque/plugin.properties,v
retrieving revision 1.1
diff -u -b -r1.1 plugin.properties
--- plugin.properties	26 Feb 2003 23:30:46 -	1.1
+++ plugin.properties	9 Jul 2003 12:49:27 -
@@ -183,10 +183,10 @@
 torque.schema.sql.excludes =
 torque.schema.doc.includes = *-schema.xml
 torque.schema.doc.excludes =
-torque.schema.create-db.includes = *-schema.xml
-torque.schema.create-db.excludes =
-torque.schema.init-sql.includes = *-schema.xml
-torque.schema.init-sql.excludes = id-table-schema.xml
+torque.schema.createdb.includes = *-schema.xml
+torque.schema.createdb.excludes =
+torque.schema.initsql.includes = *-schema.xml
+torque.schema.initsql.excludes = id-table-schema.xml
 torque.schema.om.includes = *-schema.xml
 torque.schema.om.excludes = id-table-schema.xml
 torque.schema.ojb.includes = *-schema.xml

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[ANNOUNCEMENT] Commons FileUpload 1.0 Release Candidate 1 Released

[Henning Schmiedehausen]

Hi,

could someone please put this jar on ibiblio? Thanks.

Regards
Henning


>Path: news.hometree.net!not-for-mail
>From: Martin Cooper <[EMAIL PROTECTED]>
>Newsgroups: hometree.jakarta.announce
>Subject: [ANNOUNCEMENT] Commons FileUpload 1.0 Release Candidate 1 Released
>Date: Fri, 6 Jun 2003 15:03:25 + (UTC)
>Organization: INTERMETA - Gesellschaft fuer Mehrwertdienste mbH
>Lines: 36
>Sender: [EMAIL PROTECTED]
>Approved: yes
>Message-ID: <[EMAIL PROTECTED]>
>NNTP-Posting-Host: news.hometree.net
>Mime-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>X-Trace: tangens.hometree.net 1054911805 12712 212.34.181.127 (6 Jun 2003 15:03:25 
>GMT)
>X-Complaints-To: [EMAIL PROTECTED]
>NNTP-Posting-Date: Fri, 6 Jun 2003 15:03:25 + (UTC)
>Organisation: INTERMETA - Gesellschaft fuer Mehrwertdienste mbH
>X-To: [EMAIL PROTECTED]
>Xref: news.hometree.net hometree.jakarta.announce:186

The Commons FileUpload team is pleased to announce the release of
FileUpload 1.0 Release Candidate 1. This release includes some new
functionality, as well as fixes for a number of bugs which were reported
against earlier versions. The FileUpload team believes that this release
is ready for prime time, hence its designation as a release candidate.

For details of the changes in this release, see the Release Notes, here:

http://www.apache.org/dist/jakarta/commons/fileupload/RELEASE-NOTES.txt

The binary distribution is available at:

http://jakarta.apache.org/site/binindex.cgi

and the source distribution is available at:

http://jakarta.apache.org/site/sourceindex.cgi

When downloading from a mirror site, please remember to verify the
signatures of the distribution using the keys found on the main Apache web
site:

http://www.apache.org/dist/jakarta/commons/fileupload/KEYS

For more information on Commons FileUpload, see the FileUpload web site:

http://jakarta.apache.org/commons/fileupload/

--
Martin Cooper


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen  INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0   http://www.intermeta.de/

Java, perl, Solaris, Linux, xSP Consulting, Web Services 
freelance consultant -- Jakarta Turbine Development  -- hero for hire

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]