Re: Changes necessary in StAX to get it on par with DecentXML

[Aaron Digulla]

Quoting Jochen Wiedmann <[EMAIL PROTECTED]>:


That didn't work well. Okay, since you don't believe me, here is an
(incomplete) list of changes I would need in StAX to be able to use it for
my work instead of having to write my own XML parser.


I think here is a misunderstandment. The question was not (at least
not IMO) whether you could rewrite DecentXML to use StAX, but whether
you could give DecentXML a StAX API. That way Maven components could
basically trust in a standard API, except for the cases where the
differences matter.


Internally, DecentXML uses a StAX-like API (the DOM parser part uses a  
tokenizer to break the input into pieces). The problem is that I can't  
base DecentXML on StAX because StAX throws information away that I  
need and I can't offer a StAX-compatible API because StAX isn't meant  
to keep the information I need to preserve.


I could create a filter class which strips the information that  
DecentXML provides down to a StAX API but that would still be useless:


1. Case: You read POM files to create an object model. Here, you would  
gain nothing except you'd have to look for new bugs.


2. Case: You read POM files to filter them. Here the StAX API is  
useless because it throws too much information away, so this code  
would have to be written from scratch using an incompatible API  
anyway, no matter how you solve it.


That said, I've written a Maven search'r'replace tool using DecentXML.  
It's standalone (no dependencies besides DecentXML and Java's rt.jar),  
it can search pom.xml files with certain elements/texts and on these  
files, it can print certain parts (search), check that certain parts  
have certain values (for example, that all parent elements have the  
right version in them) and it can replace existing values with new ones.


The source is roughly 400 lines:  
http://code.google.com/p/decentxml/source/browse/trunk/src/test/java/de/pdark/decentxml/MavenSNR.java?r=34


What I would like to see is that Maven keeps the StAX API internally  
to build the POM and to do its job. Only when a plugin needs to  
*manipulate* XML that a *user* has written *by hand*, it should use  
DecentXML. Currently, I know only of these plugins which fall into  
that category:


- archetype
- war
- version

All other plugins wouldn't gain enough from a transition to make the  
effort worthwhile.


Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Changes necessary in StAX to get it on par with DecentXML

[Aaron Digulla]

Hello,

That didn't work well. Okay, since you don't believe me, here is an  
(incomplete) list of changes I would need in StAX to be able to use it  
for my work instead of having to write my own XML parser. Note: If you  
feel like asking "who would ever need that?" while reading that list,  
then my answer is that I didn't want this mail to become 100KB long,  
so I won't tell you all the reasonings which finally distilled into  
the list below. I'm working with XML for 10 years, now, I have used  
almost every XML tool out there and none of them could cover all the  
ground I need to plow.


- Remove final from class XmlReader
- The interface Attribute needs a new method which returns the raw  
value read by the parser (i.e. without " expanded)
- The interface Attribute needs a new method to specify the quote  
which was read/should be used during writing
- The reader API must allow a way to return entity references  
unexpanded plus a way to expand the references during parsing and later
- The StartElement must be extended to allow to specify the order in  
which attributes and name space declarations where in the input
- A way to find out if the namespace was given by prefixing the  
element name or by using an xmlns attribute.
- There must be a special text element which can be used everywhere  
where Attribute is used.
- The writer is probably powerful enough; I'd just use writeRaw() in a  
lot of places (which kind of defeats the purpose but it would work).


Since the client API should ignore anything it doesn't understand, it  
might be possible to implement this without breaking client code but  
I'm only 80% sure of that at this time.


That would get me about 30% to where I am now with DecentXML, because  
DecentXML doesn't only read XML, it also creates a DOM-like structure  
for me, which I can navigate and modify. As far as I can see, stax  
doesn't have any support for collecting the data in a smart data  
structure.


These are the reasons why I don't think that StAX would be the right  
tool for my task, why I think that no amount of work spent on it would  
ever make it the right tool. Even if I spent the time, the result  
would be as non-standard as DecentXML and DecentXML already does what  
I need after three days of work.


I have poured the wisdom of 10 years working with various XML parsers  
and tool and that is why I'm so confident that no other XML tool can  
do what it can.


I'm not 100% sure whether StAX could be modified to allow to  
modify/filter POM files without too much disruption, because POM uses  
only a small subset of XML. But then, Maven POMs are only 1% of my  
daily work and I need a tool that can solve the other 99% as well.


A lot of people find that XML can do whatever they need but when I  
asked them, after a bit of poking, the real answer is that they  
actually needed something else but gave up on it, because they  
eventually realized that no tool on the market gave them the necessary  
flexibility to do it. So again, the available tools have limited what  
they can do instead of the other way around. That is the issue  
DecentXML tries to solve.


Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: POM rewriting with DecentXML

[Aaron Digulla]

Jochen Wiedmann schrieb:

>>> particular mode, one could supply and accept additional events. In the
>>> case of white space around attributes, you could offer an extension of
>>> the Attribute interface that informs about whitespace to the left and
>>> to the right.
>> That's great. Can I also add new getters to the Attribute interface? ;)
> 
> Aaron, I know you since the early Amiga days quite well and have a
> very high opinion of you. So believe me: Such nonsense is way beyond
> your abilities. Or do I really need to point out how you can extemd an
> API, exposing additional powers, without loosing upwards
> compatibility, by extending interfaces or adding methods to
> implementations?

My point is that you can't extend an API which is part of a standard.
Either the standard already contains means to save the information I
need to add or there is no way to keep it.

What drives me so mad is that no one here on the list takes the five
minutes to even try to understand what I'm talking about.

>> Okay. Look at the last example in the tutorial 
>> (http://code.google.com/p/decentxml/wiki/Tutorial).
>> If StAX can pass this test case, I'm willing to have a look.
> 
> I know how difficult it can be to keep XML syntax from a lot of
> experience. Typical areas of trouble are internal DTD (which we
> hopefully no longer need to bother with, thanks heaven) and (as you
> have pointed out) white space within opening and closing tags. But
> that example is almost trivial. I think you are underestimating the
> power of SAX, StAX, and friends quite a lot.

Despite the example being so trivial, I haven't seen a single XML parser
who can do this:

- Create a document
- Add a single root element
- Add two attributes
- Insert a newline between two attributes
- Write the document to a file

You can't do it. The XML standard allows it as input but there is no API
to do that for the output. The space between attributes is a limbo. Same
goes for comments before the root element in DOM. SAX can't do it, DOM
certainly can't do it and StAX can't do it either.

I challenge you to prove me wrong. Send me a piece of code which I can
compile against any existing XML parser to prove me wrong (and it must
be a parser. System.out or FileWriter isn't a parser; of course you can
do that manually).

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://darkviews.blogspot.com/  http://www.pdark.de/

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

Re: POM rewriting with DecentXML

[Aaron Digulla]

Stuart McCulloch schrieb:

>> Why not fix StAX?
>> Because StAX is not meant to do this. I need to keep the original XML
>> source somewhere to be able to recreate anything you might have done. That
>> includes entities (and how you entered them originally) and all kind of
>> weird stuff that every XML parser out there throws away.
> this isn't necessarily true - you could take the XML source and map
> it into a model that's used by the application - later on you'd take the
> modified model and compare (diff) it against the original model and
> use this to rewrite sections of the XML source while keeping the rest
> undisturbed... (using indexing to improve performance/tracking)

Right. And I could have China paint the moon in red so that I can write
"Coca Cola" on it. ;)

>>  As I said: My parser is probably not so useful as a general purpose
  replacement for POM *reading* in general. It ought to be used in  the 
 Maven
 artifact plugin and any other code which *writes* POM  files.

>>> If we've read in the model using the tools that we currently use which
>>> knows about everything about the whitespace, and then manipulate the
>>> model in memory how exactly would we integrate your writer?
>>>
>> Same issue as above. My suggestion is to keep the model reader as it is. If
>> you write a plugin which wants to manipulate any kind of XML, you add a
>> dependency to DecentXML, read the XML, manipulate it and write it out.
> 
> which kind of sucks if you want to pass the model around collecting
> changes from different components - then everyone would have to
> use the DecentXML document, otherwise you'd lose the formatting.

That's one way. Another way would be to generate XML after each step and
pass that on.

Secondly, in the patch I've sent you, I directly modify the StringBuffer
after I've located the bit that should change. So you could hand each
component this buffer.

It would mean some overhead for parsing the document every time but the
documents are small and the parser is very fast.

Thirdly, all components should preserve the formatting and DecentXML is
the only way to do that, so each component has to use it anyway.

>> My solution returns a complete XML document to begin with, so the setup is
>> just a single line of code and then you can start working on the document.
> 
> your solution is interesting, but I think you'd get more support if you
> stopped dissing everything else - there's been a lot of innovation in
> this area already and I expect there's still more to come.
> 
> at least have a serious look at StAX and see if it could be improved

Make StAX pass the test I've sent to the list and I'll have a look. From
what I know, it can't pass this test because it throws that information
away before anyone can see it.

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://darkviews.blogspot.com/  http://www.pdark.de/

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

Re: POM rewriting with DecentXML

[Aaron Digulla]

Stuart McCulloch schrieb:

>> Sorry. I've written code with about any XML parser out there and none of
>> them would even get close to what DecentXML can do. In DecentXML, there are
>> no private fields or methods. Everything is meant to be extended or reused.
>> It's meant to be useful instead of limiting what you can do.
> 
> ouch, there's a reason to use private fields, etc. - if you open everything
> up then you don't know what people are using and can't be sure that you
> don't break them when you change or refactor your implementation

That's a non-issue for OSS software. If a user used something from 1.1
that's gone in 1.2, he has three options:

1. He can chose *not* to upgrade. Nothing forces him to.

2. He can backport the changes he needs from 1.2

3. He can modify his code to work with 1.2.

Of course, with closed software, you have no choice but #3.

That said, I of course try to make no breaking changes and the
information that I offer is basic. It can't be broken down further or
aggregated in any useful way with other information, so even if I have
to change some internal details, this information will be still around.

>> That said, I haven't thought about building Maven on DecentXML and get rid
>> of StAX. Pull parsers are a step forward to what we had before (SAX&DOM) but
>> they still suck (any parser sucks, pull parsers just suck a bit less).
> 
> *any* parser sucks? does that include DecentXML? ;)

It sucks least. For me. :)

>> As of right now, there are two reasons not to use XML:
>>
>> 1. You documents are huge (10MB and more)
> 
> kind of orthogonal to choosing a parser - besides I can write large
> documents in any format

Well, all parsers that build context for you (so you don't have to track
it yourself), need the memory to keep the whole document in memory.

That said, I haven't tried DecentXML with a big document yet. I've tried
to make it memory conservative (I'm an old C64 guy; I hate to waste
bytes), so it won't allocate memory for a lot of things until it has to
(for example, if your elements don't have attributes, each element will
only need 4-8 bytes for the null pointer)

> 2. You must be compliant to some API.
> 
> I actually like APIs, because it gives me confidence I can swap in other
> implementations later on

You still believe that? ;) Okay ... have you ever tried to replace
Xerces with Crimson or the other way around? Both are SAX parsers and
both are SAX compliant and if you do, you will have the most strange
errors plus some of your code probably won't work because you needed
that one feature which wasn't in the standard ...

Further more, there usually is one implementation which fits you need so
you will never ever do that and any minute spent of making it compatible
is most likely wasted.

As for DecentXML, I've considered to make it Duck-typing compatible to
JDOM (so you can replace the JAR and recompile and you shouldn't have
many errors). Didn't have the time nor the pressure, yet.

I also considered to make the API compatible to java.util.List to make
it more natural to work with child nodes, etc. But that would mean a
major breaking change in the API and I'm not sure it's worth the effort.

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://darkviews.blogspot.com/  http://www.pdark.de/

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

Re: POM rewriting with DecentXML

[Aaron Digulla]

Stuart McCulloch schrieb:

>> For example, the first version of the m2eclipse POM editor would remove all
>> comments after "Add dependency". That's not cool. Those comments contained
>> references to web pages and explanations why some stuff was set up "oddly".
> 
> yeah, I hate it when an editor zaps all the intermediate comments and
> whitespace - that's why in the past I've used a modified version of the
> plexus XML parser that preserves comments and maintains consistent
> indentation levels:  (although it definitely doesn't preserve 100%)
> 
> http://www.ops4j.org/projects/pax/construct/maven-pax-plugin/xref/org/ops4j/pax/construct/util/RoundTripXml.html
> 
> bit hacky, but was good enough for my purposes at the time :)

That was the first time I thought about writing my own XML parser but
only when I need to replace the parent version in 200 POM files, I
actually started to do it.

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://darkviews.blogspot.com/  http://www.pdark.de/

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

Re: POM rewriting with DecentXML

[Aaron Digulla]

Quoting Michael McCallum <[EMAIL PROTECTED]>:


On Tue, 05 Aug 2008 19:28:47 Aaron Digulla wrote:

I mean, there was *no* XML parser which can do 100%  
round-tripping before DecentXML. It's just a non-issue for the XML guys.


xom using xerces 2.6.7 was supposed to be able to do a complete round trip,
have you disproved that?


Yes. SAX parsers can't do 100% perfect round-tripping, they always  
lose some information, for example, whitespace in elements (i.e. when  
you put every attribute in it's own line and things like that).


Also, attribute values come with entities already expanded, etc.

There are more cases but these are the ones which are most simple to  
explain :)


Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: POM rewriting with DecentXML

[Aaron Digulla]

Quoting Stephen Connolly <[EMAIL PROTECTED]>:


You can fix StAX, we know the authors. Even if you added an extension
property that turned on better whitespace handling that would be fine. I'm
not keen on pulling in another XML parser to be honest.

+1000...


*sigh*

Okay. Look at the last example in the tutorial  
(http://code.google.com/p/decentxml/wiki/Tutorial). If StAX can pass  
this test case, I'm willing to have a look.


Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: POM rewriting with DecentXML

[Aaron Digulla]

Quoting Jason van Zyl <[EMAIL PROTECTED]>:

StAX can't preserve whitespace between attributes, between "<" and   
the element name, whitespace after the last attribute and the ">",   
between "parsers.


Why not fix StAX?


Because StAX is not meant to do this. I need to keep the original XML  
source somewhere to be able to recreate anything you might have done.  
That includes entities (and how you entered them originally) and all  
kind of weird stuff that every XML parser out there throws away.


In my code, I tokenize the XML source and then keep references to  
these tokens. Can StAX do that? Do I have full access to the unicode  
input stream? Can I patch the tokenizer?


Later, in your POM reader, you turn the XML events into a Java object  
model. At this stage, all the information I've gathered is thrown  
away. So even if I could extend StAX to keep the necessary bits, you  
would still have to rewrite your POM readers to save the XML tokens  
somewhere and then, later, when we want to recreate the POM, you would  
have to collect that information from the various bits and pieces.


And even if that would all work ... how would you preserve the  
original order of XML elements from the Java version of the POM? I  
mean, it's nice and all that I can iterate over the dependencies but  
is the original order preserved?


Sorry, Jason, your arguments only tell me that you haven't thought  
this through.


As I said: My parser is probably not so useful as a general purpose  
 replacement for POM *reading* in general. It ought to be used in   
the Maven artifact plugin and any other code which *writes* POM   
files.


If we've read in the model using the tools that we currently use which
knows about everything about the whitespace, and then manipulate the
model in memory how exactly would we integrate your writer?


Same issue as above. My suggestion is to keep the model reader as it  
is. If you write a plugin which wants to manipulate any kind of XML,  
you add a dependency to DecentXML, read the XML, manipulate it and  
write it out.


There is no way to read the XML with tool A and then write it out with tool B.


You can fix StAX, we know the authors. Even if you added an extension
property that turned on better whitespace handling that would be fine.


StAX is just another XML parser. It might be better for round-tripping  
than SAX and all the other crap but so far, you've failed to convince  
me that you even understand what the issue is, so I can't trust your  
trust in StAX :)


