Improve dependency consistency and simplify them

May you attach a new patch please? JIRA has munged this one (indentation).

Hi Aslak,

not attaching a patch was intented, because it is some work and introduces some kind of design desicion for the building system. Therefore I only pasted the diff to give an impression, what I would like to do, but I wanted to here first if this would be welcome!

Regards,
Jörg

Aslak, Paul,

can you comment on this proposed change? Is it welcome?

Regards,
Jörg

I think it is a great idea, and would be most welcome as a patch.

build-system.tar.gz

The core files in the new build-system directory.

picocontainer/project.xml.diff

The patch upgrading the project.xml of picocontainer to the entity-based build-system.

Hi Aslak,

my implementation got more radical than I thought myself

Since it is quite some work, I've started now with picocontainer first.
I have attached an archive that contains all the entity files and a patch for picocontainer/project.xml. I have verified that the global and local build works fine and also the local site generation for picocontainer. The entity files are located in a directory build-system (as sibling to the component's directories). If you don't like the name, just put them elsewhere at a general place and adjust the reference at the top of the new picocontainer/project.xml.

At a later stage, this build-system directory may also contain common goals for the maven.xml's (also shared by entities). At the office I have realized a goal, that supports a global project.properties file for maven's multiproject plugin.

Please have a look, I will continue with the other project.xml's if you like it and apply it. IMHO this will make it very easy to share data between all those maven files and keep dpeendencies and versions consistent.

Regards,
Jörg

Hi Alsak,

unfotunately the build was only successful for Linux, but not in Windows, since it does not resolve entity file references in the same way. I had to introduce an entity locator that references the proper entity location in each directory. The global locator and the one for picocontainer is included here in the attached archive. Please unpack it also in the java basedir and add the locator ent files to CVS. Additionally if you want to change the name of the build-system directory, you have to edit the locator files now.

picocontainer/project.xml.2.diff

New version of the patch using the entitiy locator now.

I'm not sure this is really needed. I myself would open TextPad, FindInFiles 3.8.1, OpenAll, change (one by one), SaveAll, build from root.

I think leaving it the way it is means we don't lose a percentage more users just because one more thing is cryptic.

A case of just because we can does not mean we should.

Opinions?

Sorry, Paul, did see your comment on this issue here too late. I'll stop now as requested, that you can make up your mind.

Well, see youself. We have four references for commons-logging in our POMs. What do you think how many different versions we refer? I count three!

I just experienced a problem with this. When going down to a subproject, say servlet, and try to build, I get:

C:\scm\picocontainer\java\servlet>maven -o
__ __

java.io.FileNotFoundException: locator.ent (The system cannot find the file specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at java.io.FileInputStream.<init>(FileInputStream.java:66)
at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:69)
at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:156)
at java.net.URL.openStream(URL.java:913)
at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source)
at org.apache.xerces.impl.XMLDTDScannerImpl.startPE(Unknown Source)
at org.apache.xerces.impl.XMLDTDScannerImpl.skipSeparator(Unknown Source)
at org.apache.xerces.impl.XMLDTDScannerImpl.scanDecls(Unknown Source)
at org.apache.xerces.impl.XMLDTDScannerImpl.scanDTDInternalSubset(Unknown Source)
at org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.commons.digester.Digester.parse(Digester.java:1527)
at org.apache.maven.MavenUtils.getProject(MavenUtils.java:224)
at org.apache.maven.MavenUtils.getProject(MavenUtils.java:161)
at org.apache.maven.MavenSession.initializeRootProject(MavenSession.java:324)
at org.apache.maven.MavenSession.initialize(MavenSession.java:234)
at org.apache.maven.cli.App.doMain(App.java:532)
at org.apache.maven.cli.App.main(App.java:1109)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.werken.forehead.Forehead.run(Forehead.java:551)
at com.werken.forehead.Forehead.main(Forehead.java:581)

(because the relative path to the .ent files is now different). It looks like this externalising of dependencies might be causing more harm than good. And I second Paul's comment: a global search and replace with a decent text editor can do the trick too.

Hello Aslak and Paul,

the problem above arose, since I already used entities in the global POM, although not all POMs were converted. I reverted the changes for this file, so nobody is disturbed.

I am aware that these changes are a little different from the normal usage, therefore I've asked. Since I don't want to make a big issue out of this, I just summarize pros and cons:

Pros:

• Maven has limits if you have a multiproject with a lot of subprojects depending on various other libraries. Entites help to keep their versions in sync, but without introducing a dependency for all (no POM inheritance wanted here). We already have the issue for commons-logging.
• Upgrading for a dependency is a change in a single file and less error-phrone (grep for jar and version is currently not possible)
• By managing the version of the subprojects with dependencies the release of the projects is a change in a single file
• Entities help to reduce redundancy massivly (normally wanted)
• Global project information is not scattered in all subprojects
• Information in POMs is more clearly arranged (have a look at pool's picocontainer's current POM)
• Normal Maven usage is exactly the same, so not even users building the project must care

Cons:

• Unusual, developers have to get used to it and building errors may arise at another stage

Anything else?

So we can:

• revert anything immediately
• finalize it, give it a try and decide in two or three weeks to revert or not (so you have the possibility to get used to it)
• finalize and keep it

Take your choise, you rule

Paul, Aslak,

did you make up your mind concerning this issue?
See our options in the last comment on JIRA.

A complete description is available in Maven's wiki at: http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities

We currently have 6 projects with the entity technique in CVS and I personally do not like the mixture.

Regards,
Jörg

Please roll it back to the way it was before. Using entities is problematic because:

1) It makes it impossible (AFAICT) to build individual subprojects separately

2) It creates more confusion and makes the build system harder to understand (Maven is hard enough already).

The problem that entities is solving can also be solved with a simple text editor that supports search/replace over multiple files.

Changes reverted.