Re: [RANT] This Maven thing is killing us....

[Brett Porter]

On 6/07/2006 2:19 AM, Mark Hobson wrote:

Could we not use the syntax 3.7 to represent 'the latest revision of
3.7', whereas 3.7-1 would lock the version down to 3.7 rev 1?  So
during development people could use 3.7 to allow updated revisions of
the pom to be pushed to them, and then for reproducable builds they
could use the 3.7-1 syntax.

The release plugin could fully-qualify any version numbers of the form
3.7 to the currently-used revision, e.g. 3.7-1, at release time.


This is actually how I'd originally designed it to work (using newest 
instead of nearest, with ranges much more common). Will have to come 
back to that in 2.1 :)


Anyway, I think it's currently debatable whether a -1 release is enough 
for this case. I'd really like to investigate a "vendor" element of the 
version that allows people that aren't the original project to 
modify/repackage their releases without screwing up the dependency model.


- Brett

--
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

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

Re: [RANT] This Maven thing is killing us....

[Brett Porter]

I think we need the necessary auditing in the repository manager for 
this first, but it's worth moving on. I'm trying to get that up and 
running right now, and writing some internal docs so others can dig in 
and do stuff like this.


The ideal is actually to have those segments of the repository managed 
by the projects themselves, of course.


- Brett

On 6/07/2006 2:32 AM, Alexandre Poitras wrote:

+1, really great idea.

On 7/5/06, Mark Hobson <[EMAIL PROTECTED]> wrote:

On 05/07/06, Arik Kfir <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> A while back I suggested that the Maven team delegate some of the
> reponsibility of maintaining the ibiblio repo to volunteers (as in 
the linux
> equivalent, as Jerome has noted earlier in the thread). Each such 
voluteer
> can maintain a specific area in the repo; so, someone who uses 
hibernate
> frequently can maintain its poms, until the hibernate team agrees to 
do it

> for us.
>
> The idea was generally accepted by brett, with a slight modification 
that
> volunteers go through a screening process, just like normal commit 
access is
> provisioned (someone who submits enough pom patches will slowly be 
given

> commit access to ibiblio).
>
> for more info, see
> http://www.nabble.com/critique-of-maven-2.0.2-tf1052845.html#a2738495
>
> perhaps it is time to move this forward?

Definitely +1 to seeing the ibiblio repostory devolving responsibility
to smaller, more managable, repositories - ideally maintained by
developers closer to the hosted projects.

Mark

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




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




--
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

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

Re: [RANT] This Maven thing is killing us....

[Brett Porter]

On 7/07/2006 4:58 PM, Jörg Schaible wrote:

You may also have the need to exclude a version in that range because of a 
critical bug. E.g. proxytoys run with CGLIB 2.0, 2.0.2 and 2.1.x ... but not 
with 2.0.1, that one had introduced a major bug, that broke proxytoys.


you can already do that from the dependees end:
[2.0],[2.0.2,) or [2.0],[2.0.2],[2.1,) depending on if 2.0.3 <= x < 2.1 
are any good.


From a releasers end, I'm inclined to say they should pull the release, 
but since some people may have already gotten it metadata that says 
"this release is totally broken" that warns new users might be better.


- Brett

--
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

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

Re: [RANT] This Maven thing is killing us....

[Brett Porter]

On 6/07/2006 1:32 AM, jerome lacoste wrote:

- they typically use a versionning similar to x.y.z-n sometimes
adding. -n can be used to fix packaging issues (POM in the case of
maven). Vendor fixes are also accepted and version names reflect the
vendor name.


Yep, already have that for that very reason (calling it build number in 
hindsight was not the greatest choice :)




- the distributions with the best repositories typically require the
package to be buildable from source. The build is tested in a separate
environment where all the required build dependencies are listed, to
make sure that the dependency list is accepted. Something similar
should maybe be done before accepting a project on a POM, setting up a
build environment based on the given pom.


This seems like a good idea in theory, but our situation is different 
for the following reasons:

- we may not always have the source
- this assumes that the dependency list is used to build the project 
(which assumes they build with m2). We could take a stab at anything 
using ant by doing what gump does, though, so it's worth a shot.
- we are actually distributing the originally released artifact rather 
than rebuilding and repackaging like most distros. They also go ahead to 
test their repackaging, something we can't afford to do.



- number of versions of a particular package in a repo is reduced to a
minimum. users are adviced to upgrade to the latest & greatest to make
sure that fixes are always present in the last released versions


And it is almost impossible to build stuff that targetted older releases 
of the OS (look what happened with the various incompatible 
autoconf/automake releases, gcc2 -> 3 -> 4, etc).


Makes sense for a stable OS, not so much a build system.


- responsibilities of preparing packages is spread around 10s of
people. Packages are orphaned when no one is taking care of them.
People can reuse tricks/scripts learned by former packagers to go on
with the job.


I think we are already on the way to this. Better docs and tooling needed.



- use of provides and various other dependency markers (that's coming
in m2 2.1 if I got it right)


Yup.

- Brett

--
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

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

RE: [RANT] This Maven thing is killing us....

[Jörg Schaible]

Hi Brett,

Brett Porter wrote on Friday, July 07, 2006 8:49 AM:

> On 6/07/2006 3:40 AM, Rinku wrote:
[snip]
>> The other thing is that when an artifact is published to a repo, the
>> publisher can add some compatibility meta-data as well to indicate
>> that the current version is incompatible with certain other versions
>> or the artifacts.
> 
> Yes, this would be a good addition to 2.1 - I think it is
> already in the
> wiki (but should be added if not).
> 
> This would only need to affect open-upper-ended ranges (including soft
> versions). So for junit, if we assumed 4.0 was not compatible with <
> 4.0, ranges would change like this:
> 
> [3.8,) --> [3.8,4.0)
> [3.8,4.1] --> unchanged (the range explicitly allows the
> incompatibility, maybe a warning)
> (,5.0] --> unchanged (the range explicitly allows the incompatibility,
> maybe a warning)
> 3.8 --> (,4.0) (suggest 3.8)
> 
> Then the normal logic could kick in.

You may also have the need to exclude a version in that range because of a 
critical bug. E.g. proxytoys run with CGLIB 2.0, 2.0.2 and 2.1.x ... but not 
with 2.0.1, that one had introduced a major bug, that broke proxytoys.

- Jörg

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

Re: [RANT] This Maven thing is killing us....

[Brett Porter]

On 6/07/2006 3:40 AM, Rinku wrote:
Just wondering if rather than having an  list stuffed in each 
of  elements, if we could have some sort of   
tag that can 'advise' Maven the choosing strategy for conflicting 
artifacts (pretty much like version ranges).


For sake of an example:

 
   
   junit
   junit
   3.8.2
<=3.8.2 
   
   . . .
  

So, Maven can safely choose 3.8.2 for all varying versions JUnit less 
than or equal to 3.8.2, but not 4.0.


That's no different to (,3.8.2] now.



The other thing is that when an artifact is published to a repo, the 
publisher can add some compatibility meta-data as well to indicate that 
the current version is incompatible with certain other versions or the 
artifacts.


Yes, this would be a good addition to 2.1 - I think it is already in the 
wiki (but should be added if not).


This would only need to affect open-upper-ended ranges (including soft 
versions). So for junit, if we assumed 4.0 was not compatible with < 
4.0, ranges would change like this:


[3.8,) --> [3.8,4.0)
[3.8,4.1] --> unchanged (the range explicitly allows the 
incompatibility, maybe a warning)
(,5.0] --> unchanged (the range explicitly allows the incompatibility, 
maybe a warning)

3.8 --> (,4.0) (suggest 3.8)

Then the normal logic could kick in.

- Brett

--
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

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

Re: [RANT] This Maven thing is killing us....

[Alexandre Poitras]

Or can't Maven offer you to upgrade like it does with plugin (or use to)?

On 7/5/06, Jesse McConnell <[EMAIL PROTECTED]> wrote:

yep, totally...its just that 3.7 should never be 'fuzzy' from a
dependency standpoint unless it is 3.7-SNAPSHOT or this new idea of
incrementing pom versions for same jar.

in freebsd versioning this would be equivalent to something like
treating this 3.7-1 deal as 3.7-STABLE which could be treated just
like the -SNAPSHOT.  Difference being that 3.7-STABLE refers to the
evolution of metadata surrounding tne 3.7 release whereas -SNAPSHOT
refers to evolution of the underlying code.

jesse

On 7/5/06, Mark Hobson <[EMAIL PROTECTED]> wrote:
> On 05/07/06, Jesse McConnell <[EMAIL PROTECTED]> wrote:
> > might be better off using the version ranges notation for this kind of
> > thing, I don't think you want to get into the habit of x.y being some
> > kinda fuzzy defintion, it should refer to a specific version.
> >
> > [3.7,) or something along those lines...
> >
> > 
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
> >
> > then when it comes to your release time, pin it down to a specific
> > version of the pom for release
>
> I did think of ranges, but even atm 3.7 is just a 'soft' version -
> merely a recommendation.  This notion could be extended to accommodate
> the above, with it becoming the 'hard' version [3.7-1] at release
> time.
>
> Mark
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
jesse mcconnell
jesseDOTmcconnellATgmailDOTcom

-
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: [RANT] This Maven thing is killing us....

[Steve Loughran]

jerome lacoste wrote:

On 7/5/06, Steve Loughran <[EMAIL PROTECTED]> wrote:

Ralph Goers wrote:
>
>
> Carlos Sanchez wrote:
>>
>> Yes you can, it's not the best way to do it but you can, by adding
>> explicitly the dependency with the versoin you want to your pom. In
>> the very worst case you have to add all transitive deendencies to your
>> pom, like in Maven 1.



[..]

I've been following this thread with interest.


Its an interesting discussion. Although the topic is how maven builds, 
the underlying issue is how to do late binding to library versions 
without things breaking...its one aspect of the whole 
configuration-management problem.



It makes me think of the various problems Linux distribution have to
deal with when making their own repositories. It took 10 years for
these solutions to be what they are today. I really think some ideas
should be reused, even though the goals are slightly different.


I need to research these more. One issue I have with the linux world is 
that they tend to require that a system only has a single version of a 
package installed on a machine; they dont really support side-by-side 
stuff. So if you install jdk-1.4.2 and lib-gtk-2.0.4 then you are 
expected to uninstall jdk-1.4.0 and lib-gtk-2.0.3. In java, excluding 
stuff in the JVM/JRE itself, and that endorsed directory mistake, you 
can have any number of JARs around and each process gets to choose the 
entire set of libraries to depend on.


Except of course if you use the sun manifest.mf way of specifying 
dependencies, that just sucks, because you have to hard code in a 
relative/absolute path to every JAR in the JAR file itself.




Some features/ways of working that may or may not be applicable:

- they typically use a versionning similar to x.y.z-n sometimes
adding. -n can be used to fix packaging issues (POM in the case of
maven). Vendor fixes are also accepted and version names reflect the
vendor name.

- the distributions with the best repositories typically require the
package to be buildable from source. The build is tested in a separate
environment where all the required build dependencies are listed, to
make sure that the dependency list is accepted. Something similar
should maybe be done before accepting a project on a POM, setting up a
build environment based on the given pom.

- number of versions of a particular package in a repo is reduced to a
minimum. users are adviced to upgrade to the latest & greatest to make
sure that fixes are always present in the last released versions


I could make some negative comments about linux backwards compatibility 
here.


One person's bug fix is another person's "unexpected change in system 
behaviour". This is why on qualified systems, you dont change 
*anything*, if you can help it, even OS security patches are carefully 
assessed before rollout.




- responsibilities of preparing packages is spread around 10s of
people. Packages are orphaned when no one is taking care of them.
People can reuse tricks/scripts learned by former packagers to go on
with the job.


yes, there is a good spread of participants. and the distros take on the 
job of integrating everything.


-steve

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

Re: [RANT] This Maven thing is killing us....

[Rinku]

Just wondering if rather than having an  list stuffed in each 
of  elements, if we could have some sort of   
tag that can 'advise' Maven the choosing strategy for conflicting 
artifacts (pretty much like version ranges).


For sake of an example:

 
   
   junit
   junit
   3.8.2
<=3.8.2 
   
   . . .
  

So, Maven can safely choose 3.8.2 for all varying versions JUnit less 
than or equal to 3.8.2, but not 4.0.


The other thing is that when an artifact is published to a repo, the 
publisher can add some compatibility meta-data as well to indicate that 
the current version is incompatible with certain other versions or the 
artifacts.


Just a thought...

Cheers
Rahul




  

  
  



  

 



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

Re: [RANT] This Maven thing is killing us....

[Jesse McConnell]

yep, totally...its just that 3.7 should never be 'fuzzy' from a
dependency standpoint unless it is 3.7-SNAPSHOT or this new idea of
incrementing pom versions for same jar.

in freebsd versioning this would be equivalent to something like
treating this 3.7-1 deal as 3.7-STABLE which could be treated just
like the -SNAPSHOT.  Difference being that 3.7-STABLE refers to the
evolution of metadata surrounding tne 3.7 release whereas -SNAPSHOT
refers to evolution of the underlying code.

jesse

On 7/5/06, Mark Hobson <[EMAIL PROTECTED]> wrote:

On 05/07/06, Jesse McConnell <[EMAIL PROTECTED]> wrote:
> might be better off using the version ranges notation for this kind of
> thing, I don't think you want to get into the habit of x.y being some
> kinda fuzzy defintion, it should refer to a specific version.
>
> [3.7,) or something along those lines...
>
> 
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
>
> then when it comes to your release time, pin it down to a specific
> version of the pom for release

I did think of ranges, but even atm 3.7 is just a 'soft' version -
merely a recommendation.  This notion could be extended to accommodate
the above, with it becoming the 'hard' version [3.7-1] at release
time.

Mark

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





--
jesse mcconnell
jesseDOTmcconnellATgmailDOTcom

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

Re: [RANT] This Maven thing is killing us....

[Mark Hobson]

On 05/07/06, Jesse McConnell <[EMAIL PROTECTED]> wrote:

might be better off using the version ranges notation for this kind of
thing, I don't think you want to get into the habit of x.y being some
kinda fuzzy defintion, it should refer to a specific version.

[3.7,) or something along those lines...

http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution

then when it comes to your release time, pin it down to a specific
version of the pom for release


I did think of ranges, but even atm 3.7 is just a 'soft' version -
merely a recommendation.  This notion could be extended to accommodate
the above, with it becoming the 'hard' version [3.7-1] at release
time.

Mark

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

Re: [RANT] This Maven thing is killing us....

[Jesse McConnell]

might be better off using the version ranges notation for this kind of
thing, I don't think you want to get into the habit of x.y being some
kinda fuzzy defintion, it should refer to a specific version.

[3.7,) or something along those lines...

http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution

then when it comes to your release time, pin it down to a specific
version of the pom for release

jesse

On 7/5/06, Mark Hobson <[EMAIL PROTECTED]> wrote:

On 05/07/06, Steve Loughran <[EMAIL PROTECTED]> wrote:
> OK, but the other part of the problem is pushing the changes out to the
> user.
>
> in a linux distro, what you are effectively buying is a set of artifacts
> compiled on the same gcc version/options, and a subscription that keeps
> your box up to date. They are usually manual or cron updates.
>
> If you're using an artifact 3.7, and the pom goes to 3.7-1, you need to
> get that new pom, without having your stuff updated. Except when you
> dont, of course, because you've just QA'd everything against a previous
> version and dont want stuff with new metadata creeping in.

Could we not use the syntax 3.7 to represent 'the latest revision of
3.7', whereas 3.7-1 would lock the version down to 3.7 rev 1?  So
during development people could use 3.7 to allow updated revisions of
the pom to be pushed to them, and then for reproducable builds they
could use the 3.7-1 syntax.

The release plugin could fully-qualify any version numbers of the form
3.7 to the currently-used revision, e.g. 3.7-1, at release time.

Mark

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





--
jesse mcconnell
jesseDOTmcconnellATgmailDOTcom

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

Re: [RANT] This Maven thing is killing us....

[Alexandre Poitras]

+1, really great idea.

On 7/5/06, Mark Hobson <[EMAIL PROTECTED]> wrote:

On 05/07/06, Arik Kfir <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> A while back I suggested that the Maven team delegate some of the
> reponsibility of maintaining the ibiblio repo to volunteers (as in the linux
> equivalent, as Jerome has noted earlier in the thread). Each such voluteer
> can maintain a specific area in the repo; so, someone who uses hibernate
> frequently can maintain its poms, until the hibernate team agrees to do it
> for us.
>
> The idea was generally accepted by brett, with a slight modification that
> volunteers go through a screening process, just like normal commit access is
> provisioned (someone who submits enough pom patches will slowly be given
> commit access to ibiblio).
>
> for more info, see
> http://www.nabble.com/critique-of-maven-2.0.2-tf1052845.html#a2738495
>
> perhaps it is time to move this forward?

Definitely +1 to seeing the ibiblio repostory devolving responsibility
to smaller, more managable, repositories - ideally maintained by
developers closer to the hosted projects.

Mark

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




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

Re: [RANT] This Maven thing is killing us....

[Mark Hobson]

On 05/07/06, Arik Kfir <[EMAIL PROTECTED]> wrote:

Hello all,

A while back I suggested that the Maven team delegate some of the
reponsibility of maintaining the ibiblio repo to volunteers (as in the linux
equivalent, as Jerome has noted earlier in the thread). Each such voluteer
can maintain a specific area in the repo; so, someone who uses hibernate
frequently can maintain its poms, until the hibernate team agrees to do it
for us.

The idea was generally accepted by brett, with a slight modification that
volunteers go through a screening process, just like normal commit access is
provisioned (someone who submits enough pom patches will slowly be given
commit access to ibiblio).

for more info, see
http://www.nabble.com/critique-of-maven-2.0.2-tf1052845.html#a2738495

perhaps it is time to move this forward?


Definitely +1 to seeing the ibiblio repostory devolving responsibility
to smaller, more managable, repositories - ideally maintained by
developers closer to the hosted projects.

Mark

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

Re: [RANT] This Maven thing is killing us....

[Carlos Sanchez]

I remember more or less who makes good upload requests and who doesn't ;)

Anyway that's why the field in jira proving that you're a member of
the project is. If you are member and you request an upload that goes
directly without checking correctness if the group already exist.

We can start a wiki with people volunteering for projects that don't
collaborate.

On 7/5/06, Arik Kfir <[EMAIL PROTECTED]> wrote:

Hello all,

A while back I suggested that the Maven team delegate some of the
reponsibility of maintaining the ibiblio repo to volunteers (as in the linux
equivalent, as Jerome has noted earlier in the thread). Each such voluteer
can maintain a specific area in the repo; so, someone who uses hibernate
frequently can maintain its poms, until the hibernate team agrees to do it
for us.

The idea was generally accepted by brett, with a slight modification that
volunteers go through a screening process, just like normal commit access is
provisioned (someone who submits enough pom patches will slowly be given
commit access to ibiblio).

for more info, see
http://www.nabble.com/critique-of-maven-2.0.2-tf1052845.html#a2738495

perhaps it is time to move this forward?




On 7/5/06, jerome lacoste <[EMAIL PROTECTED]> wrote:
>
> On 7/5/06, Steve Loughran <[EMAIL PROTECTED]> wrote:
> > Ralph Goers wrote:
> > >
> > >
> > > Carlos Sanchez wrote:
> > >>
> > >> Yes you can, it's not the best way to do it but you can, by adding
> > >> explicitly the dependency with the versoin you want to your pom. In
> > >> the very worst case you have to add all transitive deendencies to
> your
> > >> pom, like in Maven 1.
>
>
> [..]
>
> I've been following this thread with interest.
>
> It makes me think of the various problems Linux distribution have to
> deal with when making their own repositories. It took 10 years for
> these solutions to be what they are today. I really think some ideas
> should be reused, even though the goals are slightly different.
>
> Some features/ways of working that may or may not be applicable:
>
> - they typically use a versionning similar to x.y.z-n sometimes
> adding. -n can be used to fix packaging issues (POM in the case of
> maven). Vendor fixes are also accepted and version names reflect the
> vendor name.
>
> - the distributions with the best repositories typically require the
> package to be buildable from source. The build is tested in a separate
> environment where all the required build dependencies are listed, to
> make sure that the dependency list is accepted. Something similar
> should maybe be done before accepting a project on a POM, setting up a
> build environment based on the given pom.
>
> - number of versions of a particular package in a repo is reduced to a
> minimum. users are adviced to upgrade to the latest & greatest to make
> sure that fixes are always present in the last released versions
>
> - responsibilities of preparing packages is spread around 10s of
> people. Packages are orphaned when no one is taking care of them.
> People can reuse tricks/scripts learned by former packagers to go on
> with the job.
>
> - use of provides and various other dependency markers (that's coming
> in m2 2.1 if I got it right)
>
> Cheers,
>
> Jerome
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
__
Cheers,
  Arik Kfir   [EMAIL PROTECTED]
  Linux user, number 415067 - http://counter.li.org/
  http://corleon.dnsalias.org





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

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

Re: [RANT] This Maven thing is killing us....

[Mark Hobson]

On 05/07/06, Steve Loughran <[EMAIL PROTECTED]> wrote:

OK, but the other part of the problem is pushing the changes out to the
user.

