Re: need info about Maven

[Tomasz Pik]

On Thu, Jan 5, 2012 at 12:08 AM, Ansgar Konermann
 wrote:
> Am 04.01.2012 19:45, schrieb Shamitha Reddy:
>> the Microsoft JDBC Driver for SQL Server, can be made available within Maven
>
> Hi Shamitha,

[...]

> Another option is to make your JAR file compatible with the requirements
> of "the world-wide central library of Maven artifacts", or "Maven
> Central" for short. This means some more preparation from your side [8]
> and is only advisable if your product is intended to be used by a wide
> audience, preferrably as open source software. Your JAR file could then
> be deployed to Maven Central and any Maven installation could
> automatically pull it from there, without the need for uploading it to a
> corporate repository manager first.

I'd like to add, that many developers (including myself) would be very
happy, if they
could get Microsoft JDBC Driver for SQL Server directly from Maven Central
repository.

Regards,
Tomek

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

Re: fetching latest release of an artifact

[Tomasz Pik]

On Fri, Oct 16, 2009 at 9:18 PM, Peter Janes
 wrote:
> On 16/10/09 11:45 AM, Stephen Connolly wrote:
>>
>> 2009/10/16 Peter Janes
>>
>>> On 15/10/09 05:45 AM, Stephen Connolly wrote:
>>>
 These are very dangerous versions to suggest use of.
>>>
>>> ...but there *are* use cases for them.
>>
>> When your use case results in a completely unpredictable build... no thank
>> you.
>>
>> For dependencies, use version ranges.
>>
>> For plugins, you should always lock down the version.
>>
>> That is best practice, and that is what we should support.
>
> OK, I guess what I really need is something like HIGHEST-RELEASE and
> HIGHEST-SNAPSHOT.  I don't think version ranges will support this case, as
> the version in use could be anything in the range; RELEASE/LATEST would work
> locally (since we generally perform incremental releases rather than
> patches) but not in the general case.

This http://jira.codehaus.org/browse/MENFORCER-51 will probably help you.

Regards,
Tomek

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

Re: How Mercury resolution works?

[Tomasz Pik]

On Fri, Dec 19, 2008 at 7:29 PM, Oleg Gusakov
 wrote:
> a diagram of mercury inner workflow is here:
> http://blogs.sonatype.com/people/?p=1016

One minor change - there should be a1 = 1 instead of a = 1.

Regards,
Tomek

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

Re: [VOTE] POM Element for Source File Encoding

[Tomasz Pik]

On Sat, Apr 5, 2008 at 7:20 PM, Hervé BOUTEMY <[EMAIL PROTECTED]> wrote:

[...]

>  The full proposal is here:
>  
> http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding

Non-binding +1

Regards,
Tomek

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

Re: [Vote] Release Maven Plugin Tools projects

[Tomasz Pik]

On 3/6/08, Vincent Siveton <[EMAIL PROTECTED]> wrote:
> Hi,
>
>  The Maven Plugin Tools projects are ready to be released. It includes
>  the following sub-projects:
>  * maven-plugin-plugin-2.4

I'm worry it might be too late but..
Is there a chance to change image for marking 'non reports' goals
to something... different? I'm sorry that I cannot provide any replacement
but while looking on
http://maven.apache.org/plugins-tools/maven-plugin-plugin-2.4/plugin-info.html
I'm under impression that those marked as 'red' are... deprecated?
not-yet-finished?
I know what this red mark vs green mark means but if  It'd be a maven
novice, I'd be scarred using something marked as 'red'.

Just a thought,
Tomek

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

Re: [VOTE] Release Maven Toolchains version 1.0

[Tomasz Pik]

On Sat, Mar 1, 2008 at 8:33 PM, Milos Kleint <[EMAIL PROTECTED]> wrote:
> Hi,
>
>  Please vote on the maven-toolchain 1.0 artifact.
>  The background for the release:
>  http://mail-archives.apache.org/mod_mbox/maven-dev/200802.mbox/[EMAIL 
> PROTECTED]
>  http://docs.codehaus.org/display/MAVEN/Toolchains
>
>  Unfortately I've messed up and released the bits already. As
>  instructed by Wendy Smoak I've added gpg signatures. Please
>  double-check that everything is ok.
>
>  Repo:
>  
> http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/maven/maven-toolchain/1.0/

Hmm, doesn't this location means that vote may be considered as 'passed'
because this has been synced to main repo:
http://repo1.maven.org/maven2/org/apache/maven/maven-toolchain/1.0/

Regards,
Tomek

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

Re: Plexus classloader

[Tomasz Pik]

On Mon, Feb 25, 2008 at 11:21 AM, Bengali Bengali <[EMAIL PROTECTED]> wrote:
> I need to find annotated classes and generate an XML file.
>  Since i haven't found any good library to scan source files for annotations.
>
>  I decided to compile classes -> then run my maven plugin to find
>  annotations.

What about this one:
http://myfaces.apache.org/tobago/tobago-tool/maven-apt-plugin/introduction.html

Regards,
Tomek

>
>  I have been able to do it instantiating my own classloader (adding it
>  target/classes directory)
>  and running my class scanner to detect annotations. It works now but i have
>  to perform some reflection to instantiate my scanner in its own classloader.
>  I thought of using my class scanner directly in my maven plugin and run the
>  plugin in a URLClassLoader that has already the classes/target url in it.
>
>  Hope i have been clear enough.
>
>  Thanks
>  Luc
>
>  On Sat, Feb 23, 2008 at 1:59 AM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>
>  > It has the code for populating a classloader, and anything in Maven
>  > uses plexus. If you're writing a Maven plugin it uses plexus.
>  >
>  > What exactly are you trying to do aside from populating a classloader
>  > with the classes and dependencies of the current project?
>  > On 22-Feb-08, at 1:55 PM, Bengali Bengali wrote:
>  >
>  >
>  >
>

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

