RPM Factory Plugin for RPMing the Maven Repository

[Ole Ersoy]

Hi Guys,

I finished up an RPM Factory Plugin recently (At least the first pass)
and it can be found here in case anyone is interested:

https://svn.apache.org/repos/asf/directory/sandbox/oersoy/rpm.factory.all

There is a eclipse documentation plugin guide for installing and using here:

https://svn.apache.org/repos/asf/directory/sandbox/oersoy/guides/rpm.factory.user.guide

Just drop it into the eclipse plugins folder, and open eclipse help.  
You will find a RPM Factory User Guide book.


The motivation behind this plugin is to create a RPM mirror of the 
entire maven repository,
such that servers and other applications can be packaged as a Minimal 
rpm, and pull it's dependencies
from the RPM mirror, the same way Maven builds source their dependencies 
from the Maven repository.


I plan on adding a capability for also inserting OSGi manifests prior to 
packaging each jar artifact,

so that that the jars packaged are also OSGi compliant.

Cheers,
- Ole



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

Re: Eclipse PDE questions/suggestions

[Ole Ersoy]

Hi Markus,

I need to play with the  PDE feature of the eclipse plugin more,
but I did write an archetype for generating baseline eclipse 
documentation plugins

that you can see here:

https://svn.apache.org/repos/asf/directory/sandbox/oersoy/documentation.checklist.parent

It's actually a checklist / recipe documentation generator, but if you
run the archetype it will generate a baseline eclipse project with
${groupId}.${artifactId} in plugin.xml

So one way you could get things going is to just modify the archetype, 
add a few templates
maybe, and just use the archetype plugin to generate the baseline for 
your project.


Cheers,
- Ole




Markus Wiederkehr wrote:

I have a two questions regarding the Maven Eclipse plugin and
especially its PDE mode...

1) I would like to use ${groupId}.${artifactId} instead of the
artifact ID alone as project name in .project and (more importantly)
as Bundle-SymbolicName in META-INF/MANIFEST.MF. Is this possible?

2) In PDE mode the plugin creates linkedResources in the .project
file.. At this point it uses the absolute path of the jar file for the
location element. I think a better solution would be to define a
path variable (similar to M2_REPO) under
Preferences/General/Workspace/Linked Resources and make the location
relative to that path variable. mvn eclipse:add-maven-repo should
also add this variable to the workspace.

The absolute path should be removed from source attachments in
.classpath too. One way to accomplish this would be to create another
link in .project and use it as sourcepath in .classpath.

Here's an example that seems to work:

.project:
 linkedResources
   link
 nameognl-2.6.9.jar/name
 type1/type
 locationM2/ognl/ognl/2.6.9/ognl-2.6.9.jar/location
   /link
   link
 nameognl-2.6.9-sources.jar/name
 type1/type
 locationM2/ognl/ognl/2.6.9/ognl-2.6.9-sources.jar/location
   /link
 /linkedResources

.classpath:
 classpathentry kind=lib path=ognl-2.6.9.jar
sourcepath=ognl-2.6.9-sources.jar/

where M2 is a path variable defined under
Preferences/General/Workspace/Linked Resources or in
~/workspace/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.core.resources.prefs 


respectively.

Thanks
Markus




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

Lifecycle Goal for Injecting POM Parameters?

[Ole Ersoy]

Hi,

I posted this  on maven users, but did not get a reply, so I hope that 
it's ok that I ask here.


I created a mojo and gave it a lifecycle for a specific packaging.

After I did this, the mojo stops receiving pom parameters.

I'm assuming there is a specific goal that I have to run per the 
lifecycle to get maven to inject

the parameters?

Anyone know if this is correct and would you happen to know the 
artifactId and goal that I need to run?


Thanks,
- Ole





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

Re: [Archetypes] plugin proposition

[Ole Ersoy]

Awesome!

Incidentally does your plugin have the ability to evaluate the maven name
element when it processes the archetype templates?

There is a patch for the current archetype plugin here:

http://jira.codehaus.org/browse/ARCHETYPE-55

But if yours does it already, I'm skipping the patching and just using 
yours :-)


Thanks,
- Ole



Raphaël Piéroni wrote:

Hi,

I added it on my todo list.

Raphaël

2007/3/19, Ole Ersoy [EMAIL PROTECTED]:

Hi Raphael,

Sounds like you are doing some terrific work.

If you have time, could you please take a look at this bug:

http://jira.codehaus.org/browse/MNG-2856

When the current archetype plugin processes png images, it changes them,
and makes the unreadable.

I think if we add a binary element (possibly contained in the
resources container element) to the archetype.xml descriptor,
which tells the plugin to just copy those resources, the issue gets 
fixed.


Cheers,
- Ole



Raphaël Piéroni wrote:
 Hi all,

 Here is the resent of a mail i sent on [EMAIL PROTECTED]

 I would like to introduce the work i have done so far concerning
 archetypes.
 I have improved the current archetype mecanism by adding
 - the interactive selection of the archetype to create a project from
 - the interactive configuration of the archetype to create a 
project from
 - the interactive configuration of the archetype created from a 
project


 To acheive this i needed to refactor the archetype descriptor and
 workflow.
 I must admit having stole some code from current implementation :).

 You can checkout the sources in the mojo sandbox. Just beware when
 checking out the sources in Windows, the source tree is quite deep and
 breaks.

 I will be happy to have some feedback about it.

 The plugins comes with a little pack of archetypes.
 The core goals are :
 - generate: to generate a project from an archetype
 - create: to create an archetype from a project

 This first implementation have som limitations as the archetypes 
are for

 now mono-project.

 I copy my current todo list for starting point to discuss about :

 - package mojo: to jar the created archetype
 - sample properties mojo: to provide a sample configuration file 
for an

 archetype (which could be filled and used in batch mode)
 - descriptor with attributes: refactor the current archetype
 descriptor to
 use attributes instead of xml elements
 - generate multi project: to generate a project and its internal 
modules

 from one archetype.
 - create multi project: to create one archetype from a project with
 modules
 - CRUD group mojo: mojos to change the archetype groups defined in the
 ~/.m2/archetypes.xml
 - Documentation:  Document the workfow of user interaction, explain 
the

 internal plexus components
 - integration tests and sibling: handle directories other than 
src/main,

 src/test, src/site. a first case would be integration tests
 - pom.xml sibling: handle templates in the main directory. some use 
case

 would be readme files
 - translator: create a tool to translate current archetypes into 
this new

 way
 - archetype group metadata: create a new group metadata for archetypes
 (same
 way as plugins metadata) therefore we could have a archetype 
packaging.
 - velocity tools in templates: provide the official velocity tools 
to be

 used by archetype creators


 The plugin don't have backward compatibility yet.

 Regards,

 Raphaël


-
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: [Archetypes] plugin proposition

[Ole Ersoy]

Hi Raphael,

Sounds like you are doing some terrific work.

If you have time, could you please take a look at this bug:

http://jira.codehaus.org/browse/MNG-2856

When the current archetype plugin processes png images, it changes them, 
and makes the unreadable.


I think if we add a binary element (possibly contained in the 
resources container element) to the archetype.xml descriptor,

which tells the plugin to just copy those resources, the issue gets fixed.

Cheers,
- Ole



Raphaël Piéroni wrote:

Hi all,

Here is the resent of a mail i sent on [EMAIL PROTECTED]

I would like to introduce the work i have done so far concerning 
archetypes.

I have improved the current archetype mecanism by adding
- the interactive selection of the archetype to create a project from
- the interactive configuration of the archetype to create a project from
- the interactive configuration of the archetype created from a project

To acheive this i needed to refactor the archetype descriptor and 
workflow.

I must admit having stole some code from current implementation :).

You can checkout the sources in the mojo sandbox. Just beware when
checking out the sources in Windows, the source tree is quite deep and
breaks.

I will be happy to have some feedback about it.

The plugins comes with a little pack of archetypes.
The core goals are :
- generate: to generate a project from an archetype
- create: to create an archetype from a project

This first implementation have som limitations as the archetypes are for
now mono-project.

I copy my current todo list for starting point to discuss about :

- package mojo: to jar the created archetype
- sample properties mojo: to provide a sample configuration file for an
archetype (which could be filled and used in batch mode)
- descriptor with attributes: refactor the current archetype 
descriptor to

use attributes instead of xml elements
- generate multi project: to generate a project and its internal modules
from one archetype.
- create multi project: to create one archetype from a project with 
modules

- CRUD group mojo: mojos to change the archetype groups defined in the
~/.m2/archetypes.xml
- Documentation:  Document the workfow of user interaction, explain the
internal plexus components
- integration tests and sibling: handle directories other than src/main,
src/test, src/site. a first case would be integration tests
- pom.xml sibling: handle templates in the main directory. some use case
would be readme files
- translator: create a tool to translate current archetypes into this new
way
- archetype group metadata: create a new group metadata for archetypes 
(same

way as plugins metadata) therefore we could have a archetype packaging.
- velocity tools in templates: provide the official velocity tools to be
used by archetype creators


The plugin don't have backward compatibility yet.

Regards,

Raphaël



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

maven-metadata.xml in version level repository directory?

[Ole Ersoy]

Hi,

Just wondering if there is a purpose to having maven-metadata.xml in the 
version directories (The directories that also contain the pom for the 
project) of the maven repository?


Thanks,
- Ole





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

Re: maven-metadata.xml in version level repository directory?

[Ole Ersoy]

I mirrored a repository, and from what I can see a lot of the 
non-snapshot version directories have

the maven-metadata.xml as well.

Also, since the snapshot version is contained in maven-metadata.xml in 
at the artifactId level, should we
be duplicating it at the version level?  After all the same info is also 
in the pom.  So now it's in 3 different places.


Thoughts?

Thanks,
- Ole





Kenney Westerhof wrote:


It's only available in snapshot version directories and contains a 
list of all
the snapshot versions there and names the latest version. So it's 
useful for snapshots.


Ole Ersoy wrote:

Hi,

Just wondering if there is a purpose to having maven-metadata.xml in 
the version directories (The directories that also contain the pom 
for the project) of the maven repository?


Thanks,
- Ole





-
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: Creating a central Maven repository for OSGi bundles

[Ole Ersoy]

Hi Carloz,

Just in case you need a mojo to process the repository,
I'm almost done with this RPM Factory mojo.

I'm going to use it to RPM the maven repository, but
with a little modification, it could be used to create and add
manifests to all the jars in the maven repository as well.

I'll probably have the RPM factory in my sandbox tomorrow some time,
if you are interested.

Cheers,
- Ole



Carlos Sanchez wrote:

There are some initiatives like Apache Felix about repackaging
libraries from the maven repository until projects themselves include
the OSGi manifest.

It makes sense in the meantime to have a Maven repo with same
structure but with OSGi bundles. This repo would be temporal and
things could change over the time until it's stable.

There was already a temporal repo from eclipse installation in
http://repo1.maven.org/eclipse/ Artifacts there can go into central
with one change, bundle id = groupId + artifactId, meaning that they
are going to be stored in the repo with different name than they are
in the eclipse installation.
eg. org.eclipse.equinox.common will be group=org.eclipse.equinox 
artifact=common


About infrastructure, we'd need to know if maven.org has enough
bandwidth to host it or we need to look for alternatives. I'm gonna
run it also through [EMAIL PROTECTED] to see if we can have apache
artifacts in apache machines and sync as we do with the usual maven
repo.

comments?




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

Re: Creating a central Maven repository for OSGi bundles

[Ole Ersoy]

It processes all jar artifacts contained in a repo.

So if the repo it points to contains the whole maven repo, it will do 
the whole thing.



Carlos Sanchez wrote:

there's already a bundleall goal in the felix bundle plugin that will
generate osgi bundles for each dependency in the tree
https://issues.apache.org/jira/browse/FELIX-199

are you processing the whole repo or just a tree of dependencies

On 3/13/07, Ole Ersoy [EMAIL PROTECTED] wrote:

Hi Carloz,

Just in case you need a mojo to process the repository,
I'm almost done with this RPM Factory mojo.

I'm going to use it to RPM the maven repository, but
with a little modification, it could be used to create and add
manifests to all the jars in the maven repository as well.

I'll probably have the RPM factory in my sandbox tomorrow some time,
if you are interested.

Cheers,
- Ole



Carlos Sanchez wrote:
 There are some initiatives like Apache Felix about repackaging
 libraries from the maven repository until projects themselves include
 the OSGi manifest.

 It makes sense in the meantime to have a Maven repo with same
 structure but with OSGi bundles. This repo would be temporal and
 things could change over the time until it's stable.

 There was already a temporal repo from eclipse installation in
 http://repo1.maven.org/eclipse/ Artifacts there can go into central
 with one change, bundle id = groupId + artifactId, meaning that they
 are going to be stored in the repo with different name than they are
 in the eclipse installation.
 eg. org.eclipse.equinox.common will be group=org.eclipse.equinox
 artifact=common

 About infrastructure, we'd need to know if maven.org has enough
 bandwidth to host it or we need to look for alternatives. I'm gonna
 run it also through [EMAIL PROTECTED] to see if we can have apache
 artifacts in apache machines and sync as we do with the usual maven
 repo.

 comments?



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

