Re: [VOTE] Configure IDE plugins to download sources by default within Maven projects
Jochen Wiedmann wrote: On 7/3/07, Mark Hobson <[EMAIL PROTECTED]> wrote: Following the recent thread "Maven POM plugin config", this is a vote to add downloadSources=true to both the eclipse and idea plugin configurations in the maven-parent POM: [ ] +1: I like Javadoc and easy debugging [ ] +0: I'll go with the flow [ ] -1: I like superfluous typing, guessing Javadoc and reading bytecode -1 for both, although I like to have sources and javadocs attached to Eclipse. (Non-binding) Downloading sources (or javadocs) is an excellent thing, if the sources (or the javadocs) are available. Unfortunately this isn't the case in a real lot of cases. As a consequence, running the plugins can get darned slow. For the same reasons I'm -1 on this proposal too (non-binding) -- Reinhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven 2.0.5 (take 2)
Jason van Zyl wrote: Hi, The assemblies that people are interested in are staged here: http://people.apache.org/~jvanzyl/staging-repository/org/apache/maven/maven-core/2.0.5/ Here is the JIRA roadmap: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/order=DESC +1 Cocoon trunk builds fine, here my non-binding +1 -- Reinhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Continuum behind SSL, any progress on this
Graham Leggett wrote:
Hi all,
It seems that http://jira.codehaus.org/browse/CONTINUUM-734 "Can't use
continuum behind https proxy" still hasn't been resolved, which is a
serious oversight.
Looking at the code, is this a continuum problem or a plexus problem?
Has there been any progress on this?
In the case you run behind an Apache 2 webserver, I found a work-around by
rewritting all absolute links:
- install mod_proxy_html and load it within your Apache configuration
- add following lines to your Apache configuration file:
ProxyRequests Off
ProxyPass/ http://localhost:8082/
ProxyPassReverse / http://localhost:8082/
SetOutputFilter proxy-html
ProxyHTMLURLMap http://localhost:8082 https://[your-domain.org]
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
LICENSE and NOTICE in jar artifacts (was: New copyright header policy)
According to the two mails below from [EMAIL PROTECTED], starting with today a PMC isn't allowed to release an artifact if the sources don't cover the new copyright header policy (second mail). Additionally we need to add LICENSE and NOTICE files inside jars too (first mail). Has the maven-jar-plugin been adapted to meet this requirement or is there some simple way to achieve the same result? Reinhard Cliff Schmidt wrote: On Jun 2, 2006, at 6:59 PM, Carlos Sanchez wrote: What would be the policy for jar files that can be distributed individually through the Apache repository? do all of them need to have the LICENSE and NOTICE files inside the jar? Yes -- if they are the result of work created at the ASF (not third-party works, which should just be left as they were found) - o - On 6/2/06, Cliff Schmidt <[EMAIL PROTECTED]> wrote: > During the last ASF Board meeting, a resolution was passed to require > a different licensing header in source files plus requirements for > copyright notices. PMCs are not required to make any changes to past > releases, but must apply these new rules to all distributions > released on or after August 1, 2006. > > Before I send this out to committers@, I thought I'd start by sending > it here to collect and answer any FAQ-type questions. So, here's the > new policy; hit me with any questions you have. > > Thanks, > Cliff > > --- New copyright notice and source header policy --- > > A. THIRD-PARTY COPYRIGHT NOTICES AND LICENSES >0. The term "third-party work" refers to a work not submitted > directly to the ASF by the copyright owner or owner's agent. >1. Do not modify or remove any copyright notices or licenses > within third-party works. >2. Do not add the standard Apache License header to the top of any > third-party source files. >3. Minor modifications/additions to third-party source files > should typically be licensed under the same terms as the rest of the > source for convenience. >4. Major modifications/additions to third-party should be dealt > with on a case-by-case basis by the PMC. > > B. SOURCE FILE HEADERS >0. This section refers only to works submitted directly to the ASF > by the copyright owner or owner's agent. >1. If the source file is submitted with a copyright notice > included in it, the copyright owner (or owner's agent) must either: > a. remove such notices, or > b. move them to the NOTICE file associated with each applicable > project release, or > c. provide written permission for the ASF to make such removal > or relocation of the notices. >2. Each source file should include the following license header -- > note that there should be no copyright notice in the header: > > Licensed to the Apache Software Foundation (ASF) under one > or more contributor license agreements. See the NOTICE file > distributed with this work for additional information > regarding copyright ownership. The ASF licenses this file > to you under the Apache License, Version 2.0 (the > "License"); you may not use this file except in compliance > with the License. You may obtain a copy of the License at > > http://www.apache.org/licenses/LICENSE-2.0 > > Unless required by applicable law or agreed to in writing, > software distributed under the License is distributed on an > "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY > KIND, either express or implied. See the License for the > specific language governing permissions and limitations > under the License. > > C. NOTICE FILE >0. Every Apache distribution should include a NOTICE file in the > top directory, along with the standard LICENSE file >1. The top of each NOTICE file should include the following text, > suitably modified to reflect the product name and year(s) of > distribution of the current and past versions of the product: > >Apache [PRODUCT_NAME] >Copyright [] The Apache Software Foundation > >This product includes software developed at >The Apache Software Foundation (http://www.apache.org/). > >2. The remainder of the NOTICE file is to be used for required > third-party notices. The NOTICE file may also include copyright > notices moved from source files submitted to the ASF (see B.1.). ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-eclipse-plugin and Eclipse Plugin support
Rinku wrote:
So far I added the configuration parameter "pde". If set to true, the
PluginNature and the schema and manifest builders are added to .project.
I have a patch submitted for this for the maven-eclipse-plugin. Though
not sure when that gets integrated into the plugin. IMHO you would not
need a separate config param but just detect the natures being specified
in the config and that should set up PDE project definition.
My idea was consistency with the WTP configuration parameter, less typing and
I'm sure that I will never remember the class name of the nature ;-)
Additionally, instead of pointing to libraries in the local
repository, I copy them to "target/osgi/lib" and point to them from
within .classpath - unfortunatly PDE doesn't allow referencing
libraries outside of the project (as you describe in 3).
Yep, I noticed that too. Just curious why do want to copy them to the
target/osgi/lib and then reference them from there. Why not copy them
under the PDE project/osgi/lib directory (and may be add that folder to
ignore list in for CVS/SVN).
My initial idea was that a "mvn clean" should remove them. But I'm not sure
about this.
I think you will need to update both
.classpath and Manifest.mf (see 3) for the libs.
Yes, the cocoon-maven-eclipse-plugin already does so.
Before I will provide a patch, I will implement what you describe in
2). I was thinking of keeping "Bundle-ClassPath" in sync with the
libraries in "target/osgi/lib".
You can also look under Apache Felix sources, they have a maven osgi
plugin implemented, may be you can draw some ideas from there as well.
Thanks for the pointer!
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-eclipse-plugin and Eclipse Plugin support
Rinku wrote:
Hi,
Not sure if there is some work in progress for Eclipse Plugin support
but here are some quick notes on the following logged in JIRA
http://jira.codehaus.org/browse/MECLIPSE-92
http://jira.codehaus.org/browse/MECLIPSE-103
1) Running eclipse:eclipse should generate the project definition just
as it does now, it detects if a "org.eclipse.pde.PluginNature" is
specified for .project and setups the PDE nature (updates to .classpath)
accordingly.
2) A Bundle Manifest writer could write out the Bundle Manifest. We
could default some of the headers to 'sensible' default values
(extracted from pom.xml), and allow for user to specify them via
configuration for the Eclipse plugin.
3) Plugin dependencies could be copied from the local M2 repo to under
/lib and Manifest updated for Bundle-Classpath values.
I thought I'd rake up a discussion :-)
As Cocoon 3.0 will be based on OSGi I need PDE support too. For the time being I
started with a branch of the maven-eclipse-plugin within the Cocoon SVN tree
(see
http://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-maven-eclipse-plugin/).
The goal is providing a patch for the "offical" maven eclipse plugin within the
next weeks.
So far I added the configuration parameter "pde". If set to true, the
PluginNature and the schema and manifest builders are added to .project.
Additionally, instead of pointing to libraries in the local repository, I copy
them to "target/osgi/lib" and point to them from within .classpath -
unfortunatly PDE doesn't allow referencing libraries outside of the project (as
you describe in 3).
Before I will provide a patch, I will implement what you describe in 2). I was
thinking of keeping "Bundle-ClassPath" in sync with the libraries in
"target/osgi/lib".
What do you think?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Debugging Maven with Eclipse?
Geoffrey De Smet wrote:
I created a "mvnd" script and there is an issue for it.
After that it's just a matter of creating a remote debugger in eclipse.
Would you mind sharing the issue link with us?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MECLIPSE-71) eclipse:clean delets too much
[ http://jira.codehaus.org/browse/MECLIPSE-71?page=comments#action_60229 ] Reinhard Poetz commented on MECLIPSE-71: Are there any implications if I don't run "eclipse:clean" before I run "eclipse:eclipse"? Is it possible that the plugin creates some inconsistent Eclipse settings files? If no, I agree with you that deleting isn't necessary. (Although Maven delets a file that it doesn't generate *completly* --> org.eclipse.jdt.core.prefs) I'd propose following cleaning procedure: - eclipse:clean delets all files it generates/manipulates - if after deleting these files, something is left (e.g. .svn directory) the .settings directory is _not_ deleted - if .settings is empty, the .settings directory is deleted too. WDYT? > eclipse:clean delets too much > - > > Key: MECLIPSE-71 > URL: http://jira.codehaus.org/browse/MECLIPSE-71 > Project: Maven 2.x Eclipse Plugin > Type: Bug > Versions: 2.1 > Reporter: Reinhard Poetz > > > If I call eclipse:clean, the complete ".settings" directory is deleted. In my > projects we share some Eclipse settings in our team by adding the .settings > directory to SVN. > This behaviour is unpractical for us as SVN gets confused by the missing > ./settings/.svn directory. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MECLIPSE-71) eclipse:clean delets too much
[ http://jira.codehaus.org/browse/MECLIPSE-71?page=comments#action_59893 ] Reinhard Poetz commented on MECLIPSE-71: ok, this makes it even easier :-) AFAICS, the SettingsWriter writes to org.eclipse.jdt.core.prefs. It doesn't generate the complete file, but reads out the already set parameters and overrides the "o.e.j.c.c.compliance", "o.e.j.c.c.source" and "o.e.j.c.c.target" properties. The question now is: Should we delete the file or not? In my projects, org.eclipse.jdt.core.prefs is shared via SVN (e.g. to set project specific code styles) and deleting it is problematic and I don't think necessary. IIUC, the only file within the .settings directory that should get deleted with eclipse:clean is ".settings/.component", which is generated by the EclipseWtpComponentWriter. I could provide a patch if you want. WDYT? > eclipse:clean delets too much > - > > Key: MECLIPSE-71 > URL: http://jira.codehaus.org/browse/MECLIPSE-71 > Project: Maven 2.x Eclipse Plugin > Type: Bug > Versions: 2.1 > Reporter: Reinhard Poetz > > > If I call eclipse:clean, the complete ".settings" directory is deleted. In my > projects we share some Eclipse settings in our team by adding the .settings > directory to SVN. > This behaviour is unpractical for us as SVN gets confused by the missing > ./settings/.svn directory. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[MECLIPSE] eclipse:clean delets too much
If I call eclipse:clean, the complete ".settings" directory is deleted. In some
of my projects we share some Eclipse settings in our team by adding the
.settings directory to SVN.
The behaviour of deleting the comlete .settings directory is unpractical for us
as SVN gets confused by the missing ./settings/.svn directory.
My idea was adding a configuration parameter, that makes it possible to add
paths that are excluded from deletion.
I've created an issue in Jira: http://jira.codehaus.org/browse/MECLIPSE-71
WDYT?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MECLIPSE-71) eclipse:clean delets too much
[ http://jira.codehaus.org/browse/MECLIPSE-71?page=comments#action_59810 ] Reinhard Poetz commented on MECLIPSE-71: My idea was adding a configuration parameter, that makes it possible to add paths that are excluded from deletion. WDYT? > eclipse:clean delets too much > - > > Key: MECLIPSE-71 > URL: http://jira.codehaus.org/browse/MECLIPSE-71 > Project: Maven 2.x Eclipse Plugin > Type: Bug > Versions: 2.1 > Reporter: Reinhard Poetz > > > If I call eclipse:clean, the complete ".settings" directory is deleted. In my > projects we share some Eclipse settings in our team by adding the .settings > directory to SVN. > This behaviour is unpractical for us as SVN gets confused by the missing > ./settings/.svn directory. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MECLIPSE-71) eclipse:clean delets too much
eclipse:clean delets too much - Key: MECLIPSE-71 URL: http://jira.codehaus.org/browse/MECLIPSE-71 Project: Maven 2.x Eclipse Plugin Type: Bug Versions: 2.1 Reporter: Reinhard Poetz If I call eclipse:clean, the complete ".settings" directory is deleted. In my projects we share some Eclipse settings in our team by adding the .settings directory to SVN. This behaviour is unpractical for us as SVN gets confused by the missing ./settings/.svn directory. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[MECLIPSE] Duplicate entries in .classpath and .project
I have a pom.xml, which declares following dependencies:
com.mycompany
app-framework
1.0-SNAPSHOT
jar
com.mycompany
app-framework
1.0-SNAPSHOT
test-jar
test
This creates an invalid .project for Eclipse as the artifactId is used as
project name. As the artifactId is not a unique identifier, following XML is
created:
webapp
app-framework
app-framework
This, of course, leads to an error in Eclipse.
Additionally, .classpath also contains duplicate entries in this case.
I've createda an entry in JIRA (http://jira.codehaus.org/browse/MECLIPSE-70)
that also contains a patch that fixes both problems.
I would be glad, if somebody could review it :-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Setting parameters doesn't work with 2.0.3
Well, the Eclipse plugin was up-to-date. Today I wasn't able to reproduce the
problem again :-/
Unfortunalty there have been some changes in our pom.xml files since last week.
If I can reproduce the problem again, I'll let you know.
Reinhard
Kenney Westerhof wrote:
On Fri, 24 Feb 2006, Reinhard Poetz wrote:
We'll have to look into that, but you're using a very old eclipse
plugin, since the downloadSources is false by default.
-- Kenney
John Casey wrote:
If you're interested, you can take the current release candidate for a
test drive. The RC tarball is at:
http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060222.031501.tar.gz
As I had some problems with Maven 2.0.2 I tried to use this RC. Unfortunatly
it's not possible to set configuration parameters anymore. I tried to call
mvn eclipse:eclipse -Declipse.downloadSources=false
which still leads to downloads. Printing the value of downloadSource from within
the execute() method to the console shows, that the value is always 'true'.
Switching back to 2.0.2 made the parameter setting work again.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MECLIPSE-70) Duplicate entries in .project (/projectDescription/projects/project)
[ http://jira.codehaus.org/browse/MECLIPSE-70?page=all ] Reinhard Poetz updated MECLIPSE-70: --- Attachment: patch_removeDuplicateEntries.diff > Duplicate entries in .project (/projectDescription/projects/project) > > > Key: MECLIPSE-70 > URL: http://jira.codehaus.org/browse/MECLIPSE-70 > Project: Maven 2.x Eclipse Plugin > Type: Bug > Versions: 2.0, 2.2, 2.1 > Reporter: Reinhard Poetz > Attachments: patch_removeDuplicateEntries.diff, > patch_removeDuplicateEntries.diff > > > If a pom.xml has following dependencies > > com.mycompany > app-framework > 1.0-SNAPSHOT > jar > > > com.mycompany > app-framework > 1.0-SNAPSHOT > test-jar > test > > the plugin creates an invalid .project for Eclipse as the artifactId is used > as project name. As the artifactId is not a unique identifier, following is > created: > > webapp > > > app-framework > app-framework > > > This, of course, leads to an error in Eclipse -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Setting parameters doesn't work with 2.0.3 (was: [vote] Release Maven 2.0.3)
John Casey wrote:
If you're interested, you can take the current release candidate for a
test drive. The RC tarball is at:
http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060222.031501.tar.gz
As I had some problems with Maven 2.0.2 I tried to use this RC. Unfortunatly
it's not possible to set configuration parameters anymore. I tried to call
mvn eclipse:eclipse -Declipse.downloadSources=false
which still leads to downloads. Printing the value of downloadSource from within
the execute() method to the console shows, that the value is always 'true'.
Switching back to 2.0.2 made the parameter setting work again.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MECLIPSE-70) Duplicate entries in .project (/projectDescription/projects/project)
[ http://jira.codehaus.org/browse/MECLIPSE-70?page=all ] Reinhard Poetz updated MECLIPSE-70: --- Attachment: patch_removeDuplicateEntries.diff > Duplicate entries in .project (/projectDescription/projects/project) > > > Key: MECLIPSE-70 > URL: http://jira.codehaus.org/browse/MECLIPSE-70 > Project: Maven 2.x Eclipse Plugin > Type: Bug > Versions: 2.2, 2.0, 2.1 > Reporter: Reinhard Poetz > Attachments: patch_removeDuplicateEntries.diff > > > If a pom.xml has following dependencies > > com.mycompany > app-framework > 1.0-SNAPSHOT > jar > > > com.mycompany > app-framework > 1.0-SNAPSHOT > test-jar > test > > the plugin creates an invalid .project for Eclipse as the artifactId is used > as project name. As the artifactId is not a unique identifier, following is > created: > > webapp > > > app-framework > app-framework > > > This, of course, leads to an error in Eclipse -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MECLIPSE-70) Duplicate entries in .project (/projectDescription/projects/project)
Duplicate entries in .project (/projectDescription/projects/project) Key: MECLIPSE-70 URL: http://jira.codehaus.org/browse/MECLIPSE-70 Project: Maven 2.x Eclipse Plugin Type: Bug Versions: 2.2, 2.0, 2.1 Reporter: Reinhard Poetz If a pom.xml has following dependencies com.mycompany app-framework 1.0-SNAPSHOT jar com.mycompany app-framework 1.0-SNAPSHOT test-jar test the plugin creates an invalid .project for Eclipse as the artifactId is used as project name. As the artifactId is not a unique identifier, following is created: webapp app-framework app-framework This, of course, leads to an error in Eclipse -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
