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

[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] Created: (MNG-691) Ability to assign a report to choosen navigation menu

[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

[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

[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


 (typical "naked" pom)
 A
  ...
 





 B
 ...
 
   
 foo
 1.1
   
   
 




   
 C

  ...
 
   
 foo
 1.2
   
 





  D
  ...
  
 
 A  
   
 
 B  
   
 
 C  
   

 


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):


  D
  ...
  
 
 A  
   
 
 C  
   
 
 D  
   
   
 



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:



 A
 ...
 
   
 foo
 1.3
   
   
 


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 and don't use transtive 
dependenies at all.


If the change like the last one (to pom A) will be done after projet D 
was relased suddenly
diffrent dependecy from the one which was used during the release will 
be imposed on all users

of D (if they are using transitive dependencies).
Devloper of "D" obiously cannot predict such change or what's worst he 
may be unaware of it

as long as he is not going to purge his local repository.

And it is not only the issue with conflict resolution. You may add 
second, somehow

incompatible xml parser etc in some projects.

[...]

>
>
> My advice: If you're unhappy with the state of the m2 repository, then
> by all means show us where the problem areas are.


Here you are: For me the problem w

Re: POM issues in the repository

[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>
 4.0.0
 axis
 axis
 1.2



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

[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: [result] demote plugins

[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: [m2] How to add an artifact dynamically to the CP?

[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: [vote] demote plugins

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

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

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

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

[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


  
   runtime  (will be included in the war)




  
   runtime  (will be included in the war)
   compile  




  
 
   compile  (will not be included in the war)




   
   test  (will not be included in the war)


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]

Re: [M2] filter definition

[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: [M2] Filter definition

[Michal Maczka]

Vincent Massol wrote:
I agree that putting  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:

 
true
../../template-project/src/main/resources
 
 
src/main/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: Maven 2 directory structure for Multiple Modules configurable?

[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 2 directory structure for Multiple Modules configurable?

[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:

maven-plugins/
 |_ plugin1/
   |_ trunk/ 
   |_ branches/
   |_ tags/
 |_ pluginN/
   |_ trunk/ 
   |_ branches/
   |_ tags/

and how to use it with help of  section in pom.
Is something like this going to be supported:

   plugin1/trunk
   ...
   pluginK/tags/3.2
   ...
   pluginN/trunk

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 and ivy

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

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

[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: 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

[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: 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

[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

[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=rev&rev=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  > javatools 
 > * javacc *

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=154533&view=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: Maven Librarian

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

[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: versioning of maven-model drops

[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: versioning of maven-model drops

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

one more time: [site&multiproject plugins] - reorganization of goals used to generate sites

[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
  
   

)
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 

 
 
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

[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  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  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: Adding a comment to dependencies

[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  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 ?

[Michal Maczka]

Stephen Nesbitt wrote:
should be visited.
   

I am not sure that this is fine grained enough. I can imagine a use 
case in which a developer has dependecies on jar A & jar B both 
having the same groupId with a repository tied to say QA snapshots. 
For whatever reason the developer decides that he wants Jar A from 
the bleeding edge repository while leaving Jar B from the QA 
repository (maybe confirming a fix to a QA issue?) In any case 
having the repository assigned to the groupID won't meet this case.

I'm not sure just how much of an edge case this is, but I do think 
it is important to have some sort of answer (even if it is a manual 
process of updating your local repo directly)

 

I am sure that it can be addressed in some way.
For example you can write your own plugin which will deploy some 
artifacts to QA repository
or do somthing which is needed to match coorporate standards.
I would't be expecting that maven will be out of the box supporting all 
possible artifact flows
in every company.

One thing which will be particulary good in m2 is that it is componetizied.
We are not sure what we will be willing to expose to end users but there 
are componets like
ArtifactDeployer, ArtifactInstaller, ArtifactDowloader etc and m2 will 
come with "default" implementation.
of that componets which define our strategy for communicating with 
repositories.
In case of highly no standart needs I imagine that implementation of 
that components can be extended or replaced
to match those unusal needs. It will be probably very, very rare case - 
but still it will be possible to do so.

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 ?

[Michal Maczka]

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.
Currently, Maven tries to download them every time and the timeout (about 3
seconds for me) is a pain and is not normal. 

The main problem which we have here is not snapshot semantic per se but 
the fact that ibiblio is currently too slow
to handle it.

Sometime ago I proposed something different but the reasoning behind it 
was the same: we can have dedicated repositories for snapshot artifacts.
IMO snapshot artifact should not go repositories to ibiblio ( 
"milestone", timestamped version  builds can)

With m2 per project basis you are allowed to add repositories which 
should be visited while artifacts are downloaded.
It will be nice to have a possibility of  adding repositories where 
maven should search for the latest version of snapshot artifacts
(by default this list might be empty).  The situation when snapshot 
artifact is missing in the local repository still can be handled in a 
normal way.

This + unified source directory and in situ processing with reactor 
which Jason mentioned previously might be helpful.

Michal
--
Ponad 400 tysiecy facetow szuka przyjaciolki, a moze czegos wiecej... 
http://link.interia.pl/f183b

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

Re: Is maven.final.name deprecated?

[Michal Maczka]

 

I'm asking because I don't want to fix this bug leaving some plugins
inconsistent. For instance, maven-war sets:
maven.war.final.name = ${pom.artifactId}.war
   

Why on earth does that not have the version in it?
 

This is something which has a very long history.
I change in many months ago but it was reverted back to use 
${pom.artifactId}.war
simply becouse some people just want to take war produced by maven in 
target directory
and use it without any changes - as for some servlet containers the name 
of the war  = the name of the context root.

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

RE: More details required on new upload procedure

[Michal Maczka]

> For each version, I agree. But also for each artifact generated by the
> project, no?
> 
> Imagine the aspectj jars. There are 2: aspectjrt.jar and
> aspectjtools.jar. We need 2 POMs, one for each, right?

Definitely. Simply in maven-land those are two projects so we need two poms.

Michal



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

RE: More details required on new upload procedure

[Michal Maczka]

> > 
> > We need one POM per each version of the project but for upload process
> > it is sane to required a presence of the pom everytime even if it is
> > already in the repository.
> 
> Are you sure? That's not exactly what's on ibiblio. In several places,
> there is one POM per artifact, which I think is right.
> 
> In any case, it needs better explanation in the FAQ section I think.
> 

Not sure if I understand you. What I am saying is that if you have

maven-jar-plugin-1.1.jar 
maven-jar-plugin-1.2.jar 
maven-artifact-plugin-1.1.jar

You need 3 poms (so 2 poms are needed for maven-jar-plugin) 
You need to have a pom for each combinataion of a triple 
(artifactId, groupId, version)


Michal



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

Re: More details required on new upload procedure

[Michal Maczka]

On Sun, 2004-06-13 at 14:57, Vincent Massol wrote:
> Hi,
> 
> I'm in the process of uploading the abbot jars on ibiblio. With the new
> procedure I also need to upload some POM (please note that the abbot
> build does not use maven). I've read
> http://maven.apache.org/repository-upload.html but I still have a few
> questions:
> 
> 1/ Should there be a POM file per artifact? That sounds strange to me as
> a POM is related to a project rather than an artifact but I've looked at
> ibiblio/maven and it seems that's what's done in some cases (like
> aspectj). I'd like confirmation.
> 

We need one POM per each version of the project but for upload process
it is sane to required a presence of the pom everytime even if it is
already in the repository.


> 2/ What is the minimal information the POM should contain. If it only
> contains  element + //, is it ok? Don't
> tell me it requires a full POM! That would be as bad as lengthy as
> mavenizing each project...
> 

I think this is minimal. But more is better.  For example dependency
report is already able to point you to the web site of given dependency
if url tag is present. License section can be used for determining 
valid license of your project (e.g. if you have been infected by GPL
viral license)


> 3/ What name should the pom file(s) have? -.pom?

yes. 

> If the project is not yet versioned, should SNAPSHOT be used?
> 

Michal






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

Re: [VOTE] release various plugins

[Michal Maczka]

On Sun, 2004-06-13 at 06:43, Brett Porter wrote:
> As mentioned, can we formalize the release of:
> 
> clean, cruisecontrol, idea, javadoc,
> jcoverage, pmd, scm, test, xdoc
> 
> to their next incarnation from CVS? Changes are in respective changes.xml files.
> 
> +1 from me
> 
> - Brett
> 
+1

Michal



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

Re: [VOTE] remove old releases from www.apache.org

[Michal Maczka]

Brett Porter wrote:
Old releases are archived at archive.apache.org. I propose we rely on these, and
remove everything before RC1 from www.apache.org.
 

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

Re: standard name for license file

[Michal Maczka]

Jason van Zyl wrote:

Hi,

Did we ever decide on a standard name for the license file? I'm already
catching a couple variations in the upload bundles so if we haven't
decided already can we pick a file name as I would like to convert it
to:
-.license 

When uploading into ibiblio.

 

I like the idea .. but what about projects whith multiple licenses?

Michal

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

Re: [VOTE] Carlos Sanchez as maven-plugins developers

[Michal Maczka]

Vincent Massol wrote:

Hi,

Following my post on the subject of "Is it possible to accept a new
committer for a specific plugin?", I'd like to propose Carlos as a
maven-plugins committer. Carlos has provided an excellent patch (it's
actually a full rewrite) for the AspectJ plugin. I suggest that we let
him improve and maintain the AspectJ plugin himself! :-)
+1 from me

Thanks
-Vincent
 

And +1 from me

Michal

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

Re: cvs commit: maven-components/maven-core/src/main/java/org/apache/maven/plugin/descriptor GoalDescriptor.java

[Michal Maczka]

[EMAIL PROTECTED] wrote:

jvanzyl 2004/04/01 16:13:07

 Modified:maven-core/src/main/java/org/apache/maven/plugin/descriptor
   GoalDescriptor.java
 Log:
 o does the goal require dependency resolution in order to execute, by
   default we will assume yes. But for things like "clean" we don't.
 
 Revision  ChangesPath
 1.4   +3 -1  maven-components/maven-core/src/main/java/org/apache/maven/plugin/descriptor/GoalDescriptor.java
 
 Index: GoalDescriptor.java
 ===
 RCS file: /home/cvs/maven-components/maven-core/src/main/java/org/apache/maven/plugin/descriptor/GoalDescriptor.java,v
 retrieving revision 1.3
 retrieving revision 1.4
 diff -u -r1.3 -r1.4
 --- GoalDescriptor.java	21 Mar 2004 00:33:17 -	1.3
 +++ GoalDescriptor.java	2 Apr 2004 00:13:07 -	1.4
 @@ -37,6 +37,8 @@
  
  private MethodDescriptor method;
  
 +private boolean requiresDependencyResolution = true;
 +
  public String getName()
  {
  return name;
 
 

I think that this is already very cool improvement over what we have in 1.0.

I am just thinking out loud here: maybe we can go even one step further 
and leave the dependency resolution up to plugins?
I mean that plugin should process an execution of goal as long as all 
required dependecies for the goal which is processed are present.

if we have a pom like:


 
 ...
jar
 
 
 ...
plugin
 

there are two special cases here:

- probably java:compile goal should be executable even if plugin which 
is defined as dependency is missing (it can be plugin which contains 
just an extra report)
- dependency resolution mechanism should be already invoked and attempt 
to install plugin defined in this POM made. Probably the fact that 
plugin cannot be installed should not break the build as long as all 
required goals are available.

I can imagine more examples of that kind where all required artifacts 
for given goal are present and this goal can be executed, while other goal


 
 ...
jar
 
 
 ...
web-compoents
 

java:compile should succed.
war:war should failed
but I am not yet convinced myself if such use- cases should be accepted 
or now.

Michal

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

RE: cvs commit: maven-plugins/announcement plugin.properties

[Michal Maczka]

> You're right that the docs suck and this would be one way to try and
> enforce it. If there are no public properties then that would have to be
> explicitly stated too.
>

I am all for not only explicitly stating public properties(+1) but also for

a) stating public goals
b) expressing constrains of properties
(I have "dumb" GUIs in my mind, which can try to help to customize plugin).

IMHO all those things are somehow linked together and can be most likely
solved in a common way.
Having in mind that we are aiming at having not only jelly plugins (Java
rocks :)),
we can think ahead and try to find a common way of describing the
functionality exported by the given plugin.
Maybe some 'smart' XML file stating plugin "exports" could be a solution
(exports = goals + properties).
This file can be probably auto-generated from jelly script or java code.


[off topic]
Other think we can think of is to enforce that goal
( an example)  war:war is implemented in war plugin (string before colon
determines the plugin name)
It's not that simple as goals can be overridden in maven.xml etc.
It is important for make things like:

maven help -Dplugin=war (displays goals exported by war plugin)

possible

but first of all it's required for better scalability
and for simplifying lazy loading of plugins and possibly downloading them on
demand
(war plugin was requested via invocation of war:war  goal, and if it's not
installed - we can try to fetch it).


Michal



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

RE: cvs commit: maven-components/maven-model/src/test/org/apache/maven/model DependencyTest.java

[Michal Maczka]

> -Original Message-
> From: Ben Walding [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 05, 2004 1:44 PM
> To: Maven Developers List
> Subject: Re: cvs commit:
> maven-components/maven-model/src/test/org/apache/maven/model
> DependencyTest.java
>
>
> Jason van Zyl wrote:
>
> >On Sun, 2004-01-04 at 16:57, [EMAIL PROTECTED] wrote:
> >
> >
> >>brett   2004/01/04 13:57:53
> >>
> >>  Modified:maven-model/src/test/org/apache/maven/model
> >>DependencyTest.java
> >>  Log:
> >>  improve testing, remove stuff "to simple to fail"
> >>  add ASL
> >>
> >>
> >
> >What does "too simple to fail" mean? If you're refering to
> >getters/setters then please put them back. It contributes to coverage
> >and getters/setters are certainly subject to accidental typos.
> >
> >It's just hard to tell from the cvs log but it looked like
> getters/setters
> >to me.
> >
> >
> >
> I don't necessarily agree that getters and setters should be tested
> explicitly.  If you are exercising your beans properly, the getters and
> setters should be getting hit by other methods. If they are not getting
> hit, and you have good coverage across the board, then that tends to
> indicate that you might not need those attributes any more.
>
>
> Just another perspective...
>
>
My 2 cents :
Test coverage tools like clover show what was not tested but they are not
really showing that something was tested.
No tool can do this.
Even if some code has 100% test cov. it doesn't mean that it is tested or
bug free.  But surely probability of "stupid" error is going down.

So I subscribe to Jason's opinion here: it's better to test everything
explicitly and tests are never harmful and nothing is "too simple to fail".


Michal







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

RE: Installed POMS not interpolated

[Michal Maczka]

> -Original Message-
> From: Michael A Melia [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 05, 2004 10:39 PM
> To: Maven Developers List
> Subject: Re: Installed POMS not interpolated
>
>
> Hi Jason,
> I checked on irc a few times but was unable to catch up with you. I am
> very keen to implement transitive dependencies - there is way too much
> duplication in my poms right now and they are looking very messy.
> I understand that you are probably busy with 1.0 right now but if
> you have
> already thought of an approach to implement this functionality
> then please
> share your thoughts  with me and I will happily put the code in place. I
> would make a start myself but I don't want to conflict with any plans
> already in place.
> This is a top priority for me right now so if you could spare 5
> minutes to
> jot down a few notes I would really appreciate it.
>
> Thanks in advance,
> Mike
>

Some bits of ___highly___ experimental code are located here:
http://cvs.apache.org/viewcvs.cgi/maven-components/maven-artifact/src/main/j
ava/org/apache/maven/artifact/collector/


There is one principal difficulty related to transitive dependencies:
version clashes.
There is plethora of strategies which can be applied to resolve this problem
(one of them is (almost) implemented),
but non of them can be possibly fully reliable (I have automated process in
my mind) without a mechanism for determining compatible/replaceable
versions.

IMHO it would be nice to have two step process:
a) building the graph of dependencies spaned from given project (it's not a
tree, it's a graph!!)
b) have plugable strategy (in addition to GUI:) ) for resolving conflicts.


Michal











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

RE: Archive format for automated upload requests

[Michal Maczka]

> -Original Message-
> From: Jörg Schaible [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 02, 2003 1:43 PM
> To: Maven Developers List
> Subject: RE: Archive format for automated upload requests
>
>
> Hi Jason,
>
> Jason van Zyl wrote on Tuesday, December 02, 2003 12:42 PM:
> > On Mon, 2003-12-01 at 22:52, Jason van Zyl wrote:
> > As a start how about:
> >
> > - project.xml: which can be renamed with the info in the POM itself
> > - license file: do we have a standard name for this?
> > - artifact to be uploaded
> >
> > Anything else?
>
> How do you handle packages with native extensions as available
> with SWT or JAI ?
>
I have written some highly experimental code which partially handles this:
http://cvs.apache.org/viewcvs.cgi/maven-components/maven-artifact/src/test/j
ava/org/apache/maven/artifact/layout/DefaultRepositoryLayoutTest.java?rev=HE
AD&content-type=text/vnd.viewcvs-markup

http://cvs.apache.org/viewcvs.cgi/maven-components/maven-artifact/src/main/c
onf/

Michal



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

RE: Archive format for automated upload requests

[Michal Maczka]

> As a start how about:
>
> - project.xml: which can be renamed with the info in the POM itself
> - license file: do we have a standard name for this?
> - artifact to be uploaded
>
> Anything else?
>
> A simple zip/jar file would do as items can be easily extracted.
>
I think it is almost enough.
For any artifact we need to know it's artifactId, groupId (which are both in
POM) and the type.
So probably we need to do something with "type".
POM v4 has addressed this issues, but we have made the right decision to
postpone any changes in POM.


Michal




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

RE: patch for hibernate plugin : add delimiter property

[Michal Maczka]

> -Original Message-
> From: Konstantin Shaposhnikov [mailto:[EMAIL PROTECTED]
> Sent: Sunday, November 30, 2003 11:16 AM
> To: Maven Developers List
> Subject: Re: patch for hibernate plugin : add delimiter property
>
>
> Hello,
>
> I've just update my CVS sources and it seems to me that you
> have applied only part of my patch (project.properties,
> project.xml and plugin.jelly files), but there were no
> changes to the sources (SchemaExportBean.java and
> SchemaExportTag.java files). Should I create JIRA issue for
> that?

That's the best way
>
> As for xdoc/changes.xml file, what developer should I
> specify in the action tag (dev attribute)?
>
Those documents will be updated by the developer which will apply you patch.


Michal




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

RE: [VOTE] Make groupId mandatory for POM version 4?

[Michal Maczka]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 20, 2003 4:14 PM
[...]

>
> I think we need to talk about my comments above on letting users
> access v4
> features in a v3 POM.
>
> I think we should talk about timing. I don't think introducing a new POM
> version in a RC to release cycle is wise.
>

+10!!! ( I cannot agree more)
I also think all those changes are badly needed but it is a mistake to
introduce them right now at this particular moment in time.
And another branch is the last thing we need right now IMHO. We have already
enough mess with two existing branches.
BTW: Why we need new branch?
Why simply don't have two folders like: maven, maven-experimental.
if we need a place for code which will be not used in 1.0, and maybe will be
used in 1.1 or 2.0 or whatever will come next we can use maven-experimental.
Vincent's code related to POM 4 can go there.



Michal



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

Re: [VOTE] Make groupId mandatory for POM version 4?

[Michal Maczka]

Vincent Massol wrote:

Hi,

I'd like to make  a mandatory element in POM version 4. What do
you think? The reason is that I don't what the default can be if it's
not specified and if we want to have plugins that start using the
id/groupId/type elements, there must be a groupId defined.
Here's my +1

Thanks
-Vincent
 

You mean:
 for the project: +1
 for  the dependecy: +1
And  for both should be now only deprecated and removed in future (+1)?

Michal



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

Re: [VOTE] Adding type element in POM

[Michal Maczka]

Erdfelt,

Also, if there is open discussion about changes to the pom, are there
plans to address any of the requests for project.xml changes in the
jira?  (i have a personal interest in MAVEN-954, and would like to 
see more meta-data in the  elements.  In a corporate
environment, phone number, department, etc.. are terribly useful.)

 

Why don't you link your Project Team Report with intranet pages of your 
corporation?


  jsmith
  John Smith
  http://intranet_server/people/JohnSmith

You can even write your own Project Team Report which will automatically 
generate link to intranet page using devloper's name or id.

Michal

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

Re: [VOTE] Adding type element in POM

[Michal Maczka]

Joakim Erdfelt wrote:

Michal Maczka wrote:

Other thinng I was thinking of  is to introduce   element

javadocUrl will point to URL when project's javadocs are accessible.  
This can be used for liniking project's javadocs with javadocs of 
other projects
(http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/javadoc.html#link)


I've been toying with a "intra-maven" concept for a while now (in an 
effort to understand the maven internals better).

If we leave the  in the dependency, we could make all maven 
generated sites auto-link to each other.

We can make it without  tag.

For example it is just enough to put download URL of  javamail to 
http://www.ibblio.org/maven/javamail/poms/javamail-1.1.pom
and every project can profit from this.

Anyway - I am _not_  proposing that we should drop  tag.

What I was hoping to do:
* Auto-identify mavenized projects in the dependency report.
Maveized = Those which (can) have POM in your local repository or even 
some kind of  POM database.
Not those which are using Maven as their build system.

* Auto-link javadoc from other mavenized projects.
That's why I want to have standard javadoc tag in POM.

* Auto-determine deep dependency links.
   MyProject -> Struts -> Commons-Beanutils (for example)
* On compile, auto-notify of new upgrades to dependencies?
It's all planned since a long time.

Michal

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

Re: Other POM modifcations (was RE: [VOTE] Adding type element in POM)

[Michal Maczka]

Vincent Massol wrote:

 

-Original Message-
From: Michal Maczka [mailto:[EMAIL PROTECTED]
Sent: 13 November 2003 10:44
To: Maven Developers List
Subject: Re: [VOTE] Adding type element in POM
   

[snip]

 

When any changes to POM will be introduced should we increment it to
4?
   

+1. The pom:validate should use this information to validate the POM and
we should have the different XSD version files distributed with Maven.
 

I have few more prosition for things which can be added to POM.

I personally think that  tag inside  element is not so
much needed (as it can be found  in  POM  database)
but very freqently I need  to document  "why  I need this artifact" or
"why this particular version is used" etc.
  
 forehead
 forehead
 1.0
 jar
 We want to replace forehead with classworlds
   
   

What do you want to do with ? Put it in the dependency report?

 

Yes. IMHO This will make project documentation more complete. I




Of course  is not hurting and can stay.

One more proposition (I think Jason was thinking about it)

What about renaming
 element to  so we have perfect match
   

between
 

POM and  Dependency
( pom.groupId = dep.groupId, pom.artifactId = dep.artifactId,
   

pom.type
 

= dep.type, pom.version=dep.version)
   

+1 but we should deprecate  and not remove it right
away.
 

Sure!!

Other thinng I was thinking of  is to introduce   element

javadocUrl will point to URL when project's javadocs are accessible.
This can be used for liniking project's javadocs with javadocs of
   

other
 

projects

   

(http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/javadoc.html#link)

How is this different from all other Maven reports. They are all in
well-defined places, including the javadoc one, no? For Javadoc, for any
project, it is:
${pom.siteAddress}/apidocs/index.html

 

URL of javadocs is "fixed" only for projects which were built with Maven.
POM is an universal project descriptor and can be used without maven - 
you can create and publish (via repository) a POM for any project -
even for such projects which do not use maven (e.g. xerces, ant, xalan, 
struts ).

Michal



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

Re: [VOTE] Adding type element in POM

[Michal Maczka]

Vincent Massol wrote:

Ok, after the discussion on the thread titled "[Proposal] Project
deliverables definition in POM", it seems we agree on adding a 
element in the POM for now. As not everyone has answered, I'd like to
propose a vote for this. If it passes, I can implement it quickly.
Here's my +1 

 

+ 1.

I Just have a question :)

We are using:
3
When any changes to POM will be introduced should we increment it to
4?
I have few more prosition for things which can be added to POM.

I personally think that  tag inside  element is not so 
much needed (as it can be found  in  POM  database)
but very freqently I need  to document  "why  I need this artifact" or 
"why this particular version is used" etc.

  
 forehead
 forehead
 1.0
 jar
 We want to replace forehead with classworlds
   
Of course  is not hurting and can stay.

One more proposition (I think Jason was thinking about it)

What about renaming
 element to  so we have perfect match between 
POM and  Dependency
( pom.groupId = dep.groupId, pom.artifactId = dep.artifactId,  pom.type 
= dep.type, pom.version=dep.version)

Other thinng I was thinking of  is to introduce   element

javadocUrl will point to URL when project's javadocs are accessible.  
This can be used for liniking project's javadocs with javadocs of other 
projects
(http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/javadoc.html#link)



Michal





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

RE: [Proposal] Project deliverables definition in POM

[Michal Maczka]

> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 12, 2003 12:28 PM
> To: 'Maven Developers List'
> Subject: RE: [Proposal] Project deliverables definition in POM
>
>
> I would be -1 to change the standard naming of
> -..
>

The problem is that there is no standard naming convention yet which deals
with artifacts like:

> > -.jar
> > -src-.zip
> > -javadoc-.zip


The standard convention is that every artifacts is describable by POM's
dependency element.
It means that we have four attributes to our disposition {groupId,
artifactId, version, type}
and artifact location in the repository  (layout)  is a simple function of
those four attributes (with exception to artifacts of type "ejb")

This is purely technical limitation of our implementation.

For me the most natural way will be to have possibility to assign a function
which computes the layout per each artifact type separately.

so you can e.g. specify that  layout of "javadoc"
is=${groupId}//javadocs/${artifactId}-javadoc-${version}.jar



> Could you explain why you think it doesn't belong to the POM?
>
> If it's not put in the POM (i.e. if we use properties), who will be the
> owner of them? driver.properties (i.e the core)? Or some other plugins
> (a deliverable plugin, the release plugin, etc)?
>

In other thread I also asked about this (Re: cvs commit:
maven-plugins/multichanges/src/plugin-resources releases.jsl):
"The fundamental question is: shall we use properties which belong
to no plugin and what kind of problems they can cause?"


POM can be also seen as conglomerate of project.xml + and properties files.
As we have methods like project.getProperties()

So it's like we have first class (standardized) and second class properties
(not standardized).
In fact ownership of properties is needed purely for setting default values.

At the moment I don't have a good answer to the question "who will be the
owner of them?"
I think that probably plugins should.

Michal



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

RE: [Proposal] Project deliverables definition in POM

[Michal Maczka]

> Assuming a 1 to 1 relationship with groupId and artifactId would
> be harmful for many projects. (including mine. ;-)
>

I didn't mean that artifactId=groupId  :)

I meant that the same artifactId and groupId are shared between two or more
artifacts.
Just their types are different.

For example:

(groupId:artifactId:type)
foo:baa:jar
foo:baa:pom
foo:baa:javadoc




Michal








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

RE: [Proposal] Project deliverables definition in POM

[Michal Maczka]

> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 11, 2003 6:50 PM
> To: 'Maven Developers List'
> Subject: RE: [Proposal] Project deliverables definition in POM
>
>
>
>
> > -Original Message-
> > From: Michal Maczka [mailto:[EMAIL PROTECTED]
> > Sent: 11 November 2003 14:21
> > To: Maven Developers List
> > Subject: Re: [Proposal] Project deliverables definition in POM
> >
> > Vincent Massol wrote:

> >
> > Why type is not sufficient?
>
> Adding a type would be a good first step. But a project does not have a
> single deliverable.
>

Sorry but  I don't understand:
Aren't artifactId and groupId always the same for all deliverables ?
(please forget about the fact that maven artifact resolving mechanism cannot
handle this )

Michal



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

Re: [Proposal] Project deliverables definition in POM

[Michal Maczka]

Vincent Massol wrote:

Hi,

Shouldn't we define project deliverables in the POM? I think this could
be very useful. Let me give some potential usages:
- ability to automatically say "build me this project", whether the
project generates a war, an ejb, an ear, a jar, a plugin jar, etc. ATM,
there is no way to recognize a project's type.
- ability to develop maven plugins that uses deliverable information.
For example the maven site plugin could automatically generate download
links pointing to the project's deliverables. The multichanges plugin
could provide links for the latest releases, etc.
Here's how it could be defined in the POM:

Example for a plugin project:
-

 
   ${pom.artifactId}
   plugin
 

Note 1:  is already defined at the global level and this is
fine.
Note 2:  should be removed. Indeed, it is not enough as there are
possibly several deliverables per project (for example a typical jar
project will deliver: a jar, a zipped javadoc, a source distribution, a
website zip, etc.
Note 3: We would of course only deprecate the  tag to preserve
compatibility. It would be equivalent to saying:

 
   ${pom.artifactId}
   jar
 

Example for a standard jar project:
---

 
   ${pom.artifactId}
   jar
 
 
   ${pom.artifactId}
   javadoc
 

 

Why type is not sufficient?

etc.

Summary: I believe the existing mechanism (i.e. global ,  -
BTW, there is no global ) is too limitative and that it is
preventing us from providing further added value for projects. The
proposal above suggest a mechanism for extending it to support several
deliverables.
Comments? (I'm sure there'll be plenty ;-)).

 

Some times ago I was thinking about doing this via plugin.

Say we have "foo" plugin (no nice name is coming to my minds at the moment)

with goals

foo:install
foo:install-snapshot
foo:deploy
foo:deploy-snapshot
foo:all-install
foo:all-install-snapshot
foo:all-deploy
foo:all-deploy-snapshot
and then properties like

maven.foo.main=jar
maven.foo.all=jar, javadoc,  javasources,


For example Implementation of foo:all-install can look like

foreach type in  {maven.foo.all} do
  
end
Then this plugin can be used by multiproject  plugin (in 
multiproject:install, multiproject:deploy etc) andfor creation of pages 
with download information

I knew some reason why such functionality should not be based on 
informaton which is kept in POM ()
(I have to refresh my memory and recall them...)



Michal





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

Re: [changes] New goal for release report!

[Michal Maczka]

For 1/, yes, there is already the multiproject plugin and the reactor.
Are we saying we want to deprecate the reactor and promote using the
multiproject plugin. Isn't that a bit too "heavy". Unless the
multiproject offers additional features of course (I have to admit I
haven't looked too far in its plugin.jelly).
 

It is not like multiproject makes usage of reactor deprecated.
It's like it trys to centralize the information about "subprojects" and 
uniform reactor based builds

"Multi" plugins are quite fresh  and  even if you will try to do 
something on your own
without looking at multiproject plugin can have some benefits - maybe 
you will find better patterns the we did ;)
But it will be nice to merge some code in the end.

Michal

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

Re: cvs commit: maven-plugins/multichanges/src/plugin-resources releases.jsl

[Michal Maczka]

Vincent Massol wrote:

dIon,

I don't quite agree. Each of these plugins are separate. Sharing the
same properties ties them together. I would agree, provided the
multiproject plugin provides some useful infrastructure for all plugins
dealing with several projects. In which case the other plugins would
"extend" it and it would make sense to share properties. Tying them
together just to share some properties does not seem enough to me to
justify the tie.
Ideas?

 

I agree with dIon here.

We have alredy have a set of properties which are shared among plugins 
and even such properties which don't belong
to any plugin (like ${maven.build.dest}}.

I see that  you are not happy about the fact that multiproject plugin is 
in some way  favourized.

Then we can imagine to have( as for this just compilcates things for end 
user):

maven.reactor.basedir=${basedir}
maven.reactor.includes=*/project.xml
maven.reactor.excludes=**/target/**/project.xml,project.xml
maven.reactor.ignoreFailures=false
(and then default setting per plugin)

maven.multiproject.basedir=${maven.reactor.basedir}
maven.multiproject.includes=${maven.reactor.includes}
maven.multiproject.excludes=${maven.reactor.excludes}
maven.multiproject.ignoreFailures={maven.reactor.ignoreFailures}
maven.multichanges.basedir=${maven.reactor.basedir}
maven.multichanges.includes=${maven.reactor.includes}
maven.multichanges.excludes=${maven.reactor.excludes}
maven.multichanges.ignoreFailures=${maven.reactor.ignoreFailures}

So no plugin is favourized. 

The fundamental question here is: shall we use properties which belong 
to no plugin and what technical problems it can cause.
If this should be recommended or forbbiden pratice.

I personally have noting against using  properties of multiproject 
plugin in other plugins.

[completly off topic]We can even imagine to have plugins of the 
multiproject plugin:
so multiproject is a plugin which runs reactor in favour of its plugins 
and those plugins can be e.g plugged into maven reporting API.
Plugins of multiproject need not even be plugins in maven sense. They 
can be scripts or java classes
In case of reactor-powered plugins this can speed up many things in 
significant way.



Michal

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

Re: is project inheritance transitive ?

[Michal Maczka]

If it's not transititve, is there any workaround to
reach the same effect?
 

Project inheritance is not transitive at the moment and I am afraid there is no workaround for this problem.
AFAIK Brett is preparing some changes in Maven Core. Could be that he will address this issue
(which was alredy solved some time ago in CVS branch of Maven). 

Michal



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

RE: "deploy" and "artifact" plugins

[Michal Maczka]

> -Original Message-
> From: Dominik Roblek [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 28, 2003 3:58 PM
> To: [EMAIL PROTECTED]
> Subject: "deploy" and "artifact" plugins
>
>
> I'm pretty confused when looking at "artifact" and
> "deploy" plugins. It seems to me, that they offer very
> similar functionality.

Deploy plugin is assumed to be "stable", while the code Artifact plugin is
still experimental phase

I am currently working on new framwork which will be used in maven artifact
plugin.
When code is well tested it will most likely completly replace deploy
plugin.

Michal



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

RE: RE: non-core plugins site

[Michal Maczka]

> -Original Message-
> From: Emmanuel Venisse [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 02, 2003 4:27 PM
> To: Maven Developers List
> Subject: Rep:RE: non-core plugins site
> 
> OK, eclipse-plugins site is great, but on apache site, I think we can
> only use static content. 

I am not saying that we must do exactly the same thing as them.
I am just saying that what I did sucks and we should improve it.
If somebody has nice idea how to improve this page ( I don't have one at
the moment) it would be just great.

We can surly even now do things like paging/alphabetical index.

We are not yet ready for category based classification.

>We can't generate all possible pages for store
> plugins descriptions.
> 
>
We have those pages - don't we? Every plugin has its own page already.

Michal


> -Message d'origine-
> De: "Michal Maczka" <[EMAIL PROTECTED]>
> A: "'Maven Developers List'" <[EMAIL PROTECTED]>
> Date: 02/10/03
> Objet: RE: non-core plugins site
> 
> Other issue:
> 
> Somebody has better idea for the layout of the page which lists all
> maven plug-ins?
> 
> The usability of this page is clearly very poor (somebody already
> complained about it) and as for most of the plugins pom.Description =
> pom.shortDescripion the expanded information is useless at the moment.
> 
> 
> Maybe following page can give some inspiration?:
> http://eclipse-plugins.2y.net/eclipse/plugins.jsp
> 
> 
> Michal
> 
> > -Original Message-
> > From: Emmanuel Venisse [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, October 02, 2003 12:57 PM
> > To: [EMAIL PROTECTED]
> > Subject: non-core plugins site
> >
> > Hi,
> >
> > Maven was regenerated today and all plugins that moved from maven to
> > maven-plugins doesn't appears on the plugins list page.
> >
> > Where users can find plugin documentation?
> >
> > I think we should create a new page for non-core plugins, add a link
> in
> > the navigation tree and in the header.
> > Actually, we have a link "other plugins" in the header that link to
> > maven-plugins at sourceforge. We can link this to a page that list
all
> > plugin site like that "powered by" page.
> >
> > any comments?
> >
> > Emmanuel
> >
> >
> >
_
> > Un mot doux à envoyer? Une sortie ciné à organiser? Faites le en
temps
> > réel avec MSN Messenger! C'est gratuit!
http://ifrance.com/_reloc/m
> >
_
> > Envie de discuter en "live" avec vos amis ? Télécharger MSN
Messenger
> > http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de
> France
> >
> >
> >
-
> > 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]
> 
> _
> Envie de discuter en "live" avec vos amis ? Télécharger MSN Messenger
> http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de
France
> 
> _
> Un mot doux à envoyer? Une sortie ciné à organiser? Faites le en temps
> réel avec MSN Messenger! C'est gratuit!   http://ifrance.com/_reloc/m
> 
> _
> Envie de discuter en "live" avec vos amis ? Télécharger MSN Messenger
> http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de
France
> 
> 
> -
> 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: non-core plugins site

[Michal Maczka]

Other issue:

Somebody has better idea for the layout of the page which lists all
maven plug-ins?

The usability of this page is clearly very poor (somebody already
complained about it) and as for most of the plugins pom.Description =
pom.shortDescripion the expanded information is useless at the moment.


Maybe following page can give some inspiration?:
http://eclipse-plugins.2y.net/eclipse/plugins.jsp


Michal

> -Original Message-
> From: Emmanuel Venisse [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 02, 2003 12:57 PM
> To: [EMAIL PROTECTED]
> Subject: non-core plugins site
> 
> Hi,
> 
> Maven was regenerated today and all plugins that moved from maven to
> maven-plugins doesn't appears on the plugins list page.
> 
> Where users can find plugin documentation?
> 
> I think we should create a new page for non-core plugins, add a link
in
> the navigation tree and in the header.
> Actually, we have a link "other plugins" in the header that link to
> maven-plugins at sourceforge. We can link this to a page that list all
> plugin site like that "powered by" page.
> 
> any comments?
> 
> Emmanuel
> 
> 
> _
> Un mot doux à envoyer? Une sortie ciné à organiser? Faites le en temps
> réel avec MSN Messenger! C'est gratuit!   http://ifrance.com/_reloc/m
> _
> Envie de discuter en "live" avec vos amis ? Télécharger MSN Messenger
> http://www.ifrance.com/_reloc/m la 1ère messagerie instantanée de
France
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


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

RE: [Proposal] Interface plugin

[Michal Maczka]

Vincent!

I think this idea is cool.

I am just afraid that realization won't be so smooth, as this requires
better coordination between plugins.

I am not saying "no" to you initiative - but I'd like to rather see Maven
1.0 out  ASAP
and then concentrate our efforts on service oriented version of Maven.

I am certain it won't get long to have Maven2-Aplha1 out.

But surly if you are convinced that you changes are "safe"

go ahead and you have my +1

Michal


> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: Saturday, September 27, 2003 8:36 AM
> To: 'Maven Developers List'
> Subject: [Proposal] Interface plugin
>
>
> Hi,
>
> While waiting for the future component-based Maven implementation...
>
> What would you think about an "interface" plugin that would be used by
> plugins when calling goals from other plugins. The interface plugin
> would have properties to wire calls to "Well-Known Goals" (WKG) to the
> implementation. Default values would be the core plugins can be changed.
> For example the aspectj:weave goal would rewire the
> "maven.interface.call.compile-main" WKG to "aspect:compile" instead of
> the default "java:compile"?
>
> Thanks
> -Vincent
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> --
> Swietne miejsce na Twoja poczte!!! >>> http://link.interia.pl/f1765
>
>
>



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

RE: Why is build.properties from ${user.home} the most dominant

[Michal Maczka]

> -Original Message-
> From: Rafal Krzewski [mailto:[EMAIL PROTECTED]
> Sent: Sunday, September 21, 2003 3:43 PM
> To: Maven Developers List
> Subject: Re: Why is build.properties from ${user.home} the most dominant
>
>
> [EMAIL PROTECTED] wrote:
>
> > The idea is that the user knows what he wants, not the project builder.
>
> I thought that the difference between project.properties and
> build.properties was the the former were created by the project's
> vendor and the latter by the person who is building the project
> and are supposed to contain machine-specific settings that should
> not be shared through an SCM system.
> Because of that it makes sense to have both project.proerties and
> build.properties in a single project directory at the same time.
> Additionally Maven allows the user to set properties in
> ~/build.properties file. Currently the settings from this file
> override the settings from project's build.properties file.
> Both of the files say what the user (project builder) wants, not the
> project vendor, it's just the matter of specificality (<- correct
> english???). The settings in project's build.propertis say what
> the user want for this particular project and thus should override
> what the user wants generally. That's why I think Colin's request
> is valid.
>
> R.

I also see this as Rafal does.

We didn't have any compliments because current processing order is forcing
users
to use ${user.home}/properties for what they are meant for: for keeping
common settings
which are shared between all project.

At the moment what you put to this file is affecting 100% of the projects.
If this is our choice - "all or nothing" -  I am OK with that.

But this sometimes can be a problem.

I have once worked on project which has a content of  maven.local.repo  kept
in CVS and
IMHO it was wise decision in this particular case (very tight security
policy).

With the current processing order I was unable to override this property for
this particular project.
(which would be very helpful)



Michal






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

RE: cvs commit: maven/src/plugins-build/aspectj .cvsignore

[Michal Maczka]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Sunday, September 21, 2003 3:50 PM
> To: Maven Developers List
> Subject: Re: cvs commit: maven/src/plugins-build/aspectj .cvsignore
> 
> 
> Wouldn't you be better off putting these in your Eclipse preferences, 
> instead of in every plugin/project?
> --
> dIon Gillard, Multitask Consulting
> Blog:  http://blogs.codehaus.org/people/dion/
> 
> 
I think that it's safer to this like Vincent did.
Every instance of eclipse used by any of committers will see a change.


Michal 





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

RE: [aspectj] Changing behavior of aspectj plugin, is it ok?

[Michal Maczka]

> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: Sunday, September 21, 2003 11:51 AM
> To: 'Maven Developers List'
> Subject: [aspectj] Changing behavior of aspectj plugin, is it ok?
>
>
> Hi,
>
> I'd like to change the way the aspectj plugin works. Here's what I'd
> like to implement:
>
> - make it a pre-goal of jar:jar
> - verify if there are aspects present in the source tree
> - if there are, weave the aspects on the *bytecode* (classes compiled by
> the java plugin)
> - the generated jar of the jar plugin will then contain the aspects
>
> This way, building an aspected project will be seamless. Of course we
> could have a property to turn off automatic aspecting if we want.
>
> Would that be ok?
>
I hope that soon AspectJ will be used on daily basis and there will be more
and more libraries containing aspects.
So any project can be both consumer and producer of such libs.
Your scenario is bit to simple to handle such cases.


> Note: The only fear I have is when Maven users using aspects also define
> a pre-goal on jar:jar. Would the aspect pre-goal be run before or after
> the user one? I think the user one should run before the aspect one. But
> is that what is going to happen?
>
Order of execution is unknown.

Any way: +1 on any improvments of this plugin :)

Michal



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

RE: [jira] Updated: (MAVEN-831) Can't specify location of web.xml

[Michal Maczka]

>
> Description:
> When the WAR plugin was converted from using Ant's  task to
> using the  task we lost the ability to use the
> ${maven.war.webxml} property to specify the location of the
> web.xml file.  Not only does this reduce flexibility (the only
> place you can put web.xml is in
> ${maven.war.src}/WEB-INF/web.xml), but it prevents the token
> filtering tip (in xdocs/tips.xml) from working.
>
>

Flexibility is not necesserly a good thing.
In current shape of the plugin you are able to define pre- or post- goals
which will do the same exact thing as you patch does.
War plugin is not limiting your possibilities but if you want to do
something non standard you have to do this in non standard way.
For me this is very resonable.
Keeping web xml  in location different then {maven.war.src}/WEB-INF/web.xml)
is a no standard thing.
Mandating non standard project layouts through the set of configurable
properties is imho a very bad thing
(even though many plugins are written in this way).

I am not saying that the way how maven war plugin works currently is the
best thing possible, but
if you have better idea how to structure directories or where web.xml file
should be kept - please speak out!

(Token Filtering in web.xml file is a bit different subject! I have nothing
against it!)

Michal



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

RE: Next release?

[Michal Maczka]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 15, 2003 7:43 AM
> To: [EMAIL PROTECTED]
> Subject: Next release?
> 
> Are we all in agreement that the next release should happen pretty
soon,
> and be called 1.0-beta-11?
> 
> I'm +0 on that name vs 1.0-RC1, as we know we aren't adding new
> functionality.
> 
> Any objections/vote now?
> 
> Here's my +1.
> --

-1 on calling it beta-11
+1 on calling it RC1


We already called it RC-1 and it's better to be consequent with this
choice.
Are we going to have beta-11 and then again website saying that current
version of Maven is RC1-SNAPSHOT? Some users have already asked if RC-1
is out, we should not confuse them even more. 

Michal 


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

RE: [offtopic] Re: Core plugins?

[Michal Maczka]

> -Original Message-
> From: Norbert Pabiś [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 12, 2003 6:05 PM
> To: Maven Developers List
> Subject: [offtopic] Re: Core plugins?
>
>
> Jason van Zyl wrote:
> > I don't think so, Aslak likes his container and I like mine :-) But
> > there's no reason Plexus can't support Pico components. It has other
> > factories. If people write components for Picocontainer we can use them.
> > Not a problem. As for Picocontainer itself, I'm really not sold on the
> > idea.
> There should much more documentation in plexus xdocs.

And everybody should be healthy and rich,  there should be peace all over
the world
and many, many more things. Sorry this world is cruel :)


> I am a newbie to both containers, and my first experience to PicoContainer
> was smooth while Plexus is still kinda mysterious after reading
> available documentation.
>
AFAIK: It is not yet ready for public consumption.


serd. pzdr.

Michal



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

RE: cvs commit: maven/src/plugins-build/xdoc/xdocs faq.fml navigation.xml

[Michal Maczka]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Sunday, September 07, 2003 4:51 PM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: maven/src/plugins-build/xdoc/xdocs faq.fml
> navigation.xml
> 
> dion2003/09/07 07:50:33
> 
>   Modified:src/plugins-build/xdoc project.properties project.xml
>src/plugins-build/xdoc/xdocs navigation.xml
>   Added:   src/plugins-build/xdoc/xdocs faq.fml
>   Log:
>   Move xdoc FAQs from Wiki to site docs
> 
>   Revision  ChangesPath
>   1.4   +1 -1  maven/src/plugins-build/xdoc/project.properties
> 
>   Index: project.properties
>   ===
>   RCS file:
/home/cvs/maven/src/plugins-build/xdoc/project.properties,v
>   retrieving revision 1.3
>   retrieving revision 1.4
>   diff -u -r1.3 -r1.4
>   --- project.properties  19 Mar 2003 06:01:19 -  1.3
>   +++ project.properties  7 Sep 2003 14:50:33 -   1.4
>   @@ -5,4 +5,4 @@
>maven.xdoc.version=${pom.currentVersion}
>
#maven.xdoc.developmentProcessUrl=http://maven.apache.org/development-
> process.html
>maven.license.licenseFile=${basedir}/../../../LICENSE.txt
>   -
>   +maven.checkstyle.header.file=${basedir}/../../../LICENSE.txt
> 
> 
> 
>   1.26  +16 -0 maven/src/plugins-build/xdoc/project.xml

I am not complaing :) ... but wouldn't it be better to 
to solve this issue by inheriting

maven.license.licenseFile
and 
maven.checkstyle.header.file

from parent project for all plugins?

We need to implement this feature (afaik properties were not inherited
some time ago) before 1.0 goes out.


Michal



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

RE: clarify plugin version loading

[Michal Maczka]

> -Original Message-
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 08, 2003 12:24 AM
> To: 'Maven Developers List'
> Subject: RE: clarify plugin version loading
> 
> 
> > AD 2 & 3
> >
> > We can easily use information which we have in POM:
> >
> > 
> > 
> >   b1
> >   1.0-b1
> >   MAVEN_1_0_B1
> > 
> > 
> >   b2
> >   1.0-b2
> >   MAVEN_1_0_B2
> > 
> > 
> >   b3
> >   1.0-b3
> >   MAVEN_1_0_B3
> > 
> > 
> >   b4
> >   1.0-b4
> >   MAVEN_1_0_B4
> > 
> >   
> >
> > verion 1.0-b3 is "below" 1.0-b2 so it is higher version.
> >
> 
> I tend to do them in the reverse order :)

If you keep versions in reverse order it means that docs for this part
of the POM are not good enough! There should be only one way of doing
that!

> 
> I don't know whether this will work out though - that means opening
the
> plugins, getting the project (or locating it elsewhere), and figuring
> out
> which is newer. 
>You could just as easily say the one with more versions
> too.
> 
> If we were going to do that I think I'd rather have a last release
date
> in
> the POM.
> 
Well this is just an idea at the moment. At least I am sure that POM
holds enough data for comparing and ordering different versions of
artifacts. Implementation of "version comparator" seems to be quite easy
too. 
What about adding  section as required in POM for uploading
artifact to ibiblio?

regards 

Michal


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

RE: [jira] Created: (MAVEN-783) clarify plugin version loading

[Michal Maczka]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 05, 2003 1:07 AM
> To: [EMAIL PROTECTED]
> Subject: [jira] Created: (MAVEN-783) clarify plugin version loading
> 
> Message:
> 
>   A new issue has been created in JIRA.
> 
> -
> View the issue:
> 
>   http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-783
> 
> 
> Here is an overview of the issue:
> -
> Key: MAVEN-783
> Summary: clarify plugin version loading
>Type: Task
> 
>  Status: Assigned
>Priority: Major
> 
>  Time Spent: Unknown
>   Remaining: Unknown
> 
> Project: maven
>Fix Fors:
>  1.0-final
> 
>Assignee: Brett Porter
>Reporter: Brett Porter
> 
> Created: Thu, 4 Sep 2003 6:06 PM
> Updated: Thu, 4 Sep 2003 6:06 PM
> 
> Description:
> verify that:
> 
> 1) there should only be one plugin of a type loaded at a time (easy to
> change by having the manager use the artifactId as the name - removing
the
> version)

I agree that for 1.0 and probably only for 1.0 this is a right
assumption. 

> 2) if 1.2 and 1.2-SNAPSHOT are present, use 1.2 (difficult, because we
> have no concept of version X > version Y since you can use any type of
> string)
> 3) if 1.2 and 1.3 are present, use 1.3

AD 2 & 3 

We can easily use information which we have in POM:



  b1
  1.0-b1
  MAVEN_1_0_B1


  b2
  1.0-b2
  MAVEN_1_0_B2


  b3
  1.0-b3
  MAVEN_1_0_B3


  b4
  1.0-b4
  MAVEN_1_0_B4

  

verion 1.0-b3 is "below" 1.0-b2 so it is higher version.

[..]

Michal





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

RE: [VOTE] Brett Porter to be given committer privileges

[Michal Maczka]

+1

mm

> -Original Message-
> From: Ben Walding [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 13, 2003 4:50 AM
> To: Maven Developers List
> Subject: [VOTE] Brett Porter to be given committer privileges
> 
> 
> I'd like to nominate Brett Porter as a new committer.
> 
> He's been active on the lists helping newbies, he's been submitting good 
> patches, seems not to be saying anything demented (irc / lists) and has 
> been sorting through a lot of the old crufty jira issues that we tend to 
> forget about.
> 
> I think he'd be a good fit for Maven.
> 
> (And he lives in Australia, which is highly important as we try and 
> implement the new Vegemite scripting language)
> 
> If at least 3 committers could +1 this, we can get the wheels in 
> motion.  Close of voting at Thursday 12:01pm EST (USA)  (not that I 
> really know when that is)
> 
> Cheers,
> 
> Ben
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> --
> Super konto na szybkim serwerze! >>> http://link.interia.pl/f1755
> 
> 
> 


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

RE: [jira] Commented: (MAVEN-194) Two dependiencise having the same id but different type should not be assumed as duplicates

[Michal Maczka]

Because one project can "produce" more then one artifact.
e.g. JSP tag libs are often distributed as two files: jar + tld file.

You should be able to do 


   foo
   boo
   jar



   foo
   boo
   tld


and there is nothing wrong with it.

There are more examples like this.

At the moment even simple project can "emit" following artifacts:

jar  (jar:install)
javadoc (javadoc:install)
java-sources (java:install-src)
pom (pom:install)





Michal




> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 05, 2003 4:06 AM
> To: [EMAIL PROTECTED]
> Subject: [jira] Commented: (MAVEN-194) Two dependiencise having 
> the same id but diffrent type should not be assumed as duplicats
> 
> 
> The following comment has been added to this issue:
> 
>  Author: dion gillard
> Created: Mon, 4 Aug 2003 9:05 PM
>Body:
> I'm not sure I agree with the use of artifactType as a differentiator.
> 
> From my angle, artifactId and groupId as a combination should be unique.
> 
> I don't see why type should be taken into account at all. Declare them as
>  
> boo
> 
> and
> 
> boo-web
> 
> -
> View the issue:
> 
>   http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-194
> 
> 
> Here is an overview of the issue:
> -
> Key: MAVEN-194
> Summary: Two dependiencise having the same id but diffrent 
> type should not be assumed as duplicats
>Type: Bug
> 
>  Status: Reopened
>Priority: Major
> 
>  Time Spent: Unknown
>   Remaining: Unknown
> 
> Project: maven
>Fix Fors:
>  1.0-final
>Versions:
>  1.0-beta-8
> 
>Assignee: Jason van Zyl
>Reporter: Michal Maczka
> 
> Created: Sun, 12 Jan 2003 10:22 AM
> Updated: Mon, 4 Aug 2003 12:56 PM
> 
> Description:
> Currently in case of following dependincies in POM:
> 
> 
> 
>   mydep
>   1.0.1
>   war
> 
>   
> 
> 
>   
> 
>   mydep
>   1.0.1
>jar
> 
>   
> 
> only the first dependency will be availabe in dependency list.
> 
> Solution:
> 
> Both "id" and "type" should be used in 
> org.apache.maven.project.BaseObject and two dependincies should
> be assumed as equal only if
> dep1.id == dep2.id
>&&
> dep1.type == dep2.type
> 
> 
> 
> 
> 
> -
> JIRA INFORMATION:
> 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]
> 
> 
> --
> Portal INTERIA.PL zaprasza... >>> http://link.interia.pl/f174b 
> 
> 
> 


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

RE: EJB plugin modification

[Michal Maczka]

> I guess I'm having trouble figuring out how you would do that cleanly
> without duplicating a lot of jelly script.
>
> In jboss:ejbdoclet you would have this:
>
> 
>... lots of common stuff like 
>
> 
>
> Then in weblogic:ejbdoclet you would have this:
>
> 
>... lots of common stuff like 
>
> 
>
> How do we avoid duplicating all of the common stuff (ejbdoclet attributes
> and subtasks) in an easy to maintain way?

I agree that code written in jelly is not really reusable in case of nested
ant tasks.

So there are two options here:

a) put everything to one hugh bag
b) copy & past  programming

for me out of those two b) still wins

This option was also silently chosen by jar/war/ejb/jnlp plugins for code
which creates manifest file.

Michal

P.S.

There is in fact 3rd and option for ejbdoclet:
 c) do it in Java trying to reuse Ant java code.





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

RE: EJB plugin modification

[Michal Maczka]

> -Original Message-
> From: Brian Towles [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 31, 2003 5:57 PM
> To: Maven Developers List
> Subject: RE: EJB plugin modification
>
>
>
> On Thu, 2003-07-31 at 03:54, Michal Maczka wrote:
> > IMHO the correct workflow which should be supported by ejb plugin looks
> > like follows:
> >
> > a) gather all the files which will be packaged in ejb-jar in one place
> > (equivalent of war:webapp)
> > b) archive this directory (equivalent of war:war)
> >
> >
> > Now other plugins like xdoclet/jboss/websphere/whatever
> >
> > Will be able to easily run pre/post goals for steps "a" and "b"
> and decorate
> > them accordingly to their needs
> >
> > And those plugins can deliver higher level methods like:
> >
> > jboss:ejb weblogic:ejb
> >
> > which will create ejb jar for jboss/weblogic and reuse maven-ejb plugin
> >
> > So basically maven-ejb plugin IMHO should be used as a tag library
> > which can be extended/overridden and should not contain
> container specific
> > logic.
>
> Im actually in complete agreement with you that this should be the
> proper way to do it.  But there are several issues that I see
> that prevent it.
>
> First, there is the Ant ejbjar task itself.
>
> Re-codeing all off the work done by the Weblogic or Websphere ant
> subtasks into a
> jelly enviroment would be a royal pain.
>

I don't say that ant task(s) shouldn't be used at all
What I say is: if ant tasks are used it should be something this like:

  (jboss plugin)
   


   (Weblogic plugin)
   



etc

in place of

 (ejb plugin)
  
  
  
  
  
   


xxx.jboss=false
xxx.jweblogic=false
...
xxx.jrun=true


which is simply very very bad.

> > I really dislike the desing of ant ejb-jar task.
> >
> http://cvs.apache.org/viewcvs.cgi/*checkout*/ant/src/main/org/apac
> he/tools/a
> > nt/taskdefs/optional/ejb/EjbJar.java?rev=1.45
> >
> > The parent tag knows about existence of server specific Tasks.
> >
> >
> > The reason for that is that in ant world tasks have no idea
> where to search
> > for behavioral properties so they simply inherit them from
> parent tag. So
> > this is somehow justified.
>
> Its not only serching for behavioral properties. It does this for
> code reuse.
> The base level generic jar for all of the ant ejbjar tasks are
> the same.  Why recode
> everything when you can just use what you did before.  Base OO design.
>
> Secondly, reinventing the wheel is a bad thing IMHO.  Maven already
> uses ant as a basis for the underlying tool, using the tools
> provided just
> makes sense.  The ejbjar task is a known quantity and well proven
> in the Ant world.
>
ditto


In addition I strongly believe that layering like:

[java] [ant]
   [maven]
   [gui]
   [maven][gui]

is better and this is what really can stimulate code reuse

and certainly it is not:

[ant] [maven] [gui]
or
[ant] [gui]


You can do things programmatically in java with Ant, but Ant was not created
for that.
But writing Ant task for existing Bean is a matter of seconds. So is writing
a jelly tag lib.

The same lesson was learnt with XDoclet. XDoclet 1.x was not adopted by any
IDE nor never
was IDE friendly basically because it was impossible to use it without Ant.
AFAIK XDoclet 2 will be free from this defect.


I have nothing against Ant (still use it for more complicated builds).
I just have an opinion that some things can be done
in better way without it. And if we will do them in Java there is 0.0001 %
of the
chance that they will be reused by Ant and much higher chance that they will
be reused
by some other tools.

[...]

Michal



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

RE: EJB plugin modification

[Michal Maczka]

> 
> Do you want to have a jboss:ejbdoclet and a weblogic:ejbdoclet goal when
> both of them are going to be 80% the same?
> 

Yeap! I would like to see them as two separate projects.
AFAIK XDoclet team (I know this from mailing lists not from developers) is
not going to maintain as many plugin as it has place now when version 2.0
will be out.

They just want to concentrate on writing XDoclet core and maybe few core
plugins (@jakarata) and give the control over plugins to community
(@sourceforge ?). So they want to do exactly the same thing as seems to me
to be a right thing for Maven.

Note for example that when XDoclet 2.0 will be out probably jboss plugin for
it will most likely be released much faster then e.g. the plugin for Borland
Application Server. So then some users will be still willing to use XDoclet
2.0 some others them will want to use 1.x while some others would prefer to
use some other doclet. 

It will be a horror to see a code supporting all those tools inside
maven-ejb plugin.


[...]


Michal

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

RE: EJB plugin modification

[Michal Maczka]

> -Original Message-
> From: James CE Johnson [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 31, 2003 2:44 PM
> To: [EMAIL PROTECTED]
> Subject: RE: EJB plugin modification
> 
> Hi Michal,
> 
> My $.02 worth...  I'm biased towards invoking xdoclet, however, which is a
> slightly different focus than Brian (I think) so my replies may not be
> 100% compatible with yours.
> 
> > Hi Brian!
> >
> > I don't like the idea of making fatter ejb:plugin
> > and putting there a logic which is particular to some application
> > server.
> >
> > IMHO the correct workflow which should be supported by ejb plugin looks
> > like follows:
> >
> > a) gather all the files which will be packaged in ejb-jar in one place
> > (equivalent of war:webapp)
> > b) archive this directory (equivalent of war:war)
> >
> >
> > Now other plugins like xdoclet/jboss/websphere/whatever
> 
> I'm not seeing any plugins that invoke xdoclet's  tag. I really
> think it makes sense to have an ejb:ejbdoclet goal in the ejb plugin to
> invoke that.
> 
> Why? A couple of reasons:
> 
> a) Because it can generate code for multiple appservers it doesn't make
>sense to invoke it in a container-specific plugin.
> 

IMHO it does make sense.

It almost makes no difference if you type

maven ejb:jar 
   or 
maven jboss:ejb-jar 

And maven ejb:jar can briefly do entire work if it can be decorated at
appropratie call-back points (read: drop dependency on ant). 

I really dislike the desing of ant ejb-jar task.

http://cvs.apache.org/viewcvs.cgi/*checkout*/ant/src/main/org/apache/tools/a
nt/taskdefs/optional/ejb/EjbJar.java?rev=1.45

The parent tag knows about existence of server specific Tasks.


The reason for that is that in ant world tasks have no idea where to search
for behavioral properties so they simply inherit them from parent tag. So
this is somehow justified.

But with Maven we are at least one step further and the design can be
cleaner and simply much better (my personal opinion).

I don't see any reason why we should mimic wrong design in Maven when we can

do a lot better.



> b) I suppose we could create a maven-xdoclet-plugin to do the invocation
>but, really,  is *only* for generating the ejb-related files
>so IMO it just makes sense that it would be a part of the ejb plugin.
> 
> >
> > Will be able to easily run pre/post goals for steps "a" and "b" and
> > decorate them accordingly to their needs
> >
> > And those plugins can deliver higher level methods like:
> >
> > jboss:ejb weblogic:ejb
> >
> > which will create ejb jar for jboss/weblogic and reuse maven-ejb plugin
> 
> In my experience (using only jboss and weblogic) there's not really a
> difference in the ejb jar creation process. There *is* a difference in
> some of the files contained in there but those are (typically) generated
> by xdoclet or hand-coded into src/ejb/foo.
> 
> >
> > So basically maven-ejb plugin IMHO should be used as a tag library which
> > can be extended/overridden and should not contain container specific
> > logic.
> 
> I hope to submit (to jira) my ejb:ejbdoclet goal today. I would appreciate
> your thoughts on whehter or not its appropriate for the ejb plugin or, if
> not, where it might make sense to be.
> 
>

My opinion is: we should support automated management of plugins ASAP
And let people/small communities maintain their own plugins.

BTW: Who says there should be only one ejb plugin?

I am using XDoclet every day and from this point of view
It would better for me if it were included in maven distribution.
 
But from the point of view of Maven it is not a good thing.
Basically in plugins we have thousand of lines of code which are not tested 
and this is getting out of control. 
I am not using any EJB container at the moment. Not many active Maven
developers do.
Probably Vincent has the biggest experience here but he is also probably not
using every possible application server.
So nobody will be able to test your even code manually (saying nothing about
automated tests). And once this code sits in our CVS we should 
maintain it, manages bugs etc. IMHO Maven developers should not take such
responsibility.  
 
Michal

P.S.

Still go ahead with your patches ... it's fine if they are in JIRA.

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

RE: EJB plugin modification

[Michal Maczka]

Hi Brian!

I don't like the idea of making fatter ejb:plugin
and putting there a logic which is particular to some application server.

IMHO the correct workflow which should be supported by ejb plugin looks 
like follows: 

a) gather all the files which will be packaged in ejb-jar in one place
(equivalent of war:webapp)
b) archive this directory (equivalent of war:war)


Now other plugins like xdoclet/jboss/websphere/whatever 

Will be able to easily run pre/post goals for steps "a" and "b" and decorate
them accordingly to their needs

And those plugins can deliver higher level methods like:

jboss:ejb weblogic:ejb

which will create ejb jar for jboss/weblogic and reuse maven-ejb plugin

So basically maven-ejb plugin IMHO should be used as a tag library
which can be extended/overridden and should not contain container specific
logic.


Also properties like:
maven.ejb.support.0.includes

are not really compatible with other properties used in maven.
Only plugin which uses them which I am aware of is auto-generated xdoclet
plugin
And it uses them because ... it is auto-generated.
I am rather against them.

regards

Michal


> -Original Message-
> From: Brian Towles [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 31, 2003 7:31 AM
> To: Maven Developers List
> Cc: [EMAIL PROTECTED]
> Subject: Re: EJB plugin modification
> 
> Helps if I attach what I say im going to..
> 
> On Thu, 2003-07-31 at 00:28, Brian Towles wrote:
> > On Wed, 2003-07-30 at 17:56, James CE Johnson wrote:
> > > I agree. maven's mode of operation, however, is one artifact per
> > > (sub)project. I generally try to work within that philosophy but there
> > > are times when it doesn't work for me. For instance, in one subproject
> > > we create foo.jar that contains the EJBs; foo.ear that contains
> foo.jar
> > > and all of its dependencies; foo-client.jar that has only the classes
> > > needed by clients of the ejb; foo-mock.jar that contains
> > > mockdoclet-generated classes that other subprojects can use in their
> > > unit tests. To me, that seems reasonable since all of the artifacts
> > > come from the same set of sources and are, in some way, related.
> > >
> >
> > Yeah your right   for now im going to leave the ejbjar to be able to do
> > what you want it to   but supporting a multi-jar install and deploy
> > would be a pain.
> >
> >
> > > Ah. Not using ejbc so that's new information. We do use WebLogic
> though
> > > so I'd really like to see what you've got when you're happy with it. I
> > > gather pre-generating the rmi stubs gives you a boost at deployment?
> > > Runtime?
> >
> > I havent used weblogic since the 5.X and early 6.X days, so i cant say
> > what the current method of deployment is.  Back in 5.X there was not
> > autogeneration of stubs on deploy and ejbc had to be run.  I would
> > assume BEA has made some strides in that.
> >
> > And since you asked :)
> >
> > Im actually in a pretty good state.  Im using it for jboss projects just
> > fine.  I need people with different environments to try it out.
> >
> > Ive attached the patch to 1.0beta10.  Im going to wait to submit it
> > officially until I can get some more feedback.
> >
> > You can also just get the modified plugin jar from
> > http://www.casadeslug.com/mavenmods/maven-ejb-plugin-1.1-SNAPSHOT.jar
> >
> > and the modified properties.html docs are here
> > http://www.casadeslug.com/mavenmods/docs/properties.html
> >
> > They look a scary   but its not really.
> >
> > I can only test the JBoss portion of the code out, so if anyone else
> > wants to try the other app servers out please do.  They should be
> > working (not really much to em)  but i could have some typos.  Any help
> > would be appreciated.
> >
> >
> > -=Brian
> --
> Brian Towles <[EMAIL PROTECTED]>

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

RE: Maven documentation build with multiproject plugin

[Michal Maczka]

It seems that my attachments get eaten on the way.

I've sent 3 emails with attachments in last 2 weeks.
Only one was delivered without problems.

Somebody knows what are the filtering rules?


Michal

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 29, 2003 7:12 AM
> To: Maven Developers List
> Subject: Re: Maven documentation build with multiproject plugin
> 
> Michal, the attachment wasn't in the email
> --
> dIon Gillard, Multitask Consulting
> Blog:  http://blogs.codehaus.org/people/dion/
> 
> 
> "Michal Maczka" <[EMAIL PROTECTED]> wrote on 29/07/2003 05:55:43 AM:
> 
> > I have made an attempt to generalize the page
> > which shows overview of subproject build via multiproject plugin.
> >
> > Here you can find an sample output.
> >
> > Note that on the top of the page I am using ${pom.shortDescription}
> > and for subsections ${pom.description}
> >
> > In case of maven plugins this web page is surly overloaded
> > (maybe it will be sufficient for codehaus?)
> >  but I believe this is not a problem of this plugin ( :) )
> > but rather the fact that we have xx plugins and we do need to categorize
> > them.
> >
> > This page can also serve as a kind of report which shows how many
> plugins
> > don't have correct information provided inside  and/or
> >  tags.
> > Should we rise issue in JIRA for that?
> >
> > As this is still experiment ... I am not saying that this should replace
> the
> > plugin listing which
> > we have (but old page is not much better!).
> >
> >
> >
> > To regenerate this page either  (CVS HEAD version of multiproject plugin
> and
> > maven code (maven.xml and project.properties))
> > do:
> > maven multiproject:create-overview-page xdoc:transfrom
> >
> >
> > Note also that following goals become usable:
> >
> > multiproject:install (will install all plugins)
> > multiproject:clean (will clean all plugins)
> >
> >
> > At the moment I don't want to refractor/touch top-level maven.xml file
> and
> > replace any more goals with
> > multiproject - it is not wise to do this with broken head. But this is
> > rather straight-forward task.
> >
> >
> > Michal
> >
> > P.S.
> >
> > (for the best results please view provided pages in the location where
> CSS
> > files are accessible :))
> >
> > -
> > 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]

Maven documentation build with multiproject plugin

[Michal Maczka]

I have made an attempt to generalize the page
which shows overview of subproject build via multiproject plugin.

Here you can find an sample output.

Note that on the top of the page I am using ${pom.shortDescription}
and for subsections ${pom.description}

In case of maven plugins this web page is surly overloaded
(maybe it will be sufficient for codehaus?)
 but I believe this is not a problem of this plugin ( :) )
