Brett Porter wrote:
http://jira.codehaus.org/browse/MODELLO-18
when this is fixed it will be possible (however, it will be a non-default
option)
- Brett
On 9/12/05, Jörg Schaible <[EMAIL PROTECTED]> wrote:
Andy Glick wrote on Saturday, September 10, 2005 4:10 AM:
Marco,
When I executed "maven pom:validate" on your project.xml file
I found 2
lines that the Modello generated parser rejected.
1) Maven 1.1 no longer supports XML entities as a means of
including XML
fragments
This is a complete show-stopper for Maven 1.1 for us. We make heavily use
of XML entities for all kind of information in the POMs and we use company
wide system entities and entitiy overload mechanism.
The requirements on a deployed POM have changed greatly between M1 and M2, and
I believe they have have actually changed between M 1.0.2 and M 1.1B1. Because
of the various incompatibility issues that are being mentioned on the list and
because I have to believe that the active community would like to see the
transitions between releases be as convenient and smooth as possible, both for
now and going forward, I wanted to propose that we discuss the possibility of
having development time POM binding and deployment time POM binding.
That would mean that there could be
1) a private form of the POM maintained by the development team in a manner that was compatible with their development conventions and goals
2) a public form of the POM that was a well defined member of a per artifact/version
"upload bundle" that would follow strict conventions so that it can be used in an
as is fashion and supports transitive dependency computation and conflict resolution. The M2
POM & repository models now support much finer grained control and variation than M1 at
the artifact/version level.
3) Some set of default as well as optional interception points to allow the
integration of transformers which could produce a deployment POM from a
development POM
I didn't mention implementation details, because I don't want to muddy the
water. If we can agree that this is an issue that we would like to address, I'm
sure that we will be able to identify candidate implementations.
I'm sorry if this is already under active discussion, but if it is, I missed it
on the lists.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]