Re: Maven Archetype Plugin 2.0-alpha-2

[Tomasz Pik]

On Sat, Feb 23, 2008 at 1:20 AM, Brian Fox <[EMAIL PROTECTED]> wrote:
> The Maven team would like to announce the release of Maven Archetype
>  2.0-alpha-2. This release corrected backwards compatibility with the
>  1.0 version and a few windows issues. The site has also been updated
>  and deployed: http://maven.apache.org/plugins/maven-archetype-plugin

Could you please verify this?
I've just checked and there's 'Last Published: 10 Feb 2008' and most of
'navigation' links points to 'page not found'.

Regards,
Tomek

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

Re: An Attribute Based POM

[Tomasz Pik]

On Feb 11, 2008 1:23 PM, Brett Porter <[EMAIL PROTECTED]> wrote:

> I'm collecting these up to put back into the wiki later on

Please, add also:


  


or something similar.

> though
> this initial attempt is intended not to change the model just yet
> (though it's very feasible with the current codebase as it has model
> conversion built in).

Agree.

Regards,
Tomek

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

Re: [VOTE] Release Maven Archetype plugin version 2.0-alpha-1

[Tomasz Pik]

On Feb 5, 2008 11:14 AM, Brett Porter <[EMAIL PROTECTED]> wrote:
>
> On 05/02/2008, at 8:50 PM, Tomasz Pik wrote:
>
> > On Feb 5, 2008 9:03 AM, Raphaël Piéroni <[EMAIL PROTECTED]>
> > wrote:
> >> The main list is the internal catalog.
> >> It is also possible to define a specific catalog
> >> by -DarchetypeCatalog=http://repo.company.com/maven2 the catalog
> >> is an xml file located at the root and called archetype-catalog.xml.
>
> Should archetype catalog reside at the group level, to be consistent
> with the plugin metadata?
>
> >>
> >
> > Perhaps it would be a good addition to archiva: creating such catalog
> > on the fly using database of artifacts already handled by archiva.
> > It would be a kind of chicken-egg thing (given archetype is not on
> > a list because nobody asked for it and nobody asked for it because
> > it's not on a list) but this also may be handled in 'distributed way'
> > (while asking for catalog archiva will go through proxied
> > repositories,
> > asking for their catalogs and result will be a sum of all
> > repositories).
>
> Yep - this should be no problem - we essentially do the same thing for
> the metadata already, so the addition of a consumer could do this. It
> would also need to learn how to merge the metadata so that it can be
> proxied properly but everything else is in place. Would you like to
> file a request in JIRA?

But where? :)
As an issue for archetypes: "Should archetype catalog reside at the group
level, to be consistent with the plugin metadata?"
Or as an issue for archiva: "archiva should be able to merge archetype catalogs
as they are defined currently in archetype plugin"?
With 'catalogs at group level' it will be more complex and finally ends up
as a 'provide a list of artifacts with given packaging type' and some metadata
about it.

Regards,
Tomek

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

Re: [VOTE] Release Maven Archetype plugin version 2.0-alpha-1

[Tomasz Pik]

On Feb 5, 2008 9:03 AM, Raphaël Piéroni <[EMAIL PROTECTED]> wrote:
> The main list is the internal catalog.
> It is also possible to define a specific catalog
> by -DarchetypeCatalog=http://repo.company.com/maven2 the catalog
> is an xml file located at the root and called archetype-catalog.xml.