That said, how do you manipulate the result of what StAX gives you? I  
mean, StAX is a streaming API. Which means I would have to build a  
model from the XML events returned by StAX. Only then, I could  
manipulate that XML document.



I'm not keen on pulling in another XML parser to be honest.


I know that. I don't have a better solution because there probably  
isn't. I don't start forks just because of the fun of it. This is  
essential an unsolved problem in the XML space, it's been unsolved  
since XML was invented and it won't ever be solved because it's a  
corner case. I just happen to be in that corner very often, so I  
finally gave in and started on a solution.


My solution returns a complete XML document to begin with, so the  
setup is just a single line of code and then you can start working on  
the document.


Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: POM rewriting with DecentXML

[Aaron Digulla]

Quoting Jochen Wiedmann <[EMAIL PROTECTED]>:


As for patching it: StAX is a standard API (JSR-173). How big are my chances
that the standard API is going to be extended to allow the features I need?


No API forbids extending.


In Java, APIs are written by paranoid control freaks ;) Just try to  
add a line number to org.jdom.Element... It *ought* to be possible ...  
maybe with a little bit of reflection, setAccessible(true) and a smart  
classloader ...



In the case of a StAX parser, one could by
default supply and accept the standard event types. However, in a
particular mode, one could supply and accept additional events. In the
case of white space around attributes, you could offer an extension of
the Attribute interface that informs about whitespace to the left and
to the right.


That's great. Can I also add new getters to the Attribute interface? ;)

Sorry. I've written code with about any XML parser out there and none  
of them would even get close to what DecentXML can do. In DecentXML,  
there are no private fields or methods. Everything is meant to be  
extended or reused. It's meant to be useful instead of limiting what  
you can do.



As I said: My parser is probably not so useful as a general purpose
replacement for POM *reading* in general. It ought to be used in the Maven
artifact plugin and any other code which *writes* POM files.


Unfortunately, these can hardly be separated. At least from a software
architects point of view, I'd strongly argue against two completely
different approaches for reading POM files.


You gave the answer to that yourself:


Look, that's why there's rules, understand? So that you think before
you break 'em.


As long as the current standard XML tools can't do what we need, we  
need a second tool.


That said, I haven't thought about building Maven on DecentXML and get  
rid of StAX. Pull parsers are a step forward to what we had before  
(SAX&DOM) but they still suck (any parser sucks, pull parsers just  
suck a bit less).


I haven't tried to write a XML->OO mapper with DecentXML, yet, but  
it'll probably be more simple to do than with anything else in the  
market. One of the reasons is that you can extend and override methods  
in XMLParser, so you could call the parser and get a Document back  
whose root element is a Project object. Or have Project extend Document.


That would allow you to merge the XML and the OO API into one. Not  
sure if that was smart but at least, you have the choice.


Or you could use the XML tokenizer directly to slurp in the POM.  
Another choice which might make sense in 1% of all the situations.  
Most people will never do that, of course, but the 1% sure will be  
happy to be able to without having to invent the wheel again.


AFAIK, DecentXML is also the only XML parser out there which allows  
you to access the class which turns a byte stream into unicode (see  
XMLInputStreamSource).


As of right now, there are two reasons not to use XML:

1. You documents are huge (10MB and more)

2. You must be compliant to some API.

Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: POM rewriting with DecentXML

[Aaron Digulla]

Quoting Stuart McCulloch <[EMAIL PROTECTED]>:


StAX can't preserve whitespace between attributes, between "<" and the
element name, whitespace after the last attribute and the ">", between "

personally speaking, I don't actually mind if  is changed to 
for me preserving comments and the general layout, such as indentation
is much more important than attribute spacing.


Same here, but how about newlines in the project element to keep the  
namespace declarations in view?



as Milos mentioned: how do you decide where to slot new elements, like
dependencies if there weren't any dependencies in the original pom - are
they always appended? do they inherit the surrounding indentation?


DecentXML doesn't try to be smarter than you. It just gives you all  
the tools to get what you want. It doesn't throw information away  
which was in the original file, so you can examine it and make an  
educated guess what would probably look right.


Even if it's not 100% correct, it will at least preserve all comments  
and processing instructions and other special XML data because the guy  
who wrote that XML probably had a reason to write it the way it is.


For example, the first version of the m2eclipse POM editor would  
remove all comments after "Add dependency". That's not cool. Those  
comments contained references to web pages and explanations why some  
stuff was set up "oddly".



Just looking at an XML gives you a visual clue: these guys couldn't care
less how it *looks* as long as their tools can read it.


usually I'm more concerned about getting it working than the *look*, in
fact often what I need is an XML formatting tool that I can apply to our
poms to make them consistent (ie. like formatting code in an IDE)


In that case, DecentXML is for you. With it, you can pick all the  
whitespace in the POM file (and *only* that) and replace it with  
something that is more correct. It will leave comments, etc. alone.


Or you can also reorder the elements without messing with the indentation.

I've been thinking about such a cleanup tool myself. All the POM  
creators create POMs which look different, which have a different  
indentation, different order of elements, etc. With DecentXML, all  
that could be fixed without messing with parts of the XML which we  
might want to preserve.


Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: POM rewriting with DecentXML

[Aaron Digulla]

Quoting Milos Kleint <[EMAIL PROTECTED]>:


how do you deal with newly added content? just overwriting a value for
existing elements is relatively easy.
I mean if I add a new dependency to the pom file, how do I make sure
it's properly indented? That's been the major issue for me now with
the jdom modello writer (which I wrote). I don't really care if it
screws up attribute spacing, but newly added content needs to fit in.


The most simple solution is to search for an existing dependency and  
then copy any whitespace before it plus the dependency itself and then  
overwrite the text content of groupId, etc, of the copy.


If that doesn't work, search for an element in the same level as  
"dependency", "dependencies", etc., check the whitespace before that  
and duplicate it as necessary.


Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Just released DecentXML 1.1

[Aaron Digulla]

Hi,

I've released DecentXML last Friday.

Changelog: http://code.google.com/p/decentxml/wiki/Changelog

Tutorial: http://code.google.com/p/decentxml/wiki/Tutorial

In SVN you can find 1.2-SNAPSHOT which has a TreeIterator, too.

I suggest everyone who *writes* POM and other XML files to have a look  
and let me know if you're missing something that would make your life  
easier.


Currently, I've released the code under the New BSD License. Let me  
know if you need something else. I'm happy to release this code under  
any license on earth.


Now ... how do I get this stuff on central? :)

Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: POM rewriting with DecentXML

[Aaron Digulla]

Quoting Jason van Zyl <[EMAIL PROTECTED]>:


But I think looking at StAX and possibly trying to patch that to be
smarter about formatting, if necessary, might be a better route for us.


StAX can't preserve whitespace between attributes, between "<" and the  
element name, whitespace after the last attribute and the ">", between  
"

Not sure about CDATA but I guess StAX can't preserve that, either.  
Lastly, StAX is about *reading* XML. DecentXML is about *writing* XML  
*preserving* the original format 100%, no compromises.


As for patching it: StAX is a standard API (JSR-173). How big are my  
chances that the standard API is going to be extended to allow the  
features I need? I mean, there was *no* XML parser which can do 100%  
round-tripping before DecentXML. It's just a non-issue for the XML guys.


Just looking at an XML gives you a visual clue: these guys couldn't  
care less how it *looks* as long as their tools can read it.


As I said: My parser is probably not so useful as a general purpose  
replacement for POM *reading* in general. It ought to be used in the  
Maven artifact plugin and any other code which *writes* POM files.


Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: POM rewriting with DecentXML

[Aaron Digulla]

Michael McCallum schrieb:
> there is already  that is worth considering... its goal 
> is 
> correctness and roundtripability ;-)... its mature and stable... i have used 
> it and been very happy

xom doesn't preserve whitespace in elements (no XML parser besides
DecentXML can do that) and it doesn't preserve CDATA and entities.

Also, you can create elements with special whitespace between the
element attributes, for example.

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://darkviews.blogspot.com/  http://www.pdark.de/

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

Re: POM rewriting with DecentXML

[Aaron Digulla]

Hi,

I've finished all the main features and released version 1.0 of
DecentXML on Google Code: http://code.google.com/p/decentxml/

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://darkviews.blogspot.com/  http://www.pdark.de/

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

Re: POM rewriting with DecentXML

[Aaron Digulla]

Jason van Zyl schrieb:

>> It's official: I'm through with the W3C and the stupid XML parsers which
>> came in it's wake. To allow to write XML filters and editors which don't
>> ruin the layout, I've started my own XML parser project "DecentXML".
> There are a couple that are decent. XMLBeans does a good job of not
> completely mutilating the XML, and the code that's been created for
> m2eclipse using EMF is pretty good as well. Netbeans is still using some
> JDOM based code that is not bad either.

None of them can preserve whitespace in elements (between attributes,
for example or in the end tag).

For XMLBeans, you need to define POJOs for all any any elements in the
XML that you want to process. Not suitable for a generic XML
search'n'replace tool.

EMF has a classpath that is longer than my attention span which not
documented anywhere. I'm past guesswork in my job.

JDOM has the best XML API so far but it's still based on Java 1.4, so
the code is pretty expressive ... lots of "ceremony".

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://darkviews.blogspot.com/  http://www.pdark.de/

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

Re: POM rewriting with DecentXML

[Aaron Digulla]

Quoting John Casey <[EMAIL PROTECTED]>:


I've got some code ready for you to try:
http://www.pdark.de/decentxml-1.0-SNAPSHOT-src.tar.gz

wrong list? :)

still, sounds cool. Are you parking this at SF or Codehaus or anywhere
like that? :-)


Currently, I'm hosting that on my own server; this was a mad dash (I  
wrote the whole thing in about ten hours), so I hadn't had the time to  
plan how to release the project.


Regards,

PS: Guys, please learn to quote :)

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: [VOTE] Release Maven Filtering version 1.0-alpha-1

[Aaron Digulla]

Quoting Olivier Lamy <[EMAIL PROTECTED]>:


Hi,
In preparation of the maven-war-plugin, I'd like to release and
promote out of the sandbox the maven-filtering component version
1.0-alpha-1.
The goal of this component is to provide a common tool for maven
plugins to filtering resources.


If you're planning to filter XML files, too, you might want to have a  
look at my new XML parser DecentXML. It's designed to be able to  
modify existing XML files with the least amount of disruption.


Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: POM rewriting with DecentXML

[Aaron Digulla]

Quoting Brett Porter <[EMAIL PROTECTED]>:


I've got some code ready for you to try:
http://www.pdark.de/decentxml-1.0-SNAPSHOT-src.tar.gz

wrong list? :)


I've seen three Maven plugins which use their own code to manipulate  
POM and other XML files in projects, so I guess this is the right list  
to announce such a project.


Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

POM rewriting with DecentXML

[Aaron Digulla]

Hi guys,

It's official: I'm through with the W3C and the stupid XML parsers which
came in it's wake. To allow to write XML filters and editors which don't
ruin the layout, I've started my own XML parser project "DecentXML".

The main goals are to provide a library to manipulate exiting (small)
XML files with the least amount of disruption plus good error handling
(like telling line and column numbers) and an easy to use API.

And no, it's not W3C compliant. And it never will be. That's the whole
point :)

I've got some code ready for you to try:
http://www.pdark.de/decentxml-1.0-SNAPSHOT-src.tar.gz

It can read XML 1.0 including namespaces, manipulate it (not completely
but all common operations are supported) and write it back.

As time permits, I'll get the test coverage above 90% tomorrow plus I'll
replace toXML(StringBuilder) with toXML(Writer).

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://darkviews.blogspot.com/  http://www.pdark.de/

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

Re: Is there a way to use a property as the version of a parent pom?

[Aaron Digulla]

Quoting Stephen Connolly <[EMAIL PROTECTED]>:


you can use -DparentVersion=[1.3.4]

to force a specific version and it rewrites the pom without changing
any formatting or comments


That sounds very promising!

In fact, I've just downloaded the "patch" and found it's a complete plugin.

Here are a few suggestions:

1. Create a new project on CodeHaus for this plugin instead of trying  
to get this plugin into maven core.


2. Rename the plugin to "pom" (for pom modification)

3. Make the plugin more general, i.e. allow to specify a simple XPath  
on the command-line and a replacement. Kind of XML search'n'replace.


4. Work on the current POM and all POMs in all sub-modules.

Since I need this pretty urgent, I'm willing to help to develop this.  
I'll send you a patch to your private address later today.


Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: Is there a way to use a property as the version of a parent pom?

[Aaron Digulla]

Quoting Ralph Goers <[EMAIL PROTECTED]>:


It is currently working as designed. Maven won't resolve properties for
any of the items in the parent section. The pom below would be a
problem if it was actually installed into a repository as it would
require that the property be specified even if the artifact was a
transitive dependency.


I don't follow you here. In the parent pom.xml, I use normal   
version numbers. All I want is that the current pom.xml allows a   
property as the version of the parent POM. Even if the current POM   
gets installed in a repository, it's no problem because (just like   
when it's local), the property must be set when it's   
loaded/resolved/whatever.

This is a problem. Anyone who wants to use your artifact, or anyone who
wants to use an artifact which uses your artifact would have to set the
property. Worse, they really wouldn't have any idea what the proper
version should be.


Well, we need this only internally. Then, if you really wanted to, you  
could add a comment to the pom to give a hint which version to use and  
you could give an explanation in the website.


And if all else fails, you could just look in the repository to see  
which versions are available. I mean, this is not some info which has  
no context. This is part of a project and that means that you have  
more ways to transfer this information (which is vital since you need  
that feature).


Does that mean that I could omit the version tag and just use   
relativePath? That would work for me. Is that patch for 2.0 or 2.1?

No, you would need the version tag with the version being a "special"
symbol. While omitting the version would be nice I'm sure it would
break all kinds of existing use cases and that can't be tolerated.  I
am targeting 2.0, but only if I can be sure it won't break any builds.


And timeframe for a patch to try?

I'm aware that there are plans to allow "includes" in Maven 2.1 but  
 I'd like a solution for 2.0.

I'm not really sure what you mean by this. I'm not aware of "includes".


In 2.1, you can build a POM by using fragments (I don't remember the  
real name and I couldn't find anything in the Wiki right now). It's  
kind of like having several parent POMs where each of them adds a  
certain piece of info.


Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: Is there a way to use a property as the version of a parent pom?

[Aaron Digulla]

Quoting Stephen Connolly <[EMAIL PROTECTED]>:


What is the most simple way to include common dependencies, plugin configs
and properties in many POMs?
[...]

please vote for http://jira.codehaus.org/browse/MOJO-1178

This has a goal called update-parent that will update the parent version in
the pom to the latest available.


Dear me, no! What I want is to update to a specific version. Also,  
rewriting the POM.xml means that I'll loose all comments and  
formatting. No thanks.


Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: Is there a way to use a property as the version of a parent pom?

[Aaron Digulla]

Quoting Ralph Goers <[EMAIL PROTECTED]>:


It is currently working as designed. Maven won't resolve properties for
any of the items in the parent section. The pom below would be a
problem if it was actually installed into a repository as it would
require that the property be specified even if the artifact was a
transitive dependency.


I don't follow you here. In the parent pom.xml, I use normal version  
numbers. All I want is that the current pom.xml allows a property as  
the version of the parent POM. Even if the current POM gets installed  
in a repository, it's no problem because (just like when it's local),  
the property must be set when it's loaded/resolved/whatever.


