Re: Programmatically adding dependencies to a MavenProject

[Richard van Nieuwenhoven]

Hi,

i also had this problem, and yes Jason is right don't do it! You will 
have all sorts of follow up problems (like some other plugins not 
working). It will work for the normal stuff, but be sure to start your 
plugin in the validate phase.


Now i use a custom repository layout / repository to enable me to add 
maven dependencies to those jars (that works also with maven 3 and all 
other plugins keep working ;-).  But you could also try Tycho.


http://docs.codehaus.org/display/M2ECLIPSE/Tycho+project+overview

I am thinking of creating a sourceforge project for the repository 
layout, if there people willing to help (like adding your needed feature 
of embedded jars).


regards,
Richard van Nieuwenhoven


Costin Caraivan wrote:


Jason van Zyl-5 wrote:
This is a bad idea and don't count on Maven 3.x supporting this  
because it makes determining what the dependencies are black magic.  
The dependency tree and visualization tools won't work. In Maven 3.x  
we are likely to make the dependency set immutable post resolution  
phase.


I don't feel there is any valid use case for programatically adding  
dependencies and if someone finds one then something is wrong with  
Maven itself.




Use case: Eclipse bundles. They can be simple jars or jars containing jars.
Any other ideas for getting the classes inside those inner jars visible for
the compiler?
eclipse.jar contains whatever.jar. whatever.jar contains classes. I want to
compile myjar.jar using the classes in whatever.jar. I do not want (for ease
of use, this is a request) to manually add the inside dependencies, I just
want to add eclipse.jar (like Eclipse itself does during plugin
development).

I think this is a legitimate use case, *so*, for my use case, could anyone
please point out what I'm doing wrong?



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: rcp builds with maven (trying to write a Eclipse-ArtifactRepositoryLayout )

[Richard van Nieuwenhoven]

Hi,

Tycho sound good, but misses the target for our specific project (the 
story is to full of details to explain it here).


