date:20070710




Daniel Kulp wrote:

On Monday 09 July 2007 19:08, Kenney Westerhof wrote:

Daniel Kulp wrote:

On Monday 09 July 2007 14:42, Kenney Westerhof wrote:

Daniel Kulp wrote:

Yep.   That's the #1 issue.I've completely given up on trying to
get the string ${pom.version} outputted into the file.

Ok, but why are you filtering a file with that in there? Do you need
filtering at all, or do you only want some things filtered?

You can exclude specific files from filtering; doesn't that solve your
problem?


It has to do with creating an archtype.   The pom.xml that we want the 
archtype to create needs to have certain versions pushed in, but other 
things in the pom should be left as is (or allow us to escape it).


The other thing we want to do is push some values INTO a resource that 
eventually is a velocity template.  (actually, that's what an archtype 
is anyway).   For those, we need the ability to not have some thing 
substituted in.




Ok, so it's archetype stuff. Well, the archetype resources
should be velocity templates anyway, and processed with velocity.
It should -not- use filtering, just pure velocity. 
Then you can use the velocity escaping mechanisms to leave certain 
expressions untouched.


So for the short run I think updating archetype itself is the safest..


Maybe just adding escaping to interpolationfilterreader is much
simpler than all of this, wdyt?


Probably yes, but would you consider that backwords compatible?   

I have no problems with going that route if people don't think it would 
seriously impact people.  


Depends on how we'll be escaping I guess..

-- Kenney



Dan



The other thing I'd like to do is conditional filtering based on
whether the version is a SNAPSHOT or not.   Kind of like: 
(pseudocode, not sure on the velocity syntax)


#if ${pom.version}.indexOf(SNAPSHOT) != -1
version.message=Version ${pom.version} - Use at your own risk.
#else
version.message=Version ${pom.version}
#fi

Why would you want that? :)

-- Kenney


2) The next option would be to add a filterType configuration
property onto the resources plugin itself.   You would need to
configure the plugin to use it.   Also, it would apply to all
resources with filtering=true.We could combine this with (1)
and instead of making simple the default if not specified in the
resource, whatever this option is set to is the default.

This is a better option. the plugin can be configured with resource
sets, which are just initialized from the pom itself.
perhaps 'src/main/velocity/' could be checked by default and
velocity-copied.

The problem is the Resource object that the resources plugin uses
is maven-model defined.   Not something that's extensible as that
requires a schema change.I suppose what COULD work well is to
add: velocityResources = ListResource
configuration to the resources plugin (and if list is empty, look
for the default of src/main/velocity) and use that.In that case,
regular resources can be configured just in build/resources and
build/testResources, but the velocity based ones would need a full
plugin configuration.   A bit inconsistent, but acceptable.


After thinking about this a bit more, I wonder if it makes more
sense to just create a maven-velocity-plugin and ignore resources
all-together? That would be super quick to write.(I'd still like
to see the escaping issue fixed.  :-) We already have the plexus
VelocityComponent.   Would take very little work to wire it into a
plugin.


Anyway, what are peoples thoughts on this?Any other options?
What direction do people feel is the best way to proceed? I
personally would like to go with Option #1 and require Maven 2.0.8
if you want to use the advanced filtering, but I know some people
are totally against schema changes.

Well, if there's a good reason to change the schema then I'm all
for it. Maybe we should just add properties again to dependencies
and resource sets, so the resource plugin can look at the
resourceset property 'filterType' or something, if it's set.

Either way, changes to the model won't happen until 2.1.

So, what's the problem with the filtering?

Getting any of the normal pom properties outputted to the target
file seems to be impossible.

-
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: [VOTE] Configure IDE plugins to download sources by default within Maven projects



Ok, if you really need both sources and javadoc then that should
be possible. I never heard of the shift-f2 but indeed it doesn't work here.
I either use the tooltip when I hover over an element and possibly f2 for focus,
or open the javadoc view which displays the javadoc as soon as I select any 
element, which
does work with sources - no javadoc needed. This seems more of a bug
in eclipse than anything else though.

So I propose:

- if -DdownloadSources is specified, download sources and fallback to javadoc, 
just as it is now
- if -DdownloadJavaDoc is specified, download javadoc (possibly fallback to 
sources)
- if both are specified, download both.

And:

- don't make this a default; the default behaviour of attaching
 either source or javadoc when it's present in the local repo
 is fine though, but turning this on by default is just too slow.

-- Kenney


Mark Hobson wrote:

On 05/07/07, Cabasson Denis [EMAIL PROTECTED] wrote:

Well, I kinda changed the suject of the discussion.

The matter here is whether the eclipse-plugin should be able to 
download sources AND javadoc or only (as is the cas right now) 
sources, and only javadoc as a fallback if sources are missing. I'd 
like to get the plugin download and link both for me.


But I agree with you on the matter that is not the original 
discussion, but it's closely related.
I don't really see how the original discussion could do with the 
actual version of the plugin BTW.


I agree that the eclipse plugin should be able to attach source jars,
javadoc jars or both (MECLIPSE-292), but I think the original
proposition proved to be too contentious.  I'm happy to leave it to
users' discretion for now.

Mark

-
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: Proposal: Required declaration of properties in pom.xml




Jochen Kuhnle wrote:

Hi,

currently, Maven does not require declaration of properties used in 
the pom, you just use them anywhere you like. Usually, if a property 
is missing, bad things tend to happen because it is replaced with the 
string null. On a good day, resources from translations-null-null 


When/where is it null?

aren't included in the build, on bad days it's worse... And when you 
find the missing property in a pom you haven't written, you have to 
figure out what ${lopt} means and what its legal values are...


True, but proper defaults should be specified in the pom itself using
the normal properties tag. Commandline, profiles, and settings
can override these. A pom should just work out of the box. If you
want to customize it you'll have to read the pom to see what can be customized;
there should be a readme or documentation in the pom for that.

There's lots of cases where properties are used - pom interpolation,
plugin configuration, filtering.. which one are you talking about?

For pom interpolation, you may not always want properties evaluated.
In any case, if the property can't be evaluated, the ${expression} is 
left intact. So the null case doesn't apply here..


For plugin configuration, you cannot possibly list all properties for all
plugins out there.

For filtering, you may just want to print a warning or fail; this could
be configured in the resources plugin.

So how/when do you get the 'translations-null-null' problem exactly?

I don't like the proposal as it's way too verbose and as others have said
only fixes a small set of problems you may have, but doesn't cover all
cases.

There's an issue out there to make all property references/declarations
in the pom the same, preferrably propnamevalue/propname. 


Perhaps a 'propertyManagement' section is more appropriate? :)



So instead typing

properties
lopten_US/lopt
/properties

this proposal wants you to write

properties
property
namelopt/name
defaultValueen_US/defaultValue
requiredtrue/required
descriptionLocale to use/description
options
option
valuede_DE/value
descriptionUse German locale/description
/option
/options
/property
/properties


This is rather verbose. Do you really want to list all locales in this case?



Of course, Maven should display an error if a required variable is 
missing. And it would be nice to have help:describe-properties...


-- Kenney




Regards,
Jochen



-
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: Resource filtering thoughts...

2007-07-10 Thread soula_jeremy

What about choosing the sources of property whose be filtering? So we 
can have an way to escape properties

For example, in the pom.xml:
resources
   resource
  filtering
sources
  source
typeMavenProject/type
excludes
   excludepom.version/exclude
 /excludes
  /source
  source
typeCli/type
  /source
  source
typefile/type
  filetoto.properties/file
  /source
/sources
   /resource
/resources

Kenney Westerhof a écrit :



Daniel Kulp wrote:

On Monday 09 July 2007 19:08, Kenney Westerhof wrote:

Daniel Kulp wrote:

On Monday 09 July 2007 14:42, Kenney Westerhof wrote:

Daniel Kulp wrote:

Yep.   That's the #1 issue.I've completely given up on trying to
get the string ${pom.version} outputted into the file.

Ok, but why are you filtering a file with that in there? Do you need
filtering at all, or do you only want some things filtered?

You can exclude specific files from filtering; doesn't that solve your
problem?