I mean, the repository server isn't going to try to use that string  
for anything, is it? Maven will download the file, parse it and  
complain if the property isn't set.



I am working on a modification that allows the version to be obtained
by reading the pom located at the relativePath and getting the version
from it, but I still have a couple of issues to resolve. It wouldn't
solve your case though, as even there it won't actually accept a system
property for the version.


Does that mean that I could omit the version tag and just use  
relativePath? That would work for me. Is that patch for 2.0 or 2.1?


What is the most simple way to include common dependencies, plugin  
configs and properties in many POMs?


I'm using  but as it is, I have to update the version numbers  
in about 100 files when I change the different parent POMs (and no,  
the parent pom is not "../pom.xml"; it's somewhere else in the tree  
and I have three different "parent" POMs).


I'm aware that there are plans to allow "includes" in Maven 2.1 but  
I'd like a solution for 2.0.


Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Is there a way to use a property as the version of a parent pom?

[Aaron Digulla]

Hi,

This may sound silly but I can't get this to work:


ch.globus
globus-parent-pom
${version.globus-parent-pom}



I tried to define the property via settings.xml, via  
%HOME%\mavenrc_pre.bat and directly on the command line. No luck.  
Maven doesn't seem to resolve properties for parent POMs.


Why is that? Is that a bug?

Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: SUREFIRE-491 copying sys props to forked process

[Aaron Digulla]

Dan Fabulich schrieb:

> The sad tale of SUREFIRE-491 began when I tried to fix SUREFIRE-121.
> 
> http://jira.codehaus.org/browse/SUREFIRE-491
> http://jira.codehaus.org/browse/SUREFIRE-121
> 
> The request seemed innocent enough.  Wouldn't it be cool if you could
> pass system properties to your tests, like this?
> 
>   mvn clean test -Dbrowser=firefox
> 
> Apparently this used to work in an earlier version of Surefire, even.
> What could go wrong?
> [...]
> Any other suggestions before I just roll ahead with this?

IMHO, the correct fix would be to collect command line properties
somewhere in the model and copy only *those* to the child process.

That might be more work but as you said, it's a) very convenient and b)
the current implementation just isn't doing what the user expects.

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://darkviews.blogspot.com/  http://www.pdark.de/

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

java.lang.IllegalStateException: The PluginDescriptor for the plugin ... was not found (Was: Re: problem with site-plugin 2.0-beta-6)

[Aaron Digulla]

Quoting Aaron Digulla <[EMAIL PROTECTED]>:

After an epiphany, I found the problem: A corrupt JAR file in the  
repository. I've opened http://jira.codehaus.org/browse/MNG-3523



The bug is still there in 2.0.9. I've downloaded the source and the bug
lurks in this code:

MavenPluginCollector.java:

   public PluginDescriptor getPluginDescriptor( Plugin plugin )
   {
   // TODO: include version, but can't do this in the plugin
manager as it is not resolved to the right version
   // at that point. Instead, move the duplication check to the
artifact container, or store it locally based on
   // the unresolved version?
   return (PluginDescriptor) pluginDescriptors.get( plugin.getKey() );
   }

Obviously, the plugin isn't in pluginDescriptors. Why not? It seems
that the component is not discovered but if that was the case, then why
would maven try to invoke it??


After some more time spent on this, I've added debug output to
MavenPluginCollector. I had to debug with getLogger().info() because it
seems that the debug level is not set when this code is called. :(

What I found is that after the POMs for the site plugin have been read,
I get a ComponentDescriptor event with an
"org.apache.maven.usability.diagnostics.ErrorDiagnoser" entry. This
seems to indicate that something went wrong during the loading of the
site plugin but the error handling has a bug and the error message was
lost.

Any hints where I can look now? I'm pretty sure that one of the
artifacts in my repository or the proxy is broken but I'd rather find
out which one instead of downloading 1.27GB again...




Aaron Digulla schrieb:

Brian E. Fox schrieb:

I think it's safer to leave it at beta-6. Most people aren't 
expressing any issues and if anyone has trouble, they can
manually lock to beta-5. This is safer than potentially
downgrading everyone.


beta-6 doesn't work for me at all. I suddenly get:

java.lang.IllegalStateException: The PluginDescriptor for the plugin
Plugin [org.apache.maven.plugins:maven-site-plugin] was not found

This error is definitely not true; I can see the file on disk and maven
can read it (I can see that it resolves parent POMs from it in the debug
log).


Here is the output from the log:

[DEBUG] maven-site-plugin: resolved to version 2.0-beta-6 from
repository central
[DEBUG] Retrieving parent-POM:
org.apache.maven.plugins:maven-plugins::10 for project:
null:maven-site-plugin:maven-plugin:2.0-beta-6 from the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::7 for
project: org.apache.maven.plugins:maven-plugins:pom:10 from the repository.
[DEBUG] Retrieving parent-POM: org.apache:apache::4 for project:
org.apache.maven:maven-parent:pom:7 from the repository.
[INFO]

[ERROR] FATAL ERROR
[INFO]

[INFO] The PluginDescriptor for the plugin Plugin
[org.apache.maven.plugins:maven-site-plugin] was not found.
[INFO]

[DEBUG] Trace
java.lang.IllegalStateException: The PluginDescriptor for the plugin
Plugin [org.apache.maven.plugins:maven-site-plugin] was not found.
  at
org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:321)
  at
org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:208)
[code]

As you can see, the plugin exists and the POM could be loaded. So what
is wrong in this case?

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://darkviews.blogspot.com/  http://www.pdark.de/

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







--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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




--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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




--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, i

Re: problem with site-plugin 2.0-beta-6

[Aaron Digulla]

Quoting Aaron Digulla <[EMAIL PROTECTED]>:


Quoting Aaron Digulla <[EMAIL PROTECTED]>:

The bug is still there in 2.0.9. I've downloaded the source and the bug
lurks in this code:

MavenPluginCollector.java:

public PluginDescriptor getPluginDescriptor( Plugin plugin )
{
// TODO: include version, but can't do this in the plugin
manager as it is not resolved to the right version
// at that point. Instead, move the duplication check to the
artifact container, or store it locally based on
// the unresolved version?
return (PluginDescriptor) pluginDescriptors.get( plugin.getKey() );
}

Obviously, the plugin isn't in pluginDescriptors. Why not? It seems
that the component is not discovered but if that was the case, then why
would maven try to invoke it??


After some more time spent on this, I've added debug output to  
MavenPluginCollector. I had to debug with getLogger().info() because  
it seems that the debug level is not set when this code is called. :(


What I found is that after the POMs for the site plugin have been  
read, I get a ComponentDescriptor event with an  
"org.apache.maven.usability.diagnostics.ErrorDiagnoser" entry. This  
seems to indicate that something went wrong during the loading of the  
site plugin but the error handling has a bug and the error message was  
lost.


Any hints where I can look now? I'm pretty sure that one of the  
artifacts in my repository or the proxy is broken but I'd rather find  
out which one instead of downloading 1.27GB again...





Aaron Digulla schrieb:

Brian E. Fox schrieb:

I think it's safer to leave it at beta-6. Most people aren't
expressing any issues and if anyone has trouble, they can   
manually  lock to beta-5. This is safer than potentially   
downgrading everyone.


beta-6 doesn't work for me at all. I suddenly get:

java.lang.IllegalStateException: The PluginDescriptor for the plugin
Plugin [org.apache.maven.plugins:maven-site-plugin] was not found

This error is definitely not true; I can see the file on disk and maven
can read it (I can see that it resolves parent POMs from it in the debug
log).


Here is the output from the log:

[DEBUG] maven-site-plugin: resolved to version 2.0-beta-6 from
repository central
[DEBUG] Retrieving parent-POM:
org.apache.maven.plugins:maven-plugins::10 for project:
null:maven-site-plugin:maven-plugin:2.0-beta-6 from the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::7 for
project: org.apache.maven.plugins:maven-plugins:pom:10 from the repository.
[DEBUG] Retrieving parent-POM: org.apache:apache::4 for project:
org.apache.maven:maven-parent:pom:7 from the repository.
[INFO]

[ERROR] FATAL ERROR
[INFO]

[INFO] The PluginDescriptor for the plugin Plugin
[org.apache.maven.plugins:maven-site-plugin] was not found.
[INFO]

[DEBUG] Trace
java.lang.IllegalStateException: The PluginDescriptor for the plugin
Plugin [org.apache.maven.plugins:maven-site-plugin] was not found.
   at
org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:321)
   at
org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:208)
[code]

As you can see, the plugin exists and the POM could be loaded. So what
is wrong in this case?

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://darkviews.blogspot.com/  http://www.pdark.de/

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







--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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




--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: problem with site-plugin 2.0-beta-6

[Aaron Digulla]

Quoting Aaron Digulla <[EMAIL PROTECTED]>:

The bug is still there in 2.0.9. I've downloaded the source and the  
bug lurks in this code:


MavenPluginCollector.java:

public PluginDescriptor getPluginDescriptor( Plugin plugin )
{
// TODO: include version, but can't do this in the plugin  
manager as it is not resolved to the right version
// at that point. Instead, move the duplication check to the  
artifact container, or store it locally based on

// the unresolved version?
return (PluginDescriptor) pluginDescriptors.get( plugin.getKey() );
}

Obviously, the plugin isn't in pluginDescriptors. Why not? It seems  
that the component is not discovered but if that was the case, then  
why would maven try to invoke it??



Aaron Digulla schrieb:

Brian E. Fox schrieb:

I think it's safer to leave it at beta-6. Most people aren't   
expressing any issues and if anyone has trouble, they can manually  
 lock to beta-5. This is safer than potentially downgrading  
everyone.


beta-6 doesn't work for me at all. I suddenly get:

java.lang.IllegalStateException: The PluginDescriptor for the plugin
Plugin [org.apache.maven.plugins:maven-site-plugin] was not found

This error is definitely not true; I can see the file on disk and maven
can read it (I can see that it resolves parent POMs from it in the debug
log).


Here is the output from the log:

[DEBUG] maven-site-plugin: resolved to version 2.0-beta-6 from
repository central
[DEBUG] Retrieving parent-POM:
org.apache.maven.plugins:maven-plugins::10 for project:
null:maven-site-plugin:maven-plugin:2.0-beta-6 from the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::7 for
project: org.apache.maven.plugins:maven-plugins:pom:10 from the repository.
[DEBUG] Retrieving parent-POM: org.apache:apache::4 for project:
org.apache.maven:maven-parent:pom:7 from the repository.
[INFO]

[ERROR] FATAL ERROR
[INFO]

[INFO] The PluginDescriptor for the plugin Plugin
[org.apache.maven.plugins:maven-site-plugin] was not found.
[INFO]

[DEBUG] Trace
java.lang.IllegalStateException: The PluginDescriptor for the plugin
Plugin [org.apache.maven.plugins:maven-site-plugin] was not found.
at
org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:321)
at
org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:208)
[code]

As you can see, the plugin exists and the POM could be loaded. So what
is wrong in this case?

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://darkviews.blogspot.com/  http://www.pdark.de/

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







--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: problem with site-plugin 2.0-beta-6

[Aaron Digulla]

Aaron Digulla schrieb:
> Brian E. Fox schrieb:
> 
>> I think it's safer to leave it at beta-6. Most people aren't expressing any 
>> issues and if anyone has trouble, they can manually lock to beta-5. This is 
>> safer than potentially downgrading everyone.
> 
> beta-6 doesn't work for me at all. I suddenly get:
> 
> java.lang.IllegalStateException: The PluginDescriptor for the plugin
> Plugin [org.apache.maven.plugins:maven-site-plugin] was not found
> 
> This error is definitely not true; I can see the file on disk and maven
> can read it (I can see that it resolves parent POMs from it in the debug
> log).

Here is the output from the log:

[DEBUG] maven-site-plugin: resolved to version 2.0-beta-6 from
repository central
[DEBUG] Retrieving parent-POM:
org.apache.maven.plugins:maven-plugins::10 for project:
null:maven-site-plugin:maven-plugin:2.0-beta-6 from the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::7 for
project: org.apache.maven.plugins:maven-plugins:pom:10 from the repository.
[DEBUG] Retrieving parent-POM: org.apache:apache::4 for project:
org.apache.maven:maven-parent:pom:7 from the repository.
[INFO]

[ERROR] FATAL ERROR
[INFO]

[INFO] The PluginDescriptor for the plugin Plugin
[org.apache.maven.plugins:maven-site-plugin] was not found.
[INFO]

[DEBUG] Trace
java.lang.IllegalStateException: The PluginDescriptor for the plugin
Plugin [org.apache.maven.plugins:maven-site-plugin] was not found.
at
org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:321)
at
org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:208)
[code]

As you can see, the plugin exists and the POM could be loaded. So what
is wrong in this case?

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://darkviews.blogspot.com/  http://www.pdark.de/

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

Re: problem with site-plugin 2.0-beta-6

[Aaron Digulla]

Brian E. Fox schrieb:

> I think it's safer to leave it at beta-6. Most people aren't expressing any 
> issues and if anyone has trouble, they can manually lock to beta-5. This is 
> safer than potentially downgrading everyone.

beta-6 doesn't work for me at all. I suddenly get:

java.lang.IllegalStateException: The PluginDescriptor for the plugin
Plugin [org.apache.maven.plugins:maven-site-plugin] was not found

This error is definitely not true; I can see the file on disk and maven
can read it (I can see that it resolves parent POMs from it in the debug
log).

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://darkviews.blogspot.com/  http://www.pdark.de/

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

Maven, JAR names and Java Security Policy

[Aaron Digulla]

Hello,

I'd like to call your attention to this discussion:

https://issues.apache.org/jira/browse/DERBY-3083

The issue here is that the Derby Network Server looks for a JAR called  
"derbynet.jar" on the classpath ... by *name*. Of course, when I use  
Maven, the JAR is called "derbynet-10.3.1.4.jar" and the security  
policy fails to find the file.


I'm by no means an expert to Java security policies but I thought I'd  
let you know that there is something which might cause trouble. Is  
anyone using Java security policies in Maven projects? Is there a  
better way to handle "code domains" than specifying JAR file names?


Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: Mirror woes

[Aaron Digulla]

Jorg Heymans schrieb:

>> Since a few months, some European mirrors have become increasingly
>> unreliable. For example, maven.sateh.com is missing some packages
>> which were distributed in June, mirrors.dotsrc.org is missing some
>> dated from February (for example, asm/asm/3.0)!
> 
> Any particular reason why you're using a mirror ? We've been using repo1
> extensively for over a year now (after it migrated to contegix) and have
> been extremely happy with its responsiveness since.

I don't want to burden repo1 too much. Granted, I have an interal cache
using DSMP, so the actual load would be minimal. Still, every now and
then, I have to flush the cache and populate it again.

It's time for a P2P mirror infrastructure in the internet where you
register a service (org.apache.maven) and every node of the mirror web
will sync it. For the client, there must be a service to get the three
closest mirrors and a simple way to download from them. That would be
great :-)

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: Mirror woes

[Aaron Digulla]

Quoting Jason van Zyl <[EMAIL PROTECTED]>:

