from:"michal"

adding dependency to subproject's pom.xml
-

 Key: MNGECLIPSE-11
 URL: http://jira.codehaus.org/browse/MNGECLIPSE-11
 Project: Maven 2.x Plug-in for Eclipse
Type: Improvement

Reporter: Michal Stochmialek
 Assigned to: Eugene Kuleshov 


I have maven multiproject  in a single eclipse project. 

Maven plugin correctly searches dependencies in all subprojects and adds them 
to eclipse .classpath. The same is for updating source folders.

Unfortunately, adding dependecies (with add dependency option) works only for 
main pom.xml.

I would like to choose to which subproject plugin should add chosen dependency. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (MNGECLIPSE-12) searching for dependencies should use mirrors from settings.xml

searching for dependencies should use mirrors from settings.xml
---

 Key: MNGECLIPSE-12
 URL: http://jira.codehaus.org/browse/MNGECLIPSE-12
 Project: Maven 2.x Plug-in for Eclipse
Type: Improvement

 Environment: eclipse 3.1, maven plugin 0.0.3
Reporter: Michal Stochmialek
 Assigned to: Eugene Kuleshov 


I'm using internal repository in company intranet as a mirror of central 
repository, but when searching for dependencies any of additional artifacts 
stored in out internal repository (and not in central) aren't shown. I suspect 
that maven plugin uses ibiblio for searching dependencies and ignores my mirror 
settings.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (MNGECLIPSE-13) adding dependency to pom.xml changes its formating

adding dependency to pom.xml changes its formating
--

 Key: MNGECLIPSE-13
 URL: http://jira.codehaus.org/browse/MNGECLIPSE-13
 Project: Maven 2.x Plug-in for Eclipse
Type: Bug

 Environment: win xp, eclipse 3.1, plugin 0.0.3
Reporter: Michal Stochmialek
 Assigned to: Eugene Kuleshov 
Priority: Minor


I use pom.xml as a human-readable file, so I insert empty lines between main 
sections of pom etc. But after adding a depedency using maven plugin, those 
blank lines have disappeared. 

The similar thing happened to indentions. I usually use tabs for indenting, but 
plugin changed whole file indenting to spaces. In result CVS diff shows that 
whole file have been changed.

Maven plugin should modify only lines that contain new (just added) dependency.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (MNGECLIPSE-11) adding dependency to subproject's pom.xml

[ http://jira.codehaus.org/browse/MNGECLIPSE-11?page=comments#action_53567 
] 

Michal Stochmialek commented on MNGECLIPSE-11:
--

Good idea

 adding dependency to subproject's pom.xml
 -

  Key: MNGECLIPSE-11
  URL: http://jira.codehaus.org/browse/MNGECLIPSE-11
  Project: Maven 2.x Plug-in for Eclipse
 Type: Improvement

 Reporter: Michal Stochmialek
 Assignee: Eugene Kuleshov



 I have maven multiproject  in a single eclipse project. 
 Maven plugin correctly searches dependencies in all subprojects and adds them 
 to eclipse .classpath. The same is for updating source folders.
 Unfortunately, adding dependecies (with add dependency option) works only for 
 main pom.xml.
 I would like to choose to which subproject plugin should add chosen 
 dependency. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (MNGECLIPSE-10) problems with dependencies with system scope

[ http://jira.codehaus.org/browse/MNGECLIPSE-10?page=comments#action_53573 
] 

Michal Stochmialek commented on MNGECLIPSE-10:
--

You are right. The issue is more complex than I thought. System scope 
dependencies are properly added to eclipse .classpath by maven plugin. 

The problem is rather with transitive system scope dependencies. I'm attaching 
two eclipse projects which ilustrate the issue.


 problems with dependencies with system scope
 

  Key: MNGECLIPSE-10
  URL: http://jira.codehaus.org/browse/MNGECLIPSE-10
  Project: Maven 2.x Plug-in for Eclipse
 Type: Bug

  Environment: windows xp, eclipse 3.1, plugin 0.0.3
 Reporter: Michal Stochmialek
 Assignee: Eugene Kuleshov



 Maven Plug-in tries to find system scope dependencies in repositories. This 
 of course ends with failure since system scope dependencies are located on 
 local computer.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Updated: (MNGECLIPSE-10) problems with dependencies with system scope

 [ http://jira.codehaus.org/browse/MNGECLIPSE-10?page=all ]

Michal Stochmialek updated MNGECLIPSE-10:
-

Attachment: mngeclipse-10.zip

 problems with dependencies with system scope
 

  Key: MNGECLIPSE-10
  URL: http://jira.codehaus.org/browse/MNGECLIPSE-10
  Project: Maven 2.x Plug-in for Eclipse
 Type: Bug

  Environment: windows xp, eclipse 3.1, plugin 0.0.3
 Reporter: Michal Stochmialek
 Assignee: Eugene Kuleshov
  Attachments: mngeclipse-10.zip


 Maven Plug-in tries to find system scope dependencies in repositories. This 
 of course ends with failure since system scope dependencies are located on 
 local computer.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (MNG-1832) built-in property containing current timestamp

2005-12-14 Thread Michal Stochmialek (JIRA)

built-in property containing current timestamp
--

 Key: MNG-1832
 URL: http://jira.codehaus.org/browse/MNG-1832
 Project: Maven 2
Type: New Feature

Versions: 2.0.1
Reporter: Michal Stochmialek


Current timestamp (time or date) is often used while filtering resources or 
creating manifest in ant builds. There is no equivalent in maven.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (MNG-1733) attaching javadoc jars to eclipse dependencies

2005-12-02 Thread Michal Stochmialek (JIRA)

attaching javadoc jars to eclipse dependencies
--

 Key: MNG-1733
 URL: http://jira.codehaus.org/browse/MNG-1733
 Project: Maven 2
Type: New Feature
  Components: maven-eclipse-plugin  
Versions: 2.0
Reporter: Michal Stochmialek


The downloadSources is great feature of eclipse plugin.

I would like similar feature, that downloads jars with javadocs and also 
attaches them to eclipse dependecies.

best regards, Michal

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (MNG-1558) Manifest generation problems caused by valid POM information

2005-11-25 Thread Michal Stochmialek (JIRA)

[ http://jira.codehaus.org/browse/MNG-1558?page=comments#action_52009 ] 

Michal Stochmialek commented on MNG-1558:
-

I also had some problems connected with this issue.

I had problems while running tests. Surefire was throwning NoClassDefFound for 
classes in jar created by maven. After longer investigation I've discovered 
that Specification-Title of the jar was filled with description field's 
content. After removing the description field and rebuilding the jar, the 
problem dissapeared.

I've voted on this bug.

best regards

 Manifest generation problems caused by valid POM information
 

  Key: MNG-1558
  URL: http://jira.codehaus.org/browse/MNG-1558
  Project: Maven 2
 Type: Bug
   Components: maven-jar-plugin
 Versions: 2.0
 Reporter: Bob Allison
  Fix For: 2.0.1



 It looks like we have some problems with the contents of manifests in jar 
 files.
 According to Sun's documentation 
 (http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html), there are three 
 basic formatting rules which are not always being enforced:
1) All text must be UTF-8
2) Lines are limited to 72 characters; longer lines must be continued
3) Sections are divided by blank lines
 Where are these rules being violated?  The first rule can be violated by any 
 POM which is in a character set other than UTF-8.  The last two rules can be 
 violated by any POM value which spans multiple lines.  Both of these are 
 potential problems since a number of POM values go directly into the manifest 
 without sufficient checking.
   
   
 Example:
 The plugin I have been working on suddenly stopped working.  It stopped when 
 I added a two-line description to the POM.  I have been able to determine 
 that converting the second line of the description into a proper manifest 
 continuation line fixed the problem.  As it turns out, the class loader was 
 ignoring the jar; this created an error where the name of the Mojo class was 
 found but the class could not be loaded.
 Workarounds for the present:
-- Any POM fields which end up in a jar manifest needs to be limited to 
 UTF-8 characters.
-- Multi-line values should be constructed so that all lines start with a 
 space character (not strictly required for the first line but it doesn't 
 hurt).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (MNG-1613) knownhosts file isn't updated when .ssh dir is missing (while deploying to remote scp repo)

2005-11-18 Thread Michal Stochmialek (JIRA)

knownhosts file isn't updated when .ssh dir is missing (while deploying to 
remote scp repo)
---

 Key: MNG-1613
 URL: http://jira.codehaus.org/browse/MNG-1613
 Project: Maven 2
Type: Improvement
  Components: maven-deploy-plugin  
Versions: 2.0
 Environment: windows xp
Reporter: Michal Stochmialek


While deploying an artifact to remote repo using scp, maven asks about 
authenticity of host for every artifact:

The authenticity of host 'tesa3' can't be established.
RSA key fingerprint is 71:50:80:89:dd:38:bf:19:4b:63:e9:2d:a6:25:41:a0.
Are you sure you want to continue connecting? (yes/no):

Then, I created .ssh directory in %USERPROFILE% dir. And after next 
confirmation of host's autheniticy, knownhosts file had been created.  In 
result, problem dissappeared.

I suspect that this is documented somewhere (or maybe not), but I think that 
automatical creation of this directory would be more user-friendly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (MNG-1487) bundleDir

2005-11-10 Thread Michal Stochmialek (JIRA)

 bundleDir
--

 Key: MNG-1487
 URL: http://jira.codehaus.org/browse/MNG-1487
 Project: Maven 2
Type: New Feature
  Components: maven-ear-plugin  
Reporter: Michal Stochmialek




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (MNG-1487) bundleDir

