Resource filtering...

["Washusen, Dan" <Da...@sensis.com.au>]

I noticed that the resource element in the project.xml has a
<filtering>true</filtering> element.  Can anyone point me in the direction
on some doco (or anything) that could help me understand what this achieves?


I've had a quick hunt around and only really found Maven NG
details/thoughts...  Does it basically boil down to using ant's filtering?

Cheers,
--
Dan Washusen
Developer
Structured Search
Sensis Pty Ltd

www.sensis.com.au

A leading Australian advertising, information 
and directories business. 

www.yellowpages.com.au
www.whitepages.com.au
www.citysearch.com.au
www.whereis.com.au
www.telstra.com.au
www.tradingpost.com.au

This email and any attachments are intended only for the use of the recipient and may be confidential and/or legally privileged.
Sensis Pty Ltd disclaims liability for any errors, omissions, viruses, loss and/or damage arising from using, opening or transmitting this email.
If you are not the intended recipient you must not use, interfere with, disclose, copy or retain this email and you should notify the sender immediately by return email or by contacting Sensis Pty Ltd by telephone on [+61 3 9201 4888]

Re: XML entities and forward compatibility

[Jason van Zyl <jv...@maven.org>]

On Tue, 2004-06-08 at 23:20, Jeff Turner wrote:
> Character entities (Ӓ) are handy though, for storing 16 bit unicode
> chars in a utf8/ascii project.xml.  Hopefully xpp3 distinguishes
> character entities from external entities.

I believe they do, but the source is so small it wouldn't be hard to
wangle it in.

> --Jeff
> 
> On Tue, Jun 08, 2004 at 09:50:41PM -0400, Jason van Zyl wrote:
> > On Tue, 2004-06-08 at 21:24, Dion Gillard wrote:
> > > Given that they're a standard part of XML, and that the m2 project
> > > descriptor in one form will be an XML document, why would they not be
> > > available?
> > 
> > If decided that the native mechanisms would work best, which I
> > definitely think would be the case as there would be one standard way
> > that work whereas the use of XML entities could be used in any fashion,
> > then I would disable their use them in the xpp3 parser.
> > 
> > I honestly cannot see any cases where entities would be beneficial with
> > what's running now in m2. Also, with some of the more advanced features
> > in m2 for conflict resolution amongst dependencies, better jar
> > overriding, and better general handling of artifacts exact control over
> > processing becomes necessary. I would really like to avoid having to
> > locate the source of a problem by finding the source of an entity.
> > 
> > In addition things like accurate authoring will have difficulty dealing
> > with entities. If you, say, have a GUI that is allowing you to fix a
> > conflict, or align dependencies then we can provide the exact
> > information to client code to find the source of the conflict.
> > 
> > I don't see any upside to entities at all in m2 and I think they would
> > actually be harmful. Nothing special happens with the processing of XML
> > in m1 so it doesn't really matter. But sophisticated tools will need
> > exacting control whether than be our own like the conflict resolution
> > mechanism or GUI tools.
> > 
> > -- 
> > jvz.
> > 
> > Jason van Zyl
> > jason@maven.org
> > http://maven.apache.org
> > 
> > happiness is like a butterfly: the more you chase it, the more it will
> > elude you, but if you turn your attention to other things, it will come
> > and sit softly on your shoulder ...
> > 
> >  -- Thoreau 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org

-- 
jvz.

Jason van Zyl
jason@maven.org
http://maven.apache.org

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

 -- Thoreau 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: XML entities and forward compatibility

[Jeff Turner <je...@apache.org>]

Character entities (Ӓ) are handy though, for storing 16 bit unicode
chars in a utf8/ascii project.xml.  Hopefully xpp3 distinguishes
character entities from external entities.

--Jeff

On Tue, Jun 08, 2004 at 09:50:41PM -0400, Jason van Zyl wrote:
> On Tue, 2004-06-08 at 21:24, Dion Gillard wrote:
> > Given that they're a standard part of XML, and that the m2 project
> > descriptor in one form will be an XML document, why would they not be
> > available?
> 
> If decided that the native mechanisms would work best, which I
> definitely think would be the case as there would be one standard way
> that work whereas the use of XML entities could be used in any fashion,
> then I would disable their use them in the xpp3 parser.
> 
> I honestly cannot see any cases where entities would be beneficial with
> what's running now in m2. Also, with some of the more advanced features
> in m2 for conflict resolution amongst dependencies, better jar
> overriding, and better general handling of artifacts exact control over
> processing becomes necessary. I would really like to avoid having to
> locate the source of a problem by finding the source of an entity.
> 
> In addition things like accurate authoring will have difficulty dealing
> with entities. If you, say, have a GUI that is allowing you to fix a
> conflict, or align dependencies then we can provide the exact
> information to client code to find the source of the conflict.
> 
> I don't see any upside to entities at all in m2 and I think they would
> actually be harmful. Nothing special happens with the processing of XML
> in m1 so it doesn't really matter. But sophisticated tools will need
> exacting control whether than be our own like the conflict resolution
> mechanism or GUI tools.
> 
> -- 
> jvz.
> 
> Jason van Zyl
> jason@maven.org
> http://maven.apache.org
> 
> happiness is like a butterfly: the more you chase it, the more it will
> elude you, but if you turn your attention to other things, it will come
> and sit softly on your shoulder ...
> 
>  -- Thoreau 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: XML entities and forward compatibility