It has to do with creating an archtype.   The pom.xml that we want 
the archtype to create needs to have certain versions pushed in, but 
other things in the pom should be left as is (or allow us to escape it).


The other thing we want to do is push some values INTO a resource 
that eventually is a velocity template.  (actually, that's what an 
archtype is anyway).   For those, we need the ability to not have 
some thing substituted in.




Ok, so it's archetype stuff. Well, the archetype resources
should be velocity templates anyway, and processed with velocity.
It should -not- use filtering, just pure velocity. Then you can use 
the velocity escaping mechanisms to leave certain expressions untouched.


So for the short run I think updating archetype itself is the safest..


Maybe just adding escaping to interpolationfilterreader is much
simpler than all of this, wdyt?


Probably yes, but would you consider that backwords compatible?  
I have no problems with going that route if people don't think it 
would seriously impact people.  


Depends on how we'll be escaping I guess..

-- Kenney



Dan



The other thing I'd like to do is conditional filtering based on
whether the version is a SNAPSHOT or not.   Kind of like: 
(pseudocode, not sure on the velocity syntax)


#if ${pom.version}.indexOf(SNAPSHOT) != -1
version.message=Version ${pom.version} - Use at your own risk.
#else
version.message=Version ${pom.version}
#fi

Why would you want that? :)

-- Kenney


2) The next option would be to add a filterType configuration
property onto the resources plugin itself.   You would need to
configure the plugin to use it.   Also, it would apply to all
resources with filtering=true.We could combine this with (1)
and instead of making simple the default if not specified in the
resource, whatever this option is set to is the default.

This is a better option. the plugin can be configured with resource
sets, which are just initialized from the pom itself.
perhaps 'src/main/velocity/' could be checked by default and
velocity-copied.

The problem is the Resource object that the resources plugin uses
is maven-model defined.   Not something that's extensible as that
requires a schema change.I suppose what COULD work well is to
add: velocityResources = ListResource
configuration to the resources plugin (and if list is empty, look
for the default of src/main/velocity) and use that.In that case,
regular resources can be configured just in build/resources and
build/testResources, but the velocity based ones would need a full
plugin configuration.   A bit inconsistent, but acceptable.


After thinking about this a bit more, I wonder if it makes more
sense to just create a maven-velocity-plugin and ignore resources
all-together? That would be super quick to write.(I'd still like
to see the escaping issue fixed.  :-) We already have the plexus
VelocityComponent.   Would take very little work to wire it into a
plugin.


Anyway, what are peoples thoughts on this?Any other options?
What direction do people feel is the best way to proceed? I
personally would like to go with Option #1 and require Maven 2.0.8
if you want to use the advanced filtering, but I know some people
are totally against schema changes.

Well, if there's a good reason to change the schema then I'm all
for it. Maybe we should just add properties again to dependencies
and resource sets, so the resource plugin can look at the
resourceset property 'filterType' or something, if it's set.

Either way, changes to the model won't happen until 2.1.

So, what's the problem with the filtering?

Getting any of the normal pom properties outputted to the target
file seems to be impossible.

RE: [VOTE] Configure IDE plugins to download sources by default within Maven projects


So I propose:

- if -DdownloadSources is specified, download sources and fallback to javadoc, 
just as it is now
- if -DdownloadJavaDoc is specified, download javadoc (possibly fallback to 
sources)
- if both are specified, download both.

And:

- don't make this a default; the default behaviour of attaching
  either source or javadoc when it's present in the local repo
  is fine though, but turning this on by default is just too slow.

This is already done in Eclipse 2.4 although it doesn't fallback to the javadoc.

http://jira.codehaus.org/browse/MECLIPSE-292

--Brian

Re: Maven site plugin and inheritance

2007-07-10 Thread Brett Porter


Hi Fabrice,

This is definitely not the intended behaviour - sounds like a bug.  
FWIW, I've successfully built sites in this fashion before - so  
perhaps you could expand on how you do this (perhaps a sample project?).


Thanks,
Brett


On 07/07/2007, at 1:05 AM, Fabrice Bellingard wrote:


Hi guys,

I'm playing a bit with the maven site plugin to see what's left  
before it
gets released. However, I have a problem with the site.xml  
inheritance when

building multimodule projects: whether I define a site.xml file in
submodules or not, the site plugin always uses the site.xml of the  
root
project to generate the site of the submodules (when I run mvn  
site on the
root project, of course). Is this the normal behaviour of  
inheritance for

the site.xml? How should I do then if I want a cutom site for each
submodule?
Maybe http://docs.codehaus.org/display/MAVEN/Sites+and+Inheritence  
should be

updated?

Fabrice.


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

Re: Resource filtering thoughts...

2007-07-10 Thread Andrew Williams

It's not just archetype - this has come up in appserver too, where  
you need some properties in a file escaped and others left.
I suspect adding escape handling to the InterpolationFilterReader  
might be a good way to go.


Andy

On 10 Jul 2007, at 11:35, Kenney Westerhof wrote:




Daniel Kulp wrote:

On Monday 09 July 2007 19:08, Kenney Westerhof wrote:

Daniel Kulp wrote:

On Monday 09 July 2007 14:42, Kenney Westerhof wrote:

Daniel Kulp wrote:
Yep.   That's the #1 issue.I've completely given up on  
trying to

get the string ${pom.version} outputted into the file.

Ok, but why are you filtering a file with that in there? Do you need
filtering at all, or do you only want some things filtered?

You can exclude specific files from filtering; doesn't that solve  
your

problem?
It has to do with creating an archtype.   The pom.xml that we want  
the archtype to create needs to have certain versions pushed in,  
but other things in the pom should be left as is (or allow us to  
escape it).
The other thing we want to do is push some values INTO a resource  
that eventually is a velocity template.  (actually, that's what an  
archtype is anyway).   For those, we need the ability to not have  
some thing substituted in.


Ok, so it's archetype stuff. Well, the archetype resources
should be velocity templates anyway, and processed with velocity.
It should -not- use filtering, just pure velocity. Then you can use  
the velocity escaping mechanisms to leave certain expressions  
untouched.


So for the short run I think updating archetype itself is the safest..


Maybe just adding escaping to interpolationfilterreader is much
simpler than all of this, wdyt?
Probably yes, but would you consider that backwords compatible?
I have no problems with going that route if people don't think it  
would seriously impact people.


Depends on how we'll be escaping I guess..

-- Kenney


Dan

The other thing I'd like to do is conditional filtering based on
whether the version is a SNAPSHOT or not.   Kind of like:  
(pseudocode, not sure on the velocity syntax)


#if ${pom.version}.indexOf(SNAPSHOT) != -1
version.message=Version ${pom.version} - Use at your own risk.
#else
version.message=Version ${pom.version}
#fi

Why would you want that? :)

-- Kenney


2) The next option would be to add a filterType configuration
property onto the resources plugin itself.   You would need to
configure the plugin to use it.   Also, it would apply to all
resources with filtering=true.We could combine this with (1)
and instead of making simple the default if not specified in  
the

resource, whatever this option is set to is the default.
This is a better option. the plugin can be configured with  
resource

sets, which are just initialized from the pom itself.
perhaps 'src/main/velocity/' could be checked by default and
velocity-copied.

The problem is the Resource object that the resources plugin uses
is maven-model defined.   Not something that's extensible as that
requires a schema change.I suppose what COULD work well is to
add: velocityResources = ListResource
configuration to the resources plugin (and if list is empty, look
for the default of src/main/velocity) and use that.In that  
case,

regular resources can be configured just in build/resources and
build/testResources, but the velocity based ones would need a full
plugin configuration.   A bit inconsistent, but acceptable.


After thinking about this a bit more, I wonder if it makes more
sense to just create a maven-velocity-plugin and ignore resources
all-together? That would be super quick to write.(I'd still  
like
to see the escaping issue fixed.  :-) We already have the  
plexus

VelocityComponent.   Would take very little work to wire it into a
plugin.


Anyway, what are peoples thoughts on this?Any other options?
What direction do people feel is the best way to proceed? I
personally would like to go with Option #1 and require Maven  
2.0.8