Possible Maven Archetype Template Processing Bug

[Ole Ersoy]

Hi,

I have an archetype that uses a png image.

When I create archetype instances the png
image is no longer readable (And its size has
increased by 1kb, from 1.6kb).

Here's is what maven says:

[WARNING]
org.apache.velocity.runtime.exception.ReferenceException:
reference : template =
archetype-resources/src/main/resources/images/123.png
[line 9,column 50] : $I is not a valid reference.

Perhaps there should be a binary/binary element
in the archetype.xml descriptor, so that maven would
just copy the image over, instead of trying to process
it and write the result.

Thoughts?

Cheers,
- Ole




 

Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

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

Re: [Archiva] Comment on Local Repository Format Reading for DefaultMetadataDiscoverer

[Ole Ersoy]

Yes to the index of local repository part.

[CONTEXT]
My immidiate plan is to mirror the Ibiblio repository
so that it's local.

Then set the mirrors base directory on the plugin.

Then the plugin will produce a
repository-metadata.xml (Version 2)
per a JIRA entry I submitted.

This will be placed at the base of the repository.

Then the RPMFactory picks that up and starts producing
RPMs using it.

[OTHER USE CASE]
Someone may want to just create a 
repository-metadata.xml for a parent 
project.

And just create RPMs for the parent project.

Cheers,
- Ole



--- Brett Porter [EMAIL PROTECTED] wrote:

 would they use this against an index on their local
 repository, or by  
 querying a remote archiva instance?
 
 I do think we need to index the local metadata
 anyway so that the  
 code can be used from other tools.
 
 - Brett
 
 On 31/01/2007, at 3:37 PM, Ole Ersoy wrote:
 
  Hi,
 
  I'm going through the DefaultMetadataDiscoverer,
 and
  noticed this todo:
 
   * @todo Note that only the remote format is
  supported at this time: you cannot search local
  repository metadata due
   * to the way it is later loaded in the
 searchers.
  Review code using pathOfRemoteMetadata. IS there
 any
  value in
   * searching the local metadata in the first
 place
  though?
 
 
  Maybe.
  I'm for instance using the metadata files to build
 a
  bigger metadata file, for either a parent project,
 or
  the entire repository, and then using that as a
 target
  to build RPMs with.
 
  So there might be a scenario where someone wants
 to
  use the plugin to build rpms for their parent
 project,
  based on the install in the local repository, and
 they
  may want to filter some of the metadata.
 
  Cheers,
  - Ole
 
 
 
 

__
 
  __
  Bored stiff? Loosen up...
  Download and play hundreds of games for free on
 Yahoo! Games.
  http://games.yahoo.com/games/front
 
 

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



 

Sucker-punch spam with award-winning protection. 
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html

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

Re: [Archiva] Comment on Local Repository Format Reading for DefaultMetadataDiscoverer

[Ole Ersoy]

Sorry - Substitute maven-metadata.xml where I have 
repository-metadata.xml.

Cheers,
- Ole


--- Ole Ersoy [EMAIL PROTECTED] wrote:

 Yes to the index of local repository part.
 
 [CONTEXT]
 My immidiate plan is to mirror the Ibiblio
 repository
 so that it's local.
 
 Then set the mirrors base directory on the plugin.
 
 Then the plugin will produce a
 repository-metadata.xml (Version 2)
 per a JIRA entry I submitted.
 
 This will be placed at the base of the repository.
 
 Then the RPMFactory picks that up and starts
 producing
 RPMs using it.
 
 [OTHER USE CASE]
 Someone may want to just create a 
 repository-metadata.xml for a parent 
 project.
 
 And just create RPMs for the parent project.
 
 Cheers,
 - Ole
 
 
 
 --- Brett Porter [EMAIL PROTECTED] wrote:
 
  would they use this against an index on their
 local
  repository, or by  
  querying a remote archiva instance?
  
  I do think we need to index the local metadata
  anyway so that the  
  code can be used from other tools.
  
  - Brett
  
  On 31/01/2007, at 3:37 PM, Ole Ersoy wrote:
  
   Hi,
  
   I'm going through the DefaultMetadataDiscoverer,
  and
   noticed this todo:
  
* @todo Note that only the remote format is
   supported at this time: you cannot search local
   repository metadata due
* to the way it is later loaded in the
  searchers.
   Review code using pathOfRemoteMetadata. IS there
  any
   value in
* searching the local metadata in the first
  place
   though?
  
  
   Maybe.
   I'm for instance using the metadata files to
 build
  a
   bigger metadata file, for either a parent
 project,
  or
   the entire repository, and then using that as a
  target
   to build RPMs with.
  
   So there might be a scenario where someone wants
  to
   use the plugin to build rpms for their parent
  project,
   based on the install in the local repository,
 and
  they
   may want to filter some of the metadata.
  
   Cheers,
   - Ole
  
  
  
  
 

__
  
   __
   Bored stiff? Loosen up...
   Download and play hundreds of games for free on
  Yahoo! Games.
   http://games.yahoo.com/games/front
  
  
 

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


 Sucker-punch spam with award-winning protection. 
 Try the free Yahoo! Mail Beta.

http://advision.webevents.yahoo.com/mailbeta/features_spam.html
 

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



 

Have a burning question?  
Go to www.Answers.yahoo.com and get answers from real people who know.

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

Commons-vfs for Archiva?

[Ole Ersoy]

I noticed that there seems to be a lot of 
overlap between Archiva's approach to
file discovery and VFS's.

Should Archiva use VFS?

Overview:
http://wiki.apache.org/jakarta-commons/VFS

Using the API:
http://jakarta.apache.org/commons/vfs/api.html

Here's an example of how to get maven-metadata.xml
files:

public FileObject[] discoverMetadata() throws
FileSystemException
{
//MetadataDiscoverer metadataDiscoverer = new
DefaultMetadataDiscoverer();

FileSelector ff = new FileSelector()
{
public boolean includeFile(FileSelectInfo
fileInfo) throws Exception
{
FileObject fileObject = fileInfo.getFile();
return
fileObject.getName().getBaseName().contentEquals(maven-metadata.xml);
}

public boolean
traverseDescendents(FileSelectInfo fileInfo) throws
Exception
{
return true;
}
};

File file = new File(src/test/resources/);
return
VFS.getManager().resolveFile(file.getAbsolutePath()).findFiles(ff);
}




Cheers,
- Ole




 

The fish are biting. 
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php

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

Re: Commons-vfs for Archiva?

[Ole Ersoy]

Ah - OK - Cool - Just thought I'd check.

Cheers,
- Ole


--- Carlos Sanchez [EMAIL PROTECTED] wrote:

 that topic was already brought before and didn't
 succeed
 
 On 1/31/07, Ole Ersoy [EMAIL PROTECTED] wrote:
  I noticed that there seems to be a lot of
  overlap between Archiva's approach to
  file discovery and VFS's.
 
  Should Archiva use VFS?
 
  Overview:
  http://wiki.apache.org/jakarta-commons/VFS
 
  Using the API:
  http://jakarta.apache.org/commons/vfs/api.html
 
  Here's an example of how to get
 maven-metadata.xml
  files:
 
  public FileObject[] discoverMetadata()
 throws
  FileSystemException
  {
  //MetadataDiscoverer
 metadataDiscoverer = new
  DefaultMetadataDiscoverer();
 
  FileSelector ff = new
 FileSelector()
  {
  public boolean
 includeFile(FileSelectInfo
  fileInfo) throws Exception
  {
  FileObject fileObject =
 fileInfo.getFile();
  return
 

fileObject.getName().getBaseName().contentEquals(maven-metadata.xml);
  }
 
  public boolean
  traverseDescendents(FileSelectInfo fileInfo)
 throws
  Exception
  {
  return true;
  }
  };
 
  File file = new
 File(src/test/resources/);
  return
 

VFS.getManager().resolveFile(file.getAbsolutePath()).findFiles(ff);
  }
 
 
 
 
  Cheers,
  - Ole
 
 
 
 
 
 


  The fish are biting.
  Get more visitors on your site using Yahoo! Search
 Marketing.
 

http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php
 
 

-
  To unsubscribe, e-mail:
 [EMAIL PROTECTED]
  For additional commands, e-mail:
 [EMAIL PROTECTED]
 
 
 
 
 -- 
 I could give you my word as a Spaniard.
 No good. I've known too many Spaniards.
  -- The Princess Bride
 

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



 

Finding fabulous fares is fun.  
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel 
bargains.
http://farechase.yahoo.com/promo-generic-14795097

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

[Archiva] Comment on Local Repository Format Reading for DefaultMetadataDiscoverer

[Ole Ersoy]

Hi,

I'm going through the DefaultMetadataDiscoverer, and
noticed this todo:

 * @todo Note that only the remote format is
supported at this time: you cannot search local
repository metadata due
 * to the way it is later loaded in the searchers.
Review code using pathOfRemoteMetadata. IS there any
value in
 * searching the local metadata in the first place
though?


Maybe.  
I'm for instance using the metadata files to build a
bigger metadata file, for either a parent project, or
the entire repository, and then using that as a target
to build RPMs with.

So there might be a scenario where someone wants to
use the plugin to build rpms for their parent project,
based on the install in the local repository, and they
may want to filter some of the metadata.

Cheers,
- Ole


 

Bored stiff? Loosen up... 
Download and play hundreds of games for free on Yahoo! Games.
http://games.yahoo.com/games/front

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

Re: maven-metadata xml schema?

[Ole Ersoy]

OK - Cool - I thought so too...I'll just make one and
throw it in JIRA.

Thanks,
- Ole



--- Gregory Kick [EMAIL PROTECTED] wrote:

 I'm not positive, but I don't think so.  I think
 that all of the
 schemas are in http://maven.apache.org/xsd/ and I
 don't see it there.
 
 On 1/19/07, Ole Ersoy [EMAIL PROTECTED] wrote:
  Is there a xml schema available for
  maven-metadata.xml files?
 
  Thanks,
  - Ole
 
 
 
 


  Finding fabulous fares is fun.
  Let Yahoo! FareChase search your favorite travel
 sites to find flight and
  hotel bargains.
  http://farechase.yahoo.com/promo-generic-14795097
 
 

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

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



 

The fish are biting. 
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php

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

Re: maven-metadata xml schema?

[Ole Ersoy]

Thanks Wendy.

I went ahead and created two anyways.

http://jira.codehaus.org/browse/MRM-271

For those interested,
They will be used in the RPM Factory I'm creating.

It will come with a mojo that generates the
maven-metadata.xml per version 2.0.0 of the schema
for the entire repository.

Then it loads that instance, and generates RPMs for
all the libraries in the repository.

CHeers,
- Ole

--- Wendy Smoak [EMAIL PROTECTED] wrote:

 On 1/20/07, Ole Ersoy [EMAIL PROTECTED] wrote:
 
  OK - Cool - I thought so too...I'll just make one
 and
  throw it in JIRA.
 
 Most of the schemas are generated with modello.  If
 this is something
 Maven is generating, I wonder if there isn't a model
 for it somewhere
 already.
 
 (That it's not published on the website doesn't
 necessarily mean there
 isn't one.)
 
 -- 
 Wendy
 

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



 

Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

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

maven-metadata xml schema?

[Ole Ersoy]

Is there a xml schema available for 
maven-metadata.xml files?

Thanks,
- Ole


 

Finding fabulous fares is fun.  
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel 
bargains.
http://farechase.yahoo.com/promo-generic-14795097

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

Loading a list of all installed repository dependencies

[Ole Ersoy]

Hi,

Does anyone know if there is a Canned way of loading

all jar packaged artifacts in an M2 repository?

I was hoping for something like a 
maven-metadata.xml file for the entire repository.

Thanks,
- Ole




 

The fish are biting. 
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php

Re: Generating a Maven2 Repository RPM Mirror

[Ole Ersoy]

Hey Wayne,

Thanks for the tip.  I thought that was the case, just
wanted to be sure.

Yes, I am planning on generating an RPM mirror of the
entire ibiblio repo.

So I'll use your approach (Using a mojo) to write the
global maven-metadata.xml file.

Then suck that into a mojo, that generates the RPM
mirror.

Meanwhile hopefully archiva will address creating and
updating this type of file on the fly, for this type
of scenario.

Thanks,
- Ole


--- Wayne Fay [EMAIL PROTECTED] wrote:

 I'm not aware of any file which contains this kind
 of information.
 All of this information already exists in the local
 repo itself -- the
 repo is the documentation in and of itself -- you
 just have to look at
 every single file in the repo to build it up. The
 checksums are in the
 .sha1 and .md5 files and the *.pom files will give
 you the information
 you need about the artifactId, groupId, and version.
 
 So it sounds like step one of your project is to
 write some code (Perl
 etc) that scans the local repo and generates this
 meta-data.xml file
 you're looking for. Unless of course you're talking
 about generating a
 RPM mirror of the Maven repo hosted at ibiblio or
 another site, which
 would certainly complicate things a bit.
 
 Wayne
 
 On 1/17/07, Ole Ersoy [EMAIL PROTECTED] wrote:
  Hi,
 
  I need to generate an RPM mirror of the maven
  repository.
 
  I was hoping to do this by reading something like
 a
  meta-data.xml file in the Maven repository, that
  contains a list of all the projects in the
 repository,
  their corresponding artifactId, groupId, and
 version
  (And checksum would be really nice if there.).
 
  Anywone know if this type of information exists in
 the
  Maven repository?
 
  Thanks,
  - Ole
 
 
 
 
 


  Sucker-punch spam with award-winning protection.
  Try the free Yahoo! Mail Beta.
 

http://advision.webevents.yahoo.com/mailbeta/features_spam.html
 
 

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



 

TV dinner still cooling? 
Check out Tonight's Picks on Yahoo! TV.
http://tv.yahoo.com/

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

maven-metadata.xml for entire repository?

[Ole Ersoy]

Anyone know if 
maven-metadata.xml exists for the entire 
ibiblio repository?

I see 
http://mirrors.ibiblio.org/pub/mirrors/maven2/maven-metadata.xml.md5

but there is no corresponding 
maven-metadata.xml

file.

Ideas?

Thanks,
- Ole





 

We won't tell. Get more on shows you hate to love 
(and love to hate): Yahoo! TV's Guilty Pleasures list.
http://tv.yahoo.com/collections/265 

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

Re: Maven RPM Creation and Quality Control Factory

[Ole Ersoy]

Oh - cool - thanks Brett.

Do you know what the project URL for c-builds is by
chance?

I tried:

http://c-builds.codehaus.org/

I also tried googleing, and 
looking through all the confluence projects
at codehaus, but did not see a c-builds (Just so you
know I made attempts before asking :-) )

