Re: Recent contributions
There are some good patches here - could we get them integrated any time soon? James On Thu, 2008-02-14 at 08:06 -0800, Dário Oliveros wrote: Hi there, I've recently created and commented out a couple of issues, provided fixes for some of them and would like anyone (if possible, of course) to check whether any of these changes is acceptable and also if there is anything else I could help with. I'll be glad to do so. Here they are: - MRM-687 (patch that may also fix MRM-608) - MRM-692 (patch) - MRM-617 (workaround for javascript validation) - MRM-622 (patch) - MRM-206 (zip containing xmlrpc functionality) Thanks
Re: Recent contributions
Thanks for the patches Darios! I'll look into them this weekend :) Thanks, Deng On Fri, Feb 15, 2008 at 8:33 AM, James William Dumay [EMAIL PROTECTED] wrote: There are some good patches here - could we get them integrated any time soon? James On Thu, 2008-02-14 at 08:06 -0800, Dário Oliveros wrote: Hi there, I've recently created and commented out a couple of issues, provided fixes for some of them and would like anyone (if possible, of course) to check whether any of these changes is acceptable and also if there is anything else I could help with. I'll be glad to do so. Here they are: - MRM-687 (patch that may also fix MRM-608) - MRM-692 (patch) - MRM-617 (workaround for javascript validation) - MRM-622 (patch) - MRM-206 (zip containing xmlrpc functionality) Thanks
Re: Archiva 1.1 Roadmap
Thanks for putting the roadmap [1] in place Deng - I made a couple of cleanups and did a quick run through JIRA as well. I think we still need to cut back on the features for 1.1, since there's 62 issues in there... do we just timebox, or do we pick some features for 1.2 now? Cheers, Brett [1] http://docs.codehaus.org/display/MAVENUSER/Archiva+Roadmap On 11/02/2008, at 5:07 PM, Maria Odea Ching wrote: On Feb 7, 2008 7:08 PM, Brett Porter [EMAIL PROTECTED] wrote: I have some additions :) I also think we need to keep reviewing the types of problems people have and helping them diagnose them. It seems that figuring out repo whitelists and blacklists and the cause of proxy problems is still difficult - so maybe a UI configuration for the logging might be a good idea? Or a way to request it from a browser and get additional information (ie, 404 screen could capture all the logging even if it's not logged). +1 :) Also, I'd like to finish the work of replacing the plexus runtime with a standalone jetty bundle that runs the war as is :) I have a local copy of Archiva which includes the jetty-archetype you started for this Brett, though I haven't been able to work on it lately. I'll try to put some time to complete it and check it in as soon as I can. Ill also file a jira to keep track of this. Thanks, Deng On 07/02/2008, at 12:16 AM, Brett Porter wrote: These all sound good to me. Really enjoying the discussion :) Some comments and additions: On 06/02/2008, at 5:48 PM, Maria Odea Ching wrote: From the thread so far, these are the things to choose from for the 1.1roadmap: 1. Reduce memory consumption 2. Preemptive artifact synchronisation 3. Eliminate client side blocking when artifacts are being downloaded from remote repositories. 4. Ability to take repositories (both managed and remote) offline 5. Communication with remote repositories should be done asynchronously 6. Web UI for deploying artifacts 7. Plugin subsystem. We already have this for consumers but we really should have features like search, dependency graphing and browsing as plugins so we can turn bad behaving features and also give a way for users to create their own functionality. 8. Separation between managed repositories used for publishing and those used for caching artifacts from remote repositories. This separation would allow us to have: * Provide indexing, browsing and search only for publishing * RSS feeds for new artifacts in published repositories. I think this is something that is configurable, and set nicely by default. I don't think we should completely separate proxy cache managed repos from deployed repos, but having a default configuration that does and recommending it is the way to go. 9. Review synchronization of the configuration object 10. Improve the tests where databases are being set-up (use mock objects instead) 11. Statistical reports 12. Repository grouping Any more suggestions or comments for this? :) I'd just add 13. architectural simplification - we talked about some technology changes and while I don't think we need to rush into any, it would be worth having them in mind if we can either gradually move to them or if it becomes simpler to do than make a change in the current set up. For instance, doing (10) might be better at a time when we make changes to the database layer itself. Along these lines, architecturally I think we need to add: 14. separate the subsystems better. In my view - the base system being the tools (scanning, consumers, etc - with or without the database), then the addition of the proxy/webdav on that (possibly without the database), then the web application/visualisation on top of that (this requires the databases and all other pieces of functionality). We might later add web services as an option with or without the webapp. These different deployment options would make it much more flexible. Again I don't think this all needs to be done in one go - but designing the target architecture and moving towards it would be a good goal for 1.1 and beyond. Some of the above may actually be plugins too, so we should consider the impact of that. Would be great to update the wiki with this list split into 1.1 and beyond sections :) Btw, what does everyone think of having the end of March as the target release date of 1.1? Great! We should probably aim to be feature complete a few weeks before that then. This probably means only picking a few of the above (there is a lot there!), and moving the rest to 1.2. Also need to pick some important issues from the JIRA pool - as well as cutting down the 60+ in there now :) We can keep working on critical stuff in the 1.0.x line. Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: wiki was: [Discussion] Continuum 2.0 Roadmap
I have created an page for Continuum 2.0 related stuff (treat this as a dashboard with links to related C2 docs). http://cwiki.apache.org/confluence/display/CONTINUUMDEV/Draft+-+Continuum+2.0 The other content will keep moving in the background. Cheers, Rahul Emmanuel Venisse wrote: Thanks Brett. I'm +1 to open it. Emmanuel On Feb 13, 2008 8:43 AM, Brett Porter [EMAIL PROTECTED] wrote: no, permissions changes are non-destructive :) On 13/02/2008, at 6:33 PM, Rahul Thakur wrote: +1 as long as editing it requires a login :-) Should I hold off the migration from Codehaus? Rahul On Feb 13, 2008 6:32 PM, Brett Porter [EMAIL PROTECTED] wrote: On 13/02/2008, at 4:04 PM, Wendy Smoak wrote: On Feb 12, 2008 10:01 PM, Brett Porter [EMAIL PROTECTED] wrote: Ok, I've created two wiki's: ... http://cwiki.apache.org/confluence/display/CONTINUUMDEV/Index (exported to: http://cwiki.apache.org/CONTINUUMDEV/) This one is editable by developers only (accepts comments from anyone). This is for the roadmap and design docs. I only granted access to a few people that I could easily find - if you need to edit, just let me or a confluence admin know. Why would we not want to allow the community to participate in roadmap and design docs? The only reason I can think of to restrict access is to make sure we have a CLA for content we intend to redistribute. Both good points - I was following what we had in Maven already - what do others think - shall we just open it up? Or do we not even need the DEV space? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: atypical plugin use cases
On Wed, Feb 13, 2008 at 11:52 PM, Dan Fabulich [EMAIL PROTECTED] wrote:
John Casey wrote:
I'm trying to document some of the design problems with sort of exotic
plugin
use cases, things like aggregation and use of ${reactorProjects}, that
we're
running into under the current setup. I have proposals to address most
of the
issues, but I'd love to hear what you would propose...or even tell me
about
plugin-design issues that I haven't thought of.
This may be quibbling, but it seems weird to me that aggregation would be
an atypical case. IMO, almost every reporting plugin needs to do
aggregation (or at least be able to do it). checkstyle, clover, docck,
javadoc, jxr, pmd, surefire-report all need aggregation somehow or other.
-Dan
However, IMHO they should implement the aggregation as a separate goal.
Recent contributions
Hi there, I've recently created and commented out a couple of issues, provided fixes for some of them and would like anyone (if possible, of course) to check whether any of these changes is acceptable and also if there is anything else I could help with. I'll be glad to do so. Here they are: - MRM-687 (patch that may also fix MRM-608) - MRM-692 (patch) - MRM-617 (workaround for javascript validation) - MRM-622 (patch) - MRM-206 (zip containing xmlrpc functionality) Thanks -- View this message in context: http://www.nabble.com/Recent-contributions-tp15481243p15481243.html Sent from the archiva-dev mailing list archive at Nabble.com.
Re: atypical plugin use cases
That's not really the point. The point is that these behaviors
require exceptional logic to the main build process inside Maven.
They're a deviation of the normal once-per-project mojo, which is
geared to operate on the current project.
If you wanted to draw attention to something that doesn't fit the
'atypical' heading, I'd say that build introspection is a much better
target. Almost any sort of integration with Maven will need to be
able to extract this sort of information, and forcing a build to get
that information is a bad way to go.
If you really want to spend the time, and have a better title, feel
free to rename the document. I have no problems with that; I'm more
concerned with solving the problems I talk about in the document's
content.
-john
On Feb 13, 2008, at 6:52 PM, Dan Fabulich wrote:
John Casey wrote:
I'm trying to document some of the design problems with sort of
exotic plugin use cases, things like aggregation and use of $
{reactorProjects}, that we're running into under the current
setup. I have proposals to address most of the issues, but I'd
love to hear what you would propose...or even tell me about plugin-
design issues that I haven't thought of.
This may be quibbling, but it seems weird to me that aggregation
would be an atypical case. IMO, almost every reporting plugin
needs to do aggregation (or at least be able to do it).
checkstyle, clover, docck, javadoc, jxr, pmd, surefire-report all
need aggregation somehow or other.
-Dan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
Re: Maven artifact work
On 13/02/2008, at 11:32 PM, Mark Hobson wrote: Hi there, I've been chatting to Jason about making some headway with the maven artifact improvements that have been on the cards for sometime now. I've dug through much of the code on my travels implementing dependency:tree, conflict resolution and integrating maven-artifact 3.x into maven 2.0.x. Cool - you're saying you've got local changes that do these, or you've been investigating? I believe that Oleg and Ralph have been working on various related matters, so I'd like to discuss the current state of artifact work and what features would be suitable to work on next. Yeah, it would be great to get an update here - the latest information I can find is that on the wiki from June last year and I don't believe that's current, and the CAP branch notes focus on refactoring the API rather than the changes to the resolution mechanism. Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
any other critical fixes needed for an Archetype alpha?
Hi, I would like to put together an archetype release incorporating the fixes I made for backwards compat. Are there any other critical problems that should go in first? Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: any other critical fixes needed for an Archetype alpha?
Without fixing: http://jira.codehaus.org/browse/ARCHETYPE-133 The create-from-project option does not work, but that's the only thing I can think of that makes it really suck. Create from project also doesn't work on Windows. On 14-Feb-08, at 9:51 AM, Brett Porter wrote: Hi, I would like to put together an archetype release incorporating the fixes I made for backwards compat. Are there any other critical problems that should go in first? Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: any other critical fixes needed for an Archetype alpha?
I'm fixing archetype:generate now as it's the best feature in the new version to let people grab things from lists. On 14-Feb-08, at 11:20 AM, Jason van Zyl wrote: ARCHETYPE-133 is fixed. I asked some Windows folks in IRC to test the create from project on Windows. I also notice now the archetype:generate which brings up the list (which makes it easier for people) is now hosed. So that needs to be fixed. On 14-Feb-08, at 10:21 AM, Jason van Zyl wrote: Without fixing: http://jira.codehaus.org/browse/ARCHETYPE-133 The create-from-project option does not work, but that's the only thing I can think of that makes it really suck. Create from project also doesn't work on Windows. On 14-Feb-08, at 9:51 AM, Brett Porter wrote: Hi, I would like to put together an archetype release incorporating the fixes I made for backwards compat. Are there any other critical problems that should go in first? Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: any other critical fixes needed for an Archetype alpha?
On 14-Feb-08, at 11:41 AM, Brett Porter wrote: On 15/02/2008, at 6:31 AM, Jason van Zyl wrote: I'm fixing archetype:generate now as it's the best feature in the new version to let people grab things from lists. Thanks. I see what you mean about it being broken now as I just get an NPE. I wasn't seeing this yesterday. I hadn't seen Raphaël's commit before I asked about a release - I had already restored some level of backwards compat to the goal prior to that. I haven't tried the new create method, but I think it's a good idea. The changes I made are still good defaults for the new method IMO. I'm fixing the archetype:generate now, but other then that it's just Windows issues. Brian said he would try to take a look, but one of the best features is busted for Windows users if that doesn't get corrected. Not sure if he'll get time so if other windows users can try the archetype:create-from-project goal on a multi-module build that would be helpful. BTW, has anyone else seen Leopard not always recognising new messages in IMAP folders until you click on them? :) Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: any other critical fixes needed for an Archetype alpha?
On 15/02/2008, at 6:31 AM, Jason van Zyl wrote: I'm fixing archetype:generate now as it's the best feature in the new version to let people grab things from lists. Thanks. I see what you mean about it being broken now as I just get an NPE. I wasn't seeing this yesterday. I hadn't seen Raphaël's commit before I asked about a release - I had already restored some level of backwards compat to the goal prior to that. I haven't tried the new create method, but I think it's a good idea. The changes I made are still good defaults for the new method IMO. BTW, has anyone else seen Leopard not always recognising new messages in IMAP folders until you click on them? :) Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: any other critical fixes needed for an Archetype alpha?
ARCHETYPE-133 is fixed. I asked some Windows folks in IRC to test the create from project on Windows. I also notice now the archetype:generate which brings up the list (which makes it easier for people) is now hosed. So that needs to be fixed. On 14-Feb-08, at 10:21 AM, Jason van Zyl wrote: Without fixing: http://jira.codehaus.org/browse/ARCHETYPE-133 The create-from-project option does not work, but that's the only thing I can think of that makes it really suck. Create from project also doesn't work on Windows. On 14-Feb-08, at 9:51 AM, Brett Porter wrote: Hi, I would like to put together an archetype release incorporating the fixes I made for backwards compat. Are there any other critical problems that should go in first? Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: any other critical fixes needed for an Archetype alpha?
On 15/02/2008, at 6:41 AM, Brett Porter wrote: On 15/02/2008, at 6:31 AM, Jason van Zyl wrote: I'm fixing archetype:generate now as it's the best feature in the new version to let people grab things from lists. Thanks. I see what you mean about it being broken now as I just get an NPE. I wasn't seeing this yesterday. I hadn't tested my change fully enough. I've fixed the problem and published a new snapshot. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r627675 - in /maven/components/branches/maven-2.0.x/maven-project/src: main/java/org/apache/maven/project/MavenProject.java test/java/org/apache/maven/project/MavenProjectTest.java
Carlos,
Can you elaborate on the need for this?
I understand that since MavenProject is non-final and so are the get/
sets they can be overridden and so we should be using the get/set
internally. However, it would seem we don't need that funcationality
for every field - which particular ones do you see as needing to be
overridden?
Also, I don't think the clone() stuff is right:
- you've deprecated the copy constructor even though it is still
useful. You also require it's existence which means it shouldn't be
deprecated.
- clone()'s contract says that it doesn't call any constructors,
making the method work but not as documented by the JDK
- clone() should call super.clone() to get a valid MavenProject instance
- MavenProject doesn't implement clonable
Why did you need clone()?
Thanks,
Brett
On 14/02/2008, at 5:40 PM, [EMAIL PROTECTED] wrote:
Author: carlos
Date: Wed Feb 13 22:40:35 2008
New Revision: 627675
URL: http://svn.apache.org/viewvc?rev=627675view=rev
Log:
[MNG-3400] MavenProject is not extensible. Merge rev 627670 from trunk
Modified:
maven/components/branches/maven-2.0.x/maven-project/src/main/java/
org/apache/maven/project/MavenProject.java
maven/components/branches/maven-2.0.x/maven-project/src/test/java/
org/apache/maven/project/MavenProjectTest.java
Modified: maven/components/branches/maven-2.0.x/maven-project/src/
main/java/org/apache/maven/project/MavenProject.java
URL:
http://svn.apache.org/viewvc/maven/components/branches/maven-2.0.x/maven-project/src/main/java/org/apache/maven/project/MavenProject.java?rev=627675r1=627674r2=627675view=diff
=
=
=
=
=
=
=
=
==
--- maven/components/branches/maven-2.0.x/maven-project/src/main/
java/org/apache/maven/project/MavenProject.java (original)
+++ maven/components/branches/maven-2.0.x/maven-project/src/main/
java/org/apache/maven/project/MavenProject.java Wed Feb 13 22:40:35
2008
@@ -158,103 +158,107 @@
model.setArtifactId( EMPTY_PROJECT_ARTIFACT_ID );
model.setVersion( EMPTY_PROJECT_VERSION );
-this.model = model;
+this.setModel( model );
}
public MavenProject( Model model )
{
-this.model = model;
+this.setModel( model );
}
+/**
+ * @deprecated use [EMAIL PROTECTED] #clone()}
+ */
public MavenProject( MavenProject project )
{
// disown the parent
// copy fields
-this.file = project.file;
+setFile( project.getFile() );
-// don't need a deep copy, they don't get modified or added/
removed to/from - but make them unmodifiable to be sure!
-if ( project.dependencyArtifacts != null )
+// don't need a deep copy, they don't get modified or added/
removed to/from - but make them unmodifiable to be
+// sure!
+if ( project.getDependencyArtifacts() != null )
{
-this.dependencyArtifacts =
Collections.unmodifiableSet( project.dependencyArtifacts );
+
setDependencyArtifacts
( Collections.unmodifiableSet( project.getDependencyArtifacts() ) );
}
-
-if ( project.artifacts != null )
+
+if ( project.getArtifacts() != null )
{
-this.artifacts =
Collections.unmodifiableSet( project.artifacts );
+
setArtifacts( Collections.unmodifiableSet( project.getArtifacts() ) );
}
-
-if ( project.pluginArtifacts != null )
+
+if ( project.getPluginArtifacts() != null )
{
-this.pluginArtifacts =
Collections.unmodifiableSet( project.pluginArtifacts );
+
setPluginArtifacts
( Collections.unmodifiableSet( project.getPluginArtifacts() ) );
}
-
-if ( project.reportArtifacts != null )
+
+if ( project.getReportArtifacts() != null )
{
-this.reportArtifacts =
Collections.unmodifiableSet( project.reportArtifacts );
-}
-
-if ( project.extensionArtifacts != null )
+
setReportArtifacts
( Collections.unmodifiableSet( project.getReportArtifacts() ) );
+}
+
+if ( project.getExtensionArtifacts() != null )
{
-this.extensionArtifacts =
Collections.unmodifiableSet( project.extensionArtifacts );
-}
-
-this.parentArtifact = project.parentArtifact;
+
setExtensionArtifacts
( Collections.unmodifiableSet( project.getExtensionArtifacts() ) );
+}
+
+setParentArtifact( ( project.getParentArtifact() ) );
-if ( project.remoteArtifactRepositories != null )
+if ( project.getRemoteArtifactRepositories() != null )
{
-this.remoteArtifactRepositories =
Collections.unmodifiableList( project.remoteArtifactRepositories );
-}
-
-if ( project.pluginArtifactRepositories != null )
+
setRemoteArtifactRepositories
( Collections
.unmodifiableList(
Re: svn commit: r627675 - in /maven/components/branches/maven-2.0.x/maven-project/src: main/java/org/apache/maven/project/MavenProject.java test/java/org/apache/maven/project/MavenProjectTest.java
Reading carefully the javadoc I see the mistakes i made in clone :( I
can fix that
The problem arised with a delegate pattern implementation, the
MavenProject instance is encapsulated [1], but the problem comes with
other classes using this constructor to make copies, which will ignore
any customizations made in the delegating object (the subclass).
If the way to make a copy where defined in a method ( clone() seems to
be the right one ) then subclasses could just override that method and
there wouldnt be any need of getters/setters, but right now that
constructor is used in the maven archiver. Adding the getters and
setters is a patch until the other classes are updated to use clone()
and to keep backwards compatibility.
[1] http://tinyurl.com/29jzte
On Thu, Feb 14, 2008 at 4:15 PM, Brett Porter [EMAIL PROTECTED] wrote:
Carlos,
Can you elaborate on the need for this?
I understand that since MavenProject is non-final and so are the get/
sets they can be overridden and so we should be using the get/set
internally. However, it would seem we don't need that funcationality
for every field - which particular ones do you see as needing to be
overridden?
Also, I don't think the clone() stuff is right:
- you've deprecated the copy constructor even though it is still
useful. You also require it's existence which means it shouldn't be
deprecated.
- clone()'s contract says that it doesn't call any constructors,
making the method work but not as documented by the JDK
- clone() should call super.clone() to get a valid MavenProject instance
- MavenProject doesn't implement clonable
Why did you need clone()?
Thanks,
Brett
On 14/02/2008, at 5:40 PM, [EMAIL PROTECTED] wrote:
Author: carlos
Date: Wed Feb 13 22:40:35 2008
New Revision: 627675
URL: http://svn.apache.org/viewvc?rev=627675view=rev
Log:
[MNG-3400] MavenProject is not extensible. Merge rev 627670 from trunk
Modified:
maven/components/branches/maven-2.0.x/maven-project/src/main/java/
org/apache/maven/project/MavenProject.java
maven/components/branches/maven-2.0.x/maven-project/src/test/java/
org/apache/maven/project/MavenProjectTest.java
Modified: maven/components/branches/maven-2.0.x/maven-project/src/
main/java/org/apache/maven/project/MavenProject.java
URL:
http://svn.apache.org/viewvc/maven/components/branches/maven-2.0.x/maven-project/src/main/java/org/apache/maven/project/MavenProject.java?rev=627675r1=627674r2=627675view=diff
=
=
=
=
=
=
=
=
==
--- maven/components/branches/maven-2.0.x/maven-project/src/main/
java/org/apache/maven/project/MavenProject.java (original)
+++ maven/components/branches/maven-2.0.x/maven-project/src/main/
java/org/apache/maven/project/MavenProject.java Wed Feb 13 22:40:35
2008
@@ -158,103 +158,107 @@
model.setArtifactId( EMPTY_PROJECT_ARTIFACT_ID );
model.setVersion( EMPTY_PROJECT_VERSION );
-this.model = model;
+this.setModel( model );
}
public MavenProject( Model model )
{
-this.model = model;
+this.setModel( model );
}
+/**
+ * @deprecated use [EMAIL PROTECTED] #clone()}
+ */
public MavenProject( MavenProject project )
{
// disown the parent
// copy fields
-this.file = project.file;
+setFile( project.getFile() );
-// don't need a deep copy, they don't get modified or added/
removed to/from - but make them unmodifiable to be sure!
-if ( project.dependencyArtifacts != null )
+// don't need a deep copy, they don't get modified or added/
removed to/from - but make them unmodifiable to be
+// sure!
+if ( project.getDependencyArtifacts() != null )
{
-this.dependencyArtifacts =
Collections.unmodifiableSet( project.dependencyArtifacts );
+
setDependencyArtifacts
( Collections.unmodifiableSet( project.getDependencyArtifacts() ) );
}
-
-if ( project.artifacts != null )
+
+if ( project.getArtifacts() != null )
{
-this.artifacts =
Collections.unmodifiableSet( project.artifacts );
+
setArtifacts( Collections.unmodifiableSet( project.getArtifacts() ) );
}
-
-if ( project.pluginArtifacts != null )
+
+if ( project.getPluginArtifacts() != null )
{
-this.pluginArtifacts =
Collections.unmodifiableSet( project.pluginArtifacts );
+
setPluginArtifacts
( Collections.unmodifiableSet( project.getPluginArtifacts() ) );
}
-
-if ( project.reportArtifacts != null )
+
+if ( project.getReportArtifacts() != null )
{
-this.reportArtifacts =
Re: svn commit: r627675 - in /maven/components/branches/maven-2.0.x/maven-project/src: main/java/org/apache/maven/project/MavenProject.java test/java/org/apache/maven/project/MavenProjectTest.java
I'm not sure why the archiver needs to use the delegate? Is it because
you lose track of the updates? IF that's all, then you could follow
the @todo in the class javadoc :)
If it truly needs it, clone is the right method - I'd definitely
recommend reading the section on clone in Effective Java though :)
- Brett
On 15/02/2008, at 11:57 AM, Carlos Sanchez wrote:
Reading carefully the javadoc I see the mistakes i made in clone :( I
can fix that
The problem arised with a delegate pattern implementation, the
MavenProject instance is encapsulated [1], but the problem comes with
other classes using this constructor to make copies, which will ignore
any customizations made in the delegating object (the subclass).
If the way to make a copy where defined in a method ( clone() seems to
be the right one ) then subclasses could just override that method and
there wouldnt be any need of getters/setters, but right now that
constructor is used in the maven archiver. Adding the getters and
setters is a patch until the other classes are updated to use clone()
and to keep backwards compatibility.
[1] http://tinyurl.com/29jzte
On Thu, Feb 14, 2008 at 4:15 PM, Brett Porter [EMAIL PROTECTED]
wrote:
Carlos,
Can you elaborate on the need for this?
I understand that since MavenProject is non-final and so are the get/
sets they can be overridden and so we should be using the get/set
internally. However, it would seem we don't need that funcationality
for every field - which particular ones do you see as needing to be
overridden?
Also, I don't think the clone() stuff is right:
- you've deprecated the copy constructor even though it is still
useful. You also require it's existence which means it shouldn't be
deprecated.
- clone()'s contract says that it doesn't call any constructors,
making the method work but not as documented by the JDK
- clone() should call super.clone() to get a valid MavenProject
instance
- MavenProject doesn't implement clonable
Why did you need clone()?
Thanks,
Brett
On 14/02/2008, at 5:40 PM, [EMAIL PROTECTED] wrote:
Author: carlos
Date: Wed Feb 13 22:40:35 2008
New Revision: 627675
URL: http://svn.apache.org/viewvc?rev=627675view=rev
Log:
[MNG-3400] MavenProject is not extensible. Merge rev 627670 from
trunk
Modified:
maven/components/branches/maven-2.0.x/maven-project/src/main/java/
org/apache/maven/project/MavenProject.java
maven/components/branches/maven-2.0.x/maven-project/src/test/java/
org/apache/maven/project/MavenProjectTest.java
Modified: maven/components/branches/maven-2.0.x/maven-project/src/
main/java/org/apache/maven/project/MavenProject.java
URL:
http://svn.apache.org/viewvc/maven/components/branches/maven-2.0.x/maven-project/src/main/java/org/apache/maven/project/MavenProject.java?rev=627675r1=627674r2=627675view=diff
=
=
=
=
=
=
=
=
=
=
--- maven/components/branches/maven-2.0.x/maven-project/src/main/
java/org/apache/maven/project/MavenProject.java (original)
+++ maven/components/branches/maven-2.0.x/maven-project/src/main/
java/org/apache/maven/project/MavenProject.java Wed Feb 13 22:40:35
2008
@@ -158,103 +158,107 @@
model.setArtifactId( EMPTY_PROJECT_ARTIFACT_ID );
model.setVersion( EMPTY_PROJECT_VERSION );
-this.model = model;
+this.setModel( model );
}
public MavenProject( Model model )
{
-this.model = model;
+this.setModel( model );
}
+/**
+ * @deprecated use [EMAIL PROTECTED] #clone()}
+ */
public MavenProject( MavenProject project )
{
// disown the parent
// copy fields
-this.file = project.file;
+setFile( project.getFile() );
-// don't need a deep copy, they don't get modified or
added/
removed to/from - but make them unmodifiable to be sure!
-if ( project.dependencyArtifacts != null )
+// don't need a deep copy, they don't get modified or
added/
removed to/from - but make them unmodifiable to be
+// sure!
+if ( project.getDependencyArtifacts() != null )
{
-this.dependencyArtifacts =
Collections.unmodifiableSet( project.dependencyArtifacts );
+
setDependencyArtifacts
( Collections.unmodifiableSet( project.getDependencyArtifacts() ) );
}
-
-if ( project.artifacts != null )
+
+if ( project.getArtifacts() != null )
{
-this.artifacts =
Collections.unmodifiableSet( project.artifacts );
+
setArtifacts
( Collections.unmodifiableSet( project.getArtifacts() ) );
}
-
-if ( project.pluginArtifacts != null )
+
+if ( project.getPluginArtifacts() != null )
{
-this.pluginArtifacts =
Collections.unmodifiableSet( project.pluginArtifacts );
+
setPluginArtifacts
( Collections.unmodifiableSet( project.getPluginArtifacts() ) );
}
-
-if ( project.reportArtifacts != null )
+
+if ( project.getReportArtifacts() !=
Re: svn commit: r627675 - in /maven/components/branches/maven-2.0.x/maven-project/src: main/java/org/apache/maven/project/MavenProject.java test/java/org/apache/maven/project/MavenProjectTest.java
On 14-Feb-08, at 4:57 PM, Carlos Sanchez wrote:
Reading carefully the javadoc I see the mistakes i made in clone :( I
can fix that
The problem arised with a delegate pattern implementation, the
MavenProject instance is encapsulated [1], but the problem comes with
other classes using this constructor to make copies, which will ignore
any customizations made in the delegating object (the subclass).
If the way to make a copy where defined in a method ( clone() seems to
be the right one ) then subclasses could just override that method and
there wouldnt be any need of getters/setters, but right now that
constructor is used in the maven archiver.
In the Archiver?? That just sounds wrong. It should be more of
extracting the information necessary from the POM and passing that in
as a set of attributes to be used by the Archiver.
Adding the getters and
setters is a patch until the other classes are updated to use clone()
and to keep backwards compatibility.
[1] http://tinyurl.com/29jzte
On Thu, Feb 14, 2008 at 4:15 PM, Brett Porter [EMAIL PROTECTED]
wrote:
Carlos,
Can you elaborate on the need for this?
I understand that since MavenProject is non-final and so are the get/
sets they can be overridden and so we should be using the get/set
internally. However, it would seem we don't need that funcationality
for every field - which particular ones do you see as needing to be
overridden?
Also, I don't think the clone() stuff is right:
- you've deprecated the copy constructor even though it is still
useful. You also require it's existence which means it shouldn't be
deprecated.
- clone()'s contract says that it doesn't call any constructors,
making the method work but not as documented by the JDK
- clone() should call super.clone() to get a valid MavenProject
instance
- MavenProject doesn't implement clonable
Why did you need clone()?
Thanks,
Brett
On 14/02/2008, at 5:40 PM, [EMAIL PROTECTED] wrote:
Author: carlos
Date: Wed Feb 13 22:40:35 2008
New Revision: 627675
URL: http://svn.apache.org/viewvc?rev=627675view=rev
Log:
[MNG-3400] MavenProject is not extensible. Merge rev 627670 from
trunk
Modified:
maven/components/branches/maven-2.0.x/maven-project/src/main/java/
org/apache/maven/project/MavenProject.java
maven/components/branches/maven-2.0.x/maven-project/src/test/java/
org/apache/maven/project/MavenProjectTest.java
Modified: maven/components/branches/maven-2.0.x/maven-project/src/
main/java/org/apache/maven/project/MavenProject.java
URL:
http://svn.apache.org/viewvc/maven/components/branches/maven-2.0.x/maven-project/src/main/java/org/apache/maven/project/MavenProject.java?rev=627675r1=627674r2=627675view=diff
=
=
=
=
=
=
=
=
=
=
--- maven/components/branches/maven-2.0.x/maven-project/src/main/
java/org/apache/maven/project/MavenProject.java (original)
+++ maven/components/branches/maven-2.0.x/maven-project/src/main/
java/org/apache/maven/project/MavenProject.java Wed Feb 13 22:40:35
2008
@@ -158,103 +158,107 @@
model.setArtifactId( EMPTY_PROJECT_ARTIFACT_ID );
model.setVersion( EMPTY_PROJECT_VERSION );
-this.model = model;
+this.setModel( model );
}
public MavenProject( Model model )
{
-this.model = model;
+this.setModel( model );
}
+/**
+ * @deprecated use [EMAIL PROTECTED] #clone()}
+ */
public MavenProject( MavenProject project )
{
// disown the parent
// copy fields
-this.file = project.file;
+setFile( project.getFile() );
-// don't need a deep copy, they don't get modified or
added/
removed to/from - but make them unmodifiable to be sure!
-if ( project.dependencyArtifacts != null )
+// don't need a deep copy, they don't get modified or
added/
removed to/from - but make them unmodifiable to be
+// sure!
+if ( project.getDependencyArtifacts() != null )
{
-this.dependencyArtifacts =
Collections.unmodifiableSet( project.dependencyArtifacts );
+
setDependencyArtifacts
( Collections.unmodifiableSet( project.getDependencyArtifacts() ) );
}
-
-if ( project.artifacts != null )
+
+if ( project.getArtifacts() != null )
{
-this.artifacts =
Collections.unmodifiableSet( project.artifacts );
+
setArtifacts
( Collections.unmodifiableSet( project.getArtifacts() ) );
}
-
-if ( project.pluginArtifacts != null )
+
+if ( project.getPluginArtifacts() != null )
{
-this.pluginArtifacts =
Collections.unmodifiableSet( project.pluginArtifacts );
+
setPluginArtifacts
( Collections.unmodifiableSet( project.getPluginArtifacts() ) );
}
-
-if ( project.reportArtifacts != null )
+
+if ( project.getReportArtifacts() != null )
{
-this.reportArtifacts =
Collections.unmodifiableSet( project.reportArtifacts );
-}
-
-if
RE: svn commit: r627675 - in /maven/components/branches/maven-2.0.x/maven-project/src: main/java/org/apache/maven/project/MavenProject.java test/java/org/apache/maven/project/MavenProjectTest.java
It seems curious to me that the archiver needs to understand eclipse.
Isn't this a generic component? Perhaps you should be making
maven-eclipse-archiver or something.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
Sanchez
Sent: Thursday, February 14, 2008 5:41 PM
To: Maven Developers List
Subject: Re: svn commit: r627675 - in
/maven/components/branches/maven-2.0.x/maven-project/src:
main/java/org/apache/maven/project/MavenProject.java
test/java/org/apache/maven/project/MavenProjectTest.java
The archiver is making a copy of the MavenProject using newProject =
new MavenProject(project)
project is a subclass of MavenProject (EclipseMavenProject)
Instead the archiver should do project.clone() if any
Previous to my patch new MavenProject(project) fails with NPE as the
fields are accessed directly. After the patch it works, although I
still think to make copies it should use clone() and that's why I
deprecated the constructor
what @todo are you talking about?
I will fix the clone method.
On Thu, Feb 14, 2008 at 5:17 PM, Brett Porter [EMAIL PROTECTED] wrote:
I'm not sure why the archiver needs to use the delegate? Is it because
you lose track of the updates? IF that's all, then you could follow
the @todo in the class javadoc :)
If it truly needs it, clone is the right method - I'd definitely
recommend reading the section on clone in Effective Java though :)
- Brett
On 15/02/2008, at 11:57 AM, Carlos Sanchez wrote:
Reading carefully the javadoc I see the mistakes i made in clone :(
I
can fix that
The problem arised with a delegate pattern implementation, the
MavenProject instance is encapsulated [1], but the problem comes
with
other classes using this constructor to make copies, which will
ignore
any customizations made in the delegating object (the subclass).
If the way to make a copy where defined in a method ( clone() seems
to
be the right one ) then subclasses could just override that method
and
there wouldnt be any need of getters/setters, but right now that
constructor is used in the maven archiver. Adding the getters and
setters is a patch until the other classes are updated to use
clone()
and to keep backwards compatibility.
[1] http://tinyurl.com/29jzte
On Thu, Feb 14, 2008 at 4:15 PM, Brett Porter [EMAIL PROTECTED]
wrote:
Carlos,
Can you elaborate on the need for this?
I understand that since MavenProject is non-final and so are the
get/
sets they can be overridden and so we should be using the get/set
internally. However, it would seem we don't need that
funcationality
for every field - which particular ones do you see as needing to
be
overridden?
Also, I don't think the clone() stuff is right:
- you've deprecated the copy constructor even though it is still
useful. You also require it's existence which means it shouldn't
be
deprecated.
- clone()'s contract says that it doesn't call any constructors,
making the method work but not as documented by the JDK
- clone() should call super.clone() to get a valid MavenProject
instance
- MavenProject doesn't implement clonable
Why did you need clone()?
Thanks,
Brett
On 14/02/2008, at 5:40 PM, [EMAIL PROTECTED] wrote:
Author: carlos
Date: Wed Feb 13 22:40:35 2008
New Revision: 627675
URL: http://svn.apache.org/viewvc?rev=627675view=rev
Log:
[MNG-3400] MavenProject is not extensible. Merge rev 627670 from
trunk
Modified:
maven/components/branches/maven-2.0.x/maven-project/src/main/java/
org/apache/maven/project/MavenProject.java
maven/components/branches/maven-2.0.x/maven-project/src/test/java/
org/apache/maven/project/MavenProjectTest.java
Modified:
maven/components/branches/maven-2.0.x/maven-project/src/
main/java/org/apache/maven/project/MavenProject.java
URL:
http://svn.apache.org/viewvc/maven/components/branches/maven-2.0.x/maven
-project/src/main/java/org/apache/maven/project/MavenProject.java?rev=62
7675r1=627674r2=627675view=diff
=
=
=
=
=
=
=
=
=
=
--- maven/components/branches/maven-2.0.x/maven-project/src/main/
java/org/apache/maven/project/MavenProject.java (original)
+++ maven/components/branches/maven-2.0.x/maven-project/src/main/
java/org/apache/maven/project/MavenProject.java Wed Feb 13
22:40:35
2008
@@ -158,103 +158,107 @@
model.setArtifactId( EMPTY_PROJECT_ARTIFACT_ID );
model.setVersion( EMPTY_PROJECT_VERSION );
-this.model = model;
+this.setModel( model );
}
public MavenProject( Model model )
{
-this.model = model;
+this.setModel( model );
}
+/**
+ * @deprecated use [EMAIL PROTECTED] #clone()}
+ */
public MavenProject( MavenProject project )
Re: svn commit: r627675 - in /maven/components/branches/maven-2.0.x/maven-project/src: main/java/org/apache/maven/project/MavenProject.java test/java/org/apache/maven/project/MavenProjectTest.java
On 15/02/2008, at 12:41 PM, Carlos Sanchez wrote: The archiver is making a copy of the MavenProject using newProject = new MavenProject(project) project is a subclass of MavenProject (EclipseMavenProject) Instead the archiver should do project.clone() if any I think I was asking the same thing as Jason - I didn't know why the archiver should be creating a new project (and if it was, why it would need to be another instance of the delegate class). what @todo are you talking about? I meant in the other code, but it's not relevant since you aren't doing this for lack of update visibility. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r627675 - in /maven/components/branches/maven-2.0.x/maven-project/src: main/java/org/apache/maven/project/MavenProject.java test/java/org/apache/maven/project/MavenProjectTest.java
The archiver doesnt have to understand eclipse. But it can't create a MavenProject object when the one passed is a subclass that may have customized behavior On Thu, Feb 14, 2008 at 5:42 PM, Brian E. Fox [EMAIL PROTECTED] wrote: It seems curious to me that the archiver needs to understand eclipse. Isn't this a generic component? Perhaps you should be making maven-eclipse-archiver or something. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Thursday, February 14, 2008 5:41 PM To: Maven Developers List Subject: Re: svn commit: r627675 - in /maven/components/branches/maven-2.0.x/maven-project/src: main/java/org/apache/maven/project/MavenProject.java test/java/org/apache/maven/project/MavenProjectTest.java The archiver is making a copy of the MavenProject using newProject = new MavenProject(project) project is a subclass of MavenProject (EclipseMavenProject) Instead the archiver should do project.clone() if any Previous to my patch new MavenProject(project) fails with NPE as the fields are accessed directly. After the patch it works, although I still think to make copies it should use clone() and that's why I deprecated the constructor what @todo are you talking about? I will fix the clone method. On Thu, Feb 14, 2008 at 5:17 PM, Brett Porter [EMAIL PROTECTED] wrote: I'm not sure why the archiver needs to use the delegate? Is it because you lose track of the updates? IF that's all, then you could follow the @todo in the class javadoc :) If it truly needs it, clone is the right method - I'd definitely recommend reading the section on clone in Effective Java though :) - Brett On 15/02/2008, at 11:57 AM, Carlos Sanchez wrote: Reading carefully the javadoc I see the mistakes i made in clone :( I can fix that The problem arised with a delegate pattern implementation, the MavenProject instance is encapsulated [1], but the problem comes with other classes using this constructor to make copies, which will ignore any customizations made in the delegating object (the subclass). If the way to make a copy where defined in a method ( clone() seems to be the right one ) then subclasses could just override that method and there wouldnt be any need of getters/setters, but right now that constructor is used in the maven archiver. Adding the getters and setters is a patch until the other classes are updated to use clone() and to keep backwards compatibility. [1] http://tinyurl.com/29jzte On Thu, Feb 14, 2008 at 4:15 PM, Brett Porter [EMAIL PROTECTED] wrote: Carlos, Can you elaborate on the need for this? I understand that since MavenProject is non-final and so are the get/ sets they can be overridden and so we should be using the get/set internally. However, it would seem we don't need that funcationality for every field - which particular ones do you see as needing to be overridden? Also, I don't think the clone() stuff is right: - you've deprecated the copy constructor even though it is still useful. You also require it's existence which means it shouldn't be deprecated. - clone()'s contract says that it doesn't call any constructors, making the method work but not as documented by the JDK - clone() should call super.clone() to get a valid MavenProject instance - MavenProject doesn't implement clonable Why did you need clone()? Thanks, Brett On 14/02/2008, at 5:40 PM, [EMAIL PROTECTED] wrote: Author: carlos Date: Wed Feb 13 22:40:35 2008 New Revision: 627675 URL: http://svn.apache.org/viewvc?rev=627675view=rev Log: [MNG-3400] MavenProject is not extensible. Merge rev 627670 from trunk Modified: maven/components/branches/maven-2.0.x/maven-project/src/main/java/ org/apache/maven/project/MavenProject.java maven/components/branches/maven-2.0.x/maven-project/src/test/java/ org/apache/maven/project/MavenProjectTest.java Modified: maven/components/branches/maven-2.0.x/maven-project/src/ main/java/org/apache/maven/project/MavenProject.java URL: http://svn.apache.org/viewvc/maven/components/branches/maven-2.0.x/maven -project/src/main/java/org/apache/maven/project/MavenProject.java?rev=62 7675r1=627674r2=627675view=diff = = = = = = = = = = --- maven/components/branches/maven-2.0.x/maven-project/src/main/ java/org/apache/maven/project/MavenProject.java (original) +++ maven/components/branches/maven-2.0.x/maven-project/src/main/ java/org/apache/maven/project/MavenProject.java Wed Feb 13
Re: svn commit: r627675 - in /maven/components/branches/maven-2.0.x/maven-project/src: main/java/org/apache/maven/project/MavenProject.java test/java/org/apache/maven/project/MavenProjectTest.java
I dont know why it is there, but it is, line 314 https://svn.apache.org/viewvc/maven/shared/trunk/maven-archiver/src/main/java/org/apache/maven/archiver/MavenArchiver.java?annotate=627672 emmanuel comment is we have to clone the project instance so we can write out the pom with the deployment version, without impacting the main project instance... On Thu, Feb 14, 2008 at 5:51 PM, Brett Porter [EMAIL PROTECTED] wrote: On 15/02/2008, at 12:41 PM, Carlos Sanchez wrote: The archiver is making a copy of the MavenProject using newProject = new MavenProject(project) project is a subclass of MavenProject (EclipseMavenProject) Instead the archiver should do project.clone() if any I think I was asking the same thing as Jason - I didn't know why the archiver should be creating a new project (and if it was, why it would need to be another instance of the delegate class). what @todo are you talking about? I meant in the other code, but it's not relevant since you aren't doing this for lack of update visibility. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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: svn commit: r627675 - in /maven/components/branches/maven-2.0.x/maven-project/src: main/java/org/apache/maven/project/MavenProject.java test/java/org/apache/maven/project/MavenProjectTest.java
Ok, well in that case you don't need clone, you just needed to flip all the get/set's like you did and continue using the copy constructor. On 15/02/2008, at 12:59 PM, Carlos Sanchez wrote: I dont know why it is there, but it is, line 314 https://svn.apache.org/viewvc/maven/shared/trunk/maven-archiver/src/main/java/org/apache/maven/archiver/MavenArchiver.java?annotate=627672 emmanuel comment is we have to clone the project instance so we can write out the pom with the deployment version, without impacting the main project instance... On Thu, Feb 14, 2008 at 5:51 PM, Brett Porter [EMAIL PROTECTED] wrote: On 15/02/2008, at 12:41 PM, Carlos Sanchez wrote: The archiver is making a copy of the MavenProject using newProject = new MavenProject(project) project is a subclass of MavenProject (EclipseMavenProject) Instead the archiver should do project.clone() if any I think I was asking the same thing as Jason - I didn't know why the archiver should be creating a new project (and if it was, why it would need to be another instance of the delegate class). what @todo are you talking about? I meant in the other code, but it's not relevant since you aren't doing this for lack of update visibility. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r627675 - in /maven/components/branches/maven-2.0.x/maven-project/src: main/java/org/apache/maven/project/MavenProject.java test/java/org/apache/maven/project/MavenProjectTest.java
does this look better? https://svn.apache.org/viewvc/maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/MavenProject.java?r1=627670r2=627932pathrev=627932diff_format=h On Thu, Feb 14, 2008 at 6:11 PM, Brett Porter [EMAIL PROTECTED] wrote: Ok, well in that case you don't need clone, you just needed to flip all the get/set's like you did and continue using the copy constructor. On 15/02/2008, at 12:59 PM, Carlos Sanchez wrote: I dont know why it is there, but it is, line 314 https://svn.apache.org/viewvc/maven/shared/trunk/maven-archiver/src/main/java/org/apache/maven/archiver/MavenArchiver.java?annotate=627672 emmanuel comment is we have to clone the project instance so we can write out the pom with the deployment version, without impacting the main project instance... On Thu, Feb 14, 2008 at 5:51 PM, Brett Porter [EMAIL PROTECTED] wrote: On 15/02/2008, at 12:41 PM, Carlos Sanchez wrote: The archiver is making a copy of the MavenProject using newProject = new MavenProject(project) project is a subclass of MavenProject (EclipseMavenProject) Instead the archiver should do project.clone() if any I think I was asking the same thing as Jason - I didn't know why the archiver should be creating a new project (and if it was, why it would need to be another instance of the delegate class). what @todo are you talking about? I meant in the other code, but it's not relevant since you aren't doing this for lack of update visibility. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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]
[jira] Subscription: Design Best Practices
Issue Subscription Filter: Design Best Practices (29 issues) Subscriber: mavendevlist Key Summary MNG-2184Possible problem with @aggregator and forked lifecycles http://jira.codehaus.org/browse/MNG-2184 MNG-3313NetBeans projects, more than ant project, more than free form project. http://jira.codehaus.org/browse/MNG-3313 MNG-612 implement conflict resolution techniques http://jira.codehaus.org/browse/MNG-612 MNG-2381improved control over the repositories in the POM http://jira.codehaus.org/browse/MNG-2381 MNG-1950Ability to introduce new lifecycles phases http://jira.codehaus.org/browse/MNG-1950 MNG-2584Rebuild on pom change http://jira.codehaus.org/browse/MNG-2584 MNG-139 server definitions should be reusable - review use of repository IDs http://jira.codehaus.org/browse/MNG-139 MNG-2125[doc] when and how to define plugins in a pom http://jira.codehaus.org/browse/MNG-2125 MNG-474 performance improvement for forked lifecycles http://jira.codehaus.org/browse/MNG-474 MNG-1381best practices: testing strategies http://jira.codehaus.org/browse/MNG-1381 MNG-1931add a reportingManagement section http://jira.codehaus.org/browse/MNG-1931 MNG-1563how to write integration tests http://jira.codehaus.org/browse/MNG-1563 MNG-1423best practices: setting up multi-module build http://jira.codehaus.org/browse/MNG-1423 MNG-1867deprecate system scope, analyse other use cases http://jira.codehaus.org/browse/MNG-1867 MNG-1885Uniquely identify modules by module name and version number http://jira.codehaus.org/browse/MNG-1885 MNG-647 Allow Maven 2 to be monitored using JMX. http://jira.codehaus.org/browse/MNG-647 MNG-868 Use uniform format for properties and other tags http://jira.codehaus.org/browse/MNG-868 MNG-1441Starting thinking about a proper distributed repository mechanism a la CPAN http://jira.codehaus.org/browse/MNG-1441 MNG-416 best practices: multiple profile deployments http://jira.codehaus.org/browse/MNG-416 MNG-657 possible chicken and egg problem with extensions http://jira.codehaus.org/browse/MNG-657 MNG-1440Developer Object Model (DOM) http://jira.codehaus.org/browse/MNG-1440 MNG-1439Organization Object Model (OOM) http://jira.codehaus.org/browse/MNG-1439 MNG-1463best practices: plugin inheritance for a multi project build http://jira.codehaus.org/browse/MNG-1463 MNG-367 best practices: multi-user installation http://jira.codehaus.org/browse/MNG-367 MNG-125 guarded mojo execution http://jira.codehaus.org/browse/MNG-125 MNG-1569Make build process info read-only to mojos, and provide mechanism for explicit out-params for mojos to declare http://jira.codehaus.org/browse/MNG-1569 MNG-41 best practices: site management http://jira.codehaus.org/browse/MNG-41 MNG-1425best practices: the location of configuration files vs resources http://jira.codehaus.org/browse/MNG-1425 MNG-1468best practices: version management in multi project builds http://jira.codehaus.org/browse/MNG-1468 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