Perhaps it would be a good addition to archiva: creating such catalog
on the fly using database of artifacts already handled by archiva.
It would be a kind of chicken-egg thing (given archetype is not on
a list because nobody asked for it and nobody asked for it because
it's not on a list) but this also may be handled in 'distributed way'
(while asking for catalog archiva will go through proxied repositories,
asking for their catalogs and result will be a sum of all repositories).

Regards,
Tomek

>
> The process that populates a catalog during deploy. is not currently working.
>
> Regards,
>
> Raphaël
>
> 2008/2/5, Arnaud HERITIER <[EMAIL PROTECTED]>:
>
> > +1
> > Great work.
> > How the plugin find the list of archetypes ? More particularly, how in a
> > corporate environment I can access to our custom archetypes ? We just have
> > to upload them in our internal repository ?
> >
> > Arnaud
> >
> > On Feb 4, 2008 11:35 PM, Raphaël Piéroni <[EMAIL PROTECTED]> wrote:
> >
> > > Hi,
> > >
> > > http://people.apache.org/~rafale/site/maven-archetype-plugin/
> > >
> > > Here is the actual documentation.
> > > Please consider it is a work in progress.
> > >
> > > Raphaël
> > >
> > > 2008/2/4, Brian E. Fox <[EMAIL PROTECTED]>:
> > > > It's interactive by default so pretty easy to use. The other new goal is
> > > create-from-project where you run it in a project and it will walk you
> > > through making an archetype of that project (it goes into
> > > /target/generated-sources where you can then go and install/deploy it)
> > > >
> > > > -Original Message-
> > > > From: Raphaël Piéroni [mailto:[EMAIL PROTECTED]
> > > > Sent: Monday, February 04, 2008 3:36 AM
> > > > To: Maven Developers List
> > > > Subject: Re: [VOTE] Release Maven Archetype plugin version 2.0-alpha-1
> > > >
> > > > How to use it :
> > > > mvn archetype:create.
> > > >
> > > > Regards,
> > > >
> > > > Raphaël
> > > >
> > > > 2008/2/4, Jorg Heymans <[EMAIL PROTECTED]>:
> > > > > (sorry for hijacking the vote thread for this)
> > > > >
> > > > > Hi Raphaël,
> > > > >
> > > > > Can you give us some pointers to list threads, proposals or specs that
> > > > > explain the basics of the new architecture and how to use it ? I'm
> > > very keen
> > > > > to try it out and give you all the feedback you want, but if it means
> > > > > grepping the sources to find out how things work i'll hold off until
> > > > > alpha-2.
> > > > >
> > > > > Thanks!
> > > > > Jorg
> > > > >
> > > > > On Feb 2, 2008 1:25 AM, Raphaël Piéroni <[EMAIL PROTECTED]>
> > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Here comes the time for calling the first release of the Maven
> > > > > > Archetype plugin version 2.0-alpha-1.
> > > > > >
> > > > > > Staging repo:
> > > > > >
> > > http://people.apache.org/~rafale/staging-repo/maven-archetype-plugin/
> > > 
> > > > > >
> > > > > > Staging site:
> > > > > > No staging site now, the new documentation is not yet written.
> > > > > > Its is planed for version 2.0-alpha-2.
> > > > > >
> > > > > > Vote open for 96 hours.
> > > > > >
> > > > > > [ ] +1
> > > > > > [ ] +0
> > > > > > [ ] -1
> > > > > >
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Raphaël
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > ..
> > Arnaud HERITIER
> > ..
> > OCTO Technology - aheritier AT octo DOT com
> > www.octo.com | blog.octo.com
> > ..
> > ASF - aheritier AT apache DOT org
> > www.apache.org | maven.apache.org
> > ...
> >
>

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

Re: [release] introduce a "releaseProfiles" parameter on PerformReleaseMojo

[Tomasz Pik]

On Jan 10, 2008 9:16 AM, nicolas de loof <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I'd like to introduce a new option in the release:perform mojo to set some
> additional profiles to get enabled during release (MRELEASE-313).

A big non-binding +1 - it would be very useful (at least IMHO).

> In my projects I use to put all tasks non required at developemnt time in
> "release" profile (example : add buildnumber in jar MANIFEST,  ...) so that
> the developer build gets simplier and quicker. During release, I need to
> enabe this profile. To ensure this is not omitted, I'd like the release
> plugin to have a parameter for some release-time required profiles. The
> performRelease=true option is not enough as this enables the maven super-POM
> profile that I don't want to use (I don't need sources.jar neither javadocs)
>
> I have a working change on the plugin, based on a new :
> /**
>  * Comma separated profiles to enable on deployment, in addition to
> active profiles
>  * for project execution.
>  *
>  * @parameter
>  */
> private String releaseProfiles;
>
> Any objection to commit this and deploy a new 2.0-beta-8-SNAPSHOT ?
>
> Nico.
>

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

Re: [vote] release maven war plugin 2.1-alpha-1

[Tomasz Pik]

On 10/19/07, Stephane Nicoll <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'd like to release maven war plugin 2.1-alpha-1. This version brings
> a complete refactoring of the packaging as well as the overlay
> mechanism. One can now specify the order in which overlays are applied
> in a "first-win" strategy.

non-binding +1
I've compiled some projects and didn't encounter problems.

Thanks,
Tomek

PS I'd suggest extend 72 hours vote window because of weekend.

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

Re: Maven WAR plugin

[Tomasz Pik]

On 10/15/07, olivier lamy <[EMAIL PROTECTED]> wrote:
> Hi,
> I have fixed both (thanks for the patch).
> A new maven-war-plugin snapshot have been deployed
> maven-war-plugin-2.1-alpha-1-20071015.195227-3.jar.
> Can you try it ?

Works perfectly, I've tried 5 different projects and didn't find
any issues.

Thanks a lot,
Tomek

PS Now I need to lobby for plexus-utils release I guess...

>
> Thanks,
> --
> Olivier
>
>
> 2007/10/14, Tomasz Pik <[EMAIL PROTECTED]>:
> >
> > On 10/14/07, Stephane Nicoll <[EMAIL PROTECTED]> wrote:
> > > I have identified an issue in the latest changes (zip overlays). I
> > > have reopened the issue (MWAR-104).  As soon as we address this, we
> > > can call a vote.
> >
> > What about MWAR-123?
> > I've tested maven-war-plugin with plexus-utils containing patch
> > attached to http://jira.codehaus.org/browse/PLXUTILS-50
> > and I did not encounter any problem (and filtering with '@'
> > works correctly).
> >
> > And current behavior is very problematic, at least for me.
> >
> > Regards,
> > Tomek
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Olivier
>

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

Re: Maven WAR plugin

[Tomasz Pik]

On 10/14/07, Stephane Nicoll <[EMAIL PROTECTED]> wrote:
> I have identified an issue in the latest changes (zip overlays). I
> have reopened the issue (MWAR-104).  As soon as we address this, we
> can call a vote.

What about MWAR-123?
I've tested maven-war-plugin with plexus-utils containing patch
attached to http://jira.codehaus.org/browse/PLXUTILS-50
and I did not encounter any problem (and filtering with '@'
works correctly).

And current behavior is very problematic, at least for me.

Regards,
Tomek

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

Re: Automatically updating the repository for MySQL Connector/J

[Tomasz Pik]

On 10/5/07, Mark Matthews <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi folks,
>
> We've been handing you .jars for awhile, but I finally got our web team
> to setup a rsync repository so that we can do this automagically.
>
> I have been working with Henri Yandell, through MAVENUPLOAD-1552, but I
> wanted to see if you had any tools that could maintain the repository
> structure based on the .jar files (with embedded POMs) that we've been
> sending you.
>
> We don't use Maven to build our stuff, so I'm not really clued in on
> what I have to do to get this all to work. I'm perfectly okay if you
> tell me to "RTFM", I just don't know where in the manual to look this
> stuff up.

Here's RTFM you're looking for:
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
Please, scroll down to 'Sync'ing your own repository to the central
repository automatically'.

Regards,
Tomek

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

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Tomasz Pik]