but rather the fact that we have xx plugins and we do need to categorize
them.

This page can also serve as a kind of report which shows how many plugins
don't have correct information provided inside  and/or
 tags.
Should we rise issue in JIRA for that?

As this is still experiment ... I am not saying that this should replace the
plugin listing which
we have (but old page is not much better!).



To regenerate this page either  (CVS HEAD version of multiproject plugin and
maven code (maven.xml and project.properties))
do:
maven multiproject:create-overview-page xdoc:transfrom


Note also that following goals become usable:

multiproject:install (will install all plugins)
multiproject:clean (will clean all plugins)


At the moment I don't want to refractor/touch top-level maven.xml file and
replace any more goals with
multiproject - it is not wise to do this with broken head. But this is
rather straight-forward task.


Michal

P.S.

(for the best results please view provided pages in the location where CSS
files are accessible :))

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

[POM extensions]

[Michal Maczka]

I want to propose following changes in POM:

a) Add  tag which points to a place where javadoc of given project
is accessible (URL)
I should be on the same level as  tag.

   This can be used e.g. by javadoc plugin.



b)  tag inside of  tag
   I quite frequently use XML comments  ( )
   to describe why do I need a given dependency, or why e.g. I use version
1.1 when 1.3 is already
   out. I think it would be nice to see such comments in reports.

