On Sat, May 16, 2009 at 5:17 AM, Joerg Hohwiller 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 the jar o
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 wrote:
>
> On May 16, 2009, at 1:48 PM, Joerg Hohwiller wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
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 th
-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
-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 propo
>
>
> 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 w
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. I
>
>
> 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
-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ö
-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
http://maven.apache.org/guides/introduction/introduction-
On Fri, May 15, 2009 at 4: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 ?
>
> >>
> >>
> >> A
-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 the
-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
-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 defi
On Fri, May 15, 2009 at 2:58 PM, Joerg Hohwiller wrote:
> -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
-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
-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 th
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 th
2009/5/15 Christian Schulte
> 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)
> +B(1.3-SNAPSH
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
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 disal
> 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
>
>
> 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
-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 c
-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 forgettin
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-
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 revisi
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-SNAP
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 (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 thou
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)
+A(
-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.
>
-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 co
-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
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 artifa
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 lo
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 NOT
On Tue, May 12, 2009 at 11:01 PM, Joerg Hohwiller wrote:
> -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 dis
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"
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
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
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
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 motivat
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
logi
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 proje
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
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 yo
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 pl
-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
-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
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
christianedwardgr
>
>
>
> 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 struct
-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.
>>
>
>
>
> >
> > 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
-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 re
-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) a
-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
On Sun, May 10, 2009 at 3:09 PM, Joerg Hohwiller wrote:
> -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 structure m
On May 9, 2009, at 7:42 PM, Brian Fox wrote:
On Sat, May 9, 2009 at 5:44 PM, Joerg Hohwiller hohwiller.de>wrote:
-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
> > 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 do
-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 g
On Sat, May 9, 2009 at 5:44 PM, Joerg Hohwiller wrote:
> -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 the complete
-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 as well
as in t
63 matches
Mail list logo