in a linux distro, what you are effectively buying is a set of artifacts
compiled on the same gcc version/options, and a subscription that keeps
your box up to date. They are usually manual or cron updates.

If you're using an artifact 3.7, and the pom goes to 3.7-1, you need to
get that new pom, without having your stuff updated. Except when you
dont, of course, because you've just QA'd everything against a previous
version and dont want stuff with new metadata creeping in.


Could we not use the syntax 3.7 to represent 'the latest revision of
3.7', whereas 3.7-1 would lock the version down to 3.7 rev 1?  So
during development people could use 3.7 to allow updated revisions of
the pom to be pushed to them, and then for reproducable builds they
could use the 3.7-1 syntax.

The release plugin could fully-qualify any version numbers of the form
3.7 to the currently-used revision, e.g. 3.7-1, at release time.

Mark

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

Re: [RANT] This Maven thing is killing us....

[Arik Kfir]

Hello all,

A while back I suggested that the Maven team delegate some of the
reponsibility of maintaining the ibiblio repo to volunteers (as in the linux
equivalent, as Jerome has noted earlier in the thread). Each such voluteer
can maintain a specific area in the repo; so, someone who uses hibernate
frequently can maintain its poms, until the hibernate team agrees to do it
for us.

The idea was generally accepted by brett, with a slight modification that
volunteers go through a screening process, just like normal commit access is
provisioned (someone who submits enough pom patches will slowly be given
commit access to ibiblio).

for more info, see
http://www.nabble.com/critique-of-maven-2.0.2-tf1052845.html#a2738495

perhaps it is time to move this forward?




On 7/5/06, jerome lacoste <[EMAIL PROTECTED]> wrote:


On 7/5/06, Steve Loughran <[EMAIL PROTECTED]> wrote:
> Ralph Goers wrote:
> >
> >
> > Carlos Sanchez wrote:
> >>
> >> Yes you can, it's not the best way to do it but you can, by adding
> >> explicitly the dependency with the versoin you want to your pom. In
> >> the very worst case you have to add all transitive deendencies to
your
> >> pom, like in Maven 1.


[..]

I've been following this thread with interest.

It makes me think of the various problems Linux distribution have to
deal with when making their own repositories. It took 10 years for
these solutions to be what they are today. I really think some ideas
should be reused, even though the goals are slightly different.

Some features/ways of working that may or may not be applicable:

- they typically use a versionning similar to x.y.z-n sometimes
adding. -n can be used to fix packaging issues (POM in the case of
maven). Vendor fixes are also accepted and version names reflect the
vendor name.

- the distributions with the best repositories typically require the
package to be buildable from source. The build is tested in a separate
environment where all the required build dependencies are listed, to
make sure that the dependency list is accepted. Something similar
should maybe be done before accepting a project on a POM, setting up a
build environment based on the given pom.

- number of versions of a particular package in a repo is reduced to a
minimum. users are adviced to upgrade to the latest & greatest to make
sure that fixes are always present in the last released versions

- responsibilities of preparing packages is spread around 10s of
people. Packages are orphaned when no one is taking care of them.
People can reuse tricks/scripts learned by former packagers to go on
with the job.

- use of provides and various other dependency markers (that's coming
in m2 2.1 if I got it right)

Cheers,

Jerome

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





--
__
Cheers,
 Arik Kfir   [EMAIL PROTECTED]
 Linux user, number 415067 - http://counter.li.org/
 http://corleon.dnsalias.org

Re: [RANT] This Maven thing is killing us....

[Pete Marvin King]

   sometimes it makes me wonder how gentoo manages their ebuilds.
   portage and maven both supports transitive dependencies, but somehow
   the portage ebuilds which can be compared to the maven pom is more
   stable and reliable. currently the number of portage ebuilds is
around 24,000+,
   a large amount of ebuilds to maintain.

   i'm guessing the community plays a crucial part in the health of the
ebuilds.
   the gentoo community has a lot of passionate people taking care of
the ebuilds.



jerome lacoste wrote:
> On 7/5/06, Steve Loughran <[EMAIL PROTECTED]> wrote:
>> Ralph Goers wrote:
>> >
>> >
>> > Carlos Sanchez wrote:
>> >>
>> >> Yes you can, it's not the best way to do it but you can, by adding
>> >> explicitly the dependency with the versoin you want to your pom. In
>> >> the very worst case you have to add all transitive deendencies to
>> your
>> >> pom, like in Maven 1.
>
>
> [..]
>
> I've been following this thread with interest.
>
> It makes me think of the various problems Linux distribution have to
> deal with when making their own repositories. It took 10 years for
> these solutions to be what they are today. I really think some ideas
> should be reused, even though the goals are slightly different.
>
> Some features/ways of working that may or may not be applicable:
>
> - they typically use a versionning similar to x.y.z-n sometimes
> adding. -n can be used to fix packaging issues (POM in the case of
> maven). Vendor fixes are also accepted and version names reflect the
> vendor name.
>
> - the distributions with the best repositories typically require the
> package to be buildable from source. The build is tested in a separate
> environment where all the required build dependencies are listed, to
> make sure that the dependency list is accepted. Something similar
> should maybe be done before accepting a project on a POM, setting up a
> build environment based on the given pom.
>
> - number of versions of a particular package in a repo is reduced to a
> minimum. users are adviced to upgrade to the latest & greatest to make
> sure that fixes are always present in the last released versions
>
> - responsibilities of preparing packages is spread around 10s of
> people. Packages are orphaned when no one is taking care of them.
> People can reuse tricks/scripts learned by former packagers to go on
> with the job.
>
> - use of provides and various other dependency markers (that's coming
> in m2 2.1 if I got it right)
>
> Cheers,
>
> Jerome
>
> -
> 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: [RANT] This Maven thing is killing us....

[Steve Loughran]

Mike Perham wrote:

The more I think about it, the more I agree with this.  I believe we
will need to start using this -n versioning for POM fixes.  It's easy to
develop and test a java module but screw up the POM and make it unusable
to the public.  How long and how many revisions did it take for us to
get hibernate or spring in decent shape?  ;-)



OK, but the other part of the problem is pushing the changes out to the 
user.


in a linux distro, what you are effectively buying is a set of artifacts 
compiled on the same gcc version/options, and a subscription that keeps 
your box up to date. They are usually manual or cron updates.


If you're using an artifact 3.7, and the pom goes to 3.7-1, you need to 
get that new pom, without having your stuff updated. Except when you 
dont, of course, because you've just QA'd everything against a previous 
version and dont want stuff with new metadata creeping in.


-steve


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

RE: [RANT] This Maven thing is killing us....

[Mike Perham]

The more I think about it, the more I agree with this.  I believe we
will need to start using this -n versioning for POM fixes.  It's easy to
develop and test a java module but screw up the POM and make it unusable
to the public.  How long and how many revisions did it take for us to
get hibernate or spring in decent shape?  ;-)

> -Original Message-
> From: jerome lacoste [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, July 05, 2006 10:33 AM
> To: Maven Developers List
> Subject: Re: [RANT] This Maven thing is killing us
> 
> 
> - they typically use a versionning similar to x.y.z-n sometimes
> adding. -n can be used to fix packaging issues (POM in the case of
> maven). Vendor fixes are also accepted and version names reflect the
> vendor name.
> 

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

Re: [RANT] This Maven thing is killing us....

[jerome lacoste]

On 7/5/06, Steve Loughran <[EMAIL PROTECTED]> wrote:

Ralph Goers wrote:
>
>
> Carlos Sanchez wrote:
>>
>> Yes you can, it's not the best way to do it but you can, by adding
>> explicitly the dependency with the versoin you want to your pom. In
>> the very worst case you have to add all transitive deendencies to your
>> pom, like in Maven 1.



[..]

I've been following this thread with interest.

It makes me think of the various problems Linux distribution have to
deal with when making their own repositories. It took 10 years for
these solutions to be what they are today. I really think some ideas
should be reused, even though the goals are slightly different.

Some features/ways of working that may or may not be applicable:

- they typically use a versionning similar to x.y.z-n sometimes
adding. -n can be used to fix packaging issues (POM in the case of
maven). Vendor fixes are also accepted and version names reflect the
vendor name.

- the distributions with the best repositories typically require the
package to be buildable from source. The build is tested in a separate
environment where all the required build dependencies are listed, to
make sure that the dependency list is accepted. Something similar
should maybe be done before accepting a project on a POM, setting up a
build environment based on the given pom.

- number of versions of a particular package in a repo is reduced to a
minimum. users are adviced to upgrade to the latest & greatest to make
sure that fixes are always present in the last released versions

- responsibilities of preparing packages is spread around 10s of
people. Packages are orphaned when no one is taking care of them.
People can reuse tricks/scripts learned by former packagers to go on
with the job.

- use of provides and various other dependency markers (that's coming
in m2 2.1 if I got it right)

Cheers,

Jerome

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

Re: [RANT] This Maven thing is killing us....

[Steve Loughran]

Ralph Goers wrote:



Carlos Sanchez wrote:


Yes you can, it's not the best way to do it but you can, by adding
explicitly the dependency with the versoin you want to your pom. In
the very worst case you have to add all transitive deendencies to your
pom, like in Maven 1.
That is so impractical as to be nonsensical. Our Configuration 
Management folks require that all projects use the same dependencies 
from the top to the bottom. For example, we build our base set of 
frameworks with one multiproject build, then a higher level of 
frameworks, and then finally the product itself. Each of these must be 
built and unit tested with the same third party jars. Furthermore, the 
product can consist of a war and one or more ejb's which may all be 
packaged in an ear. These must also all have all the same versions of 
the jars. The solution you propose makes that tedious, error prone, and 
would require our CM folks to manually inspect every pom to insure 
nothing is done improperly. At least with Maven 1 we can have a 
build.properties that all projects share.  In our case, the ideal 
solution in Maven 2 would be to have a "master" pom with nothing in it 
but a dependencyManagement section (with something like override="true" 
set as an attribute) that all our projects would reference.




FYI, using the maven tasks in ant, I create my own pom files based on 
the values in a shared properties file. The poms are then fed in to the 
tasks and used to publish the artifacts themselves. This lets me do two 
things

 -have a single library.properties file to control the version of things
 -have developer-specific build.properties driven overrides of 
versions, and know that those versions get picked up everywhere.
This isn't a perfect process, as it is fairly verbose, but it does 
ensure consistency. It would be easier with a task that did both the pom 
file creation and path setup in one go.


I run the tasks with verbose=true so I get to see what is happening 
w.r.t dependency inference, something like this:


ready-to-declare-classpaths:

core-libraries:
unspecified:unspecified:jar:0.0 (selected)
  commons-lang:commons-lang:jar:2.1 (selected)
  commons-logging:commons-logging:jar:1.0.4 (selected)
log4j:log4j:jar:1.2.6 (selected)
  log4j:log4j:jar:1.2.6 (removed - nearer found: 1.2.13)
  log4j:log4j:jar:1.2.13 (selected)

smartfrog-modules-classpath:
unspecified:unspecified:jar:0.0 (selected)
  org.smartfrog:sf-cdl:jar:3.08.steve-private (selected)
[m2:libraries] [INFO] snapshot org.ggf:cddlm:ggf16-SNAPSHOT: checking 
for updates from remote

org.ggf:cddlm:jar:ggf16-SNAPSHOT (selected)
commons-logging:commons-logging-api:jar:1.0.4 (selected)
org.smartfrog:sf-xml:jar:3.08.steve-private (selected)
  xerces:xmlParserAPIs:jar:2.6.2 (selected)
  xerces:xercesImpl:jar:2.6.2 (selected)
  xom:xom:jar:1.1 (selected)
xom:xom:jar:1.0b3 (removed - causes a cycle in the graph)
jaxen:jaxen:jar:1.1-beta-8 (selected)
  org.smartfrog:sf-www:jar:3.08.steve-private (selected)
  org.smartfrog:sf-m32:jar:3.08.steve-private (selected)
commons-httpclient:commons-httpclient:jar:3.0 (selected)
  commons-codec:commons-codec:jar:1.2 (selected)
servletapi:servletapi:jar:2.3 (selected)
xerces:xmlParserAPIs:jar:2.6.2 (selected)
xom:xom:jar:1.1 (selected)
  xom:xom:jar:1.0b3 (removed - causes a cycle in the graph)
  jaxen:jaxen:jar:1.1-beta-8 (selected)
xerces:xercesImpl:jar:2.6.2 (selected)
  org.smartfrog:sf-jetty:jar:3.08.steve-private (selected)
  org.smartfrog:sf-loggingservices:jar:3.08.steve-private (selected)
org.smartfrog:smartfrog:jar:3.08.steve-private (selected)
log4j:log4j:jar:1.2.13 (selected)
  org.smartfrog:sf-xml:jar:3.08.steve-private (selected)

smartfrog-core-classpath:
unspecified:unspecified:jar:0.0 (selected)
  org.smartfrog:smartfrog:jar:3.08.steve-private (selected)
  org.smartfrog:sfServices:jar:3.08.steve-private (selected)

jetty-classpath:
unspecified:unspecified:jar:0.0 (selected)
  jetty:jetty:jar:4.2.24 (selected)
  servletapi:servletapi:jar:2.3 (selected)

declare-compile.classpath:

declare-exec.classpath:

smartfrog-testharness-classpath:
unspecified:unspecified:jar:0.0 (selected)
  org.smartfrog:sf-testharness:jar:3.08.steve-private (selected)
unspecified:unspecified:jar:0.0 (selected)
  org.smartfrog:sf-testharness:jar:3.08.steve-private (selected)
  junit:junit:jar:3.8.1 (selected)

Everything with steve-private is tagged as a release for me only; built 
locally and never saved up to the net. I am just using the local cache 
as a way of sharing artifacts.


One problem with this (ant-centric, obviously) approach is that I'm 
building up multiple graphs of dependencies, and the version logic only 
works in the scope of one graph, but ant lets me merge them. In an ideal 
world, you'd have the ability to merge two dependency graphs and have 
the resolution thing kick in again. I suppose if I had a separate pom 
for each path I c

RE: [RANT] This Maven thing is killing us....

[Ruel Loehr]

I made some noise a few months ago about the repository poms.

There are 3 or 4 issues currently in JIRA regarding this.  I also agree that it 
is an issue.

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

Ruel Loehr
JBoss QA
 
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 04, 2006 10:13 AM
To: Maven Developers List
Cc: dev@cocoon.apache.org
Subject: Re: [RANT] This Maven thing is killing us

On 4/07/2006 9:34 PM, Torsten Curdt wrote:
> I agree that the whole maven2 situation is currently far less than
> just acceptable ...but TBH I am not sure the maven team is (or was?)
> really aware of all the problems we have.

Not until you forwarded a message (and thanks for doing so). We don't 
really have the bandwidth to follow along with everyone that is 
converting builds...

> 
> Maybe we can get a statement on the maven self-update and
> unreliable-messed-up-repository situation. From what it sounds they
> are working on it. So let's not work this out in our little cocoon
> corner but let's hear what they have to say.

I think we all recognise there are some issues, particularly with 
ibiblio dropping out consistently, and also issues with transitivity and 
versioning that have been raised on the [EMAIL PROTECTED] thread. I'm not sure 
what "messed up repository" issues you are having, but would like to 
hear about it.

I know this stuff needs a good hard looking at, but I don't believe 
there is anything insurmountable here.

- Brett

-- 
Brett Porter <[EMAIL PROTECTED]>
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

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


-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006
 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006
 

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

Re: [RANT] This Maven thing is killing us....

[Ralph Goers]

Carlos Sanchez wrote:

so... you can do it.
In m1 anybody can override the build.properties as in m2 they can put
a different version.
Pardon me for going on and on about this, but the reality is that, at 
least in my organization, "anybody" cannot override the 
build.properties. When our CM team gets a release they will use the 
correct build.properties and your project damn well better build with 
it.  If a new or upgraded third party jar is required it has to be 
explicitly called out in the release documentation. 


i'm not saying it's the right solution but while is not implemented
you can still do it. There's a limited number of hours in the day to
do all the things we want to do ;)

This part I understand! ;-)

Ralph

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

Re: [RANT] This Maven thing is killing us....

[Brett Porter]

Not a bulletproof one (there's ${user.dir}, but that's only right 90% of 
the time). In a multiproject scenario, you might be better off putting 
the individual jars in as stubbed projects:


parent pom:
jar-in-svn
...

jar-in-svn/pom.xml: the POM from the repository, but add a copy file.jar 
to target/artifactId-version.jar at the package phase.


Cheers,
Brett

On 5/07/2006 7:27 PM, Geoffrey De Smet wrote:



Brett Porter wrote:

Hi Ralph,

There are a couple of options for addressing this use case in Maven.
- include the JARs in SVN, and reference it as an additional 
repository file://localhost/${basedir}/extra-jar-repo



When you declare such a repository in your parent pom, the child poms 
don't use the parent's basedir, but their own basedir. Is there a 
workaround for that problem?






--
Brett Porter <[EMAIL PROTECTED]>
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

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

Re: [RANT] This Maven thing is killing us....

[Carlos Sanchez]

On 7/5/06, Stephen Duncan <[EMAIL PROTECTED]> wrote:

On 7/4/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> On 7/5/06, Stephen Duncan <[EMAIL PROTECTED]> wrote:
> > On 7/4/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> > >
> > > On 4 Jul 06, at 2:37 PM 4 Jul 06, Steve Loughran wrote:
> > >
> > > The metadata will never be perfect but right now I still
> > > think it's far from being ideal because we have no real active
> > > process of improving it on a large scale. Carlos puts in a _lot_ of
> > > time trying to correct things and absorb changes submitted for
> > > improvement but as mentioned in the previous message it's a matter of
> > > education and automated tools running to point people in the right
> > > direction.
> >
> > Well, but it seems (recently?) that a policy has been put into place
> > that POMs already in the repository should not be corrected or
> > improved, in order to preserve repeatability for builds depending on
> > the existing version, and that corrections should be done by making
> > new releases.  It's hard enough to get projects to care about
> > providing Maven POMs, but to ask for a new release seems a bit much.
>
> There's always the possibiblity of adding a new version ourselves with
> a build number, like 1.0-1 where only the pom changes. Only as an
> exception when a project is dead or don't release often

That's essentially what I suggesting later on as an option for
by-convention fix for allowing fixes to POMs.  I don't think I agree
that it's an exceptional case though.   What do you see as the correct
process here?  That the issue for POM improvement be placed into the
other projects issue tracker, not Maven Evangelism, and that the
project make a new release with the changes?  Is that likely to
actually happen?


If enough users complain they'll do it. If not then the maven team
plays its role and can allow that new *-1 version. First ask the
project, then if you get a no by answer we'll try to fix it.



> >
> > It also may seem ideal to have projects take care of their own POMs,
> > but it makes it frustrating for users to provide information on fixes.
> >  I know, personally, I've cut down on contributing to central
> > repository improvement.  I've taken to simply installing new jars to
> > my internal repository, because asking individual projects to do it
> > gives slow-to-no returns.  I put top-level exclusions into
> > dependencyManagement rather than request changes to POMs, because
> > again, there seems no process for actually getting that to happen
> > that's not haphazard.  I'll try to work on doing better, but the
> > cost-reward ratio isn't helping.
>
> Well, if everybody does that then there's no community benefit and we
> all lose. When I need something not in ibiblio I put it there because
> it's not much harder than putting it in my local repo.

Like I said, I know I shouldn't do that.  But it certainly doesn't
feel as easy to get it put into ibiblio.  mvn deploy:deploy-file for
myself seems much easier than getting someone else's stuff into
ibiblio, where I need to make sure of all the details for groupId,
license, the rest of the POM is accurate, etc.  Plus, it's not even
clear that doing so for a third-party app was the encouraged way to
go, vs. trying to get the third-party to do it themselves.  If I
should be doing it, I guess I'll work to make an upload bundle for
tagsoup 1.0 tomorrow...


If they don't do it you can do it. All that info in the POM is for the
benefit of the users, eg so you can see reports with all licenses of
your dependencies. At least you can do the pom and show it to the
project to get an ok if everything looks right.



> > I think maybe some either feature or convention for handling version
> > changes to just POMs so they can be improved without another release
> > of the software would help.  Some clarification/policy statements on
> > when I should go straight to the project responsible for a jar vs.
> > filing in Maven evangelism for uploads & for POM improvements might be
> > helpful.  Certainly some of the 2.1 planned features (like being able
> > to rely on geronimo-transaction & have that take care of anything
> > relying in javax.transaction:jta...) could help.  I think some concept
> > work needs to go into optional dependencies, because it we can't
> > control when Spring decides they want to stop providing modularized
> > jars, and move to a single jar that will essentially have all optional
> > dependencies.  I'm not looking forward to getting my projects to work
> > with Spring 2.0.
>
> You can always have poms for different maven configurations against
> only one jar, see
> http://jroller.com/page/carlossg?entry=optional_dependencies_in_maven
>
> >
> > Believe me, this is all coming from someone who's been trying.  I've
> > filed bug reports with Spring, and Lucene, other projects to get Maven
> > uploads.  I've volunteered to work on providing and maintaining a
> > Maven 2 build for an incubator project

Choreographed releases (was [RANT] This Maven thing is killing us....)