Thanks again,
- Ole


--- Brett Porter [EMAIL PROTECTED] wrote:

 Seems consistent with what's happening in the
 c-builds stuff at  
 mojo.codehaus.org - you might want to ask there?
 
 The additions to archiva sound interesting too.
 
 - Brett
 
 On 14/01/2007, at 3:35 AM, Ole Ersoy wrote:
 
  Hi,
 
  I'm in need of a RPM repository that is yum
  accessible, where all the RPMs are produced by
 Maven,
  and I wanted to check if anyone else is interested
 in
  the same thing?
 
  The primary goal is to be able to produce yum
 installs
  of Apache and other servers/applications that were
  built using a dependencies from a Maven repository
  that is synchronized with the RPM repository.
 
  There will be a layer on top of this that ensures
  Maven best practices with respect to dependency
  management and plugin management of the poms that
 are
  used to produce the RPM spec file (Later I want to
  combine it with the Archiva server for automatic
  signature checking).
 
  Here's a brief synapsis of the
 requirements/benefits.
 
  EASE OF USE
  - A Maven download with preconfigured repository
  settings pointing to a Maven repository that is
 synced
  with the corresponding RPM repository is made
  available for download.  The purpose of this
 download
  is to minimize the effort required by developers
 who
  wish to write artifacts that will commit RPMs to
 the
  repository.  Thus it will come with archetypes
 that
  produce Java projects and other project which
 ensure
  repository quality requirements are met.
 
  ONLY MAVEN BUILT ARTIFACTS IN THE REPOSITORY
  - Only Maven artifacts will be allowed in the RPM
  repository, at least in the beginning.  The reason
 for
  this is to focus quality control automation around
 a
  set of Maven plugins.
 
  ALL RPMS ARE A 1:1 MATCH WITH THE CORRESPONDING
 MAVEN
  PROJECT
  - This is so that RPMS are automatically generated
 and
  applications that depend on these RPMS have a 1:1
  match with the original dependencies that
 developers
  used when creating the application / server.
 
  SERVER INSTALL AUTOMATION TOOLS FOR RPM
  - So that servers built from the maven artifacts
 can
  be easily generated and installed.  These servers
 will
  use an the standard UNIX/LINUX FHS layout, and use
  best practices with respect to UNIX/LINUX file
  permissions and ownership.
 
  I have a lot of this work done already, I just
 wanted
  to see whether there are others interested in this
  type of approach and whether there are any
 thoughts on
  how to go about creating the central location for
 this
  type of effort?
 
  Cheers,
  - Ole
 
 
 
 
 
 
 

__
 
  __
  Don't pick lemons.
  See all the new 2007 cars at Yahoo! Autos.
  http://autos.yahoo.com/new_cars.html
 
 

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



 

It's here! Your new message!  
Get new email alerts with the free Yahoo! Toolbar.
http://tools.search.yahoo.com/toolbar/features/mail/

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

Re: Maven RPM Creation and Quality Control Factory

[Ole Ersoy]

OK - I'll try 

dev@mojo.codehaus.org

and hopefully they will see it.

Thanks,
- Ole


--- Brett Porter [EMAIL PROTECTED] wrote:

 http://svn.codehaus.org/mojo/c-builds/
 
 Don't know if it has a web site up yet at
 http://mojo.codehaus.org/
 
 On 15/01/2007, at 11:03 AM, Ole Ersoy wrote:
 
  Oh - cool - thanks Brett.
 
  Do you know what the project URL for c-builds is
 by
  chance?
 
  I tried:
 
  http://c-builds.codehaus.org/
 
  I also tried googleing, and
  looking through all the confluence projects
  at codehaus, but did not see a c-builds (Just so
 you
  know I made attempts before asking :-) )
 
  Thanks again,
  - Ole
 
 
  --- Brett Porter [EMAIL PROTECTED] wrote:
 
  Seems consistent with what's happening in the
  c-builds stuff at
  mojo.codehaus.org - you might want to ask there?
 
  The additions to archiva sound interesting too.
 
  - Brett
 
  On 14/01/2007, at 3:35 AM, Ole Ersoy wrote:
 
  Hi,
 
  I'm in need of a RPM repository that is yum
  accessible, where all the RPMs are produced by
  Maven,
  and I wanted to check if anyone else is
 interested
  in
  the same thing?
 
  The primary goal is to be able to produce yum
  installs
  of Apache and other servers/applications that
 were
  built using a dependencies from a Maven
 repository
  that is synchronized with the RPM repository.
 
  There will be a layer on top of this that
 ensures
  Maven best practices with respect to dependency
  management and plugin management of the poms
 that
  are
  used to produce the RPM spec file (Later I want
 to
  combine it with the Archiva server for automatic
  signature checking).
 
  Here's a brief synapsis of the
  requirements/benefits.
 
  EASE OF USE
  - A Maven download with preconfigured repository
  settings pointing to a Maven repository that is
  synced
  with the corresponding RPM repository is made
  available for download.  The purpose of this
  download
  is to minimize the effort required by developers
  who
  wish to write artifacts that will commit RPMs to
  the
  repository.  Thus it will come with archetypes
  that
  produce Java projects and other project which
  ensure
  repository quality requirements are met.
 
  ONLY MAVEN BUILT ARTIFACTS IN THE REPOSITORY
  - Only Maven artifacts will be allowed in the
 RPM
  repository, at least in the beginning.  The
 reason
  for
  this is to focus quality control automation
 around
  a
  set of Maven plugins.
 
  ALL RPMS ARE A 1:1 MATCH WITH THE CORRESPONDING
  MAVEN
  PROJECT
  - This is so that RPMS are automatically
 generated
  and
  applications that depend on these RPMS have a
 1:1
  match with the original dependencies that
  developers
  used when creating the application / server.
 
  SERVER INSTALL AUTOMATION TOOLS FOR RPM
  - So that servers built from the maven artifacts
  can
  be easily generated and installed.  These
 servers
  will
  use an the standard UNIX/LINUX FHS layout, and
 use
  best practices with respect to UNIX/LINUX file
  permissions and ownership.
 
  I have a lot of this work done already, I just
  wanted
  to see whether there are others interested in
 this
  type of approach and whether there are any
  thoughts on
  how to go about creating the central location
 for
  this
  type of effort?
 
  Cheers,
  - Ole
 
 
 
 
 
 
 
 
 

__
 
  __
  Don't pick lemons.
  See all the new 2007 cars at Yahoo! Autos.
  http://autos.yahoo.com/new_cars.html
 
 
 
 

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

__
 
  __
  It's here! Your new message!
  Get new email alerts with the free Yahoo! Toolbar.
 
 http://tools.search.yahoo.com/toolbar/features/mail/
 
 

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



 

Sucker-punch spam with award-winning protection. 
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html

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

Re: maven-solaris-plugin

[Ole Ersoy]

Joerg,

I'm actually in hot pursuit of discussions right now.

If you look a few posts down you will see:

Maven RPM Creation and Quality Control Factory

I'm about to send this out on 

dev@mojo.codehaus.org, to see whether there's more
interest there.

I also forwarded your solaris mojo post to
the Apache Directory project.

dev@directory.apache.org

If you by chance need a Solaris install of the Apache
Directory server, I know we would love to work with
you on it.

Cheers,
- Ole


--- Joerg Hohwiller [EMAIL PROTECTED] wrote:

 Hi there,
 
 for those who are interested:
 http://jira.codehaus.org/browse/MNG-2761
 
 Please get into discussion about creating deployment
 packages (also DEB, RPM,
 etc.) with maven.
 
 Regards
   Jörg
  Hi
  
  I think the best way is to create an issue for the
 sandbox component
  http://jira.codehaus.org/browse/MNG
  
  Cheers,
  
  Vincent
  
  2006/8/29, Joerg Hohwiller [EMAIL PROTECTED]:
  Hi there,
  
  as I promised some time ago, I wanted to provide
 my work in creating a
  maven2
  plugin for solaris packaging. I uses an ant mojo
 and only works on a
  solaris
  machine with pkgtools installed.
  
  For the moment I set in the POM
  groupId to org.apache.maven.plugins and artifactId
 maven-solaris-plugin.
  
  Should I set groupId to org.codehaus.mojo instead?
  
  Where should I put the current state?
  
  I have the plugin itself and a dummy example
 project that is using the
  plugin.
  Should I create the example as archtype?
  
  Best regards
   Jörg
 

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



 

Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/

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

Maven RPM Creation and Quality Control Factory

[Ole Ersoy]

Hi,

I'm in need of a RPM repository that is yum
accessible, where all the RPMs are produced by Maven,
and I wanted to check if anyone else is interested in
the same thing?

The primary goal is to be able to produce yum installs
of Apache and other servers/applications that were
built using a dependencies from a Maven repository
that is synchronized with the RPM repository.

There will be a layer on top of this that ensures
Maven best practices with respect to dependency
management and plugin management of the poms that are
used to produce the RPM spec file (Later I want to
combine it with the Archiva server for automatic
signature checking).

Here's a brief synapsis of the requirements/benefits.

EASE OF USE
- A Maven download with preconfigured repository
settings pointing to a Maven repository that is synced
with the corresponding RPM repository is made
available for download.  The purpose of this download
is to minimize the effort required by developers who
wish to write artifacts that will commit RPMs to the
repository.  Thus it will come with archetypes that
produce Java projects and other project which ensure
repository quality requirements are met.

ONLY MAVEN BUILT ARTIFACTS IN THE REPOSITORY
- Only Maven artifacts will be allowed in the RPM
repository, at least in the beginning.  The reason for
this is to focus quality control automation around a
set of Maven plugins.

ALL RPMS ARE A 1:1 MATCH WITH THE CORRESPONDING MAVEN
PROJECT
- This is so that RPMS are automatically generated and
applications that depend on these RPMS have a 1:1
match with the original dependencies that developers
used when creating the application / server.

SERVER INSTALL AUTOMATION TOOLS FOR RPM
- So that servers built from the maven artifacts can
be easily generated and installed.  These servers will
use an the standard UNIX/LINUX FHS layout, and use
best practices with respect to UNIX/LINUX file
permissions and ownership.

I have a lot of this work done already, I just wanted
to see whether there are others interested in this
type of approach and whether there are any thoughts on
how to go about creating the central location for this
type of effort?

Cheers,
- Ole





 

Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html 

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

Re: Request for Summary element in POM

[Ole Ersoy]

Cool - Why don't we take a look together a little
later on, as soon as I get all the mappings finished
up?

Here's a brief overview of the approach I'm using:

- Create an Ecore (Eclipse EMF Project) of the
parameters that the Spec file needs
- Set defaults that are specific to the JPackage
project (Like Vendor, etc.) (These can be changed
simply by opening the ecore xml document, changing the
default parameters, and regenerating the model)
- Store Annotations that map the spec header model 
attributes to their corresponding pom elements (I
wrote a how cookbook page on how to read these
annotations)
- This way the mapping can be updated simply by
changing the value of a fragment and regenerating the
model.
- The same EMF model is also used to generate an
Eclipse editor that can be used to edit the model.

