Re: Process maven mdo files via ModelloCLI

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Process maven mdo files via ModelloCLI

William L. Thomson Jr.
I guess no one is familiar with Plexus or Modello. If Maven developers
are not familiar with what technologies Maven is built atop. Not sure
who else would have a clue about Plexus or Modello.

I can look to building Maven via other means. But does not reflect to
well on Maven IMHO. Plexus and Modello are part of how Maven is built.
Someone should have a clue about both.

If your a Maven developer, I highly recommend getting to know Plexus
and Modello. It is the underlying foundation to Maven it seems.

On Thu, 14 Jun 2018 10:41:14 -0400
"William L. Thomson Jr." <[hidden email]> wrote:

> I have been working on packaging and building Maven from source on
> Gentoo. Without using Maven, just straight javac, etc.  It is looking
> like I cannot do this without using pre-generated sources on Maven
> Central. I am having issues with ModelloCLI loading plugins.
> https://github.com/codehaus-plexus/modello/issues/15
>
> My gut says MetadataPlugins are not the same as Generators. Maybe need
> to package more of Modello plugins and/or have them on the classpath.
> I am really not clear how Modello loads its plugins via Plexus. Once I
> can get the plugin loaded. I should be able to proceed. This is where
> I am stuck, Modello loading a plugin to generate Java from mdo files.
> I do not need any other formats, just Java.
>
> Even more interesting, seems to be a chicken/egg situation with parts
> of Plexus. Which also has mdo files.
> https://github.com/codehaus-plexus/plexus-containers/tree/plexus-containers-1.x/plexus-container-default/src/main/mdo
>
> Mailing lists for Modello and Plexus seem MIA. It does not seem like
> anything else uses this other than Maven. This is not a normal user
> issue, thus asking on Maven development list.
>
> If someone here does not know about Modello and Plexus. Not sure where
> I can find someone who does... Thanks for any help!
>


--
William L. Thomson Jr.

attachment0 (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Process maven mdo files via ModelloCLI

William L. Thomson Jr.
Per my final comment question below, the 6 vs 4. That was because
modello-plugin-xpp3 was also on the classpath. Which has 3 Generators
and no MetaDataPlugin, thus it does not show.

Seems more and more like there is a problem with the Generators
HashMap. It has a size, but elements are messed up or something.

I kept thinking maybe I needed to chain in other plugins. But seems
like only the Java one is needed to go from *.mdo to *.java per
description on pom.xml, but maybe misleading.
https://github.com/codehaus-plexus/modello/blob/master/modello-plugins/modello-plugin-java/pom.xml#L13

If it is not a missing plugin needed for Java plugin. Then it must be
something messing up the HashMap for Generators.

On Mon, 25 Jun 2018 16:19:55 -0400
"William L. Thomson Jr." <[hidden email]> wrote:

snip

> Here is some example output with java, xml, and xsd plugins. I see the
> MetaDataPlugins, but never any Generators. The plugin ModelloCLI wants
> is a generator not a MetaDataPlugin.
>
> --------------------------------------------------------------------------------------------------------------
>
> $ modello  settings.mdo modello ../java/ 4.0.0 false true
> DefaultPlexusContainer
> AbstractPluginManager.initialize()
> plugins = 4
> xsd :
> org.codehaus.modello.plugin.xsd.metadata.XsdMetadataPlugin@275710fc
> model :
> org.codehaus.modello.plugin.model.ModelMetadataPlugin@4de5031f java :
> org.codehaus.modello.plugin.java.metadata.JavaMetadataPlugin@5d47c63f
> xml :
> org.codehaus.modello.plugins.xml.metadata.XmlMetadataPlugin@3bbc39f8
> AbstractPluginManager.initialize() plugins = 6 ModelloCore new
> Modello() parsed args
> generatorId = modello
> plugins = 6
> getPlugin = modello
> Exception in thread "main"
> org.codehaus.modello.ModelloRuntimeException: No such plugin: modello
>
> --------------------------------------------------------------------------------------------------------------
>
> Not sure how it sees 6 plugins from 4 before. Or why I cannot access
> any. Seems like some Generator plugins exist. But the HashMap has
> some issues. Not sure if its improper types being passed or what.
>


--
William L. Thomson Jr.

attachment0 (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Process maven mdo files via ModelloCLI

William L. Thomson Jr.
In reply to this post by William L. Thomson Jr.
On Mon, 25 Jun 2018 08:24:58 +0200
Michael Osipov <[hidden email]> wrote:
>
> William,
>
> my first an foremost question is why do you need this?

Maven and parts are needed as dependencies for Gradle and Netbeans.

> Aren't you  satisfied with the signed binary released we provide?

No, I do not run a binary distribution. Why should Maven be one of the
sole binaries? The only exception is the JDK itself, for other reasons.

> Even if you pursue the from-source-BSD-approach, it is perfectly fine
> to use packages as-is.

Pre-generated sources are bad. One should have a means to build from
version control for a variety of reasons. Java has a horrendous habit
of developing things that require bootstrapping, needlessly...
The JDK is one thing, but anything built atop should have a better way.
Most of these generate Java code or bytecode from something else.

> This is what I recommend on the FreeBSD Java mailing list. Moreover,
> the general consensus from us is that we do not support packages not
> carrying the Git commit or our signature. Debian guys do abnormal
> things by splitting every single dependency of Maven into a deb file.

I am not looking for support. I am looking to understand things Maven
is built atop and how its developed. If one makes changes to a mdo
file. They must run Maven to generate the Java file. Plus then write
tests to ensure that what Modello generated was what was expected.
Rather than writing pure Java from the start...

In a nutshell to develop maven, you must be able to run maven. To use
said plugins to generate Java code. Which a choice was made to use that
format over others. Which can always be changed and eliminates any
issues I have with build.

It is not like Modello's .mdo files are in wide use. I cannot find them
anywhere other than Maven, and even worse a circular dep issue with
Plexus.
https://github.com/codehaus-plexus/plexus-containers/issues/11

That is poor design IMHO. Maven could drop using Modello mdo files for
some other format for Maven build. Which would not effect other stuff.
It likely would not change work flow described above. As you swap out
the modello-maven-plugin for javacc, antlr, xjc, or some other plugin.
Lots of Generators to choose from that are more common.

> These days compiling Java software w/ pure javac is a pain.

Maybe how you do it, but using what I have been working on for sometime
it is anything but. I was able to package most of Netbeans in a much
more simplistic way using a completely different build system.

You should look at some of my packages and tell me that is complex. Or
even the eclasses. They are trivial compared to most other build
systems. It could even be used on other distros or OS.
https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/dev-java/

Netbeans ones are even less due to its eclass
https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/nb-ide
https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/eclass/java-netbeans.eclass

> Even if this will work, you'd still need -- as you have said -- all
> dependencies from Maven. So you still rely on binary files.

Nice assumption, but you are wrong. I build ALL dependencies from
source.... I use no binaries, except for javacc only to build javacc
from source within its package. Its the only one using a pre-build
binary that resides within source releases.
https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/dev-java/javacc/javacc-9999.ebuild#L39

Which I have a request into to stop requiring bootstrap.
https://github.com/javacc/javacc/issues/40

Other stuff I can build to build itself like Groovy, antlr and many
other generators. Though I do dislike bootstrapping and believe it can
be avoided in many cases. Sadly others do not care about such and
rather continue with the bad practices of requiring bootstrapping.

--
William L. Thomson Jr.

attachment0 (201 bytes) Download Attachment