Do other people have the same problems? If so, is someone working   
on a solution? For example, by creating a main site for mirrors   
only (i.e. closed to the general public so mirrors can get the   
updates in a timely manner). Or can mirrors connect directly to   
repo1?


We can start letting mirrors connect directly. Contegix has donated all
the bandwidth used thus far, I pay for the rest of it and I don't
really mind now if other mirrors want to hit the central machine
directly. The cost is not that great and will help mirrors and it's
really only the first hit . A second machine is going in and mirrors
can use that. Point anyone at the [EMAIL PROTECTED]
list and we'll start trying to get them sorted out.


Thanks a lot, I've forwarded the mail to the maintainers of dotsrc and sateh.

Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: Mirror woes

[Aaron Digulla]

Quoting Carlos Sanchez <[EMAIL PROTECTED]>:


you can try cica.es too, that's up to date
http://maven.apache.org/guides/mini/guide-mirror-settings.html


Thanks, I'll keep that in mind :-)

Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Mirror woes

[Aaron Digulla]

Hello,

Since a few months, some European mirrors have become increasingly  
unreliable. For example, maven.sateh.com is missing some packages  
which were distributed in June, mirrors.dotsrc.org is missing some  
dated from February (for example, asm/asm/3.0)!


I talked to the admins of dotsrc and the underlying problem is that  
ibilio is overloaded -> rsync will abort because of timeouts.


Do other people have the same problems? If so, is someone working on a  
solution? For example, by creating a main site for mirrors only (i.e.  
closed to the general public so mirrors can get the updates in a  
timely manner). Or can mirrors connect directly to repo1?


Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: dependency on system library (java.library.path)

[Aaron Digulla]

Joerg Hohwiller wrote:
> Hi there,
> 
> I have already used SWT and GWT together with maven. Both need native system
> libraries at some specific point. This causes trouble when running code (e.g.
> test-cases) with maven.

The latest 3.3 release of SWT includes the library files in the JAR! I
have no idea how they do it and how the Java VM can find and load these
but it works. Maybe you could ask the SWT guys how they did it and
provide a Maven plugin to add dll/so-files to a JAR in such a way that
the Java runtime can find and load them without messing with
java.library.path.

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: Extension to install custom proxy muck in Maven?

[Aaron Digulla]

Jason Dillon wrote:

> Yes Maven 2.0.x does allow you to configure a mirror for a repo, but
> that is *not* what I am looking for.
> 
> Also, there is no corporate proxy, if I has the luxury of such a proxy
> for my users then this would not be an issue.  The problem is that my
> users are all of the folks who build Apache Geronimo... and I can't
> force them all to setup a proxy pointing at some server for all artifacts.
> 
> What I need is a way to install/configure a tiny proxy which can follow
> some simple rules (aka something like DSMP) and have it run
> automatically *inside* of the Maven JVM w/o the user having to worry
> about it at all (ie. they still run `mvn install` and it works just the
> same).

How about packaging up a preconfigured DSMP proxy which every developer
has to install on their machines? That would solve most of your problems
*now*. When this works, you can have a look at the download code of
Maven. I figure all you need is the URL rewriting code of DSMP (which is
pretty simple).

Plus open a JIRA which allows to put  and  in a
 or a parent pom.

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: Escaping HTML entities for canoo webtests -- resources-plugin?

[Aaron Digulla]

Mika Göckel wrote:

> Do you think of a chain of filters like in ant?

Maybe. One of the issues I've had was to make the plugin to replace
everything *except* ${basedir}. If I was able to write my own filters, I
 could have solved that more easily (now, I just call an ant task
afterwards which replaces !BASEDIR! with the right string ... ahem :-)

> But I wouldn't put this into the resources plugin, as this is a more
> general idea and the resources plugin only filters *.properties files
> (on ${...}... all files on @...@).

The resource plugin will filter anything under .../resources. I've never
noticed the behaviour your describe. We're talking about Maven2, yes?

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: Escaping HTML entities for canoo webtests -- resources-plugin?

[Aaron Digulla]

Mika Göckel wrote:
> Hi!
> 
> My problem is, that I need to escape HTML entities in resource files
> when coping them to target/test-classes.
> Is it a good idea to extend resources-plugin to support something like
> escapeHtml=true as attribute or is it a better idea to create a
> completely new mojo?

The best solution would be to allow chainable filter "plugins" in the
resource mojo :-) There are just so many way in which you can copy a
file. But I guess that's asking too much.

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: [vote] release maven-source-plugin 2.0.3

[Aaron Digulla]

Stephane Nicoll wrote:

> This release fixes all known issues.
> ** Improvement
>* [MSOURCES-11] - When source plugin is used, it should make sure
> it is invoked during install

YAY! +1 :-)

Just to be sure: You checked with a parent POM? (ie. when the source
plugin is configured in the *parent* POM and you run "install" in the
module?)

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: Where can I find command line properties??

[Aaron Digulla]

Quoting Franz Allan Valencia See <[EMAIL PROTECTED]>:


Good day to you, Aaron,

add @parameter to your mojos field so that it can be configured in the pom.


How do I add "@parameter" to my mojo at runtime? :-)

Some background: I'm currently extending the archetype plugin. In my  
new version, you can add arbitrary additional template  
parameters/variables to replace in the archetype templates.


Of course, I need a way for the user to specify them. That would be  
-D... on the command line. But I had trouble to find the additional  
properties. To my surprise, they seem to show up in System.properties.  
Is that the "official" place for all properties specified on the  
command line?


At second thought this makes sense since mvn.bat eventually calls  
java.exe with all the extra parameters...


Regards,



I have a mojo which has dynamic parameters/properties which have to be
specified via the commandline.

When I'm in my execute() method, what do I have to call to see "value"
when I call mvn with "-Dtest=value"?

They aren't in MavenProject/Model.getProperties()...

Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

-
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]




--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Where can I find command line properties??

[Aaron Digulla]

Hello,

I have a mojo which has dynamic parameters/properties which have to be  
specified via the commandline.


When I'm in my execute() method, what do I have to call to see "value"  
when I call mvn with "-Dtest=value"?


They aren't in MavenProject/Model.getProperties()...

Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: Extending the notion of "parent pom"

[Aaron Digulla]

John Casey wrote:

> That sparked the idea of having mixins. With mixins, I could separate
> the two trees cleanly. 
> 
> I'm still a little unclear on how mixins would be "cleaner" than two
> levels of inheritance. If multiple levels of inheritance confuses the
> site plugin, then that plugin needs to be fixed in some way. However, I
> don't think it's appropriate to address a problem that could be fixed
> via rearrangement of directory structures by instead introducing a
> massively complex new feature to Maven. It'd be a lot like replacing the
> engine in your car just so you can get a little more torque to turn a
> flat tire, rather than just fixing the tire.

I don't say that my problem can't be fixed by fixing the site plugin. I
say that it got me thinking if there is a bigger problem hiding
somewhere below all that.

Single parent inheritance is limited. It leads to a long line of parent
POMs because every time you find you need a feature in more than one
project, you have to inject a new level if you don't want to "pollute"
unrelated projects or if you can't (for example when you have to
configure a build plugin).

With mixins, I could have a single mixin file which configures all
plugins and all aspects of Maven I can think of in one place. In the
POMs, I could then use these superblocks as I see fit.

It's probably the extension of the Maven idea: Create powerful, smart
building blocks from which you can build your projects.

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

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

Re: [m2] New pre-package phase?

[Aaron Digulla]

Quoting Brett Porter <[EMAIL PROTECTED]>:

> I don't think either of these are cases for 'package resources', but
> general lifecycle improvements (Which are in the 2.1 design wiki).

I'm still arguing for a generic lifecycle management (where a mojo can
add any number of additional phases and maven just supplies a default
starting set). Do you want me to add my ideas and use cases to
http://docs.codehaus.org/display/MAVEN/Lifecycle+and+Plugin+Handling?

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.philmann-dark.de/

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

Re: repository id vs repository url

[Aaron Digulla]

Quoting Joakim Erdfelt <[EMAIL PROTECTED]>:

> I'm the one responsible for the misguided repository.urlName concept.

Maybe you'd like to have a look at DSMP (http://www.pdark.de/dsmp/)

I'm using the repository ID to find out which user/password to use
during deploy but other than that, I'm ignoring it.

When Maven wants to download any artefact, I have it go through DSMP
and rewrite the URL in there. This way, I can control how Maven
accesses the Internet and from which URLs it can download. I have one
central place to configure and it will work no matter what you put in
your settings and POMs.

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.philmann-dark.de/

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

Re: Extending the notion of "parent pom"

[Aaron Digulla]

Quoting John Casey <[EMAIL PROTECTED]>:

> Do you have even more plugin configuration in this third parent POM? If not,
> why is it critical that the webapp/library projects can declare themselves
> to be children of this POM (in addition to the type-specific POMs)? If you
> do have more plugin configuration in this coordinating parent POM, why is it
> not maintained in the type-specific POMs, or even further up the chain in a
> common parent of those two parent POMs?

That's what I currently do and it confuses the site plugin. The site
plugin has to determine which projects are "children" or another. Here
is the directory tree:

root
+--parent-pom
+--library-pom
+--webapp-pom
+--lib1
+--p2
   +--lib2
   +--webapp2

POM inheritance:

parent-pom
+--library-pom
|  +--lib1
|  +--lib2
+--webapp-pom
|  +--webapp2
+--p2

So when the site plugin builds "p2" does it have children or not? How
should it link to lib2 and webapp2? From the parent POM or the pom.xml
in the parent directory?

I think that other plugins are also affected because I see that Maven
is printing some messages when I have ../pom.xml and  in a
project.

That sparked the idea of having mixins. With mixins, I could separate
the two trees cleanly.

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.philmann-dark.de/

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

Re: DSMP 1.0 - A new maven proxy

[Aaron Digulla]

Quoting Jason Dillon <[EMAIL PROTECTED]>:

> I played around with this a little today, very nice.
>
> How does DSMP handle SNAPSHOT updates?

Usually, I just forbid them :-) (see the allow and deny rules).

At work, I don't want SNAPSHOTs to pollute my environment, so I
disabled them. Even if a POM requests them, it won't get them and I'll
see an error so I can make an educated guess if I want them or not.

The default rule in DSMP itself is to download something once and only
once (for example, the metadata file which contains the available
versions). This was the most simple way to implement it and it worked
for me. So basically, DSMP works like a permanent --offline switch to
Maven which can download new artifacts but can't change ones you
already have.

If you need SNAPSHOTs that update, there are these possible solutions:

- When you know there is a new version of something, delete the files
in the cache and DSMP will get them again (no need to restart; just
delete the files).

- I could add a "no cache" option for SNAPSHOT sites so DSMP would
always forward the requests (ie. you would have the default Maven
behavior of updating the files in the local repository once per day
but every developer would download it from him/herself).

- You could setup a timed build on a machine which wipes the cached
SNAPSHOTs and runs a single build in the morning. This way, the cache
would be filled with the most current snapshots before the developers
show up for work.

- Someone (ie. not me; I don't know enough about this) could send me a
patch which replicates the Maven update policy or could tell me a way
to find out that I should update something.

- I have a TODO to activate a cache per IP address. The idea was to
create a new cache at request, fill it with the most recent stuff and
present this as the "current" cache to this single IP while everyone
else sees the "public cache".

This way, I could activate this feature, do a clean build to see that
everything still works and then "commit" the new files to the common
cache for everyone else.

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.philmann-dark.de/

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

Re: using saxon within a mojo

[Aaron Digulla]

Quoting Gregory Kick <[EMAIL PROTECTED]>:

> I'm writing a plugin that I would like to be able to use the saxon
> XPath 2.0 implementation.  I've got it working perfectly fine in my
> unit tests, but when I try to run it as a mojo, it reverts back to
> using the jdk XPathFactory.  I would assume that this has something to
> do with the whole META-INF/services mechanism being screwed up by
> classworlds, and that's fine, but I couldn't get
> MAVEN_OPTS=-Djavax.xml.xpath.XPathFactory=net.sf.saxon.xpath.XPathFactoryImpl
> or even System.setProperty("javax.xml.xpath.XPathFactory",
> "net.sf.saxon.xpath.XPathFactoryImpl") to work either.  (Not that I
> really expected anything from System.setProperty()...)
>
> Does anyone know how to either make maven respect META-INF/services or
> set the system property and make it stick for mojos?

I had similar problems with SaxParserFactory. What happens is that the
JDK not only sets the default implementation but also remembers the
classloader to use to look for an implementation. After that, Maven is
loaded, sets its own classloader and when your mojo comes into view,
there is no way to revert the mistake the JDK made.

That's why MAVEN_OPTS doesn't work: When the JDK wants to load the
class, the mojo isn't there, yet, so the JAR hasn't been loaded by the
Maven classloader . When the mojo (and all its dependencies) have been
loaded by Maven, the JDK has already made up his mind that only his
own classloader could possible find these classes. Like in: "Nobody in
their right mind would ever try to install their own custom
classloader when using XML! That's ridiculous!"

Of course, all this is private/hidden/unaccessible/go-away-and-die, so
you can't hammer the right values back in. I've tried with
setPrivateField (using reflection and Field.setPrivate(false)) with
some success but you easily end up with a classloader mess (half of
the classes loaded by the wrong classloader) if you can't call this in
the right moment (basically, you have to do this *before* Maven
accesses the XML classes the first time ... like before it tries to
read pom.xml ... If you can show a way to do that from a mojo, you
might have found a way to travel backwards in time ;-))

The only stable solution I found so far was to drop the JARs with the
right XML implementation into the endorsed dir of Java.

In the end, I forked a new process from my mojo with a custom
classpath and all the necessary options. Much more simple and reliable.

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.philmann-dark.de/

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

Re: deploy:deploy-file target and DAV

[Aaron Digulla]

Quoting Graham Leggett <[EMAIL PROTECTED]>:


Can anyone confirm whether this plugin has ever worked for them, and if
so, what DAV server is being used? I am using httpd v2.0.52 as shipped
default with RHEL4.


I'm using wagon-webdav 1.0-beta-2 with maven-deploy-plugin 2.3  
together with Archiva (SVN SNAPSHOT build). Before 1.0-beta-2/2.3,  
this was pretty unstable (every 3rd deploy would fail) but now, it  
works pretty good (even though I still have the occasional hickup).


Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.philmann-dark.de/

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

Extending the notion of "parent pom"

[Aaron Digulla]

Hello,

My POMs have two parents: The one in the parent directory and the one  
which supplies them with the build defaults.


Out of necessity, they can't be the same POM. The ../pom.xml just  
specifies the build order. The POM specified with the  element  
supplies the build config (for example for webapps or for code  
libraries).


Usually, a web project in our company contains a code and a web part,  
so I need two  POMs (one for libraries and one for webapps)  
and I need a POM which says "build the library, then build the webapp".


This means, I'm fighting with the limitations of Maven's parent POM  
model. Some plugins like the site plugin are confused how to build the  
aggregated site structure.


I see three ways to improve the situation:

- Support .

Pro: It's a W3C standard (some will say that's a drawback :-)

Con: It doesn't really fit into the XML inheritance model of Maven.  
When will variables be resolved? Before or after the includes? Or  
somewhere inbetween? How can we debug this?


- Allow multiple  elements

Pro: People are already used to the parent element

Con: Humans have more than one parent (father and mother) and we all  
know how confusing it is when they can't agree about something. So  
this would call for a smart conflict resolution strategy which a  
developer can understand without help.