I'm also writing a Maven POM structuring best
practices mojo that reviews a build analyzing the
structure of dependencies, etc. and make
recommendations such that the build poms conform to
what the JPackage RPM generator expects the structure
to look like in order to get a clean/valid spec. 
Right now I'm mainly working on dependencies, but the
same will add support for plugin analysis later as
well.





--- Bob Allison [EMAIL PROTECTED] wrote:

 The reason I mentioned it is that the plugin WRITES
 the spec file it uses. 
 You might want to see how I mapped POM elements into
 the spec file.  There 
 is likely to be a difference in how we are doing
 things, in which case it 
 would be good to use a uniform mapping of elements.
 
 - Original Message - 
 From: Ole Ersoy [EMAIL PROTECTED]
 To: Maven Developers List dev@maven.apache.org
 Sent: Monday, December 25, 2006 9:25 PM
 Subject: Re: Request for Summary element in POM
 
 
  Hey Bob,
 
  Thanks for the tip.  I'll probably have a look
 later
  for comparison of my approach vs. that mojo's
  approach.  Perhaps an even better mojo could be
 made
  from the combination of the two approaches :-)
 
  I'm using Eclipse's EMF project that allows me to
  easily map various POM elements to their
 corresponding
  spec values using fragment path annotations
  on the SpecDescriptor ecore model I created.  I
 wanted
  to see whether would lean to a cleaner overall and
  more manageable design.
 
  Anyways,
 
  Regardless of which mojo is used to generate the
 spec,
  a Summary element on the POM would still be very
  useful.
 
  I could just put it on the SpecDescriptor model,
 but
  then the JPackage project, and any other project,
 that
  wants to generate RPMs using Maven would
  need to provide this value outside of Maven.
 
  This means that someone other than the original
  project creator is providing the summary or
  description on the spec file, which equals less
  collaboration / consensus between the original
 project
  creator and the spec writer.
 
  Cheers,
  - Ole
 
 
  --- Bob Allison [EMAIL PROTECTED]
 wrote:
 
  You might take a look at the RPM plugin in the
 Mojo
  sandbox...
 
  - Original Message - 
  From: Ole Ersoy [EMAIL PROTECTED]
  To: Maven Developers List
 dev@maven.apache.org
  Sent: Sunday, December 24, 2006 4:38 PM
  Subject: Request for Summary element in POM
 
 
   Hi,
  
   I'm in the process of releasing an RPM Spec
  generator
   for the JPackage project, and noticed that
 there
  is a
   description element in the pom, but no summary
   element.
  
   If a summary element were added it would make
  JPackage
   spec generation more efficient, assuming
 various
   projects would put both elements to use.
  
   Can we add a summary element to the pom?
  
   I think this would be a convienent element to
 have
 
   in the sense that description could now be more
 of
  a
   detailed description and the summary...well a
  summary
   :-)
  
   I could put a JIRA in for this and update the
 xml
   schema if this sounds reasonable.
  
   Thanks,
   - Ole
  
  
  
  
 __
   Do You Yahoo!?
   Tired of spam?  Yahoo! Mail has the best spam
  protection around
   http://mail.yahoo.com
  
  
 
 

-
   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]
 
 
 
 
  __
  Do You Yahoo!?
  Tired of spam?  Yahoo! Mail has the best spam
 protection around
  http://mail.yahoo.com
 
 

-
  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: Request for Summary element in POM

[Ole Ersoy]

Hey Bob,

Thanks for the tip.  I'll probably have a look later
for comparison of my approach vs. that mojo's
approach.  Perhaps an even better mojo could be made
from the combination of the two approaches :-)

I'm using Eclipse's EMF project that allows me to
easily map various POM elements to their corresponding
spec values using fragment path annotations 
on the SpecDescriptor ecore model I created.  I wanted
to see whether would lean to a cleaner overall and
more manageable design.

Anyways,

Regardless of which mojo is used to generate the spec,
a Summary element on the POM would still be very
useful.

I could just put it on the SpecDescriptor model, but
then the JPackage project, and any other project, that
wants to generate RPMs using Maven would 
need to provide this value outside of Maven.

This means that someone other than the original
project creator is providing the summary or
description on the spec file, which equals less
collaboration / consensus between the original project
creator and the spec writer.

Cheers,
- Ole


--- Bob Allison [EMAIL PROTECTED] wrote:

 You might take a look at the RPM plugin in the Mojo
 sandbox...
 
 - Original Message - 
 From: Ole Ersoy [EMAIL PROTECTED]
 To: Maven Developers List dev@maven.apache.org
 Sent: Sunday, December 24, 2006 4:38 PM
 Subject: Request for Summary element in POM
 
 
  Hi,
  
  I'm in the process of releasing an RPM Spec
 generator
  for the JPackage project, and noticed that there
 is a
  description element in the pom, but no summary
  element.
  
  If a summary element were added it would make
 JPackage
  spec generation more efficient, assuming various
  projects would put both elements to use.
  
  Can we add a summary element to the pom?
  
  I think this would be a convienent element to have
 
  in the sense that description could now be more of
 a
  detailed description and the summary...well a
 summary
  :-)
  
  I could put a JIRA in for this and update the xml
  schema if this sounds reasonable.
  
  Thanks,
  - Ole
  
  
  
  __
  Do You Yahoo!?
  Tired of spam?  Yahoo! Mail has the best spam
 protection around 
  http://mail.yahoo.com 
  
 

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


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

Request for Summary element in POM

[Ole Ersoy]

Hi,

I'm in the process of releasing an RPM Spec generator
for the JPackage project, and noticed that there is a
description element in the pom, but no summary
element.

If a summary element were added it would make JPackage
spec generation more efficient, assuming various
projects would put both elements to use.

Can we add a summary element to the pom?

I think this would be a convienent element to have 
in the sense that description could now be more of a
detailed description and the summary...well a summary
:-)

I could put a JIRA in for this and update the xml
schema if this sounds reasonable.

Thanks,
- Ole



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

Re: Maven and Fedora

[Ole Ersoy]

I have not seen any issues with the JPackage Fedora
RPMs, and have been running with them for about 2
months now.

I just followed the instructions here:
http://fedoranews.org/mediawiki/index.php/JPackage_Java_for_FC4

They even let you easily switch between Java
implementation using an Alternatives system.



--- Steve Loughran [EMAIL PROTECTED] wrote:

 Jason van Zyl wrote:
 
  
  Have you ever tried using a cleaning installed
 Redhat and trying to use 
  the Java stuff that's installed? In the recent
 past I spent an hour 
  trying to figure out why AMQ tests were failing
 and it was because gjc 
  was picking stuff up instead of the JDK I
 installed. Then I had to go 
  remove some packages and nuke some weird symlinks.
 Multiply that by who 
  knows how many people using Java on RedHat and I
 hope you understand.
 
 
 You need better diagnostics.
 I (accidentally) tested on the default JVMs last
 month, and did find 
 things break in interesting ways. The fact that the
 system in question 
 was a firewall and an SSH-connection away merely
 complicated the matter.
 
 Nowadays we catch bits, such as here where I use
 reflection to load in a 
 class that implements  sun.misc.SignalHandler, and
 which doesnt load on 
 gjc Java.
 
 if (addShutdownHook) {
  try {
  Class irqHandlerClass =
 Class.forName(INTERRUPT_HANDLER);
  Constructor constructor = 
 irqHandlerClass.getConstructor(new Class[0]);
  InterruptHandler
 handler=(InterruptHandler) 
 constructor.newInstance(new Object[0]);
  handler.bind(INT, sfLog());
  } catch (Exception e) {
  sfLog().error(Could not create an
 interrupt handler 
 from + INTERRUPT_HANDLER
  +\nSmartFrog may be
 running on a JVM which 
 does not support this feature,e);
  }
  }
 
 We could go the other way and detect when we were
 runing on a 'free' JVM 
 by looking for kaffe, classpath or harmony classes
 and logging/warning 
 on that. Its not that we want to say 'you are
 running on someone else's 
 JVM, stop it', so much as 'you are running on
 something we have never 
 tested, please fix all the problems you encounter
 and submit the patches 
 and test results'
 
  Give me a break, I've actually tried this shit and
 it doesn't work and 
  it is extremely frustrating. I've used some form
 of RedHat for a very 
  long time and the Java stuff has yet to be a
 satisfying experience. And 
  that's what I'm afraid of for the user base.
  
  Jason.
 
 I concur, but dont think it always has to be this
 way. I also think its 
 a shame that the mono experience on Linux is better
 than the Java one. 
 Admittedly, Sun have been half the problem, but as
 that is slowly being 
 addressed, the rest of the java world has to move up
 to the challenge.
 
 Stefano M. is now running Gump on Harmony BTW.
 
 -steve
 
 
 -Steve
 

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



 

Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

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

Testing Harness Strange Behavior

[Ole Ersoy]

Hey Guys,

I'm seeing some really strange JUnit behavior in
combination with the testing harness and Eclipse EMF. 


Someone from the JUnit list suspected that it might be
due to a static in the harness setup.

Here's the scenario:

I'm testing a method, testLoadPomResource()

When I have the method by itself it tests fine.

When I put another test in front of it like this:
public void testCreateResourceSet() {
//Stub
assertTrue(true);
}

I get an exception like this:
java.lang.ExceptionInInitializerError
at
org.eclipse.emf.ecore.xml.type.impl.AnyTypeImpl.eStaticClass(AnyTypeImpl.java:83)
at
org.eclipse.emf.ecore.impl.EObjectImpl.eClass(EObjectImpl.java:210)



I get the same exception when
running JUnit with Maven or Eclipse,
so I know it is localized to
JUnit/TestHarness/EMF/Java(build 1.5.0_09-b01).

I'll paste the full test case below, in case anyone
wants to look at it further.

Cheers,
- Ole


package org.jpackage.test;

import java.io.File;
import java.io.IOException;

import org.apache.maven.artifact.Artifact;
import
org.apache.maven.artifact.factory.ArtifactFactory;
import
org.apache.maven.artifact.repository.ArtifactRepository;
import
org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout;
import
org.apache.maven.artifact.repository.layout.ArtifactRepositoryLayout;
import org.apache.maven.plugin.MojoExecutionException;
import
org.apache.maven.plugin.testing.AbstractMojoTestCase;
import org.eclipse.emf.common.util.URI;
import org.eclipse.emf.ecore.resource.Resource;
import org.eclipse.emf.ecore.resource.ResourceSet;
import org.jpackage.impl.JPackageMojoHelperBufferImpl;
import org.jpackage.impl.JPackageMojoImpl;
import org.jpackage.JPackageMojoConstants;
import org.jpackage.impl.JPackageMojoHelperImpl;

import
com.pyramidetechnologies.emf.utils.EMFUtilities;

public class JPackageMojoHelperTest extends
AbstractMojoTestCase implements JPackageMojoConstants
{

private JPackageMojoImpl mojo = null;
private ArtifactRepository artifactRepository = null;
private ResourceSet resourceSet = null;
protected void setUp() throws Exception {

// required for mojo lookups to work
super.setUp();

File pluginXml = new File(getBasedir(),
src/test/resources/plugin-config.xml);
mojo = (JPackageMojoImpl) lookupMojo(
xml2spec.mojo, org.jpackage, 1.0-SNAPSHOT,
generate, pluginXml, false);

resourceSet =
JPackageMojoHelperImpl.createResourceSet();
}

public void testCreateResourceSet() {
//Stub
assertTrue(true);
}

public void testLoadPomResource() throws
MojoExecutionException
{
String artifactId = apacheds-server-main;
String groupId = org.apache.directory.server;
String version = 1.5.0-SNAPSHOT;

ArtifactFactory artifactFactory =
mojo.getArtifactFactory();
assertNotNull(artifactFactory);

Artifact pomArtifact =
artifactFactory.createArtifact(groupId, artifactId,
version, null, pom);
assertNotNull(pomArtifact);

String path = pathOf(pomArtifact);
File file = new File(path);
assertTrue(file.exists());

pomArtifact.setFile(file);

Resource resource = null;
resource =
JPackageMojoHelperImpl.loadPomResource(pomArtifact,
resourceSet);

assertNotNull(resource);
}

private static String pathOf(Artifact artifact)
{
ArtifactRepositoryLayout artifactRepositoryLayout =
new DefaultRepositoryLayout();
String artifactPath =
artifactRepositoryLayout.pathOf(artifact);
return REPOSITORY_BASE_DIRECTORY + artifactPath;
}

private static String REPOSITORY_BASE_DIRECTORY =
/home/ole/.m2/repository/;

}


 

Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index

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

Re: Testing Harness Strange Behavior - Gotcha

[Ole Ersoy]

OK - Got it.

Apparently Eclipse EMF likes
each resourceSet = createResourceSet()

method inside each test case.

Cheers,
- Ole