On 5/1/07, Hervé BOUTEMY <[EMAIL PROTECTED]> wrote:

Le mardi 1 mai 2007, Jerome Lacoste a écrit :
> Maybe there could be an easy way to let users use the latest ? maybe
> something like
>   mvn -L  ...  ( L for latest)
> that would ignore all specified versions, without requiring a POM
> change ? Maybe too radical.
such a LATEST option would be very usefull, not only for plugins but for every
dependencies, to do regression testing against latest development version of
everything. It would be like if Gump was integrated into Maven:
http://gump.apache.org/

I think we would need to differentiate plugin latest from dependencies latest.


This LATEST thing is already in jira: http://jira.codehaus.org/browse/MNG-2431
And I think it would be very useful, both for plugins and for 'normal
dependencies'.

Regards,
Tomek

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

Re: Note on copying staged repositories

[Tomasz Pik]

On 4/22/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:

Hi,

I just copied the staged repo for the clover plugin over and I used
the following:

mvn stage:copy -Dsource="http://people.apache.org/~vmassol/maven-
staging" -Dtarget="scp://people.apache.org/www/people.apache.org/repo/
m2-ibiblio-rsync-repository" -Dversion=2.4


Will it copy all artifacts with version=2.4 from one repository to another?
I think that optional groupId/artifactId parameters would be useful,
what does others think about it?

Regards,
Tomek

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

Re: [vote] Release 2.2-beta-1 of maven-assembly-plugin

[Tomasz Pik]

On 3/28/07, John Casey <[EMAIL PROTECTED]> wrote:

Hi everyone,

I wanted to call a vote to release a beta version of the new assembly
plugin. There are still some outstanding issues (though not as many as jira
would have you believe; they just need tests), but I think we're at around
95-99% backward compatibility and the new features seem to be working well.


[...]


So, let's try for 24hrs. Please vote +1/+0/-1.


Non-binding +1.

Thanks!
Tomek

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

exit code on windows

[Tomasz Pik]

Hello,

After running some tests I've found that on Windows
maven-invoker-plugin is not handling errors correctly.
POMs for invoked projects may be broken and m-i-p
still reports them as success.
There's a couple of resolved issues in MNG JIRA
related to exit error code on windows and currently
mvn.bat contains
if "%MAVEN_TERMINATE_CMD%" == "on" exit %ERROR_CODE%
which means, that if mvn.bat will be invoked with
MAVEN_TERMINATE_CMD environment variable
set to 'on', then script will return non-zero code
if build will fail. Which is exactly as expected...
.. as long, as script is being invoked with this variable
being set.
But mvn.bat invoked from DefaultInvoker is invoked
without any changes in environment so without this
variable being set by default.
Using 'exit %ERROR_CODE%' means also, that 'cmd'
running maven will also be closed so it's not too practical
for windows users to set this value - they needs to open
new window every time so it's not a good idea to set
MAVEN_TERMINATE_CMD=on as global value.
So - to make all of this working as expected (to make
maven-invoker-plugin reports failed tests as failures)
cli.addEnvironment("MAVEN_TERMINATE_CMD", "on");
needs to be added to DefaultInvoker.
Where in JIRA I should added this as an issue?

Regards,
Tomek

PS I've also found a more practical workaround :)
remove /B in last line of mvn.bat and use cygwin to
run 'mvn' shell script. So main maven execution is
controlled by cygwin and child executions are controlled
by mvn.bat, which returns error code as expected.
Probably mvn.bat may set up this variable before executing
java so child executions will return exit codes and main script
(the same script, main execution in fact) will use global value?
WDYT?

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

Re: [VOTE] Release Maven 2.0.5 (take 2)

[Tomasz Pik]

On 2/12/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:

Hi,

The assemblies that people are interested in are staged here:

http://people.apache.org/~jvanzyl/staging-repository/org/apache/maven/
maven-core/2.0.5/

Here is the JIRA roadmap:

http://jira.codehaus.org/secure/IssueNavigator.jspa?
reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/
order=DESC


Error code from mvn.bat is not returned correctly on windows,
solution described at continuum site is not working so maven-invoker-plugin
cannot be treat as reliable tool.
Steps to reproduce:
* checkout maven-antrun-plugin
* break one pom.xml files inside src/it/test_n directories
* run mvn install at project level
maven-invoker-plugin will report all tests as 'passed' but 'build.log'
file in directory with broken pom will contain errors.

Should I add it into JIRA?

Regards,
Tomek

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

Re: [VOTE] Release Maven 2.0.5

[Tomasz Pik]

On 1/12/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:


On 12 Jan 07, at 2:15 PM 12 Jan 07, Tomasz Pik wrote:

> On 1/12/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>
>> http://people.apache.org/~jvanzyl/maven-2.0.5/org/apache/maven/maven-
>> core/2.0.5/
>
> Can something be done with:
> tar: A lone zero block at 4174
>
> It's with tar 1.16 on windows/cygwin
>
> Not a bug but a little annoying warning.
>

Not going to happen for this release, but create an issue. Tell me
what it is and I'll assign it to 2.0.6.


here you are:
http://jira.codehaus.org/browse/MNG-2762

Regards,
Tomek

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

Re: [VOTE] Release Maven 2.0.5

[Tomasz Pik]

On 1/12/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:


http://people.apache.org/~jvanzyl/maven-2.0.5/org/apache/maven/maven-
core/2.0.5/


Can something be done with:
tar: A lone zero block at 4174

It's with tar 1.16 on windows/cygwin

Not a bug but a little annoying warning.

Regards,
Tomek

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

maven-war-plugin v2.0.2 in jira

[Tomasz Pik]

Hi,

It looks that version 2.0.2 of maven-war-plugin is not marked as relesed
in jira so changes are not visible in changelog - they are in roadmap.
Can somebody take care about this?

Thanks,
Tomek

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