[Steve Loughran]

Brett Porter wrote:

Hi Ralph,

You've got a general versioning problem here, and you'll find the answer 
to "how do I do this with Maven?" will be more straightforward once 
considering the question of how you should generally deal with them. As 
you've said, this is already a problem for you as you don't know where 
they really came from.


This is broader than just versioning, it is a "how do OSS projects do 
coordinated releases?" kind of problem.


In the closed source world, everything targets a single release 
milestone and either comes in on time (I'm trying to think of an example 
but it escapes me) or horribly late (Vista)


In OSS-land, everyone just pushes releases out when they feel like it, 
ideally with some kind of testing/QA stage. Then the downstream projects 
take it, finally it is considered stable enough to go into the 
"Enterprise" linux distros. Projects like fedora and SuSE get to be more 
timely by bundling beta release versions of many things and skipping on 
the testing.


This release process *appears* to work, at least as long as you dont 
really need everything to work together properly. If you want an 
integrated, testing, working distro you need a longer QA process and get 
something like RHEL, though even there they sometimes seem to have a 
hard time deciding which versions of which java stuff to bundle.




Ignoring Maven for a moment, there's a couple of questions I'd consider 
(bear in mind I'm not a Cocoon user so I may be misunderstanding how 
they eventually get used):
- how would a user that used one of these dependencies themselves in 
addition to that Cocoon component select which version of the dependency 
to use? Would they use the Cocoon-supplied one, one they select, or both?
- are the changes Cocoon specific? Will you always be using a custom 
release, or will you pick up the next release when it is available?


There are a couple of options for addressing this use case in Maven.
- include the JARs in SVN, and reference it as an additional repository 
file://localhost/${basedir}/extra-jar-repo


- host your own repository of these artifacts (this is basically 
equivalent to the above and probably easier to work with, and could be 
accommodated in a general ASF repository of such things, once taking 
into account the licensing guidelines)


This is effectively what the fedora/core distros do when they use 
jpackage to push out releases of various things. historically they've 
tended to stick to point releases of java stuff, and custom releases of 
stuff like firefox and and OOo, but with redhat getting more into java, 
this could change.




- ask projects to do a beta/point release for you (it should be easy to 
make a case for this if the version you are using is both stable and 
contains critical fixes)


this should be your fundamental goal. You need to persuade projects that 
they need to cut a tagged, labelled, supported release on your schedule. 
Its pretty hard, especially if you get burned by the first time you ship 
something before it is not ready (e.g axis1.0 because websphere wanted 
it) and are left maintaining it for a while. The next time the team 
comes back for a new release, you are going to push back and say "wait 
until we are ready"


The hard part becomes convincing j-random-component.jar that they should 
do a point release, with the beta testing and support costs. For 
axis1.4, I think geronimo solved the problem by taking on the release 
management role.





- "fork" the code (taking into consideration licensing guidelines) 
either temporarily or permanently in your own repository (ie 
http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html). Make 
it part of your build, and do the custom group ID thing. We really need 
the "provides" functionality planned for Maven 2.1 to make this feasible 
if it is intended to be a drop in replacement of the original JAR (so 
that you don't get duplicates in the dependency chain), but it can 
certainly work.


BTW, I also think we need specific support for this type of artifact (it 
is essentially a "vendor" release), and it is under consideration for 
Maven 2.1.




Fork someone else's project and you take ownership of all support calls 
forever. Take a look at how Axis handles support emails related to the 
JBoss fork of Axis 1.x, it is essentially "please, go ask them; we dont 
know what they did before they shipped". And don't even get me started 
on the BEA version of Ant, the one with the modified manifests and the 
broken .bat and .sh files.


Now that Cocoon is using OSGi, does that change versioning rules? 
Because that lets components run different versions of things 
side-by-side, doesnt it?


-Steve

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

Re: [RANT] This Maven thing is killing us....

[Carlos Sanchez]

On 7/5/06, Ralph Goers <[EMAIL PROTECTED]> wrote:



Carlos Sanchez wrote:
>
> Yes you can, it's not the best way to do it but you can, by adding
> explicitly the dependency with the versoin you want to your pom. In
> the very worst case you have to add all transitive deendencies to your
> pom, like in Maven 1.
That is so impractical as to be nonsensical. Our Configuration
Management folks require that all projects use the same dependencies
from the top to the bottom. For example, we build our base set of
frameworks with one multiproject build, then a higher level of
frameworks, and then finally the product itself. Each of these must be
built and unit tested with the same third party jars. Furthermore, the
product can consist of a war and one or more ejb's which may all be
packaged in an ear. These must also all have all the same versions of
the jars. The solution you propose makes that tedious, error prone, and
would require our CM folks to manually inspect every pom to insure
nothing is done improperly. At least with Maven 1 we can have a
build.properties that all projects share.  In our case, the ideal
solution in Maven 2 would be to have a "master" pom with nothing in it
but a dependencyManagement section (with something like override="true"
set as an attribute) that all our projects would reference.


so... you can do it.
In m1 anybody can override the build.properties as in m2 they can put
a different version.

i'm not saying it's the right solution but while is not implemented
you can still do it. There's a limited number of hours in the day to
do all the things we want to do ;)



Ralph




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

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

Re: [RANT] This Maven thing is killing us....

[Carlos Sanchez]

On 7/5/06, David Jencks <[EMAIL PROTECTED]> wrote:


On Jul 4, 2006, at 6:33 PM, Brett Porter wrote:

> On 5/07/2006 10:54 AM, David Jencks wrote:
>> I think the process is somewhat broken and that the maven team is
>> being far too strict about changing broken poms that were in fact
>> installed by the maven team, not supplied by the project.
>> (xmlbeans is the case in point for me).  I also think that
>> traceability of where poms came from and under what auspices they
>> are added to either the repository svn tree or ibiblio is sorely
>> lacking.  (again xmlbeans being my sore spot).  We are in the
>> situation where a pom appeared from an unknown source, is wrong,
>> did not come from the project, and can't be updated.  Much as I
>> like maven it's hard for me to see how this is going to lead to
>> success.
>
> David,
>
> I thought we'd agreed to fix that up? I can't find the issue on it
> other than http://jira.codehaus.org/browse/MEV-406 which is not the
> one I recall (that one is about stax which is a whole other problem
> beyond the scope of Maven too).

that's the one.  The xmlbeans pom does not have the required stax-api
dependency listed in it.  As that issue notes, Carlos declined to
change the existing pom.  IIUC Carlos said I needed to get xmlbeans
to produce the pom, which I am currently working on, see http://
issues.apache.org/jira/browse/XMLBEANS-277


The problem is that people want a stable repo, you just have to check
this thread. If I could go back in time I wouldn't do the
autogeneration of poms.

Another issue I've already seen several times is patches to fix poms
that at the end where not the *right* fix. For instance people saying
that dependency A is missing, so it's added. Then somebody else uses
it differently and then dependency B is missing. I don't want that to
happen again.



The xmlbeans team have agreed in principle to cooperate but have not
in fact yet reviewed my first draft for things like correct urls.  I
originally planned to produce a complete set of poms for their 3 jars
and 3 releases but am not sure how to test one of them.To me it
seems like its turned into an enormous amount of work to fix a really
obvious problem.  One of the most frustrating things for me is that
there is no way to find out where the existing wrong poms came from.


Brett has a good suggestion about adding traceability to uploaded
poms. But I can tell you that if the pom only has group, artifact and
version is coming from the early times of the repo autogenerated it
from a missing pom in the m1 repo.
Things from Apache, Codehaus, Objectweb,... come synced from their repos.


Second most frustrating was that the MEV instructions turned out to
be 100% inaccurate, so following them to the letter was a complete
waste of time.


Sorry about that, now they are changed, not sure if they have been deployed yet.



There was another problem with the maven xmlbeans plugin that Kris
Bravo fixed immediately.

thanks
david jencks

>
> - Brett
>
> --
> Brett Porter <[EMAIL PROTECTED]>
> Apache Maven - http://maven.apache.org/
> Better Builds with Maven - http://library.mergere.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


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





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

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

Re: [RANT] This Maven thing is killing us....

[Steve Loughran]

Jason van Zyl wrote:


On 4 Jul 06, at 1:45 PM 4 Jul 06, Steve Loughran wrote:


In a way, many of the stuff in M2 is experimental; a build tool that 
effectively encodes beliefs about how a project should be structured 
and delivered, focusing on component-based development instead of 
application dev. I also think its time to look at how well some of the 
experiment is working.




You make it sound like we're some sort of cult :-)


I think you are exploring cutting edge loosely coupled software 
development processes. It's research. Interesting, fun research, but 
research nonetheless. Just as Gump is an experiment in whether a unified 
nightly build changes people's working processes.


I've been hanging round with semantic-web people recently, and have 
devolved into using the word "belief" where they use "fact", because of 
differences of opinion on what they and I think RDF triples are (they 
think they're facts in a graph, I think every triple is a belief 
published by an entity at a particular moment in time). The nice thing 
about a belief-centric model is you get to accept the fact that 
different entities have different beliefs, and a single entity/agent can 
change its belief set, without ever having to worry about the fact that 
the global belief-set is inconsistent.


in real agent-oriented-runtimes (still very much academic research, even 
more than RDF engines), the resolver takes in to account the metadata 
about which agent issued a belief statement and when during its 
resolution process. Newer statements by the same entity can override 
older ones; differences between entities are allowable but result in 
ambiguities that may need to be dealt with further down the line.


When you apply the same agent-oriented view to POM metadata, you can say 
"a POM file represents the pom author's beliefs about the artifact's 
dependencies at the time they wrote the POM". It may be the beliefs 
match what the artifact really needs, it may be those beliefs turn out 
to be utterly wrong.


[interlude. I just grabbed the chair of the W3C RDF working group by the 
coffee machine. Apparently "a belief is a state of mind", "a fact is 
something that is believed". So all facts are beliefs, the only variable 
being the number of believers]


Because the ibiblio repository contains fact/belief metadata from so 
many sources, its that much harder to reconcile than those from single 
entities. The good news is that we do have a very nice way to test these 
assertions in java; running the program and seeing what classes get 
loaded. So when someone is utterly wrong in their dependencies, its 
pretty obvious. Its when they are slightly wrong, when they use some 
classes in certain cases, often using reflection to bind at run time, 
that you can get caught out.





The phrase "encoding beliefs" is an inaccurate description. It's is 
simply the pursuit of best practices for software development and those 
practices are very much mutable, this thread being very good evidence of 
that. We also not only focused on component-oriented development, we 
ourselves develop applications ourselves and we're trying to make that 
coherent as well.


Ok. how about "encoding the team's ideas and experience in how to build 
applications as sets of components, using

shared repositories to exchange components and their metadata"?



Personally, I always experience a bit of fear when adding a new 
dependency to a project. the repository stuff, and estimate a couple 
of hours to get every addition stable, primarily by building up a good 
exclusion list.


This is the place to talk about that as people shouldn't be fearful 
adding dependencies. But people who have an ideal setup here they 
completely control the repository they use internally don't have many of 
the problems that people are experiencing in this thread. Having a 
public repository of high quality is not a trivial task.




Is it worse than before? Better? Or just, well, different? and if 
things are either worse or not as good as they could be, what can be 
changed?




The process is absolutely better. The process couple with the public 
infrastructure we have now is problematic. Two very different things.


One underlying cause seems to be pom quality. Open source software dev 
is a vast collection of loosely coupled projects, and what we get in 
the repository in terms of metadata matches this model. Each project 
produces artifacts that match their immediate needs, with POM files 
that appear to work at the time of publishing. Maven then caches those 
and freezes that metadata forever, even if it turns out that the 
metadata was wrong.  There's far better coherence within Gump, where 
the metadata is effectively maintained more by the gump team 
themselves than by the individual projects.


There is absolutely no way this is scalable over time. You are saying 
that a small group of people can maintain metadata for projects that 
they are not intimately involved

Re: [RANT] This Maven thing is killing us....

[Geoffrey De Smet]

Brett Porter wrote:

Hi Ralph,

There are a couple of options for addressing this use case in Maven.
- include the JARs in SVN, and reference it as an additional repository 
file://localhost/${basedir}/extra-jar-repo



When you declare such a repository in your parent pom, the child poms 
don't use the parent's basedir, but their own basedir. Is there a 
workaround for that problem?



--
With kind regards,
Geoffrey De Smet


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

Re: [RANT] This Maven thing is killing us....

[Carsten Ziegeler]