c) I would like also to remove in future  tag from . This
information can be easily
   accessed from POM of given artifact. I have rewritten xdoc plugin and now
if there is a POM
   of given dependency present in a local repository, dependency report is
able to retrieve artifact's description
   and url from it. Still  tag wins if user has provided it.

   All we need is to have much more POMS in the repository!!

   a) What about creating area in Maven Wiki where users will be able to
edit/ submit new POMS.

   b) What about officially do not let any new artifact to be put to ibiblio
repository
   without the POM which describe it? So basically being very strict about
the rules
   described in http://maven.apache.org/repository-upload.html
   and every time upload both: artifact and its POM? Maybe even the set of
mandatory tags in POM
   should be extended?

   I can easily hook POM deployment to artifact:install, artifact:deploy
goals, so if any of those two goals
   is called POM is also installed/deployed.



regards

Michal




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

Latest Dependecy Convergence Report.

[Michal Maczka]

Latest Dependency Convergence Report.

Thanks to dIon we are now at 94% (two days ago it was just 74%!!)

I don't know if somebody ever did a tool like this:
so if somebody has better name for the tool itself or better replacement for
terms like: Convergence, NOD, NOA

Also any idea how to improve this report is much appreciated.

Michal

P.S.

I finally manage to commit it to CVS...


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

