[ http://jira.codehaus.org/browse/MECLIPSE-120?page=comments#action_77004 ]
Joerg Schaible commented on MECLIPSE-120:
-----------------------------------------
bq. Your first problem is another issue (MECLIPSE-152), that I'd like to see
solved there. Forcing snapshot versions only fixes that problem in certain
situations.
IMHO this is strongly related to MNG-1245 (just another issue that starts to
embarass me, since it is fixed for months and 2.0.5 seems not going to happen
anwhere in near time - just a different story)
bq. But you actually mean -forceProjectReference here, right?
Yep.
bq. Second issue: I see that as a good thing - you'll find out soon enough
which artifacts are affected by a change since you can't change them because
they reference jar files, not projects.
?? If your project refer jars, then they are not affected by a refactoring.
This is the point! If you have a central jar with APIs and you change it, none
of the other projects are affected at all. Even worse - Eclipse does not
detect, that some of those are affected. Now the developer has to guess.
bq. Also, when you do a lot of refactoring etc, I get the impression you don't
have multiple release cycles, but just 1, for the entire project tree. If
that's the case, you could use a dependencyManagement section in the root pom,
specifying ${version} for all modules. That way they're always referring to
reactor/workspace projects. This should fix your issue, no?
No. A lot of our ~100 artifacts have an own release cycles and this for good
reason. Nevertheless sometimes you have to refactor something. It's like
changing commons-logging, but with the fortune to get an impression by the
impact a change will have.
bq. Third issue: this is fixing it afterwards, and hoping that the developer
will indeed update the poms. As I mentioned above, if you still have jar
references and not project references, you're forced to update the pom at that
time, or decide not to since it's an unwanted change. Isn't that safer?
Developers are confronted with making a good decision on what to upgrade and
what for.
So you say it is better to run into the problems, when you are actually
building the release? Sorry, *then* you're normally under time constraints and
it is really no fun to sort things out at that level.
bq. What I meant with my third comment is that you see stuff working in
eclipse, but it won't compile on the commandline. That gives the developer
another responsibility - mvn install before a commit, and update the poms. It's
an iterative process and requires more time on big projects. Just updating a
pom and mvn eclipse:eclipse, then refresh in eclipse gives you much faster
feedback on wheter it still works.
Exaclty. It *is* the developers responsibility. The difference to the situation
now is that he actually has a chance to be responsible. And as I said, this is
optional and not the default working mode of the Eclipse plugin. And currently
the situation is even worse, since of MNG-1245 Eclipse *is* using the SNAPSHOT
to compile when invoked from the command line ignoring the POM defining a
released version. Therefore the generated Eclipse projects are often broken
anyway. Currently it took me quite a complete day to get this into sync again
by adding depednencyManagement sections to the POMs that affect the Eclipse
plugin's project generation (and I don't blame the Eclipse plugin here - there
are too may bugs in the reelase core, but the complete situation starts to get
unmanagable).
bg. On the EAR thing: shouldn't that be solved in the dependencyManagement
section? That way it'll work both for eclipse and on the commandline.
No, it won't. We already use a company wide POM with dependencyManagement
section. But if you release an EJB it will refer a special version of it as
parent. Releasing another EJB might refer another parent. Now a project P wants
to build an EAR of those two EJBs and it simply does not work. EJB1 is
depending on artifact X-1.1, EJB2 is depending on artifact X-1.2. Building the
EAR will package one of those X artifacts, but either EJB1 is broken or EJB2,
because they refer X in their manifests. Now the project realizes, that it also
needs an updated EJB1 and then somebody of the core team providing EJB1
recognizes that upgrading EJB1 to dependency X-1.2 will break the code of EJB1
...
This all could have been avoided if team of X would have known that their
change also had impact on EJB1. Therefore they should have been able to see the
results of their refactoring.
bq. Let me know what you think. I feel this change will probably make things
worse because it requires a lot of extra attention from developers, and makes
it much easier for them to commit breaking builds.
IMHO the Eclipse projects cannot really reflect the Maven build anyway. Eclipse
has no means of test scope, you don't use the transitive deps from Eclipse
itself (at least not in the released version of the eclipse plugin). A
developer has to take always attention. And since Maven is behaving differently
for multi-module builds vs. local builds (see MNG-1245) some developers here
even started to manage their Eclipse projects on their own (Another team has
meanwhile kicked off Maven at all).
> Force inter-project dependencies
> --------------------------------
>
> Key: MECLIPSE-120
> URL: http://jira.codehaus.org/browse/MECLIPSE-120
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Improvement
> Components: multiproject
> Affects Versions: 2.2
> Reporter: Joerg Schaible
>
> In a multi-module setup, the dependencies between the projects are only
> created, if the project's version match the one of the referenced artfiact.
> After a release this is normally no longer the case if you have modules with
> independent release cycles. Therefore it would be good, if the plugin could
> be forced with an option (e.g. -forceSnapshot) to use a dependency to a
> module's project with a snapshot version instead of a dependency to the
> released artifact in the local repository. The plugin detects this situation
> already, but logs just a warning. Without this feature, refactorings are
> getting really tedious.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