Brett Porter wrote:
> 
> The first thing I'd suggest is for those having problems to try another 
> mirror. I know requiring everyone to do that is a pain and not a long 
> term solution, but I'd like to see how much that reduces the problem.
> 
I'm not sure if the following problem has already been mentioned in this
thread as somehow my mail client messed up :(

We experience problems like the build is working on one machine while
not on another one. The reason for this is changing poms on the public
repository! M2 does not recognize when a pom is changed on the
repository, so once you have a pom for a dependency it's never updated.
If now someone builds before the update he has the old version while
someone who builds after the update for the first time, gets the new
version.
And this is exactly the reason why on some machines our build works
(they have the new version of a dependency which brings in other
transitive dependencies). It took us some time to recognize this as one
of the main problems.

Obviously, a pom in a public repository should never change, but as
there are faulty poms out there, these need to be fixed. So its very
likely that this will still happen in the future.
So it would be good if m2 could detect changes in the pom and then
update the local version. This would at least solve most of our problems.

I'm still thinking that adding a switch "turn off transitive dependency
handling" would be a nice think as then you really control what you get
without adding excludes all over the place.

And it seems that m2 is trying to get poms for snapshots even in offline
mode (haven't checked if this is filed as a bug already) and more
important it downloads snapshot versions from the repository although a
newer version of the snapshot is in the local repository. And the
interesting thing is, that although a version has been downloaded, the
local one is later on used.

Carsten
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

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

Re: [RANT] This Maven thing is killing us....

[Brett Porter]

Hi Ralph,

You've got a general versioning problem here, and you'll find the answer 
to "how do I do this with Maven?" will be more straightforward once 
considering the question of how you should generally deal with them. As 
you've said, this is already a problem for you as you don't know where 
they really came from.


Ignoring Maven for a moment, there's a couple of questions I'd consider 
(bear in mind I'm not a Cocoon user so I may be misunderstanding how 
they eventually get used):
- how would a user that used one of these dependencies themselves in 
addition to that Cocoon component select which version of the dependency 
to use? Would they use the Cocoon-supplied one, one they select, or both?
- are the changes Cocoon specific? Will you always be using a custom 
release, or will you pick up the next release when it is available?


There are a couple of options for addressing this use case in Maven.
- include the JARs in SVN, and reference it as an additional repository 
file://localhost/${basedir}/extra-jar-repo


- host your own repository of these artifacts (this is basically 
equivalent to the above and probably easier to work with, and could be 
accommodated in a general ASF repository of such things, once taking 
into account the licensing guidelines)


- ask projects to do a beta/point release for you (it should be easy to 
make a case for this if the version you are using is both stable and 
contains critical fixes)


- "fork" the code (taking into consideration licensing guidelines) 
either temporarily or permanently in your own repository (ie 
http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html). Make 
it part of your build, and do the custom group ID thing. We really need 
the "provides" functionality planned for Maven 2.1 to make this feasible 
if it is intended to be a drop in replacement of the original JAR (so 
that you don't get duplicates in the dependency chain), but it can 
certainly work.


BTW, I also think we need specific support for this type of artifact (it 
is essentially a "vendor" release), and it is under consideration for 
Maven 2.1.


Your point about never being a Cocoon release while waiting for 
dependencies to release is something I'm familiar with and there's 
definitely a need for this. However, is it possible to reduce the impact 
of it by being able to release individual components at different times 
so that they can track the release cycles of their dependencies? This 
sounds very similar to the scenario of Maven plugins, where it works 
quite successfully.


HTH,
Brett

On 5/07/2006 4:49 PM, Ralph Goers wrote:

Brett Porter wrote:
It depends on how you use them as to the best solution here. I assume 
that they are customised for cocoon, so they shouldn't be considered 
to be the same as the original. In that case, I'd suggest you release 
them under your own groupID (maybe org.apache.cocoon.thirdparty) so 
that they don't conflict (bearing in mind that someone will 
transitively receive both that and the original if they are both 
used). I'm assuming this isn't the case as you are only bundling these 
modified versions into a distributable app, not as part of a reusable 
component?


Hope this helps,
Brett

Actually, I'm not exactly sure why non-released jars are currently 
included, but I'm almost certain that in most cases it is not because it 
is customized for Cocoon. In looking in our latest 2.1.9 release (which 
isn't built with Maven) I see that jcs, chaperon, jackrabbit, deli, 
dojo, jing, joost, myfaces, poi, wsrp4j, xmldb and xreporter were all 
included in the release from some interim version that is probably 
unknown to those projects.  I suspect for many of them this was done 
because they included critical fixes.  Since Cocoon contains so many 
third party jars we would either have to make releases knowing that some 
things are broken or never put out a release.


However, your point about naming them o.a.c.thirdparty is well taken (at 
least by me).  A complaint I frequently have had is that it is often 
difficult to locate the exact source that was used to create the jar. 
Sometimes they are named with the svn revision with makes it easy. 
Sometimes they have a datestamp, which isn't necessarily guaranteed to 
get you the exact source, and sometimes they have a name like 
wsrp4j-shared-0.3-dev.jar (wsrp4j is in inclubator and I don't believe 
it has ever done a release, but this version number is really bad since 
there is no tag in svn matching 0.3-dev that I can see). In wsrp4j's 
case, I'm fairly sure Cocoon's usage of it is considered experimental - 
it gives users a way to have early access to it for experimentation 
purposes.


Ralph

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




--
Brett Porter <[EMAIL PROTECTED]>
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.merge

Re: [RANT] This Maven thing is killing us....

[David Jencks]

On Jul 4, 2006, at 6:33 PM, Brett Porter wrote:


On 5/07/2006 10:54 AM, David Jencks wrote:
I think the process is somewhat broken and that the maven team is  
being far too strict about changing broken poms that were in fact  
installed by the maven team, not supplied by the project.   
(xmlbeans is the case in point for me).  I also think that  
traceability of where poms came from and under what auspices they  
are added to either the repository svn tree or ibiblio is sorely  
lacking.  (again xmlbeans being my sore spot).  We are in the  
situation where a pom appeared from an unknown source, is wrong,  
did not come from the project, and can't be updated.  Much as I  
like maven it's hard for me to see how this is going to lead to  
success.


David,

I thought we'd agreed to fix that up? I can't find the issue on it  
other than http://jira.codehaus.org/browse/MEV-406 which is not the  
one I recall (that one is about stax which is a whole other problem  
beyond the scope of Maven too).


that's the one.  The xmlbeans pom does not have the required stax-api  
dependency listed in it.  As that issue notes, Carlos declined to  
change the existing pom.  IIUC Carlos said I needed to get xmlbeans  
to produce the pom, which I am currently working on, see http:// 
issues.apache.org/jira/browse/XMLBEANS-277


The xmlbeans team have agreed in principle to cooperate but have not  
in fact yet reviewed my first draft for things like correct urls.  I  
originally planned to produce a complete set of poms for their 3 jars  
and 3 releases but am not sure how to test one of them.To me it  
seems like its turned into an enormous amount of work to fix a really  
obvious problem.  One of the most frustrating things for me is that  
there is no way to find out where the existing wrong poms came from.   
Second most frustrating was that the MEV instructions turned out to  
be 100% inaccurate, so following them to the letter was a complete  
waste of time.


There was another problem with the maven xmlbeans plugin that Kris  
Bravo fixed immediately.


thanks
david jencks



- Brett

--
Brett Porter <[EMAIL PROTECTED]>
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

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




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

Re: [RANT] This Maven thing is killing us....

[Brett Porter]

Thanks Carsten. The first part was certainly already discussed (so you 
can see it in the mail archives).


It'd be good if you could file bugs for the last 3 things and we can 
schedule them for upcoming releases.


- Brett

On 5/07/2006 4:45 PM, Carsten Ziegeler wrote:

Brett Porter wrote:
The first thing I'd suggest is for those having problems to try another 
mirror. I know requiring everyone to do that is a pain and not a long 
term solution, but I'd like to see how much that reduces the problem.



I'm not sure if the following problem has already been mentioned in this
thread as somehow my mail client messed up :(

We experience problems like the build is working on one machine while
not on another one. The reason for this is changing poms on the public
repository! M2 does not recognize when a pom is changed on the
repository, so once you have a pom for a dependency it's never updated.
If now someone builds before the update he has the old version while
someone who builds after the update for the first time, gets the new
version.
And this is exactly the reason why on some machines our build works
(they have the new version of a dependency which brings in other
transitive dependencies). It took us some time to recognize this as one
of the main problems.

Obviously, a pom in a public repository should never change, but as
there are faulty poms out there, these need to be fixed. So its very
likely that this will still happen in the future.
So it would be good if m2 could detect changes in the pom and then
update the local version. This would at least solve most of our problems.

I'm still thinking that adding a switch "turn off transitive dependency
handling" would be a nice think as then you really control what you get
without adding excludes all over the place.

And it seems that m2 is trying to get poms for snapshots even in offline
mode (haven't checked if this is filed as a bug already) and more
important it downloads snapshot versions from the repository although a
newer version of the snapshot is in the local repository. And the
interesting thing is, that although a version has been downloaded, the
local one is later on used.

Carsten



--
Brett Porter <[EMAIL PROTECTED]>
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

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

Re: [RANT] This Maven thing is killing us....

[Ralph Goers]

Brett Porter wrote:
It depends on how you use them as to the best solution here. I assume 
that they are customised for cocoon, so they shouldn't be considered 
to be the same as the original. In that case, I'd suggest you release 
them under your own groupID (maybe org.apache.cocoon.thirdparty) so 
that they don't conflict (bearing in mind that someone will 
transitively receive both that and the original if they are both 
used). I'm assuming this isn't the case as you are only bundling these 
modified versions into a distributable app, not as part of a reusable 
component?


Hope this helps,
Brett

Actually, I'm not exactly sure why non-released jars are currently 
included, but I'm almost certain that in most cases it is not because it 
is customized for Cocoon. In looking in our latest 2.1.9 release (which 
isn't built with Maven) I see that jcs, chaperon, jackrabbit, deli, 
dojo, jing, joost, myfaces, poi, wsrp4j, xmldb and xreporter were all 
included in the release from some interim version that is probably 
unknown to those projects.  I suspect for many of them this was done 
because they included critical fixes.  Since Cocoon contains so many 
third party jars we would either have to make releases knowing that some 
things are broken or never put out a release.


However, your point about naming them o.a.c.thirdparty is well taken (at 
least by me).  A complaint I frequently have had is that it is often 
difficult to locate the exact source that was used to create the jar. 
Sometimes they are named with the svn revision with makes it easy. 
Sometimes they have a datestamp, which isn't necessarily guaranteed to 
get you the exact source, and sometimes they have a name like 
wsrp4j-shared-0.3-dev.jar (wsrp4j is in inclubator and I don't believe 
it has ever done a release, but this version number is really bad since 
there is no tag in svn matching 0.3-dev that I can see). In wsrp4j's 
case, I'm fairly sure Cocoon's usage of it is considered experimental - 
it gives users a way to have early access to it for experimentation 
purposes.


Ralph

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

Re: [RANT] This Maven thing is killing us....

[Ralph Goers]

Carlos Sanchez wrote:


Yes you can, it's not the best way to do it but you can, by adding
explicitly the dependency with the versoin you want to your pom. In
the very worst case you have to add all transitive deendencies to your
pom, like in Maven 1.
That is so impractical as to be nonsensical. Our Configuration 
Management folks require that all projects use the same dependencies 
from the top to the bottom. For example, we build our base set of 
frameworks with one multiproject build, then a higher level of 
frameworks, and then finally the product itself. Each of these must be 
built and unit tested with the same third party jars. Furthermore, the 
product can consist of a war and one or more ejb's which may all be 
packaged in an ear. These must also all have all the same versions of 
the jars. The solution you propose makes that tedious, error prone, and 
would require our CM folks to manually inspect every pom to insure 
nothing is done improperly. At least with Maven 1 we can have a 
build.properties that all projects share.  In our case, the ideal 
solution in Maven 2 would be to have a "master" pom with nothing in it 
but a dependencyManagement section (with something like override="true" 
set as an attribute) that all our projects would reference.


Ralph

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

Re: AW: [RANT] This Maven thing is killing us....

[Brett Porter]

On 5/07/2006 3:51 PM, Jörg Schaible wrote:
C'mon. The opposite behaviour was the default for Maven 1, where this worked perfectly. 


And everyone complained about how slow it was. As I said, there is a 
working fix in MNG-1908, but it is not in the release because the 
performance is, IMO, unacceptable.



And using uniqueVersion == false did not work out very well when releasing 
multi-module projects (don't know if it works now).


It does in both versions.

- Brett

--
Brett Porter <[EMAIL PROTECTED]>
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

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

RE: AW: [RANT] This Maven thing is killing us....

[Jörg Schaible]

Brett Porter wrote on Monday, July 03, 2006 2:27 PM:

> The original snapshot feature works just fine.
> 
> There was a particular variation of the feature added that
> doesn't work
> as designed. (MNG-1908). The variation works exactly the same way but
> reuses the file on the server.
> 
> Using uniqueVersion = false (the default) and a clean up
> script on the
> server is a workaround.

C'mon. The opposite behaviour was the default for Maven 1, where this worked 
perfectly. And using uniqueVersion == false did not work out very well when 
releasing multi-module projects (don't know if it works now).

This is one of Maven's core functionalitioes htat is currently not working in 
M2!

- Jörg

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

Re: [RANT] This Maven thing is killing us....

[Brett Porter]

On 5/07/2006 10:54 AM, David Jencks wrote:
I think the process is somewhat broken and that the maven team is being 
far too strict about changing broken poms that were in fact installed by 
the maven team, not supplied by the project.  (xmlbeans is the case in 
point for me).  I also think that traceability of where poms came from 
and under what auspices they are added to either the repository svn tree 
or ibiblio is sorely lacking.  (again xmlbeans being my sore spot).  We 
are in the situation where a pom appeared from an unknown source, is 
wrong, did not come from the project, and can't be updated.  Much as I 
like maven it's hard for me to see how this is going to lead to success.


David,

I thought we'd agreed to fix that up? I can't find the issue on it other 
than http://jira.codehaus.org/browse/MEV-406 which is not the one I 
recall (that one is about stax which is a whole other problem beyond the 
scope of Maven too).


- Brett

--
Brett Porter <[EMAIL PROTECTED]>
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

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

Re: [RANT] This Maven thing is killing us....

[David Jencks]

On Jul 4, 2006, at 5:16 PM, Carlos Sanchez wrote:


On 7/5/06, Stephen Duncan <[EMAIL PROTECTED]> wrote:

On 7/4/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>
> On 4 Jul 06, at 2:37 PM 4 Jul 06, Steve Loughran wrote:
>
> The metadata will never be perfect but right now I still
> think it's far from being ideal because we have no real active
> process of improving it on a large scale. Carlos puts in a _lot_ of
> time trying to correct things and absorb changes submitted for
> improvement but as mentioned in the previous message it's a  
matter of

> education and automated tools running to point people in the right
> direction.

Well, but it seems (recently?) that a policy has been put into place
that POMs already in the repository should not be corrected or
improved, in order to preserve repeatability for builds depending on
the existing version, and that corrections should be done by making
new releases.  It's hard enough to get projects to care about
providing Maven POMs, but to ask for a new release seems a bit much.


There's always the possibiblity of adding a new version ourselves with
a build number, like 1.0-1 where only the pom changes. Only as an
exception when a project is dead or don't release often


I think the process is somewhat broken and that the maven team is  
being far too strict about changing broken poms that were in fact  
installed by the maven team, not supplied by the project.  (xmlbeans  
is the case in point for me).  I also think that traceability of  
where poms came from and under what auspices they are added to either  
the repository svn tree or ibiblio is sorely lacking.  (again  
xmlbeans being my sore spot).  We are in the situation where a pom  
appeared from an unknown source, is wrong, did not come from the  
project, and can't be updated.  Much as I like maven it's hard for me  
to see how this is going to lead to success.


thanks
david jencks





It also may seem ideal to have projects take care of their own POMs,
but it makes it frustrating for users to provide information on  
fixes.

 I know, personally, I've cut down on contributing to central
repository improvement.  I've taken to simply installing new jars to
my internal repository, because asking individual projects to do it
gives slow-to-no returns.  I put top-level exclusions into
dependencyManagement rather than request changes to POMs, because
again, there seems no process for actually getting that to happen
that's not haphazard.  I'll try to work on doing better, but the
cost-reward ratio isn't helping.


Well, if everybody does that then there's no community benefit and we
all lose. When I need something not in ibiblio I put it there because
it's not much harder than putting it in my local repo.



I think maybe some either feature or convention for handling version
changes to just POMs so they can be improved without another release
of the software would help.  Some clarification/policy statements on
when I should go straight to the project responsible for a jar vs.
filing in Maven evangelism for uploads & for POM improvements  
might be

helpful.  Certainly some of the 2.1 planned features (like being able
to rely on geronimo-transaction & have that take care of anything
relying in javax.transaction:jta...) could help.  I think some  
concept

work needs to go into optional dependencies, because it we can't
control when Spring decides they want to stop providing modularized
jars, and move to a single jar that will essentially have all  
optional

dependencies.  I'm not looking forward to getting my projects to work
with Spring 2.0.


You can always have poms for different maven configurations against
only one jar, see
http://jroller.com/page/carlossg?entry=optional_dependencies_in_maven



Believe me, this is all coming from someone who's been trying.  I've
filed bug reports with Spring, and Lucene, other projects to get  
Maven

uploads.  I've volunteered to work on providing and maintaining a
Maven 2 build for an incubator project so that it will be easy to
provide Maven jars & poms when the time comes.


You can see in http://opensource.atlassian.com/projects/spring/ 
browse/SPR-1484

that Spring got pressure from their users to provide POMs, it's by far
the most popular issue. Any project that wants to succeed must listen
to their users



Oh, another quality issue.  -source and -javadoc jars.  It really
slows down running eclipse:eclipse when half or more of my
dependencies don't have these jars.  And a lot don't.  All of
spring-1.2.7, for instance.


You can download Spring, jar the stuff up and submit them for adding
to ibiblio. I don't understand how can you complain when maven is the
only project providing that feature.



My purpose isn't just to complain.  I just think that there's  
going to

have be more to it than "it'll get better over time" for the central
repository to improve, because, from the narrow view of the things I
use, it's getting a bit worse, not better right now.


M

Re: [RANT] This Maven thing is killing us....

[Stephen Duncan]

On 7/4/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote:

On 7/5/06, Stephen Duncan <[EMAIL PROTECTED]> wrote:
> On 7/4/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> >
> > On 4 Jul 06, at 2:37 PM 4 Jul 06, Steve Loughran wrote:
> >
> > The metadata will never be perfect but right now I still
> > think it's far from being ideal because we have no real active
> > process of improving it on a large scale. Carlos puts in a _lot_ of
> > time trying to correct things and absorb changes submitted for
> > improvement but as mentioned in the previous message it's a matter of
> > education and automated tools running to point people in the right
> > direction.
>
> Well, but it seems (recently?) that a policy has been put into place
> that POMs already in the repository should not be corrected or
> improved, in order to preserve repeatability for builds depending on
> the existing version, and that corrections should be done by making
> new releases.  It's hard enough to get projects to care about
> providing Maven POMs, but to ask for a new release seems a bit much.

There's always the possibiblity of adding a new version ourselves with
a build number, like 1.0-1 where only the pom changes. Only as an
exception when a project is dead or don't release often


That's essentially what I suggesting later on as an option for
by-convention fix for allowing fixes to POMs.  I don't think I agree
that it's an exceptional case though.   What do you see as the correct
process here?  That the issue for POM improvement be placed into the
other projects issue tracker, not Maven Evangelism, and that the
project make a new release with the changes?  Is that likely to
actually happen?


>
> It also may seem ideal to have projects take care of their own POMs,
> but it makes it frustrating for users to provide information on fixes.
>  I know, personally, I've cut down on contributing to central
> repository improvement.  I've taken to simply installing new jars to
> my internal repository, because asking individual projects to do it
> gives slow-to-no returns.  I put top-level exclusions into
> dependencyManagement rather than request changes to POMs, because
> again, there seems no process for actually getting that to happen
> that's not haphazard.  I'll try to work on doing better, but the
> cost-reward ratio isn't helping.

Well, if everybody does that then there's no community benefit and we
all lose. When I need something not in ibiblio I put it there because
it's not much harder than putting it in my local repo.


Like I said, I know I shouldn't do that.  But it certainly doesn't
feel as easy to get it put into ibiblio.  mvn deploy:deploy-file for
myself seems much easier than getting someone else's stuff into
ibiblio, where I need to make sure of all the details for groupId,
license, the rest of the POM is accurate, etc.  Plus, it's not even
clear that doing so for a third-party app was the encouraged way to
go, vs. trying to get the third-party to do it themselves.  If I
should be doing it, I guess I'll work to make an upload bundle for
tagsoup 1.0 tomorrow...


> I think maybe some either feature or convention for handling version
> changes to just POMs so they can be improved without another release
> of the software would help.  Some clarification/policy statements on
> when I should go straight to the project responsible for a jar vs.
> filing in Maven evangelism for uploads & for POM improvements might be
> helpful.  Certainly some of the 2.1 planned features (like being able
> to rely on geronimo-transaction & have that take care of anything
> relying in javax.transaction:jta...) could help.  I think some concept
> work needs to go into optional dependencies, because it we can't
> control when Spring decides they want to stop providing modularized
> jars, and move to a single jar that will essentially have all optional
> dependencies.  I'm not looking forward to getting my projects to work
> with Spring 2.0.

You can always have poms for different maven configurations against
only one jar, see
http://jroller.com/page/carlossg?entry=optional_dependencies_in_maven

>
> Believe me, this is all coming from someone who's been trying.  I've
> filed bug reports with Spring, and Lucene, other projects to get Maven
> uploads.  I've volunteered to work on providing and maintaining a
> Maven 2 build for an incubator project so that it will be easy to
> provide Maven jars & poms when the time comes.

You can see in http://opensource.atlassian.com/projects/spring/browse/SPR-1484
that Spring got pressure from their users to provide POMs, it's by far
the most popular issue. Any project that wants to succeed must listen
to their users


Again, it doesn't feel like that means much.  I had to work with you &
another helpful Maven user to get POMs for Spring 1.2.7.  And there
are no source or javadoc jars there.  Spring 1.2.8 doesn't have POMs,
and has been there for over a month:
http://ibiblio.org/maven2/org/springframework/spring-support/

Re: [RANT] This Maven thing is killing us....

[Brett Porter]

Ralph,

Thanks for this, it's very helpful.

On 5/07/2006 6:59 AM, Ralph Goers wrote:
However, this isn't even the biggest problem that has been hampering the 
Cocoon community. It is that there seems to be at best a 50% chance of 
getting a Maven 2 based Cocoon build to work due to dependencies failing 
to download from repositories.  Cocoon also consistently uses snapshot 
versions of some of its dependencies. While this isn't desirable, it is 
a fact of life.  From Cocoon's perspective we really need to treat them 
like they are a "private" release - i.e. they weren't formally released 
from wherever they came from, but we don't want to have to download them 
at every build since they will never change.


The first thing I'd suggest is for those having problems to try another 
mirror. I know requiring everyone to do that is a pain and not a long 
term solution, but I'd like to see how much that reduces the problem.


Regarding private releases, this is entirely possible just by giving 
them a version that isn't in the form of a snapshot. eg. if it is jetty 
6.0-SNAPSHOT, use 6.0-cocoon-1, 6.0-cocoon-2.


We'd considered this on the asf repository list: 
http://mail-archives.apache.org/mod_mbox/www-repository/200606.mbox/[EMAIL PROTECTED]


However, this changes the use case a bit, since it considered those only 
to be needed for development and full releases would be released against 
full releases of their dependencies.


It depends on how you use them as to the best solution here. I assume 
that they are customised for cocoon, so they shouldn't be considered to 
be the same as the original. In that case, I'd suggest you release them 
under your own groupID (maybe org.apache.cocoon.thirdparty) so that they 
don't conflict (bearing in mind that someone will transitively receive 
both that and the original if they are both used). I'm assuming this 
isn't the case as you are only bundling these modified versions into a 
distributable app, not as part of a reusable component?


Hope this helps,
Brett

--
Brett Porter <[EMAIL PROTECTED]>
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

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

Re: [RANT] This Maven thing is killing us....

[Carlos Sanchez]

On 7/4/06, Ralph Goers <[EMAIL PROTECTED]> wrote:



Carlos Sanchez wrote:
> If project A says it depends on B 1.0 and C says it depends on B 1.1,
> there's a conflict in Maven, Ant and anything you want to use, the
> difference is that Maven tries to do it for you, but you still can
> override that behaviour.
Actually, you can't in Maven 2 - at least not in any rational manner -
until http://jira.codehaus.org/browse/MNG-1577 is addressed.  The good
news is that there is a strong desire to move to Maven 2 in my
organization, so I may be given some time soon to do something about this.


Yes you can, it's not the best way to do it but you can, by adding
explicitly the dependency with the versoin you want to your pom. In
the very worst case you have to add all transitive deendencies to your
pom, like in Maven 1.



However, this isn't even the biggest problem that has been hampering the
Cocoon community. It is that there seems to be at best a 50% chance of
getting a Maven 2 based Cocoon build to work due to dependencies failing
to download from repositories.  Cocoon also consistently uses snapshot
versions of some of its dependencies. While this isn't desirable, it is
a fact of life.  From Cocoon's perspective we really need to treat them
like they are a "private" release - i.e. they weren't formally released
from wherever they came from, but we don't want to have to download them
at every build since they will never change.


You can publish that releases under your groupId, anything you want,
you can't force things to happen under other groupIds. If the other
projects don't want to make a release it doesn't matter if you use
maven or anything else.



Ralph

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





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

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

Re: [RANT] This Maven thing is killing us....

[Carlos Sanchez]

On 7/5/06, Stephen Duncan <[EMAIL PROTECTED]> wrote:

On 7/4/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>
> On 4 Jul 06, at 2:37 PM 4 Jul 06, Steve Loughran wrote:
>
> The metadata will never be perfect but right now I still
> think it's far from being ideal because we have no real active
> process of improving it on a large scale. Carlos puts in a _lot_ of
> time trying to correct things and absorb changes submitted for
> improvement but as mentioned in the previous message it's a matter of
> education and automated tools running to point people in the right
> direction.

Well, but it seems (recently?) that a policy has been put into place
that POMs already in the repository should not be corrected or
improved, in order to preserve repeatability for builds depending on
the existing version, and that corrections should be done by making
new releases.  It's hard enough to get projects to care about
providing Maven POMs, but to ask for a new release seems a bit much.


There's always the possibiblity of adding a new version ourselves with
a build number, like 1.0-1 where only the pom changes. Only as an
exception when a project is dead or don't release often



It also may seem ideal to have projects take care of their own POMs,
but it makes it frustrating for users to provide information on fixes.
 I know, personally, I've cut down on contributing to central
repository improvement.  I've taken to simply installing new jars to
my internal repository, because asking individual projects to do it
gives slow-to-no returns.  I put top-level exclusions into
dependencyManagement rather than request changes to POMs, because
again, there seems no process for actually getting that to happen
that's not haphazard.  I'll try to work on doing better, but the
cost-reward ratio isn't helping.


Well, if everybody does that then there's no community benefit and we
all lose. When I need something not in ibiblio I put it there because
it's not much harder than putting it in my local repo.



I think maybe some either feature or convention for handling version
changes to just POMs so they can be improved without another release
of the software would help.  Some clarification/policy statements on
when I should go straight to the project responsible for a jar vs.
filing in Maven evangelism for uploads & for POM improvements might be
helpful.  Certainly some of the 2.1 planned features (like being able
to rely on geronimo-transaction & have that take care of anything
relying in javax.transaction:jta...) could help.  I think some concept
work needs to go into optional dependencies, because it we can't
control when Spring decides they want to stop providing modularized
jars, and move to a single jar that will essentially have all optional
dependencies.  I'm not looking forward to getting my projects to work
with Spring 2.0.


You can always have poms for different maven configurations against
only one jar, see
http://jroller.com/page/carlossg?entry=optional_dependencies_in_maven



Believe me, this is all coming from someone who's been trying.  I've
filed bug reports with Spring, and Lucene, other projects to get Maven
uploads.  I've volunteered to work on providing and maintaining a
Maven 2 build for an incubator project so that it will be easy to
provide Maven jars & poms when the time comes.


You can see in http://opensource.atlassian.com/projects/spring/browse/SPR-1484
that Spring got pressure from their users to provide POMs, it's by far
the most popular issue. Any project that wants to succeed must listen
to their users



Oh, another quality issue.  -source and -javadoc jars.  It really
slows down running eclipse:eclipse when half or more of my
dependencies don't have these jars.  And a lot don't.  All of
spring-1.2.7, for instance.


You can download Spring, jar the stuff up and submit them for adding
to ibiblio. I don't understand how can you complain when maven is the
only project providing that feature.



My purpose isn't just to complain.  I just think that there's going to
have be more to it than "it'll get better over time" for the central
repository to improve, because, from the narrow view of the things I
use, it's getting a bit worse, not better right now.


My view is that it's getting better, more jars, more poms, more
javadocs, more sources, and more and more projects caring about the
repository, being a must for them.



--
Stephen Duncan Jr
www.stephenduncanjr.com

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





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

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

Re: [RANT] This Maven thing is killing us....

[Ralph Goers]

Carlos Sanchez wrote:

If project A says it depends on B 1.0 and C says it depends on B 1.1,
there's a conflict in Maven, Ant and anything you want to use, the
difference is that Maven tries to do it for you, but you still can
override that behaviour.
Actually, you can't in Maven 2 - at least not in any rational manner - 
until http://jira.codehaus.org/browse/MNG-1577 is addressed.  The good 
news is that there is a strong desire to move to Maven 2 in my 
organization, so I may be given some time soon to do something about this.


However, this isn't even the biggest problem that has been hampering the 
Cocoon community. It is that there seems to be at best a 50% chance of 
getting a Maven 2 based Cocoon build to work due to dependencies failing 
to download from repositories.  Cocoon also consistently uses snapshot 
versions of some of its dependencies. While this isn't desirable, it is 
a fact of life.  From Cocoon's perspective we really need to treat them 
like they are a "private" release - i.e. they weren't formally released 
from wherever they came from, but we don't want to have to download them 
at every build since they will never change.


Ralph

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

Re: [RANT] This Maven thing is killing us....

[Stephen Duncan]

On 7/4/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:


On 4 Jul 06, at 2:37 PM 4 Jul 06, Steve Loughran wrote:

The metadata will never be perfect but right now I still
think it's far from being ideal because we have no real active
process of improving it on a large scale. Carlos puts in a _lot_ of
time trying to correct things and absorb changes submitted for
improvement but as mentioned in the previous message it's a matter of
education and automated tools running to point people in the right
direction.


Well, but it seems (recently?) that a policy has been put into place
that POMs already in the repository should not be corrected or
improved, in order to preserve repeatability for builds depending on
the existing version, and that corrections should be done by making
new releases.  It's hard enough to get projects to care about
providing Maven POMs, but to ask for a new release seems a bit much.

It also may seem ideal to have projects take care of their own POMs,
but it makes it frustrating for users to provide information on fixes.
I know, personally, I've cut down on contributing to central
repository improvement.  I've taken to simply installing new jars to
my internal repository, because asking individual projects to do it
gives slow-to-no returns.  I put top-level exclusions into
dependencyManagement rather than request changes to POMs, because
again, there seems no process for actually getting that to happen
that's not haphazard.  I'll try to work on doing better, but the
cost-reward ratio isn't helping.

I think maybe some either feature or convention for handling version
changes to just POMs so they can be improved without another release
of the software would help.  Some clarification/policy statements on
when I should go straight to the project responsible for a jar vs.
filing in Maven evangelism for uploads & for POM improvements might be
helpful.  Certainly some of the 2.1 planned features (like being able
to rely on geronimo-transaction & have that take care of anything
relying in javax.transaction:jta...) could help.  I think some concept
work needs to go into optional dependencies, because it we can't
control when Spring decides they want to stop providing modularized
jars, and move to a single jar that will essentially have all optional
dependencies.  I'm not looking forward to getting my projects to work
with Spring 2.0.

Believe me, this is all coming from someone who's been trying.  I've
filed bug reports with Spring, and Lucene, other projects to get Maven
uploads.  I've volunteered to work on providing and maintaining a
Maven 2 build for an incubator project so that it will be easy to
provide Maven jars & poms when the time comes.

Oh, another quality issue.  -source and -javadoc jars.  It really
slows down running eclipse:eclipse when half or more of my
dependencies don't have these jars.  And a lot don't.  All of
spring-1.2.7, for instance.

My purpose isn't just to complain.  I just think that there's going to
have be more to it than "it'll get better over time" for the central
repository to improve, because, from the narrow view of the things I
use, it's getting a bit worse, not better right now.

--
Stephen Duncan Jr
www.stephenduncanjr.com

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

Re: [RANT] This Maven thing is killing us....

[Jason van Zyl]

On 4 Jul 06, at 2:37 PM 4 Jul 06, Steve Loughran wrote:


Carlos Sanchez wrote:

The repository is as good as the users/projects make it. There's no
difference at all with using ant and including the wrong jars, maybe
the problem is that how to fix it in maven is not as easy as in ant.
If project A says it depends on B 1.0 and C says it depends on B 1.1,
there's a conflict in Maven, Ant and anything you want to use, the
difference is that Maven tries to do it for you, but you still can
override that behaviour.



It seems to me that the difference in ant, the duty to set up your  
classpath belongs to the project alone, so you, the build.xml  
author are the only one who can make a mess of your CP.


This also means that you are the only one who can help create a  
correct classpath.




However, on any system with transitive dependencies, you are ceding  
control of your classpath to other programs out there.


No, you are ceding control of the dependency chain to the projects  
which you are depending on.


Even if you think you know exactly what the dependency graph of  
your app is, an update to a new version of any your dependencies  
can pull in new metadata, with a new set of dependencies, and  
potentially a new classpath.


So how is that different then with Ant when you try a new version of  
a dependency? You're going to have to go hunt down the dependencies  
or copy in a new set of dependencies provided by that project. It  
doesn't matter what you use to build if you change a dependency you  
are subject to change.




This is not a maven-specific problem; anything that supports  
transitive dependency logic can suffer from it. Gump and Ivy could,  
though in both cases the descriptors tend to be hand-written tuned  
to not exhibit the problem. (in gump most projects dont export  
dependencies, as the default is compile-time-only).




Ok, I agree this is not a Maven specific problem.

You cannot maintain metadata for a growing number of projects and you  
can't stay on top of projects changing all the time except in  
reaction of problems. The projects themselves must provide useful  
metadata and it is of value to them to do so.


> Right now we are in a good position with a huge number of users  
trying

> and testing the metadata in the repository, and forcing projects to
> support maven by providing good data.

That still assumes that transitive dependencies are a good thing,  
and that perfect metadata is achievable. I'm not sure about either  
of those. I also think they're straying dangerously close to one of  
the big software engineering tar-pits: versioning.




Transitive dependencies in the state they are in now can be  
problematic. What can be done to fix this? The repository manager  
running integrity checks, some visualization tools to help people see  
the chains easily, and visualization tools to help detect conflicts.  
For both of these things IDE integration will be key to making this  
easy for users. Big challenges, and not trivial but certainly not  
untenable. The metadata will never be perfect but right now I still  
think it's far from being ideal because we have no real active  
process of improving it on a large scale. Carlos puts in a _lot_ of  
time trying to correct things and absorb changes submitted for  
improvement but as mentioned in the previous message it's a matter of  
education and automated tools running to point people in the right  
direction.



-steve

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




Jason van Zyl
[EMAIL PROTECTED]




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

Re: [RANT] This Maven thing is killing us....

[Jason van Zyl]

On 4 Jul 06, at 1:45 PM 4 Jul 06, Steve Loughran wrote:


In a way, many of the stuff in M2 is experimental; a build tool  
that effectively encodes beliefs about how a project should be  
structured and delivered, focusing on component-based development  
instead of application dev. I also think its time to look at how  
well some of the experiment is working.




You make it sound like we're some sort of cult :-)

The phrase "encoding beliefs" is an inaccurate description. It's is  
simply the pursuit of best practices for software development and  
those practices are very much mutable, this thread being very good  
evidence of that. We also not only focused on component-oriented  
development, we ourselves develop applications ourselves and we're  
trying to make that coherent as well.


Personally, I always experience a bit of fear when adding a new  
dependency to a project. the repository stuff, and estimate a  
couple of hours to get every addition stable, primarily by building  
up a good exclusion list.


This is the place to talk about that as people shouldn't be fearful  
adding dependencies. But people who have an ideal setup here they  
completely control the repository they use internally don't have many  
of the problems that people are experiencing in this thread. Having a  
public repository of high quality is not a trivial task.




Is it worse than before? Better? Or just, well, different? and if  
things are either worse or not as good as they could be, what can  
be changed?




The process is absolutely better. The process couple with the public  
infrastructure we have now is problematic. Two very different things.


One underlying cause seems to be pom quality. Open source software  
dev is a vast collection of loosely coupled projects, and what we  
get in the repository in terms of metadata matches this model. Each  
project produces artifacts that match their immediate needs, with  
POM files that appear to work at the time of publishing. Maven then  
caches those and freezes that metadata forever, even if it turns  
out that the metadata was wrong.  There's far better coherence  
within Gump, where the metadata is effectively maintained more by  
the gump team themselves than by the individual projects.


There is absolutely no way this is scalable over time. You are saying  
that a small group of people can maintain metadata for projects that  
they are not intimately involved with? That's like saying that people  
who live outside your community have a better chance at describing  
your community. I really just don't think that's possible. How many  
problems has Gump had over the years trying to maintain the metadata?  
Huge problems, almost never in sync with projects. You basically find  
out when it breaks and go back track most of the time. There is no  
doubt that the same process will happen with Maven where users of  
Maven will eventually make their metadata better but that will take  
time. Gump has been around for 5-6 years now. People are really only  
starting to use Maven 2.x which is closing in on being out for a  
year. I am will to bet in another year a great number of the problems  
seen in this thread will be gone. I would argue that Gump will not  
work precisely because it is not the projects themselves maintaining  
the metadata. Projects using Maven will eventually get it right  
because it provides some value to them to get it right.




Question is, what to do about it? And if the m2 repository was an  
attempt to leave the problems of the M1 repository behind, has it  
worked?




To a large extent I would say we have fixed many of the problems on a  
technical level. Correctly the metadata and educating projects as to  
how best maintain is it is a social problem and a matter of  
education. Couple that with some automated integrity checks that will  
be performed by the repository manager.



-steve





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




Jason van Zyl
[EMAIL PROTECTED]




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

Re: [RANT] This Maven thing is killing us....

[Niclas Hedhman]

On Tuesday 04 July 2006 20:53, Carlos Sanchez wrote:
> If project A says it depends on B 1.0 and C says it depends on B 1.1,
> there's a conflict in Maven, Ant and anything you want to use, the
> difference is that Maven tries to do it for you, but you still can
> override that behaviour.

Well, since Cocoon is going for OSGi, this does not need to be a problem per 
se. However, Maven currently doesn't support the CP resolution needed in 
complex OSGi builds (such as Eclipse itself). There are people investigating 
what would be needed, but no promises have been made so far.

One main issue is that OSGi is not concerned over versioning of the jars, but 
versioning of the packages (normal Java packages for the uninitiated). More 
exactly, the jar is essentially just a delivery container of the packages, 
and the resulting "classpath" may be a subset of a jar and mixed in with 
packages from another version of the same jar.

For the record; Ant is not capable of handling this perfectly either.
Also; Very often it is not need for OSGi development.

Cheers
Niclas

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

Re: [RANT] This Maven thing is killing us....

[Brett Porter]

On 4/07/2006 9:34 PM, Torsten Curdt wrote:

I agree that the whole maven2 situation is currently far less than
just acceptable ...but TBH I am not sure the maven team is (or was?)
really aware of all the problems we have.


Not until you forwarded a message (and thanks for doing so). We don't 
really have the bandwidth to follow along with everyone that is 
converting builds...




Maybe we can get a statement on the maven self-update and
unreliable-messed-up-repository situation. From what it sounds they
are working on it. So let's not work this out in our little cocoon
corner but let's hear what they have to say.


I think we all recognise there are some issues, particularly with 
ibiblio dropping out consistently, and also issues with transitivity and 
versioning that have been raised on the [EMAIL PROTECTED] thread. I'm not sure 
what "messed up repository" issues you are having, but would like to 
hear about it.


I know this stuff needs a good hard looking at, but I don't believe 
there is anything insurmountable here.


- Brett

--
Brett Porter <[EMAIL PROTECTED]>
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

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

Re: [RANT] This Maven thing is killing us....

[Alexandre Poitras]

I think having a transitive dependency repository is good. Of course,
you depend upon the community good willing but it is the same
principle for a wiki. Quality will increase if more and more people
participate. I think the Maven Evangelisation guide should be more
visible on the Maven web site because right now there aren't a lot of
people who know how to submit a correction.

On 7/4/06, Steve Loughran <[EMAIL PROTECTED]> wrote:

Jesse Kuhnert wrote:
> Please, let's not go overboardAnt is nice like c is nice when you need
> to get small things done. If you have to maintain very large projects with
> varying releases/users/etc maven is a much better choice. Even with its
> current flaws. =p

I'm not arguing with that, its the transitive dependency thing I'm
commenting on.

when you write a project, your goal is to get it compile, to create
whatever artifacts you create. If you include too many things in your
dependency list (like commons-logging instead of commons-logging-api),
your stuff still build happily, it just has excessive dependencies, as
now it thinks logkit comes in. The people consuming your jar either
propagate the problem, or have to do stuff like :

   
 
   
   
 
 
 
   

That's the issue. With transitive dependencies, you inherit any error
made by anything you depend on. And while you can upgrade versions at
the touch of a file, you have to recheck the dependencies whenver you
upgrade, or junk creeps in.

Now, I think its really nice to know what something was built with; its
a wonderful hint as to what you should be using, but its nothing more. A
hint. Something to be looked at, and, in the case of the example above,
then pretty much discarded.

-Steve

-
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: [RANT] This Maven thing is killing us....

[Nicolas De Loof]

Say if xmlrpc decide to split into xmlrpc-common, xmlrpc-server,
xmlrpc-client, xmlrcp-all then it can say that it "conflict" with xmlrpc
- and for xmlrpc-all it can say that it "replace" xmlrpc.
Still, user intervention is required, but thats better than having the
same library on the path multiple times, just due to the fact that the
name differs.

  

AFAIK this this what the  element is designed for in POMs
If you ask for xmlrpc and new version has split as you suugest, a POM 
can be deployed with relocation to xmlrpc-all


This message contains information that may be privileged or confidential and is 
the property of the Capgemini Group. It is intended only for the person to whom 
it is addressed. If you are not the intended recipient,  you are not authorized 
to read, print, retain, copy, disseminate,  distribute, or use this message or 
any part thereof. If you receive this  message in error, please notify the 
sender immediately and delete all  copies of this message.


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

Re: [RANT] This Maven thing is killing us....

[Steve Loughran]

Jesse Kuhnert wrote:

Please, let's not go overboardAnt is nice like c is nice when you need
to get small things done. If you have to maintain very large projects with
varying releases/users/etc maven is a much better choice. Even with its
current flaws. =p


I'm not arguing with that, its the transitive dependency thing I'm 
commenting on.


when you write a project, your goal is to get it compile, to create 
whatever artifacts you create. If you include too many things in your 
dependency list (like commons-logging instead of commons-logging-api), 
your stuff still build happily, it just has excessive dependencies, as 
now it thinks logkit comes in. The people consuming your jar either 
propagate the problem, or have to do stuff like :


  

  
  



  

That's the issue. With transitive dependencies, you inherit any error 
made by anything you depend on. And while you can upgrade versions at 
the touch of a file, you have to recheck the dependencies whenver you 
upgrade, or junk creeps in.


Now, I think its really nice to know what something was built with; its 
a wonderful hint as to what you should be using, but its nothing more. A 
hint. Something to be looked at, and, in the case of the example above, 
then pretty much discarded.


-Steve

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

Re: [RANT] This Maven thing is killing us....

[Carlos Sanchez]

The "replace" dependency is alredy logged in jira. Not sure about the
conflict one.


On 7/4/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:

Hi!
> If project A says it depends on B 1.0 and C says it depends on B 1.1,
> there's a conflict in Maven, Ant and anything you want to use, the
> difference is that Maven tries to do it for you, but you still can
> override that behaviour.
We also ended up putting our jars in svn again and using only system
jars with a path to the jar in our pom.
We have 50 direct dependencies, maintaining exclusion lists is a pain in
the a** as you have really spent a couple of hours to get everything
right again when you add a new dependency.

And the problem is not only a version number difference. Also a project
might decide to change its artifactId - or split into different smaller
pieces.
THAT was the real bummer for us.

Whats missing in pom.xml is something like: replaces and conflicts
So a artifact might say, ok, I "replace" any other artifact or I cant
work together "conflict" with one.

Say if xmlrpc decide to split into xmlrpc-common, xmlrpc-server,
xmlrpc-client, xmlrcp-all then it can say that it "conflict" with xmlrpc
- and for xmlrpc-all it can say that it "replace" xmlrpc.
Still, user intervention is required, but thats better than having the
same library on the path multiple times, just due to the fact that the
name differs.

Maybe also a "contains" would be nice, so xmlrpc-all can say it already
"contains" the server,client and common part.

But I have to admit, I dont want the one programming the dependency
solver ;-)

Ciao,
Mario


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





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

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

Re: [RANT] This Maven thing is killing us....

[Mario Ivankovits]

Hi!
> If project A says it depends on B 1.0 and C says it depends on B 1.1,
> there's a conflict in Maven, Ant and anything you want to use, the
> difference is that Maven tries to do it for you, but you still can
> override that behaviour.
We also ended up putting our jars in svn again and using only system
jars with a path to the jar in our pom.
We have 50 direct dependencies, maintaining exclusion lists is a pain in
the a** as you have really spent a couple of hours to get everything
right again when you add a new dependency.

And the problem is not only a version number difference. Also a project
might decide to change its artifactId - or split into different smaller
pieces.
THAT was the real bummer for us.

Whats missing in pom.xml is something like: replaces and conflicts
So a artifact might say, ok, I "replace" any other artifact or I cant
work together "conflict" with one.

Say if xmlrpc decide to split into xmlrpc-common, xmlrpc-server,
xmlrpc-client, xmlrcp-all then it can say that it "conflict" with xmlrpc
- and for xmlrpc-all it can say that it "replace" xmlrpc.
Still, user intervention is required, but thats better than having the
same library on the path multiple times, just due to the fact that the
name differs.

Maybe also a "contains" would be nice, so xmlrpc-all can say it already
"contains" the server,client and common part.

But I have to admit, I dont want the one programming the dependency
solver ;-)

Ciao,
Mario


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

Re: [RANT] This Maven thing is killing us....

[Jesse Kuhnert]

Please, let's not go overboardAnt is nice like c is nice when you need
to get small things done. If you have to maintain very large projects with
varying releases/users/etc maven is a much better choice. Even with its
current flaws. =p

On 7/4/06, Steve Loughran <[EMAIL PROTECTED]> wrote:


Carlos Sanchez wrote:
> The repository is as good as the users/projects make it. There's no
> difference at all with using ant and including the wrong jars, maybe
> the problem is that how to fix it in maven is not as easy as in ant.
>
> If project A says it depends on B 1.0 and C says it depends on B 1.1,
> there's a conflict in Maven, Ant and anything you want to use, the
> difference is that Maven tries to do it for you, but you still can
> override that behaviour.
>


It seems to me that the difference in ant, the duty to set up your
classpath belongs to the project alone, so you, the build.xml author are
the only one who can make a mess of your CP.

However, on any system with transitive dependencies, you are ceding
control of your classpath to other programs out there. Even if you think
you know exactly what the dependency graph of your app is, an update to
a new version of any your dependencies can pull in new metadata, with a
new set of dependencies, and potentially a new classpath.

This is not a maven-specific problem; anything that supports transitive
dependency logic can suffer from it. Gump and Ivy could, though in both
cases the descriptors tend to be hand-written tuned to not exhibit the
problem. (in gump most projects dont export dependencies, as the default
is compile-time-only).

> Right now we are in a good position with a huge number of users trying
> and testing the metadata in the repository, and forcing projects to
> support maven by providing good data.

That still assumes that transitive dependencies are a good thing, and
that perfect metadata is achievable. I'm not sure about either of those.
I also think they're straying dangerously close to one of the big
software engineering tar-pits: versioning.

-steve

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





--
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.

Re: [RANT] This Maven thing is killing us....

[Steve Loughran]

Carlos Sanchez wrote:

The repository is as good as the users/projects make it. There's no
difference at all with using ant and including the wrong jars, maybe
the problem is that how to fix it in maven is not as easy as in ant.

If project A says it depends on B 1.0 and C says it depends on B 1.1,
there's a conflict in Maven, Ant and anything you want to use, the
difference is that Maven tries to do it for you, but you still can
override that behaviour.




It seems to me that the difference in ant, the duty to set up your 
classpath belongs to the project alone, so you, the build.xml author are 
the only one who can make a mess of your CP.


However, on any system with transitive dependencies, you are ceding 
control of your classpath to other programs out there. Even if you think 
you know exactly what the dependency graph of your app is, an update to 
a new version of any your dependencies can pull in new metadata, with a 
new set of dependencies, and potentially a new classpath.


This is not a maven-specific problem; anything that supports transitive 
dependency logic can suffer from it. Gump and Ivy could, though in both 
cases the descriptors tend to be hand-written tuned to not exhibit the 
problem. (in gump most projects dont export dependencies, as the default 
is compile-time-only).


> Right now we are in a good position with a huge number of users trying
> and testing the metadata in the repository, and forcing projects to
> support maven by providing good data.

That still assumes that transitive dependencies are a good thing, and 
that perfect metadata is achievable. I'm not sure about either of those. 
I also think they're straying dangerously close to one of the big 
software engineering tar-pits: versioning.


-steve

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

Re: RE: [RANT] This Maven thing is killing us....

[Carlos Sanchez]

The repository is as good as the users/projects make it. There's no
difference at all with using ant and including the wrong jars, maybe
the problem is that how to fix it in maven is not as easy as in ant.

If project A says it depends on B 1.0 and C says it depends on B 1.1,
there's a conflict in Maven, Ant and anything you want to use, the
difference is that Maven tries to do it for you, but you still can
override that behaviour.

Right now we are in a good position with a huge number of users trying
and testing the metadata in the repository, and forcing projects to
support maven by providing good data.

On 7/4/06, Torsten Curdt <[EMAIL PROTECTED]> wrote:

Sorry, for the cross-post ...but it seems we need a dialog here
somehow. We now have two threads on two different mailing
lists/communities that really should talk to each other.

> I propose to commit again all JARs into, say, cocoon/trunk/m2repo
> and then tell Maven at build time to use that directory in the
> checkout area as first repository server in the search list.

So where is the big difference? For every fresh checkout you download
the jars from subversion.

Guys I have no solution at hand but let's not throw out the baby with
the bath water. I would be good to summarize all the pain points and
post them over in maven land. The pain being so bad that we are
(somehow) considering going back to ant should be alarming enough.

Another point seems to be forgotten in this discussion so far - the
legal aspects of distributing jars. Does the ASF want to re-distribute
3rd party jars? Plus: based on a chat Sylvain and me had with Cliff
during ApacheCon it seems we could have blocks providing bridging code
to LGPL ...as long as we do not provide the jar and the block is
optional. (Sylvain, did I summarize that correctly?)

I agree that the whole maven2 situation is currently far less than
just acceptable ...but TBH I am not sure the maven team is (or was?)
really aware of all the problems we have.

Maybe we can get a statement on the maven self-update and
unreliable-messed-up-repository situation. From what it sounds they
are working on it. So let's not work this out in our little cocoon
corner but let's hear what they have to say.

cheers
--
Torsten

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





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

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

Re: [RANT] This Maven thing is killing us....

[Tamás Cservenák]

Hi,

just to mention a Maven Proxy alternative Proximity, that collects these
kind of stats. Currently (ver RC2) contains a simple Stat implementation
that is not transient (on restart it "forgets" the stats) and it offers only
few a "top10" views just to demonstrate the feature, the final release will
have some more advanced capabilities.

Proximity (on the screenshot below) actually shows served artifacts
(requested by M2 clients), local hits (items found in local cache) and
remote hits (items that had to be [re]fetched from proxied remote
reposes)...

https://is-micro.myip.hu/~cstamas/proximity-stats.jpg


Have fun!
~t~

On 7/3/06, Steve Loughran <[EMAIL PROTECTED]> wrote:


yeah, some httpd stats could be interesting too. Perhaps someone hosting
an internal repo could see that.

Of course, with caching, you explicitly dont get told whenever something
builds against log4j, only when something first pulls it down. There's
another reason polling would be interesting I guess; statistics.

Re: [RANT] This Maven thing is killing us....

[Steve Loughran]

Torsten Curdt wrote:

Sorry, for the cross-post ...but it seems we need a dialog here
somehow. We now have two threads on two different mailing
lists/communities that really should talk to each other.


I propose to commit again all JARs into, say, cocoon/trunk/m2repo
and then tell Maven at build time to use that directory in the
checkout area as first repository server in the search list.


So where is the big difference? For every fresh checkout you download
the jars from subversion.

Guys I have no solution at hand but let's not throw out the baby with
the bath water. I would be good to summarize all the pain points and
post them over in maven land. The pain being so bad that we are
(somehow) considering going back to ant should be alarming enough.


Actually, speaking on behalf of the ant team, can I extend a big 
(tentative) welcome back :)





Another point seems to be forgotten in this discussion so far - the
legal aspects of distributing jars. Does the ASF want to re-distribute
3rd party jars? Plus: based on a chat Sylvain and me had with Cliff
during ApacheCon it seems we could have blocks providing bridging code
to LGPL ...as long as we do not provide the jar and the block is
optional. (Sylvain, did I summarize that correctly?)


There is always the option of a public yet locked down repository with 
the sun jars and/or the other external dependencies. Working on a 
sourceforge repo, we keep extra stuff under SCM, and have the dependency 
logic look there first.


you could even have an SCM-managed repo on sourceforge or codehaus for 
this other stuff, though it would be a somewhat public admission that 
the main repository has failed.



I agree that the whole maven2 situation is currently far less than
just acceptable ...but TBH I am not sure the maven team is (or was?)
really aware of all the problems we have.

Maybe we can get a statement on the maven self-update and
unreliable-messed-up-repository situation. From what it sounds they
are working on it. So let's not work this out in our little cocoon
corner but let's hear what they have to say.



In a way, many of the stuff in M2 is experimental; a build tool that 
effectively encodes beliefs about how a project should be structured and 
delivered, focusing on component-based development instead of 
application dev. I also think its time to look at how well some of the 
experiment is working.


Personally, I always experience a bit of fear when adding a new 
dependency to a project. the repository stuff, and estimate a couple of 
hours to get every addition stable, primarily by building up a good 
exclusion list.


M2, and  in ant, has changed the nature of the problem, 
from "what versions of what things do I need with this?" to "how much of 
this stuff do I really need?" and "why are my junit tests not compiling 
with an error about assertTrue not being known", the latter seguing into 
"where is junit3.7 coming from?".  Its a form of progress, but still 
painful. Similarly, keeping a repository cache under SCM does at least 
give you a structured layout for storing multiple versions of stuff 
under SCM, with flick-of-a-switch access to new versions. It just adds 
an extra step "pom creation/fixup" to the process.


Is it worse than before? Better? Or just, well, different? and if things 
are either worse or not as good as they could be, what can be changed?


One underlying cause seems to be pom quality. Open source software dev 
is a vast collection of loosely coupled projects, and what we get in the 
repository in terms of metadata matches this model. Each project 
produces artifacts that match their immediate needs, with POM files that 
appear to work at the time of publishing. Maven then caches those and 
freezes that metadata forever, even if it turns out that the metadata 
was wrong.  There's far better coherence within Gump, where the metadata 
is effectively maintained more by the gump team themselves than by the 
individual projects.


Question is, what to do about it? And if the m2 repository was an 
attempt to leave the problems of the M1 repository behind, has it worked?


-steve





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

Re: RE: [RANT] This Maven thing is killing us....

[Torsten Curdt]

Sorry, for the cross-post ...but it seems we need a dialog here
somehow. We now have two threads on two different mailing
lists/communities that really should talk to each other.


I propose to commit again all JARs into, say, cocoon/trunk/m2repo
and then tell Maven at build time to use that directory in the
checkout area as first repository server in the search list.


So where is the big difference? For every fresh checkout you download
the jars from subversion.

Guys I have no solution at hand but let's not throw out the baby with
the bath water. I would be good to summarize all the pain points and
post them over in maven land. The pain being so bad that we are
(somehow) considering going back to ant should be alarming enough.

Another point seems to be forgotten in this discussion so far - the
legal aspects of distributing jars. Does the ASF want to re-distribute
3rd party jars? Plus: based on a chat Sylvain and me had with Cliff
during ApacheCon it seems we could have blocks providing bridging code
to LGPL ...as long as we do not provide the jar and the block is
optional. (Sylvain, did I summarize that correctly?)

I agree that the whole maven2 situation is currently far less than
just acceptable ...but TBH I am not sure the maven team is (or was?)
really aware of all the problems we have.

Maybe we can get a statement on the maven self-update and
unreliable-messed-up-repository situation. From what it sounds they
are working on it. So let's not work this out in our little cocoon
corner but let's hear what they have to say.

cheers
--
Torsten

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

Re: AW: AW: [RANT] This Maven thing is killing us....

[Brett Porter]

On 4/07/2006 12:49 AM, [EMAIL PROTECTED] wrote:
Hi! 

Brett, can you give some more information about the cleanup script on the server? I found nothing in JIRA. It would be a great help for us if a simple server solution exists. 


There isn't anything prepared, but if you do so I'm sure it would be 
valuable to share. It need only remove files older than the current one 
(ie, keep metadata files and the latest snapshot).


It's a feature that's been requested for the repository manager too.



Where is the performance problem with the snapshot feature? I can see maven downloads new metadata (once a day, as specified), it should be visible in the metadata that there is a new version on the server, so there are no wasted server roundtrips. 


If you use uniqueVersion=false, then the metadata is no longer in play 
and it has to check if the SNAPSHOT file has changed (using 
If-Modified-Since). It was doing this far more often than was necessary.


It's been a while since I tinkered with it and don't exactly remember 
the problem, but I think it's all documented in MNG-1908. We should try 
and get this fixed in Maven 2.0.5.


Thanks for your patience.

- Brett

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

AW: AW: [RANT] This Maven thing is killing us....

[roger.butenuth]

Hi! 

Steve is right, one of the core features is currently broken. Currently we are 
in the "startup phase" of our project with few developers, so sending an email 
around "clear your local repository" is an option.

We hope the bug is fixed before the full team is working. If not, we will have 
to use uniqueVersion=true (and waste disk space).

Brett, can you give some more information about the cleanup script on the 
server? I found nothing in JIRA. It would be a great help for us if a simple 
server solution exists. 

Where is the performance problem with the snapshot feature? I can see maven 
downloads new metadata (once a day, as specified), it should be visible in the 
metadata that there is a new version on the server, so there are no wasted 
server roundtrips. 

Roger

> -Ursprüngliche Nachricht-
> Von: Brett Porter [mailto:[EMAIL PROTECTED] 
> Gesendet: Montag, 3. Juli 2006 14:27
> An: Maven Developers List
> Betreff: Re: AW: [RANT] This Maven thing is killing us
> 
> The original snapshot feature works just fine.
> 
> There was a particular variation of the feature added that 
> doesn't work as designed. (MNG-1908). The variation works 
> exactly the same way but reuses the file on the server.
> 
> Using uniqueVersion = false (the default) and a clean up 
> script on the server is a workaround.
> 
> On 3/07/2006 10:00 PM, Steve Loughran wrote:
> > [EMAIL PROTECTED] wrote:
> >> Unfortunately the SNAPSHOT-feature is broken (at least in 2.0.4): 
> >> When you have a copy of a snapshot versioned artifact, the 
> jar is not 
> >> updated when a new jar with same snapshot version is 
> uploaded to the 
> >> repository. I already filed this as a bug and hope it will 
> be fixed 
> >> in 2.0.5. It is annoying to increase version numbers during 
> >> development or sending mails around "please delete xyz in 
> you local repository...
> >>
> >> Roger
> > 
> > If artifact sharing at snapshot time is not working, then 
> one of the 
> > nominal core features of maven "better x-team dev" isnt. 
> What is the 
> > test process here?
> > 
> > -steve
> > 
> > 
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED] For 
> > additional commands, e-mail: [EMAIL PROTECTED]
> > 
> 
> 
> --
> Brett Porter <[EMAIL PROTECTED]>
> Apache Maven - http://maven.apache.org/
> Better Builds with Maven - http://library.mergere.com/
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED] For 
> additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

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

Re: [RANT] This Maven thing is killing us....

[Steve Loughran]

Brett Porter wrote:

On 3/07/2006 10:22 PM, Steve Loughran wrote:
I'm kind of busy right now, so am not offering to do this, not until, 
say, September. But otherwise, it would be a really interesting thing 
to work on.  Anyone interesting in co-authoring?


Yep, I've been thinking about these issues for a while (and similar 
timeframe for being able to do any sort of work on it). I'd be 
interested in writing something on it.


OK, we could do something there; latex files in svn as an authoring tool 
unless you have a better suggestion.


In the mean time, I'd like to see some of the problems and ideas 
collated somewhere. I'm hoping some of it is already written down in the 
mails I have flagged.


I'm really keen to see the repository manager up and running as it will 
start to give us a better view of the information already in there and 
the ability to do some repository-wide analysis.


yeah, some httpd stats could be interesting too. Perhaps someone hosting 
an internal repo could see that.


Of course, with caching, you explicitly dont get told whenever something 
builds against log4j, only when something first pulls it down. There's 
another reason polling would be interesting I guess; statistics.




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

Re: [RANT] This Maven thing is killing us....

[Brett Porter]

On 3/07/2006 10:22 PM, Steve Loughran wrote:
I'm kind of busy right now, so am not offering to do this, not until, 
say, September. But otherwise, it would be a really interesting thing to 
work on.  Anyone interesting in co-authoring?


Yep, I've been thinking about these issues for a while (and similar 
timeframe for being able to do any sort of work on it). I'd be 
interested in writing something on it.