new functinality added to multiproject plugin

[Michal Maczka]

I have added new goal to multiproject plugin called:
"multiproject:harmony"
It is  allowing to create  a global report which lists all dependencies 
from all sub- projects  and shows inconsistencies in versions between
them. 

At the moment I put it to multiproject plugin, but I am not sure if this
is a best place for it.

It is still in early stage of development - but already  usable - the
proof - see: attached file:harmony.zip.

I think it would be nice to harmonize the versions of artifacts used in
plugins (wherever it is possible). I believe that at least  all maven
core plugins should use artifacts in consistent way. I hope that this
"new code"  will help to achieve this.

Any comments are much appreciated!

Specially the name for "this code" is still not decided.
I thought about names like: "Harmony" "FengShui" etc.
Anybody has a good idea?

To generate the report for maven unzip the file depcheck.zip

to maven/src/plugin-builds

then do 

cd maven/src/plugin-builds/depcheck

and type:

maven  multiproject:harmony site


and then see harmony.html  in a target dir


Michal

P.S.

Note that I have added two new icons to xdoc plugin.


depcheck.zip
Description: Zip archive


harmony.zip
Description: Zip archive
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

multiproject - Latest commits

[Michal Maczka]

FYI:

While I was trying to commit my latest addition to muliproject plugin  CVS
Server  was unusable (CVS server at apache is not really usable at the
moment)

