On Wednesday 05 July 2006 18:29, Steve Loughran wrote:
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?
To some extent. Individual Java Packages can be versioned and one can declare
a
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
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
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)
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
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
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
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
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
]
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
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
On 7/4/06, Torsten Curdt [EMAIL PROTECTED] wrote:
...I would be good to summarize all the pain points and
post them over in maven land...
Agreed. I'm a bit drowning in stuff since I got back for ApacheCon,
will try to summarize but if someone else has more time, please go for
it.
-Bertrand
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
Torsten Curdt wrote:
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
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
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
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
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
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
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
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
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
From: Ralph Goers [EMAIL PROTECTED]
Date: Sun, 02 Jul 2006 21:16:47 -0700
Tim Williams wrote:
The If it ain't broke, don't fix it Principle. Ant has just worked
in the past, I wasn't around or probably smart enough to understand
why the move to maven but I can say from a user perspective it
Tim Williams wrote:
On a side note, I use the Cocoon code to learn forrest internals and
that task has even been increasingly more difficult since the
directory restructoring, which seems random at best.
As you proceed with this discussion, I hope you'll appreciate that
there are
Andrew Stevens wrote:
From what I've heard on the list so far, though, the Maven build is a
long way from working correctly. Until it does, I'm not wasting my
time trying to look at Cocoon 2.2, I'm sticking with the 2.1.x branch.
I can't recall seeing lots of bug reports in JIRA saying the
] This Maven thing is killing us
Simone Gianni wrote:
Niclas Hedhman wrote:
What happens *if* Mergere runs out of juice and flip the switch off?
IIUC, maven repos are nothing more than HTTP servers, and SVN is
accessible thru HTTP, so we can create a folder named repository in
our svn
: Upayavira [mailto:[EMAIL PROTECTED]
Sent: Montag, 3. Juli 2006 10:42
To: dev@cocoon.apache.org
Subject: Re: [RANT] This Maven thing is killing us
Simone Gianni wrote:
Niclas Hedhman wrote:
What happens *if* Mergere runs out of juice and flip the switch off?
IIUC, maven
: Re: [RANT] This Maven thing is killing us
Hi Alfred,
see the previous mail by Upayavira :
A good idea, but I can't see any way in which infrastructure would
allow this.That is because it would prevent any useful partitioning of
resources.
Maven is likely to become a resource hog, and could
-
From: Upayavira [mailto:[EMAIL PROTECTED]
Sent: Montag, 3. Juli 2006 10:42
To: dev@cocoon.apache.org
Subject: Re: [RANT] This Maven thing is killing us
Simone Gianni wrote:
Niclas Hedhman wrote:
What happens *if* Mergere runs out of juice and flip the switch off
On Jun 30, 2006, at 12:58 PM, Bertrand Delacretaz wrote:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 3 Jul 2006, Simone Gianni wrote:
It's not just a question of having a reliable build system, simply in
many companies they have a lifecycle for their applications that steps
thru test, integration etc.. and quite often this servers are not
Gavin Carothers wrote:
rm -rf .m2/repository/
Of course I now have to download all the dependencies and even basic
maven plugins again. There should be a better way.
What about rm -rf .m2/repository/org/apache/cocoon?
--
Reinhard Pötz Independent Consultant, Trainer
... yes, indeed that would have been a much smarter thing to do. I
leave this is a happy lesson for everyone else following me, and
myself next time this happens.
Cheers,
Gavin
On Jul 3, 2006, at 3:27 PM, Reinhard Poetz wrote:
Gavin Carothers wrote:
rm -rf .m2/repository/
Of course I
Gavin Carothers wrote:
mvn install -Dmaven.test.skip=true
Need to run this 6 or 7 times to get all the plugins from:
central (http://repo1.maven.org/maven2),
apache.snapshots (http://svn.apache.org/maven-snapshot-repository),
snapshots (http://snapshots.maven.codehaus.org/maven2)
I
On Jul 3, 2006, at 4:10 PM, Jorg Heymans wrote:
Gavin Carothers wrote:
mvn install -Dmaven.test.skip=true
Need to run this 6 or 7 times to get all the plugins from:
central (http://repo1.maven.org/maven2),
apache.snapshots (http://svn.apache.org/maven-snapshot-repository),
snapshots
Gavin Carothers wrote:
Tried two, had the same issues as main. Tried lsu and .net mirrors. I'm
the US. I think if I'm going to keep doing this I'm just going to need
to setup a mirror locally for the company, cause none of the other
people here are going to keep trying :)
Consider also
Ralph Goers wrote:
We've been using Maven 1 successfully for a couple of years. We want to
upgrade to Maven 2 but can't until I (or someone) fixes
http://jira.codehaus.org/browse/MNG-1577.
http://jira.codehaus.org/browse/MNG-1577 However, I suspect that we
would be having the same problems
Ralph Goers wrote:
Bertrand Delacretaz wrote:
On 7/1/06, Ralph Goers [EMAIL PROTECTED] wrote:
...I know in my case our Configuration Management folks have come to
love
Maven and the repository concept as it gives them total control over
when the third party components are updated
Reinhard Poetz wrote:
Ralph Goers wrote:
Bertrand Delacretaz wrote:
On 7/1/06, Ralph Goers [EMAIL PROTECTED] wrote:
...I know in my case our Configuration Management folks have come
to love
Maven and the repository concept as it gives them total control over
when the third party
Carsten Ziegeler wrote:
Especially the unpredictable results and the not reproduciable builds
are imho a real problem. You build today, it works, you build tomorrow
and it does not. And this occurs on some machines even if nothing has
changed and even if you build in offline mode! Which is
Bertrand Delacretaz wrote:
-Use our own/ASF repository, managed in SVN
-Make this the default repository, using ASF mirrors (might need some
changes to Maven IIUC), and using a snapshot repository in second
priority
i suggest you join [EMAIL PROTECTED] and discuss this there.
-Find a
Bertrand Delacretaz wrote:
About OJB, basically the poms that I found at ibiblio did not help much.
then we should ping the ojb folks and ask them to come up with proper poms.
But this is the last of many problems that have prevented us from
making serious progress this week. See my answer
Simone Gianni wrote:
I don't know if what I've done is a good work or not, I will commit it
in a single revision so that it's easy to roll back it in case I made
mistakes.
If you're unsure you can send me the patch and i'll have a look at it.
Otherwise just commit and we'll deal with things
Carsten Ziegeler wrote:
Now, m2 is theoretically a very good tool :)
Stefano principle: you need good ideas and bad code to grow a community.
The application of this principle in Maven is different than usual, as
it forces other projects (and not only its own developers) to endure the
Sylvain Wallez wrote:
And this actually endangers these other projects by forbidding their
developers from concentrating on actual productive work. Cocoon with all
its dependencies is certainly an extreme use case for Maven compared to
all others, and broken builds led some of Cocoon's major
On 7/2/06, Sylvain Wallez [EMAIL PROTECTED] wrote:
Carsten Ziegeler wrote:
Now, m2 is theoretically a very good tool :)
Stefano principle: you need good ideas and bad code to grow a community.
I like this Stefano guy more and more every day, as I have a tendency
towards both of these
On Saturday 01 July 2006 20:41, Bertrand Delacretaz wrote:
-Use our own/ASF repository, managed in SVN
Our own Stefano Mazzocchi has recently suggested this, and AFAICT work has
been started.
The idea is to have both release and snapshot repos operating on ASF
infrastructure, and replicated to
On Monday 03 July 2006 01:29, Jorg Heymans wrote:
I just spoke to Jason, he mentioned that ibiblio will go away soon.
That statement actually worries me quite a lot. AFAIU, the central repo is
going to Mergere (a VC funded company) sponsored host(s). And this/these
host(s) have to me shown
Niclas Hedhman wrote:
What happens *if* Mergere runs out of juice and flip the switch off?
IIUC, maven repos are nothing more than HTTP servers, and SVN is
accessible thru HTTP, so we can create a folder named repository in
our svn repo, copy the folders of artifacts we need from ibiblio,
Tim Williams wrote:
The If it ain't broke, don't fix it Principle. Ant has just worked
in the past, I wasn't around or probably smart enough to understand
why the move to maven but I can say from a user perspective it don't
work. I'm over at forrest and, for learning purposes, like to
I totally agree with Bertrand that using m2 really sucked up a lot of
our time which we could have better used on real development.
Especially the unpredictable results and the not reproduciable builds
are imho a real problem. You build today, it works, you build tomorrow
and it does not. And
On 7/1/06, Carsten Ziegeler [EMAIL PROTECTED] wrote:
...what
about settings up a Cocoon M2 repository where we host all our
dependencies and this is the default repository you're using when you're
developing with Cocoon...
Without knowing much about how Maven works today, my impression is
On 6/30/06, Jorg Heymans [EMAIL PROTECTED] wrote:
...Please don't, details please
About OJB, basically the poms that I found at ibiblio did not help much.
But this is the last of many problems that have prevented us from
making serious progress this week. See my answer to Carsten for
Bertrand Delacretaz wrote:
-Allow Cocoon users to add their own jars to the build in the old way
(lib directory), without forcing them to use Maven for that
I think this is the most interesting point. We could try to push maven
to allow this...would be fun to see what they think. Seriously, I
On 7/1/06, Carsten Ziegeler [EMAIL PROTECTED] wrote:
Bertrand Delacretaz wrote:
-Allow Cocoon users to add their own jars to the build in the old way
(lib directory), without forcing them to use Maven for that
I think this is the most interesting point. We could try to push maven
to
We've been using Maven 1 successfully for a couple of years. We want to
upgrade to Maven 2 but can't until I (or someone) fixes
http://jira.codehaus.org/browse/MNG-1577.
http://jira.codehaus.org/browse/MNG-1577 However, I suspect that we
would be having the same problems as the Cocoon builds
On 7/1/06, Ralph Goers [EMAIL PROTECTED] wrote:
...I know in my case our Configuration Management folks have come to love
Maven and the repository concept as it gives them total control over
when the third party components are updated
But they carefully manage their own repository, right?
Bertrand Delacretaz wrote:
I didn't realize it before this week, but if we don't allow this we
force our users to put all of their dependencies in Maven.
OTOH, if people can add their own jars in the plain old way, they
benefit from the M18n of Cocoon (assuming it works...) without having
to
Bertrand Delacretaz wrote:
On 7/1/06, Ralph Goers [EMAIL PROTECTED] wrote:
...I know in my case our Configuration Management folks have come to
love
Maven and the repository concept as it gives them total control over
when the third party components are updated
But they carefully
Hi all,
after a weekend of fights, I managed to have all projects (yes, all the
blocks) loaded in eclipse with only 4 errors, which are actually not
real errors. This involved the following operations :
- Adding some dependencies in pom.xml files, in particular :
... Some blocks didn't included
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
Bertrand Delacretaz wrote:
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
62 matches
Mail list logo
