Re: An Attribute Based POM

[Fabian Christ]

Hi there,

I read through this discussion as a Maven user and (sometimes) plugin
developer and also like the idea of more readable POMs. But I also
agree with Jörg's opinion:

>  +1 for more readable POMs
>
>  I personally like the idea of the attributes because it makes
>  it a lot easier to write the POMs, cause you do not have to
>  open and  close a tag  and may end in
>  foo copy and paste mistakes.
>
>  However when I scanned the big example

>
> I did not get the impression, that it is really easier to read, since your 
> eyes
>  get overdosed by the dominating pattern
>
> 
> so you miss the important things even though it is more compact.

The problem with the pattern  tag of dependencies to group the dependencies. I use this
pattern to keep long lists of dependencies more structured.


   
  ...
  ...
  ...
   
   ...
   ...
   ...


Best regards,
   Fabian

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

Re: [m2] Adding further dependency goals

[Fabian Christ]

Hi,

really great ideas here and I'm looking forward for these new goals. I just
wrote my own deptree-plugin to generate a tree graph with all project
dependencies. When starting this work I was also looking for the right place to
implement such a feature but didn't found the right place - now I know ;-) I
also had problems to extract the right information and with the different scopes
but I hope the new goals will help.

My plugin generates a *.dot [1] file for all dependencies and uses the DOT tool
from [2] to generate a SVG image from it. Looks really cool! By using SVG you
can link subgraphs to other SVG images. This enables you to navigate through a
deptree like clicking through a web site ;-) I tried to attach a sample but it
was to large.

[1] http://www.graphviz.org/cgi-bin/man?dot
[2] http://www.graphviz.org/

- Fabian


Jörg Schaible schrieb:
> Brian E. Fox wrote on Thursday, January 18, 2007 3:34 PM:
> 
>>> This is true, I haven't used dependency:resolve until you
>> mentioned it.
>> I
>>> guess the only difference is that it doesn't show the scope of the
>>> dependencies, but this could be easily resolved.
>> Heh, actually I just added that feature last night before reading
>> this thread. (mdep-57). 
> 
> Really cool :D
> 
> - Jörg
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



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

Re: Manipulating the WAR directory before the WAR file gets built

[Fabian Christ]

Simone Gianni schrieb:
> Steve Loughran wrote:
>> The thing to remember about WAR files is that they are a packaging
>> format that is intended to make it easy to deploy web apps. Not
>> distribute, but deploy. The old WAR/EAR use cases always had the
>> 'assembler' who would be some person who would somehow assemble WARs
>> and EJB beans to make a working app, presumably through some GUI that
>> required the same work to be repeated every release.
>>
>> If you are doing lots of late binding tuning to the WAR file, then
>> perhaps build time is the wrong place to do it; it should really be
>> done as part of the deployment process, where per machine
>> optimisations can go in. In this world what you want from the outset
>> is the exploded WAR, which is then taken with server-specific options
>> to create the target WAR for the target system.
> It's not late binding tuning with custom parameters. For example the
> cocoon plugin was ment to unpack and write some configuration files in
> the WAR, configuration files which are not bindings to external servers,
> but settings for the internal servlets. In that case, it is a build
> problem, and not a configuration one. Also, the web.xml often contains
> directives which are "configuration" in the strict sense (like various
> init parameters), but also contains all the assembly informations of a
> web application, being unable to write plugins that can manipulate these
> file in the build phase is, IMMO, a problem.
> 

Hi together,

I followed with interest your discussion about manipulating a WAR structure
before building the WAR file. Here are some of my thoughts at this topic:

First, the problem is not WAR specific as others here mentioned before. A WAR is
nothing more than a zipped file structure. Now the problems described here arise
when you try to modularize your web application. This is what Cocoon does with
their blocks. Each block consists of Code and of WebApp-Resources. During the
build process the code and the resources are repackaged as a WAR.

A new pre-package phase in Maven might solve some problems that these people
have when modularizing such a WAR. Now there is a concrete phase where such a
job can be done. But I think the problem is more complex.

I had the same problem some time ago and was thinking about something like a WAF
(a Web Archive Fragment). A WAF describes a fragment of a WAR similar to Cocoon
blocks. A WAF contains of a) Code and b) Resources. Now a WAR can depend on
several WAFs that are integrated during the build. Here you get again problems,
e.g.: How do you specify the order in which the WAFs are integrated? How do you
handle conflicts when files from different WAFs are overwritten (patching)? How
can you depend on code from a WAF (same problem with WARs today)?

I came to the idea that at first you have to split code and resources in a WAF.
This means that a WAF can produce two artifacts: a JAR and a file structure. So
Maven must have support for defining projects that can have more than one
artifact as result.

As I said this problems are not WAR specific - other archive structures have the
same problem. I think a general solution can be found here. Such a solution
might look like:

- allow multiple artifacts from one project (code JAR and resources ZIP)
- allow configurable overlay of file structures (resources) with configurable
orders, includes and excludes
- allow file patching during the overlay as different modules might modify the
same file and not overwrite each others changes

By this you don't need something like a WAR plugin in the end as each project
can define itself how the resulting archive is constructed from code and
resources by an overlay mechanism. This is an important use case I think as you
get independent for future archive formats. I know that those ideas are beyond
the current discussion and break the philosophy of Maven in some points but
perhaps someone is interested.

- Fabian

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

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