I will fix this tommorow ( from work)

Michal



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

[javadoc plugin] Install/Deploy facility was added

[Michal Maczka]

I have added:
install, install-snapshot, deploy and deploy-snapshot  goals to javadoc
plugin.

Once repository-layout component is back-ported from Maven-new
we can think about naming convention for javadoc artifact.
At the moment it is named (in repository)
javadocs/${maven.final.name}.javadoc


Question:
Somebody knows why we need commons-lang in javadoc plugin:
It seems to be 
a) not needed
b) if it is needed it is rather outdated:   

   
  commons-lang
  1.0-b1.1
  
root.maven
  


Michal

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

RE: cvs commit: maven/src/plugins-build/multiproject plugin.jelly

[Michal Maczka]

It was a long fight?
:)

mm
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 09, 2003 9:57 AM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: maven/src/plugins-build/multiproject plugin.jelly
> 
> dion2003/07/09 00:56:40
> 
>   Modified:src/plugins-build/multiproject plugin.jelly
>   Log:
>   Add comment about why it can't use goal
> 

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

RE: Artifact managment - deploy & fetch

[Michal Maczka]

> -Original Message-
> From: Jason van Zyl [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 07, 2003 1:16 PM
> To: Maven Developers List
> Subject: Re: Artifact managment - deploy & fetch
> 
> On Mon, 2003-07-07 at 04:13, Michal Maczka wrote:
> > I hope to find time today (latest tomorrow) and finish reaming issues of
> > artifact deployer.
> >
> >
> > I have some issues I want to discuss:
> >
> > 1)
> > When artifacts are big (few MB) frequent deployment of snapshots to
> > repository (local or remote) results in MB of unused space,
> > as snapshot == latest version (we don't need older versions of the
> snapshots
> > anymore)
> 
> Yes we do. You can never know which timestamped version someone might be
> dependending on. You can't just remove them.
> 
> > I suppose that in case of snapshot it wouldn't be so bad
> > if during deployment we will delete an older version of the artifact
> 
> If you mean the removal of timestamped JARs that have been deployed then
> most definitely -1. You can't remove them.

