On Sat, May 16, 2009 at 5:17 AM, Joerg Hohwiller jo...@j-hohwiller.de wrote:
Off topic.
Actually I believe this isn't true anymore.
See http://jira.codehaus.org/browse/MECLIPSE-344
[del]
mvn eclipse:eclipse will make sure my module pA references the eclipse
project for module cA (and not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Brian,
Do you need simple IT-projects that I shall attach to MNG-4161 and related?
Sample ITs for sure, and some level of detail in a proposal like these:
http://docs.codehaus.org/display/MAVENUSER/User+Proposals
here is my proposal:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ralph,
Okay. So thats what I guessed when I said that the MavenProject/Model is
just a stupid POJO and various plugins manipulate it with side effects.
Sounds a little hacky to me but thats the way it is. So my serialization
idea is nuts
On May 16, 2009, at 1:48 PM, Joerg Hohwiller wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ralph,
Okay. So thats what I guessed when I said that the MavenProject/
Model is
just a stupid POJO and various plugins manipulate it with side
effects.
Sounds a little hacky to me but
Also be aware that 2.1/2.2 already do some pom transformations, so this
would have to extend instead of replicate what's already there.
On Sat, May 16, 2009 at 5:14 PM, Ralph Goers ralph.go...@dslextreme.comwrote:
On May 16, 2009, at 1:48 PM, Joerg Hohwiller wrote:
-BEGIN PGP SIGNED
Ralph Goers schrieb:
They just shouldn't change things significantly without good
arguments.
Which are only the ones you agree with?
I am really just trying to warn you about doing something dangerous.
Mixing release versions with snapshot versions. The release plugin takes
care of this -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
OK. So you would NOT mind if maven adds some new features that
are compatible to older versions of maven.
Thats all I am fighting for.
No fighting required, just make a patch. If it's truly backwards compatible,
then there wouldn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
By inheriting the version, groupId, etc. from the parent - yes. The
release plugin still handles the pom transformations and the tagging
(SCM URLs, snapshot to release version, release to next snapshot
version, etc.)
But there is nothing to
On Fri, May 15, 2009 at 2:58 PM, Joerg Hohwiller jo...@j-hohwiller.dewrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
By inheriting the version, groupId, etc. from the parent - yes. The
release plugin still handles the pom transformations and the tagging
(SCM URLs, snapshot to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Stephen,
If A(1.0) has root(1.2-SNAPSHOT) as a parent it should never have been
released as the pom for A(1.0) is based on content from root(1.2-SNAPSHOT)
which is subject to change... which means that a released pom does not have
a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Off topic.
Actually I believe this isn't true anymore.
See http://jira.codehaus.org/browse/MECLIPSE-344
all dependent artefacts that are available in your eclipse-workspace
will be attached as project references even if they are not in the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I think you are referring to one of the other patches that was
submitted, not what I committed to the MNG-624 branch.
MNG-624 or maven-2.1.x-MNG-624 ?
A big problem could be the encoding issue if you store XML in a string
and then want to
On Fri, May 15, 2009 at 4:10 PM, Joerg Hohwiller jo...@j-hohwiller.dewrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I think you are referring to one of the other patches that was
submitted, not what I committed to the MNG-624 branch.
MNG-624 or maven-2.1.x-MNG-624 ?
A
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Brian,
Your better bet will be to try and get this documented so it can be
implemented in 3.x.
I would surely NOT mind. What do you expect?
A new xdoc? Or a diff to the actual source of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi again,
Your better bet will be to try and get this documented so it can be
implemented in 3.x.
no change to see some improvement about version maintenance in 2.x?
See the list of issues I just posted and also look at the votes.
Thanks
Jörg
Do you need simple IT-projects that I shall attach to MNG-4161 and related?
Sample ITs for sure, and some level of detail in a proposal like these:
http://docs.codehaus.org/display/MAVENUSER/User+Proposals
On May 15, 2009, at 1:10 PM, Joerg Hohwiller wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I think you are referring to one of the other patches that was
submitted, not what I committed to the MNG-624 branch.
MNG-624 or maven-2.1.x-MNG-624 ?
I think it was maven-2.1.x-MNG-624.
You have to understand that although the problem might seem trivial, fixes
for problems like this can't break existing builds. That makes even the
simplest fix challenging.
Not only that, it needs to cooperate with other functionality... just like
we found with the previous patch. It would
Ralph Goers schrieb:
On May 13, 2009, at 5:09 PM, Christian Schulte wrote:
Ralph Goers schrieb:
So the tree really looks like:
+tags
+root-1.0 (trunk revision 1)
+A(1.0)
+B(1.0)
+root-1.1 (trunk revision 2)
+A(1.0)
+B(1.1)
+root-1.2 (trunk revision 3)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Chistian,
What stops a developer from making changes to A(1.0) on trunk,
rebuilding locally - that is - overwriting release artifacts with
something different in the local repository, and then later on even
commit those changes forgetting to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Christian,
My question may have sounded rhetorically but I really meant that. You
could of course manage commit rights with subversion so that whenever
someone mistakenly would try to commit to that release version on trunk,
subversion could
OK. So you would NOT mind if maven adds some new features that
are compatible to older versions of maven.
Thats all I am fighting for.
No fighting required, just make a patch. If it's truly backwards compatible,
then there wouldn't be much reason for it to be declined.
I'm interested in
Ask someone why you have to invoke eclipse:eclipse on toplevel everytime.
If the dependency of some-module has changed, you can NOT invoke
eclipse:eclipse
just on some-module since the plugin then wants to resolve the dependencies
from the repository and adds JAR-Dependencies to the IDE
Joerg Hohwiller schrieb:
Hi Christian,
My question may have sounded rhetorically but I really meant that. You
could of course manage commit rights with subversion so that whenever
someone mistakenly would try to commit to that release version on trunk,
subversion could simply disallow that.
On May 14, 2009, at 9:18 PM, Christian Schulte wrote:
Why? In SCM there should never be a non-snapshot module with snapshot
dependencies. Further a non-snapshot module should not be modified
except
for pom.xml
/trunk at revision 4
+root(1.2-SNAPSHOT)
+A(1.0)
+B(1.3-SNAPSHOT)
If the pom
2009/5/15 Christian Schulte c...@schulte.it
Joerg Hohwiller schrieb:
Why? In SCM there should never be a non-snapshot module with snapshot
dependencies. Further a non-snapshot module should not be modified except
for pom.xml
/trunk at revision 4
+root(1.2-SNAPSHOT)
+A(1.0)
Ralph Goers schrieb:
On May 12, 2009, at 9:30 PM, Christian Schulte wrote:
Ralph Goers schrieb:
Imagine that you could get a pom.xml for all of Apache Commons that
contained the dependency management for it. Every time a commons
project released a new Commons bill of materials would go with
On Tue, May 12, 2009 at 11:01 PM, Joerg Hohwiller jo...@j-hohwiller.dewrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Milos,
relying on the reactor and giving up on being able to build the one
project
separately is very bad (read: completely breaks) any IDE integration.
I
On May 12, 2009, at 7:02 PM, Ralph Goers wrote:
On May 12, 2009, at 6:20 PM, David Jencks wrote:
On May 12, 2009, at 3:43 PM, Ralph Goers wrote:
On May 12, 2009, at 2:43 PM, Brian Fox wrote:
As I already said, I talked about release-plugin and my view of
the world
and it seems
On May 13, 2009, at 12:53 AM, David Jencks wrote:
I'm even more mystified and understand how you want to use scm even
less. One of the basic principles I have for scm is that stuff
shouldn't be duplicated, in the sense that if some artifact is
released at version 1.2.3.4 say, the scm
On May 13, 2009, at 7:02 AM, Ralph Goers wrote:
On May 13, 2009, at 12:53 AM, David Jencks wrote:
I'm even more mystified and understand how you want to use scm even
less. One of the basic principles I have for scm is that stuff
shouldn't be duplicated, in the sense that if some
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi David,
[cut.]
Sorry I wasn't more specific last night at 2:00 am :-). I need more scm
context to understand. I'm assuming something like svn with
+tags
+root-1.0 (1.0)
+A(1.0)
\B(1.0)
+root-1.1 (1.1)
+A(1.0)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Milos,
mvn eclipse:eclipse does perform a build (partially) and might even produce
1 eclipse project for multiple maven projects (correct me if I'm wrong)
No it does not. But I hope it will one finest day.
And it will definitely do NOT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ralph,
I've been promised by Jason that the work on Maven 3 is going to fix
some of these issues. I simply haven't had the time to look at the work
on Maven 3 and even if I had, it has been changing at a fairly rapid
pace for months.
On May 13, 2009, at 10:41 AM, David Jencks wrote:
Sorry I wasn't more specific last night at 2:00 am :-). I need more
scm context to understand. I'm assuming something like svn with
+tags
+root-1.0 (1.0)
+A(1.0)
\B(1.0)
+root-1.1 (1.1)
+A(1.0)
\B(1.1)
\root-1.2 (1.1)
On May 13, 2009, at 12:33 PM, Joerg Hohwiller wrote:
Okay. So thats what I guessed when I said that the MavenProject/
Model is
just a stupid POJO and various plugins manipulate it with side
effects.
Sounds a little hacky to me but thats the way it is. So my
serialization
idea is nuts
On May 13, 2009, at 12:55 PM, Ralph Goers wrote:
On May 13, 2009, at 10:41 AM, David Jencks wrote:
Sorry I wasn't more specific last night at 2:00 am :-). I need
more scm context to understand. I'm assuming something like svn with
+tags
+root-1.0 (1.0)
+A(1.0)
\B(1.0)
+root-1.1
Ralph Goers schrieb:
So the tree really looks like:
+tags
+root-1.0 (trunk revision 1)
+A(1.0)
+B(1.0)
+root-1.1 (trunk revision 2)
+A(1.0)
+B(1.1)
+root-1.2 (trunk revision 3)
+A(1.0)
+B(1.2)
/trunk at revision 4
+root(1.2-SNAPSHOT)
On May 13, 2009, at 5:09 PM, Christian Schulte wrote:
Ralph Goers schrieb:
So the tree really looks like:
+tags
+root-1.0 (trunk revision 1)
+A(1.0)
+B(1.0)
+root-1.1 (trunk revision 2)
+A(1.0)
+B(1.1)
+root-1.2 (trunk revision 3)
+A(1.0)
+B(1.2)
/trunk at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Brian,
Are you using the release plugin?
Nope! I tried it and came to the point that is no good for me.
I also had a discussion with the developers long time ago
and filed some feature request. Anyhow I still think this
is the wrong approach
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Milos,
relying on the reactor and giving up on being able to build the one project
separately is very bad (read: completely breaks) any IDE integration.
I totally disagree. I am successfully using maven-eclipse-plugin (mvn
eclipse:eclipse) and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ralph,
Hi there,
absolutely everybody having large maven projects is
annoyed by maintaining the versions in all the poms.
Are you using the release plugin?
This problem probably goes away for anyone able to use the release
plugin, but
Can you give more details about what doesn't work or doesn't match your
process?
E.g. it tried to convince me to release all modules of my entire project
and complained if some module had a non SNAPSHOT version.
Since it's going to convert a module to a release version, you shouldn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Fox wrote:
Can you give more details about what doesn't work or doesn't match your
process?
E.g. it tried to convince me to release all modules of my entire project
and complained if some module had a non SNAPSHOT version.
Since it's
As I already said, I talked about release-plugin and my view of the world
and it seems NOT to fit together. My POM-tree follows strict logical
aspects that is motivated by the architecture of the project and NOT by
the philosophy of some plugin.
I'm trying to understand your structure and
On May 12, 2009, at 5:43 PM, Brian Fox wrote:
My POM-tree follows strict logical aspects that is motivated by the
architecture of the project and NOT by the philosophy of some plugin.
You do know these folks are trying to help, right? ;)
Christian.
Christian Edward Gruber
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi again,
I did not yet get the point, why you have to write a new pom.xml to the disc.
My naive illusion was that there is a central component that reads and parses
the POM in maven where you can hook into and perform the transformation.
Then
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Brian,
As I already said, I talked about release-plugin and my view of the world
and it seems NOT to fit together. My POM-tree follows strict logical
aspects that is motivated by the architecture of the project and NOT by
the philosophy of
On May 12, 2009, at 2:43 PM, Brian Fox wrote:
As I already said, I talked about release-plugin and my view of the
world
and it seems NOT to fit together. My POM-tree follows strict logical
aspects that is motivated by the architecture of the project and
NOT by
the philosophy of some
On May 12, 2009, at 3:01 PM, Joerg Hohwiller wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi again,
I did not yet get the point, why you have to write a new pom.xml to
the disc.
My naive illusion was that there is a central component that reads
and parses
the POM in maven where
On May 12, 2009, at 3:43 PM, Ralph Goers wrote:
On May 12, 2009, at 2:43 PM, Brian Fox wrote:
As I already said, I talked about release-plugin and my view of
the world
and it seems NOT to fit together. My POM-tree follows strict logical
aspects that is motivated by the architecture of
Ralph Goers schrieb:
On May 12, 2009, at 2:43 PM, Brian Fox wrote:
As I already said, I talked about release-plugin and my view of the
world
and it seems NOT to fit together. My POM-tree follows strict logical
aspects that is motivated by the architecture of the project and
NOT by
On May 12, 2009, at 6:20 PM, David Jencks wrote:
On May 12, 2009, at 3:43 PM, Ralph Goers wrote:
On May 12, 2009, at 2:43 PM, Brian Fox wrote:
As I already said, I talked about release-plugin and my view of
the world
and it seems NOT to fit together. My POM-tree follows strict
On May 12, 2009, at 6:17 PM, Christian Schulte wrote:
Ralph Goers schrieb:
On May 12, 2009, at 2:43 PM, Brian Fox wrote:
As I already said, I talked about release-plugin and my view of the
world
and it seems NOT to fit together. My POM-tree follows strict
logical
aspects that is
Ralph Goers schrieb:
Imagine that you could get a pom.xml for all of Apache Commons that
contained the dependency management for it. Every time a commons
project released a new Commons bill of materials would go with it.
a) You want all the projects to be part of the build to be sure
On May 12, 2009, at 9:30 PM, Christian Schulte wrote:
Ralph Goers schrieb:
Imagine that you could get a pom.xml for all of Apache Commons that
contained the dependency management for it. Every time a commons
project released a new Commons bill of materials would go with it.
a) You want all
It sounds like some people should have a look at the
versions-maven-plugin...
ok, so it will still force updating your pom, but it will allow releasing
individual modules using the release plugin and then updating the reactor to
reflect the new release.
-Stephen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
thanks for your answer...
absolutely everybody having large maven projects is
annoyed by maintaining the versions in all the poms.
Are you using the release plugin?
Nope! I tried it and came to the point that is no good for me.
Are you using the release plugin?
Nope! I tried it and came to the point that is no good for me.
I also had a discussion with the developers long time ago
and filed some feature request. Anyhow I still think this
is the wrong approach for me.
Can you give more details about what doesn't
On May 9, 2009, at 7:42 PM, Brian Fox wrote:
On Sat, May 9, 2009 at 5:44 PM, Joerg Hohwiller jo...@j-
hohwiller.dewrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
absolutely everybody having large maven projects is
annoyed by maintaining the versions in all the poms.
Are
On Sun, May 10, 2009 at 3:09 PM, Joerg Hohwiller jo...@j-hohwiller.dewrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
You can use dependency management or properties to deal with omitting
the
dependencies. I personally never assume what will be contained in a
reactor
and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
absolutely everybody having large maven projects is
annoyed by maintaining the versions in all the poms.
Additionally the complete solution is quite simple
and seems to be quite common sense:
1. Allow to omitt versions in parent as well
On Sat, May 9, 2009 at 5:44 PM, Joerg Hohwiller jo...@j-hohwiller.dewrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
absolutely everybody having large maven projects is
annoyed by maintaining the versions in all the poms.
Are you using the release plugin?
Additionally
63 matches
Mail list logo