if you want to use the advanced filtering, but I know some people
are totally against schema changes.

Well, if there's a good reason to change the schema then I'm all
for it. Maybe we should just add properties again to  
dependencies

and resource sets, so the resource plugin can look at the
resourceset property 'filterType' or something, if it's set.

Either way, changes to the model won't happen until 2.1.

So, what's the problem with the filtering?

Getting any of the normal pom properties outputted to the target
file seems to be impossible.
 
-

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

Re: Archiva now always writes to ~/.m2/archiva.xml

2007-07-10 Thread Brett Porter


Yeah, I had the same problem today trying to install it.

We need some integration tests on this functionality.

- Brett

On 10/07/2007, at 1:18 PM, Wendy Smoak wrote:


From http://maven.apache.org/archiva/guides/configuration.html :

When Archiva saves it's configuration, all configuration is stored to
a single file. The file chosen is by the following rules:

   * If ~/.m2/archiva.xml exists, it is saved there

   * Otherwise, it is saved to $ARCHIVA_BASE/conf/archiva.xml,
regardless of whether it previously existed. 

The latest code (r553963) always writes to ~/.m2/archiva.xml, even if
it did not exist, and completely ignores
$ARCHIVA_BASE/conf/archiva.xml.

Did something change?  I'm fairly sure I used to be able to customize
Archiva with conf/archiva.xml and keep everything out of my home
directory.

It's a bigger problem in a customized install of Archiva that has a
different list of config files.  In that situation, it picks up the
contents of the alternate config file, but always writes changes made
through the web UI to ~/.m2/archiva.xml.  When you re-start Archiva,
your changes are lost because they were not written to the correct
file.

I think it needs to work as described, and write to the conf directory
in the absence of a ~/.m2/archiva.xml file.

--
Wendy

Accessing command line properties

2007-07-10 Thread Kevin Jackson


Hi all,

I have a unit test which has to behave differently based on if the
test is being run normally or if the test is running within mvn with
the -o (offline switch) option.

With mvn 2.0.4, I could look at the environment variables being set
(QUOTED_ARGS for linux and MVN_CMD_LINE_ARGS for windows) to determine
if mvn was running in online or offline mode.

Now with 2.0.6  2.0.7, QUOTED_ARGS is no longer exported in the
mvn.sh script and therefore my unit test breaks.

I'd prefer to gain access directly to the command line arguments
instead of relying on the exported command line variables, but in
searching for a mvn api (javadoc etc) I've not really found anything
apart from some references to

org.codehaus.plexus.util.cli.Commandline; and other plexus code, again
this doesn't seem to have much in the way of documentation

Is there an elegant/cross-platform way of accessing the command line
options given to mvn within a unit test running under Surefire?

Thanks,
Kev

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

Re: [VOTE] release maven-plugin-testing-tools


+1


On Jul 6, 2007, at 11:27 PM, Brian E. Fox wrote:

The plugin testing tools had a bug that caused the real build  
artifacts

to become corrupted with the IT test version. This release is required
for the eclipse-plugin 2.4 release.

Issues fixed:
MNG-3095 : maven-plugin-testing-tools causes bad version in deployed
artifacts after tests are run
MECLIPSE-295 : Eclipse plugin fails due to missing
org.apache.maven.plugins:maven-eclipse-plugin:pom:test
MNG-3003 : maven-plugin-testing-tools: Updates for PLXUTILS-31 patches
And numerous other improvements without Jira issues

Staged at:
http://people.apache.org/~brianf/staging-repository

Tag:
https://svn.apache.org/repos/asf/maven/shared/tags/maven-plugin- 
testing-

tools-1.0-alpha-2

Please +1/+0/-1, vote is open for 72hrs.

+1
--Brian




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



---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john

Re: [VOTE] Promote and release maven-osgi shared library 0.1.0

2007-07-10 Thread Carlos Sanchez


Result
+1: 3

On 7/9/07, Arnaud HERITIER [EMAIL PROTECTED] wrote:

+1

Arnaud
On 09/07/07, Carlos Sanchez [EMAIL PROTECTED] wrote:
 fixed in the java classes, the pom missing license is due to the
 release plugin changes

 On 7/9/07, Vincent Siveton [EMAIL PROTECTED] wrote:
  +1
 
  Review license header (pom or Maven2OsgiConverter) before the release.
 
  Cheers,
 
  Vincent
 
  2007/7/9, Carlos Sanchez [EMAIL PROTECTED]:
   anyone else?
  
   On 7/6/07, Jason van Zyl [EMAIL PROTECTED] wrote:
+1
   
On 6 Jul 07, at 4:27 PM 6 Jul 07, Carlos Sanchez wrote:
   
 maven-osgi is a shared library for maven to osgi and viceversa common
 code, like version conversion. It's used by the felix bundle plugin
 and the eclipse plugin.

 https://svn.apache.org/repos/asf/maven/sandbox/trunk/shared/maven-osgi

 Tagged in https://svn.apache.org/repos/asf/maven/shared/tags/maven-
 osgi-0.1.0

 --
 I could give you my word as a Spaniard.
 No good. I've known too many Spaniards.
 -- The Princess Bride

 -
 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]
   
   
  
  
   --
   I could give you my word as a Spaniard.
   No good. I've known too many Spaniards.
-- The Princess Bride
  
   -
   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]
 
 


 --
 I could give you my word as a Spaniard.
 No good. I've known too many Spaniards.
  -- The Princess Bride

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




--
..
Arnaud HERITIER
..
OCTO Technology - [EMAIL PROTECTED]
www.octo.com | blog.octo.com
..
ASF - [EMAIL PROTECTED]
www.apache.org | maven.apache.org
...

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





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

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

Re: Resource filtering thoughts...

Yeah, escaping makes more sense to me, too. IMO it's a bit of a duct- 
tape solution to say this is only applicable in {archetype,  
appserver, other-limited-effect-plugins...} when those are the  
examples given... People can use filtering for just about anything,  
and they may use the '${...}' format for their own expression  
handling, which has nothing to do with Maven at all.


The question is: what escape sequence/character is safe to use?

-john


On Jul 10, 2007, at 9:17 AM, Andrew Williams wrote:

It's not just archetype - this has come up in appserver too, where  
you need some properties in a file escaped and others left.
I suspect adding escape handling to the InterpolationFilterReader  
might be a good way to go.


Andy

On 10 Jul 2007, at 11:35, Kenney Westerhof wrote:




Daniel Kulp wrote:

On Monday 09 July 2007 19:08, Kenney Westerhof wrote:

Daniel Kulp wrote:

On Monday 09 July 2007 14:42, Kenney Westerhof wrote:

Daniel Kulp wrote:
Yep.   That's the #1 issue.I've completely given up on  
trying to

get the string ${pom.version} outputted into the file.
Ok, but why are you filtering a file with that in there? Do you  
need

filtering at all, or do you only want some things filtered?

You can exclude specific files from filtering; doesn't that  
solve your

problem?
It has to do with creating an archtype.   The pom.xml that we  
want the archtype to create needs to have certain versions pushed  
in, but other things in the pom should be left as is (or allow us  
to escape it).
The other thing we want to do is push some values INTO a resource  
that eventually is a velocity template.  (actually, that's what  
an archtype is anyway).   For those, we need the ability to not  
have some thing substituted in.


Ok, so it's archetype stuff. Well, the archetype resources
should be velocity templates anyway, and processed with velocity.
It should -not- use filtering, just pure velocity. Then you can  
use the velocity escaping mechanisms to leave certain expressions  
untouched.


So for the short run I think updating archetype itself is the  
safest..



Maybe just adding escaping to interpolationfilterreader is much
simpler than all of this, wdyt?
Probably yes, but would you consider that backwords compatible?
I have no problems with going that route if people don't think it  
would seriously impact people.


Depends on how we'll be escaping I guess..

-- Kenney


Dan

The other thing I'd like to do is conditional filtering based on
whether the version is a SNAPSHOT or not.   Kind of like:  
(pseudocode, not sure on the velocity syntax)