2005-11-10 Thread Michal Stochmialek (JIRA)

 [ http://jira.codehaus.org/browse/MNG-1487?page=all ]
 
Michal Stochmialek closed MNG-1487:
---

Resolution: Incomplete

Sorry. I've created it by mistake.

  bundleDir
 --

  Key: MNG-1487
  URL: http://jira.codehaus.org/browse/MNG-1487
  Project: Maven 2
 Type: New Feature
   Components: maven-ear-plugin
 Reporter: Michal Stochmialek





-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (MNG-1488) need to set default bundleDir for all ear modules

2005-11-10 Thread Michal Stochmialek (JIRA)

need to set default bundleDir for all ear modules
-

 Key: MNG-1488
 URL: http://jira.codehaus.org/browse/MNG-1488
 Project: Maven 2
Type: New Feature
  Components: maven-ear-plugin  
Reporter: Michal Stochmialek


I need an improvement of bundleDir feature. I would like to specify common 
bundleDir for all modules in ear. For example:

plugin
artifactIdmaven-ear-plugin/artifactId
configuration
resourcesDirsrc/resources/resourcesDir
defaultBundleDirAPP-INF/lib/defaultBundleDir
modules
javaModule
...
/javaModule
ejbModule
...
/ejbModule
/modules
/configuration
/plugin

I have ear with single ejb and a bunch of jar archives. I would like them all 
placed in APP-INF/lib directory. Using bundleDir tag I must duplicate whole 
dependency list (and also transitive dependencies) in ear-plugin configuration 
and change bundle dir of each archive. It's very frustrating.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (MNG-1422) antrun: properties not resolved in attributes

2005-11-09 Thread Michal Stochmialek (JIRA)

[ http://jira.codehaus.org/browse/MNG-1422?page=comments#action_50446 ] 

Michal Stochmialek commented on MNG-1422:
-

I've got additional testcase. 

tasks
property name=property1 value=value/
property name=property2 value=${property1}/
property name=property3 value=prefix ${property1}/

echoP1: ${property1}/echo
echoP2: ${property2}/echo
echoP3: ${property3}/echo

echo message=P1: ${property1}/
echo message=P2: ${property2}/
echo message=P3: ${property3}/

echo message=${property1}/
echo message=${property2}/
echo message=${property3}/
/tasks

And it produces:

[INFO] Executing tasks
 [echo] P1: value
 [echo] P2: value
 [echo] P3: prefix null
 [echo] P1: null
 [echo] P2: null
 [echo] P3: null
 [echo] value
 [echo] value
 [echo] prefix null
[INFO] Executed tasks

As you see resolving properties in attributes doesn't work only when there is a 
prefix before property reference (${prop}). 
${property} - WORKS
pre ${property} - NOT

I'm attaching pom.xml


 antrun: properties not resolved in attributes
 -

  Key: MNG-1422
  URL: http://jira.codehaus.org/browse/MNG-1422
  Project: Maven 2
 Type: Bug
   Components: maven-antrun-plugin
 Versions: 2.0
  Environment: windows xp pro
 Reporter: Michal Stochmialek



 I found strange behavior of antrun plugin. I believe that properties are not 
 resolved correctly in attributes content. For example echo task is 
 producing different output depending on place where property is used. When 
 property is used in tag body, the result is correct. But when used in 
 attributes the result contains 'null's.
 I've tested it on example below.
 plugin
 artifactIdmaven-antrun-plugin/artifactId
 executions
 execution
 phasepackage/phase
 configuration
 tasks
 property name=destdir
 
 location=${maven.build.directory}/jarInEar/
 #  Those two lines below produce 
 different output
 echo1: ${destdir}/echo
 echo message=2: ${destdir} /
 /tasks
 /configuration
 goals
 goalrun/goal
 /goals
 /execution
 /executions
 /plugin
 [INFO] [antrun:run {execution: default}]
 [INFO] Executing tasks
 [DEBUG] getProperty(ns=null, name=ant.reuse.loader, user=false)
 [DEBUG] getProperty(ns=null, name=destdir, user=false)
  [echo] 1: P:\projects\endpoint\target\jarInEar
  [echo] 2: null
 [INFO] Executed tasks
 This bug prevents from using properties in general, since almost most task's 
 arguments are applied using arguments. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Updated: (MNG-1422) antrun: properties not resolved in attributes

2005-11-09 Thread Michal Stochmialek (JIRA)

 [ http://jira.codehaus.org/browse/MNG-1422?page=all ]

Michal Stochmialek updated MNG-1422:


Attachment: pom.xml

test case

 antrun: properties not resolved in attributes
 -

  Key: MNG-1422
  URL: http://jira.codehaus.org/browse/MNG-1422
  Project: Maven 2
 Type: Bug
   Components: maven-antrun-plugin
 Versions: 2.0
  Environment: windows xp pro
 Reporter: Michal Stochmialek
  Attachments: pom.xml


 I found strange behavior of antrun plugin. I believe that properties are not 
 resolved correctly in attributes content. For example echo task is 
 producing different output depending on place where property is used. When 
 property is used in tag body, the result is correct. But when used in 
 attributes the result contains 'null's.
 I've tested it on example below.
 plugin
 artifactIdmaven-antrun-plugin/artifactId
 executions
 execution
 phasepackage/phase
 configuration
 tasks
 property name=destdir
 
 location=${maven.build.directory}/jarInEar/
 #  Those two lines below produce 
 different output
 echo1: ${destdir}/echo
 echo message=2: ${destdir} /
 /tasks
 /configuration
 goals
 goalrun/goal
 /goals
 /execution
 /executions
 /plugin
 [INFO] [antrun:run {execution: default}]
 [INFO] Executing tasks
 [DEBUG] getProperty(ns=null, name=ant.reuse.loader, user=false)
 [DEBUG] getProperty(ns=null, name=destdir, user=false)
  [echo] 1: P:\projects\endpoint\target\jarInEar
  [echo] 2: null
 [INFO] Executed tasks
 This bug prevents from using properties in general, since almost most task's 
 arguments are applied using arguments. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (MNG-1422) antrun: properties not resolved in attributes

2005-11-04 Thread Michal Stochmialek (JIRA)

antrun: properties not resolved in attributes
-

 Key: MNG-1422
 URL: http://jira.codehaus.org/browse/MNG-1422
 Project: Maven 2
Type: Bug
  Components: maven-antrun-plugin  
Versions: 2.0
 Environment: windows xp pro
Reporter: Michal Stochmialek


I found strange behavior of antrun plugin. I believe that properties are not 
resolved correctly in attributes content. For example echo task is producing 
different output depending on place where property is used. When property is 
used in tag body, the result is correct. But when used in attributes the result 
contains 'null's.

I've tested it on example below.

plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasepackage/phase
configuration
tasks
property name=destdir

location=${maven.build.directory}/jarInEar/
#  Those two lines below produce 
different output
echo1: ${destdir}/echo
echo message=2: ${destdir} /
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
/plugin


[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[DEBUG] getProperty(ns=null, name=ant.reuse.loader, user=false)
[DEBUG] getProperty(ns=null, name=destdir, user=false)
 [echo] 1: P:\projects\endpoint\target\jarInEar
 [echo] 2: null
[INFO] Executed tasks


This bug prevents from using properties in general, since almost most task's 
arguments are applied using arguments. 



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (MNG-940) assembly:unpack should support more archive types

2005-09-21 Thread Michal Maczka (JIRA)

assembly:unpack should support  more archive types
--

 Key: MNG-940
 URL: http://jira.codehaus.org/browse/MNG-940
 Project: Maven 2
Type: New Feature
  Components: maven-assembly-plugin  
 Reporter: Michal Maczka


assembly:unpack should support more types of archives. In particular I need to 
assembly zips and wars togethter.

Other feature which is missing (should I add another issue for this) is a 
possiblility of deciding per artifact basis where given archive should be 
unpacked.

Implementation hint: I don't think that it is really necessery to make any 
distiniction between jars, zips wars, ears etc. They can be all threted as 
zips. So implementation can be in fact simplified and support for more type 
added very easly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (MPMULTIPROJECT-49) Can not mix multiproject goals with other/custom goals

2005-09-05 Thread Michal Slocinski (JIRA)

[ 
http://jira.codehaus.org/browse/MPMULTIPROJECT-49?page=comments#action_45815 ] 

Michal Slocinski commented on MPMULTIPROJECT-49:


Workaround given here doesn't work for me :-/ I've similar situation like 
described below, 
except that I'm tryining to run goal defined in my custom plugin.

 Can not mix multiproject goals with other/custom goals
 --

  Key: MPMULTIPROJECT-49
  URL: http://jira.codehaus.org/browse/MPMULTIPROJECT-49
  Project: maven-multiproject-plugin
 Type: Bug
  Environment: windows 2000
 cruisecontrol
 maven 1.0.2
 java 1.4.2
 Reporter: Jesper Tejlgaard Pedersen



 I would like to configure the multiproject plug-in to run checkstyle 
 separately on our buildserver.
 We are trying to run maven using the command 
 maven -Dgoal checkstyle multiproject:install multiproject:goal 
 multiproject:clean multiproject:deploy
 This however only results in an execution which could have been described as 
 maven multiproject:install multiproject:install multiproject:clean 
 multiproject:deploy.
 That is: install is runned twice instead of running install followed by 
 checkstyle.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (MNG-691) Ability to assign a report to choosen navigation menu

2005-08-03 Thread Michal Maczka (JIRA)

Ability to assign a report to choosen navigation menu 
--

 Key: MNG-691
 URL: http://jira.codehaus.org/browse/MNG-691
 Project: Maven 2
Type: Wish
 Reporter: Michal Maczka


It will be nice to have a possibiliy of deciding per report basis where (in 
which menu) given report will appear in the left side navigation instead of 
putting all reports into one bag (reports menu).



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (MNG-521) Version inheritance from the parent pom

2005-07-15 Thread Michal Maczka (JIRA)

[ http://jira.codehaus.org/browse/MNG-521?page=comments#action_42869 ] 

Michal Maczka commented on MNG-521:
---

If I can add my two cents:

It is not really required to have single place that will have global version 
number, which then used for submodules.

I belive that the correctly stated requirment should be: It's important that 
common version number for multiple modules can be easily changed. 
And the strategy of having the version in a single place is just the one of the 
implementation of that requirement which can exist.

What if there were gui tool or maven plugin which will do the job for you?

say you will do something like:

m2 project:upgrade-version -Dversion=1.2

and maven will recursively upgrade the current version and parent's version in 
multiple POMs. Wouldn't it be simple enough?


 Version inheritance from the parent pom
 ---

  Key: MNG-521
  URL: http://jira.codehaus.org/browse/MNG-521
  Project: Maven 2
 Type: Improvement
   Components: design
 Reporter: Eugene Kuleshov
 Assignee: John Casey
  Fix For: 2.0-beta-1



 Currently m2 pom require to have explicit version of the parent pom in all 
 submodules. This should work fine for standalone artifacts. However there 
 is different type of projects (e.g. EAR) that is usually stored in version 
 control as a whole thing and may contain multiple modules (ejb jars, rar, 
 war, etc) that are build with the same version as entire EAR. So, EAR 
 application released with a single global version for all submodules. In m1 
 this was possible to specify relative path to parent pom and use version 
 substitution in child modules and deployer goal was substituting values for 
 version numbers upon deployment.
 For this kind of modules it is very important to have single palce that will 
 have global version number, which then used for submodules. It is also make 
 sense to kee optional relative path (that can be also removed/replaced with 
 concrete parent id/version upon deployment) to support local build. I believe 
 this is very important for J2EE builds as well as any other projects that are 
 releasing multiple artifacts/jars under the same version  (e.g. ASM, XDoclet).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

Re: POM issues in the repository

2005-07-10 Thread Michal Maczka


John Casey wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 In my opinion, this thread is not particularly useful. As far as I know,
 we have not called for a vote on the final release of Maven 2.0. (we
 haven't even released -beta-1 yet, for crying out loud!)

 This is my last reply on this thread; it is fast growing into another
 bitch session and waste of my time.

 See my comments inline.

 Maczka Michal wrote:
 |
 | a) build won't be reproductable

 If you're declaring your API dependencies correctly for your project,
 this absolutely should not have an impact on you. Any POM cleanup
 efforts should be directed at eliminating test-scope dependencies, or in
 some [extremely rare] cases, optional dependencies. The latter case
 should be covered by your project, since if it uses these optional
 parts, it should make some use of these same dependencies.

So you are saying that: you are not going to add any dependencies to any 
poms

nor to re order them?


 | b) the scenario which you are proposing - everybody maintaining its own
 | maven repository with competing metadata even for open source projects
 | will become the reality. And this is something which in my opinion
 won't be
 | any good for maven nor for improving the quality of the maven central
 | repository. I already know some people which are creating their own m2
 | repositories and the work which there are doing is not at all serving
 maven
 | community. I am all for centralising that effort.

 I know of people who won't use Maven or its repository because the
 artifacts aren't signed. Sure, there are going to be people who demand a
 higher level of quality than we are prepared to offer for the meantime;
 that is unavoidable. However, most users should be fine with the level
 of quality we can provide, particularly for the dependency use case.
 Project URLs and such are not as critical for this use case.

 |
 | Note then when I am saying that no POMs should not be changed - 
this means
 | that no dependency should be added, removed or moved to different 
position

 | witin the pom. The algorithm which resolves transitive dependencies is
 very
 | fragile: it is even (accordingly to my knowledge) sensitive to the
 position
 | of the dependency in the pom.

 If I understand correctly, you're alluding to the use of the nearest
 dependency-version taking precedence in a collision scenario. This is
 the default policy for m2, but doesn't have to be the only one. Before
 we release m2 final, we will allow (if we don't already) pluggable
 dependency-version conflict resolution policies. I don't agree that the
 transitive dep algorithm is so fragile, particularly when you change the
 version conflict policy...can you be more specific, or will this remain
 an unsubstantiated claim?

Sure I can be more specific.

The algorithm which resolves transitive dependecies does two things:

a) Iterates throgh graph of dependecies
b) Collects some of them into the list appling some conflict resolution 
strategy.


Let's analyse togther the following example (and you tell me if I am am 
wrong)


We have 4 projects: A, B, C, D


project (typical naked pom)
 artifactIdA/artifactId
  ...
 dependencies/
/project



project
 artifactIdB/artifactId
 ...
 dependencies
   dependency
 artifactIdfoo/artifactId
 version1.1/version
   /dependency
   dependency
 dependencies
/project



project   
 artifactIdC/artifactId

  ...
 dependencies
   dependency
 artifactIdfoo/artifactId
 version1.2/version
   /dependency
 /dependencies
/project



project
  artifactIdD/artifactId
  ...
  dependencies
   dependency  
 artifactIdA/artifactId  
   /dependency
   dependency  
 artifactIdB/artifactId  
   /dependency
   dependency  
 artifactIdC/artifactId  
   /dependency

 /dependencies
/project

When you will be building D

m2 will use foo 1.1 as dependency.


If you will change D to (B and C changed their positions):

project
  artifactIdD/artifactId
  ...
  dependencies
   dependency  
 artifactIdA/artifactId  
   /dependency
   dependency  
 artifactIdC/artifactId  
   /dependency
   dependency  
 artifactIdD/artifactId  
   /dependency
   
 /dependencies

/project

you will have foo 1.2 as dependency in D.


Now if you will change pom A  - that's what's happening now often to 
naked poms -

and you will add there some dependencies:


project
 artifactIdA/artifactId
 ...
 dependencies
   dependency
 artifactIdfoo/artifactId
 version1.3/version
   /dependency
   dependency
 dependencies
/project

you will have foo 1.3 as dependency in D.

That's how the current policy works.
But there is nothing wrong with it per se - it is impossble to invent 
version conflict policy,
which will be insensitive to chages in graph structure (introduced by 
changes in individual POMs)
other then the one which is currently  used in ... m1:  
you explicitly have to list all you dependencies

RE: POM issues in the repository

2005-07-09 Thread Maczka Michal

 -Original Message-
 From: Kris Bravo [mailto:[EMAIL PROTECTED] 
 Sent: Saturday, July 09, 2005 5:18 PM
 To: Maven Developers List
 Subject: RE: POM issues in the repository

 There is nothing wrong with having or using the minimal POMs 
 that can be found in the repository. As a user if I find, for 
 example, a sun library for which no POM exists, I am willing 
 to submit a basic POM which will cause my build to continue 
 unimpeded by its absence. I won't however, stop every time 
 this occurs and fill out a bunch of excess metadata with no 
 programmatic relevance that someone else decided would be 
 nice to have in the file as well.

 Keep in mind this one file format is used for two entirely 
 distinct purposes. The first, describing a project you're 
 building, seems a more plausible explanation of what the 
 extra metadata is geared towards. The second, using the 
 project as a dependency, gains no benefit from the metadata 
 you are suggesting users should insist on.

 When the m2 codebase becomes beta-ready and the minimal 
 information in the repository lets me build my projects, I 
 personally don't want to wait around for a metadata cleanup 
 before they open the doors on mainstream usage. I'd rather 
 have the extra effort go towards plugin development.

 But since maven permits you to specify your repository in 
 your settings, none of this is a problem. If you need a 
 higher quality repository than what's available you can 
 simply create one within your own environment and point to 
 it. Each time you need a new dependency met, you can copy 
 from ibiblio and add the additional information to the POM 
 necessary for your projects. See maven-proxy, it works with 
 m2 as well.

 Kris

You didn't get my point.

My point was that it is irrelevant if POMs in the repository are minimal or
not.
But it is extremely important that information which is the main maven
repository is _not changing_!!!

Otherwise:

a) build won't be reproductable 
b) the scenario which you are proposing - everybody maintaining its own
maven repository with competing metadata even for open source projects 
will become the reality. And this is something which in my opinion won't be
any good for maven nor for improving the quality of the maven central
repository. I already know some people which are creating their own m2
repositories and the work which there are doing is not at all serving maven
community. I am all for centralising that effort.

Note then when I am saying that no POMs should not be changed - this means
that no dependency should be added, removed or moved to different position
witin the pom. The algorithm which resolves transitive dependencies is very
fragile: it is even (accordingly to my knowledge) sensitive to the position
of the dependency in the pom.

I also have no better alternative to what's happening now with m2
repository. But I share Vincent's opinion:
There needs to be a big effort to clean the m2 repo of bad POMs and I am
just adding that this in my opinion should happen and ___finish_ 
before maven 2.0 will be proclaimed as final or even beta. Otherwise the
situation which happen with m1: some people tried unstable beta versions and
never come back to maven will be repeated one more time. But this time it
won't happen due to the code quality (which is really excellent in case of
m2) but due to the repository related problems.

Michal

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

Re: POM issues in the repository

2005-07-09 Thread Michal Maczka


Kris Bravo wrote:


You didn't get my point.

My point was that it is irrelevant if POMs in the repository are minimal or
not.
But it is extremely important that information which is the main maven
repository is _not changing_!!!

   



I did get your overall point. But contrary to what you're now saying,
you went on this tangent, which I was addressing specifically:

From this perspective it might be better to have a smaller but high
quality
repository which is growing then a big crappy repository containing 
invalid POMs or naked POMs like that

(http://www.ibiblio.org/maven2/axis/axis/1.2/axis-1.2.pom):

project
 modelVersion4.0.0/modelVersion
 groupIdaxis/groupId
 artifactIdaxis/artifactId
 version1.2/version
/project


IMO at least project description and license should be present in all
POMs
in the repository. 

So if you're now saying that minimal POMs are okay, then yeah, I agree.

Kris

 


To make myself clear - I wanted to say that:

a) maven _central_ repository to be reliable should implement WORM 
(Write Once Read Many times) principle from some moment in time.
It would be nice to know a date when it will happen to be sure that 
poms  in the central repository are not going to change even a bit.
IMO it this date should preceded 2.0 release but it is definitely too 
early to make that move now as the velocity of repository building

will go down.

b) if WORM principle would be applied - then naked poms still may exist 
in the central repository but it will be a big pity to have them threre 
as they
 never can be changed or improved. That's why it would be actually 
better to get rid of them at some moment in time as the place for high 
quality poms will remain open.



Michal

--
Najnowsze wiadomosci!!!  http://link.interia.pl/f18a0


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

Re: POM issues in the repository

2005-07-08 Thread Michal Maczka


John Casey wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I think that such a drastic step will only serve to completely
marginalize maven 2.x, and alienate users. Who would convert to using m2
if they first had to re-request uploads for the 10 dependencies they
have?? 


I hope that m2 users will help you to get this problem fixed.


While I agree that the repository information we currently have
is inadequate and incomplete, such is life. When have you ever worked on
a product revision/rewrite where you *didn't* have to deal with bad
data? 

In my build system??  Never! That's too high risk to take. I would only 
change the build system if I would be certain that if will

not deceive me as I have to many problems to deal with elsewhere.


The answer is *never* to blow away everything you know and replace
it with only the things you know to a perfect degree...you'd be
re-creating your datastore with every new major version.
Also, to address your assertion about Maven 2.x's readiness for
production - perhaps you noticed the -alpha-3 notation we've used on the
latest release? ;) This software isn't perfect yet, and neither is the
data it relies on...but we're working on it, and it *will* get better.

 


But you are aiming at 2.0 release real soon: in August, do not you?
I personally would keep maven in alpha stage as long as repository is 
not ready for public use even if the m2 code will be prefect
and ready for prime time as you simply cannot use m2 without reliable 
repository.
This gives  a full right to use the current strategy for improving the 
repository data.



Obviously, having naked poms isn't a good idea, but it will help users
trying to migrate from maven 1.x (where they couldn't use the
transitivity of dependencies anyway), and as these users attempt to trim
their own dep lists, they can help us fix these bad poms. We cannot
adopt the strategy of only putting perfect metadata into the repository,
since our users need access to such a wide spectrum of libraries.
Initially, for upgrading users, it will be better to have *some* access
to these artifacts rather than clogging the MAVENUPLOAD project with
re-requests.
 


I am complete agreeing  with you.
I am just linking 2.0  release (which gives clear signal to users: __it 
is production ready__) with readiness of the repository for the 
demanding (normal?) users
and not  just  for those brave early adopters, which are generally fans 
of maven and will use it anyway.
Once m2 final relases will get the label of being not reliable as its 
repository is constantly changing this is what can be actually
the factor (just hypothesis) which marginalize maven 2.x, and alienate 
users
as it is very difficult to change such negative image after bad press, 
which you will surly have.
I am just feeling that missisng poms in the repository give more 
motivation to provide good ones then naked ones as they give the false 
impression
that data in the repository is OK. I do hope to have time to help you to 
clean you poms I am using. And I am hoping that your community will 
really help you to get it fixed asap.


just my 2 cents

regards

Michal




--
Zamachy w Londynie: FOTO RAPORT  http://link.interia.pl/f18a1


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

RE: POM issues in the repository

2005-07-08 Thread Maczka Michal

 -Original Message-
 From: John Casey [mailto:[EMAIL PROTECTED] 
 Sent: Thursday, July 07, 2005 7:12 PM
 To: Maven Developers List
 Subject: Re: POM issues in the repository

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 1. define sanity.

 2. define validity.

 We have a tool out there right now that converts POMs from 
 the m1 repository to the m2 repository, and does some meager 
 checking on the XML/model validity of the POM on the way. 
 HOWEVER, that's not the same as saying it checks that all of 
 that POM's deps are in the repository.

 Reiterating what Emmanuel said, we do have plans to enhance 
 this application and provide much more 
 functionality...eventually. So far, we've been emphasizing 
 the development and stability of m2 over this tool. If you'd 
 like to log a specific issue, you might want to do so in the 
 Maven Repository Manager project (MRM) in JIRA...if it's a 
 specific POM you're having trouble with, you can do one of two things:

 1. add an exclusions block to your dependency (useful for 
 dom4j). This will work if the dependency has a dependency 
 which is only used in certain cases, which you are not interested in.

 2. file an issue in MEV (Maven Evangelism) JIRA, or enhance a 
 current issue. If the POM is really bad (not just a bad build 
 design on the part  of dom4j or something), then we can only 
 fix our copy and get in touch with the dom4j guys to fix it 
 at the source. However, if for some reason that POM's 
 filesystem timestamp changes in our staging repository, the 
 same old problems will be re-propagated. This is because we 
 consider the dependencies given by a project's development 
 team in the POM to be authoritative by default.

 We're all pretty much aware that the metadata from the 
 maven-1 repository is somewhat lacking, to say the least. 
 Unfortunately, due to the decentralized control over the 
 repository's contents (projects are supposed to be in control 
 of their own information, as we cannot be experts on all 
 projects we supply in the repository), I'm not at all 
 convinced that there is an easier way to clean this stuff up.

 Of course, suggestions and help are both very welcome. :)