--- Ole Ersoy [EMAIL PROTECTED] wrote:

 Hey Guys,
 
 I'm seeing some really strange JUnit behavior in
 combination with the testing harness and Eclipse
 EMF. 
 
 
 Someone from the JUnit list suspected that it might
 be
 due to a static in the harness setup.
 
 Here's the scenario:
 
 I'm testing a method, testLoadPomResource()
 
 When I have the method by itself it tests fine.
 
 When I put another test in front of it like this:
 public void testCreateResourceSet() {
 //Stub
 assertTrue(true);
 }
 
 I get an exception like this:
 java.lang.ExceptionInInitializerError
 at

org.eclipse.emf.ecore.xml.type.impl.AnyTypeImpl.eStaticClass(AnyTypeImpl.java:83)
 at

org.eclipse.emf.ecore.impl.EObjectImpl.eClass(EObjectImpl.java:210)
 
 
 
 I get the same exception when
 running JUnit with Maven or Eclipse,
 so I know it is localized to
 JUnit/TestHarness/EMF/Java(build 1.5.0_09-b01).
 
 I'll paste the full test case below, in case anyone
 wants to look at it further.
 
 Cheers,
 - Ole
 
 
 package org.jpackage.test;
 
 import java.io.File;
 import java.io.IOException;
 
 import org.apache.maven.artifact.Artifact;
 import
 org.apache.maven.artifact.factory.ArtifactFactory;
 import

org.apache.maven.artifact.repository.ArtifactRepository;
 import

org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout;
 import

org.apache.maven.artifact.repository.layout.ArtifactRepositoryLayout;
 import
 org.apache.maven.plugin.MojoExecutionException;
 import

org.apache.maven.plugin.testing.AbstractMojoTestCase;
 import org.eclipse.emf.common.util.URI;
 import org.eclipse.emf.ecore.resource.Resource;
 import org.eclipse.emf.ecore.resource.ResourceSet;
 import
 org.jpackage.impl.JPackageMojoHelperBufferImpl;
 import org.jpackage.impl.JPackageMojoImpl;
 import org.jpackage.JPackageMojoConstants;
 import org.jpackage.impl.JPackageMojoHelperImpl;
 
 import
 com.pyramidetechnologies.emf.utils.EMFUtilities;
 
 public class JPackageMojoHelperTest extends
 AbstractMojoTestCase implements
 JPackageMojoConstants
 {
 
 private JPackageMojoImpl mojo = null;
 private ArtifactRepository artifactRepository =
 null;
 private ResourceSet resourceSet = null;
 protected void setUp() throws Exception {
 
 // required for mojo lookups to work
 super.setUp();
 
 File pluginXml = new File(getBasedir(),
 src/test/resources/plugin-config.xml);
 mojo = (JPackageMojoImpl) lookupMojo(
 xml2spec.mojo, org.jpackage, 1.0-SNAPSHOT,
 generate, pluginXml, false);
 
 resourceSet =
 JPackageMojoHelperImpl.createResourceSet();
 }
 
 public void testCreateResourceSet() {
 //Stub
 assertTrue(true);
 }
 
 public void testLoadPomResource() throws
 MojoExecutionException
 {
 String artifactId = apacheds-server-main;
 String groupId = org.apache.directory.server;
 String version = 1.5.0-SNAPSHOT;
 
 ArtifactFactory artifactFactory =
 mojo.getArtifactFactory();
 assertNotNull(artifactFactory);
 
 Artifact pomArtifact =
 artifactFactory.createArtifact(groupId, artifactId,
 version, null, pom);
 assertNotNull(pomArtifact);
 
 String path = pathOf(pomArtifact);
 File file = new File(path);
 assertTrue(file.exists());
 
 pomArtifact.setFile(file);
 
 Resource resource = null;
 resource =
 JPackageMojoHelperImpl.loadPomResource(pomArtifact,
 resourceSet);
 
 assertNotNull(resource);
 }
 
 private static String pathOf(Artifact artifact)
 {
 ArtifactRepositoryLayout artifactRepositoryLayout =
 new DefaultRepositoryLayout();
 String artifactPath =
 artifactRepositoryLayout.pathOf(artifact);
 return REPOSITORY_BASE_DIRECTORY + artifactPath;
 }
 
 private static String REPOSITORY_BASE_DIRECTORY =
 /home/ole/.m2/repository/;
 
 }
 
 
  


 Want to start your own business?
 Learn how on Yahoo! Small Business.
 http://smallbusiness.yahoo.com/r-index
 

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



 

Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

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

Testing Harness Bug?

[Ole Ersoy]

Hi,

If I run the mojo tests in the same project that the
mojo is in, they run fine.

If I create another project with the same setup, but
different artifactId, I get the exception pasted at
the end (xml2spec.mojo.test is the new testing project
I created.  It allows me to simulate how the mojo
works without modifying the resource directories that
a project that uses the mojo would use).

It seems like the Test Harness is reading the mojo
artifact Id from the project POM, instead of the
plugin-config.xml testing pom.

Thoughts?

Thanks,
- Ole

EXCEPTION
org.apache.maven.plugin.testing.ConfigurationException:
Cannot find a configuration element for a plugin with
an artifactId of xml2spec.mojo.test.
at
org.apache.maven.plugin.testing.AbstractMojoTestCase.extractPluginConfiguration(AbstractMojoTestCase.java:217)
at
org.apache.maven.plugin.testing.AbstractMojoTestCase.extractPluginConfiguration(AbstractMojoTestCase.java:191)
at
org.apache.maven.plugin.testing.AbstractMojoTestCase.lookupMojo(AbstractMojoTestCase.java:108)
at org.jpackage.test.JPackageMojoTest.setUp(JPackageMojoTest.java:27


 

Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index

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

Re: Testing Harness Bug?

[Ole Ersoy]

Hmmm,

Sorry - Not really a bug...but more of a convenience
lookup method request.

I reviewed lookupMojo, and if these was another one
like this I think everything would work out:
protected Mojo lookupMojo(
String mojoArtifactId, 
String mojoGroupId, 
String mojoVersion, 
String goal, 
File pom )
throws Exception
{
PlexusConfiguration pluginConfiguration =
extractPluginConfiguration( artifactId, pom );

return lookupMojo( groupId, artifactId, version,
goal, pluginConfiguration );
}

I'll give this a shot next, and post back.  I have a
CLA with Apache...in case anyone wants to throw this
in with the rest of the harness.

Cheers,
- Ole


 

Any questions? Get answers on any topic at www.Answers.yahoo.com.  Try it now.

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

Re: Testing Harness Bug?

[Ole Ersoy]

Well,

I had to fudge it a little by adding a bogus
Boolean b to avoid signature conflict,
but it seems to works fine now.  Here is the
convenience method:

protected Mojo lookupMojo(
String mojoArtifactId, 
String mojoGroupId, 
String mojoVersion, 
String goal, 
File pom,
Boolean b)
throws Exception
{
PlexusConfiguration pluginConfiguration =
extractPluginConfiguration( mojoArtifactId, pom );

return lookupMojo( mojoGroupId, mojoArtifactId,
mojoVersion, goal, pluginConfiguration );
}



Here is are my JUnit test methods:

protected void setUp() throws Exception {

// required for mojo lookups to work
super.setUp();

File pluginXml = new File(getBasedir(),
src/test/resources/plugin-config.xml);
mojo = (JPackageMojo) lookupMojo(
xml2spec.mojo, 
org.jpackage, 
1.0-SNAPSHOT, 
generate, 
pluginXml, 
false);


}



public void testMojoLookup() throws Exception {
File pluginXml = new File(getBasedir(),
src/test/resources/plugin-config.xml);
mojo = (JPackageMojo) lookupMojo(
xml2spec.mojo, 
org.jpackage, 
1.0-SNAPSHOT, 
generate, 
pluginXml, 
false);

assertNotNull(mojo);
}

Cheers,
- Ole
--- Ole Ersoy [EMAIL PROTECTED] wrote:

 Hmmm,
 
 Sorry - Not really a bug...but more of a convenience
 lookup method request.
 
 I reviewed lookupMojo, and if these was another one
 like this I think everything would work out:
 protected Mojo lookupMojo(
   String mojoArtifactId, 
   String mojoGroupId, 
   String mojoVersion, 
   String goal, 
   File pom )
   throws Exception
 {
 PlexusConfiguration pluginConfiguration =
 extractPluginConfiguration( artifactId, pom );
 
 return lookupMojo( groupId, artifactId, version,
 goal, pluginConfiguration );
 }
 
 I'll give this a shot next, and post back.  I have a
 CLA with Apache...in case anyone wants to throw this
 in with the rest of the harness.
 
 Cheers,
 - Ole
 
 
  


 Any questions? Get answers on any topic at
 www.Answers.yahoo.com.  Try it now.
 

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



 

Yahoo! Music Unlimited
Access over 1 million songs.
http://music.yahoo.com/unlimited

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

Archiva Description

[Ole Ersoy]

Hi,

I was trying to come up with a description of what it
would take to make a repository really trustworthy.  

As I was writing it I thought...didn't I see something
like this on the Maven site.

So here I am.

Anyways, I wrote the description in a cookbook format.

If this matches a subset of what archiva does, then we
could use the description in the archiva documents
perhaps.

If there are differences I would be really interested
in what they are.

I'll be glad to incorporate them into the description
and resubmit, if someone has time to review the info.

Here it is (Thanks):

Challenge

 Ensuring that versioning 
 happens on maven repository artifacts,
 along with signature checking on repository
 provided dependencies.

Solution

 See discussion
 
Discussion

 Developers need to be assured
 that the versions they have in their
 local repository are not 
 updated WITHOUT a corresponding
 version revision.
 
 For example suppose 
 someone wants to try out
 ApacheDS, and they also want to build
 it themselves.  Suppose that ApacheDS
 has the following dependency:
 
 dependency
artifactIdSuperImportantArtifact/artifactId
versionSuperImportantArtifact/version
scopecompile/scope
 /dependency  
 
 Suppose the provider of SuperImportantArtifact
 makes a few changes and uploads the changes
 to ibiblio, however the provider forgets to 
 change the version correspondingly.
 
 Next someone checks out the ApacheDS build
 and builds it.
 
 Maven downloads the dependencies it needs
 from Ibiblio, including SuperImportantArtifact.
 
 However the developer is getting build errors.
 
 We know why in this case.
 
 How do we insure that this case does not happen.
 
Proposal

 * Artifact Download Concern
 
 Have the repository deployer calculate a checksum
 for artifacts and write the checksum to
repository meta
 data.  When maven deploys and artifact, have it
write the 
 checksums into the pom artifact for all the
dependencies,
 and rewrite it's own pom with these checksums
built in.
 
 So now if someone checks out the build from
subversion..say..
 the pom is checksum aware, and can validate the
corresponding
 checksum using repository meta data for
dependencies that it 
 downloads. 
  
 * Artifact Upload Concern
 
 Create a Maven Repository Server that performs
 revision checking.  If someone tries to upload
 an artifact without changing the version
(overwriting
 and existing artifact), the server complains and
sends
 the complaint back to maven.  Maven then just
logs
 it to the console.
 
 This ensures that an artifact does not get 
 overwritten without changing the version.

 * Summary
 
 I think with the above two concerns address the
process
 should be fairly tight.  We have a unique
signature on 
 dependencies, so we match this up with the
signature on the
 repository before the dependency is downloaded. 
If the signatures
 don't match, we cancel the build.
 
 We also check the upload to make sure that
version revision happens.





 

Any questions? Get answers on any topic at www.Answers.yahoo.com.  Try it now.

dependencyManagement Bug? in Eclipse Plugin

[Ole Ersoy]

Hi,

If I override a dependency
in a child pom, and then
run 

mvn eclipse:eclipse 

in the child project directory
it does not set the class path
correctly.

I uploaded the testing document
I used containing shell scripts, etc.
to my sandbox account here:

https://svn.apache.org/repos/asf/directory/sandbox/oersoy/maven-testing/eclipse-maven-testing.apt

Incidentally - Anyone know if there is an option that
makes the eclipse plugin create eclipse projects for
projects with packaging pom.  This would be really
nice for editing the dependencyManagement section of
the pom.

Here is the section of this document containing the
test for this (The mail parser may nix some of the
entities)


Challenge

 See whether we can set
 a dependency version in
 the dependency management
 section of a pom and then 
 override it on a child pom. 
 
Solution

 Run the following script



mvn archetype:create -DartifactId=L0Project
-DgroupId=test
cd L0Project
sed -e 's/jar/pom/' pom.xml | sed -e '10,18d' 
pom.xml.tmp
cat  END  pom.xml.tmp
dependencyManagement
 dependencies
  dependency

artifactIdcommons-collections/artifactId
 groupIdcommons-collections/groupId
 version2.11/version
 scopetest/scope
  /dependency
 /dependencies
/dependencyManagement
/project
END
mv pom.xml.tmp pom.xml

mvn archetype:create -DartifactId=L1Project
-DgroupId=test

pushd L1Project
sed -e '20,21d' pom.xml  pom.xml.tmp

cat  END  pom.xml.tmp
  dependency
 artifactIdcommons-collections/artifactId
 groupIdcommons-collections/groupId
 version3.2/version
 scopetest/scope
/dependency
/dependencies
/project
END

mv pom.xml.tmp pom.xml

pushd src/test/java/test

cat  END  AppTest.java
package test;

import
org.apache.commons.collections.bag.AbstractBagDecorator;

import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;


/**
 * Unit test for simple App.
 */
public class AppTest 
extends TestCase
{
/**
 * Create the test case
 *
 * @param testName name of the test case
 */
public AppTest( String testName )
{
super( testName );
}

/**
 * @return the suite of tests being tested
 */
public static Test suite()
{
return new TestSuite( AppTest.class );
}

/**
 * Rigourous Test :-)
 */
public void testApp()
{
AbstractBagDecorator emannuelsBagDecorator;
assertTrue( true );
}
}
END


popd
popd
mvn eclipse:eclipse
mvn test



Result

 The test runs fine. 











Challenge

 See whether we can import the 
 L1Project into eclipse and have
 the AbstractBagDecorator that the 
 AppTest needs loaded successfully. 
 
Solution

 Import the L1Project into 
 eclipse.
 
Result

 The AbstractBagDecorator
 does not load.

Follow Up

 Check with Maven Dev to see 
 whether this is a known bug.

Cheers,
- Ole



 

Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

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

Re: dependencyManagement Bug? in Eclipse Plugin

[Ole Ersoy]

Terrific - Thanks for the update.  I put in votes on
both :-)