#if ${pom.version}.indexOf(SNAPSHOT) != -1
version.message=Version ${pom.version} - Use at your own risk.
#else
version.message=Version ${pom.version}
#fi

Why would you want that? :)

-- Kenney


2) The next option would be to add a filterType configuration
property onto the resources plugin itself.   You would need to
configure the plugin to use it.   Also, it would apply to all
resources with filtering=true.We could combine this with (1)
and instead of making simple the default if not specified  
in the

resource, whatever this option is set to is the default.
This is a better option. the plugin can be configured with  
resource

sets, which are just initialized from the pom itself.
perhaps 'src/main/velocity/' could be checked by default and
velocity-copied.
The problem is the Resource object that the resources plugin  
uses

is maven-model defined.   Not something that's extensible as that
requires a schema change.I suppose what COULD work well is to
add: velocityResources = ListResource
configuration to the resources plugin (and if list is empty, look
for the default of src/main/velocity) and use that.In that  
case,

regular resources can be configured just in build/resources and
build/testResources, but the velocity based ones would need a full
plugin configuration.   A bit inconsistent, but acceptable.


After thinking about this a bit more, I wonder if it makes more
sense to just create a maven-velocity-plugin and ignore  
resources
all-together? That would be super quick to write.(I'd still  
like
to see the escaping issue fixed.  :-) We already have the  
plexus

VelocityComponent.   Would take very little work to wire it into a
plugin.


Anyway, what are peoples thoughts on this?Any other options?
What direction do people feel is the best way to proceed? I
personally would like to go with Option #1 and require Maven  
2.0.8
if you want to use the advanced filtering, but I know some  
people

are totally against schema changes.

Well, if there's a good reason to change the schema then I'm all
for it. Maybe we should just add properties again to  
dependencies

and resource sets, so the resource plugin can look at the
resourceset property 'filterType' or something, if it's set.

Either way, changes to the model won't happen until 2.1.

So, what's the problem with the filtering?

Getting any of the normal pom

Re: Resource filtering thoughts...

2007-07-10 Thread Daniel Kulp


Personally, I was thinking of just doing $$ - $.

Thus, if you want ${pom.version} outputted, it would be $${pom.version}.

I think @@ also needs to be done.

Dan



On Tuesday 10 July 2007 12:05, John Casey wrote:
 Yeah, escaping makes more sense to me, too. IMO it's a bit of a duct-
 tape solution to say this is only applicable in {archetype,
 appserver, other-limited-effect-plugins...} when those are the
 examples given... People can use filtering for just about anything,
 and they may use the '${...}' format for their own expression
 handling, which has nothing to do with Maven at all.

 The question is: what escape sequence/character is safe to use?

 -john

 On Jul 10, 2007, at 9:17 AM, Andrew Williams wrote:
  It's not just archetype - this has come up in appserver too, where
  you need some properties in a file escaped and others left.
  I suspect adding escape handling to the InterpolationFilterReader
  might be a good way to go.
 
  Andy
 
  On 10 Jul 2007, at 11:35, Kenney Westerhof wrote:
  Daniel Kulp wrote:
  On Monday 09 July 2007 19:08, Kenney Westerhof wrote:
  Daniel Kulp wrote:
  On Monday 09 July 2007 14:42, Kenney Westerhof wrote:
  Daniel Kulp wrote:
 
  Yep.   That's the #1 issue.I've completely given up on
  trying to
  get the string ${pom.version} outputted into the file.
 
  Ok, but why are you filtering a file with that in there? Do you
  need
  filtering at all, or do you only want some things filtered?
 
  You can exclude specific files from filtering; doesn't that
  solve your
  problem?
 
  It has to do with creating an archtype.   The pom.xml that we
  want the archtype to create needs to have certain versions pushed
  in, but other things in the pom should be left as is (or allow us
  to escape it).
  The other thing we want to do is push some values INTO a resource
  that eventually is a velocity template.  (actually, that's what
  an archtype is anyway).   For those, we need the ability to not
  have some thing substituted in.
 
  Ok, so it's archetype stuff. Well, the archetype resources
  should be velocity templates anyway, and processed with velocity.
  It should -not- use filtering, just pure velocity. Then you can
  use the velocity escaping mechanisms to leave certain expressions
  untouched.
 
  So for the short run I think updating archetype itself is the
  safest..
 
  Maybe just adding escaping to interpolationfilterreader is much
  simpler than all of this, wdyt?
 
  Probably yes, but would you consider that backwords compatible?
  I have no problems with going that route if people don't think it
  would seriously impact people.
 
  Depends on how we'll be escaping I guess..
 
  -- Kenney
 
  Dan
 
  The other thing I'd like to do is conditional filtering based on
  whether the version is a SNAPSHOT or not.   Kind of like:
  (pseudocode, not sure on the velocity syntax)
 
  #if ${pom.version}.indexOf(SNAPSHOT) != -1
  version.message=Version ${pom.version} - Use at your own risk.
  #else
  version.message=Version ${pom.version}
  #fi
 
  Why would you want that? :)
 
  -- Kenney
 
  2) The next option would be to add a filterType configuration
  property onto the resources plugin itself.   You would need to
  configure the plugin to use it.   Also, it would apply to all
  resources with filtering=true.We could combine this with
  (1) and instead of making simple the default if not
  specified in the
  resource, whatever this option is set to is the default.
 
  This is a better option. the plugin can be configured with
  resource
  sets, which are just initialized from the pom itself.
  perhaps 'src/main/velocity/' could be checked by default and
  velocity-copied.
 
  The problem is the Resource object that the resources plugin
  uses
  is maven-model defined.   Not something that's extensible as
  that requires a schema change.I suppose what COULD work well
  is to add: velocityResources = ListResource
  configuration to the resources plugin (and if list is empty,
  look for the default of src/main/velocity) and use that.In
  that case,
  regular resources can be configured just in build/resources
  and build/testResources, but the velocity based ones would need
  a full plugin configuration.   A bit inconsistent, but
  acceptable.
 
 
  After thinking about this a bit more, I wonder if it makes more
  sense to just create a maven-velocity-plugin and ignore
  resources
  all-together? That would be super quick to write.(I'd still
  like
  to see the escaping issue fixed.  :-) We already have the
  plexus
  VelocityComponent.   Would take very little work to wire it into
  a plugin.
 
  Anyway, what are peoples thoughts on this?Any other
  options? What direction do people feel is the best way to
  proceed? I personally would like to go with Option #1 and
  require Maven 2.0.8
  if you want to use the advanced filtering, but I know some
  people
  are totally against schema changes.
 
  Well, if there's a good reason to

Re: [VOTE] Configure IDE plugins to download sources by default within Maven projects




Brian E. Fox wrote:

So I propose:



- if -DdownloadSources is specified, download sources and fallback to javadoc, 
just as it is now
- if -DdownloadJavaDoc is specified, download javadoc (possibly fallback to 
sources)
- if both are specified, download both.



And:



- don't make this a default; the default behaviour of attaching
 either source or javadoc when it's present in the local repo
 is fine though, but turning this on by default is just too slow.


This is already done in Eclipse 2.4 although it doesn't fallback to the javadoc.


Cool though the fallback has been there a long time ago, and still was until a 
few days ago
(just svn upped and it was gone; a few days ago this still was present...).

Guess the fallback isn't really required so it's fine like this imho.



http://jira.codehaus.org/browse/MECLIPSE-292

--Brian



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

Re: [VOTE] release eclipse 2.4 (take 2)


+1

-john

On Jul 7, 2007, at 11:09 PM, Brian E. Fox wrote:


It's been about 5 months since an eclipse plugin release and we have
lots of fixes and a handful of enhancements. The issues detected in  
the

last vote (MECLIPSE-295) have been fixed in the currently staged
plugin-testing-tools 1.0-alpha-2. As such, this release is  
dependent on

the successful release of the updated tools.

The site has been updated:
http://maven.apache.org/plugins/maven-eclipse-plugin

The plugin is staged at:
http://people.apache.org/~brianf/staging-repository

The tag is at:
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-eclipse- 
plugin-

2.4/