Yeap. I see the problem. I realized that it is not so easy, if at all
possible.


However I see that there is a certain problem there:
I have 5 MB large wars. After 20 deployments of snapshots
100 MB of space in repository gets eaten. 20 deployments = 3/4 days.

Currently when we deploy snapshot - we also deploy a time-stamped file.
In most of the cases (I am speaking about company-wide remote repository,
not about repositories like IBiblio) most of this files become
obsolete once new snapshot is replacing an old one. And those files are
taking up a lot of space.

We need timestamped jars(artifacts) when we want to resolve real versions of
snapshots and when we need to convert them to immutable dependencies
(e.g while making the release)

But for example for "intranet reposositories" we can imagine that those
timestamped version will appear in repository only when we will start to
need it. 
So I dare to say that:

artifact:deploy-snapshot != artifact:deploy-timestamped-file


So we can imagine that when other project needs to convert a snapshot
version of artifact delivered by other project to immutable, timestamped
artifact - that this project will be responsible to upload timestamped
version of the other artifact to remote repository.


That is just immature idea. 
What I really want is to "save my disk space" :)
There are maybe better possibilities. 


> > 2)
> > I think it will be nice to start using POMs as descriptor of the
> artifact.
> 
> Yes, I often use them just not a widely known feature.
> 
> > E.g I would prefer to retrieve information about artifact URL from the
> POM
> > of this artifact rather then do:
> >
> > 
> >xerces
> >2.2.1
> >>http://xml.apache.org/xerces2-j/ > 
> 
> Sorry, not sure what you mean here? You mean looking up the POM to find
> it's URL and other information about the artifact? In that case, yes,
> definitely.
> 