Re: [VOTE] Rename repository manager

[Tomasz Pik]

On 8/10/06, Brett Porter <[EMAIL PROTECTED]> wrote:

Please vote for one of the following names:

[x] Archiva


Non-binding +1

Tomek Pik

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

Re: Configure plugins through settings.xml

[Tomasz Pik]

On 6/19/06, John Allen <[EMAIL PROTECTED]> wrote:

Tomasz Pik  gmail.com> writes:
>
> Hello,
>
> It's currently not possible but generally I think it would be nice to have
> possibility to configure plugins through profiles using $HOME/.m2/settings.xml


Please note there are some bugs in maven that prevent all of the aspects of
plugin configurations from working properly from within profiles (i.e. defined
inside profiles).


Do you (or somebody else) know, which ones and generally, if there's
a chance to have plugins configured through profiles in settings.xml
in near future?
This really blocks me from using cargo at this moment - I cannot put
whole cargo plugin configuration into every pom I have to provide a way
to override server configurations across developers and test/prod
environments.

thanks in advance,
Tomek

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

Re: Common API for issue tracking systems

[Tomasz Pik]

On 7/7/06, Mik Kersten <[EMAIL PROTECTED]> wrote:

Eclipse.org provides us with an excellent download infrastructure and
mirroring system, so it's probably simplest to use that.  It would make
bundling the JARs and maintaining dependencies Mylar's responsibility.
Anything extra you would need (i.e. the poms) would be best as a
contribution you make to the Ant build script.  Would that work?


Yes. But this brings up a bigger question about providing jars
in a way that Maven will be able to use (which means a repository
with given layout of directories/fiels) - is there a way to setup such
a thing on eclipse.org infrastructure?
I don't know if this thread is a good place to start such a discussion.
I remember that somebody (Brett?) was talking with one of eclipse
projects (PDE?) about switching their builds to maven so maybe
in future this project will provide it's jars in maven way 'out of the
box'.


Note that 0.6.0 is not ready for being used in this way because it has the
Tasks API in the mylar.tasklist, which is coupled into the UI.  Bug for that
is:

149981: extract tasks framework from mylar.tasklist
https://bugs.eclipse.org/bugs/show_bug.cgi?id=149981


Pehaps we should move disussion about this to more appopriate place,
mylar newsgroup or 'dev' list?

Regards,
Tomek


Mik

> -Original Message-
> From: Tomasz Pik [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 07, 2006 1:45 AM
> To: Mik Kersten
> Cc: [EMAIL PROTECTED]; Maven Developers List
> Subject: Re: Common API for issue tracking systems
>
> On 7/7/06, Mik Kersten <[EMAIL PROTECTED]> wrote:
>
> > Could you please create a bug report for us to indicate how you want to
> get
> > this API, e.g. have a downloadable bin+src JAR, separate JARs, build
> from
> > source?  http://www.eclipse.org/mylar/bugs.php
>
> Ideally I'd like just to define, that my code depends on mylar libraries
> and maven will download them from ibblio mirrors.
> But this comes down to disussion about maintaining libraries on
> ibiblio, I don't know if mylar team is interested in providing jars
> and poms in a needed form.
> Please, let me know this, otherwise I'll try to prepare such set
> based on mylar 0.6.0 distribution and open an issue for adding them
> to ibiblio (perhaps asking Mylar team to review dependencies and other
> things first).
>
> Regards,
> Tomek




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

Re: Common API for issue tracking systems

[Tomasz Pik]

On 7/7/06, Mik Kersten <[EMAIL PROTECTED]> wrote:


Could you please create a bug report for us to indicate how you want to get
this API, e.g. have a downloadable bin+src JAR, separate JARs, build from
source?  http://www.eclipse.org/mylar/bugs.php


Ideally I'd like just to define, that my code depends on mylar libraries
and maven will download them from ibblio mirrors.
But this comes down to disussion about maintaining libraries on
ibiblio, I don't know if mylar team is interested in providing jars
and poms in a needed form.
Please, let me know this, otherwise I'll try to prepare such set
based on mylar 0.6.0 distribution and open an issue for adding them
to ibiblio (perhaps asking Mylar team to review dependencies and other
things first).

Regards,
Tomek

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

Re: Common API for issue tracking systems

[Tomasz Pik]

On 7/4/06, Mik Kersten <[EMAIL PROTECTED]> wrote:

Thanks for pulling me in Jason, this is good timing.  In terms of Mylar's
'Connectors' we currently have a robust and well tested framework for
querying Bugzilla and JIRA.  Trac will be ready for experimentation within a
week or so, and no, there is no Mantis connector yet.  The Bugzilla
connector is already being used headless on the server by other projects,
and we are a bout to de-couple the generic task/issue management API from
Eclipse as well.


So it seems that the roadmap will be:
* Mylar project will provide 'Abstraction API' for and implementations for
 various trackers;
* Maven wil use those libraries in plugins that will deal with trackers
right?
Or you're going to move 'generic task/issue mgmt API' out of Mylar,
to somewhere elese (Maven Issue projects/Codehaus ? :)

Regards,
Tomek



It would be great to have Maven be a driver for that and we would be happy
to package the API in a way that makes it easy for Maven to consume.  To get
started, would it suffice if we produced a JAR with a JRE 1.5 and
org.eclipse.runtime dependency that provided you API for doing the
following:
1) create a repository (e.g. bugzilla)
2) query the repository, get bugs back, check values
3) operate on one or more bugs (e.g. change milestones, submit)

Mik

--
Mik Kersten, http://kerstens.org/mik
Mylar Project Lead, http://eclipse.org/mylar

