Re: jtidy

[Stefan Bodewig]

On Tue, 12 Oct 2004, Adam Jack [EMAIL PROTECTED] wrote:

 The jtidy build.xml vanished, so it is Maven or nada. Anybody else
 tempted to package jtidy

Yep.

Depends on the answer to my question below and/or how easy a migration
to a Maven build would be.

 -- it is the last step before Cocoon, it seems. That, or somehow we
 need to tackle this list below.

Brett, if we built all those plugins from source, would we be able to
use the freshly compiled versions of them in Maven using jar overrides
or something?  Or would this involve changing the Maven installation?

I'm very reluctant to make more parts of our build systems installed.

Stefan

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

RE: jtidy

[Stephen McConnell]

 -Original Message-
 From: Brett Porter [mailto:[EMAIL PROTECTED]
 Sent: 13 October 2004 09:19
 To: Gump code and data
 Subject: Re: jtidy
 
   -- it is the last step before Cocoon, it seems. That, or somehow
we
   need to tackle this list below.
 
  Brett, if we built all those plugins from source, would we be able
to
  use the freshly compiled versions of them in Maven using jar
overrides
  or something?  Or would this involve changing the Maven
installation?
 
 I'll give a more explanatory answer, but the short answer is that it
 doesn't require changing the Maven installation, so this should be
 easy enough.
 
 plugins are a bit interesting in Maven 1.x.
 
 There are installation-wide plugins in $MAVEN_HOME/plugins
 There are user plugins in $MAVEN_HOME_LOCAL/plugins (usually
 $HOME/.maven/plugins)
 
 to gump, I imagine we never go near the second one, and only change
 the first one when we start building Maven from source.
 
 Then there are runtime only plugins - specified as dependencies (as in
 the case above), or built as part of a maven build using the reactor
 (see geronimo, I think).
 
 Since these ones are dependencies, they can be built using gump and
 handled as regular dependencies with jar overrides. They will not
 affect other projects, as they are not installed into either of the
 two locations above - just loaded into memory for the current maven
 run and forgotten once it stops.
 
  I'm very reluctant to make more parts of our build systems
installed.
 
 Not exactly what you mean by installed here. I agree that they
 shouldn't be installed in Maven for all builders to use.
 
 I think that they have to be treated as with other dependencies: use
 jar overrides. But whether you build them from source, or package them
 is up to you. I'd say building them is unlikely to be problematic
 (unless they have some obscure dependencies): plugin:plugin is a very
 simple goal.

Brett:

Any ideas what will happen when a project declares a dependency on a
artifact in both the project.xml and the gump project definition, and
the plugin itself is not built by maven?

This is the case with a plugin in the avalon repository that is build by
Magic and used in Maven under the Fulcrum project.

Steve.




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

Re: jtidy

[Brett Porter]

 I really haven't followed Maven development, but when we tried to list
 the dependencies last time, some things (werkz is something I
 remember) simply were unbuildable if not un-findable.
 
 We'll sort that out, I'm sure.

I thought the issue was dom4j - since resolved.

There are things like werkz, forehead, comons-grant which are pretty
much dead outside of Maven. The plan is to fold them in for Maven 1.1,
as they are quite small.  But we'll still build them for now.

We'll sort something out.

Cheers,
Brett

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