In the mean time, I'd like to see some of the problems and ideas 
collated somewhere. I'm hoping some of it is already written down in the 
mails I have flagged.


I'm really keen to see the repository manager up and running as it will 
start to give us a better view of the information already in there and 
the ability to do some repository-wide analysis.


Cheers,
Brett

--
Brett Porter <[EMAIL PROTECTED]>
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

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

Re: AW: [RANT] This Maven thing is killing us....

[Brett Porter]

The original snapshot feature works just fine.

There was a particular variation of the feature added that doesn't work 
as designed. (MNG-1908). The variation works exactly the same way but 
reuses the file on the server.


Using uniqueVersion = false (the default) and a clean up script on the 
server is a workaround.


On 3/07/2006 10:00 PM, Steve Loughran wrote:

[EMAIL PROTECTED] wrote:
Unfortunately the SNAPSHOT-feature is broken (at least in 2.0.4): When 
you have a copy of a snapshot versioned artifact, the jar is not 
updated when a new jar with same snapshot version is uploaded to the 
repository. I already filed this as a bug and hope it will be fixed in 
2.0.5. It is annoying to increase version numbers during development 
or sending mails around "please delete xyz in you local repository...


Roger 


If artifact sharing at snapshot time is not working, then one of the 
nominal core features of maven "better x-team dev" isnt. What is the 
test process here?