That's what I meat. I think only artifact's own POM should be used
for providing metadata information about this artifact.
We should avoid using things like:

http://xml.apache.org/xerces2-j/


So e.g the the report like:

http://maven.apache.org/dependencies.html

can contain much more information (e.g. short description about each
artifact)


> > What about deploying (installing) also the POM to the repository, every
> time
> 
> The POM really only needs to be deployed for releases. I'm not sure it
> would be wise to start deploying snapshot POMs though I haven't thought
> about it much.
> 
Between two deployments of snapshot something might get added/changed in the
POM. It is even often the case.



Michal

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

RE: Snapshots for each artifact?

[Michal Maczka]

Fixed (goals were added)

regards

Michal

> -Original Message-
> From: Rademacher Tobias [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 07, 2003 11:08 AM
> To: '[EMAIL PROTECTED]'
> Subject: Snapshots for each artifact?
> 
> Hi Folks,
> 
> currently only JAR and WAR plugins support snapshot. As far as I can see
> in
> ViewCVS EJB plugin does not support it.
> Shoud't we support it for all possible types of artifacts? (Avalon has its
> own Artifacts, in J2EE has RAR, Jboss has SAR...).
> 
> What do you think?
> 
> Bye
> Toby
> 
> 
> -
> 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]

Artifact managment - deploy & fetch

[Michal Maczka]

I hope to find time today (latest tomorrow) and finish reaming issues of
artifact deployer.


I have some issues I want to discuss: 

1)
When artifacts are big (few MB) frequent deployment of snapshots to
repository (local or remote) results in MB of unused space, 
as snapshot == latest version (we don't need older versions of the snapshots
anymore)

I suppose that in case of snapshot it wouldn't be so bad
if during deployment we will delete an older version of the artifact

To do this we would probably need to fetch some files from repository
(e.g foo-snapshot-version file).

2) 
I think it will be nice to start using POMs as descriptor of the artifact.

E.g I would prefer to retrieve information about artifact URL from the POM
of this artifact rather then do:


   xerces
   2.2.1
   http://xml.apache.org/xerces2-j/


What about deploying (installing) also the POM to the repository, every time

we deploy some artifact? 



Michal

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

RE: [war plugin] - Proposition by default include instead ofexclude

[Michal Maczka]