> -Original Message-
> From: Jason van Zyl [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 03, 2006 11:05 AM
> To: Maven Developers List
> Cc: Mik Kersten
> Subject: Re: Common API for issue tracking systems
>
> Hi,
>
> One person who should definitely be pulled into the discussion is Mik
> Kersten. He's the fellow who works on Mylar and has integration for
> Bugzilla and JIRA and I think Mantis. He's got some code that would
> definitely be of use.
>
> Mik, are you interested creating a general library for issue
> management here?
>
> Sorry for just pulling you in here but I figure it's just easier to
> get you involved as the topic has come up :-)
>
> Jason.
>
> On 3 Jul 06, at 5:07 PM 3 Jul 06, Mark Hobson wrote:
>
> > Hi there,
> >
> > I was wondering whether any thought had been given to an abstract
> > issue tracking API with implementations for Bugzilla, JIRA, etc.?  I
> > can see a couple of uses within maven:
> >
> > * Querying the issues fixed when releasing a new version of a project,
> > to be used within the maven-changes-plugin
> >
> > * Creating a new version of a product in the underlying issue tracking
> > system when releasing a new version of a project
> >
> > I couldn't see this abstraction in the maven-changes-plugin, but
> > correct me if I'm wrong.
> >
> > I've recently written some code to programmatically manipulate
> > Bugzilla, and thought this could be expanded into a general-purpose
> > abstract API for manipulating issue tracking systems.  Rather like
> > Wagon is to transports and SCM is to SCMs.
> >
> > It'd be good to see Bugzilla support within maven and I'd be
> > interested in people's thoughts.
> >
> > Cheers,
> >
> > Mark
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> Jason van Zyl
> [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: Common API for issue tracking systems

[Tomasz Pik]

On 7/4/06, Brett Porter <[EMAIL PROTECTED]> wrote:

On 4/07/2006 8:16 PM, Steve Loughran wrote:
> very +1 too, though I'd like it decoupled from any partiucular build
> tool if possible, primarily because you can do other things outside the
> build itself. Imagine apps auto-opening bugreps on system crashes, for
> example.

None of the shared libraries (be it wagon, scm, doxia, issue, jxr, the
repository tools, etc) are coupled to a particular build tool. It's only
Ant that does that :)

Just flicking through it, there doesn't seem to be much there for the
issue stuff but I know that a couple of people have a keen interest
here, and there is code in the changes plugin, and some ruby code that
possibly does a bit more.

http://svn.apache.org/viewvc/maven/sandbox/issue/


And here: http://svn.sourceforge.net/viewcvs.cgi/itapi/project/trunk/
is a kind of 'issue tracker' abstracton and working client for mantis
(which has creating new issue and some report possibility).

I'd like to contubute this in some way to maen issue project.

Regards,
Tomek

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

Re: what to do if jar not available on ibiblio?

[Tomasz Pik]

On 6/9/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:

Is there a common pattern people follow when a jar you need isn't available
on ibiblio, but also isn't compatible with the ASF license wise? In
particular I'm finding one project that requires the latest version of
javassist (3.1), which for whatever reason hasn't been published on ibiblio.


Can I publish it for them? Heh..Guess not.
http://www.jboss.org/products/list/downloads#javassist


Well, it seems that you may use JBoss Maven2 repo directly
http://repository.jboss.com/maven2/


Jesse Kuhnert
Tacos/Tapestry, team member/developer


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

Re: what to do if jar not available on ibiblio?

[Tomasz Pik]

On 6/9/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:

Is there a common pattern people follow when a jar you need isn't available
on ibiblio, but also isn't compatible with the ASF license wise? In
particular I'm finding one project that requires the latest version of
javassist (3.1), which for whatever reason hasn't been published on ibiblio.


Can I publish it for them? Heh..Guess not.
http://www.jboss.org/products/list/downloads#javassist


this is LGPL so may be published on iblblio.
you may use this as starting point:
http://maven.apache.org/guides/mini/guide-maven-evangelism.html

Regards,
tomek

Jesse Kuhnert
Tacos/Tapestry, team member/developer


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

Configure plugins through settings.xml

[Tomasz Pik]

Hello,

It's currently not possible but generally I think it would be nice to have
possibility to configure plugins through profiles using $HOME/.m2/settings.xml
Here's a simple example why it would be useful:
consider maven-eclipse-plugin and application using spring.
Some developers working on this application using 'plain' Eclipse, some
of them have SpringIDE installed.
So it they want to be able just execute mvn eclipse:eclipse to have
project working in eclipse, there's a need for having two profiles in
main pom.xml, one for eclipse with IDE and one for others.
Now there's another developer using NetBeans, next using only vi
and of course somebody with emacs. They are not interested in
having any Eclipse-related things in project. And 'hints' for
maven-eclipse-plugin
are in fact not a part of project itself. That's why I think there should
be a possibilty to define this in $HOME/.m2/settings.xml, not at project
level. And then if somebody wants to have SpringIDE settings, (s)he
executing mvn -PspringIDE eclipse:eclipse, others use different profiles
(WebTools for example).
I think there may be similar problems with container setup for Cargo
(do I really need to provide 'places' for every containers so developers
may choose them between them?).

I know that such approach, with plugins 'driven by settings.xml' may
not be portable, But, on the other side, does it really makes sense
to put on iblblio poms having profiles for different eclipse settings?

Please, consider adding plugin configuration to profiles in settings.xml

Tomek

PS or I'm missing a simple solution somewhere?

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

Re: [vote] Release Maven WAR plugin 2.0

[Tomasz Pik]

On 3/31/06, Brett Porter <[EMAIL PROTECTED]> wrote:
> Vote open for 72 hours, based on:
> maven-war-plugin 2.0-20060331.041208-2 (r390317)
>
> [ ] +1
> [ ] +0
> [ ] -1

Non-binding +0  (+10!) from happy user,

Thanks,
Tomek

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

Re: tests in a JAR file and surefire

[Tomasz Pik]