-steve


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




--
Brett Porter <[EMAIL PROTECTED]>
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

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

Re: [RANT] This Maven thing is killing us....

[Steve Loughran]

Edwin Punzalan wrote:


May I add, that when maven already downloaded a poor/invalid pom, even 
after fixing the pom in the repository, maven won't know that it's 
changed (unless the version changed) and it will not download it.  So 
you end up still using your local repo copy.


To re-download a pom, you have to delete your local copy first.

This is a good solution though: http://jira.codehaus.org/browse/MNG-1258


A complete forced rebuild is a bit of an opt out, but if you are using 
http then you can do  if-modified-since. Stuff in ftp and filesystems 
are different, but you could always do a checksum poll. After all, the 
stuff in the local cache is just that, a cache.


Maybe you need a revocation mechanism, in which repositories can not 
only publish stuff, they can revoke things. I'm not so sure about this, 
as it would complicate stuff.


The big issue is just pom quality. I've heard the blame put on projects 
that dont actually use maven, but I dont think that is the real problem. 
Its more that the artifact set needed to build something and the 
artifact set needed to use something are often different. Developers 
seem to stop after creating a pom that can build, even if that includes 
stuff that isnt needed. Possibly this is just ignorance; unless they see 
the complete list of dependencies, it isnt obvious what really is being 
pulled in. It can also be that if you explicitly ask for something like 
junit3.8.1 in test scope, you dont notice that something else is pushing 
junit3.7 in the runtime scope, but someone downstream who uses your 
stuff may find out that junit3.7 is creeping in via accidental 
transitive dependencies.


It would be very interesting to do a post-mortem of how well the 
transitive development stuff is working. Really. This is not an critique 
of what's been done, but a proposal to do reviews/interviews and a paper 
that would be of a grade you could present at any tier-1 software 
engineering conference, something like "Dependency management in 
community software development, lessons from the field"


-review of design goals of M1 and M2 repos, intro concepts of 
projects/artifacts, dependency lists, snapshots and version logic.

-interview people who worked with m2 as end user projects (cocoon, geronimo)
-open up the debate on whether transitive dependency is a good thing or not
-worry about security implications and explore vulnerabilities

-look at other users  of the repository (ivy, smartfrog) and what they 
do differently.

-look at alternatives and see whether they are better or worse
	-.NET strong versions that use MD5 hashes to bind; (secure, good in 
production, not in dev, no way to tell which version is older)
 	-GGF application repository service (hasnt really realised what the 
problems are yet)

-Java repository stuff in that JCP w.g
-CPAN
-RPM/APT repositories, esp, JPackage packaged java artifacts
Make some serious suggestions about how to fix it, both process-wise and 
technologically.


I'm kind of busy right now, so am not offering to do this, not until, 
say, September. But otherwise, it would be a really interesting thing to 
work on.  Anyone interesting in co-authoring?


-steve





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

Re: AW: [RANT] This Maven thing is killing us....

[Steve Loughran]

[EMAIL PROTECTED] wrote:

Unfortunately the SNAPSHOT-feature is broken (at least in 2.0.4): When you have a 
copy of a snapshot versioned artifact, the jar is not updated when a new jar with 
same snapshot version is uploaded to the repository. I already filed this as a bug 
and hope it will be fixed in 2.0.5. It is annoying to increase version numbers 
during development or sending mails around "please delete xyz in you local 
repository...

Roger 


If artifact sharing at snapshot time is not working, then one of the 
nominal core features of maven "better x-team dev" isnt. What is the 
test process here?


-steve


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

AW: [RANT] This Maven thing is killing us....

[roger.butenuth]

Hello!

Yes, 1908 is correct. Additionally, http://jira.codehaus.org/browse/MNG-2289 is 
related to the same problem.

I suppose more people will run into this problem because the usage of SNAPSHOTs 
is very convenient in large projects during the development phase. 

Roger

> -Ursprüngliche Nachricht-
> Von: Wendy Smoak [mailto:[EMAIL PROTECTED] 
> Gesendet: Montag, 3. Juli 2006 01:35
> An: Maven Developers List
> Betreff: Re: [RANT] This Maven thing is killing us
> 
> On 7/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Unfortunately the SNAPSHOT-feature is broken (at least in 
> 2.0.4): When you have a copy of a snapshot versioned 
> artifact, the jar is not updated when a new jar with same 
> snapshot version is uploaded to the repository. I already 
> filed this as a bug and hope it will be fixed in 2.0.5. It is 
> annoying to increase version numbers during development or 
> sending mails around "please delete xyz in you local repository...
> 
> Is it this issue?  http://jira.codehaus.org/browse/MNG-1908
> 
> --
> Wendy
> 
> -
> 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]

AW: [RANT] This Maven thing is killing us....

[roger.butenuth]

Hello!

I am not the first one with this problem, see 
http://jira.codehaus.org/browse/MNG-2289.

We are not using the uniqueVersion feature (we don't want all the versions in 
our repository).

We observe the behaviour with all our artifacts in a company maven-proxy. May 
be it does not happen against ibiblio, but that is difficult to check without 
the possibility to update things in ibiblio. 

Regards

Roger 

> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im 
> Auftrag von Carlos Sanchez
> Gesendet: Sonntag, 2. Juli 2006 22:34
> An: Maven Developers List
> Betreff: Re: [RANT] This Maven thing is killing us
> 
> I don't know what you're saying, you are the first one 
> complaining about it. SNAPSHOTS work for me
> 
> On 7/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Unfortunately the SNAPSHOT-feature is broken (at least in 
> 2.0.4): When you have a copy of a snapshot versioned 
> artifact, the jar is not updated when a new jar with same 
> snapshot version is uploaded to the repository. I already 
> filed this as a bug and hope it will be fixed in 2.0.5. It is 
> annoying to increase version numbers during development or 
> sending mails around "please delete xyz in you local repository...
> >
> > Roger
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Andrew Williams [mailto:[EMAIL PROTECTED]
> > > Gesendet: Sonntag, 2. Juli 2006 11:11
> > > An: Maven Developers List
> > > Betreff: Re: [RANT] This Maven thing is killing us
> > >
> > > This is only true for release repositories though, as a snapshot 
> > > repository will have an updated version when you re-deploy surely?
> > >
> > > Andy
> > >
> > > On Sun, 2006-07-02 at 07:01 +0800, Edwin Punzalan wrote:
> > > > May I add, that when maven already downloaded a
> > > poor/invalid pom, even
> > > > after fixing the pom in the repository, maven won't 
> know that it's 
> > > > changed (unless the version changed) and it will not
> > > download it.  So
> > > > you end up still using your local repo copy.
> > > >
> > > > To re-download a pom, you have to delete your local copy first.
> > > >
> > > > This is a good solution though:
> > > > http://jira.codehaus.org/browse/MNG-1258
> > > >
> > > >
> > > > Mike Perham wrote:
> > > > >> -Original Message-
> > > > >> From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
> > > > >> Sent: Saturday, July 01, 2006 2:59 PM
> > > > >> To: Maven Developers List
> > > > >> Subject: RE: [RANT] This Maven thing is killing us
> > > > >>
> > > > >>
> > > > >>
> > > > >>> Perhaps we can have a rule that every dependency MUST have
> > > > >>>
> > > > >> a declared
> > > > >>
> > > > >>>  and  element so that we know the
> > > > >>>
> > > > >> developer has thought
> > > > >>
> > > > >>> about the correct values for them, rather than always using 
> > > > >>> the defaults?
> > > > >>>
> > > > >> That's against Maven philosophy: conventions based builds.
> > > > >> Only specify
> > > > >> things that don't follow the defaults..
> > > > >>
> > > > >> I think the problems with poms are because they're 
> generated by 
> > > > >> default or converted from maven 1, or just uploaded by
> > > someone who
> > > > >> wants it there.
> > > > >> If a project is built using maven 2, the poms should 
> be correct.
> > > > >>
> > > > >>
> > > > >
> > > > > Agreed, but how do we solve the problem?  My 
> suggestion does not 
> > > > > force anyone to change their POMs _unless_ they want them
> > > hosted at central.
> > > > > The issue is that anything hosted at central necessarily
> > > becomes a
> > > > > publicly available component that others can use.  If
> > > people want to
> > > > > use the conventions, fine, but there obviously needs to
> > > be a higher
> > > > > standard to make your component publicly available for use by 
> > > > > others.  We are hurting nob

Re: [RANT] This Maven thing is killing us....

[Brett Porter]

yes, that's the one I was referring to, thanks!

On 3/07/2006 9:35 AM, Wendy Smoak wrote:

On 7/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Unfortunately the SNAPSHOT-feature is broken (at least in 2.0.4): When 
you have a copy of a snapshot versioned artifact, the jar is not 
updated when a new jar with same snapshot version is uploaded to the 
repository. I already filed this as a bug and hope it will be fixed in 
2.0.5. It is annoying to increase version numbers during development 
or sending mails around "please delete xyz in you local repository...


Is it this issue?  http://jira.codehaus.org/browse/MNG-1908





--
Brett Porter <[EMAIL PROTECTED]>
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

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

Re: [RANT] This Maven thing is killing us....

[Wendy Smoak]

On 7/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Unfortunately the SNAPSHOT-feature is broken (at least in 2.0.4): When you have a 
copy of a snapshot versioned artifact, the jar is not updated when a new jar with 
same snapshot version is uploaded to the repository. I already filed this as a bug 
and hope it will be fixed in 2.0.5. It is annoying to increase version numbers 
during development or sending mails around "please delete xyz in you local 
repository...


Is it this issue?  http://jira.codehaus.org/browse/MNG-1908

--
Wendy

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

Re: [RANT] This Maven thing is killing us....

[Brett Porter]

You are right. It was turned off in the late betas because we were'nt 
going to have time to verify the entire repository.


With the availability of tools, I think this could be reinstated for 
2.1, but I've since rethought it and would rather do this in a way that 
is more predictable (ie, even if the old POM is broken and we change it, 
people can still get reproducible builds by building against the old 
version).


Some of this was captured in a discussion I brought up about the POM, 
probably back in January. I fully intend to drag it back up when we get 
into the swing of 2.1.


- Brett

On 3/07/2006 2:33 AM, Kenney Westerhof wrote:

On Sun, 2 Jul 2006, Carlos Sanchez wrote:

Ah.. Well, it used to work in the beta's.. :)
There was a problem then with manually installed projects who lacked the
status field - it tried to download them from ibiblio which didn't have
them, and then the build failed. But that's a long time ago now.
But I'm probably wrong.. :)



--
Brett Porter <[EMAIL PROTECTED]>
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

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

Re: [RANT] This Maven thing is killing us....

[Brett Porter]

Now, they're referring to when uniqueVersion = false (which is not the 
default). That feature has always been broken, it was only discovered 
recently though, and when I attempted to fix it for 2.0.4 it caused a 
performance degradation and I decided to hold off until it could be more 
fully considered. It's all documented in JIRA, including the patch to 
make it work if you can live with all the extra connections.