Release Notes - Maven 2.x Eclipse Plugin - Version 2.4:
http://jira.codehaus.org/secure/ReleaseNote.jspa? 
version=13001styleName

=HtmlprojectId=11133Create=Create

** Bug
* [MECLIPSE-108] - .wtpmodules with version 2.4 for
javax.servlet:servlet-api:2.3
* [MECLIPSE-109] - .component wb-resource source path incorrect  
for

ear packaging
* [MECLIPSE-151] - Incorrect name for test sources jars
* [MECLIPSE-198] - EJB version is not resloved
* [MECLIPSE-215] - WTP 1.5 Documentation
* [MECLIPSE-220] - Incorrect eclipse facet information when doing
mvn eclipse:eclipse for war and ejb projects.
* [MECLIPSE-225] - Invalid .classpath Entries.
* [MECLIPSE-231] - Clean mojo assumes that POM projects never have
.project files - this is incorrect
* [MECLIPSE-233] - Manifest attributes incorrectly treated as
case-sensitive
* [MECLIPSE-234] - [PATCH] EclipsePlugin.extractResourceDirs()
reuses String method argument causing maven-eclipse.xml copy-resources
problems
* [MECLIPSE-236] - eclipse:make-artifacts should preserve the
resolution:=optional directive
* [MECLIPSE-237] - unsafe EclipseSourceDir.equals() method
* [MECLIPSE-239] - eclipse:eclipse fails to find dependency
org.apache.maven.plugins:maven-eclipse-plugin:pom:test
* [MECLIPSE-241] - Compiler settings in pluginManagement aren't  
used

in wtp facet
* [MECLIPSE-243] - The last 2.4 SNAPSHOT forbid Apache Directory
Server to be built
* [MECLIPSE-248] - Tests fail due to incorrectly attempting to use
released plugin version, not locally sandboxed one under test,
* [MECLIPSE-255] - WTP Settings does not use servlet-api version
defined in pom.xml
* [MECLIPSE-263] - Project Facet 'Java' set to 1.4 instead of  
5.0 in

a Java 5.0 project
* [MECLIPSE-278] - duplicated classpathentries
* [MECLIPSE-279] - PDE projects should be considered java projects
in all cases
* [MECLIPSE-287] - Regression - fails to correctly construct
classpath containing dependencies with classifiers
* [MECLIPSE-295] - Eclipse plugin fails due to missing
org.apache.maven.plugins:maven-eclipse-plugin:pom:test

** Improvement
* [MECLIPSE-40] - Multi project dependencies should not require
eclipse project names to be the artifactId
* [MECLIPSE-207] - Add supprt for arbitrary facets, like JSF
* [MECLIPSE-267] - Resolve version ranges in make-artifacts
* [MECLIPSE-268] - [eclipse:rad goal] Make customization of  
servlet

version, jsp version, ... possible through pom configuration
* [MECLIPSE-286] - Ability to skip generated-resources/rad6 folder
creation while executing eclipse:rad
* [MECLIPSE-292] - Behaviour for sources and Javadoc  
attachement for

dependencies should be consistent

** New Feature
* [MECLIPSE-65] - Add contextName parameter to eclipse mojo so a
webtool context name doesn't have to match artifactId/project name.
* [MECLIPSE-119] - Allow custom project name for eclipse projects
* [MECLIPSE-189] - addVersionToProjectName property
* [MECLIPSE-251] - Allows prefixing of eclipse project name
* [MECLIPSE-271] - Ability to skip



Vote is open for 72hrs, please +1/+0/-1


+1


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



---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john

Re: Resource filtering thoughts...




Daniel Kulp wrote:

Personally, I was thinking of just doing $$ - $.


Yah, that's already in place for plugin parameters.



Thus, if you want ${pom.version} outputted, it would be $${pom.version}.

I think @@ also needs to be done.


Yup.

My original idea was to use both by default but allow them to be configurable,
so you could use @foo@ for filtering and leave ${foo} alone or vice versa.
Doesn't cover the case where you want both @foo@ and ${foo} to be left
alone, but @bar@ and ${bar} interpolated, though.

So:

 $${foo} - ${foo}
 ${foo} - value_of_foo

 @@ - @@ (or @?)
 @@foo@ - @foo@  (or @@foo@@ - @foo@ ?)
 @foo@  - value_of_foo
 @foo@@ - value_of_foo@, or @foo@, or @foo@@ ?

Maybe it's better if we leave the @foo@ interpretation as-is. ;)

-- Kenney



Dan



On Tuesday 10 July 2007 12:05, John Casey wrote:

Yeah, escaping makes more sense to me, too. IMO it's a bit of a duct-
tape solution to say this is only applicable in {archetype,
appserver, other-limited-effect-plugins...} when those are the
examples given... People can use filtering for just about anything,
and they may use the '${...}' format for their own expression
handling, which has nothing to do with Maven at all.

The question is: what escape sequence/character is safe to use?

-john

On Jul 10, 2007, at 9:17 AM, Andrew Williams wrote:

It's not just archetype - this has come up in appserver too, where
you need some properties in a file escaped and others left.
I suspect adding escape handling to the InterpolationFilterReader
might be a good way to go.

Andy

On 10 Jul 2007, at 11:35, Kenney Westerhof wrote:

Daniel Kulp wrote:

On Monday 09 July 2007 19:08, Kenney Westerhof wrote:

Daniel Kulp wrote:

On Monday 09 July 2007 14:42, Kenney Westerhof wrote:

Daniel Kulp wrote:

Yep.   That's the #1 issue.I've completely given up on
trying to
get the string ${pom.version} outputted into the file.

Ok, but why are you filtering a file with that in there? Do you
need
filtering at all, or do you only want some things filtered?

You can exclude specific files from filtering; doesn't that
solve your
problem?

It has to do with creating an archtype.   The pom.xml that we
want the archtype to create needs to have certain versions pushed
in, but other things in the pom should be left as is (or allow us
to escape it).
The other thing we want to do is push some values INTO a resource
that eventually is a velocity template.  (actually, that's what
an archtype is anyway).   For those, we need the ability to not
have some thing substituted in.

Ok, so it's archetype stuff. Well, the archetype resources
should be velocity templates anyway, and processed with velocity.
It should -not- use filtering, just pure velocity. Then you can
use the velocity escaping mechanisms to leave certain expressions
untouched.

So for the short run I think updating archetype itself is the
safest..


Maybe just adding escaping to interpolationfilterreader is much
simpler than all of this, wdyt?

Probably yes, but would you consider that backwords compatible?
I have no problems with going that route if people don't think it
would seriously impact people.

Depends on how we'll be escaping I guess..

-- Kenney


Dan


The other thing I'd like to do is conditional filtering based on
whether the version is a SNAPSHOT or not.   Kind of like:
(pseudocode, not sure on the velocity syntax)

#if ${pom.version}.indexOf(SNAPSHOT) != -1
version.message=Version ${pom.version} - Use at your own risk.
#else
version.message=Version ${pom.version}
#fi

Why would you want that? :)

-- Kenney


2) The next option would be to add a filterType configuration
property onto the resources plugin itself.   You would need to
configure the plugin to use it.   Also, it would apply to all
resources with filtering=true.We could combine this with
(1) and instead of making simple the default if not
specified in the
resource, whatever this option is set to is the default.

This is a better option. the plugin can be configured with
resource
sets, which are just initialized from the pom itself.
perhaps 'src/main/velocity/' could be checked by default and
velocity-copied.

The problem is the Resource object that the resources plugin
uses
is maven-model defined.   Not something that's extensible as
that requires a schema change.I suppose what COULD work well
is to add: velocityResources = ListResource
configuration to the resources plugin (and if list is empty,
look for the default of src/main/velocity) and use that.In
that case,
regular resources can be configured just in build/resources
and build/testResources, but the velocity based ones would need
a full plugin configuration.   A bit inconsistent, but
acceptable.


After thinking about this a bit more, I wonder if it makes more
sense to just create a maven-velocity-plugin and ignore
resources
all-together? That would be super quick to write.(I'd still
like
to see the escaping issue fixed.  :-) We already have the
plexus