> -Original Message-
> From: Jason van Zyl [mailto:[EMAIL PROTECTED]
> Sent: Sunday, July 06, 2003 3:02 PM
> To: Maven Developers List
> Subject: RE: [war plugin] - Proposition by default include instead
> ofexclude
>
>
> On Sun, 2003-07-06 at 06:32, Michal Maczka wrote:
> > Changes/breaking in API not necessarily are so bad, as long as
> > the tools which are helping user to switch to new API are provided.
>
> Yah, I've tried that in the past and my experience is something goes
> wrong and you ulimately end up with annoyed users.
>
> > In this case writing such tool - POM transformer seem to be fairly easy.
>
> It is, but don't assume anyone else will find it easy. I would really
> just leave the old method
>

I will leave it.

That was just an idea. Vincent convinced me with his argumentation.

regards
Michal



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

RE: [war plugin] - Proposition by default include instead ofexclude

[Michal Maczka]

> -Original Message-
> From: Jason van Zyl [mailto:[EMAIL PROTECTED]
> Sent: Saturday, July 05, 2003 11:52 PM
> To: Maven Developers List
> Subject: RE: [war plugin] - Proposition by default include instead
> ofexclude
>
>
> On Sat, 2003-07-05 at 17:24, Michal Maczka wrote:
> > > -Original Message-
> > > From: Vincent Massol [mailto:[EMAIL PROTECTED]
> > > Sent: Saturday, July 05, 2003 10:57 PM
> > > To: 'Maven Developers List'
> > > Subject: RE: [war plugin] - Proposition by default include
> > > instead of exclude
> > >
> > >
> > > I think I'm -1 for making this change now. As you say there
> are just too
> > > many who are using it the other way.
> > >
> > But from the other hand - such change will be never easier from this
> > perspective
> > and there are much more "painful" changes coming (e.g. naming schema of
> > plugins' properties)
> > I think that we have a right to change things even drastically
> while maven
> > in still in beta stage.
>
> I think you should look at how you specify what you want in the WAR, I
> think having properties within dependencies that affect the way plugins
> work is not very good. I would say leave the current way as it is and
> look for a better solution. Try to determine how you could isolate what
> you want bundled, or more generally how to specify properties for
> plugins.
>
> I have started cleaning up some of the plugin property access and marked
> them as requirements for 1.0. You might want to do the same with plugin
> properties that are defined in the POM. I think the war.bundle thing is
> fairly bad as it started a bad trend of looking for hints in the
> dependencies themselves.
>

I agree. The best strategy will be to make something in the spirit
of what we discussed some time ago
I mean e.g. somehow distinguish between "runtime", "test" "compile"  deps
So say in case of war plugin all "runtime" dependencies should
be bundled. And no special (plugin specific) way of marking will be needed.

I will leave this subject until we will define what those terms
mean and how we will denote them. As I am afraid that once
we will progress in this field ...changes will be needed anyway.

This case has also other background. We are discussing about
changes in peripheral plugin (for sure maven-war-plugin is not a core
plugin)
and we are associating changes in this plugin with release of entire maven.

For the moment I agree with Vincent that as long as do this and
we are releasing this plugin along with maven core (or maven as a "whole")
and we have no means to define dependencies on particular version of plugin,
we should keep it backward compatible.


Michal



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

RE: [war plugin] - Proposition by default include instead ofexclude

[Michal Maczka]

Changes/breaking in API not necessarily are so bad, as long as
the tools which are helping user to switch to new API are provided.

In this case writing such tool - POM transformer seem to be fairly easy.

But I was also convinced by Vincent.

regards

Michal

> -Original Message-
> From: Juergen Heidak [mailto:[EMAIL PROTECTED]
> Sent: Saturday, July 05, 2003 11:51 PM
> To: Maven Developers List
> Subject: RE: [war plugin] - Proposition by default include instead
> ofexclude
>
>
> Hi
>
> Breaking API's or configuration settings is always bad. The much better
> way is to keep compatibility and make the new feature configurable so
> that it can be turned on easily.
>
> I dont use the war plugin I just wanted to say that I agree with
> Vincent.
>
> Regards
>
>
> > > >
> > > >
> > > > I think I'm -1 for making this change now. As you say there are just
> > too
> > > > many who are using it the other way.
> > > >
> > > But from the other hand - such change will be never easier from this
> > > perspective
> > > and there are much more "painful" changes coming (e.g. naming schema
> > of
> > > plugins' properties)
> > > I think that we have a right to change things even drastically while
> > maven
> > > in still in beta stage.
> >
> > I think I'll disagree here (and lot of person will also disagree with
> > me). OpenSource projects has the word open in it. That is person will
> > start to use it if they think it is useful. And Maven certainly is. The
> > fact that it's been more than 1 year without any release is indeed
> > problematic but persons who like Maven have to live with this. I am one
> > of them and I use Maven on big production projects.
> >
> > My view is that when you're doing open source development you have to
> > respect your user base. It is your duty to do so. Some projects have a
> > problem with doing releases and Maven is one of them. MockObjects is
> > another one (it is still at version 0.09). This is not right.
> >
> > The very least you can do is make it painless for your users and avoid
> > breaking things at each beta release.
> >
> > >
> > > I agree that for some users this will be a bit painful, but for those
> > who
> > > are going
> > > to start using maven or for those who are just going to make another
> > > webapp
> > > with maven, this change means simplification.
> >
> > I don't agree. I'm using the war plugin on a big project (5 years span,
> > 200 persons, 70 developers, 2 geographic locations, 300+ Maven
> > projects). I'm also using it on about 3-4 other projects. It's working
> > for us and it's never been a pain to declare our war dependencies.
> >
> > Now, if you want to break APIs, I'd suggest we release Maven 1.0 and
> > start working on Maven 2.0. But we *MUST* release 1.0 before.
> >
> > Now, I don't know if you were already working on Maven but not long ago,
> > the Maven team decided that from now on (that was about 2-3 months ago)
> > there would be no breaking of APIs and that we would put all our efforts
> > in fixing bugs and release 1.0...
> >
> > I don't believe this promise has been completely fulfilled but we have
> > tried. And adding more incompatibilities will not help.
> >
> > I'll continue to veto this change. I'm still -1 :-)
> >
> > -Vincent
> >
> > >
> > >
> > > > I'm +0 if you want to introduce a war plugin property such as:
> > > >
> > > > maven.war.dependency.behavior=exclude|include
> > > >
> > > > so that the current behavior is the default.
> > > >
> > > Also thought about that.
> > > If still prefer to update my POMs... but certainly this is an option.
> > >
> > >
> > > regards
> > >
> > > Michal
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> --
> SPORT!!! Wyniki na zywo!!! >>> http://link.interia.pl/f174a
>
>
>



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

RE: [war plugin] - Proposition by default include instead of exclude

[Michal Maczka]

> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: Saturday, July 05, 2003 10:57 PM
> To: 'Maven Developers List'
> Subject: RE: [war plugin] - Proposition by default include
> instead of exclude
>
>
> I think I'm -1 for making this change now. As you say there are just too
> many who are using it the other way.
>
But from the other hand - such change will be never easier from this
perspective
and there are much more "painful" changes coming (e.g. naming schema of
plugins' properties)
I think that we have a right to change things even drastically while maven
in still in beta stage.

I agree that for some users this will be a bit painful, but for those who
are going
to start using maven or for those who are just going to make another webapp
with maven, this change means simplification.


> I'm +0 if you want to introduce a war plugin property such as:
>
> maven.war.dependency.behavior=exclude|include
>
> so that the current behavior is the default.
>
Also thought about that.
If still prefer to update my POMs... but certainly this is an option.


regards

Michal



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

[war plugin] - Proposition by default include instead of exclude

[Michal Maczka]

I realized that in POMs of my web projects I have very long lists
of dependencies marked with:

 
   ...
   
 true
   
 


I always want to "bundle" most of deps (or all of them)
while if I exclude I do exclude only few of them


I think that war plugin will be bit easier to use if by default
all dependencies are bundled and only those specially marked:



   ...
   
 false
   
 

will be excluded.

Anybody will oppose if I will change the war plugin and make it work this
way.

I do believe that this is a change for better ... but also I myself will
have to edit
a lot POMs, that's why I prefer to know opinion of other users of this
plugin.

Michal



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

Hibernate Plugin

[Michal Maczka]

Is somebody using maven-hibernate-plugin?

I as the author have used it only for my particular needs.
The functionality of this plugin very limited and I 
believe that it has not yet reached the release quality.
As at the moment I don't really use hibernate nor have good knowledge of
this library - So I am not planning to improve this plugin in next couple of
days/weeks.

Is there somebody really interested in existence of this plugin?

In the current state of this plugin I would rather prefer
to have it removed from CVS repository then to release it together with
maven beta-10.

I will try to contact hibernate team and ask them if they will be interested
in maintaining "their own" plugin which seems to me to be the best option.

Other option will be to have something like maven-incubator:
the place when some plugins are getting more mature.

Any comments?

Michal

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

RE: cvs commit: maven/src/plugins-build/ejb plugin.jelly

[Michal Maczka]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 04, 2003 8:33 AM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: maven/src/plugins-build/ejb plugin.jelly
> 
> dion2003/07/03 23:32:37
> 
>   Modified:src/plugins-build/ejb plugin.jelly
>   Log:
>   Add fixme for problem I don't know how to fix just yet.
> 


[...]
 
>   dir="${maven.repo.local}/${dep.artifactDirectory}/jars/">
>
>  
> 


  



does a trick
I will fix this.

regards
mm

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

RE: cvs commit: maven/src/plugins-build/multiproject project.xml plugin.jelly plugin.properties

[Michal Maczka]

Just added new functionality to multiproject plugin (ex-reactor)
Comments much appreciated.

Basically I implemented "group" install, deploy facility for
subprojects

Michal

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 03, 2003 10:42 PM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: maven/src/plugins-build/multiproject project.xml
> plugin.jelly plugin.properties
>
>
> michal  2003/07/03 13:41:36
>
>   Modified:src/plugins-build/multiproject/xdocs changes.xml goals.xml
> properties.xml
>src/plugins-build/multiproject project.xml plugin.jelly
> plugin.properties
>   Log:
>   Added multiproject 'install', 'install-snapshot', 'deploy' and
> 'deploy-snapshot' facility
>
>   Revision  ChangesPath
>   1.2   +4 -0
> maven/src/plugins-build/multiproject/xdocs/changes.xml
>
>   Index: changes.xml
>   ===
>   RCS file:
> /home/cvs/maven/src/plugins-build/multiproject/xdocs/changes.xml,v
>   retrieving revision 1.1
>   retrieving revision 1.2
>   diff -u -r1.1 -r1.2
>   --- changes.xml 30 Jun 2003 03:18:49 -  1.1
>   +++ changes.xml 3 Jul 2003 20:41:36 -   1.2
>   @@ -7,6 +7,10 @@
>
>  
>
>   +  
>   +Added multiproject 'install', 'install-snapshot',
> 'deploy' and 'deploy-snapshot'
>   +facility
>   +  
>  
>Rename plugin from reactor to multiproject to reduce confusion
>  
>
>
>
>   1.2   +54 -7
> maven/src/plugins-build/multiproject/xdocs/goals.xml
>
>   Index: goals.xml
>   ===
>   RCS file:
> /home/cvs/maven/src/plugins-build/multiproject/xdocs/goals.xml,v
>   retrieving revision 1.1
>   retrieving revision 1.2
>   diff -u -r1.1 -r1.2
>   --- goals.xml   30 Jun 2003 03:18:49 -  1.1
>   +++ goals.xml   3 Jul 2003 20:41:36 -   1.2
>   @@ -4,6 +4,7 @@
>  
>Maven Multi-Project Plug-in Goals
>dIon Gillard
>   +Michal Maczka
>  
>  
>
>   @@ -12,12 +13,58 @@
>Run the site goal of all projects
>  
>  
>   -multiproject:site
>   -Run the site goal of all projects
>   +multiproject:install
>   +
>   +  Run 'artifact':install goal for all project.
>   +  
>   +  'artifact' is replaced by the value of property
>   +  maven.multiproject.type which should be set
>   +  individualy for each project.
>   +  
>   +  E.g. if we have projects A, B and C
>   +  with following settiing:
>   +  
>   +A: maven.multiproject.type=war
>   +B: maven.multiproject.type=ejb
>   +C: maven.multiproject.type=jar
>   +  
>   +  
>   +  Following goals will be run:
>   +  
>   +A: war:install
>   +B: ejb:install
>   +C: jar:install
>   +  
>   +
>   +  
>   +  
>   +multiproject:install-snapshot
>   +
>   +  Run 'artifact':install-snapshot goal
> for all projects.
>   +
>  
>   -
>   -  multiproject:goal
>   -  
>   +  
>   +multiproject:deploy
>   +
>   +  Run 'artifact':install-snapshot goal
> for all projects.
>   +
>   +  
>   +  
>   +multiproject:deploy-snapshot
>   +
>   +  Run 'artifact':install-snapshot goal
> for all projects.
>   +
>   +  
>   +  
>   +multiproject:artifact
>   +
>   +  Run 'artifact':'artifact' goal for all projects.
>   +
>   + +
>   +  
>   +multiproject:goal
>   +
>  Run the comma separated list of goals provided
> by the variable goal for all projects
>  e.g.
>  
>   @@ -27,8 +74,8 @@
>  
>  maven -Dgoal=clean,java:compile,test
> multiproject:goal
>  
>   -  
>   -
>   +
>   +  
>
>  
>
>
>
>
>   1.2   +24 -0
> maven/src/plugins-build/multiproject/xdocs/properties.xml
>
>

RE: smart reactor proposal

[Michal Maczka]

my two cents:

I agree we Mark:
the decision if goal should be started or not should
belong purely to this goal and is out of the scope of the rector.

It's kind of micro-scale decision.

Using this strategy we can speed up the execution of most of the goals and
reactor will profit from this strategy for free.

So I say: we need timestamp files and other ways of expressing condition
when given goal should be started and when not. 


I also agree with Mark:
This will be painful do to in jelly.

But I am almost sure that this has nothing to do with reactor itself.

Michal


> -Original Message-
> From: Mark H. Wilkinson [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 02, 2003 12:34 PM
> To: Maven Developers List
> Subject: Re: smart reactor proposal
> 
> On Wed, 2003-07-02 at 12:18, Jason van Zyl wrote:
> > On Wed, 2003-06-04 at 05:47, Aslak Hellesøy wrote:
> > > I think this can be implemented quite simply by doing some date
> > > comparisons between java sources and classes in each project.
> >
> > Did you ever make any progress on this because I was going to add some
> > stuff to JIRA about uptodate checks in general for docs. There are some
> > checking utilities in CruiseControl and there is some stuff in DVSL
> > itself so I'm going to steal something and make a general tool.
> 
> Hrrm; I started writing up my thoughts on this yesterday to save for
> after 1.0 was out, but I guess I should air them now. Basically, I think
> that the problem is that neither ant nor maven currently do dependency
> checking in the way make used to, and I think that this hurts maven more
> than ant because maven's plugin system leads to larger graphs that
> describe the build system. The following is quite long, but hopefully it
> explains the problem. (Well, what *I* think is a problem, anyway. I'm
> sure others will likely disagree with my opinions... :-)
> 
> In a nutshell, make builds a dependency graph where the nodes are files,
> arcs are dependencies and arcs are annotated with commands that can be
> used to bring files up to date if their timestamps indicate that
> something is out of date.
> 
> Ant builds a dependency graph where the nodes are scripts and the arcs
> describe the order in which the scripts ought to be run.
> 
> When you run make you tell it which file you want it to build, and it
> works out the minimum set of commands that need to be run to make sure
> that file is up to date.
> 
> When you run ant you tell it which script you want it to run, and it
> works out all the scripts which are required to be run before it. It
> then runs every single script, whether needed or not. Some scripts
> include statements that take a bit of time to execute, so those
> statements make local decisions about what they need to do based on
> timestamps, but there's no overall mechanism for file timestamp
> dependency checking in build.xml because the dependency graph just
> doesn't model that kind of thing.
> 
> Maven at the moment is kind-of like ant, with a bunch of plugins that
> build a similar dependency graph to describe an idealised build system.
> So you get a nice complete build system without having to write a 500
> line build.xml. But it's still just a dependency graph that connects
> scripts (goals) together.
> 
> The reactor resolves dependencies at a different level - where ant (and
> normal maven execution) satisfies dependencies between scripts, reactor
> satisfies dependencies between artifacts required by one project.xml and
> those built by another project.xml. It presumably builds a dependency
> graph between Projects based on artifact ids, and then works out an
> ordering over those projects.
> 
> So the reactor takes multiple script-dependency graphs and works out an
> ordering for running named scripts in every project. Not surprisingly
> this can lead to maven spending lots of time just running scripts, even
> if those scripts don't need to be executed.
> 
> One solution to this would be to make more of the individual statements
> check timestamps before they run, but this is not easy. It needs logic
> adding to every piece of processing that can take a significant amount
> of time. It's harder for things that are written in jelly because
> there's currently no mechanism for checking timestamps (I think - and I
> guess this might be the kind of solution that Jason's alluding to
> above).
> 
> But having done this, maven would still need to run the entire script
> chain so that each statement can confirm that nothing needs to be done.
> 
> Another solution is to try to short-circuit the reactor, with some kind
> of check to decide on a project-by-project basis whether a build needs
> to be done or not. I think this is what Aslak's suggesting.
> 
> I'm wondering if there's a fundamental reason why we couldn't change
> maven to build a dependency graph of files with scripts attached to the
> arcs, just like make used to do. Statements and scripts would need a way
> to expose the lists o

RE: cvs commit: maven/src/plugins-build/ear/xdocs changes.xml

[Michal Maczka]

Dion!

Can you check my second commit from yesterday?
I hope that I fixed all the issues.

Michal

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 02, 2003 2:57 AM
> To: Maven Developers List
> Subject: Re: cvs commit: maven/src/plugins-build/ear/xdocs changes.xml
> 
> [EMAIL PROTECTED] wrote on 01/07/2003 06:45:14 PM:
> 
> > michal  2003/07/01 01:45:14
> >
> >   Modified:src/plugins-build/ear plugin.jelly
> >src/plugins-build/ear/xdocs changes.xml
> >   Log:
> >   o Iterating over artifacts not deps
> >
> >   o Added deploy, deploy-snapshot and install-shapshot goals
> >
> >   Revision  ChangesPath
> >   1.9   +77 -21maven/src/plugins-build/ear/plugin.jelly
> >
> >   Index: plugin.jelly
> >   ===
> >   RCS file: /home/cvs/maven/src/plugins-build/ear/plugin.jelly,v
> >   retrieving revision 1.8
> >   retrieving revision 1.9
> >   diff -u -r1.8 -r1.9
> >   --- plugin.jelly   17 Jun 2003 17:57:47 -   1.8
> >   +++ plugin.jelly   1 Jul 2003 08:45:13 -   1.9
> >   @@ -6,6 +6,7 @@
> >  xmlns:license="license"
> >  xmlns:util="jelly:util"
> >  xmlns:x="jelly:xml"
> >   +  xmlns:artifact="artifact"
> >  >
> >
> >
> 
> >   @@ -48,7 +49,8 @@
> >excludes="**/META-INF/application.xml"/>
> >
> >  
> >   -  
> >   +  
> >   +
> >
> >  Bundling: ${dep.type}
> >  
> >   @@ -57,8 +59,8 @@
> >   
> >  
> >
> >   -
> >   -  
> >   +
> >   +  
> I don't get this. Since when do ears get bundled into ear files?? Why was
> this changed from war?
> 
> And do we really want to use dep.artifactDirectory again rather than
> artifact.path?
> 
> [snip]
> >
> 
> >  
> >   @@ -132,14 +121,15 @@
> > >
> >
> > name="display-name">${maven.ear.displayname}
> >   -
> >   +
> >   + 
> >  
> >
> >   -  
> >   +  
> Again,
> why is an ear file being bundled within an ear? This makes no sense...
> 
> 
> --
> dIon Gillard, Multitask Consulting
> Blog:  http://blogs.codehaus.org/people/dion/
> Work:  http://www.multitask.com.au


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

RE: cvs commit: maven/src/plugins-build/war/xdocs changes.xml goals.xml

[Michal Maczka]

> Is the dep.type check here really necessary? If the user has added the
> war.bundle property, then I say let it go in there. It could be an
> ejb-client jar file in which case the  may not be jar.
> 
> >   -  
> >   -
> >   +
> Ditto.
> 

For the moment only jars can go into war.

I made this type-sensitive bundling while I was planning
to support also other types of artifacts (e.g. "tld").
Those artifacts sometimes should be bundled is a different way and in some
cases won't go to  WEB-INF\lib. 

I hope that more complex artifact like "webcomponent" (e.g collection of
css, js, images) will be supported in near feature.


If you feel that current implementation is to strict we can change it.


BTW: It will be nice to have selectors of artifact


Pom.getArtifcats("jar", "war.bundle")

Will return all jars which should be bundled in the war.


Michal


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

RE: cvs commit: maven/src/plugins-build/cactus/xdocs changes.xml

[Michal Maczka]

Shouldn't you be doing:


 
   
 
   
 


See Maven-518 for explanations why.


regards

Michal

P.S.

I did such changes to war, ear plugin and  plan to do the same to eclipse
plugin.
We won't need to set MAVEN_REPO in eclipse workbench.






>   +   Cactus test but not in a runtime war -->
>   +  
>   +
>   +   file="${maven.repo.local}/${dep.artifactDirectory}/jars/${dep.artifact}"/>
>   +
>   +  
>   +
>
>
>  
>
>



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