Cheers,
- Ole

--- Stephen Duncan [EMAIL PROTECTED] wrote:

 Yes, this is a known issue.  See
 http://jira.codehaus.org/browse/MECLIPSE-107 and
 http://jira.codehaus.org/browse/MNG-2340
 
 -Stephen
 
 On 12/3/06, Ole Ersoy [EMAIL PROTECTED] wrote:
  Hi,
 
  If I override a dependency
  in a child pom, and then
  run
 
  mvn eclipse:eclipse
 
  in the child project directory
  it does not set the class path
  correctly.
 
  I uploaded the testing document
  I used containing shell scripts, etc.
  to my sandbox account here:
 
 

https://svn.apache.org/repos/asf/directory/sandbox/oersoy/maven-testing/eclipse-maven-testing.apt
 
  Incidentally - Anyone know if there is an option
 that
  makes the eclipse plugin create eclipse projects
 for
  projects with packaging pom.  This would be really
  nice for editing the dependencyManagement section
 of
  the pom.
 
  Here is the section of this document containing
 the
  test for this (The mail parser may nix some of the
  entities)
 
 
  Challenge
 
   See whether we can set
   a dependency version in
   the dependency management
   section of a pom and then
   override it on a child pom.
 
  Solution
 
   Run the following script
 
 


 
  mvn archetype:create -DartifactId=L0Project
  -DgroupId=test
  cd L0Project
  sed -e 's/jar/pom/' pom.xml | sed -e '10,18d' 
  pom.xml.tmp
  cat  END  pom.xml.tmp
  dependencyManagement
   dependencies
dependency
 
  artifactIdcommons-collections/artifactId
  
 groupIdcommons-collections/groupId
   version2.11/version
   scopetest/scope
/dependency
   /dependencies
  /dependencyManagement
  /project
  END
  mv pom.xml.tmp pom.xml
 
  mvn archetype:create -DartifactId=L1Project
  -DgroupId=test
 
  pushd L1Project
  sed -e '20,21d' pom.xml  pom.xml.tmp
 
  cat  END  pom.xml.tmp
dependency
  
 artifactIdcommons-collections/artifactId
   groupIdcommons-collections/groupId
   version3.2/version
   scopetest/scope
  /dependency
  /dependencies
  /project
  END
 
  mv pom.xml.tmp pom.xml
 
  pushd src/test/java/test
 
  cat  END  AppTest.java
  package test;
 
  import
 

org.apache.commons.collections.bag.AbstractBagDecorator;
 
  import junit.framework.Test;
  import junit.framework.TestCase;
  import junit.framework.TestSuite;
 
 
  /**
   * Unit test for simple App.
   */
  public class AppTest
  extends TestCase
  {
  /**
   * Create the test case
   *
   * @param testName name of the test case
   */
  public AppTest( String testName )
  {
  super( testName );
  }
 
  /**
   * @return the suite of tests being tested
   */
  public static Test suite()
  {
  return new TestSuite( AppTest.class );
  }
 
  /**
   * Rigourous Test :-)
   */
  public void testApp()
  {
  AbstractBagDecorator
 emannuelsBagDecorator;
  assertTrue( true );
  }
  }
  END
 
 
  popd
  popd
  mvn eclipse:eclipse
  mvn test
 


 
 
  Result
 
   The test runs fine.
 
 
 
 
 
 
 
 
 
 
 
  Challenge
 
   See whether we can import the
   L1Project into eclipse and have
   the AbstractBagDecorator that the
   AppTest needs loaded successfully.
 
  Solution
 
   Import the L1Project into
   eclipse.
 
  Result
 
   The AbstractBagDecorator
   does not load.
 
  Follow Up
 
   Check with Maven Dev to see
   whether this is a known bug.
 
  Cheers,
  - Ole
 
 
 
 
 


 
=== message truncated ===



 

Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index

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

XML Schema Default Attribute on Dependency Scope

[Ole Ersoy]

Hi,

Just a suggestion for an update to the scope element
in the schema.

default=compile is the addition.

This helps when generating model code from the Schema,
using frameworks like Eclipse EMF.

I've pasted the updated schema element definition
below.

  xs:element name=scope minOccurs=0
type=xs:string default=compile
xs:annotation
  xs:documentation
source=version4.0.0/xs:documentation
  xs:documentation source=description
The scope of the dependency -
lt;codegt;compilelt;/codegt;,
lt;codegt;runtimelt;/codegt;,
lt;codegt;testlt;/codegt;,
lt;codegt;systemlt;/codegt;, and
lt;codegt;providedlt;/codegt;. Used to
calculate the various classpaths used for
compilation, testing, and so on. It also assists in
determining
which artifacts to include in a
distribution of this project. For more information,
see
lt;a
href=quot;http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.htmlquot;gt;the
dependency mechanismlt;/agt;.
  /xs:documentation
/xs:annotation
  /xs:element

Cheers,
- Ole


 

Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

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

Injecting the Maven Model into a Mojo?

[Ole Ersoy]

Hey Guys,

Can I inject inject the entire Maven model into a Mojo
using annotations?

I'll be glad to elaborate further if there are any
questions on why I want to do this.

Thanks,
- Ole

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

Re: Injecting the Maven Model into a Mojo?

[Ole Ersoy]

Super - I will,

Thanks

--- Vincent Siveton [EMAIL PROTECTED] wrote:

 Please use the maven user list for user questions in
 the future...
 
 /**
  * @parameter expression=${project}
  * @required
  * @readonly
  */
 protected MavenProject project;
 
 Cheers,
 
 Vincent
 
 2006/7/21, Ole Ersoy [EMAIL PROTECTED]:
  Hey Guys,
 
  Can I inject inject the entire Maven model into a
 Mojo
  using annotations?
 
  I'll be glad to elaborate further if there are any
  questions on why I want to do this.
 
  Thanks,
  - Ole
 
  __
  Do You Yahoo!?
  Tired of spam?  Yahoo! Mail has the best spam
 protection around
  http://mail.yahoo.com
 
 

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


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

New Archetype Component - Dependency Issue

[Ole Ersoy]

Hey Guys,

I'm trying to create a new archetype component,
however I'm having issues loading the the Archetype
interface.

I put the following in the pom dependency list:

dependency
  groupIdorg.apache.maven.archetype/groupId
  artifactIdmaven-archetype-core/artifactId
  version1.0-SNAPSHOT/version
/dependency

I also tried changing the version to 2.0, but as far
as I can tell by looking at Subversion, the version is
still 1.0-SNAPSHOT.

When I run eclipse:eclipse I don't get any complaints,
just build successful.

However the api is still not available.  The eclipse
plugin usually complains if it can't download a
dependency.

Is the maven-archetype-core project not available to
maven via repositories yet?

Thanks,
- Ole

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

Re: New Archetype Component - Dependency Issue

[Ole Ersoy]

OK - Doh - I was a little quick to just copy and paste
the dependencies from the subversion pom without
adding scope.  I added compile  and now it tells me
that the project is not available.  I'll have a look
around for it or install manually.

--- Ole Ersoy [EMAIL PROTECTED] wrote:

 Hey Guys,
 
 I'm trying to create a new archetype component,
 however I'm having issues loading the the Archetype
 interface.
 
 I put the following in the pom dependency list:
 
 dependency
   groupIdorg.apache.maven.archetype/groupId
   artifactIdmaven-archetype-core/artifactId
   version1.0-SNAPSHOT/version
 /dependency
 
 I also tried changing the version to 2.0, but as far
 as I can tell by looking at Subversion, the version
 is
 still 1.0-SNAPSHOT.
 
 When I run eclipse:eclipse I don't get any
 complaints,
 just build successful.
 
 However the api is still not available.  The eclipse
 plugin usually complains if it can't download a
 dependency.
 
 Is the maven-archetype-core project not available to
 maven via repositories yet?
 
 Thanks,
 - Ole
 
 __
 Do You Yahoo!?
 Tired of spam?  Yahoo! Mail has the best spam
 protection around 
 http://mail.yahoo.com 
 

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


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

Archetype Component Development Questions

[Ole Ersoy]

Hi,

It looks like the Archetype component is pluggable,
since there's one named DefaultArchetype?  Is there
any documentation that describes how to make the
substitution happen?

I need to make one that I can substitute for the
default, such that a multi project archetype istance
can be created.

So it will create both the parent project and the
child projects.

Is anyone working on something like this already?

I tried using the same dependencies as the
maven-archetype-core project, but they are not
fetchable from the repository.

Should I just install them manually?

Thanks,
- Ole

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

Re: DefaultArchetype Code

[Ole Ersoy]

Hey Brett,

I've seen modello mentioned a few times on the maven
site, but I have not had a chance to do a head to head
comparison with EMF yet, I'm sure they both do a good
job at realizing the benefit of not having to update
hardcoded Strings.  

The reason I suggested EMF is that it can generate
the entire model based on the xml schema, so that any
time there is a change in the schema, the code can be
regenerated.

EMF is also eclipse's modeling framework, and it is
used for code generation in a lot of the eclipse
projects - like BIRT, so if Maven were to adopt it,
I'm thinking it would speed integration with other
eclipse projects, as well as maven eclipse plugins,
like the Mergere one.

Anyways, the suggestion would just mean that 
components like DefaultArchetype would 
get their maven pom default values from the generated 
model defaults.

So for instance to apply this generically to
DefaultArchetype, DefaultArchetype would import the
generated model implementation for the pom element(s)
that it needs.

So for instance for the source directory default EMF
would generated code that looks like this:

protected static final String
SOURCE_DIRECTORY_EDEFAULT = src/main/java;

protected String sourceDirectory =
SOURCE_DIRECTORY_EDEFAULT;

And then ofcoarse public getter and setters for
sourceDirectory.

So now DefaultArchetype would create an instance of 
Build, call it build say, and then do
build.getSourceDirectory();

to get the default value.

So the micro process for doing this type of
refactoring would be (And I'm sure I'm preaching to
the quire here and everywhere else, but I'd rather be
more thorough for the benefit of everyone on the
list):

- Generate the entire POM model from the XML Schema 
- Whenever defaults are needed in the maven
components,
  create an instance of the element that was generated

  and then just call getWhateverAttributeIsNeeded()
  which will return the default.

The Macro process would be:

- Go through all the source code and remove hardcoded
model defaults, or any other Strings that could be put
in the Schema and generated into the EMF model code.
- Source the defaults from the model code
- Make the entire team aware that this process is
going on so that the codebase follows the same
standard, that way whenever there is a code review,
and someone sees hard coded strings, they know to put
it in JIRA to be updated.

So I'm sure the same benefits will be achieved with
modello, if it generates code from the Schema,
including defaults.

I could put together a little tutorial on how an EMF
based model would be integrated with the maven code if
that sounds useful?  Something like taking a single
XML Schema element with defaults, using eclipse to
generate an emf model from it, and then using the emf
model to generate the java code for the POM element. 
Then using the defaults for the attributes on the POM
element in sample maven code.

Cheers,
- Ole




--- Brett Porter [EMAIL PROTECTED] wrote:

 I thought there was already a model generated with
 modello in trunk?
 
 Certainly a good idea to move these out of the code,
 though.
 
 We're interested - just let us know what you propose
 before doing it :)
 
 - Brett
 
 On 26/06/2006 1:27 PM, Ole Ersoy wrote:
  Hey Guys,
  
  Just looking over some of the code, and noticed
 this
  in 
  DefaultArchetype.
  
  private static final String
  DEFAULT_TEST_RESOURCE_DIR = /src/test/resources;
  
  private static final String
  DEFAULT_TEST_SOURCE_DIR = /src/test/java;
  
  private static final String
 DEFAULT_RESOURCE_DIR =
  /src/main/resources;
  
  private static final String DEFAULT_SOURCE_DIR
 =
  /src/main/java;
  
  I thought I'd suggest putting these defaults in
 the
  xml schema, and then generating the model using
  eclipse emf, that way the defaults are built into
 the
  model and the code that emf generates.
  
  It generates very elegant code (Interface,
  Implementation, Factories, etc.) and whenever the
 xml
  schema changes/the maven model changes, all the
  changes  it's just a few clicks and the model is
  updated.
  
  I'd be glad to help with this refactoring if there
 is
  any interest.
  
  Cheers,
  - Ole
  
  __
  Do You Yahoo!?
  Tired of spam?  Yahoo! Mail has the best spam
 protection around 
  http://mail.yahoo.com 
  
 