The only working solution i found (including maven 3-alpha-1) is to
extend m2.conf to:
--
[plexus.core]
load ${maven.home}/extentions/*.jar
load ${maven.home}/lib/*.jar
--
Then put the component-jars in the newly created directory "extentions".
now maven picks them up and i can use my eclipse plugins as 
dependencies, transparently in maven. Also no need to add the extensions 
tag to the pom.


I tested this solution with maven 2.0.9 and 3-alpha-1 and both worked 
correctly.


I would prefer a solution just involving the project pom, but this is ok 
too because it only triggers when i use the repository layout "eclipse".


When there are others needing such a possibility, e-mail me! Maybe i can 
convince my customer to give it free.


regards,
Ritchie


Igor Fedorenko wrote:

Richard,

I wonder if you have seen Tycho [1]? This is one of the projects I work 
on, so I am biased ;-) but I believe it should address your problem, 
i.e. building eclipse rcp application with maven.



[1] http://docs.codehaus.org/display/M2ECLIPSE/Tycho+project+overview

--
Regards,
Igor

Richard van Nieuwenhoven wrote:

Hi,

i am having troubles activating a plexus ArtifactRepositoryLayout 
component from a pom. I tried the notation:


 
xxx
xxx
xxx
  

but it didn't pick up the component.

The reason of doning this is that after bending maven builds to create 
eclipse rcp applications for a long time, i want to try a different 
approach. By creating a plexus "ArtifactRepositoryLayout" that 
understands a eclipse installation, that works out pretty well!


We have a complete eclipse-rcp tgz/zip in the repository and extract 
it on demand during the build. the Eclipse-ArtifactRepositoryLayout 
takes up this directory structure and points the dependency:




eclipse-local
eclipse
file:/.../org.eclipse.rcp.target-eclipse.3.4.1.0/eclipse




org.eclipse.rcp
org.eclipse.swt
3.4.1.0


to "plugins/org.eclipse.swt_3.4.1.v3449c.jar" and generates a 
(temporary) pom for this dependency from the manifest of the 
eclipse-plugin.


So far so good.. my problem is that i have to copy the plexus 
component with the Eclipse-ArtifactRepositoryLayout in to the 
maven2/lib directory to activate it, is there any way to activate it 
from inside the pom?


Thanks for any help,
Richard van Nieuwenhoven

My prerequisites (and the solution satisfies them so far):
- use only eclipse plugins that are contained in the same stable version.
- We do not want to "pollute" the repository with all the versions 
from eclipse plugins and features.
- We so not want to know the correct version of plugin 
org.eclipse..xxx. we just want the version bundled with eclipse 
version "3.4.1" for example.



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

rcp builds with maven (trying to write a Eclipse-ArtifactRepositoryLayout )

[Richard van Nieuwenhoven]

Hi,

i am having troubles activating a plexus ArtifactRepositoryLayout 
component from a pom. I tried the notation:


 
xxx
xxx
xxx
  

but it didn't pick up the component.

The reason of doning this is that after bending maven builds to create 
eclipse rcp applications for a long time, i want to try a different 
approach. By creating a plexus "ArtifactRepositoryLayout" that 
understands a eclipse installation, that works out pretty well!


We have a complete eclipse-rcp tgz/zip in the repository and extract it 
on demand during the build. the Eclipse-ArtifactRepositoryLayout takes 
up this directory structure and points the dependency:




eclipse-local
eclipse
file:/.../org.eclipse.rcp.target-eclipse.3.4.1.0/eclipse




org.eclipse.rcp
org.eclipse.swt
3.4.1.0


to "plugins/org.eclipse.swt_3.4.1.v3449c.jar" and generates a 
(temporary) pom for this dependency from the manifest of the eclipse-plugin.


So far so good.. my problem is that i have to copy the plexus component 
with the Eclipse-ArtifactRepositoryLayout in to the maven2/lib directory 
to activate it, is there any way to activate it from inside the pom?


Thanks for any help,
Richard van Nieuwenhoven

My prerequisites (and the solution satisfies them so far):
- use only eclipse plugins that are contained in the same stable version.
- We do not want to "pollute" the repository with all the versions from 
eclipse plugins and features.
- We so not want to know the correct version of plugin 
org.eclipse..xxx. we just want the version bundled with eclipse 
version "3.4.1" for example.



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: a way to extend the dependencies at build time

[Richard van Nieuwenhoven]

Hi,

That is why i ask for an "official" solution, a plugin will probably not
work. But is there an other? like a custom "dependence resolution
component" for this project. Or a global custom "dependence resolution
component". Or a way to dynamically create a global or local profile.

Or .. any ideas?

thanks for the help,
Ritchie

Gilles Scokart wrote:
> On 24/04/2008, Richard van Nieuwenhoven <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>>  the reason i need it is that a plugin generates code that depends on a
>>  framework in a specific configuration. And the knowledge witch
>>  combination of frameworks is needed, is provided by the generator (the
>>  plugin). I do not like to duplicate this knowledge in evey module that
>>  uses the plugin, this is why i would like the plugin (or some other
>>  mean) to include the dependencies in the ProjectModel.
>>
>>  The IDE integration should be no problem because the included
>>  dependencies would (and must) be included in the ProjectModel and
>>  therefore are propagated to all running plugins as if they were in the
>>  pom directly.
>>
>>  mfg
>>  Ritchie
>>
> Only if the plugin is executed.  IDE (or other tools like Ivy for
> instance) don't run the plugins to use the dependency informations.
> 
> Also think to what you will publish to a repository.  The projects
> that depends on the project using the plugin will not execute your
> plugin neither.
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: a way to extend the dependencies at build time

[Richard van Nieuwenhoven]

Hi,

the reason i need it is that a plugin generates code that depends on a
framework in a specific configuration. And the knowledge witch
combination of frameworks is needed, is provided by the generator (the
plugin). I do not like to duplicate this knowledge in evey module that
uses the plugin, this is why i would like the plugin (or some other
mean) to include the dependencies in the ProjectModel.

The IDE integration should be no problem because the included
dependencies would (and must) be included in the ProjectModel and
therefore are propagated to all running plugins as if they were in the
pom directly.

mfg
Ritchie

Milos Kleint wrote:
> I discourage any dynamic tweaking of the project. Among other things
> is breaks IDE integration. appfuse' warpath plugin does this sort of
> thing somehow. I would say it's a hack however and might not work in
> future versions..
> 
> Milos
> 
> On Thu, Apr 24, 2008 at 9:33 AM, Richard van Nieuwenhoven <[EMAIL PROTECTED]> 
> wrote:
>> Hi,
>>
>>  i have a strange requirement, i need a possibility to extend the
>>  dependencies of a MavenProject in a plugin or component during build
>>  time. I tried adding dependencies in a validation phase plugin, with no
>>  success.
>>
>>  Is there a "official" way to do this? Maybe a dynamic profile? Defaults
>>  injector?
>>
>>  (The built stability is guarantied because the plugin or component will
>>  produce alway the same dependencies for a project configuration).
>>
>>  thanks for any ideas!
>>  Ritchie
>>
>>  -
>>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>>  For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

a way to extend the dependencies at build time

[Richard van Nieuwenhoven]

Hi,

i have a strange requirement, i need a possibility to extend the
dependencies of a MavenProject in a plugin or component during build
time. I tried adding dependencies in a validation phase plugin, with no
success.

Is there a "official" way to do this? Maybe a dynamic profile? Defaults
injector?

(The built stability is guarantied because the plugin or component will
produce alway the same dependencies for a project configuration).

thanks for any ideas!
Ritchie

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release Maven Eclipse plugin version 2.5.1

[Richard van Nieuwenhoven]

Hi,

the requireMavenVersion also applies to the runtime, but 2.0.8 is just
required for the testing during the build. As far as i know not for the
runtime. We use the plugin in a lot of projects that are locked to maven
2.0.7.

So please limit it only for the build time.

regards,
Ritchie



Jerome Lacoste wrote:
> On Wed, Apr 2, 2008 at 11:13 AM, Arnaud HERITIER <[EMAIL PROTECTED]> wrote:
>> Hi Jerome,
>>
>>   As you noticed, this plugin requires to be build with maven >= 2.0.8
>>  because of some tests with encodings.
>>   I'll add an enforcer rule as Benjamin proposed.
> 
> I had added a patch to the issue  hat uses the inbbuild POM
> requireMavenVersion instead of using the enforcer plugin. That worked
> for me.
> 
> Cheers,
> 
> Jerome
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release Maven Eclipse plugin version 2.5.1

[Richard van Nieuwenhoven]

Hi,

just created the JIRA http://jira.codehaus.org/browse/MECLIPSE-415 and
attached the patch. This problem seems to be connected to the wrongly
used executedProject parameter and maven 2.0.9.

The stage thing is that "testProject11" fails when i remove the usage of
the executedProject.

Also i am in favour to delete the code in the validate method of the
EclipsePlugin that allows to use an other directory for the settings as
the base directory. This code can only work for very very simple
projects, so we should just delete it. And make the eclipseProjectDir =
eclipse.projectDir readonly and set it to ${basedir}

Ritchie

Arnaud HERITIER wrote:
> Ok. Thx a lot. I'll fix it with the executedProject the next week.
> 
> Arnaud
> 
> On Fri, Mar 28, 2008 at 12:16 PM, Richard van Nieuwenhoven <[EMAIL 
> PROTECTED]> wrote:
>> hmmm, that seems to be a relict of the old usage of the workspace
>>  variable usage (that Arnaud removed). Later today i will create an jira
>>  issue and a patch. (this should not be hard to find).
>>
>>  Ritchie
>>
>>
>>
>>  nicolas de loof wrote:
>>  > Also had this issue since 2.5-SNAPSHOTs, but never took the time to report
>>  > in Jira :-/
>>  >
>>  > Setting eclipse.projectDir=${basedir} in the POM eclipse-plugin
>>  > configuration solves this, but this is only a workaround.
>>  >
>>  > Nicolas.
>>  >
>>  > 2008/3/28, Arnaud HERITIER <[EMAIL PROTECTED]>:
>>  >> Hi all,
>>  >>
>>  >>   I just discovered a bug, or an hidden feature in 2.5 :-)
>>  >>   Richard, I think it is related to MECLIPSE-344.
>>  >>
>>  >>   I store my projects in a directory which isn't my eclipse workspace.
>>  >>   If I define the workspace attribute to be able to read its settings,
>>  >> when I call eclipse:eclipse, my projects settings are written in the
>>  >> workspace and not in each project's directory.
>>  >>   Is it what you expected ?
>>  >>
>>  >> Arnaud
>>  >>
>>  >> N.B. : I will not be able to publish a new version before my departure
>>  >> this evening, thus I'll prepare a 1.5.2 just after this one if we
>>  >> decide that we have to fix the plugin (what I'm thinking)
>>  >>
>>  >>
>>  >>
>>  >> On Fri, Mar 28, 2008 at 10:09 AM, nicolas de loof <[EMAIL PROTECTED]>
>>  >> wrote:
>>  >>> I've got an issue with eclipse plugin 2.5 & 2.5.1 combined with latest
>>  >> maven
>>  >>>  2.0.9 RC4 :
>>  >>>
>>  >>>  I've set a custom profile in my corporate POM to setup eclipse. It runs
>>  >> the
>>  >>>  validate phase and attach eclipse:eclipse plugin goal to this phase.
>>  >> Using
>>  >>>  this, a fresh SVN checkout can configure eclipse by running "mvn
>>  >> -Psetup"
>>  >>> 
>>  >>>   setup
>>  >>>   
>>  >>> validate
>>  >>> 
>>  >>> 
>>  >>> maven-eclipse-plugin
>>  >>> 
>>  >>> 
>>  >>> setup
>>  >>> 
>>  >>> eclipse
>>  >>> 
>>  >>> validate
>>  >>> 
>>  >>> 
>>  >>> 
>>  >>>
>>  >>>  I get this error :
>>  >>>
>>  >>>  [INFO]
>>  >>>  
>> --------
>>  >>>  [ERROR] BUILD ERROR
>>  >>>  [INFO]
>>  >>>  
>> 
>>  >>>  [INFO] There must be a POM in the current working directory for the
>>  >> Eclipse
>>  >>>  plugin to work.
>>  >>>  [INFO]
>>  >>>  
>> 
>>  >>>
>>  >>>  The EclispePlugin.validate() method fails on
>>  >>>
>>  >>>if ( executedProject.getFile() == null ||
>>  >>>  !executedProject.getFile().exists() ) ...
>>  >>>
>>  >>>  What is the distinc

Re: [VOTE] Release Maven Eclipse plugin version 2.5.1

[Richard van Nieuwenhoven]

hmmm, that seems to be a relict of the old usage of the workspace
variable usage (that Arnaud removed). Later today i will create an jira
issue and a patch. (this should not be hard to find).

Ritchie

nicolas de loof wrote:
> Also had this issue since 2.5-SNAPSHOTs, but never took the time to report
> in Jira :-/
> 
> Setting eclipse.projectDir=${basedir} in the POM eclipse-plugin
> configuration solves this, but this is only a workaround.
> 
> Nicolas.
> 
> 2008/3/28, Arnaud HERITIER <[EMAIL PROTECTED]>:
>> Hi all,
>>
>>   I just discovered a bug, or an hidden feature in 2.5 :-)
>>   Richard, I think it is related to MECLIPSE-344.
>>
>>   I store my projects in a directory which isn't my eclipse workspace.
>>   If I define the workspace attribute to be able to read its settings,
>> when I call eclipse:eclipse, my projects settings are written in the
>> workspace and not in each project's directory.
>>   Is it what you expected ?
>>
>> Arnaud
>>
>> N.B. : I will not be able to publish a new version before my departure
>> this evening, thus I'll prepare a 1.5.2 just after this one if we
>> decide that we have to fix the plugin (what I'm thinking)
>>
>>
>>
>> On Fri, Mar 28, 2008 at 10:09 AM, nicolas de loof <[EMAIL PROTECTED]>
>> wrote:
>>> I've got an issue with eclipse plugin 2.5 & 2.5.1 combined with latest
>> maven
>>>  2.0.9 RC4 :
>>>
>>>  I've set a custom profile in my corporate POM to setup eclipse. It runs
>> the
>>>  validate phase and attach eclipse:eclipse plugin goal to this phase.
>> Using
>>>  this, a fresh SVN checkout can configure eclipse by running "mvn
>> -Psetup"
>>> 
>>>   setup
>>>   
>>> validate
>>> 
>>> 
>>> maven-eclipse-plugin
>>> 
>>> 
>>> setup
>>> 
>>> eclipse
>>> 
>>> validate
>>> 
>>> 
>>> 
>>>
>>>  I get this error :
>>>
>>>  [INFO]
>>>  
>>>  [ERROR] BUILD ERROR
>>>  [INFO]
>>>  
>>>  [INFO] There must be a POM in the current working directory for the
>> Eclipse
>>>  plugin to work.
>>>  [INFO]
>>>  --------
>>>
>>>  The EclispePlugin.validate() method fails on
>>>
>>>if ( executedProject.getFile() == null ||
>>>  !executedProject.getFile().exists() ) ...
>>>
>>>  What is the distinction between "executedProject" and "project" from a
>>>  plugin point of view ?
>>>  This seem to have changed in maven 2.0.9.
>>>
>>>  My use case is not really standard, but this may suggest some
>> regression
>>>  either in maven 2.0.9 or the eclipse plugin.
>>>
>>>  Nicolas
>>>
>>>
>>>  2008/3/28, Richard van Nieuwenhoven <[EMAIL PROTECTED]>:
>>>
>>>
>>>  > Hi,
>>>  >
>>>  > here is my +1
>>>  >
>>>  > Thanks for the fast release!
>>>  >
>>>  > Ritchie
>>>  >
>>>  > Arnaud HERITIER wrote:
>>>  > > Hi,
>>>  > >
>>>  > >   Since the 2.5 release we did 10 days ago, we solved 3 annoying
>> issues:
>>>  > > * [MECLIPSE-266] - plugin applies java facet to ear project
>>>  > > * [MECLIPSE-411] - manifest property usage is only for ogsi
>> maifests
>>>  > > * [MECLIPSE-413] - EclipseOSGiManifestWriter uses the artifact
>> id
>>>  > > and not the EclipseProjectName
>>>  > >   We also added a new feature :
>>>  > > * [MECLIPSE-405] - to-maven target should allow to strip
>> qualifier
>>>  > > when creating artifacts from osgi bundles
>>>  > >
>>>  > > There are still a lot of issues left in JIRA :
>>>  > >
>>>  >
>> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11133&status=1
>>&

Re: [VOTE] Release Maven Eclipse plugin version 2.5.1

[Richard van Nieuwenhoven]

Hi,

here is my +1

Thanks for the fast release!

Ritchie

Arnaud HERITIER wrote:
> Hi,
> 
>   Since the 2.5 release we did 10 days ago, we solved 3 annoying issues:
> * [MECLIPSE-266] - plugin applies java facet to ear project
> * [MECLIPSE-411] - manifest property usage is only for ogsi maifests
> * [MECLIPSE-413] - EclipseOSGiManifestWriter uses the artifact id
> and not the EclipseProjectName
>   We also added a new feature :
> * [MECLIPSE-405] - to-maven target should allow to strip qualifier
> when creating artifacts from osgi bundles
> 
> There are still a lot of issues left in JIRA :
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11133&status=1
> 
> Staging repo :
> http://people.apache.org/~aheritier/stage/repo/
> 
> Staging site (I'm uploading it) :
> http://maven.apache.org/plugins/maven-eclipse-plugin-2.5.1/
> 
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 5 days. I'll be back on wednesday to do the release if
> the vote passes.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: maven-eclipse-plugin problems with jee5 ears coming

[Richard van Nieuwenhoven]

Hi,

i also agree with Arnaud that this would be great but i think it is
almost not do-able. I tried for example to use the plexus manifest
generator (= service reuse) but failed because the dependencies are not
yet resolved (or something simulator) when the eclipse plugin starts.

Now to the difficulty: the plexus manifest generator will get a LOT more
difficult when it is required to function in the phase the eclipse
plugin is running, is that what we want? i do not think so. the plexus
manifest generator should remain as simple as it is (dependent on a
specific phase, and dependencies available in a specific "packaged" format).

note: the plexus manifest generator is just an example!

regards,
Ritchie

Siarhei Dudzin wrote:
> Richard,
> 
> I've noticed the plugin does invoke
> ear:generate-application-xml<http://maven.apache.org/plugins/maven-ear-plugin/generate-application-xml-mojo.html>goal
> - may be the lifecycle isn't a problem here?
> 
> I agree with Arnaud, that way we could keep up with plugins and be more
> consistent.
> 
> Siarhei
> 
> On Thu, Mar 20, 2008 at 10:48 AM, Arnaud HERITIER <[EMAIL PROTECTED]>
> wrote:
> 
>> We could also think to extract some part of ear/war/... plugins to
>> reuse some services throught a shared library
>>
>> Arnaud
>>
>> On Thu, Mar 20, 2008 at 9:03 AM, Richard van Nieuwenhoven
>> <[EMAIL PROTECTED]> wrote:
>>> Hi,
>>>
>>>  The problem here is the phase in the life cycle.. The best thing would
>>>  be to use the generated application.xml from the ear plugin but thats
>>>  generated very late in the packaging phase. The eclipse plugin runs in
>> a
>>>  very early phase to be able to generate eclipse config files also for
>>>  broken projects... It is even very difficult to generate the
>> application
>>>  .xml because any of the dependent artifacts can and will not be
>>>  available in a packaged version (the information source of the
>>>  maven-ear-plugin). This means till the time we find a solution to that
>>>  problem, the only chance is to simulate the ear generation as best as
>>>  possible, and thats not easy The same thing is valid also for other
>>>  packaging's.
>>>
>>>  Once i stated that maybe the best solution is to split the eclipse
>>>  plugin to be activated in different phases, and in each phase do the
>>>  best thing possible to make the project visible in eclipse, getting
>>>  better in each phase. But that would be a lot of work.
>>>
>>>  Does anyone have a good idea how to do this, i would love to delete the
>>>  tons of plugin simulation code (that will never be complete) in the
>>>  maven-eclipse-plugin.
>>>
>>>  regards,
>>>  Ritchie
>>>
>>>
>>>
>>>  Siarhei Dudzin wrote:
>>>  > Hi All,
>>>  >
>>>  > When I was trying to do a workaround with
>>>  > http://jira.jboss.org/jira/browse/JBIDE-1862 (actually seems to be
>> WTP
>>>  > 2.0.2bug) it appears that maven-eclipse-plugin ignores
>>>  > application.xml that is generated by maven ear plugin. While this
>> might be
>>>  > ok with WTP 2.0.2 you will have a problem if you use a ejb module as
>> a jar
>>>  > (not in a project in the workspace) it adds the module anyway and
>> ignores
>>>  > the JEE5 spec _and_ the EAR plugin settings which allow to specify
>> modules
>>>  > and eventually exclude them.
>>>  >
>>>  > While it is possible to specify in maven-eclipse-plugin config a
>> setting to
>>>  > use a hardcoded application.xml there are still 2 problems:
>>>  >
>>>  > 1. maven-ear-plugin already has the same setting, isn't it better to
>> read
>>>  > it's settings?
>>>  > 2. If you choose to generate application.xml the plugin will put all
>> modules
>>>  > in the application.xml (it does not check the JEE version) thus
>> ignoring the
>>>  > JEE5 spec _and_ ear-plugin settings anyway.
>>>  >
>>>  > As soon as more users will upgrade their eclipse version lots of
>> projects
>>>  > wont hot-deploy via WTP anymore...
>>>  >
>>>  > Your thoughts?
>>>  >
>>>  > Regards,
>>>  > Siarhei
>>>  >
>>>
>>>
>>>  -
>>>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>  For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>
>>
>> --
>> ..
>> Arnaud HERITIER
>> ..
>> OCTO Technology - aheritier AT octo DOT com
>> www.octo.com | blog.octo.com
>> ..
>> ASF - aheritier AT apache DOT org
>> www.apache.org | maven.apache.org
>> ...
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: maven-eclipse-plugin problems with jee5 ears coming

[Richard van Nieuwenhoven]

Hi,

The problem here is the phase in the life cycle.. The best thing would
be to use the generated application.xml from the ear plugin but thats
generated very late in the packaging phase. The eclipse plugin runs in a
very early phase to be able to generate eclipse config files also for
broken projects... It is even very difficult to generate the application
.xml because any of the dependent artifacts can and will not be
available in a packaged version (the information source of the
maven-ear-plugin). This means till the time we find a solution to that
problem, the only chance is to simulate the ear generation as best as
possible, and thats not easy The same thing is valid also for other
packaging's.

Once i stated that maybe the best solution is to split the eclipse
plugin to be activated in different phases, and in each phase do the
best thing possible to make the project visible in eclipse, getting
better in each phase. But that would be a lot of work.

Does anyone have a good idea how to do this, i would love to delete the
tons of plugin simulation code (that will never be complete) in the
maven-eclipse-plugin.

regards,
Ritchie

Siarhei Dudzin wrote:
> Hi All,
> 
> When I was trying to do a workaround with
> http://jira.jboss.org/jira/browse/JBIDE-1862 (actually seems to be WTP
> 2.0.2bug) it appears that maven-eclipse-plugin ignores
> application.xml that is generated by maven ear plugin. While this might be
> ok with WTP 2.0.2 you will have a problem if you use a ejb module as a jar
> (not in a project in the workspace) it adds the module anyway and ignores
> the JEE5 spec _and_ the EAR plugin settings which allow to specify modules
> and eventually exclude them.
> 
> While it is possible to specify in maven-eclipse-plugin config a setting to
> use a hardcoded application.xml there are still 2 problems:
> 
> 1. maven-ear-plugin already has the same setting, isn't it better to read
> it's settings?
> 2. If you choose to generate application.xml the plugin will put all modules
> in the application.xml (it does not check the JEE version) thus ignoring the
> JEE5 spec _and_ ear-plugin settings anyway.
> 
> As soon as more users will upgrade their eclipse version lots of projects
> wont hot-deploy via WTP anymore...
> 
> Your thoughts?
> 
> Regards,
> Siarhei
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Couldn't find a version when building pde-maven-plugin

[Richard van Nieuwenhoven]

Hi,

i did hit the same problem and found that there is a difference in the
version range handling between maven and eclipse plugins.

My solution was rather "ugly" i used the maven-eclipse-plugin in the
version 2.4 to create a local repository. because that version of the
plugin ignores the version ranges and makes hard links between the versions.

mvn org.apache.maven.plugins:maven-eclipse-plugin:2.4:to-maven

But the real question will be for Carlos Sanchez (who wrote new version
ranges as far as i know). How to resolve these version ranges with maven
in the correct way. Maven rules specify that the version 3.3.0-v20070604
is before 3.3.0 and not after, as eclipse resolves them

Carlos what do you say to this problem?

regards,
Ritchie



Jeroen Lankheet wrote:
> Hi,
> 
> I need to change the Ant build target for the pde-maven-plugin.
> So I checked out the trunk, changed version 2.0.9-SNAPSHOT into 2.0.8 in the
> POM
> and did a mvn clean install.
> The following error came up:
> 
> [ERROR] BUILD ERROR
> [INFO]
> 
> [INFO] Failed to resolve artifact.
> 
> Couldn't find a version in [3.3.0-v20070604, 3.2.1-R32x_v20060914] to match
> range [3.3.0,4.0.0)
>   org.eclipse.core:resources:jar:null
> 
> from the specified remote repositories:
>   codehaus.org (http://snapshots.repository.codehaus.org),
>   central (http://repo1.maven.org/maven2),
>   internal
> (file:notorious.ehv.apptech.philips.com/aurora/MavenRepository)
> 
> The org.eclipse.core.resources plugin has version 3.3.0-v20070604.
> That is a match isn't it?
> 
> Regards,
> Jeroen Lankheet


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release Maven Eclipse plugin version 2.5

[Richard van Nieuwenhoven]

+1

Ritchie

Arnaud HERITIER wrote:
> Hi,
> 
> We solved more than 50 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13593&styleName=Html&projectId=11133
> Important changes are :
> - Add support for WTP 2.0
> - Add support for MyEclipse
> - Improve RAD6 support
> - Posibility to discover projects in the eclipse workspace
> And I certainly forgot several others.
> 
> There are still a lot of issues left in JIRA but we applied all
> patches which were usable :
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11133&status=1
> 
> Staging repo:
> http://people.apache.org/~aheritier/stage/repo/
> 
> Staging site:
> Not yet deployed. I'm looking for a sftp client for leopard
> 
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [eclipse 2.5] workspace parameter side-effect

[Richard van Nieuwenhoven]

Hi,

The original use of this parameter was for this "strange" effect. When i
introduced the new parameter i called it workspaceToConnect because the
parameter workspace was in use.

Arnaud fixed a jira (don't remember the number) that this effect has
nothing to do with the workspace and renamed it, so the parameter name
was now free and replaced the new workspaceToConnect property..

So someware on this way, the renaming went wrong...

Arnaud should be able to tell us where.

Ritchie





nicolas de loof wrote:
> Hello,
> 
> setting the workspace parameter to my workspace has a strange side-effect :
> 
> my eclipse .project files are not created in my project folder, but in my
> eclipse workspace directory. I like the idea to automagically detect
> available projects in my eclipse (MECLIPSE-344) but I prefer to have the
> "classic" .project files created in my svn checkout directory.
> 
> Setting ${basedir} fixes this, but
> reading the plugin source code I don't understand how the workspace
> parameter changed the output dir.
> 
> I also noticed the new workspace parameter, that is 100% eclipse related, is
> in AbstractIdeSupportMojo class and not in EclipsePlugin ;-p
> 
> Nico
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

[Richard van Nieuwenhoven]

ok, just changed my mind. after reading all comments and looking into my
needs now. I can work with with the mapping, specially because i need
only one at the moment.

It is MUCH more important there is a consistent mapping! Than it is that
somebody like me likes it or not.

Just see a lot of work coming  and hole bunches of backward
compatibility stuff.

One of the troubles i see coming for example in the maven-eclipse-plugin
is convincing eclipse that a file reference to a jar in the local
repository called "resources.jar" should be handled as if it is called
"org.eclipse.core.resources.jar". In some cases i know it is possible in
others 

Could somebody (hint-> "Carlos Sanchez") write a page on the maven site
about this discussion: about the naming of artifact's and the proper
handling in bundling plugin's. So next time somebody (like me) asks a
question that breaks lose a discussion, we can point the page for
the arguments. It can also be used as a reference for jira tasks in the
various bundling plugins so that all have the same handling, share the
same (activation) parameter names and share the same backward
compatibility handling.

Then with version 2.x.x of maven the default can be switched to the
"correct" handling.

Ritchie

Carlos Sanchez wrote:
> oh, and btw the war plugin already uses the groupId when in conflict :)
> http://jira.codehaus.org/browse/MWAR-19
> 
> 
> On Nov 29, 2007 10:44 AM, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
>> answering several mails here:
>>
>>> id=org.eclipse.core.eclipse-core-resources
>> how can I programatically map this back to the OSGi id ?
>> you must be able to map  osgi<->maven
>>
>>
>>> I totally agree that tools which rely on artifactId-uniqueness are
>>> technically broken, but is it right to choose a programmatic mapping
>>> which increases the severity of this breakage?
>> it doesnt increase anything, you were not using eclipse artifacts
>> before, because they were not in the repo
>> it's most likely that you will use the eclipse bundles for osgi
>> development than for webapp, so it's worse to accommodate the broken
>> war plugin than break the osgi plugins
>>
>>> Eclipse is the first project that introduces this artifactId conflict issue,
>> not really, if i create an artifact with a very commons artifactId
>> like "util" i'm in the same trouble
>>
>>
>>
>> On Nov 28, 2007 9:14 PM, nicolas de loof <[EMAIL PROTECTED]> wrote:
>>> Your right : the packaging plugins may provide a optional workaround to
>>> conflicting artifacts names.
>>> I've created MWAR-132 for this.
>>>
>>> Eclipse is the first project that introduces this artifactId conflict issue,
>>> but many other could appear in future, so the plugins must be upgraded asap
>>> to provide a workaround.
>>>
>>> Nico.
>>>
>>>
>>> 2007/11/28, Carlos Sanchez <[EMAIL PROTECTED]>:
 On Nov 28, 2007 7:09 PM, nicolas de loof <[EMAIL PROTECTED]> wrote:
> 2007/11/28, Carlos Sanchez <[EMAIL PROTECTED]>:
>> plugins (war, ear,...) should support and even make it the default, to
>> package the jars using the full group+arifact id, because using just
>> the artifactId has limitations. What happens now if you have 2 jars
>> with same artifactId and version in a war? they overwrite each other
>>
>>
> This would be great in an ideal world.
> Lets consider the required changes :
>
> - war plugin to create required WEB-INF/lib
> - jar/ear/ejb plugin to create the correct MANIFEST entries
> - assembly plugin to bundle dependencies
>
> Adn now, consider how many builds could be broken by such changes...
 for those plugins it can be an option, doesnt need to be the default
 right away. What i'm saying is that it's the path forward and new
 stuff like the eclipse bundles need to be aware of it. The OSGi tools,
 like felix bundle plugin already compose the bundle symbolic name with
 group+artifact.

 in any case those plugins are already broken if there are two
 artifacts with same artifactid and version (eg util-1.0.jar)

 Now imagine that the eclipse plugins get the name from the artifactId
 only, what about the thousands of artifacts that are already in the
 repo? org.apache.commons-logging/commons-logging should be
 commons-logging in an osgi bundle or org.apache.commons-logging???





 --
 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]


>>
>>
>> --
>>
>> I could give you my word as a Spaniard.
>> No good. I've known too many Spaniards.
>>  -- The Princess Bride
>>
> 
> 
> 


-
To unsubscribe, 

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

[Richard van Nieuwenhoven]

i do not think anybody want to change the repository:

 id=groupId+artifactId

Just that the artifactId may include a part of the groupId

  id=org.eclipse.core.org-eclipse-core-resources

I know now that that me have the osgi-id problem, but we have also the
grown average use factor to consider. I think we can live with long
names. In this case i see no problem stripping the "org" from the
artifactId so the id is:

 id=org.eclipse.core.eclipse-core-resources

This way we can survive till the moment where there is only an id left
and no more groupId or artifactId. Relocations can then be used for a
smooth transition.

So can we find a way to suit both sides?
- keep the tools we have running
and
- move to a unique id

Ritchie







Carlos Sanchez wrote:
> As I said before it's easier to add the new bundles using
> id=groupId+artifactId than to change the whole repo so artifactId can
> be used as id
> 
> You have to consider that the repository is not only for Maven users
> 
> 
> On Nov 28, 2007 7:51 PM, Max Bowsher <[EMAIL PROTECTED]> wrote:
>> Carlos Sanchez wrote:
>>> On Nov 28, 2007 6:40 PM, Richard van Nieuwenhoven <[EMAIL PROTECTED]> wrote:
>>>> The reason for me is that eclipse is the source of the jars and eclipse
>>>> does repeat the group name in the jar name.
>>>>
>>>> It looks very strange to have 10 different jars in the classpath all
>>>> called "resource.jar". And what would happen when you need to package
>>>> the jars together in a directory (ear, war, standalone tool). What would
>>>> the resulting MANIFEST.MF look like.
>>> plugins (war, ear,...) should support and even make it the default, to
>>> package the jars using the full group+arifact id, because using just
>>> the artifactId has limitations. What happens now if you have 2 jars
>>> with same artifactId and version in a war? they overwrite each other
>> That might make a lot of sense for the future, but it really isn't the
>> current state of plugins and people's general expectations.
>>
>> For that reason, I submit that it would be a mistake to add a large
>> collection of jars to the central repository in a way highly likely to
>> cause confusion and name clashes.
>>
>>
>>
>> I have to say that there's a certain pleasant simplicity to using plain
>> artifactId names - it's certainly vastly easier to look at a lib
>> directory and quickly understand what's in there. In the vast majority
>> of projects there will be no clash at all, given the current tendencies
>> of choosing artifactIds.
>>
>> I'd even go so far to suggest that a sort of ad-hoc standard has grown
>> up of choosing an artifactId of what the originating project would
>> reasonably call the jar in the absence of Maven (subject to
>> conventionally allowed characters), and then prepending a suitable
>> groupId to ensure global uniqueness. If those rules are followed then
>> org.eclipse.core.resources_3.3.0.whatever.jar does quite reasonably map
>> to artifactId=org-eclipse-core-resources, groupId=org.eclipse.core.
>>
>> Max.
>>
>>
> 
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

[Richard van Nieuwenhoven]

Hi,

Such changes will not happen easy! think about the consequences in all
existing MANIFEST.MF files with classpaths .

Most users will use the group id as a organizational help but still use
"almost" unique artifactId's as identifications. -> When i see the name
of the jar i know what it is.

Ritchie


Carlos Sanchez wrote:
> On Nov 28, 2007 6:40 PM, Richard van Nieuwenhoven <[EMAIL PROTECTED]> wrote:
>> The reason for me is that eclipse is the source of the jars and eclipse
>> does repeat the group name in the jar name.
>>
>> It looks very strange to have 10 different jars in the classpath all
>> called "resource.jar". And what would happen when you need to package
>> the jars together in a directory (ear, war, standalone tool). What would
>> the resulting MANIFEST.MF look like.
> 
> plugins (war, ear,...) should support and even make it the default, to
> package the jars using the full group+arifact id, because using just
> the artifactId has limitations. What happens now if you have 2 jars
> with same artifactId and version in a war? they overwrite each other
> 
>> Sorry to reopen this discussion, but i think a jar's name should be as
>> near as possible to the original jar name.
>>
>> It is done all the time, example:
>> "maven-eclipse-plugin" is not called "eclipse" because the groupId
>> contains "maven" and "plugin".
> 
> but i think if groupid is org.apache.maven.plugins then the artifact
> should be just eclipse. Doesnt happen now, but it probably should
> 
>> Ritchie
>>
>>
>>
>>
>> Carlos Sanchez wrote:
>>> why would we use groupIds and artifactIds if we were going to repeat
>>> the same information in both fields?
>>>
>>> this was already brought before and the way the jars are stored
>>> doesn't imply the way they are used
>>>
>>> On Nov 27, 2007 8:12 PM, Richard van Nieuwenhoven <[EMAIL PROTECTED]> wrote:
>>>> I think it is important that {artifactId}-{version}.jar results in a
>>>> name as similar as possible the the name as they are in the plugin
>>>> directory of eclipse.
>>>>
>>>> And the eclipse project name should represent the group id of the plugin
>>>> as on http://www.eclipse.org/projects/ , whereas i do not care if only
>>>> top-level-projects are used as group-id's. Or (to keep it simple) just
>>>> use the first three words as a groupId
>>>>
>>>> this way the jar should be:
>>>>
>>>> org.eclipse.platform
>>>> org-eclipse-core-resources
>>>> 3.2.1
>>>>
>>>> or
>>>>
>>>> org.eclipse.platform.core
>>>> org-eclipse-core-resources
>>>> 3.2.1
>>>>
>>>> or
>>>>
>>>> org.eclipse.core
>>>> org-eclipse-core-resources
>>>> 3.2.1
>>>>
>>>> any other idea's...
>>>>
>>>> Ritchie
>>>>
>>>>
>>>> Max Bowsher wrote:
>>>>> Carlos Sanchez wrote:
>>>>>> I'm uploading right now a good number of jars to
>>>>>> http://repo1.maven.org/eclipse-staging/
>>>>>> If it looks good I will sync to central
>>>>>>
>>>>>> Note that the location for the one you want should be
>>>>>> http://repo1.maven.org/eclipse-staging/org/eclipse/core/resources/3.2.1/
>>>>> I wonder if this groupId:artifactId mapping is a bad idea?
>>>>>
>>>>> Most jars in the repository have an artifactId which is, whilst not
>>>>> necessarily globally unique, good enough to give you a pretty good idea
>>>>> what they are. This is a good thing, since there are several use cases
>>>>> where a collection of jars is bundled into a single directory, and those
>>>>> jars are named {artifactId}-{version}.jar (e.g, war file WEB-INF/lib/,
>>>>> common usage of assembly plugin).
>>>>>
>>>>> The suggested mapping of just taking the last component of the name as
>>>>> the artifactId will lead to many artifacts with non-descriptive and
>>>>> clashing names like "common", "core", "ui", etc.  At best case, this
>>>>> will merely be horrendously confusing for humans attempting to
>>>>> understand and debug these generated collections of jars. At worst case,
>>>>>  some of the artifacts will not only have the same artifactId, but same
>>>>> version too, and will overwrite each other.
>>>>>
>>>>> So, I think the current mapping fits poorly with existing Maven
>>>>> use-cases and plugin design, and needs further consideration.
>>>>>
>>>>> Max.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> -
>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

[Richard van Nieuwenhoven]

The reason for me is that eclipse is the source of the jars and eclipse
does repeat the group name in the jar name.

It looks very strange to have 10 different jars in the classpath all
called "resource.jar". And what would happen when you need to package
the jars together in a directory (ear, war, standalone tool). What would
the resulting MANIFEST.MF look like.

Sorry to reopen this discussion, but i think a jar's name should be as
near as possible to the original jar name.

It is done all the time, example:
"maven-eclipse-plugin" is not called "eclipse" because the groupId
contains "maven" and "plugin".

Ritchie



Carlos Sanchez wrote:
> why would we use groupIds and artifactIds if we were going to repeat
> the same information in both fields?
> 
> this was already brought before and the way the jars are stored
> doesn't imply the way they are used
> 
> On Nov 27, 2007 8:12 PM, Richard van Nieuwenhoven <[EMAIL PROTECTED]> wrote:
>> I think it is important that {artifactId}-{version}.jar results in a
>> name as similar as possible the the name as they are in the plugin
>> directory of eclipse.
>>
>> And the eclipse project name should represent the group id of the plugin
>> as on http://www.eclipse.org/projects/ , whereas i do not care if only
>> top-level-projects are used as group-id's. Or (to keep it simple) just
>> use the first three words as a groupId
>>
>> this way the jar should be:
>>
>> org.eclipse.platform
>> org-eclipse-core-resources
>> 3.2.1
>>
>> or
>>
>> org.eclipse.platform.core
>> org-eclipse-core-resources
>> 3.2.1
>>
>> or
>>
>> org.eclipse.core
>> org-eclipse-core-resources
>> 3.2.1
>>
>> any other idea's...
>>
>> Ritchie
>>
>>
>> Max Bowsher wrote:
>>> Carlos Sanchez wrote:
>>>> I'm uploading right now a good number of jars to
>>>> http://repo1.maven.org/eclipse-staging/
>>>> If it looks good I will sync to central
>>>>
>>>> Note that the location for the one you want should be
>>>> http://repo1.maven.org/eclipse-staging/org/eclipse/core/resources/3.2.1/
>>> I wonder if this groupId:artifactId mapping is a bad idea?
>>>
>>> Most jars in the repository have an artifactId which is, whilst not
>>> necessarily globally unique, good enough to give you a pretty good idea
>>> what they are. This is a good thing, since there are several use cases
>>> where a collection of jars is bundled into a single directory, and those
>>> jars are named {artifactId}-{version}.jar (e.g, war file WEB-INF/lib/,
>>> common usage of assembly plugin).
>>>
>>> The suggested mapping of just taking the last component of the name as
>>> the artifactId will lead to many artifacts with non-descriptive and
>>> clashing names like "common", "core", "ui", etc.  At best case, this
>>> will merely be horrendously confusing for humans attempting to
>>> understand and debug these generated collections of jars. At worst case,
>>>  some of the artifacts will not only have the same artifactId, but same
>>> version too, and will overwrite each other.
>>>
>>> So, I think the current mapping fits poorly with existing Maven
>>> use-cases and plugin design, and needs further consideration.
>>>
>>> Max.
>>>
>>>
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)

[Richard van Nieuwenhoven]

I think it is important that {artifactId}-{version}.jar results in a
name as similar as possible the the name as they are in the plugin
directory of eclipse.

And the eclipse project name should represent the group id of the plugin
as on http://www.eclipse.org/projects/ , whereas i do not care if only
top-level-projects are used as group-id's. Or (to keep it simple) just
use the first three words as a groupId

this way the jar should be:

org.eclipse.platform
org-eclipse-core-resources
3.2.1

or

org.eclipse.platform.core
org-eclipse-core-resources
3.2.1

or

org.eclipse.core
org-eclipse-core-resources
3.2.1

any other idea's...

Ritchie

Max Bowsher wrote:
> Carlos Sanchez wrote:
>> I'm uploading right now a good number of jars to
>> http://repo1.maven.org/eclipse-staging/
>> If it looks good I will sync to central
>>
>> Note that the location for the one you want should be
>> http://repo1.maven.org/eclipse-staging/org/eclipse/core/resources/3.2.1/
> 
> I wonder if this groupId:artifactId mapping is a bad idea?
> 
> Most jars in the repository have an artifactId which is, whilst not
> necessarily globally unique, good enough to give you a pretty good idea
> what they are. This is a good thing, since there are several use cases
> where a collection of jars is bundled into a single directory, and those
> jars are named {artifactId}-{version}.jar (e.g, war file WEB-INF/lib/,
> common usage of assembly plugin).
> 
> The suggested mapping of just taking the last component of the name as
> the artifactId will lead to many artifacts with non-descriptive and
> clashing names like "common", "core", "ui", etc.  At best case, this
> will merely be horrendously confusing for humans attempting to
> understand and debug these generated collections of jars. At worst case,
>  some of the artifacts will not only have the same artifactId, but same
> version too, and will overwrite each other.
> 
> So, I think the current mapping fits poorly with existing Maven
> use-cases and plugin design, and needs further consideration.
> 
> Max.
> 
> 
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: in repo1 it is available

[Richard van Nieuwenhoven]

Hi,

but it would be better to start with version 3.3.x even if the source we
need "now" is unchanged. I checked some other workspace reading stuff
and there was a rather good backward compatibility's stuff.

Ritchie


Arnaud HERITIER wrote:
> Can we upload some jars in the central repo and more precisely this one :
> http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/
> ??
> Arnaud
> 
> On Nov 26, 2007 4:15 PM, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> 
>> that's right, I still have to polish the eclipse plugin to generate
>> the Eclipse repo using some "conventions"
>>
>> On Nov 26, 2007 10:04 PM, nicolas de loof <[EMAIL PROTECTED]>
>> wrote:
>>> AFAIK this one is an experimental repository created by carlos.
>>>
>>> (http://marc.info/?l=turbine-maven-dev&m=117393683323837&w=2)
>>>
>>> 2007/11/26, Arnaud HERITIER <[EMAIL PROTECTED]>:
>>>
>>>> ouch, I didn't notice.
>>>> It's a maven 2 repository but not the central one.
>>>> Carlos, Jason, do you know why the content of
>>>> http://repo1.maven.org/eclipse/
>>>> <
>>>>
>> http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/
>>>>> isn't
>>>> available in http://repo1.maven.org/maven2
>>>> ??<
>>>>
>> http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/
>>>> Arnaud
>>>>
>>>> On Nov 26, 2007 1:57 PM, Richard van Nieuwenhoven <[EMAIL PROTECTED]> 
>>>> wrote:
>>>>
>>>>> just that it is not the maven2 central repository.
>>>>> It is the maven1 repository or is that wrong / or a problem?
>>>>>
>>>>> Ritchie
>>>>>
>>>>> Arnaud HERITIER wrote:
>>>>>> Ok, it's cool.
>>>>>> Thus we just have to add the dependency (with all excludes ...)
>>>>>> The jar is here, thus we don't need to request an upload.
>>>>>>
>> http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/
>>>>>> Arnaud
>>>>>>
>>>>>> On Nov 26, 2007 1:51 PM, Richard van Nieuwenhoven <[EMAIL PROTECTED]>
>> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> in the repo1 repository it is available!
>>>>>>>
>>>>>>>
>>>>>>>
>> http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/org.eclipse.core.resources-3.2.1.pom
>>>>>>> (the needed code did not change in 3.3)
>>>>>>> just be sure to exclude all deeper dependencies!
>>>>>>>
>>>>>>> anyway, now you have the data needed for the upload request.
>>>>>>>
>>>>>>> regards,
>>>>>>> Ritchie
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> --
>>>> ..
>>>> Arnaud HERITIER
>>>> ..
>>>> OCTO Technology - aheritier AT octo DOT com
>>>> www.octo.com | blog.octo.com
>>>> ..
>>>> ASF - aheritier AT apache DOT org
>>>> www.apache.org | maven.apache.org
>>>> ...
>>>>
>>
>>
>> --
>> 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]
>>
>>
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: in repo1 it is available

[Richard van Nieuwenhoven]

ah, so we are back in the maven-eclipse-plugin to generate repository
from which a dependency we need in the maven-eclipse-plugin.

What are the open issues in the repository generation?

Ritchie

Carlos Sanchez wrote:
> that's right, I still have to polish the eclipse plugin to generate
> the Eclipse repo using some "conventions"
> 
> On Nov 26, 2007 10:04 PM, nicolas de loof <[EMAIL PROTECTED]> wrote:
>> AFAIK this one is an experimental repository created by carlos.
>>
>> (http://marc.info/?l=turbine-maven-dev&m=117393683323837&w=2)
>>
>> 2007/11/26, Arnaud HERITIER <[EMAIL PROTECTED]>:
>>
>>> ouch, I didn't notice.
>>> It's a maven 2 repository but not the central one.
>>> Carlos, Jason, do you know why the content of
>>> http://repo1.maven.org/eclipse/
>>> <
>>> http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/
>>>> isn't
>>> available in http://repo1.maven.org/maven2
>>> ??<
>>> http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/
>>> Arnaud
>>>
>>> On Nov 26, 2007 1:57 PM, Richard van Nieuwenhoven <[EMAIL PROTECTED]> wrote:
>>>
>>>> just that it is not the maven2 central repository.
>>>> It is the maven1 repository or is that wrong / or a problem?
>>>>
>>>> Ritchie
>>>>
>>>> Arnaud HERITIER wrote:
>>>>> Ok, it's cool.
>>>>> Thus we just have to add the dependency (with all excludes ...)
>>>>> The jar is here, thus we don't need to request an upload.
>>>>>
>>> http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/
>>>>> Arnaud
>>>>>
>>>>> On Nov 26, 2007 1:51 PM, Richard van Nieuwenhoven <[EMAIL PROTECTED]> 
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> in the repo1 repository it is available!
>>>>>>
>>>>>>
>>>>>>
>>> http://repo1.maven.org/eclipse/org/eclipse/core/org.eclipse.core.resources/3.2.1/org.eclipse.core.resources-3.2.1.pom
>>>>>> (the needed code did not change in 3.3)
>>>>>> just be sure to exclude all deeper dependencies!
>>>>>>
>>>>>> anyway, now you have the data needed for the upload request.
>>>>>>
>>>>>> regards,
>>>>>> Ritchie
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> --
>>> ..
>>> Arnaud HERITIER
>>> ..
>>> OCTO Technology - aheritier AT octo DOT com
>>> www.octo.com | blog.octo.com
>>> ..
>>> ASF - aheritier AT apache DOT org
>>> www.apache.org | maven.apache.org
>>> ...
>>>
> 
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: copieing sources in to a maven-plugin

[Richard van Nieuwenhoven]

Hi,

where can i find that page?

After writing test cases i now know how to read the binary files, almost
without the code but i need at least two defined constants "a long magic
number".
But as far as i know it is still called copying, if i used the original
code to see what it does.

Does the EPL allow repackaging? copying singular class files from the
original jar and put them in a other (along with the legal notice, and
no change what so ever).

This is the first time (a least one i know of) but surly not the last
time the maven-eclipse-plugin needs "something" from eclipse, so this
should be solved.

When we really do not want this dependency, we could include a parameter
 to point to the eclipse installation directory  (but i don't
think thats a good solution)

regards,
Ritchie

Carl Trieloff wrote:
> 
> yes and no.
> 
> You can NOT copy files from EPL into an ASL project, or modify them in
> an ASL project. However you can take a binary (jar) dependency on an EPL
> binary. So you would have to copy the jar that the source is in.
> However, the source or part of the jar is also not permitted by the
> combination of ASL / EPL. i.e. only binary dependencies on EPL will work
> under ASL. Cliff has a good page posted on topic posted.
> 
> Carl.
> 
> Arnaud HERITIER wrote:
>> Hi Guys,
>>
>>   Thus what can I do ?
>>   Richard proposed a patch (http://jira.codehaus.org/browse/MECLIPSE-344)
>> which is very useful for our eclipse plugin, but it bundles 2 java
>> classes
>> coming from eclipse (IBM - EPL 1.0). Those sources are in
>> src/main/eclipse
>> with the license file.
>>
>>   Can I add them, or is it prohibited ?
>>
>> Arnaud
>>
>> On Nov 14, 2007 4:37 AM, Brett Porter <[EMAIL PROTECTED]> wrote:
>>
>>  
>>> On 13/11/2007, at 4:37 AM, Richard van Nieuwenhoven wrote:
>>>
>>>
>>>> I see different solutions, but witch one to take 
>>>> - copy the sources and leaf them as untouched as possible (may be even
>>>> in a own source folder to separate them and exclude them from code
>>>> reformating)
>>>>   
>>> yes, they will need to be separate in this case - note that the EPL
>>> requires you contribute enhancements and fixes back to the author.
>>>
>>>
>>>> - extract the classes or sources at build time and include them in the
>>>> package as classes
>>>>   
>>> this is likely a better alternative to the above, but remember you
>>> need to include the relevant license/notice if you distribute your code.
>>>
>>>
>>>> - completely rewrite the part i need (to remove the copyright)
>>>>   
>>> you can't just "remove copyright" and rewrite in place - if you
>>> rewrite it must be free of influence from the original.
>>>
>>>
>>>> - include the dependency anyway
>>>>   
>>> that might be the best place to start, and use exclusions to remove
>>> the tree of deps you don't need.
>>>
>>> - Brett
>>>
>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>> 
>>
>>
>>   
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

copieing sources in to a maven-plugin

[Richard van Nieuwenhoven]

All,

with a very small code change and 2 small sources from a eclipse-plugin
the maven-eclipse-plugin will be able to connect projects to the
projects in the workspace instead of the jars for the repository. This
is a very important feature for the maven-eclipse-plugin.

Now to my question:
To do this, i need two small sources from a eclipse-plugin that reads a
special binary file. But a dependency to the eclipse-plugin would
include a deep tree of dependencies, what i would think is way to big
for those two small classes (they are probably not intended to be part
of a public API anyway)

I see different solutions, but witch one to take 
- copy the sources and leaf them as untouched as possible (may be even
in a own source folder to separate them and exclude them from code
reformating)
- extract the classes or sources at build time and include them in the
package as classes
- completely rewrite the part i need (to remove the copyright)
- include the dependency anyway
- any other solution?

Specially the legal considerations make it difficult for me to decide
for a solution. The eclipse-plugin has this copyright
http://www.eclipse.org/legal/epl-v10.html and the maven-eclipse-plugin
has this one
http://maven.apache.org/plugins/maven-eclipse-plugin/license.html

Probably i am not the fist one fighting with such considerations, so
what is the "standard" way to go?

thanks for any help,
Ritchie










-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven deployment

[Richard van Nieuwenhoven]

Hi,

use the maven-eclipse-plugin for RAD-6 support. I do not know the status
of the RAD-7 support.

http://maven.apache.org/plugins/maven-eclipse-plugin/

tip 1: Stay with the maven project layout as far as possible!

tip 2: extract java code from any war into a separate jar-module
(this will reduce a lot of rad problems)

regards,
Richard van Nieuwenhoven


Hemant Ved wrote:
> Hi all
> 
> Can anybody explain me the steps to deploy ejb using maven with Websphere
> 6?Has anybody tried using Maven and RAD combination? Can maven follow the
> directory structure of RAD?
> 
> 
> 
> Thanks and regards
> Hemant Ved
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Different approach to Multiple Module Projects

[Richard van Nieuwenhoven]

Hi,

The right place for maven-eclipse-plugin patch is
http://jira.codehaus.org/browse/MECLIPSE

i am also using many multi module projects, but i like it far more to:

* checkout one multi module project
* start maven-eclipse-plugin
* import using the eclipse multi project importer all sub modules from
this project as separate eclipse-projects

This works very good, just like using symbolic links in Unix.

Richard van Nieuwenhoven

Syte Beimin wrote:
> First of all I hope this is the right place to send my patch to.
> At my company we're used to check out an entire project from
> subversion. So we'll get all the modules of a project in one eclipse
> project. The eclipse plugin will create .project and .classpath files
> in each module directory. For easy checkout and maintainability I've
> made a patch for the eclipse plugin. With the config
> 'true' the plugin now creates a .project
> and .classpath file in the root of the multi module project. This
> classpath has all the source and output directories setup so eclipse
> put's it's outputs in the same directories (in the modules target
> directories) where maven places them.
>
> I'm sending this patch to this mailinglist because I suspect more
> people would like to be able to check out their multi module projects
> in this manner instead of the circumvent way that is described on
> http://maven.apache.org/plugins/maven-eclipse-plugin/reactor.html .
>
> Perhaps it'll even make it into the next release who knows :)
>
> Syte Beimin
> Better.be
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] maven-eclipse-plugin 2.4

[Richard van Nieuwenhoven]

ok, after this release i will make/take time for myself to create a new
patch that includes all patches of the 3 companies i know that use
patched versions.

This time i will make the time to include tests and documentation!!!
(maybe release 2.5 is not so far away)

Another question did anyone test the plugin with eclipse 3.3 (with and
without WTP) ?

Ritchie

Brian E. Fox wrote:
> Ritchie,
> I understand the issue but on the flip side, without tests to ensure the
> functionality works as expected, we can't verify it. I don't personally
> use this functionality of the plugin so I can't tell at a glance if it's
> right or not. As I see it, once we are this close to a release
> (discussion about preparing for it occurred mid-june) then only complete
> patches can be considered for inclusion. Otherwise we might have to wait
> another week or two until someone has time to analyze and complete the
> patch. It's a recurring cycle where we wait and wait and before you know
> it, it's 5 months like it is now with good functionality already sitting
> there.
>
> --Brian
>
> -Original Message-
> From: Richard van Nieuwenhoven [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, July 05, 2007 9:21 AM
> To: Maven Developers List
> Subject: Re: [VOTE] maven-eclipse-plugin 2.4
>
> test are missing correct, but a fix for this ear problem is rather
> important because
> ear's won't work with WTP as they are.
>
> Ritchie
>
> Brian E. Fox wrote:
>   
>> Same thing with this one, the patch doesn't exist yet along with tests
>> or doc changes. If we have to respin the release because of the test
>> problems, then we can grab a few patches if they are complete,
>> 
> otherwise
>   
>> I say they wait. We've been discussing releasing for several weeks now
>> and need to pull the trigger at some point. We shouldn't wait another
>> 
> 5
>   
>> months before releasing again so this doesn't become a problem.
>>
>> -Original Message-
>> From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] 
>> Sent: Thursday, July 05, 2007 4:55 AM
>> To: Maven Developers List
>> Subject: Re: [VOTE] maven-eclipse-plugin 2.4
>>
>> We just received a comment about MECLIPSE-184 (it was in private
>> before).
>> WDYT ? I'm not a ear user...
>>
>> Arnaud
>>
>>
>> On 04/07/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>>   
>> 
>>> It's been about 5 months since an eclipse plugin release and we have
>>> lots of fixes and a handful of enhancements:
>>>
>>> Bug
>>> * [MECLIPSE-108] - .wtpmodules with version 2.4 for
>>> javax.servlet:servlet-api:2.3
>>> * [MECLIPSE-109] - .component wb-resource source path incorrect for
>>> 
>>>   
>> ear
>>   
>> 
>>> packaging
>>> * [MECLIPSE-151] - Incorrect name for test sources jars
>>> * [MECLIPSE-198] - EJB version is not resloved
>>> * [MECLIPSE-215] - WTP 1.5 Documentation
>>> * [MECLIPSE-220] - Incorrect eclipse facet information when doing mvn
>>> eclipse:eclipse for war and ejb projects.
>>> * [MECLIPSE-225] - Invalid .classpath Entries.
>>> * [MECLIPSE-233] - Manifest attributes incorrectly treated as
>>> case-sensitive
>>> * [MECLIPSE-234] - [PATCH] EclipsePlugin.extractResourceDirs() reuses
>>> String method argument causing maven-eclipse.xml copy-resources
>>> 
>>>   
>> problems
>>   
>> 
>>> * [MECLIPSE-236] - eclipse:make-artifacts should preserve the
>>> resolution:=optional directive
>>> * [MECLIPSE-237] - unsafe EclipseSourceDir.equals() method
>>> * [MECLIPSE-241] - Compiler settings in pluginManagement aren't used
>>> 
>>>   
>> in
>>   
>> 
>>> wtp facet
>>> * [MECLIPSE-243] - The last 2.4 SNAPSHOT forbid Apache Directory
>>> 
>>>   
>> Server
>>   
>> 
>>> to be built
>>> * [MECLIPSE-248] - Eclipse plugin looks for pom version "test"
>>> * [MECLIPSE-255] - WTP Settings does not use servlet-api version
>>> 
>>>   
>> defined
>>   
>> 
>>> in pom.xml
>>> * [MECLIPSE-263] - Project Facet 'Java' set to 1.4 instead of 5.0 in
>>>   
> a
>   
>>> Java 5.0 project
>>> * [MECLIPSE-278] - duplicated classpathentries
>>> * [MECLIPSE-279] - PDE projects should be considered java projects in
>>> all cases
>>

Re: [VOTE] maven-eclipse-plugin 2.4

[Richard van Nieuwenhoven]

test are missing correct, but a fix for this ear problem is rather
important because
ear's won't work with WTP as they are.

Ritchie

Brian E. Fox wrote:
> Same thing with this one, the patch doesn't exist yet along with tests
> or doc changes. If we have to respin the release because of the test
> problems, then we can grab a few patches if they are complete, otherwise
> I say they wait. We've been discussing releasing for several weeks now
> and need to pull the trigger at some point. We shouldn't wait another 5
> months before releasing again so this doesn't become a problem.
>
> -Original Message-
> From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, July 05, 2007 4:55 AM
> To: Maven Developers List
> Subject: Re: [VOTE] maven-eclipse-plugin 2.4
>
> We just received a comment about MECLIPSE-184 (it was in private
> before).
> WDYT ? I'm not a ear user...
>
> Arnaud
>
>
> On 04/07/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>   
>> It's been about 5 months since an eclipse plugin release and we have
>> lots of fixes and a handful of enhancements:
>>
>> Bug
>> * [MECLIPSE-108] - .wtpmodules with version 2.4 for
>> javax.servlet:servlet-api:2.3
>> * [MECLIPSE-109] - .component wb-resource source path incorrect for
>> 
> ear
>   
>> packaging
>> * [MECLIPSE-151] - Incorrect name for test sources jars
>> * [MECLIPSE-198] - EJB version is not resloved
>> * [MECLIPSE-215] - WTP 1.5 Documentation
>> * [MECLIPSE-220] - Incorrect eclipse facet information when doing mvn
>> eclipse:eclipse for war and ejb projects.
>> * [MECLIPSE-225] - Invalid .classpath Entries.
>> * [MECLIPSE-233] - Manifest attributes incorrectly treated as
>> case-sensitive
>> * [MECLIPSE-234] - [PATCH] EclipsePlugin.extractResourceDirs() reuses
>> String method argument causing maven-eclipse.xml copy-resources
>> 
> problems
>   
>> * [MECLIPSE-236] - eclipse:make-artifacts should preserve the
>> resolution:=optional directive
>> * [MECLIPSE-237] - unsafe EclipseSourceDir.equals() method
>> * [MECLIPSE-241] - Compiler settings in pluginManagement aren't used
>> 
> in
>   
>> wtp facet
>> * [MECLIPSE-243] - The last 2.4 SNAPSHOT forbid Apache Directory
>> 
> Server
>   
>> to be built
>> * [MECLIPSE-248] - Eclipse plugin looks for pom version "test"
>> * [MECLIPSE-255] - WTP Settings does not use servlet-api version
>> 
> defined
>   
>> in pom.xml
>> * [MECLIPSE-263] - Project Facet 'Java' set to 1.4 instead of 5.0 in a
>> Java 5.0 project
>> * [MECLIPSE-278] - duplicated classpathentries
>> * [MECLIPSE-279] - PDE projects should be considered java projects in
>> all cases
>> * [MECLIPSE-287] - Regression - fails to correctly construct classpath
>> containing dependencies with classifiers
>> Improvement
>> * [MECLIPSE-207] - Add supprt for arbitrary facets, like JSF
>> * [MECLIPSE-267] - Resolve version ranges in make-artifacts
>> * [MECLIPSE-268] - [eclipse:rad goal] Make customization of servlet
>> version, jsp version, ... possible through pom configuration
>> * [MECLIPSE-286] - Ability to skip generated-resources/rad6 folder
>> creation while executing eclipse:rad
>> New Feature
>> * [MECLIPSE-119] - Allow custom project name for eclipse projects
>> * [MECLIPSE-189] - addVersionToProjectName property
>> * [MECLIPSE-251] - Allows prefixing of eclipse project name
>> * [MECLIPSE-271] - Ability to skip
>>
>> The site has been updated:
>> http://maven.apache.org/plugins/maven-eclipse-plugin
>>
>> Plugin is staged here:
>> http://people.apache.org/~brianf/staging-repository/
>>
>> Vote is open for 72hrs.
>>
>> +1
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>> 
>
>
>   


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] maven-eclipse-plugin 2.4

[Richard van Nieuwenhoven]

Hello,

my patch http://jira.codehaus.org/browse/MECLIPSE-213 contains a fix for
this problem.
i have also a better version that takes it from the ear-plugin
configuration because there
there is a property *defaultLibBundleDir

*that should be used to specify the directory, i can
post it if you need it.

Ritchie

Arnaud HERITIER wrote:
> Brian, what do we do ?
> We fix it for 2.4 or not ?
>
> On 05/07/07, Cabasson Denis <[EMAIL PROTECTED]> wrote:
>> Looks relevant to me. In a EAR you indeed expect dependencies to be
>> in the root directory, not under WEB-INF lib.
>>
>> Suggested solution looks sensible.
>>
>> Denis.
>>
>> > -Message d'origine-
>> > De : Arnaud HERITIER [mailto:[EMAIL PROTECTED]
>> > Envoyé : Thursday, July 05, 2007 10:55 AM
>> > À : Maven Developers List
>> > Objet : Re: [VOTE] maven-eclipse-plugin 2.4
>> >
>> > We just received a comment about MECLIPSE-184 (it was in
>> > private before).
>> > WDYT ? I'm not a ear user...
>> >
>> > Arnaud
>> >
>> >
>> > On 04/07/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>> > > It's been about 5 months since an eclipse plugin release
>> > and we have
>> > > lots of fixes and a handful of enhancements:
>> > >
>> > > Bug
>> > > * [MECLIPSE-108] - .wtpmodules with version 2.4 for
>> > > javax.servlet:servlet-api:2.3
>> > > * [MECLIPSE-109] - .component wb-resource source path incorrect for
>> > > ear packaging
>> > > * [MECLIPSE-151] - Incorrect name for test sources jars
>> > > * [MECLIPSE-198] - EJB version is not resloved
>> > > * [MECLIPSE-215] - WTP 1.5 Documentation
>> > > * [MECLIPSE-220] - Incorrect eclipse facet information when
>> > doing mvn
>> > > eclipse:eclipse for war and ejb projects.
>> > > * [MECLIPSE-225] - Invalid .classpath Entries.
>> > > * [MECLIPSE-233] - Manifest attributes incorrectly treated as
>> > > case-sensitive
>> > > * [MECLIPSE-234] - [PATCH]
>> > EclipsePlugin.extractResourceDirs() reuses
>> > > String method argument causing maven-eclipse.xml copy-resources
>> > > problems
>> > > * [MECLIPSE-236] - eclipse:make-artifacts should preserve the
>> > > resolution:=optional directive
>> > > * [MECLIPSE-237] - unsafe EclipseSourceDir.equals() method
>> > > * [MECLIPSE-241] - Compiler settings in pluginManagement
>> > aren't used
>> > > in wtp facet
>> > > * [MECLIPSE-243] - The last 2.4 SNAPSHOT forbid Apache Directory
>> > > Server to be built
>> > > * [MECLIPSE-248] - Eclipse plugin looks for pom version "test"
>> > > * [MECLIPSE-255] - WTP Settings does not use servlet-api version
>> > > defined in pom.xml
>> > > * [MECLIPSE-263] - Project Facet 'Java' set to 1.4 instead
>> > of 5.0 in a
>> > > Java 5.0 project
>> > > * [MECLIPSE-278] - duplicated classpathentries
>> > > * [MECLIPSE-279] - PDE projects should be considered java
>> > projects in
>> > > all cases
>> > > * [MECLIPSE-287] - Regression - fails to correctly
>> > construct classpath
>> > > containing dependencies with classifiers Improvement
>> > > * [MECLIPSE-207] - Add supprt for arbitrary facets, like JSF
>> > > * [MECLIPSE-267] - Resolve version ranges in make-artifacts
>> > > * [MECLIPSE-268] - [eclipse:rad goal] Make customization of servlet
>> > > version, jsp version, ... possible through pom configuration
>> > > * [MECLIPSE-286] - Ability to skip generated-resources/rad6 folder
>> > > creation while executing eclipse:rad New Feature
>> > > * [MECLIPSE-119] - Allow custom project name for eclipse projects
>> > > * [MECLIPSE-189] - addVersionToProjectName property
>> > > * [MECLIPSE-251] - Allows prefixing of eclipse project name
>> > > * [MECLIPSE-271] - Ability to skip
>> > >
>> > > The site has been updated:
>> > > http://maven.apache.org/plugins/maven-eclipse-plugin
>> > >
>> > > Plugin is staged here:
>> > > http://people.apache.org/~brianf/staging-repository/
>> > >
>> > > Vote is open for 72hrs.
>> > >
>> > > +1
>> > >
>> > >
>> > >
>> > -
>> > > To unsubscribe, e-mail: [EMAIL PROTECTED] For
>> > > additional commands, e-mail: [EMAIL PROTECTED]
>> > >
>> > >
>> >
>> >
>> > --
>> > ..
>> > Arnaud HERITIER
>> > ..
>> > OCTO Technology - [EMAIL PROTECTED]
>> > www.octo.com | blog.octo.com
>> > ..
>> > ASF - [EMAIL PROTECTED]
>> > www.apache.org | maven.apache.org
>> > ...
>> >
>> > -
>> > To unsubscribe, e-mail: [EMAIL PROTECTED] For
>> > additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>


-

Re: Developed a RAD6 extention of maven-eclipse-plugin

[Richard van Nieuwenhoven]

It supports J2EE projects with the websphere development envorment, 
supported are

- EJB projects
- Web projects
- EAR- projects
all these projects are recognized by rad-6 as what they are and use of 
the development enviorment including hot-deployment features.

i wrote writers for:
- the ".j2ee" files
- the "application.xml" and the "modulemaps" file
- copying the extrenal libs in the ear project root
- adapting the MANIFEST.MF of the projects
- the ".websettings" file
- the ".websiteconfig" file
- the ".project" (only alternative project natures/builders)

regards,
Ritchie

Mike Perham schrieb:

What does it do above and beyond the normal eclipse plugin?  I ask
because we are using RAD here and it works fine with the normal plugin.

-Original Message-
From: Richard van Nieuwenhoven [mailto:[EMAIL PROTECTED] 
Sent: Friday, July 28, 2006 8:13 AM

To: Maven Developers List
Subject: Developed a RAD6 extention of maven-eclipse-plugin

Hello,

i developed a rad-6 maven plugin based on the eclipse plugin for a big 
customer who want's to use maven-2.

It was developed because i could not find a rad-6.0 capable maven plugin

that realy works.
My customer allowed me to release the code, now my question is how to do
it
- where to commit it to or shall i just send a tgz with the sources.
- sould it be integrated with the eclipse plugin (my faforite)

anyone interested?

regards,
Ritchie


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Developed a RAD6 extention of maven-eclipse-plugin

[Richard van Nieuwenhoven]

Hello,

i developed a rad-6 maven plugin based on the eclipse plugin for a big 
customer who want's to use maven-2.
It was developed because i could not find a rad-6.0 capable maven plugin 
that realy works.

My customer allowed me to release the code, now my question is how to do it
- where to commit it to or shall i just send a tgz with the sources.
- sould it be integrated with the eclipse plugin (my faforite)

anyone interested?

regards,
Ritchie


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]