If I can have a suggestion:

I the fact that repository is changing constantly is even worst then the
fact that some POMs are missing or are incorrect. 

I cannot imagine somebody using m2 in production and relaying on such
unstable repository which introduces indeterminism to builds.
It's just enough to change an order of dependencies in one of the POMs and
some builds might be broken or what's very serious
not possible to reproduce in the future. 

From this perspective it might be better to have a smaller but high quality
repository which is growing then a big crappy repository containing 
invalid POMs or naked POMs like that
(http://www.ibiblio.org/maven2/axis/axis/1.2/axis-1.2.pom):

project
  modelVersion4.0.0/modelVersion
  groupIdaxis/groupId
  artifactIdaxis/artifactId
  version1.2/version
/project

IMO at least project description and license should be present in all POMs
in the repository. 
It will be nice to have more things in those POMs (e.g. url of the main
website, organization section etc)
And unfortunately no tool can provide this information automatically. You
need many people to help you with that!

Michal

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

Re: [result] demote plugins

2005-06-15 Thread Michal Maczka


Brett Porter wrote:


The following have been demoted:
ashkelon, wizard, tjdo, shell, appserver, webserver, aspectwerkz, 
caller, struts, docbook, jdee, jdeveloper, junitdoclet, latex, latka

Nobody piped up to object on the users list.

javacc was spared on the account of Stephane and Michal's use of it. 
It moves to the borderline list. I'd really appreciate anyone actively 
using something on that list to step up and work through the JIRA 
issues, document it, or find it a new home.



*mucios* *gracias!

michal*



--
Startuj z INTERIA.PL!  http://link.interia.pl/f186c 



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

RE: [vote] demote plugins

2005-06-14 Thread Maczka Michal

 -Original Message-
 From: Brett Porter [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, June 14, 2005 2:55 AM
 To: Maven Developers List
 Subject: Re: [vote] demote plugins

 Michal Maczka wrote:

  I am using javacc in production in couple of project and it 
 actually 
  works like charm for me (I am not using jjtree). Docs are definitly 
  not up to date. I know that there is more people using it. So if I 
  could cast no binding, user vote for that plugin it would be:  -1.

 This is not about terminating plugins, but about improving 
 the out of the box usability. So while you might be using it 
 - that's fine, and you can continue to do so by downloading 
 the last release, or building from the sandbox. But until 
 someone steps up to maintain it and document it, I'd rather 
 not have it in the core distribution. Of all the plugins, it 
 and probably release are the ones that had a specific 
 complaint about its roadworthiness from a user.

I understand all that and from your perspective this is definitly a good
thing.

I don't know nothing about recent complaints reagrding javacc plugin. Really
it just works for me.

What I am saying is that from the user perspective it is reasonable to
expect that builds which used to work out of the box with maven 1.0.X 
should also work with maven 1.1.x. (just minor version is changing). Believe
it or not but there is a bunch of users who has never built maven plugin and
even don't know how to manually download plugins. In case of the enterprises
where nobody is controlling which version of maven they are using so if any
of them will upgrade to maven 1.1 (or simply somebody new will just start
directly using maven from version 1.1.0). For such people it is really a
breaking and quite scary change. There is a general and a good rule often
used while software platforms are evolving:: things go in, but they never go
out (even if they are of dubious quality or better equivalents already
exit). Java/Windows and other platforms try to follow that rule as full
backward compatibility is a top priority for them. In your case m2 will
hopefully come with high quality plugins, but removal of the plugin from the
base distribution of m1 will actually downgrade user experience rather then
improve it. People are (unfortunately) used to undocumented plugins but they
are not used to disappearing ones. 

Note: I am not writing about plugins which are clearly broken or are not
working at all.

BTW: Are you going to publish all plugins from sandbox somewhere?

regards

Michal

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

Re: [vote] demote plugins

2005-06-13 Thread Michal Maczka


Brett Porter wrote:

Please vote on demoting the following plugins. They will be moved back 
to the sandbox, and will not be distributed with Maven 1.1. Any with 
no open bugs in JIRA will have their project deleted (we should work 
on a server side solution to toss all the others into a sandbox bug 
project and delete them too).


Docs will be added to the backwards compat page explaining how you get 
the old releases, and what to do if you want to revive its 
development. An RFC will be sent to the user list first too.


A single +1 indicates agreement to all of the below. Otherwise, please 
+1, -1 the individually. Any -1's will prevent that plugin from being 
demoted until we can resolve the issue. The vote is open until it is 
no longer Monday 13th in your part of the world.


javacc - experimental at best, no maintainer


I am using javacc in production in couple of project and it actually 
works like charm for me (I am not using jjtree). Docs are definitly not 
up to date. I know that there is more people using it. So if I could 
cast no binding, user vote for that plugin it would be:  -1.


Wouldn't it be nice to ask users - how many of them are using plugins 
from your list?
I guess that there is probably bit more people following the traffic on 
maven-user then on maven-dev list.


regards

Michal

--
Startuj z INTERIA.PL!  http://link.interia.pl/f186c 



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

Re: [m2] How to add an artifact dynamically to the CP?

2005-06-13 Thread Michal Maczka


Vincent Massol wrote:


Hi,

I need to add the Clover JAR defined in the Clover plugin to the compile CP
of the project using the Clover plugin. This is because the Clover
instruments the source code and thus when compiling the instrumenting
sources the Clover JAR needs to be in the CP.


 



Vincent,

Maybe completly stupid and wrong proposition/idea - but wouldn't it be 
simpler for you to reuse some plexus components directly in your clover 
plugin

rather then to relay on maven lifecycle execution with some strange tricks?

As I understand mojo api - the main reason why it looks like it looks 
was to make mojo standalone and reusable outside maven.
Doesn't it mean that clover mojo should also be aiming to be possibly 
usable without maven?


In you case you can probably reuse plexus compiler and test runner 
components and bent them to your needs..


greets

Michal



--
Znajdz swoja milosc na wiosne...  http://link.interia.pl/f187a


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

RE: [jira] Commented: (MNG-415) allow exclusion of certain depend encies from inclusion in an archive

2005-05-23 Thread Maczka Michal

Hey Brett!


my comments inline. To me, you seem to be viewing all of dependency 
management through the eyes of a single use case (being war 
exclusions), which is where we are disagreeing.

Maczka Michal wrote:

  

And it indeed requires some amount of extra work in a very limited set 
of cases ( triples what needs to be specified  is not really 
accurate - see below).



To allow for multiple values:
scopefoo/scope
becomes
scopes
  scopefoo/scope
/scopes
if we are to retain the conventions used so far.

  


This is just one of many possibilities.

Some of others are:

a) use predefined tags (do you want to have more scopes then compile,
runtime and test?) :

dependency
compile/
test/
/dependency

b) use flat structure
dependency
scopetest/scope
scopecompile/scope
/dependency

c) change the rules which exists and add one more predefined scope

one more scope maybe introduced (e.g. named global)

and your rules:

compile -- runtime   (-- means imply)
runtime -- test

can be replaced with:

global -- compile
global -- runtime
runtime -- test
compile -- test


And have a default scope set to global

I am sure that there is bunch of much better options then those which I
found quite quickly.

But the question is: do you want to still consider changes in that part of
m2 or for you this part is fixed?
At the moment the number of POMs which are using scope tag is very low. 
So this will be no almost breaking change.
So if you are saying: scopes in m2 are not going to change and this is not
something which we are ever going to consider - I think that this discussion
is useless and I am not going to waste my precious time anymore.

I also believe that the best option here will be this one, which will be the
most intuitive for users. So they can guess what are the rules without even
looking at the documentation. So my proposition c) and what exists now as
for me seem to be an inferior solutions as users have to learn some
unintuitive and very arbitrary rules. But to know that for sure what's easy
and intuitive you must actually ask your users what is simple for them. As
something which is simple for you or for me does not have to be simple for
avg. user.


You wrote:

Hugo - if you make runtime imply compile you can never have a runtime
only dependency, which is a valid and common use case (i.e. anything where
you only call into it via reflection - like a JCE provider, etc). 

I can replay to that

if you make compile imply runtime you can never have a compile time only
dependency, which is a valid and common use case. 

I don't think that any of those two usecase is more important and that's why
it would be nice to support both.



[...]

Or for simplicity, let's make servletapi a default exclude for WAR and 
not configure anything. It's not worth changing the defiition of the 
dependencies for a single JAR.

  

you may have classes from servletapi incorporated into some other jars (e.g.
j2ee). And you still need to exclude some other jars.

Sure. But war is an assembling plugin and if you have project 
packaging set to war you are actually not likely going to use the 
same pom for creating other assemblies and you definitly know 
something about environment in which this artifact will be used 
(servlet container). It is just a question if standard attributes of 
dependencies are sufficient or not and if they are not sufficient how it
can be done in the other way.
Anyway scope tag (scope=test) is already used for filtering out 
artifacts


from assemblies so I don't see what's actually the problem with that.
  

 



I'm probably missing something, but I can't see how what you are saying 
here is related to my point at all. I'm saying you can't change the 
definition of scope for the entire system to fit the war use case.

  


From a pure point of view a compile time dependency is always needed 
at
runtime (unless the code is never hit, or the server provides the jar, 
all of which is environmental, not by definition)

Not true. For example servletapi is a jar agaist which you want to 
compile but most servlet containers have classes from that jar bundled 
in their own jars which have completely different names.
 



Read what I wrote again. The servletapi, needed at compile time, is 
also needed at runtime. You've just said so yourself. Just because the 
container happens to provide it, doesn't change anything.
  

One more time: no! The container doesn't have to provide _the_ servletapi
jar which was used at compile time.
It just needs to provide the compatible substitute. It maybe be a different
jar (e.g. something like geronimo-spec) or servletapi with higher version.  


Since we seem to be stuck on servletapi, let's go to a practical 
example. You run some tests using a mock library that calls your code, 
which utilises the servletapi. No container. What scope does the 
servletapi have in your proposal? You'll probably answer compile, test
which in this example is valid

[jira] Commented: (MNG-415) allow exclusion of certain dependencies from inclusion in an archive

2005-05-19 Thread Michal Maczka (JIRA)

 [ http://jira.codehaus.org/browse/MNG-415?page=comments#action_39283 ]
 
Michal Maczka commented on MNG-415:
---

EAR is a different case then WAR as not only you must decide what will be 
included in the archive 
but also attach some information to some dependencies (e.g. context roots for 
wars)

The decison of what gets included and what not can be based on artifact's type 
and scope.
For wars in particular only all runtime dependecies should be included and 
nothing else (compile and test dependecies should be skipped). So one of the 
possible solutons would be to enable to enumerate dependency scopes rather then 
assume that all compile time dependecies are also runtime dependecies.

To give an example

dependency
  
   scoperuntime/scope  (will be included in the war)
/dependency


dependency
  
   scoperuntime/scope  (will be included in the war)
   scopecompile/scope  
/dependency


dependency
  
 
   scopecompile/scope  (will not be included in the war)
/dependency


dependency
   
   scopetest/scope  (will not be included in the war)
/dependency

This approch seems to be the most natural and simple one and covers in a 
generic way all the cases I can think of. 

Note the artifact scope given at the top level affects also dependencies of 
dependencies.





 allow exclusion of certain dependencies from inclusion in an archive
 

  Key: MNG-415
  URL: http://jira.codehaus.org/browse/MNG-415
  Project: m2
 Type: Improvement
   Components: maven-plugins, maven-archiver
 Versions: 2.0-alpha-2
 Reporter: Brett Porter
  Fix For: 2.0-alpha-3



 this has been requested for WAR, but it should apply to all archives that 
 include dependencies.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (MNG-415) allow exclusion of certain dependencies from inclusion in an archive

2005-05-19 Thread Michal Maczka (JIRA)

 [ http://jira.codehaus.org/browse/MNG-415?page=comments#action_39285 ]
 
Michal Maczka commented on MNG-415:
---

I understood how the scopes work and that why I am proposing is to change it as 
this seems to be the simplest
solution for this problem.

Really what you want to bundle in wars, ears and such  artifacts are only 
runtime dependecies.
servletapi is compile time only dependency but __it is not__ a runtime 
dependecy so it should not be bundled in wars. 

This seems to be natural for me and apparently for some other people.
Look at the subject of the thread:

how to exclude compile time only jars from .war?




 allow exclusion of certain dependencies from inclusion in an archive
 

  Key: MNG-415
  URL: http://jira.codehaus.org/browse/MNG-415
  Project: m2
 Type: Improvement
   Components: maven-plugins, maven-archiver
 Versions: 2.0-alpha-2
 Reporter: Brett Porter
  Fix For: 2.0-alpha-3



 this has been requested for WAR, but it should apply to all archives that 
 include dependencies.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

RE: [jira] Commented: (MNG-415) allow exclusion of certain depend encies from inclusion in an archive

2005-05-19 Thread Maczka Michal

 

 -Original Message-
 From: Brett Porter (JIRA) [mailto:[EMAIL PROTECTED] 

  
to your point, however - making your change: 
a) triples what needs to be specified for most compile dependencies - you'd
also need to specify test, and hope we never add anything else implied from
compile. This violates the rule we're 
following of making the defaults work most of the time, and the amount of
configuration needed minimal. 

How does it violates this rule?
The defaults will remain the same - if you don't give provide dependency
scope (as far as I see it now this will be a case for most of the non test
dependencies) dependencies will be visible in all classpaths.
Only when you will want to have one of them  excluded  from some classpaths
you will want to use scope tags. both compile time and runtime dependecies
can be also still visible in test class path.

And it indeed requires some amount of extra work in a very limited set of
cases ( triples what needs to be specified  is not really accurate - see
below).  But if you compare this to amount of work needed in any other
solution I can think of it actually reduces that amount by much larger
factor (probably more then 10).  So if you look for simplicity - this is
probaly the simplest solution. Just to exclude serlvletapi from war you will
have to change:

from:
dependency
 ..
artifactIdservletapi/artifactId
..
/dependency

to:
dependency
 ..
artifactIdservletapi/artifactId
scopecompile/scope  (you just need to add this single line to
excluded dependency from runtime classpath)
..
/dependency

I don't see how does it triples what needs to be specified and how it can
get any simpler :)


b) is not actually scope any more. Excluding something from runtime, but
including it compile assumes something about the end environment, which the
dependencies should not do - that's the job of the assembling plugin. 

Sure. But war is an assembling plugin and if you have project packaging set
to war you are actually not likely going to use the same pom for creating
other assemblies and you definitly know something about environment in which
this artifact will be used (servlet container). It is just a question if
standard attributes of dependencies are sufficient or not and if they are
not sufficient how it can be done in the other way. 
Anyway scope tag (scope=test) is already used for filtering out artifacts
from assemblies so I don't see what's actually the problem with that.


From a pure point of view a compile time dependency is always needed at
runtime (unless the code is never hit, or the server provides the jar, all
of which is environmental, not by definition) 

Not true. For example servletapi is a jar agaist which you want to compile
but most servlet containers have classes from that jar bundled in their own
jars which have completely different names. 


 So unless there is something else missing, the scope will 
 remain as it is. We can't go breaking backwards compatibility 
 unless it is a really serious problem that we can't take forward.
 

I think this case qualifies for such change :) 
 
regards

michal

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

RE: payload

2005-04-19 Thread Maczka Michal

 -Original Message-
 From: Brett Porter [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, April 19, 2005 4:21 AM
 To: Maven Developers List
 Cc: 'Henri Yandell'
 Subject: payload

 http://www.osjava.org/payload/index.html

 This seems very much related to what we were talking about 
 with respect
 to filtering - applying deployment profiles to previously 
 built artfiacts.

Yes. Now I am sure that we are on the same page :).

I have one question - what's really the signification of packaging tag in
POM?
Does it activate a plugin or does it tell maven what will be the type of the
main artifact or both?
(I am not only asking about current state of the implementation but also
about your plans  regarding it- so please don't send me to read sources!)

Say that I have a plugin which takes existing war and somehow mutates it and
produces another war on output.
Will I still use packagingwar/packaging in such case?

I belive that multiple plugins can create artifacts of the same type.
so somehow I feel that either a type tag is also needed in pom or plugins
should inform mave core (via metadata?) what types of artifacts are they
creating.

Also how install and deploy plugins will work when secondary artifacts are
going to be present? 

Michal

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

RE: [M2] filter definition

2005-04-19 Thread Maczka Michal

 -Original Message-
 From: Brett Porter [mailto:[EMAIL PROTECTED]
 Sent: Monday, April 18, 2005 11:06 PM
 To: Maven Developers List
 Subject: Re: [M2] filter definition

 Maczka Michal wrote:

 I a not 100% sure if I understand you.
 What do you mean by deployment process here? Is it going to be
 supported/executed in m2? 

 Yes, what we were talking about covers your use case, you'd 
 just need to
 run your deployment profiles over the artifacts and store 
 them wherever
 is suitable to later retrieve them and distribute them.

 Maybe a layered repository approach would be helpful here, where you
 copy the relevant artifacts to change and build a small repository of
 them that they can use, and for the standard stuff the base repository
 is used.

 Just thinking out loud, but it all fits together with what we 
 were thinking.

I think all this is already supported in m2. For each artifact you can
already choose to which repository it will be deployed
so it is up to users to organize repository systems as they wish :). Only
missing parts are plugins which will mutate artifacts. 
Your assemble plugin is really very good example which shows the way in
which such plugins could be written. I don't think that much more is needed
:)