-
  To unsubscribe, e-mail:
 [EMAIL PROTECTED]
  For additional commands, e-mail:
 [EMAIL PROTECTED]
  
 
 
 -- 
 Brett Porter [EMAIL PROTECTED]
 Apache Maven - http://maven.apache.org/
 Better Builds with Maven -
 http://library.mergere.com/
 

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


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http

Re: DefaultArchetype Code

[Ole Ersoy]

comments inline

--- Milos Kleint [EMAIL PROTECTED] wrote:

 comments inline.
 
 On 6/27/06, Ole Ersoy [EMAIL PROTECTED] wrote:
  Hey Brett,
 
  I've seen modello mentioned a few times on the
 maven
  site, but I have not had a chance to do a head to
 head
  comparison with EMF yet, I'm sure they both do a
 good
  job at realizing the benefit of not having to
 update
  hardcoded Strings.
 
  The reason I suggested EMF is that it can generate
  the entire model based on the xml schema, so that
 any
  time there is a change in the schema, the code can
 be
  regenerated.
 
 exactly what modello does, except it's not the
 schema that is the
 ultimate source of code, it's the modello's model.
 (I guess equivalent
 to emf's model, but never actually used emf)
 

It sounds like modello has something equivalent to
EMF's ecore meta model, which is a subset of OMG's
meta object facility.  It also integrates / is
integrated with the ecipse UML2 API.

One nice thing about generating directly from the XML
Schema is that the Ecore model and the XML Schema are
kept in Sync.  If one changes, the other can be
automatically generated.  EMF can also generate an XSD
(XML Schema Definition) to Ecore Map and has a
corresponding editor for viewing this map.

 
  EMF is also eclipse's modeling framework, and it
 is
  used for code generation in a lot of the eclipse
  projects - like BIRT, so if Maven were to adopt
 it,
  I'm thinking it would speed integration with other
  eclipse projects, as well as maven eclipse
 plugins,
  like the Mergere one.
 
 can you elaborate how it's supposed to speed up
 integration when all
 it does is generated java code? or are there some
 additional features?

There are a lot of additional features.  Most, if not
all, of eclipse's MDA effort and plugins is built
around it and UML2.

See www.eclipse.org/emf and check out emf corner which
is where other open source projects / vendors build on
top of EMF and UML2.

I'll give a quick example that I discovered was not
necessary for what I was doing, but it may apply to
others.

I'm writing a code generator for Java Server Faces
components.  

I did not want to duplicate template variables in
models.  In other words I wanted to take some of the
initial project variables and pull them from the POM
and then get the rest from the EMF Java Server Faces
model.

So I grabbed the Maven XML Schema and generated all
the model code from it.

Then I created a reference to the Maven POM from the
JSF EMF model.  Now when generating code I could grab
parameters from the Maven POM and the JSF EMF model at
the same time inside the code generator.

Now since the code generator is a mojo, Maven
automatically injects the parameters, so it turns out
I did'nt need the reference, but someone else might
(Could be someone wants to integrate with maven
through an application that does not embed Maven).

An other benefit I would have realized from having the
defaults in the model would be in writing unit tests.

Since I could not just ask, for instance Build, to
give me the default for sourceDirectory, it would make
the unit tests a little more robust, without the need
to embed maven in the unit tests.  So in other words
it lets me work with Maven's default POM values,
without embedding maven.

I'm sure embedding maven is no big deal either, but
it's nice to have the flexibility.

 
 
  Anyways, the suggestion would just mean that
  components like DefaultArchetype would
  get their maven pom default values from the
 generated
  model defaults.
 
  So for instance to apply this generically to
  DefaultArchetype, DefaultArchetype would import
 the
  generated model implementation for the pom
 element(s)
  that it needs.
 
  So for instance for the source directory default
 EMF
  would generated code that looks like this:
 
  protected static final String
  SOURCE_DIRECTORY_EDEFAULT = src/main/java;
 
  protected String sourceDirectory =
  SOURCE_DIRECTORY_EDEFAULT;
 
  And then ofcoarse public getter and setters for
  sourceDirectory.
 
  So now DefaultArchetype would create an instance
 of
  Build, call it build say, and then do
  build.getSourceDirectory();
 
  to get the default value.
 
  So the micro process for doing this type of
  refactoring would be (And I'm sure I'm preaching
 to
  the quire here and everywhere else, but I'd rather
 be
  more thorough for the benefit of everyone on the
  list):
 
  - Generate the entire POM model from the XML
 Schema
  - Whenever defaults are needed in the maven
  components,
create an instance of the element that was
 generated
 
and then just call
 getWhateverAttributeIsNeeded()
which will return the default.
 
 how is that more clear than having a static constant
 value defined
 (either in the component or in the model's classes)?

If it's defined in the model's classes and referenced
in the component, then we are saying the same thing. 

The main goal to keep all the constants / default
values defined in one place so

DefaultArchetype Code

[Ole Ersoy]

Hey Guys,

Just looking over some of the code, and noticed this
in 
DefaultArchetype.

private static final String
DEFAULT_TEST_RESOURCE_DIR = /src/test/resources;

private static final String
DEFAULT_TEST_SOURCE_DIR = /src/test/java;

private static final String DEFAULT_RESOURCE_DIR =
/src/main/resources;

private static final String DEFAULT_SOURCE_DIR =
/src/main/java;

I thought I'd suggest putting these defaults in the
xml schema, and then generating the model using
eclipse emf, that way the defaults are built into the
model and the code that emf generates.

It generates very elegant code (Interface,
Implementation, Factories, etc.) and whenever the xml
schema changes/the maven model changes, all the
changes  it's just a few clicks and the model is
updated.

I'd be glad to help with this refactoring if there is
any interest.

Cheers,
- Ole

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

Question about Archetype Creation

[Ole Ersoy]

Hey Guys,

I'm throwing together some archetypes for a project
and according to the documentation all archetype
directories must contain a source filei.e. empty
directories cannot be created.

It would make my life slighly easier if the archetype
plugin could generate archetypes with empty
directories.

For instance some of the archetypes are for code
generation using jet templates, however the eclipse
builder throws exceptions when no directories exist to
generate code into.

So either I put something like dummy.java in the
src/main/java directory, I create the directory
manually, I talk to the eclipse developers to see if
the jet builder can create the source directory if it
is not availble, or I just recode the archetype mojo
(because I know more about mojo's than the jet
builder).

The last option is the most attractive, but first I
wanted to check if anyone is already in the middle of
this and if not, is this something that might be
considered a useful update?

Maven is very Do it right as it becomes an obvious
need ish which is very cool and makes a lot of
sense.  So since the eclipse jet builder is the
component that needs the directory, it would make
sense for it to create it if it's not available.

On the other hand, maven archetypes are so easy to
make that being able to create empty directories ready
for use would make for the quickest solution in code
generation cases.

So I'm really just trying to gage how the maven
developer community feels about empty directories.  Is
there a concern that people might go crazy and create
lots of empty directories that make an archetype
instance more tricky to understand, or is it really
not a big deal and we have just not gotten around to
allowing empty directories in archetype instances yet?

Cheers,
- Ole

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

Re: Maven Not Resolving Dependencies

[Ole Ersoy]

Stefan,

Myfaces has an equally named package.  It's not just
myfaces, but any dependency from the local repository.

Everything was working fine before, and then all of a
sudden stopped working.

Since eclipse resolves the dependencies in the
repository fine, I'm guessing it is an issue in the
maven compiler mojo.  Maybe maven downloaded an update
that had a bug in it.

I've gone over all directory permissions, reinstalled
java both as root and as a local user, deleted the
whole .m2 maven repository and let maven repopulate
it, and I'm maven is still not see dependencies that
it downloads and writes to disk.  I say downloads and
writes to disk because if it can write it, it should
be able to read it.  Since eclipse is resolving the
dependencies from the maven repository, we know that
it's not a java issue.

Thanks for the try though,
- Ole

--- Stefan Hübner [EMAIL PROTECTED] wrote:

 Could it be possible, that in myfaces' dependencies
 the javax.faces
 artifact is missed out? Or does myfaces contain an
 equally named
 package javax.faces...?
 
 Stefan
 
 2006/5/18, Ole Ersoy [EMAIL PROTECTED]:
  John,
 
  I'd be extremely glad to do that at this point,
  because I think I'm out of options.  I've tried
  deleting .m2, installing an older version of java
  (1.5.02), upgrading maven to 2.0.4...I could go
 back
  to ant, but that would be like plowing a field
 with a
  horse and buggie.
 
  OK - I setup a really simple project (tt) and
 here's
  the pom:
 
  project xmlns=http://maven.apache.org/POM/4.0.0;
 

xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 
 

xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
  http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdtt/groupId
artifactIdtt/artifactId
packagingjar/packaging
version1.0-SNAPSHOT/version
nameMaven Quick Start Archetype/name
urlhttp://maven.apache.org/url
dependencies
  dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version3.8.1/version
scopetest/scope
  /dependency
  dependency
  groupIdmyfaces/groupId
 
 artifactIdmyfaces-all/artifactId
  version1.1.1/version
  scoperuntime/scope
  /dependency
/dependencies
  build
  plugins
  plugin
 
 groupIdorg.apache.maven.plugins/groupId
 
 artifactIdmaven-compiler-plugin/artifactId
  configuration
 
 source1.5/source
 
 target1.5/target
  /configuration
  /plugin
  /plugins
  /build
  /project
 
  I then created a really simple class that only
 depends
  on UICompoentBase from myfaces.
 
  When I try to compile with -X I get this:
  [/home/ole/workspaces/tt]#mvn -X compile
  + Error stacktraces are turned on.
  Maven version: 2.0.4
  [DEBUG] Building Maven user-level plugin registry
  from: '/root/.m2/plugin-registry.xml'
  [DEBUG] Building Maven global-level plugin
 registry
  from:
 

'/usr/local/foundation/applications/maven-2.0.4/conf/plugin-registry.xml'
  [INFO] Scanning for projects...
  [INFO]
 


  [INFO] Building Maven Quick Start Archetype
  [INFO]task-segment: [compile]
  [INFO]
 


  [DEBUG] maven-resources-plugin: resolved to
 version
  2.2 from repository central
  [DEBUG] Retrieving parent-POM:
  org.apache.maven.plugins:maven-plugins::1 for
 project:
  null:maven-resources-plugin:maven-plugin:2.2 from
 the
  repository.
  [DEBUG] Retrieving parent-POM:
  org.apache.maven:maven-parent::1 for project:
  org.apache.maven.plugins:maven-plugins:pom:1 from
 the
  repository.
  [DEBUG] Retrieving parent-POM:
 org.apache:apache::1
  for project: org.apache.maven:maven-parent:pom:1
 from
  the repository.
  [DEBUG] maven-compiler-plugin: resolved to version
  2.0.1 from repository central
  [DEBUG] Retrieving parent-POM:
  org.apache.maven.plugins:maven-plugins::1 for
 project:
  null:maven-compiler-plugin:maven-plugin:2.0.1 from
 the
  repository.
  [DEBUG] Retrieving parent-POM:
  org.apache.maven:maven-parent::1 for project:
  org.apache.maven.plugins:maven-plugins:pom:1 from
 the
  repository.
  [DEBUG] Retrieving parent-POM:
 org.apache:apache::1
  for project: org.apache.maven:maven-parent:pom:1
 from
  the repository.
  [DEBUG]
 

org.apache.maven.plugins:maven-resources-plugin:maven-plugin:2.2:runtime
  (selected for runtime)
  [DEBUG] Retrieving parent-POM:
  org.apache.maven:maven::2.0 for project:
  org.apache.maven:maven-model:jar:2.0 from the
  repository.
  [DEBUG]  
 org.apache.maven:maven

Re: Maven Not Resolving Dependencies

[Ole Ersoy]

Greg,

You are right

Thanks a gazillion.  It actually compiles and installs
fine.

Thanks again!
- Ole

--- Grzegorz Slowikowski [EMAIL PROTECTED] wrote:

 Hi Ole
 
 myfaces dependency scope should be compile, not
 runtime:
 
 dependency
 groupIdmyfaces/groupId
 artifactIdmyfaces-all/artifactId
 version1.1.1/version
 scopecompile/scope
 /dependency
 
 or:
 
 dependency
 groupIdmyfaces/groupId
 artifactIdmyfaces-all/artifactId
 version1.1.1/version
 /dependency
 
 Greg
 
 - Original Message - 
 From: Ole Ersoy [EMAIL PROTECTED]
 To: Maven Developers List dev@maven.apache.org
 Sent: Thursday, May 18, 2006 5:15 AM
 Subject: Re: Maven Not Resolving Dependencies
 
 
  John,
 
  I'd be extremely glad to do that at this point,
  because I think I'm out of options.  I've tried
  deleting .m2, installing an older version of java
  (1.5.02), upgrading maven to 2.0.4...I could go
 back
  to ant, but that would be like plowing a field
 with a
  horse and buggie.
 
  OK - I setup a really simple project (tt) and
 here's
  the pom:
 
  project xmlns=http://maven.apache.org/POM/4.0.0;
 

xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 
 

xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
  http://maven.apache.org/maven-v4_0_0.xsd;
   modelVersion4.0.0/modelVersion
   groupIdtt/groupId
   artifactIdtt/artifactId
   packagingjar/packaging
   version1.0-SNAPSHOT/version
   nameMaven Quick Start Archetype/name
   urlhttp://maven.apache.org/url
   dependencies
 dependency
   groupIdjunit/groupId
   artifactIdjunit/artifactId
   version3.8.1/version
   scopetest/scope
 /dependency
  dependency
  groupIdmyfaces/groupId
  artifactIdmyfaces-all/artifactId
  version1.1.1/version
  scoperuntime/scope
  /dependency
   /dependencies
   build
  plugins
  plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-compiler-plugin/artifactId
  configuration
  source1.5/source
  target1.5/target
  /configuration
  /plugin
  /plugins
  /build
  /project
 
  I then created a really simple class that only
 depends
  on UICompoentBase from myfaces.
 
  When I try to compile with -X I get this:
  [/home/ole/workspaces/tt]#mvn -X compile
  + Error stacktraces are turned on.
  Maven version: 2.0.4
  [DEBUG] Building Maven user-level plugin registry
  from: '/root/.m2/plugin-registry.xml'
  [DEBUG] Building Maven global-level plugin
 registry
  from:
 

'/usr/local/foundation/applications/maven-2.0.4/conf/plugin-registry.xml'
  [INFO] Scanning for projects...
  [INFO]
 


  [INFO] Building Maven Quick Start Archetype
  [INFO]task-segment: [compile]
  [INFO]
 


  [DEBUG] maven-resources-plugin: resolved to
 version
  2.2 from repository central
  [DEBUG] Retrieving parent-POM:
  org.apache.maven.plugins:maven-plugins::1 for
 project:
  null:maven-resources-plugin:maven-plugin:2.2 from
 the
  repository.
  [DEBUG] Retrieving parent-POM:
  org.apache.maven:maven-parent::1 for project:
  org.apache.maven.plugins:maven-plugins:pom:1 from
 the
  repository.
  [DEBUG] Retrieving parent-POM:
 org.apache:apache::1
  for project: org.apache.maven:maven-parent:pom:1
 from
  the repository.
  [DEBUG] maven-compiler-plugin: resolved to version
  2.0.1 from repository central
  [DEBUG] Retrieving parent-POM:
  org.apache.maven.plugins:maven-plugins::1 for
 project:
  null:maven-compiler-plugin:maven-plugin:2.0.1 from
 the
  repository.
  [DEBUG] Retrieving parent-POM:
  org.apache.maven:maven-parent::1 for project:
  org.apache.maven.plugins:maven-plugins:pom:1 from
 the
  repository.
  [DEBUG] Retrieving parent-POM:
 org.apache:apache::1
  for project: org.apache.maven:maven-parent:pom:1
 from
  the repository.
  [DEBUG]
 

org.apache.maven.plugins:maven-resources-plugin:maven-plugin:2.2:runtime
  (selected for runtime)
  [DEBUG] Retrieving parent-POM:
  org.apache.maven:maven::2.0 for project:
  org.apache.maven:maven-model:jar:2.0 from the
  repository.
  [DEBUG]  
 org.apache.maven:maven-model:jar:2.0:runtime
  (selected for runtime)
  [DEBUG]
  org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime
  (selected for runtime)
  [DEBUG] Retrieving parent-POM:
  org.apache.maven:maven::2.0 for project:
  null:maven-project:jar:2.0 from the repository.
  [DEBUG]
  org.apache.maven:maven-project:jar:2.0:runtime
  (selected for runtime)
  [DEBUG]
 

org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8:runtime
  (selected for runtime)
  [DEBUG]
  classworlds:classworlds:jar:1.1-alpha-2:runtime
  (selected for runtime)
  [DEBUG]   junit:junit:jar:3.8.1:runtime
 (selected
  for runtime)
  [DEBUG] Retrieving parent-POM:
  org.apache.maven:maven::2.0 for project:
  org.apache.maven:maven-artifact:jar:2.0 from the
  repository.
  [DEBUG]
  org.apache.maven:maven-artifact:jar:2.0:runtime
  (selected for runtime)
  [DEBUG] Retrieving parent-POM

Maven Not Resolving Dependencies

[Ole Ersoy]

Hey Guys,

I posted this on the users list, but I'm starting that
maybe it's a bug.  I'm running 2.0.4.

Maven downloads dependencies fine from Ibiblio, and
after running the eclipse plugin, eclipse can see them
all.

However maven does not and I get messages like:

java:[4,29] package javax.faces.component does not
exist.

I recently upgraded to Java 1.5.06 and at first I
thought maybe I should not have installed it as root,
so I changed the owner and group to myself.

However maven is still not able to see dependencies.

Any ideas?

It was working fine a day ago, and the only thing
changed was upgrading the jdk from 1.5.02 to 06...

Thanks in advance,
- Ole


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

Re: Maven Not Resolving Dependencies

[Ole Ersoy]

Hi,

I'm using myfaces...version 1.1.1.

I thought it might be an issue with the myfaces
download, but I have the same issue with other
libraries as well.

Thanks for trying though,
- Ole

--- Alexandre Poitras [EMAIL PROTECTED]
wrote:


http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html
 
 Just use myfaces instead of the reference
 implementation.
 
 On 5/17/06, Ole Ersoy [EMAIL PROTECTED] wrote:
  Hey Guys,
 
  I posted this on the users list, but I'm starting
 that
  maybe it's a bug.  I'm running 2.0.4.
 
  Maven downloads dependencies fine from Ibiblio,
 and
  after running the eclipse plugin, eclipse can see
 them
  all.
 
  However maven does not and I get messages like:
 
  java:[4,29] package javax.faces.component does not
  exist.
 
  I recently upgraded to Java 1.5.06 and at first I
  thought maybe I should not have installed it as
 root,
  so I changed the owner and group to myself.
 
  However maven is still not able to see
 dependencies.
 
  Any ideas?
 
  It was working fine a day ago, and the only thing
  changed was upgrading the jdk from 1.5.02 to 06...
 
  Thanks in advance,
  - Ole
 
 
  __
  Do You Yahoo!?
  Tired of spam?  Yahoo! Mail has the best spam
 protection around
  http://mail.yahoo.com
 
 

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


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

Re: Maven Not Resolving Dependencies

[Ole Ersoy]

, Ole Ersoy [EMAIL PROTECTED] wrote:
 
  Hi,
 
  I'm using myfaces...version 1.1.1.
 
  I thought it might be an issue with the myfaces
  download, but I have the same issue with other
  libraries as well.
 
  Thanks for trying though,
  - Ole
 
  --- Alexandre Poitras
 [EMAIL PROTECTED]
  wrote:
 
  
 

http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html
  
   Just use myfaces instead of the reference
   implementation.
  
   On 5/17/06, Ole Ersoy [EMAIL PROTECTED]
 wrote:
Hey Guys,
   
I posted this on the users list, but I'm
 starting
   that
maybe it's a bug.  I'm running 2.0.4.
   
Maven downloads dependencies fine from
 Ibiblio,
   and
after running the eclipse plugin, eclipse can
 see
   them
all.
   
However maven does not and I get messages
 like:
   
java:[4,29] package javax.faces.component does
 not
exist.
   
I recently upgraded to Java 1.5.06 and at
 first I
thought maybe I should not have installed it
 as
   root,
so I changed the owner and group to myself.
   
However maven is still not able to see
   dependencies.
   
Any ideas?
   
It was working fine a day ago, and the only
 thing
changed was upgrading the jdk from 1.5.02 to
 06...
   
Thanks in advance,
- Ole
   
   
   
 __
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam
   protection around
http://mail.yahoo.com
   
   
  
 

-
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]
  
  
 
 
  __
  Do You Yahoo!?
  Tired of spam?  Yahoo! Mail has the best spam
 protection around
  http://mail.yahoo.com
 
 

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


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

[jira] Commented: (MNG-1649) Allow plugins to depend upon other plugin's goals

[Ole Ersoy (JIRA)]

[ http://jira.codehaus.org/browse/MNG-1649?page=comments#action_56293 ] 

Ole Ersoy commented on MNG-1649:


Hi,

I've been reading through all the maven 2 documentation to understand how I can:
Use Case A) Define a new archetype and give it's own lifecycle.
Use Case B) Redefine the lifecycle of a current archetype