- Brett

On 3/07/2006 7:04 AM, Jesse Kuhnert wrote:

Maybe they've been deploying versions using a normal repository element
instead of defining a snapshot repository and -SNAPSHOT version ?

On 7/2/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:


YeahEven though in my instance it wasn't what I wanted to happen (not
maven's fault, unrelated local patches..), I have seen definite 
updates of

SNAPSHOT builds with the same version.

You can pretty easily infer why it works by looking at the timestamp
generated poms from them...


On 7/2/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
>
> I don't know what you're saying, you are the first one complaining
> about it. SNAPSHOTS work for me
>
> On 7/2/06, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote:
> > Unfortunately the SNAPSHOT-feature is broken (at least in 2.0.4): 
When
> you have a copy of a snapshot versioned artifact, the jar is not 
updated
> when a new jar with same snapshot version is uploaded to the 
repository. I

> already filed this as a bug and hope it will be fixed in 2.0.5. It is
> annoying to increase version numbers during development or sending 
mails

> around "please delete xyz in you local repository...
> >
> > Roger
> >


--
Brett Porter <[EMAIL PROTECTED]>
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

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

Re: [RANT] This Maven thing is killing us....

[Jesse Kuhnert]

Maybe they've been deploying versions using a normal repository element
instead of defining a snapshot repository and -SNAPSHOT version ?

On 7/2/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:


YeahEven though in my instance it wasn't what I wanted to happen (not
maven's fault, unrelated local patches..), I have seen definite updates of
SNAPSHOT builds with the same version.

You can pretty easily infer why it works by looking at the timestamp
generated poms from them...


On 7/2/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
>
> I don't know what you're saying, you are the first one complaining
> about it. SNAPSHOTS work for me
>
> On 7/2/06, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote:
> > Unfortunately the SNAPSHOT-feature is broken (at least in 2.0.4): When
> you have a copy of a snapshot versioned artifact, the jar is not updated
> when a new jar with same snapshot version is uploaded to the repository. I
> already filed this as a bug and hope it will be fixed in 2.0.5. It is
> annoying to increase version numbers during development or sending mails
> around "please delete xyz in you local repository...
> >
> > Roger
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Andrew Williams [mailto:[EMAIL PROTECTED]
> > > Gesendet: Sonntag, 2. Juli 2006 11:11
> > > An: Maven Developers List
> > > Betreff: Re: [RANT] This Maven thing is killing us
> > >
> > > This is only true for release repositories though, as a
> > > snapshot repository will have an updated version when you
> > > re-deploy surely?
> > >
> > > Andy
> > >
> > > On Sun, 2006-07-02 at 07:01 +0800, Edwin Punzalan wrote:
> > > > May I add, that when maven already downloaded a
> > > poor/invalid pom, even
> > > > after fixing the pom in the repository, maven won't know that it's
>
> > > > changed (unless the version changed) and it will not
> > > download it.  So
> > > > you end up still using your local repo copy.
> > > >
> > > > To re-download a pom, you have to delete your local copy first.
> > > >
> > > > This is a good solution though:
> > > > http://jira.codehaus.org/browse/MNG-1258
> > > >
> > > >
> > > > Mike Perham wrote:
> > > > >> -Original Message-
> > > > >> From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
> > > > >> Sent: Saturday, July 01, 2006 2:59 PM
> > > > >> To: Maven Developers List
> > > > >> Subject: RE: [RANT] This Maven thing is killing us
> > > > >>
> > > > >>
> > > > >>
> > > > >>> Perhaps we can have a rule that every dependency MUST have
> > > > >>>
> > > > >> a declared
> > > > >>
> > > > >>>  and  element so that we know the
> > > > >>>
> > > > >> developer has thought
> > > > >>
> > > > >>> about the correct values for them, rather than always using
> the
> > > > >>> defaults?
> > > > >>>
> > > > >> That's against Maven philosophy: conventions based builds.
> > > > >> Only specify
> > > > >> things that don't follow the defaults..
> > > > >>
> > > > >> I think the problems with poms are because they're generated by
> > > > >> default or converted from maven 1, or just uploaded by
> > > someone who
> > > > >> wants it there.
> > > > >> If a project is built using maven 2, the poms should be
> correct.
> > > > >>
> > > > >>
> > > > >
> > > > > Agreed, but how do we solve the problem?  My suggestion does not
>
> > > > > force anyone to change their POMs _unless_ they want them
> > > hosted at central.
> > > > > The issue is that anything hosted at central necessarily
> > > becomes a
> > > > > publicly available component that others can use.  If
> > > people want to
> > > > > use the conventions, fine, but there obviously needs to
> > > be a higher
> > > > > standard to make your component publicly available for use by
> > > > > others.  We are hurting nobody but ourselves by
> > > distributing poorly
> > > > > defined POMs because inevitably the Maven project as a

Re: [RANT] This Maven thing is killing us....

[Jesse Kuhnert]

YeahEven though in my instance it wasn't what I wanted to happen (not
maven's fault, unrelated local patches..), I have seen definite updates of
SNAPSHOT builds with the same version.

You can pretty easily infer why it works by looking at the timestamp
generated poms from them...

On 7/2/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote:


I don't know what you're saying, you are the first one complaining
about it. SNAPSHOTS work for me

On 7/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Unfortunately the SNAPSHOT-feature is broken (at least in 2.0.4): When
you have a copy of a snapshot versioned artifact, the jar is not updated
when a new jar with same snapshot version is uploaded to the repository. I
already filed this as a bug and hope it will be fixed in 2.0.5. It is
annoying to increase version numbers during development or sending mails
around "please delete xyz in you local repository...
>
> Roger
>
> > -Ursprüngliche Nachricht-
> > Von: Andrew Williams [mailto:[EMAIL PROTECTED]
> > Gesendet: Sonntag, 2. Juli 2006 11:11
> > An: Maven Developers List
> > Betreff: Re: [RANT] This Maven thing is killing us
> >
> > This is only true for release repositories though, as a
> > snapshot repository will have an updated version when you
> > re-deploy surely?
> >
> > Andy
> >
> > On Sun, 2006-07-02 at 07:01 +0800, Edwin Punzalan wrote:
> > > May I add, that when maven already downloaded a
> > poor/invalid pom, even
> > > after fixing the pom in the repository, maven won't know that it's
> > > changed (unless the version changed) and it will not
> > download it.  So
> > > you end up still using your local repo copy.
> > >
> > > To re-download a pom, you have to delete your local copy first.
> > >
> > > This is a good solution though:
> > > http://jira.codehaus.org/browse/MNG-1258
> > >
> > >
> > > Mike Perham wrote:
> > > >> -Original Message-
> > > >> From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
> > > >> Sent: Saturday, July 01, 2006 2:59 PM
> > > >> To: Maven Developers List
> > > >> Subject: RE: [RANT] This Maven thing is killing us
> > > >>
> > > >>
> > > >>
> > > >>> Perhaps we can have a rule that every dependency MUST have
> > > >>>
> > > >> a declared
> > > >>
> > > >>>  and  element so that we know the
> > > >>>
> > > >> developer has thought
> > > >>
> > > >>> about the correct values for them, rather than always using the
> > > >>> defaults?
> > > >>>
> > > >> That's against Maven philosophy: conventions based builds.
> > > >> Only specify
> > > >> things that don't follow the defaults..
> > > >>
> > > >> I think the problems with poms are because they're generated by
> > > >> default or converted from maven 1, or just uploaded by
> > someone who
> > > >> wants it there.
> > > >> If a project is built using maven 2, the poms should be correct.
> > > >>
> > > >>
> > > >
> > > > Agreed, but how do we solve the problem?  My suggestion does not
> > > > force anyone to change their POMs _unless_ they want them
> > hosted at central.
> > > > The issue is that anything hosted at central necessarily
> > becomes a
> > > > publicly available component that others can use.  If
> > people want to
> > > > use the conventions, fine, but there obviously needs to
> > be a higher
> > > > standard to make your component publicly available for use by
> > > > others.  We are hurting nobody but ourselves by
> > distributing poorly
> > > > defined POMs because inevitably the Maven project as a
> > whole gets the blame.
> > > >
> > > > mike
> > > >
> > > >
> > 
> > > > - 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]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


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

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





--
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.

Re: [RANT] This Maven thing is killing us....

[Carlos Sanchez]

I don't know what you're saying, you are the first one complaining
about it. SNAPSHOTS work for me

On 7/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Unfortunately the SNAPSHOT-feature is broken (at least in 2.0.4): When you have a 
copy of a snapshot versioned artifact, the jar is not updated when a new jar with 
same snapshot version is uploaded to the repository. I already filed this as a bug 
and hope it will be fixed in 2.0.5. It is annoying to increase version numbers 
during development or sending mails around "please delete xyz in you local 
repository...

Roger

> -Ursprüngliche Nachricht-
> Von: Andrew Williams [mailto:[EMAIL PROTECTED]
> Gesendet: Sonntag, 2. Juli 2006 11:11
> An: Maven Developers List
> Betreff: Re: [RANT] This Maven thing is killing us
>
> This is only true for release repositories though, as a
> snapshot repository will have an updated version when you
> re-deploy surely?
>
> Andy
>
> On Sun, 2006-07-02 at 07:01 +0800, Edwin Punzalan wrote:
> > May I add, that when maven already downloaded a
> poor/invalid pom, even
> > after fixing the pom in the repository, maven won't know that it's
> > changed (unless the version changed) and it will not
> download it.  So
> > you end up still using your local repo copy.
> >
> > To re-download a pom, you have to delete your local copy first.
> >
> > This is a good solution though:
> > http://jira.codehaus.org/browse/MNG-1258
> >
> >
> > Mike Perham wrote:
> > >> -Original Message-
> > >> From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
> > >> Sent: Saturday, July 01, 2006 2:59 PM
> > >> To: Maven Developers List
> > >> Subject: RE: [RANT] This Maven thing is killing us
> > >>
> > >>
> > >>
> > >>> Perhaps we can have a rule that every dependency MUST have
> > >>>
> > >> a declared
> > >>
> > >>>  and  element so that we know the
> > >>>
> > >> developer has thought
> > >>
> > >>> about the correct values for them, rather than always using the
> > >>> defaults?
> > >>>
> > >> That's against Maven philosophy: conventions based builds.
> > >> Only specify
> > >> things that don't follow the defaults..
> > >>
> > >> I think the problems with poms are because they're generated by
> > >> default or converted from maven 1, or just uploaded by
> someone who
> > >> wants it there.
> > >> If a project is built using maven 2, the poms should be correct.
> > >>
> > >>
> > >
> > > Agreed, but how do we solve the problem?  My suggestion does not
> > > force anyone to change their POMs _unless_ they want them
> hosted at central.
> > > The issue is that anything hosted at central necessarily
> becomes a
> > > publicly available component that others can use.  If
> people want to
> > > use the conventions, fine, but there obviously needs to
> be a higher
> > > standard to make your component publicly available for use by
> > > others.  We are hurting nobody but ourselves by
> distributing poorly
> > > defined POMs because inevitably the Maven project as a
> whole gets the blame.
> > >
> > > mike
> > >
> > >
> 
> > > - 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]
>
>

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





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

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

Re: [RANT] This Maven thing is killing us....

[Alexandre Poitras]

I had the same problem. One quick fix in the mean time is to set
uniqueValue to true in the distributionManagement section of the
project pom.

On 7/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Unfortunately the SNAPSHOT-feature is broken (at least in 2.0.4): When you have a 
copy of a snapshot versioned artifact, the jar is not updated when a new jar with 
same snapshot version is uploaded to the repository. I already filed this as a bug 
and hope it will be fixed in 2.0.5. It is annoying to increase version numbers 
during development or sending mails around "please delete xyz in you local 
repository...

Roger

> -Ursprüngliche Nachricht-
> Von: Andrew Williams [mailto:[EMAIL PROTECTED]
> Gesendet: Sonntag, 2. Juli 2006 11:11
> An: Maven Developers List
> Betreff: Re: [RANT] This Maven thing is killing us
>
> This is only true for release repositories though, as a
> snapshot repository will have an updated version when you
> re-deploy surely?
>
> Andy
>
> On Sun, 2006-07-02 at 07:01 +0800, Edwin Punzalan wrote:
> > May I add, that when maven already downloaded a
> poor/invalid pom, even
> > after fixing the pom in the repository, maven won't know that it's
> > changed (unless the version changed) and it will not
> download it.  So
> > you end up still using your local repo copy.
> >
> > To re-download a pom, you have to delete your local copy first.
> >
> > This is a good solution though:
> > http://jira.codehaus.org/browse/MNG-1258
> >
> >
> > Mike Perham wrote:
> > >> -Original Message-
> > >> From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
> > >> Sent: Saturday, July 01, 2006 2:59 PM
> > >> To: Maven Developers List
> > >> Subject: RE: [RANT] This Maven thing is killing us
> > >>
> > >>
> > >>
> > >>> Perhaps we can have a rule that every dependency MUST have
> > >>>
> > >> a declared
> > >>
> > >>>  and  element so that we know the
> > >>>
> > >> developer has thought
> > >>
> > >>> about the correct values for them, rather than always using the
> > >>> defaults?
> > >>>
> > >> That's against Maven philosophy: conventions based builds.
> > >> Only specify
> > >> things that don't follow the defaults..
> > >>
> > >> I think the problems with poms are because they're generated by
> > >> default or converted from maven 1, or just uploaded by
> someone who
> > >> wants it there.
> > >> If a project is built using maven 2, the poms should be correct.
> > >>
> > >>
> > >
> > > Agreed, but how do we solve the problem?  My suggestion does not
> > > force anyone to change their POMs _unless_ they want them
> hosted at central.
> > > The issue is that anything hosted at central necessarily
> becomes a
> > > publicly available component that others can use.  If
> people want to
> > > use the conventions, fine, but there obviously needs to
> be a higher
> > > standard to make your component publicly available for use by
> > > others.  We are hurting nobody but ourselves by
> distributing poorly
> > > defined POMs because inevitably the Maven project as a
> whole gets the blame.
> > >
> > > mike
> > >
> > >
> 
> > > - 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]
>
>

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

AW: [RANT] This Maven thing is killing us....

[roger.butenuth]

Unfortunately the SNAPSHOT-feature is broken (at least in 2.0.4): When you have 
a copy of a snapshot versioned artifact, the jar is not updated when a new jar 
with same snapshot version is uploaded to the repository. I already filed this 
as a bug and hope it will be fixed in 2.0.5. It is annoying to increase version 
numbers during development or sending mails around "please delete xyz in you 
local repository...

Roger 

> -Ursprüngliche Nachricht-
> Von: Andrew Williams [mailto:[EMAIL PROTECTED] 
> Gesendet: Sonntag, 2. Juli 2006 11:11
> An: Maven Developers List
> Betreff: Re: [RANT] This Maven thing is killing us
> 
> This is only true for release repositories though, as a 
> snapshot repository will have an updated version when you 
> re-deploy surely?
> 
> Andy
> 
> On Sun, 2006-07-02 at 07:01 +0800, Edwin Punzalan wrote:
> > May I add, that when maven already downloaded a 
> poor/invalid pom, even 
> > after fixing the pom in the repository, maven won't know that it's 
> > changed (unless the version changed) and it will not 
> download it.  So 
> > you end up still using your local repo copy.
> > 
> > To re-download a pom, you have to delete your local copy first.
> > 
> > This is a good solution though: 
> > http://jira.codehaus.org/browse/MNG-1258
> > 
> > 
> > Mike Perham wrote:
> > >> -Original Message-
> > >> From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
> > >> Sent: Saturday, July 01, 2006 2:59 PM
> > >> To: Maven Developers List
> > >> Subject: RE: [RANT] This Maven thing is killing us
> > >>
> > >>
> > >> 
> > >>> Perhaps we can have a rule that every dependency MUST have
> > >>>   
> > >> a declared
> > >> 
> > >>>  and  element so that we know the
> > >>>   
> > >> developer has thought
> > >> 
> > >>> about the correct values for them, rather than always using the 
> > >>> defaults?
> > >>>   
> > >> That's against Maven philosophy: conventions based builds. 
> > >> Only specify
> > >> things that don't follow the defaults..
> > >>
> > >> I think the problems with poms are because they're generated by 
> > >> default or converted from maven 1, or just uploaded by 
> someone who 
> > >> wants it there.
> > >> If a project is built using maven 2, the poms should be correct.
> > >>
> > >> 
> > >
> > > Agreed, but how do we solve the problem?  My suggestion does not 
> > > force anyone to change their POMs _unless_ they want them 
> hosted at central.
> > > The issue is that anything hosted at central necessarily 
> becomes a 
> > > publicly available component that others can use.  If 
> people want to 
> > > use the conventions, fine, but there obviously needs to 
> be a higher 
> > > standard to make your component publicly available for use by 
> > > others.  We are hurting nobody but ourselves by 
> distributing poorly 
> > > defined POMs because inevitably the Maven project as a 
> whole gets the blame.
> > >
> > > mike
> > >
> > > 
> 
> > > - 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]
> 
> 

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

Re: [RANT] This Maven thing is killing us....

[Kenney Westerhof]

On Sun, 2 Jul 2006, Carlos Sanchez wrote:

Ah.. Well, it used to work in the beta's.. :)
There was a problem then with manually installed projects who lacked the
status field - it tried to download them from ibiblio which didn't have
them, and then the build failed. But that's a long time ago now.
But I'm probably wrong.. :)

> That's not implemented yet. Maven won't recheck poms right now. It's
> just informative
>
> On 7/2/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
> > On Sun, 2 Jul 2006, Edwin Punzalan wrote:
> >
> > That's not entirely true. The distributionManagement section
> > has a  field that get's set on deploy:
> >
> >  > http://maven.apache.org/ref/current/maven-model/maven.html#class_distributionManagement>
> > Gives the status of this artifact in the remote repository. This must not
> > be set in your local project, as it is updated by tools placing it in the
> > repository. Valid values are:
> > - none (default),
> > - converted (repository manager converted this from an Maven 1 POM),
> > - partner  (directly synced from a partner Maven 2 repository),
> > - deployed (was deployed from a Maven 2 instance),
> > - verified (has been hand verified as correct and final).
> > 
> >
> > So when the status is not 'verified', maven will keep re-checking the pom
> > to see if it's final.
> >
> > -- Kenney
> >
> > >
> > > May I add, that when maven already downloaded a poor/invalid pom, even
> > > after fixing the pom in the repository, maven won't know that it's
> > > changed (unless the version changed) and it will not download it.  So
> > > you end up still using your local repo copy.
> > >
> > > To re-download a pom, you have to delete your local copy first.
> > >
> > > This is a good solution though: http://jira.codehaus.org/browse/MNG-1258
> > >
> > >
> > > Mike Perham wrote:
> > > >> -Original Message-
> > > >> From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
> > > >> Sent: Saturday, July 01, 2006 2:59 PM
> > > >> To: Maven Developers List
> > > >> Subject: RE: [RANT] This Maven thing is killing us
> > > >>
> > > >>
> > > >>
> > > >>> Perhaps we can have a rule that every dependency MUST have
> > > >>>
> > > >> a declared
> > > >>
> > > >>>  and  element so that we know the
> > > >>>
> > > >> developer has thought
> > > >>
> > > >>> about the correct values for them, rather than always using the
> > > >>> defaults?
> > > >>>
> > > >> That's against Maven philosophy: conventions based builds.
> > > >> Only specify
> > > >> things that don't follow the defaults..
> > > >>
> > > >> I think the problems with poms are because they're generated
> > > >> by default
> > > >> or converted from maven 1, or just uploaded by someone who
> > > >> wants it there.
> > > >> If a project is built using maven 2, the poms should be correct.
> > > >>
> > > >>
> > > >
> > > > Agreed, but how do we solve the problem?  My suggestion does not force
> > > > anyone to change their POMs _unless_ they want them hosted at central.
> > > > The issue is that anything hosted at central necessarily becomes a
> > > > publicly available component that others can use.  If people want to use
> > > > the conventions, fine, but there obviously needs to be a higher standard
> > > > to make your component publicly available for use by others.  We are
> > > > hurting nobody but ourselves by distributing poorly defined POMs because
> > > > inevitably the Maven project as a whole gets the blame.
> > > >
> > > > mike
> > > >
> > > > -
> > > > 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]
> > >
> >
> > --
> > Kenney Westerhof
> > http://www.neonics.com
> > GPG public key: http://www.gods.nl/~forge/kenneyw.key
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>  -- The Princess Bride
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key

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