On 3/31/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> It means that test can be reused in other projects, so you can extend
> or use them from the tests in that project. What is the point of
> runing the same tests again in another project?

For example when you want to test some implementations of given API.
And tests 'bootstraps' implementation using some properties.
Something like TCK for JAXP implementation for example, with tests
starting with -Djavax.xml.parsers.DocumentBuilderFactory=my.jaxp.impl.DBF
(I've never seen a TCK for JAXP but I can imagine that such approach
for testing implementations makes sense).

Regards,
Tomek

> On 3/31/06, Pablo <[EMAIL PROTECTED]> wrote:
> > Hello everyone
> >
> > Is it possible to run tests using maven-surefire-plugin when the tests
> > are in a JAR file ?
> > I can see that SurefirePlugin uses
> > org.apache.maven.surefire.battery.DirectoryBattery exclusively and
> > presume that it's not possible to use tests in JAR.
> > DirectoryBattery uses DirectoryScanner which checks if the baseDir is a
> > directory. If not it throws an Exception.
> >
> > However in the page:
> > http://maven.apache.org/guides/mini/guide-attached-tests.html
> > there's written that it's possible to reuse tests using tests-jar.
> >
> > Can someone tell me what it is meant for and how it can be used in
> > surefire plugin?
> >
> > 
> >   ...
> >   
> > 
> >   com.myco.app
> >   foo
> >   1.0-SNAPSHOT
> >   test-jar
> > 
> >   
> >   ...
> > 
> >
> >
> > Cheers
> > Pablo
> >
> > -
> > 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]
>
>

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

Re: [PROPOSAL] Integration testing proposal for Maven 2.0.x

[Tomasz Pik]

On 26/01/06, Brett Porter <[EMAIL PROTECTED]> wrote:

> I have the following concerns:
> - adding an "it" scope. I haven't seen explained how this will behave,
> nor the impact on existing plugins.

Maybe 'itest' (instead of 'it') will be easier to understand for those, who
see it for the first time?

Regards,
Tomek

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

Re: [m2]: include war in war

[Tomasz Pik]

On 17/08/05, Stephane Nicoll <[EMAIL PROTECTED]> wrote:
> Hey,
> 
> Sounds rather weird. How would you merge the web.xml files?

XSLT or something similar for example.
Customizing war is such a way makes a lot of sense for me.
Consider 'application-1.1.war' which is located in repository.
As web application, application-1.1.war provides very simple
HTML.
And consider project referencing application-1.1.war, consisting
of set of SiteMesh decorators, CSS files and other stuff like this.
With some discipline, upgrade from version 1.1 to 2.0 of 'application'
will be just a version change in POM, and 'application' will still
be customized.
Similar things for adding/removing security constraint and so on...

To answer Solo's question - I'm sorry I don't know...

Regards,
Tomek

> 
> s/
> 
> On 8/17/05, solo turn <[EMAIL PROTECTED]> wrote:
> > hi,
> >
> > would it make sense to allow including a war into a war? so you could
> > take a standard war without touching it, and add specific things to
> > it, jars, tld, html, class. or would this be ugly? how would you do
> > that then?
> >
> > -solo
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> 
> --
> .::You're welcome ::.
> 
> -
> 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]

[jira] Created: (CONTINUUM-250) Continuum should not update SCM url for Maven1 projects.

[Tomasz Pik (JIRA)]

Continuum should not update SCM url for Maven1 projects.


 Key: CONTINUUM-250
 URL: http://jira.codehaus.org/browse/CONTINUUM-250
 Project: Continuum
Type: Bug
  Components: continuum-core  
 Reporter: Tomasz Pik


I've some Maven1 projects with parametrized SCM urls, in form of
scm:cvs:pserver:${scm1.server}:/root/to/repo:module
They are correct for Maven1 - SCM plugin works with them very good.
Continuum do not handle them as there's no way to specify value for 
${scm1.server} property (and I think it's OK).
Continnum loads evaluated project.xml (with ${scm1.server} replaced by correct 
value) and starts building peoject but after checkout updates in internals 
(ContinuumProject) value for SCM url with one from project.xml
so in next build SCM url is invalid.
As a resolution for this I'd like to propose:
1. add an option to import Maven1 project using SCM url only (and read rest of 
properties from loaded POM) so user may provide evaluated version (this is a 
good thing to be done in plugin for Maven1)
2. do not update ContiuumProject.scmURL based on POM;


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

Re: JIRA vs changes.xml (was RE: svn commit: r179026 - /maven/maven-1/plugins/trunk/scm/xdocs/changes.xml)

[Tomasz Pik]

On 5/30/05, Brett Porter <[EMAIL PROTECTED]> wrote:

> >In long term I think it might be a good idea to provide some kind of 
> >abstraction
> >layer for issue trackers (like maven-scm for cvs/scm/other things) to cover
> >JIRA, mantis and other tools like this.
> >
> >
> Good idea, volunteering? :)

I'm not saying NO :)
I'm trying to define scope for such a thing as issues are/may be used
in some places. At least in two of them, changelogs and scm reports.

> We actually had that in mind - you'll see the Maven2 POM has an
> "issueManagement" section with a URL and system key.

I didn't look yet, does 'system' means 'JIRA' for example?

Thanks,
Tomek

> - Brett

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

Re: JIRA vs changes.xml (was RE: svn commit: r179026 - /maven/maven-1/plugins/trunk/scm/xdocs/changes.xml)

[Tomasz Pik]

On 5/30/05, Vincent Massol <[EMAIL PROTECTED]> wrote:

[...]

> I think we need to have the JIRA plugin working to use this approach as end
> users will want to see the changes when looking at a plugin's web site.
> 
> Also, before we can move to this approach we would also need to modify the
> announcement plugin to support the JIRA plugin. ATM it's using the
> changes.xml file only.