Before I started I tried to think of the simplest way to do this, so I had a 
reference point for how it is currently being done.

Here's an example of what I think would be the simplest way to do use case A:
- Define the archetype just as specified in the guide to creating archetypes
http://maven.apache.org/guides/mini/guide-creating-archetypes.html

- Then add to the pom something like this:
Routing-Sequences
Sequence id=1
goal name=p1:g1
/goal
goal name=p2:g1
/goal
goal name=p3:g1
/goal
goal name=p4:g1
/goal
/Sequence
Sequence id=2
goal name=p1:g1
/goal
goal name=p4:g1
/goal
goal name=p3:g1
/goal
goal name=p5:g1
/goal
/Sequence
/Routing-Sequences

This would let maven know how to process the files given by an archetype 
instance.

In this case the sequences are mutually exclusive.  So they can be performed in 
paralell if need be.  The order in which the plugin goals are executed is the 
order in which they are given.

Now if I needed to do Use Case B I would just put something like this in the 
POM 
for that archetype instance:
Sequence
goal name=px:g1 sequence=1 depends=p2:g1
/Sequence

This lets maven know that it needs to perform goal g1 of plugin px after goal 
g1 of plugin p2 of sequence 1.

Now since Maven executes phases in the lifecycle,
lifecycle metadata could be bound to each goal element within each sequence, 
and
the user could just do 
mvn sequence1:deploy ...

Obviously the sequence would need to be specified if there are multiple 
sequences.

Any thoughts?

Thanks,
- Ole

 Allow plugins to depend upon other plugin's goals
 -

  Key: MNG-1649
  URL: http://jira.codehaus.org/browse/MNG-1649
  Project: Maven 2
 Type: Bug

 Versions: 2.0
 Reporter: Mark Hobson
  Fix For: 2.1



 Need to resolve the use-case discussed on dev:
 http://www.nabble.com/Re%3A-m2-Plugins-that-depend-on-other-plugin-goals-t473646.html

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

Simpler Lifecycle Configuration?

[Ole Ersoy]

Hi,

I posted this as a comment on:
http://jira.codehaus.org/browse/MNG-1649

but figured I'd air it out here as well to see if it's
sounds reasonable.

I've been reading through all the maven 2
documentation to understand how I can:
Use Case A) Define a new archetype and give it its own
lifecycle.
Use Case B) Redefine the lifecycle of a current
archetype

Before I started I tried to think of the simplest way
to do this, so I had a reference point for how it is
currently being done.

Here's an example of what I think would be the
simplest way to do use case A:

* Define the archetype just as specified in the
guide to creating archetypes
 
http://maven.apache.org/guides/mini/guide-creating-archetypes.html

* Then add to the pom something like this:
Routing-Sequences
   Sequence id=1
  goal name=p1:g1
  /goal
  goal name=p2:g1
  /goal
  goal name=p3:g1
  /goal
  goal name=p4:g1
  /goal
  /Sequence
  Sequence id=2
  goal name=p1:g1
  /goal
  goal name=p4:g1
  /goal
  goal name=p3:g1
  /goal
  goal name=p5:g1
  /goal
  /Sequence
/Routing-Sequences

This would let maven know how to process the files
given by an archetype instance.

In this case the sequences are mutually exclusive. So
they can be performed in paralell if need be. The
order in which the plugin goals are executed is the
order in which they are given.

Now if I needed to do Use Case B I would just put
something like this in the POM
for that archetype instance:
Sequence
goal name=px:g1 sequence=1 depends=p2:g1
/Sequence

This lets maven know that it needs to perform goal g1
of plugin px after goal g1 of plugin p2 of sequence 1.

Now since Maven executes phases in the lifecycle,
lifecycle metadata could be bound to each goal
element within each sequence, and
the user could just do
mvn sequence1:deploy ...

Obviously the sequence would need to be specified if
there are multiple sequences.

Any thoughts?

Thanks,

- Ole



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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