Re: Version ranges and snapshots




Patrick Schneider wrote:

For now, I'm a fan of disallowing snapshots when they are not explicitly in
the boundary, as per the patch.

In my mind, the problem with a profile flag is that it's an all-or-nothing
proposition.  Any released artifacts with version ranges will also start to
pull in snapshots.  There wouldn't be enough control, IMO.



You can always exclude snapshots explicitly:

[1.0,1.1-SNAPSHOT),(1.1-SNAPSHOT,1.1]

Snapshots are valid versions in a range [1.0, 1.1], or even [1.0, 1.1).

Personally I'm +1 for updating the docs, and let the presence of snapshot repo's
and valid snapshot artifacts there determine wheter snapshots are used or not.

-- Kenney




Patrick

On 7/6/07, Mark Hobson [EMAIL PROTECTED] wrote:


Hi,

Whilst attempting to fix MNG-2994, I discovered MNG-3092 that was
contrary to the 2.0 design docs:

http://jira.codehaus.org/browse/MNG-3092

Brett, Kenney and myself had a brief discussion on IRC about this:
Kenney says that the behaviour is theoretically correct (which it is),
although I feel it goes against the practical usage described in the
docs.  The two main choices I can see are:

1) We stick to the design docs and disallow snapshots in ranges when
they aren't an explicit boundary, as per the MNG-3092 patch.

2) We reconsider the design docs and leave range resolution behaving
as it is, then use profiles to enable or disable snapshot repositories
at build time.

Any thoughts?

Mark

-
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: Version ranges and snapshots

2007-07-10 Thread Max Bowsher

Kenney Westerhof wrote:
 
 
 Patrick Schneider wrote:
 For now, I'm a fan of disallowing snapshots when they are not
 explicitly in
 the boundary, as per the patch.

 In my mind, the problem with a profile flag is that it's an
 all-or-nothing
 proposition.  Any released artifacts with version ranges will also
 start to
 pull in snapshots.  There wouldn't be enough control, IMO.

 
 You can always exclude snapshots explicitly:
 
 [1.0,1.1-SNAPSHOT),(1.1-SNAPSHOT,1.1]
 
 Snapshots are valid versions in a range [1.0, 1.1], or even [1.0, 1.1).
 
 Personally I'm +1 for updating the docs, and let the presence of
 snapshot repo's
 and valid snapshot artifacts there determine wheter snapshots are used
 or not.

Not only is the syntax above very cumbersome, but what about the
possibility of 1.0.1-SNAPSHOT, etc?

Controlling this through snapshot repo presence/absence would be rather
suboptimal, because you couldn't pull in a snapshot for one particular
artifact without possibly getting unwanted snapshots for other
dependency artifacts published in the same repo.

Max.





signature.asc
Description: OpenPGP digital signature

Re: Resource filtering thoughts...

I've seen several unix commands that allow configurable  
delimiters...maybe that would be a better option?


-john


On Jul 10, 2007, at 12:55 PM, Kenney Westerhof wrote:




Daniel Kulp wrote:

Personally, I was thinking of just doing $$ - $.


Yah, that's already in place for plugin parameters.

Thus, if you want ${pom.version} outputted, it would be $$ 
{pom.version}.

I think @@ also needs to be done.


Yup.

My original idea was to use both by default but allow them to be  
configurable,
so you could use @foo@ for filtering and leave ${foo} alone or vice  
versa.

Doesn't cover the case where you want both @foo@ and ${foo} to be left
alone, but @bar@ and ${bar} interpolated, though.

So:

 $${foo} - ${foo}
 ${foo} - value_of_foo

 @@ - @@ (or @?)
 @@foo@ - @foo@  (or @@foo@@ - @foo@ ?)
 @foo@  - value_of_foo
 @foo@@ - value_of_foo@, or @foo@, or @foo@@ ?

Maybe it's better if we leave the @foo@ interpretation as-is. ;)

-- Kenney


Dan
On Tuesday 10 July 2007 12:05, John Casey wrote:
Yeah, escaping makes more sense to me, too. IMO it's a bit of a  
duct-

tape solution to say this is only applicable in {archetype,
appserver, other-limited-effect-plugins...} when those are the
examples given... People can use filtering for just about anything,
and they may use the '${...}' format for their own expression
handling, which has nothing to do with Maven at all.

The question is: what escape sequence/character is safe to use?

-john

On Jul 10, 2007, at 9:17 AM, Andrew Williams wrote:

It's not just archetype - this has come up in appserver too, where
you need some properties in a file escaped and others left.
I suspect adding escape handling to the InterpolationFilterReader
might be a good way to go.

Andy

On 10 Jul 2007, at 11:35, Kenney Westerhof wrote:

Daniel Kulp wrote:

On Monday 09 July 2007 19:08, Kenney Westerhof wrote:

Daniel Kulp wrote:

On Monday 09 July 2007 14:42, Kenney Westerhof wrote:

Daniel Kulp wrote:

Yep.   That's the #1 issue.I've completely given up on
trying to
get the string ${pom.version} outputted into the file.

Ok, but why are you filtering a file with that in there? Do you
need
filtering at all, or do you only want some things filtered?

You can exclude specific files from filtering; doesn't that
solve your
problem?

It has to do with creating an archtype.   The pom.xml that we
want the archtype to create needs to have certain versions pushed
in, but other things in the pom should be left as is (or allow us
to escape it).
The other thing we want to do is push some values INTO a resource
that eventually is a velocity template.  (actually, that's what
an archtype is anyway).   For those, we need the ability to not
have some thing substituted in.

Ok, so it's archetype stuff. Well, the archetype resources
should be velocity templates anyway, and processed with velocity.
It should -not- use filtering, just pure velocity. Then you can
use the velocity escaping mechanisms to leave certain expressions
untouched.

So for the short run I think updating archetype itself is the
safest..


Maybe just adding escaping to interpolationfilterreader is much
simpler than all of this, wdyt?

Probably yes, but would you consider that backwords compatible?
I have no problems with going that route if people don't think it
would seriously impact people.

Depends on how we'll be escaping I guess..

-- Kenney


Dan

The other thing I'd like to do is conditional filtering  
based on

whether the version is a SNAPSHOT or not.   Kind of like:
(pseudocode, not sure on the velocity syntax)

#if ${pom.version}.indexOf(SNAPSHOT) != -1
version.message=Version ${pom.version} - Use at your own risk.
#else
version.message=Version ${pom.version}
#fi

Why would you want that? :)

-- Kenney


2) The next option would be to add a filterType configuration
property onto the resources plugin itself.   You would  
need to

configure the plugin to use it.   Also, it would apply to all
resources with filtering=true.We could combine this with
(1) and instead of making simple the default if not
specified in the
resource, whatever this option is set to is the default.

This is a better option. the plugin can be configured with
resource
sets, which are just initialized from the pom itself.
perhaps 'src/main/velocity/' could be checked by default and
velocity-copied.

The problem is the Resource object that the resources plugin
uses
is maven-model defined.   Not something that's extensible as
that requires a schema change.I suppose what COULD work  
well

is to add: velocityResources = ListResource
configuration to the resources plugin (and if list is empty,
look for the default of src/main/velocity) and use that.In
that case,
regular resources can be configured just in build/resources
and build/testResources, but the velocity based ones would need
a full plugin configuration.   A bit inconsistent, but
acceptable.


After thinking about this a bit more, I wonder if it makes more
sense to just create a

Re: Version ranges and snapshots

Max Bowsher wrote:

Kenney Westerhof wrote:

Patrick Schneider wrote:

For now, I'm a fan of disallowing snapshots when they are not
explicitly in
the boundary, as per the patch.

In my mind, the problem with a profile flag is that it's an
all-or-nothing
proposition. Any released artifacts with version ranges will also
start to
pull in snapshots. There wouldn't be enough control, IMO.

You can always exclude snapshots explicitly:

[1.0,1.1-SNAPSHOT),(1.1-SNAPSHOT,1.1]

Snapshots are valid versions in a range [1.0, 1.1], or even [1.0, 1.1).