Please, note that JIRA is not used in all projects.
So, using JIRA plugin to generate 'changelogs' in annocemenets results in
empty changelogs for projects not using JIRA.

In long term I think it might be a good idea to provide some kind of abstraction
layer for issue trackers (like maven-scm for cvs/scm/other things) to cover
JIRA, mantis and other tools like this.

Regards,
Tomek

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

Re: 1.0.1 release

[Tomasz Pik]

On Fri, 24 Sep 2004 20:34:07 +1000, Brett Porter <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> I'm planning to roll out the 1.0.1 release. I think just a private test
> release will be sufficient before a vote as this is all bugfixes and
> already released plugins (with the exception of the following). Any
> objections?
> 
> On the note of plugins: do the leads have any in mind they want
> released? I'd prefer to see only bugfixes going in from this stage to
> keep them stable and backwards compat with 1.0.
> 
> I'd like to release as they are:

[...]

Is it possible to add Jalopy plugin to the list.
There's fix for http://jira.codehaus.org/browse/MPJALOPY-6 commited
and not released.

Thanks in advance,
Tomek

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

Re: XML Catalogs

[Tomasz Pik]

bob mcwhirter wrote:
Ah, catalogs are actually a wonderful thing.  They translate identifiers
to something system-specific, typically.  They are mircales in SGML and
XML has been knocked for not having them previously.
Has the w3c done a catalog spec?
OASIS: 
http://www.oasis-open.org/committees/download.php/2384/cs-entity-xml-catalogs-1.0.html

I posted some of ideas about XML processing in maven.
It's rather for support for XML processing rather then solving
cross-projects problems but I thing it might be worth to mention
it here.
I cannot find this email in archives so I'm copying content here
=
During using war/ear plugins I've found that it will be very useful
to have the possibility to verify deployment descriptors.
I know that validating against DTD is not enough but I think it's
worth a while to find some kind of general solution.
First thought was: just add war-related DTDs as resources for war
plugins and call xml-commons resolver-driven validation.
Same for other plugins.
But there're some problems with such attempt:
* DTDs should be embed into plugins;
* there's no way to add additonal verification like 'my webapp
  is using Castor so let's validate mapping.xml too during war
  build' because it's not clear where to put those DTDs;
Some of them have working SYSTEMID so may be loaded directly
during verification but this won't work offline and slow down
Maven.
Another idea that comes to me was to specify DTDs as deps, something
like

  webapp
  servletapi
  2.3
  dtd

but this is not enough because there's not enough information to
solve validation problem because there's no way to get PUBLIC/SYSTEM
IDs of given DTD having only DTD so some external info is needed.
In theory this may be added as properties in  but it's not
a good idea...
So at least it looks for me that with DTD there should be a catalog
entry defining DTD. So xml-validator may download all 'dtd', 'xsd',
'xslt', 'ent' and maybe other files and their 'cat' descriptors,
build one catalog for all of them and then validate given set of files.
This comes to a problem of having two things instead of one and this
is not playing good with Maven dependency model...
After all I think that it might be a good idea to define some kind
of 'xmlarchive' to handle XML in Maven-way. 'xar' or something like
this. With catalog file in META-INF and other files packaged as
java class files.
And finally, with such thing docbook plugin may rely on 'xar' package
containing DocBook stylesheets stored on iBiblio...
What's the opinion about all of this?
Regards,
Tomek
PS1 more about resolving and catalogs 
http://xml.apache.org/commons/components/resolver/resolver-article.html
PS2 I know Ant has all of this implemented but the problem is not
in calling validator but in locating DTD/XSD/XSLT files.


Regards,
Tomek
	-bob


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

xml files handling Re: cvs commit: maven-plugins/docbook plugin.jelly project.xml

[Tomasz Pik]

On 2004-01-15 23:00, Ben Walding wrote:

styles/* => These are probably the only things that would be caught up 
by an LGPL license. As such I've removed them. I may reimplement them 
soon / get some kind of release from Hibernate.
During using war/ear plugins I've found that it will be very useful
to have the possibility to verify deployment descriptors.
I know that validating against DTD is not enough but I think it's
worth a while to find some kind of general solution.
First thought was: just add war-related DTDs as resources for war
plugins and call xml-commons resolver-driven validation.
Same for other plugins.
But there're some problems with such attempt:
* DTDs should be embed into plugins;
* there's no way to add additonal verification like 'my webapp
  is using Castor so let's validate mapping.xml too during war
  build' because it's not clear where to put those DTDs;
Some of them have working SYSTEMID so may be loaded directly
during verification but this won't work offline and slow down
Maven.
Another idea that comes to me was to specify DTDs as deps, something
like

  webapp
  servletapi
  2.3
  dtd

but this is not enough because there's not enough information to
solve validation problem because there's no way to get PUBLIC/SYSTEM
IDs of given DTD having only DTD so some external info is needed.
In theory this may be added as properties in  but it's not
a good idea...
So at least it looks for me that with DTD there should be a catalog
entry defining DTD. So xml-validator may download all 'dtd', 'xsd',
'xslt', 'ent' and maybe other files and their 'cat' descriptors,
build one catalog for all of them and then validate given set of files.
This comes to a problem of having two things instead of one and this
is not playing good with Maven dependency model...
After all I think that it might be a good idea to define some kind
of 'xmlarchive' to handle XML in Maven-way. 'xar' or something like
this. With catalog file in META-INF and other files packaged as
java class files.
And finally, with such thing docbook plugin may rely on 'xar' package
containing DocBook stylesheets stored on iBiblio...
What's the opinion about all of this?
Regards,
Tomek
PS1 more about resolving and catalogs 
http://xml.apache.org/commons/components/resolver/resolver-article.html
PS2 I know Ant has all of this implemented but the problem is not
in calling validator but in locating DTD/XSD/XSLT files.



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