[Jason van Zyl <jv...@maven.org>]

On Tue, 2004-06-08 at 21:24, Dion Gillard wrote:
> Given that they're a standard part of XML, and that the m2 project
> descriptor in one form will be an XML document, why would they not be
> available?

If decided that the native mechanisms would work best, which I
definitely think would be the case as there would be one standard way
that work whereas the use of XML entities could be used in any fashion,
then I would disable their use them in the xpp3 parser.

I honestly cannot see any cases where entities would be beneficial with
what's running now in m2. Also, with some of the more advanced features
in m2 for conflict resolution amongst dependencies, better jar
overriding, and better general handling of artifacts exact control over
processing becomes necessary. I would really like to avoid having to
locate the source of a problem by finding the source of an entity.

In addition things like accurate authoring will have difficulty dealing
with entities. If you, say, have a GUI that is allowing you to fix a
conflict, or align dependencies then we can provide the exact
information to client code to find the source of the conflict.

I don't see any upside to entities at all in m2 and I think they would
actually be harmful. Nothing special happens with the processing of XML
in m1 so it doesn't really matter. But sophisticated tools will need
exacting control whether than be our own like the conflict resolution
mechanism or GUI tools.

-- 
jvz.

Jason van Zyl
jason@maven.org
http://maven.apache.org

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

 -- Thoreau 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: XML entities and forward compatibility

[Dion Gillard <di...@gmail.com>]

Given that they're a standard part of XML, and that the m2 project
descriptor in one form will be an XML document, why would they not be
available?

On 08 Jun 2004 21:21:50 -0400, Jason van Zyl <jv...@maven.org> wrote:
> 
> On Tue, 2004-06-08 at 19:23, Tim Reilly wrote:
> > Does anyone know, or can anyone comment on whether external xml entities in
> > the POM (particularly for dependencies) will continue to work or be
> > supported in future versions (maven-2, etc)?
> 
> You won't need them and the plexus and geronimo builds will be proof of
> that. Today was infact the first day a build using arbitrary recursive
> inheritance and transitive dependencies occurred. Michal finished
> checking in his wagon integration into m2, I tweaked it a bit and
> presto! A new level of manageability.
> 
> I really, really, really don't want to promote the use of entities. I've
> kept my mouth shut because they were really the only way to work around
> some congenital problems in m1. m2 is a ways off and there will be some
> surveys for users and one of questions will be regarding the use of
> entities. No one will probably want to use them anyway with m2.
> 
> > Before making so many changes... just want verify.
> >
> > TIA,
> > -TR
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> 
> --
> jvz.
> 
> Jason van Zyl
> jason@maven.org
> http://maven.apache.org
> 
> happiness is like a butterfly: the more you chase it, the more it will
> elude you, but if you turn your attention to other things, it will come
> and sit softly on your shoulder ...
> 
>  -- Thoreau
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: XML entities and forward compatibility

[Jason van Zyl <jv...@maven.org>]

On Tue, 2004-06-08 at 19:23, Tim Reilly wrote:
> Does anyone know, or can anyone comment on whether external xml entities in
> the POM (particularly for dependencies) will continue to work or be
> supported in future versions (maven-2, etc)?

You won't need them and the plexus and geronimo builds will be proof of
that. Today was infact the first day a build using arbitrary recursive
inheritance and transitive dependencies occurred. Michal finished
checking in his wagon integration into m2, I tweaked it a bit and
presto! A new level of manageability.

I really, really, really don't want to promote the use of entities. I've
kept my mouth shut because they were really the only way to work around
some congenital problems in m1. m2 is a ways off and there will be some
surveys for users and one of questions will be regarding the use of
entities. No one will probably want to use them anyway with m2.

> Before making so many changes... just want verify.
> 
> TIA,
> -TR
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org

-- 
jvz.

Jason van Zyl
jason@maven.org
http://maven.apache.org

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

 -- Thoreau 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

XML entities and forward compatibility

[Tim Reilly <ti...@consultant.com>]

Does anyone know, or can anyone comment on whether external xml entities in
the POM (particularly for dependencies) will continue to work or be
supported in future versions (maven-2, etc)?

Before making so many changes... just want verify.

TIA,
-TR



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Resource filtering...

[Tim Reilly <ti...@consultant.com>]

Sorry for the noise, hopefully one these answers Dan's question.

http://wiki.codehaus.org/maven/FilteringResources
http://wiki.codehaus.org/maven/ResourceFiltering


-TR



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: Resource filtering...

[Tim Reilly <ti...@consultant.com>]

Ditto. Same question here.

In my case I have a test resource, but don't want it in the resulting jar.
I think the filter is for such cases, but don't know how to use it?
Or is this feature available/implemented yet?


I assume it supports this?:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-514

> Washusen, Dan wrote:
>
> I noticed that the resource element in the project.xml has a
> <filtering>true</filtering> element.  Can anyone point me in the direction
> on some doco (or anything) that could help me understand what
> this achieves?
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org