Personally I'm +1 for updating the docs, and let the presence of
snapshot repo's
and valid snapshot artifacts there determine wheter snapshots are used
or not.

Not only is the syntax above very cumbersome, but what about the
possibility of 1.0.1-SNAPSHOT, etc?

Ah. Yes indeed. That'll be really cumbersome.

Controlling this through snapshot repo presence/absence would be rather
suboptimal, because you couldn't pull in a snapshot for one particular
artifact without possibly getting unwanted snapshots for other
dependency artifacts published in the same repo.

True, though the proposed change will only affect version ranges, not versions.

I think snapshots are a different aspect, outside of version ranges. Version
ranges are meant to specify a range of versions. Snapshots fit perfectly
in a version range.

So you want to prevent accidental use of snapshots when released versions
are available in the given range.

Having a mechanism in place to explicitly state what dependencies can be
resolved
to snapshot versions, and what dependencies cannot is certainly useful

So what we're dealing here is a way to do that. This has nothing to do with
version
ranges but with being able to say that you don't want snapshots for a certain
artifact. Specifying a normal version (without SNAPSHOT) is not going to be resolved to a snapshot,
unless there's another declaration that does mention it, and with version ranges that could happen.
The current resolution mechanism uses the first match, so it's pretty random
(the order of the searched repositories is important here).

If someone specifies a version range, he doesn't care about the version except
that it must
be in that range because he knows those versions work. SNAPSHOTs that fall into
that range
are compatible, so why can't they be used?
What about other dependencies that _are_ declared as a snapshot and bring in a
SNAPSHOT version
also declared somewhere else with a SNAPSHOT-excluding range? Should the build
fail then?

Most importantly, making this change prevents snapshots from being used in
version ranges.
Sure, you can explicitly mention them in the range, but you'd have the same
problem
as the other way around: specifying 1.0.1-SNAPSHOT, 1.0.2-SNAPSHOT etc..

It seems we want more fine grained control on this matter.
We could change the order of resolution to first check for non-snapshots,
then for snapshots, so a non-snapshot will be used when it's possible. That
would solve the problem,
except for people who want to use snapshots.
Another solution would be to somehow mark wheter a dependency or version range
should
include or exclude snapshots, or add information to repositories specifying the
groupid/artifactids
they provide or must not provide. That way you can declare the same repo twice,
once with snapshots enabled
and once without, listing the dependencies.

Not sure if this is worth the trouble though..

Anyway, we could just 'assume' that when people specify version ranges they
don't want
snapshots and apply this change. I'm just worried about the side effects, since
A (using snapshots
in ranges) is possible now and B (excluding snapshots in ranges) is cumbersome,
but when we apply this, B is possible but A is even more cumbersome.

Ow, just thought of something - have 'processing instructions' or similar in
the version ranges,
like [1.0,2.0){snapshots=off} (or just use xml attributes ofcourse ;))

-- Kenney

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

Re: Resource filtering thoughts...


Yeah that would settle this once and for all ;)

Except you probably have to be able to specify the delimiters per
resource set sigh.

John Casey wrote:
I've seen several unix commands that allow configurable 
delimiters...maybe that would be a better option?


-john


On Jul 10, 2007, at 12:55 PM, Kenney Westerhof wrote:




Daniel Kulp wrote:

Personally, I was thinking of just doing $$ - $.


Yah, that's already in place for plugin parameters.


Thus, if you want ${pom.version} outputted, it would be $${pom.version}.
I think @@ also needs to be done.


Yup.

My original idea was to use both by default but allow them to be 
configurable,
so you could use @foo@ for filtering and leave ${foo} alone or vice 
versa.

Doesn't cover the case where you want both @foo@ and ${foo} to be left
alone, but @bar@ and ${bar} interpolated, though.

So:

 $${foo} - ${foo}
 ${foo} - value_of_foo

 @@ - @@ (or @?)
 @@foo@ - @foo@  (or @@foo@@ - @foo@ ?)
 @foo@  - value_of_foo
 @foo@@ - value_of_foo@, or @foo@, or @foo@@ ?

Maybe it's better if we leave the @foo@ interpretation as-is. ;)

-- Kenney


Dan
On Tuesday 10 July 2007 12:05, John Casey wrote:

Yeah, escaping makes more sense to me, too. IMO it's a bit of a duct-
tape solution to say this is only applicable in {archetype,
appserver, other-limited-effect-plugins...} when those are the
examples given... People can use filtering for just about anything,
and they may use the '${...}' format for their own expression
handling, which has nothing to do with Maven at all.

The question is: what escape sequence/character is safe to use?

-john

On Jul 10, 2007, at 9:17 AM, Andrew Williams wrote:

It's not just archetype - this has come up in appserver too, where
you need some properties in a file escaped and others left.
I suspect adding escape handling to the InterpolationFilterReader
might be a good way to go.

Andy

On 10 Jul 2007, at 11:35, Kenney Westerhof wrote:

Daniel Kulp wrote:

On Monday 09 July 2007 19:08, Kenney Westerhof wrote:

Daniel Kulp wrote:

On Monday 09 July 2007 14:42, Kenney Westerhof wrote:

Daniel Kulp wrote:

Yep.   That's the #1 issue.I've completely given up on
trying to
get the string ${pom.version} outputted into the file.

Ok, but why are you filtering a file with that in there? Do you
need
filtering at all, or do you only want some things filtered?

You can exclude specific files from filtering; doesn't that
solve your
problem?

It has to do with creating an archtype.   The pom.xml that we
want the archtype to create needs to have certain versions pushed
in, but other things in the pom should be left as is (or allow us
to escape it).
The other thing we want to do is push some values INTO a resource
that eventually is a velocity template.  (actually, that's what
an archtype is anyway).   For those, we need the ability to not
have some thing substituted in.

Ok, so it's archetype stuff. Well, the archetype resources
should be velocity templates anyway, and processed with velocity.
It should -not- use filtering, just pure velocity. Then you can
use the velocity escaping mechanisms to leave certain expressions
untouched.

So for the short run I think updating archetype itself is the
safest..


Maybe just adding escaping to interpolationfilterreader is much
simpler than all of this, wdyt?

Probably yes, but would you consider that backwords compatible?
I have no problems with going that route if people don't think it
would seriously impact people.

Depends on how we'll be escaping I guess..

-- Kenney


Dan


The other thing I'd like to do is conditional filtering based on
whether the version is a SNAPSHOT or not.   Kind of like:
(pseudocode, not sure on the velocity syntax)

#if ${pom.version}.indexOf(SNAPSHOT) != -1
version.message=Version ${pom.version} - Use at your own risk.
#else
version.message=Version ${pom.version}
#fi

Why would you want that? :)

-- Kenney


2) The next option would be to add a filterType configuration
property onto the resources plugin itself.   You would need to
configure the plugin to use it.   Also, it would apply to all
resources with filtering=true.We could combine this with
(1) and instead of making simple the default if not
specified in the
resource, whatever this option is set to is the default.

This is a better option. the plugin can be configured with
resource
sets, which are just initialized from the pom itself.
perhaps 'src/main/velocity/' could be checked by default and
velocity-copied.

The problem is the Resource object that the resources plugin
uses
is maven-model defined.   Not something that's extensible as
that requires a schema change.I suppose what COULD work well
is to add: velocityResources = ListResource
configuration to the resources plugin (and if list is empty,
look for the default of src/main/velocity) and use that.In
that case,
regular resources can be configured just in build/resources
and build/testResources, but the velocity based ones would need
a full plugin

Continuum and minimum JDK requirement

2007-07-10 Thread Joerg Heinicke

Hello guys,

we had an issue recently with Continuum on Cocoon and continuous integration
which fails to check JDK 1.4 compliance of Cocoon's code base since Continuum
itself is running with a JDK 5 (in that particular case it was usage of
ThreadLocal.remove() [1]). I found the thread about raising the minimum JDK for
Continuum where exactly such issues where foreseen [2]. Brett talked about the
possibility to fork builds with Continuum [3]. Is that how Maven assures 1.4
compatibility running its Continuum? Or how do you assure it? Putting it to the
extremes there might even be a JDK 1.4 project using enum keyword which should
be build with Continuum. If the latter requires JDK 5 is it possible though to
build that project?