reagrds

michal

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

RE: [M2] filter definition

2005-04-18 Thread Maczka Michal

 -Original Message-
 From: Brett Porter [mailto:[EMAIL PROTECTED]
 Sent: Monday, April 18, 2005 1:53 AM
 To: Maven Developers List
 Subject: Re: [M2] filter definition

 Jason van Zyl wrote:

 Here's the full URL: http://www.jconfig.org/ConfigurationServer.html

 Cool! I'll take a look and try to integrate it into what I'm making.

 Yeah, I think we are all on the same page now.

almost :) 

 - Build a single archive
 - swizzle J2EE files that need to be changed for deployment, 
 as part of
 the deployment process, not the build process

I a not 100% sure if I understand you.
What do you mean by deployment process here? Is it going to be
supported/executed in m2? 

In a place where I am working we often follow the following scenario: 
There is one person resposible to prepare deployment artifacts.
Some other person is verifing if everything is OK and is transfering those
artifacts to CDs which are later taken to the customer.
Alternativly they are transferd to the customer via ftp/ssh.
Third person is responsible of physical deployment of those artifacts at the
customer site. And this may happen weeks or even months after the artifacts
were prepared (built). It may also happen in the place where there is not a
chance that they will let you use any extra tool (so maven ant and such
tools are excluded).
So as you can see in my case really build process is completly seperated
from deployment process but during the deployment process we are not allowed
to change any artifacts.

As we try to deploy more and more artifacts for each customer to our
artifact repository  - it makes it possible to do some cool things
and for example we are exeprimenting with incremental updates and hoping to
soon have a possibility of transfering 
to the clients just very small archives which contains the files, which have
changed since the last deployment. This is possible as we know what we have
deployed (historical version are stored in the repoitory) and what we have
to deploy.

So from my experince the communication via artifact repositories (e.g. maven
repositories) and the requirment that build process on output must deploy
ready (or almost ready to use) artifacts to repositoriy(ies) realy is a key
and works quite well. This also requires that each artifact must have unique
name - so the rule one project - one artifact has to be followed. So for
example Vincent's solution:

---

project1
  |_ src/resources
|_ env1
  |_ [files or env1]
|_ envN
  |_ [files or envN]
|_ shared
  |_ [files shared by all envs]
  |_ [...]

And then having the logic to choose the resource files based on a
env.name=env1|envN property.
--

is not something which we can use as artifacts for different environments
will replace each other in local/remote repository.

I don't think that my scenario is the only valid one it is one and most
likely some other case (simpler or more complex) may require completely
different solutions (e.g. the one described by Jason and Vincent). But I
don't think that there is too many such cases.  And I am sure there is a lot
of private existing m1 plugins which were never published, which support
those use cases. So it is not like we are exploring new lands - just nothing
was shared and standarized in that domain :).

best regards

Michal

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

Re: [M2] Filter definition

2005-04-17 Thread Michal Maczka

Vincent Massol wrote:
I agree that putting filtering in the POM is a good first approach but
that it won't handle the need for different environments.
This is something that I've been wanted to include in maven for a very long
time: the ability to say build me this project for this environment.
It seems that you're currently moving in the direction of doing this with
the settings.xml file. However I'm concerned that the definition of the
different environments is something that you need to share with your
co-workers so it can't be located in a file that contains machine-dependent
information such as (location of your local repo, etc). In other words parts
of the environment definition should be shared through the SCM and part
shouldn't.
I was going to propose a solution but I've just realized while writing it
that it needs more thinking... :-)
 

 

I personally use two different approaches for customizing environmental 
settings of produced artifacts:
/
/1. Source based approach

I share the same sources between multiple projects.
For example I use the organization of the projects which resembles this one:
- template-project
  src
main
   resources
   conf
  db.conf
  a.xml
- envs
envA (point to resources defined in template-project and adds some 
new resources)
  src
main
resources
conf
   b.xml
filters (this is used for resource filtering)
   some-propertiesA.properties
   some-propertiesB.properties
envB
  ...

project.xml in envA node among others has the following entry:
resources
 resource
filteringtrue/filtering
directory../../template-project/src/main/resources/directory
 /resource
 resource
directorysrc/main/resources/directory
 /resource
/resources
2. binaries based approach
If I need to customize some environment specific settings in existing 
artifacts (binaries) I do the following:
a) unpack them
b) replace some files with new ones
c) sometimes I apply resource filtering
d) create new archive

So for example I unpack existing war archive, replace web.xml file and 
then create another war file.
In this case I can also customize existing 3rd party artifacts.  To my 
surprise this approach works quite fast in practice.

What's nice in case of those both approaches (they can be applied in the 
same project)
then I can always choose for which env. I want to build an artifact (no 
command line switches are needed!)
and I can use continuous integration system for building artifacts for 
each of the defined environments.
So maven key rule - one project one artifact is obeyed.

I hope that this will be helpful  for /accommodating different use case.../
Michal



--
Teraz na tapecie mamy najwiekszego z silaczy. 
Sciagnij  http://link.interia.pl/f1873 

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

Re: [M2] filter definition

2005-04-17 Thread Michal Maczka

Jason van Zyl wrote:
On Sun, 2005-04-17 at 17:20 +0200, Vincent Massol wrote:
 

The way I've been doing it so far is by having:
project1
 |_ src/resources
   |_ env1
 |_ [files or env1]
   |_ envN
 |_ [files or envN]
   |_ shared
 |_ [files shared by all envs]
 |_ [...]
And then having the logic to choose the resource files based on a
env.name=env1|envN property.
See http://www.pivolis.com/pdf/Enterprise_Builds_V1.0.pdf, pages 9 to 11.
However, I have always thought this selection of resource files based on a
deployment environment is something that the build system should help with
(which was not really the case with m1 where you had to implement it in an
ad-hoc fashion). Hence my question for m2: is m2 going to help in this
domain?
   

I have the start of some tools that I've been working on for the current
contract I'm working on and the approach I've been taking is that that
same archive is used across all environments. I package the resources
for each of the environments inside the one archive and use an external
property to signal to the application which set of resources to use. I
think building archives for each environment is not only time consuming
but dangerous. Before I started taking that approach an archive was
taken and deployed to the wrong environment causing great amounts of
wonder. 

Are you just describing generic situation or just simple dev/qa/prod 
situation where environments are almost identical?