The current element will probably have to be extended with new attributes.

- A new  element

The element refers to a POM artifact like the  element but I  
would also like it to be able to select deeper in XML tree of a POM:


* "I'd like to copy the configuration for the maven-deploy-plugin but  
overwrite the version element"


* "Copy the report config and merge it with the definitions in the  
current POM"


* "Copy the config for the cobertura plugin except for the include  
element in the configuration"


Pro: New element allows new semantic

Con: This will be a pretty complex element, especially if it can copy  
conditionally. The syntax should be simple enough so people don't  
swamp the Maven lists with questions but powerful enough to actually  
solve the limitations of the current inheritance system.


We might be tempted to support a copy operator based on XPath. I think  
this is a bad idea because the XPath syntax is really very complex and  
can be quite confusing.


- Allow to include "macro POMs". A macro POM defines common building  
blocks which can be extended as we're used to or configured via  
paramaters:




...
...
...





compile
version2.0.2
source1.4
target@{source}


maven-compiler-plugin
@{version}

@{source}
@{target}









compile
version2.1




1.5







Some comments:

- The "" element deletes anything inherited below the current  
parent element. In the example, there is no target element in the  
effective POM anymore.


- Includes overwrite in the order in which they are specified. So the  
macros defined in the artefact are overwritten by those in the file  
and any "compile" macro will be overwritten with the local definition.


Maybe inheritance merge should be supported here, too.

Comments?

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.philmann-dark.de/

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

Re: deploy:deploy-file target and DAV

[Aaron Digulla]

Quoting Graham Leggett <[EMAIL PROTECTED]>:


Have you tried with 1.0-beta-2 of wagon-webdav? This solved some
problems for me.


Which version of the maven-deploy-plugin do you use? Have you tried 2.3?

Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.philmann-dark.de/

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

Re: deploy:deploy-file target and DAV

[Aaron Digulla]

Quoting Graham Leggett <[EMAIL PROTECTED]>:


On Tue, January 30, 2007 1:55 pm, Aaron Digulla wrote:


Have you tried with 1.0-beta-2 of wagon-webdav? This solved some
problems for me.


Added the 1.0-beta-2 of wagon-webdav like this:

  

  
org.apache.maven.wagon
wagon-webdav
1.0-beta-2
  

...
  


You do see the correct version in the output of Maven?

I copied the JAR and the dependencies into maven-2.0.4/lib/


Analysing the logs, I can't see how the plugin in it's current form could
work at all - the logs show no attempt to detect whether the directories
already exist, nor do they show any attempt to create directories - the
upload is therefore doomed to fail.

Has anyone got any ideas?


The simple workaround would be to create the directories manually  
until the bug is fixed.


Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.philmann-dark.de/

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

Piping commons-logging into Maven log

[Aaron Digulla]

Hello,

This should be an FAQ but I couldn't find anything: How do I connect a  
dependency of a mojo which uses commons-logging to the Maven logging?


In my case, I'm using the jasperreports mojo which uses the  
jasperreports JARs which depend on commons-logging. Since nothing is  
specified, commons-logging searches the classpath, finds log4j (from  
the project which is being compiled) and tries to use that which leads  
to "Please initialize the log4j system properly."


Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.philmann-dark.de/

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

Re: deploy:deploy-file target and DAV

[Aaron Digulla]

Quoting Graham Leggett <[EMAIL PROTECTED]>:


It looks like the plugin is not making an attempt to create the
directories in the repository before trying to upload the file to the
repository, thus the failure:


Have you tried with 1.0-beta-2 of wagon-webdav? This solved some  
problems for me.


Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.philmann-dark.de/

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

Re: [m2] New pre-package phase?

[Aaron Digulla]

Brett Porter wrote:

> Can anyone think of a use case other than the war plugin, or should we
> just go with the pre-package phase?

I have these use cases:

- Filter or generate files for the site plugin (for example, extract
information out of the sources for apt files)

- Multi-Step source/unit test generation (XML -> XML -> Java and DB ->
XML -> Java including filtering)

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.philmann-dark.de/

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

DSMP 1.0 - A new maven proxy

[Aaron Digulla]

Hello,

I had a couple of problems with Maven's way to access the internet. For
example, if I wanted to redirect maven to the closest mirror, I would
have to define a whole lot of mirrors in my settings.xml. And it
wouldn't always work because different projects use different IDs.

Then, there are the broken artefacts on the main servers. Or how about
PMD 3.8? You need it? Well, maybe in a few months (when the project has
released 3.10), it might show up on the central repository servers.

Or have you ever tried to configure Maven to use a snapshot version of
one plugin but the stable versions for all others?

It's a pain.

My solution was to write a new proxy which is simple to configure can
which can do all kinds of magic with a single configuration in Maven.
You can find it on http://www.pdark.de/dsmp/ It's called "Dead Simple
Maven Proxy" and can do these things:

- Rewrite any URL Maven wants to download, so you can force all projects
to download from your closest mirror. You can even make sure that
artefacts from linked directories on the server will be downloaded just
once.

- You can intervene and make Maven see patched versions of any file, no
matter what is on any repository server out there

- You can allow and deny access per URL to make sure that Maven cannot
download things it shouldn't (for example a buggy version of a plugin or
SNAPSHOTs you don't want).

- The firewall in your workplace just won't let you download some artifact.

See http://www.pdark.de/dsmp/usage.html for a whole lot of use cases and
how to solve them with DSMP.

Note that this is a *proxy* and not a repository server. It's meant to
run alongside Archiva or any other repository server and *not* to
replace it.

Best Regards and a Happy New Year,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.philmann-dark.de/

DSMP 1.0 - A new maven proxy

[Aaron Digulla]

Hello,

I had a couple of problems with Maven's way to access the internet. For
example, if I wanted to redirect maven to the closest mirror, I would
have to define a whole lot of mirrors in my settings.xml. And it
wouldn't always work because different projects use different IDs.

Then, there are the broken artefacts on the main servers. Or how about
PMD 3.8? You need it? Well, maybe in a few months (when the project has
released 3.10), it might show up on the central repository servers.

Or have you ever tried to configure Maven to use a snapshot version of
one plugin but the stable versions for all others?

It's a pain.

My solution was to write a new proxy which is simple to configure can
which can do all kinds of magic with a single configuration in Maven.
You can find it on http://www.pdark.de/dsmp/ It's called "Dead Simple
Maven Proxy" and can do these things:

- Rewrite any URL Maven wants to download, so you can force all projects
to download from your closest mirror. You can even make sure that
artefacts from linked directories on the server will be downloaded just
once.

- You can intervene and make Maven see patched versions of any file, no
matter what is on any repository server out there

- You can allow and deny access per URL to make sure that Maven cannot
download things it shouldn't (for example a buggy version of a plugin or
SNAPSHOTs you don't want).

- The firewall in your workplace just won't let you download some artifact.

See http://www.pdark.de/dsmp/usage.html for a whole lot of use cases and
how to solve them with DSMP.

Note that this is a *proxy* and not a repository server. It's meant to
run alongside Archiva or any other repository server and *not* to
replace it.

Best Regards and a Happy New Year,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.philmann-dark.de/

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

Antwort: How to set Classpath with maven

[Aaron . Digulla]

"Sekhar Merrinti IV." <[EMAIL PROTECTED]> schrieb am 
21.12.2006 10:56:06:

> Hi Maven Team,
> 
> can you please suggest me in setting classpath with maven
> 
> even i used the Set CLASSPATH from command promt, but its not
> recognised.

Maven sets the classpath itself, you don't have to do it (and maven 
ignores it if you do).

Use dependencies in your pom.xml to specify what you need and maven will 
add the right version to your classpath.

Regards,

-- 
Aaron Digulla


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

Re: versioning

[Aaron . Digulla]

> 
>   1
>   2
>   1
>   123
> 

It's just as simple to specify a regexp which defines what is allowed as 
the text child for the version element.

Do not break everything up into one element. That's an XML sickness from 
the DTD era (or rather the pre-XSD/Schema era).

Regards,

-- 
Aaron Digulla


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

Re: downloading eclipse runtime binary or RCP delta pack

[Aaron . Digulla]

> So, what is the way forward?

The most simple solution right now is probably to add 
http://repo1.maven.org/eclipse/ to your list of repositories in 
settings.xml.

Regards,

-- 
Aaron Digulla

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

Re: versioning

[Aaron . Digulla]

Jason Dillon <[EMAIL PROTECTED]> schrieb am 19.12.2006 01:26:54:

> I've seen projects switch back and forth... depends on who is in 
> power at the time and what style they like.  So it would be best if 
> mvn would be able comprehend:

Since versions are such an important information in Maven, Maven should 
refuse version numbers which aren't easily comparable.

How about forcing the contents of the version element in the POM to 1-3 
digits, separated by dots? That would "help" people who can't decide.

After that, you can add something with "-" which maven will just 
string-compare (so alpha10 comes between alpha1 and alpha2).

Regards,

-- 
Aaron Digulla

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

Re: downloading eclipse runtime binary or RCP delta pack

[Aaron . Digulla]

"Graham Leggett" <[EMAIL PROTECTED]> schrieb am 18.12.2006 17:53:54:

> The problem I saw posted recently about this was that once published, 
the
> repository is cast in stone, including errors.

=8*O I beg your pardon? I looked in JIRA but couldn't find a report about 
this. Is there? If not, I'd open one. ;-)

The idea that you'll never have to fix a broken POM/JAR/whatever is just 
ridiculous. :-) As I understand it, the repo admins are just very 
reluctant to modify already published artefacts.

Regards,

-- 
Aaron Digulla


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

Re: [m2] New pre-package phase?

[Aaron . Digulla]

Hello,

> What about we just change the lifecycle for the war plugin and add 
> phases there?

Because the same problem crops up time and time again which means the 
current solution is part of the problem.

Imagine. I'm generating a database for my tests from XML descriptions.

The intended control flow should be:

- Copy resources (fill in DB connection details from some existing file)
- Copy resources (convert model specific XML into "XML to SQL" tool 
specific XML)
- Copy resources (turn the XML into SQL)
- Copy resources (load DB with SQL)
- Copy resources (classpath resources for tests)
- Run the tests

How can I make sure in my mojo that the many "copy resources" are executed 
in the right order?

The idea of lifecycle is good but only as a big framework in which you can 
plug other things and you need a way to specify dependencies between the 
"other things", too.

Regards,

-- 
Aaron Digulla

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

Re: [m2] Dev help needed: Should multiple repositories be able to host an artifact, potentially with different versions

[Aaron . Digulla]

Hello,

> The releases of your companies artifacts can't use snapshot versions
> and internally patched versions of the plugins needs to be made
> available to all developers.

I solved these issues by writing my own proxy which can rewrite URLs (so 
even if someone configures Maven to download something from Xyz.com, it 
will still go to Sateh, no matter what). Plus I can "blind" maven (return 
404 for any URL I like).

This way, I can make a beta of the site plugin (which contains vital bug 
fixes for me) available to all developers but maven will not be able to 
download the snapshots of the source or compiler plugin.

As a last resort, the proxy will look into a "patches" tree for files. The 
search order is: patches, allow/deny rules, rewrite rules.

This allows me to fix any bugs by using my own patches, let maven see what 
it should (and nothing else) and force all external connections to one 
single maven repository.

Regards,

-- 
Aaron Digulla

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

Antwort: Re: [m2] build failure, Version: test ??? error

[Aaron . Digulla]

"Barrie Treloar" <[EMAIL PROTECTED]> schrieb am 13.12.2006 01:47:02:

> Running mvn in debug mode so I can attach eclipse to the running 
instance.

How do you do that?

Regards,

-- 
Aaron Digulla

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

Re: [m2] New pre-package phase?

[Aaron . Digulla]

Kenney Westerhof <[EMAIL PROTECTED]> schrieb am 07.12.2006 15:54:46:

> 
> Hi,
> 
> What I'm reading below looks exactly like Maven, except for the scope of 
the
> dependencies. 
> 
> Just for fun, I'll try to make the differences in your system and maven 
> more concrete. Correct me if I get anything wrong. 
> 
> In Maven we have 2 types of 'dependencies': artifact dependencies, which 

> control build order (amongst other things), and 'mojo dependencies', 
which
> hook into the lifecycle and make sure that certain things are executed.
> 
> Your system only has 1 type of (build order) dependency, which depends 
on
> phases/goals in all projects in your system. If you were to depend on
> the 'install' phase of other projects only, you'd have the Maven 

> thing.
> 
> In maven, if you specify a , you implicitly specify a 
dependency
> on the install/deploy phase (depending on wheter the artifact's project 
is in
> the reactor). In your system you can specify a dependency on 
> 'generate-resources',
> but you can't specify for what project that is. So basically your 
> entire project tree
> can be built using just 1 lifecycle, where for each lifecycle phase,
> that phase is executed
> for all projects - and all hooks to that phase from all projects 
areexecuted.
> 
> I bet your system only works for a monolithic project tree, since 
> you require access to
> files in artifacts that have not been completely built. I don't know
> if you have a 'deploy'
> kind of phase, but is it possible for you to just build a sub-tree 
> of your project tree,
> and if that sub tree requires some icon, can that icon be pulled 
> from a remote repo?

If you run MetaMake in a sub-project, it will build only those things 
which the sub-project really needs. If you build at the root, MetaMake 
sees "everything".

If you need something like downloading from a remote repo, this is not 
implemented (we're C guys, we like monolithic project trees :-). But it 
would be simple to run a tool during a certain phase which tries to 
download the file and directs MetaMake to build it if the download fails.

> > The key to make this simple was "inversion of dependency". In my 
project 
> > (module) I don't say "my new phase depends on generate" but "generate 
> > depends on my new phase". When the build tool decides to look at 
> > "generate", it first considers all the phases which "pre-depend" on 
it. 
> > Like so:
> > 
> > ## generate:: generate-includes
> 
> This can be done in Maven: in the project that has a 'generate-
> includes' requirement
> just adds a mojo for that to the 'generate-sources' phase.

Imagine you have two mojos which both are run during generate-sources. How 
do you make sure one of them is run before or after the other?

As I see it, that's the major difference between the maven approach and 
MetaMake. In MetaMake, you can reorder dependencies.

Example:

Mojo A runs in generate-sources
Mojo B runs in generate-sources

Usually, the order of them is undefined (A and B don't depend on each 
other).

Mojo C wants to run after A but before C. In MetaMake, I can say in C: 

## C: A
## B: C

Now, the build order will be defined: A -> C -> B.

Regards,

-- 
Aaron Digulla


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

Re: [m2] help resolving OverConstrainedVersionException for eclipse plugin

[Aaron . Digulla]

"Barrie Treloar" <[EMAIL PROTECTED]> schrieb am 07.12.2006 10:50:33:

> > > 3. Have you tried to delete your local Maven repo? Or at least the
> > > maven-metadata-*.xml files?
> >
> > No, this was a last resort.
> >
> > I'm trying to build from home and see what happens there.
> >
> 
> Hmm, I have a clean machine at home and it build fine (except for test
> failures...)

Congratulations, you've run into the Maven Suicide Bug. Sometimes, maven 
downloads something which it shouldn't and afterwards, it suddenly is 
unable to resolve version, dependencies, whatever.

Try to locate all SNAPSHOTs in your local maven repo and delete them. If 
that doesn't help, wipe the whole thing. You're on a fat internet connect, 
right?

If that doesn't help, make sure your firewall doesn't block certain 
things.

Note: I'm working on a Maven Proxy (something which you specify in 
) which can prevent Maven from seeing something which it shouldn't 
(like certain snapshots, buggy POMs, deadly versions of JARs, etc).

