You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Elliotte Rusty Harold <el...@ibiblio.org> on 2021/06/02 11:02:00 UTC
Moving away from Modello
I was looking into
https://issues.apache.org/jira/projects/DOXIATOOLS/issues/DOXIATOOLS-68
and https://issues.apache.org/jira/projects/DOXIATOOLS/issues/DOXIATOOLS-67
when Modello got in my way. So I tried a little experiment to see how
hard it would be to rip Modello out of a project. Result: not very
hard. Just copy the generated sources into the src tree, remove the
.mdo files and plugins, and add some license comments to make Rat
happy.
Why do this? Several reasons:
1. Eclipse can't build Modello based projects. Yes there's probably
some magic incantation and knobs to twist in the settings which can
make it work if you look at it sideways, but why go through that
hassle every time you want to set up a new project.
2. Modello is an extra thing for developers to learn and understand
before they can contribute to a project. Java is well understood.
Modello isn't. It's only really used by Maven. Let Java developers
write and edit Java code. It's not as if writing value classes with
equals methods is hard, and IDEs can autogenerate a lot of what
Modello gives us.
3. Modello is one more tool that can break when building a project
because of a new JDK, a hosting site going dark, etc. Tools of this
nature tend to break more frequently than pure Java code or Maven
itself. The build is less fragile without it.
What do folks think about slowly moving away from Modello where
feasible to simplify the build? Does anyone find Modello a net
positive, especially in longterm maintenance, not just in initial code
generation?
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Moving away from Modello
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Mon, Jun 7, 2021 at 2:11 PM Guillaume Nodet <gn...@apache.org> wrote:
> > There are current issues in our pom.xml parsing, particularly around
> > namespaces, that aren't going to be resolved until we get rid of or
> > fix Modello, and possibly that's going to require fixing XPP3. I don't
> > know. However the XML parser should be an implementation detail.
> >
>
> Which parsing problems exactly ? I used the MXParser / XPP3 for the Camel
> reader and it has full support for namespaces afaik.
>
It's been a few months (or a year?) since I dug into this. Might just
be Modello, not XPP3; I'm no longer sure.
The fundamental mistake is that Maven allows pom.xml both with and
without namespace declarations, and possibly does not properly handle
prefixed element names. (It's been a little while so I might not
remember every detail.) Either way, this misunderstanding makes it
extremely difficult to process pom.xml files with standard XML tools
such as XSLT and XQuery. This cost me a lot of extra work circa
2019/2020 when I was writing tooling that needed to process pom.xml
files to follow dependency chains.
At one point I dug into the code to see how hard it would be to repair
this and let Maven work with XML namespaces instead of against them.
Most of the offending code proved to be in plexus rather than maven
itself, and it was made far more opaque by the multiple extra levels
of indirection in the various frameworks like Modello that Maven sits
on top of.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Moving away from Modello
Posted by Guillaume Nodet <gn...@apache.org>.
Le lun. 7 juin 2021 à 15:37, Elliotte Rusty Harold <el...@ibiblio.org> a
écrit :
> On Mon, Jun 7, 2021 at 1:21 PM Guillaume Nodet <gn...@apache.org> wrote:
> >
> > The generated xml readers are used to actually read the pom. That's an
> > important part :-)
> > I spent quite some time profiling those and XPP3 is really fast, so I'd
> > really like to avoid using JAXB for that.
> >
> >
>
> I agree with not using JAXB. It's a poorly designed API that causes
> more problems than it solves, though I could say the same for all the
> other data binding APIs out there. Not just for XML either. JSON and
> SQL data binding APIs suffer from the same flawed goal of avoiding
> writing the code necessary to understand the data. It never works and
> it always ends up costing more in the end.
>
When I was working on an alternative to JAXB for Camel, I ended up writing
a simple generator that generates the reader + xsd from POJOs.
>
> There are current issues in our pom.xml parsing, particularly around
> namespaces, that aren't going to be resolved until we get rid of or
> fix Modello, and possibly that's going to require fixing XPP3. I don't
> know. However the XML parser should be an implementation detail.
>
Which parsing problems exactly ? I used the MXParser / XPP3 for the Camel
reader and it has full support for namespaces afaik.
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: Moving away from Modello
Posted by Andreas Sewe <an...@buildingblobs.com>.
Robert Scholte wrote:
> Well, where is the need for additional namespaces and how they be handled?
> The reader has a strict mode, should it fail or ignore unknown tags?
> I am aware of one request: adding a namespace on plugins configuration (to validate its content), however the configuration-element is part of the maven namespace, so I don't think this will work.
Yes, unless you want namespace prefixes, which is awkward for
<configuration> children.
However, there is one area where I would have liked better namespace
support in the past, namely when plugins need free-form XML
<configuration> elements. The most well-known use case is the
maven-antrun-plugin's <target> configuration element, which is of type
PlexusConfiguration.
AFAIK, the following won't work with a PlexusConfiguration target:
<configuration xmlns:ex="http://example.org/">
<target>
<ex:example>42</ex:example>
</target>
</configuration>
The PlexusConfiguration would only give you access to the QName
"ex:example" with no way to determine what URI the "ex" namespace prefix
is bound to.
You would have to write it like this:
<configuration>
<target xmlns:ex="http://example.org/">
<ex:example>42</ex:example>
</target>
</configuration>
Now that might not seem like a big difference, but remember that you
could move the xmlns:ex declaration all the way up to the project
<project> element and thereby sharing it among multiple <configuration>
elements.
FYI, the use case I had in the past was configuring XQuery/XSLT engines,
whose external variables and configuration options are namespaced:
<configuration>
<variables
xmlns:ex="http://example.org/"
xmlsns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ex:example xsi:type="xs:decimal">42</ex:example>
</variables>
</configuration>
Not being able to place those namespace declarations on the root element
really hurts, in particular as the XMLSchema-instance namespace is
normally already declared there -- but you cannot "see" that from your
PlexusConfiguration.
Note that this is *not* an argument in favour of dropping Modello; it is
just an argument in favour of better namespace support (or rather
awareness) in something like PlexusConfiguration.
Best wishes,
Andreas Sewe
Re: Moving away from Modello
Posted by Robert Scholte <rf...@apache.org>.
Well, where is the need for additional namespaces and how they be handled?
The reader has a strict mode, should it fail or ignore unknown tags?
I am aware of one request: adding a namespace on plugins configuration (to validate its content), however the configuration-element is part of the maven namespace, so I don't think this will work.
thanks,
Robert
On 7-6-2021 15:37:17, Elliotte Rusty Harold <el...@ibiblio.org> wrote:
On Mon, Jun 7, 2021 at 1:21 PM Guillaume Nodet wrote:
>
> The generated xml readers are used to actually read the pom. That's an
> important part :-)
> I spent quite some time profiling those and XPP3 is really fast, so I'd
> really like to avoid using JAXB for that.
>
>
I agree with not using JAXB. It's a poorly designed API that causes
more problems than it solves, though I could say the same for all the
other data binding APIs out there. Not just for XML either. JSON and
SQL data binding APIs suffer from the same flawed goal of avoiding
writing the code necessary to understand the data. It never works and
it always ends up costing more in the end.
There are current issues in our pom.xml parsing, particularly around
namespaces, that aren't going to be resolved until we get rid of or
fix Modello, and possibly that's going to require fixing XPP3. I don't
know. However the XML parser should be an implementation detail.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Moving away from Modello
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Mon, Jun 7, 2021 at 1:21 PM Guillaume Nodet <gn...@apache.org> wrote:
>
> The generated xml readers are used to actually read the pom. That's an
> important part :-)
> I spent quite some time profiling those and XPP3 is really fast, so I'd
> really like to avoid using JAXB for that.
>
>
I agree with not using JAXB. It's a poorly designed API that causes
more problems than it solves, though I could say the same for all the
other data binding APIs out there. Not just for XML either. JSON and
SQL data binding APIs suffer from the same flawed goal of avoiding
writing the code necessary to understand the data. It never works and
it always ends up costing more in the end.
There are current issues in our pom.xml parsing, particularly around
namespaces, that aren't going to be resolved until we get rid of or
fix Modello, and possibly that's going to require fixing XPP3. I don't
know. However the XML parser should be an implementation detail.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Moving away from Modello
Posted by Guillaume Nodet <gn...@apache.org>.
Le lun. 7 juin 2021 à 14:49, Elliotte Rusty Harold <el...@ibiblio.org> a
écrit :
> On Wed, Jun 2, 2021 at 6:53 PM Hervé BOUTEMY <he...@free.fr>
> wrote:
> >
> > I don't get how Modello got in your way on these issues: please explain
> > And it works perfectly on Eclipse: there is a m2e extension for Modello
> that
> > does the job.
>
> I assume you're referring to the unsigned, pre-1.0 extensions that
> corporate security policy prohibits installing. The details don't
> really matter though. Every extra tool introduced into the build
> process is one extra piece to break in some environment that makes the
> build more fragile and makes it that much harder to bring on new
> developers.
>
> > from a Modello model, we generate:
> > - Java objects
> > - serializers and deserializers: there are other options for some APIs,
> but
> > not for XPP3 AFAIK
> > - XML format documentation
> > - xsd
> > with consistent explanation on each field: how do you expect to keep
> that?
> >
>
> Other than the Java objects, which can trivially be pure Java code,
> when do we use any of those? It all feels like YAGNI to me.
>
The generated xml readers are used to actually read the pom. That's an
important part :-)
I spent quite some time profiling those and XPP3 is really fast, so I'd
really like to avoid using JAXB for that.
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: Moving away from Modello
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Wed, Jun 2, 2021 at 6:53 PM Hervé BOUTEMY <he...@free.fr> wrote:
>
> I don't get how Modello got in your way on these issues: please explain
> And it works perfectly on Eclipse: there is a m2e extension for Modello that
> does the job.
I assume you're referring to the unsigned, pre-1.0 extensions that
corporate security policy prohibits installing. The details don't
really matter though. Every extra tool introduced into the build
process is one extra piece to break in some environment that makes the
build more fragile and makes it that much harder to bring on new
developers.
> from a Modello model, we generate:
> - Java objects
> - serializers and deserializers: there are other options for some APIs, but
> not for XPP3 AFAIK
> - XML format documentation
> - xsd
> with consistent explanation on each field: how do you expect to keep that?
>
Other than the Java objects, which can trivially be pure Java code,
when do we use any of those? It all feels like YAGNI to me.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Moving away from Modello
Posted by Hervé BOUTEMY <he...@free.fr>.
I don't get how Modello got in your way on these issues: please explain
And it works perfectly on Eclipse: there is a m2e extension for Modello that
does the job.
from a Modello model, we generate:
- Java objects
- serializers and deserializers: there are other options for some APIs, but
not for XPP3 AFAIK
- XML format documentation
- xsd
with consistent explanation on each field: how do you expect to keep that?
just look at
https://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/
for a typical example
Modello has another benefit: you know that it's pure object model for a defined
model.
Regards,
Hervé
Le mercredi 2 juin 2021, 13:02:00 CEST Elliotte Rusty Harold a écrit :
> I was looking into
> https://issues.apache.org/jira/projects/DOXIATOOLS/issues/DOXIATOOLS-68
> and https://issues.apache.org/jira/projects/DOXIATOOLS/issues/DOXIATOOLS-67
> when Modello got in my way. So I tried a little experiment to see how
> hard it would be to rip Modello out of a project. Result: not very
> hard. Just copy the generated sources into the src tree, remove the
> .mdo files and plugins, and add some license comments to make Rat
> happy.
>
> Why do this? Several reasons:
>
> 1. Eclipse can't build Modello based projects. Yes there's probably
> some magic incantation and knobs to twist in the settings which can
> make it work if you look at it sideways, but why go through that
> hassle every time you want to set up a new project.
>
> 2. Modello is an extra thing for developers to learn and understand
> before they can contribute to a project. Java is well understood.
> Modello isn't. It's only really used by Maven. Let Java developers
> write and edit Java code. It's not as if writing value classes with
> equals methods is hard, and IDEs can autogenerate a lot of what
> Modello gives us.
>
> 3. Modello is one more tool that can break when building a project
> because of a new JDK, a hosting site going dark, etc. Tools of this
> nature tend to break more frequently than pure Java code or Maven
> itself. The build is less fragile without it.
>
> What do folks think about slowly moving away from Modello where
> feasible to simplify the build? Does anyone find Modello a net
> positive, especially in longterm maintenance, not just in initial code
> generation?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Moving away from Modello
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I agree that dropping modello means using JAXB but it will likely be a
transitive breaking change, ie drop xpp3 too and sadly XPP3 is part of the
maven API and used a lot in extensions and mojo because it enables to
programmatically handle the mojo configuration.
I'd really be to move to an XSD first approach and generate the models (and
implicitly readers/writers) with JAXB but it means keeping a bridge layer
since I can't envision to break these usages which would make it really
inconsistent.
So overall even if I agree modello is not contribution friendly nor a
friendly format, it is likely the least worse we can use as of today to
make it smooth to end users in time IMHO.
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 jeu. 3 juin 2021 à 07:27, Benjamin Marwell <bm...@apache.org> a
écrit :
> > - For some time, JAXB has been bundled with the JRE.
> > As of this writing, this still applies to Java 8.
> > In Java 9, and 10, there's --add-modules=java.xml.bind.
> > As of Java 11, it has been removed from the JDK.
> > I'd consider that to be a migration problem.
>
> You can just include jaxb-api and jaxb-impl for any version of Java.
> This will work and it won't even break Java 8.
>
> Am Mi., 2. Juni 2021 um 22:46 Uhr schrieb Jochen Wiedmann
> <jo...@gmail.com>:
> >
> > On Wed, Jun 2, 2021 at 2:38 PM Gary Gregory <ga...@gmail.com>
> wrote:
> > >
> > > On Wed, Jun 2, 2021 at 8:30 AM Jochen Wiedmann
> > > <jo...@gmail.com> wrote:
> > > >
> > > > On Wed, Jun 2, 2021 at 1:02 PM Elliotte Rusty Harold <
> elharo@ibiblio.org> wrote:
> > > >
> > > > > What do folks think about slowly moving away from Modello where
> > > > > feasible to simplify the build? Does anyone find Modello a net
> > > > > positive, especially in longterm maintenance, not just in initial
> code
> > > > > generation?
> > > >
> > > > To me, it sounds feasible to replace Modello with a Sax parser
> > > > (reading), and a Sax
> > > > event generator (writing), that take as input a bean class (either
> > > > written manually,
> > > > or generated by Modello, and do the serialization/deserialization.
> > > >
> > > > Would, most likely, not be a drop-in-replacement, but definitely a
> medium-term
> > > > solution.
> > >
> > > What about JAXB?
> >
> > In general, JAXB is an excellent technology. For use in Maven, I'd
> > foresee a few gotchas:
> >
> > - For some time, JAXB has been bundled with the JRE. As of this
> > writing, this still applies to Java 8.
> > In Java 9, and 10, there's --add-modules=java.xml.bind. As of Java
> > 11, it has
> > been removed from the JDK. I wouldn't want to deal with that.
> > - To use JAXB, one either needs to have an XSD, or rather specific
> > annotations on the Java beans.
> > I'd consider that to be a migration problem.
> >
> > Jochen
> >
> >
> > --
> >
> > Look, that's why there's rules, understand? So that you think before
> > you break 'em.
> >
> > -- (Terry Pratchett, Thief of Time)
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Moving away from Modello
Posted by Benjamin Marwell <bm...@apache.org>.
> - For some time, JAXB has been bundled with the JRE.
> As of this writing, this still applies to Java 8.
> In Java 9, and 10, there's --add-modules=java.xml.bind.
> As of Java 11, it has been removed from the JDK.
> I'd consider that to be a migration problem.
You can just include jaxb-api and jaxb-impl for any version of Java.
This will work and it won't even break Java 8.
Am Mi., 2. Juni 2021 um 22:46 Uhr schrieb Jochen Wiedmann
<jo...@gmail.com>:
>
> On Wed, Jun 2, 2021 at 2:38 PM Gary Gregory <ga...@gmail.com> wrote:
> >
> > On Wed, Jun 2, 2021 at 8:30 AM Jochen Wiedmann
> > <jo...@gmail.com> wrote:
> > >
> > > On Wed, Jun 2, 2021 at 1:02 PM Elliotte Rusty Harold <el...@ibiblio.org> wrote:
> > >
> > > > What do folks think about slowly moving away from Modello where
> > > > feasible to simplify the build? Does anyone find Modello a net
> > > > positive, especially in longterm maintenance, not just in initial code
> > > > generation?
> > >
> > > To me, it sounds feasible to replace Modello with a Sax parser
> > > (reading), and a Sax
> > > event generator (writing), that take as input a bean class (either
> > > written manually,
> > > or generated by Modello, and do the serialization/deserialization.
> > >
> > > Would, most likely, not be a drop-in-replacement, but definitely a medium-term
> > > solution.
> >
> > What about JAXB?
>
> In general, JAXB is an excellent technology. For use in Maven, I'd
> foresee a few gotchas:
>
> - For some time, JAXB has been bundled with the JRE. As of this
> writing, this still applies to Java 8.
> In Java 9, and 10, there's --add-modules=java.xml.bind. As of Java
> 11, it has
> been removed from the JDK. I wouldn't want to deal with that.
> - To use JAXB, one either needs to have an XSD, or rather specific
> annotations on the Java beans.
> I'd consider that to be a migration problem.
>
> Jochen
>
>
> --
>
> Look, that's why there's rules, understand? So that you think before
> you break 'em.
>
> -- (Terry Pratchett, Thief of Time)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Moving away from Modello
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Wed, Jun 2, 2021 at 2:38 PM Gary Gregory <ga...@gmail.com> wrote:
>
> On Wed, Jun 2, 2021 at 8:30 AM Jochen Wiedmann
> <jo...@gmail.com> wrote:
> >
> > On Wed, Jun 2, 2021 at 1:02 PM Elliotte Rusty Harold <el...@ibiblio.org> wrote:
> >
> > > What do folks think about slowly moving away from Modello where
> > > feasible to simplify the build? Does anyone find Modello a net
> > > positive, especially in longterm maintenance, not just in initial code
> > > generation?
> >
> > To me, it sounds feasible to replace Modello with a Sax parser
> > (reading), and a Sax
> > event generator (writing), that take as input a bean class (either
> > written manually,
> > or generated by Modello, and do the serialization/deserialization.
> >
> > Would, most likely, not be a drop-in-replacement, but definitely a medium-term
> > solution.
>
> What about JAXB?
In general, JAXB is an excellent technology. For use in Maven, I'd
foresee a few gotchas:
- For some time, JAXB has been bundled with the JRE. As of this
writing, this still applies to Java 8.
In Java 9, and 10, there's --add-modules=java.xml.bind. As of Java
11, it has
been removed from the JDK. I wouldn't want to deal with that.
- To use JAXB, one either needs to have an XSD, or rather specific
annotations on the Java beans.
I'd consider that to be a migration problem.
Jochen
--
Look, that's why there's rules, understand? So that you think before
you break 'em.
-- (Terry Pratchett, Thief of Time)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Moving away from Modello
Posted by Manfred Moser <ma...@simpligility.com>.
I agree with a lot of what has been said towards keeping modello in use. There is really no existing drop-in alternative. The benefits of moving off
Modello are mostly unknown until we actually do the work. And in the end it should be mostly internal refactoring.
However that work is a very large effort that is much better invested in the user facing improvements and new features.
Manfred
Robert Scholte wrote on 2021-06-02 11:54 (GMT -07:00):
> The title suggest it should me moved completely from the Maven codebase, but I
> think there's no alternative for Maven Core, as we need quite a huge set of
> features. I don't think there's another tool that can keep the model, reader,
> writers, mergers, validators and xsd in sync. If you want to replace it, start
> with Maven core. If you succeed we can have another discussion otherwise we
> will stick to Modello. We have enough committers that can maintain it.
>
> To me consistency is just as important, so it makes sense to have a preferred
> library for reading/writing XML. As Maven Core already claims Modello, better
> mark this as the preferred solution.
>
> Regarding Eclipse support, most likely Eclipse was the first IDE to support
> Modello and it still does. If you open the pom you should see there are m2
> plugins available, including one for modello. Once installed and restarted, it
> works as expected (just tested it). Like any IDE, in general you don't get all
> the options but often pluguins are available.
>
> You rarely need to touch the mdo-files, but with the right documentation you
> should be able to extend it.
> But that is for any solution we would choose. We shouldn't maintain all Java
> files and XSDs by hand, but generate it. And any generating tool will require
> read that famous manual.
>
> Robert
> On 2-6-2021 14:38:43, Gary Gregory <ga...@gmail.com> wrote:
> On Wed, Jun 2, 2021 at 8:30 AM Jochen Wiedmann
> wrote:
>>
>> On Wed, Jun 2, 2021 at 1:02 PM Elliotte Rusty Harold wrote:
>>
>> > What do folks think about slowly moving away from Modello where
>> > feasible to simplify the build? Does anyone find Modello a net
>> > positive, especially in longterm maintenance, not just in initial code
>> > generation?
>>
>> To me, it sounds feasible to replace Modello with a Sax parser
>> (reading), and a Sax
>> event generator (writing), that take as input a bean class (either
>> written manually,
>> or generated by Modello, and do the serialization/deserialization.
>>
>> Would, most likely, not be a drop-in-replacement, but definitely a medium-term
>> solution.
>
> What about JAXB?
>
> Gary
>
>>
>> Jochen
>>
>>
>> --
>>
>> Look, that's why there's rules, understand? So that you think before
>> you break 'em.
>>
>> -- (Terry Pratchett, Thief of Time)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Moving away from Modello
Posted by Robert Scholte <rf...@apache.org>.
The title suggest it should me moved completely from the Maven codebase, but I think there's no alternative for Maven Core, as we need quite a huge set of features. I don't think there's another tool that can keep the model, reader, writers, mergers, validators and xsd in sync. If you want to replace it, start with Maven core. If you succeed we can have another discussion otherwise we will stick to Modello. We have enough committers that can maintain it.
To me consistency is just as important, so it makes sense to have a preferred library for reading/writing XML. As Maven Core already claims Modello, better mark this as the preferred solution.
Regarding Eclipse support, most likely Eclipse was the first IDE to support Modello and it still does. If you open the pom you should see there are m2 plugins available, including one for modello. Once installed and restarted, it works as expected (just tested it). Like any IDE, in general you don't get all the options but often pluguins are available.
You rarely need to touch the mdo-files, but with the right documentation you should be able to extend it.
But that is for any solution we would choose. We shouldn't maintain all Java files and XSDs by hand, but generate it. And any generating tool will require read that famous manual.
Robert
On 2-6-2021 14:38:43, Gary Gregory <ga...@gmail.com> wrote:
On Wed, Jun 2, 2021 at 8:30 AM Jochen Wiedmann
wrote:
>
> On Wed, Jun 2, 2021 at 1:02 PM Elliotte Rusty Harold wrote:
>
> > What do folks think about slowly moving away from Modello where
> > feasible to simplify the build? Does anyone find Modello a net
> > positive, especially in longterm maintenance, not just in initial code
> > generation?
>
> To me, it sounds feasible to replace Modello with a Sax parser
> (reading), and a Sax
> event generator (writing), that take as input a bean class (either
> written manually,
> or generated by Modello, and do the serialization/deserialization.
>
> Would, most likely, not be a drop-in-replacement, but definitely a medium-term
> solution.
What about JAXB?
Gary
>
> Jochen
>
>
> --
>
> Look, that's why there's rules, understand? So that you think before
> you break 'em.
>
> -- (Terry Pratchett, Thief of Time)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Moving away from Modello
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le jeu. 3 juin 2021 à 13:24, Gary Gregory <ga...@gmail.com> a écrit :
> Wouldn't the first step to move from XPP3 to a standard API?
>
Don't think it is something we can target for maven 4/5, will break too
much the ecosystem requiring users to use a maven wrapper solution which is
always a sign of a fragile build solution and not that nice locally for
multimodule projects because you need to launch the command from the
wrapper.
The adoption of the new API would be insanely slow - we still heavily rely
on plexus for example - so it sounds like an effort which wouldnt pay in
time so I'd likely vote for another fight ;).
>
> Gary
>
> On Thu, Jun 3, 2021, 03:13 Markus Karg <ma...@headcrashing.eu> wrote:
>
> > In the very long term I would be +1 for JAXB, as clearly much more Java
> > programmers on earth are used to JAXB than with Modello due to it being a
> > former part of the JRE. It now is open source at the Eclipse Foundation,
> so
> > we all can contribute to it, which could make it a success story.
> > But I am with Robert here: We need to start with it from the core. So if
> > there is a group of contributors that will change the Maven eco system
> from
> > the core to all plugins, then I would be +1 for that.
> > But we should stay with modello until there are PRs for core and ALL
> > plugins, to prevent a mix.
> > -Markus
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Gary Gregory [mailto:garydgregory@gmail.com]
> > Gesendet: Mittwoch, 2. Juni 2021 14:38
> > An: Maven Developers List
> > Betreff: Re: Moving away from Modello
> >
> > On Wed, Jun 2, 2021 at 8:30 AM Jochen Wiedmann
> > <jo...@gmail.com> wrote:
> > >
> > > On Wed, Jun 2, 2021 at 1:02 PM Elliotte Rusty Harold <
> elharo@ibiblio.org>
> > wrote:
> > >
> > > > What do folks think about slowly moving away from Modello where
> > > > feasible to simplify the build? Does anyone find Modello a net
> > > > positive, especially in longterm maintenance, not just in initial
> code
> > > > generation?
> > >
> > > To me, it sounds feasible to replace Modello with a Sax parser
> > > (reading), and a Sax
> > > event generator (writing), that take as input a bean class (either
> > > written manually,
> > > or generated by Modello, and do the serialization/deserialization.
> > >
> > > Would, most likely, not be a drop-in-replacement, but definitely a
> > medium-term
> > > solution.
> >
> > What about JAXB?
> >
> > Gary
> >
> > >
> > > Jochen
> > >
> > >
> > > --
> > >
> > > Look, that's why there's rules, understand? So that you think before
> > > you break 'em.
> > >
> > > -- (Terry Pratchett, Thief of Time)
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Moving away from Modello
Posted by Gary Gregory <ga...@gmail.com>.
Wouldn't the first step to move from XPP3 to a standard API?
Gary
On Thu, Jun 3, 2021, 03:13 Markus Karg <ma...@headcrashing.eu> wrote:
> In the very long term I would be +1 for JAXB, as clearly much more Java
> programmers on earth are used to JAXB than with Modello due to it being a
> former part of the JRE. It now is open source at the Eclipse Foundation, so
> we all can contribute to it, which could make it a success story.
> But I am with Robert here: We need to start with it from the core. So if
> there is a group of contributors that will change the Maven eco system from
> the core to all plugins, then I would be +1 for that.
> But we should stay with modello until there are PRs for core and ALL
> plugins, to prevent a mix.
> -Markus
>
>
> -----Ursprüngliche Nachricht-----
> Von: Gary Gregory [mailto:garydgregory@gmail.com]
> Gesendet: Mittwoch, 2. Juni 2021 14:38
> An: Maven Developers List
> Betreff: Re: Moving away from Modello
>
> On Wed, Jun 2, 2021 at 8:30 AM Jochen Wiedmann
> <jo...@gmail.com> wrote:
> >
> > On Wed, Jun 2, 2021 at 1:02 PM Elliotte Rusty Harold <el...@ibiblio.org>
> wrote:
> >
> > > What do folks think about slowly moving away from Modello where
> > > feasible to simplify the build? Does anyone find Modello a net
> > > positive, especially in longterm maintenance, not just in initial code
> > > generation?
> >
> > To me, it sounds feasible to replace Modello with a Sax parser
> > (reading), and a Sax
> > event generator (writing), that take as input a bean class (either
> > written manually,
> > or generated by Modello, and do the serialization/deserialization.
> >
> > Would, most likely, not be a drop-in-replacement, but definitely a
> medium-term
> > solution.
>
> What about JAXB?
>
> Gary
>
> >
> > Jochen
> >
> >
> > --
> >
> > Look, that's why there's rules, understand? So that you think before
> > you break 'em.
> >
> > -- (Terry Pratchett, Thief of Time)
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
AW: Moving away from Modello
Posted by Markus Karg <ma...@headcrashing.eu>.
In the very long term I would be +1 for JAXB, as clearly much more Java programmers on earth are used to JAXB than with Modello due to it being a former part of the JRE. It now is open source at the Eclipse Foundation, so we all can contribute to it, which could make it a success story.
But I am with Robert here: We need to start with it from the core. So if there is a group of contributors that will change the Maven eco system from the core to all plugins, then I would be +1 for that.
But we should stay with modello until there are PRs for core and ALL plugins, to prevent a mix.
-Markus
-----Ursprüngliche Nachricht-----
Von: Gary Gregory [mailto:garydgregory@gmail.com]
Gesendet: Mittwoch, 2. Juni 2021 14:38
An: Maven Developers List
Betreff: Re: Moving away from Modello
On Wed, Jun 2, 2021 at 8:30 AM Jochen Wiedmann
<jo...@gmail.com> wrote:
>
> On Wed, Jun 2, 2021 at 1:02 PM Elliotte Rusty Harold <el...@ibiblio.org> wrote:
>
> > What do folks think about slowly moving away from Modello where
> > feasible to simplify the build? Does anyone find Modello a net
> > positive, especially in longterm maintenance, not just in initial code
> > generation?
>
> To me, it sounds feasible to replace Modello with a Sax parser
> (reading), and a Sax
> event generator (writing), that take as input a bean class (either
> written manually,
> or generated by Modello, and do the serialization/deserialization.
>
> Would, most likely, not be a drop-in-replacement, but definitely a medium-term
> solution.
What about JAXB?
Gary
>
> Jochen
>
>
> --
>
> Look, that's why there's rules, understand? So that you think before
> you break 'em.
>
> -- (Terry Pratchett, Thief of Time)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Moving away from Modello
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Jun 2, 2021 at 8:30 AM Jochen Wiedmann
<jo...@gmail.com> wrote:
>
> On Wed, Jun 2, 2021 at 1:02 PM Elliotte Rusty Harold <el...@ibiblio.org> wrote:
>
> > What do folks think about slowly moving away from Modello where
> > feasible to simplify the build? Does anyone find Modello a net
> > positive, especially in longterm maintenance, not just in initial code
> > generation?
>
> To me, it sounds feasible to replace Modello with a Sax parser
> (reading), and a Sax
> event generator (writing), that take as input a bean class (either
> written manually,
> or generated by Modello, and do the serialization/deserialization.
>
> Would, most likely, not be a drop-in-replacement, but definitely a medium-term
> solution.
What about JAXB?
Gary
>
> Jochen
>
>
> --
>
> Look, that's why there's rules, understand? So that you think before
> you break 'em.
>
> -- (Terry Pratchett, Thief of Time)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Moving away from Modello
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Wed, Jun 2, 2021 at 1:02 PM Elliotte Rusty Harold <el...@ibiblio.org> wrote:
> What do folks think about slowly moving away from Modello where
> feasible to simplify the build? Does anyone find Modello a net
> positive, especially in longterm maintenance, not just in initial code
> generation?
To me, it sounds feasible to replace Modello with a Sax parser
(reading), and a Sax
event generator (writing), that take as input a bean class (either
written manually,
or generated by Modello, and do the serialization/deserialization.
Would, most likely, not be a drop-in-replacement, but definitely a medium-term
solution.
Jochen
--
Look, that's why there's rules, understand? So that you think before
you break 'em.
-- (Terry Pratchett, Thief of Time)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org