Thanks for any hint,

Joerg

[1] http://marc.info/?l=xml-cocoon-devm=118115701130207w=4
[2] http://marc.info/?t=11522363541r=1w=4, in particular Steven's mail
http://marc.info/?l=turbine-maven-devm=115227611406486w=4
[3] http://marc.info/?l=turbine-maven-devm=115518652524872w=4


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

Re: Continuum and minimum JDK requirement

2007-07-10 Thread Brett Porter


On 11/07/2007, at 10:32 AM, Joerg Heinicke wrote:


Hello guys,

we had an issue recently with Continuum on Cocoon and continuous  
integration
which fails to check JDK 1.4 compliance of Cocoon's code base since  
Continuum
itself is running with a JDK 5 (in that particular case it was  
usage of
ThreadLocal.remove() [1]). I found the thread about raising the  
minimum JDK for

Continuum where exactly such issues where foreseen [2].


The binding problem is a relatively small number of cases that can  
probably be avoided in your code. Accidentally using JDK 5 methods is  
something that comes up frequently and you should certainly regularly  
build on 1.4 to check.



Brett talked about the
possibility to fork builds with Continuum [3].


Continuum always forks builds. However, controlling the JDK it used  
was not easy. I do believe profiles support will be in the next  
release and will make it easy.



Putting it to the
extremes there might even be a JDK 1.4 project using enum keyword  
which should
be build with Continuum. If the latter requires JDK 5 is it  
possible though to

build that project?


Setting the correct -source will take care of that.

- Brett

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

RE: [VOTE] release maven-plugin-testing-tools

Results:
Binding: +5 (Brian, John, Carlos, Fabrizio, Arnaud)
Non-Binding: +1 Mark

I will proceed with the release. 
Thanks,
Brian

-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED] 
Sent: Friday, July 06, 2007 11:28 PM
To: Maven Developers List
Subject: [VOTE] release maven-plugin-testing-tools

The plugin testing tools had a bug that caused the real build artifacts
to become corrupted with the IT test version. This release is required
for the eclipse-plugin 2.4 release.

Issues fixed:
MNG-3095 : maven-plugin-testing-tools causes bad version in deployed
artifacts after tests are run
MECLIPSE-295 : Eclipse plugin fails due to missing
org.apache.maven.plugins:maven-eclipse-plugin:pom:test
MNG-3003 : maven-plugin-testing-tools: Updates for PLXUTILS-31 patches
And numerous other improvements without Jira issues

Staged at:
http://people.apache.org/~brianf/staging-repository

Tag:
https://svn.apache.org/repos/asf/maven/shared/tags/maven-plugin-testing-
tools-1.0-alpha-2

Please +1/+0/-1, vote is open for 72hrs.

+1
--Brian




-
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: [VOTE] release eclipse 2.4 (take 2)

Results:
Binding: +5 (Brian, John, Carlos, Fabrizio, Arnaud)
Non-Binding: +0 Mark, +1 Denis C.

I will proceed with the release. 
Thanks,
Brian

-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED] 
Sent: Saturday, July 07, 2007 11:09 PM
To: Maven Developers List
Subject: [VOTE] release eclipse 2.4 (take 2)

It's been about 5 months since an eclipse plugin release and we have
lots of fixes and a handful of enhancements. The issues detected in the
last vote (MECLIPSE-295) have been fixed in the currently staged
plugin-testing-tools 1.0-alpha-2. As such, this release is dependent on
the successful release of the updated tools. 

The site has been updated: 
http://maven.apache.org/plugins/maven-eclipse-plugin

The plugin is staged at:
http://people.apache.org/~brianf/staging-repository

The tag is at:
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-eclipse-plugin-
2.4/

Release Notes - Maven 2.x Eclipse Plugin - Version 2.4:
http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13001styleName
=HtmlprojectId=11133Create=Create

** Bug
* [MECLIPSE-108] - .wtpmodules with version 2.4 for
javax.servlet:servlet-api:2.3
* [MECLIPSE-109] - .component wb-resource source path incorrect for
ear packaging
* [MECLIPSE-151] - Incorrect name for test sources jars
* [MECLIPSE-198] - EJB version is not resloved
* [MECLIPSE-215] - WTP 1.5 Documentation
* [MECLIPSE-220] - Incorrect eclipse facet information when doing
mvn eclipse:eclipse for war and ejb projects.
* [MECLIPSE-225] - Invalid .classpath Entries.
* [MECLIPSE-231] - Clean mojo assumes that POM projects never have
.project files - this is incorrect
* [MECLIPSE-233] - Manifest attributes incorrectly treated as
case-sensitive
* [MECLIPSE-234] - [PATCH] EclipsePlugin.extractResourceDirs()
reuses String method argument causing maven-eclipse.xml copy-resources
problems
* [MECLIPSE-236] - eclipse:make-artifacts should preserve the
resolution:=optional directive
* [MECLIPSE-237] - unsafe EclipseSourceDir.equals() method
* [MECLIPSE-239] - eclipse:eclipse fails to find dependency
org.apache.maven.plugins:maven-eclipse-plugin:pom:test
* [MECLIPSE-241] - Compiler settings in pluginManagement aren't used
in wtp facet
* [MECLIPSE-243] - The last 2.4 SNAPSHOT forbid Apache Directory
Server to be built
* [MECLIPSE-248] - Tests fail due to incorrectly attempting to use
released plugin version, not locally sandboxed one under test, 
* [MECLIPSE-255] - WTP Settings does not use servlet-api version
defined in pom.xml
* [MECLIPSE-263] - Project Facet 'Java' set to 1.4 instead of 5.0 in
a Java 5.0 project
* [MECLIPSE-278] - duplicated classpathentries
* [MECLIPSE-279] - PDE projects should be considered java projects
in all cases
* [MECLIPSE-287] - Regression - fails to correctly construct
classpath containing dependencies with classifiers
* [MECLIPSE-295] - Eclipse plugin fails due to missing
org.apache.maven.plugins:maven-eclipse-plugin:pom:test

** Improvement
* [MECLIPSE-40] - Multi project dependencies should not require
eclipse project names to be the artifactId
* [MECLIPSE-207] - Add supprt for arbitrary facets, like JSF
* [MECLIPSE-267] - Resolve version ranges in make-artifacts
* [MECLIPSE-268] - [eclipse:rad goal] Make customization of servlet
version, jsp version, ... possible through pom configuration
* [MECLIPSE-286] - Ability to skip generated-resources/rad6 folder
creation while executing eclipse:rad
* [MECLIPSE-292] - Behaviour for sources and Javadoc attachement for
dependencies should be consistent

** New Feature
* [MECLIPSE-65] - Add contextName parameter to eclipse mojo so a
webtool context name doesn't have to match artifactId/project name.
* [MECLIPSE-119] - Allow custom project name for eclipse projects
* [MECLIPSE-189] - addVersionToProjectName property
* [MECLIPSE-251] - Allows prefixing of eclipse project name
* [MECLIPSE-271] - Ability to skip



Vote is open for 72hrs, please +1/+0/-1


+1


-
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: [VOTE] release maven-plugin-testing-harness 1.1

Results:
Binding +4 (Brian, Arnaud,Vincent, S. Jason)
Non-Binding +1 Andy

I'll proceed with the release.
Thanks,
Brian

-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED] 
Sent: Sunday, July 08, 2007 7:38 PM
To: Maven Developers List
Subject: [VOTE] release maven-plugin-testing-harness 1.1

There have been tons of enhancements to the plugin testing harness since
the last release in April. Several plugins require the new version
before release.

 

Tag:

https://svn.apache.org/repos/asf/maven/shared/tags/maven-plugin-testing-
harness-1.1

 

Staged at:

http://people.apache.org/~brianf/staging-repository

 

Vote is open for 72hrs, please +1/+0/-1

 

+1

 

Thanks,

Brian


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

RE: [Vote] release maven-enforcer-plugin 1.0-alpha-3 and maven-enforcer-rule-api 1.0-alpha-2