I have a real life use case when we deploy the same application to 
approximately 30 banks.
There is only one application and approximately 50-60 environments. 
Differences between those environments are huge:
- different operating system, different databases, different jvm, 
different application servers (ours or j2ee) .
We don't actually use clustering but I imagine that people who deploy 
the same application to multiple cluster nodes in the same location can 
easily have couple dozen of environments more, which they need to 
support. This really requires a scalable solution.
If you will put all that to one archive not only it would be couple of 
megabytes larger but you risk to ship to clients the knowledge which 
should be protected (e.g. digital certificates, harcoded passwords (yes 
it happens :( )).

In a case when you are using j2ee and build-in security mechanism 
(declarative security in  deployment descriptors)
you really need to replace fragments of web.xml, ejb-jar.xml 
application.xml files. If you deploy j2ee applications
(war, ear) to different application server you will also need to add 
application server specific descriptor.

I don't really see how you could activate some settings, which are 
stored in the some archive in such case.
I find it more scalable to have app-node1, app-node2, app-node-N 
artifacts in repository and to have some qa practices in place
which are assuring that right archive (more often archive of archives) 
is shipped to the right customer.
I haven't really had problem which you described nad never an archive 
was sent to the wrong place (and as you can see number of that places is 
quite big).  Archive names which are clearly describing the environment 
name where this archive should be used are really helpful. So the 
conventions like myapp-clientX-nodeY-1.0.war are really priceless.

And don't get me wrong: you approach looks really interesting in certain 
circumstances. I just want to point that there are sometimes far more 
complex but not so unusual situations which would be nice to have 
covered in m2.

michal

--
Wszystko o MOTORYZACJI  http://link.interia.pl/f186a
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven 2 directory structure for Multiple Modules configurable?

2005-04-16 Thread Michal Maczka

Joachim Schreiber wrote:
[...]
Now I read in the Getting Started section of the new Maven 2 documentation
in Subsection Multiple Modules the new plans for creating multiple modules.

I want to ask, is the new directory structure configurable?
+- pom.xml
+- my-app
| +- pom.xml
+- my-webapp
| +- pom.xml
I saw this new structure in Vincent Massol's ppt presentations and examples
and now in Maven 2 (but not in Cargo ;-).
I'm interested because the pitfall with Eclipse is that this kind of
directory structure is not supported.

AFAIK the only limitation which exists in eclipse is that project
directories cannot overlap.
So you should be able to import to eclipse all projects, which contain
java sources and are leaves in the directory tree.
So in you case you can create eclipse projects for my-app and my-webapp

In more complex case
+- pom.xml
+- my-app
| +- pom.xml
+- my-webapp
| +- pom.xml
+- subprojects
+- pom.xml
+-sub1
+- pom.xml
+-sub2
+- pom.xml

you can create eclipse projects for my-app, my-webapp sub1 and sub2.
But there are other tools which may require (or recommend) other directory layout.
For example subversion. I don't know if recommended subversion layout which is already quite frequently used is already supported in m2:

and how to use it with help of modules section in pom.
Is something like this going to be supported:
modules
moduleplugin1/trunk/module
...
modulepluginK/tags/3.2/module
...
modulepluginN/trunk/module
/modules
or users will be forced to use svn:externals in such cases (or
something else)?

Michal

Nie dzwon do Londynu...
zanim nie sprawdzisz HALO.interia.pl
Tutaj: http://link.interia.pl/f1870
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven 2 directory structure for Multiple Modules configurable?

2005-04-16 Thread Michal Maczka

Joachim Schreiber wrote:
From: Michal Maczka [mailto:[EMAIL PROTECTED]
   

 

AFAIK the only limitation which exists in eclipse is that project
directories cannot overlap.
   

Yes
 

So you should be able to import to eclipse all projects, which contain
java sources and are leaves in the directory tree.
So in you case you can create eclipse projects for my-app and my-
webapp
   

Ok I do this and...
eclipse_workspcae
+- my-app
|  +- pom.xml
+- my-webapp
|  +- pom.xml
...I have no root project for my root pom.xml because the root is the
workspace and there is no possibility to check out something from inside
eclipse in the workspace.
Do I misunderstand?
Last time I did two ~ months ago as I am using different ide more often 
so sorry if my memory  is playing tricks:

I used import  feature to import existing projects into the 
workspace.  So afaik you can keep your projects where ever you want
and just virtually add them to any workspace.
I used one of the milestones builds of eclipse 3.1. I don't know if this 
is something new for eclipse 3.1 or if it works also for 3.0


michal

--
Startuj z INTERIA.PL!  http://link.interia.pl/f186c 

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

RE: maven and ivy

2005-04-15 Thread Maczka Michal

 -Original Message-
 From: Brett Porter [mailto:[EMAIL PROTECTED]
 Sent: Friday, April 15, 2005 1:48 AM
 To: Maven Developers List
 Subject: Re: maven and ivy

 Michal Maczka wrote:

  Group Dependencies (aka composite artifacts)  is the feature which
  enables to define a single dependency on multiple artifacts.

  Depenedecny Group is the feature which allows to logically group
  dependencies in poms and for example
  mark some dependencies as optional.

  I do believe that the  first feature is actually very useful and not
  at all against maven's philosophy and it
  can eliminate completly the need of having dependency 
 groups. Simply
  if we take hiberante as example
  hibernate team can publish just one jar and multiple poms - for
  example: hibernate-full.3.0.pom, hibernate-minimal-3.0.pom,
  hibernate-jcs.3.0.pom etc. Those poms will list the 
 dependecies which
  are needed in diffrent cirumstances.
  Of couse jars like hibernate-full.3.0.jar will not exists.

 Michal, I'm confused. You seem to be talking about the latter, not the
 first one.

 I think splitting the pom of an artifact is a very bad idea, 
 especially
 if those jars don't exist.

I also think that splitting the pom of artifact into some group is a bad
idea. But group (composite)
dependencies are about something else. They provide useful shortcut method
for including multiple artifacts in projects
via declaration of just a single dependency.

With help of them  for example I can create a pom which will contain a list
of all known (or preferred) wagon providers. 

model
  modelVersion4.0.0/modelVersion
  artifactIdmy-favourite-wagons/artifactId
  packagingpom/packaging
  version1.0/version

   dependendcies

here will go: http-wagon, scp-wagon, ftp-wagon, etc 

   dependendcies

/model

I can deploy it to the repository as /xx/yy/my-favourite-wagons-1.0.pom

Then if I wanted to include all those wagons in some project I simply could
do something like:

dependency
groupIdxx.yygroupId
artifactIdmy-favourite-wagonsartifactId
typecompositetype  (or simply type = pom)
version1.0/version
dependency

and have all those wagons included in my project

Of course my-favourite-wagons-1.0.jar does not really make sense so it won't
exist.
But really what happens here is an aggregation not splitting.

If I understood this is more or less what happens in ivy and what ivy module
are about. They used example of Spring Framework,
which provides very many jars and it will be usefull to have a possibility
of creating multiple views over that selection.
For example if you were using spring (core), hibernate and tapestry in
multiple projects in your company you could create
a pom which contain appropiate entries, which describe that selection and
import it to any project via declararation of  single composite dependency.

Other useful example: say that you are working with j2ee and you have to add
to your projects: servlatapi, jms, jta, ejb etc.
With help of group dependecies you could create pom like j2ee-1.3.pom,
j2ee-1.4 pom which will include all required jars in appropiate versions.
(forget that they are not in the repository :-/) 

reagrds

Michal

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

RE: maven and ivy

2005-04-15 Thread Maczka Michal

 -Original Message-
 From: Brett Porter [mailto:[EMAIL PROTECTED]
 Sent: Friday, April 15, 2005 9:00 AM
 To: Maven Developers List
 Subject: Re: maven and ivy

 Maczka Michal wrote:

 I also think that splitting the pom of artifact into some 
 group is a bad
 idea. But group (composite)
 dependencies are about something else. They provide useful 
 shortcut method
 for including multiple artifacts in projects
 via declaration of just a single dependency.

 Perhaps you should test things before posting such a lengthy response?

 Depending on typepom/type already works.

Sorry no time for that these days. 
But the main reason why I have sent lengthy response was to explain to ivy
people that 
the feature they are after is already supported by maven2 metadata  (poms)
as it was not well communicated and probably not so obvious
even to early adopters of m2.
I also wanted to explain to you what I meant by group dependencies.

 There are a couple of caveats:
 1) there is a bug where it attempts to include it on the compiler's
 classpath. Will fix. So it only works for runtime in alpha-1

so now I am glad that I haven't tried to test it as I may had false
impressions :)

 2) it might be more useful to pull in the modules instead of the
 dependencies when doing this (e.g. depending on wagon-providers 
 would get
 what you want, rather than creating another aggregating pom). I'll put
 it in JIRA for alpha-3.

I haven't tested how this feature works in this version of maven but I did
test it before and in fact I fell that few more additions are needed to make
it useful. For example the necessity of saying that some dependency should
not be resolved transitively (I know that you are thinking about including
this feature). If you want to to pull in the modules instead of the
dependencies it will also nice to have some control over it (e.g. different
dependency type for that)

Note also that in case of wagon providers there are two competing jars:
http and http-lightweight. 
One of the reasons why group dependencies could be useful is exactly for
giving the possibility of choosing only once which one of them should be
used
by default in your projects if you are using multiple wagons very often.

regards

Michal

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

Re: maven and ivy

2005-04-14 Thread Michal Maczka

Xavier Hanin wrote:
Hi all,
To give a bit more of context on this discussion, the starting point
was brett's blog titled Ivy: do we really need more metadata?:
http://blogs.codehaus.org/people/brett/archives/001023_ivy_do_we_really_need_more_metadata.html

If I still agree that it would be much better to have only one
repository, and one metadata for each project, I'm not sure this is
possible for the moment.

I'd be very happy to use poms in ivy, but for the moment the
philosophy is still too different.

I've gone a bit deeper in maven doc, and what makes a big difference
between maven and ivy dependency management is that in ivy
dependencies are declared on modules (= a project in maven), whereas
in maven, as far as I understand, dependencies are declared on
artifacts. So it's not so easy to share the same metadata with those
two different approaches. Both have their advantages and drawbacks,
I'm not claiming ivy is better, it's simply different. But in our day
to day use in my company, we appreciate the advantage to have to
declare only one dependency to get all the needed spring-framework
jars and dependencies, and only the one required. And this is made
possible with dependencies on module and the configuration directive.
So I personnaly think it justifies to have our own metadata... and
thus to provide ivyrep, unless you open a gate on ibiblio to publish
our ivy files, in which case we would really be glad to use it.
I think that there are two ideas floating around, which have similar
names but are quite different:
group dependencies and dependency groups

Group Dependencies (aka composite artifacts) is the feature which
enables to define a single dependency on multiple artifacts.

Depenedecny Group is the feature which allows to logically group
dependencies in poms and for example
mark some dependencies as optional.

I do believe that the first feature is actually very useful and not at
all against maven's philosophy and it
can eliminate completly the need of having dependency groups. Simply
if we take hiberante as example
hibernate team can publish just one jar and multiple poms - for example:
hibernate-full.3.0.pom, hibernate-minimal-3.0.pom,
hibernate-jcs.3.0.pom etc. Those poms will list the dependecies which
are needed in diffrent cirumstances.
Of couse jars like hibernate-full.3.0.jar will not exists.

It is true that in maven you can only declared dependecies on artifacts.
But those artifacts can be files, which contain metadata which can be
expanded to list of artifacts.
Isn't it something which is already sufficient for ivy?

If I rememebr group dependencies it is something, which was planned
since a long time but I don't know if there are still plans to include
that feature in m2. IMHO ivy can use poms to implement this feature even
if maven won't support this feature.

It can be helpful as we could then define a single dependecy on virtual
artifact like my-web-platform:1.0, which can for example include a web
framwork, tag liblaries, logging liblary, ioc container, zip files with
css and js files and what ever else which is commonly used for
developing web applications inside some company.

Michal

---
Wzmocnij swoja komorke. Najwiekszy z silaczy na tapecie?
Sprawdz: http://link.interia.pl/f1872

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

RE: [M2] Plugins vs Mojo vs Plexus components?

2005-04-13 Thread Maczka Michal

 -Original Message-
 From: Brett Porter [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, April 13, 2005 12:30 AM
 To: Maven Developers List
 Subject: Re: [M2] Plugins vs Mojo vs Plexus components?

 This is really a name confusion. The plexus things being used, for the
 most part, just being used as additional libraries, as is
 maven-archiver. eg plexus-compiler, plexus-archiver. Mojos 
 are goals or
 tasks within a plugin.

 The only time plexus the container comes into it is when you see an
 expression like #component.org.codehaus.modello.ModelloCore. This
 tells Maven to populate the variable with an instance of the given
 component from the container. However, if you are using it outside
 Maven, that's fine - you just need to pass in your own 
 instance of that,
 which can be constructed as a normal bean in most cases and configured
 manually.

 What's probably missing for use outside of Maven is getters 
 and setters :)

 We are currently working on the external Mojo API, so feel 
 free to mail
 any more comments about it.

 Cheers,
 Brett

If I can suggest something it would be nice to move more logic which deals
with mojo configuration from maven to plexus
as at the moment this logic is bit duplicated.

Mojos can be really plexus components with per-lookup lifestyle. 

What you will ideally have in plexus is the lookup method which takes four
parameters: role, role-hint, version and configuration
So you can lookup mojos by their ids and versions and request to inject
given configuration settings into requested components.

So the plexus API can look like follows:

lookup( Mojo.ROLE, compiler, 1.2, myConfiguration );

With exception for versioning it is all already implemented in plexus and
just needs to be exposed.

Other thing which will be nice to have are common services which you can
configure and which are shared by multiple mojos.
For example compile, test, clover mojos they all need to use java
compiler service. 
(If I under how clover works) Clover even needs to use it twice to
instrument/compile java and test sources (and possibly generated sources), 
and needs to invoke test runner (e.g. junit, surefire, testng) which is used
in the project.
So now the question is: how it can be done?
IMO it will be nice (or even necessary) to have a possibility of configuring
some common services (like java compile, testruuner) once and only once.

michal 

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

RE: xml entities and maven 2

2005-04-13 Thread Maczka Michal

 -Original Message-
 From: Brett Porter [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, April 13, 2005 8:53 AM
 To: Maven Developers List
 Subject: Re: xml entities and maven 2

 Jörg Schaible wrote:

 dependencies
  definition id=mx4j
  groupIdmx4j/groupId
  version2.1.1/version
  urlhttp://mx4j.sf.net/url
  /definition
  dependency
  artifactIdmx4j-jmx/artifactId
  ref id=mx4j /
  /dependency
 /dependencies

 I think we'd be more likely to allow something like:
 version${project.getDependency(mx4j).version}/version

 ... though I'm still hesitant to suggest that is a good idea.

 Again, transitive dependencies means most of these won't be specified
 anyway, and the above is going to dramatically complicate, if not make
 impossible future, more advanced, dependency mediation (eg when you
 specify a range of versions). Not to mention being an eye sore (I'm
 referring to both examples :)

BTW: Are there still some plans to support group dependencies in m2?

Michal

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

[jira] Commented: (MNG-271) exported pom.xml should contain full pom information

2005-04-08 Thread Michal Maczka (JIRA)

 [ http://jira.codehaus.org/browse/MNG-271?page=comments#action_31727 ]
 
Michal Maczka commented on MNG-271:
---

I also think that this is a way to go.

Say we have parent project P1 and child project P2.

There are two possible sources of errors here:

a) P2 pom is deployed to repository and P1 pom is missing there (from my 
experience this happens very often).
b) P1 and P2 are both in the snapshot state. P1 and P2 poms are deployed to 
repository, then P1 pom
  is changed (e.g. some dependencies are upgraded) and then re-deployed to the 
repository. 
  After that operation P2 pom in the repository will be also indirectly changed.
  It is questionable if this is a desired thing. Taking into the consideration 
the fact that we have  
multilevel inheritance it can easily lead to the problems which are difficult 
to detect and it can  break builds which would work if expanded poms were 
deployed to the repository.
  

Other reasons why this is a good idea:

- It should be easy to write a tool which reuses m2 repository metadata. 
Project inheritance in m2 is very complex and is mostly irrelevant for such 
tools. So this will help to widespread the acceptance of poms as the artifact 
repository metadata.

- Process of resolving transitive dependencies should be fast. So it would be 
better if less operations for building full poms were needed. This can be 
addressed in m2 in a different way (e.g. local database of POMs can be build) 
but again such thing for efficiency must be reimplemented by any other tools.




 exported pom.xml should contain full pom information
 

  Key: MNG-271
  URL: http://jira.codehaus.org/browse/MNG-271
  Project: m2
 Type: Wish
 Versions: 2.0-alpha-1
 Reporter: Vincent Massol



 When you install a module in the local repo the pom.xml file is copied (it's 
 also included in jars). That's very good. However if my project is a module 
 (i.e it depends on some parent(s)), the pom.xml that is dumped only contains 
 partial information (it does not contain inherited information).
 Thus it can be used standalone and does not offer all the information there 
 is about the module.
 As the pom is fully constructed in memory, it would be nice to dump it from 
 memory instead of copying the pom.xml file.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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

RE: further changes to the new repository layout

2005-04-01 Thread Maczka Michal

 -Original Message-
 From: Brett Porter [mailto:[EMAIL PROTECTED]
 Sent: Friday, April 01, 2005 1:16 PM
 To: Maven 2 Developers List
 Subject: Re: further changes to the new repository layout

 Cool! 
 That's what I was fighting for (specially with trygvis ;)) 
 for couple of
 months.

 Enough of this. Maybe I'm reading this wrong, but this looks 
 to me like
 you are gloating and trying to put Trygve down by singling him out.
 There is no place for that here.

Yes you are reading it very, very wrong. 
Only Trygvis knows how much time and energy we spent together during IRC
sessions unproductively discussing about this particular feature.
That's why I put a smiley addressed to him in the end of the sentence as I
was hoping (knowing Trygve just a bit) that he can also
come to that with the sense of humour and have some laugh about it.

I don't know from where you are coming from but in my culture the
disagreement for somebody else's opinion
regarding 2-3 points in list of thousand points (I don't know how many
decision we had o make for design m2 and other project)
never makes my team-mate or friend a less valuable to  me. 

Michal

RE: Plugin parameters

2005-03-30 Thread Maczka Michal

 -Original Message-
 From: Emmanuel Venisse [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, March 30, 2005 3:07 PM
 To: Maven 2 Developers List
 Subject: Plugin parameters

 Hi,

 Can we change the plugin parameter definition from class 
 comment to field
 comment for obtain a more readable source?

 Actually, we have :
 /**
  ...
  * @parameter name=outputDirectory
  * type=String
  * required=true
  * validator=
  * expression=#project.build.outputDirectory
  * description=
  ...
  */

 Can we replace this by :

 /**
  * Description is here like a javadoc comment
  * @parameter
  * alias=optional name that replace the field name
  * required=true
  * validator=
  * expression==#project.build.outputDirectory
  */
  String outputDirectory=aDefaultValue;

 = the type isn't an attribute of parameter but the type of field

 I'm not sure if it's possible for inherited classes with 
 inherited parameter
 field.

It is possible with qdox (and quite easy) if classes are residing in the
same module.

You make take a look at plexus-cotlet module which does that
It is capable to generate component descriptors and xdoc documentation from
javadoc tags.

There is almost no diff between ordinary plexus component (ODC) and maven
plugin. Only expression attribute does not make sense in case of ODC
(mayeb it can denote context variable?).

It should also be doable to create plugin decsriptors in case of plugins,
which import classes which are used as plugin parameters from other modules.
I made some experiments to implemnet that some times ago and wanted to add
it to plexus-cdc, but it was rejected and
the vison that components should not cross jar boudaries won at that time.
In that case simply some sort of merger, which merges metadata found by qdox
with metadata which exists in xml files in other modules is needed in case
of plexus component. I suppose that in case of maven plugins the situation
is not much different (probably expression attribute may bring some
problems here).
INn such case maulaly edition of plugin descriptor may be a solution.

Note also that in early days of plugin api we tried to use exactly that
stratgy and levarge xstream for populating plugin fields. 
If I am right the samples of markup and how it used to work should still
exist in cvs. Honstly I was always finding that way of feeding plugins with
params to be superior as it makes the code much more readable.

michal

RE: SNAPSHOT design

2005-03-23 Thread Maczka Michal

 -Original Message-
 From: Brett Porter [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, March 23, 2005 1:47 PM
 To: Maven 2 Developers List
 Subject: Re: SNAPSHOT design

 Maczka Michal wrote:

 Is the symetry between local and remote repositories no 
 longer a desgin
 goal?
 Isn't it possible to find a solution, which will enable at 
 any moment in
 time to turn any local repository into a remote repository 
 without any extra
 effort?

 To some extent, they are intentionally different, as the act of
 deployment is the promotion of a successful build up the ladder to
 release, where the local is your own build which is not in any way
 shared with anyone else as the work is not committed. If they 
 were meant
 to be the same, there'd just be a deploy goal - no install.

 As for the actual differences, the reason for not using the same
 snapshot-version file was listed in the document - its 
 timestamp is used
 to check whether to consult the remote repository again. The 
 other more
 important one is to avoid the cost of filling up your disk with
 timestamped snapshots on install, which in turn means 
 building tools to
 clean them out. I used this technique for a while, and I disliked it
 intensely. I'd prefer the same snapshot be overridden.

 This was ofen very useful feature for m1. 

 I can't think of any decent use cases - please elaborate. The 
 only time
 I used it was to use a fresh repo, and add the old one to my 
 remote list
 to pull them across again one by one. But it was more related to
 development on maven rather than any normal use.

I have seen quite often the situtation when one person in the compoany
started to experiment with maven1 and
after some minutes (when internet connection to ibiblio is slow it can ealsy
take 30+ minutes) he has finally populated
his local repository with artifacts which are needed to use maven plugins
and by his project.
Then it was very convient to just share his local repo with other collegues.

But I am not sure if this is that important for snapshot artifcts. 

 The additional files are markup - they don't stop it behaving as it
 should. If you request a SNAPSHOT, it will fall back to the file.

 If I remeber we had workable
 solution for that for m2.

 If you figure it out, let me know.

I think it will be just enough to have also timestamped files in local repo
and after sucessfully delivering newer artifact
to first switch local pointer form old snapshot to new one and then delete
the old artifact for saving diskspace (this could be optional).
This will also remove the issue that old snapshots are currently deleted
before the attempt to fetch the replacement is made.
At the the moment in the case of the sitution when download or validation is
failing you actually would have a missing dependency and can be left in
void. 
This can be also importand when you will want to fetch both primary and
secondary artifacts
during the same transaction and only switch to newer snapshot if all
artifacts were upgraded sucessfully.
I am not sure if this is relevant remark here: prior to the release process
you should have all artifacts and metadata locally and you should not be
required to hit any remote repository. It means for example that if you
would use convert-snapshots function of release plugin no transfer from
remote repo should be required as you will fetch duplicates.

 Why some magic strings, which are concatenating timestamp 
 and build number
 together are used?

 It's convenient to be able to reference it as an entire 
 version string.
 It's not magic - I used a delimiter of - where you used a 
 delimiter of
 \nbuild: .

 Would not it be better to directly use a properties file 
 with for example
 the following (and possibly more) fields:

 timestamp: 20040101.100011
 build: 10
 deployer: brett
 profile: qa

 This is a version tracker that is meant to remain small. The 
 many more
 fields you are alluding to probably all relate to auditing 
 which I don't
 believe should be incorporated in this file as it will 
 require history.
 For now, the username on the server is just as useful as 
 putting it in here.

 Is this solution uniform with another places in maven where 
 pointer files
 are needed 
 (I mean e.g the strategy how the latest released plugin or 
 another artifact
 is going to be discovered)?

 it applies equally to all artifacts - plugins, jars, etc.

This I know.

I asked if this is already aligned with for example the strategy for getting
the latest release (not the snapshot)
If I remember when we introduced the idea of pointer files they were also
covering that use case.

In m2 you need it for example to automatically download missing plugins (the
name of the plugin was guessed from the name of the goal).
I don't know if this feature is still preserved but the version was simply
hardcoded.

Michal

My resignation

2005-02-24 Thread Maczka Michal

Hereby I want to announce my resignation from Maven PMC and the retirement
from the function of Maven Committer (this is including every project
developed under maven umbrella).

I just feel that I am no longer able to be a valuable part of the Maven
team.

There are two things which I recently started and which are not yet
finished:

- upload/download cancellation in wagon (I need it badly for one of my
projects)

- improved site navigation in m1

First thing was not committed to cvs and therefore there should not be any
problem if I will implement it else where outiside the apache.

For the second thing: I leave you the choice how you (it's probably up to
Brett) want to handle it and if you want to continue in that direction.
If you want me to revert this change in SVN just let me know.

Thank you guys for all those things I learnt from you during all those
years!

Michal

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

RE: svn commit: r154533 - in maven/maven-1/plugins/trunk/xdoc: pr oject.properties project.xml src/plugin-resources/site.jsl xdocs/changes. xml xdocs/index.xml xdocs/navigation.xml

 -Original Message-
 From: Arnaud HERITIER [mailto:[EMAIL PROTECTED]
 Sent: Sunday, February 20, 2005 8:29 PM
 To: 'Maven Developers List'
 Subject: RE: svn commit: r154533 - in 
 maven/maven-1/plugins/trunk/xdoc:
 project.properties project.xml src/plugin-resources/site.jsl
 xdocs/changes.xml xdocs/index.xml xdocs/navigation.xml

 2 remarks :

 - spaces between crumbs and separators aren't equals (no 
 spaces between maven and maven plugins) :

 MavenMaven Plugins Maven XDoc Plug-in  About

 Is it normal ?

No. It looks quite bad. 

I am using css style separator
span class=separatorgt;/span to separate entries in breadcrumbs.
I think that style should define the spacing between entries. I can try to
increase and make it look better. 
Other thing which looks very bad are link in left nav menu. They are way too
dense. This is not something, which
I changed but I can try to improve it a bit.

 - I don't like the date and the release in the bottom left.
 Can't we put them anywhere else ?

Sure. Just propose where :)

For sites which I am preparing for my daytime work and I think that also for
maven website the date when site was last published 
is not very important piece of information and I don't think that it must be
very visible as this is something internal
for web site maintainer.

Michal

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

RE: svn commit: r154533 - in maven/maven-1/plugins/trunk/xdoc: pr oject.properties project.xml src/plugin-resources/site.jsl xdocs/changes . xml xdocs/index.xml xdocs/navigation.xml

 -Original Message-
 From: Arnaud HERITIER [mailto:[EMAIL PROTECTED]
 Sent: Monday, February 21, 2005 12:03 PM
 To: Maven Developers List
 Subject: Re: svn commit: r154533 - in 
 maven/maven-1/plugins/trunk/xdoc:
 pr oject.properties project.xml src/plugin-resources/site.jsl
 xdocs/changes. xml xdocs/index.xml xdocs/navigation.xml

   - I don't like the date and the release in the bottom left.
   Can't we put them anywhere else ?

  Sure. Just propose where :)

 It's the problem ;-)

  For sites which I am preparing for my daytime work and I 
 think that also for
  maven website the date when site was last published
  is not very important piece of information and I don't 
 think that it must be
  very visible as this is something internal
  for web site maintainer.

 I agree for the date but we must keep visible the Doc for

One possibility is to incorporate DOC for into breadcrumps e.g::

Maven  Maven Plugins  Maven XDoc Plug-in 1.9-SNAPSHOT  About

But I somehow feel that this is not that good idea.

Michal

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

RE: svn commit: r154533 - in maven/maven-1/plugins/trunk/xdoc: pr oject.properties project.xml src/plugin-resources/site.jsl xdocs/changes . xml xdocs/index.xml xdocs/navigation.xml

 -Original Message-
 From: Brett Porter [mailto:[EMAIL PROTECTED]
 Sent: Monday, February 21, 2005 12:27 PM
 To: Maven Developers List
 Subject: Re: svn commit: r154533 - in 
 maven/maven-1/plugins/trunk/xdoc:
 pr oject.properties project.xml src/plugin-resources/site.jsl
 xdocs/changes . xml xdocs/index.xml xdocs/navigation.xml

 Why not leave it where it was and put the breadcrumbs some where else,
 like at the top of the body?

 eg: http://smh.com.au/articles/2005/02/14/1108229893506.html

I used http://style.tigris.org/nonav/docs/sampler_inst.html as the reference
as this is where our style was born.
Somehow what you are proposing is not matching the spirit of the original
work.
I am not big fan of that layout and look  feel but imo it makes sense to
use it in the way which was previewed by its authors.
But if you have better alternative I definitely won't be against it!

I personally don't find doc for to be that important for the website

E.g. websites for codehaus projects:

http://drools.codehaus.org/
http://picocontainer.codehaus.org/

don't have this piece of information and I don't think that they are any
worst then maven generated sites.
Simply site is living longer then particular version of the the project and
it is not happening often 
that historical versions of sites are available. So people are naturaly
making an assumption
that the site which they are viewing is always for the latest version of the
project.
And the info what's the latest version can be given somewhere on welcome
page (drools provide nice example of that approch)

Note also that for maven we have praticaly the same website since beta
versions.

Michal

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

RE: svn commit: r154533 - in maven/maven-1/plugins/trunk/xdoc: pr oject.properties project.xml src/plugin-resources/site.jsl xdocs/changes . xml xdocs/index.xml xdocs/navigation.xml

 -Original Message-
 From: Vincent Massol [mailto:[EMAIL PROTECTED]
 Sent: Monday, February 21, 2005 2:01 PM
 To: 'Maven Developers List'
 Subject: RE: svn commit: r154533 - in 
 maven/maven-1/plugins/trunk/xdoc:
 pr oject.properties project.xml src/plugin-resources/site.jsl
 xdocs/changes . xml xdocs/index.xml xdocs/navigation.xml

 Hi Michal,

  -Original Message-
  From: Maczka Michal [mailto:[EMAIL PROTECTED]
  Sent: lundi 21 février 2005 12:50
  To: 'Maven Developers List'
  Subject: RE: svn commit: r154533 - in 
 maven/maven-1/plugins/trunk/xdoc: pr
  oject.properties project.xml src/plugin-resources/site.jsl 
 xdocs/changes .
  xml xdocs/index.xml xdocs/navigation.xml

 [snip]

  I personally don't find doc for to be that important for 
 the website

  E.g. websites for codehaus projects:

  http://drools.codehaus.org/
  http://picocontainer.codehaus.org/

 Here are some other web sites:

 http://jakarta.apache.org/cactus
 http://cargo.codehaus.org

 :-)

  don't have this piece of information and I don't think that 
 they are any
  worst then maven generated sites.

 I think they're worse in that regards :-) I personally think 
 that the doc
 for is important. I use it all the time when I view Maven web sites.

It is quite subjective judment :)

For example for standard maven plugins what is important is not a version of
particular plugin as it is really meaningless for end user
but the information with which version of maven this plugin was distributed
or more precisly when it was modified for the last time.

Say I am still using m1 1.0.0 and version 1.0.2 was already released. I have
absolutely no clue what's the version of
each and particular plugin which I am currently using (and I am quite close
to the source ;) ) 
and if the information available at the website is at all relevant for me. 
I really don't care what's the current version of any of those plugins (and
there is too many of them to rememebr any versions) 
- this is something only important for developers not for end users.

For plugins it would make more sense to somehow document changes in time so
user of older versions of maven will be still be 
able to find information relevant for them only if they know which version
of maven they are using.

Other type of situation we have in plexus:

http://cvs.plexus.codehaus.org/plexus/

the web site is kept in separate module and the version which is used for it
has really nothing to do
with any other module - the website has its own lifecycle (much slower the
anything else but this is a different story :) )

Michal

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

RE: svn commit: r154533 - in maven/maven-1/plugins/trunk/xdoc: pr oject.properties project.xml src/plugin-resources/site.jsl xdocs/changes . xml xdocs/index.xml xdocs/navigation.xml

 -Original Message-
 From: Vincent Massol [mailto:[EMAIL PROTECTED]
 Sent: Monday, February 21, 2005 2:50 PM
 To: 'Maven Developers List'
 Subject: RE: svn commit: r154533 - in 
 maven/maven-1/plugins/trunk/xdoc:
 pr oject.properties project.xml src/plugin-resources/site.jsl
 xdocs/changes . xml xdocs/index.xml xdocs/navigation.xml

 Michal, I am not criticizing your work, quite the opposite 
 actually. I think
 the breadcrumb is a very nice thing. I'm just saying that we 
 need to find a
 solution for putting the doc for information in a visible 
 place (as it
 was).

NP. I never felt that you are criticizing me :)

For me this new improved navigation is just much more important feature than
dates, versions etc.

I find it rather unacceptable then when you are viewing maven generated
sites for modules like this one:
http://geronimo.apache.org/modules/jetty/index.html

you have no information about the context in which this module emerged and
you cannot easily navigate to sibling/parent modules.

I am all for including version/date etc in visible place if somebody finds
it useful :)
We just need to find the right place for them...

Michal

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

svn commit: r154533 - in maven/maven-1/plugins/trunk/xdoc: project.properties project.xml src/plugin-resources/site.jsl xdocs/changes.xml xdocs/index.xml xdocs/navigation.xml

2005-02-20 Thread michal

Author: michal
Date: Sun Feb 20 09:30:03 2005
New Revision: 154533

URL: http://svn.apache.org/viewcvs?view=revrev=154533
Log:
Add a support for hierarchical site navigation in breadcrumbs

Modified:
maven/maven-1/plugins/trunk/xdoc/project.properties
maven/maven-1/plugins/trunk/xdoc/project.xml
maven/maven-1/plugins/trunk/xdoc/src/plugin-resources/site.jsl
maven/maven-1/plugins/trunk/xdoc/xdocs/changes.xml
maven/maven-1/plugins/trunk/xdoc/xdocs/index.xml
maven/maven-1/plugins/trunk/xdoc/xdocs/navigation.xml

Modified: maven/maven-1/plugins/trunk/xdoc/project.properties
URL: 
http://svn.apache.org/viewcvs/maven/maven-1/plugins/trunk/xdoc/project.properties?view=diffr1=154532r2=154533
==
--- maven/maven-1/plugins/trunk/xdoc/project.properties (original)
+++ maven/maven-1/plugins/trunk/xdoc/project.properties Sun Feb 20 09:30:03 2005
@@ -21,3 +21,4 @@
 
 maven.jar.override = on
 maven.jar.maven = ${maven.home}/lib/maven.jar
+maven.xdoc.date=bottom

Modified: maven/maven-1/plugins/trunk/xdoc/project.xml
URL: 
http://svn.apache.org/viewcvs/maven/maven-1/plugins/trunk/xdoc/project.xml?view=diffr1=154532r2=154533
==
--- maven/maven-1/plugins/trunk/xdoc/project.xml (original)
+++ maven/maven-1/plugins/trunk/xdoc/project.xml Sun Feb 20 09:30:03 2005
@@ -1,4 +1,4 @@
-?xml version=1.0 encoding=UTF-8?
+?xml version=1.0 encoding=UTF-8?
 !-- 
 /*
  * Copyright 2001-2004 The Apache Software Foundation.
@@ -96,8 +96,7 @@
 developer
   nameMichal Maczka/name
   idmmaczka/id
-  email[EMAIL PROTECTED]/email
-  organizationDimatics/organization
+  email[EMAIL PROTECTED]/email  
   roles
 roleJava Developer/role
   /roles

Modified: maven/maven-1/plugins/trunk/xdoc/src/plugin-resources/site.jsl
URL: 
http://svn.apache.org/viewcvs/maven/maven-1/plugins/trunk/xdoc/src/plugin-resources/site.jsl?view=diffr1=154532r2=154533
==
--- maven/maven-1/plugins/trunk/xdoc/src/plugin-resources/site.jsl (original)
+++ maven/maven-1/plugins/trunk/xdoc/src/plugin-resources/site.jsl Sun Feb 20 
09:30:03 2005
@@ -151,33 +151,43 @@
   /div
 
   div id=breadcrumbs
-maven:property var=version name=maven.xdoc.version 
defaultValue=${pom.currentVersion}/
-j:if test=${date == 'left'}
-  div class=xleft
-Last published: ${build.date}
-j:if test=${!empty(version)}
-  j:if test=${!(maven.xdoc.crumb.separator == '')}
-span class=separator${maven.xdoc.crumb.separator}/span
-  /j:if
-  Doc for ${version}
-/j:if
-  /div
-/j:if
+maven:property var=version name=maven.xdoc.version 
defaultValue=${pom.currentVersion}/
+
+j:set var=breadcrumbsUsed value=/  
+x:if select=$nav/body/breadcrumbs
+  j:set var=breadcrumbsUsed value='true'/  
+/x:if
+  
+div class=xleft
+   j:if test=${empty(breadcrumbsUsed)} 
  
+ j:if test=${date == 'left'} 
+ Last published: ${build.date}
+ j:if test=${!empty(version)}
+   j:if test=${!(maven.xdoc.crumb.separator == '')}
+ span 
class=separator${maven.xdoc.crumb.separator}/span
+   /j:if
+   Doc for ${version}
+ /j:if 
+ /j:if
+   /j:if 
+   j:if test=${!empty( breadcrumbsUsed )}  
+ jsl:applyTemplates select=$nav/body/breadcrumbs /
+ ${pom.name} span class=separatorgt;/span ${docTitle}   
+  /j:if 
+/div
+ 
 div class=xright
-  j:if test=${date == 'right'}
-Last published: ${build.date}
-j:if test=${!empty(version)}
-  j:if test=${!(maven.xdoc.crumb.separator == '')}
-span class=separator${maven.xdoc.crumb.separator}/span
-  /j:if
-  Doc for ${version}
-/j:if
-x:if select=$nav/body/links
-  j:if test=${!(maven.xdoc.crumb.separator == '')}
-span class=separator${maven.xdoc.crumb.separator}/span
-  /j:if
-/x:if
-  /j:if
+  j:if test=${empty(breadcrumbsUsed)}  
+j:if test=${date == 'right'}
+  Last published: ${build.date}
+  j:if test=${!empty(version)}
+j:if test=${!(maven.xdoc.crumb.separator == '')}
+  span class=separator${maven.xdoc.crumb.separator}/span
+/j:if

svn commit: r154534 - in maven/maven-1/plugins/trunk/xdoc: project.properties src/plugin-test/test01/common/links.xml src/plugin-test/test01/xdocs-replacement/test.xml

2005-02-20 Thread michal

Author: michal
Date: Sun Feb 20 09:33:01 2005
New Revision: 154534

URL: http://svn.apache.org/viewcvs?view=revrev=154534
Log:
removed property which was used for testing

Modified:
maven/maven-1/plugins/trunk/xdoc/project.properties
maven/maven-1/plugins/trunk/xdoc/src/plugin-test/test01/common/links.xml

maven/maven-1/plugins/trunk/xdoc/src/plugin-test/test01/xdocs-replacement/test.xml

Modified: maven/maven-1/plugins/trunk/xdoc/project.properties
URL: 
http://svn.apache.org/viewcvs/maven/maven-1/plugins/trunk/xdoc/project.properties?view=diffr1=154533r2=154534
==
--- maven/maven-1/plugins/trunk/xdoc/project.properties (original)
+++ maven/maven-1/plugins/trunk/xdoc/project.properties Sun Feb 20 09:33:01 2005
@@ -21,4 +21,4 @@
 
 maven.jar.override = on
 maven.jar.maven = ${maven.home}/lib/maven.jar
-maven.xdoc.date=bottom
+

Modified: 
maven/maven-1/plugins/trunk/xdoc/src/plugin-test/test01/common/links.xml
URL: 
http://svn.apache.org/viewcvs/maven/maven-1/plugins/trunk/xdoc/src/plugin-test/test01/common/links.xml?view=diffr1=154533r2=154534
==
--- maven/maven-1/plugins/trunk/xdoc/src/plugin-test/test01/common/links.xml 
(original)
+++ maven/maven-1/plugins/trunk/xdoc/src/plugin-test/test01/common/links.xml 
Sun Feb 20 09:33:01 2005
@@ -15,7 +15,7 @@
  * limitations under the License.
  */
  --
-!-- $Id: links.xml,v 1.1 2004/08/25 19:58:20 aheritier Exp $ --
+!-- $Id$ --
 
 !ENTITY _module 'codelt;modulegt;/code'
 !ENTITY module 'a href=descriptor.html#module_module;/a'

Modified: 
maven/maven-1/plugins/trunk/xdoc/src/plugin-test/test01/xdocs-replacement/test.xml
URL: 
http://svn.apache.org/viewcvs/maven/maven-1/plugins/trunk/xdoc/src/plugin-test/test01/xdocs-replacement/test.xml?view=diffr1=154533r2=154534
==
--- 
maven/maven-1/plugins/trunk/xdoc/src/plugin-test/test01/xdocs-replacement/test.xml
 (original)
+++ 
maven/maven-1/plugins/trunk/xdoc/src/plugin-test/test01/xdocs-replacement/test.xml
 Sun Feb 20 09:33:01 2005
@@ -17,7 +17,7 @@
  */
  --
 
-!-- $Id: test.xml,v 1.1 2004/08/25 19:58:20 aheritier Exp $ --
+!-- $Id$ --
 !DOCTYPE document [
!ENTITY % common-links SYSTEM ../common/links.xml
%common-links;



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

Re: svn commit: r154533 - in maven/maven-1/plugins/trunk/xdoc: project.properties project.xml src/plugin-resources/site.jsl xdocs/changes.xml xdocs/index.xml xdocs/navigation.xml

2005-02-20 Thread Michal Maczka

[EMAIL PROTECTED] wrote:
Author: michal
Date: Sun Feb 20 09:30:03 2005
New Revision: 154533
URL: http://svn.apache.org/viewcvs?view=revrev=154533
Log:
Add a support for hierarchical site navigation in breadcrumbs
 


Hey!
I just added support a feature which enables better navigation in within 
large web sites.
Simply breadcrumbs page section is used for displaying current 
location within the larger website.

This is something which is pretty commonly used by many websites (e.g. 
java.net
- see e.g. javacc site: https://javacc.dev.java.net/  and links
Projects https://www.dev.java.net/servlets/ProjectList  javatools 
https://javatools.dev.java.net/  * javacc https://javacc.dev.java.net/*

If everybody is OK with that I can modify navigation.xml file of 
existing maven plugins and activate
it for those plugins.  It requires addition ot the new section called 
breadcrumbs.
e.g:
http://svn.apache.org/viewcvs.cgi/maven/maven-1/plugins/trunk/xdoc/xdocs/navigation.xml?rev=154533view=markup

greets
Michal

--
Sprawdz NOWE parametry hostingu!
http://link.interia.pl/f1857  

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

Re: svn commit: r154533 - in maven/maven-1/plugins/trunk/xdoc: project.properties project.xml src/plugin-resources/site.jsl xdocs/changes.xml xdocs/index.xml xdocs/navigation.xml

2005-02-20 Thread Michal Maczka

Vincent Massol wrote:
Hi Michal,
Do you have an example web page where we could see the live result of
applying breadcrumbs to a project? The navigation.xml example you gave
involves external links and I am not what's the relationship between
breadcrumbs and external links.
Thanks
-Vincent
 

You can create web site for xdoc plugin after updating it from svn:)
(invoke plugin:install then site)
I think that this information can be some how inherited from parent 
projects.
in m2 it should be easy.

Michal
--
Sprawdz NOWE parametry hostingu!
http://link.interia.pl/f1857  

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

Re: svn commit: r154533 - in maven/maven-1/plugins/trunk/xdoc: project.properties project.xml src/plugin-resources/site.jsl xdocs/changes.xml xdocs/index.xml xdocs/navigation.xml

2005-02-20 Thread Michal Maczka

Vincent Massol wrote:
Hi Michal,
Do you have an example web page where we could see the live result of
applying breadcrumbs to a project? 

http://codehaus.org/~michal/docs/
greets
Michal
--
Sprawdz NOWE parametry hostingu!
http://link.interia.pl/f1857  

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

RE: [MAVEN] ${pom.properties} is a ArrayList of String?

2005-02-11 Thread Maczka Michal

 -Original Message-
 From: Nacho G. Mac Dowell [mailto:[EMAIL PROTECTED]
 Sent: Friday, February 11, 2005 1:29 PM
 To: dev@maven.apache.org
 Subject: [MAVEN] ${pom.properties} is a ArrayList of String?

 Hi all, I was trying to use ${pom.properties} and I found it is an 
 ArrayList of Strings in the form property:elementName:...:. I was 
 thinking it might be useful to have them as Nodes. What do you think? 

[..]

 properties

 jaxme-jelly-tag-libraryhttp://jakarta.apache.org/commons/jel
 ly/libs/jaxme/index.html/jaxme-jelly-tag-library
 .
 /properties

 and then access them as: 
 ${project.properties.getChild(jaxme-jelly-tag-library)} or 
 something 
 similar.

 This way we would (easily) avoid the problem that arised when moving 
 from nagoya in apache. Other suggestions are very welcome.

Maybe it is a stupid question:

why don't you use project.properties file for that and do is like this:

jaxme-jelly-tag-library=http://jakarta.apache.org/commons/jelly/libs/jaxme/i
ndex.html

?

 I would also like to draw attention to bug #MPXDOC-131 which gives 
 direct access to velocity in user-documentation when 
 maven.docs.src.templates=true. I know I can use maven.xml for 
 this but I 
 beleive it is easier to use it this way. There are no side-effects 
 (maven.docs.src.templates defaults to false) and quite a few benefits!

 Regards,

 Nacho G. Mac Dowell

 PD: Does anybody know where I can find 
 org.apache.maven.project.Model? 
 It is now in a separate artifact, but what project? Thanks!

http://cvs.apache.org/viewcvs.cgi/maven-components/maven-model/

michal

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

RE: [MAVEN] ${pom.properties} is a ArrayList of String?

2005-02-11 Thread Maczka Michal

 -Original Message-
 From: Nacho G. Mac Dowell [mailto:[EMAIL PROTECTED]
 Sent: Friday, February 11, 2005 2:14 PM
 To: Maven Developers List
 Subject: Re: [MAVEN] ${pom.properties} is a ArrayList of String?

 Maybe it is a stupid question:

 why don't you use project.properties file for that and do is 
 like this:

 jaxme-jelly-tag-library=http://jakarta.apache.org/commons/jel
 ly/libs/jaxme/i
 ndex.html

 ?

 Actually this is what I am doing at the moment. I have:

 link-jaxme-jelly-tag-library=http://jakarta.apache.org/commons
 /jelly/libs/jaxme/index.html

 It is probably a better aproach for this, specially when resource 
 bundles come in. The thing is that I didn't like mixing contents (a 
 link) with maven configuration (project.properties).

 I just thought it would be useful to be able to navigate through the 
 properties (from the pom). I suppose this is for performance 
 reasons. If 
 this is the case it is agood enough reason for me.

The only real difference for maven1 is that project.properties file is not
deploy to the repository.
So project.properties are usually just good enough. 

  http://cvs.apache.org/viewcvs.cgi/maven-components/maven-model/

 I didn't find org.apache.maven.project.Model there... no 
 sources either.

java classes are generated from the model file which you can find in that
project.

 Regards,

 Nacho

michal

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

RE: [vote] Alex Karasulu as a Maven Plugins committer

2005-01-14 Thread Maczka Michal

+1

michal

 -Original Message-
 From: Brett Porter [mailto:[EMAIL PROTECTED]
 Sent: Friday, January 14, 2005 5:52 AM
 To: Maven Developers List
 Subject: [vote] Alex Karasulu as a Maven Plugins committer

 Hi,

 I'd like to propose Alex Karasulu as a committer on the Maven 
 plugins and
 plugins sandbox.

 Alex is an Apache member and a committer on the incubated 
 Apache Directory
 project. In the process of making releases there, he has been 
 suggesting
 improvements and submitting patches for plugins, and is 
 willing to continue this.

 I believe he would be a valuable addition to the team, so 
 from me a +1.

 Regards,
 Brett

 -
 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: Maven Librarian

2005-01-07 Thread Michal Maczka

Vítor Souza wrote:
Hi,
I don't know if this is the right place to post this, if not, 
please excuse me and point me to the right mailing list/forum.

As long as it has something to do with maven - this is the rigth place :)
[...]
As you can see, the app was designed to run here at my company, 
but can be changed to an open-source tool for everyone to use. I'm 
sending this message to see if any of you Maven developers are 
interested in transforming it into an Official Maven tool after I'm 
done with the features above. I would gladly donate it to the Apache 
Software Foundation (it's already developed under the Apache Software 
License anyways).

I think this is unlikly to happen as you are mostly reproducing the work 
which we already did for maven2, partially maven-proxy and continuum 
projects. It will be technically quite difficult to integrate your code 
with what we did.

There are some features of your tool which migth be attractive for 
maven1 users and some ideas which are nice
and planned to be supported in maven-land since a long time but neither 
implemented by you or us.
I think that you will better serve the community  (specially maven 1 
community) ...  trying to compete with us  :)
There is nothing wrong if there is more then one supporting tool built 
on top of maven.

Also, ff any of you would like to contribute to it at this stage 
of development, just join the project at dev.java.net and request a 
role as developer. I'd be glad to have any partners on this.

Hope this is of interest of any of you.
Best regards,
- Vítor Souza

regards
Michal
--
Startuj z INTERIA.PL!!!  http://link.interia.pl/f1837
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven Librarian

2005-01-07 Thread Michal Maczka

Vítor Souza wrote:
Hi Michal,
Good to hear that the recursive dependencies thing is on Maven 
2. It's a very important functionality IMHO.

What I'll do then is continue developing MavenLibrarian internally 
and use it until Maven 2 comes out. When it does, I'll see if there is 
need to continue using MavenLibrarian.

Many people won't be using alpha   beta version of new maven and it 
will stll take months to have a 2.0 release.
Some of the bits from m2 are going to be back ported to m1
but in any case maven1 is not going to diapear from day to day. I bet 
there will be many people which are not going to switch..
Some of your planned features (e.g. repository  searching , sync) will 
be still useful for users of any version of maven.

Michal
--
Startuj z INTERIA.PL!!!  http://link.interia.pl/f1837
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [proposal] Move Maven 1.x from CVS to Subversion

2004-12-06 Thread Maczka Michal



 -Original Message-
 From: Brett Porter [mailto:[EMAIL PROTECTED]
 Sent: Sunday, December 05, 2004 10:55 PM
 To: [EMAIL PROTECTED]
 Subject: [proposal] Move Maven 1.x from CVS to Subversion
 
 
 Hi,
 
 I'd like to start a discussion about this to see what people think.
 
 The reasons:
 - timing is right as we wind down MAVEN-1_0-BRANCH
 - HTTPS makes it more practical behind firewalls
 - the tool support seems to be mostly there now (not perfect, 
 but good enough)
 - is being encouraged ASF wide
 

+1

Michal

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

RE: Problem dynamically excluding some tests

2004-12-03 Thread Maczka Michal

 -Original Message-
 From: Corey Scott [mailto:[EMAIL PROTECTED]
 Sent: Friday, December 03, 2004 8:25 AM
 To: Maven Dev List
 Subject: Problem dynamically excluding some tests

 Currently I am trying to exclude a certain set of tests from running
 on different machines based on their operation system.  Basically I
 have some DB code which has ODBC tests that I don't want to run on my
 Redhat server but I want to run them on my XP desktop.

I would propose you to put such logic into your test classes.
IMO it is better to address this problem globally 
and skip system dependent tests also inside idea/eclipse when you are
Linux or Mac OS user etc.
So no matter if you are using maven, ant, eclipse or whatever else the given
test won't be executed in unsupported environment.

There are even some junit extensions (test runners) which are supporting
three states returned by test methods:
success failure and skipped. In some situation this really makes sense
and test can be also skipped
for many reason e.g - becouse it was commented out.

Michal

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

RE: versioning of maven-model drops

2004-12-01 Thread Maczka Michal

 -Original Message-
 From: Jason van Zyl [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, November 30, 2004 7:11 PM
 To: Maven Developers List
 Subject: Re: versioning of maven-model drops

 On Wed, 2004-12-01 at 00:27, Michal Maczka wrote:
  Brett Porter wrote:

  I am just trying to propose something simpler as I am 
 afraid that there 
  will be way too many converters and parsers.

 The whole point in trying to stabilize the v4 POM is so that 
 there will
 not be a proliferation of parsers and converters. For the v4.x there
 will only ever be additions. Period. If we much something up 
 then we can
 replace the bad elements with something better but leave the mistakes
 and deprecate them over years. That being the case there won't be any
 converters because it will all be additions. And because we 
 will only be
 dealing with additions any subsequent versions of the generate model
 tools will know how to deal with past versions. Moving from 
 v3 - v4 is
 the only real chore we have to deal with. 

 It will be simple because we're only going to do additions. And we can
 only do additions to the model as it's the only way we're 
 going to have
 long-term stability.

That's exactly what I was saying in that thread :)

So to respond to yor initial question:

What we are doing now is generating the most current version of the
model is generated without versioning in the package name, so it's
something like:

org.apache.maven.model.*

But we can optionally have versioning in the package name:

org.apache.maven.model.v301.*

We have used the versionless variant in the maven-core so that we don't
have the wrangle version names when we upgrade the model which I like
but if we are going to make separate utility drops should we release
them with versioning in the package name? This would be for general use
like the fellow wants to do on the user list.

As we all agree that v4 model is not going to change radically (in case it
will we can have v5 in the far away future)

We can use using something like:

org.apache.maven.model.v3
org.apache.maven.model.v4

as we won't ever need to have to flip packages names to

org.apache.maven.model.v401
org.apache.maven.model.v402
etc

when model will be envolving. The latest parser which we will deliver will
support all possible mutation of v4 model.

So I'm thinking we can always generate releases with versioning in the
package name and generate the versionless package name for our use in
maven-core. I guess that brings up the question of how to name the
artifacts but that's the general notions. Once we figure this out I
would like to cut a release of maven-model and let folks try it out.

Thoughts?

Most of the m2 plugins will not be using model directly.
But some will. 

It will be nice if m2 and other tools were using exactly the same liblary
(jar) and package names.
So somebody can for example take some particular m2 mojo which uses m2 model
and m2 model and execute it without a help
of m2 runtime and m2-core jars.

I suppose that dual packaging of the same classes will be confusing and we
should avoid it.

The only exception here should be made in case of m1 where both core and
some plugins expects model v3 in certain package.

Still tools like continum can use the parser which uses
org.apache.maven.model.v3 for keeping model.

So really the only difficulty which we will ever need to deal with is the
differnces between version v3 and v4.

Michal

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

RE: New navigation

 -Original Message-
 From: Dion Gillard [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, November 30, 2004 5:20 AM
 To: Maven Developers List
 Subject: Re: New navigation

 Taxonomy as a name doesn't gel with the web site concepts.

 'Parent'/'Child'?

I thought about it but it kind of conflicts with terminology used to
describe project inheritance and might be bit confusing.
Other problem with that is that I want to diplay more elements then just two

For example:

Maven  Plugins  Maven Plugins  Maven Site Plugin

and this is linked with classification (categorization) of projects and
that's why I used the word taxonomy.
But I am sure there must be a better word for it :)

Michal

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

RE: versioning of maven-model drops

 -Original Message-
 From: Trygve Laugstøl [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, November 30, 2004 9:40 AM
 To: Maven Developers List
 Subject: Re: versioning of maven-model drops

[...]
  So I'm thinking we can always generate releases with 
 versioning in the
  package name and generate the versionless package name for 
 our use in
  maven-core. I guess that brings up the question of how to name the
  artifacts but that's the general notions. Once we figure this out I
  would like to cut a release of maven-model and let folks try it out.

  Thoughts?

 +1 for releasing it.

 So the SNAPSHOT version will be without versioned packages and the
 released version will be with versions?

I don't think that this is linked with snapshots.
Snapshot word in version is used for underlining the work in progress but
once the release is made it should be (almost) identical
to the last snapshot.

--general comment--
I think that we are making this whole thing more complicated then it needs
to be.

There are probably two issues related to numbering of pom versions:

At the moment we have two major versions of POMs: 3 and 4.
Those versions are incompatible. 

Then within major version we have (can have) minor versions like 4.0.0,
4.0.1 etc.

The changes introduced by minor version should be no breaking - it means
that we can possibly 
add new tags or deprecate tags but all existing tags should be supported.

Which means that in m2 which currently supports pom v4.0 we can simply put
POM model into o.a.m.model.v4.*
as this is not going to change anytime soon.

The latest parser for each major version of POM should be able to parse all
sub-versions of that version (4.0.0. 4.0.1, 4.0.2)
Note that POM is quite stable and the changes are going to be quite rare.
This is not something which is going to change every week.

We should just not officialy release final version of POM v4.0.0 until we
are happy with all use cases which we want address in m2
(until we will reaach beta version).

Everybody willing to be an early adopter of m2 when it is still in alpha
stage should be prepered that things might not be stable
and API and POM can change. And I think it is quite acceptable.

I would also propose to re-think our numbering of POM versions and use the
following:

v3 -  maven 1.0.X
v4 -  maven 1.1.X   
v5 -  maven 2.0.X

For m1 we indeed need to generate model to o.a.m.project.* package.
The same model and parser for it can be generated to o.a.m.model.v3 and used
in m2, continuum etc.

Michal

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

RE: versioning of maven-model drops

 -Original Message-
 From: Brett Porter [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, November 30, 2004 2:10 PM
 To: Maven Developers List
 Subject: Re: versioning of maven-model drops

[...]

 This will still work - you should be able to drop in 
 maven-model-4.0.1 
 and it still works with code that expected 4.
 Converters, which care more about any version differences, 
 will need to 
 access v400 and v401.

That's why I think it is more complicated then it needs to be.

The first question is what kind of converters do you imagine here?
Do you imagine that we will have converters between v400 and v401?.
And for example between v400 and v405? How such converters will be
implemented?
Will we have converters between all version pairs possible? Chained
converters (v400-v401-v402--...-v405)?

I am not keen at all about having such converters as both scenarios are
quite complex.
I hope that once we are ready with pom v4 it will be almost never radically
changed. Fundamental changes will go to v500 and m3 :)
And as v405 will  be backward compatible with v400 and we won't really need
a converter between them - just a parser which supports
both v400 and v405 in the same time.

Next question is what we can really do with converters between major
versions of POMs: e.g. between v3 and v4
and where and how such converter will be used?

POMs v3 is fundamentaly different the POMv4 and conversion between those two
versions can be partially automated but some information 
e.g. releated to inheriatnce, plugin configuration, preGoal, postGoals used
in the project
is not really easy to transform. It will be easier if we had a tool which
will help to do this outside of m2 but I doubt that
m2 will be able to directly support all v3 POMs and perform the required
conversion is reliable way at the runtime.

Do I miss something about converters or I misunderstood them completely?

 We should just not officialy release final version of POM 
 v4.0.0 until we
 are happy with all use cases which we want address in m2
 (until we will reaach beta version).

 This is exactly the plan.

 I would also propose to re-think our numbering of POM 
 versions and use the
 following:

 v3 -  maven 1.0.X
 v4 -  maven 1.1.X   
 v5 -  maven 2.0.X

 I currently intend:
 v3.1.0 - Maven 1.1: non breaking additions.

Haven't we been planning to use new way of declaring project inheritance in
1.1 with help of groupId and artifactId versions tags (like in m)?

Michal

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

RE: Possible meeting of the minds in Europe

 I think sometime in January or early February would be better as it
 gives us time to prepare. I'm totally cool with Paris. If you 
 folks over

It is all fine for me. Early Febrarur is also the best date for me!


Michal

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

Re: versioning of maven-model drops

2004-11-30 Thread Michal Maczka

Brett Porter wrote:
[...]
It's been decided writing small converters (and if the changes are 
compatible, they should be trivial to write) is better than trying to 
get the model to do some form of inheritence. 

Minor versions might introduce deprecations on elements, for example - 
which makes the model different.

Is there any reason where this is actually going to cause you a problem?
I am just trying to propose something simpler as I am afraid that there 
will be way too many converters and parsers.

It could be that I don't get correctly what is the responsibility of 
converter in that solution.

Say that the latest  POM version supported by m2 is v402 - how many 
packages with different model versions and how many converters we will 
need to distribute to support v400, v401?

I imagined that there will be always one parser in m2 for all possible 
released pom v4 variants and it will hide all the complexivity
related to changes in POM structure. Exactly like it used to be for m1 
where for example we had dual support
for id  and groupId/artifactId' tags in dependency.
So if we will have something like maven2-model-v4-1.0.2.jar - it will 
contain the only parser which users/developers want to use
to parse all known variants of pom v4. Once we will have pom v403 we 
will release maven2-model-v4-1.0.3.jar
which support all previous versions and this new version. Isn't it 
simple enough?

Michal

--
Nudzisz sie? Zagraj sobie!  http://link.interia.pl/f183d
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning of maven-model drops

2004-11-30 Thread Michal Maczka

Brett Porter wrote:

Next question is what we can really do with converters between major
versions of POMs: e.g. between v3 and v4
and where and how such converter will be used?
 

I believe Trygvis has already implemented one for continuum. Correct, 
it is only partially automated, but it can warn on ignored info, fail 
on missing info.
It can easily handle the different names in scm and connection, for 
example.

As far I know Trygvis' tool converts poms in the repository.
The biggest problem here is not that pom structure is different but that 
in case of m1 poms were splitted into 3 files
(project.xml, project.properties, maven.xml)
And we will just have one of them (project.xml) in the repository.

Michal
--
Ponad 400 tysiecy facetow czeka na Ciebie 
http://link.interia.pl/f183a

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

RE: one more time: [sitemultiproject plugins] - reorganization o f goals used to generate sites

2004-11-29 Thread Maczka Michal

 -Original Message-
 From: Brett Porter [mailto:[EMAIL PROTECTED]
 Sent: Sunday, November 28, 2004 9:07 PM
 To: Maven Developers List
 Subject: Re: one more time: [sitemultiproject plugins] - 
 reorganization
 of goals used to generate sites

 Michal Maczka wrote:

  Sometime I ago I have proposed some changes in site  multiproject 
  plugins.
  I could not apply them at that time as we were releasing  
 1.0.1 version.
  Somebody has any objections against those changes (they are 
 described 
  below)?

 Actually, there was still some confusion about whether this was 
 necessary. I'd like to avoid needing to override goals. See below:

[...]
 Then you can do
 maven.multiproject.site.goal=site
 or
 maven.multiproject.site.goal=multiproject:site

 depending on the context.

I feel that both your and mine solutions are hacks.
First one requires to override goals, second binds two plugins: site and
multiproject.
Before proposing my solution - which I hope will be the temporary one - I
thought about both options
and I have chosen the one which was subjectively less harmful.

 As a more general case, perhaps we should have:
 maven.multiproject.type=multiproject

I am already using it and for example multiproject:install goal works pretty
fine.

 and flip that to multiproject:site automatically. This will also make 
 multiproject:install, etc recurse properly. WDYT?

I actually think that once we will make it properly multiproject plugin
won't be needed anymore.
You will do something like:

maven install
maven site
maven idea

and those goals will render different results in the context of normal
project and multiproject project.
That's why I am not in favour of putting the new functionality into
multiproject plugin. I'd prefer to have it decentralized.
And imo it is better to ask users to put the functionality and behaviour
which is not yet standardized into scripts
then to ask them to use plugins which are simply bad as this usually serves
as an example of a contract between plugins and will be spread.

As the comment to discussion between Vincent and Jason regarding aggregation
of reports (whish is loosly connected to that)
I will also add that it will be interesting to see also transitive
(multilevel) aggregation of results.

Michal

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

New navigation

2004-11-29 Thread Maczka Michal

Howdy!

As I described before in one of my previous emails I would like to improve
the usability of maven generated websites and add the possibility of adding
links to parent modules. 

The example of such functionality can be found here
http://style.tigris.org/nonav/docs/sampler_tigris.html 
(I mean those links like Foo  Bar  Baz  Bat )


When somebody will start viewing the website at page like that
http://geronimo.apache.org/modules/jetty/index.html  
it won't be a dead end for him anymore! 
He will be able to click on link which will take you one or two levels up in
the hierarchy of pages and from there navigate to sibling modules.


At the movement  the best solution which I found is to

a) move information which currently is put in breadcrumbs section (I mean
something like  Last published: 29 November 2004 11:54 CET | Doc for
1.0.1-SNAPSHOT ) 
to the page footer (left side of it)
  
b) add new tags to navigation.xml:



project 
titleyyy/title
body 
  taxonomy
 item name=Maven href=http://maven.apache.org/

 item name=Plugins
href=http://maven.apache.org/plugins/index.html/
  taxonomy

links
item name=Apache href=http://www.apache.org/
/links

menu name=Overview
item name=Overview href=/index.html/
/menu

/body
/project


Somebody has a good idea how to name this new tag. I used the name
taxonomy at the moment but I am not convinced that this is a best name.

Anybody is against this change or have a better idea how to implement such
functionality?
If not I can try to implement it in next few days...

It would be even nicer if taxonomy tree can be deducted from location of
given module in the source tree (I think it  will be possible with unified
source tree)


Michal


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

one more time: [sitemultiproject plugins] - reorganization of goals used to generate sites

2004-11-28 Thread Michal Maczka

Sometime I ago I have proposed some changes in site  multiproject plugins.
I could not apply them at that time as we were releasing  1.0.1 version.
Somebody has any objections against those changes (they are described 
below)?

Michal
Hi!
Recently I've trying to generate multilevel sites using multiproject plugin
and I have problems with  that approach
due to some strange relationships between goals in multiproject and site
plugins
What I am trying to do exactly is to run site:generate goal if project is
a leaf in a project tree or multiprojct:site in other case.
( I am using maven.xml file for controlling that
  goal name=site
   attainGoal name=multiproject:site/
/goal
)
I would like change both multiproject and site plugin to make it possible
- In site plugin:
I would like to attain site:generate goal from site goal - not other way
around
- in multiproject plugin at the end of the code of the goal 

 goal name=multiproject:site
 /goal
I would like to attain site:generate goal - not site goal. 

I wonder if 

a) it will be still possible to include those changes in 1.0.1 release?
b) am I missing something and this will brake something or will not work? I
tested it locally and it seems to be working for me...
regards
Michal
 

--
Startuj z INTERIA.PL!!!  http://link.interia.pl/f1837
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Adding a comment to dependencies

2004-11-26 Thread Maczka Michal

 -Original Message-
 From: Felipe Leme [mailto:[EMAIL PROTECTED]
 Sent: Friday, November 26, 2004 10:35 AM
 To: Maven Developers List
 Subject: Re: Adding a comment to dependencies

 On Fri, 2004-11-26 at 03:22, Michal Maczka wrote:
  I don't think that XML comments are sufficient here.

 I agree.

  First of all I'd like to see those comments propagated to 
 documenatation 
  (website, pdf etc) sometimes they are quite important...

 That's right. Take a look in the Display Taglib as an example:

 http://displaytag.sourceforge.net/dependencies.html

I actually think that this is not a best example why we need that new tag as
once we have categorization of dependencies (scope like thing) 
and transitive dependecies waht you see there will be mostly covered.

But I see that there is often need to document why the dependecy was used.

For example if you are using asm you can be informed that (dependecy report
can contain that information)

ASM is a Java bytecode manipulation framework. It can be used to
dynamically generate stub classes or other proxy classes, directly in binary
form, or to dynamically modify classes at load time, i.e., just before they
are loaded into the Java Virtual Machine.

This is helpful as you will know what asm is. 
But the information that asm is used in this project for implementing
dynamic proxies is also very important and could
be quite precious. Not only for documentation purpose in the scope of
particular project but also for exchaning information between projects and
higher 
level tools.
Once we have reliable database of poms it will be possible to select all
project which use asm and see that

project A uses it for 'implementing dynamic proxies
project B uses it for ''

so exchaning of knowledge between projects can be bi-directional (I hope
that it is clear what I mean by that)

Other type of informationion I imagine to see in that new tag is something
like 
commentWe deliberately use version 1.0.0. Do not upgrade to version 1.0.1
as it is not compatible/comment

Such information is of high importance and it should be displayed by the
tools which will help you to maintain your POMs 
(e.g. upgrade version of dependecies) or perform releases...

Michal

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

RE: Adding a comment to dependencies

2004-11-25 Thread Maczka Michal

 -Original Message-
 From: Patrick Moore [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, November 24, 2004 11:05 PM
 To: Maven Developers List
 Subject: Re: Adding a comment to dependencies

 I like this Idea. A related need is commenting what services the 
 dependencies provide. What does 'jaxen', 'jdom', etc. provide to the 
 codebase? it would be good if there was a standard method by which 
 dependencies could describe themselves. So in addition to the jar, 
 licenses, and pom information maven would pull down a brief purpose 
 'description' file. Or did I miss something?

Yes - you missed the fact that this already exists :)

Try to put thme POM for any of the dependencies which you are using in any
of your current project
to your local repository and dependecy report will use content provided
inside the description tag of that POM
This already works.

But there are two distinct things:

a) what given project does (this should be documented in project's own POM)
b) why it it was used (this should be documented in the pom of the project
which uses given artifacts)

Say that you have choose to use jdom in your project.
DOM and SAX apis are built-in into java and probably you have choosen to use
jdom for some good reasons.
Those reasons can be technical or non technical (e.g. you like it better
then DOM). Specially in the the first
case it will be  nice to document those reasons.

Michal

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

RE: Adding a comment to dependencies

2004-11-25 Thread Maczka Michal

 -Original Message-
 From: Maczka Michal [mailto:[EMAIL PROTECTED]
 Sent: Thursday, November 25, 2004 9:24 AM
 To: 'Maven Developers List'
 Subject: RE: Adding a comment to dependencies

 Try to put thme POM for any of the dependencies which you are 
 using in any
 of your current project
 to your local repository and dependecy report will use 
 content provided
 inside the description tag of that POM
 This already works.

Upps sorry - it seems that this functinality was removed sometimes ago ...
it should be easy to revert it...

Michal

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

Re: Adding a comment to dependencies

2004-11-25 Thread Michal Maczka

Brett Porter wrote:
That said, there will be the ability to make changes for 1.1, so we 
should decide whether it is really needed.

You can use a property now to get this happening - I have no problem 
with that.

I don't believe a comment element under a dependency is really 
necessary. The use cases I see are:
- describe why this project has such a dependency
- describe what the dependency is

The first can be done with an inline XML comment, and I don't see the 
value of automatically including it on the site.
The second will be solved properly by transitive dependencies, where 
you read the description/ of the dependency's project.

So I don't see the need to add the element myself, and also there are 
the reasons against making dependency different to the project that 
I've listed earlier (or in another thread recently, I'm not sure).

I don't think that XML comments are sufficient here.
First of all I'd like to see those comments propagated to documenatation 
(website, pdf etc) sometimes they are quite important...
But there are purely technical reasons against XML comments.
We are trying to make POM independent from XML representation - it can 
be kept for example in the database.
We will have tools which will operate on POMs and change some values in 
them and serialize them back to XML files.
This will be a case for example for a tool which will help to make releases.
Ideally after all those operations any information kept in POM which is 
not changed should be left untouched.
To make it possible we should stay away from any xml-ish stuff 
(comments, entities etc)

regards
Michal
--
Nudzisz sie? Zagraj sobie!  http://link.interia.pl/f183d
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: maven site work

2004-11-24 Thread Maczka Michal

 -Original Message-
 From: Jason Van Zyl [mailto:[EMAIL PROTECTED]
 Sent: Monday, November 22, 2004 10:46 PM
 To: [EMAIL PROTECTED]
 Subject: Re: maven site work

 Howdy,

 Awesome! The content can definitely be fleshed out as you progress and
 hopefully people contribute.

 The only comment I have is that there is far too much in the left
 navigation. For example I might take the Getting Started item and
 make that a top-level menu item and then deal with the act of getting
 started on a separate page. I would probably do that with each of the
 main menu items you have there to lighten up the front-end navigation.
 But as far as the actual items in the menu I think that's stuff is
 great.

I agree with this comments but .. I also agree with Brett's intention.

One thing which might be helpful is imo better starting page which will
display more links.

I also have some other idea regarding usability of maven generated sites:

I think it would be nice to use breadcrumbs section of webpages in bit
different (I dare to say) more standard way.
One thing which particularly sucks in maven site itself (this also applies
to most maven generated sites) is that if you are viewing 
sites of subproject (like plugins) that you cannot easily come back to
parent project.

So for example if somebody is viewing the site for maven-site plugin we
would see in his breadcrumbs bar the following content

maven  plugins  site plugin

(maven  plugins are both links)

You can see this pattern in action at www.tigris.org  or java.net (e.g. here
http://style.tigris.org/nonav/docs/sampler_inst.html)

I just started to investigate the possibility of implementing such
functionality for maven 1.

Before I will go further with it (like often I have the idea but not much
time for it) I would like to know
if this is something which other people will find valuable or maybe even
somebody will have a better idea how this aspect
of usability can be improved?

Also hints regarding possible implementation are much appreciated!

Michal

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

Re: Adding a comment to dependencies

2004-11-24 Thread Michal Maczka

Miguel Griffa wrote:
Hi
   At my company we are asking to add a comment to dependencies, this
comment  is supossed to aid kowing why is that dep there. I'm trying
add a column to the dependencies report in the xdoc plugin. My
questions are:
1. How to I access the dep property from the velocity template
context? (There seems to be no way to access the properties even from
Dependency at maven)
 

As far as I rember you may look at ear plugin for inspiration.
2. Is this funcionallity of interest to the group to contribute it? 
 

I personally would rather like to see it such tag directly added as 
child of dependency tag.
I also find it to be very useful. Once it will be there we can  modify  
the dependencies report.
At the time being probably your strategy is the only one which may work...

Michal
--
Startuj z INTERIA.PL!!!  http://link.interia.pl/f1837
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [PROPOSAL] Ading a new tag to dependency?

 -Original Message-
 From: Corey Scott [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, November 23, 2004 5:11 AM
 To: Maven Developers List
 Subject: Re: [PROPOSAL] Ading a new tag to dependency?

 While we are on the subject of adding tags to dependancy has a scope
 tag been considered? 

Yes it is still considered and will be addressed soon.
The final form of that functinality is not yet decided and the version
similar to which you have shown
is still a serious contender...

Other options include among others type tag whch will merge two concern:
what you use as type now and the what you want to use as scope.

I am personally more supportive for the first option as imo it will be
overall simpler.

Michal

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

RE: [PROPOSAL] Ading a new tag to dependency?

 -Original Message-
 From: Stephen Nesbitt [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, November 23, 2004 1:14 AM
 To: [EMAIL PROTECTED]
 Cc: Vincent Massol
 Subject: Re: [PROPOSAL] Ading a new tag to dependency?

 On Sunday 21 November 2004 02:14, Vincent Massol wrote:
  Hi Maven devs,

  I think there's a need to allow specifying when some artifacts
  are only to be looked for in the local repository. For example,
  in a multiproject the local repository is used to share private
  artifacts between the subprojects. These private artifacts are
  not meant to be uploaded to a Maven remote repo.

[..]

 I noticed that Jörg Schaible's post kinda made the same point with 
 the suggestion of a repository tag in the dependency element.

 Hows does any of this fit intoin situ artifacts?

In situ artifact won't be that helpful in that case if it comes to speed of
processing.

Other m2 feature might be helpful - you can define a repositories per
project basis.
IT means that each pom can contain the location from which corresponding jar
should be taken
and you just need to push your poms to right repositoriy(ies)

In m2 we have limited the number of repositories into which you can deploy
artifact to 1.
That's is probaably something which  we may can revisit in case it will be
really needed
as I also see a need of having distinct repositories for snapshots artifacts
and released artifacts.
We can probably search for solution here. But first we have to be ready with
more fundental things
as the processing model in m2 is bit different mainly due to introduction of
transitive dependencies and it might be that
we will find different bottlnecks and while we will be searching for the
solution which will remove them also this problem will be gone.

But such use cases like yours are definitly helpful for us as definitly
large teams of devlopers are using maven differently
then we do internally among maven devlopers.

Michal

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

RE: [PROPOSAL] Ading a new tag to dependency?

 -Original Message-
 From: Jörg Schaible [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, November 23, 2004 3:49 PM
 To: Maven Developers List
 Subject: RE: [PROPOSAL] Ading a new tag to dependency?

 Maczka Michal wrote on Tuesday, November 23, 2004 12:00 PM:

  -Original Message-
  From: Stephen Nesbitt
 [snip]

  I noticed that Jörg Schaible's post kinda made the same point with
  the suggestion of a repository tag in the dependency element.

  Hows does any of this fit intoin situ artifacts?

  In situ artifact won't be that helpful in that case if it
  comes to speed of processing.

  Other m2 feature might be helpful - you can define a
  repositories per project basis. IT means that each pom can
  contain the location from which corresponding jar should be
  taken and you just need to push your poms to right repositoriy(ies)

 How does this help if your project relies on OSS and 
 proprietary artifacts? How can I configure Maven to look for 
 the proprietary artifacts (SNAPSHOT or not) only in the local 
 repo? 

The simplest solution which you can use now would be to use exclusivly the
local intranet repo which 
must be be initially seeded in some way (e.g sychronized with ibiblio once
per day/week)
This should already make in some case the processing much faster  as you
will be never hitting ibiblio directly.
So general idea is - you should possibly use single repository which is
close to you and very fast.
How this idea should be implemented it is a different story. Maven Proxy and
such tools might be helpful.
I bet it is even implementable in case of teams are geographically
dispersed. In such case 
artifact repositories might be servers which are somehow activly
synchronizing the content among them.
But I believe that this is not releated to particular maven projects or poms
- it is global configuration of maven and the question
of organizing the repository system properly.

Michal

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

RE: [PROPOSAL] Ading a new tag to dependency?