Regards,

-- 
Aaron Digulla


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

Re: [m2] help resolving OverConstrainedVersionException for eclipse plugin

[Aaron . Digulla]

A few hints which might help:

1. Maven 2.0.4 has a bug when it comes to resolving dependencies. If a 
parent POM defines the version to 1.0 and your POM wants 1.1, the parent 
wins.

2. Can you download the missing POM? Sometimes, Maven believes the POM 
can't be downloaded because it tries to download something else from that 
repository which fails and Maven blacklists it for the build. -U doesn't 
help in this case. Check your log for download errors.

3. Have you tried to delete your local Maven repo? Or at least the 
maven-metadata-*.xml files?

Regards,

-- 
Aaron Digulla
Magazine zum Globus
Informatik AW - Web
Eichstrasse 23
8045 Zuerich
Phone:  +41 58 455 26 20
Fax: +41 58 455 27 28

www.globus.ch
Mail: [EMAIL PROTECTED] 

"Barrie Treloar" <[EMAIL PROTECTED]> schrieb am 07.12.2006 08:07:49:

> On 12/7/06, Barrie Treloar <[EMAIL PROTECTED]> wrote:
> > I might add that these artifacts are in my local repository.
> >
> > Trawling through poms now to see if I can find differing versions.
> >
> 
> If I comment out
> org.apache.maven.shared.maven-plugin-testing-tools:1.0-SNAPSHOT from
> the pom file I get past the failure to resolve artifacts (but
> obviously compilation fails because of missing dependencies)
> 
> 
>   org.apache.maven.shared
>   maven-plugin-testing-tools
>   1.0-SNAPSHOT
>   test
> 
> 
> org.apache.maven.shared.maven-test-tools:1.0-SNAPSHOT defines
> 
> 
>   org.codehaus.plexus
>   plexus-utils
>   1.4-SNAPSHOT
> 
> 
> 
> But I still can't work out why it is failing to resolve.
> 
> Re-reading BBWM - 3.6. Resolving Dependency Conflicts and Using
> Version Ranges, here is the debug stuff for plexus-utils only:
> 
> [DEBUG] Retrieving parent-POM: org.codehaus.plexus:plexus::1.0.4 for
> project: null:plexus-utils:jar:1.0.5 from the repository.
> [DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.5:runtime
> (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime
> (removed - nearer found: 1.0.5)
> [DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime
> (removed - nearer found: 1.0.5)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5:runtime
> (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime
> (removed - nearer found: 1.0.5)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime
> (removed - nearer found: 1.0.5)
> [DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime
> (removed - nearer found: 1.0.5)
> [DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime
> (removed - nearer found: 1.0.5)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime
> (removed - nearer found: 1.0.5)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime
> (removed - nearer found: 1.0.5)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime
> (selected for runtime)
> [DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4:compile
> (selected for compile)
> [DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.5:compile
> (removed - nearer found: 1.0.4)
> [DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.5:compile
> (removed - nearer found: 1.0.4)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:compile
> (removed - nearer found: 1.0.5)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5:compile
> (selected for compile)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:compile
> (removed - nearer found: 1.0.5)
> [DEBUG] Retrieving parent-POM: org.codehaus.plexus:plexus::1.0.5 for
> project: null:plexus-utils:jar:1.2 from the repository.
> [DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.2:compile
> (removed - nearer found: 1.0.5)
> [DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.4:compile
> (removed - nearer found: 1.0.5)
> [DEBUG] plexus-utils: resolved to version 1.4-20061015.155106-2 from
> repository apache.snapshots
> [DEBUG] Retrieving parent-POM:
> org.codehaus.plexus:plexus::1.0.9-SNAPSHOT for project:
> null:plexus-utils:jar:1.4-20061015.155106-2 from the repository.
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.4-SNAPSHOT:test
> (removed - nearer found: 1.0.5)
> [DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.0.5:compile (removed
> - nearer found: 1.2)
> [DEBUG]   org.codehaus.plexus:plexus-utils:jar:1.2:compile (selected
> for compile)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5:test
> (removed - nearer found: 1.2)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:test
> (removed - nearer found: 1.2)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5:test
> (removed

Re: [m2] New pre-package phase?

[Aaron . Digulla]

Steve Loughran <[EMAIL PROTECTED]> schrieb am 05.12.2006 14:51:52:

> The weakness is that someone, somewhere, has to lay down what those 
> states are. And what works for simple 
> ready-to-compile->compiled->packaged->tested->published lifecycle gets 
> complex if you have to do silly things like throw the SOAP stack at the 
> compiled app source to generate the WSDL for the test run, or create a 
> test JAR that is itself signed and tested (meta testing, yes!).

With MetaMake, something like that is possible but we (usually) don't do 
it.

As you said, the key argument is: Even if it's stupid to run though a mine 
field, sometimes, you *have* to (because someone is shooting at you).

A build tool should make the obvious things simple but it should not 
prevent to solve corner cases. The current maven build system just cannot 
cope with running "mvn deploy" for a part of the project so you can run 
your tests in another.

The question is not if it's a stupid thing to do, the question is: If I 
*have* to, what do I do? Currently, my solution is to revert to ant and 
control maven from there.

Rgards,

-- 
Aaron Digulla


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

Re: [m2] New pre-package phase?

[Aaron . Digulla]

Jason van Zyl <[EMAIL PROTECTED]> schrieb am 04.12.2006 17:43:29:

> > As I said before, I've had very good results with a build system in 
> > which
> > you can specify arbitrary phases and say "this phase depends on 
> > that one".
> 
> And how much luck have you had showing that system to other people? 
> And how much luck have other people had looking at what you've made 
> without them having to consult you?

It's about as hard to explain and understand as the Maven dependency 
system. It's just an odd idea at first glance.

You see, just like Maven, we have several "big" phases ("generate", 
"compile", "link", "site").

Eventually, we added generate-includes, generate-source, generate-scripts, 
generate-makefiles, ...

The key to make this simple was "inversion of dependency". In my project 
(module) I don't say "my new phase depends on generate" but "generate 
depends on my new phase". When the build tool decides to look at 
"generate", it first considers all the phases which "pre-depend" on it. 
Like so:

## generate:: generate-includes

Now, MetaMake will look for projects which define "generate-includes" (or 
new dependencies for it) and runs those phases/goals/targets first.

This way, each developer can create their own little world, making sure 
all their phases are called in the correct order. You need a second 
"generate include" phase? No problem. Hooking them into the big world is 
also simple because of the predefined phases which are always there.

The implementation was dead simple (4h in plain C) and worked reliable at 
the first attempt. We only had to add caching because searching 20'000 
Makefiles for targets was bit slow :-) My project (AROS) is using this 
build system for several years, now. Currently, we have roughly 5'000 
phases which, oddly enough, makes the build more *simple*.

Let me explain. You have a big maven project with hundreds of modules (we 
have about 200). How do you make sure that module X is built and ready 
before module Y? Or, say, I need a generated file from a module now but 
not all of it? In current Maven, you have to move things around in the 
parent POMs. The dependencies "leak".

In our world, I say:

Project X:

## install:: workbench-icon
## workbench-icon:: icon-generator-install
... create the workbench icon ...

Project Y:

## site: workbench-icon
... use the icon ...

Let's imagine I have a clean checkout and want to see the website. Even 
though workbench hasn't been completely yet, the single icon file can be 
generated after the icon generator has been installed. When I say "mmake 
site", it will compile and install the icon generator, generate the 
workbench icon and then the HTML files.

In maven, this level of detail is probably not possible. Maven projects 
are more encapsulated than ours and I don't think it's even necessary to 
go to such lengths in Maven. Operating systems usually have many small 
components with heavy dependencies between them, that's why we choose the 
approach described above.

What I would like to see is a simple way to "'install' depends on my new 
phase/target/goal" in a Mojo and in the execute-elements in the POM. That 
way, I could do extra work before something is installed, without 
influencing the standard lifecycle, other projects or plugins.

> Creating a system 
> where you have random interaction can potentially create a system 
> with extremely high infrastructural costs. Shared infrastructure 
> means lower costs and that means a predictable system.

Random? Since when is the maven dependency resolution "random"? I haven't 
seen the code but from what I see, it probebly works exactly like the 
MetaMake target resolution.

Regards,

-- 
Aaron Digulla


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

Antwort: Re: [m2] New pre-package phase?

[Aaron . Digulla]

Jason van Zyl <[EMAIL PROTECTED]> schrieb am 04.12.2006 16:51:30:

> You can always make your own lifecycle, which is not that hard if you 
> really need it.[...]To 
> allow free form to accommodate the ever shrinking number of cases we 
> can't handle is just not worth it. The standard lifecycle then 
> disappears and Maven becomes a very hard to explain. It one of the 
> fundamental differences between Maven and everything else and though 
> we run up against some limitations it is one of Maven's most powerful 
> attributes.

I'm not against the standard life cycle. I'm against the "executions" 
elements in the POM :-)

What I would like to see is to get rid of "executions" and add "depends" 
where you can name arbitrary phases. Some will come from the standard life 
cycle of maven, others will be created by the POM. That would allow to 
weave in arbitrary complex phase dependencies as you need them. They would 
not pollute the core or any other plugins.

So basically just add an interface which allows me to inject new phases 
from my POMs and Mojos.

And while we're at it: How about merging phases and goals? What is the big 
difference between them anyway?

Isn't that something which new users always wonder about and which you 
could easily hide behind the scenes?

Regards,

-- 
Aaron Digulla


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

Re: [m2] New pre-package phase?

[Aaron . Digulla]

Richard van der Hoff <[EMAIL PROTECTED]> schrieb am 04.12.2006 
14:08:37:

> > Actually, before we jump into this, let's consider the use case at 
hand. 
> > While easily solved by pre-package at this point, we may find other 
needs.
> 
> To take these suggestions even further, perhaps the idea of a fixed set 
> of phases is too limiting. An alternative would be to number phases, 
> from (say) 0 to 1000, with the current named phases as aliases for 100, 
> 200, etc. Then it's easy for plugins which need it to slip in an extra 
> phase.

As I said before, I've had very good results with a build system in which 
you can specify arbitrary phases and say "this phase depends on that one".

So I could say "package depends on prepackage-tomcat-war" and maven sorts 
everything out.

This of course means maven has to load all plugins (or at least the 
configs) at startup.

Regards,

-- 
Aaron Digulla


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

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

[Aaron . Digulla]

> Yes, I've seen this thread as well. Sounds good to me even if we need
> strong use cases to create a new standard phase.

How about adding support for custom phases to the POM?

That would allow developers and users to experiment with new phases and to 
build some experience with which ones are useful and which only look good 
but don't really work.

Incidentially, I'd like to see a tool which can show me what phases there 
are and which plugin binds to which phase (in order to debug 
execution/dependency problems like 
https://jira.codehaus.org/browse/MSOURCES-11).

Regards,

-- 
Aaron Digulla


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

Re: Maven's classpaths (Was: [discuss] Java 5)

[Aaron . Digulla]

Emmanuel Hugonnet <[EMAIL PROTECTED]> schrieb am 28.11.2006 
15:54:34:

> >> I have to edit the pom.xml of 
> >> maven-plugin-tools-java to set the version of qdox to 1.6.1 and then 
all 
> >> is fine.
> Hi,
> This is a temporary solution I use with a proximity proxy and an 
> overriding pom.xml but my question is more theorical than practical ;-)
> Why can't I override this dependency?

In the pom, you can tell maven how to compile and test *your* code. From 
maven's point of view, the maven-plugin-tools-java is "external" and 
outside the scope of the dependencies in your pom.xml.

Imagine: A plugin depends on some class in qdox 1.5 which is deprecated 
and was removed in qdox 1.6. Now, your project says "I depend on qdox 
1.6". If maven took this into account when loading plugins, the plugin 
wouldn't work and there was no way to make it work without breaking the 
build of your project. A deadlock.

Therefore, maven carefully separates the classpaths from every plugin from 
your project. You can have plugin A which needs qdox 1.5 and plugin B 
which needs qdox 2.0 in the *same* build and include qdox 1.6 in your 
project and it will work.

A solution might be to extend maven's xml merge mechanism. If you could 
add "patches" to pom.xml and settings.xml//profile, then it would be 
possible to override the values in other POM's (for example, to patch the 
POM of maven-plugin-tools-java to depend on a different version of qdox).

Here, I must ask how economical that would be. As it is, the solution is 
simple (at least when you're used at how simple it is to setup and compile 
maven projects) and the question is how useful such a patch mechanism will 
be (ie. how often can you fix your problems with it?).

Regards,

-- 
Aaron Digulla


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

Re: [discuss] Java 5

[Aaron . Digulla]

Emmanuel Hugonnet <[EMAIL PROTECTED]> schrieb am 28.11.2006 
14:24:44:

> I have to edit the pom.xml of 
> maven-plugin-tools-java to set the version of qdox to 1.6.1 and then all 

> is fine.

My solution in such a case:

- Download the source for the broken plugin
- Fix the dependencies
- Increment the version by 1 (i.e. 2.0.2 in this case).
- Deploy the new plugin to a local repository

Now, you can use this version in your projects until the bug is fixed.

You might also want to add -SNAPSHOT to the version but then, you have to 
make sure that you're not getting into conflicts with the official 
snapshots.

If the plugin is released with the very same version, you have to delete 
it manually on your side but until then, you can work.

How about a -PATCH version? :-)

Regards,

-- 
Aaron Digulla
Magazine zum Globus
Informatik AW - Web
Eichstrasse 23
8045 Zuerich
Phone:  +41 58 455 26 20
Fax: +41 58 455 27 28

www.globus.ch
Mail: [EMAIL PROTECTED] 

> [EMAIL PROTECTED] a écrit :
>  > Please post the error.
>  >
>  > Regards,
>  >
>  > 
> It is some qdox exception. I have posted on the users list about my 
> problem, in summary I have a dependency on maven-plugin-tools when I 
> build my plugin, maven-plugin-tools depends on maven-plugin-tools-java 
> which depends on qdox for extracting the metadata to plugin.xml. The 
> problem is that I can't find a way to override this dependency path, 
> since maven-plugin-tools-java is 2.0.1 it goes to qdox 1.5 which is not 
> compatible with Java 1.5 so
> I read a conversation on dev mailing list this summer about a similar 
> kind of problem when trying to build maven.
> I have checked this dependency problem on 2.04, 2.0.5-SNAPSHOT and 
> 2.1-SNAPSHOT but on 2.1 I didn't try overriding and I didn't change my 
pom.
> I have attached all the log I could get, if you could prove me wrong and 

> give me a solution I would be more than happy :-)
> Regards,
> Emmanuel


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

Archiva: 507 Insufficient Storage

[Aaron . Digulla]

Hello,

Every now and then, I get the error " 507 Insufficient Storage" during mvn 
deploy. Is this a known error?

I'd like to debug this. Where in the server code is this error generated?

[INFO] Uploading repository metadata for: 'artifact 
statcvs:maven-statcvs-plugin'
Connecting to http://.../archiva/repository/...
28.11.2006 14:13:41 org.apache.commons.httpclient.HttpMethodBase 
processRedirectResponse
INFO: Redirect requested but followRedirects is disabled
[INFO] 

[ERROR] BUILD ERROR
[INFO] 

[INFO] Error installing artifact's metadata: Error while deploying 
metadata: Failed to transfer file: 
http://.../archiva/repository/.../statcvs/maven-statcvs-plugin/maven-metadata.xml.
 
Return code is: 507 Insufficient Storage

Regards,

-- 
Aaron Digulla


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

Re: [discuss] Java 5

[Aaron . Digulla]

Please post the error.

Regards,

-- 
Aaron Digulla

Emmanuel Hugonnet <[EMAIL PROTECTED]> schrieb am 27.11.2006 
15:26:32:

> Tom Huybrechts a écrit :
> > On 11/27/06, Tom Huybrechts <[EMAIL PROTECTED]> wrote:
> >> This plugin uses sourcelevel 1.5:
> >>
> >> https://svn.codehaus.org/mojo/trunk/mojo/mojo-
> sandbox/repositorytools-maven-plugin 
> >>
> >>
> >
> > ... and it does have non-mojo classes that do not have these
> > constraints (see the components package)
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> If I add an enum in its own file in this plugin I get a build failure :( 

> without any reference from a MOJO. This is most infortunate and blocking 

> in my opinion.
> 
> 
> 
> The enum :
> 
> package org.codehaus.mojo.repositorytools;
> 
> /**
>  *
>  * @author ehugonnet
>  */
> public enum OperationTypeEnum {
>   ADD,UPDATE, FIX, REMOVE;
> }
> 
> 
> -
> 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]

Antwort: Error compiling Archiva

[Aaron . Digulla]

After cleaning my local repository and the cached repositories in my 
Archiva proxy, I could compile again.

While this works, it's sub-optimal. How do I debug an error like this?

Regards,

-- 
Aaron Digulla

[EMAIL PROTECTED] schrieb am 27.11.2006 11:00:11:

> Hello,
> 
> I updated Archiva today and tried to compile it. The "mvn install" 
aborts 
> with NoClassDefFoundError:
> 
> [INFO] 
> 

> [INFO] Building Archiva Web Application
> [INFO]task-segment: [install]
> [INFO] 
> 

> [INFO] [plexus:descriptor {execution: default}]
> [INFO] [plexus:descriptor {execution: default}]
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [plexus:merge-descriptors {execution: default}]
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] Lorg/codehaus/plexus/archiver/manager/ArchiverManager;
> [INFO] 
> 
> [INFO] Trace
> java.lang.NoClassDefFoundError: 
> Lorg/codehaus/plexus/archiver/manager/ArchiverManager;
> at java.lang.Class.getDeclaredFields0(Native Method)
> at java.lang.Class.privateGetDeclaredFields(Class.java:2259)
> at java.lang.Class.getDeclaredField(Class.java:1852)
> at 
> org.codehaus.plexus.util.ReflectionUtils.
> getFieldByNameIncludingSuperclasses(ReflectionUtils.java:26)
> at 
> org.codehaus.plexus.util.ReflectionUtils.
> getFieldByNameIncludingSuperclasses(ReflectionUtils.java:34)
> at 
> org.codehaus.plexus.component.composition.FieldComponentComposer.
> getFieldByName(FieldComponentComposer.java:212)
> at 
> org.codehaus.plexus.component.composition.FieldComponentComposer.
> findMatchingField(FieldComponentComposer.java:171)
> 
> What's wrong?
> 
> Regards,
> 
> -- 
> Aaron Digulla
> 
> 
> -
> 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: Error compiling Archiva

[Aaron . Digulla]

Arnaud HERITIER <[EMAIL PROTECTED]> wrote:

> Did you try to clean the project before ?
> I successfully built it yesterday.

Yes. I've also tried to build with and without Codehaus snapshots but to 
no avail.

Maybe it's not Archive but a new maven plugin that causes the problem?

Also, can someone tell me where DigestUtils is now? I have problems with 
the checksum checking code (see http://jira.codehaus.org/browse/MRM-154).

Regards,

-- 
Aaron Digulla

> Aaron.Digulla wrote:
> > 
> > Hello,
> > 
> > I updated Archiva today and tried to compile it. The "mvn install" 
aborts 
> > with NoClassDefFoundError:
> > 
> > [INFO] 
> > 

> > [INFO] Building Archiva Web Application
> > [INFO]task-segment: [install]
> > [INFO] 
> > 

> > [INFO] [plexus:descriptor {execution: default}]
> > [INFO] [plexus:descriptor {execution: default}]
> > [INFO] [resources:resources]
> > [INFO] Using default encoding to copy filtered resources.
> > [INFO] [plexus:merge-descriptors {execution: default}]
> > [INFO] 
> > 

> > [ERROR] FATAL ERROR
> > [INFO] 
> > 

> > [INFO] Lorg/codehaus/plexus/archiver/manager/ArchiverManager;
> > [INFO] 
> > 

> > [INFO] Trace
> > java.lang.NoClassDefFoundError: 
> > Lorg/codehaus/plexus/archiver/manager/ArchiverManager;
> > at java.lang.Class.getDeclaredFields0(Native Method)
> > at java.lang.Class.privateGetDeclaredFields(Class.java:2259)
> > at java.lang.Class.getDeclaredField(Class.java:1852)
> > at 
> > org.codehaus.plexus.util.ReflectionUtils.
> getFieldByNameIncludingSuperclasses(ReflectionUtils.java:26)
> > at 
> > org.codehaus.plexus.util.ReflectionUtils.
> getFieldByNameIncludingSuperclasses(ReflectionUtils.java:34)
> > at 
> > org.codehaus.plexus.component.composition.FieldComponentComposer.
> getFieldByName(FieldComponentComposer.java:212)
> > at 
> > org.codehaus.plexus.component.composition.FieldComponentComposer.
> findMatchingField(FieldComponentComposer.java:171)
> > 
> > What's wrong?


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

Error compiling Archiva

[Aaron . Digulla]

Hello,

I updated Archiva today and tried to compile it. The "mvn install" aborts 
with NoClassDefFoundError:

[INFO] 

[INFO] Building Archiva Web Application
[INFO]task-segment: [install]
[INFO] 

[INFO] [plexus:descriptor {execution: default}]
[INFO] [plexus:descriptor {execution: default}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [plexus:merge-descriptors {execution: default}]
[INFO] 

[ERROR] FATAL ERROR
[INFO] 

[INFO] Lorg/codehaus/plexus/archiver/manager/ArchiverManager;
[INFO] 

[INFO] Trace
java.lang.NoClassDefFoundError: 
Lorg/codehaus/plexus/archiver/manager/ArchiverManager;
at java.lang.Class.getDeclaredFields0(Native Method)
at java.lang.Class.privateGetDeclaredFields(Class.java:2259)
at java.lang.Class.getDeclaredField(Class.java:1852)
at 
org.codehaus.plexus.util.ReflectionUtils.getFieldByNameIncludingSuperclasses(ReflectionUtils.java:26)
at 
org.codehaus.plexus.util.ReflectionUtils.getFieldByNameIncludingSuperclasses(ReflectionUtils.java:34)
at 
org.codehaus.plexus.component.composition.FieldComponentComposer.getFieldByName(FieldComponentComposer.java:212)
at 
org.codehaus.plexus.component.composition.FieldComponentComposer.findMatchingField(FieldComponentComposer.java:171)

What's wrong?

Regards,

-- 
Aaron Digulla


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

Re: MSOURCES-11 When source plugin is used, it should make sure it is invoked during install

[Aaron . Digulla]

Hello,

I'm trying to write a patch for MSOURCES-11.

If I have this in my pom.xml:

  


true
org.apache.maven.plugins
maven-jar-plugin
2.1



test-jar





true
org.apache.maven.plugins
maven-source-plugin
2.0.1



jar





  

the test jar will always be created while the sources-jar will only be 
created if the plugin is configured in the pom.xml of every module. It 
does not work if the plugin is configured in the parent pom!

Somehow, the definition of maven-jar-plugin is passed into module POMs 
while this doesn't happen for maven-source-plugin.

I checked that the config is correct by running mvn help:effective-pom 
which prints:


  maven-jar-plugin
  2.1
  

  
test-jar
  

  
  true


  maven-source-plugin
  2.0.1
  

  
jar
  

  
  true


but only the test jar is created. It's as if the config for 
maven-source-plugin is ignored.

When I run maven with -X, there is no trace of the config of 
maven-source-plugin while maven-jar-plugin is mentioned:

[DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::1 
for project: null:maven-resources-plugin:maven-plugin:2.2 from the 
repository.
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::1 for 
project: org.apache.maven.plugins:maven-plugins:pom:1 from the repository.
[DEBUG] Retrieving parent-POM: org.apache:apache::1 for project: 
org.apache.maven:maven-parent:pom:1 from the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::1 
for project: null:maven-compiler-plugin:maven-plugin:2.0.1 from the 
repository.
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::1 for 
project: org.apache.maven.plugins:maven-plugins:pom:1 from the repository.
[DEBUG] Retrieving parent-POM: org.apache:apache::1 for project: 
org.apache.maven:maven-parent:pom:1 from the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::1 
for project: null:maven-surefire-plugin:maven-plugin:2.2 from the 
repository.
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::1 for 
project: org.apache.maven.plugins:maven-plugins:pom:1 from the repository.
[DEBUG] Retrieving parent-POM: org.apache:apache::1 for project: 
org.apache.maven:maven-parent:pom:1 from the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::3 
for project: null:maven-jar-plugin:maven-plugin:2.1 from the repository.
[DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::4 for 
project: org.apache.maven.plugins:maven-plugins:pom:3 from the repository.
[DEBUG] Retrieving parent-POM: org.apache:apache::3 for project: 
org.apache.maven:maven-parent:pom:4 from the repository.
[DEBUG] 
org.apache.maven.plugins:maven-resources-plugin:maven-plugin:2.2:runtime 
(selected for runtime)

Does anyone have any idea what the problem could be?

Regards,

-- 
Aaron Digulla


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

Re: [VOTE] Release PMD Plugin

[Aaron . Digulla]

> Could it be updated to use PMD 3.8 first?   3.7 is still very buggy with 

> JDK 1.5 code.  3.8 has several fixes for that.

I'm using a locally patched version of the PMD plugin which uses 3.8 for 
some time now. All you have to do is to change the version number to 3.8.

So I second this request.

Please also consider http://jira.codehaus.org/browse/MPMD-44 (allow to 
specify a ruleset in the POM) because it's just a single line change. I've 
tested the patch here and it works OK for me.

With those two: +1

Without those two: 0

Best regards,

-- 
Aaron Digulla
Daniel Kulp <[EMAIL PROTECTED]> schrieb am 06.11.2006 05:41:40:


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

Re: Plugin execution ordering within a phase

[Aaron . Digulla]

> > There's just one problem - inheritance. Should plugins/executions 
> > defined
> > in the parent be placed before or after the ones in the child pom?
> > I'd say before, but maybe they need to be interleaved..
> 
> This is where an  element makes a lot of sense.  The order 
> doesn't have to be sequential integers, you just sort whatever you 
> have from all the inherited POMs.

In the AROS project, we use MetaMake (a tool which we developed 
ourselves). Basically, in MetaMake, you can depend on targets defined 
elsewhere in the project.

In the first pass, MM collects all meta-targets and then looks for targets 
which don't depend on anything else. These are run. Now all dependencies 
to these are deleted and the cycle starts again until everything is built.

This is very easy for the developers to handle: They just say "run me 
after Xyz". This feels natural and is easy to implement without assigning 
priorities.

Cycles are easy to detect in MM (set a flag which gets cleared if 
something could be built and check the flag after one cycle) but they 
appear very rarely, so this solution works pretty well for us.

Therefore, I suggest using a "depends" or "after" element so maven can 
build the dependency chains for us instead of developers having to think 
about the ordering of the whole process.

I guess there are two types of these dependencies:

goal/phase: Do the build step after a specific goal or phase has 
completed.

id-based: Devs should be able to assign IDs to plugins, so you can say 
"before you run me, run that first" in your pom.

One could argue that the latter ones could be dangerous when their POMs 
get installed in the maven repo. I'm not sure if that's really an issue, 
though. Most of the time, these dependencies will be necessary for 
internal (complex) projects which don't get deployed. Also, if I 
understand this correctly, maven doesn't import build instructions from 
dependencies (only parent POMs), so we need only care about parent POMs. 
How hard would it be to make sure parent POMs in the maven repo don't use 
this feature?

(Note: The parent-POM problem is not related to my solution!)

Regards,

-- 
Aaron Digulla


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

Classloader woes

[Aaron . Digulla]

Hello,

I need help with a classloader problem. Can someone tell me the difference 
between:

String s = "/data/demo.txt";
URL u1 = this.getClass().getResource(s);
URL u2 = this.getClass().getClassLoader().getResource(s);

My problem: u1 is != null (so the path is correct and the resouce is in 
the JAR, etc) but u2 is *always* null.

I've been looking at the Java VM source (Sun) and getResource() just calls 
getClassLoader0() just like getClassLoader() does (there is no 
SecurityManager installed).

Regards,

-- 
Aaron Digulla


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

Re: integration tests: how to handle versions and external oddities?

[Aaron . Digulla]

How do you handle the case of tests which don't have to or should be run 
every time?

In my case, I have tests which check external connectivity which means 
that other systems have to be up and running (and correctly configured) or 
the test will fail. Currently, I'm using exclude rules and run the connect 
tests manually but I'd prefer some kind of switch on the command line to 
enable them.

For example, in the integration test, I'd like the tests to run always 
because there, the other systems should be up. In the development 
environment, they're only up when I ask for them.

Regards,

-- 
Aaron Digulla

Brett Porter <[EMAIL PROTECTED]> schrieb am 30.10.2006 09:12:53:

> I was thinking that as well, wrt testng. It would be really good to 
> establish some dependencies so that tests that are bound to fail 
> could just be skipped if an earlier one fails. Also, the groups would 
> be useful to run artifact related tests together, etc.
> 
> I'm not sure about branching the tests - I thought that was what we 
> were trying to get away from by taking them away from the 
> corresponding tags/branches/trunk?
> 
> On 30/10/2006, at 7:01 PM, Dan Fabulich wrote:
> 
> > I should also mention that TestNG has some handy facilities to handle
> > marking tests as "skipped" based on fancy criteria...  I still think
> > branching the tests is the cleanest way to handle this, but running
> > integration tests in TestNG is a good fit regardless.
> >
> > -Dan
> >
> >> -Original Message-
> >> From: Dan Fabulich
> >> Sent: Sunday, October 29, 2006 11:33 PM
> >> To: Maven Developers List
> >> Subject: RE: integration tests: how to handle versions?
> >>
> >> Jason and I had discussed this briefly a while ago...  In my opinion,
> >> the best/clearest way to handle this is to branch the integration
> > tests.
> >>
> >> -Dan
> >>
> >>> -Original Message-
> >>> From: Brett Porter [mailto:[EMAIL PROTECTED]
> >>> Sent: Sunday, October 29, 2006 4:24 PM
> >>> To: Maven Developers List
> >>> Subject: integration tests: how to handle versions?
> >>>
> >>> Hi,
> >>>
> >>> I like the new integration testing method. However, I've just added
> > a
> >>> test that will only work with a version of Maven that fixes the bug
> >>> (which I have sorted out locally, just doing some other checks
> > before
> >>> committing).
> >>>
> >>> So the two things we need to do:
> >>> - exclude that test from Maven < 2.0.5
> >>> - display what Maven version is being used before starting, because
> > I
> >>> keep accidentally using the wrong version.
> >>>
> >>> Maybe the  tag in the pom.xml for the test (and
> >>> handle the error case from Maven), or just have a condition in the
> >>> test that if mavenVersion < 2.0.5(which would need to be obtained in
> >>> the verifier, perhaps by scraping mvn -version), output SKIPPED.
> >>>
> >>> Any thoughts on the best way to do this?
> >>>
> >>> - Brett
> >>
> >>
> > __ 

> > _
> >> Notice:  This email message, together with any attachments, may
> > contain
> >> information  of  BEA Systems,  Inc.,  its subsidiaries  and
> > affiliated
> >> entities,  that may be confidential,  proprietary,  copyrighted
> > and/or
> >> legally privileged, and is intended solely for the use of the
> > individual
> >> or entity named in this message. If you are not the intended
> > recipient,
> >> and have received this message in error, please immediately return
> > this
> >> by email and then delete it.
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > __ 

> > _
> > Notice:  This email message, together with any attachments, may 
> > contain
> > information  of  BEA Systems,  Inc.,  its subsidiaries  and 
> > affiliated
> > entities,  that may be confidential,  proprietary,  copyrighted 
> > and/or
> > legally privileged, and is intended solely for the use of the 
> > individual
> > or entity named in this message. If you are not the intended 
> > recipient,
> > and have received this message in error, please immediately return 
> > this
> > by email and then delete it.
> >
> > -
> > 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]
> 


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

Re: Antwort: SAXParser problem with Maven 2.0.4, Xalan 2.8.1, Xerces 2.8

[Aaron . Digulla]

barry <[EMAIL PROTECTED]> schrieb am 24.10.2006 21:53:16:

>  This is a great cvs reporting plug-in you've started for maven2, have 
you
> been succesful and would you be putting it for public use.

Well, somewhat :-) Open issues:

1. I can't run the plugin "inline", ie. because of the SAXParser issues, I 
have to spawn a new process :-(

2. I didn't manage to get StatCVS-XML to work, so my plugin depends on 
StatCVS itself.

If you can live with that, I'm game to put the code online, now. Note that 
I can't access CVS from here. Subversion works, though. How should I 
proceed?

Regards,

-- 
Aaron Digulla


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

RE: Maven and the Apache processes...

[Aaron . Digulla]

Jörg Schaible <[EMAIL PROTECTED]> schrieb am 20.10.2006 
10:35:18:

> Jason van Zyl wrote on Thursday, October 19, 2006 11:14 PM:
> > 
> > I think skipping release numbers is Bad Thing(tm). It would certainly
> > confuse users if we release Maven 2.0.7 next.
> 
> Anything > 2.0.4 would be welcome ... hehehe
> 
> Technically you could simply use an additional number at the end:
> 
> maven-2.0.5.x
> 
> And if final 2.0.5 is in the end 2.0.5.4 ... who cares? You might 
> also call x the build number, so Maven 2.0.5 would be e.g. maven-2.
> 0.5.4711 ... done so by Windows for a long time. The only thing 

What's wrong with 2.0.4711? Isn't it "major.minor.patchlevel"?

I see no reason to add another level which doesn't add any useful 
information.

The confusion of users would only happen if there was no hint what 
happened to 2.0.6, so we just need a complete changelog.

Regards,

-- 
Aaron Digulla


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

Antwort: Re: Maven and the Apache processes...

[Aaron . Digulla]

Joakim Erdfelt <[EMAIL PROTECTED]> schrieb am 13.10.2006 20:06:51:

> 
===
> == LICENSE FILE / HEADER
> 
> The LICENSE file is a unique monster in the world of apache.
> It will always be Apache v2.0.

Thank you. But please keep in mind that maven is also used by non-apache 
projects which just might not like the idea to be relicensed automatically 
;-)

Please create the plugin in such a way that a different license can be 
specified easily. Also, allow to specify where it should go to in the 
release.

Regards,

-- 
Aaron Digulla


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

Antwort: Re: Determine the path to a JAR file

[Aaron . Digulla]

Ok, I guess I'm still not used to the "maven way" :-) The code in 
ResolvePluginsMojo was confusing to me until I walked up the class 
hierarchy. Here is what I came up with:

/**
 * Used to look up Artifacts in the remote repository.
 * 
 * @parameter 
expression="${component.org.apache.maven.artifact.factory.ArtifactFactory}"
 * @required
 * @readonly
 */
protected org.apache.maven.artifact.factory.ArtifactFactory factory;

/**
 * Used to look up Artifacts in the remote repository.
 * 
 * @parameter 
expression="${component.org.apache.maven.artifact.resolver.ArtifactResolver}"
 * @required
 * @readonly
 */
protected org.apache.maven.artifact.resolver.ArtifactResolver 
resolver;

/**
 * Location of the local repository.
 * 
 * @parameter expression="${localRepository}"
 * @readonly
 * @required
 */
protected org.apache.maven.artifact.repository.ArtifactRepository 
local;

/**
 * List of Remote Repositories used by the resolver
 * 
 * @parameter expression="${project.remoteArtifactRepositories}"
 * @readonly
 * @required
 */
protected java.util.List remoteRepos;

private File getArtifactFile(String groupId, String artifactId, 
String version) throws MavenReportException
{
// Ask maven for the correct path to statcvs
VersionRange range = VersionRange.createFromVersion 
(version);
Artifact statcvs = factory.createPluginArtifact(groupId, 
artifactId, range);
try {
resolver.resolve(statcvs, remoteRepos, local);
} catch (ArtifactResolutionException e) {
throw new MavenReportException ("Error resolving 
artifact "+statcvs, e);
} catch (ArtifactNotFoundException e) {
throw new MavenReportException ("Error resolving 
artifact "+statcvs, e);
}
 
return statcvs.getFile();
}

Is this code correct?

Now, it would be great if I could access my plugin's POM (*not* the POM of 
the current project) to load the version number from there. Is there a 
way? 

I guess I could use a filter :-/

Regards,

-- 
Aaron Digulla

[EMAIL PROTECTED] schrieb am 13.10.2006 11:11:39:

> "Dan Tran" <[EMAIL PROTECTED]> schrieb am 12.10.2006 12:14:47:
> 
> > > How do I determine the absolute path for a JAR in the repository?
> > 
> 
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-dependency-plugin
> > 
> > Look for Copy Artifact/Dependency, etc
> 
> That's only for project dependencies. I need to find the dependencies of 

> myself (where self == report plugin)!
> 
> I tried to find myself in getProject().getReportArtifactMap() which 
works 
> but the Artifact returned contains almost no information (getFile() is 
> null, for example, the list of dependencies is empty, the metadata is 
> empty, ...)
> 
> The next idea was to browse the Repositories but how do I ask a 
repository 
> for an artifact? (Note: this artifact is *not* in the dependency list of 

> the current POM!)
> 
> Regards,
> 
> -- 
> Aaron Digulla
> 
> 
> -
> 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: Determine the path to a JAR file

[Aaron . Digulla]

"Dan Tran" <[EMAIL PROTECTED]> schrieb am 12.10.2006 12:14:47:

> > How do I determine the absolute path for a JAR in the repository?
> 
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-dependency-plugin
> 
> Look for Copy Artifact/Dependency, etc

That's only for project dependencies. I need to find the dependencies of 
myself (where self == report plugin)!

I tried to find myself in getProject().getReportArtifactMap() which works 
but the Artifact returned contains almost no information (getFile() is 
null, for example, the list of dependencies is empty, the metadata is 
empty, ...)

The next idea was to browse the Repositories but how do I ask a repository 
for an artifact? (Note: this artifact is *not* in the dependency list of 
the current POM!)

Regards,

-- 
Aaron Digulla


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

Antwort: Maven and the Apache processes...

[Aaron . Digulla]

Daniel Kulp <[EMAIL PROTECTED]> schrieb am 12.10.2006 16:36:57:

> 1) The LICENSE/NOTICE files in the META-INF dir of the jar - currently, 
> none of the maven plugins do this at all.   I've seen projects handle 
> this in a couple different ways.   Some projects put them in the 
> src/main/resources... dir like other resources, but that kind of hides 
> them.   Others put them in the same dir as the pom.xml and add a "." 
> resource dir, but that breaks eclipse:eclipse.  Both have the issue 
> of having BUNCHES of copies of the LICENSE and NOTICE files to maintain, 

> which sucks.

How about a license plugin? Then, the plugin could copy this new resource 
into the right place.

Or putting licences into a special maven dependency? Maybe we could add 
"source" dependencies. There are like JAR dependencies but are downloaded 
and compiled locally instead.

I mean, 99% of all license files will me verbatim copies of the original 
ones, so we could keep them in a single, central space. And in the POM, I 
just say "license:gpl:2.0".

Regards,

-- 
Aaron Digulla


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

Determine the path to a JAR file

[Aaron . Digulla]

Hello,

How do I determine the absolute path for a JAR in the repository?

In the StatCVS plugin for Maven2, I need to know where 
statcvs:statcvs:0.2.3 is. Since I have to fork a Java process, it's not 
enough just to define this dependency in the pom of the plugin, I need a 
way to determine its path after maven's dependency mechanism has 
downloaded it for me.

This also means I cannot ask for ${project.dependencies} because it's a 
dependency of the plugin, not the project.

Regards,

-- 
Aaron Digulla


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

Antwort: SAXParser problem with Maven 2.0.4, Xalan 2.8.1, Xerces 2.8.0 and Java 1.5

[Aaron . Digulla]

Hello,

I made some further progress.

Apparently, the problem is in Sun's SAXParserFactory which stores a 
classloader internally. This classloader is from the Pleistocene (when the 
current VM was still fresh and didn't know about Maven).

So when my plugin comes into play, the classloader used by SAX simply 
doesn't know about any classes loaded by the maven classloader.

*expletive deleted*

Is it possible to create a plugin which uses Xalan 2.8.1 despite the fact 
that maven has its own Xalan in lib/endorsed and with Java 1.5?

Regards,

-- 
Aaron Digulla

[EMAIL PROTECTED] schrieb am 11.10.2006 13:32:47:

> Hello,
> 
> I'm trying to port StatCVS to maven2 and had some success ... well, if I 

> invoke
> StatCVS as a subprocess.
> 
> But I want to invoke StatCVS directly, too. Now, I'm stuck while 
invoking 
> StatCVS
> from Java. When I try, I get this error:
> 
> saxFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> ...
> Caused by: javax.xml.parsers.FactoryConfigurationError: Provider 
> org.apache.xerc
> es.jaxp.SAXParserFactoryImpl could not be instantiated: 
> java.lang.NullPointerExc
> eption
> at javax.xml.parsers.SAXParserFactory.newInstance(Unknown 
Source)
> at 
> de.berlios.statcvs.xml.output.HTMLRenderer.create(HTMLRenderer.java:98)
> 
> The code looks like this:
> 
> SAXParserFactory x = new 
> org.apache.xerces.jaxp.SAXParserFactoryImpl();
> System.out.println("saxFactory="+x.getClass().getName());
> 
> x = SAXParserFactory.newInstance(); // <-- This is line 98
> System.out.println("saxFactory="+x.getClass().getName());
> 
> So basically, when I instantiate the SAXParserFactoryImpl directly, it 
> works
> which means that Xerces is in the classpath. When I use
> javax.xml.parsers.SAXParserFactory.newInstance() (as I should), I get a 
> NPE but
> the classname is the same in both cases!
> 
> When I run this code within Eclipse, it works. Therefore, I assume that 
> maven
> somehow breaks this but I have no idea what could cause this.
> 
> Any ideas?
> 
> Best Regards,
> 
> -- 
> Aaron Digulla
> 
> -
> 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]

Antwort: RE: manually managing external dependencies in maven 2

[Aaron . Digulla]

Hello,

A simple solution would be to run "mvn -U" (i.e. run a CLI command) which 
will update all dependencies in the repository.

There should also be a goal which just downloads all dependencies without 
compiling.

But a clean way to browse the dependency tree (including "update this") 
from Java code would be nice, too. Don't forget to post here if you find a 
solution!

Regards,

-- 
Aaron Digulla

fogwolf <[EMAIL PROTECTED]> schrieb am 11.10.2006 16:39:43:

> 
> Thanks for the suggestion. This Eclipse plugin looks good & does a lot 
of
> what the plugin I've written does, but I'd still like to know how to 
control
> the download of external dependencies, since my plugin does more custom
> things I've written based on my development environment here. Could 
anyone
> help with that?
> 
> Thanks!
> 
> 
> Manuel Ledesma wrote:
> > 
> > Look at this page, it might help u 
> > 
> > http://maven.apache.org/eclipse-plugin.html
> > 
> > -Original Message-
> > From: fogwolf [mailto:[EMAIL PROTECTED] 
> > Sent: Tuesday, October 10, 2006 5:24 PM
> > To: dev@maven.apache.org
> > Subject: manually managing external dependencies in maven 2
> > 
> > 
> > Hi,
> > 
> > I'm using Maven 2 for managing my Java projects in Eclipse & am 
wondering
> > how I can manually get Maven to check for any new external 
dependencies in
> > my pom.xml & automatically download them to the local repository 
without
> > having to call "maven compile". I have a Java Mojo that I run after 
adding
> > dependencies to a project's pom which updates Eclipse's .classpath 
file
> > with
> > any added dependencies but then Eclipse flags the project with an 
error if
> > it's not a dependency already stored in my local repository. How could 
I
> > add
> > a step to download any new dependencies from this plugin I've written?
> > 
> > Thanks! 
> > -- 
> > View this message in context:
> > 
http://www.nabble.com/manually-managing-external-dependencies-in-maven-2-tf2
> > 419629.html#a6745832
> > Sent from the Maven Developers mailing list archive at Nabble.com.
> > 
> > 
> > -
> > 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]
> > 
> > 
> > 
> 
> -- 
> View this message in context: http://www.nabble.com/manually-
> managing-external-dependencies-in-maven-2-tf2419629.html#a6757750
> Sent from the Maven Developers mailing list archive at Nabble.com.
> 
> 
> -
> 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]

SAXParser problem with Maven 2.0.4, Xalan 2.8.1, Xerces 2.8.0 and Java 1.5

[Aaron . Digulla]

Hello,

I'm trying to port StatCVS to maven2 and had some success ... well, if I 
invoke
StatCVS as a subprocess.

But I want to invoke StatCVS directly, too. Now, I'm stuck while invoking 
StatCVS
from Java. When I try, I get this error:

saxFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
...
Caused by: javax.xml.parsers.FactoryConfigurationError: Provider 
org.apache.xerc
es.jaxp.SAXParserFactoryImpl could not be instantiated: 
java.lang.NullPointerExc
eption
at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source)
at 
de.berlios.statcvs.xml.output.HTMLRenderer.create(HTMLRenderer.java:98)

The code looks like this:

SAXParserFactory x = new 
org.apache.xerces.jaxp.SAXParserFactoryImpl();
System.out.println("saxFactory="+x.getClass().getName());

x = SAXParserFactory.newInstance(); // <-- This is line 98
System.out.println("saxFactory="+x.getClass().getName());

So basically, when I instantiate the SAXParserFactoryImpl directly, it 
works
which means that Xerces is in the classpath. When I use
javax.xml.parsers.SAXParserFactory.newInstance() (as I should), I get a 
NPE but
the classname is the same in both cases!

When I run this code within Eclipse, it works. Therefore, I assume that 
maven
somehow breaks this but I have no idea what could cause this.

Any ideas?

Best Regards,

-- 
Aaron Digulla

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