Re: [RANT] This Maven thing is killing us....

[Carlos Sanchez]

That's not implemented yet. Maven won't recheck poms right now. It's
just informative

On 7/2/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote:

On Sun, 2 Jul 2006, Edwin Punzalan wrote:

That's not entirely true. The distributionManagement section
has a  field that get's set on deploy:

http://maven.apache.org/ref/current/maven-model/maven.html#class_distributionManagement>
Gives the status of this artifact in the remote repository. This must not
be set in your local project, as it is updated by tools placing it in the
repository. Valid values are:
- none (default),
- converted (repository manager converted this from an Maven 1 POM),
- partner  (directly synced from a partner Maven 2 repository),
- deployed (was deployed from a Maven 2 instance),
- verified (has been hand verified as correct and final).


So when the status is not 'verified', maven will keep re-checking the pom
to see if it's final.

-- Kenney

>
> May I add, that when maven already downloaded a poor/invalid pom, even
> after fixing the pom in the repository, maven won't know that it's
> changed (unless the version changed) and it will not download it.  So
> you end up still using your local repo copy.
>
> To re-download a pom, you have to delete your local copy first.
>
> This is a good solution though: http://jira.codehaus.org/browse/MNG-1258
>
>
> Mike Perham wrote:
> >> -Original Message-
> >> From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
> >> Sent: Saturday, July 01, 2006 2:59 PM
> >> To: Maven Developers List
> >> Subject: RE: [RANT] This Maven thing is killing us
> >>
> >>
> >>
> >>> Perhaps we can have a rule that every dependency MUST have
> >>>
> >> a declared
> >>
> >>>  and  element so that we know the
> >>>
> >> developer has thought
> >>
> >>> about the correct values for them, rather than always using the
> >>> defaults?
> >>>
> >> That's against Maven philosophy: conventions based builds.
> >> Only specify
> >> things that don't follow the defaults..
> >>
> >> I think the problems with poms are because they're generated
> >> by default
> >> or converted from maven 1, or just uploaded by someone who
> >> wants it there.
> >> If a project is built using maven 2, the poms should be correct.
> >>
> >>
> >
> > Agreed, but how do we solve the problem?  My suggestion does not force
> > anyone to change their POMs _unless_ they want them hosted at central.
> > The issue is that anything hosted at central necessarily becomes a
> > publicly available component that others can use.  If people want to use
> > the conventions, fine, but there obviously needs to be a higher standard
> > to make your component publicly available for use by others.  We are
> > hurting nobody but ourselves by distributing poorly defined POMs because
> > inevitably the Maven project as a whole gets the blame.
> >
> > mike
> >
> > -
> > 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]
>

--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key

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





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

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

Re: [RANT] This Maven thing is killing us....

[Kenney Westerhof]

On Sun, 2 Jul 2006, Edwin Punzalan wrote:

That's not entirely true. The distributionManagement section
has a  field that get's set on deploy:

http://maven.apache.org/ref/current/maven-model/maven.html#class_distributionManagement>
Gives the status of this artifact in the remote repository. This must not
be set in your local project, as it is updated by tools placing it in the
repository. Valid values are:
- none (default),
- converted (repository manager converted this from an Maven 1 POM),
- partner  (directly synced from a partner Maven 2 repository),
- deployed (was deployed from a Maven 2 instance),
- verified (has been hand verified as correct and final).


So when the status is not 'verified', maven will keep re-checking the pom
to see if it's final.

-- Kenney

>
> May I add, that when maven already downloaded a poor/invalid pom, even
> after fixing the pom in the repository, maven won't know that it's
> changed (unless the version changed) and it will not download it.  So
> you end up still using your local repo copy.
>
> To re-download a pom, you have to delete your local copy first.
>
> This is a good solution though: http://jira.codehaus.org/browse/MNG-1258
>
>
> Mike Perham wrote:
> >> -Original Message-
> >> From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
> >> Sent: Saturday, July 01, 2006 2:59 PM
> >> To: Maven Developers List
> >> Subject: RE: [RANT] This Maven thing is killing us
> >>
> >>
> >>
> >>> Perhaps we can have a rule that every dependency MUST have
> >>>
> >> a declared
> >>
> >>>  and  element so that we know the
> >>>
> >> developer has thought
> >>
> >>> about the correct values for them, rather than always using the
> >>> defaults?
> >>>
> >> That's against Maven philosophy: conventions based builds.
> >> Only specify
> >> things that don't follow the defaults..
> >>
> >> I think the problems with poms are because they're generated
> >> by default
> >> or converted from maven 1, or just uploaded by someone who
> >> wants it there.
> >> If a project is built using maven 2, the poms should be correct.
> >>
> >>
> >
> > Agreed, but how do we solve the problem?  My suggestion does not force
> > anyone to change their POMs _unless_ they want them hosted at central.
> > The issue is that anything hosted at central necessarily becomes a
> > publicly available component that others can use.  If people want to use
> > the conventions, fine, but there obviously needs to be a higher standard
> > to make your component publicly available for use by others.  We are
> > hurting nobody but ourselves by distributing poorly defined POMs because
> > inevitably the Maven project as a whole gets the blame.
> >
> > mike
> >
> > -
> > 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]
>

--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key

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

Re: [RANT] This Maven thing is killing us....

[Andrew Williams]

This is only true for release repositories though, as a snapshot
repository will have an updated version when you re-deploy surely?

Andy

On Sun, 2006-07-02 at 07:01 +0800, Edwin Punzalan wrote:
> May I add, that when maven already downloaded a poor/invalid pom, even 
> after fixing the pom in the repository, maven won't know that it's 
> changed (unless the version changed) and it will not download it.  So 
> you end up still using your local repo copy.
> 
> To re-download a pom, you have to delete your local copy first.
> 
> This is a good solution though: http://jira.codehaus.org/browse/MNG-1258
> 
> 
> Mike Perham wrote:
> >> -Original Message-
> >> From: Kenney Westerhof [mailto:[EMAIL PROTECTED] 
> >> Sent: Saturday, July 01, 2006 2:59 PM
> >> To: Maven Developers List
> >> Subject: RE: [RANT] This Maven thing is killing us
> >>
> >>
> >> 
> >>> Perhaps we can have a rule that every dependency MUST have 
> >>>   
> >> a declared
> >> 
> >>>  and  element so that we know the 
> >>>   
> >> developer has thought
> >> 
> >>> about the correct values for them, rather than always using the
> >>> defaults?
> >>>   
> >> That's against Maven philosophy: conventions based builds. 
> >> Only specify
> >> things that don't follow the defaults..
> >>
> >> I think the problems with poms are because they're generated 
> >> by default
> >> or converted from maven 1, or just uploaded by someone who 
> >> wants it there.
> >> If a project is built using maven 2, the poms should be correct.
> >>
> >> 
> >
> > Agreed, but how do we solve the problem?  My suggestion does not force
> > anyone to change their POMs _unless_ they want them hosted at central.
> > The issue is that anything hosted at central necessarily becomes a
> > publicly available component that others can use.  If people want to use
> > the conventions, fine, but there obviously needs to be a higher standard
> > to make your component publicly available for use by others.  We are
> > hurting nobody but ourselves by distributing poorly defined POMs because
> > inevitably the Maven project as a whole gets the blame.
> >
> > mike
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >   
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


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

Re: [RANT] This Maven thing is killing us....

[Edwin Punzalan]

May I add, that when maven already downloaded a poor/invalid pom, even 
after fixing the pom in the repository, maven won't know that it's 
changed (unless the version changed) and it will not download it.  So 
you end up still using your local repo copy.


To re-download a pom, you have to delete your local copy first.

This is a good solution though: http://jira.codehaus.org/browse/MNG-1258


Mike Perham wrote:

-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED] 
Sent: Saturday, July 01, 2006 2:59 PM

To: Maven Developers List
Subject: RE: [RANT] This Maven thing is killing us



Perhaps we can have a rule that every dependency MUST have 
  

a declared

 and  element so that we know the 
  

developer has thought


about the correct values for them, rather than always using the
defaults?
  
That's against Maven philosophy: conventions based builds. 
Only specify

things that don't follow the defaults..

I think the problems with poms are because they're generated 
by default
or converted from maven 1, or just uploaded by someone who 
wants it there.

If a project is built using maven 2, the poms should be correct.




Agreed, but how do we solve the problem?  My suggestion does not force
anyone to change their POMs _unless_ they want them hosted at central.
The issue is that anything hosted at central necessarily becomes a
publicly available component that others can use.  If people want to use
the conventions, fine, but there obviously needs to be a higher standard
to make your component publicly available for use by others.  We are
hurting nobody but ourselves by distributing poorly defined POMs because
inevitably the Maven project as a whole gets the blame.

mike

-
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: [RANT] This Maven thing is killing us....

[Mike Perham]

> -Original Message-
> From: Kenney Westerhof [mailto:[EMAIL PROTECTED] 
> Sent: Saturday, July 01, 2006 2:59 PM
> To: Maven Developers List
> Subject: RE: [RANT] This Maven thing is killing us
> 
> 
> > Perhaps we can have a rule that every dependency MUST have 
> a declared
> >  and  element so that we know the 
> developer has thought
> > about the correct values for them, rather than always using the
> > defaults?
> 
> That's against Maven philosophy: conventions based builds. 
> Only specify
> things that don't follow the defaults..
> 
> I think the problems with poms are because they're generated 
> by default
> or converted from maven 1, or just uploaded by someone who 
> wants it there.
> If a project is built using maven 2, the poms should be correct.
> 

Agreed, but how do we solve the problem?  My suggestion does not force
anyone to change their POMs _unless_ they want them hosted at central.
The issue is that anything hosted at central necessarily becomes a
publicly available component that others can use.  If people want to use
the conventions, fine, but there obviously needs to be a higher standard
to make your component publicly available for use by others.  We are
hurting nobody but ourselves by distributing poorly defined POMs because
inevitably the Maven project as a whole gets the blame.

mike

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

RE: [RANT] This Maven thing is killing us....

[Kenney Westerhof]

On Fri, 30 Jun 2006, Mike Perham wrote:



> Maybe we need a much harsher line around the quality of accepted POMs.

Maybe that's wise.

> Perhaps we can have a rule that every dependency MUST have a declared
>  and  element so that we know the developer has thought
> about the correct values for them, rather than always using the
> defaults?

That's against Maven philosophy: conventions based builds. Only specify
things that don't follow the defaults..

I think the problems with poms are because they're generated by default
or converted from maven 1, or just uploaded by someone who wants it there.
If a project is built using maven 2, the poms should be correct.

-- Kenney


> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> > Torsten Curdt
> > Sent: Friday, June 30, 2006 12:06 PM
> > To: Maven Developers List
> > Subject: Fwd: [RANT] This Maven thing is killing us
> >
> > FYI
> >
> > -- Forwarded message --
> > From: Bertrand Delacretaz <[EMAIL PROTECTED]>
> > Date: Jun 30, 2006 5:58 PM
> > Subject: [RANT] This Maven thing is killing us
> > To: dev@cocoon.apache.org
> >
> >
> > Hi gang,
> >
> > It's Friday, I'm tired and a bit depressed after losing about two more
> > hours unsuccessfully trying to add OJB to the dependencies of the
> > bricks-archetype example I'm working on (would have needed all of six
> > minutes to do this with our old ant build).
> >
> > I'll spare you the details on that one, but I think each of us present
> > at the ApacheCon EU Hackathon has lost several hours this week
> > fighting with Maven (or rather Maven repositories) problems instead of
> > doing useful progress.
> >
> > From what I understand now, it seems like most people using Maven in
> > their companies have their own local repositories, which they take
> > care to keep in good shape.
> >
> > But using public repositories seems to bring us more problems than
> > Maven should solve, especially because Cocoon integrates many
> > libraries from the ASF and from other places, and there are many ways
> > in which dependencies can be broken apparently.
> >
> > I'm sorry that I have nothing to suggest at this point (except going
> > back to ant, but it's probably a lot of work).
> >
> > The main thing is that I'm afraid our users will go away if they are
> > confronted with the same problems than many of us had this week trying
> > to catch up with 2.2. The collective time wasted on this is huge and
> > it hides all the good things that are in 2.2.
> >
> > Suggestions are welcome I guess.
> >
> > -Bertrand
> >
> > -
> > 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]
>
>

--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key

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

Re: [RANT] This Maven thing is killing us....

[Bertrand Delacretaz]

On 6/30/06, Mike Perham <[EMAIL PROTECTED]> wrote:

"I'll spare you the details on that one"

This does nothing to solve the problem.  We can't fix what we don't know
about...


Sorry about that, if was meaning to write to the Maven list with more
precise information later, my email was meant for the Cocoon team
first.

I will be talking with Cocoon people who know Maven better than me and
come back with more constructive ideas hopefully.

-Bertrand

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

Re: [RANT] This Maven thing is killing us....

[Wendy Smoak]

On 6/30/06, Torsten Curdt <[EMAIL PROTECTED]> wrote:

FYI

-- Forwarded message --
From: Bertrand Delacretaz <[EMAIL PROTECTED]>
Date: Jun 30, 2006 5:58 PM
Subject: [RANT] This Maven thing is killing us
To: dev@cocoon.apache.org


Is anyone here using Cocoon?  They could probably use a Maven
ambassador who understands their project.  I know I really appreciated
seeing Brett on [EMAIL PROTECTED] when we were going through the two recent
conversions.

--
Wendy

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

Re: [RANT] This Maven thing is killing us....

[Alexandre Poitras]

I don't know what he complains about. True sometimes the repository
quality sucks but just submit a patch and it usually take 3 to 4 days
until the problem is solves. Really I don't want to seem arrogant but
I haven't had those kind of troubles.

On 6/30/06, Mike Perham <[EMAIL PROTECTED]> wrote:

"I'll spare you the details on that one"

This does nothing to solve the problem.  We can't fix what we don't know
about.

The quality of the repository metadata has always struck me as something
that will make or break the long-term success of Maven.  We can only
document it as best as possible - it's up to the module owner to provide
a quality POM.

Maybe we need a much harsher line around the quality of accepted POMs.
Perhaps we can have a rule that every dependency MUST have a declared
 and  element so that we know the developer has thought
about the correct values for them, rather than always using the
defaults?

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Torsten Curdt
> Sent: Friday, June 30, 2006 12:06 PM
> To: Maven Developers List
> Subject: Fwd: [RANT] This Maven thing is killing us
>
> FYI
>
> -- Forwarded message --
> From: Bertrand Delacretaz <[EMAIL PROTECTED]>
> Date: Jun 30, 2006 5:58 PM
> Subject: [RANT] This Maven thing is killing us
> To: dev@cocoon.apache.org
>
>
> Hi gang,
>
> It's Friday, I'm tired and a bit depressed after losing about two more
> hours unsuccessfully trying to add OJB to the dependencies of the
> bricks-archetype example I'm working on (would have needed all of six
> minutes to do this with our old ant build).
>
> I'll spare you the details on that one, but I think each of us present
> at the ApacheCon EU Hackathon has lost several hours this week
> fighting with Maven (or rather Maven repositories) problems instead of
> doing useful progress.
>
> From what I understand now, it seems like most people using Maven in
> their companies have their own local repositories, which they take
> care to keep in good shape.
>
> But using public repositories seems to bring us more problems than
> Maven should solve, especially because Cocoon integrates many
> libraries from the ASF and from other places, and there are many ways
> in which dependencies can be broken apparently.
>
> I'm sorry that I have nothing to suggest at this point (except going
> back to ant, but it's probably a lot of work).
>
> The main thing is that I'm afraid our users will go away if they are
> confronted with the same problems than many of us had this week trying
> to catch up with 2.2. The collective time wasted on this is huge and
> it hides all the good things that are in 2.2.
>
> Suggestions are welcome I guess.
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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




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

RE: [RANT] This Maven thing is killing us....

[Mike Perham]

"I'll spare you the details on that one"

This does nothing to solve the problem.  We can't fix what we don't know
about.

The quality of the repository metadata has always struck me as something
that will make or break the long-term success of Maven.  We can only
document it as best as possible - it's up to the module owner to provide
a quality POM.

Maybe we need a much harsher line around the quality of accepted POMs.
Perhaps we can have a rule that every dependency MUST have a declared
 and  element so that we know the developer has thought
about the correct values for them, rather than always using the
defaults?

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of 
> Torsten Curdt
> Sent: Friday, June 30, 2006 12:06 PM
> To: Maven Developers List
> Subject: Fwd: [RANT] This Maven thing is killing us
> 
> FYI
> 
> -- Forwarded message --
> From: Bertrand Delacretaz <[EMAIL PROTECTED]>
> Date: Jun 30, 2006 5:58 PM
> Subject: [RANT] This Maven thing is killing us
> To: dev@cocoon.apache.org
> 
> 
> Hi gang,
> 
> It's Friday, I'm tired and a bit depressed after losing about two more
> hours unsuccessfully trying to add OJB to the dependencies of the
> bricks-archetype example I'm working on (would have needed all of six
> minutes to do this with our old ant build).
> 
> I'll spare you the details on that one, but I think each of us present
> at the ApacheCon EU Hackathon has lost several hours this week
> fighting with Maven (or rather Maven repositories) problems instead of
> doing useful progress.
> 
> From what I understand now, it seems like most people using Maven in
> their companies have their own local repositories, which they take
> care to keep in good shape.
> 
> But using public repositories seems to bring us more problems than
> Maven should solve, especially because Cocoon integrates many
> libraries from the ASF and from other places, and there are many ways
> in which dependencies can be broken apparently.
> 
> I'm sorry that I have nothing to suggest at this point (except going
> back to ant, but it's probably a lot of work).
> 
> The main thing is that I'm afraid our users will go away if they are
> confronted with the same problems than many of us had this week trying
> to catch up with 2.2. The collective time wasted on this is huge and
> it hides all the good things that are in 2.2.
> 
> Suggestions are welcome I guess.
> 
> -Bertrand
> 
> -
> 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]

Fwd: [RANT] This Maven thing is killing us....

[Torsten Curdt]

FYI

-- Forwarded message --
From: Bertrand Delacretaz <[EMAIL PROTECTED]>
Date: Jun 30, 2006 5:58 PM
Subject: [RANT] This Maven thing is killing us
To: dev@cocoon.apache.org


Hi gang,

It's Friday, I'm tired and a bit depressed after losing about two more
hours unsuccessfully trying to add OJB to the dependencies of the
bricks-archetype example I'm working on (would have needed all of six
minutes to do this with our old ant build).

I'll spare you the details on that one, but I think each of us present
at the ApacheCon EU Hackathon has lost several hours this week
fighting with Maven (or rather Maven repositories) problems instead of
doing useful progress.


From what I understand now, it seems like most people using Maven in

their companies have their own local repositories, which they take
care to keep in good shape.

But using public repositories seems to bring us more problems than
Maven should solve, especially because Cocoon integrates many
libraries from the ASF and from other places, and there are many ways
in which dependencies can be broken apparently.

I'm sorry that I have nothing to suggest at this point (except going
back to ant, but it's probably a lot of work).

The main thing is that I'm afraid our users will go away if they are
confronted with the same problems than many of us had this week trying
to catch up with 2.2. The collective time wasted on this is huge and
it hides all the good things that are in 2.2.

Suggestions are welcome I guess.

-Bertrand

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